tcp的连接以及断开

三次握手：
1.客户端会发送一个SYN同步标志和seq序列号为x的请求报文段给服务端（状态处于SYN_SENT）；
2.服务端接收到客户端的SYN请求报文段之后会发送给客户端一个（SYN = 1， ACK = 1， Seq = y， Ack = x+1）请求加上确认数据报段（状态处于SYN_RECD）；
3.客户端接收到服务端返回过来的请求数据报文段之后，会回复一个（ACK = 1， seq = x+1， ack = y+1）(状态处于已连接状态)；
4.服务端接收到客户端发送过来的确认报文段后（状态变为已连接状态），双方连接成功；

疑问：
1.三次握手变成两次握手可以吗？
影响就是：服务器会处于忙等状态，浪费资源。
客户端发送SYN包A1，由于网络链路的问题，导致A1到达的时间滞后，因为客户端迟迟收不到服务端发送过来的响应就会重新发送一个B1，并且清理掉A1，结果B1的请求连接成功，之后A1的请求成功送达到了服务端，此时服务就会以为是另外的一个请求连接，然后成功的返回，并变成连接成功的状态，但是客户端已经建立了一个连接的请求，就会把A1的响应丢弃掉，这样的话，就会维护一个服务端的僵尸连接。（简单点说就是防止已经失效的连接请求报文段发送到服务器，导致服务器维持一个僵尸连接）

2.三次握手变成四次握手可以吗
主要的为了提高传输的效率，合并了（客户端同步请求的确认以及服务端同步请求）；

3.三次握手过程中还有其他的作用吗？
(1)在双方的请求报文段中的头部都会加入各自随机的随机序列号
(2)接收窗口的窗口缩放系数；
(3)MSS(最大报文段长度)；
(4)是否支持SACK(选择性确认);

4.第三次握手失败了，会怎么处理？
此时服务端的状态为SYN-RCVD，如果等不到客户端发过来的ACK确认，服务端就会重新发送一个SYN和ACK给客户端，如果服务端发重发了好几个SYN+ACK给客户端，都没接收到客户端返回过来的ACK，就会发送RST包，强制关闭连接。

四次挥手：
1.客户端会发送一个FIN断开连接标志的请求报文段给服务端（客户端处于终止等待1）；
2.服务端收到了客服端发过来的FIN之后，发送一个ACK报文给客户端（服务端处于关闭等待），客户端接收到服务端的ACk之后（客户端处于终止等待2）；
3.服务端发送一个FIN断开连接标志的请求报文段给客户端（服务端处于最后确认）；
4.客户端接收到服务端的FIN报文段之后，发送ACK报文段给服务端（客户端处于时间等待）；
5.服务端接收到ACK报文段之后（服务端处于关闭）；
6.客户端在进过2MSL（Maximum Segment Lifetime）之后（客户端处于关闭）；

疑问
1.为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
网络是不可靠的，当服务端发送给客户端的FIN之后一直得不到ACK的返回，就会重新发送一个FIN报文段，这个时间差最大值就是2MSL，这样的确保服务端能接收到客户端发送给服务端的ACK报文段，然后客户端和服务端就会处于关闭状态。

2.为什么释放连接需要四次挥手？
tcp是全双工模式，前两次挥手表示的是一方没有数据发送和另外一方的确认， 后两次挥手就是另外一方没有数据发送和一方的确认。这是一个双方的断开行为。