精华内容
下载资源
问答
  • TCP滑动窗口机制

    2018-12-11 09:31:10
    TCP通过滑动窗口机制检测丢包,并在丢包发生时调整数据传输速率。滑动窗口机制利用数据接收端的接收窗口来控制数据流。 接收窗口值由数据接收端指定,以字节数形式存储于TCP报文头,并告知传输设备有多少数据将会...

    TCP通过滑动窗口机制检测丢包,并在丢包发生时调整数据传输速率。滑动窗口机制利用数据接收端的接收窗口来控制数据流。

    接收窗口值由数据接收端指定,以字节数形式存储于TCP报文头,并告知传输设备有多少数据将会存储在TCP缓冲区。缓冲区就是数据暂时放置的地方,直至传递至应用层协议等待处理。因此,发送端每次只能发送Window Size字段指定的数据量。为了使发送端继续传送数据,接收端必须发送确认信息:之前的数据接收到了。同时必须对占用缓冲区的数据进行处理以释放缓存空间。下图显示了接收窗口是如何工作的:

    上图中,客户端向服务器发送数据,服务器接收窗口是5000字节。客户端发送了2500字节,服务器缓冲区还剩2500字节,之后又发送了2000字节,从而缓冲区只剩500字节。服务器发送确认信息。对缓存中数据进行处理并清空缓存。此过程重复进行,客户端又发送3000字节和1000字节,服务器缓存减少至1000字节,客户端再次确认数据并处理缓存中内容。

    更多信息
    调整窗口大小:

    当TCP堆 栈接收到数据的时候,生成一个确认信息并以回复的方式发送,但是放置在接收端缓存中的数据并不总是立即被处理。当服务器忙于处理从多个客户端接收的报文, 服务器很有可能因为清理缓存而变得缓慢,无法腾出空间接收新的数据,如果没有流控,则可能会造成丢包和数据损坏。好在,接收窗口所设定的速率无法使服务器 正常处理数据时,能够调整接收窗口大小。通过减小返回给发送端的ACK报文的TCP头窗口大小值来实现。如下图所示:

    上图中,服务器初始窗口大小为5000字节。客户端发送2000字节,之后又发送了2000字节,缓冲区中只有1000字节可用。服务器意识到缓冲区正在快速填满,它知道如果数据继续以此速率传输,很快会有报文丢失。为了防止报文丢失,服务器发送确认信息给客户端,更新窗口大小为1000字节。结果,客户端减少数据发送,服务器以可以接受的速率处理缓存内容,即保持数据流以稳定的速率传输。

    调整窗口大小在两个方向都是可行的。当服务器能够更加快速的处理报文时,它会发送一个较大窗口的ACK报文。

    零窗口暂停数据流:

    某些情况下,服务器无法再处理从客户端发送的数据。可能是由于内存不足,处理能力不够,或其他原因。这可能会造成数据被丢弃以及传输暂停,但接收窗口能够帮助减小负面影响。

    当上述情况发生时,服务器会发送窗口为0的报文。当客户端接收到此报文时,它会暂停所有数据传输,但会保持与服务器的连接以传输探测(keep-alive)报文。探测报文在客户端以稳定间隙发送,以查看服务器接收窗口状态。一旦服务器能够再次处理数据,将会返回非零值窗口大小,传输会恢复。下图示例了零窗口通知过程。

    服务器初始接收数据窗口为5000字节大小。从客户端接收4000字节数据之后,服务器负载变得非常繁重,无法继续处理客户端任何数据。服务器于是发送窗口大小值为0的报文。客户端暂停数据传输并发送一个探测报文。探测报文之后,服务器回复以告知客户端现在可以接收数据的报文,以及窗口大小为1000字节。客户端恢复传送数据。

    TCP滑动窗口实战:

    本例中,开始从192.168.0.20发送至192.168.0.30。我们关心的是窗口大小字段,可以从Packet List面板的Info栏以及Packet Details的TCP报文头看到。前三个报文后,可看到该值立刻减小,如下图所示:

    窗口大小值从第一个报文的8760字节变成第二个报文的5840字节到第三个报文的2920字节①。窗口大小值的减小是主机延时的典型标志。在时间栏注意到这一过程发生的非常迅速②。当窗口大小迅速减小的时候,通常就有可能下降为零。这就是第四个报文所发生的,如下图所示:

    第四个报文从192.168.0.20发送至192.168.0.30,目的是告诉192.168.0.30它不再接收任何数据。0值见于TCP报文头①,Wireshark的Packet List面板Info栏,以及TCP报文头的SEQ/ACK Analysis字段②也告诉我们这是一个0窗口报文。

    一旦发送了零窗口报文,192.168.0.30的设备不会再发送任何数据,直到收到从192.168.0.20的窗口更新,告知窗口大小已经增加了。本例中导致零窗口的问题是暂时的,所以在下一个报文中发送了窗口更新信息,如下图所示。

    本例中,窗口大小增加到一个非常健康的数值64,240字节①。Wireshark再次在SEQ/ACK Analysis告诉我们这是一个窗口更新。

    一旦收到更新报文,192.168.0.30的主机就再次开始发送数据,在报文6和报文7中。这一过程发生很快。如果它持续时间再长一点,就可能会导致网络的潜在中断,引起数据传输减慢或失败。

    下一个关于滑动窗口的例子,第一个报文是正常HTTP,从195.81.202.68至172.31.136.85。此报文之后立刻跟随一个从172.31.136.85发送的零窗口报文,如下图所示:

    这与上一个例子中的零窗口报文十分类似,但结果显著不同,172.31.136.85主机不是发送一个窗口更新并回复通讯,而是一个探测报文,如下图所示:

    此报文被Wireshark标注为探测报文①。时间栏告诉我们这一报文发生于最后一个接收到的报文3.4秒之后。这一过程持续若干次,一端发送零窗口报文另一端发送探测报文,如下图所示:

    探测报文发送间隙为3.4,6.8,13.5秒。这一过程可能会持续相当长一段时间,取决于通讯设备的操作系统。该情况下,把时间栏的值加起来,通讯暂停了25秒。

    TCP差错控制和流控排查总结:

    重传报文

    重 传的发生是由于客户端检测到服务器没有接收到它所发送的数据。因此,取决于你所分析的是通讯的哪一端,有可能是看不见重传的。如果从服务器端抓取数据,并 且它确实没有接收到客户端所发送的和重传报文,可能会一无所获因为无法看见重传报文。如果怀疑并不是服务器端导致的报文丢失,可以考虑在客户端尝试抓取报 文,以查看实际是否有重传发生。

    重复ACK

    可以将重复ACK看作重传的“所谓相反面”,因为它是在服务器检测到客户端发送报文丢失的时候产生的。大多数情况下,在通讯两端抓取流量时都可以看到重复ACK。需记住当接收报文乱序时会触发重复ACK。例如,如果服务器之接收到发送的第一个和第三个报文,就会导致发送重复ACK引起客户端对第二个报文的快速重传,因为你已经收到了第一个和第三个报文,因此不管导致第二个报文丢弃的原因是什么,都很有可能是暂时的,因此大多数情况下重复ACK都会成功发送和接收。当然,这种情形并不一定永远会发生,因此当你怀疑在服务器端丢失报文而又看不到任何重复ACK,考虑从通讯的客户端抓取报文。

    零窗口和探测报文

    滑动窗口直接与服务器无法接收和处理报文有关,任何窗口大小的缩小以及零值都是服务器问题的直接结果。所以如果你在哪里看到这两者之一发生,就应该在那里深入研究。通常应当在网络通讯两端一直主机窗口更新报文。

    展开全文
  • TCP 滑动窗口机制

    千次阅读 2016-08-03 10:00:41
    了解滑动窗口机制的原理和基本方法。 (1).窗口机制  滑动窗口协议的基本原理就是在任意时刻,发送方都维持了一个连续的允许发送的帧的序号,称为发送窗口;同时,接收方也维持了一个连续的允许接收的帧的...

    本文要解决的问题:

    了解滑动窗口机制的原理和基本方法。


    (1).窗口机制
        滑动窗口协议的基本原理就是在任意时刻,发送方都维持了一个连续的允许发送的帧的序号,称为发送窗口;同时,接收方也维持了一个连续的允许接收的帧的序号,称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样,甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送,但是还没有被确认的帧,或者是那些可以被发送的帧。下面举一个例子(假设发送窗口尺寸为2,接收窗口尺寸为1):


       分析:①初始态,发送方没有帧发出,发送窗口前后沿相重合。接收方0号窗口打开,等待接收0号帧;②发送方打开0号窗口,表示已发出0帧但尚确认返回信息。此时接收窗口状态不变;③发送方打开0、1号窗口,表示0、1号帧均在等待确认之列。至此,发送方打开的窗口数已达规定限度,在未收到新的确认返回帧之前,发送方将暂停发送新的数据帧。接收窗口此时状态仍未变;④接收方已收到0号帧,0号窗口关闭,1号窗口打开,表示准备接收1号帧。此时发送窗口状态不变;⑤发送方收到接收方发来的0号帧确认返回信息,关闭0号窗口,表示从重发表中删除0号帧。此时接收窗口状态仍不变;⑥发送方继续发送2号帧,2号窗口打开,表示2号帧也纳入待确认之列。至此,发送方打开的窗口又已达规定限度,在未收到新的确认返回帧之前,发送方将暂停发送新的数据帧,此时接收窗口状态仍不变;⑦接收方已收到1号帧,1号窗口关闭,2号窗口打开,表示准备接收2号帧。此时发送窗口状态不变;⑧发送方收到接收方发来的1号帧收毕的确认信息,关闭1号窗口,表示从重发表中删除1号帧。此时接收窗口状态仍不变。

        若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议,它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议:发送窗口=1,接收窗口=1;后退n协议:发窗口>1,接收窗口>1;选择重传协议:发送窗口>1,接收窗口>1。

    (2).1比特滑动窗口协议

        当发送窗口和接收窗口的大小固定为1时,滑动窗口协议退化为停等协议(stop-and-wait)。该协议规定发送方每发送一帧后就要停下来,等待接收方已正确接收的确认(acknowledgement)返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧,因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧,因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。

             

    (3).后退n协议(GBN)

        由于停等协议要为每一个帧进行确认后才继续发送下一帧,大大降低了信道利用率,因此又提出了后退n协议。后退n协议中,发送方在发完一个数据帧后,不停下来等待应答帧,而是连续发送若干个数据帧,即使在连续发送过程中收到了接收方发来的应答帧,也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧,就要重发相应的数据帧。如:当发送方发送了N个帧后,若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息,则该帧被判为出错或丢失,此时发送方就不得不重新发送出错帧及其后的N帧。

       从这里不难看出,后退n协议一方面因连续发送数据帧而提高了效率,但另一方面,在重传时又必须把原来已正确传送过的数据帧进行重传(仅因这些数据帧之前有一个数据帧出了错),这种做法又使传送效率降低。由此可见,若传输信道的传输质量很差因而误码率较大时,连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k,接收窗口仍是1。

    (4).选择重传协议

        在后退n协议中,接收方若发现错误帧就不再接收后续的帧,即使是正确到达的帧,这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后,其后继续送来的正确的帧虽然不能立即递交给接收方的高层,但接收方仍可收下来,存放在一个缓冲区中,同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后,就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT),其工作过程如图所示。显然,选择重发减少了浪费,但要求接收方有足够大的缓冲区空间。

    展开全文
  • 浅谈TCP滑动窗口机制概念滑动窗口是两台主机间传送数据时的缓冲区。每台TCP /IP 主机支持两个滑动窗口,一个用于接收数据, 另一个用于发送数据。窗口尺寸表示计算机可能缓冲的数据量大小。工作原理1. 滑动窗口工作...

    浅谈TCP滑动窗口机制

    概念

    滑动窗口是两台主机间传送数据时的缓冲区。每台TCP /IP 主机支持两个滑动窗口,

    一个用于接收数据, 另一个用于发送数据。窗口尺寸表示计算机可能缓冲的数据量大小。

    工作原理

    1. 滑动窗口工作过程

    TCP 协议通过采用滑动窗口的方式控制数据流的传输。在传输层中, 数据按照一定的

    格式打成大小相同的包。每一个滑动窗口中包含一定数目的数据包, 滑动窗口的大小可以

    进行调整。每台网络上的主机维护一个发送窗口和一个接收窗口。发送方一次可发送相当于滑动窗口大小的数据包数目, 并在每个数据包前添加包头信息, 然后等待接收方返回确认信息。由于TCP 是面向连接的协议, 可以保证数据传输的完整性和准确性, 当传输过程中发生丢包时, 接收方会要求发送方从断点处重传数据。

    当TCP 从应用层中接收到数据时, TCP 将一个带序列号的报头加入数据包并将其交给

    IP, 由IP 将它发送到目标主机。

    当每一个数据包传送时, 源主机设置重发计时器, 描述在重新发送数据包前将等待

    ACK 的时间。在一般情况下, 当第一次发送失败后, 重发计时器的重试时间将设置为前一

    次的两倍。在发送窗口中有每一个数据包的备份, 直到收到ACK。

    当数据包到达目的主机接收窗口, 它们按照序列号放置。当目的主机接收到连续的数

    据段时, 就向源主机发送一个关于数据的认可( ACK) 的应答报文, 其中带有当前窗口尺寸。一旦源主机接收到数据包并认可, 发送窗口将进行滑动。如果在重发计时器设定的时

    间内, 源主机没有接收到对现存数据的认可, 数据将重新传送。重发数据包将加重网络和源主机的负担。下面通过应用实例来了解其作用吧。

    滑动窗口应用实例

    “ 三次握手”的例子描述了一个典型的TCP 传输过程。TCP 可使用称为滑动窗口的方法获得更好的TCP 传输性能。在TCP“ 三次握手”的过程中, 两台主机交换传输窗口大小, 接收主机把它的接收窗口大小设置成和发送主机的传输窗口大小一致。窗口大小表明任何一次所能传输段的最大个数。窗口大小是通过TCP 协议的格式中“ 窗口”字段, 在传输给目标主机的每一个报文中给出的。

    发送主机通过创建一个发送窗口, 以设置它的最大传输规模。例如, 如果发送主机设置

    发送窗口的大小是6, 如下图1所示,

    这意味着发送主机一次最多可连续发送6 个数据段, 此时必须得到目标主机确认后, 才能继续发送后续的数据段。

    图1发送窗口为6 的数据段的传送

    ( 1) 第一次连续发送6 个数据段后( 即1 至6 段) , 发送主机必须等待接收主机的确认。

    假如接收主机只收到段1, 2 和5, 则接收主机发回包含有序列号为3 的段进行确认, 确认的是1 和2 段。此时, 发送主机的滑动窗口向右滑过两个确认的段, 7 和8 段出现在滑动窗口中。如图2 所示。

    图2 发送窗口向右滑过两个确认的段

    ( 2 ) 发送主机又连续发送6 个数据段( 即3 至8 段) 。假定这6 段均被正确收到, 接收

    主机发回包含有序列号为9 的段进行确认, 即表示9 段前的数据段均已正确收到, 期待第9段的发送。此时, 发送主机的滑动窗口向右滑过6 个确认的段, 9 至14 段出现在滑动窗口中, 如图3 所示。

    图3 发送窗口向右滑过6 个确认的段

    通过上例可以看出, 借助于滑动窗口能够提高TCP 数据的传输性能。因为TCP 无须对

    每一数据段进行确认, 只需要对发送一个窗口宽度的段确认一次。

    小结

    滑动窗口的大小对网络性能有很大的影响。如果滑动窗口过小, 则需要在网络上频繁

    的传输确认信息, 占用了大量的网络带宽; 如果滑动窗口过大, 对于利用率较高、容易产生丢包现象的网络, 则需要多次发送重复的数据, 这同样耗费了网络带宽。

    决定滑动窗口大小的因素, 包括网络的带宽、可靠性以及需要传输的数据量。

    展开全文
  • TCP协议通过“滑动窗口(Sliding Window)”机制解决这一问题。看下图的通讯过程:滑动窗口1. 发送端发起连接,声明最大段尺寸是1460,初始序号是0,窗口大小是4K,表示“我的接收缓冲区还有4K字节空闲,你发的数据...

    滑动窗口 (TCP流量控制)

    介绍UDP时我们描述了这样的问题:如果发送端发送的速度较快,接收端接收到数据后处理的速度较慢,而接收缓冲区的大小是固定的,就会丢失数据。TCP协议通过“滑动窗口(Sliding Window)”机制解决这一问题。看下图的通讯过程:

    82a5f3eb5f1d770988afdbd9587605ef.png

    滑动窗口

    1. 发送端发起连接,声明最大段尺寸是1460,初始序号是0,窗口大小是4K,表示“我的接收缓冲区还有4K字节空闲,你发的数据不要超过4K”。接收端应答连接请求,声明最大段尺寸是1024,初始序号是8000,窗口大小是6K。发送端应答,三方握手结束。

    2. 发送端发出段4-9,每个段带1K的数据,发送端根据窗口大小知道接收端的缓冲区满了,因此停止发送数据。

    3. 接收端的应用程序提走2K数据,接收缓冲区又有了2K空闲,接收端发出段10,在应答已收到6K数据的同时声明窗口大小为2K。

    4. 接收端的应用程序又提走2K数据,接收缓冲区有4K空闲,接收端发出段11,重新声明窗口大小为4K。

    5. 发送端发出段12-13,每个段带2K数据,段13同时还包含FIN位。

    6. 接收端应答接收到的2K数据(6145-8192),再加上FIN位占一个序号8193,因此应答序号是8194,连接处于半关闭状态,接收端同时声明窗口大小为2K。

    7. 接收端的应用程序提走2K数据,接收端重新声明窗口大小为4K。

    8. 接收端的应用程序提走剩下的2K数据,接收缓冲区全空,接收端重新声明窗口大小为6K。

    9. 接收端的应用程序在提走全部数据后,决定关闭连接,发出段17包含FIN位,发送端应答,连接完全关闭。

    上图在接收端用小方块表示1K数据,实心的小方块表示已接收到的数据,虚线框表示接收缓冲区,因此套在虚线框中的空心小方块表示窗口大小,从图中可以看出,随着应用程序提走数据,虚线框是向右滑动的,因此称为滑动窗口。

    从这个例子还可以看出,发送端是一K一K地发送数据,而接收端的应用程序可以两K两K地提走数据,当然也有可能一次提走3K或6K数据,或者一次只提走几个字节的数据。也就是说,应用程序所看到的数据是一个整体,或说是一个流(stream),在底层通讯中这些数据可能被拆成很多数据包来发送,但是一个数据包有多少字节对应用程序是不可见的,因此TCP协议是面向流的协议。而UDP是面向消息的协议,每个UDP段都是一条消息,应用程序必须以消息为单位提取数据,不能一次提取任意字节的数据,这一点和TCP是很不同的。

    展开全文
  • tcp滑动窗口机制

    2011-12-23 17:06:00
    窗口机制 滑动窗口协议的基本原理就是在任意时刻,发送方都维持了一个连续的允许发送的帧的序号,称为发送窗口;同时,接收方也维持了一个连续的允许接收的帧的序号,称为接收窗口。发送窗口和接收窗口的序号的上下...
  • TCP协议通过“滑动窗口(Sliding Window)”机制解决这一问题。看下图的通讯过程:滑动窗口1. 发送端发起连接,声明最大段尺寸是1460,初始序号是0,窗口大小是4K,表示“我的接收缓冲区还有4K字节空闲,你发的数据...
  • TCP滑动窗口机制 流量控制

    千次阅读 2018-04-07 16:45:18
    TCP滑动窗口机制TCP滑动窗口机制分为两种:固定大小窗口;滑动窗口(不固定大小)。由于TCP传输是支持全双工的,因此发送方和接收方各维护了两个滑动窗口(接收窗口和发送窗口)。滑动窗口会对数据帧进行编号,只有...
  • 浅谈TCP滑动窗口机制

    2020-02-24 19:57:39
    1. 浅谈TCP滑动窗口机制 概念  滑动窗口是两台主机间传送数据时的缓冲区。每台TCP /IP 主机支持两个滑动窗口,  一个用于接收数据, 另一个用于发送数据。窗口尺寸表示计算机可能缓冲的数据量大小。 2. 工作原理 1. ...
  • 程序员成长之旅——TCP滑动窗口机制什么是滑动窗口它的优势是什么 什么是滑动窗口 我所理解的滑动窗口就是客户端和服务端控制两个窗口,一个是发送窗口,一个是接收窗口,它们会根据窗口的大小,在TCP头部进行一个...
  • 滑动窗口的本质其实就是维护几个变量,通过这些变量将TCP处理的数据分为几类,同时在发送出一个报文、接收一个报文对这些变量做一定的处理维护。发送窗口如上图 :(1)N是发送窗口的起始字节,也就是说:...
  • 为了更有效地进行通信,TCP 协议在数据进行数据传输时,使用滑动窗口机制来同时发送多个数据包。当数据包丢失时,TCP 协议利用数据重发功能重新发送数据包。因接收端接收数据包的能力不同,TCP 流控制会根据接收端的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,171
精华内容 468
关键字:

tcp滑动窗口机制