인터넷 속도 측정용 존 개발

모든 Habr 사용자 여러분, 안녕하세요.

저는 Habr에서 Raspberry Pi에서 이런저런 기능을 개발하는 것에 대한 기사를 끊임없이 읽었습니다. 저는 제 경험을 공유하기로 했습니다.

선사 시대

저는 케이블 TV와 인터넷 접속 서비스를 제공하는 회사에서 일합니다. 그리고 그런 회사에서는 요금제와 계약서에 명시된 내용이 다르다는 불만을 주기적으로 듣습니다. 가끔 사용자는 "케이블을 통한" 느린 속도에 대해 불평하고, 가끔은 특정 서비스의 ping이 높다고 불평하고, 가끔은 특정 시간대에 인터넷이 전혀 없다고 불평합니다. 종종 이러한 불만 사항은 여러 신청서에 반영되어 직원 중 한 명이 작동하는 노트북을 들고 "현장"에 가서 모든 측정을 수행하게 됩니다. 그리고 종종 속도만 좋다면 모든 게 괜찮을 때가 있습니다. 그리고 낮은 속도는 실제로 발코니에서 Wi-Fi를 통해 모바일 폰에서 발생합니다. 글쎄요, 그런 비슷한 거죠.

안타깝게도 속도가 가장 느린 21:37에 구독자에게 접근하는 것은 불가능합니다. 결국, 직원들의 근무 시간은 제한되어 있습니다. 라우터를 교체해도 효과가 없습니다. 우리나라의 Wi-Fi 주파수 범위는 매우 좁기 때문입니다.

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

외부 커뮤니케이션 채널을 모니터링한 결과, 일정량의 대역폭이 사용 가능하다는 사실이 밝혀졌습니다. 구독자는 최대 시간대에도 사용 가능한 채널을 전부 소비하지 않습니다. 우리는 이 문제를 매우 심각하게 여깁니다. 다양한 서비스와 속도 측정 서버를 사용했더니 흥미로운 결과가 나왔습니다. 모든 서비스가 똑같이 유용한 것은 아니라는 것이 밝혀졌습니다... 특히 저녁에는 더욱 그렇습니다. 그리고 당신은 그들을 절대 믿어서는 안 됩니다. 동일한 Ookla 네트워크를 사용하는 많은 운영자는 광범위한 커뮤니케이션 채널을 갖고 있지 않거나, 좁은 거리에서만 작업합니다. 즉, 저녁에는 정직한 결과를 얻는 것이 거의 불가능하다는 뜻입니다. 그리고 고속도로에도 잘못이 있는 것으로 밝혀졌습니다. 예를 들어, 일본에서 속도를 측정하려는 시도는 매우 암울한 결과를 보였습니다...

1차 솔루션

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

2개의 속도 제어 서버가 배치되었습니다. 첫 번째는 리브레스피드, 두번째 - OOKLA의 속도 테스트. 두 서비스의 성과 지표를 비교했습니다. 결국 우리는 Ookla를 선택했습니다. 그 이유는... 구독자의 최대 90%가 이 서비스를 사용하기 때문입니다.

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

국내 속도를 측정하려면(국내 모든 통신 사업자와 주요 데이터 센터를 통합하는 별도의 통신 사업자 네트워크가 있음) 국내 공급업체를 선택하고 두 번째 측정을 수행해야 합니다. 우리는 하루 중 어느 시간대에나 다소 안정적인 결과를 제공하는 몇몇 서버를 경험적으로 파악했으며, 이를 지침에 권장하는 대로 나열했습니다.

외부 커뮤니케이션 채널에도 비슷한 조치가 적용됩니다. 저희는 속도 테스트 서버에서 대규모 채널을 보유한 대형 통신사를 찾아 추천 목록에 포함했습니다("모스크바 - 로스텔레콤"과 "리가 - 발트콤"은 양해해 주시면 감사하겠습니다. 하지만 충분한 속도를 얻기 위해 이 노드들을 추천하겠습니다. 개인적으로는 피크 시간대에 이 서버들에서 최대 870메가비트의 속도를 얻었습니다).

왜 그렇게 복잡하냐고 물으시죠? 모든 것이 매우 간단해요. 우리는 숙련된 사람의 손에 들어가면 우리 네트워크에 문제가 있는지, 공화국 네트워크에 문제가 있는지, 주요 회선에 문제가 있는지 확인할 수 있는 매우 편리한 도구를 받았습니다. 만약 어떤 사람이 어떤 서비스의 다운로드 속도가 느리다고 불평한다면, 우리는 가입자의 채널 속도를 측정한 다음, 그 속도를 그 서비스에서 얻는 속도와 비교할 수 있습니다. 그리고 계약서에 명시된 채널을 정직하게 할당하고 있다는 것을 합리적인 방식으로 입증합니다. 또한 우리는 그러한 속도 차이에 대한 가능한 이유를 설명할 수 있습니다.

2차 솔루션

저녁이나 낮에 속도가 떨어지는 문제는 여전히 해결되지 않았습니다. 가입자의 집에 가지 않고도 동일한 작업을 수행하는 방법은 무엇입니까? 기가비트 네트워크를 갖춘 값싼 단일 보드 컴퓨터를 가져다가 그것으로 소위 프로브를 만들어 보세요. 이 장치는 지정된 시간 간격으로 케이블의 속도를 측정해야 합니다. 솔루션은 오픈 소스여야 하며, 가능한 한 소박해야 하며, 측정 결과를 볼 수 있는 편리한 관리자 패널이 있어야 합니다. 이 장치는 가능한 한 저렴해야 쉽게 교체할 수 있고, 가입자가 아무 걱정 없이 n일 동안 사용할 수 있어야 합니다.

Реализация

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

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

다음으로 파이썬 클라이언트를 사용하기로 결정했습니다. 스피드 테스트 - 클라이 속도 측정을 위한 백엔드로 Ookla 서비스의 Speedtest를 사용합니다. 도서관 파이썬핑 ping 속도를 측정합니다. 음, 관리자 패널에는 php가 필요하죠. 기분 좋은 인식을 위해 나는 다음을 사용했습니다. 부트 스트랩.

Raspberry Pi 리소스가 탄력적이지 않기 때문에 nginx+php-fpm+sqlite3 번들을 사용했습니다. MySQL은 너무 무겁고 중복적이어서 없애고 싶었습니다. Iperf에 대한 질문이 있을 것으로 예상합니다. 지역적인 특성상 다른 지역에서는 사용이 불가능하기 때문에 폐기되어야 했습니다.

처음에는 저도 이 사이트의 많은 사람들의 길을 따랐습니다. speedtest-cli 클라이언트를 수정했습니다. 하지만 그는 잠시 생각한 뒤 그 생각을 포기했습니다. 저는 원래 클라이언트의 기능을 활용하는 작업자를 직접 작성했습니다.

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

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

결과를 평가하는 관리자 패널은 매우 단순했습니다.

그림. 테스트 결과가 있는 메인 관리자 패널 창

그림. 테스트 설정

그림. 속도 테스트 서버 목록 업데이트

사실 그게 전부예요. 그 아이디어는 제가 여가시간을 이용해서 즉석에서 구현했습니다. 현장 테스트는 아직 시작되지 않았습니다. 하지만 가까운 미래에 프로토타입을 출시할 계획입니다. 서비스 제공자와 서비스 제공자의 고객 모두 사용할 수 있습니다. 집에서 24시간 내내 측정하는 것을 막는 사람은 없습니다. 유일하게 기억해야 할 점은 웹 서핑을 하거나 무언가를 다운로드하는 경우 측정값이 실제 값보다 낮다는 것입니다. 따라서 이상적으로는 프로브를 트래픽의 유일한 소비자로 네트워크에 남겨두는 것이 좋습니다.

PS: 코드의 품질이 좋지 않다고 해서 저를 비난하지 마세요. 저는 경험 없이 독학으로 배웠습니다. 소스 코드 GitHub의. 비판은 받아들여진다.

출처 : habr.com