最速インターフェース研究会

IEのKeepAliveとwikipedia

最近、Wikipediaにアクセスすると初回だけWindowsが固まる…という問題に悩まされていたんだけど、これが原因だったのか。 最速インターフェース研究会 :: 最近IE6でWikipedia日本語版の表示が異常に遅いのはKeepAliveのせい http://la.ma.la/blog/diary_200702101610.htm k..

【百科事典】ウィキペディア第337刷【Wikipedia】

　　　 　ｒu‐┐__ 　 ｒu‐┐　'''ウィキペディア''' (''Wikipedia'') とは、 　　　　.} Ω_{' ⌒´ヾｰ､.{　　みんなで作るフリー[[百科事典]]のこと。 　　　　´ｒｰﾞｆ（ﾉﾉ）)））!i.｢ 　 　 　 ﾉ乂k(lﾟ ヮﾟﾉ'ﾉ乂　　このスレの住人には、 　　　 ´ ' 　 と}i凹{つ 　 '　'''マターリ'''いくことが求められます。 　　　　 　　ｆく/{__}〉 　　　　　　 ´　し'ﾉ　　　　　fromウィキペたん ==前スレ== 【百科事典】ウィキペディア第336刷【Wikipedia】 http://hobby9.2ch.net/test/read.cgi/hobby/1170860938/ ==ウィキペディア関連スレ検索== http://ttsearch.net/s.cgi?k=Wikipedia&o=r http://ttsearch.net/s.cgi?k=%83E%83B%83L%83y%83f%83B%83A&o=r ==関連リンク== * [http://ja.wikipedia.org/ 日本語版ウィキペディア] * [http://ja.wiktionary.org/ 日本語版ウィクショナリー] * [http://ja.wikibooks.org/ 日本語版ウィキブックス] * [http://ja.wikiquote.org/ 日本語版ウィキクォート] * [http://ja.wikinews.org/ 日本語版ウィキニュース] * [http://ja.wikipedia.org/wiki/Wikipedia:Sandbox 練習用ページ] * [http://mail.wikipedia.org/mailman/listinfo/wikija-l 日本語版ウィキペディアメーリングリスト] * [http://tools.wikimedia.de/〜interiot/cgi-bin/count_edits 編集数カウンター] * [http://ja.wikipedia.tietew.jp/utils/reverse.rhtml IP調査ページ] * [http://commons.wikimedia.org/ ウィキメディア・コモンズ]

これが原因だったのか！？

Sleipnirを使ってます。
そういえば最近確かに、Google検索してヒットしたWikiPediaのリンクを開くと、表示までに時間がかかってました。

WikiPediaが人気沸騰でアクセスが集中し、Webサーバの応答が遅いのかな??？と想像していたんですが。(・∀・)
対策として、GoogleでヒットしたWikiPediaのページは、Googleのキャッシュページで閲覧していました。
とりあえずならFirefoxで見ればいいのかな！？＼(^o^)／

私も同様です。

IE6で Wikipedia 日本語版を見に行くと、私も固まったようになります。

かといって、CPU負荷が増えているでもなく、ただ単にそのウィンドウが固まっているだけのようです。

私だけではないということで少しホッとしましたが、Wikipedia 好きな私としては、ちょっと困ってます。

Firefox に乗り換え時って事なんでしょうか・・・。

re

はじめましてこんにちは。

面白そうなので調べてみました。
以下は私の出した結論です。
（間違っていたらすみません…）

これはIEのバグである。wikipedia以外のサイトであまり見られない理由は、ウェブサーバー側の動作が珍しく、この動作をするウェブサーバーとIEの組み合わせでのみ発生するからだ。しかしこの珍しい動作は（おそらく）RFCを違反しているわけではないので、やはり原因はIEであるというべきだろう。

問題は
http://upload.wikimedia.org/wikipedia/ja/b/bc/Wiki.png
の取得において発生する。

この画像へのリクエストとして
--
GET /wikipedia/ja/b/bc/Wiki.png HTTP/1.1
Connection: Keep-Alive
Host: upload.wikimedia.org

--
というリクエストを送ってみると、レスポンスヘッダは
--
HTTP/1.0 200 OK
Server: lighttpd/1.4.13
Content-Length: 11248
Connection: close

--
となる（関係のない行は省略）。
このときサーバー側はコネクションを（1分間）切断しない。

サーバー側は「Connection: close」、つまり「このレスポンスが最後で、もうこのTCPコネクションは使わないよ」と宣言しているにもかかわらず、サーバー側からTCPコネクションを切断しない。これは珍しい動作である。普通は「Connection: close」を宣言するウェブサーバーは自分からコネクションを切断する。

IEはレスポンスを正常に受信し終えている（Content-Lengthで指定されたバイト数のデータを受信している）にもかかわらず、このコネクションがサーバー側から切断されるまで、ファイル受信後の処理を開始しない。そのため、固まったようになってしまう。

仮にレスポンスヘッダが次のようだと
--
HTTP/1.0 200 OK
Server: lighttpd/1.4.13
Content-Length: 11248
Connection: Keep-Alive

--
IEは固まらない。

つまりIEは

レスポンスヘッダのConnectionフィールドの値が「Keep-Alive」のときは、Content-Lengthの内容と受信したデータのサイズから、ファイルが受信しおわっているかどうかを判断する

レスポンスヘッダのConnectionフィールドの値が「close」のときは、コネクションが切断されることをファイルの受信完了の合図とする

という動作をするが、後者の動作は適切でない。コネクション自体の切断よりも、Content-Lengthを先に見るべきである。

今回のwikipediaでの問題はIEとsquidとlighttpdの組み合わせで特異的に発生しているものだと思われる。

re

立て続けにすみません。

RFCを見てきました。
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
1??5まで項目があります。今回問題になるのは3番と5番だと思います。

3番はContent-Lengthについて、5番がコネクションの切断についてのようです。

3番を先に評価すべきところ、IEは5番を先に評価してしまっているようですね。

ところで先の私のポストですが、

『普通は「Connection: close」を宣言するウェブサーバーは自分からコネクションを切断する。』

は

『普通は「Connection: close」を宣言するウェブサーバーは自分からコネクションをすぐに切断する。』

の方がわかりやすかったです。すみません。

いちおうIE7にすると直るようです。
IE7自体は個人的には、使い勝手良くないと思うので
自分はIE7+Grani（Sleipnirの簡易版？）を使用してます。

Wikipedia、閉鎖の危機か？

Web2.0の代名詞的存在になっているオンライン百科事典“Wikipedia”が運用資金不足で3〜4ヶ月以内に閉鎖してしまう・・・（mathewingram.com/workより）。

the Wikimedia FoundationのFlorence Devouard会長が，先ほどジュネーブで開かれたLift カンファレンスで，Wikipe...

Wikipedia閉鎖？

閉鎖は困ります。   ちょっとした調べ物にも重宝、またネタの宝庫としても大活躍の Wikipedia http://ja.wiki/ ですが、資金難により閉鎖の噂が。 ◆Wikipediaが資金不足で3~4ヶ月以内に閉鎖かも?（メディア・パブ） http://zen.seesaa.net/article/33407146.ht..

IE6でja.wikipedia.orgが遅い件をHTTPキャプチャしてみる

最速インターフェース研究会 :: 最近IE6でWikipedia日本語版の表示が...

金床さん:
> つまりIEは (略) という動作をするが、後者の動作は適切でない。

今回のレスポンスは「HTTP/1.0」なので、TCP 切断をもってコンテンツの終わりとする IE の動作も規格に準拠していると言えるのではないかと思いました。

7.2.2 Length

When an Entity-Body is included with a message, the length of that
body may be determined in one of two ways. If a Content-Length header
field is present, its value in bytes represents the length of the
Entity-Body. Otherwise, the body length is determined by the closing
of the connection by the server.
(RFC 1945)

rere

＞今回のレスポンスは「HTTP/1.0」なので

ご指摘通りで、RFC見るなら1.0の方を見るべきでしたね。

ただし、引用して頂いた箇所の後半の意味は
「Content-Lengthがないならばコネクションの切断によって判断せよ」
となります。

つまり、やはりIEの挙動はおかしい（RFCには違反している）ということになるかと思います。

#別にRFC原理主義者じゃないですが(ﾟдﾟ)

金床さんごめんなさい。いまどきそんなサーバがあるのかというのはさておき 7.2.2 の Note のほうを引用すべきでした。

Note: ... Unless the client knows that it is receiving a response from a compliant server, it should not depend on the Content-Length value being correct.

ほんとだ！

こちらこそ細かく確認せずにすみません。

「通信相手のサーバーが規約に準拠していること」
が確認できていないならば

IEの動作がRFC1945準拠

ってことになりますね。いやぁ面白いなぁ…


「通信相手のサーバーが規約に準拠していること」
ってどうやって確認するんですかねw
そこまで書いてくれRFCよw

ということで、一概に「IEのバグ」と斬ることはできないネタのようですね。すみませんでした。

とおりすがりさんに感謝。

「Connection: close」の場合にはサーバ側がすぐにコネクションを切るようにするのが、最もわかりやすい落としどころかもしれないです。

私だけじゃなかったのですね

私だけではなかったんですね。
私の場合は、gooにある「goo wikipedia」を使っていますが、
詳しいことは分からないので…

お世話になります。

>あとwikiが重いwikiが重いってどこのwikiだよ(おやくそく)。

某所でみかけますね(笑)。

情報公開ありがとうございます。非常に助かります。
今後ともよろしくお願いいたします！

【監禁】ポイントサイトについて詳細

が１クリック150ポイント＝150円還元となっているので70個位の広告をクリックまたは登録すれば1万円の監禁閾値に達するわけですが、２ヶ月かかってようやく７万円の換金に成功しました！（.....省略されました。続きを読むにはワッフルワッフルと入力してください）

【監禁】ポイントサイトについて詳細

が１クリック150ポイント＝150円還元となっているので70個位の広告をクリックまたは登録すれば1万円の監禁閾値に達するわけですが、２ヶ月かかってようやく７万円の換金に成功しました！（.....省略されました。続きを読むにはワッフルワッフルと入力してください）

Link/Network/HTTP

Link/Network/HTTP HTTPリクエストの種類を制限する「URLScan」 HTTP Status Code 301 と302の違い：おいっちょの日記 404 Blog Not Found:multipart/form-data をお忘れなく クエリ文字列の内容を調べるのに便利な「クエリ文字列解析機」 FlashでHTTPリクエストヘッダ...

writeback message: Ready to post a comment.