Webhookパブリッシャーは、データ受信前にDNS解決、TCP接続、TLSハンドシェイクを必要とするイベント通知を送信します。これらのハンドシェイクの往復時間は、遠隔地の受信者にとって主なネットワークコストとなります。パブリッシャーは応答に対して厳格なタイムアウトを課し、一部は配信失敗のためのリトライメカニズムを提供します。この記事では、各ハンドシェイクステップのコストを調査し、BGP Anycastがパスを短縮する方法を探ります。また、TCP Fast Open (TFO) と TLS 1.3 0-RTT の利点と欠点についても議論します。ユニキャスト配信は、送信者の距離に関係なく、すべてのトラフィックを単一のエンドポイントロケーションに送信します。一方、BGP Anycastは、複数のポイントオブプレゼンスを使用し、同じIPプレフィックスをアナウンスすることで、送信者がトポロジ的に近いサイトに接続できるようにします。Anycastにおける「最も近い」とは、必ずしも地理的な距離ではなく、ネットワークパスを指します。Anycastの安定性はルーティングポリシーの影響を受ける可能性がありますが、短命なWebhookリクエストの場合、ルーティングの切り替わりは一般的に短時間です。トラフィックのブラックホーリングを防ぐためには、正常でないAnycastポイントオブプレゼンスからルートを撤回することが重要です。これは、サービスヘルスを監視し、ExaBGPのようなツールを使用してルートアナウンスを管理することで自動化できます。TCP Fast Openは、クライアントがリピート接続の最初のSYNパケットでデータを送信できるようにし、1回の往復を節約します。しかし、その有効性は、送信者のサポート、潜在的なミドルボックスの干渉、およびアプリケーションが重複データを処理できる能力に依存します。TLS 1.3は1回の往復でハンドシェイクを完了し、0-RTTは後続の接続で初期のClientHelloと共にアプリケーションデータを送信することを可能にします。この0-RTT機能は、ハンドラーが厳密に冪等でない限り、リプレイの懸念からWebhook POSTリクエストにはリスクがあります。0-RTTを受け入れる場合、イベントIDによる重複排除と共有ストアの使用がリプレイ防御に不可欠です。AnycastとTFOおよびTLS 1.3 0-RTTを組み合わせることで、大幅な遅延削減が実現します。Anycastは基本的な往復時間を短縮し、TFOと0-RTTは接続設定とデータ送信に必要な往復回数を最小限に抑えます。最も最適化されたシナリオでも、いくらかの往復オーバーヘッドが残ります。HTTP Keep-Aliveを介した接続の再利用も、同じホストへの後続の配信におけるハンドシェイクコストを大幅に削減します。