TCP：连接的建立和终止

图18-1显示了这条命令产生TCP报文段的tcpdump输出：

这7个TCP报文段仅包含TCP首部，没有任何数据。对于TCP段，每个输出行开始按如下格式显示：

   源 > 目的 : 标志

这里的标志代表TCP首部中6个标志比特中的4个。下表显示了标志的5个字符的含义：

在这个例子中，看到了 S 、 F 和 . 标志符。以后看到其他的两个标志（ R 和 P ）。TCP首部中的其他两个标志比特 ACK 和 URG ，tcpdump将作特殊显示。表中4个标志比特中的多个可能同时出现在一个报文段中，但通常一次只见到一个

RFC 1025将一种报文段称为Kamikaze分组Θ，在这样的报文段中有最大数量的标志比特同时被置为1（SYN,URG,PSH,FIN和1字节的数据）。这样的报文段也叫作nastygram,圣诞树分组，灯测试报文段

• 在第1行 1415531521:1415531521(0) : 分组的序号是1415531521，而报文段中数据字节数为0
  • tcpdump显示这个字段的格式：
    • 开始的序号
    • 一个冒号
    • 隐含的结尾序号
    • 圆括号内的数据字节数
  • 优点：便于了解数据字节数大于0时的隐含结尾序号
  • 隐含的结尾序号只有在满足下面条件之一才显示 ：
    1. 报文段中至少包含一个数据字节
    2. SYN、FIN或RST被设置为1时才显示
• 在第2行中 ack 1415531522 ：确认序号， 它只有在首部中的ACK标志比特被设置1时才显示
• 每行显示的字段 win 4096 : 发送端通告的窗口大小。例子中没有交换任何数据，所以窗口大小就维持默认情况下的4096
• 最后一个字段 <mss1024> ：由发送端指明的最大报文段长度选项。发送端将不接收超过这个长度的TCP报文段。这通常是为了避免分段

图18-3显示了这些分组序列的时间系列，这个图显示出哪一端正在发送分组：

为了建立一条TCP连接：

1. 报文段1：请求端（通常称为客户）发送一个SYN段指明客户打算连接的服务器的端口，以及初始序号（ISN，在这个例子中为1415531521）
2. 报文段2：服务器发回包含服务器的初始序号的SYN报文段（报文段2）作为应答。同时， 将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认，而且一个SYN将占用一个序号
3. 报文段3：客户必须 将确认序号设置为服务器的ISN加1以对服务器的SYN报文段进行确认

发送第一个SYN的一端将执行主动打开。接收这个SYN并发回下一个SYN的另一端执行被动打开

当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。RFC 793指出ISN可看作是一个32比特的计数器，每4ms加1。这样选择序号的目的在于 防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它作错误的解释

  如何进行序号选择？

  在4.4BSD（和多数的伯克利的实现版）中，系统初始化时初始的发送序号被初始化为1

  这个变量每0.5秒增加64000，并每隔9.5小时又回到0（对应这个计数器每8 ms加1，而不是每4 ms加1）

  另外，每次建立一个连接后，这个变量将增加64000

报文段3与报文段4之间4.1秒的时间间隔是建立TCP连接到向telnet键入quit命令来中止该连接的时间

建立一个连接需要三次握手，而终止一个连接要经过4次握手，这由TCP的半关闭造成的。 因为一个TCP连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭 。这原则就是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向连接。当一端收到一个FIN，它必须通知应用层另一端已经终止了那个方向的数据传送。 发送FIN通常是应用层进行关闭的结果

   收到一个FIN只意味着在这一方向上没有数据流动。一个TCP连接在收到一个FIN后仍能发送数据
   
   而这对利用半关闭的应用来说是可能的，尽管在实际应用中只有很少的TCP应用程序这样做

首先进行关闭的一方（即发送第一个FIN）将执行主动关闭，而另一方（收到这个FIN）执行被动关闭。通常一方完成主动关闭而另一方完成被动关闭，但也可能双方都执行主动关闭

正常关闭过程如图18-3所示：

1. 报文段4：发起终止连接，它由Telnet客户端关闭连接时发出。这在键入quit命令后发生。它将导致TCP客户端发送一个FIN，用来关闭从客户到服务器的数据传送
2. 报文段5：当服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。 和SYN一样，一个FIN将占用一个序号
   • TCP服务器还向应用程序（即丢弃服务器）传送一个文件结束符
3. 报文段6：这个服务器程序就关闭它的连接，导致它的TCP端发送一个FIN
4. 报文段7：客户必须发回一个确认，并将确认序号设置为收到序号加1

图18-4显示了终止一个连接的典型握手顺序。在这个图中，发送FIN将导致应用程序关闭它们的连接，这些FIN的ACK是由TCP软件自动产生的：

连接通常是由客户端发起的，这样第一个SYN从客户传到服务器。每一端都能主动关闭这个连接（即首先发送FIN）。然而，一般由客户端决定何时终止连接，因为客户进程通常由用户交互控制，用户会键入诸如“quit”一样的命令来终止进程。在图18-4中，我们能改变上边的标识，将左方定为服务器，右方定为客户，一切仍将像显示的一样工作

对所有的数值很大的序号进行排序是很麻烦的，因此默认情况下tcpdump只在显示SYN报文段时显示完整的序号，而对其后的序号则显示它们与初始序号的相对偏移值

除非我们需要显示完整的序号，否则将在以下的例子中使用这种形式的输出显示：

在图18-6中，出现了符号 [tos 0x10]。这是IP数据报内的服务类型（TOS）字段。BSD/386中的Telnet客户进程将这个字段设置为最小时延

考虑主机slip，通过MTU为296的SLIP链路连接到路由器bsdi上。图18-8显示这些系统和主机sun：

从sun向slip发起一个TCP连接，并使用tcpdump来观察报文段。图18-9显示这个连接的建立：

在这个例子中，sun发送的报文段不能超过256字节的数据，因为它收到的MSS选项值为256。此外，由于slip知道它外出接口的MTU长度为296，即使sun已经通告它的MSS为1460，但为避免将数据分段，它不会发送超过256字节数据的报文段。系统允许发送的数据长度小于另一端的MSS值

只有当一端的主机以小于576字节的MTU直接连接到一个网络中，避免这种分段才会有效 。如果两端的主机都连接到以太网上，都采用536的MSS，但中间网络采用296的MTU，也将会出现分段。使用路径上的MTU发现机制是关于这个问题的唯一方法

一个典型的例子是Unix中的rsh(1)命令，它将完成在另一个系统上执行一个命令

sun$ rsh bsdi sort < datafile

这将在主机bsdi上执行sort排序命令，rsh命令的标准输入来自文件datafile。rsh将在它与在另一主机上执行的程序间建立一个TCP连接。rsh的操作很简单：它将标准输入（datafile）复制给TCP连接，发送给bsdi主机，并将bsdi上的执行结果从TCP连接中复制给标准输出（sun主机的终端）。图18-11显示了这个建立过程：

在远端主机bsdi上，rshd服务器将执行sort程序，它的标准输入和标准输出都是TCP连接

   请牢记TCP连接是全双工的，两边都可以互相发送数据

sort程序只有读取到所有输入数据后才能产生输出。所有的原始数据通过TCP连接从rsh客户端传送到sort服务器进行排序。当输入(datafile)到达文件尾时，rsh客户端执行这个TCP连接的半关闭。接着sort服务器在它的标准输入（TCP连接）上收到一个文件结束符，对数据进行排序，并将结果写在它的标准输出上（TCP连接）。rsh客户端继续接收来自TCP连接另一端的数据，并将排序的文件复制到它的标准输出上

   没有半关闭，需要其他的一些技术让客户通知服务器，客户端已经完成了它的数据传送，但仍要接收来自服务器的数据
   
   使用两个TCP连接也可作为一个选择，但使用半关闭的单连接更好

TIME_WAIT状态也称为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL。它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段

RFC 793指出MSL为2分钟。然而，实现中的常用值是30秒，1分钟，或2分钟

对一个具体实现所给定的MSL值，处理的原则是： 当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失，被动关闭的另一端超时并重发最后的FIN

这种2MSL等待的结果： 这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用 。这个连接只能在2MSL结束后才能再被使用

   遗憾的是，大多数TCP实现强加了更为严格的限制。在2MSL等待期间，插口中使用的本地端口在默认情况下不能再被使用
   
   某些实现和API提供了一种避开这个限制的方法：使用socket API时，可说明其中的SO_REUSEADDR选项
   
   它将让调用者对处于2MSL等待的本地端口进行赋值，但TCP原则上仍将避免使用仍处于2MSL连接中的端口

在连接处于2MSL等待时，任何迟到的报文段将被丢弃。因为处于2MSL等待的、由该插口对定义的连接在这段时间内不能被再用，因此当要建立一个有效的连接时，来自该连接的一个较早替身的迟到报文段作为新连接的一部分不可能不被曲解（一个连接由一个插口对来定义。一个连接的新的实例称为该连接的替身）。

图18-13中客户执行主动关闭并进入TIME_WAIT是正常的。服务器通常执行被动关闭，不会进入TIME_WAIT状态。这暗示 如果终止一个客户程序，并立即重新启动这个客户程序，则这个新客户程序将不能重用相同的本地端口。这不会带来什么问题，因为客户使用本地端口，而并不关心这个端口号是什么

然而，对于服务器，情况就有所不同，因为服务器使用熟知端口。 如果终止一个已经建立连接的服务器程序，并试图立即重新启动这个服务器程序，服务器程序将不能把它的这个熟知端口赋值给它的端点，因为那个端口是处于2MSL连接的一部分。在重新启动服务器程序前，它需要在1~4分钟

在FIN_WAIT_2状态已经发出了FIN，并且另一端也已对它进行确认。除非我们在实行半关闭，否则将等待另一端的应用层意识到它已收到一个文件结束符说明，并向我们发一个FIN来关闭另一方向的连接。只有当另一端的进程完成这个关闭，我们这端才会从FIN_WAIT_2状态进入TIME_WAIT状态。

这意味着 我们这端可能永远保持这个状态。另一端也将处于CLOSE_WAIT状态，并一直保持这个状态直到应用层决定进行关闭

   许多伯克利实现采用如下方式来防止这种在FIN_WAIT_2状态的无限等待：
   
   如果执行主动关闭的应用层将进行全关闭，而不是半关闭来说明它还想接收数据，就设置一个定时器。如果这个连接空闲10分钟75秒，TCP将进入CLOSED状态

已经介绍了TCP首部中的RST比特是用于 复位 的。一般说来，无论何时一个报文段发往基准的连接出现错误，TCP都会发出一个复位报文段

   基准的连接是指由目的IP地址和目的端口号以及源IP地址和源端口号指明的连接，这就是为什么RFC 793称之为插口

两个应用程序同时彼此执行主动打开的情况是可能的，尽管发生的可能性极小。每一方必须发送一个SYN，且这些SYN必须传递给对方。这需要每一方使用一个对方熟知的端口作为本地端口。这又称为 同时打开

例如，主机A中的一个应用程序使用本地端口7777，并与主机B的端口8888执行主动打开。主机B中的应用程序则使用本地端口8888，并与主机A的端口7777执行主动打开

   这与下面的情况不同：
   主机A中的telnet客户程序和主机B中telnet的服务器程序建立连接，与此同时，主机B中的telnet客户程序与主机A的telnet服务器程序也建立连接
   
   这里两个telnet服务器都执行被动打开，而不是主动打开，并且telnet客户选择的本地端口不是另一端telnet服务器进程所熟悉的端口

TCP是特意设计为了可以处理同时打开，对于同时打开它 仅建立一条连接而不是两条连接 （其他的协议族，最突出的是OSI运输层，在这种情况下将建立两条连接而不是一条连接）

当出现同时打开的情况时，状态变迁与图18-13所示的不同。两端几乎在同时发送SYN，并进入SYN_SENT状态。当每一端收到SYN时，状态变为SYN_RCVD，同时它们都再发SYN并对收到的SYN进行确认。当双方都收到SYN及相应的ACK时，状态都变迁为ESTABLISHED。图18-17显示了这些状态变迁过程：

一个同时打开的连接需要交换4个报文段，比正常的三次握手多一个 。此外，要注意的是没有将任何一端称为客户或服务器，因为 每一端既是客户又是服务器

以前讨论过一方（通常但不总是客户方）发送第一个FIN执行主动关闭。双方都执行主动关闭也是可能的，TCP协议也允许这样的 同时关闭

在图18-12中，当应用层发出关闭命令时，两端均从ESTABLISHED变为FIN_WAIT_1。这将导致双方各发送一个FIN，两个FIN经过网络传送后分别到达另一端。收到FIN后，状态由FIN_WAIT_1变迁到CLOSING，并发送最后的ACK。当收到最后的ACK时，状态变化为TIME_WAIT。图18-19总结了这些状态的变化：

同时关闭与正常关闭使用的段交换数目相同

通过观察任何一个TCP服务器，可以了解TCP如何处理端口号。使用netstat命令来观察telnet服务器。下面是在没有telnet连接时的显示：

sun$ netstat -a -n -f inet

Active Internet Connections (including servers)
Proto Recv-Q Send-Q Local-Address Foreign-Address State
tcp   0      0      *.23          *.*             LISTEN

• -a 标志显示网络中的所有主机端，而不仅仅是处于ESTABLISHED的主机端。 -n 标志将以点分十进制的形式显示IP地址，而不是通过DNS将地址转化为主机名，同时还要求显示端口号(23)而不是服务名称(telnet）。 -f inet 选项则仅要求显示使用TCP或UDP的主机
• 显示的本地地址为 * .23 ，星号通常又称为通配符。这表示传入的连接请求 SYN 将被任何一个本地接口所接收。如果该主机是多接口主机，将制定其中的一个IP地址为本地IP地址，并且只接收来自这个接口的连接。本地端口为 23 ，这是 telnet 的熟知端口号
• 远端地址显示为 . ，表示还不知道远端IP地址和端口号，因为该端还处于LISTEN状态，正等待连接请求的到达

现在在主机slip（140.252.13.65）启动一个telnet客户程序来连接这个telnet服务器。以下是netstat程序的输出行：

Active Internet Connections (including servers)
Proto Recv-Q Send-Q Local-Address        Foreign-Address         State
tcp   0      0      140.252.13.33.23     140.252.13.65.1029      ESTABLISHED
tcp   0      0      *.23                 *.*                     LISTEN

• 端口为23的第1行表示处于ESTABLISHED状态的连接。另外还显示了这个连接的本地IP地址、本地端口号、远端IP地址和远端端口号。本地IP地址为该连接请求到达的接口（以太网接口，140.252.13.33）
• 处于LISTEN状态的服务器进程仍然存在。这个服务器进程是当前telnet服务器用于接收其他的连接请求。当传入的连接请求到达并被接收时， 系统内核中的TCP模块就创建一个处于ESTABLISHED状态的进程
• 处于ESTABLISHED状态的连接的端口不会变化：也是23， 与处于LISTEN状态的进程相同

现在在主机slip上启动另一个telnet客户进程，并仍与这个telnet服务器进行连接。以下是netstat程序的输出行：

Active Internet Connections (including servers)
Proto Recv-Q Send-Q Local-Address        Foreign-Address         State
tcp   0      0      140.252.13.33.23     140.252.13.65.1030      ESTABLISHED
tcp   0      0      140.252.13.33.23     140.252.13.65.1029      ESTABLISHED
tcp   0      0      *.23                 *.*                     LISTEN

• 现在有两条从相同主机到相同服务器的处于ESTABLISHED的连接。它们的本地端口号均为23。由于它们的远端端口号不同，这不会造成冲突。因为 每个telnet客户进程要使用一个外设端口，并且这个外设端口会选择为主机(slip)当前未曾使用的端口，因此它们的端口号肯定不同
• 再次重申TCP使用由本地地址和远端地址组成的4元组：目的IP地址、目的端口号、源IP地址和源端口号来处理传入的多个连接请求。 TCP仅通过目的端口号无法确定那个进程接收了一个连接请求
• 在三个使用端口23的进程中， 只有处于LISTEN的进程能够接收新的连接请求 。处于ESTABLISHED的进程将不能接收SYN报文段，而处于LISTEN的进程将不能接收数据报文段

最后从主机solaris上启动第3个Telnet客户进程，这个主机通过SLIP链路与主机sun相连，而不是以太网接口：

Active Internet Connections (including servers)
Proto Recv-Q Send-Q Local-Address        Foreign-Address         State
tcp   0      0      140.252.1.29.23      140.252.13.65.1031      ESTABLISHED
tcp   0      0      140.252.13.33.23     140.252.13.65.1030      ESTABLISHED
tcp   0      0      140.252.13.33.23     140.252.13.65.1029      ESTABLISHED
tcp   0      0      *.23                 *.*                     LISTEN

• 现在第一个ESTABLISHED连接的本地IP地址对应多地址主机sun中的SLIP链路接口地址(140.252.1.29)

现在来看下当服务器不能任选其本地IP地址而必须使用特定的IP地址时的情况。如果为sock程序指明一个IP地址（或主机名），并将它作为服务器，那么该IP地址就成为处于LISTEN服务器的本地IP地址。例如：

sun$ sock -s 140.252.1.29 8888

使这个服务器程序的连接仅局限于来自SLIP接口(140.252.1.29)。netstat的显示说明了这一点：

Active Internet Connections (including servers)
Proto Recv-Q Send-Q Local-Address           Foreign-Address State
tcp   0      0      140.252.1.29.8888       *.*             LISTEN

如果从主机solaris通过SLIP链路与这个服务器相连接，它将正常工作：

Active Internet Connections (including servers)
Proto Recv-Q Send-Q Local-Address           Foreign-Address       State
tcp   0      0      140.252.1.29.8888       140.252.1.32.34614    ESTABLISHED
tcp   0      0      140.252.1.29.8888       *.*                   LISTEN

但如果试图从以太网(140.252.13)中的主机与这个服务器进行连接，连接请求将被TCP模块拒绝。如果使用tcpdump来观察这一切，对连接请求SYN的响应是一个如图所示的RST：

这个连接请求将不会到达服务器的应用程序，因为它根据应用程序中指定的本地IP地址被 内核中的TCP模块拒绝

UDP服务器通常在指定IP本地地址和本地端口外，还能指定远端IP地址和远端端口。RFC 793中显示的接口函数允许一个服务器在执行被动打开时，可指明远端插口（等待一个特定的客户执行主动打开），也可不指明远端插口（等待任何客户）

遗憾的是，大多数API都不支持这么做。 服务器必须不指明远端插口，而等待连接请求的到来，然后服务器程序自己检查客户端的IP地址和端口号

下表总结了TCP服务器进行连接时三种类型的地址绑定：

• lport: 服务器的熟知端口
• localIP: 必须是一个本地接口的IP地址
• 表中行的顺序正是TCP模块在收到一个连接请求时确定本地地址的顺序：
  • 最常使用的绑定（第1行，如果支持的话）将最先尝试
  • 最不常用的（最后一行两端的IP地址都没有制定）将最后尝试

一个并发服务器调用一个新的进程来处理每个客户请求，因此处于被动连接请求的服务器应该始终准备处理下一个呼入的连接请求。那正是使用并发服务器的根本原因。但仍有可能出现当服务器在创建一个新的进程时，或操作系统正忙于处理优先级更高的进程时，到达多个连接请求。当服务器正处于忙时，TCP是如何处理这些呼入的连接请求？

在伯克利的TCP实现中采用以下规则：

1. 正等待连接请求的一端有一个固定长度的连接队列，该队列中的连接已被TCP接受（即三次握手已经完成），但还没有被应用层所接受
   • TCP接受一个连接是 将其放入这个队列
   • 应用层接受连接是 将其从该队列中移出
2. 应用层将指明该队列的最大长度，这个值通常称为积压值。它的取值范围是 0~5 之间的整数，包括0和5
   • 大多数的应用程序都将这个值说明为5
3. 当一个连接请求（即SYN）到达时，TCP使用一个算法：根据当前连接队列中的连接数来确定是否接收这个连接。我们期望应用层说明的积压值为这一端点所能允许接受连接的最大数目，但情况不是那么简单
   • 积压值：说明的是TCP监听的端点已被TCP接受而 等待应用层接受的最大连接数 。这个积压值 对系统所允许的最大连接数，或者并发服务器所能并发处理的客户数，并无影响
     • Solaris系统：规定的值正如所期望的
     • 传统的BSD系统：将这个值设置为积压值乘3除以2，再加1
4. 如果对于新的连接请求，该TCP监听的端点的连接队列中还有空间，TCP模块将对SYN进行确认并完成连接的建立。但应用层只有在三次握手中的第三个报文段收到后才会知道这个新连接时。 + 当客户进程的主动打开成功但服务器的应用层还不知道这个新的连接时，它可能会认为服务器进程已经准备好接收数据了, 如果发生这种情况，服务器的TCP仅将接收的数据放入缓冲队列
5. 如果对于新的连接请求，连接队列中已没有空间，TCP将不理会收到的SYN。也不发回任何报文段, 即不发回RST
   • 如果应用层不能及时接受已被TCP接受的连接，这些连接可能占满整个连接队列， 客户的主动打开最终将超时

下表显示了积压值与传统的伯克利系统和Solaris2.2所能允许的最大接受连接数之间的关系：