キープアライブ
gRPCでHTTP/2 PINGベースのキープアライブを使用する方法。
キープアライブ
概要
HTTP/2 PINGベースのキープアライブは、データが転送されていない場合でもHTTP/2接続を維持する方法です。これは、接続の相手側にPINGフレームを定期的に送信することによって行われます。HTTP/2キープアライブは、HTTP/2接続のパフォーマンスと信頼性を向上させることができますが、キープアライブの間隔を慎重に構成することが重要です。
注意
関連するが別の懸念事項として[ヘルスチェック]があります。ヘルスチェックは、接続のみに関するキープアライブに対して、サーバーがサービスが正常であるかどうかを通知できるようにします。背景
TCPキープアライブは、接続を維持し、壊れた接続を検出するためのよく知られた方法です。TCPキープアライブが有効になっている場合、接続の両側が冗長パケットを送信できます。相手側からACKが送信されると、接続は良好と見なされます。繰り返しの試行後もACKが受信されない場合、接続は切断されたと見なされます。
TCPキープアライブとは異なり、gRPCはHTTP/2を使用しており、ラウンドトリップ時間、帯域幅遅延積の推定、または接続のテストに使用できる必須のPINGフレームを提供します。TCPキープアライブのインターバルとリトライは、トランスポートが信頼できるためPINGにはあまり適用されません。そのため、gRPC PINGベースのキープアライブの実装ではタイムアウト（インターバル * リトライに相当）に置き換えられます。
注意
サービス所有者がキープアライブをサポートする必要はありません。クライアントの作成者は、特定のクライアント側の設定が受け入れられるかどうかについて、サービス所有者と調整する必要があります。サービス所有者は、キープアライブをまったく受信するかどうかを含め、サポートしてもよいものを決定します（サービスがキープアライブをサポートしていない場合、最初のいくつかのキープアライブPINGは無視され、サーバーは最終的にtoo_many_pingsのASCIIコードに等しいデバッグデータを含むGOAWAYメッセージを送信します）。キープアライブの設定が呼び出しに与える影響
キープアライブは、迅速な応答を伴う単項RPCではトリガーされる可能性が低くなります。キープアライブは主に、長時間のRPCがある場合にトリガーされ、キープアライブチェックに失敗して接続が閉じられた場合は失敗します。
ストリーミングRPCの場合、接続が閉じられると、進行中のRPCは失敗します。呼び出しがデータをストリーミングしている場合、ストリームも閉じられ、まだ送信されていないデータは失われます。
警告
DDoS攻撃を回避するために、キープアライブ設定を設定する際には注意することが重要です。したがって、呼び出しなしでキープアライブを有効にすることを避け、クライアントがキープアライブを1分未満に設定することを避けることが推奨されます。キープアライブが役立つ一般的な状況
gRPC HTTP/2キープアライブは、次のようなさまざまな状況で役立ちます。
- プロキシまたはロードバランサーによってアイドルと見なされる可能性がある長時間の接続でデータを送信する場合。
- ネットワークの信頼性が低い場合（たとえば、モバイルアプリケーション）。
- 長期間の非アクティブ状態の後に接続を使用する場合。
キープアライブ設定の仕様
| オプション | 利用可能性 | 説明 | クライアントのデフォルト | サーバーのデフォルト |
|---|---|---|---|---|
KEEPALIVE_TIME | クライアントとサーバー | PINGフレーム間のミリ秒単位の間隔。 | INT_MAX（無効） | 7200000（2時間） |
KEEPALIVE_TIMEOUT | クライアントとサーバー | PINGフレームが承認されるまでのミリ秒単位のタイムアウト。送信者がこの時間内に確認応答を受信しなかった場合、接続を閉じます。 | 20000（20秒） | 20000（20秒） |
KEEPALIVE_WITHOUT_CALLS | クライアント | 未処理のストリームがない状態で、クライアントからキープアライブpingを送信することが許可されていますか。 | 0（false） | N/A |
PERMIT_KEEPALIVE_WITHOUT_CALLS | サーバー | 未処理のストリームがない状態で、クライアントからキープアライブpingを送信することが許可されていますか。 | N/A | 0（false） |
PERMIT_KEEPALIVE_TIME | サーバー | サーバーがデータ/ヘッダーフレームを送信せずに連続したpingフレームを受信する間の最小許容時間。 | N/A | 300000（5分） |
MAX_CONNECTION_IDLE | サーバー | チャネルが未処理のrpcを持たない最大時間。これを超えるとサーバーは接続を閉じます。 | N/A | INT_MAX（無限） |
MAX_CONNECTION_AGE | サーバー | チャネルが存在できる最大時間。 | N/A | INT_MAX（無限） |
MAX_CONNECTION_AGE_GRACE | サーバー | チャネルが最大経過時間に達した後の猶予期間。 | N/A | INT_MAX（無限） |
注意
一部の言語では追加のオプションが提供されている場合があります。詳細については、言語の例と追加リソースを参照してください。言語ガイドと例
| 言語 | 例 | ドキュメント |
|---|---|---|
| C++ | C++の例 | C++のドキュメント |
| Go | Goの例 | Goのドキュメント |
| Java | Javaの例 | Javaのドキュメント |
| Python | Pythonの例 | Pythonのドキュメント |