0

レガシー システムと Linux システム間の通信を実装しようとしていますが、次のシナリオのいずれかが常に発生します。

(レガシーシステムはサーバー、Linux はクライアント)

Function recv(2) returns 0 (the peer has performed an orderly shutdown.)
> SYN
< SYN, ACK
> ACK
< PSH, ACK  (the data)
> FIN, ACK
< ACK
> RST
< FIN, ACK
> RST
> RST

Function connect(2) returns -1 (error)
> SYN
< RST, ACK

サーバーがデータを送信すると、クライアントはデータで応答する必要がありますが、代わりに「FIN、ACK」が返されるのはなぜですか? これをどのように解釈すればよいでしょうか。私はこのレベルの TCP にあまり詳しくありません

4

2 に答える 2

1

サーバーがデータを送信すると、クライアントはデータで応答する必要がありますが、代わりに「FIN、ACK」が返されます。これをどのように解釈すればよいでしょうか。

サーバーがデータを送信すると (4 行目)、クライアントがソケットを閉じるか途中で終了し、オペレーティング システムがソケットを閉じて送信するFIN(5 行目) 可能性があります。サーバーは に応答しますFINがACK、クライアントは既に存在しなくなり、オペレーティング システムは で応答しRSTます。(クライアント OS は、悪名高い状態のときに閉じられた接続に到着する TCP セグメントを黙って無視して破棄することを期待していますTIME-WAITが、何らかの理由でそれは起こりません。)

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_termination :

一部のホスト TCP スタックは、Linux や HP-UX が行うように、半二重クローズ シーケンスを実装する場合があります。そのようなホストがアクティブに接続を閉じても、スタックがリンクから既に受信したすべての着信データをまだ読み取っていない場合、このホストは FIN の代わりに RST を送信します (RFC 1122 のセクション 4.2.2.13)。これにより、TCP アプリケーションは、リモート アプリケーションが以前に送信したすべてのデータを読み取ったことを確認できます。つまり、リモート側からの FIN を待機して、積極的に接続を閉じます。ただし、リモート TCP スタックは、接続中止 RST とこのデータ損失 RST を区別できません。どちらも、リモート スタックが受信したすべてのデータを破棄しますが、アプリケーションはまだ読み取っていません。

于 2012-11-07T13:43:49.370 に答える