“Keep-Alive: timeout=20″이라고? 20초 뒤에 연결이 무조건 끊기는 건 아니다

들어가며

Chrome 개발자 도구의 Network 탭을 보다 보면 HTTP 헤더에서 낯익은 문구를 발견할 때가 있다.

Connection: keep-alive
Keep-Alive: timeout=20

처음 보면 상당히 단순해 보인다.

“아, 서버가 연결을 20초 동안 유지하는구나.”

그런데 실제로는 여기서 한 가지를 더 알아야 한다.

timeout=20이 무조건 20초 후에 연결을 끊는다는 뜻은 아니다.

이 값을 제대로 이해하려면 HTTP 연결 재사용, idle timeout, 브라우저와 서버의 연결 관리 방식까지 함께 살펴봐야 한다.

개발자 도구를 자주 사용하는 사람이라면 한번쯤 짚고 넘어갈 만한 내용이다.

Keep-Alive: timeout=20은 무엇일까?

먼저 가장 간단하게 설명해보자.

Keep-Alive 헤더의 timeout 파라미터는 서버가 유휴 상태인 연결을 얼마 동안 유지할지에 대한 시간을 나타내는 값이다.

여기서 중요한 단어가 바로 유휴 상태(idle)다.

예를 들어 서버와 브라우저가 연결되어 있다고 해보자.

요청
 ↓
응답
 ↓
아무 요청도 없음
 ↓
유휴 상태

이 상태가 계속된다면 서버는 해당 연결을 계속 유지할 필요가 없다고 판단할 수 있다.

이때 timeout=20이라면 일반적으로 유휴 연결을 약 20초 정도 유지하려는 서버 측 설정을 나타낸다.

즉,

timeout=20
≠
연결 생성 후 20초 뒤 종료

가 아니라,

timeout=20
=
유휴 상태가 지속될 경우 약 20초를 기준으로 연결을 유지

하는 개념으로 이해하는 것이 좋다.

개발자 도구에서는 어디에서 볼 수 있을까?

Chrome에서 F12를 눌러 개발자 도구를 열어보자.

그다음 Network 탭으로 이동한다.

페이지를 새로고침한 뒤 HTML이나 API 요청을 하나 선택하고 Headers를 확인하면 된다.

환경에 따라 다음과 같은 헤더가 보일 수 있다.

Connection: keep-alive
Keep-Alive: timeout=20

이 값은 특히 HTTP/1.x 기반 통신을 분석할 때 눈에 띄는 경우가 있다.

다만 모든 웹사이트에서 동일한 헤더가 나타나는 것은 아니다.

웹사이트가 HTTP/2 또는 HTTP/3를 사용한다면 HTTP/1.x의 Connection이나 Keep-Alive 헤더를 같은 방식으로 확인할 수 없다.

따라서 개발자 도구에서 이 값을 확인했다면 먼저 Protocol도 함께 확인하는 것이 좋다.

20초가 지나면 정말 연결이 끊어질까?

이 질문이 가장 중요하다.

결론부터 말하면 반드시 그렇지는 않다.

Keep-Alive: timeout=20은 보통 서버가 연결을 유지할 수 있는 유휴 시간에 대한 힌트 또는 설정을 나타낸다.

예를 들어 이런 상황을 생각해보자.

0초
요청 발생
 ↓
응답

5초
새로운 요청 발생
 ↓
응답

10초
새로운 요청 발생
 ↓
응답

각 요청이 계속 발생한다면 연결을 재사용할 수 있는 상황이 이어질 수 있다.

반대로 응답 이후 아무런 통신이 없고 유휴 시간이 계속된다면 서버가 설정한 timeout을 기준으로 연결을 종료할 수 있다.

따라서 timeout=20을 볼 때는 연결의 전체 수명보다 마지막 통신 이후의 유휴 시간에 초점을 맞추는 것이 좋다.

Keep-Alive timeout과 요청 처리 시간은 다르다

또 하나 헷갈리기 쉬운 것이 있다.

Keep-Alive: timeout=20의 20초와 API 요청이 처리되는 데 걸리는 20초는 완전히 다른 개념이다.

예를 들어 API 요청이 다음처럼 처리됐다고 해보자.

요청 시작
 ↓
서버 처리 500ms
 ↓
응답 완료

이후 연결이 계속 유지될 수 있고, 유휴 상태가 일정 시간 이어지면 연결이 종료될 수 있다.

반면 서버가 요청을 처리하는 데 20초가 걸렸다면 그것은 request processing time 또는 response time과 관련된 문제이지 Keep-Alive timeout과 같은 개념이 아니다.

개발자 도구에서 성능 문제를 분석할 때 이 둘을 구분하는 것이 중요하다.

Network의 Timing과 함께 보면 이해하기 쉽다

Network 탭에서 요청 하나를 클릭하면 Timing 정보를 확인할 수 있다.

여기에는 요청이 처리되는 과정에서 어느 구간에 시간이 사용됐는지 확인할 수 있는 정보가 나온다.

대략적으로 다음과 같은 흐름으로 생각할 수 있다.

Queueing
 ↓
DNS Lookup
 ↓
Initial connection
 ↓
Request sent
 ↓
Waiting for server response
 ↓
Content Download

여기서 Keep-Alive timeout=20은 Timing에 표시되는 요청 처리 시간과 동일한 개념이 아니다.

예를 들어 서버 응답이 빠르게 끝났는데도 브라우저와 서버 사이의 연결이 일정 시간 유지될 수 있다.

이것이 바로 연결 재사용을 위한 persistent connection의 개념이다.

왜 굳이 연결을 유지할까?

웹페이지 하나를 열었을 때 발생하는 요청을 생각해보자.

HTML
CSS
JavaScript
이미지
폰트
API
광고
분석 요청

하나의 페이지에서도 여러 HTTP 요청이 발생할 수 있다.

매번 요청할 때마다 TCP 연결을 새로 만든다면 연결을 설정하는 과정이 반복된다.

HTTPS라면 TLS 관련 연결 과정까지 고려해야 한다.

그래서 이미 만들어진 연결을 재사용하면 불필요한 연결 설정 작업을 줄일 수 있다.

간단하게 표현하면 다음과 같다.

연결 재사용 X

연결 → 요청 → 응답 → 종료
연결 → 요청 → 응답 → 종료
연결 → 요청 → 응답 → 종료

반면 연결을 재사용하면

연결
 ├─ 요청 → 응답
 ├─ 요청 → 응답
 └─ 요청 → 응답

처럼 처리할 수 있다.

이런 구조는 웹페이지의 여러 리소스를 가져오는 데 유리하다.

timeout 값은 서버마다 다를 수 있다

여기서 timeout=20이라는 숫자를 보고 “HTTP Keep-Alive는 항상 20초구나”라고 생각하면 안 된다.

이 값은 서버나 웹 서버 소프트웨어의 설정에 따라 달라질 수 있다.

어떤 환경에서는 5초일 수도 있고, 10초나 30초일 수도 있다.

또한 웹 서버 앞에 프록시나 로드밸런서가 있다면 이야기가 더 복잡해진다.

예를 들어

Browser
   ↓
CDN
   ↓
Load Balancer
   ↓
Reverse Proxy
   ↓
Web Server

처럼 여러 네트워크 계층을 거치는 경우 각각의 연결 정책과 timeout 설정이 존재할 수 있다.

따라서 개발자 도구에서 Keep-Alive: timeout=20을 발견했다고 해서 전체 네트워크 경로의 모든 연결이 20초 동안 유지된다고 생각해서는 안 된다.

브라우저가 20초마다 새로운 연결을 만드는 것은 아니다

이것도 자주 나오는 오해다.

timeout=20을 보고

“그러면 브라우저는 20초마다 서버와 다시 연결하나?”

라고 생각할 수 있다.

그렇지 않다.

이 값은 유휴 연결을 얼마나 유지할 것인지에 대한 정책과 관련된 값이다.

브라우저가 계속해서 요청을 보내고 있고 기존 연결을 사용할 수 있다면 연결이 재사용될 수 있다.

반대로 연결이 종료된 뒤 새로운 요청이 발생한다면 그때 새로운 연결이 만들어질 수 있다.

즉,

요청이 계속 발생
→ 기존 연결 재사용 가능

오랫동안 요청 없음
→ 연결 종료 가능

연결 종료 후 새로운 요청
→ 새로운 연결 생성

정도로 이해하면 된다.

HTTP/2에서는 어떻게 다를까?

최근 웹사이트에서는 HTTP/2를 사용하는 경우가 많기 때문에 여기서 한 가지 더 주의해야 한다.

HTTP/2는 하나의 연결에서 여러 스트림을 동시에 처리하는 Multiplexing을 지원한다.

그래서 HTTP/1.1에서 여러 요청을 처리할 때와는 연결 구조가 다르다.

또한 HTTP/2에서는 Connection과 같은 connection-specific header를 사용할 수 없다.

따라서 Network 탭에서 Connection: keep-alive가 보이지 않는다고 해서 HTTP 연결 재사용이 이루어지지 않는 것은 아니다.

오히려 Network 탭의 Protocol 컬럼을 확인해서 현재 HTTP/1.1인지 HTTP/2인지 HTTP/3인지 먼저 파악하는 것이 좋다.

Keep-Alive timeout을 볼 때 체크할 것

개발자 도구에서 Keep-Alive: timeout=20을 발견했다면 다음 정도만 확인해도 충분하다.

1. 어떤 HTTP 프로토콜인가?
2. Connection 헤더가 있는가?
3. Keep-Alive timeout 값은 얼마인가?
4. Network Timing에서 연결 과정은 어떤가?
5. 요청이 반복될 때 연결이 재사용되는가?

특히 성능 문제를 조사하고 있다면 timeout 숫자 하나만 가지고 결론을 내리지 않는 것이 중요하다.

Network 탭의 Timing, Protocol, 서버 응답 시간 등을 함께 봐야 한다.

개발할 때 이 값을 직접 수정해야 할까?

프론트엔드 개발자라면 Keep-Alive: timeout=20을 봤다고 해서 JavaScript에서 뭔가 수정해야 하는 것은 아니다.

이 값은 일반적으로 서버 측 HTTP 연결 관리와 관련된 설정이다.

예를 들어 Apache, Nginx 또는 애플리케이션 서버 앞의 프록시나 로드밸런서 등에서 각각 연결 유지 정책을 관리할 수 있다.

따라서 웹사이트 성능을 개선하려는 상황이라면 브라우저 코드만 보는 것이 아니라 서버 및 인프라 설정까지 함께 확인해야 할 수 있다.

다만 실제 설정을 변경할 때는 사용 중인 서버 소프트웨어와 HTTP 버전에 맞는 공식 문서를 확인하는 것이 좋다.

마무리

개발자 도구에서 발견한

Connection: keep-alive
Keep-Alive: timeout=20

이 두 줄은 단순한 HTTP 헤더처럼 보이지만, 웹 브라우저와 서버가 연결을 어떻게 재사용하는지 이해하는 데 좋은 출발점이다.

특히 기억해야 할 것은 timeout=20이 연결 생성 후 정확히 20초가 지나면 무조건 끊긴다는 뜻은 아니라는 것이다.

핵심은 유휴 상태다.

Keep-Alive
→ 기존 연결을 재사용하기 위한 개념

timeout=20
→ 유휴 연결을 유지하는 시간에 대한 설정

20초
→ 요청 처리 시간이 아님

HTTP/2 / HTTP/3
→ HTTP/1.x와 연결 관리 방식이 다름

Network 탭에서 이 값을 발견했다면 Headers만 보고 끝내지 말고 Protocol과 Timing까지 같이 확인해보자.

처음에는 timeout=20이라는 숫자가 별것 아닌 것처럼 보이지만, 실제로는 웹 성능과 HTTP 연결 관리 방식을 이해하는 데 꽤 좋은 단서가 된다.

특히 Network 탭을 공부하고 있다면 Fetch/XHR, Headers, Response와 함께 Connection, Keep-Alive, Protocol, Timing까지 하나씩 살펴보는 것을 추천한다.

이런 내용을 하나씩 확인하다 보면 개발자 도구가 단순히 오류를 찾는 도구가 아니라 브라우저와 서버 사이에서 실제로 어떤 통신이 일어나고 있는지를 들여다보는 도구라는 것을 점점 체감하게 된다.