どのように処理速度を早くするか
すべての高速ネットワーク設計者が心に刻むべき基本原理を以下に記す。
「帯域でなく、スピードを最適化する設計をせよ」
従来のプロトコルは、回線上のビット数を最小化するように設計されていた。小さなフィールドを利用し、それにバイトやワードに詰め込んでいた。しかし、今や豊富な帯域が使えるように設計すべきである。IPv6の設計者は明らかにこの原理を理解していた。
ハードウェアによる処理速度改善
ハードウェアで高速なネットワーク・インタフェースを開発することである。しかし、プロトコルが非常に単純でない限り、そのハードウェアは第二のCPUとプロトコル・プログラムを持つプラグイン・ボードとしての意味しか持たない。ネットワーク・コプロセサをメインCPUのような高価なものになるのを避けるには、遅いチップを採用しなければならない。すると、メインCPUはその待ちの間に他の仕事をすればいいと考えるのは都合の良すぎる考えである。さらに二つの汎用CPUが通信を行うときは競合状態に陥る可能性があるので、二つのプロセサが正確に同期するための精巧なプロトコルが必要になる。プロトコルを単純にし、メインCPUにその仕事をやらせるのが最善のアプローチである。
- コプロセサとは
ヘッダーを最適な大きさにする
ギガビット・ネットワークでは、パケット・レイアウトも重要項目である。ヘッダーはその処理時間を減らすためにできるだけ少ないフィールドを持つようにすべきである。フィールドは十分な大きさを持ち、かつ処理の効率のためにワード単位に揃える必要がある。十分な大きさとは、古いパケットがまだネットワーク上に存在しているのに順序番号が一巡してしまうとか、ウインドウ・フィールドが小さすぎて受信者が十分なウインドウ・スペースの通知を行えないといった問題を起きないようなという意味である。
送るデータサイズも大きくする
ソフトウェア・オーバーヘッドを削除し、動作を効率するために、最大データサイズも大きくすべきである。高速ネットワークでは、1500バイトは小さすぎる。この理由により、ギガビット・イーサネットでは最大9KBのジャンボ・フレームを扱えるようになっているし、IPv6 は64KBを超えるデータグラムをサポートしちえる。
フィードバックによる遅延を少なくする
高速プロトコルにおけるフィードバック問題について考えてみよう。比較的長い遅延ループがあるので、フィードバックを避ける必要がある。
...
スライディング・ウインドウ・プロトコルを利用した伝送速度の決定がある。受信者は送信者にウインドウ更新を送るが、それには長い遅延が含まれる。これを避けるために、速度準拠プロトコル(rate-based protcol)の利用が望ましい。速度準拠プロトコルでは、送信者と受信者があらかじめ合意したレートを超えない範囲で、送信者は好きなだけデータを送ることができる。
あらかじめリソースを予約することでジッターを減らす
送信者、受信者、ネットワーク全てが、コネクション設定時に必要なリソースを予約する手法が効率的である。あらかじめリソースを予約することは、ジッターを減らすという効果もある。まとめると、高速ネットワークの設計は否応なしにコネクション指向になるということである。
- ジッターがぼやぼやしてきた