Я студент и подключаюсь к интернету с помощьюШибболет. На самом деле у меня есть скрипт Python на Raspberry Pi с Selenium и PhantomJS для автоматического подключения при запуске.
Я хотел бы проверить подключение к Интернету, не перегружая сеть.
Мониторинг Icinga, установленные соединения netstat, ping, nmap... Лучший способ?
решение1
Было бы неправильно предполагать, что соединение должно быть либо мертвым, либо живым, и что вы можете надежно определить разницу. Такое предположение приводит к ненадежным системам, поскольку вы можете в конечном итоге положиться на эвристику, которая на самом деле не проверяет свойство живости, которое вы ожидали.
Лучший подход — следить за тем, работает ли то, что вам нужно для подключения. Например, если вам нужно, чтобы определенный клиент подключился к определенному серверу, то это то, за чем вам следует следить. Пока эти двое продолжают общаться, вам все равно, посчитает ли другая эвристика, что соединение не работает.
Если мониторинг обнаруживает проблему, то вы можете захотеть, чтобы мониторинг оповещал об этом. Возможно, вы хотите, чтобы мониторинг не только обнаруживал отсутствие соединения и оповещал, но и пытался исправить проблему. Однако это приводит к большему количеству вопросов.
Например, предположим, что у вас есть оборудование, которое может выключить и включить сетевой компонент в случае сбоя. Тогда, возможно, вы не хотите выключать и включать его только потому, что клиент и сервер не могут общаться друг с другом. Может быть, другой конец соединения был отключен, и выключение и включение не было нужно. Может быть даже, что выключение и включение питания само по себе приведет к отключению или помешает ручному вмешательству.
Существуют способы обойти такие проблемы. Например, если соединение с сервером, по-видимому, разорвано, то вы можете отправить DNS-запрос для сервера. Если вы получили ответ, то это произошло не потому, что соединение полностью разорвано. Но вам даже не нужно отправлять запрос на весь путь до DNS-сервера. Вы можете отправить DNS-запрос с низким пределом переходов. Например, если вы отправили DNS-запрос с пределом переходов 3 и получили ICMP-отчет с третьего перехода, то маловероятно, что выключение и включение первого перехода решит проблему.
Конечно, это не панацея. Даже самые лучшие эвристики иногда дают сбои. Если вы когда-нибудь построите что-то, что попытается автоматически перезапустить разорванное соединение, вам определенно нужно убедиться, что у него есть стратегия экспоненциального отката, чтобы предотвратить его повторный перезапуск.
Очевидно, что мониторинг подключения не может быть выполнен без обмена пакетами. Но вы хотите ограничить стоимость обработки этих пакетов. Например, хотя вы можете отправить пакет на несколько скачков и получить сообщение об ошибке обратно от определенного маршрутизатора, это не самая дешевая операция для большинства маршрутизаторов. Если вы можете найти способ отправить пакет туда и обратно, не задействуя ничего, кроме аппаратной части пересылки маршрутизаторов, то это дешевле, даже если для этого потребуется больше скачков.
Если у вас больше сайтов, вы можете повысить надежность мониторинга соединения, периодически связываясь друг с другом попарно. Если один сайт одновременно потерял связь со всеми другими сайтами, то весьма вероятно, что у этого сайта есть проблема с подключением.
решение2
Если вы хотите узнать, возможен ли доступ в Интернет, то наиболее надежным способом будет DNS-поиск www.google.com через серверы 8.8.8.8 и 8.8.4.4.
Если вы не можете получить ответ, то, скорее всего, что-то не так с вашим подключением к Интернету. Обратите внимание, что «что-то не так» не означает отсутствие доступа вообще.
Невозможно доказать, что интернет-соединение идеально.