웹훅 게시자는 DNS 확인, TCP 연결 및 TLS 핸드셰이크가 완료된 후에야 데이터를 수신하는 이벤트 알림을 보냅니다. 이러한 핸드셰이크의 왕복 시간은 원거리 수신자에게 주요 네트워크 비용입니다. 게시자는 응답에 대해 엄격한 타임아웃을 부과하며, 일부는 실패한 전달에 대한 재시도 메커니즘을 제공합니다. 이 글은 각 핸드셰이크 단계의 비용을 살펴보고 BGP Anycast가 경로를 단축하는 방법을 탐구합니다. 또한 TCP Fast Open(TFO) 및 TLS 1.3 0-RTT의 장단점을 논의합니다.유니캐스트 전달은 발신자 거리와 관계없이 모든 트래픽을 단일 엔드포인트 위치로 보냅니다. 반대로 BGP Anycast는 동일한 IP 접두사를 알리는 여러 개의 PoP(Point of Presence)를 사용하여 발신자가 지리적으로 더 가까운 사이트에 연결할 수 있도록 합니다. Anycast에서 "가장 가까운"은 지리적 거리가 아닌 네트워크 경로를 의미합니다. Anycast의 안정성은 라우팅 정책에 영향을 받을 수 있지만, 단기 웹훅 요청의 경우 라우팅 변경은 일반적으로 짧습니다.트래픽 블랙홀링을 방지하기 위해 비정상적인 Anycast PoP에서 라우트를 철회하는 것이 중요합니다. 이는 서비스 상태를 모니터링하고 ExaBGP와 같은 도구를 사용하여 라우트 알림을 관리함으로써 자동화할 수 있습니다. TCP Fast Open은 클라이언트가 반복 연결 시 초기 SYN 패킷에 데이터를 보낼 수 있도록 하여 왕복 시간을 절약합니다. 그러나 그 효과는 발신자 지원, 잠재적인 미들박스 간섭 및 중복 데이터를 처리하는 애플리케이션의 능력에 따라 달라집니다.TLS 1.3은 한 번의 왕복으로 핸드셰이크를 완료하며, 0-RTT는 후속 연결 시 초기 ClientHello와 함께 애플리케이션 데이터를 보낼 수 있도록 합니다. 이 0-RTT 기능은 핸들러가 엄격하게 멱등적이지 않은 한, 재현 가능성 문제로 인해 웹훅 POST 요청에 위험합니다. 0-RTT를 수락하는 경우, 이벤트 ID별 중복 제거 및 공유 저장소 사용이 재현 방어에 필수적입니다.Anycast와 TFO 및 TLS 1.3 0-RTT를 결합하면 상당한 지연 시간 감소를 제공합니다. Anycast는 기본적인 왕복 시간을 단축하는 반면, TFO와 0-RTT는 연결 설정 및 데이터 전송에 필요한 왕복 횟수를 최소화합니다. 가장 최적화된 시나리오에서도 일부 왕복 오버헤드는 여전히 남아 있습니다. HTTP Keep-Alive를 통한 연결 재사용은 동일한 호스트에 대한 후속 전달의 핸드셰이크 비용을 크게 줄입니다.