클라우드플레어가 인터넷 규모 TCP 연결 특성을 측정한 방법

웹 페이지 로딩, 동영상 스트리밍, API 호출… 우리가 인터넷에서 하는 모든 상호작용은 '연결'로부터 시작하죠. 마치 물이 흐르듯, 기기와 기기 사이를 오가는 패킷들의 연속이 바로 이 연결입니다. 그런데 이 연결의 특성, 예를 들어 '얼마나 길고, 얼마나 크고, 얼마나 자주 발생할까?' 같은 기본적인 질문에 대한 답을 글로벌 인터넷 규모에서 얻기란 정말 어렵습니다.

일반적인 사용자라면 Wireshark 같은 도구로 내 컴퓨터의 연결을 들여다볼 수 있지만, 전 세계 인터넷의 모든 연결을 측정하는 건 사실상 불가능합니다. 대부분의 네트워크 운영사들도 이러한 내부 데이터를 공유하지 않으니, 새로운 프로토콜이나 알고리즘을 개발할 때 필요한 '현실 데이터'를 확보하기가 어려웠어요.

그래서 이 글에서는 클라우드플레어의 글로벌 CDN을 통해 관찰한 TCP 연결의 집계된 인사이트를 공유합니다. 우리 모두의 인터넷 경험을 더 빠르고 안정적으로 만들기 위한 필수 지식들을 다음 내용을 중심으로 살펴볼 거예요:

인터넷 연결의 50%가 '쥐'처럼 짧고 가벼운 이유 - 패킷 수, 바이트 전송량, 지속 시간 분석
HTTP/1.X와 HTTP/2가 연결 재사용에서 보여주는 극명한 차이 - 연결당 요청 수 심층 분석
클라이언트와 서버 간 비대칭적인 데이터 교환의 비밀 - 패킷/바이트 비율로 본 숨겨진 이야기
TCP 연결 특성으로 예측하는 네트워크 경로의 잠재력 - PMTU와 초기 혼잡 윈도우(ICWND)의 실제 값
BBR의 '뻥튀기' ICWND가 작은 연결 성능에 30-40% 영향을 미치는 이유 - 기본 10 패킷의 한계점

🧐 왜 인터넷 연결의 '진짜' 모습을 알기 어려웠을까요?

인터넷의 모든 상호작용은 TCP 연결에서 시작되지만, 이 근본적인 연결의 특성을 글로벌 규모에서 파악하는 것은 오랫동안 큰 도전이었습니다. 1991년 "Characteristics of wide-area TCP/IP conversations" 같은 연구가 있었지만, 수십 년이 지난 지금도 광범위한 실측 데이터는 여전히 부족합니다.

글로벌 측정의 한계

개인이 Wireshark 같은 도구로 로컬 데이터를 캡처할 수는 있지만, 전 세계적인 연결을 측정하는 것은 접근성과 규모 문제로 거의 불가능합니다. 게다가 대부분의 네트워크 운영자들은 관찰 데이터를 공유하지 않아요. 이는 새로운 라우팅 알고리즘이나 전송 프로토콜의 효과를 예측하고, 더욱 현실적인 시뮬레이션을 만드는 데 큰 걸림돌이 됩니다.

클라우드플레어는 이러한 문제에 대한 해답을 찾기 위해, 자사의 글로벌 CDN을 통하는 TCP 연결의 집계된 특성을 분석하고 공유합니다. 이는 HTTP 요청의 약 70%를 차지하는 TCP 연결에 대한 경험적 통찰력을 제공하며, 클라이언트 측 측정만으로는 얻기 힘든 귀중한 정보를 담고 있습니다.

🛰️ 클라우드플레어는 어떻게 '숨겨진' 연결 데이터를 모았을까?

어떤 데이터든 그 가치는 수집 메커니즘에 달려 있습니다. 클라우드플레어는 다음 원칙에 따라 데이터를 수집했어요:

광범위한 데이터셋: HTTP 1.0, 1.1, 2.0을 통해 클라우드플레어 글로벌 CDN으로 들어오는 TCP 연결을 분석했습니다. 이는 평균 초당 8천 4백만 개의 HTTP 요청 중 약 70%에 해당하죠.
정밀한 샘플링: 2025년 10월 7일부터 15일까지 전체 TCP 연결의 1%를 균일하게 샘플링했습니다. 데이터 센터 레벨의 편향을 줄이기 위해 각 클라이언트-향 서버에서 개별적으로 샘플링을 진행했어요.
독보적인 다양성: 일반적인 대형 운영사와 달리, 클라우드플레어 트래픽은 고객들의 다양성 덕분에 웹 애플리케이션, 서비스, 전 세계 사용자들의 광범위한 행동을 반영합니다.
'유용한' 연결 선별: 공격 완화, 타임아웃, RST 패킷으로 종료된 연결은 제외하고, FIN 패킷으로 정상 종료되며 최소 하나 이상의 성공적인 HTTP 요청을 처리한 연결만 분석에 포함했습니다. 이러한 필터링 후에도, 유휴 연결이나 비-HTTP 연결이 전체의 11%를 차지한다는 점은 흥미로운 부분입니다.

이러한 과정을 통해 수집된 데이터는 Linux 커널의 TCP_INFO 구조체를 통해 캡처된 소켓 레벨 메타데이터, SNI, 연결당 요청 수 등으로 구성됩니다.

📦 50%의 연결은 왜 '쥐'처럼 가볍고 짧을까? (패킷 & 바이트)

"코끼리와 쥐" 현상처럼 인터넷 트래픽은 대부분 작고 일부는 매우 크다는 것은 잘 알려져 있습니다. 클라우드플레어 데이터는 이를 명확히 보여줍니다.

응답 패킷 중앙값

12개

전체 TCP 연결의 50%

HTTP/1.X 패킷 중앙값

10개

HTTP/2는 16개

서버 전송 바이트 중앙값

4.8KB

HTTP/1.X 기준 (HTTP/2는 6KB)

응답 패킷의 중앙값은 고작 12개로, 인터넷 연결의 절반이 극도로 가볍다는 것을 의미합니다. 90%도 107개 패킷을 넘지 않죠. 바이트 전송량 역시 HTTP/1.X는 중앙값 4.8KB, HTTP/2는 6KB로 대부분의 상호작용이 매우 작다는 것을 알 수 있습니다. 이는 비디오 스트림 같은 대량 데이터 전송과 달리, 작은 웹 객체나 API 응답이 주를 이루기 때문입니다.

흥미로운 점은 클라이언트-서버 패킷 비율입니다. 중앙값은 0.91로, 서버가 응답하는 것보다 클라이언트가 약간 더 많은 패킷을 보냅니다. 이는 TLS 핸드셰이크나 HTTP 제어 요청 헤더, 데이터 ACK 때문이죠. 반면, 바이트 비율은 서버가 클라이언트에 비해 데이터를 약 4배 더 많이 보내는 경향을 보입니다 (중앙값 3.78). 이는 CDN의 주요 역할인 다운로드 중심의 흐름을 반영합니다.

⏱️ 대부분의 연결은 왜 5초 안에 끝날까? (지속 시간 & 요청 수)

패킷과 바이트가 연결의 크기를 알려준다면, 지속 시간은 연결이 얼마나 오래 유지되는지를 보여줍니다.

연결 지속 시간 중앙값

4.7초

전체 연결의 50%가 5초 미만

HTTP/1.X 요청 중앙값

1개

90%는 2개 이하

HTTP/2 요청 중앙값

1개

90%는 10개 이상 (멀티플렉싱)

연결 지속 시간의 중앙값은 단 4.7초입니다. 이는 인터넷 트래픽의 대다수가 짧고 일시적이라는 것을 말해주죠. 평균은 96초로 길지만, 이는 며칠씩 유지되는 소수의 장기 연결(keep-alives)이 평균을 끌어올린 결과입니다. 대부분은 0.1초에서 300초 사이에 분포합니다.

또한, 연결당 처리되는 HTTP 요청 수를 보면 흥미로운 재사용 패턴을 발견할 수 있습니다. HTTP/1.X와 HTTP/2 모두 중앙값은 1개로, 여전히 제한적인 연결 재사용이 일반적입니다. 그러나 HTTP/2는 멀티플렉싱 덕분에 90th 퍼센타일이 10개 요청까지 오르며, 연결 코얼레싱 등으로 수천 개의 요청을 처리하는 경우도 있습니다. 이는 HTTP/1.X가 90th 퍼센타일에서 2개 요청에 그치는 것과 대조적입니다.

데이터 센터 발(자동화된) 트래픽은 연결당 평균 3개 요청, 90th 퍼센타일 2개인 반면, 사용자 주도 트래픽은 평균 5개, 90th 퍼센타일 5개로 약간 더 높은 재사용률을 보였습니다. 하지만 두 경우 모두 중앙값은 여전히 1개로, 대부분의 연결이 짧고 단발적이라는 사실은 변함없습니다.

🛣️ TCP 연결 데이터로 네트워크 경로를 예측하는 방법

연결 수준 측정은 네트워크 경로의 특성까지 유추할 수 있게 해줍니다.

경로 MTU (PMTU) 분석

PMTU는 단편화 없이 전송될 수 있는 최대 패킷 크기를 결정하며, 처리량과 효율성에 영향을 줍니다. 클라우드플레어 데이터에 따르면 중앙값과 90th 퍼센타일 PMTU는 1500바이트로, 일반적인 이더넷 MTU와 일치합니다. 10th 퍼센타일은 1420바이트인데, 이는 VPN이나 IPv6-over-IPv4 터널 같은 환경에서 약간 작은 MTU를 사용하는 경우를 반영합니다. IPv4 연결의 경우 552바이트까지 작은 MTU도 관찰되었습니다.

🚀 초기 혼잡 윈도우(ICWND)의 실제 값

ICWND는 TCP 연결 초기에 중요한 역할을 합니다. 너무 낮으면 작은 전송에 추가 RTT가 필요하고, 너무 높으면 네트워크를 과부하 시킬 위험이 있죠. BBR의 'slow start' 종료 시점 CWND 중앙값은 약 464KB (약 310개 패킷)로 나타났습니다. 하지만 이는 BBR이 대역폭 지연 곱(BDP) 추정치보다 CWND를 의도적으로 높게 설정하는 특성 때문입니다.

실제 BBR의 BDP 추정치 중앙값은 약 77KB (약 50개 패킷)로 훨씬 안정적인 값을 보여주죠. 이러한 차이는 ICWND의 최적값을 찾는 데 중요한 통찰력을 제공하며, 수십 년간 10개 패킷으로 고정되어 있던 기본 ICWND 값을 재고할 필요가 있음을 시사합니다. 클라우드플레어 내부 실험 결과, ICWND가 작은 연결 성능에 30-40%까지 영향을 미칠 수 있습니다.

✅ 더 깊은 이해가 더 나은 인터넷을 만든다

클라우드플레어가 수집한 대규모 TCP 연결 데이터는 인터넷 연결이 "코끼리와 쥐" 현상과 같은 헤비테일 특성을 강하게 보인다는 수십 년간의 관찰을 다시 한번 확인시켜 줍니다. 특히 작은 흐름에서 업로드-다운로드 바이트 비율이 예상보다 훨씬 작다는 점은 인터넷 트래픽의 비대칭성을 명확히 보여주죠.

이러한 연결 특성에 대한 심도 깊은 이해는 연결 성능, 안정성, 그리고 사용자 경험을 지속적으로 개선하는 데 핵심적인 역할을 합니다. 클라우드플레어는 이 연구를 바탕으로 Cloudflare Radar에 연결 수준 통계를 공개하여, 더 많은 사람이 이 인사이트를 활용할 수 있도록 할 계획입니다.

우리의 네트워크 개선 작업은 현재진행형이며, 연구원, 학계 전문가, 인턴 등 이 분야에 관심 있는 모든 분들의 협력을 환영합니다. 함께 지식을 공유하고 노력함으로써 우리는 모두를 위한 인터넷을 더 빠르고 안전하며 신뢰할 수 있도록 만들 수 있습니다.

실전 적용 인사이트

클라우드플레어의 TCP 연결 특성 분석은 인터넷 트래픽의 복잡성과 비대칭성을 명확히 보여줍니다. 중앙값 4.7초의 짧은 연결, 12개의 적은 패킷, 그리고 BBR ICWND의 잠재적 최적화 가능성까지. 이러한 데이터 기반의 이해는 차세대 네트워크 프로토콜 및 인프라 설계에 필수적인 인사이트를 제공합니다.

원문 읽기 →