为了防止这种情况，RFC793提出TCP在重启后的MSL秒内不能建立任何连接，这就是平静等待时间(quiet time)。
只有极少的实现版准遵守这一原则，因为大多数主机重启时间的时间都比MSL秒要长。
5.3 FIN_WAIT_2状态
主动关闭方已经发出了FIN，并且被动关闭方也已对它进行ACK确认，那么主动方进入FIN_WAIT_2状态。只有当被动方的进程完成这个关闭（发出FIN包），主动方才从FIN_WAIT_2进入TIME_WATI状态。
这意味着主动和被动方分别永远保持FIN_WAIT_2和CLOSE_WAIT状态，并一直保持这个状态直到应用层决定进行关闭。（许多伯克利实现采用以下方法来防止这种FIN_WAIT_2状态的无限等待，如果执行主动关闭的应用层将进行全关闭，而不是半关闭，表示它不想接收数据，就设置一个定时器，如果这个连接空闲超过10分钟75秒，那么TCP将进入CLOSED状态）
6.复位报文段
连接不存在的端口：
一般来说，无论何时一个报文段发往基准的连接出现错误，TCP都会发出一个复位报文段。产生复位的一种常见情况是当连接请求到达时，，目的端口没有进程正在监听，例如当一个数据报达到目的端口时，该端口没在使用，它将产生一个端口不可达的信息，而TCP则使用复位。
异常终止一个连接：
终止连接有2个方式，其中一个是正常方式：一方发送FIN，也称为有序释放，正常情况下没有任何数据丢失。但也有可能发送一个复位报文段而不是FIN来中途释放一个连接，称为异常释放。
异常终止一个连接对应用程序来说有2个优点：
1）丢弃任何待发数据并立即发送复位报文段
2）RST的接收方会区分另一端执行的是异常关闭还是正常关闭。
需要注意的是RST报文段不会导致另一端产生任何响应，另一端根本不进行确认。收到RST的一方将终止连接，并通知应用层连接复位。
检测半打开连接：
如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的TCP连接称为半打开的（Half-Open）。任何一端的主机异常都可能导致发生这种情况。只要不打算在半打开连接上传输数据，仍处于连接状态的一方就不会检测另一方已经出现异常。
半打开连接的另一个常见原因是当客户主机突然掉电而不是正常的结束客户应用程序后再关机。此时如果服务器又重新启动，它将丢失复位前连接的所有信息，因此它不知道数据报文段中提到的连接。此时TCP处理的原则是接收方以复位作为应答。
7.同时打开
两个应用程序同时彼此执行主动打开的情况是可能的，TCP特意设计可以处理同时打开，对于同时打开它仅建立一条连接而不是两条连接。
同时打开时，两端几乎同时发送SYN，并进入SYN_SENT状态。当每一端收到SYN时，状态变为SYN_RCVD，同时它们都再发SYN并对收到的SYN进行确认。当双方都收到SYN相应的ACK时，状态都变迁为ESTABLISH。
一个同时打开的连接需要交换4个报文段，比正常的三次握手多1个，如下图所示：
7.同时打开
双方同时执行主动关闭是可能的，TCP协议也允许这样的同时关闭。
当应用层发出关闭命令时，两端均从ESTABLISH变为FIN_WAIT1，这将导致双方各发送一个FIN，两个FIN经过网络传送后分别到达另一端。收到FIN后，状态由FIN_WAIT1变迁到CLOSING，并发达最后的ACK，状态变化为TIME_WAIT。
同时关闭与正常关闭使用的段交换数据相同。
8.TCP服务器的设计
8.1 TCP服务器端口号:
TCP服务器对于每一个连接都需要建立一个独立的进程（或者是轻量级的，线程），来保证对话的独立性。所以TCP服务器是并发的。
当一个服务器进程接受一个来自客户端的请求时是如何处理端口的？如果多个连接请求几乎同时到达会发生什么情况？
1）首先使用neststat -a -n可以查看网络中的所有主机端，假定端口号23为监听端口，在没有任何请求连接时输入命令可以看到23端口处于LISTEN监听状态。（Foreign Address为*.*表示还不知道远端IP地址和端口号，因为该端还处于LISTEN状态，正等待连接请求的到达）
告诉自己，我这次失败了，重新开始吧!下次我会吸取教训，不让自己犯同样的错误的
