최종 사용자 경험을 더 잘 이해하기 위한 네트워크 품질 측정

연휴를 맞아 가족을 방문하고 Wi-Fi에 연결했는데, 넷플릭스가 평소보다 빠르게 로딩되지 않는 것을 발견했습니다. Cloudflare.com, fast.com, speedtest.net, Google Chrome에서 "속도 테스트"를 입력하여 인터넷 연결에 문제가 있는지 확인하면 다음과 같은 메시지가 표시됩니다.

어떤 모습인지 확인하려면 여기에서 직접 사용해 보세요. 하지만 이들 숫자는 무엇을 의미할까요? 이들 숫자는 넷플릭스가 로딩되지 않는지 여부 또는 다른 일반적인 사용 사례인 게임이나 친구 및 가족과의 오디오/비디오 채팅과 어떤 관련이 있을까요? 네트워크 엔지니어조차도 속도 테스트는 인터넷 사용에 대한 사용자 경험과 연관 짓기 어렵다는 것을 알고 있습니다.

놀랍게도, 인터넷 사용 방식이 많이 바뀌었음에도 불구하고 속도 테스트는 거의 20년 동안 별로 변하지 않았습니다. 인터넷 사용자가 훨씬 더 많아지면서 속도 테스트 결과와 사용자가 체감하는 네트워크 품질 간의 격차가 점점 더 커지고 있습니다. 이 문제는 인터넷 표준 기구에서도 주목할 만큼 중요한 문제입니다.

높은 수준에서 보면, 크게 세 가지 네트워크 테스트 과제가 있습니다.

1. 네트워크 품질을 효율적이고 정확하게 측정하고 품질이 사용자 경험에 어떤 영향을 미치는지를 최종 사용자에게 전달할 수 있는 방법 찾기.
2. 문제가 발견되면 무선 연결 또는 인터넷을 구성하는 여러 케이블과 컴퓨터 중 어느 곳에 문제가 있는지 파악하기.
3. 한 사용자의 테스트 결과를 이웃 사용자의 맥락에서 이해하거나, 결과를 보관하여 이웃 사용자와 비교하거나 네트워크가 개선되고 있는지 또는 악화되고 있는지 파악하기.

Cloudflare에서는 이 세 가지 문제를 모두 해결할 수 있는 새로운 통합 인터넷 측정(AIM) 이니셔티브를 발표하게 되어 기쁩니다. AIM은 새롭고 개방적인 형식으로, 엔지니어가 인터넷에서 문제를 해결하는 데 필요한 모든 네트워크 데이터를 유지하면서 특정 유형의 인터넷 성능을 요구하는 사용 사례를 중심으로 인터넷 최종 사용자가 이해할 수 있는 방식으로 인터넷 품질을 표시합니다. 이 프로젝트에서 Measurement Lab과 협력하여 이 모든 데이터를 공개적으로 이용 가능한 리포지터리에 저장하여 사용자가 속도 테스트 페이지에 표시되는 점수 이면의 데이터를 분석할 수 있게 되어 기쁘게  생각합니다. 그 소스 코드는 AIM 점수 계산과 함께 현재 오픈 소스화되어 있습니다.

속도 테스트란?

속도 테스트는 인터넷이 연결된 특정 시점을 측정하는 것입니다. 속도 테스트에 연결하면 일반적으로 대용량 파일 가져오기(동영상 스트리밍에 중요), 패킷 손실 테스트(게임에 중요), 지터 측정(동영상/VOIP 통화에 중요), 대기 시간(모든 인터넷 사용 사례에서 중요) 등이 시도됩니다 . 이 테스트의 목표는 인터넷이 연결된 상태에서 기본 작업 수행 능력을 측정하는 것입니다.

이 접근 방식에는 간단한 관찰에서 시작되는 몇 가지 문제가 있습니다. 데이터와 패킷을 이동시키는 인터넷의 "네트워크 계층"에서 직접 관찰할 수 있는 측정값은 단 세 가지뿐이며, 다음과 같습니다.

• 가용 대역폭. 이를 "처리량"이라고도 합니다.
• 패킷 손실. 이는 정상 상태의 인터넷에서 매우 낮은 수준에서 발생합니다.
• 대기 시간. 이를 흔히 왕복 시간(RTT)이라고도 합니다.

이 세 가지 속성은 서로 긴밀하게 연결되어 있습니다. 특히 사용자가 실제로 달성하는 가용 대역폭(처리량)의 비율은 손실 및 대기 시간의 직접적인 영향을 받습니다. 컴퓨터는 손실 및 대기 시간을 사용하여 패킷을 전송할지 여부를 결정합니다. 약간의 손실과 대기 시간이 예상되며, 심지어 필요하기도 합니다! 어느 쪽이든 너무 많으면 대역폭이 줄어들기 시작합니다.

이들은 단순한 숫자이지만, 그 관계는 결코 단순하지 않습니다. 두 숫자를 더하여 100이 되도록 하는 모든  방법, 즉 x + y ≤ 100에 대해 생각해 보세요. x와 y가 적절하면 100이 됩니다. 그러나 x와 y의 조합이 적절하지 않은 경우가 많습니다. 더 안 좋은 것은 x와 y 중 하나 또는 둘 다 약간 잘못되는 경우 그 합이 100보다 적게 된다는 것입니다. 이 예에서 x와 y는 손실 및 대기 시간이고 100은 가용 대역폭입니다.

이 수치만으로는 모든 것을 알 수 없으며, 다른 요인도 작용합니다. 하지만 이 수치는 직접 관찰할 수 있는 유일한 수치입니다. 각 항목의 의미와 해당 항목이 진단에 중요한 이유를 순서대로 살펴보고, 인터넷 종합 측정으로 각 항목을 어떻게 해결하려고 하는지 알아보겠습니다.

속도 테스트의 숫자는 무엇을 의미할까요?

대부분의 속도 테스트가 실행되면 앞서 본 대역폭, 대기 시간, 지터, 패킷 손실 등의 숫자가 표시됩니다. 각 숫자를 하나씩 분석하면서 그 의미를 설명해 보겠습니다.

대역폭

대역폭은 통신 링크를 통한 최대 처리량/용량입니다. 대역폭을 정의하는 데 사용되는 일반적인 비유는, 인터넷 연결이 고속도로라면 대역폭은 고속도로의 차로 수와 그 차로에 들어갈 수 있는 자동차 대수입니다. 과거에는 대역폭을 '속도'라고 불렀는데, 이는 인터넷 서비스 공급자(ISP)가 대용량 파일을 다운로드하는 데 걸리는 시간으로 속도를 측정하기 때문입니다. 연결의 대역폭이 더 크면 속도가 빨라질 수 있습니다.

패킷 손실

패킷 손실은 말 그대로 일부 패킷이 소스에서 대상으로 전송되었지만, 대상에서 패킷을 수신하지 못하는 현상입니다. 수신자에게 전송되는 도중에 정보가 손실되면 수신자가 전송되는 내용을 이해하기 어려우므로 많은 애플리케이션에 아주 큰 영향이 미칠 수 있습니다(수신자가 전송 내용을 이해하기 어려울 수 있음).

대기 시간

대기 시간은 패킷/메시지가 A 지점에서 B 지점으로 이동하는 데 걸리는 시간입니다. 인터넷의 핵심은 컴퓨터가 케이블을 통해 다른 컴퓨터로 전기 신호 또는 광선 빔 형태의 신호를 보내는 것으로 구성됩니다. 대기 시간은 일반적으로 해당 전기 신호가 케이블이나 광섬유를 통해 한 컴퓨터에서 다른 컴퓨터로 이동하는 데 걸리는 시간으로 정의되어 왔습니다. 따라서 대기 시간을 줄이는 한 가지 방법은 신호가 목적지에 도달하기 위해 이동해야 하는 거리를 줄이는 것입니다.

대기 시간은 유휴 대기 시간과 로드된 대기 시간이 구분됩니다. 이는 라우터와 스위치에 데이터 패킷이 전송될 수 있는 속도보다 빨리 도착할 때 이를 저장하는 대기열이 존재하기 때문입니다. 대기열은 설계상 정상이며 데이터 흐름을 올바르게 유지합니다. 그러나 대기열이 너무 크거나 다른 애플리케이션이 내 애플리케이션과 아주 다르게 작동하는 경우 연결이 실제보다 느리다고 느껴질 수 있습니다. 이러한 경우를 버퍼블로트라고 합니다.

우리의 AIM 테스트에서는 고객의 대기 시간이 어떻게 될 수 있는지 보여주기 위해 유휴 대기 시간을 살펴보지만, 로드된 대기 시간도 수집하는데, 이는 일상적인 인터넷 사용 중 대기 시간을 더 잘 반영합니다.

지터

지터는 대기 시간을 측정하는 특별한 방법입니다. 지터는 인터넷 연결에 따른 대기 시간의 차이입니다. 지터가 높으면 일부 패킷이 도착하는 데 시간이 더 오래 걸릴 수 있으며, 이는 음성 통신과 같이 실시간으로 콘텐츠를 전송해야 하는 인터넷 시나리오에 영향을 미칠 수 있습니다.

지터에 대해서는 어떤 루트나 경로를 따라 출퇴근하는 것을 생각해 보면 좋을 것 같습니다. 대기 시간만 본다면 "시간으로 측정하면 목적지까지 얼마나 남았나요?"라고 물을 수 있습니다. 예를 들어 기차 여행은 평균 40분 정도 걸립니다. 지터는 여행 시간 대신 "내 여행 시간이 얼마나 일정합니까?"라고 묻습니다. 출퇴근 시간을 생각할 경우, 지터가 0이라는 것은 기차 여행에 항상 40분이 걸린다는 뜻입니다. 하지만 지터가 15라면 출퇴근 시간이 25분에서 55분까지 걸릴 수 있으므로 출퇴근이 훨씬 더 어려워집니다.

하지만 이러한 수치를 이해한다고 해도, 무슨 일이 일어나고 있는지 알 수는 있어도 어디에서 무슨 일이 일어나고 있는지는 알 수 없습니다 .

Wi-Fi 또는 인터넷 연결이 문제인가요?

속도 테스트를 실행하면 인터넷 서비스 공급자에게만 연결되는 것이 아니라 인터넷 서비스 공급자에 연결되는 로컬 네트워크에도 연결됩니다. 그리고 로컬 네트워크 자체에 문제가 있을 수도 있습니다. 패킷 손실과 지터가 높은 속도 테스트: 일반적으로 네트워크의 무언가가 패킷을 떨어뜨릴 수 있다는 의미입니다. 일반적으로 인터넷 서비스 공급자에게 전화하면 "Wi-Fi 액세스 포인트에 더 가까이 가거나 확장기를 설치하라"는 등의 말을 듣게 되는 경우가 많습니다.

Wi-Fi는 전파를 사용하여 정보를 전송하는데, 벽돌, 석고, 콘크리트 등의 물질이 신호를 방해하므로 액세스 포인트에서 멀어질수록 신호가 약해질 수 있습니다. Nest Wi-Fi 및 Eero와 같은 Mesh Wi-Fi 장비는 주기적으로 주 액세스 포인트에서 속도 테스트를 수행하여 이와 같은 문제를 감지합니다. 따라서 높은 패킷 손실, 지터 등의 문제에 대한 잠재적인 빠른 해결책을 마련하고 이를 사용자에게 미리 제공하면 사용자가 무선 연결 설정과 관련된 문제인지 더 잘 파악할 수 있습니다.

이는 인터넷에서 발생하는 대부분의 문제에 해당되지만, 네트워크 운영자가 단순히 사용자에게 액세스 포인트에 더 가까이 오라고 지시하는 것 외에도, 이 데이터를 종합적으로 볼 수 있다면 도움이 되는 경우가 많습니다. 네트워크 운영자와 해당 지역의 다른 사람들이 볼 수 있는 장소에서 속도 테스트를 진행하면 네트워크 엔지니어가 사용자가 문제를 신고하기 전에 선제적으로 문제를 감지할 수 있습니다. 이는 사용자에게만 도움이 되는 것이 아닙니다. 네트워크 공급자에게도 도움이 되는데, 사용자 설정으로 인한 문제로 전화를 걸고 기술자를 파견하는 데는 많은 시간과 비용이 소요되기 때문입니다.

누군가가 전화를 받기 전에 문제를 해결하도록 돕는 것이 AIM의 목표 중 하나입니다. 최종 사용자는 인터넷 연결로 할 수 있는 일과 할 수 없는 일, 그 상황에서 개선하는 방법을 이해하는 것 등에 도움이 되는 일련의 팁을 읽기 쉬운 형식으로 제공받을 수 있습니다. 네트워크 운영자는 고객이 전화를 받기 전에 라스트 마일 문제를 감지하는 데 필요한 모든 데이터를 확보하여 시간과 비용을 절약할 수 있습니다. 실제 사례를 통해 어떻게 작동하는지에 대해 이야기해 보겠습니다.

실생활에서의 예

속도 테스트 결과를 받아 보면 수치가 혼란스러울 수 있습니다. 이러한 수치가 결합되어 인터넷 경험에 어떤 영향을 미치는지 이해가 되지 않을 수 있기 때문입니다. 실생활에서의 예와 그 예가 여러분에게 미치는 영향에 대해 이야기해 보겠습니다.

사무실이 4개이고 주요 공간이 다음과 같은 모습인 건물에서 근무한다고 가정해 보겠습니다.

하루 종일 고객들과 화상 통화를 해야 하는데 사용자는 무선 액세스 포인트에서 가장 멀리 떨어진 사무실에 앉아 있습니다. 전화가 계속 끊기고 정말 불편한 경험을 하고 있습니다. 사무실에서 속도 테스트를 실행하면 다음과 같은 결과를 볼 수 있습니다.

이를 어떻게 이해할 수 있을까요? 네트워크 엔지니어는 높은 지터와 패킷 손실을 보고 "이 사용자가 더 높은 신호 감도를 얻으려면 라우터에 더 가까이 이동해야 할 것 같다"고 생각할 것입니다. 하지만 사용자가 이러한 결과를 보고도 잘 모르겠다면 네트워크 엔지니어에게 도움을 요청해야 하며, 이로 인해 인터넷 서비스 공급자에게 전화를 걸어 모두의 시간과 비용이 낭비될 수도 있습니다. 하지만 Wi-Fi 액세스 포인트를 옮겨야 하는지, 인터넷 서비스 공급자가 좋은 경험을 제공하지 않는지 알아내기 위해 네트워크 엔지니어와 상담할 필요는 없습니다.

종합 인터넷 측정에서는 속도 테스트의 수치에 정성적 평가가 부여되므로 이러한 수치를 이해하는 데 도움이 됩니다. 우리는 시나리오 수준에서 계산되는 단일 정성적 값인 시나리오별 점수를 마련했습니다. 이에 따르면 사용자가 수행하려는 작업에 따라 서로 다른 품질 점수가 계산됩니다. 먼저, 스트리밍, 게임, WebChat/RTC 등 세 가지 AIM 점수를 마련했습니다. 이들 점수는 애플리케이션이 성공적으로 실행되는 데 필요한 인터넷 조건에 따라 각 측정 항목의 가중치를 다르게 부여합니다.

AIM 채점 지시문에서는 테스트에 따라 연결에 점수 값을 할당합니다. 우리는 "가중치 점수"를 적용한 AIM을 출시할 예정인데, 이는 해당 시나리오에서 가장 중요한 메트릭에 따라 점수 값이 계산되는 방식입니다. 이러한 점수 체계는 고정된 것이 아니라 애플리케이션 개발자, 네트워크 사업자, 인터넷 커뮤니티가 각 시나리오별로 다양한 성능 특성이 애플리케이션 경험에 미치는 영향에 대해 알아낸 내용을 바탕으로 진화하도록 설계되었으며, 이는 커뮤니티에서 좋은 점수 체계를 설계하고 수렴할 수 있도록 데이터를 M-Lab에 게시하는 또 하나의 이유이기도 합니다.

다음은 전체 지시문 및 현재 메트릭과 관련된 각 점수 값입니다.

다음은 각 시나리오에서 중요한 값과 점수를 계산하는 방법에 대한 간략한 개요입니다.

• 스트리밍: 다운로드 대역폭 + 언로드 대기 시간 + 패킷 손실 + (로드 대기 시간 - 언로드 대기 시간 차이)
• 게임: 패킷 손실 + 언로드 대기 시간 + (로드 대기 시간 - 언로드 대기 시간 차이)
• RTC/비디오: 패킷 손실 + 지터 + 언로드 대기 시간 + (로드 대기 시간 - 언로드 대기 시간 차이)

각 점수를 계산하기 위해 속도 테스트의 점수 값을 가져와 해당 시나리오의 총점 중 해당 점수를 계산합니다. 따라서 결과에 따라 인터넷 연결 상태를 각 시나리오별로 판단할 수 있습니다: 가, 양, 미, 우, 수. 예를 들어, 화상 통화의 경우 인터넷 품질이 화상 통화에 적합한지 여부를 판단할 때 패킷 손실, 지터, 언로드 대기 시간, 로드 대기 시간과 언로드 대기 시간의 차이가 중요한 요소로 작용합니다. 속도 테스트 결과에서 얻은 점수를 합산하면 인터넷 품질이 완벽한 화상 통화 환경과 얼마나 거리가 먼지 알 수 있는 점수가 나옵니다. 속도 테스트를 기반으로 액세스 포인트에서 멀리 떨어진 사무실에서 측정한 AIM 점수는 다음과 같습니다.

따라서 "귀하의 대역폭은 X이고 지터는 Y입니다"라고 말하는 대신, "귀하의 인터넷은 넷플릭스용으로는 괜찮지만, 게임용으로는 느리고, Zoom용으로는 평균에 불과합니다"라고 말할 수 있습니다. 이 경우 Wi-Fi 액세스 포인트를 보다 중앙화된 위치로 이동하는 것이 해결책으로 판명되어 AIM 점수가 이렇게 바뀌었습니다.

이러한 결과는 오늘 Cloudflare 속도 테스트에서 네트워크 품질 점수로도 확인할 수 있습니다.

이 특별한 경우에는 인터넷 서비스 공급자에게 전화할 필요가 없었으며 네트워크 엔지니어와 상담할 필요도 없었습니다. 액세스 포인트를 사무실 중앙에 더 가깝게 옮기는 것만으로도 모든 사람의 경험이 개선되었고, 아무도 전화를 받을 필요가 없어져 모두에게 더욱 원활한 경험이 제공되었습니다.

AIM은 네트워크 엔지니어가 중요하게 생각하는 메트릭을 사용자가 사용하려는 앱을 기반으로 하는, 사람이 읽을 수 있는 메트릭으로 변환합니다. 집계된 데이터는 익명으로 처리되므로(개인정보 처리방침에 따라) 인터넷 서비스 공급자가 실제로 해당 대도시 지역에서 해당 인터넷 서비스 공급자를 이용하는 경우의 속도 테스트를 조회하고 기초 데이터를 얻어 사용자의 불만을 네트워크 엔지니어가 조치할 수 있는 내용으로 전환하는 데 도움이 됩니다. 또한 정책 입안자와 연구자들은 종합 데이터를 검토하여 지역 사회의 사용자들이 겪고 있는 문제를 더 잘 이해함으로써 더 나은 인터넷 품질을 위한 로비를 하는 것을 지원할 수 있습니다.

작업 조건

흥미로운 질문이 하나 있습니다. 속도 테스트를 실행할 때 어디에 연결하며 연결되는 다른 쪽 끝의 인터넷은 어떤 상황인가요? 속도 테스트를 하면서 종종 직면하는 문제 중 하나는 테스트 대상이 되는 서버가 웹 사이트를 실행하거나 보호하는 서버와 동일하지 않다는 점입니다. 따라서, 속도 테스트에 따라 반대편 호스트에 도달하는 네트워크 경로가 크게 다를 수 있으며, 최대한 많은 속도 테스트를 제공하도록 최적화될 수도 있습니다. 즉, 속도 테스트는 트래픽이 평소에 사용하는 애플리케이션에 도달할 때 일반적으로 이동하는 경로를 실제로 테스트하는 것이 아닙니다. 실행한 테스트는 네트워크 경로를 측정하는 것이지만, 정기적으로 사용하는 네트워크 경로가 아닙니다.

속도 테스트는 사람들이 인터넷을 사용하는 방식을 반영하는 실제 네트워크 조건에서 여러 애플리케이션, 브라우저 탭, 장치가 모두 연결을 위해 경쟁하는 상황에서 실행해야 합니다. 애플리케이션 대면 도구를 사용하여 인터넷 연결을 측정하고 네트워크가 최대한 많이 사용되는 동안 측정하는 이 개념을 작업 조건에서의 측정이라고 합니다. 오늘날 속도 테스트가 실행되면 네트워크 성능 테스트를 위해 예약된 웹 사이트에 완전히 새로운 연결이 이루어집니다. 안타깝게도 일상적인 인터넷 사용은 전용 속도 테스트 웹 사이트에 새로 연결할 때 수행되지 않습니다. 이는 실제로 많은 인터넷 애플리케이션이 암호화 설정, 인증서 교환 등으로 인해 발생하는, 비용이 많이 드는 대기 시간을 제거하여 최종 사용자에게 더 나은 경험을 제공하기 위해 웹 사이트에 대한 동일한 연결을 재사용하는 데 의존하도록 설계되어 있기 때문입니다.

AIM은 여러 가지 방법으로 이 문제를 해결하도록 지원하고 있습니다. 첫 번째는 우리가 모든 테스트를 애플리케이션과 동일한 방식으로 구현하고 작업 조건에서 측정했다는 점입니다. 우리는 로딩 대기 시간을 측정하여 실제로 인터넷 연결이 어떻게 작동하는지 보여줍니다. 오늘 속도 테스트에서 이를 확인할 수 있습니다.

두 번째는 우리가 현재 사용 중인 엔드포인트에 대한 속도 테스트 결과를 수집하고 있다는 점입니다. Cloudflare 및 기타 사이트에 대한 속도 테스트를 측정하여 일상 생활에서 자주 사용하는 네트워크에 대한 최종 사용자 인터넷 품질을 보여주므로, 실제 작업 환경을 더 잘 파악할 수 있습니다.

AIM 데이터베이스

측정 연구소(M-Lab)와의 파트너십을 통해 AIM 데이터를 오늘부터 공개적으로 사용할 수 있게 되었음을 발표하게 되어 기쁩니다. 최종 사용자와 네트워크 엔지니어 모두 다양한 네트워크에서 네트워크 품질 데이터를 분석할 수 있습니다. M-Lab과 Cloudflare는 모두 속도 테스트에서 도출된 AIM 점수를 계산하고 이를 공유 데이터베이스에 저장하여 최종 사용자와 네트워크 운영자가 모두 다양한 속도 테스트를 통해 최대한 많은 지점에서 인터넷 품질을 확인할 수 있도록 할 것입니다.

우리가 보고 있는 내용의 샘플을 위해 10월 첫째 주 일본 도쿄에서 시나리오당 Cloudflare 데이터의 점수만 표시하는 이 데이터를 사용하여 만든 시각적 자료를 살펴보겠습니다.

이를 바탕으로 5,814건의 속도 테스트를 실행한 사용자 중 50.7%의 경우에는 스트리밍 품질이 좋았지만, 48.2%의 경우에는 평균에 불과했다는 것을 알 수 있습니다. 도쿄에서는 사용자 중 39%의 게임 경험이 좋지 않은 것으로 나타나 상대적으로 게임이 어려운 것으로 보이지만, 대부분의 사용자는 평균 수준에서 보통 수준까지의 RTC를 경험했습니다. 다른 도시와 비교했을 때는 어떤 차이가 있는지 살펴보겠습니다.

데이터에 따르면 약간 뒤처진 뭄바이를 제외하고는 대부분의 사용자가 동영상 스트리밍에 문제가 없는 것을 알 수 있습니다. 대기 시간이 게임 점수의 주요 요인으로 작용하므로 일반적으로 사용자들의 게임 경험은 다양하지만, RTC 앱은 모든 현지에서 대체로 평균을 기록하며 약간 더 나은 수준을 보입니다.

M-Lab과의 협업

M-Lab은 개방형 인터넷 측정 리포지터리로, 인터넷을 측정하고 데이터를 저장하여 누구나 쉽게 액세스하고 유용하게 사용할 수 있도록 하는 것을 사명으로 삼고 있습니다. M-Lab은 네트워크 사업자에게 AIM 데이터에 대한 무료 공개 액세스를 제공할 뿐만 아니라 정책 입안자, 학계 연구자, 언론인, 디지털 포용성 옹호자 등 관심 있는 모든 사람에게 인터넷 개선에 도움이 되는 중요한 결정을 내리는 데 필요한 데이터에 액세스할 수 있도록 할 것입니다.

정책 입안자와 학계에 인터넷 품질 데이터를 공개적으로 공유하는 것으로 이미 명성이 자자한 M-Lab에서는 이미 Google에 "속도 테스트"를 입력하면 실행되는 것과 동일한 네트워크 진단 테스트(NDT)라는 "속도" 테스트를 제공하고 있습니다. M-Lab과의 파트너십을 통해 Cloudflare에서는 더 많은 사용자로부터 인터넷 측정 메트릭을 집계할 수 있게 되었습니다. 우리는 다른 속도 테스트 업체와도 협력하여 최대한 많은 사용자의 인터넷 품질이 전 세계에 어떻게 매핑되는지 전체적으로 파악하고자 합니다. 현재 인터넷 성능을 측정하고 계신다면, 사용자에게 인터넷의 진정한 장점을 보여줄 수 있도록 동참해 주시기 바랍니다.

속도 테스트, 이제 오픈 소스화

Cloudflare에서는 M-Lab과의 제휴와 더불어 속도 테스트 클라이언트도 오픈 소스화 했습니다. 속도 테스트의 오픈 소스화는 애플리케이션이 Cloudflare를 통해 속도 측정에 액세스할 수 있도록 하는 중요한 단계이며, 애플리케이션의 AIM 점수 계산을 쉽게 시작할 수 있는 방법입니다. 이제 속도 테스트를 javascript 애플리케이션으로 임베드할 수 있으므로 브라우저로 이동할 필요 없이 네트워크 품질 테스트를 수행할 수 있습니다. 이 애플리케이션으로 현재 속도 테스트에 사용하는 모든 측정값이 제공될 뿐만 아니라 결과도 비공개 방식으로 Cloudflare에 업로드됩니다. 또한 리포지터리에서는 AIM 점수를 계산하는 방법이 제시되므로 최종 사용자는 네트워크 품질이 정의되는 방식과 실시간으로 어떻게 변하는지에 대한 내부 작동을 확인할 수 있습니다. 오픈 소스 속도 테스트로 개발을 시작하려면 오픈 소스 링크를 확인하세요.

인터넷 품질의 더욱 밝은 미래

이 데이터를 종합하여 다양한 테스트와 네트워크에서 인터넷 품질을 보여드릴 수 있게 되어 기쁩니다. 우리는 이 데이터를 분석하여 점수 시스템을 개선할 예정이며, 속도 테스트 측정값을 사용하여 다양한 애플리케이션에서 인터넷 품질을 평가하고 직접 AIM을 구현하는 방법을 확인할 수 있도록 오픈 소스로 공개했습니다. 또한, 오늘 소개하는 모든 테스트와 함께 속도 테스트에 AIM 점수를 넣어 인터넷의 성능을 더 잘 이해할 수 있도록 했습니다.

현재 속도 테스트를 진행 중이면서 당사와 파트너십을 맺고 사용자 경험 인터넷 품질에 대한 데이터 수집을 지원하는 데 관심이 있으신 경우, 당사에연락하여 더 나은 인터넷을 만들기 위해 함께 노력해 주시기 바랍니다. 인터넷 품질을 측정하고자 하는 애플리케이션을 운영 중이시라면 지금 바로 개발을 시작할 수 있도록 오픈 소스 리포지터리를 확인하십시오.

인터넷이 어떤 용도로 사용되는지 파악하기 위해 네트워킹 전문가가 될 필요는 없습니다. Cloudflare에서 도움을 드리니까요. AIM과 MLab의 협력자들과 함께 우리는 사용자의 인터넷이 무엇을 할 수 있는지 알려주고 그 정보를 이용하여 모든 사람을 위해 더 나은 인터넷을 만드는 것을 지원하고자 합니다.