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