따뜻한 HTTPS와 따뜻한 VPN: 같은 요청 경로로 비교하세요

HTTPS가 모든 API 요청마다 새 TCP 연결과 새 TLS 핸드셰이크를 열어, 한 시간 동안 유지되는 터널이 더 싸 보인다고 읽으셨을 것입니다. 그 주장의 앞부분은 대개 틀렸습니다. 지원되는 클라이언트는 이미 맺은 연결을 여러 번의 교환에 재사용하고, 호출마다 새 클라이언트를 만드는 측정은 보호가 아니라 수명 주기를 재는 것입니다. 이 페이지의 나머지는 대신 무엇을 재야 하는지를 다룹니다.

재사용이 실제로 요구하는 것

지속성은 요령이 아니라 HTTP 모델의 일부입니다: 하나의 연결이 여러 요청-응답 교환을 실어 나릅니다. 연결은 둘 중 한쪽이 닫을 때, 서버가 유휴 상태이거나 과부하된 연결을 정리할 때, 또는 헤더나 프로토콜 규칙이 재사용할 수 없다고 말할 때 끝납니다. HTTPS는 그 대화를 TLS 안에 넣되 교환마다 새 핸드셰이크를 요구하지 않습니다. 따라서 두 번째 요청은 중간에 무언가가 연결을 끝내지 않는 한 첫 요청의 핸드셰이크를 반복하지 않습니다.

재사용에는 애플리케이션이 쉽게 깨뜨리는 조건이 하나 더 있습니다. 연결을 재사용하려는 클라이언트는 응답 본문을 끝까지 읽어야 하며, 중간에 버려진 응답은 아무도 눈치채지 못하는 사이에 연결 풀이 사라지는 흔한 원인입니다.

풀이 켜져 있는지 꺼져 있는지 가정하지 말고 라이브러리가 지원하는 클라이언트와 연결 풀의 수명 주기를 확인하세요. 협상된 HTTP 버전도 기록하세요, HTTP/2와 HTTP/3가 HTTP/1.1과 다른 방식으로 연결 재사용을 다루기 때문입니다. 협상된 버전을 각주가 아니라 측정의 일부로 다루세요.

비교가 수명 주기를 재는 이유

작업마다 새 클라이언트를 만들고 한 시간째 연결된 터널과 비교하는 것은 연결 설정과 정상 상태를 비교하는 일입니다. 그것은 정당한 측정이며 HTTPS 대 VPN은 아닙니다. 같은 클라이언트 설정으로 두 번 실행하면 한 번보다 동작을 잘 설명합니다, 특히 첫 실행이 리졸버나 연결 캐시를 데울 때 그렇습니다.

API 작업, 서버, 계정, 데이터를 일정하게 유지하세요, 그렇지 않으면 비교가 변수를 하나보다 많이 안게 됩니다. 타이머를 어디에 둘지 미리 정하세요, 설정, TLS 협상, 애플리케이션 실행, 응답 전달이 합계에 각기 다르게 기여하기 때문입니다. 첫 요청 타이머 하나는 설정을 특징지을 뿐 실제로 운영하는 정상 트래픽에 대해서는 아무것도 말하지 않습니다. 타이머의 경계를 숫자 옆에 적어 두세요.

차가운 설정과 따뜻한 요청을 분리하기

첫 요청은 뒤따르는 요청과 따로 재세요. 그런 다음 서비스가 실제로 보는 것을 더하세요: 유휴 구간, 폭주, 동시성, 응답 크기, 재연결입니다.

두 경로 모두에서 인증서 검증과 HTTPS를 켜 두세요, 그것을 빼는 것은 더 빠른 설계가 아니라 다른 보안 설계를 재는 일입니다. 터널이 경로나 게이트웨이 위치를 바꾼다면 모든 시간 변화를 암호화에 돌리지 말고 그 차이를 따로 보고하세요, 경로, 손실, 대기열이 작은 요청을 지배할 수 있기 때문입니다. 결론을 내리기 전에 같은 경로에서 각 경로를 두 번 실행하세요. 협상된 프로토콜과 타이머 경계는 두 실행과 함께 기록하세요.

닫히는 연결에 대비하기

지속은 영구가 아닙니다. 서버, 프록시, 네트워크 변화가 유휴 구간에 연결을 닫을 수 있고, 클라이언트는 라이브러리가 지원하는 동작으로 복구해야 합니다. 그 복구에는 상태 기계가 있습니다: 요청이 서버에서 완료되었는지, 서버가 읽기 전에 실패했는지는 알 수 없고, 닫힌 소켓은 호출자에게 어느 쪽이 일어났는지 알려 주지 않습니다. 그 위치에서 멱등하지 않은 작업은 그냥 재생할 수 없습니다, 재생은 알 수 없는 결과를 중복 쓰기로 바꾸기 때문입니다. 여기서 따뜻한 터널과 따뜻한 연결은 같은 방식으로 동작합니다, 둘 다 작업이 진행 중인 순간에 실패할 수 있기 때문입니다.

소켓을 다시 여는 루프 대신 서비스가 문서화한 재시도나 멱등성 메커니즘을 사용하세요. 복구는 분명하게 시험하세요: 유휴 연결을 닫고 클라이언트가 다음에 무엇을 하는지 관찰하세요. 소켓을 다시 여는 것은 상태를 바꾸는 호출의 반복을 안전하게 만들지 않습니다.

경계를 먼저 고르고 그다음 조정하기

무엇이든 최적화하기 전에 접근과 신뢰 요구에서 네트워크 경계를 고르세요. VPN은 자기 피어 사이의 구간을 보호하지만, 애플리케이션 엔드포인트와 터널 밖의 평문 구간은 여전히 중요합니다. 그다음 그 경계 안에서 연결의 수명 주기를 조정하세요. 더 싼 터널이라는 결론은 모든 요청이 핸드셰이크를 반복한다는 믿음에서만 나오며, 여기서 시험하는 것이 바로 그 믿음입니다.

RFC 9112의 지속성 절은 연결을 끝내는 조건을 포함해 재사용이 실제로 무엇을 약속하는지에 대한 참조입니다. 그것을 무시하는 측정을 믿기 전에 한 번 읽어 보세요.