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

HTTP/2 PINGフレームの真実：パケットの往来から読み解く生存確認とRTT測定の極意

ネットワークの最前線でインフラやAPI設計に向き合っていると、「なぜこのコネクションは突然切断されるのか」「このレイテンシーの揺らぎはどこから来るのか」という泥臭い問題に必ず直面する。

HTTP/1.1の時代、私たちはコネクションの生存確認（キープアライブ）や遅延測定において、TCP層のキープアライブやHTTPヘッダーのやり取りに頼りきっていた。しかし、1本のTCPコネクション上で複数のリクエストとレスポンスを同時に多重化（マルチプレクシング）するHTTP/2の世界では、ゲームのルールが根本から変わった。

今回は、HTTP/2のバイナリフレーミングレイヤーの裏側で密かに、しかし極めて重要な役割を果たしている「PINGフレーム」にスポットを当てる。RFC 7540の仕様の紐解きから、実務でのRTT（往復遅延時間）測定、さらには現場のトラブルシューティングで使える実践知まで、シニアエンジニアの視点で徹底的に解説しよう。

—

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

HTTP/2はTCPの上で動作する。それなら「TCPのキープアライブや、HTTP/1.1のコネクション管理で十分ではないか」という疑問が湧くのは当然だ。だが、ここにはHTTP/2特有のアーキテクチャ上のジレンマがある。

マルチプレクシングの弊害とアプリケーション層の孤独

HTTP/2の最大の武器は、1本のTCPコネクション上で無数の「ストリーム」を並行して流せることだ。これにより、いわゆるヘッド・オブ・ライン・ブロッキング（Head-of-Line Blocking）がアプリケーション層で解消された。

しかし、考えてみてほしい。1本のTCPコネクションが何時間も「アイドル状態（リクエストが流れていない状態）」になったとき、何が起きるだろうか？
途中に存在するファイアウォールやNATルーターは、トラフィックが途絶えると容赦なくステートテーブルからそのコネクションを削除（タイムアウト）してしまう。

TCP層にもキープアライブ機能はあるが、OSのデフォルト設定では数時間単位と非常に緩慢であり、細かなアプリケーションの要求には耐えられない。また、HTTP/2のコネクション全体（セッション）の健全性を、特定のアプリケーション用ストリームに依存させずに測る仕組みがどうしても必要だった。

ここで登場するのが、ストリームID `0` を使ってやり取りされるPINGフレームだ。特定のストリームに紐づかない、HTTP/2セッション全体の「心拍確認」である。

—

2. RFC 7540が定めるPINGフレームの構造とACKの仕組み

HTTP/2のすべての通信は「フレーム」という単位でバイナリデータとして流れる。PINGフレームの構造は非常にシンプルかつ洗練されている。

フレームの基本フォーマット

長さ（Length）: 固定で `8オクテット（8バイト）`
タイプ（Type）: `0x6`（PING）
フラグ（Flags）: `0x01`（ACK）または `0x00`（なし）
ストリーム識別子（Stream Identifier）: 必ず `0x0`（コネクション全体を指す）
ペイロード: 任意の `8バイトのデータ`

ACKフラグによる往復確認のダンス

PINGフレームの挙動は、ネットワークエンジニアお馴染みのICMP Echo（Ping）と非常によく似ているが、HTTP/2レイヤーで完結する点が異なる。

1. 送信側（クライアントまたはサーバー）:

ストリームID `0`、フラグ `0x00`（無印）で、8バイトのランダムなペイロードを詰めたPINGフレームを送出する。この瞬間のタイムスタンプをメモリ上に記録しておく。

2. 受信側:

PINGフレームを受け取ると、受け取った8バイトのペイロードをそのままコピーし、フラグに `ACK (0x01)` を立てて即座に応答（返送）しなければならない。

3. 送信側（確認）:

ACKフラグが立ったPINGフレームを受信したら、送信時に記録したタイムスタンプとの差分を計算する。これで正確なRTT（Round Trip Time）が算出できるというわけだ。

> 実務のTips： 受信側が「受け取ったペイロードをそのままオウム返しにする」という仕様になっているのは、送信側が複数のPINGを同時に投げた際、どの送信に対する応答（ACK）なのかを8バイトのデータで一意に識別するためである。非常に理にかなった設計だ。

—

3. 通信フロー（シーケンス）のイメージ

HTTP/2コネクション上で、クライアントがサーバーに対してPINGを投げ、RTTを測定する一連の流れをシーケンスとして視覚化してみよう。

4. 実務での活用：コードとデバッグの実践例

では、このHTTP/2の仕組みを私たちの開発やインフラ運用でどのように活かせるのか。残念ながら、一般的なブラウザの `fetch()` APIや標準的なアプリケーションコードから「直接PINGフレームを送信してACKを待つ」ような低レイヤーの操作を露出している言語やランタイムはほとんどない（セキュリティや不正利用を防ぐため、HTTP/2の接続管理はランタイムやブラウザの底深いところで隠蔽されている）。

しかし、Go言語などの低レイヤーを叩ける言語での実装や、nghttp2などのツールを用いたデバッグ手法を知ることで、インフラの挙動を深く理解し、トラブルシューティングに役立てることができる。

パターンA: Go言語を用いたHTTP/2クライアントでのコネクション監視・Ping送信

Go言語の `net/http` および `golang.org/x/net/http2` パッケージを使うと、HTTP/2の接続（ClientConn）に対して直接Pingを打つことができる。これは、マイクロサービスのバックエンド間通信の監視などで極めて有効だ。

package main

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

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

func main() {
// 接続先のターゲット（HTTP/2対応サーバー）
addr := “example.com:443”

// 1. TCP接続を確立し、TLSでラップする
tcpConn, err := net.DialTimeout(“tcp”, addr, 5time.Second)
if err != nil {
panic(err)
}
defer tcpConn.Close()

tlsConn := tls.Client(tcpConn, &tls.Config{
ServerName: “example.com”,
NextProtos: []string{“h2”}, // HTTP/2 (h2) をネゴシエーション
})
if err := tlsConn.Handshake(); err != nil {
panic(err)
}
defer tlsConn.Close()

// 2. http2のTransport層オブジェクトを生成
t := &http2.Transport{}

// 3. HTTP/2のClientConn（コネクション実体）を初期化
// ここでTCP/TLSコネクションがHTTP/2のセッションに結びつけられる
cc, err := t.NewClientConn(tlsConn)
if err != nil {
panic(err)
}

// 4. PINGフレームを送信してRTTを測定する
ctx, cancel := context.WithTimeout(context.Background(), 3time.Second)
defer cancel()

fmt.Println(“HTTP/2 PINGフレームを送信中…”)
start := time.Now()

// Pingメソッドは内部でストリーム0を使ったPINGフレームの送受信とACK待ちを行う
err = cc.Ping(ctx)
if err != nil {
fmt.Printf(“PINGの送信または応答に失敗しました: %v\n”, err)
return
}

rtt := time.Since(start)
fmt.Printf(“成功！ HTTP/2 RTT: %d ms\n”, rtt.Milliseconds())
}

パターンB: nghttp2コマンド（nghttp）によるパケット・フレーム確認

インフラエンジニアとして現場で最も頼りになるのは、C言語ベースのHTTP/2クライアント実装である `nghttp2` パッケージに含まれる `nghttp` コマンドだ。

`-v`（verbose）オプションを付与して通信を行うと、ブラウザのデベロッパーツールでも見えない「生のHTTP/2フレーム」のやり取りが標準出力にダンプされる。

nghttp -v https://http2.golang.org/

実行結果のログ（一部抜粋）には、以下のようなフレームの往来が手に取るように現れる。

[ 0.038] send SETTINGS frame
[ 0.038] send WINDOW_UPDATE frame
[ 0.039] recv SETTINGS frame
…
ここで定期的な生存確認やストリームの制御フレームが流れる

さらに、独自のデバッグスクリプトやパケットキャプチャ（Wireshark）を使用する場合、Wiresharkのフィルターに `http2.type == 6` を指定すれば、ネットワーク上に流れるすべてのPINGフレームをピンポイントでキャプチャし、ACKフラグの立っているパケットと見比べることで、ロードバランサーやリバースプロキシ（EnvoyやNginxなど）が適切に生存確認に応答しているかをミリ単位で検証できる。

—

5. 現場のシニアが教える「ハマりどころ」とトラブルシューティング

最後に、実務の現場でHTTP/2のPINGやコネクション管理に絡んで発生しがちなトラブルと、その処方箋を共有しよう。

トラブル1: アイドルタイムアウトによる突然のコネクション切断

症状: APIサーバーへのリクエストが数分間途切れた後、次のリクエストが必ず「Connection Reset」や「RST_STREAM」で失敗する。
原因: 途中のロードバランサー（ALBやCloudflareなど）のアイドルタイムアウト（例: 60秒）が、アプリケーションのキープアライブ設定よりも短いため、ロードバランサー側からコネクションが勝手に切断されている。
対策:
サーバー側およびクライアント側のHTTP/2設定で、HTTP/2 PINGの送信間隔（KeepAlive Ping Interval）を明示的に短く設定する（例: 30秒に1回PINGを送るようにし、ルーターのタイムアウトよりも前に必ずトラフィックを流す）。
Go言語の `http2.Transport` や各種 gRPC クライアントライブラリには、`PermitWithoutStream` や `KeepAlivePing` といったパラメータが存在するので、アイドル状態のコネクションを維持するために必ずチューニングを入れること。

トラブル2: 過剰なPINGによるDDoS判定・リソース枯渇

症状: クライアント側があまりに高頻度（例: 1秒に10回など）でPINGを送り続けた結果、サーバー側のCPU負荷が跳ね上がり、最悪の場合「Excessive PINGs（過剰なPING）」としてHTTP/2の仕様違反（Goawayフレームの送信）で強制切断される。
原因: ネットワークの健全性を気にするあまり、PINGを過剰に撃ちすぎてセッションがスパム認定された状態。
対策: PINGはあくまで「数分に1回」あるいは「コネクションが一定時間アイドルになったときのみ」に絞るべきだ。RFC 7540でも、PINGフレームの乱用に対するレートリミットや警告が言及されている。

—

まとめ

HTTP/2のPINGフレームは、目立たない存在ではあるものの、現代の高速で複雑なWebアプリケーションの足回りを支える「縁の下の力持ち」だ。

単なる「生存確認」という言葉の裏には、マルチプレクシング環境下でもコネクションの生死を正確に見極め、ミリ秒単位のRTTを計測するための洗練されたバイナリプロトコルのロジックが詰まっている。

インフラの挙動が怪しいとき、アプリのレイテンシーに説明のつかない揺らぎがあるとき――。パケットの底で何が起きているのかを想像し、フレーミングレイヤーにまで踏み込んで思考する。それこそが、私たちエンジニアを真のトラブルシューターへと引き上げてくれるはずだ。