TCP未ACK仍递增序列号及SIP注册响应异常技术问询

场景说明 #

NAT后的终端通过NAT设备与应用服务器（AS）建立TCP连接，流程如下：

• TCP握手完成后，终端(A)向AS发送100字节的SIP REGISTER，AS回复100字节的200 OK。
• 此时TCP连接状态：发送序列号已到100，下一个待发序列号为101，已确认字节数为100。
• 数秒后，AS通过同一TCP连接发送OPTIONS请求（seq:101，下一个seq:201，已确认字节数:100）检测NAT针孔，未收到ACK，判定针孔已关闭。
• 数秒后，终端触发RE-REGISTER（100字节），NAT设备打开新针孔并通过原TCP连接发送至AS，但TCP头未确认之前的OPTIONS字节（seq:101，下一个seq:201，已确认字节数:100）。
• AS收到RE-REGISTER后，以自身维护的最新序列号回复200 OK（seq:201，下一个seq:301，已确认字节数:200），但仅设置ACK标志、未设置PUSH标志，且只发送了一半的200 OK缓存。
• 剩余的200 OK在终端下一次RE-REGISTER时才发送。

技术问题解答 #

1. NAT针孔关闭后，AS与终端间的TCP连接能否保持开放？ #

不能保证保持开放。NAT针孔关闭意味着NAT设备已删除该TCP连接的地址映射条目，此时AS侧的TCP连接虽然系统层面可能仍处于ESTABLISHED状态，但网络通路已断——AS主动发往终端的报文会被NAT丢弃。终端发起RE-REGISTER时，NAT新建针孔复用原有四元组，此时连接属于“半开”状态：终端和AS侧的连接都未被内核主动回收，但中间NAT映射曾中断。若后续无双向报文交互，AS侧TCP连接最终会因超时（如TCP保活超时）被内核关闭。

2. 服务器端TCP连接中，前一报文未被ACK时，下一包能否使用连续序列号？ #

可以。TCP序列号基于字节流，只要发送方的发送窗口未耗尽，就可继续发送后续字节并使用连续序列号，这属于TCP的流水线传输，是协议允许的正常行为。即便前一报文未收到ACK，只要发送窗口还有余量，发送方就可延续字节计数发送下一包。

3. 为何RE-REGISTER的200 OK仅部分发送且未设置PUSH标志仅为ACK包？ #

这大概率是老旧TCP栈的实现缺陷：

• 未设置PUSH标志：老旧栈对PUSH标志的触发逻辑不完善，可能仅在应用层明确调用带PUSH标识的发送接口、或缓存填满时才设置PUSH，此次因缓存仅填充一半，栈认为可继续缓存后续数据，未触发PUSH。
• 仅发送一半缓存：可能是栈的发送缓存调度逻辑异常，比如处理RE-REGISTER响应时，因存在未ACK的OPTIONS报文，状态机出现错误，仅推送了部分缓存数据；或是老旧栈对“半开”连接的报文处理存在bug，未将完整200 OK数据推入发送队列。
• 剩余数据延迟发送：后续终端再次RE-REGISTER时，栈将之前缓存的剩余数据与新响应数据合并发送，这是老旧栈在异常连接状态下的错误缓存处理行为。

内容的提问来源于stack exchange，提问作者Prakash GiBBs