[ はじめに ]

　快適なブラウジングの条件の1つは、ページがさくっと表示されることでしょう。 アナログモデムやISDNからブロードバンドに変えたときには、誰しも感動を覚えたと思います。

　AirH"の定額モバイルは、ワイヤレスで定額という画期的なサービスです。 しかし32kbpsというスピードは、ブロードバンドに慣れてしまうと耐え難い遅さです。

　AirH"でも快適なブラウジングができないものかと思い、高速化実験をしてみました。

• 基本的な理屈
• 圧縮が有効な条件
• 速くて遅い回線圧縮
• テキストファイルの転送実験
• まとめ
• 画像が混在するページの高速化を考える
• おまけ - 環境構築の話
• 参考・関連ページ

[ 基本的な理屈 ]

　タイトルこそAirH"の高速化ですが、高速化できるのはAirH"に限らず、低速回線全般に適用できます。

　基本的なアイデアは、回線速度が遅い区間の入り口と出口でデータを圧縮して、より多くのデータを運ぼうというものです。

　下の図を見てください。 仮に１つのデータを8kバイト(=32kbit)、通信回線の速度が32kbit/sだったとします。 3つのデータをそのまま送ると3秒かかる計算です。
　次にデータを圧縮してから送って、出口で解凍してみます。圧縮・解凍はそれぞれ0.1秒ででき、データ量を1/3にできるとします。 この時、圧縮(0.1s)＋データ1つ分(1s)＋解凍(0.1s)＝1.2秒で3つ分のデータを送れたことになります。

○：データ　●：圧縮されたデータ

　　　　　　＿＿＿＿＿＿＿＿＿＿
　　○○○　＿＿＿＿＿＿＿＿＿＿　○○○

　　　　　　　　　　回線
○　　　　　＿＿＿＿＿＿＿＿＿＿　　　　　○
○　→　●　＿＿＿＿＿＿＿＿＿＿　●　→　○
○　　　　　　　　　　　　　　　　　　　　○
　　圧縮　　　　　　　　　　　　　　解凍

　見た目の回線速度を計算してみましょう。

無圧縮時：96/3 = 32kbps

　圧縮時：96/1.2 = 80kbps

すばらしいですね！　32kbpsの回線が80kbps相当になりました。

[ 圧縮が有効な条件 ]

　次に圧縮が有効な条件を考えてみます。

無圧縮＞圧縮 無圧縮≒圧縮 無圧縮＜圧縮 回線速度 − 十分速い 十分遅い 圧縮率 − 低い 高い 圧縮にかかる時間 長い やや長い 十分短い

　圧縮が不利に働くのは圧縮時間が長くてデータ圧縮が効かず、 圧縮せずにそのまま送った方が速いときだけです。

　回線速度はあらかじめ決まっています。圧縮率は流れるデータによりけりですから、 圧縮にかかる時間が無視できれば無圧縮＜＝圧縮となります。 回線速度が十分遅い環境であれば、相対的に圧縮時間の影響が小さくなるので、圧縮をかけた方がトータルで速いことになります。 AirH"やナローバンドはこの条件を満たしています。

さて、現実でも上手く高速化できるでしょうか？

[ 速くて遅い回線圧縮 ]

　実験の前に、速さについてもう少し考えてみます。

○：データ　●：圧縮されたデータ

　　　　　　＿＿＿＿＿＿＿＿＿＿
　　○○○　＿＿＿＿＿＿＿＿＿＿　○○○

　　　　　　　　　　回線
○　　　　　＿＿＿＿＿＿＿＿＿＿　　　　　○
○　→　●　＿＿＿＿＿＿＿＿＿＿　●　→　○
○　　　　　　　　　　　　　　　　　　　　○
　　圧縮　　　　　　　　　　　　　　解凍

　例題と同じ条件で1つ目のデータが届く時間を計算してみましょう。 1つ目のデータが届くのにかかる時間は、無圧縮時は1秒です。では、圧縮時はどうでしょう。 圧縮時は解凍が終わるまで元のデータは出てこないので、1つ目のデータが見られるようになるまで1.2秒かかります。

　おや、1つ目のデータが届く時間は圧縮時の方が遅いですね。

　条件を追加して、上流からのデータが1秒に1つだけしか流れてこないとします。 1つ目のデータが届く時間を計算すると、無圧縮時は当然1秒ですが、圧縮時は3.2秒^※1もかかってしまいます。
　全てのデータが届くのにかかる時間は、無圧縮時で3秒、圧縮時は3.2秒です。

　上流回線の混み具合によっては必ずしも期待通りの速度が得られないことが分かります。

　まとめると、低速回線と、上流の高速回線の速度差が大きい程圧縮が有効に機能すると言えます。

[ テキストファイルの転送実験 ]

　実際にAirH"を使って転送速度の検証をしてみます。 ADSL回線(約1.0Mbps)で繋がった自宅のPCサーバに100kバイトのテキストファイル^※2を用意しました。

　1つ目の実験では、TeraTerm+SSH[1][2]でサーバに接続し、 コンソールでcatコマンド^※3を使ってテキストファイルの内容が全て表示されるまでの時間を計ります。
　比較対象はssh経由(圧縮あり)とssh経由(圧縮なし)です。圧縮によって転送効率が上がるかどうかをテストします。

　1つ目の実験は時間を変えて2回、それぞれ5回の試行を行いました。
 

ssh経由(圧縮あり) ssh経由(圧縮なし) 1 17 s 35 s 2 20 s 40 s 3 18 s 35 s 4 18 s 33 s 5 18 s 34 s 平均転送時間 18.2 s 35.4 s 平均転送速度 44.0 kbps 22.6 kbps

ssh経由(圧縮あり) ssh経由(圧縮なし) 1 32 s 50 s 2 38 s 60 s 3 28 s 67 s 4 24 s 68 s 5 27 s 65 s 平均転送時間 29.8 s 62.0 s 平均転送速度 26.8 kbps 12.9 kbps

　2つめの実験ではブラウザでPCサーバ上のテキストファイルを読み込むのにかかる時間を計ります。
　比較対象はssh経由(圧縮あり)と直接接続です。ブラウザでも同様の転送効率が得られるかをテストします。

　2つ目の実験は時間を変えて2回、それぞれ3回の試行を行いました。
 

ssh経由(圧縮あり) 直接接続(圧縮なし) 1 21 s 34 s 2 20 s 33 s 3 19 s 34 s 平均転送時間 20 s 33.7 s 平均転送速度 40.0 kbps 23.7 kbps

ssh経由(圧縮あり) 直接接続(圧縮なし) 1 23 s 40 s 2 20 s 35 s 3 21 s 37 s 平均転送時間 21.3 s 37.3 s 平均転送速度 37.6 kbps 21.4 kbps

　おおむね1.5〜2倍程度速くなっているのが分かります。 見た目の速度でも32kbpsを上回っていますね！

[ まとめ ]

　先の実験はテキストファイルを転送するだけでした。 テキストファイルの転送速度が約2倍になったとして、実際のブラウジングが快適になると言えるでしょうか。

　WEBページには画像ファイルが付いていることもしばしばです。 画像データはもともとGIFやJPEGで圧縮されているので、zipによる圧縮は効果がありません。 データ量の比で言ってもテキストデータと画像では圧倒的に画像の方が大きいです。

　では、圧縮を行っても快適なブラウジング環境は得られないのでしょうか？

　快適なブラウジングの1つの指標として、ページがさくっと表示されるかどうかを最初に挙げました。 圧縮によって少なくともこれは達成されます。 なぜなら、テキストデータのHTMLが送られてきた時点でブラウザのレイアウトが完了するからです。^※4
　速くて遅い回線圧縮 で書いたように、立ち上がりが遅いときもあるかもしれません。
　それでも体感で表示が速くなったと感じられます。 これまで、ぺろ〜っと表示されていたページが、ピシッと表示されます。もちろん画像の出る速さはこれまでと変わりませんが。

　ここまでの結論として、画像を除けば快適なブラウジング環境が得られると言って良いでしょう。

[ 画像が混在するページの高速化を考える ]

　え、画像も速くならないかって？ 実は画像の転送も高速化する方法もあります[3]。 ただし、転送速度は画質とのトレードオフになります。

　もともとこれ以上圧縮できない、画像データのデータ量を減らすのですから、何か削らなければなりません。 具体的には、画像をモノクロ化したり非可逆圧縮をかけたりしてデータ量を削減します。

　劣化具合によっては見るに耐えなかったりするものもありますが、 概要が分かれば良い場合なんかは有効に機能します。 ページのナビゲーションが画像だったりすると、悲惨なこともあります。

[ おまけ - 環境構築の話 ]

　最後に、おまけの環境構築のお話です。 細かい設定は各アプリケーションに付属のドキュメントを読んで下さい。

　まず、今回の実験では通信路の圧縮にSSHを利用しました。 SSHではポートフォワード機能が提供されていて、他のプロトコルのトンネリングが可能です。 この実験を思いついたのは、SSH上にHTTPを通す見通しが立ったからです。

　環境を構築するには、高速回線上にroot権限のあるサーバが必要です。 クライアント端末側でProxyサーバ(Proxomitron, Squid等)、SSHクライアント(TeraTerm+SSH, PuTTY等)を、 サーバ側でProxyサーバ(Squid)とSSHDを動かします。

　1. SSHクライアントをサーバに接続。 端末側の任意のポートをサーバ側のProxyに転送させる。
　2. 端末側のProxyで、外部Proxyを利用する設定にして、1.で指定したポートに接続。
　3. 端末側のブラウザでローカルの2.のProxyを利用する設定にする。

　経路概略

クライアント端末 → (Proxy)　　　 (Proxy) → ADSL → 外 
　　　　　　　　　　　 ↓            ↑ 
　　　　　　　　　　　(ssh)  →  サーバ(sshd)
　　　　　　　　　　　 ↓            ↑
実際の経路　　　　　　AirH" → 外 → ADSL

　これで、ブラウザのリクエストがSSHのトンネルを経由し、 サーバ側のProxyがリクエストを代行、取得したデータがSSHのトンネルを経由して戻ってきます。

　ブラウザのProxy設定で、クライアント端末のSSHの転送ポートを直接指定しても良いのですが、 LAN環境との切り替えの度にブラウザのProxy設定を変えるのは手間です。 端末側のProxyはProxomitronのような、スルーや外部Proxyの切り替えが楽なものを選ぶと良いです。

[4]ではクライアント側でSquidとRubyスクリプトを利用して、ポートフォワードを自動化しています。

[ 参考・関連ページ ]

• [1]TTSSH 日本語版
• [2]OpenSSH
• [3]RabbIT web proxy
• [4]Squid+SSH or Squid+Zebedeeの利用

有料の高速化サービス

• iAccele
• Fourelle Venturi for AirH"-PRIN

2003.04.27 大石みかげ
※このページは2002-05-09に書いたものを全面修正しました。