分析客户端主动发起的TCP连接与断开

参考《TCP IP详解卷1：协议 原书第2版》第13章

TCP建立连接和断开连接过程

连接过程

第一个报文段

作用：客户端发起TCP连接请求

操作：客户端发送一个SYN置位为1的报文段

TCP头部内容：

• 随机源端口
• 目的端口为服务端监听的端口
• 随机客户端的初始序列号

第二个报文段

作用：服务端响应确认客户端发送的TCP连接请求和服务端被动发起TCP连接请求

操作：服务端收到客户端的连接请求后，发送SYN置位为1和ACK置位为1的报文段

TCP头部内容：

• 源端口为监听端口
• 目的端口为收到的客户端发送请求的随机源端口
• 随机的服务端初始序列号
• Ack确认号为收到的客户端发送请求的初始序列号 + 1

第三个报文段

作用：客户端响应确认服务端被动发起TCP连接请求

操作：客户端发送ACK置位为1的报文段

TCP头部内容：

• 源端口为第一个报文段中的随机源端口
• 目的端口为服务端监听的端口
• 序列号为第一个报文段中的初始序列号 + 1
• Ack确认号为收到的服务端初始序列号 + 1

断开过程

第一个报文段

作用：客户端主动发起TCP断开请求

操作：客户端发送一个FIN、ACK置位为1的报文段

TCP头部内容：

• 源端口为已经建立TCP连接的客户端随机端口
• 目的端口为服务端监听的端口
• 序列号为当前序列号
• Ack确认号为服务端最近一次发来的序列号

第二个报文段

作用：服务端响应确认客户端发起的断开请求

操作：服务端收到客户端的断开请求后，发送ACK置位为1的报文段

TCP头部内容：

• 源端口为监听端口
• 目的端口为已经建立TCP连接的客户端随机端口
• 序列号为服务端最近一次发给客户端的序列号
• Ack确认号为接收到客户端发来的当前序列号+1

第三个报文段

作用：服务端发起主动断开TCP请求

操作：服务端发送一个FIN、ACK置位为1的报文段

TCP头部内容：

• 源端口为监听端口
• 目的端口为已经建立TCP连接的客户端随机端口
• 序列号为服务端最近一次发给客户端的序列号
• Ack确认号为服务端最近一次发来的序列号+1

第四个报文段

作用：客户端响应服务端发起的主动断开TCP请求

操作：客户端发送一个ACK置位为1的报文段

TCP头部内容：

• 源端口为已经建立TCP连接的客户端随机端口
• 目的端口为服务端监听的端口
• 序列号为第一个FIN报文段序列号+1
• Ack确认号为服务端最近一次发给客户端的序列号+1

报文验证

通过SSH登入和登出过程的报文捕获进行验证，拓扑结构如下

TCP连接

TCP连接第一个报文段

TCP连接第二个报文段

TCP连接第三个报文段

TCP断开

TCP断开第一个报文段

TCP断开第二个报文段

TCP断开第三个报文段

TCP断开第四个报文段

最后

• 这TCP连接与断开貌似更多的在软件开发方面，虽然防火墙安全策略五原组也涉及到有点内容，也就那么点
• 这么些年来，也没预见过因为传输层TCP连接失败而导致的网络连通性故障（防火墙安全策略不算）
• 毕竟TCP设计之初就考虑到糟糕的网络环境而导致的重传（那时候带宽低，设备性能不比现在）
• 最近遇到个网络ipsec vpn连接失败问题，不知是哪个老六在vpn设备上配了个目的NAT，我这查看会话记录和抓包，发现一个网络中从未有的地址出现在发起ipsec连接，（严重怀疑有人也想卖设备或搞破坏）
• 文章开头的两个图是用excalidraw画的