パスワードを忘れた? アカウント作成
4847 story

6倍速いブラウザ 88

ストーリー by Oliver
6人のスレッド達 部門より

float 曰く、 " HOTWIREDの記事によれば、アイルランドの16歳少年が「XWEBS」と呼ばれる6倍速いブラウザを開発したとのこと(原文記事)。
この記事を読んだ限りではコネクション数を増やしてリクエストを並行に出し、データを分割取得(partial-content?)してレンダリングを部分ごとに行い結合する、ということだろうか?(求む識者)「インターネットで広く使用されているある種のサーバーの特徴を活かした」は、Apacheのモジュールのことを指しているように読める。
「自分のブラウザーについて特許や著作権の可能性を探っているため、それ以上のコードを公開するつもりはない」とのことなので、オープンソースにはならなさそうだ。/.本家の記事では6倍ではなく4倍(quadruple)となっている。
なお、赤い PC に入れると18倍……というネタはすでにfj.net.www.browsers,japan.www.browserで既出だ :)"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by ahiguti (10103) on 2003年01月30日 2時57分 (#246669)
    記事を読んだ感じでは、コネクション数を増やして並行にRange付きリクエストを出して、クライアント側で再構成してるようです。こういうことはHTTPクライアントはやるべきではないと思います。たしかにレスポンスは速くなりますが、ネットワークの負荷は増大します。要するに、スループットを犠牲にしてレスポンスを上げているわけです。
    HTTP/1.1では、できるだけ少ない接続を使ってpersistent connection、とくにrequest pipeliningを使う(サーバ側からの返事を待たずに複数のリクエストを一つの接続から送る)のがもっともスループットが高くなり、レスポンスも良くなります。もし、HTTP/1.1のrequest pipeliningを使うよりも接続数を増やしてRangeリクエストを使うほうが速いのであれば、それは相手サーバの資源を一人占めすることによって速くなっている可能性が高いです。
    request pipeliningは最近の主なWebサーバは全てサポートしています(ただし余り最適化されていません。我田引水リンク [hokudai.ac.jp])。しかし残念ながら現在の主なWebブラウザはrequest pipeliningを使っていないようです。
    最近、Windowsのレジストリを変更してMSIEの同時接続数を増やす技が紹介されているのを見かけることがありますが、これもやはりネットワークや相手サーバの資源を浪費してレスポンスを速くすることになるので、あまりやるべきではないと思います。
    • by Anonymous Coward on 2003年01月30日 16時57分 (#247189)
      記事を読んだ感じでは、コネクション数を増やして並行にRange付きリクエストを出して 、クライアント側で再構成してるようです。こういうことはHTTPクライアントはやるべ きではないと思います。

      私もRange分割だと思いましたが、 その程度なら誰でも考える方法だし、 実験的になら誰もがよくやってることですね。 そして誰もがやるべきでないと考えます。 通常のHTTPアクセスの場合、 たった1つのパケットロストがそのHTTPセッション全体を遅らせることになり 複数のパケットロストが発生するとそれらの遅延の合計が HTTPセッション全体の遅延になるという弱点があります。 Rangeによって複数セッション同時アクセスすれば パーシャル化された小さなリプライのうち最も遅い到着パーシャルの 遅延が全体の遅延となりますので、ある種のリスクヘッジにはなります。 ただし、その自分勝手なニーズのためにウェブサーバーや回線に対して 無駄な負荷をかけることになります。 回線やサーバーの負荷が高まっている混雑時に 早く閲覧したいという自分勝手なニーズで さらに負荷を高めるという手法を皆が使用すれば 混雑はさらに増大します。 お正月の一番混雑するタイミングで年賀Eメールを送るようなものであり、 こういうのは遠慮すべきことです (個人の自由は公共の福祉に反しない限りということ) 。

      そもそもTCPの上のHTTPに備わっているパーシャル機能を利用して 仮想的なUDPらしき通信を作りだし、 それによってわずかな速度向上を得る代わりにサーバーや回線に余計な負荷をかける、 なんてのは悪しき発想です。 そんなもの作る暇があったら HTTP on UDP のプロトコルとクライアントサーバーの実装をしてくれた方が いくらか社会に貢献することでしょう。

      Range分割によるDoSのようなアクセスで負荷増加があったら 多くのサーバーはアクセス拒否をすることでしょう。 ついでにCGIやSSIなど動的生成コンテンツの場合 マージで不整合が起きてクライアントとして実用性が落ちるでしょう。 こういう自分勝手なセミDoSツールを作る人は地獄に落ちるべきでしょう。

      親コメント
    • by Anonymous Coward on 2003年01月30日 5時20分 (#246690)
      最初は私もそう思いました。多コネクションかなと。
      でもそれだけじゃ極悪だし、

      >この技術が現実に機能するのかどうか不明だ
      >考案した技術はまったく独自のもののようだ

      ここまで言われる程無茶で斬新な方法では全く無い
      (アイルランドにも多重ダウンロードツールくらいあるだろ)ので、
      せいぜいブラウザ側からサーバの最大接続可能数を知る方法でも
      見つけたのかとも考えたんですよ。
      でもやっぱりしっくりこない。

      >Xウェブズは情報に対するリクエストを、1本の情報の流れでなく、
      >いくつもの流れとして同時に処理する。

      ストレステストをしていないので推論ですが、
      必要処理時間は重い順に
      解析エンジン>表示処理>パケットデータ
      だと思うんですよ。解析と表示の切り分けは難しいですが。で、

      一つのソケットに解析エンジンを複数使っているのでは?
      と考えました。

      例えばフレーム単位や、バイナリデータ専用に複数、ヘッダ、
      スクリプト、BODY、テーブル等でそれぞれ分けて同時処理させたのでは?
      IEコンポーネントやボーランドのsocketは知らないので
      出来るのか不明ですが。
      どうでしょ?
      親コメント
      • 解析を同時処理というのは、複数のスレッドで、ということでしょうか。Pen4のHTで少しだけ速くなるのならありえると思いますが、600%は難しいのではないでしょうか。ひょっとして600%というのは、8CPUのマシンでの結果だったりして(笑
        親コメント
    • 最近レスポンス悪い(表示が遅い)なぁ、と思うページって画像やバナーが別サーバーに置かれているケースが多いです。この場合並行してコネクションをはるメリットがあり、コネクション確立のオーバーヘッドもあるのでかなり高速化出来ると思うのです。

      まあ、レンダリング速度なんてページの作りに依存する理由で 600% ってのは測り方/条件しだいなのでしょうが、手が無いわけじゃないかなと。 でも、私はそういうコード書く元気はないなぁ。

      --
      親コメント
    • 極悪http proxy (スコア:1, 興味深い)

      by Anonymous Coward on 2003年01月30日 10時16分 (#246799)
      正確にはHTTPクライアントではないですが、技術力では世界有数の超有名日本企業が使っているhttp proxyは複数proxyマシン(複数IPアドレス)から並列でWebサーバにアクセスしてきます。proxy上で再構成してクライアントに引き渡しているんでしょうか?ちょっとしたDDoS攻撃です。それにしても、こんな極悪なhttp proxyを見たことがないのですが、どなたか知っていますか>識者の方。
      親コメント
    • 複数のプロクシサーバに対して要求を分散するようにすれば
      応答性が速くなる可能性がありますね。

      キャッシュの当たり具合にもよると思いますが。

      メールアカウントのためだけに契約を続けているプロバイダから、
      webのプロクシサーバのサービスをやめるとの通知がキタばかり何で
      ちょっとがっかり。
      親コメント
  • (嘘でもいいから) 数万行のコードからなるブラウザを引っ提げて
    大会で絶賛の嵐(?)を浴びるような若者、日本に いますかねぇ。

    しかも、すでに特許とかビジネスの事まで考えている。たいしたもんだ。

    /.jp と /.org の反応の差といい、
    日本はいろんな意味でまだまだだなぁと思います。
  • そんなホイホイ6倍速にもなるものなんだろうか…。
    2chでXウェブズのスクリーンショットのURLが貼られていましたが、
    できそこないのXBoxみたいでダサかったです(笑)。
    ソースが公開されてないなら自分は興味無いっすねぇ…。
    --
    This cookie has a scrap of paper inside. It reads:
    If you can't learn to do it well, learn to enjoy.
    • by krackmania (7864) on 2003年01月30日 2時05分 (#246640) 日記
      >オスマニさんのブラウザーは、米マイクロソフト社のインターネッ>・エクスプローラ(IE)をベースとしている。

      一瞬自分で独自エンジンを積んだブラウザだと思ったよ。<滝汗
      それならスゲエ感動するけど。
      IEベースならOperaより遅いんでは<汗
      親コメント
  • 世界中の人が必死になって6倍以上のやつを作りそうな予感。

    # あ、もしやテキストのブラウザ開発したんじゃないだろうな。(お
    --
    (´д`;)
  • by take0m (4948) on 2003年01月29日 23時42分 (#246520) 日記
    なんとなく燃費が悪そうだなぁ。
    資源の無駄遣いな気もするけど。
    サーバ管理者的にはどう思うんだろう、こういうのは・・・
    • 記事読んで一言 (スコア:2, すばらしい洞察)

      by take0m (4948) on 2003年01月30日 0時30分 (#246565) 日記
      私は最高に高性能なエンジンを開発した。このエンジンを積みこめばどんな自動車も時速600㎞以上で走ることができる。ただし理論上での話しだ。シャーシやタイヤなどが、私の高性能なエンジンについてこなければならないだろう。
      燃費はほんのちょっと悪い。リッター1km程度だ。なあに、普通のエンジンの6分の1程度さ。

      しかし、このエンジンについて詳細をこれ以上お話しすることはできない。なぜならば私はこのエンジンについて特許の可能性をさぐっているからだ。
      親コメント
    • by Anonymous Coward
      アクセスカウンタも6倍で増えるなら、それはそれでうれしい人も多いかもね。

      #多分、増えないと思うのでAC
      • by tomatsu (2545) on 2003年01月30日 16時04分 (#247158)
        部分取得なら、普通、増えるでしょう。
        アクセス手法やらの場合分けをしてなけりゃ、アクセスがあった時に、それが部分取得だろうとHEADアクセスだろうと、+1カウント。
        リロードでカウントが回らない様に組んであったりとかしてたら別かも知れないけど。
        親コメント
  • by HajimeG3 (6109) on 2003年01月29日 23時55分 (#246538)
    世のダウンローダーと呼ばれるソフトはその機能を活用して
    サーバの負荷あげてアクセス制限かけられたりしてるようですが。
    --
    -- for whom are you alive?
  • by shn (7678) on 2003年01月30日 3時29分 (#246680) ホームページ
    1/100圧縮 [srad.jp]なんてのが昔あったなぁと思いました。
    実現可能性で言えば"XWEBS"の方が高そうだけど
  • by gk-hyn (7889) on 2003年01月30日 17時36分 (#247229)
    ビジュアル・ベーシックではなく、ボーランドC++をプログラミングに使用した。このため、さらにマイクロソフト社のツールをいくつか使って言語を変換しなければならなかった
    こうしたプロセスのために、かなりの行数のコードが余分にできることになった
    これの意味が分からなくてずーっと気になっていたんだが、IEコンポーネント(多分)を使う時に、VBでは要らなくて、古いBorland C++では必要で、「MS製の変換プログラム」が存在し、かなりの行が無駄に自動生成される、、、
    ひょっとしてIDL(ツールはMIDL)の事だったりするんだろうか。他に該当するのも見あたらないように思える。ただ、MIDLで吐かれるのは、インターフェースに付いてのヘッダと、ラッパークラスでは無かったか、、、
    引用した下の段落は、「100万行、っていっても結構無駄があってね」という言い訳みたいなもので、とすると、「100万行のコード」には、「変換されたidl」、ン万行(mshtml.idlのVC++変換版mshtml.hが61K行) が勘定に入ってることに、、、
    とここまで書いたら、「このブラウザーは100万行以上のコードからなっている」≠「オスマニが100万行書いた」という事に気づく。
    上まあ消防署の方から来た消火器売りと同じでstdio.hとかprintf.cとかの分も入ってたりしても全然OKというわけで windows.hの30万行分も水増しされているのであろうか(苦笑)
  • 訂正 (オフトピ) (スコア:0, オフトピック)

    by float (7805) on 2003年01月29日 23時15分 (#246482) ホームページ 日記
    「すでに~既出」が「馬から落馬」している、というツッコミは
    自分で気づいたのでご勘弁を。
  • by Anonymous Coward on 2003年01月29日 23時30分 (#246499)
    intelは理論的に可能って言ってる様だけど、もしかしてこれって新CPUの宣伝じゃないだろうね。 なにげなくつるんでる事が多いからね。intelは。
  • by Anonymous Coward on 2003年01月29日 23時30分 (#246500)
    回線が6倍速くなる訳ではないようなので、どうでも良いです。
  • by Anonymous Coward on 2003年01月30日 0時35分 (#246572)
    >コンテストの審査員たちによると、オスマニさんが
    >早熟と言えるほどの優秀なプログラミング技術を持っていることは
    >間違いないという。
    ネーミングセンスも!
    素晴らしいネーミングセンスも!

    #スーパーエキストラバーニングヒートナイトメアIE5の使用者なのでAC
  • by Anonymous Coward on 2003年01月30日 0時40分 (#246577)
    中に6人もいて大変だな。

    ... というネタを呼ぶための餌でしょうか?
typodupeerror

Stay hungry, Stay foolish. -- Steven Paul Jobs

読み込み中...