tcp的三次握手和四次挥手

tcp可以说是面试常问考点，这不周六面试又栽了一次。其实常问考点就这么几个，整理一下，好记性不如烂笔头。
先上张图，这张图真是生动形象啊

tcp万能图

1.tcp的三次握手
tcp的三次握手发生在客户端和服务端建立连接的时候
在建立连接的时候会发送两个信息1)SYN(synchronize的缩写) 2)ACK(acknowledge的缩写)
第一次握手
当客户端需要和服务端建立连接的时候，客户端会向客户端发送一个SYN，假设为x。此时客户端的状态为syn_sent
第二次握手
服务端收到客户端的请求以后，会响应客户端，同时发送一个SYN,假设值为y，ACK的值为客户端发送SYN的值上加1，即x+1表示你的请求我已经收到了。此时服务端的状态为syn_reciver
第三次
客户端向服务端发送ACK，其值为服务端SYN的值加1，即y+1，表示我已经收到服务端的信息
三次握手每次握手的内容都不一样，只有服务端会一次性传递ACK，SYN两个信息，客户端分次传递ACK，SYN。三次握手保证了可靠传输，比如A，B两个人，A向B发消息，A说我上线了，B回消息，我也在线，A继续向B发消息，我知道你在线了。如果只有两次握手，那么B不知道A已经收到消息了，四次握手就有点多余了。
和某同学聊天经常三次握手失败

真让人生气

2.tcp的四次握手
四次握手发生在客户端和服务端释放连接的时候，可以是客户端发起请求，也可以是服务端发起请求。这里我们用A端向B端发起释放连接讲解tcp四次挥手
第一次挥手
A端向B端发送一个FIN(finish的缩写)报文
第二次挥手
B端收到A端发送来的一个释放连接请求(FIN)，此时可能数据据传输并没有结束，不能马上释放连接，因此B端先发送一个ACK，告诉A端刚刚发送来的请求我已经收到了
第三次挥手
B端将数据传输结束后，向A端发送一个SYN，告诉A端数据传输完毕，可以释放连接了
第四次挥手
A端收到B端发送来的SYN会向B端发送一个ACK，告诉B端的请求我已经收到，并在两个MSL时长后断开连接

3.为什么不是两次握手
在《计算机网络》中是这样解释的：已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK。这样就会白白浪费资源。
而经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。

4.为什么四次握手以后会有2MSL时长的延迟
MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。
如果第四次握手的时候发生网络故障，即B端没有收到A端的ACK，那么A端将定时重复发这个ACK。2MSL的延迟是为了处理可能丢失的ACK