TCP建立连接和拆除连接的过程

1、TCP报文格式

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/77/11/wKiom1ZiSO7DKJh_AAClFg1mtgc653.png" title="360反馈意见截图16370622317666.png" alt="wKiom1ZiSO7DKJh_AAClFg1mtgc653.png" />

2、TCP连接建立时三次握手的过程

图示

650) this.width=650;" src="http://s1.51cto.com/wyfs02/M02/77/0F/wKioL1ZiScKhzYWuAACiOk6YXbI677.png" title="360反馈意见截图16470417200242.png" alt="wKioL1ZiScKhzYWuAACiOk6YXbI677.png" />

1. 文字说明

   1. 第一次握手：建立连接时，客户端发送syn包(seq=x)到服务器，并进入SYN_SEND状态，等待服务器确认；

   2. 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（seq=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

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

   4. 完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：

2. TCP的弱点

   1. TCP 连接的资源消耗，其中包括：数据包信息、条件状态、序列号等

   2. 通过故意不完成建立连接所需要的三次握手过程，造成连接一方的资源耗尽

   3. 序列号的可预测性，目标主机应答连接请求时返回的SYN/ACK 的序列号是可预测的

   4. TCP 会话劫持和SYN FLOOD（同步洪流）就是根据TCP的这个弱点出现的一种网络攻击方式

• 
  

• TCP三次握手过程中用到的一些数据结构和参数

  • 未连接队列：在 三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN 包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器 进入ESTABLISHED状态。

  • Backlog参数：表示未连接队列的最大容纳数目。

  • SYN-ACK 重传次数：服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。

  • 半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。　　

  • SYN（同步标志）：该标志置上的时候，同 步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户 端)的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字 节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。　

  • ACK（确认标志）：该标志置上的时候，确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。　　

  • RST（复位标志）：该标志置上的时候，用于复位相应的TCP连接。　　

  • URG（紧急标志）：该标志置上的时候，表示紧急(The urgent pointer) 标志有效。

  • PSH（推标志）：该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。　　

  • FIN（结束标志）：带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据。

• 
  

• TCP三次握手的一些中间状态

• SYN_SENT：客户端发送syn数据包向服务器端申请建立TCP连接，此时客户端的状态为SYN_SENT

• SYN_RCVD：接收方收到请求，给发起方发送一个设置了SYN与ACK标志位的TCP数据包做为应答，另外设置一个比客户机发送来的ISN大1个单位的ISN值，这常被称为SYN_ACK数据包或SYN_ACK报文这时连接的状态称做SYN_RCVD

• ESTABLISHED：发起方然后发送一个带有ACK应答和增1后的ISN标志来确认SYN_ACK至此，完成了三次握手，此时的连接状态为连结成功: ESTABLISHED

• 
  

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

650) this.width=650;" src="http://s5.51cto.com/wyfs02/M01/77/10/wKioL1ZiS96igHuWAACYjYv-31k739.png" title="360反馈意见截图162709077610682.png" alt="wKioL1ZiS96igHuWAACYjYv-31k739.png" />

关闭过程

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

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

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

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

• 客户段发回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状态下，需要完成的事情是等待你去关闭连接。

• LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。
  最后有2个问题的回答，我自己分析后的结论（不一定保证100%正确）

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

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