不一致的TCP實現

我在C/Obj-C中實現了TCP。
我注意到不同的服務器在某些場合增加了序列號，而另一些則沒有。即在服務器發送FIN/ACK的拆卸過程中，有些服務器將ACK號碼加1，而其他服務器則不加。不一致的TCP實現

爲了闡明該問題：

服務器1：的ACK數目已增加至2 Working TCP-Teardown

服務器2：的ACK數目仍爲1 ACK number not increased http://img853.imageshack.us/img853/1248/zf70.png

我的程序關於第二臺服務器的輸出：

FIN(/ACK)# was 18238 but should have been 18239

我應該如何處理這些類型的服務器端實現在我的代碼中的變化？

來源

2013-10-12 0xfee1dead

你的目的是什麼？你正在實現* TCP/IP協議棧*（通常是操作系統的一部分），還是你正在編寫一個* TCP客戶端*或一個* TCP服務器*（一個應用程序）？ – kol

我正在實施TCP/IP協議棧，從創建IP頭到解析TCP數據包。 – 0xfee1dead

如果您對ACK編號不滿意，那麼您應該使用RST中止。如圖所示。 –

你指的是你的實現的一些RFC？在發送FIN + ACK時，我不知道哪個RFC包含正確的行爲（增加或不增加ACK數），但我的猜測是應該增加ACK數。這就是說，我們都知道'符合RFC'的實現方式可以...（而不僅僅是TCP實現）！對於那些破壞連接的消息交換來說，編寫軟件的人一定是一絲不苟。所以，現在你有兩個選擇：

手柄在你的代碼兩種情況 - 當ACK遞增，並且當它不是 - 並妥善關閉您的連接結束，或者
屁滾尿流與RST對於不正確的ACK（請參閱RFC以瞭解正確的行爲），但仍然正常關閉連接的末端

這是處理相同標準的不同實現時的一個相當普遍的問題（它違背了首先是一個標準）。所以要警告的是，這可能只是您可能遇到的第一個此類問題。

我經常不得不添加額外的代碼來處理特定的情況，當一個給定的RFC的實現可以在Linux中很好地工作，並且失敗了Windows上最基本的測試。

來源

2013-10-12 19:44:10 Gautam

拆除在[RFC-793]（http://tools.ietf.org/html/rfc793#section-3.5 ）。 – 0xfee1dead

不一致的TCP實現

回答

相關問題