TCP Slow Start 변경에 대한 클라이언트 측 주장¶

작성자: Mike Belshe (mbelshe@chromium.org) 날짜: 2010년 1월 11일

TCP Slow Start란¶

Slow Start는 TCP 혼잡 제어 알고리즘의 핵심 요소입니다.

참고: http://www.faqs.org/rfcs/rfc2581.html

그리고, "패킷 전달의 동작 방식에 주의를 기울이지 않으면 심각한 서비스 저하 또는 '인터넷 붕괴'를 초래할 수 있다"

— Sally Floyd, http://www.rfc-editor.org/rfc/rfc2914.txt

그런데 오늘날의 웹 브라우저들은 의도치 않게 Slow Start를 무력화하고 있습니다....

HTTP 배경¶

HTTP는 원래 단순했습니다¶

연결 열기
요청 전송
응답 수신
서버가 연결을 끊으면 완료!

구현하기 매우 쉬웠지만... 네트워크 효율 면에서는 그다지 좋지 않았습니다.

하지만 비효율성은 크게 문제가 되지 않았습니다¶

초기 웹 페이지는 매우 작았습니다 — 텍스트 조금과 강아지 사진 한두 장 정도였죠. CSS, JS, 동영상 같은 것은 없었습니다.

웹 페이지가 커지면서 간단한 최적화들이 추가되었습니다:

Keep-Alive로 TCP 연결 재사용
캐싱 지원 강화
기타 등등

하지만...

웹 페이지는 계속 커졌습니다¶

기술이 발전하면서 CSS, JavaScript, 이미지 사용이 급격히 증가했습니다.

상위 100대 사이트 평균 페이지당 약 40개의 요청 발생 (캐시 미적용 시)
브라우저는 여전히 사이트당 2개의 연결로 제한됨 (스펙 기준)
우회 방법은 쉽게 찾을 수 있었습니다...

Slow Start 우회하기¶

동시에 두 개의 요청만 보내는 것은 병목이 되었습니다. 속도를 원하는 사이트들은 더 많은 연결이 필요했습니다.

기존 브라우저가 서브도메인마다 2개씩 연결을 열었기 때문에 "서브도메인 샤딩(Subdomain Sharding)" 기법이 고안되었습니다.
결국 브라우저의 연결 제한이 상향 조정되었습니다.
도메인당 2개 연결 → 6개로 증가

그 결과, Slow Start는 사실상 무력화되었습니다.

도메인당 6개 연결
× 서브도메인 6개
× 연결당 초기 cwnd 3
= 초기 cwnd 108  (RFC2581이 제안하는 값과는 전혀 다릅니다!)

문제는 누구에게 있을까요?¶

TCP 스펙이 잘못된 걸까요?
Slow Start가 너무 공격적인 걸까요? 끄면 인터넷이 무너질까요?
아니면 이것이 오늘날 웹 페이지에서 1~1.5%의 패킷 손실이 발생하는 이유일까요?

"답은 모르겠지만, 이것이 현실입니다."

더 나은 프로토콜을 만들려는 시도: SPDY¶

SPDY는 HTTP의 근본적인 문제들을 해결하려 합니다:

직렬화된 요청 처리 문제
압축 부족 문제

그리고 실제로 더 효율적입니다:

전체 패킷 수 40% 감소
전송 바이트 15% 감소
대부분의 경우 더 빠름

그런데 Slow Start가 발목을 잡습니다¶

SPDY는 더 적은 TCP 연결로 네트워크를 효율적으로 활용하려 합니다. 하지만:

프로토콜	도메인당 연결 수	초기 cwnd
SPDY	1개	~3
HTTP	6개	~18 (6배)

결과적으로 HTTP의 초기 cwnd가 "효율적인" 프로토콜보다 6배 더 큽니다!

실제 사례: Slow Start 병목 현상¶

테스트 환경¶

네트워크: - 100 Mbps - RTT 200ms - 패킷 손실 0%

브라우저: Chrome (SPDY 사용, 단일 연결, 캐시 없음)

대상 페이지: http://www.facebook.com/

(이 현상은 매우 많은 웹 페이지에서 관찰됩니다 — Facebook 페이지 자체에는 아무 문제가 없습니다.)

초기 cwnd를 18로 늘리면 어떻게 될까요?¶

초기 cwnd를 HTTP의 유효 cwnd 수준인 18로 늘리면, SPDY의 로딩 시간이 크게 향상되어 기존 HTTP 성능에 근접하게 됩니다.

초기 cwnd 증가, 어떻게 봐야 할까요?¶

초기 cwnd를 늘려야 하느냐의 문제가 아닙니다. HTTP는 이미 증가된 상태입니다.

데이터¶

상황	유효 초기 cwnd
사이트가 이미 사용 중인 init-cwnd	3
HTTP (도메인당 6개 연결)	18
서브도메인 3~8개 사용 시	54 ~ 144

하지만 현실적으로 가능할까요?¶

initcwnd는 일반적으로 TCP 내부에 숨겨진 전역 설정입니다.
전역으로 늘리면 HTTP의 init-cwnd는 항상 적정 수준의 최소 6배 이상이 됩니다.
SPDY를 쓰더라도, 사이트들이 서브도메인 샤딩을 그만두지 않는 한 유효 cwnd는 TCP가 강제하려는 값보다 높습니다.
인터넷 전체가 cwnd를 늘릴까요? 최소한 커널 패치가 필요하고, 소켓 API 변경도 필요할 수 있습니다.

결론¶

네트워크를 최대한 효율적으로 사용하려는 모든 TCP 기반 프로토콜은 HTTP보다 더 적은 TCP 연결을 사용하게 됩니다.
하지만 연결 수를 줄이면 고지연 환경에서 TCP Slow Start로 인해 오히려 불리해집니다.
Slow Start는 ~2~4 패킷으로 규정되어 있지만, 현실에서는 이미 다중 연결과 서브도메인 사용으로 인해 그 한계를 훨씬 넘어선 상태입니다.
TCP가 initcwnd를 늘리지 못한다면, 차세대 HTTP 프로토콜은 TCP 기반이 아닐 가능성이 높습니다.

쉽게 이해하기: cwnd란 무엇이고 이 글은 무슨 말을 하는가?¶

cwnd(Congestion Window)란?¶

cwnd는 Congestion Window(혼잡 윈도우)의 줄임말로, TCP가 "확인(ACK)을 받기 전까지 한 번에 보낼 수 있는 데이터의 최대량"을 의미합니다.

쉽게 비유하자면, 택배 기사가 배달할 수 있는 상자 수라고 생각하면 됩니다. cwnd = 3이면 한 번에 상자 3개를 보내고, 수신 확인이 오면 다음 배달을 합니다.

TCP Slow Start가 왜 존재하는가?¶

인터넷이 막 시작될 때, 누군가 데이터를 너무 빠르게 쏟아내면 네트워크가 혼잡해져 "인터넷 마비"가 생겼습니다. 이를 막기 위해 TCP는 처음엔 조금만 보내고, 문제 없으면 조금씩 늘려가는 Slow Start 방식을 채택했습니다.

처음: cwnd = 3 (조심스럽게 시작)
  → 잘 됨 → cwnd = 6
  → 잘 됨 → cwnd = 12
  → 패킷 손실 → cwnd 다시 줄임

RFC(인터넷 표준 문서)는 초기 cwnd를 약 2~4 패킷으로 규정하고 있습니다.

이 글의 핵심 주장¶

이 글은 Slow Start 규칙이 브라우저들의 관행 때문에 이미 사실상 사문화(死文化)되었다고 주장합니다.

어떻게 무력화되었나?

브라우저는 원래 사이트당 연결을 2개로 제한했는데, 이것이 느리자 사이트들은 꼼수를 썼습니다.

서브도메인 샤딩: img1.site.com, img2.site.com, img3.site.com처럼 서브도메인을 여러 개 만들면, 브라우저가 각각에 새 연결을 열어줌 → 연결 수 폭발적으로 증가

결국 브라우저도 도메인당 6개 연결을 공식 허용했고, 그 결과:

도메인당 연결 6개
  × 서브도메인 6개
  × 연결당 초기 cwnd 3
= 실질적 초기 cwnd 108

RFC가 규정한 3~4가 아니라, 현실에서는 이미 108짜리 cwnd로 동작하고 있는 셈입니다.

SPDY(HTTP/2의 전신)가 왜 손해를 보는가?¶

구글은 SPDY라는 더 효율적인 프로토콜을 만들었습니다. SPDY는 연결 하나로 모든 요청을 처리해서 네트워크를 훨씬 덜 낭비합니다.

그런데 아이러니하게도, "효율적이라서 손해"를 봅니다.

	HTTP	SPDY
연결 수	6개	1개
실질 초기 cwnd	~18	~3
첫 번째 왕복(RTT)에 보낼 수 있는 데이터	6배 많음	적음

고속도로 비유로 설명하면, HTTP는 차선을 6개 쓰는데 SPDY는 규칙을 지켜 1개만 씁니다. 출발선에서 보낼 수 있는 데이터량이 6배 차이나니, SPDY가 오히려 느리게 느껴지는 상황이 발생합니다.

결론이 무엇을 의미하는가?¶

이 글은 2010년에 쓰였지만, 매우 선견지명이 있었습니다. 저자의 마지막 결론은 이렇습니다:

"TCP가 initcwnd를 늘릴 수 없다면, 차세대 HTTP는 TCP 기반이 아닐 것이다."

실제로 이 예측은 맞아떨어졌습니다. 현재의 HTTP/3는 TCP가 아닌 UDP 기반의 QUIC 프로토콜을 사용합니다. TCP의 Slow Start 같은 제약을 근본적으로 피하기 위해 프로토콜 자체를 바꾼 것입니다.

즉, 이 문서는 HTTP/3의 탄생 배경을 설명하는 역사적으로 중요한 글이라고 볼 수 있습니다.