Что такое слабый способ проверить, действительно ли интернет работает медленно на питоне?

Question

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

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

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

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

Использование пинга может быть разумным решением. Другой вопрос предоставляет решение для проверки связи, которое приведено в этом разделе, но оно довольно сложное и требует запуска 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 я узнал, что тесты пропускной способности TCP - не единственный способ измерения качества линии, и их выполнение может привести к неверным результатам. Любая операция загрузки или выгрузки, которая каким-либо образом не ограничена скоростью ни приложением, ни сетью, всегда будет пытаться "максимально использовать" схему. Выбор меньшего файла может по-прежнему максимально использовать схему, но только на более короткий период времени. И, конечно же, страх использования слишком большой полосы пропускания или скачков в цепи - вот что приводит к попытке ограничить частоту, что, в свою очередь, ограничивает вашу видимость.

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

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

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

удачи!

Дейв

Средний пинг и UDP RTT от МА до ВА

Answer 2

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

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

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

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

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

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

всего наилучшего,

Дейв

(На рисунке ниже показана наша диаграмма потери пакетов, показывающая серьезные потери при загрузке через соединение Comcast в Массачусетсе.)