TCP三次握手与四次挥手

TCP建立连接与断开连接的过程如下图：

TCP连接断开其状态转移路线如下：

其中以上1,2,3段则代表的为TCP建立连接的时的三次握手，过程如下：

1. 客户端client主动发起请求连接,发送携带SYN标志同步报文段1，并包含一个ISN值为1000的序号，并指定自己的最大段尺寸mss为1460等;
   其代表含义为：序号是1000,这个序号在⽹网络通讯中⽤用作临时的地址,每发一个数据字节,这个序号要加1,这样在接收端可以根据序号排出数据包的正确顺序,也可以发现丢包的情况,另外,规定SYN位和FIN位也要占一个序号,这次虽然没发数据,但是由于发了SYN位,因此下次再发送应该用序号1001。mss表示最大段尺寸,如果一 个段太大,封装成帧后超过了链路层的最大帧长度,就必须在IP 层分片,为了避免这种情况,客户端声明自己的最大段尺寸,建议服务器端发来的段不要超过这个长度。
2. 服务器server端发出段2，其收到连接请求，其同意与client建立连接，并向其发送自己的连接请求SYN，其ISN值为8000，声明自己最大段尺寸为mss为1024，并对第一个同步报文段进行了确认。其代表含义是：我接收到序号1000及其以前所有的段,请你下次发送序号为1001的段,也就是应答了客户端的连接请求,同时也给客户端发出一个连接请求,同时声明最大尺寸为1024“；
3. 段3是client端对第2同步报文段的确认，确认序号为8001.

以上即为TCP三次握手的具体过程。
4、5、6段则是数据传输。
以上第一个图中7、8、9、10段则代表TCP断开连接时的四次挥手，具体过程如下：

1. 客户端发出段7,FIN位表示关闭连接的请求；
2. 服务器发出段8,应答客户端的关闭连接请求；
3. 服务器发出段9,其中也包含FIN位,向客户端发送关闭连接请求；
4. 客户端发出段10,应答服务器的关闭连接请求。

至此，TCP连接将断开，client端则进入TIME_WAIT状态（即客户端还要生存2MSL生存时间，下篇博客详解此状态），server端则进入CLOSE状态。

此处说明TCP建立连接后数据传输的过程，依然以第1个图为例：

1. 客户端发出段4,包含从序号1001开始的20个字节数据；
2. 服务器发出段5,确认序号为1021,对序号为1001-1020的数据表示确认收到,同时请求发送序号1021开始的数据,服务器在应答的同时也向客户端发送从序号8001开始的10个字节数据,这称为piggyback；
3. 客户端发出段6,对服务器发来的序号为8001-8010的数据表示确认收到,请求发送序号8011开始的数据。

超时重传：在数据传输过程中,ACK和确认序号是非常重要的,应用程序交给TCP协议发送的数据会暂存在TCP层的发送缓冲区中,发出数据包给对方之后,只有收到对方应答的ACK段才知道该数据包确实发到了对方,可以从发送缓冲区中释放掉了,如果因为网络故障丢失了数据包或者丢失了对方发回的ACK段,经过等待超时后TCP协议自动将发送缓冲区中的数据包重发。
其实现机制则是对每一个TCP报文段维护一个重传定时器，定时器在TCP报文段第一次发送时启动，如果超时未收到对方的应答，TCP模块则将重传TCP报文段并重置定时器，下次的超时时间与执行多少次重传设定取决于TCP重传策略。

知道以上所有的知识，现在回答两个经典问题：
1.为什么TCP连接要经过3次握手？

• 防止已失效的连接请求报文再一次传到对端（服务端）：若客户端发送一个连接请求没有丢失，由于某些网络结点长时间滞留，客户端一定时间未收到服务端的确认，则会重传一次连接请求，此连接收到确认，建立连接，数据传输完毕，释放连接，此时第一次滞留的连接请求则到达服务端，服务端收到此滞留的报文段后，误认为是客户端又一次的连接请求，于是向客户端发出确认报文段，同意建立连接，假定是2次握手，此时服务器端则认为连接确立了，并一直等待客户端发来数据，可客户端并不认定这次连接，不会发任何数据，则会造成服务器资源的浪费，但采用3次握手，客户端则不会给服务器端的确认发出确认，服务器收最终不到确认信息则会放弃这次连接。

2.为什么TCP连接断开要经过4次挥手？
首先了解半关闭状态：通信的一端可以发送结束报文段给对方，告诉本端已经完成了数据的发送，但允许继续接收来自对方的数据，直到对方也发送结束报文段以关闭连接，将这种状态称为半关闭状态。

• 依然以第一幅图为例，服务器关闭连接通常需要4个段,服务器的应答和关闭连接请求通常不合并在一个段中,因为有连接半关闭的情况,客户端关闭连接之后就不能再发送数据给服务器了,但是服务器可能还有很多数据还未发送给客户端，其则需要继续发送数据给客户端,直到发送完成，服务器则在关闭连接。
• 两个端都要确认对方端的FIN，保证TCP可靠的断开连接，若没收到ACK，则超时重传。