조용한 개발 노트

HTTPS는 이제 선택이 아니라 기본입니다.대부분의 서비스는 TLS 위에서 동작하고, 평소에는 그 존재를 거의 의식하지 않습니다.하지만 지연을 추적하다 보면, TLS가 요청 처리 이전에 꽤 많은 일을 하고 있다는 사실을 마주하게 됩니다.이 편에서는 TLS가 어떤 비용을 요구하고, 그 비용이 언제 지연으로 드러나는지를 정리합니다.1. TLS는 요청을 보내기 전에 끝나야 한다TLS는 HTTP 요청을 보내기 전에 연결의 안전성을 먼저 합의해야 합니다.이 과정에는 다음 단계가 포함됩니다.암호 스위트 협상서버 인증서 검증키 교환즉, TLS handshake가 끝나기 전에는 애플리케이션 데이터는 한 바이트도 전송되지 않습니다.이 과정은 추가 RTT를 요구합니다.2. TLS handshake는 생각보다 무겁다TLS ..

요청이 느려질 때 흔히 보는 설정 중 하나가 Keep-Alive입니다.HTTP/2를 쓰면 빨라진다는 이야기도 자주 듣습니다.하지만 왜 이 설정들이 필요한지, 그리고 무엇을 해결하려는 것인지는 명확하지 않은 경우가 많습니다.이 편에서는 연결을 계속 유지하는 선택이 왜 지연 문제를 완화하는지부터 정리합니다.1. 매 요청마다 연결을 만드는 구조의 문제Keep-Alive가 없으면, 요청 하나마다 다음 작업이 반복됩니다.DNS 조회TCP 연결 생성TLS handshake요청 전송연결 종료이 흐름은 단순하지만, 지연 관점에서는 가장 비싼 선택입니다.2편에서 다뤘듯이, TCP 연결 자체가 이미 RTT 비용을 포함합니다.여기에 TLS까지 얹히면, 요청 처리 이전에 이미 상당한 시간이 소비됩니다.2. Keep-Alive..

API 응답이 느릴 때, 가장 먼저 확인하는 것은 보통 코드와 쿼리입니다.하지만 코드와 쿼리가 문제가 아닌 상황에서도 지연은 반복됩니다.이때 많은 경우 원인은 요청을 처리하기 전에 이미 지불한 비용에 있습니다.바로 TCP 연결입니다.1. 요청 하나는 생각보다 많은 일을 한다HTTP 요청 하나를 보낼 때, 애플리케이션은 단순히 데이터를 전송하지 않습니다.연결이 없다면, 먼저 연결부터 만들어야 합니다.클라이언트가 서버에 연결 요청을 보낸다서버가 이를 받아 응답한다클라이언트가 다시 확인 응답을 보낸다이 과정을 TCP 3-way handshake라고 부릅니다.중요한 점은 이 과정이 최소 1 RTT를 소모한다는 사실입니다.RTT가 30ms면 30ms, 100ms면 100ms가 요청 처리 이전에 이미 소비됩니다.2..