博士

やっほー、ロボ子！今日のITニュースはFirefoxのQUIC UDP I/Oスタックの書き換えについてじゃ。

ロボ子

QUICですか、博士。HTTP/3で使われている技術ですね。それがどう書き換えられたんですか？

博士

そうじゃ、HTTP/3じゃ。FirefoxのHTTPトラフィックの約20%がHTTP/3を使っておるらしいぞ。で、今回のプロジェクトは、もっと効率的なUDP I/Oのために、最新のシステムコールを使うように書き換えたらしい。

ロボ子

なるほど。以前はNSPRというものを使っていて、POSIXのsendtoやrecvfromのラッパーであるPR_SendToやPR_RecvFromというAPIを使っていたんですね。

博士

その通り！でも、今のOSはもっと進化していて、sendmmsgやrecvmmsgみたいなマルチメッセージAPIや、GSO/GROみたいなセグメンテーションオフロードを提供しているものもあるからの。これらを使うことで、もっと効率的なデータ転送ができるようになるのじゃ。

ロボ子

マルチメッセージAPIやセグメンテーションオフロードですか。具体的にどう効率が上がるんですか？

博士

マルチメッセージAPIを使うと、一度のシステムコールで複数のUDPデータグラムを送受信できるからの。セグメンテーションオフロードは、大きなUDPデータグラムをカーネルに送ると、ネットワークインターフェースが自動的に分割してくれるのじゃ。これによって、CPUの負荷が減って、スループットが上がるというわけじゃ。

ロボ子

なるほど、効率的ですね！それで、具体的に何をしたんですか？

博士

まず、NSPRの使用をquinn-udpというRustのライブラリに置き換えたのじゃ。これは、メモリセーフな言語を使うことでセキュリティを向上させるためじゃ。そして、UDPデータグラム処理パイプラインを書き換えて、データグラムのバッチを送受信するようにしたのじゃ。

ロボ子

Rustを選んだのは、FirefoxのQUICステートマシン自体がすでにRustで実装されているからなんですね。マルチプラットフォーム対応も大変だったんじゃないですか？

博士

そうじゃ、FirefoxはWindows、Android、MacOS、Linuxと、色々なOSをサポートしているからの。特に古いバージョンのサポートが大変だったみたいじゃな。例えば、Windows on ARMでWSLが有効になっていると、UROを使ったWSARecvMsg呼び出しがうまくいかないバグがあったり、Android APIレベル25以下だと、ECNビットが設定されたsendmsgを呼び出すとエラーが返ってきたり…。

ロボ子

色々なOSで細かい挙動の違いがあるんですね。それを一つ一つ潰していくのは大変そうです。

博士

じゃろ？でも、その甲斐あって、CPUバウンドのベンチマークでは、1Gbit/s未満から4Gbit/sへの向上が見られたらしいぞ！

ロボ子

それはすごいですね！

博士

じゃろじゃろ？しかも、Firefoxが主要なオペレーティングシステム全体で最新のシステムコールを使用することで、IP ECNのような補助データを送受信できるようになったのじゃ。QUIC接続の約50%がECNアウトバウンド対応パスで実行されているらしいぞ。

ロボ子

ECNですか。輻輳を緩和するための技術ですね。それが使えるようになったのは大きいですね。

博士

そういうことじゃ！今回のプロジェクトで、FirefoxのQUIC UDP I/Oスタックを、quinn-udpを使った最新のメモリセーフな実装に置き換えることに成功したのじゃ！

ロボ子

素晴らしい成果ですね！

博士

じゃろ？最後にクイズじゃ！FirefoxのUDP I/Oスタックを書き換えたのは誰でしょう？

ロボ子

えーっと…、開発チームの皆さん、でしょうか？

博士

ブー！正解は…、Firefoxを使ったあなたじゃ！なぜなら、使ってくれてありがとう！