GPT와 토론한 내용을 바탕으로 작성한 포스트 입니다. 틀린부분이 있다면 피드백 마구마구 주시면 감사드리겠습니다.
Keep Alive 란?
네트워크 또는 시스템에서 커넥션을 지속해서 유지하기 위해 사용되는 기술이나 설정을 의미합니다. TCP 연결 자체를 재사용하기 위한 메커니즘이라고 이해하면 될 것 같습니다.
Keep Alive의 장점과 단점은 무엇이 있을까요?
일단 Keep Alive의 장단점 먼저 알아봐야 겠죠?
장점
- 커넥션을 재사용하여 네트워크 비용을 절감할 수 있습니다.
- handshake에 필요한 RTT(Round Trip Time)가 감소하여 네트워크 지연 시간(Latency)을 줄일 수 있습니다.
- handshake 과정에서 발생하는 CPU, 메모리 등의 리소스 소비를 줄일 수 있습니다.
단점
- 유휴 상태일 때에도 커넥션을 점유하고 있기 때문에 서버의 소켓이 부족해질 수 있습니다.
- DoS 공격으로 다수의 연결을 길게 유지하여 서버를 과부하시킬 수 있습니다.
- 타임아웃 설정이 적절하지 않으면 커넥션 리소스가 낭비될 수 있습니다.
어디에 속해있고 어떻게 동작하지?
HTTP/1.1부터는 Keep-Alive가 Header에 기본값으로 등록되어 있습니다. 헤더에 Connection: keep-alive가 명시되어 있거나, 또는 아무것도 없으면 자동으로 유지됩니다. 끊고 싶다면 Connection: close를 사용하여 끊을 수 있습니다.
Connection: keep-alive
Keep-Alive: timeout=5, max=100
- timeout: 유휴 연결이 계속 열려 있어야 하는 최소한의 시간(초 단위)을 가르킵니다.
keep-alive TCP 메시지가 전송 계층에 설정되지 않는다면 TCP 타임아웃 이상의 타임아웃은
무시된다는 것을 알아두시기 바랍니다.
- max: 연결이 닫히기 이전에 전송될 수 있는 최대 요청 수를 가리킵니다.
만약 0이 아니라면, 해당 값은 다음 응답 내에서 다른 요청이 전송될 것이므로
비-파이프라인 연결의 경우 무시됩니다.
HTTP 파이프라인은 파이프라이닝을 제한하는 용도로 해당 값을 사용할 수 있습니다.-
Keep-Alive 없을 때
클라이언트 연결 들어옴 → 요청 처리 → 응답 보냄 → 연결 종료 → 리소스 정리
새 연결 들어옴 → 요청 처리 → 응답 보냄 → 연결 종료 → 리소스 정리
새 연결 들어옴 → ... (반복) -
Keep-Alive 있을 때
클라이언트 연결 들어옴 → 요청 처리 → 응답 보냄 → 연결 유지 → 대기
같은 연결에서 새 요청 → 처리 → 응답 → 연결 유지 → 대기
같은 연결에서 새 요청 → 처리 → 응답 → timeout 후 종료
즉, TCP 연결을 time-out 동안 유지시켜 3-way-handshake의 사용을 줄여 TCP 연결에 대한 생성/종료 오버헤드 감소가 된다는 것이죠!
HTTP Keep-Alive / TCP Keep-Alive
Keep-Alive도 HTTP 프로토콜과 TCP 프로토콜로 나뉘어 집니다.
HTTP Keep-Alive
여러 HTTP 요청을 하나의 TCP 연결로 처리합니다.
클라이언트에서 일정 시간 동안 요청이 없으면 타임아웃만큼 커넥션을 유지하고, 타임아웃이 지나면 커넥션이 끊어집니다.
HTTP Keep-Alive는 짧은 시간(초 단위) 동안 연결을 재사용하여 성능을 최적화하는 것이 목적입니다.제가 위에 설명한게 HTTP 프로토콜에서의 Keep-Alive 동작 방식입니다.
TCP Keep-Alive
장시간 유휴 상태인 TCP 연결이 실제로 살아있는지 확인하기 위한 메커니즘입니다.
일정 시간(기본 2시간) 동안 데이터 전송이 없으면, OS가 작은 probe 패킷을 보내 상대방이 응답하는지 확인합니다.TCP Keep-Alive는 긴 시간(시간 단위) 동안 죽은 연결을 감지하고, NAT/방화벽 타임아웃을 방지하는 것이 목적입니다.
클라이언트 ↔ 서버: DB 커넥션 연결 (데이터베이스 연결 풀)
[2시간 동안 쿼리 없음]
OS: "연결 살아있나?" (probe 패킷 전송)
서버: "살아있어!" (ACK 응답)
→ 연결 유지
만약 응답 없으면:
OS: 재시도 (보통 9번)
계속 응답 없음 → 연결 종료정리 테이블
| 구분 | HTTP Keep-Alive | TCP Keep-Alive |
|---|---|---|
| 레벨 | HTTP (애플리케이션) | TCP (OS) |
| 목적 | 연결 재사용으로 성능 향상 | 죽은 연결 감지 |
| 타임아웃 | 짧음 (5-15초) | 김 (2시간) |
| 사용 예시 | 웹 페이지 리소스 로딩 | DB 커넥션, WebSocket |
HTTP Keep-Alive는 성능 최적화, TCP Keep-Alive는 연결 상태 확인이 목적입니다.
이름만 비슷할 뿐 완전히 다른 레벨에서 작동하는 독립적인 기술이라고 생각하시면 될 것 같습니다.
Keep-Alive 시간이 길면 길수록 좋을까? ❌
- Socket 제한 문제
서버가 열 수 있는 Socket은 유한해요.
서버 Socket 제한: 1024개 (OS 레벨)
Keep-Alive 짧음 (5초):
사용자 A → 요청 → Socket 생성 → 5초 후 Socket 종료
→ 사용자 B가 그 Socket 사용 가능 ✅
Keep-Alive 김 (1시간):
사용자 A → 요청 → Socket 생성 → 1시간 동안 점유
→ 실제로 안 쓰는데 Socket만 차지
→ Socket 1024개 다 차면 사용자 B 연결 불가 ❌- DoS 공격 대응
Dos 공격에도 취약해 질 수 있어요 time-out 시간이 길다면 Dos Bot이 모든 Connection을 점유할 수 있어요.
DoS 공격 (봇 100개):
Keep-Alive 짧음 (10초):
봇 100개 접속 → 10초 후 자동 정리
→ 정상 사용자 연결 가능 ✅
Keep-Alive 김 (1시간):
봇 100개 접속 → 1시간 동안 점유
→ Socket 고갈
→ 정상 사용자 접속 불가 ❌🧹 정리
HTTP Keep-Alive vs TCP Keep-Alive
| 구분 | HTTP Keep-Alive | TCP Keep-Alive |
|---|---|---|
| 목적 | 연결 재사용 (성능) | 죽은 연결 감지 |
| 타임아웃 | 5-15초 (짧음) | 2시간 (김) |
| 레벨 | 애플리케이션 | OS |
적절한 타임아웃 설정
✅ 웹사이트: 5-15초
✅ API 서버: 30-60초
✅ 모바일 앱: 15-30초
✅ DB 연결: TCP Keep-Alive 사용 (60초)주의사항
Keep-Alive가 너무 길면:
- ❌ 서버 Socket 고갈
- ❌ DoS 공격에 취약
- ❌ 리소스 낭비
Keep-Alive가 너무 짧으면:
- ❌ 잦은 재연결로 성능 저하
- ❌ handshake 비용 증가
Q: Keep-Alive가 뭔가요?
A: TCP 연결을 재사용해서 여러 HTTP 요청을
처리하는 기술입니다. 3-way handshake 반복을
줄여 성능을 향상시킵니다.Q: HTTP Keep-Alive와 TCP Keep-Alive 차이는?
A: HTTP Keep-Alive는 짧은 시간(초 단위) 동안
연결을 재사용하는 성능 최적화 기술이고,
TCP Keep-Alive는 긴 시간(시간 단위) 동안
죽은 연결을 감지하는 OS 레벨 기능입니다.Q: Keep-Alive를 너무 길게 설정하면 왜 안 좋나요?
A: 서버의 Socket이 고갈될 수 있습니다.
사용하지 않는 연결이 Socket을 계속 점유하면
새로운 사용자가 접속할 수 없고, DoS 공격에도
취약해집니다.한 줄:
Keep-Alive는 "적절한 길이"가 중요합니다. 무조건 길다고 좋은 것이 아니라, 상황에 맞게 설정하도록 고민해보아야 합니다.
끝까지 읽어주신 분들께 감사드리며 오늘도 행복한 하루 되셨으면 좋겠습니다!
