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

Question

我对我的客户端程序无法建立到远程web服务器的TCP连接的问题感到困惑。

[场景]

基于ubuntu服务器12.04 LTS的客户端程序。

192.168.1.118(客户端程序)&lt-------TCP-------->sync.oncecode.com(网络服务器)

[现象]

客户端发送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}@.@..u...v
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..<..@.6.K.*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..(..@.@.B....v
0x0010:  2a79 0c32 c8f1 0050 cec3 0ab8 0000 0000  *y.2...P........
0x0020:  5004 0000 145a 0000  

[追加]防火墙似乎关闭了，我检查了

olele@ubuntu:~$ 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

Answer 1

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

数据包捕获显示客户端的SYN，时间戳选项值为40855676，服务器的SYN+ACK回复包含40830368的时间戳回声回复。

查询的第一行必须是服务器已经回复了不同于数据包捕获中的SYN。

在握手过程中，正确的TCP协议栈会检查TSecr是否有效吗？

并非完全不合理：echo回复在过去返回时带有时间戳值。

谁能给出一些建议，为什么重新启动路由器后问题仍然存在。但是重新启动了客户端服务器，问题就解决了。Web服务器响应缓慢的原因是什么。

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

我建议你在路由器的客户端和面向互联网的一侧都运行数据包捕获。如果没有这些证据，其他任何事情都只是猜测，你将不得不等到问题再次出现。

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

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