爲什麼客戶端在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數據包？

回答

相關問題