Предисловие, которое вполне может сойти за disclaimer.
Прежде всего давайте договоримся о чем пойдет и о чем НЕ пойдет речь ниже, чтобы избежать неясностей в дальнейшем.
Топик 1. Речь пойдет о том, почему нельзя считать пингование фрихоста (при помощи ICMP PING) с компьютера юзера (вирпила) однозначным доказательством стабильности соединения между компом данного вирпила и фрихостом.
Топик 2. Речь также пойдет о том, можно ли быть уверенным в качестве связи (соединения) юзера (вирпила) через Интернет с фрихостом до такой степени, чтобы уверенно заявить (опираясь на увиденное только своими глазами на экране монитора), что другой вирпил находится в варпе.
Ни о чем более, кроме как о темах, указанных в топиках 1 и 2 речи вести не предполагается (потому просьба не искать в нижеизложенном глобпльной или частичной теории Интернета или теорий сетевых протоколов).
Теперь собственно дисклаймеры.
Прежде всего, слова, обращенные к моим коллегам ? специалистам IT. Все что я буду излагать ниже предназначено в основном для мало посвященных, или не очень хорошо посвященных, или посвященных, но не понявших еще до конца того, что является для нас с вами средством зарабатывания на жизнь. Потому, я прошу вас, уважаемые коллеги, принять во внимание, что излагать теорию ниже мне придется достаточно простым языком, прибегая в большинстве случаев к сокращениям и обобщениям, без которых данный материал (и без того обещающий быть не маленьким) превратится в бесконечный. Я призываю вас понять, что я буду заниматься тут неблагодарным делом популяризаторства (не очень приветствуемого мной, как и вами). Но при этом я с удовольствием (в рамках своего и вашего времени) готов дискутировать с вами на принятом между специалистами уровне и в случае необходимости вносить изменения в данный материал.
Теперь дисклаймер для тех, кому материал собственно предназначен. Большая просьба не воспринимать нижеизложенное как учебный материал или как «истину в последней инстанции, застывшую во времени». Воспринимайте это как разбор частного случая возможных проблем виртуальных соединений между вашими компьютерами и сервером фрихоста. Если вы хотите в полном объеме понять тематику и понять, почему я настаиваю на «частности» разбираемого случая, то советую воспользоваться специализированной литературой. Я особенно настаиваю на том, что материал является актуальным на сегодняшнем уровне развития сетевых технологий и может оказаться совсем никчемным через достаточно небольшой промежуток времени, ибо Интернет, а вместе с ним и сетевые технологии идут вперед довольно быстро.
Общий дисклаймер. При изложении материала мне придется воспользоваться техническими терминами и выдержками из специальной литературы. В меру своего умения я буду объяснять значение терминологии на русском языке. Я буду пользоваться цитатами из литературы на английском языке и прошу понять это не как желание кому-то запудрить мозги, а как мою уверенность в том, что лучше чем сказано авторами, мне сказать не удастся. При этом я готов буду объяснить в случае непонимания о чем идет речь (само-собой в рамках собственного понимания тематики). Каждую цитату я буду снабжать ссылкой с указанием откуда она взята.
Последнее ? являсь человеком, работающем в мире cisco, я буду пользоваться литературой cisco. Специалисты поймут о чем я, но хочется, чтобы данный материал не воспринимался как «повод к битве» между cisco и non-cisco. В конце-концов теория, на которую я буду опираться базово едина.
TOPIC 1. Почему нельзя считать пингование фрихоста (при помощи ICMP PING) с компьютера юзера (вирпила) однозначным доказательством стабильности соединения между компом данного вирпила и фрихостом.
Наверное, не будет большой ошибкой сказать, что среди пользователей Интернет общепринятым методом проверки доступности удаленного хоста является пинг. Пинг с том виде, в каком он реализован в рамках операционной системы MS Windows является программой, использующей механизм протокола ICMP, являющегося протоколом Network layer (по классификации модели OSI).
Коротко и очень популярно о том, для чего служит протокол ICMP ? для контроля и менеджмента (проверки работоспособности) протокола IP.
Более профессиональная формулировка ? ICMP, described in RFC 792, specifies a variety of messages whose common purpose is to manage internetwork. ICMP messages may be classified as either error messages or query and responses. (Chapter 2, p.73. Routing TCP/IP vol.1. CCIE Professional Deployment. Jeff Doyle)
RFC 792 дает такое описание назначения ICMP ? Occasionally, a gateway or destination host will communicate with a source host, for example, to report an error in datagram processing. For such purposes this protocol, The Internet Control Message Protocol (ICMP), is used. ICMP uses the basic support of IP as if it were a higher level protocol, however, ICMP is actually an integral part of IP, and must be implemented by every IP module.
Существенно упрощая механизм работы ICMP можно сказать так ? когда на source хосте (компьютере юзера) запущен пинг другого хоста (destination - удаленного компьютера), пакеты, сгенерированные протоколом ICMP инкапсулируются в data link layer (фреймы) на source хосте и отправляются на destination через каналы интернет. Destination хост, получив пакет ICMP отвечает на каждый пакет определенным образом, генерируя пакет ответа, и этот пакет ответа отправляется destination хостом обратно на source хост. Это может быть пакет ECHO, при котором source юзер Windows видит:
Reply from 192.168.0.2: bytes=32 time<1ms TTL=128
Reply from 192.168.0.2: bytes=32 time<1ms TTL=128
Reply from 192.168.0.2: bytes=32 time<1ms TTL=128
Reply from 192.168.0.2: bytes=32 time<1ms TTL=128
Это также может быть пакет Host Unreachable, при этом source юзер Windows видит:
Reply from (router): destination host unreachable
Reply from (router): destination host unreachable
Reply from (router): destination host unreachable
Reply from (router): destination host unreachable
Или это может быть пакет TIME EXCEEDED, с соответствующим изображением у source юзера в Windows:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Я намеренно не углубляюсь в дебри роутинга и не заостряю внимание на том, destination хост ли, роутер ли и какой именно роутер возвращает на source компьютер ответ ICMP. Для понимания сути это не столь важно.
Важно другое. Если понятно для чего служит ICMP - взгляните еще раз на картинку с моделью OSI и запомните на каком Layer находится этот протокол.
Теперь вкратце что означает модель OSI (Open System Interconnection reference model).
Глобальное назначение этой модели ? обеспечить стандарты передачи данных, позволяющие коммуникацию между собой оборудования различных производителей. Модель эта является базовой виртуальной моделью, отображающей систему передачи данных с одного компьютера на другой.
Опять таки, без углубления в дебри, рассмотрим применение модели OSI к нашему случаю.
Вот (при понимании процесса инкапсуляции как, процесса идущего от верхнего лейера к нижнему) как выглядит процесс передачи данных с одного компьютера на другой, согласно OSI:
Отправленные application (например FTP программой) с source компьютера данные разбиваются на сегменты на 4 layerе, затем на пакеты на 3-м, потом на фреймы на втором и на биты на первом. Этот процесс носит название инкапсуляции. В виде битов информация передается через Интернет на destination компьютер и на нем происходит процесс восстановления данных от первого лейера до седьмого (в нашем примере) ? этот процесс носит название деинкапсуляции.
Теперь рассмотрим что просходит при пинге с source хоста другого (destination) хоста.
Поскольку ICMP существует на Network Layer, то source компьютер отправит на destination компьютер пакеты (принадлежащие network layer). Пакеты будут инкапсулированы в фреймы и биты и отправлены, а затем деинкапсулированы на destination компьютере
ДО NETWORK LAYER. Ответ в виде ICMP reply будет отправлен с destination компьютера в обратном направлении тоже с Network Layer и будет получен source компьютером и деинкапсулирован
до Network Layer .
Если это понятно, то перейдем к сути вопроса. Почему же ICMP PING в конкретном рассматриваемом случае с фрихостом и юзером не может считаться надежным доказательством стабильности соединения?
Причин две. Основных, разумеется. И в популярном изложении, разумеется.
Первая причина ? протокол связи WB ? это протокол TCP, протокол, принадлежащий Transport Layer. То есть, клиент, установленный на вашем компьютере начинает инкапсуляцию данных обмена с фрихостом с Transport Layer. TCP сегменты инкапсулируются в IP пакеты, далее во фреймы, биты ? и передаются. ICMP же, которым вы привыкли фрихост пинговать, к данному процессу имеет достаточно виртуальное отошение ? он никак не участвует в процессе обмена данными между вашим клиентом и фрихостом. Он просто существует на том же уровне, на каком существует IP.
То есть, пинг с вашего компьютера на компьютер, где установлен фрихост и процесс обмена данными между вашим клиентом и сервером фрихоста ? процессы параллельные и мало пересекающиеся. Надеюсь теперь, исходя из теории TCP/IP и модели OSI понятно, что пинг с вашего компьютера и ответы типа
Reply from 192.168.0.2: bytes=32 time<1ms TTL=128
Означают всего лишь одно ? ваш компьютер может послать пакет ICMP до фрихост-сервера и получить от него ответ. То есть
принципиально виртуальный линк от вашего компьютера до фрихоста может существовать. И вы вполне можете запустить программу клиента и она, по всем признакам, наверняка законнектится на фрихост.
Что касается параметра time и значения возле него в ms (миллисекундах) ? то это, упрощенно говоря, время, за которое на вашем компьютере был получен назад от фрихоста ответ ICMP (ECHO REPLY). Если вы правильно поняли теорию OSI модели и правильно поняли где в этой модели существует ICMP, то вам не составит труда понять,
насколько относительно ICMP PING показывает действительное состояние (стабильность) виртуального линка от вашего компьютера до фрихоста. Для того, чтобы убедиться в справедливости этого утверждения, рекомендую проделать такую процедуру:
1. Пропинговать фрихост из ваших Windows и запомнить значение ms
2. Запустить клиента WB и дать команду .pingtest ? и сравнить полученные данные с данными от команды пинг.
Вот что получилось у меня на тестовом модемном соединении:
Из системы:
#badboy>ping 195.208.34.5
Pinging 195.208.34.5 with 32 bytes of data:
Reply from 195.208.34.5: bytes=32 time=234ms TTL=238
Reply from 195.208.34.5: bytes=32 time=206ms TTL=238
Reply from 195.208.34.5: bytes=32 time=193ms TTL=238
Reply from 195.208.34.5: bytes=32 time=216ms TTL=238
Ping statistics for 195.208.34.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 193ms, Maximum = 234ms, Average = 212ms
Из WB клиента:
463 ms TCP Round Trip
Проверяйте у себя
Теперь можно поговорить
о второй причине .
Не знаю всем ли понятно, почему ответ от ваших «форточек» (здесь говорим только о OS Windows 95/98/2000/XP) содержит только четыре пинга by default. Именно четыре, а не 10 и не 1. Ответ простой ? потому что это стандарт. И если в «форточках» задать команду ping без дополнительных параметров ? будет получен ответ от четирех посланных пакетов ICMP. Совсем уж грубо говоря, дефолтной командой пинг вы проверите соединение вашего компьютера с фрихостом в течение максимально 4 секунд. Тем, кто еще не понял о чем речь и обладает терпением и любовью к экспериментам я советую задать пинг со сделающими параметрами:
Ping ?t 195.208.34.5 и пойти попить кофе.... минут так на 30. А потом вернуться, остановить все это безобразие CTRL-C и посмотреть значение в графе Lost = 0 (0% loss). Вместо 0 у вас там вполне может оказаться иная цифра, которая вас несомненно позабавит
Для тех кто не знает ? пояснение ? здесь будет указано количество пакетов ICMP, на которые от destination хоста (в нашем случае от сервера фрихоста) не пришел ответ. Почему не пришел ? отдельный вопрос. Теперь вспоминаем насчет разницы ICMP и TCP, включаем воображение... и думаем ? а так ли надежно мое соединение с фрихостом, как мне кажется...
Надеюсь, что вышеприведенное популярное изложение всем понятно... и многое теперь встало на свои места. Если что-то непонятно ? задавайте вопросы. Будем вместе отвечать. Если заинтересовались вопросом глубже и готовы постигнуть все тонкости, о которых за неимением времени тут речь не шла ? читайте документацию по TCP/IP routing, теории TCP/IP и OSI model.
Теперь перейдем к более сложному вопросу ? Topic 2.
Сообщение от badboy
Предисловие, которое вполне может сойти за disclaimer.
Ответить с цитированием