TCP/IP详解卷1:协议学习笔记第二十二章 TCP的坚持定时器

向右看齐 2022-10-05 09:45 175阅读 0赞

如果接收方的窗口大小变为0，则发送方会停止传送数据，直到接收方再次通告窗口非0。而如果接收方的通告窗口的报文段丢失，则会出现死锁：接收方等待接收数据（它已经发送了一个非0的窗口通告），而发送方在等待允许它继续发送数据的窗口更新。为防止这种情况，发送方使用一个坚持定时器来周期性地向接收方查询，以便发现窗口是否已经增大，这些从发送方发出地报文段称为窗口探查。

为观察坚持定时器，我们启动一个接收进程，它监听来自客户的请求，接受该连接请求，然后从网上读取数据前休眠一段时间，使用sock程序的-P选项使服务器在接受连接和进行第一次读动作之间进入休眠：  
![在这里插入图片描述][20210608114128250.png]  
该命令会在从网络上读数据前休眠100000秒，客户运行在bsdi上，并向服务器的5555端口执行多次1024字节的写操作，以下是去掉建立连接过程的tcpdump输出：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70]  
报文段1~13是从客户到服务器的正常的数据传输过程，有9216字节的数据填充了窗口。服务器通告窗口大小为4096字节，但实际它一共接收了9216字节的数据，这是在SVR 4中TCP代码和流子系统之间某种交互的结果。

报文段13中，服务器确认了前面4个数据报文段，然后通告窗口为0，从而使客户通知发送任何数据，并引起客户设置其坚持定时器，如果在该定时器时间到时客户还没接收到一个窗口更新，客户就发送一个窗口探查。

客户发出的窗口探查之间的时间间隔为4.949s、4.996s、6s、12s、24s、48s、60s，这些间隔总是比整数秒小零点几秒，这是因为探查是被TCP的500ms定时器超时例程所触发，定时器时间到时，就发送一个窗口探查，大概4ms后收到一个应答，这使得客户的坚持定时器被重新启动，但到下一个时钟滴答之间的时间约为500-4ms。

窗口探查包含一个字节的数据。

TCP从不放弃发送窗口探查，一直持续到窗口被打开或连接被终止。

基于窗口的流量控制方案会导致被称为糊涂窗口综合症SWS（Silly Window Syndrome）的情况，此时，少量的数据通过连接进行交换，而非满长度的报文段。

SWS可发生在两端中的任何一端：接收方通告一个小的窗口（而非一直等到有大的窗口时才通告）；发送方发送少量的数据（而非等待其他的数据一起发送一个大的报文段）。可以在任何一端采取措施避免出现SWS：  
1.接收方不通告小窗口。通常的做法是接收方不通告一个比当前窗口大的窗口，除非增加了一个报文段大小或增加了接收方缓存空间的一半。  
2.发送方在满足以下条件之一时才发送数据：  
（1）可发送一个满长度的报文段。  
（2）可发送至少是接收方通告窗口大小的一半的报文段。  
（3）没有未被确认的数据或不能使用Nagle算法时可发送任何数据。

Nagle算法阻止我们发送小的报文段，小的含义是字节数小于报文段的大小。

观察避免出现SWS的例子。在发送主机上运行sock程序，并向接收端发6个1024字节数据：  
![在这里插入图片描述][20210608152632937.png]  
但在bsdi接受过程中加入暂停，第一次读数据前暂停4秒，之后每次读之前暂停2秒，接收方每次进行256字节的读：  
![在这里插入图片描述][20210608152724817.png]  
最初的暂停是为了让接收方缓存填满，迫使发送方停止发送，之后由于接收方从网络上进行了小数目的读取，因此能看到接收方执行的SWS避免措施，以下是去掉连接建立过程的数据传输过程的时间序列：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 1]  
以下是跟踪每个时间点上接收缓存大小等更多信息：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 2]  
上图中第一列是tcpdump输出的时间，小数点为99的是在接收服务器上产生行为的估计时间。上图中报文段19通告有767大小的接收缓存，而实际上接收方有768字节的接收缓存，这是由于FIN也占用一个字节编号，而接收方计算时将FIN也当做放在缓存的数据减去了。

当发送方的坚持定时器时间到时（坚持定时器时间设为5s），就发出1个字节的数据（报文段6），接收的应用进程此时已经从接收缓存中读取了256字节数据（在时刻3.99），因此这个字节被接受并被确认（报文段7），但通告窗口仍然为0，由于接收方仍然没有足够空间接收一个满长度的报文或腾出缓存空间的一半，这是接收方的糊涂窗口避免措施。

报文段8是发送方的坚持定时器又到时时发送的一个字节，并在报文段9中被确认，而接收方的缓存空间还不够用（1022字节），使得通告窗口为0。

发送方的坚持定时器再次到时时，发送了另一个字节并被确认（报文段10、11），这次接收方有了1533字节的有效缓存空间，因此通告了1533大小的窗口，而发送方只发送了1024字节（报文段12），接收方接收到后，对这1024字节的数据进行确认（报文段13），通告其窗口为509字节，这看起来与通告小窗口相抵触，但这是为了保证不违反窗口右边沿不能向左移动而导致窗口收缩的TCP原则。

之后发送方并没有立即向这个小窗口发送数据，这是发送方的糊涂窗口避免措施，它等待另一个坚持定时器到时，此时再发送509字节的数据，这509字节的数据使接收缓存仅剩768字节的有效空间，因此接收方通告窗口为0（报文段15）。

坚持定时器再25.151再次到时，发送方发送1个字节，于是接收缓存中有1279字节的可用空间，这是报文段17通告的窗口大小。发送方此时只有511字节的数据需要发送，因此在收到报文段17后立刻发送了剩余数据，这个报文段也带有FIN，接收方确认数据和FIN，并通告窗口大小为767。

发送方发送完数据后发出关闭命令，发送方的连接从ESTABLISHED状态转变到FIN\_WAIT\_1状态（发送完FIN后），收到此FIN的ACK后，状态转变为FIN\_WAIT\_2，它一直处于这个状态，直到收到对方的FIN，FIN\_WAIT\_2状态没有设置定时器，因为此时连接处于半关闭状态，发送方已经不再能发送数据。

接收方在39.99发送了一个ACK（报文段20），这是因为应用在39.99读取数据时，接收缓存中的可用空间从原来通告的767变为2816，增加了2049字节的空间，相当于增加了接收缓存空间的一半，因此接收方发送了一个窗口更新。

应用在51.99发出最后一个读操作，然后收到一个文件结束标志，此时缓存变空，这导致了最后两个完成连接终止的报文段的发送（报文段21、22）。

[20210608114128250.png]: /images/20221005/8a9615a0c05e47f4b617385952af159e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70]: /images/20221005/9d412c049f264aeca85d15ffd994f6e7.png
[20210608152632937.png]: /images/20221005/a08a176acfdb47618917916537e1604a.png
[20210608152724817.png]: /images/20221005/5be8d2479f5b4d3a98fff509960645e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 1]: /images/20221005/4217bc866fef4c0391f04a54099924a0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 2]: /images/20221005/6bfeb8342d024492b5e50833bc142b5e.png