アカウント名:
パスワード:
おそらくHTTP/2.0では1つの接続に複数のリクエストを並列に織り交ぜられるような仕様にする予定なのでしょう。
それが HTTP/1.1 Keep Alive + Pipelining なんですが。
失礼、そのニュアンスで取れていませんでした。
しかし、そうなると要求順序と応答順序がマッチせず HTTP/1.0 や HTTP/1.1 との互換性がなくなってしまい、HTTP/2.0 対応クライアントでのみ通信が可能となる事となります。要求と応答の順序が同一であることが HTTP/1.0 や HTTP/1.1 では保証されていますから。
応答ヘッダに File: /index.html とか乗せるにしても、おそらくは 80 番以外のポートで通信するなどしないと Web を混乱させる要因ともなってしまいかねないため、互換性を持ったプロトコルで 80 番を使い続けるという点においては難しいような気がします。
HTTP/2.0 でリクエストした場合のみそのような対応をするのはアリでしょうけど、今の世の中の Web サーバは、Apache httpd ですらリクエストを HTTP/1.0 で出しても HTTP/1.1 で返してきますから、同様に HTTP/1.1 で要求しても HTTP/2.0 で帰ってくる、とかやられるとかなり悲しい事になりそうです。
# とはいえ、現在でもブラウザ + ダウンローダに分けていれば問題なさそうなパターンにも思えます。
読んでみましたが、大きめなファイルのダウンロード時にセッション数に空きがなくなるから、といった理由のためにさらにこれ以上 HTTP を拡張して複雑化させていくよりは、素直に BitTorrent などに任せる方向の方が良さそうに思えました。
他にも実装した方がいいと思われる理由があれば別ですが、そうでもないならさほどメリットがあるとは感じられませんが、どうでしょうか。
# なんでも HTTP でやってしまおうという方向性は好きではないので。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
技術的な根拠あるの？ (スコア:0)
10 も 20 もタブ同時に開いて使うのが普通の時代にはそぐわない制限。他の人が書いてるようにサーバー側で制御すればいいし、エロサイトとかではそういう技術も確立されてるように思う。
Re:技術的な根拠あるの？ (スコア:0)
問題ないんじゃないかなぁ～
とか思ったりもするよ
Re:技術的な根拠あるの？ (スコア:1)
＞問題ないんじゃないかなぁ～
10や20の画像が含まれてるページはあるんじゃないですかね？
# サーバの性能如何では、むしろ接続(転送の)持続時間を短くできて
# そんなに負荷をあげずに快適度を上げれることも
# あるんじゃないかなぁとは思うの
Re:技術的な根拠あるの？ (スコア:1, 興味深い)
そのためのpersistent connectionです。RFC 2616は理由もなく接続数を(それまで慣習的に使われていた4から)減らせと言っているわけではありません。
まあ現実問題として巨大なファイルを2つダウンロードすると、もうそのサーバの別のページを見ようとしても接続できないので困ったりするわけですが。おそらくHTTP/2.0では1つの接続に複数のリクエストを並列に織り交ぜられるような仕様にする予定なのでしょう。
Re:技術的な根拠あるの？ (スコア:1)
それが出来て、今のソケットを浪費するやり方よりも
スマートに並列処理を扱えるならそっちがいいね。
# サーバ側があるユーザからのリクエスト、という切り口で複数のリクエストをまとめられるから
# ファイルの大きさやコンテンツの種類に応じて帯域をわけたりできるのかな？
# テキストは早く送ってくれたり、画像はヘッダ部分だけ早く送られてくるとか
# でも、個人毎っていうことならセッションにユーザ毎のユニークIDがあればいいだけか・・・
# やっぱ、一つの接続に限定するのってそんなに良くない気がしてきた・・・事態を複雑にしているだけだ・・・
# ソケット接続を効率的に捌く方法を考えた方がいい気が・・・
Re:技術的な根拠あるの？ (スコア:1)
それが HTTP/1.1 Keep Alive + Pipelining なんですが。
Re:技術的な根拠あるの？ (スコア:0)
失礼ですが元コメントはちゃんと読まれましたか?
HTTP/1.1 Keep Alive + Pipeliningでは対応できないケースを
> まあ現実問題として巨大なファイルを2つダウンロードすると、もうそのサーバの別のページを見ようとしても接続できないので困ったりする
のようにわざわざ例を挙げて説明したのですが。
HTTP/1.1のPipeliningはリクエストとレスポンスの順番を逆転させることはできないので、先の2つのダウンロードが終了しない限り次のリクエストは一切送れません。厳密には先行して送ることはできるでしょうけどダウンロードが完了するまでレスポンスを受け取れないのでユーザーの体感的には意味がありません。
そこでHTTP/2.0ではダウンロードに接続が使われていても途中に別のリクエストを割り込ませることができる仕様になるだろう…というイメージで書いたつもりなのですが説明が下手で伝わっていなかったでしょうか。
Re:技術的な根拠あるの？ (スコア:1)
失礼、そのニュアンスで取れていませんでした。
しかし、そうなると要求順序と応答順序がマッチせず HTTP/1.0 や HTTP/1.1 との互換性がなくなってしまい、HTTP/2.0 対応クライアントでのみ通信が可能となる事となります。要求と応答の順序が同一であることが HTTP/1.0 や HTTP/1.1 では保証されていますから。
応答ヘッダに File: /index.html とか乗せるにしても、おそらくは 80 番以外のポートで通信するなどしないと Web を混乱させる要因ともなってしまいかねないため、互換性を持ったプロトコルで 80 番を使い続けるという点においては難しいような気がします。
HTTP/2.0 でリクエストした場合のみそのような対応をするのはアリでしょうけど、今の世の中の Web サーバは、Apache httpd ですらリクエストを HTTP/1.0 で出しても HTTP/1.1 で返してきますから、同様に HTTP/1.1 で要求しても HTTP/2.0 で帰ってくる、とかやられるとかなり悲しい事になりそうです。
# とはいえ、現在でもブラウザ + ダウンローダに分けていれば問題なさそうなパターンにも思えます。
Re:技術的な根拠あるの？ (スコア:0)
だからHTTP/1.2ではなくHTTP/2.0なのです。詳しくはHTTPのバージョン番号に関するRFCを調べてみてください。某Firefoxみたいにマーケティング上の都合とかその場の気分でバージョン番号を思いついたわけではありません。
> HTTP/2.0 対応クライアントでのみ通信が可能となる事となります。
あとUpgrade:ヘッダフィールドについても。
Re:技術的な根拠あるの？ (スコア:1)
読んでみましたが、大きめなファイルのダウンロード時にセッション数に空きがなくなるから、といった理由のためにさらにこれ以上 HTTP を拡張して複雑化させていくよりは、素直に BitTorrent などに任せる方向の方が良さそうに思えました。
他にも実装した方がいいと思われる理由があれば別ですが、そうでもないならさほどメリットがあるとは感じられませんが、どうでしょうか。
# なんでも HTTP でやってしまおうという方向性は好きではないので。
Re:技術的な根拠あるの？ (スコア:0)
おそらくそれこそが今に至るまでHTTP NGが放置プレイにされている理由だと思います。
ただ、RFC 2616に「コネクション減らせ」と書いた以上責任とれよ、という意味で技術的可能性を考えてみたので。