왜 짧은 연결이 바쁜 자체 호스팅 서버를 과부하시키나요?

설정 및 해제 작업이 유용한 요청 작업보다 많아질 때 짧은 연결이 바쁜 자체 호스팅 서버에 과부하를 일으킵니다. 각 새 세션은 응답에 몇 바이트만 포함되어 있어도 TCP 핸드셰이크, TLS 협상, 소켓 할당, 인증, 로깅 및 정리 작업이 필요할 수 있습니다.

긴 파일 전송은 이러한 비용을 한 번만 지불하고 상당한 데이터를 전송합니다. 헬스 체크, 대시보드, 모바일 클라이언트, 웹 자산 및 제대로 풀링되지 않은 API 호출은 수백 개의 작은 세션을 생성하여 서버가 최근에 닫힌 연결의 상태를 유지하면서 고정 비용을 반복하게 만듭니다.

핵심 원인: 모든 새 연결이 고정 작업을 반복한다

TCP 연결은 애플리케이션 데이터가 흐르기 전에 핸드셰이크로 시작됩니다. HTTPS는 암호화 협상을 추가하며, 애플리케이션은 세션을 생성하거나 자격 증명을 확인하고 데이터베이스 연결을 열거나 사용자 상태를 로드할 수 있습니다. 작은 응답의 경우 이러한 설정 단계가 지연 시간과 CPU 시간을 모두 지배할 수 있습니다.

짧은 연결의 오버헤드는 서버가 높은 빈도로 이를 반복할 때 중요해집니다. 네트워크 처리량이 링크 속도보다 훨씬 낮음에도 불구하고 부하 평균이 상승하고 응답 속도가 느려지는 현상이 나타날 수 있습니다.

연결 재사용은 이 비율을 바꿉니다. 여러 요청이 하나의 확립된 전송과 지원되는 경우 하나의 암호화된 세션을 공유할 수 있습니다. 서버는 연결 상태를 할당하고 종료하는 데 드는 시간보다 애플리케이션 작업에 더 많은 시간을 할애합니다.

Keep-Alive는 핸드셰이크를 줄이지만 합리적인 제한이 필요하다

HTTP keep-alive는 각 객체나 API 호출마다 새 연결을 여는 대신 하나의 TCP 연결로 여러 요청을 처리할 수 있게 합니다. 이는 왕복 횟수를 줄이고 페이지나 대시보드가 많은 리소스를 로드할 때 반복되는 설정을 방지합니다.

HTTP keepalive 연결은 확립된 전송을 재사용하여 지연 시간을 낮춥니다. 경계는 유휴 상태입니다: 너무 긴 타임아웃은 많은 사용하지 않는 소켓이 메모리와 연결 슬롯을 차지하게 하므로, 재사용은 클라이언트 패턴에 맞는 타임아웃과 요청 제한이 필요합니다.

풀링은 내부 서비스 호출 양쪽 모두에 존재해야 합니다. 리버스 프록시는 클라이언트 연결을 재사용하면서 매 요청마다 새로운 업스트림 연결을 열어 변동을 이동시킬 뿐 제거하지 않을 수 있습니다. 데이터베이스 드라이버와 API 클라이언트도 하나의 자체 호스팅 앱 내에서 동일한 숨겨진 팬아웃을 생성할 수 있습니다.

닫힌 연결이 커널 상태를 남길 수 있다

TCP 세션을 닫아도 상태가 즉시 지워지지 않을 수 있습니다. 적극적으로 닫는 쪽은 TIME_WAIT 항목을 유지하여 이전 연결의 지연된 패킷이 동일한 주소와 포트 조합을 사용하는 이후 연결과 혼동되지 않도록 합니다.

많은 TIME_WAIT 항목은 자동으로 서버가 중단된 것이 아니라 빈번한 연결 교체를 나타냅니다. 높은 빈도에서는 메모리를 소비하고 관측성을 복잡하게 하거나 오래된 항목이 만료되기 전에 클라이언트의 임시 포트를 소진할 수 있습니다.

커널 타이머 변경은 거의 첫 번째 조치가 아닙니다. 어떤 클라이언트나 서비스가 연결을 열고 있는지 찾고, 재사용이 활성화되어 있는지 확인하며, 재시도나 헬스 프로브가 빈도를 증가시키는지 점검하세요. 공격적인 타이머 변경은 패턴을 숨기면서 지연된 패킷에 대한 TCP 보호를 약화시킬 수 있습니다.

자동화는 겉보기에는 유휴인 서버에서 연결 변동을 만들 수 있다

홈 서버는 사람이 적극적으로 사용하지 않을 때도 컨테이너 헬스 체크, 모니터링 에이전트, 브라우저 탭, 휴대폰 위젯, 미디어 클라이언트, 리버스 프록시 등에서 요청을 받을 수 있습니다. 각 프로브가 새 암호화 연결을 열면 짧은 간격이 가벼운 체크를 지속적인 설정 작업으로 바꿉니다.

짧은 수명의 TCP 연결 측정은 자동화된 클라이언트와 스크립트가 유지된 세션보다 반복되는 새 세션을 선호할 수 있음을 보여줍니다. 작은 자체 호스팅 서버에서는 CPU, 메모리, 작업자 제한이 더 작기 때문에 같은 행동이 더 낮은 규모로도 관찰됩니다.

초당 수락된 연결 수, 핸드셰이크 CPU, 열린 소켓, TIME_WAIT 항목, 연결당 요청 수를 계산하세요. 연결 속도가 요청량보다 훨씬 빠르게 증가하면 풀링과 재시도 동작을 점검하세요. 서비스가 인터넷에 노출되어 있다면 홈 서버 노출 확인으로 노출 경계를 먼저 확인하여 원치 않는 스캔을 정상 클라이언트로 오인하지 않도록 하세요.

자주 묻는 질문

짧은 연결이 항상 문제인가요?

아닙니다. 최신 서버는 많은 연결을 처리할 수 있으며, 짧은 세션은 드문 클라이언트에 적합할 수 있습니다. 문제는 연결 속도가 서버가 재활용할 수 있는 CPU, 포트, 작업자 또는 메모리보다 빠르게 소비될 때 발생합니다.

HTTP/2가 연결 과부하를 없애나요?

HTTP/2는 적은 수의 연결로 여러 요청을 다중화하여 변동을 줄입니다. 클라이언트, 프록시, 업스트림 서비스가 실제로 협상하고 재사용해야 하며, 내부 구간은 여전히 별도의 HTTP/1.1 연결을 사용할 수 있습니다.

TIME_WAIT 타임아웃을 줄여야 하나요?

변동의 원인을 파악하기 전에는 줄이지 마세요. TIME_WAIT는 정상적인 프로토콜 동작입니다. 연결 풀링, 지속 전송, 프로브 간격, 재시도 제한이 보통 커널 안전 타이머를 단축하는 것보다 작업 부하를 더 직접적으로 해결합니다.