“Connection keep-alive”, 요청할 때마다 서버에 다시 연결한다고?

들어가며

웹사이트를 개발하다 보면 Chrome 개발자 도구의 Network 탭에서 이상하게 자주 보이는 값이 하나 있다.

바로 HTTP 헤더에 표시되는 ‘Connection: keep-alive‘다.

처음 보면 별것 아닌 것처럼 보인다.

“연결을 계속 유지한다는 뜻인가?”

맞다. 그런데 여기서 조금 더 들어가 보면 웹 브라우저와 서버가 통신하는 방식에 대한 꽤 중요한 이야기가 나온다.

특히 웹페이지 하나를 열었을 뿐인데 이미지, CSS, JavaScript, API 등 수많은 요청이 발생하는 이유를 생각해보면 keep-alive가 왜 필요한지도 자연스럽게 이해할 수 있다.

Connection keep-alive란 무엇일까?

keep-alive는 쉽게 말해서 HTTP 요청 하나를 처리했다고 TCP 연결을 바로 끊지 않고 일정 시간 동안 재사용할 수 있도록 유지하는 방식이다.

예를 들어 웹페이지를 열었을 때 다음과 같은 요청이 발생한다고 생각해보자.

HTML
 ├─ CSS
 ├─ JavaScript
 ├─ 이미지
 ├─ 폰트
 └─ API

예전 방식처럼 각각의 요청마다 서버와 새로운 TCP 연결을 만들고 끊는다면 요청 하나마다 연결을 위한 과정이 반복된다.

간단하게 표현하면 이런 구조다.

요청 1 → 연결 → 응답 → 연결 종료
요청 2 → 연결 → 응답 → 연결 종료
요청 3 → 연결 → 응답 → 연결 종료

반면 연결을 재사용할 수 있다면 다음과 같은 흐름이 가능하다.

연결
 ↓
요청 1 → 응답
 ↓
요청 2 → 응답
 ↓
요청 3 → 응답
 ↓
연결 종료

요청이 많은 웹페이지에서는 이런 차이가 꽤 중요해진다.

개발자 도구에서는 어디에서 확인할까?

Chrome 개발자 도구를 열고 Network 탭으로 이동해보자.

페이지를 새로고침하면 수많은 요청이 나타난다.

여기서 원하는 요청 하나를 클릭한 다음 Headers 영역을 확인하면 HTTP 헤더를 볼 수 있다.

환경이나 프로토콜에 따라 표시되는 내용은 달라질 수 있지만 HTTP/1.1 요청에서는 다음과 같은 헤더를 볼 수 있다.

Connection: keep-alive

응답에서도 관련 헤더가 표시되는 경우가 있다.

다만 여기서 주의할 점이 있다.

오늘날의 모든 HTTP 통신에서 Connection: keep-alive 헤더가 그대로 보이는 것은 아니다.

이 부분을 이해하지 못하면 개발자 도구를 보면서 오히려 혼란스러울 수 있다.

HTTP/1.1에서는 기본적으로 연결을 재사용한다

keep-alive를 이해하려면 HTTP 버전도 함께 봐야 한다.

HTTP/1.0 시절에는 기본적으로 요청이 끝난 뒤 연결을 닫는 방식이 일반적이었다.

그래서 연결을 유지하려면 별도의 Connection: keep-alive를 사용했다.

반면 HTTP/1.1에서는 지속적인 연결이 기본 동작이 됐다.

즉, HTTP/1.1에서는 매 요청마다 새로운 TCP 연결을 만들지 않고 기존 연결을 재사용할 수 있다.

그래서 Network 탭에서 Connection: keep-alive를 발견했다고 해서 “이 사이트만 특별하게 연결을 유지하고 있구나”라고 생각할 필요는 없다.

HTTP/1.1의 기본적인 연결 관리 방식과 관련된 값이라고 이해하는 것이 좋다.

그런데 HTTP/2에서는 이야기가 조금 달라진다

여기서 한 단계 더 들어가면 재미있는 부분이 나온다.

최근 웹사이트에서는 HTTP/2나 HTTP/3를 사용하는 경우가 많다.

특히 HTTP/2에서는 하나의 연결에서 여러 요청과 응답을 동시에 처리할 수 있는 Multiplexing(다중화)이 중요한 특징이다.

예를 들어 HTTP/1.1 환경에서는 여러 리소스를 처리하는 방식이 상대적으로 제한적이었다면 HTTP/2에서는 하나의 연결 위에서 여러 스트림을 동시에 처리할 수 있다.

HTTP/2 연결
│
├─ HTML 요청
├─ CSS 요청
├─ JS 요청
├─ 이미지 요청
└─ API 요청

그래서 HTTP/2 환경에서는 HTTP/1.1에서 사용하던 Connection 헤더를 같은 방식으로 생각하면 안 된다.

실제로 HTTP/2와 HTTP/3에서는 Connection 헤더와 같은 connection-specific header field를 사용할 수 없다.

따라서 개발자 도구에서 Connection 헤더가 보이지 않는다고 해서 “keep-alive가 작동하지 않는다”고 판단하면 안 된다.

오히려 Network 탭의 Protocol 컬럼에서 현재 어떤 HTTP 프로토콜을 사용하는지 확인하는 것이 중요하다.

Network 탭의 Protocol도 같이 확인해보자

Network 탭을 보면 여러 컬럼이 있다.

Name
Status
Type
Initiator
Size
Time
Waterfall

필요하다면 컬럼 영역에서 마우스 오른쪽 버튼을 눌러 Protocol을 추가할 수 있다.

그러면 요청마다 어떤 프로토콜을 사용했는지 확인할 수 있다.

예를 들어 환경에 따라 다음처럼 표시될 수 있다.

h1
h2
h3

대략적으로 보면

h1 → HTTP/1.1
h2 → HTTP/2
h3 → HTTP/3

라고 이해할 수 있다.

이렇게 Protocol과 Headers를 함께 보면 단순히 Connection: keep-alive 하나만 보는 것보다 현재 브라우저와 서버가 어떤 방식으로 통신하고 있는지 훨씬 정확하게 파악할 수 있다.

keep-alive가 왜 필요한 걸까?

가장 큰 이유는 연결을 새로 만드는 비용을 줄이기 위해서다.

브라우저가 서버와 통신하려면 TCP 연결을 만들고 데이터를 주고받는 과정이 필요하다.

HTTPS라면 여기에 TLS 연결 과정도 추가된다.

그런데 웹페이지 하나를 구성하는 데 수십 개 이상의 리소스를 요청해야 한다면 매번 연결을 새로 만드는 것은 상당히 비효율적이다.

예를 들어

CSS 요청
→ 연결 생성
→ 응답
→ 종료

JS 요청
→ 연결 생성
→ 응답
→ 종료

이미지 요청
→ 연결 생성
→ 응답
→ 종료

이런 방식으로 계속 반복한다면 연결을 만드는 작업 자체가 상당한 비중을 차지할 수 있다.

keep-alive를 이용하면 연결을 재사용할 수 있기 때문에 이런 반복 작업을 줄일 수 있다.

결국 사용자가 웹페이지를 더 빠르게 사용할 수 있도록 돕는 중요한 기반 중 하나라고 볼 수 있다.

keep-alive라고 해서 연결이 영원히 유지되는 것은 아니다

이것도 자주 오해하는 부분이다.

keep-alive라는 이름 때문에 연결이 계속 유지될 것 같지만 실제로는 그렇지 않다.

서버나 프록시, 로드밸런서 등의 설정에 따라 idle timeout, 즉 일정 시간 동안 통신이 없으면 연결을 종료할 수 있다.

예를 들어 서버가 일정 시간 동안 새로운 요청이 들어오지 않았다고 판단하면 기존 연결을 닫을 수 있다.

따라서

keep-alive
=
연결을 영원히 유지

가 아니다.

정확하게는

keep-alive
=
필요한 동안 기존 연결을 재사용할 수 있도록 유지

정도로 이해하는 것이 좋다.

개발자 도구에서 연결 문제를 확인할 때

웹사이트가 느리거나 API 요청이 이상하게 지연되는 상황에서는 Network 탭을 보면서 여러 정보를 함께 확인하는 것이 좋다.

예를 들어 다음과 같은 순서로 살펴볼 수 있다.

Network
 ↓
요청 선택
 ↓
Headers 확인
 ↓
Protocol 확인
 ↓
Timing 확인

특히 Timing 탭은 요청이 어느 단계에서 시간을 사용했는지 확인하는 데 유용하다.

DNS Lookup에 시간이 오래 걸리는지, 연결 과정에서 지연이 발생했는지, 서버 응답을 기다리는 시간이 긴지 등을 구분하는 데 도움이 된다.

따라서 Connection: keep-alive 하나만 보고 성능 문제의 원인을 판단해서는 안 된다.

실제 성능 분석에서는 Protocol, Timing, 서버 응답 시간, 네트워크 환경 등을 함께 봐야 한다.

Keep-Alive와 Connection: keep-alive를 구분해서 생각하자

검색하다 보면 “HTTP Keep-Alive”와 “Connection: keep-alive”가 거의 같은 의미처럼 사용되는 경우가 많다.

실무에서는 비슷한 맥락으로 이야기하는 경우가 많지만 조금 구분해서 생각하면 이해하기 편하다.

HTTP persistent connection은 HTTP 요청이 끝난 뒤에도 연결을 재사용할 수 있도록 하는 개념이다.

그리고 HTTP/1.1에서는 이러한 지속 연결이 기본 동작이다.

반면 Connection: keep-alive는 HTTP/1.x에서 연결을 지속적으로 사용하려는 의도를 표현하거나 연결 관련 동작을 다룰 때 사용되는 헤더다.

특히 HTTP/2와 HTTP/3로 넘어오면서 연결 관리 방식 자체가 발전했기 때문에 과거 HTTP/1.0 시대의 개념을 그대로 적용하면 안 된다.

실제 개발에서는 어떻게 활용할까?

사실 일반적인 프론트엔드 개발에서 개발자가 직접 Connection: keep-alive를 설정할 일은 많지 않다.

브라우저와 서버, 그리고 중간 네트워크 장비가 연결을 관리하기 때문이다.

오히려 개발자 도구에서는 현재 통신이 어떻게 이루어지고 있는지 확인하는 용도로 보는 것이 더 현실적이다.

예를 들어 API 요청이 많아진 상황이라면 Network 탭에서 다음 내용을 확인해볼 수 있다.

어떤 요청이 발생했는가?
        ↓
HTTP/1.1인가 HTTP/2인가?
        ↓
요청별 처리 시간은 얼마나 되는가?
        ↓
연결 및 응답 과정에서 지연이 있는가?

이런 식으로 확인하면 단순히 “API가 느리다”에서 끝나는 것이 아니라 어느 구간에서 시간이 걸리는지 추적할 수 있다.

마무리

Chrome 개발자 도구에서 보이는 Connection: keep-alive는 단순한 문자열 하나처럼 보이지만, 그 뒤에는 웹 브라우저와 서버가 연결을 관리하는 방식이 들어 있다.

핵심만 정리하면 다음과 같다.

keep-alive
→ HTTP 연결을 재사용할 수 있도록 유지하는 개념

HTTP/1.1
→ 지속 연결이 기본

HTTP/2
→ 하나의 연결에서 여러 스트림을 처리하는 Multiplexing 사용

HTTP/3
→ QUIC 기반으로 동작하며 HTTP/1.x의 Connection 헤더와는 다르게 접근

그리고 개발자 도구에서 이 내용을 확인할 때는 Headers의 Connection 값 하나만 보는 것보다 Protocol과 Timing까지 함께 확인하는 습관을 들이는 것이 좋다.

특히 Network 탭을 공부하고 있다면 Fetch/XHR, Headers, Response뿐만 아니라 이런 연결 관리 개념까지 알아두면 웹 요청이 실제로 어떻게 움직이는지 이해하는 데 도움이 된다.

처음에는 Connection: keep-alive라는 한 줄이 별 의미 없어 보일 수 있다.

하지만 페이지 하나를 열 때 수많은 요청이 발생한다는 것을 생각해보면, 매번 서버와 새로 연결하지 않고 기존 연결을 효율적으로 사용하는 것이 왜 중요한지 자연스럽게 이해할 수 있다.

개발자 도구의 Network 탭은 단순히 API 주소를 찾는 곳이 아니다.

브라우저와 서버 사이에서 실제로 어떤 일이 벌어지고 있는지를 확인할 수 있는 가장 현실적인 디버깅 도구 중 하나다.