TCP通信

三次握手

进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

第一次握手:建立连接时，客户端发送SYN包((SYN=i)到服务器，并进入SYN SEND状态，等待服务器确认;

第二次握手:服务器收到SYN包，必须确认客户的SYN (ACK=i+1 )，同时自己也发送一个SYN包((SYN j)}即SYN+ACK包，此时服务器进入SYN_RECV状态;

第三次握手:客户端收到服务器的SYN十ACK包，向服务器发送确认包ACK(ACK=j+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手，客户端与服务器开始传送数据。

 如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。 后来收到了确认，建立了连接。 数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端 ，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

 四次挥手

 

• 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。 此时客户端处于FIN_WAIT1 状态。
  即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。FIN_WAIT1
• 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于CLOSE_WAIT 状态。
  即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ACK=u+1，序号SEQ=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。 客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。CLOSE_WAIT
• 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。 此时服务端处于LAST_ACK 的状态。
  即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号SEQ=w，确认号ACK=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
• 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于TIME_WAIT 状态。 需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于CLOSED 状态。
  即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，SEQ=u+1，ACK=w+1），客户端进入TIME_WAIT（时间等待）状态。 此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

 挥手为什么需要四次？

             因为 TCP 不允许连接处于半打开状态时就单向传输数据，所以在三次握手建立连接时，服务器会把 ACK 和 SYN 放在一起发给客户端，其中，ACK 用来打开客户端的发送通道，SYN 用来打开服务器的发送通道。 这样，原本的四次握手就降为三次握手了。

                但是当连接处于半关闭状态时，TCP 是允许单向传输数据的。 为便于理解，我们把先关闭连接的一方叫做主动方，后关闭连接的一方叫做被动方。 当主动方关闭连接时，被动方仍然可以在不调用 close 函数的状态下，长时间发送数据，此时连接处于半关闭状态。 这一特性是 TCP双向通道互相独立所致 的，却也使得关闭连接必须通过四次挥手才能做到。