TCP/IP三次握手和四次挥手

参考《计算机网络自顶向下方法》

三次握手



第一步：首先Client端向服务端发送一个特殊的报文段，连接请求报文，建立连接请求标志位SYN=1，随机生成一个序列号client_isn

第二步：Server段接受连接后发送给Client端一个报文段，包含三个重要信息，SYN=1, 回复确认应答ACK=client_isn+1，自己的序列号，并为这次连接分配资源。

第三步：Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。

四次挥手



【注意】中断连接端可以是Client端，也可以是Server端。

假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说”我Client端没有数据要发给你了”，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，”告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息”。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，”告诉Client端，好了，我这边数据发完了，准备好关闭连接了”。Client端收到FIN报文后，”就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，”就知道可以断开连接了”。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

Client TCP经历的TCP状态序列



客户端TCP状态迁移：

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

Server TCP经历的TCP状态序列



服务器TCP状态迁移：

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

三次握手四次挥手相关问题：

为什么是三次握手？两次可不可以？

答: 先假设是两次握手，当client发出同步SYN请求，server收到请求之后，发送ACK确认给client，（假设）此时server认为链接建立完毕，开始收发数据，如果一些原因导致client端关闭或者没有收到server的回应，而server一直在等待client的数据，client又在等server（是否会超时重传），造成死锁；

另外一种情况是，因为一些网络原因，存在已经失效的链接请求（即上一次的链接请求），而client端此时没有向server发送请求，而server收到了这个失效的或者说是超时的链接请求，以为要建立链接，发送一个ACK之后就进入数据收发状态（是在两次握手的假设下），浪费了资源（一系列的数据结构，比如等待确认的已经确认的队列）；

为什么是三次握手，而挥手却是4次？

答： 三次握手经上面的推理验证是最有效且成本最低的链接次数，而且，链接是client发起的，server端是被动接受的，而挥手就不是一个主动，一个被动的问题了，挥手即断开链接的问题（所谓请佛容易送佛难），是建立链接双方的问题，client数据发送完了，想要断开了，它就得小心翼翼的问问server的意见，server觉得可以就给client说，我同意你断开我，但是我断开你必须由我发起，所以，client和server都有发起断开链接FIN和收到回答的权利，即四次挥手；

FIN发起方最后的TIME_WAIT状态是为了什么？为什么要等2MSL？

答： 首先，我们很明确的一个问题就是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；

还有一个原因：即前面的为什么要三次握手提到的失效的链接请求报文，即在这个2MSL时间内，网络中关于本次链接发送的数据都会消失，从而避免出现失效的报文段的现象；