【実務・中級編】HTTP/2におけるPINGフレームによる生存確認とRTT測定 – HTTPプロトコル・通信規格実践ガイド

HTTP/2の「見えない絆」：PINGフレームで握るコネクションの生存確認とRTT計測

Web APIの設計や、大規模なインフラストラクチャの運用に携わっていると、一度は頭を悩ませるのが「コネクションの寿命と状態管理」だ。

HTTP/1.1の時代、私たちはTCPのキープアライブや、HTTPヘッダーの `Connection: keep-alive` に頼り切っていた。しかし、1本のTCPコネクション上で複数のリクエストとレスポンスを同時に、かつ双方向で多重化（マルチプレクシング）するHTTP/2の世界では、話がまったく違ってくる。

「いま、このコネクションは本当に生きているのか？」
「パケットがクライアントとサーバーの間を往復するのに、何ミリ秒かかっているのか？」

これをHTTP/2のレイヤーで正確に、かつ軽量に測定するために用意されたのが `PING` フレーム だ。今回は、教科書的な仕様のなぞり読みではなく、現場のシニアエンジニアとして、パケットの挙動から実装・デバッグ手法まで、この「見えない絆」の正体を徹底的に解き明かしていこう。

—

1. なぜHTTP/2にPINGフレームが必要なのか？

HTTP/2（RFC 7540）は、TCPという信頼性の高いトランスポート層の上に構築されている。TCP自体にも `Keep-Alive` やセグメントの再送制御があるのだから、わざわざアプリケーション層（HTTP/2レイヤー）でPINGを撃つ必要なんてないのではないか——そう思うかもしれない。

だが、現場の現実はシビアだ。

1. 中間デバイス（NAT/ロードバランサー/プロキシ）の存在:
途中に挟まるファイアウォールやALB（Application Load Balancer）は、トラフィックがしばらく流れないと、独自のアイドルタイムアウトでTCPコネクションを容赦なく切断する。TCP層が「生きている」と錯覚していても、中継器がすでにセッションを忘れていることは日常茶飯事だ。
2. TCPキープアライブの限界:
OSの設定に依存するTCPのキープアライブは、デフォルトでは検知に数時間かかることもあり、リアルタイム性が求められるWeb APIやストリーミングの維持には向かない。
3. 正確なRTT（往復時間）の把握:
HTTP/2のマルチプレクシング性能を最大限に引き出すためには、現在のネットワーク遅延（RTT）を正確に把握し、ストリームの優先度制御やタイムアウト設計にフィードバックする必要がある。

こうした課題に対し、HTTP/2はTCPコネクションを切断することなく、任意のタイミングで、かつ極めて軽量に生存確認とRTT測定を行える「PINGフレーム」を標準装備した。

—

2. PINGフレームの構造と仕様（RFC 7540）

HTTP/2のすべての通信は「フレーム」という単位で流れる。PINGフレームの仕様を、現場のエンジニアとして押さえておくべきポイントに絞って整理しよう。

フレームの基本構造

タイプ (Type): `0x6`（PING）
フラグ (Flags):
`0x01 (ACK)`: PINGに対する応答であることを示すフラグ。これが立っていないものは「送信要求」、立っているものは「応答（Pong）」となる。
ストリーム識別子 (Stream Identifier): 常に `0`（ゼロ）。
ここが非常に重要だ。PINGは特定のストリームではなく、コネクション全体（接続そのもの）の健全性をチェックするため、ストリームIDには必ず `0` が指定される。
ペイロード (Payload): 必ず 8オクバイト（64ビット）の固定長。

この8バイトのペイロードこそが、RTT測定のキモとなる。送信側は、この8バイトに適当なランダム値やタイムスタンプを詰めて送信する。受信側は、その内容を1バイトたりとも改変せず、そのままそっくりコピーして `ACK` フラグを立てたPINGフレームを折り返す義務があるのだ。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (24) | Type (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flags (8)¶ |P| Stream Identifier (31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Opaque Data |
| (8 octets) |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

—

3. 通信フロー（シーケンス）とRTT計測のからくり

クライアント（あるいはサーバー）がPINGを送信してから、ACK付きのPINGが戻ってくるまでのシーケンスは非常にシンプルだ。

厳格な応答ルール

RFC 7540では、「PINGフレームを受信した側は、他のどのフレームよりも優先して（あるいは速やかに）ACKレスポンスを返さなければならない」と規定されている。
これにより、サーバーが重いリクエスト処理（CPUバウンドな処理など）で混雑している状態であっても、ネットワーク層・HTTP/2層の健全性（死活監視）を正確に切り分けて測定できるわけだ。

—

4. 実務での検証：PythonによるHTTP/2 PINGの観察

理論だけではインフラエンジニアの血は騒がない。実際にPythonの `h2` ライブラリ（HTTP/2ステートマシンを低レベルで操作できるライブラリ）を用いて、コネクション確立からPINGの送受信、RTT計測を行うスクリプトを見てみよう。

実務でデバッグツールを作る際や、カスタムの死活監視エージェントを自作する際のベースになるコードだ。

import socket
import ssl
import time
from h2.connection import H2Connection
from h2.config import H2Configuration

def check_http2_ping(host: str, port: int = 443):
# 1. 通常のTCPソケットを生成し、TLSハンドシェイクを行う
context = ssl.create_default_context()
context.set_alpn_protocols([‘h2′]) # HTTP/2 (h2) をネゴシエーションに指定

sock = socket.create_connection((host, port))
ssl_sock = context.wrap_socket(sock, server_hostname=host)

print(f”[+] Connected to {host}:{port} with ALPN: {ssl_sock.selected_alpn_protocol()}”)

# 2. HTTP/2 コネクションの初期化 (クライアントとして動作)
config = H2Configuration(client_side=True)
conn = H2Connection(config=config)
conn.initiate_connection()

# 初期化フレーム（SETTINGSなど）を送信
ssl_sock.sendall(conn.data_to_send())

# 3. PINGフレーム用の8バイトのデータ（Opaque Data）を作成
# ここでは現在のタイムスタンプを8バイトのバイナリ（Big EndianのQ型）に詰める
ping_payload = int(time.time() 1000).to_bytes(8, byteorder=’big’)

print(f”[>] Sending HTTP/2 PING frame with payload: {ping_payload.hex()}”)
t1 = time.perf_counter() # 送信前の高精度タイマーを取得

# PINGフレームをキューイングして送信
conn.ping(ping_payload)
ssl_sock.sendall(conn.data_to_send())

# 4. 応答の受信ループ
ssl_sock.settimeout(3.0) # 3秒でタイムアウト
try:
while True:
data = ssl_sock.recv(65535)
if not data:
break

events = conn.receive_data(data)
for event in events:
# PINGのACKイベントをキャッチ
if isinstance(event, __import__(‘h2.events’, fromlist=[‘PingAcknowledged’]).PingAcknowledged):
t2 = time.perf_counter() # 受信時の高精度タイマー
rtt_ms = (t2 – t1) 1000.0

print(f”[<] Received PING ACK!") print(f" - Returned Payload: {event.payload.hex()}") print(f" - Measured RTT : {rtt_ms:.3f} ms") # 正常に計測できたのでループを抜ける return # サーバー側からのSETTINGSやWINDOW_UPDATEに対する返信があれば送信 to_send = conn.data_to_send() if to_send: ssl_sock.sendall(to_send) except socket.timeout: print("[-] Error: PING ACK timeout. Connection might be dead or blocked.") finally: ssl_sock.close() if __name__ == "__main__": # 例として nghttp2.org などのHTTP/2対応サーバーを指定 check_http2_ping("nghttp2.org", 443)

このコードのポイント

ALPN（Application-Layer Protocol Negotiation）: TLSハンドシェイクの時点で `h2` をネゴシエーションしておかないと、サーバー側がHTTP/2を受け入れてくれない。
`perf_counter()` の使用: ネットワークのRTTはミリ秒単位、あるいはサブミリ秒単位の世界であるため、Pythonの通常の `time.time()` ではなく、OSの高精度パフォーマンスカウンターを利用して正確な差分を算出している。

—

5. インフラ運用の現場で役立つ実践Tipsとトラブルシューティング

最後に、実際のプロダクション環境やロードバランサーの背後でHTTP/2を運用する際に見落とされがちな「実務の知見」をいくつか共有しよう。

1. 洪水攻撃（Ping Flood）対策に注意

悪意ある攻撃者が、大量のPINGフレームを送りつけてサーバーのCPUリソース（ACKを返す処理）を枯渇させる 「Ping Flood」 というDDoS攻撃手法が存在する。
そのため、Nginx、Envoy、HAProxy、あるいはクラウドベンダーのALBなどのリバースプロキシ側では、「一定時間内に処理するPINGフレームの数に上限（レートリミット）」を設けていることが多い。
自前でクライアント側の監視ツールやヘルスチェッカーを実装する際、短すぎる間隔（例: 10msごとなど）でPINGを連射すると、プロキシ側に「攻撃」と誤認され、コネクションを強制切断（RST_STREAM / GOAWAY）される原因になるので注意してほしい。適切な生存確認間隔は数秒〜数十秒に1回が妥当だ。

2. デバッグには `nghttp` や Wireshark が最強

Pythonを書くまでもなく、手元でHTTP/2のフレーム構造をサクッと確認したいときは、`nghttp2` パッケージに含まれる `nghttp` コマンドが非常に役立つ。

-v オプションを付けることで、送信・受信されるすべてのフレーム（SETTINGS, HEADERS, PINGなど）が標準出力にダンプされる
nghttp -v https://example.com/

また、Wiresharkでパケットキャプチャを取る際は、ブラウザやcurlのSSLキー（SSL Key Log）を環境変数 `SSLKEYLOGFILE` に設定しておくことで、暗号化されたHTTP/2のフレーム内部（PINGの中身やペイロードの8バイト）まで丸裸にして解析できるようになる。これは難解なネットワークトラブルを切り分ける際の最後の切り札だ。

—

まとめ

HTTP/2のPINGフレームは、単なる「生存確認のためのオマケ機能」ではない。マルチプレクシングという高度な多重化通信を、背後で支え続ける「信頼の心拍数」そのものだ。

コネクション全体（Stream ID: 0）の生死を、TCP層ではなくHTTP/2レイヤーで正確に捉える。
8バイトのペイロードとACKフラグにより、オーバーヘッドを最小限に抑えつつ高精度なRTTを算出する。
プロキシのタイムアウト対策や、カスタムヘルスチェックの設計において強力な武器となる。

日々のインフラ運用やAPI設計において、「通信が見えない」と感じたときは、ぜひこのパケットレベルの挙動に思いを馳せてみてほしい。ネットワークの奥底で、PINGフレームが正しく往復している姿が目に浮かぶはずだ。