【网络】TCP的连接建立
TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次连接通信过程中必不可少的。
因此，运输连接就有三个阶段： 连接建立 ， 数据传送 和 连接释放 。
需要解决以下3个问题：
连接建立 这个过程，需要在客户端和服务器之间，交换3个TCP报文段，也就是 三次握手 🤝x3。
📌请注意，在本例中， A主动打开连接，B被动打开连接
一开始，B就在准备接受客户进程的连接请求，然后服务器进程就处于 LISTEN （收听）状态，等待客户的连接请求。如有，即作出响应。
A的TCP客户进程像B发出连接请求报文段，这时，首部中的同步位SYN = 1，同时选择一个初始序号 seq = x 。
TCP规定📝，SYN报文段不能携带数据， 但要消耗掉一个序号 。这时，TCP客户进程进入 SYN-SENT （同步已发送）状态。
B收到连接请求的报文段后，如同意建立连接，则向A发送确认。在确认报文段中，应把SYN位和ASK位都置1，确认号是 ack = x + 1 ，同时也为自己选择一个初始序号 seq = y 。
请注意，这个报文段也不能携带数据。但同样 要消耗掉一个序号 。这时，TCP服务器进程进入 SYN-RCVD （同步收到）状态。
TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号 ack = y + 1 ，而自己的序号 seq = x + 1 。
TCP的标准规定📝，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq = x +1 。
这时，TCP连接已经建立🖇，A进入 ESTABLISHED （已建立连接）状态。当B收到A的确认后，也进入 ESTABLISHED （已建立连接）
🔍 Q: 为什么A最后还有发送一次确认呢？
📗 A: 主要是为了 防止已失效的连接请求报文段突然又传送到B，因而产生错误。
所谓 “已失效的连接请求报文段” 是这样产生的。
📝考虑一种正常情况，
A 发出连接请求📲，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。
A共发出了两个连接请求的报文段，其中第一个丢失💔，第二个到达了B💚，没有“已失效的连接请求报文段”。
📝现假定出现一种异常情况，
即A发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间的滞留🛑，以至延误到连接释放以后的某个时间才到达B。
本来这是一个 早已失效的报文段 ，但是B收到此时小的连接请求的报文段之后，误以为是A又发出一次新的连接请求。
于是向A发出确认报文段，同意建立连接。假定不采用报文握手。那么只要B发出确认之后，新的连接就建立了。
由于现在A并没有发出建立连接的请求，因此不会理睬B的确认🙉，也不会向B发送数据，但B确以为新的运输连接已经建立，并一直等待A发来的数据。
B的许多资源就这样白白浪费了。
Storm代理
2023-07-25 广告
