TCP/IP详解卷1:协议学习笔记第二十四章 TCP的未来和性能

港控/mmm° 2022-10-06 05:54 149阅读 0赞

虽然TCP在比以太网速率高的环境中也能正确运行，但在这些高速率环境下，TCP的某些限制被暴露出来。

路径MTU发现机制通常可以使TCP为非本地的连接使用大于536字节的MTU，从而增加吞吐量。

TCP处理长肥管道（带宽时延积很大的网络）时有局限性，为处理长肥管道，增加两个TCP选项：窗口扩大选项（增大TCP的最大窗口，使之超过65535字节）、时间戳选项（使TCP对报文段的RTT进行更加精确的测量，还能在高速率下对可能发生的序号回绕提供保护）。

T/TCP是为了增加事务功能对TCP进行的修改，通信的事务模式以客户的请求将被服务器应答为主要特征，T/TCP目的是减少两端交换的报文段数量，避免三次握手和使用4个报文段进行连接的关闭，从而使客户可以在一个RTT和处理请求所必须的时间内收到服务器的应答。

以上新功能与现有的TCP实现兼容，使用这些功能的系统仍可与原系统交互。除了需要为MTU发现机制在ICMP报文中增加一个额外字段外，其余功能只需在那些需要使用它们的端系统中实现即可。

路径MTU（两个主机间的路径上任何网络的最小MTU）。路径MTU发现通过在IP首部中设置不要分片DF比特，来观察当前路径上的路由器是否需要对正在发送的IP数据报进行分片，如果需要分片，则路由器返回一个ICMP不可达的差错，某版本的traceroute程序使用这一机制发现到目的地的路径MTU。

TCP的路径MTU发现过程：  
1.建立连接时，TCP使用输出接口或对端声明的MSS中的最小MTU作为起始的报文段大小，如果对端没有指定MSS，则默认值为536字节。路径MTU发现不允许TCP超过对端声明的MSS。  
2.在该连接上的所有被TCP发送的IP数据报都被设置DF比特，如果某个中间路由器需要对一个设置了DF标志的数据报分片，就丢弃这个数据报，并产生一个ICMP不能分片差错。  
3.发送端收到这个差错后，如果是较新的该类ICMP差错（其中含产生该差错的路由器的下一跳的MTU），则报文段大小被设置为下一跳的MTU减去IP和TCP的首部长度；如果是一个较旧的该类ICMP差错，则尝试下一个可能的最小MTU。由这个ICMP差错引起的重传发生时，拥塞窗口不需要变化，但要慢启动。

由于路由可以动态变化，在最后一次减少路径MTU一段时间以后，可以尝试使用一个较大的值（直到等于对面声明的MSS或输出接口MTU的最小值），RFC 1191推荐时间为10分钟。

非本地目的地的默认MSS通常为536字节，路径MTU发现可以避免在通过MTU小于576字节（这非常罕见）的中间链路时进行分片。为了使路径MTU更加有用和充分地利用MTU大于576字节的广域网，实现必须停止使用为非本地目的指定的536字节的MTU默认值。为非本地目的指定的默认MTU的较好选择是输出接口的MTU减去IP和TCP首部的大小，大多数实现运行系统管理员修改这个默认MSS值。

发现路径MTU的例子：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70]  
从主机slip到solaris建立一个连接，slip把接口的MTU设为552字节，而不像通常一样将其设为链路的MTU（上例中为296字节），这使得slip通告一个512字节的MSS，但SLIP链路的MTU实际为296，这引起超过256字节的TCP报文段被分片，我们在solaris上运行sock程序，并向slip上的丢弃服务器进行一个512字节的写操作：  
![在这里插入图片描述][20210615165652962.png]  
以下是在sun的SLIP接口上收集的tcpdump的输出：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 1]  
前两行建立连接时的MSS值是我们所期望的，第三行solaris发送了一个带有512字节数据的对SYN进行确认的报文段。第四行显示路由器bsdi产生了一个ICMP差错，这个是较新的包含输出接口MTU的ICMP差错。在第四行的差错到达solaris之前，solaris就发送了FIN，由于slip没有接收到被丢弃的前512字节的数据，因此不期望接收此报文段中的序号513，因此在第六行中用它所期望的序号1进行了响应，此时，ICMP差错返回到了solaris，solaris用两个256字节的报文段（第7、9行）重传了这512字节的数据，因为在bsdi后面可能还有具有更小MTU的路由器，因此这两个报文段都设置了DF比特。

在分组大小不足以引起分片时，越大的分组花费越少，但有人不同意这种观点，如下例，通过4个路由器发送8192字节，每个路由器与一个T1电话线（544000b/s）相连，首先我们使用两个4096字节的分组：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 2]  
问题在于路由器是存储转发设备，它们通常接收整个分组，检验包含IP检验和的IP首部，进行选路判决，然后发送输出分组，上图中假定在路由器中的操作不花费时间，计算从一个路由器到另一个路由器发送一个分组所需时间：  
![在这里插入图片描述][20210615172746361.png]  
从上图可知，整个发送时间是4个单位时间，即85.6ms，每个链路空闲2个单位时间（42.8ms）。

当我们发送16个512字节的分组时：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 3]  
此时每个单位时间为：  
![在这里插入图片描述][20210615173219151.png]  
此时总时间为18\*2.9=52.2ms，每个链路也空闲2个单位时间（5.8ms）。

时延带宽积也可称其为两端的管道大小，此值越大，TCP的某些局限性就会暴露出来。  
![在这里插入图片描述][20210616174145629.png]  
具有大的时延带宽积的网络被称为长肥网络（LFN，Long Fat Network），运行在LFN上的TCP连接被称为长肥管道，使用长肥管道会遇到很多问题：  
1.TCP首部中窗口大小是16bit，从而将窗口大小限制在65535字节内。  
2.在一个长肥网络内丢失的分组会使吞吐量急剧减少，如果有报文段丢失，需要使用快速重传和快速恢复算法避免管道耗尽，即使使用了这些算法，在一个窗口内发生的多个分组丢失也会使管道耗尽（慢启动将它渐渐填满，此过程需经过多个RTT）。  
3.许多TCP实现对每个窗口的RTT仅进行一次测量，在LFN上需要更好的RTT测量机制。  
4.TCP对每一个字节用一个32bit无符号的序号进行标识，如果网络中有一个被延迟一段时间的报文段，它所在的连接已经释放，而一个新的连接在这两个主机之间又建立了，防止这个报文段再次出现的措施：  
（1）IP首部中的TTL为每个IP段规定了一个生存时间的上限（255跳或255秒，看哪个上限先达到），推荐的最大报文段生存时间MSL值为2分钟，但许多实现使用了MSL为30秒。  
（2）在LFN上，由于TCP序号空间是有限的，在传输了4294967296个字节后序号会被重用，如果网络快到在不到一个MSL的时候序号就发生了回绕，此时可使用TCP的时间戳选项的PAWS（Protection Against Wrapped Sequence numbers）算法保护回绕的序号。

时延和带宽之间的差别如下：发送一个100万字节的文件时，假定时延是30ms，下图中，上部分使用了一个1544000b/s的T1电话线，下部分使用了一个1Gb/s网络：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 4]  
上图显示，在30ms后，两个网络中的第1个比特的数据都已到达对端，但对于T1网络，由于管道容量仅为5790字节，因此发送方仍然有994210个字节等待发送，而千兆比网络的容量为3750000字节，因此整个文件仅使用了25%左右的带宽，此时文件的最后一个比特已经到达第1个字节后的8ms处。

经过T1网络传输文件的总时间为5.211秒，如果增加更多的带宽，如使用一个T3网络（45000000b/s），则总时间减少到0.208秒，增加约29倍带宽将总时间减小到约25分之一。

使用千兆比网络传输文件的总时间为0.038秒（30ms的时延+8ms的真正传输文件的时间），假定将带宽增加为2000Mb/s，我们只能将总时间减小为0.304ms，此时带宽加倍仅能将时间减少约10%，在千兆比速率下，时延限制占据了主要地位，带宽不再成为限制。

时延主要是由光速引起的，不能被减小。

窗口扩大选项能使TCP的窗口定义从16bit增加到32bit，这是通过定义一个选项实现对16bit的扩大操作来完成的，TCP首部仍然使用16bit。

窗口扩大选项的移位计数器可取值0（没有扩大窗口）到14，最大值14表示窗口大小为65535\*214字节。

窗口扩大选项只能出现在一个SYN报文段中，当连接建立后，在每个方向上的扩大因子是固定的，主动建立连接的一方在其SYN中发送这个选项，被动建立连接的一方只有在收到带有这个选项的SYN后才能发送这个选项，两个方向上的扩大因子可以不同。

如果主动连接的一方发送一个非0的扩大因子，但没有从另一端收到一个窗口扩大选项，就将发送和接收的移位计数器置位0，这允许较新的系统能与较旧的、不理解新选项的系统进行互操作。

Host Requirements RFC要求TCP接受在任何报文段中的一个选项，忽略不理解的选项。

假定我们在使用窗口扩大选项，发送的移位计数为S，接受的移位计数为R，我们收到对端的16bit通告窗口时将左移R位以获得实际的通告窗口大小；我们向对端发送一个窗口通告时，我们将实际的32bit窗口大小右移S位，用它来替换TCP首部中的16bit值。

TCP根据接收缓存的大小自动选择移位计数，这个大小是由TCP设置的，但通常向应用进程提供了修改途径。

以下是在vangogh主机上与bsdi主机上的echo服务建立两次连接来观察TCP计算窗口扩大因子的情况，第1个连接指定接收缓存为128000字节，第2个缓存为220000字节：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 5]  
以下为这两个连接的tcpdump输出：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 6]

第一行中，vangogh通告一个65535的窗口，并通过设置移位计数为1来指明窗口扩大选项，这表示vangogh发送的窗口通告为131070（65535\*2）字节，这将调整我们的接收缓存（128000）。由于bsdi在它的SYN中没有发送窗口扩大选项，因此这个选项没有被使用，vangogh在随后的连接阶段继续使用65535作为最大的可能窗口。

第二个连接vangogh的请求移位计数为2，表明它发送的窗口通告大小为262140（65535\*22）字节，这比我们的接收缓存大。

时间戳选项使发送方在每个报文段中放置一个时间戳值，接收方在确认中返回这个数值，从而允许发送方为每一个收到的ACK（此处是ACK而非报文段，因为TCP通常用一个ACK确认多个报文段）计算RTT。

许多实现为每一个窗口只计算一个RTT，对于包含8个报文段的窗口而言是正确的，较大的窗口大小需要进行更好的RTT计算。通常RTT通过对一个数据信号（包含数据的报文段）以较低的频率（每个窗口一次）进行采样来计算被估计的RTT，如果一个窗口能容纳8个报文段，则计算被估计的RTT时，采样速率为数据速率的1/8，这可以忍受，但如果每个窗口中有100个报文段，采样速率变为数据速率的1/100，这将导致被估计的RTT不精确，从而引起不必要的重传。如果一个报文段被丢失，会使情况变得更糟。

包含时间戳选项的TCP首部长度将从正常的20字节增加到32字节。

时间戳选项不需要两个主机间进行时钟同步。

时间戳是一个单调递增的值，RFC 1323推荐在1ms到1秒之间将时间戳的值加1，4.4 BSD在启动时将时间戳始终设置为0，然后每隔500ms将时间戳加1。

时间戳选项只有主动发起连接的一方在它的SYN中指定且从另一方的SYN中收到此选项后，该选项才会在以后的报文段中设置。

对于一个连接，时间戳选项只会维持一个时间戳值，如果接收方发送一个ACK对多个报文段进行确认，这个ACK中存放的就是这个唯一时间戳值，此时间戳的值更新算法如下：  
1.TCP跟踪下一个ACK中将要发送的时间戳的值（一个名为tsrecent的变量）以及最后发送的ACK中的确认序号（一个名为lastack的变量），这个序号就是接收方期望的序号。  
2.当一个包含字节号lastack的报文段到达时，此报文段中的时间戳被保存在tsrecent中。  
3.无论何时发送一个时间戳选项，tsrecent就作为时间戳回显应答字段被发送，而序号字段会更新到lastack中。

此算法能处理以下情况：  
1.如果ACK被接收方迟延，则作为回显值的时间戳值应对应于最早被确认得报文段。这意味着发送方在进行重传超时时间的计算时，必须将迟延的ACK也考虑在内。  
2.如果收到的报文段在窗口范围内，但它是失序的，这表明前面的报文段已经丢失，当失序的前面报文段到达时，失序的前面报文段的时间戳（而非失序的报文段的时间戳）将被回显。这是正确的，如果ACK含有后面的失序报文段的时间戳，则重复的ACK和前面的失序报文段的重传时间或发送方的前面失序报文段的到期时间都会使发送方的RTT计算出现偏差。

使用窗口扩大选项的TCP连接的最大可能窗口大小为230（其实是65535\*214，但差距很小，不影响讨论），假定此连接还使用了时间戳选项且发送方指定的时间戳对每个将要发送的窗口加1，以下是传输6千兆字节的数据时，两个主机间可能的数据流，G表示1073741824：  
![在这里插入图片描述][20210628001058110.png]  
如上图，32bit的序号在时间D和E之间发生了回绕，假定一个报文段在时间B丢失并被重传且这个丢失的报文段在时间E重新出现，这意味着在报文段丢失和重新出现之间的时间差小于MSL，否则这个报文段在它的TTL到期时会被某个路由器丢弃，此时旧的报文段重新出现并带有当前要传输的需要，此时可用时间戳选项避免这种情况，接收方将时间戳视为序列号的一个32bit的扩展，时间E重新出现的报文段的时间戳为2，这比最近有效的时间戳小（5或6），因此PAWS算法将其丢弃。

PAWS算法不需要发送方和接收方之间进行任何形式的时间同步，接收方只需要时间戳的值单调递增且每个窗口至少加1。

TCP提供的是一种虚电路方式的运输服务，一个连接的生存时间包括三个不同阶段：建立、数据传输、终止，这种虚电路服务适合远程注册和文件传输类的应用。

一个事务是符合下面特征的一个客户请求及其随后的服务器响应：  
1.应避免连接建立和连接终止的开销，发送一个请求分组并接收一个应答分组。  
2.等待时间应减少到等于RTT（Round-Trip Time，往返时间）和SPT（Server Processing Time，服务器处理请求的时间）之和。  
3.服务器应能检测数重复的请求，收到一个重复的请求时不必重新处理事务，而是返回保存的、与该请求对应的应答。

一个使用上述类型服务的应用是域名服务。

程序设计人员面对TCP和UDP需要做出选择，TCP提供了过多的事务特征，而UDP提供的不够。通常应用程序使用UDP来避免TCP连接的开销，而许多重要特征（如动态超时和重传、拥塞避免等）被放置到应用层，又重新设计和实现一遍。

一个较好的解决方法是提供一个能够提供足够多事务处理功能的运输层，如T/TCP协议，这是一个事务协议。

T/TCP通过使用加速打开来避免三次握手：  
1.它为打开的连接指定一个32bit的连接计数CC（Connection Count），无论主动打开还是被动打开。一个主机的CC值从一个全局计数器中获得，该计数器每次使用时加1。  
2.在两个使用T/TCP的主机之间的每一个报文段都包括一个新的TCP选项CC，这个选项长度为6字节，包含发送方在该连接上的32bit的CC值。  
3.一个主机维持一个缓存，该缓存保留每个主机上一次的CC值，这些值从来自这个主机的一个可接受的SYN报文段中获得。  
4.在一个开始的SYN中收到一个CC选项的时候，接收方比较收到的值与为该发送方缓存的CC值，如果收到的CC值比缓存的大，则该SYN是新的，报文段中的任何数据直接传递给应用进程，这个连接被称为半同步；如果接收的CC比缓存小，或接收主机上没有这个客户的缓存CC，则执行正常的TCP三次握手过程。  
5.为响应一个开始的SYN，带有SYN和ACK的报文段在CCECHO选项中回显所接收到的CC值。  
6.在一个非SYN报文段中的CC值检测和拒绝来自同一个连接的前一个替身的任何重复报文段。

以上加速打开的代价是必须记住从每个客户接收的最近CC值。

T/TCP基于在两个主机之间测量RTT来动态计算TIME\_WAIT的延时（2MSL），可以缩短TIME\_WAIT状态，TIME\_WAIT时延被设置为8倍的超时重传值RTO。

通过以上特征，最小的事务序列是交换三个报文段：  
1.主动打开引起的客户到服务器的报文段，包含客户的SYN、客户的请求、客户的FIN、客户的CC。  
2.服务器到客户的报文段，包含服务器的SYN、服务器的应答、服务器的FIN、对客户的ACK（由于TCP的确认是累积的，因此这个确认包含对客户的SYN、客户数据、客户FIN的确认）、服务器的CC、包含客户CC的CCECHO选项。客户收到1中的报文段后，将其传送给客户应用进程。  
3.客户到服务器的报文段，包含对2中报文段的ACK，它确认了服务器的SYN、服务器的数据、服务器的FIN。

客户发送请求到收到响应的时间为RTT和SPT的和。

实现T/TCP时：  
1.服务器的SYN和ACK必须被迟延，从而允许捎带上应答一起发送。通常对SYN的ACK是不迟延的，但也不能迟延太久，否则客户将超时并引起重传。  
2.请求可以是多个报文段，服务器必须处理它们失序到达的情况。通常当数据在SYN之前到达时，该数据会被丢弃并产生一个复位，使用T/TCP时需要将这些数据放入队列中处理。  
3.API必须使服务器进程用一个单一的操作来发送和关闭连接，从而允许第二个报文段中的FIN与应答一起捎带发送。通常应用先写应答，从而引起发送一个应答报文段，然后关闭连接，引起发送FIN。  
4.收到来自服务器的MSS通告之前，客户就会在第一个报文段中发送数据，这需要缓存对方主机的MSS，以避免客户猜测对方一个很小的MSS。  
5.T/TCP建议默认服务器的窗口通告和缓存拥塞门限都为4096字节。  
6.由于使用了三个报文段交换，因此每个方向上只能计算一个RTT，这意味着被平滑的RTT及其方差也必须为对端主机缓存起来。

T/TCP对现有协议进行了最小的修改，同时兼容了现有实现，它还利用了TCP中的动态超时和重传、拥塞避免等特征，避免了应用来处理这些问题。

通用报文事务协议VMTP（Versatile Message Transaction Protocol）也是一个事务协议，它不是对现有TCP协议的扩充，而是使用IP的一个完整的运输层。VMTP处理差错检测、重传、重复压缩，它还支持多播通信。

TCP的限制：  
1.不能比最慢的链路更快。  
2.不能比最慢的机器内存更快（将数据从用户空间复制到内核中）。  
3.不能比接收方提供的窗口大小除以往返时间所得结果更快（将窗口大小作为时延带宽积，除以时延，解出带宽）。

一个系统发送一个窗口扩大因子为0的开始SYN报文段意味着发送TCP支持窗口扩缩选项，另一端可以说明一个窗口扩缩因子（可以是0或非0）。

已经定义了的窗口扩大因子不能在扩大因子变化是出现在报文段中，因为报文段可能丢失。

假定MSL为2分钟，在速率为232\*8/2/60=286Mb/s时会发生序号回绕。（TCP首部中的序号字段指的是字节的序号）

PAWS被定义为只在一个单独的连接中进行，为了使PAWS替换2MSL等待时间，需要TCP记住所有连接上收到的上一个时间戳。

在计算平均RTT时，只要报文段重传了，就不使用其往返时延样本，这是karn算法，但如果使用了时间戳选项，则可以明确确认是对哪个报文段的，就可以使用这个往返时延样本。

如果服务器没有使用T/TCP扩展，即使客户主动开启T/TCP发送带有FIN和请求数据的SYN报文段，客户在接收服务器的请求结果的时延仍然是两倍RTT加SPT，过程如下：  
1.客户到服务器的报文段，其中包含SYN、请求数据、FIN。  
2.服务器到客户的报文段，其中包含SYN和对客户SYN的确认。  
3.客户到服务器的报文段，其中包含对服务器SYN的确认、客户的FIN。这使服务器进入连接建立状态，报文段1中的排队客户请求数据传递给服务器应用。  
4.服务器到客户的报文段，其中包含对客户请求数据和FIN的确认、服务器的应答数据、服务器的FIN。此处假定SPT足够短以和这个延迟的确认一起发送。  
5.客户到服务器的报文段，其中包含对服务器FIN的确认。

T/TCP总是会比UDP花费更多时间，因为UDP涉及了UDP没有做的状态处理。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70]: /images/20221005/f2a5b368eda543d68293d0ca398f425b.png
[20210615165652962.png]: /images/20221005/30a78350bd8f445da71e284e918366c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 1]: /images/20221005/6e6a203c55dc4dc2b9f3a900bf4a0920.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 2]: /images/20221005/531a22f582784c9792e1234778674ddd.png
[20210615172746361.png]: /images/20221005/f793e720b80542c889b5960ac57587f7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 3]: /images/20221005/866e925906804f6cb93cfe32d38b66c4.png
[20210615173219151.png]: /images/20221005/e6b4af5045ef461ab3df45fd942b4fc6.png
[20210616174145629.png]: /images/20221005/74dc6ac0e656426a89e3644ed2f8e99a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 4]: /images/20221005/5652e4b0eb084768b6b1149e8d666bb3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 5]: /images/20221005/e17482b315a7488296c78ee7f2ae3c3f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 6]: /images/20221005/2d68aa7afe0649f28910902d3645b7c2.png
[20210628001058110.png]: /images/20221005/08495f93ebc243e789f787c4f753803d.png