ネットワークの改善

私立 U 中学校（以下，U 校という）では，600 台の PC を U 校のネットワークに接続して S 社の教育支援サービス（以下，E サービスという）を利用している。U 校では最近校内サービスの不具合に関する申告が多くの生徒から挙がってきたので，U 校は本ネットワークを設計，構築した T 社に調査を依頼し，T 社の V さんが担当になった。

V さんは U 校ネットワーク構成を確認した。U 校ネットワーク構成を図 1 に示す。

• ISP との接続は，最大 1G ビット／秒のベストエフォート型インターネット接続サービスを契約して利用している。
• ルータは ISP と接続しており，校内からインターネットへのアクセスに対し，NAPT を使って内部の a IP アドレスを ISP から割り当てられた b IP アドレスに変換している。この変換情報はルータの NAT 変換テーブルに NAPT 変換エントリーとして格納されている。
• U 校内及び ISP 接続のルーティングは全てスタティックルーティングである。
• AP は Wi-Fi 6 に対応しており，各教室に 1 台ずつ設置されている。L2SW は，最大 30W を給電する c 機能をもち，イーサネットケーブル経由で AP に電力を供給している。
• PC は，認証サーバによって IEEE802.1X 認証を行った上で，AP を介して U 校ネットワークに接続している。
• DHCP サーバは，U 校ネットワークに接続した PC に IP アドレスやサブネットマスクなどを配布している。L3SW には DHCP リレーエージェントが設定されており，PC から送信された DHCPDISCOVER メッセージを DHCP サーバに中継している。①そのときに DHCP リレーエージェントは，giaddr フィールドに DHCPDISCOVER メッセージを受信したインタフェースの IP アドレスを格納している。
• 全てのネットワーク機器は，syslog サーバにシステムログを送信している。
• E サービスは，複数のサーバで構成されるクラウド型サービスである。教員及び生徒は，E サービスに PC の Web ブラウザからアクセスしログインして利用している。
• 1 か月前から，毎朝始業直後の 8:00〜8:15 に E サービスの一つである自習ドリルを用いて全校生徒が一斉に学習している。
• サーバ室の動画サーバには，教職員が管理している複数の教材動画が格納されており，全校生徒が授業や自習のときに PC で視聴している。

V さんは，校内サービスの不具合に関する申告について U 校の教職員にヒアリングを行い，次のように整理した。

• E サービスに対し，毎朝の自習ドリルの時間帯にアクセスすると，タイムアウト画面が出てログイン画面が表示されないと，一部かつ不特定の生徒からの申告がある。
• E サービスに対し，毎朝の自習ドリルの時間帯にログインできたが，操作後の応答が遅いと，複数の生徒からの申告がある。それ以外の時間帯では申告はない。
• 校内の動画サーバの教材動画視聴は，時間帯や教室を問わず不具合申告はない。

②これらの結果から，V さんは PC から E サービスにアクセスしたときの，（1）インターネット接続帯域の不足，及び（2）NAPT 処理能力の不足，の二つの仮説を立てた。

（1）インターネット接続帯域の調査
V さんは，U 校の許可を得てルータのインターネット側ポートの通信量データを収集した。インターネット通信量（ダウンロード）を図 2 に示す。

図 2 から，実効速度が約 200M ビット／秒で頭打ちになっていることが判明した。また，この時ルータの CPU 負荷にはまだ余裕があることも確認した。頭打ちの原因を ISP に問い合わせて調査したところ，現在の契約では構成や時間帯によって実効速度はその程度になるとのことだった。V さんは実効速度を改善するために，インターネット接続サービスのベストエフォート型から d 型への契約変更を U 校に紹介することにし，ほかの原因の調査を継続した。

（2）NAPT 処理能力の調査
V さんは，U 校の許可を得て各ネットワーク機器の状態ログ，及び syslog サーバのログを収集し，内容を確認した。ルータの NAT 変換テーブルの状態を表 1 に，ルータのシステムログを図 3 に示す。

a.b.c.d, a.b.c.e：ISP から割り当てられた IP アドレス

表 1 から，ルータの NAPT 変換エントリーの内容には異常は見当たらなかった。また，図 3 から，始業直後にルータの NAT 変換テーブルが枯渇していることが判明した。また，ルータの NAT 変換テーブルのエントリー数の上限は 65,536 であり，設定によって変更することが可能であった。V さんは，③ PC 1 台当たりのセッション数を最大 200 と見積もり，全ての PC が問題なく利用できるように，NAT 変換テーブルのエントリー数を計算してルータに設定することにした。

V さんは，二つの仮説の調査結果をまとめて上司の W 課長へ報告した。W 課長は，その報告の NAPT 処理能力に関しては更なる注意が必要と考え，資料を提示して V さんに説明した。HTTP バージョンと NAPT との関係を図 4 に示す。

次は W 課長と V さんとの会話である。

W 課長：NAPT 処理能力に着目したようですが，処理能力のほかに HTTP バージョンと NAPT 変換エントリー数との関係も意識しておく必要があると思います。
V さん：HTTP のバージョンが，NAPT 変換エントリー数と何か関係があるのですか。
W 課長：図 4 で説明しましょう。HTTP は長らく HTTP/1.1 が主流でしたが，Web サイトが地図などの詳細画像，動画，アニメーションなどのコンテンツから構成されるようになるにつれて，④ HoL（Head of Line）ブロッキングの問題が表面化してきました。これは一般的に，直列処理の場合，全ての処理が完了するまでに時間が掛かるという問題です。
V さん：HTTP/1.1 では，HoL ブロッキングはどのレイヤーで発生するのですか。
W 課長：HTTP レイヤーと TCP レイヤーの両方で発生します。HTTP レイヤーでは，例えば Web ページの表示のために 10 枚の画像データをダウンロードする場合，PC からの HTTP e と，それに対するサーバからの HTTP f を一つずつ 10 回実行することになり時間が掛かるので，一般的には複数の TCP コネクションで同時にダウンロードするように実装して対処します。
V さん：HTTP/1.1 では，TCP コネクションの数が増えそうですね。
W 課長：それを抑えるために，HTTP/2 では仮想的な通信単位であるストリームの概念が導入されました。ストリームにはそれぞれ g が付与され，一つの TCP コネクションの中で複数のストリームを利用できるようになり，HTTP セッションの多重化と h 処理ができるようになっています。
V さん：HTTP/2 によって TCP コネクションの数も少なくて済むようですね。
W 課長：さらに HTTP/3 では，TCP の代わりに UDP を利用し，ストリームは QUIC で実現することで，TCP レイヤーの HoL ブロッキングの問題を回避しています。最近の Web ブラウザの多くは HTTP/3 を実装しているので，どの HTTP バージョンが使われるかは主に HTTP サーバ側の実装に依存すると考えられます。
V さん：つまり，TCP と UDP それぞれに対するルータの NAT 変換テーブルの管理方法の違いと，E サービスで利用可能な HTTP バージョンが分かれば，もっと改善できるということですね。
W 課長：そうです。今回のケースでは， ⑤E サービスのサーバがもし HTTP/3 に対応していれば，表 2 の保持時間を調整することで，もっと NAT 変換テーブルを有効活用できると思います。ただし，極端な値にすると別の問題が発生するので，気を付けてください。
V さん：分かりました。検討してみます。

V さんは，調査結果を U 校に報告した。その後 U 校で対策を行い，不具合は解決した。