Part1では、トラフィック制御機構のアプローチについて紹介する。主に、トラフィック制御を行う場所や、パケットを処理する際のキューイング方式などを解説する。
Mbps単位のインターネット接続環境が一般家庭レベルにまで浸透し、アナログモデムでのダイヤルアップなどについて忘れかけている人も多い。そのせいか、低速回線に配慮しないWebページが増えてきたり、動画などの巨大なデータをやり取りする人が増えてきた。これによって、「別のサービスに支障が出るようになった」というケースもあるだろう。特定のサービスによる通信量が突発的に肥大しても、ほかのサービスに影響を及ぼさず、QoS*を保つように先手を打っておくことが肝要だ。
ただし、単に特定サービスのデータ転送速度を絞るだけでは、せっかくの広帯域の物理回線が無駄になってしまう。トラフィック制御では帯域幅を大切な「資源」ととらえ、それを複数のサービスでいかに上手に分け合うかを決めることが重要である。
実際、P2Pによる巨大データの授受、音声や動画の配信などを無条件で転送した場合、どのような問題が発生するのかを考えてみよう。
例えば、管理運営しているメーリングリスト(以下ML)において、巨大なデータファイルが投稿されたらどうなるだろうか? 「全員に配送されるまでに時間がかかるだろうな」という心配程度では済まされない。
qmail*の登場以来、SMTPコネクションは並列で張るのが主流となっている。SendmailにおいてもSMTPfeed*を利用して並列処理することで、複数の宛先への配送が高速に行われる。しかし、巨大なメッセージを並列配送すると、サイトに与えられたネットワーク帯域幅をすべて消費することがある。その結果、すべてのネットワーク通信が使い物にならない状態が発生してしまう*。もちろん、SSHでログインして修復しようとしても、コマンド入力に時間がかかったり、SSH接続自体がタイムアウトする可能性もある。これはDoS攻撃*を受けたのと同じ状況であり、しばらくの間外部から制御不能な状態が続くわけだ(図1)。
管理運用しているサーバーのコンソール前に常駐するなら問題ないのだが、そうでない場合はSSHでのログイン作業に支障が生じないよう保証しておかなければ危険である。上述した巨大ファイルのML投稿の例に限らず、DoS的な外部からのアクセスがあった場合、それを回避する設定を行うにはSSH接続が安定した速度で行えるように設定しておく必要がある。このようなときに効果的なのがトラフィック制御である。
Quality of Serviceの略。ネットワーク上で、特定の通信用の帯域を予約し、一定の通信速度を保証する技術。
D.J.Bernstein氏が開発した代表的なMTA。詳細はこちらを参照。
Sendmailから呼び出される配送エージェント。配送を並列に行うため、高速な処理が可能。詳細はこちらを参照。
筆者が管理しているドメインの運用を開始した当初、このトラブルに遭遇した。巨大メッセージをメールキューから削除するまでに何時間もかかったのを記憶している。
Denial of Serviceの略。ネットワークを通じた攻撃の1つで、相手ホストやルーターに不正なデータを送信して使用不能に陥らせたり、トラフィックを増大させて相手のネットワークをまひさせるもの。
Copyright(c)2010 SOFTBANK Creative Inc. All rights reserved.