TCP的三次握手和四次挥手

TCP的运输连接有三个过程，即建立连接、数据传输和连接释放。
一.三次握手链接

这张图可以简单的描述三次握手连接的过程，那它具体是怎么连接的呢？
首先，客户端请求主动连接，客户端就会向服务器发送一个包含SYN标志的TCP报文，客户端进入SYN SENT状态，等待服务器确认（SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段），同步报文会指明客户端使用的端口以及TCP连接的初始序号。
第二步，服务器收到客户端发来的SYN报文后，将返回一个SYN+ACK的报文，给客户端表示收到请求，同时TCP序号被加一，此时服务器进入SYN RCVD状态（ACK: 确认号是否有效）。
第三步，客户端收到之后，返回一个ACK报文给服务器，表示收到了。此时双方进入ESTABLISHED状态。
以上就是三次握手连接的过程。
此处会有几个问题：
1.此时客户端向服务器端发送的报文如果丢失会如何？

客户端发送报文之后会启动一个定时器，在超时之后未收到服务器端的确认，会再次发送SYN请求，每次尝试的时间会是第一次的二倍，如果总的总尝试时间为75秒，此次建立链接失败。

2.如果第二次报文丢失怎么办

在发送完ACK+SYN报文后会启动一个定时器，超时没有收到ACK确认，会再次发送，会进行多次重试。超时时间依旧每次翻倍，重试次数可设置

3.如果握手只进行两次还能进行连接吗？
当然是不行，因为两次握手容易死锁。如果服务器的应答分组在传输中丢失，将不知道客户端建立什么样的序列号，客户端认为连接还未建立成功，将忽略服务器发来的任何数据分组，只等待连接确认应答分组。而服务器在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
4.如果是四次呢？
可以是可以，但效率会低。

二.四次挥手断开连接
这张图可以简单的看出四次挥手断开连接是怎样的，接下来详细说说具体过程：
首先：当客户端端的应用程序结束数据传输是，会向服务器发送一个带有FIN附加标记的报文段（FIN表示英文finish，FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段），此时客户端端进入FIN_WAIT1状态，客客户端不能在发送数据到服务器端。
第二次：服务器端收到FIN报文会响应一个ACK报文，服务器端进入CLOSE_WAIT状态。进入此状态后服务器端把剩余未发送的数据发送到客户端，客户端收到服务器端的ACK之后，进入FIN_WAIT2状态。同时继续接受S端传输的其他数据包。
第三次：服务器端处理完自己待发送的数据之后，也会发送FIN断开链接的请求，服务器端进入LAST_ACK状态。
第四次：客户端端收到服务器端的断开链接请求后会启动一个定时器，该定时器时长是2MSL(最大段报文生存时间)，同时发送最后一次ACK报文。
此处的问题：
1.为什么要四次挥手？

TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。为何建立连接时一起传输，释放连接时却要分开传输？
建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

2.为什么客户端在TIME-WAIT阶段要等2MSL?

为的是确认服务器端是否收到客户端发出的ACK确认报文当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。