TCP建立连接三次握手，四次挥手

注意：
（A）不要将确认序号Ack与标志位中的ACK搞混了。
（B）确认方Ack=发起方Req+1，两端配对。

1. “三次握手”

• 第一次握手(SYN)：客户端发送一个 TCP 的 SYN 包
  发送完毕后，客户端进入 SYN_SEND 状态。

• 第二次握手(SYN + ACK)：服务器发回确认包(ACK)应答
  发送完毕后，服务器端进入 SYN_RCVD 状态。

• 第三次握手(ACK)：客户端再次发送确认包(ACK)
  发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。

为什么需要三次握手而不是二次握手呢？

网络信道是不可靠的，可能会出现丢包等问题，如果客户端发送了一个SYN包，但此时这个包因为某些原因，导致没有到达服务端，在某个网络节点产生了滞留，然后客户端会重新发送一个SYN包，然后服务端收到以后回复SYN+ACK包，建立连接。此时第一次发送的SYN包又到达服务端，此时经历二次握手以后，服务端认为建立了两个TCP连接，客户端是一个连接，造成状态不一致问题。

丢包和乱序问题（发送端和接收端均可能为服务器或客户端，因为TCP是全双工）

TCP为每一个TCP连接都建立了发送缓冲区，从建立连接后的第一个字节序列号为0，依次递增，发送报文的时候，发送端会将数据内容（序列号+长度）一起发送过去，接收端接受到请求响应时发送的ACK包是请求序列号+长度（下一包数据发送的起始序列号）
如果发生丢包情况，那么接收端要求发送端重新发送某个起始序号+长度的包

2. “四次挥手”

• 第一次挥手(FIN)：假设客户端想要关闭连接，客户端发送一个 FIN 包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。
  发送完毕后，客户端进入 FIN_WAIT_1 状态。

• 第二次挥手(ACK)：服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。
  发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。

• 第三次挥手(FIN)：服务器端准备好关闭连接时，向客户端发送结束连接请求，发送FIN包。
  发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。

• 第四次挥手(ACK)：客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。
  服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。
  客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。

为什么连接的时候是“三次握手”，关闭的时候却是“四次握手”？

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

为什么客户端在第四次挥手后还会等待 2MSL？

等待 2MSL 是因为保证服务端接收到了 ACK 报文，因为网络是复杂了，很有可能 ACK 报文丢失了，如果服务端没接收到 ACK 报文的话，会重新发送 FIN 报文，只有当客户端等待了 2MSL 都没有收到重发的 FIN 报文时就表示服务端是正常收到了 ACK 报文，那么这个时候客户端就可以关闭了。

为什么客户端需要等待超时时间？

保证服务端确定收到了ACK包。万一ACK包丢失之后，服务器就一直处于滞留状态，如果服务端没有收到来自客户端的ACK包，那么服务端会重新发送ACK包，重新刷新超时时间。