TCP三次握手四次挥手

TCP三次握手

TCP握手是为了建立链接： 请求发起方主动打开链接，接收方被动打开
① . 第一次握手：
客户端（client）发送一个SYN报文段请求链接，由CLOSE状态转为SYN_SEND状态，此时接收端（server）被动打开，由CLOSE状态切为LISTEN状态并保持。
② . 第二次握手：
当接收到SYN报文段之后，客户端会发送一个确认报文段，告诉服务器我收到链接请求，此报文段SYN=1，ACK=1，还有窗口大小，协商好的序号；状态切换到SYN_RCVD；。
③ . 第三次握手：
客户端收到SYN的确认之后，会对这个SYN确认报文进行确认，发送一个ACK=1，此时SYN=0，状态切为ESTABLISED开始收发数据； 服务器接到最后一个ACK之后才会切换状态为ESTABLISED收发数据。
此时三次握手完成。

为什么要三次握手

先假设是两次握手，当client发出同步SYN请求，server收到请求之后，发送ACK确认给client，（假设）此时server认为链接建立完毕，开始收发数据，如果一些原因导致client端关闭或者没有收到server的回应，而server一直在等待client的数据，client又在等server（是否会超时重传），造成死锁；
另外一种情况是，因为一些网络原因，存在已经失效的链接请求（即上一次的链接请求），而client端此时没有向server发送请求，而server收到了这个失效的或者说是超时的链接请求，以为要建立链接，发送一个ACK之后就进入数据收发状态（是在两次握手的假设下），浪费了资源（一系列的数据结构，比如等待确认的已经确认的队列）；

TCP四次挥手

① . 第一次挥手：
四次挥手时可以是客户端发起的请求，也可以是服务器端发起的请求。以客户端请求断开为例。client要求取消链接，最后一个报文段置FIN为1，并状态转换为FIN_WAIT_1；当 server（服务器） 收到client端的FIN报文段后，会切换状态为CLOSE_WAIT，告诉上层应用。
② . 第二次挥手：
lient关闭了链接，并且向client发送ACK确认，如果此时server的数据还没有发送完毕，依然会继续向client发送数据，client 收到server发送的ACK之后，也就是不再发送数据，状态切换为FIN_WAIT_2。
③ . 第三次挥手：
当 server 数据发送完毕，发送一个FIN=1的报文段给client，告诉client数据发送完毕，可以关闭链接，等待client的确认，并且状态由CLOSE_WAIT转为LAST_ACK。
④ . 第四次挥手：
client 接收到server的FIN之后，会对这个FIN做出ACK回应，状态转换为TIME_WAIT，这里有个终止等待计时器，等待2MSL的时间（MSL报文最大生存时间），然后CLOSE，如果在这个期间收到重复的FIN，则会触发ACK重传，并将终止等待计时器重置；server 收到最后一个ACK之后，CLOSE。
四次挥手完成。

为什么要四次挥手

链接是client发起的，server端是被动接受的，而挥手就不是一个主动，一个被动的问题了，挥手即断开链接的问题，是建立链接双方的问题，client数据发送完了，想要断开了，它就得小心翼翼的问问server的意见，server觉得可以就给client说，我同意你断开我，但是我断开你必须由我发起，所以，client和server都有发起断开链接FIN和收到回答的权利，即四次挥手；

主动断开链接的一方为什么要进入TIME_WAIT状态

TCP建立的可靠地数据传输链接，那么可靠体现在哪些地方呢？数据的完整性，有序性，可靠地重传机制，活动窗口，拥塞窗口，拥塞避免机制等，那么这和TIME_WAIT有什么关系？既然TCP这么可靠，那么链接的建立和关闭必然也是很可靠的，哪怕是最后一次client发出了last_ACK之后，也需要确认这个ACK是否被server端收到，但是这个确认不是通过继续让server发送ACK（如果这样，就无穷尽了），而是通过一个计时器，就是前面说的终止等待计时器，当最后一个ACK被发送之后，终止等待计时器被置为2MSL，MSL即报文段在传输过程中的最大生存时间，一般为30s到2分钟不等，2MSL即可以保证一段报文从client发送到server再从server到client的最长时间，为什么是这段时间，因为在这个时间内，我们的last_ACK就算丢失，client仍然能够收到server重传的FIN，那么此时TIME_WAIT恢复初值，知道计时器结束都没有收到server的重传，client才会CLOSE。