10여 년 전, Google의 연구원들은 "더 많은 대역폭은 (별로) 중요하지 않다"라는 이단적인 제목의 논문을 발표했습니다. 저희는 자체 블로그에 샌프란시스코에서 런던으로 1TB의 데이터를 전송하는 것이 100Mbps 연결로 업로드하는 것보다 더 빠르다는 내용의 글을 게시했습니다. 안타깝게도 상황은 크게 변하지 않았습니다. 가정용 인터넷 요금제에 대한 구매 결정을 내리기 위해 인터넷 성능을 평가할 때에는 연결 대역폭을 고려할 것입니다. 대역폭이 많을수록 속도가 빠르다는 것이 마케팅의 논리입니다. 이 포스팅에서는 실제 데이터를 사용하여 대역폭과 - 스포일러 주의! - 대기 시간이 인터넷 연결 속도에 어떤 영향을 미치는지 보여드리겠습니다. 끝으로 Cloudflare가 왜 가능한 모든 곳에서 지연 시간을 줄이는 데 집중하는지 설명해 드리겠습니다.
본 블로그의 내용을 요약해 드리면 다음과 같습니다.
- 네트워크 성능을 평가하는 방법에는 여러 가지가 있습니다.
- 성능 "우수성"은 애플리케이션에 따라 달라지며, 한 애플리케이션에는 좋은 수치가 다른 애플리케이션에는 전혀 도움이 되지 않을 수 있습니다.
- 특히 단일 지표로는 모든 애플리케이션의 성능을 정확하게 설명할 수 없기 때문에 '속도'라는 수치 역시 오해의 소지가 있을 수 있습니다.
이러한 아이디어를 더 잘 이해하려면 대역폭과 대기 시간을 정의해야 합니다. 대역폭은 한 번에 전송할 수 있는 데이터의 양입니다. 데이터를 교환하려는 두 서버 간 통신 링크의 최대 처리량 또는 용량입니다. '병목 현상'은 네트워크에서 사용 가능한 대역폭의 양에 따라 연결이 제한되는 현상입니다. 일반적으로 병목 현상은 가정을 연결하는 케이블이나 가정 자체의 모뎀 또는 라우터와 같은 "라스트 마일"에서 발생합니다.
인터넷이 정보 고속도로라면 대역폭은 도로의 차선 수입니다. 도로가 넓을수록 더 많은 트래픽이 언제든지 고속도로에 들어갈 수 있습니다. 대역폭은 운영 체제 업데이트나 대규모 게임 업데이트와 같은 대용량 파일을 다운로드할 때 유용합니다. 생각보다 적은 양이지만 동영상을 스트리밍할 때도 대역폭을 사용합니다. 넷플릭스는 4K/Ultra HD 스트리밍 시청에 15Mbps의 대역폭을 권장합니다. 1Gbps 연결은 60개 이상의 넷플릭스 프로그램을 4K로 동시에 스트리밍할 수 있도록 해줍니다!
반면 대기 시간은 데이터가 인터넷을 통해 이동하는 데 걸리는 시간입니다. 고속도로에 비유하자면, 대기 시간은 고속도로에서 차량이 이동하는 속도와 같습니다. 차량이 빠르게 이동하면 목적지에 더 빨리 도착할 수 있습니다. 대기 시간은 데이터 패킷이 클라이언트(예: 노트북 컴퓨터)와 서버 사이를 이동하는 데 걸리는 시간(밀리초)으로 측정됩니다. 실제로 대기 시간은 클라이언트와 서버 간의 왕복 시간(RTT)으로 측정해야 하는데, 모든 디바이스에는 고유한 클럭이 있어 한 방향으로만 대기 시간을 측정하기 어렵기 때문입니다. 벽에 대고 테니스 연습을 하는 경우 왕복 대기 시간은 공이 공중에 떠 있는 시간입니다. 인터넷 광섬유 "백본"에서 데이터는 광섬유 내 유리에 반사되면서 초당 거의 200,000킬로미터 속도로 이동합니다. 정말 빠른 속도입니다!
대기 시간이 짧은 연결은 플레이어의 위치 변경과 같은 작은 데이터 비트가 다른 컴퓨터에 빠르게 도달해야 하는 게임에서 매우 중요합니다. 그리고 점점 더 많은 사람들이 지연 시간이 길어지면 라이브 화상 회의가 끊기고 불쾌해진다는 사실을 인지하고 있습니다.
유리를 통과하는 빛의 속도를 훨씬 빠르게 만들 수는 없지만, 콘텐츠를 사용자에게 더 가깝게 이동시켜 데이터가 이동해야 하는 거리를 단축함으로써 대기 시간을 개선할 수 있습니다. 이것이 바로 전 세계 285개 도시에 네트워크를 구축한 우리의 힘입니다. Cloudflare에 도달하기 위해 인터넷 고속도로에 올라오면 바로 다음 출구에 도착할 수 있는 셈입니다.
대역폭, 용량 및 최대 처리량이라는 용어는 서로 약간 다르지만 그 의미는 상호 교환 가능한 수준으로 가깝습니다. 인터넷 요금제에 대해 이야기할 때 "속도"는 대역폭을 의미하지만 이 "속도"라는 말에 사용자 기기와 서버 간 대기 시간에 대한 암시는 없습니다. 이에 대해서는 나중에 자세히 설명하겠습니다. 현재로서는 인터넷을 게임이나 스트리밍 비디오 시청에만 사용하지 않습니다. 우리는 이 외에도 웹페이지 방문을 비롯해 다양한 작업을 인터넷에서 수행합니다.
2010년 Google의 논문에서 저자는 연결 처리량과 대기 시간을 바꿔가면서 웹 페이지 로딩을 시뮬레이션했습니다. 그 결과 약 5Mbps 이상에서는 페이지가 더 이상 빠르게 로드되지 않는 것으로 나타났습니다. 대역폭을 1Mbps에서 2Mbps로 늘리면 페이지 로딩 시간이 거의 40% 향상되고, 5Mbps에서 6Mbps로 증가하면 개선 효과가 5% 미만에 그칩니다.
하지만 대기 시간(라운드 트립 시간, RTT)을 변경했을 때에는 흥미로운 현상이 나타났습니다. 페이지 로딩 시간이 선형적이고 비례적으로 개선되었습니다. 대기 시간이 20밀리초 감소할 때마다 페이지 로드 시간이 약 10%씩 개선되었습니다.
경험적 데이터를 통해 실생활에서 어떤 모습인지 살펴봅시다. 아래는 MIT의 두 연구원이 최근 발표한 논문 의 차트입니다. 이 연구자들은 FCC의 광대역 미국 측정 프로그램의 데이터를 사용하여 2010년 시뮬레이션과 유사한 결과를 보여주는 차트를 만들었습니다. 그 결과는 아래 차트에 요약되어 있습니다. 더 많은 대역폭에 대한 수익이 감소하는 지점이 약 20Mbps로 더 높아졌지만 전반적인 추세는 정확히 동일했습니다.
자체 Cloudflare 데이터를 사용하여 대기 시간에 중점을 두고 이 분석을 반복했습니다. 결과는 다음 차트에 요약되어 있으며, 익숙한 패턴을 보여줍니다. 대기 시간을 200밀리초 줄일 때마다 페이지 로드 시간을 1초 이상 단축할 수 있습니다. 이 관계는 대기 시간이 950밀리초인 경우에도 적용되고, 대기 시간이 50밀리초일 때도 적용됩니다.
페이지를 로드하는 데 필요한 일련의 트랜잭션에서 대기 시간이 중요한 이유가 몇 가지 있습니다. 웹 사이트에 연결할 때 브라우저에서 가장 먼저 하는 일은 보안 연결을 설정하여 웹 사이트를 인증하고 데이터가 암호화되도록 하는 것입니다. 이를 위한 프로토콜은 TCP와 TLS, 또는 QUIC(기본적으로 암호화됨)입니다. 보안 연결을 설정하는 데 필요한 메시지 교환 횟수는 각기 다르지만, 설정 단계의 한 가지 측면은 모든 프로토콜에 공통으로 적용됩니다. 대기 시간이 가장 중요하다는 것입니다.
또한 암호화를 설정하고 웹사이트 권한을 확인한 후 웹페이지를 로드할 때 브라우저에게 수십 개의 서로 다른 도메인에 걸쳐 있는 수백 개의 서로 다른 파일을 로드해달라고 요청하는 것일 수도 있습니다. 이러한 파일 중 일부는 병렬로 로드할 수 있지만 다른 파일은 순차적으로 로드해야 합니다. 브라우저는 이러한 다양한 파일을 모두 컴파일하려고 시도하기 때문에 서버로 전송하는 속도에 따라 페이지가 얼마나 빠르게 구성될 수 있는지가 결정됩니다. 파일은 대개 크기는 매우 작지만 그 수는 매우 많습니다.
아래 차트에는 브라우저에서 cnn.com을 로드할 때 수행되는 작업의 시작이 나와 있습니다. 첫 번째 단계는 연결 핸드셰이크 단계이며 다음으로 www.cnn.com으로의 301 리디렉션이 이어지는데, 여기에는 브라우저가 2단계에서 기본 HTML 페이지를 로드하기 전에 완전히 새로운 연결 핸드셰이크가 필요합니다. 그런 다음에 로딩 후 1초 이상이 지나야 페이지를 렌더링하는 데 필요한 모든 JavaScript 파일에 대해 브라우저에서 학습합니다. 파일 3~19는 대부분 동일한 연결에서 요청되지만, HTML 파일이 완전히 전달될 때까지는 제공되지 않습니다. 파일 8, 9, 10은 별도의 연결을 통해 요청됩니다(모두 핸드셰이크가 수반됨). 파일 20~27은 모두 이전 파일에서 차단되었으며 마찬가지로 새 연결이 필요합니다. 브라우저에서는 서버에서 이전 파일을 다시 가져와 실행할 때까지 이들 파일을 시작할 수 없습니다. 이 페이지 로딩에는 650개의 자산이 포함되며, 차단은 페이지 로딩 내내 발생합니다. 이에 따라 대기 시간이 개선되어 모든 파일이 더 빨리 로드되고, 다른 파일의 차단이 더 빨리 해제되는 등 여러 가지 이점이 있습니다.
프로토콜은 사용 가능한 모든 대역폭을 사용하지만 사용 가능한 대역폭이 모두 소모되기 전에 전송을 완료하는 경우가 많습니다. 따라서 대역폭을 더 추가한다고 해서 페이지 로딩 속도가 빨라지는 것은 아니지만 대기 시간이 개선되는 것은 당연한 효과를 가져옵니다. Early Hints 같은 개발은 브라우저에 종속성을 더 일찍 알려주어 서버에 미리 연결하거나 엄격하게 주문할 필요가 없는 리소스를 미리 가져올 수 있도록 함으로써 이 문제를 해결하지만, 오늘날 인터넷의 많은 웹사이트에서는 여전히 이 문제가 발생합니다.
최근 인터넷 연구자들은 처리량과 대기 시간 간의 관계에 대한 이해를 바탕으로 인터넷 체감 품질(QoE)을 개선하는 데 관심을 돌리고 있습니다. 광대역 인터넷 기술 자문 그룹(BITAG)의 논문은 다음과 같이 요약합니다.
하지만 이제는 더 많은 처리량뿐만 아니라 일관되게 낮은 대기 시간도 중요하다는 것을 잘 알고 있습니다. 안타깝게도 지금까지 대기 시간을 이해하고 특성화하는 방식에는 결함이 있었고, 대기 시간 측정 및 지표가 최종 사용자 체감 품질과 일치하지 않았습니다.
유휴 인터넷 연결에서의 대기 시간과 많은 연결이 네트워크 리소스를 공유하는 작업 조건에서 측정한 대기 시간 사이에는 차이가 있으며, 후자를 "작업 대기 시간" 또는 "응답 속도"라고 합니다. 응답 속도는 사용자가 인터넷 연결 속도로 경험하는 것이므로 이 특정 대기 시간을 이해하고 측정하는 것이 중요합니다.
인터넷 연결은 버퍼에서 데이터가 지연되면 유휴 대기 시간이 양호하더라도 응답 속도가 저하될 수 있습니다. 운영 체제 업데이트와 같은 대용량 파일을 다운로드하는 경우, 파일을 전송하는 서버가 인터넷 연결이 수용할 수 있는 처리량보다 높은 처리량으로 파일을 전송할 수 있습니다. 이건 괜찮습니다. 파일의 여분의 비트는 퍼널을 통과할 차례가 될 때까지 버퍼에 보관됩니다. 고속도로에 차선을 추가하면 더 많은 차량이 통과할 수 있으며, 교통 속도에 특별히 신경 쓰지 않는다면 좋은 전략이 될 수 있습니다.
예를 들어 크리스타벨이 화상 회의 중에 뉴스 스트림을 시청하고 있다고 가정해 보겠습니다. 크리스타벨이 동영상을 시청하기 시작하면 브라우저는 콘텐츠 호스트에서 브라우저로 이동하는 동안 여러 콘텐츠를 가져와 다양한 버퍼에 저장합니다. 동일한 버퍼에는 크리스타벨이 현재 참여 중인 화상 회의와 관련된 데이터 패킷도 포함되어 있습니다. 화상 회의의 일부로 생성된 데이터가 비디오 파일과 동일한 버퍼에 있으면 비디오 파일이 버퍼를 가득 채우고 화상 회의 패킷도 지연될 수 있습니다. 버퍼가 클수록 화상 회의 패킷을 기다리는 시간이 길어집니다.
사용자가 연결의 강점과 약점을 이해하는 데 도움을 주기 위해 최근 종합 인터넷 측정(AIM) 점수를 자체 "속도" 테스트에 추가했습니다. 이 점수는 기술적인 지표를 제거하여 사용자가 자신의 연결 상태가 어느 정도인지, 어디에서 문제가 발생할 수 있는지에 대해 실제적이고 평이한 방식으로 이해할 수 있도록 해줍니다. 또한 속도 테스트에서 더 많은 데이터를 수집하여 페이지 로드 시간(PLT)을 추적하고 이 수치가 작업 대기 시간 단축과 어떤 상관관계가 있는지 확인할 계획입니다. 곧 속도 테스트에서 이러한 수치를 확인할 수 있을 것입니다!
우리는 모두 조금씩 다른 방식으로 인터넷을 사용하지만, 가능한 한 빠른 연결을 원한다는 공통점이 있습니다. 워드 문서, 음악, 웹사이트, 커뮤니케이션 등 점점 더 많은 서비스가 클라우드로 이동함에 따라 이러한 서비스에 액세스할 수 있는 속도가 중요해지고 있습니다. 대역폭도 중요하지만, 연결 대기 시간, 즉 실제 인터넷 "속도"가 더 중요합니다.
Cloudflare는 더 나은 성능의 인터넷을 구축하기 위해 매일 노력하고 있습니다. 이 노력에 동참하고 싶으신가요? 여기에서 채용 중인 엔지니어링 공고에 지원하세요.