17.1 引言
本章将介绍TCP为应用层提供的服务，以及TCP首部中的各个字段。
随后的几章我们在了解TCP的工作过程中将对这些字段作详细介绍。
对TCP的介绍将由本章开始，并一直包括随后的7章。
第18章描述如何建立和终止一个TCP连接，
第19和第20章将了解正常的数据传输过程，包括交互使用(远程登录)和批量数据传送(文件传输)。
第21章提供TCP超时及重传的技术细节，
第22和第23章将介绍两种其他的定时器。
第24章概述TCP新的特性以及TCP的性能。
17.2TCP的服务
尽管TCP和UDP都使用相同的网络层( IP)，TCP却向应用层提供与UDP完全不同的服务。
TCP提供一种面向连接的、可靠的字节流服务。
面向连接意味着两个使用TCP的应用在彼此交换数据之前必须先建立一个TCP连接。
这一过程与打电话很相似，先拨号振铃，等待对方摘机说“喂”，然后才说明是谁。
在第1 8章我们将看到一个TCP连接是如何建立的，以及当一方通信结束后如何断开连接。
在一个TCP连接中，仅有两方进行彼此通信。在第1 2章介绍的广播和多播不能用于TCP。
TCP通过下列方式来提供可靠性：
.应用数据被分割成TCP认为最适合发送的数据块。
这和UDP完全不同，应用程序产生的数据报长度将保持不变。
由TCP传递给IP的信息单位称为报文段或段( s e g m e nT)(参见图1 - 7)。
在1 8 . 4节我们将看到TCP如何确定报文段的长度。
.当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。
如果不能及时收到一个确认，将重发这个报文段。
在第2 1章我们将了解TCP协议中自适应的超时及重传策略。
.当TCP收到发自TCP连接另一端的数据，它将发送一个确认。
这个确认不是立即发送，通常将推迟几分之一秒，这将在1 9 . 3节讨论。
•TCP将保持它首部和数据的检验和。
这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。
如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段(希望发端超时并重发)。
.既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。
如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
.既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。
•TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。
TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。
这将防止较快主机致使较慢主机的缓冲区溢出。
两个应用程序通过TCP连接交换8 bit字节构成的字节流。
TCP不在字节流中插入记录标识符。我们将这称为字节流服务( byte stream service)。
如果一方的应用程序先传1 0字节，又传2 0字节，再传5 0字节，连接的另一方将无法了解发方每次发送了多少字节。
收方可以分4次接收这8 0个字节，每次接收2 0字节。
一端将字节流放到TCP连接上，同样的字节流将出现在TCP连接的另一端。
另外，TCP对字节流的内容不作任何解释。TCP不知道传输的数据字节流是二进制数据，
还是A S C I I字符、E B C D I C字符或者其他类型数据。
对字节流的解释由TCP连接双方的应用层解释。
这种对字节流的处理方式与U n i x操作系统对文件的处理方式很相似。
U n i x的内核对一个应用读或写的内容不作任何解释，而是交给应用程序处理。对U n i x的内核来说，
它无法区分一个二进制文件与一个文本文件。
17.4 小结
TCP提供了一种可靠的面向连接的字节流运输层服务。
我们简单地介绍了TCP首部中的各个字段，并在随后的几章里详细讨论它们。
TCP将用户数据打包构成报文段；它发送数据后启动一个定时器；
另一端对收到的数据进行确认，对失序的数据重新排序，丢弃重复数据；
TCP提供端到端的流量控制，并计算和验证一个强制性的端到端检验和。
许多流行的应用程序如Te l n eT、R l o g i n、FT P和S MT P都使用TCP。
习题
17.1 我们已经介绍了以下几种分组格式： IP、I C M P、I G M P、UDP和TCP。
每一种格式的首部中均包含一个检验和。
对每种分组，说明检验和包括IP数据报中的哪些部分，以及该检验和是强制的还是可选的。
17.2 为什么我们已经讨论的所有I nT e r n eT协议
(IP, ICMP, IGMP, UDP,TCP)收到有检验和错的分组都仅作丢弃处理？
17.3TCP提供了一种字节流服务，而收发双方都不保持记录的边界。
应用程序如何提供它们自己的记录标识？
17.4 为什么在TCP首部的开始便是源和目的的端口号？
17.5 为什么TCP首部有一个首部长度字段而UDP首部(图11 - 2)中却没有？
第18章TCP连接的建立与终止
18.1 引言
TCP是一个面向连接的协议。无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。
本章将详细讨论一个TCP连接是如何建立的以及通信结束后是如何终止的。
这种两端间连接的建立与无连接协议如UDP不同。
我们在第11章看到一端使用UDP向另一端发送数据报时，无需任何预先的握手。
18.2 连接的建立与终止
为了了解一个TCP连接在建立及终止时发生了什么，我们在系统s v r 4上键入下列命令：
t e l n eT命令在与丢弃( d i s c a r d )服务对应的端口上与主机b s d i建立一条TCP连接。
这服务类型正是我们需要观察的一条连接建立与终止的服务类型，而不需要服务器发起任何数据交换。
18.12 小结
两个进程在使用TCP交换数据之前，它们之间必须建立一条连接。
完成后，要关闭这个连接。
本章已经详细介绍了如何使用三次握手来建立连接以及使用4个报文段来关闭连接。
我们用TCP d u m p程序显示了TCP首部中的各个字段。
也了解了连接建立是如何超时，连接复位是如何发送，
使用半打开连接发生的情况以及TCP是如何提供半关闭、同时打开和同时关闭。
弄清TCP操作的关键在于它的状态变迁图。我们跟踪了连接建立与关闭的步骤以及它们的状态变迁过程。
还讨论了在设计TCP并发服务器时TCP连接建立的具体实现方法。
一个TCP连接由一个4元组唯一确定：本地IP地址、本地端口号、远端IP地址和远端端口号。
无论何时关闭一个连接，一端必须保持这个连接，我们看到T I M E _ WA IT状态将处理这个问题。
处理的原则是执行主动打开的一端在进入这个状态时要保持的时间为TCP实现中规定的M S L值的两倍。
习题
18.1 在我们说初始序号( I S N)正常情况下由1开始，并且每0 . 5秒增加6 4 0 0 0，每次执行一个主动打开。
这意味着I S N的最低三位通常总是0 0 1。但在图1 8 - 3中，两个方向上I S N中的最低三位都是5 2 1。
究竟是怎么回事?
18.2 在图1 8 - 1 5中，我们键入1 2个字符，看到TCP发送了1 3个字节。
在图1 8 - 1 6中我们键入8个字符，但TCP发送了1 0个字符。
为什么在第1种情况下增加1个字节，而在第2种情况下增加2个字节？
18.3 半打开连接和半关闭连接的区别是什么？
18.4 如果启动s o c k程序作为一个服务器程序，然后终止它，我们能立即重新启动这个服务器程序。
这意味着它没有经历2 M S L等待状态。用状态变迁来解释这一切。
18.5 在1 8 . 6节我们知道一个客户进程不能重新使用同一个本地端口，如果该端口是仍处于2 M S L等待连接的一部分。
但如果s o c k程序作为客户程序连续运行两次，并且连接到
d a yT i m e服务器上，我们就能重新使用同一本地端口。
另外，对一个仍处于2 M S L等待的连接，也能为它创建一个替身。这将如何做？
18.6 在1 8 . 6节的最后，我们介绍了F I N _ WA IT _ 2状态，提到如果应用程序仅过11分钟后实行完全关闭(不是半关闭)，
许多具体的实现都将一个连接由这个状态转移到C L O S E D状态。
如果另一端(处于C L O S E _ WA IT状态)在宣布关闭(即发送F I N)之前等待了1 2分钟，
这一端的TCP将如何响应这个F I N？
18.7 对于一个电话交谈，哪一方是主动打开，哪一方是被动打开？
是否允许同时打开？是否允许同时关闭？
第19章TCP的交互数据流
19.1 引言
前一章我们介绍了TCP连接的建立与释放，现在来介绍使用TCP进行数据传输的有关问题。
一些有关TCP通信量的研究如[Caceres et al. 1991]发现，如果按照分组数量计算，
约有一半的TCP报文段包含成块数据(如FT P、电子邮件和U s e n eT新闻)，
另一半则包含交互数据(如Te l n eT和R l o g i n)。
如果按字节计算，则成块数据与交互数据的比例约为9 0 %和1 0 %。
这是因为成块数据的报文段基本上都是满长度( f u l l - s i z e d)的(通常为5 1 2字节的用户数据)，
而交互数据则小得多。
很明显，TCP需要同时处理这两类数据，但使用的处理算法则有所不同。
本章将以R l o g i n应用为例来观察交互数据的传输过程。
将揭示经受时延的确认是如何工作的以及N a g l e算法怎样减少了通过广域网络传输的小分组的数目，
这些算法也同样适用于Te l n eT应用。下一章我们将介绍成块数据的传输问题。
19.6 小结
交互数据总是以小于最大报文段长度的分组发送。
在R l o g i n中通常只有一个字节从客户发送到服务器。
Te l n eT允许一次发送一行输入数据，但是目前大多数实现仍然发送一个字节。
对于这些小的报文段，接收方使用经受时延的确认方法来判断确认是否可被推迟发送，以便与回送数据一起发送。
这样通常会减少报文段的数目，尤其是对于需要回显用户输入字符的R l o g i n会话。
在较慢的广域网环境中，通常使用N a g l e算法来减少这些小报文段的数目。
这个算法限制发送者任何时候只能有一个发送的小报文段未被确认。
但我们给出的一个例子也表明有时需要禁止N a g l e算法的功能。
习题
19.1 考虑一个TCP客户应用程序，它发送一个小应用程序首部( 8个字节)和一个小请求(1 2个字节)，
然后等待来自服务器的一个应答。
比较以下两种方式发送请求时的处理情况：先发送8个字节再发送1 2个字节和一次发送2 0个字节。
19.2 图1 9 - 4中我们在路由器s u n上运行TCP d u m p。
这意味着从右至左的箭头中的数据也需要经过b s d i，同时从左至右的箭头中的数据已经流经b s d i。
当观察一个送往s l IP的报文段及下一个来自s l IP的报文段时，我
们发现它们之间的时间差分别为： 3 4 . 8、2 6 . 7、3 0 . 1、2 8 . 1、2 9 . 9和35.3 ms。
现给定在s u n和s l IP之间存在两条链路(一个以太链路和一个9600 b/s的C S L IP链路)，
试问这些时间差的含义(提示：重新阅读2 . 1 0节)。
19.3 比较在使用N a g l e算法(图1 9 - 6)和
禁止N a g l e算法(图1 9 - 8)的情况下发送一个特殊功能键并等待其应答所需要的时间。
第20章TCP的成块数据流
20.1 引言
在第1 5章我们看到T FT P使用了停止等待协议。
数据发送方在发送下一个数据块之前需要等待接收对已发送数据的确认。
本章我们将介绍TCP所使用的被称为滑动窗口协议的另一种形式的流量控制方法。
该协议允许发送方在停止并等待确认前可以连续发送多个分组。
由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。
我们还将介绍TCP的P U S H标志，该标志在前面的许多例子中都出现过。
此外，我们还要介绍慢启动，TCP使用该技术在一个连接上建立数据流，最后介绍成块数据流的吞吐量。
20.9 小结
正如我们在本章一开始时讲的那样，没有一种单一的方法可以使用TCP进行成块数据的交换。
这是一个依赖于许多因素的动态处理过程，有些因素我们可以控制(如发送和接收缓存的大小)，
而另一些我们则没有办法控制(如网络拥塞、与实现有关的特性等)。
在本章，我们已经考察了许多TCP的传输过程，介绍了所有我们能够看到的特点和算法。
进行成块数据有效传输的最重要的方法是TCP的滑动窗口协议。
我们考察了TCP为使发送方和接收方之间的管道充满来获得最可能快的传输速度而采用的方法。
我们用带宽时延乘积衡量管道的容量，并分析了该乘积与窗口大小之间的关系。
在2 4 . 8节介绍TCP性能的时候将再次涉及这个概念。
我们还介绍了TCP的P U S H标志，因为在跟踪结果中总是观察到它，但我们无法对它的设置与否进行控制。
本章最后一个主题是TCP的紧急数据，人们常常错误地称其为“带外数据”。
TCP的紧急方式只是一个从发送方到接收方的通知，该通知告诉接收方紧急数据已被发送，
并提供该数据最后一个字节的序号。
应用程序使用的有关紧急数据部分的编程接口常常都不是最佳的，从而导致更多的混乱。
习题
20.1 我们可以看到一个序号为0的字节和一个序号为8 1 9 3的字节，试问这两个字节的含义是什么？
20.2 提前观察图2 2 - 1，并解释主机b s d i设置P U S H标志的含义。
20.3 在一个U s e n eT记录中，有人抱怨说美国和日本之间的一个128 ms时延、
速率为256 000 b/s的链路吞吐量为120 000 b/s(利用率为4 7 %)，
而当链路通过卫星时其吞吐量则为33 000 b/s(利用率为1 3％)。
试问在这两种情况下窗口大小各为多少(假定卫星链路的时延为500 ms)？
卫星链路的窗口大小应该如何调整？
20.4 如果A P I提供一种方法，使得发送方可以告诉其TCP打开P U S H标志，
而接收方可以查询一个接收的报文段是否被设置了P U S H标志，
试问该标志能否被用作一个记录标记？
20.5 在图2 0 - 3中为什么没有合并报文段1 5和1 6？
20.6 在图2 0 - 1 3中，我们假定对应数据报文段之间的间隔，返回的A C K之间的间隔被分隔得很好。
如果在链路某处进行缓存并使许多A C K同时到达发送方，试问会发生什么情况？
第21章TCP的超时与重传
21.1 引言
TCP提供可靠的运输层。它使用的方法之一就是确认从另一端收到的数据。
但数据和确认都有可能会丢失。TCP通过在发送时设置一个定时器来解决这种问题。
如果当定时器溢出时还没有收到确认，它就重传该数据。
对任何实现而言，关键之处就在于超时和重传的策略，即怎样决定超时间隔和如何确定重传的频率。
我们已经看到过两个超时和重传的例子：
(1)在6 . 5节的I C M P端口不能到达的例子中，
看到T FT P客户使用UDP实现了一个简单的超时和重传机制：
假定5秒是一个适当的时间间隔，并每隔5秒进行重传；
( 2)在向一个不存在的主机发送A R P的例子中(第4 . 5节)，
我们看到当TCP试图建立连接的时候，在每个重传之间使用一个较长的时延来重传S Y N。
对每个连接，TCP管理4个不同的定时器。
1) 重传定时器使用于当希望收到另一端的确认。
在本章我们将详细讨论这个定时器以及一些相关的问题，如拥塞避免。
2) 坚持( p e r s i sT )定时器使窗口大小信息保持不断流动，
即使另一端关闭了其接收窗口。第2 2章将讨论这个问题。
3) 保活( k e e p a l i v e )定时器可检测到一个空闲连接的另一端何时崩溃或重启。
第2 3章将描述这个定时器。
4) 2MSL定时器测量一个连接处于T I M E _ WA IT状态的时间。
我们在1 8 . 6节对该状态进行了介绍。
本章以一个简单的TCP超时和重传的例子开始，然后转向一个更复杂的例子。
该例子可以使我们观察到TCP时钟管理的所有细节。
可以看到TCP的典型实现是怎样测量TCP报文段的往返时间，
以及TCP如何使用这些测量结果来为下一个将要传输的报文段建立重传超时时间。
接着我们将研究TCP的拥塞避免—当分组丢失时TCP所采取的动作—并提供一个分组丢失的实际例子，
我们还将介绍较新的快速重传和快速恢复算法，
并介绍该算法如何使TCP检测分组丢失比等待时钟超时更快。
21.12 小结
本章提供了对TCP超时和重传机制的详细研究。
使用的第1个例子是一个丢失的建立连接的S Y N，并观察了在随后的重传和超时中怎样使用指数退避方式。
TCP计算往返时间并使用这些测量结果来维护一个被平滑的RTT估计器和被平滑的均值偏差估计器。
这两个估计器用来计算下一个重传时间。许多实现对每个窗口仅测量一次RTT。
K a r n算法在分组丢失时可以不测量RTT就能解决重传的二义性问题。
详细例子包括3个丢失的分组，使我们看到TCP的许多实际算法：
慢启动、拥塞避免、快速重传和快速恢复。
我们也能够使用拥塞窗口和慢启动门限来手工计算TCP RTT估计器，并将这些值与跟踪输出的实际数据进行比较。
以多种I C M P差错对TCP连接的影响以及TCP怎样允许对数据进行重新分组来结束本章。
我们观察到“软”的I C M P差错没有引起TCP连接终止，
但这些差错被保存以便在连接非正常中止时能够报告这些软差错。
习题
21.1 在图2 1 - 5中第1个超时时间计算为6秒而第2个为1 2秒。
如果初始S Y N的确认在1 2秒超时溢出时还没有到达，则下一次超时在什么时候发生？
21.2 在图2 1 - 5后面的讨论中，我们提到计算的超时间隔分别为图4 - 5中表示的6、2 4和4 8秒。
如果观察一个从S V R 4系统到一个不存在的主机的连接，
则超时间隔分别为6, 12, 24和4 8秒。请问发生了什么情况？
21.3 按下面的描述比较TCP滑动窗口协议与T FT P的停止等待协议的性能。
在本章中，我们在3 5秒(图2 1 - 6)内传输3 2 7 6 8字节的数据，
其中链路的平均RTT是1 . 5秒(图2 1 - 4)。计算在同样条件下T FT P需要多长时间？
21.4 在第2 1 . 7节，我们提到过收到一个重复的A C K是因为一个报文段丢失或重新进行排序。
在2 1 . 5节我们看到1个丢失的报文段产生一些重复的A C K。
请画图表示重新排序也会产生一些重复的A C K。
21.5 在图2 1 - 6中的时刻2 8 . 8和2 9 . 8之间有一个显而易见的点，请问这是不是一个重传？
21.6 在2 1 . 6节我们提到过，如果目的地址位于一个不同的网络上，
4.3BSDTa h o e版本只执行慢启动。你认为在这里“不同的网络”是由什么决定的？。
21.7 在2 0 . 2节我们提到过，在正常情况下，TCP每隔一个报文段进行一次确认，
但是在图2 1 -2中，我们看到接收方对每个报文段都进行了确认，请解释其中的原因？
21.8 如果默认路由占优势，那么每路由( p e r- r o uT e)的度量是否真的有用？
第22章TCP的坚持定时器
22.1 引言
我们已经看到TCP通过让接收方指明希望从发送方接收的数据字节数来进行流量控制。
如果窗口大小为0会发生什么情况呢？这将有效地阻止发送方传送数据，直到窗口变为非0为止。
可以在图2 0 - 3中看到这种情况。当发送方接收到报文段9时，
它打开被报文段8关闭的窗口并立即开始发送数据。
TCP必须能够处理打开此窗口的A C K(报文段9)丢失的情况。
A C K的传输并不可靠，也就是说，
TCP不对A C K报文段进行确认，TCP只确认那些包含有数据的A C K报文段。
如果一个确认丢失了，则双方就有可能因为等待对方而使连接终止：
接收方等待接收数据(因为它已经向发送方通告了一个非0的窗口)，
而发送方在等待允许它继续发送数据的窗口更新。
为防止这种死锁情况的发生，发送方使用一个坚持定时器(persistTimer)来周期性地向接收方查询，
以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查( w i n d o wp r o b e )。
在本章中，我们将讨论窗口探查和坚持定时器，还将讨论与坚持定时器有关的糊涂窗口综合症。
22.4 小结
在连接的一方需要发送数据但对方已通告窗口大小为0时，就需要设置TCP的坚持定时器。
发送方使用与第2 1章类似的重传间隔时间，不断地探查已关闭的窗口。
这个探查过程将一直持续下去。
当运行一个例子来观察坚持定时器时，我们还观察到了TCP的避免出现糊涂窗口综合症的现象。
这就是使TCP避免通告小的窗口大小或发送小的报文段。在我们的例子中，
可以观察到发送方和接收方为避免糊涂窗口综合症所使用的策略。
习题
22.1 在图2 2 - 3中注意到所有确认(报文段5、7、9、11、1 3、1 5和1 7)的发送时刻为：
0.170, 5.170、1 0 . 1 7 0、1 5 . 1 7 0、2 0 . 1 7 0和2 5 . 1 7 0，
还注意到在接收数据和发送A C K之间的时间差分别为：
1 6 4 . 5、1 8 . 5、1 8 . 7、1 8 . 8、1 9 8 . 3、1 8 . 5和19.1 ms。
试解释可能会发生的情况。
22.2 在图2 2 - 3中的时刻2 5 . 1 7 4，发送出一个7 6 7字节的通告窗口，
而在接收缓存中有7 6 8字节的可用空间。为什么相差1个字节？
第23章TCP的保活定时器
23.1 引言
许多TCP/IP的初学者会很惊奇地发现可以没有任何数据流通过一个空闲的TCP连接。
也就是说，如果TCP连接的双方都没有向对方发送数据，则在两个TCP模块之间不交换任何信息。
例如，没有可以在其他网络协议中发现的轮询。
这意味着我们可以启动一个客户与服务器建立一个连接，
然后离去数小时、数天、数个星期或者数月，而连接依然保持。
中间路由器可以崩溃和重启，电话线可以被挂断再连通，
但是只要两端的主机没有被重启，则连接依然保持建立。
这意味着两个应用进程—客户进程或服务器进程—都没有使用应用级的定时器来检测非活动状态，
而这种非活动状态可以导致应用进程中的任何一个终止其活动。
回想在第1 0 . 7节末尾曾提到过的B G P每隔3 0秒就向对端发送一个应用的探查，
就是独立于TCP的保活定时器之外的应用定时器。
然而，许多时候一个服务器希望知道客户主机是否崩溃并关机或者崩溃又重新启动。
许多实现提供的保活定时器可以提供这种能力。
保活并不是TCP规范中的一部分。
Host Requirements RFC提供了3个不使用保活定时器的理由：
(1) 在出现短暂差错的情况下，这可能会使一个非常好的连接释放掉；
2)它们耗费不必要的带宽；
(3)在按分组计费的情况下会在互联网上花掉更多的钱。
然而，许多实现提供了保活定时器。
保活定时器是一个有争论的功能。许多人认为如果需要，
这个功能不应该在TCP中提供，而应该由应用程序来完成。
这是应当认真对待的一些问题之一，因为在这个论题上有些人表达出了很大的热情。
在连接两个端系统的网络出现临时故障的时候，保活选项会引起一个实际上很好的连接终止。
例如，如果在一个中间路由器崩溃并重新启动时发送保活探查，
那么TCP会认为客户的主机已经崩溃，而实际上所发生的并非如此。
保活功能主要是为服务器应用程序提供的。
服务器应用程序希望知道客户主机是否崩溃，从而可以代表客户使用资源。
许多版本的R l o g i n和Te l n eT服务器默认使用这个选项。
一个说明现在需要使用保活功能的常见例子是当个人计算机用户使用TCP/IP向一个使用
Te l n eT的主机注册时。如果在一天结束时，他们仅仅关闭了电源而没有注销，那么便会留下一
个半开放的连接。在图1 8 - 1 6中，我们看到通过一个半开放连接发送数据会导致返回一个复位，
但那是在来自正在发送数据的客户端。如果客户已经消失了，使得在服务器上留下一个半开
放连接，而服务器又在等待来自客户的数据，则服务器将永远等待下去。
保活功能就是试图在服务器端检测到这种半开放的连接。
23.2 描述
在这个描述中，我们称使用保活选项的一端为服务器，而另一端则为客户。
并没有什么使客户不能使用这个选项，但通常都是服务器设置这个功能。
如果双方都特别需要了解对方是否已经消失，则双方都可以使用这个选项，
但在第2 6章讲到Te l n eT和R l o g i n时，只有服务器设置了这个选项，而客户则没有。
如果一个给定的连接在两个小时之内没有任何动作，则服务器就向客户发送一个探查报文段。
客户主机必须处于以下4个状态之一。
1) 客户主机依然正常运行，并从服务器可达。
客户的TCP响应正常，而服务器也知道对方是正常工作的。
服务器在两小时以后将保活定时器复位。
如果在两个小时定时器到时间之前有应用程序的通信量通过此连接，则定时器在交换数据后的未来2小时再复位。
2) 客户主机已经崩溃，并且关闭或者正在重新启动。
在任何一种情况下，客户的TCP都没有响应。服务器将不能够收到对探查的响应，并在7 5秒后超时。
服务器总共发送1 0个这样的探查，每个间隔7 5秒。
如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
3) 客户主机崩溃并已经重新启动。这时服务器将收到一个对其保活探查的响应，
但是这个响应是一个复位，使得服务器终止这个连接。
4) 客户主机正常运行，但是从服务器不可达。这与状态2相同，因为TCP不能够区分状态
4与状态2之间的区别，它所能发现的就是没有收到探查的响应。
服务器不用关注客户主机被关闭和重新启动的情况(这指的是一个操作员的关闭，而不
是主机崩溃)。当系统被操作员关闭时，所有的应用进程也被终止(也就是客户进程)，
这会使客户的TCP在连接上发出一个F I N。
接收到F I N将使服务器的TCP向服务器进程报告文件结束，使服务器可以检测到这个情况。
在第1种情况下，服务器的应用程序没有感觉到保活探查的发生。TCP层负责一切。
这个过程对应用程序都是透明的，直至第2、3或4种情况发生。
在这三种情况下，服务器应用程序将收到来自它的TCP的差错报告。
在第2种情况下，差错是诸如“连接超时”之类的信息，而在第3种情况则为“连接被对方复位”。
第4种情况看起来像是连接超时，也可根据是否收到与连接有关的I C M P差错来返回其他的差错。
在下一节中我们将观察这4种情况。
一个被人们不断讨论的关于保活选项的问题就是两个小时的空闲时间是否可以改变。
通常他们希望该数值可以小得多，处在分钟的数量级。
正如我们在附录E看到的，这个值通常可以改变，但是在该附录所描述的所有系统中，
保活间隔时间是系统级的变量，因此改变它会影响到所有使用该功能的用户。
Host Requirements RFC提到一个实现可提供保活的功能，但是除非应用程序指明要这样，
否则就不能使用该功能。而且，保活间隔必须是可配置的，但是其默认值必须不小于两个小时。
23.4 小结
正如我们在前面提到的，对保活功能是有争议的。
协议专家继续在争论该功能是否应该归入运输层，或者应当完全由应用层来处理。
在连接空闲两个小时后，在一个连接上发送一个探查分组来完成保活功能。
可能会发生4种不同的情况：对端仍然运行正常、
对端已经崩溃、对端已经崩溃并重新启动以及对端当前无法到达。
我们使用一个例子来观察每一种情况，并观察到在最后三个条件下返回的不同差错。
在前两个例子中，如果没有提供这种功能，并且也没有应用层的定时器，
则客户将永远无法知道对端已经崩溃或崩溃并重新启动。
可是在最后一个例子中，两端都没有发生差错，只是它们之间的连接临时中断。
我们在使用保活时必须关注这个限制。
习题
23.1 列出保活功能的一些优点。
23.2 列出保活功能的一些缺点
第24章TCP的未来和性能
24.1 引言
TCP已经在从1200 b/s的拨号S L IP链路到以太数据链路上运行了许多年。
在8 0年代和9 0年代初期，以太网是运行TCP/IP最主要的数据链路方式。
虽然TCP在比以太网速率高的环境(如T 2电话线、F D D I及千兆比网络)中也能够正确运行，
但在这些高速率环境下，TCP的某些限制就会暴露出来。
本章讨论TCP的一些修改建议，这些建议可以使TCP在高速率环境中获得最大的吞吐量。
首先要讨论前面已经碰到过的路径MT U发现机制，本章主要关注它如何与TCP协同工作。
这个机制通常可以使TCP为非本地的连接使用大于5 3 6字节的MT U，从而增加吞吐量。
接着介绍长肥管道(long fat pipe)，也就是那些具有很大的带宽时延乘积的网络，
以及TCP在这些网络上所具有的局限性。为处理长肥管道，我们描述两个新的TCP选项：
窗口扩大选项(用来增加TCP的最大窗口，使之超过6 5 5 3 5字节)和时间戳选项。
后面这个选项可以使TCP对报文段进行更加精确的RTT测量，还可以在高速率下对可能发生的序号回绕提供保护。
这两个选项在RFC 1323 [Jacobson, Braden, and Borman 1992]中进行定义。
我们还将介绍建议的T /TCP，这是为增加事务功能而对TCP进行的修改。
通信的事务模式以客户的请求将被服务器应答的响应为主要特征。这是客户服务器计算的常见模型。
T /TCP的目的就是减少两端交换的报文段数量，避免三次握手和使用4个报文段进行连接的关闭，
从而使客户可以在一个RTT和处理请求所必需的时间内收到服务器的应答。
这些新选项(路径MT U发现、窗口扩大选项、时间戳选项和T /TCP)中，
令人印象最深刻的就是它们与现有的TCP实现能够向后兼容，
即包括这些新选项的系统仍然可以与原有的旧系统进行交互。
除了在一个I C M P报文中为路径MT U发现增加了一个额外字段之外，
这些新的选项只需要在那些需要使用它们的端系统中进行实现。
我们以介绍近来发表的有关TCP性能的图例作为本章的结束。
24.2 路径MTU发现
在2 . 9节我们描述了路径MT U的概念。这是当前在两个主机之间的路径上任何网络上的最小MT U。
路径MT U发现在IP首部中继承并设置“不要分片( D F)”比特，
来发现当前路径上的路由器是否需要对正在发送的IP数据报进行分片。
在11 . 6节我们观察到如果一个待转发的IP数据报被设置D F比特，
而其长度又超过了MT U，那么路由器将返回I C M P不可达的差错。
在11 . 7节我们显示了某版本的t r a c e r o uT e程序使用该机制来决定目的地的路径MT U。
在11 . 8节我们看到UDP是怎样处理路径MT U发现的。
在本节我们将讨论这个机制是如何按照R F C 1191 [Mogul and Deering 1990]中规定的那样在TCP中进行使用的。
24.9 小结
本章已经讨论了五个新的TCP特征：
路径MT U发现、窗口扩大选项、时间戳选项、序号回绕保护以及使用改进的TCP事务处理。
我们观察到中间的三个特征是为在长肥管道——具有大的带宽时延乘积的网络—上优化性能所需要的。
路径MT U发现在MT U较大时，对于非本地连接，允许TCP使用比默认的5 3 6大的窗口。
这样可以提高性能。窗口扩大选项使最大的TCP窗口从6 5 5 3 5增加到1千兆字节以上。
时间戳选项允许多个报文段被精确计时，并允许接收方提供序号回绕保护( PAW S)。
这对于高速连接是必须的。这些新的TCP选项在连接时进行协商，
并被不理解它们的旧系统忽略，从而允许较新的系统与旧的系统进行交互。
为事务用的TCP扩展，即T /TCP，
允许一个客户/服务器的请求-应答序列在通常的情况下只使用三个报文段来完成。
它避免使用三次握手，并缩短了T I M E _ WA IT状态，其方法是为每个主机高速缓存少量的信息，
这些信息曾用来建立过一个连接。它还在包含数据报文段中使用S Y N和F I N标志。
由于还有许多关于TCP能够运行多快的不精确的传闻，因此我们以对TCP性能的分析来结
束本章。对于一个使用本章介绍的较新特征、协调得非常好的实现而言，
TCP的性能仅受最大的1千兆字节窗口和光速(也就是往返时间)的限制。
习题
24.1 当一个系统发送一个开始的S Y N报文段，其窗口扩大因子为0，这是什么含义？
24.2 如果在图2 4 - 7中的主机b s d i支持窗口扩大选项，则来自v a n g o g h的报文段3的16 bit窗
口大小字段中的期望值是多少？类似地，如果在该图的第2个连接中也使用这个选项，
那么报文段1 3中的窗口通告应该是多少？
24.3 与在建立连接时的固定窗口扩大因子不同，
已经定义过的窗口扩大因子能否在扩大因子变化时也出现呢？
24.4 假定M S L为2分钟，那么在什么速率下序号回绕会成为一个问题呢?
24.5 PAW S被定义为只在一个单独的连接中进行。
为了使TCP将PAW S来替换2 M S L等待(即T I M E _ WA IT状态)，需要进行什么改动？
24.6 在2 4 . 4节最后的例子中，为什么s o c k程序在紧接着后面的一行之前，将接收缓存的大小来输出呢？
24.7 假定M S S为1 0 2 4，重新计算2 4 . 8节中的吞吐量。
24.8 时间戳选项是如何影响K a r n算法的？
24.9 如果主动建立连接的TCP发送带有S Y N标志的报文段，那么接收TCP应该怎样处理这些数据呢?
24.10 在2 4 . 7节我们提到如果没有使用T /TCP扩展，即使主动开启方发送带有F I N的数据，客
户在接收服务器的响应的时延仍然是两倍的RTT再加上S PT。
给出符合这种情况的报文段。
2 4 . 11 假定支持T /TCP，且源自伯克利系统的最小RTO为0 . 5秒，重做习题1 8 . 1 4。
24.12 如果我们实现了T /TCP，并测量两个主机之间的事务时间，
那么可以通过比较什么指标来确定它的有效性？