使っているPCでIPv4 / IPv6それぞれの通信量を計測してみる

株式会社テイク-ワンの T.T です。

私はIPv4とIPv6の両方が利用可能なネットワーク環境で業務を行っています。
私を含めIPv6が利用可能なケースが増えているようですが、実際のところIPv6はどのくらい使われているのだろう?と疑問を持ち、自分の業務用PCではどうなんだろう?ということで計測してみました。

※本記事はITやネットワーク技術について入門を終えたレベルの方を対象にしています。

今回は Wireshark などの解析ツールは使わず、Windows 標準で利用できる netsh コマンドのみを使って、IPv4 / IPv6 の利用状況を「IP パケット数(OS 起動後の累計)」を計測してみました。

計測環境と前提

OS:
 ・Windows 11
ブラウザ:
 ・Google Chrome
 ・Microsoft Edge(Chromium ベース)
ネットワーク:
 ・IPv4 / IPv6 デュアルスタック
利用内容:
 ・Web ブラウジング
 ・Teams
 ・SharePoint
 ・クラウドサービス(動画・画像・API 通信を含む)

計測方法:
 netsh interface ipv4/ipv6 show ipstats
 OS 起動後からの累計値

計測コマンドについて

計測はWindows11のコマンドプロンプトでIPv4、IPv6それぞれ下記のコマンドを使うことで実施しました。

IPv4の統計

netsh interface ipv4 show ipstats

IPv6の統計

netsh interface ipv6 show ipstats

実測結果(OS起動後 累計)

IPv4

  • 出力要求(送信):21,722,894
  • 受信パケット数:27,616,445

IPv6

  • 出力要求(送信):21,970,246
  • 受信パケット数:140,837,699

IPv4 / IPv6 の比較

IPv4 / IPv6 出力要求(≒送信パケット数)

出力要求には破棄されるパケットも含みますが、実際に送信されるパケット数に近い値になります。計測結果ではIPv4とIPv6で同じような値になっています。

その理由としてはクライアントが通信するときに IP の種類をほとんど意識していないことに加えて、多くの主要な Web サービスや CDN が、すでに IPv6 を普通に使える状態になっているためだと考えられます。今では、主要なサービスの多くが IPv6 用のアドレスを DNS に登録しており、CDN 側も IPv6 接続を優先して受け付ける仕組みになっています。その結果、利用者は特に意識しなくても、自然に IPv6 経由で通信することになります。

IPv4 / IPv6 受信パケット数

IPv4:約 2,760 万
IPv6:約 1 億 4,080 万
IPv6 が IPv4 の約 5 倍という、はっきりした差が見て取れます。

なぜ IPv6 の受信パケット数がこれほど多いのか生成AIであるCopilotに聞いてみました

Copilotに確認したところ、単に「IPv6の方が多い」という結果だけでは十分ではなく、なぜこのような差が生じるのかを理解することが重要だと分かりました。

ここで重要なのは、
 「IPv6 のほうがパケット数が増えやすい」
という曖昧な説明ではなく、なぜそうなるのかをプロトコルとトラフィックの観点で整理することです。

モダンな Web トラフィックは IPv6 + QUIC を選択しやすい

現在の Web トラフィックの多くは、
 ・動画
 ・画像
 ・JavaScript / CSS
 ・API 通信
といった 小さなリソースを大量に取得する通信で構成されています。
Chrome / Edge はこれらの通信に対して、
 ・HTTP/3(QUIC)
 ・UDP / 443
 ・IPv6
という組み合わせを 積極的に選択します。
これは、
 ・QUIC が TCP よりも接続確立が速い
 ・IPv6 が UDP と相性の良いエンドツーエンド通信である
 ・CDN やクラウド事業者が IPv6 + HTTP/3 を優先提供している
といった、現在の Web インフラの設計思想と一致しています。

結果として「パケット数」が顕著に増える

HTTP/3(QUIC)は、
 ・ストリーム単位で制御
 ・再送や制御を細かく行う
 ・ヘッドオブラインブロッキングを回避
という設計上、
 同じ通信量でも、TCP よりパケット数が増えやすい
という特徴があります。
そのため、
 ・モダン Web トラフィック(動画・画像・API)
 ・IPv6
 ・QUIC
という条件がそろうと、
 通信量は体感的に変わらなくても、IP パケット数だけが顕著に増加する
という現象が起こります。
今回の結果は、まさにこの構造を反映したものだと考えられます。

Happy Eyeballs との関係

Chrome / Edge は Happy Eyeballs の考え方に基づき、
 ・IPv6 を優先的に試行
 ・問題があれば IPv4 へ素早くフォールバック
という挙動を取ります。

今回の計測では、
 Happy Eyeballs による「IPv6 優先 → IPv4 フォールバック」が発動する場面が少なく、IPv6 が素直に選ばれ続けている
環境であることが、結果から読み取れます。

感想

最近はQUICがよく利用されていることは知っていたのですが、今回の計測とCopilotによる回答でどのくらい利用されているのか、また、その特徴についても知ることができ、とても有意義でした。

参考情報

QUICとHTTP/3をやさしく解説:なぜUDPベースなのに信頼できるのか?
https://qiita.com/omochi_0604/items/01314b8cefebe521f198

Happy Eyeballsとは
https://www.nic.ad.jp/ja/basics/terms/happy-eyeballs.html

前へ

Azure Arc エージェントが 有効期限切れ になった場合の復旧方法