Что такое низкий эффект проверки, действительно ли интернет работает на python?

Question

У меня есть скрипт python, который я запускаю как фоновый процесс на моем mac каждые 10 минут. В основном, он загружает самое последнее изображение с сервера и в зависимости от скорости моего интернет-трафика загружает привет-Res (20 Мбит на соединения 5 Мбит/с или лучше) или с низким разрешением (6 Мбит на соединениях 5 до 1 Мбит/с) изображение.

Таким образом, в начале моего скрипта я использую пакет python speedtest-cli, чтобы проверить скорость моего интернета. Тем не менее, присущий любому тесту на скорость - это использование некоторой моей пропускной способности.

Если возможно, то, что я хотел бы сделать до теста скорости, - это простой тест с очень низкой пропускной способностью, чтобы проверить, не подключено ли мое интернет-соединение на каком-то базовом уровне, прежде чем я проведу свой тест скорости. Этот базовый уровень может быть измерен в скорости загрузки, времени пинга или любой полезной метрики, которая может сообщить мне об основном качестве моего соединения. Таким образом, если мой интернет слишком медленный, я ушел, прежде чем использовать ограниченную полосу пропускания с тестом скорости.

Точность здесь не так важна. Меня не интересует разница между медленным и действительно медленным Интернетом. После запуска теста скорости, если скорость загрузки не меньше 1 Мбит/с, она завершается. Таким образом, этот базовый тест может быть любым простым тестом, где базовый уровень находится где-то ниже скорости загрузки 1 Мбит/с.

Использование ping может быть разумным решением. Другой вариант question предлагает решение для pinging, которое представлено в этом gist, но это довольно сложное и требует запуска root, что я предпочел бы избежать, если это было возможно.

Ниже приведен простой вариант сценария я использую:

import requests 
import sys 
import os 
import logging 
import socket 
import json 

# python himawari.py 
# stolen from https://gist.github.com/celoyd/39c53f824daef7d363db 
# requires speedtest-cli ('pip install speedtest-cli') 

# check if we have internet 
def internet(host="8.8.8.8", port=53, timeout=3): 
    try: 
     socket.setdefaulttimeout(timeout) 
     socket.socket(socket.AF_INET, socket.SOCK_STREAM).connect((host, port)) 
     return True 
    except Exception as ex: 
     return False 

print("Checking internet speed:") 

if internet(): 
    print "Internet connection exists..." 
    os.system("rm -f /Users/scott/git-projects/live-earth-desktop/speedtest.json") 
    os.system("speedtest-cli --json >> /Users/scott/git-projects/live-earth-desktop/speedtest.json") 
else: 
    print "No internet connection. Quitting..." 
    os._exit(1) 

with open('/Users/scott/git-projects/live-earth-desktop/speedtest.json') as data_file:  
    try: 
     data = json.load(data_file) 
    except ValueError: 
     print("data was not valid JSON") 
     os._exit(1) 


speed = data["download"] 

print_speed = str(round(speed//1000000)) 
print("Download speed: ~" + print_speed + " Mb/s") 

if (speed > 5000000): # 5 Mb/s 
    print("Internet speed is good. Downloading hi-res image.") 
    # Download hi-res image here 
elif (speed > 1000000): # 1 Mb/s 
    print("Internet speed is ok. Downloading low-res image.") 
    # Download low-res image here 
else: 
    print("Internet speed is poor. Quitting.") 
    os._exit(1) 

Answer 1

Я соучредителем Firebind.

Вся причина существования Firebind состоит в том, чтобы выполнять непрерывные тесты с низким уровнем воздействия, чтобы вы могли установить качество интернета. Вы можете настроить и развернуть один из наших агентов за 2 - 3 минуты. Затем агент выполняет серию из 11 тестов каждые 5 минут на комбинацию наших фиксированных точек тестирования, а также на адресаты, которые вы настраиваете, давая вам 3 168 измерений в день.

Когда мы построили Firebind, мы поняли, что испытания с высокой отдачей, такие как тесты пропускной способности, были слишком разрушительными, что привело нас к разработке нашего флагманского имитационного теста VoIP. Каждые 5 минут мы отправляем и получаем имитированный VoIP-трафик в течение 25 секунд. Этот трафик составляет 50 п.п., 87 кбит/с с полезной нагрузкой 218 байт, что приводит к 360 000 пакетов в день в каждом направлении. Наша видимость намного превосходит ping не только потому, что мы 50x пакетов в секунду, но мы используем UDP, как и реальный VoIP-вызов. Если ping - увеличительное стекло, мы микроскоп. Другие тесты включают латентность UDP, джиттер UDP, время отклика ping, время ответа DNS и время ответа HTTP.

Вы можете установить пороговые значения тревоги, которые отправят уведомление по электронной почте, если, например, потеря вашего пакета превышает 1,5%, или ваш поиск DNS занимает больше 50 мс.

Значение номер один состоит в том, что, основываясь на вашем соединении, вы можете видеть периоды деградации качества сети, а затем исходя из этого времени и степени серьезности, вы можете более легко изолировать источник (к сожалению, чаще всего это переполненное ISP-соединение.)

У Firebind есть бесплатная 2-недельная пробная версия, если вы хотите ее проверить.

все лучшее,

Dave

(КВС ниже наша потеря пакетов график, показывающий серьезные потери загрузки на связи Comcast в Массачусетсе.)

Answer 2

Ваше упоминание " низкое воздействие "и поиск базовой линии - вот что привлекло мое внимание. То, что я узнал через Firebind, заключается в том, что тесты пропускной способности TCP не являются единственным способом измерения качества линии, и их выполнение может привести к вводящим в заблуждение результатам. Любая операция загрузки или загрузки, которая не ограничивается ограничением скорости ни приложением, ни сетью, всегда будет пытаться «максимизировать» схему. Выбор меньшего файла может по-прежнему максимизировать схему, но только на более короткий период времени. И, конечно же, страх использовать слишком большую пропускную способность или прокрутку схемы - это то, что приводит к попытке ограничить частоту, что, в свою очередь, ограничивает вашу видимость.

Моя рекомендация будет заключаться в том, чтобы вы вместо этого использовали iperf и моделировали что-то вроде этого, например, 50-процентный VoIP-вызов, чтобы вы могли измерять потерю пакетов. Вы можете использовать входы, упомянутые выше (87 кбит/с, 218 байтов полезной нагрузки по UDP.) Таким образом, вы можете установить качество линии, но вы можете сделать это с низким уровнем воздействия, а не «потопить линию» в полосе пропускания TCP контрольная работа. И поскольку пропускная способность настолько низкая, вы можете позволить себе делать это так часто, как хотелось бы. Даже в цепи 5/5 параметры, указанные выше, будут использовать емкость менее 1%.

Например, вы можете запускать его в течение 30 секунд в каждом направлении каждые 2 минуты, что дает вам гораздо больше видимости с гораздо меньшим количеством данных, чем подход TCP.

Я бы определенно держался подальше от пинга, пытаясь оценить качество линии. Картинка в приведенной ниже ссылке показывает дом Comcast в Массачусетсе, который выполняет как 20 ICMP-пингов в AWS Virginia (желтая линия), так и мы, имитируя пинг, но используя полезную нагрузку UDP (синяя линия.). Время - это все средние из этих 20 пинов. На неперегруженной схеме вы обычно видите желтую линию очень плоскую (с допуском 1 мс), и она будет иметь значение в несколько мс ниже синей линии. Причина в том, что наше программное обеспечение в Вирджинии должно обрабатывать UDP, тогда как ответы ping не имеют этих дополнительных шагов. Здесь, однако, средние пины перескакивают между 28 мс и 55 мс, тогда как UDP относительно плоский, в основном между 26 мс и 30 мс. Это признак связи с некоторой перегрузкой, и если у вас есть только данные ping, вы можете подумать, что это было хуже, чем потому, что пинг размахивает так дико. Это правда, что есть перегрузка, но UDP (пользовательский) трафик все еще работает относительно нормально.

удачи!

Dave

Average ping and UDP RTT from MA to VA