Tcp 3次握手 4次挥手
标签（空格分隔）： Java基础
报文介绍：
- SYN(synchronous建立联机)
- ACK(acknowledgement 确认)
- FIN(finish结束)
- PSH(push传送)
- RST(reset重置)
- URG(urgent紧急)
- ESTABLISHED（建立连接）
状态介绍：
- CLOSED（初始状态）
- LISTEN（监听）
- SYN_SENT（已发送SYN报文）
- SYN_RCVD （接收到了SYN报文）
- ESTABLISHED（已建立连接）
- FIN_WAIT_1（等待FIN报文）
- FIN_WAIT_2（半连接,还有数据需要传）
- TIME_WAIT（收到FIN报文,发出ACK报文）
- CLOSE_WAIT（等待关闭）
- LAST_ACK（等待对方最后的去人报文ACK）
TCP建立连接->3次握手
过程描述：
- Client发送SYN,请求连接,状态SYN_SENT,等待Server回应
- Server收到SYN,发送SYN+ACK,状态SYN_RCVD
- Client收到SYN+ACK,发送ACK
- 客户端和服务端都进入ESTABLISHED(连接已建立)状态
思考：三次握手的必要性？
client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
思考:为什么连接的时候是三次握手，关闭的时候却是四次握手
因为当Server端收到Client端的SYN（synchronous同步）连接请求报文后，可以直接发送SYN+ACK报文。其中ACK（acknowledgement）报文是用来确认的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能还有数据需要发送给Client端，并不会立即关闭连接，所以只是先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，Server端才会发送FIN报文，因此不能一起发送。故需要四次挥手
TCP数据传输
TCP关闭连接->4次挥手
过程描述：主动关闭方-Client
- Client发送一个FIN(关闭),告诉Server,我不会再发数据了.如果没收到回复,会重复发送FIN,此时的状态FIN_WAIT_1
- Server收到FIN,发送ACK,此时状态CLOSE_WAIT(等待关闭)
- Client收到ACK,但是没收到FIN,此时状态置为FIN_WAIT_2(继续等待,可接受数据)
- Server会继续发送数据
- Server发送完数据后,发送FIN(关闭)报文,此时状态LAST_ACK(就等ACK关闭连接了)
- Client收到FIN,发送ACK,状态置为TIME_WAIT
- Server收到ACK,关闭连接
- Client等待
2MSL(及TIME_WAIT状态维持1-4分钟)后置为CLOSED状态
PS:MSL(即Maximum Segment Lifetime,):TCP报文在Internet上最长生存时间。
那么，2MSL也就是这个时间的2倍，当TCP连接完成四个报文段的交换时，主动关闭的一方将继续等待一定时间(2-4分钟)，即使两端的应用程序结束
为什么有这个2MSL设置？
虽然双方都同意关闭连接了，而且挥手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文
一定是4次挥手断开连接吗？
不一定,如果没有数据需要传送了,Server可能一次回传ACK+FIN,4次挥手就会变为3次挥手完成关闭连接
关于‘TCP建立连接为什么是三次握手？’的另一种解释
这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了
总结
做了一个基本了解,有了解才有深入研究
参考文章
占小狼的博客-动画讲解TCP的3次握手，4次挥手
TCP三次握手、四次挥手及状态转换详解
关于TCP连接的3次握手和4次挥手
【TCP协议】(2)---TCP三次握手和四次挥手