各種ブラウザのTCPハンドシェークフラグ操作への対応について弊社TCP/IPプロトコルスタック「μNet3」に関する書込みはこちらにお願いします。TCP/IPスタック上に、独自WEBサーバを実装中です。Retransmission]が検出されています。下記のようなケースでWEBブラウザより、「SYN」が発行されることに起因しています。:WEBサーバ→ブラウザ8ACK9フラグメントデータ10ACKこのように、予期せぬところで「SYN」が発行されると、「RST+ACK」がWEBサーバ側から発行されます。通常の3Wayハンドシェーク想定外の「SYN」の発行に対応しているようなのですが、問題はないと考えてよいでしょうか?ブラウザのこのような動作の意図をご教示いただけないでしょうか?また、uNet3としては、このような意図を想定していますでしょうか?ちなみに、仮WEBサーバ実装としては、問題なく機能しています。22:17お世話になっております。イー・フォースの技術担当です。情報が少ないので、一部こちらの想像で書かせていただきます。:WEBサーバ→ブラウザ本件ですが、LISTEN状態のソケットがないために4のSYNに対して5でRST+ACKを返信しています。)していると思いますが、3の時点でTCPのコネクションが生成され、ソケットがLISTEN状態でなくなります。他にLISTEN状態のソケットがないので、4のSYNに対して5でRSTを返信しているのではないかと思います。同様の現象が発生します。HTTPサーバが正常に動作しません。返却してしまい、ページが表示されない。)を実行してください。)を実行することは可能です。具体的には複数のタスクを用意して次のようにしてください。タスクとソケットの数が多いほど、WEBブラウザから同時接続できる数が多くなります。}>通常の3Wayハンドシェーク想定外の「SYN」の発行に対応しているようなのですが、問題はないと考えてよいでしょうか?1~3と4~5はポート番号が異なると思います。従って1~3と4~5はそれぞれ別のセッションとなります。)を実行しているソケットがないので、RSTをブラウザへ返信するのは正しい動作となります。下記のサイトが参考になるかと思います。08:15回答ありがとうございます。当方ブラウザの知識が薄く、現象から頷ける内容でした。早々に、並列ソケット化(マルチタスク化)して検証しました。Retranmission等のTCPパケットは消えました。ケーブル切断の特殊なテストケースで、ノンブロッキング・コールバックが発生しなくなる場合があり、引き続き検証中です。