TCP协议的三次握手四次挥手

图解分析TCP三次握手协议

 

* 为什么要三次握手，不能像http或者UDP一样直接传输

 

　　主要是为了防止已失效的连接请求报文段突然又传到了B,因而报文错乱问题

　　假定A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，一直延迟到连接释放 以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为 是A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多资源就这样白白浪费了。

 

TCP四次挥手

* 为什么要进行四次挥手

　　* 确保数据能够完整传输

　　* 当被动方收到主动方的FIN报文通知时，它仅仅表示主动方没有数据再发送给被动方了。

　　* 但未必被动方所有的数据都完整的发送给了主动方，所以被动方不会马上关闭SOCKET,它可能还需要发送一些数据给主动方后，再发送FIN报文给主动方，告诉主动方同意关闭连接
　　* 所以这里的ACK报文和FIN报文多数情况下都是分开发送的。

* 模拟流程

　　A:“喂，我不说了 (FIN)。”A->FIN_WAIT1

　　B:“我知道了(ACK)。等下，上一句还没说完。Balabala…..（传输数据）”B->CLOSE_WAIT | A->FIN_WAIT2

　　B:”好了，说完了，我也不说了（FIN）。”B->LAST_ACK

　　A:”我知道了（ACK）。”A->TIME_WAIT | B->CLOSED

　　A等待2MSL,保证B收到了消息,否则重说一次”我知道了”,A->CLOSED

* 图解分析TCP四次挥手协议

 

* TCP前面10种状态切换

* TCP第11种状态CLOSING 状态概念

　　* 这种状态在实际情况中应该很少见，属于一种比较罕见的例外状态。正常情况下，当一方发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING 状态表示一方发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？那就是当双方几乎在同时close()一个SOCKET的话，就出现了双方同时发送FIN报文的情况，这是就会出现CLOSING 状态，表示双方都正在关闭SOCKET连接。

* netstat -anp|grep 8080