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

パケットの鼓動を聞け：HTTP/2 PINGフレームが明かすネットワークの真実

Webの高速化とモダナイゼーションの旗手としてHTTP/2が普及して久しい。マルチプレクシングによる単一TCPコネクション上の多重化、HPACKによるヘッダーの効率的な圧縮など、アプリケーション層のパラダイムシフトは数々のレイテンシー問題を過去のものにした。

しかし、インフラストラクチャの現場に立つアーキテクトやテックリードであれば、誰もが知っているジレンマがある。
「単一のTCPコネクションに多重化を依存するがゆえに、そのコネクションの健康状態や微細な遅延の揺らぎが、すべてのストリームの運命を握る」という事実だ。

TCP層のキープアライブ（Keep-Alive）やTCPセグメントとしての`ACK`は、あくまでトランスポート層の生存確認に過ぎない。アプリケーション層であるHTTP/2のセッションが、プロキシやロードバランサー、そしてクライアントの間で本当に健全にルーティングされているかを知るには、よりレイヤーの高い、そしてより洗練されたメカニズムが必要となる。

それが、HTTP/2のPINGフレームだ。

今回は、この小さな8バイトのペイロードに隠されたパケットレベルの挙動、RTT（往復時間）測定の妙、そしてインフラエンジニアが知るべき実践的なチューニングとセキュリティの境界線について、徹底的に解き明かしていこう。

—

1. PINGフレームの解剖学：8バイトのペイロードに宿る厳格なルール

HTTP/2のフレームは、すべてのタイプにおいて一律9バイトの共通ヘッダーから始まる。しかし、その中でも`PING`フレーム（Type: `0x6`）は、極めて特異で美しい構造を持っている。

フレーム構造の物理的レイアウト

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) |
+———————————————–+—————+
|X| Stream Identifier (31) |
+-+-+——————————————-+
| Payload (64 bits / 8 bytes) …
+—————————————————————+

1. Length (24ビット): `0x000008`（固定で8バイト）
2. Type (8ビット): `0x06`（PING）
3. Flags (8ビット):

• `0x00`: なし
• `0x01`: `ACK` フラグ（これが極めて重要）

4. Reserved (1ビット) + Stream Identifier (31ビット): 必ず `0x00000000`（ストリームID 0）

PINGフレームの最大の特徴は、ストリームIDに必ず `0` が指定される点にある。これは特定のアプリケーション・ストリームに依存せず、コネクション全体（Connection-Level）の制御フレームであることを意味する。

応答の厳格なルール：ACKフラグの義務

RFC 7540（HTTP/2仕様）において、PINGフレームの受信側には絶対的な義務が課されている。

> “Receivers of a PING frame that does not contain an ACK flag setLoading an ACK flag MUST send a response receiving a PING with this flag set.”
> （ACKフラグが立っていないPINGフレームを受信した側は、速やかにACKフラグを立てたPINGレスポンスを返さなければならない）

• 送信側（Sender）: 任意の8バイトのデータ（例えば、タイムスタンプや乱数）をペイロードに詰めて送信する。この瞬間からタイマーが回り始める。
• 受信側（Receiver）: 受信したPINGフレームのペイロード（8バイト）をそのままコピーし、フレームヘッダーのFlagsに `ACK` (`0x01`) をセットして即座にエコーバックする。

この「受信したペイロードを丸ごと送り返す」という極めてシンプルな仕組みこそが、RTT測定とコネクション生存確認の精度の高さを生み出している。

—

2. ネットワークトポロジとRTT測定：なぜTCP Keep-Aliveでは不十分なのか

インフラエンジニアであれば、「TCPのKeep-Aliveがあるのだから、アプリケーション層でわざわざPINGを送る必要はないのではないか？」という疑問を持つはずだ。

ここに、現代のクラウドネイティブ・アーキテクチャにおける深い罠がある。

L7ロードバランサー（ALB/Envoy/Nginx）の存在

現代のWebトラフィックは、直にオリジンサーバーに到達することは稀だ。多くの場合、次のようなパスを辿る。

[Client] === (HTTP/2 TLS) ===> [Envoy / L7 LB] === (gRPC / HTTP/2) ===> [Backend Pod]

このとき、ClientとEnvoyの間で張られたHTTP/2コネクションと、EnvoyとBackendの間で張られたHTTP/2コネクションは完全に別物である。
TCPのKeep-Aliveは「TCPコネクションの生存」しか保証しない。もし途中のL7プロキシやファイアウォールがアイドルタイムアウトによってセッションをサイレント切断（Drop）した場合、TCP層は「まだ生きている」と勘違いし続け、アプリケーション層のリクエストが突如として`RST`やタイムアウトエラーに見舞われることになる。

PINGによる正確なRTT（往復時間）の算出

PINGフレームのペイロードに、送信時の高精度タイムスタンプ（例: `clock_gettime` によるナノ秒単位の値など）をエンコードして送信したとしよう。

Client Server
| |
|— PING (Payload: [Timestamp_A], ACK=0) ————->| (即座に処理)
| |
|<-- PING (Payload: [Timestamp_A], ACK=1) --------------| | | 受信側がペイロードをそのまま返送するため、クライアント側は `現在時刻 - Timestamp_A` を計算するだけで、純粋なHTTP/2レイヤーでの往復遅延（RTT）をミリ秒・ナノ秒単位で計測できる。

この情報は、単なる死活監視（Health Check）にとどまらない。

• 動的なルーティング選定: 複数のHTTP/2アップストリームコネクションがある場合、直近のPING RTTが最も低いコネクションに重いリクエスト（大容量のファイル転送や重いgRPCクエリなど）を優先配分する。
• 輻輳制御の補助: TCPの輻輳ウィンドウ（cwnd）の挙動を補完する形で、アプリケーション層の遅延悪化をいち早く検知する。

—

3. 実践：Go言語によるHTTP/2 PING制御とRTT計測の実装アプローチ

理論を理解したところで、実際にプログラムやプロキシの内部でどのように扱われているかを見てみよう。Go言語の標準ライブラリ（`golang.org/x/net/http2`）は、低レイヤーのHTTP/2フレームを直接操作するための強力なフックを提供している。

以下は、確立されたHTTP/2コネクションに対して自前でPINGフレームを送信し、そのRTTを測定する診断ツールの概念コードだ。

package main

import (
“context”
“crypto/tls”
“fmt”
“log”
“net”
“time”

“golang.org/x/net/http2”
)

func main() {
target := “example.com:443”

// 1. TCP接続の確立
tcpConn, err := net.DialTimeout(“tcp”, target, 5time.Second)
if err != nil {
log.Fatalf(“TCPコネクションの確立に失敗: %v”, err)
}
defer tcpConn.Close()

// 2. TLSハンドシェイクの実行 (ALPNで “h2” をネゴシエーション)
tlsConfig := &tls.Config{
ServerName: “example.com”,
NextProtos: []string{“h2”},
}
tlsConn := tls.Client(tcpConn, tlsConfig)
if err := tlsConn.Handshake(); err != nil {
log.Fatalf(“TLSハンドシェイクに失敗: %v”, err)
}
defer tlsConn.Close()

// 3. HTTP/2クライアントコネクション（Framer）の初期化
// net.Connをラップして、低レイヤーのフレーム送受信を可能にする
framer := http2.NewFramer(tlsConn, tlsConn)

// HTTP/2接続の前提となるクライアント側セッティング（初期接続ハンドシェイク）の送信
if err := framer.WriteSettings(); err != nil {
log.Fatalf(“SETTINGSフレームの送信に失敗: %v”, err)
}

// 4. PINGフレーム用の8バイトのペイロードを作成
// ここでは現在のUnixエポックタイムスタンプを8バイトに埋め込む
var pingPayload [8]byte
nowNano := time.Now().UnixNano()
for i := 0; i < 8; i++ { pingPayload[i] = byte(nowNano >> uint(8i))
}

// 5. ACKフラグ=0のPINGフレームを送信
log.Println(“PINGフレームを送信します…”)
sentTime := time.Now()
if err := framer.WritePing(false, pingPayload); err != nil {
log.Fatalf(“PINGフレームの送信に失敗: %v”, err)
}

// 6. 応答フレームの読み込みループ
// 実運用では別ゴルーチンで非同期に処理する
if err := tlsConn.SetReadDeadline(time.Now().Add(3 time.Second)); err != nil {
log.Fatal(err)
}

for {
frame, err := framer.ReadFrame()
if err != nil {
log.Fatalf(“フレームの読み込みエラー: %v”, err)
}

// 受信したフレームがPINGであり、かつ ACK フラグが立っているか検証
if p, ok := frame.(http2.PingFrame); ok {
if p.Flags.Has(http2.FlagPingAck) {
rtt := time.Since(sentTime)
fmt.Printf(“[成功] PING ACKを受信しました！ RTT: %v\n”, rtt)
fmt.Printf(“返送されたペイロード: 0x%x\n”, p.Data)
break
}
}
}
}

このコードは、HTTP/2の生（Raw）のレイヤーがいかにシンプルであるかを示している。フレーム構造さえ理解していれば、言語を問わず、ネットワークの健全性を完全にプログラムのコントロール下に置くことができる。

—

4. パフォーマンスチューニングとセキュリティの境界線

PINGフレームは非常に強力なツールである一方、その運用を誤ると、パフォーマンスの劣化や、悪意ある攻撃の踏み台（DDoSの温床）になりかねない。プロフェッショナルとして押おくべきパラメータチューニングとセキュリティの勘所を整理する。

1. アイドルタイムアウトとPINGの頻度（Keep-Aliveの最適化）

ロードバランサーやリバースプロキシ（Nginx, Envoy等）の多くは、デフォルトでコネクションのアイドルタイムアウトを60秒〜75秒程度に設定している。
ファイアウォールやNATルーターがこれより短い時間でステートテーブルからエントリを削除してしまう環境では、「30秒に1回」などの適切な間隔でPINGフレームを能動的に送信する（HTTP/2 Keep-Alive）ことが、突発的なコネクション切断エラーを防ぐ唯一の現実的な解となる。

ただし、やみくそにPINGの頻度を上げることは禁物だ。数万〜数百万の同時接続を持つグローバルスケールのサーバー群において、無意味なPINGを数秒おきに送信し続けることは、無駄なCPUサイクルと帯域（シグナリングオーバーヘッド）を消費する「自作自演のDDoS」に他ならない。

2. HTTP/2 PINGフロッド攻撃（CVE-2019-9512）の脅威

HTTP/2の仕様において最も痛烈な教訓となったのが、2019年に発覚した一連の脆弱性、通称「HTTP/2 DoS（フレームストーム系）」である。
その筆頭が CVE-2019-9512（Ping Flood） だ。

• 攻撃のメカニズム: 悪意あるクライアントが、ACKフラグの立っていない膨大な数のPINGフレームをサーバーに連続送信する。
• サーバー側の挙動: 標準的な実装では、受信したすべてのPINGに対して「即座にACK付きのPINGを返さなければならない」というルールに従い、サーバーのリソース（CPUおよび出力バッファ）が応答の生成で完全に埋め尽くされる。結果として、正当なユーザーのリクエストが処理できなくなる（CPU exhaustion）。

堅牢なインフラストラクチャにおける防御策

Nginx、Envoy、あるいはGolangやNode.jsのHTTP/2コア実装では、この攻撃を防ぐために厳格なレートリミット（Rate Limiting）が組み込まれている。

• 未処理PINGのキュー制限: サーバー側で、処理しきれずに溜まったPINGリクエストの数にしきい値を設ける（例: 最大100個）。これを超えた場合のPINGは即座にコネクション切断（`RST_STREAM` または `GOAWAY`）の対象とする。
• 低速・過剰なトラフィックの遮断: 一定時間内に許容されるコントロールフレームの比率を監視し、異常値を検知した瞬間にTCPコネクションを強制切断する。

—

5. まとめ：パケットの細部を知る者がネットワークを制す

HTTP/2のPINGフレームは、一見すると地味な8バイトの制御信号にすぎない。しかし、その背後には「単一コネクション上の多重化」というモダナイゼーションを支えるための、極めて精緻な生存確認と遅延測定の哲学が宿っている。

• TCPではなくアプリケーション層の健全性を監視する
• 受信したペイロードのエコーバックによる高精度なRTT測定
• 過剰な送信によるオーバーヘッドと、PINGフロッド攻撃への警戒

これらを深く理解し、適切なパラメータチューニングと監視を行うことこそが、真の意味で「落ちない、速い、セキュアな」次世代ネットワークインフラを構築するための必須条件なのだ。

パケットの鼓動に耳を澄ませ。ネットワークは、常にその内部で雄弁に語りかけている。