TCP的三次握手(建立连接）和四次挥手(关闭连接）

以你之姓@ 2022-08-07 01:30 161阅读 0赞

[TCP的三次握手(建立连接）和四次挥手(关闭连接）][TCP]

参照：

http://course.ccniit.com/CSTD/Linux/reference/files/018.PDF

http://hi.baidu.com/raycomer/item/944d23d9b502d13be3108f61

[http://blog.csdn.net/risingsun001/article/details/44453685?ref=myread][http_blog.csdn.net_risingsun001_article_details_44453685_ref_myread]

# [wireshark抓包图解 TCP三次握手/四次挥手详解][wireshark_ TCP] #

**建立连接：**

理解：窗口和滑动窗口
    TCP的流量控制

TCP使用窗口机制进行流量控制

什么是窗口？

连接建立时，各端分配一块缓冲区用来存储接收的数据，并将缓冲区的尺寸发送给另一端

接收方发送的确认信息中包含了自己剩余的缓冲区尺寸

**剩余缓冲区空间的数量叫做窗口**

**2. TCP的流控过程（滑动窗口）**

**![081517071882901.png][]**

**TCP(Transmission Control Protocol)　传输控制协议**

**三次握手**

TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:

位码即tcp标志位,有6种标示:

SYN(synchronous建立联机)

ACK(acknowledgement 确认)

PSH(push传送)

FIN(finish结束)

RST(reset重置)

URG(urgent紧急)

Sequence number(顺序号码)

Acknowledge number(确认号码)

序号：32bit的序列号，由发送方使用

**客户端TCP状态迁移：**  
CLOSED->SYN\_SENT->ESTABLISHED->FIN\_WAIT\_1->FIN\_WAIT\_2->TIME\_WAIT->CLOSED  
服务器TCP状态迁移：  
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE\_WAIT->LAST\_ACK->CLOSED

![181351206012825.png][]

**各个状态的意义如下：**   
LISTEN - 侦听来自远方TCP端口的连接请求；   
SYN-SENT -在发送连接请求后等待匹配的连接请求；   
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；   
ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；   
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；  
FIN-WAIT-2 - 从远程TCP等待连接中断请求；   
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；   
CLOSING -等待远程TCP对连接中断的确认；   
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；   
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；   
CLOSED - 没有任何连接状态；

TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接，如图1所示。

（1）第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN\_SEND状态，等待服务器B确认。

（2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器B进入SYN\_RECV状态。

（3）第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK（ACK=k+1），此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据。

**确认号：其数值等于发送方的发送序号 \+1(即接收方期望接收的下一个序列号)。**

** 比如下面：第一次握手：主机A是发送方，它发送的序列号是200，主机B是接收方，收到之后发送确认号201，就是说B要A发送序列号201的数据。**

**所以第二次握手的时候ACK=201**

**第二次握手：主机B是发送方，它发送的序列号是500，主机A是接收方，收到之后发送确认号501，就是说A要B发送序列号501的数据。**

**所以第三次握手的时候ACK=501，主机A的发送序号是201，满足B第二次握手的请求。**

![TCPConnect.JPG][]

图1 TCP三次握手建立连接  ![291246111727359.png][]

**TCP的包头结构：**  
源端口 16位  
目标端口 16位  
序列号 32位  
回应序号 32位  
TCP头长度 4位  
reserved 6位  
控制代码 6位  
窗口大小 16位  
偏移量 16位  
校验和 16位  
选项  32位(可选)  
这样我们得出了TCP包头的最小长度，为20字节

**TCP三次握手**

所谓三次握手(Three-way Handshake)，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。

三次握手的目的是连接服务器指定端口，建立TCP连接,并同步连接双方的序列号和确认号并交换 TCP 窗口大小信息.在socket [编程][Link 1]中，客户端执行connect()时。将触发三次握手。

![20120821111651299.png][]

第一次握手:

客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口，以及初始序号X,保存在包头的序列号(Sequence Number)字段里。  www.2cto.com

![20120821111652779.png][]

第二次握手:

服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即X+1。

![20120821111653862.png][]

第三次握手.

客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1

![20120821111654806.png][]

SYN攻击

在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn\_RECV状态.当收到ACK后，服务器转入ESTABLISHED状态.

Syn攻击就是 攻击客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直 至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标 [系统][Link 2]运行缓慢，严重者引起网络堵塞甚至系统瘫痪。

Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.在 [Linux][]下可以如下命令检测是否被Syn攻击

netstat -n -p TCP | grep SYN\_RECV

一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.

但是不能完全防范syn攻击。  www.2cto.com

TCP 四次挥手

TCP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。

![20120821111655977.jpg][]

参见wireshark抓包，实测的抓包结果并没有严格按挥手时序。我估计是时间间隔太短造成。

![20120821111659976.png][]

1、建立连接协议（三次握手）

（1）客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。

（2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。

（3） 客户必须再次回应服务段一个ACK报文，这是报文段3。

2、连接终止协议（四次挥手）

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。

（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。  www.2cto.com

（3） 服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。

（4） 客户段发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。

CLOSED: 这个没什么好说的了，表示初始状态。

LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。

SYN\_RCVD: 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。

SYN\_SENT: 这个状态与SYN\_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN\_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN\_SENT状态表示客户端已发送SYN报文。

ESTABLISHED：这个容易理解了，表示连接已经建立了。

FIN\_WAIT\_1: 这个状态要好好解释一下，其实FIN\_WAIT\_1和FIN\_WAIT\_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN\_WAIT\_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN\_WAIT\_1状态。而当对方回应ACK报文后，则进入到FIN\_WAIT\_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN\_WAIT\_1状态一般是比较难见到的，而FIN\_WAIT\_2状态还有时常常可以用netstat看到。

FIN\_WAIT\_2：上面已经详细解释了这种状态，实际上FIN\_WAIT\_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。

TIME\_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN\_WAIT\_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME\_WAIT状态，而无须经过FIN\_WAIT\_2状态。

CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。

CLOSE\_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE\_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE\_WAIT状态下，需要完成的事情是等待你去关闭连接。  www.2cto.com

LAST\_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。

最后有2个问题的回答，我自己分析后的结论（不一定保证100%正确）

1、 为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

2、 为什么TIME\_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

这是因为：虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN\_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST\_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME\_WAIT状态的作用就是用来重发可能丢失的ACK报文。

下面是具体的例子截图：

1.此图包含两部分信息：TCP的三次握手(方框中的内容） （SYN, (SYN+ACK), ACK)

2. TCP的数据传输 （\[TCP segment of a reassembled PUD\])可以看出，server是将数据TCP层对消息包进行分片传输

(1)Server端收到HTTP请求如GET之后，构造响应消息，其中携带网页内容，在server端的HTTP层发送消息200 OK->server端的TCP层；   
(2)server端的TCP层对消息包进行分片传输；   
(3)client端的TCP层对接收到的各个消息包分片回送响应；   
(4)client端的TCP层每次收到一部分都会用ACK确认，之后server继续传输，client继续确认，直到完成响应消息的所有分片之后，Server **发送组合HTTP响应包 200 O**K，此时在client端的消息跟踪中才可以显示 **HTTP 200 OK**的消息包

![021812235945327.jpg][]

**关闭连接：**

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

CP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。

（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。

（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。

（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A。

（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。

TCP采用四次挥手关闭连接如图2所示。

![281600391879667.png][]

图2  TCP四次挥手关闭连接

参见wireshark抓包，实测的抓包结果并没有严格按挥手时序。我估计是时间间隔太短造成。

![100327023334.png][]

**深入理解TCP连接的释放：**

**由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。  
TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。   
简单说来是 “先关读，后关写”，一共需要四个阶段。以客户机发起关闭连接为例：  
1.服务器读通道关闭  
2.客户机写通道关闭  
3.客户机读通道关闭  
4.服务器写通道关闭  
关闭行为是在发起方数据发送完毕之后，给对方发出一个FIN（finish）数据段。直到接收到对方发送的FIN，且对方收到了接收确认ACK之后，双方的数据通信完全结束，过程中每次接收都需要返回确认数据段ACK。  
详细过程：  
    第一阶段   客户机发送完数据之后，向服务器发送一个FIN数据段，序列号为i；  
    1.服务器收到FIN(i)后，返回确认段ACK，序列号为i+1，关闭服务器读通道；  
    2.客户机收到ACK(i+1)后，关闭客户机写通道；  
   （此时，客户机仍能通过读通道读取服务器的数据，服务器仍能通过写通道写数据）  
    第二阶段 服务器发送完数据之后，向客户机发送一个FIN数据段，序列号为j；  
    3.客户机收到FIN(j)后，返回确认段ACK，序列号为j+1，关闭客户机读通道；  
    4.服务器收到ACK(j+1)后，关闭服务器写通道。  
这是标准的TCP关闭两个阶段，服务器和客户机都可以发起关闭，完全对称。  
FIN标识是通过发送最后一块数据时设置的，标准的例子中，服务器还在发送数据，所以要等到发送完的时候，设置FIN（此时可称为TCP连接处于半关闭状态，因为数据仍可从被动关闭一方向主动关闭方传送）。如果在服务器收到FIN(i)时，已经没有数据需要发送，可以在返回ACK(i+1)的时候就设置FIN(j)标识，这样就相当于可以合并第二步和第三步。读《Linux网络编程》关闭TCP连接章节，作以下笔记：**

# TCP的TIME\_WAIT和Close\_Wait状态 #

** **

面试时看到应聘者简历中写精通网络，TCP编程，我常问一个问题，TCP建立连接需要几次握手？95%以上的应聘者都能答对是3次。问TCP断开连接需要几次握手，70%的应聘者能答对是4次通讯。再问CLOSE\_WAIT，TIME\_WAIT是什么状态，怎么产生的，对服务有什么影响，如何消除？有一部分同学就回答不上来。不是我扣细节，而是在通讯为主的前端服务器上，必须有能力处理各种TCP状态。比如统计在本厂的一台前端机上高峰时间TCP连接的情况，统计命令：

1.  netstat -n | awk '/^tcp/ \{++S\[$NF\]\} END \{for(a in S) print a, S\[a\]\}'

结果：

![84326b90-3259-337a-84c9-1051ac366772.jpg][]

除了ESTABLISHED，可以看到连接数比较多的几个状态是：FIN\_WAIT1, TIME\_WAIT, CLOSE\_WAIT, SYN\_RECV和LAST\_ACK；下面的文章就这几个状态的产生条件、对系统的影响以及处理方式进行简单描述。

## TCP状态 ##

TCP状态如下图所示：  
![点击查看原始大小图片][bdf8d214-c8de-3b2a-8a53-219a0dce3259.png]

可能有点眼花缭乱？再看看这个时序图

![5d4e8c89-fc42-3862-bdb8-399bc982f410.png][]

下面看下大家一般比较关心的三种TCP状态

## SYN\_RECV  ##

服务端收到建立连接的SYN没有收到ACK包的时候处在SYN\_RECV状态。有两个相关系统配置：

### 1，net.ipv4.tcp\_synack\_retries ：INTEGER ###

默认值是5

对于远端的连接请求SYN，内核会发送SYN ＋ ACK数据报，以确认收到上一个 SYN连接请求包。这是所谓的三次握手( threeway handshake)机制的第二个步骤。这里决定内核在放弃连接之前所送出的 SYN+ACK 数目。不应该大于255，默认值是5，对应于180秒左右时间。通常我们不对这个值进行修改，因为我们希望TCP连接不要因为偶尔的丢包而无法建立。

### 2，net.ipv4.tcp\_syncookies ###

一般服务器都会设置net.ipv4.tcp\_syncookies=1来防止SYN Flood攻击。假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）。

这些处在SYNC\_RECV的TCP连接称为半连接，并存储在内核的半连接队列中，在内核收到对端发送的ack包时会查找半连接队列，并将符合的requst\_sock信息存储到完成三次握手的连接的队列中，然后删除此半连接。大量SYNC\_RECV的TCP连接会导致半连接队列溢出，这样后续的连接建立请求会被内核直接丢弃，这就是SYN Flood攻击。

能够有效防范SYN Flood攻击的手段之一，就是SYN Cookie。SYN Cookie原理由D. J. Bernstain和 Eric Schenk发明。SYN Cookie是对TCP服务器端的三次握手协议作一些修改，专门用来防范SYN Flood攻击的一种手段。它的原理是，在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时，TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性。如果合法，再分配专门的数据区进行处理未来的TCP连接。

观测服务上SYN\_RECV连接个数为：7314，对于一个高并发连接的通讯服务器，这个数字比较正常。

## CLOSE\_WAIT ##

发起TCP连接关闭的一方称为client，被动关闭的一方称为server。被动关闭的server收到FIN后，但未发出ACK的TCP状态是CLOSE\_WAIT。出现这种状况一般都是由于server端代码的问题，如果你的服务器上出现大量CLOSE\_WAIT，应该要考虑检查代码。

## TIME\_WAIT ##

根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME\_WAIT状态。TIME\_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟，即240秒。TIME\_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接，将导致服务器端存在大量的处于TIME\_WAIT状态的socket， 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力，甚至耗尽可用的socket，停止服务。

为什么需要TIME\_WAIT？TIME\_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证。

和TIME\_WAIT状态有关的系统参数有一般由3个，本厂设置如下：

net.ipv4.tcp\_tw\_recycle = 1

net.ipv4.tcp\_tw\_reuse = 1

net.ipv4.tcp\_fin\_timeout = 30

net.ipv4.tcp\_fin\_timeout，默认60s，减小fin\_timeout，减少TIME\_WAIT连接数量。

net.ipv4.tcp\_tw\_reuse = 1表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp\_tw\_recycle = 1表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

为了方便描述，我给这个TCP连接的一端起名为Client，给另外一端起名为Server。上图描述的是Client主动关闭的过程，FTP协议中就这样的。如果要描述Server主动关闭的过程，只要交换描述过程中的Server和Client就可以了，HTTP协议就是这样的。

描述过程：  
Client调用close()函数，给Server发送FIN，请求关闭连接；Server收到FIN之后给Client返回确认ACK，同时关闭读通道（不清楚就去看一下shutdown和close的差别），也就是说现在不能再从这个连接上读取东西，现在read返回0。此时Server的TCP状态转化为CLOSE\_WAIT状态。  
Client收到对自己的FIN确认后，关闭 写通道，不再向连接中写入任何数据。  
接下来Server调用close()来关闭连接，给Client发送FIN，Client收到后给Server回复ACK确认，同时Client关闭读通道，进入TIME\_WAIT状态。  
Server接收到Client对自己的FIN的确认ACK，关闭写通道，TCP连接转化为CLOSED，也就是关闭连接。  
Client在TIME\_WAIT状态下要等待最大数据段生存期的两倍，然后才进入CLOSED状态，TCP协议关闭连接过程彻底结束。

以上就是TCP协议关闭连接的过程，现在说一下TIME\_WAIT状态。  
从上面可以看到，主动发起关闭连接的操作的一方将达到TIME\_WAIT状态，而且这个状态要保持Maximum Segment Lifetime的两倍时间。为什么要这样做而不是直接进入CLOSED状态？

原因有二：  
一、保证TCP协议的全双工连接能够可靠关闭  
二、保证这次连接的重复数据段从网络中消失

先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME\_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME\_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

各种协议都是前人千锤百炼后得到的标准，规范。从细节中都能感受到精巧和严谨。每次深入都有同一个感觉，精妙。

做个快乐的自己。

[TCP]: http://www.cnblogs.com/Jessy/p/3535612.html
[http_blog.csdn.net_risingsun001_article_details_44453685_ref_myread]: http://blog.csdn.net/risingsun001/article/details/44453685?ref=myread
[wireshark_ TCP]: http://blog.csdn.net/risingsun001/article/details/44453685
[081517071882901.png]: /images/20220805/6fb77b73206a46a184b2726bb905daf1.png
[181351206012825.png]: /images/20220805/e972b9c655834d2ba3ca2d8c7e130315.png
[TCPConnect.JPG]: /images/20220805/39cf6b6a50c14d7c9f610dbb1eda8476.png
[291246111727359.png]: /images/20220805/f07ac31229bd45c5b09819ebd4f439e0.png
[Link 1]: http://www.2cto.com/kf
[20120821111651299.png]: http://up.2cto.com/2012/0821/20120821111651299.png
[20120821111652779.png]: http://up.2cto.com/2012/0821/20120821111652779.png
[20120821111653862.png]: http://up.2cto.com/2012/0821/20120821111653862.png
[20120821111654806.png]: http://up.2cto.com/2012/0821/20120821111654806.png
[Link 2]: http://www.2cto.com/os/
[Linux]: http://www.2cto.com/os/linux/
[20120821111655977.jpg]: http://up.2cto.com/2012/0821/20120821111655977.jpg
[20120821111659976.png]: http://up.2cto.com/2012/0821/20120821111659976.png
[021812235945327.jpg]: /images/20220805/9d680684b56647c7b9ad0bafef39ebb6.png
[281600391879667.png]: /images/20220805/8c42d4a924134c968d8b62a5d14b1015.png
[100327023334.png]: http://blogimg.chinaunix.net/blog/upfile2/100327023334.png
[84326b90-3259-337a-84c9-1051ac366772.jpg]: /images/20220805/af776bbea3914590b5846148360001ed.png
[bdf8d214-c8de-3b2a-8a53-219a0dce3259.png]: /images/20220805/d90837c777a6408d970ab6955a93ebdb.png
[5d4e8c89-fc42-3862-bdb8-399bc982f410.png]: /images/20220805/a9b40546d7544337ac8611d1401b7ad0.png