Chromium 기반 브라우저의 HTTP/1.1 연결 6개 제한과 요청 대기
Chromium 기반 브라우저에서 요청을 시작했는데 서버에는 요청이 도착하지 않는 경우가 있다
사용할 수 있는 HTTP/1.1 연결을 모두 사용하고 있으면, 추가 요청은 Chromium 기반 브라우저 내부에서 전송을 기다린다
아래는 Chromium 기반 브라우저의 일반적인 HTTP/1.1 요청을 기준으로 설명한다
왜 요청이 대기할까?
Chromium 기반 브라우저는 일반적으로 HTTP/1.1 연결 하나에서 요청과 응답을 순차적으로 처리한다
- 연결 6개가 각각 요청을 전송하고 응답을 받는 중
- 추가 요청이 발생함
- 사용할 연결이 생길 때까지 추가 요청이 대기함
- 기존 응답 수신이 끝나면 대기 요청을 전송할 수 있음
이 대기 중인 요청은 아직 서버에 전송되지 않았다
응답 본문까지 수신하고 연결을 재사용할 수 있으면, 같은 연결로 다음 요청을 보낸다. MDN HTTP/1.x 연결 관리 (opens in a new tab)
6개는 어떤 기준일까?
Chromium은 소켓 풀(socket pool) 안에서 연결 그룹(connection group)별로 기본 최대 6개의 연결을 사용하도록 제한한다. Chromium 연결 제한 구현 (opens in a new tab)
HTTP/1.1 표준은 고정된 최대 연결 수를 정하지 않는다. RFC 9112 (opens in a new tab)
Chromium의 연결 그룹을 나누는 기준
연결 그룹은 연결을 함께 재사용할 수 있는 요청들을 구분하는 단위다
Chromium의 ClientSocketPool::GroupId에는 다음 조건 등이 포함된다
| 조건 | 의미 |
|---|---|
destination | 목적지의 스킴·호스트(도메인 이름 또는 IP 주소)·포트 |
network_anonymization_key | 요청이 발생한 문맥에 따른 네트워크 격리 기준 |
privacy_mode, secure_dns_policy | 개인정보 보호 및 보안 DNS 관련 연결 설정 |
스킴·호스트·포트가 같으면 같은 출처(origin)다
같은 도메인에 대한 요청은 스킴·포트, 네트워크 격리 조건, 연결 설정도 같을 때 같은 연결 그룹을 사용한다. Chromium 연결 그룹 정의 (opens in a new tab)
탭을 여러 개 열면?
아래 조건으로 가정
- 같은 Chromium 기반 브라우저의 동일 프로필에서 일반 탭으로 HTTP/1.1 사용
- 각 페이지는 자기 출처로 요청
- 같은 출처의 탭은 네트워크 격리 조건과 연결 설정도 같음
- 소켓 풀 전체에는 여유가 있음
탭마다 도메인이 다를 때
| 탭 | 페이지 주소 | 요청 대상 | 사용할 수 있는 연결 |
|---|---|---|---|
| 탭 A | https://a.example/page | https://a.example | 기본 최대 6개 |
| 탭 B | https://b.example/page | https://b.example | 기본 최대 6개 |
서로 다른 연결 그룹을 사용하므로, 이 예시에서는 합계 12개의 연결을 동시에 사용할 수 있다
탭 A가 연결 6개를 모두 사용해도 탭 B는 자신의 연결 그룹에 남은 여유를 사용할 수 있다
탭이 달라도 도메인이 같을 때
| 탭 | 페이지 주소 | 현재 요청이 사용 중인 연결 |
|---|---|---|
| 탭 A | https://a.example/page1 | 4개 |
| 탭 B | https://a.example/page2 | 2개 |
두 탭이 같은 연결 그룹의 연결 6개를 공유한다
경로가 /page1, /page2로 달라도 같은 연결 그룹을 사용한다
이 상태에서는 어느 탭에서 추가 요청이 발생해도 사용할 연결을 기다린다. MDN 탭 사이 연결 제한 설명 (opens in a new tab)
4개와 2개는 해당 시점의 사용량이다
요청 상황에 따라 한 탭이 연결 6개를 모두 사용할 수도 있다
같은 도메인의 탭을 하나 더 열면?
탭 A와 탭 B의 요청이 아직 완료되지 않은 상태에서 탭 C를 열었다고 가정
| 탭 | 페이지 주소 | 연결 사용 상태 |
|---|---|---|
| 탭 A | https://a.example/page1 | 연결 4개 사용 중 |
| 탭 B | https://a.example/page2 | 연결 2개 사용 중 |
| 탭 C | https://a.example/page3 | 사용할 연결이 생길 때까지 요청 대기 |
탭이 늘어나도 해당 연결 그룹의 기본 제한은 6개로 유지된다
탭 C의 HTML을 네트워크에서 받아야 한다면 첫 화면 표시도 지연될 수 있다
탭 A의 요청 하나가 완료되고, Chromium 기반 브라우저가 탭 C의 대기 요청을 선택하면 다음처럼 바뀔 수 있다
| 탭 A | 탭 B | 탭 C | 합계 |
|---|---|---|---|
| 3개 | 2개 | 1개 | 6개 |
대기 요청의 처리 순서는 요청 우선순위 등에 따라 결정된다. Chromium 요청 대기 및 우선순위 설명 (opens in a new tab)
개발자 도구에서 확인하기
Chromium 기반 브라우저의 개발자 도구에서 Network를 확인한다
- 요청 목록의 열 제목을 우클릭하고
Protocol열을 표시 - 요청이 HTTP/1.1을 사용하는지 확인
- 대기 시간이 긴 요청을 선택하고
Timing확인
| 구간 | 의미 |
|---|---|
Queueing / Stalled | 연결 확보 등 요청 진행을 위한 대기 |
Waiting (TTFB) | 요청 전송 후 응답의 첫 바이트를 기다리는 시간 |
Content Download | 응답 본문을 받는 시간 |
Queueing이나 Stalled가 길면 연결 제한을 확인해볼 수 있다
다만 요청 우선순위나 캐시 처리 때문에도 나타날 수 있다. 개발자 도구의 요청 시간 구간 설명 (opens in a new tab)
같은 출처를 연 다른 탭에서 연결을 사용 중인지도 확인해야 한다
HTTP/2에서는?
HTTP/2는 하나의 연결에서 여러 요청과 응답을 다중화(multiplexing)한다
따라서 HTTP/1.1처럼 연결 6개를 각각 사용하느라 추가 요청이 대기하는 병목을 줄일 수 있다
HTTP/2에도 동시 스트림 수 제한이 있으므로 요청 대기는 발생할 수 있다. RFC 9113 (opens in a new tab)