인터넷 속도 측정용 존 개발

Habra 사용자 여러분, 안녕하세요.

나는 Habré에서 Malinka의 특정 기능 개발에 대한 기사를 끊임없이 읽었습니다. 나는 여기서 내 작업을 공유하기로 결정했습니다.

선사 시대

저는 케이블 TV와 인터넷 접속 서비스를 제공하는 회사에서 일하고 있습니다. 그리고 그러한 회사에서 발생하는 것처럼 나는 관세 계획이 계약서에 명시된 것과 일치하지 않는다는 불만을 주기적으로 듣습니다. 사용자는 "케이블을 통한"저속, 특정 서비스의 높은 핑, 때로는 하루 중 특정 시간에 인터넷이 전혀 없다는 것에 대해 불평합니다. 종종 그러한 불만은 직원 중 한 명이 작동하는 노트북을 가지고 "현장"에 가서 모든 측정이 수행되는 요청 풀로 이어집니다. 그리고 종종 속도면에서 모든 것이 괜찮은 것으로 나타났습니다. 그리고 저속은 실제로 발코니에서 Wi-Fi를 통해 휴대폰에서 발생합니다. 글쎄, 아니면 비슷한 것.

안타깝게도 가입자의 속도가 가장 낮은 21시 37분에 가입자에게 가는 것은 불가능합니다. 결국 직원의 근무 시간은 제한되어 있습니다. 라우터를 교체해도 효과가 없습니다. 왜냐하면... 우리나라의 Wi-Fi 주파수 범위는 비참할 정도로 복잡합니다.

기록을 위해 — 벨로루시 공화국의 주 공급자는 사용하도록 제공된 모든 장치에서 Wi-Fi를 강제로 켜고 각 장치에서 ByFly SSID를 브로드캐스트합니다. 가입자에게 인터넷 서비스가 없고 집 전화만 있는 경우에도 마찬가지입니다. 이는 추가 판매를 위해 수행되었습니다. 키오스크에서 이 운영자로부터 카드를 구입하고 ByFly라는 지점에 연결하고 카드의 데이터를 입력하여 인터넷 서비스를 받을 수 있습니다. 거의 100% 도시에 적용되고 민간 부문과 농촌 지역에 대한 상당한 적용 범위를 고려하면 연결점을 찾는 것은 문제가 되지 않습니다.

외부 통신 채널을 관찰한 결과 특정 대역폭 예약이 있음을 알 수 있습니다. 그리고 가입자는 출퇴근 시간에도 이용 가능한 채널을 모두 소비하지 않습니다. 우리는 이에 대해 매우 심각하게 생각합니다. 다양한 서비스와 다양한 속도 측정 서버를 사용하여 흥미로운 결과를 얻었습니다. 모든 서비스가 똑같이 유용한 것은 아닙니다... 특히 저녁에. 그리고 당신은 그들을 절대 믿어서는 안됩니다. 동일한 Ookla 네트워크의 많은 운영자는 광범위한 통신 채널을 보유하지 않거나 연속적으로 작업합니다. 이는 저녁에 정직한 결과를 얻는 것이 거의 불가능하다는 것을 의미합니다. 예, 고속도로는 죄악으로 판명되었습니다. 예를 들어, 일본에서 속도를 측정하려는 시도는 극도로 비참한 결과를 보여줍니다.

XNUMX차 결정

사진은 설명을 위한 것입니다.

XNUMX개의 속도 제어 서버가 배포되었습니다. 첫 번째는 리브레스피드, 두번째 - OOKLA의 속도 테스트. 두 서비스의 성능을 비교했습니다. 결국 우리는 Ookla에 들르기로 결정했습니다. 왜냐하면... 가입자의 최대 90%가 이 서비스를 사용합니다.

다음으로, 사용자와 직원을 위해 네트워크 내부와 외부의 속도를 측정하는 방법에 대한 지침이 작성되었습니다. 저것들. 테스트가 시작되면 기본적으로 네트워크 내 속도가 측정됩니다. 서버는 당사의 헤드엔드에 위치하며, Ookla 솔루션은 기본적으로 가입자에게 가장 가까운 서버를 선택합니다. 이러한 방식으로 우리는 자체 데이터 전송 네트워크의 작동을 확인합니다.

국내 속도를 측정하려면(우리는 국가 내 모든 통신사와 주요 데이터 센터를 통합하는 통신 사업자를 위한 별도의 네트워크를 보유하고 있습니다), 해당 국가 내에서 통신사를 선택하고 두 번째 측정을 수행해야 합니다. 우리는 하루 중 언제든지 다소 안정적인 결과를 제공하는 여러 서버를 경험적으로 식별하고 지침에 권장되는 대로 나열했습니다.

음, 외부 통신 채널에 대한 유사한 조치입니다. 우리는 속도 테스트 서버에서 큰 채널을 가진 대규모 운영자를 찾아 권장 사항에 기록했습니다(죄송합니다 "Moskva - Rostelecom" 및 "Riga - Baltcom"이지만 적절한 숫자를 얻으려면 이 노드를 추천하겠습니다. 개인적으로 저는 최대 870MB까지 수신했습니다. 피크 시간 동안 이러한 서버).

왜 그런 어려움이 있습니까? 모든 것이 매우 간단합니다. 우리는 유능한 사람의 손에서 네트워크에 문제가 있는지, 공화당 네트워크에 문제가 있는지 또는 백본에 문제가 있는지 확인할 수 있는 매우 편리한 도구를 받았습니다. 어떤 서비스에서 다운로드 속도가 느리다고 불평하는 경우, 구독자의 채널 속도를 측정한 다음 이를 서비스에서 받는 속도와 비교할 수 있습니다. 그리고 계약서에 명시된 채널을 정직하게 할당했음을 보여주는 것이 합리적입니다. 또한 이러한 속도 차이에 대한 가능한 이유를 설명할 수도 있습니다.

보조 솔루션

저녁/낮의 속도 저하 문제는 여전히 열려 있습니다. 가입자의 집에 가지 않고도 동일한 작업을 수행하는 방법은 무엇입니까? 기가비트 네트워크를 갖춘 저렴한 단일 보드 카드를 사용하여 소위 프로브를 만드십시오. 장치는 주어진 시간 간격으로 케이블을 따라 속도를 측정해야 합니다. 솔루션은 측정 결과를 볼 수 있는 편리한 관리 패널을 갖춘 오픈 소스여야 합니다. 장치는 쉽게 교체할 수 있고 가입자가 걱정 없이 n일 동안 사용할 수 있도록 가능한 한 저렴해야 합니다.

Реализация

BananaPI(모델 M1)를 기본으로 삼았습니다. 실제로 이 선택에는 두 가지 이유가 있습니다.

1. 기가비트 포트.
2. 그냥 침대 옆 탁자에 누워 있었어요.

다음으로 Python 클라이언트를 사용하기로 결정했습니다. 스피드 테스트 - 클라이 속도 측정을 위한 백엔드로 Ookla 서비스의 Speedtest를 위한 것입니다. 도서관 파이썬핑 핑 속도를 측정합니다. 음, 관리자 패널용 PHP입니다. 인식의 용이성을 위해 나는 사용했습니다. 부트 스트랩.

Raspberry의 리소스는 유연하지 않기 때문에 nginx+php-fpm+sqlite3 조합이 사용되었습니다. 나는 MySQL의 무거움과 중복성 때문에 포기하고 싶었습니다. Iperf에 관한 질문이 있을 것으로 예상됩니다. 지역 방향 이외의 방향으로 사용할 수 없기 때문에 버려야했습니다.

처음에 나는 이 사이트에서 많은 사람들의 길을 따랐습니다. speedtest-cli 클라이언트를 수정했습니다. 그러나 그는 조금 생각한 후에 이 생각을 포기했습니다. 나는 원래 클라이언트의 기능을 사용하는 자체 작업자를 작성했습니다.

핑을 분석하기 위해 별도의 핸들러를 작성했습니다. 측정에서 평균값을 취합니다. ping 도구는 IP 주소와 도메인 이름을 모두 처리할 수 있습니다.

나는 비동기 작업을 달성하지 못했습니다. 이 경우에는 특별히 필요하지 않습니다.

결과를 평가하기 위한 관리 패널은 매우 미니멀한 것으로 나타났습니다.

그림. 테스트 결과가 포함된 기본 관리 창

그림. 테스트 설정

그림. Speedtest 서버 목록 업데이트

그게 다야. 이 아이디어는 여가 시간에 무릎을 꿇고 구현되었습니다. 아직 현장 테스트가 시작되지 않았습니다. 하지만 우리는 가까운 시일 내에 프로토타입을 출시할 계획입니다. 해당 공급자와 공급자의 클라이언트 모두에서 사용할 수 있습니다. XNUMX시간 내내 집에서 측정을 하라고 귀찮게 하는 사람은 없습니다. 기억해야 할 유일한 점은 적극적으로 인터넷을 서핑하거나 무언가를 다운로드하면 측정값이 실제 측정값보다 낮아진다는 것입니다. 따라서 이상적으로는 프로브를 네트워크의 유일한 트래픽 소비자로 남겨 두어야 합니다.

추신: 코드 품질에 대해 저를 비판하지 마십시오. 저는 경험이 없이 독학을 했습니다. 소스 코드 GitHub의. 비판은 받아들여진다.

출처 : habr.com