WebサーバのIPv6対応のススメ

先日、 「2016年度Accessログのまとめ」にて、2016年度のログから、HTTP/1.1とHTTP/2の違いを見てみました。

今回は、IPv4とIPv6の違いについて、説明したいと思います。

そして、WebサーバをIPv6に対応させることで、IPv4よりたくさんのお客さんを捌けるようになる可能性があることを説明します。

IPv4とIPv6の違い

まず、IPv4とIPv6のPingを打って伝送路の遅延を見てみます。

私のモバイル環境だと、以下のようなラウンドトリップタイムになります。

IPv4の場合(from Windows 10)

C:\Users\bob>ping -4 -n 4 www.facebook.com

star-mini.c10r.facebook.com [31.13.xx.yy]に ping を送信しています 32 バイトのデ ータ:
31.13.xx.yy からの応答: バイト数 =32 時間 =54ms TTL=52
31.13.xx.yy からの応答: バイト数 =32 時間 =39ms TTL=52
31.13.xx.yy からの応答: バイト数 =32 時間 =72ms TTL=52
31.13.xx.yy からの応答: バイト数 =32 時間 =90ms TTL=52

31.13.xx.yy の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 39ms、最大 = 90ms、平均 = 63ms

IPv6の場合(from Windows 10)

C:\Users\bob>ping -6 -n 4 www.facebook.com

star-mini.c10r.facebook.com [2a03:2880:f10f:ZZZZ:face:b00c:XXXX:YYYY]に ping を送信しています 32 バイトのデータ:
2a03:2880:f10f:ZZZZ:face:b00c:XXXX:YYYY からの応答: 時間 =76ms
2a03:2880:f10f:ZZZZ:face:b00c:XXXX:YYYY からの応答: 時間 =71ms
2a03:2880:f10f:ZZZZ:face:b00c:XXXX:YYYY からの応答: 時間 =74ms
2a03:2880:f10f:ZZZZ:face:b00c:XXXX:YYYY からの応答: 時間 =94ms

2a03:2880:f10f:ZZZZ:face:b00c:XXXX:YYYY の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 71ms、最大 = 94ms、平均 = 78ms

これだけみると、IPv6の方が、20％ほど、遅いと結果です。（誤差の範囲とも言えますが…）

ところが、次に、当サイトのIPv6ログの実測を出しますが、IPv6の方が、処理時間が短く済む事が判ります。

実際に速度はどれくらい違うのか？

「2016年度Accessログのまとめ」と同じく、HTMLファイルのアクセスログに絞って集計しています。

HTMLファイルに付随する画像・CSSは集計から外していますが、HTTP/2のH2PUSHのインタリーブ（間欠送信）が効いているので、HTTP/2については、一部CSS/SVGの同時送信の影響を受けて遅く見えます。

遅く見えるだけで、実際転送したファイル群でみると、似た数値のはずです。

すべて暗号化されたHTTPSのSSL3.0～TLS1.2までのいずれかです。

HTMLファイルは、2016年5月の時点で平均約45Kバイトだったものが、2017年1月には、平均約55Kバイトとなっています。

2016年9月だけ時間がかかっていますが、それ以外は、IPｖ６+HTTP/1.1のグラフが、最も、ログ上の処理時間がかからない通信となっています。

一方、IPｖ４＋HTTP/1.1が、ログ上最も処理時間がかかってしまっています。

HTTP/2は、前述の通り、H2PUSHのインターリーブ転送の影響を受けているため、IPv6では、HTTP/1.1よりは遅くなりますが、IPv4では、逆にHTTP/2の方が速いことの方が多いようです。

IPv4で、HTTP/2の方が早くなっているのは、パケットの往復回数がHTTP/1.1よりも少なくなるように工夫していたり、Apacheのmod_http2のH2TLSWarmUpSizeディレクティブの効果と思われます。

HTTP/2で比較すると、IPｖ6は、IPｖ４の場合の半分の時間で処理が終わっています。

このように当サイトでは、HTTP/1.1と、HTTP/2の、いずれにしても、IPv6のパフォーマンスが優位です。

なぜ、IPv6の方が速いのか？

このように、Pingでは、IPv4より、IPv6の方が遅いのに、HTTPSのTCP通信では、IPv6の方が速くなります。

IPv6では、NATを経由しないから等、いろんな要因が考えられます。

その中でも、一番効いているのは、IPv6のMTU(Maximum Transmission Unit:最大転送単位)が最低でも1280バイトであること（IPv4は2桁少ない68バイト）と、IPv6では経路上のルータでフラグメントが起きないこと、ではないでしょうか。

MTUやフラグメントについての詳細は、多くのWebサイトで説明されているためここでは簡単に説明します。

一般に、MTUが大きいほど、通信の効率は良くなりますが、通信方式によって、MTUのサイズは異なります。

そして、MTUの大きな通信路から、小さな通信路にパケットを送る場合、パケットを分割して送信する必要がでてきます。これがフラグメントです。

IPv4では、経路中のルータがパケットの分割、および結合を行います。これは、通信の遅延として現れてきます。

IPv6では、MTUの小さな通信路を通過する場合が出てくると、ICMPv6のタイプ2（Packet Too Big）によって、送信元に最適なMTUを通知します。

この動作によって、経路上のルータによるフラグメント処理の必要が無いため、IPv4よりも通信が遅延する可能性が低くなります。

（注：フラグメントが起きないのは、IPv6の経路上の話しです。IPv6でもルータそのものが通信の端点の場合は、フラグメントする可能性があります。）

さらに、IPv6では、MTUの最低サイズが1280バイトですが、IPv4では最低68バイトまで小さくなる可能性があるります。つまり、IPv6の方が通信の効率は良くなる可能性が高いです。

これらは、Pingのように小さいパケットしかやりとりしない場合は、見えてきませんが、MTU(TCPでいうところのMSS)を超えるサイズのデータをやりとりする場合に効いてきます。

もちろん、IPv4でもプロバイダによっては、TCP 接続の経路中のルータが、Path MTU Discoveryに対応していたり、TCP MSS clamping を行って、同じようなことを行うことができます。

しかし、TCP MSS clampingはTCP接続の冒頭しか使えなかったり、経路中のすべてのルータがPath MTU Discoveryに対応している訳では無いこと（ICMP通信をすべてフィルタしている場合など）から、どこかしらでフラグメントが発生することは避けられないのが実情なのではないでしょうか。

この点、最初から、経路上のルータにおいて、フラグメント化しないことを前提としているIPv6は有利です。

ログの処理時間だけを見れば、単純に考えても、IPv6に対応するだけで2倍程度のお客さんを捌けそうな感じです。（実際は、呼量（アーラン）などを考えないといけませんが…）

当サイトの2017年1月のIPv6クライアントのシェアは約10%です。これは、増えることはあっても減ることは無いので、この際、是非IPv6対応を進めて、サーバの負担を軽くしていきましょう。

というか、ヘタなチューニングより効く気がします。