Question

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

[场景

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

192.168.1.118（客户端程序）＆lt; ------- TCP ---------＆gt; sync.oncecode.com（网络服务器）

[现象

客户端发送SYN，Web服务器回复SYN / ACK，客户端立即发送RST。我无法在TCP / IP标头中看到任何重击。有人能告诉我这里可能会发生什么吗？我已经没有想法......

[ Tcpdump Log ]

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 Timestamp option值为40855676，服务器的SYN+ACK回复包含40830368的时间戳回应。< / p>

第一行调查必须是服务器已经回复了除数据包捕获之外的SYN。

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

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

谁可以提供一些建议，为什么重启路由器后问题仍然存在。但重新启动客户端服务器，问题是固定的。是什么导致Web服务器慢慢响应。

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

我建议你在路由器的客户端和面向互联网的一侧运行数据包捕获。没有这些证据，其他任何东西都只是猜测，你必须等到问题再次发生。

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

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

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

1 个答案: