9 月に、The Register のネットワーク デスクは、Teclo という会社と、Linux スタックにおける TCP パフォーマンスの限界について話し合いました。
ここで説明する作業には、カーネルが長年にわたって蓄積してきた複雑な処理を回避するために、TCP/IP 処理をユーザー空間に移動することも含まれていました。
そのため、同じ問題に対処する他の高性能な取り組みがあることを知っても驚くにはあたりません。ビデオ ストリーミング ファームの BBC と、頻繁なパケット フラッド攻撃に対処する必要のある CloudFlare です。
BBCの取り組みについては、研究技術者のスチュアート・グレース氏がここで解説しています。放送局によると、高解像度のビデオストリームは、毎秒34万パケットを4Gbpsの超高解像度ストリームに送出する必要があるとのことです。
記事によると、処理時間は 1 パケットあたりわずか 3 µs なので、カーネル スタックを使用することは単純に不可能だったとのことです。
投稿によると、ネットワークソケットAPIの使用には、パケットの多くの処理が伴うとのことです。「各データパケットは、オペレーティングシステム内の複数のソフトウェア層を通過し、ネットワーク上のパケットのルートが決定され、ネットワークヘッダーが生成されます。その過程で、データはアプリケーションのバッファからソケットバッファにコピーされ、その後、ソケットバッファからデバイスドライバのバッファにコピーされます。」
Beeb の研究者たちは、カーネルから抜け出してユーザー空間に踏み込むことから始めました。これにより、アプリケーションとネットワーク ハードウェア デバイス ドライバーが共通のメモリ バッファー セットを共有する、いわゆる「ゼロ コピー カーネル バイパス インターフェイス」を作成することができました。
投稿ではさらに、アプリケーションがパケットのグループとそのネットワーク ヘッダーを作成する場合、それらの共有バッファー内で直接それを実行すると説明されています。
「その後、単一の関数呼び出しを使用して、グループ全体がデバイス ドライバーの制御に引き渡され、デバイス ドライバーがそれらを直接ネットワークに送信します。」
カーネルから離れたネットワーク：BBCのアーキテクチャ
放送局は作品をいつ公開するか、あるいは公開するかどうかについても明らかにしていない。
CloudFlare: 新しい構文を書きました。次に何が起こったか信じられないでしょう
CloudFlare のアプローチも同様で、ユーザー空間カーネルのバイパスですが、その状況に特有の工夫が凝らされています。
CloudFlareの問題は、パケットの量だけではありません。攻撃パケットとユーザーデータを区別する必要があるのです。The Registerの常連読者なら、このプロバイダーが定期的に攻撃を受けていることは既にご存知でしょう。
Gilberto Bertin氏は次のように記しています。「パケットフラッドが発生すると、選択されたネットワークフロー（フラッドに属するもの）をユーザー空間アプリケーションにオフロードします。このアプリケーションはパケットを非常に高速にフィルタリングします。ほとんどのパケットはフラッドに属するため、破棄されます。少数の「有効な」パケットはカーネルに送り返され、通常のトラフィックと同じように処理されます。」
ベルティン氏によれば、同社は目的を達成するために、Netmap プロジェクトに変更を加えることに決めたという。
Netmapのデフォルト機能（すべての受信パケットキューをカーネルから切り離す）を使用する代わりに、「ほとんどのRXキューをカーネルモードに保持し、選択したRXキューのみでNetmapモードを有効にします。この機能を「シングルRXキューモード」と呼んでいます。」
優れたハックはどれもそうですが、これは小さくてシンプルです。Bertin氏が書いているように、CloudFlareに必要なのは主にキューを分割する機能でした。「唯一の違いはnm_open()呼び出しで、これは新しい構文netmap:ifname~queue_numberを使用します。」
パッチ コードはプロジェクトに送信されており、GitHub で入手できます。®
