アカウント名:
パスワード:
問題なのは、TCP接続を張っていない状態でHTTPリクエストが送られることがあるかどうか、という点です。例えば、クライアントが(そのローカルポート番号について)SYNとACKを送る前にHTTPリクエストのパケットを送ったり、あるいはクライアントがFINを送った後にHTTPリクエストを送ったりしたならば異常です。
3.のあとにキャプチャを止めてしまうのではなくて、同じTCP接続を保ったまま7.のHTTPリクエストが送られているかどうか確かめる必要があります。もしTCP接続を保ったままである(FINがクライアント側からおくられず、同一のローカルポート番号である)ならば、それは正常なHTTP 1.1の動作です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
ガセネタではないようです (スコア:1)
しかし、WinNT4.0&IIS4の構成のサーバにIE6.0SP1でアクセスしたところ、HTTP通信完了後に60秒間程度セッションが閉じられないままになることを確認しました。
このセッションが閉じられない60秒間の間に再度、そのサーバに対してHTTPリクエストを送信すると、SYN -> SYN/ACK -> ACK の手続きを踏まずに、いきなり HTTP通信が行われます。
NT4.0のSPレベルやIISのバージョンによって違いが出るのか等、興味は尽きませんが、週末辺りにいろいろな組み合わせで検証してみようと思っています。
取り急ぎ、現状のご報告まで。
参考資料:(検証に用いたサイトは適当に選択したサンプルです)
私が今回の検証に利用したもの
・WindowsXP Pro+SP1 + IE6.0+SP1
・Ethereal + WinPcap
・NAT環境(Proxy環境は無し)
・www.teruya.co.jp (WinNT4.0& IIS4.0)
検証手順
1.Etherealでキャプチャを開始。
2.すぐにWinNT4.0&IIS4のサーバにアクセス。
3.ページの表示が完全に終了したことを確認したらキャプチャを停止。セッションが張られたままであることを確認する。
4.再度Etheralでキャプチャを開始(ページ表示完了から60秒以内)。
5.ページのリロードや同一サーバ内の他のページを表示。
6.2分ほどキャプチャさせ続ける。
7.クライアントからSYNが送信されずにいきなりHTTPコマンドが送信されていることを確認。最後にHTTP通信が完了した時点から60秒ほど経過した頃にクライアントからFIN/ACKが送信されていることを確認。
以上
Re:ガセネタではないようです (スコア:2, 参考になる)
問題なのは、TCP接続を張っていない状態でHTTPリクエストが送られることがあるかどうか、という点です。例えば、クライアントが(そのローカルポート番号について)SYNとACKを送る前にHTTPリクエストのパケットを送ったり、あるいはクライアントがFINを送った後にHTTPリクエストを送ったりしたならば異常です。
3.のあとにキャプチャを止めてしまうのではなくて、同じTCP接続を保ったまま7.のHTTPリクエストが送られているかどうか確かめる必要があります。もしTCP接続を保ったままである(FINがクライアント側からおくられず、同一のローカルポート番号である)ならば、それは正常なHTTP 1.1の動作です。
Re:ガセネタではないようです (スコア:1)
いったん床についたんですが、「キープアライブなんじゃねぇの?」と、半ばまどろみながら気づいて調べなおしたらその通りでした。
的確なご指摘、感謝致します。
Re:ガセネタではないようです (スコア:0)
醜い心が生み出した怪物 (スコア:0)
まあ、憎しみは結局誰も幸せにしないってことでしょうか。
これを期に、アンチと言われる人もちゃんと自分の心で判断して物事を見るようにしてくれると良いのですが。
(アンチMSでもアンチLinuxでもなんでも)
…認めたくないものだな…自分の、若さゆえの過ちと言うことを…。
Re:ガセネタではないようです (スコア:0)
結局HTTP1.1に沿った普通の実装、って事ですね。
# NT4なんかどこ漁っても出てこないしよ(;´Д`)
Re:ガセネタではないようです (スコア:0)