TCP 学习记录 (摘自tcp/ip卷一)

TCP的 TIME_WAIT 状态

    TCP要求，首先发出 FIN 的一端，在通信双方都完全关闭连接之后，仍然要保持在 TIME_WAIT 状态直至两倍的报文段最大生存时间(MSL)。MSL 的建议值是120秒，也即处于 TIME_WAIT 状态要达到4分钟。当连接处于 TIME_WAIT 状态时，同一连接(即客户I P地址和端口号，以及服务器I P地址和端口号这4个值相同)不能重复打开。T I M E WA I T状态也称为2 M S L等待状态。MSL为2分钟。然而，实现中的常用值是30秒，1分钟，或2分钟。

    客户端首先发出 FIN，这称为主动关闭，因而 TIME_WAIT 状态出现在客户端。在这个状态延续期内， TCP 要为这个已经关闭的连接保留一定的状态信息，以便能正确处理那些在网络中延迟一段时间、在连接关闭之后到达的报文段。同样，如果最后一个 ACK 丢失了，服务器将重传 FIN，使客户端重传最后的 ACK。由于客户进程主动关闭连接(即由客户进程首先发出FIN )，因而在客户收到服务器的 FIN 后还要在 TIME_WAIT 状态滞留大约240秒.

TIME_WAIT状态和16比特TCP端口号这两者结合起来限制了两台主机之间的最大事务速率。例如，如果同一台客户主机要不断地和同一台服务器主机进行事务通信，那么它要么每完成一次事务后等待240秒才开始下一个事务，要么为紧接着的事务选择另外一个端口号。但每240秒的时间内至多只能有64512个端口(65535减去1023个知名端口)可用，从而每秒最多也就只能处理268个事务。在RTT值大约为 1~3ms 的局域网上，实际上可能会超过这个速率.

收到一个 FIN 只意味着在这一方向上没有数据流动。一个 TCP 连接在收到一个 FIN 后仍能发送数据。而这对利用半关闭的应用来说是可能的,首先进行关闭的一方（即发送第一个FIN）将执行主动关闭，而另一方（收到这个FIN ）执行被动关闭。通常一方完成主动关闭而另一方完成被动关闭

TCP的半关闭

TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力

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

客户执行主动关闭并进入 TIME_WAIT 是正常的。服务器通常执行被动关闭，不会进入 TIME_WAIT 状态。这暗示如果我们终止一个客户程序，并立即重新启动这个客户程序，则这个新客户程序将不能重用相同的本地端口。

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

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

检测半打开连接

如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的 TCP 连接称为半打开（Half- Open）的。任何一端的主机异常都可能导致发生这种情况。只要不打算在半打开连接上传输数据，仍处于连接状态的一方就不会检测另一方已经出现异常。由于服务器的 TCP 已经重新启动，它将丢失复位前连接的所有信息，因此它不知道数据报文段中提到的连接。 TCP 的处理原则是接收方以复位作为应答。

同时打开

两个应用程序同时彼此执行主动打开的情况是可能的，尽管发生的可能性极小。每一方必须发送一个SYN，且这些 SYN 必须传递给对方。这需要每一方使用一个对方熟知的端口作为本地端口。这又称为同时打开（ simultaneous open）TCP是特意设计为了可以处理同时打开，对于同时打开它仅建立一条连接而不是两条连接（其他的协议族，最突出的是 OSI 运输层，在这种情况下将建立两条连接而不是一条连接）

异常终止一个连接

异常终止一个连接对应用程序来说有两个优点：（1）丢弃任何待发数据并立即发送复位报文段；（2）RST 的接收方会区分另一端执行的是异常关闭还是正常关闭。应用程序使用的 API 必须提供产生异常关闭而不是正常关闭的手段。

产生复位的一种常见情况是当连接请求到达时，目的端口没有进程正在听。

同时关闭

当应用层发出关闭命令时，两端均从 ESTABLISHED 变为 FIN_WAIT_1。这将导致双方各发送一个 FIN，两个 FIN 经过网络传送后分别到达另一端。收到 FIN 后，状态由 FIN_WAIT_1 变迁到 CLOSING，并发送最后的A C K。当收到最后的 ACK 时，状态变化为TIME_WAIT。

TCP服务器端口号

TCP使用由本地地址和远端地址组成的4元组：目的IP地址、目的端口号、源IP地址和源端口号来处理传入的多个连接请求。TCP仅通过目的端口号无法确定那个进程接收了一个连接请求。另外，在三个使用端口23的进程中，只有处于 LISTEN 的进程能够接收新的连接请求。处于 ESTABLISHED 的进程将不能接收 SYN 报文段，而处于 LISTEN 的进程将不能接收数据报文段。

一个TCP连接由一个4元组唯一确定：本地IP地址、本地端口号、远端IP地址和远端端口号。

呼入连接请求队列

1) 一个并发服务器调用一个新的进程来处理每个客户请求，因此处于被动连接请求的服务器应该始终准备处理下一个呼入的连接请求。那正是使用并发服务器的根本原因。但仍有可能出现当服务器在创建一个新的进程时，或操作系统正忙于处理优先级更高的进程时，到达多个连接请求。当服务器正处于忙时， TCP是如何处理这些呼入的连接请求？正等待连接请求的一端有一个固定长度的连接队列，该队列中的连接已被 TCP 接受（即三次握手已经完成），但还没有被应用层所接受。注意区分 TCP 接受一个连接是将其放入这个队列，而应用层接受连接是将其从该队列中移出。

2) 应用层将指明该队列的最大长度，这个值通常称为积压值( backlog )。它的取值范围是0-5之间的整数，包括0和5（大多数的应用程序都将这个值设置为5），当一个连接请求（即SYN）到达时，TCP 使用一个算法，根据当前连接队列中的连接数来确定是否接收这个连接。我们期望应用层说明的积压值为这一端点所能允许接受连接的最大数目，但情况不是那么简单，注意：积压值说明的是TCP 监听的端点已被TCP 接受而等待应用层接受的最大连接数。这个积压值对系统所允许的最大连接数，或者并发服务器所能并发处理的客户数，并无影响。

3) 如果对于新的连接请求，该TCP监听的端点的连接队列中还有空间，TCP模块将对 SYN 进行确认并完成连接的建立。但应用层只有在三次握手中的第三个报文段收到后才会知道这个新连接时。另外，当客户进程的主动打开成功但服务器的应用层还不知道这个新的连接时，它可能会认为服务器进程已经准备好接收数据了（如果发生这种情况，服务器的TCP仅将接收的数据放入缓冲队列)。

4) 如果对于新的连接请求，连接队列中已没有空间， TCP将不理会收到的SYN。也不发回任何报文段（即不发回RST）。如果应用层不能及时接受已被TCP接受的连接，这些连接可能占满整个连接队列，客户的主动打开最终将超时。

期望接收连接队列按先进先出顺序传递给应用层。如TCP接受了端口为1090和1091的连接，我们希望应用层先接受端口为1090的连接，然后再接受端口为1091的连接。但许多伯克利的TCP实现都出现按后进先出的传递顺序，这个错误已存在了多年。当队列已满时，TCP将不理会传入的SYN，也不发回RST作为应答，因为这是一个软错误，而不是一个硬错误。通常队列已满是由于应用程序或操作系统忙造成的，这样可防止应用程序对传入的连接进行服务。这个条件在一个很短的时间内可以改变。但如果服务器的TCP以系统复位作为响应，客户进程的主动打开将被废弃（如果服务器程序没有启动我们就会遇到）。由于不应答SYN，服务器程序迫使客户TCP随后重传SYN，以等待连接队列有空间接受新的连接。

这种行为也意味着TCP服务器无法使客户进程的主动打开失效。当一个新的客户连接传递给服务器的应用程序时， TCP的三次握手就结束了，客户的主动打开已经完全成功。如果服务器的应用程序此时看到客户的I P地址和端口号，并决定是否为该客户进行服务，服务器所能做的就是关闭连接（发送 FIN），或者复位连接（发送 RST）。无论哪种情况，客户进程都认为一切正常，因为它的主动打开已经完成，并且已经向服务器程序发送过请求。