为什么客户端在TCP握手期间发送RST数据包？

我对我的客户端程序无法建立到远程Web服务器的TCP连接的问题感到困惑。为什么客户端在TCP握手期间发送RST数据包？

[现场]

客户端程序基于Ubuntu服务器12.04 LTS上。

192.168.1.118（客户程序）< ------- TCP ---------> sync.oncecode.com（web服务器）

[现象]

客户端发送SYN，Web服务器回复SYN/ACK，客户端立即发送RST。在TCP/IP头文件中看不到任何内容。有人能给我一些线索可能发生在这里吗？我已经跑出去的想法......

[tcpdump的日志]

21:31:31.622576 IP 192.168.1.118.51441 > sync.oncecode.com.http: Flags [S], seq 3468888759, win 5360, options [mss 536,sackOK,TS val 40855676 ecr 0,nop,wscale 7], length 0 

     0x0000: 4500 003c 537d 4000 4006 ee75 c0a8 0176 E..<S}@[email protected] 
     0x0010: 2a79 0c32 c8f1 0050 cec3 0ab7 0000 0000 *y.2...P........ 
     0x0020: a002 14f0 f8f7 0000 0204 0218 0402 080a ................ 
     0x0030: 026f 687c 0000 0000 0103 0307   .oh|........ 

21:31:31.690808 IP sync.oncecode.com.http > 192.168.1.118.51441: Flags [S.], seq 1535159088, ack 3468888760, win 5792, options [mss 1440,sackOK,TS val 971694021 ecr 40830368,nop,wscale 6], length 0 

     0x0000: 4500 003c 0000 4000 3606 4bf3 2a79 0c32 E..<[email protected]*y.2 
     0x0010: c0a8 0176 0050 c8f1 5b80 ab30 cec3 0ab8 ...v.P..[..0.... 
     0x0020: a012 16a0 6d6e 0000 0204 05a0 0402 080a ....mn.......... 
     0x0030: 39ea dfc5 026f 05a0 0103 0306   9....o...... 
21:31:31.690826 IP 192.168.1.118.51441 > sync.oncecode.com.http: Flags [R], seq 3468888760, win 0, length 0 

     0x0000: 4500 0028 0000 4000 4006 4207 c0a8 0176 E..([email protected]@.B....v 
     0x0010: 2a79 0c32 c8f1 0050 cec3 0ab8 0000 0000 *y.2...P........ 
     0x0020: 5004 0000 145a 0000

[追加] 防火墙似乎是关机，我检查

[email protected]:~$ sudo iptables -L 

Chain INPUT (policy ACCEPT) 

target  prot opt source    destination 


Chain FORWARD (policy ACCEPT) 

target  prot opt source    destination 


Chain OUTPUT (policy ACCEPT) 

target  prot opt source    destination

来源

2012-11-15 tihuBird

完成了，谢谢你的建议。 – tihuBird

“SYN + ACK”中的“TSecr”与“SYN”中的“TSval”不同。所以至少看起来'SYN + ACK'不是对我们在这个数据包捕获中看到的'SYN'的回复。有没有重发？也许这种不匹配是由NAT引起的，从未在这种情况下徘徊过。 – MattH

MattH，你是对的，客户端发起发送很多重传同步包，因为服务器没有响应。一段时间后，服务器响应sync/ack，然后客户端发送RST。我怀疑家庭路由器有问题，所以重新启动路由器，问题仍然存在。但是，在客户端重新启动ubuntu服务器后，TCP握手成功非常神秘。 – tihuBird

tihuBird，请纠正我，如果我误解了以下任何：

数据包捕获ure show的客户端SYN的Timestamp option值为40855676，服务器的SYN+ACK回复包含40830368的时间戳回复应答。

查询的第一行必须是服务器已回复到数据包捕获中的一个以外的SYN。

这是正确的TCP协议栈会检查TSecr在握手期间是否有效？

并非完全不合理：过去回显回应带有时间戳值。

谁能提供一些建议，为什么重启路由器后仍然存在问题。但重新启动客户端服务器，问题已修复。什么是Web服务器缓慢响应的原因。

因此，您重新启动了正在为客户端（？）执行NAT并且问题仍然存在的路由器。你重新启动客户端，问题解决了吗？

我会建议你在路由器的客户端和面向Internet的一端运行数据包捕获。没有这些证据，其他任何事情都只是猜测，你必须等到问题再次出现。

我怀疑服务器响应速度可能不慢，并且客户端计算机上的网络接口卡/驱动程序出现问题。客户端+路由器数据包捕获应该能够驳斥这个假设。

请记住，大多数现代网卡都具有各种与性能相关的TCP“卸载”选项，可能是其中一个细微地被破坏并重新启动以清除此状况。禁用卸载功能（并让操作系统管理更多的TCP细节）也可能解决了这个问题，并证明NIC是原因。

来源

2012-11-16 10:13:39 MattH

MattH，我不能根据你的建议做测试，直到问题再次出现。如果我得到了结果，我会继续发表评论。 – tihuBird

今天发生此问题。我已经捕获了TCP客户机和服务器机器; – tihuBird

为什么客户端在TCP握手期间发送RST数据包？

回答

相关问题