标签：接收 情况下 多资源 第四次 lis style 导致 详解 报文
建立连接——“握手”； 关闭连接——“挥手”；
三次握手详解：
第一次：消息发送中，A端随机选取一个序列号作为自己的初始序号发送给B；
第二次：B端使用ack对A发送来的数据包进行确认，因为已经收到了序列号为x的数据包，准备接收序列号为x+1的包，所以ack=x+1，同时B告诉A自己的初始序列号，就是seq=y；
第三次：A端告诉B端收到了B的确认消息并准备建立连接，A自己此条消息的序列号是x+1，所以seq=x+1，而ack=y+1是表示A正准备接收B序列号为y+1的数据包。
为什么A端后来还要发送一次确认呢？
为了防止已失效的链接请求报文突然又传到了B端，因而产生错误。
所谓“已失效的链接请求报文”的产生原因：
正常情况：A发出连接请求，但因连接请求报文丢失而未收到来自B的确认报文，于是A再重传一次连接请求。后来收到了B的确认报文并建立了连接。数据传输完毕后就释放了连接。
A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B端————没有“已失效的链接请求报文”；
异常情况：A发出连接请求，但并没有丢失，而是在某些网络节点长时间滞留了，导致请求报文延误到某个连接释放以后才到达B端。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文后就误以为是A又发出一次新的连接请求，于是向A发出确认报文段，同意建立连接。假设不采用三次握手，那么只要B发出确认，新的连接就建立了。而现在A并没有发出建立连接的请求，因此不会理睬B的确认报文，也不会向B发送数据；但B却认为新的传送链接已经建立了，并一直等待A发来数据，B的许多资源就此浪费了。
采用三次握手可以防止该异常现象发生。刚才的情况下：A不会向B端的确认报文发送确认，B收不到A的确认就知道A并没有要求建立连接。
四次挥手详解：
全双工：通信允许数据在两个方向上同时传输，即指A→B的同时B→A，是瞬时同步的。
单工：在甲方向乙方传送数据时，乙方不能向甲方传送 。（比喻汽车的单行道。）
TCP是全双工的，因此每个方向都必须单独进行关闭，当一方数据发送完成后再发送一个FIN来终止该方向的连接，但是收到一个FIN只是意味着这一方不会再收到数据，而这一方仍然可以发送数据，直到对方发送了FIN。
第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态；
第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1，Server进入CLOSE_WAIT状态；
第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态；
第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都 发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。
标签：接收 情况下 多资源 第四次 lis style 导致 详解 报文
原文地址：https://www.cnblogs.com/panweiwei/p/11909209.html
