第18章 TCP连接的建立与终止
18.1 引言
T C P是一个面向连接的协议。无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。本章将详细讨论一个 T C P连接是如何建立的以及通信结束后是如何终止的。这种两端间连接的建立与无连接协议如 U D P不同。我们在第 11章看到一端使用 U D P向另一端发送数据报时，无需任何预先的握手。
18.2 连接的建立与终止
为了了解一个T C P连接在建立及终止时发生了什么，我们在系统 s v r 4上键入下列命令：
t e l n e t命令在与丢弃 ( d i s c a r d )服务（参见 1 . 1 2节）对应的端口上与主机 b s d i建立一条T C P连接。这服务类型正是我们需要观察的一条连接建立与终止的服务类型，而不需要服务器发起任何数据交换。
18.2.1 t c p d u m p的输出
图1 8 - 1显示了这条命令产生T C P报文段的t c p d u m p输出。
这7个T C P报文段仅包含T C P首部。没有任何数据。
对于T C P段，每个输出行开始按如下格式显示：
源 > 目的: 标志
这里的标志代表 T C P首部（图1 7 - 2）中6个标志比特中的 4个。图1 8 - 2显示了表示标志的 5个字符的含义。
在这个例子中，我们看到了 S、F和句点“.”标志符。我们将在以后看到其他的两个标志（ R 和P）。T C P首部中的其他两个标志比特—ACK 和 U R G—t c p d u m p将作特殊显示。
图1 8 - 2所示的4个标志比特中的多个可能同时出现在一个报文段中，但通常一次只见到一个。RFC 1025 [Postel 1987], “TCP and IP Bake Off”，将一种报文段称为K a m i k a z e分组 ，在这样的报文段中有最大数量的标志比特同时被置为1（SYN, URG, PSH, FIN和1字节的数据）。这样的报文段也叫作nastygram, 圣诞树分组，灯测试报文段(lamp test segment)。
在第1行中，字段1 4 1 5 5 3 1 5 2 1 : 1 4 1 5 5 3 1 5 2 1 ( 0 )表示分组的序号是1 4 1 5 5 3 1 5 2 1，而报文段中数据字节数为 0。t c p d u m p显示这个字段的格式是开始的序号、一个冒号、隐含的结尾序号及圆括号内的数据字节数。显示序号和隐含结尾序号的优点是便于了解数据字节数大于 0时的隐含结尾序号。这个字段只有在满足条件
（ 1）报文段中至少包含一个数据字节；或者（ 2）S Y N、F I N或R S T被设置为1时才显示。图1 8 - 1中的第1、2、4和6行是因为标志比特被置为 1而显示这个字段的，在这个例子中通信双方没有交换任何数据。在第2行中，字段ack 1415531522表示确认序号。它只有在首部中的 A C K标志比特被设置1时才显示。
每行显示的字段 win 4096表示发端通告的窗口大小。在这些例子中，我们没有交换任何数据，窗口大小就维持默认情况下的 4 0 9 6（我们将在2 0 . 4节中讨论T C P窗口大小）。 图1 8 - 1中的最后一个字段 <mss 1024>表示由发端指明的最大报文段长度选项。发端将不接收超过这个长度的 T C P报文段。这通常是为了避免分段（见 11 . 5节）。我们将在1 8 . 4节讨论最大报文段长度，而在1 8 . 1 0节介绍不同TCP 选项的格式。
18.2.2 时间系列
图1 8 - 3显示了这些分组序列的时间系列（在图 6 - 11中已经首次介绍了这些时间系列的一些基本特性）。这个图显示出哪一端正在发送分组。我们也将对 t c p d u m p输出作一些扩展（例如，印出S Y N而不是S）。在这个时间系列中也省略窗口大小的值，因为它和我们的讨论无关。
18.2.3 建立连接协议
现在让我们回到图1 8 - 3所示的T C P协议中来。为了建立一条T C P连接：
- 请求端（通常称为客户）发送一个 S Y N段指明客户打算连接的服务器的端口，以及初始序号（I S N，在这个例子中为1 4 1 5 5 3 1 5 2 1）。这个S Y N段为报文段1。
- 服务器发回包含服务器的初始序号的 S Y N报文段（报文段2）作为应答。同时，将确认序号设置为客户的I S N加1以对客户的S Y N报文段进行确认。一个S Y N将占用一个序号。
- 客户必须将确认序号设置为服务器的 I S N加1以对服务器的S Y N报文段进行确认（报文段3）。
这三个报文段完成连接的建立。这个过程也称为三次握手（ three-way handshake）。
发送第一个S Y N的一端将执行主动打开（ active open）。接收这个S Y N并发回下一个S Y N的另一端执行被动打开（passive open）（在1 8 . 8节我们将介绍双方如何都执行主动打开）。
当一端为建立连接而发送它的 S Y N时，它为连接选择一个初始序号。 I S N随时间而变化，因此每个连接都将具有不同的 I S N。RFC 793 [Postel 1981c]指出I S N可看作是一个3 2比特的计数器，每4 m s加1。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它作错误的解释。
如何进行序号选择? 在4 . 4 B S D（和多数的伯克利的实现版）中，系统初始化时初始的发送序号被初始化为1。这种方法违背了Host Requirements RFC（在这个代码中的一个注释确认这是一个错误）。这个变量每0 . 5秒增加6 4 0 0 0，并每隔9 . 5小时又回到0（对应这个计数器每8 ms加1，而不是每4 ms加1）。另外，每次建立一个连接后，这个变量将增加64000。报文段3与报文段4之间4 . 1秒的时间间隔是建立 T C P连接到向t e l n e t键入q u i t命令来中止该连接的时间。
18.2.4 连接终止协议
建立一个连接需要三次握手，而终止一个连接要经过 4次握手。这由T C P的半关闭（h a l f - c l o s e）造成的。既然一个T C P连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。这原则就是当一方完成它的数据发送任务后就能发送一个 F I N来终止这个方向连接。当一端收到一个 F I N，它必须通知应用层另一端几经终止了那个方向的数据传送。发送F I N通常是应用层进行关闭的结果。
收到一个F I N只意味着在这一方向上没有数据流动。一个 T C P连接在收到一个 F I N后仍能发送数据。而这对利用半关闭的应用来说是可能的，尽管在实际应用中只有很少的 T C P应用程序这样做。正常关闭过程如图 1 8 - 3所示。我们将在1 8 . 5节中详细介绍半关闭。
首先进行关闭的一方（即发送第一个 F I N）将执行主动关闭，而另一方（收到这个 F I N）执行被动关闭。通常一方完成主动关闭而另一方完成被动关闭，但我们将在 1 8 . 9节看到双方如何都执行主动关闭。
图1 8 - 3中的报文段4发起终止连接，它由Te l n e t客户端关闭连接时发出。这在我们键入 q u i t命令后发生。它将导致T C P客户端发送一个F I N，用来关闭从客户到服务器的数据传送。
当服务器收到这个 F I N，它发回一个A C K，确认序号为收到的序号加 1（报文段5）。和S Y N一样，一个F I N将占用一个序号。同时 T C P服务器还向应用程序（即丢弃服务器）传送一个文件结束符。接着这个服务器程序就关闭它的连接，导致它的 T C P端发送一个F I N（报文段6），客户必须发回一个确认，并将确认序号设置为收到序号加1（报文段7）。 图1 8 - 4显示了终止一个连接的典型握手顺序。我们省略了序号。在这个图中，发送F I N将导致应用程序关闭它们的连接，这些F I N的A C K是由T C P软件自动产生的。
连接通常是由客户端发起的，这样第一个 S Y N从客户传到服务器。每一端都能主动关闭这个连接（即首先发送 F I N）。然而，一般由客户端决定何时终止连接，因为客户进程通常由用户交互控制，用户会键入诸如“ q u i t”一样的命令来终止进程。在图 1 8 - 4中，我们能改变上边的标识，将左方定为服务器，右方定为客户，一切仍将像显示的一样工作（例如在 1 4 . 4节中的第一个例子中就是由d a y t i m e服务器关闭连接的）。
18.2.5 正常的t c p d u m p输出
对所有的数值很大的序号进行排序是很麻烦的，因此默认情况下 t c p d u m p只在显示S Y N报文段时显示完整的序号，而对其后的序号则显示它们与初始序号的相对偏移值（为了得到图1 8 - 1的输出显示必须加上- S选项）。对应于图1 8 - 1的正常t c p d u m p显示如图1 8 - 5所示：
除非我们需要显示完整的序号，否则将在以下的例子中使用这种形式的输出显示。
