TCP 连接的异常释放
实际上, 有两种方法可以释放 TCP 连接 1. 发送一个称为 RST 段的报文段来立即释放连接 2. 一端发送 FIN 段, 并遵循正常的释放过程
这两种释放方式的区别在于, 正常的释放操作保证了传输的数据是可靠的, RST 段会立即切断连接, 这会导致数据的丢失.
导致某一方发送 RST 报文的情况
- 客户端尝试与服务器为对外提供服务的端口建立 TCP 连接, 服务器将直接向客户端发送 RST 报文
- 客户端和服务器的某一方在交互的过程中发生异常, 发生异常的系统对端发送 RST 报文, 告知对方释放相关的 TCP 连接
- 接收端收到 TCP 报文, 但是发现该 TCP 连接不在其已建立的 TCP 连接列表内, 则直接向对端发送 RST 报文
- 在交互的双方中的某一方长期未收到来自对方的确认报文, 则其在超出一定的重传次数或时间后, 会主动向对端发送 RST 报文释放该 TCP 连接
- 部分应用在设计时, 会利用 RST 报文快速释放已经完成数据交互的 TCP 连接, 以提高业务交互的效率
使用 FIN 报文段释放 TCP 连接的异常情况
双方同时发出连接释放请求, 又同时发送确认报文
如果客户机和服务器同时发送连接释放请求, 又同时发送确认报文, 当服务器收到客户机发送的确认报文后, 就关闭连接. 当客户机收到服务器发送的确认报文后, 就关闭连接.
如果中间没有报文丢失的话, 服务器和客户机会同时关闭连接.
若双方同时发出连接释放后请求, 同时发送的确认报文发生丢失
仅一方的确认报文丢失
双方不一定同时关闭, 正常接收到确认报文的一方会立即释放 TCP 连接, 但没有收到确认报文的一方, 会在它发送确认报文之后的 2 MSL 时间后, 释放连接.
最终, 客户机和服务器完成 TCP 连接的释放
双方的确认报文均丢失
双方在发送确认报文的 2 MSL 时间后, 自行释放连接.
最终, 客户机和服务器完成 TCP 连接的释放.
双方同时发出连接释放请求, 同时关闭后, 收到确认报文
在此时收到确认报文, 会被接收方直接拒绝