TCP的窗口滑动机制

TCP的滑动窗口主要有两个作用,一是提供TCP的可靠性,二是提供TCP的流控特性同时滑动窗口机制还体现了TCP面向字节流的设计思路。

可靠:对发送的数据进行确认

流控制:窗口大小随链路变化。

一、tcp窗口机制

tcp中窗口大小是指tcp协议一次传输多少个数据。因为TCP是一个面向连接的可靠的传输协议,既然是可靠的就需要对传输的数据进行确认。TCP的窗口机制有两种,一种是固定窗口大小,另一种是滑动窗口。数据在传输时,TCP会对所有数据进行编号,发送方在发送过程中始终保持着一个窗口,只有落在发送窗口内的数据帧才允许被发送;同时接受方也始终保持着一个接收窗口,只有落在窗口内的数据才会被接收。这样通过改变发送窗口和接收窗口的大小就可以实现流量控制。

二、tcp窗口大小

tcp的窗口滑动技术通过动态改变窗口的大小来调节两台主机之间数据传输。每个TCP/IP主机支持全双工数据传输,因此TCP有两个滑动窗口,一个用于接收数据,一个用于发送数据。接收方设备要求窗口大小为0时,表明接收方已经接收了全部数据,或者接收方应用程序没有时间读取数据,要求暂停发送。

TCP在传送数据时,第一次发数据发送方的窗口大小是由链路带宽决定的,但是接受方在接收到发送方的数据后,返回ack确认报文,同时也告诉了发送方自己的窗口大小,此时发送发第二次发送数据时,会改变自己的窗口大小和接受方一致。

当窗口过大时,会导致不必要的数据来拥塞我们的链路,但是窗口太小时,会造成很大的延时,比如为1时,发送方没发送一个数据,接受方就会返回一个ack报文,在发送方未接收到接受方的确认报文ack之前不会进行下一次发送。当链路变好了或者变差了这个窗口还会发生变话,并不是第一次协商好了以后就永远不变了。

三、窗口滑动协议

是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待接收确认报文前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输。 只有在接收窗口向前滑动时(与此同时也发送了确认),发送窗口才有可能向前滑动。收发两端的窗口按照以上规律不断地向前滑动,因此这种协议又称为滑动窗口协议。

原文地址:https://www.cnblogs.com/liuqing576598117/p/10271789.html

时间: 2024-10-12 09:41:13

TCP的窗口滑动机制的相关文章

TCP数据量--滑动窗口、拥塞窗口、慢启动、Negle算法 经受时延的确认等

TCP的数据流大致可以分为两类,交互数据流与成块的数据流.交互数据流就是发送控制命令的数据流,比如relogin,telnet,ftp命令等等:成块数据流是用来发送数据的包,网络上大部分的TCP包都是这种包. 很明显,TCP在传输这两种类型的包时的效率是不一样的,因此为了提高TCP的传输效率,应该对这两种类型的包采用不同的算法. 总之,TCP的传输原则是尽量减少小分组传输的数量. TCP的交互式数据流 ?         经受时延的确认技术 TCP的交互式数据流通常使用"经过时延的确认"

TCP接收/发送滑动窗口与内核接收/发送缓冲区之间的关系

在有关TCP连接的很多配置中,有很多选项有的配置 net.ipv4.tcp_rmem:这个参数定义了TCP接收缓冲(用于TCP接收滑动窗口)的最小值.默认值.最大值 net.ipv4.tcp_wmem:这个参数定义了TCP发送缓冲(用于TCP发送滑动窗口)的最小值.默认值.最大值 netdev_max_backlog:当网卡接收数据包的速度大于内核处理的速度时,会有一个队列保存这些数据包.这个参数表示队列的最大值 rmem_default:这个参数表示内核套接字接收缓存区默认的大小 wmem_d

浅谈TCP的窗口字段

该掸掸这里的灰尘了,写一篇关于TCP的文章吧.今天的主题是TCP的滑动窗口.在开始这个话题之前,我想先提几个关于TCP协议的常见误区. 误区1:TCP协议三次握手过程中后两个包都是[ACK]包. 解释:这种说法并不错,只是不严谨.首先,第一个包是[SYN],SYN位在TCP报头flag字段中,见上图TCP报头结构.第二个包更确切地说应该叫[SYN,ACK]包,因为除了ACK位被置位以外,SYN位也被置位了.第三个包才是单纯的ACK包,因为只有ACK位被置位.所以三次握手的过程为: 客户端----

TCP 接收窗口自动调节

https://technet.microsoft.com/zh-cn/magazine/2007.01.cableguy.aspx 欢迎来到 TechNet 杂志“网络专家”的第一部分.TechNet 网站上的专栏爱好者都知道我们探讨各种网络问题,我们每个月都将继续保持这个传统.如果您是新手,要查找以前专栏的存档,请访问网络专家站点. 现在开始介绍我们的第一个主题 - TCP 接收窗口. TCP 连接的吞吐量可以通过发送和接收应用程序.发送和接收 TCP 的实现以及 TCP 对等方之间的传输路

TCP超时与重传机制

TCP超时与重传机制    TCP协议是一种面向连接的可靠的传输层协议,它保证了数据的可靠传输,对于一些出错,超时丢包等问题TCP设计的超时与重传机制.其基本原理:在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送数据的ACK确认报文,则对该报文进行重传,在达到一定次数还没有成功时放弃并发送一个复位信号.  这里比较重要的是重传超时时间,怎样设置这个定时器的时间(RTO),从而保证对网络资源最小的浪费.因为若RTO太小,可能有些报文只是遇到拥堵或网络不好延迟较大而已,这样就会造成

Android应用Activity、Dialog、PopWindow窗口显示机制及源码分析

[工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处,尊重劳动成果] 1 背景 之所以写这一篇博客的原因是因为之前有写过一篇<Android应用setContentView与LayoutInflater加载解析机制源码分析>,然后有人在文章下面评论和微博私信中问我关于Android应用Dialog.PopWindow.Toast加载显示机制是咋回事,所以我就写一篇文章来分析分析吧(本文以Android5.1.1 (API 22)源码为基础分析),以便大家在应

Android应用Activity、Dialog、PopWindow、Toast窗口添加机制及源码分析

1  背景 之所以写这一篇博客的原因是因为之前有写过一篇<Android应用setContentView与LayoutInflater加载解析机制源码分析>, 然后有人在文章下面评论和微博私信中问我关于Android应用Activity.Dialog.PopWindow加载显示机制是咋回事,所以我就写一 篇文章来分析分析吧(本文以Android5.1.1 (API 22)源码为基础分析),以便大家在应用层开发时不再迷糊. PS一句:不仅有人微博私信我这个问题,还有人问博客插图这些是用啥画的,这

uCGUI 按键窗口切换机制(更新篇)

在之前文章中,讲述了一个低内存使用量的的窗口切换机制.有人会问,低内存使用量是多低呢,我这里举个例子.我有一个项目中使用到本切换机制,128*64的单色屏,初步计算有105个窗口(后面还会增加),总内存使用量(包括任务栈)=105*3*4(窗口树) + 1024(公共buff) + 512(任务栈) + 1024*3(uCGUI动态内存) = 6k左右.从这个数字可以看出内存算是使用比较少的了.毕竟有100多个窗口,我在设计时也就只做了10多个窗口,这100多个窗口就是由10多个窗口大量复用组合

Unique Snowflakes(窗口滑动)

题目: Emily the entrepreneur has a cool business idea: packaging and selling snowflakes. She has devised a machine that captures snowflakes as they fall, and serializes them into a stream of snowflakes that flow, one by one, into a package. Once the pa