HTTP/2 PINGフレームの真実：単なる「死活監視」を超えた超低遅延RTT計測の舞台裏
インフラエンジニアやWeb APIの設計に携わる者なら、TCPのキープアライブやICMPのping、あるいはアプリケーション層のヘルスチェック（`/healthz`など）がどのように機能するか、耳タコほど聞いてきたことだろう。
しかし、いざ「HTTP/2のレイヤーで正確なラウンドトリップタイム（RTT）を測れ」と言われたとき、君ならどうする？
HTTP/1.1の時代、僕たちは無駄なTCPセッションを乱立させたり、コネクションを維持するために無慈悲なオーバーヘッドを伴うGETリクエストを定期的に投げたりしていた。だが、HTTP/2のバイナリフレーミングレイヤーは、そんな泥臭いやり方を過去のものにしてくれる。
今回は、HTTP/2の隠れた主役である「PINGフレーム」にスポットを当てる。RFC 7540が定義するこの小さな8バイトのペイロードが、いかにしてコネクションの生存確認と極めて高精度なRTT計測を同時に実現しているのか。現場のトラブルシューティングの知見を交えながら、徹底的に解き明かしていこう。
—
1. なぜ「HTTP/2 PING」が必要なのか？（TCP・HTTP/1.1の限界）
Webのパフォーマンスを極限までチューニングする現場では、ミリ秒単位の遅延がビジネスの勝敗を分ける。ここで、従来のレイヤーにおける「死活確認」と「遅延計測」のジレンマを振り返ってみよう。
- TCPキープアライブ: OSカーネルレベルで動くが、デフォルトでは数時間単位とスローすぎる。また、アプリケーション層が「本当にHTTPリクエストを処理できる状態か」までは保証しない。
- HTTP/1.1の定期リクエスト: アプリケーション層の死活確認には確実だが、毎回TCPハンドシェイクやTLSネゴシエーション（Persistent Connectionでも、HTTPヘッダーのパース、キューイングのオーバーヘッド）が発生する。純粋なネットワークのRTTを測るには不純物（ノイズ）が多すぎる。
ここで登場するのが HTTP/2のPINGフレーム だ。
TCPコネクションやTLSセッションを維持したまま、ヘッド・オブ・ライン・ブロッキング（HoLブロック）を起こさず、既存のストリームと完全に独立して、瞬時に往復遅延を計測できる。これが実務上どれほど強力か、エンジニアなら直感できるはずだ。
—
2. PINGフレームの構造とRFC 7540の仕様
HTTP/2のすべての通信は「フレーム」というバイナリの単位で行われる。PINGフレームの構造は非常にシンプルかつ洗練されている。
フレームの基本フォーマット（9バイトの共通ヘッダー + ペイロード）に照らし合わせて見てみよう。
+———————————————–+
| Length (24) |
+—————+——————————-+
| Type (8) | Flags (8) |
+-+————-+——————————-+
|R| Stream Identifier (31) |
+-+———————————————–+
| |
| Payload (64) |
| (8-byte opaque data) |
| |
+———————————————–+
各パラメーターの解説
1. Length (24ビット): ペイロードの長さ。PINGフレームの場合、仕様により必ず `8` (バイト)と固定されている。
2. Type (8ビット): フレームタイプ。PINGは `0x6` (6)。
3. Flags (8ビット): PINGフレームで使用されるフラグは1つだけ。
- `ACK` フラグ (`0x01`): 受信したPINGフレームに対して、そのままオーム返しで返送する際に立てるフラグ。
4. Stream Identifier (31ビット): ここが最大のポイント。 PINGフレームは特定のストリームに依存しないため、ストリーム識別子は必ず `0` (ゼロ) でなければならない。コネクション全体（Connection-Level）で処理される。
5. Payload (64ビット / 8バイト): 送信側が自由に設定できる不透明なデータ（opaque data）。通常はタイムスタンプや乱数が詰め込まれる。
—
3. 往復の通信フロー（シーケンス）
クライアントとサーバーの間でPINGフレームがどのように飛び交い、RTTが算出されるのか、そのシーケンスを追ってみよう。
[Client] [Server]
| |
|—- [Frame Type: PING, Flags: 0x00, Stream: 0] ->|
| (Payload: 0x0123456789ABCDEF, T1 = 100.0ms) | (受信・即座に応答を決定)
| |
|<- [Frame Type: PING, Flags: 0x01 (ACK), Stream: 0]|
| (Payload: 0x0123456789ABCDEF, T2 = 105.2ms) |
| |
(Client側で T2 - T1 を計算 = RTT 5.2ms)
1. 送信 (Request): クライアントは現在時刻（$T_1$）を記録し、任意の8バイトの値をペーストしたPINGフレーム（Flags: `0x00`）をStream ID `0` で送信する。
2. 受信と返送 (Response): サーバーがこれを受信すると、ストリームの処理を待つことなく、即座に同じ8バイトのペイロードをコピーし、ACKフラグ (`0x01`) を立てたPINGフレームを折り返し送信する。
3. 計測完了 (Calculation): クライアントはACK付きのPINGフレームを受信したら、その時の時刻（$T_2$）を取得。$T_2 – T_1$ を計算することで、純粋なHTTP/2トランスポート層のRTTを算出する。
—
4. 【実務編】各種ツールとコードによる実装・検証アプローチ
「理論は分かった、じゃあどうやってデバッグや実装でするんだ？」というシニアの要求に応えるため、現場で使える具体的な手段を紹介しよう。
A. cURLによるHTTP/2接続とPING的挙動の確認
現代の `curl` (libcurl) はHTTP/2を完全にサポートしている。残念ながら直接「PINGフレームを送れ」という単体のコマンドラインオプションはないが、詳細なHTTP/2のコネクション状態を追うには `-v` や `–http2` が欠かせない。
HTTP/2での接続を確認しつつ、詳細なハンドシェイクログを出力する
curl -Iv –http2 https://nghttp2.org/
※実務で本格的にHTTP/2のフレーム単位のやり取り（PINGフレームの送受信含む）をデバッグ・検証したい場合は、Wiresharkでのパケットキャプチャや、Go言語の `golang.org/x/net/http2` パッケージを用いたテストスクリプトを書くのが最も確実だ。
B. Python (h2ライブラリ) による低レイヤーPING送受信の実装
HTTP/2のフレームをプログラムから自由自在に操るなら、Pythonの `h2` ライブラリがベストチョイスだ。以下に、PINGフレームを送信してACKを受け取る概念的なコードを示す（実務でのカスタムヘルスチェックツールの自作などに応用できる）。
import h2.connection
import h2.config
import socket
import struct
import time
接続先の設定
HOST = “nghttp2.org”
PORT = 443
ソケットの確立（実際にはTLSラッパーが必要ですが、簡略化のためソケットのみ記載）
本番では ssl.create_default_context().wrap_socket() を使用してください
s = socket.create_connection((HOST, PORT))
実際にはここにTLSハンドシェイクとALPN(“h2”)のネゴシエーションが入ります
H2コネクションの初期化 (クライアントモード)
config = h2.config.H2Configuration(client_side=True)
conn = h2.connection.H2Connection(config=config)
conn.initiate_connection()
s.sendall(conn.data_to_send())
1. 測信用ペイロードの作成（例: 現在のタイムスタンプを8バイトに詰める）
実際にはランダムな8バイトやシーケンス番号でも可
ping_payload = struct.pack(“!Q”, int(time.time() 1000))
t1 = time.time()
print(f”[] PINGフレーム送信: Payload={ping_payload.hex()}, 時刻={t1}”)
2. PINGフレームの送信 (Stream ID 0, Flags 0x00)
conn.ping(ping_payload)
s.sendall(conn.data_to_send())
3. 応答の受信ループ
s.settimeout(5.0)
try:
while True:
data = s.recv(65535)
if not data:
break
events = conn.receive_data(data)
for event in events:
# PING ACK イベントをキャッチ
if isinstance(event, h2.events.PingAcknowledged):
t2 = time.time()
rtt_ms = (t2 – t1) 1000
print(f”[+] PING ACK 受信成功!”)
print(f” 返送されたPayload: {event.ping_payload.hex()}”)
print(f” 計測されたRTT: {rtt_ms:.2f} ms”)
break
# 送信すべきデータがあればフラッシュ
out_data = conn.data_to_send()
if out_data:
s.sendall(out_data)
if ‘t2’ in locals():
break
finally:
s.close()
—
5. 現場のトラブルシューティングTips（シニアからの助言）
最後に、実際のインフラ運用やAPI開発の現場で、HTTP/2 PINGに関して陥りがちな罠と対策を共有しよう。
1. アイドルタイムアウトの誤解
HTTP/2コネクションは、マルチプレクシングによって1つのTCPコネクションを長時間維持し続ける。ロードバランサー（ALBやNginx、Envoyなど）やファイアウォールには、無通信状態が続くとコネクションを強制切断する「アイドルタイムアウト」が存在する。
- 対策: アプリケーション側やクライアントライブラリで、定期的にこのHTTP/2 PINGフレームを送信（ハートビート）するように設定せよ。これにより、トラフィックが流れていないアイドリング時でもNATやLBのセッションタイマーをリフレッシュし、予期せぬ「Connection reset by peer」を防ぐことができる。
2. サーバー側のPING過剰負荷対策（Pings Flood）
悪意あるクライアントや、バグったクライアントが秒間数千のPINGフレームを送りつけてサーバーのCPUリソースを枯渇させる攻撃（Pings Flood）が存在する。
- 対策: NginxやEnvoyなどのリバースプロキシ、あるいはgRPC/HTTP/2サーバーを利用する際は、`http2_max_requests` や `http2_ping_ack_interval` といった設定値を適切にチューニングし、過剰なPINGを検知・ドロップできるようにインフラ側を備えておくこと。
—
まとめ
HTTP/2のPINGフレームは、単なる「つながっているかの確認（死活監視）」以上のポテンシャルを秘めている。
マルチプレクシングの恩恵を一切邪魔せず、TCPレイヤーよりもアプリケーションに近いレイヤーで、正確なネットワークの健康状態とRTTを可視化してくれる極上のツールだ。
「なぜかAPIのレスポンスが揺らぐ」
「コネクションが勝手に切れる原因がわからない」
そんな謎に直面したときは、レイヤーを少し下げて、バイナリの海を流れるPINGフレームの息吹に耳を澄ませてみてほしい。きっと、真実を教えてくれるはずだ。
コメント