Журнал LinuxFormat - перейти на главную

LXF129:DrBrown3

Материал из Linuxformat
Версия от 17:04, 3 апреля 2011; Crazy Rebel (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

Джонни-датаграмма

Взгляд на Сеть глазами скромного запроса HTTP GET.


Познакомьтесь с Джонни. Он – датаграмма, и вот его история. Он уродился обычным пакетом HTTP­запроса, одним из тех, что в бессчетном количестве каждый день бесстрашно бороздят Интернет. Но он мог бы быть и STMP­запросом, и эхо­запросом ICMP, и да же презренным сегментом TCP SYN. История отличалась бы ненамного.

Джонни возник в 13:34:07 в понедельник 14 декабря, когда Майк (реальный человек) щелкнул по ссылке в браузере, чтобы зайти на сайт Linux Format. Для получения web­страницы браузер Майка создал Джонни­датаграмму. При рождении он был длиной 522 байта. Начинался он с текста GET/HTTP/1.1, а заканчивался пустой строкой – так уж устроены HTTP­заголовки. Правду сказать, он весь состоял из заголовка при пустом теле, что, по мнению Джонни, было странновато, но браузер убедил его, что для HTTP­запроса GET это нормально. Создав пакет, браузер направил его в стек протокола TCP/IP на компьютере Майка с четкими инструкциями передать его на порт 80 компьютера с IP­адресом 88.212.205.226.

Слой TCP на компьютере Майка взял Джонни­датаграмму и добавил к нему заголовок. С этим заголовком, с его важными полями, включая window size (размер окна) и sequence number (номер последовательности), и таинственными флагами с краткими именами SYN, PSH и FIN, Джонни приосанился. Но он чувствовал, что важнейшие поля в его TCP­заголовке – номера портов источника и получателя. Слой TCP казался озабоченным судьбой Джонни: он записал в своем блокноте, когда тот покинул компьютер. Джонни думал, как здорово быть частью протокола, основанного на соединениях, и жалел датаграммы протокола UDP без установки соединения, с их тщедушными заголовками, не стоящими внимания. Теперь Джонни стал длиной 554 байта. Он был уверен, что достаточно короток, чтобы по дороге его не разреза ли на части, и благодарил за это судьбу. При мысли о фрагментации, передаче и сборке на другом конце у него слезы на глаза наворачивались.

Время вышло

Джонни передали на слой IP, который тут же добавил другой заголовок с IP­адресами источника и получателя и каким­то полем под названием time to live (время жизни), которое немного его встревожило. Джонни было всего несколько десятков микросекунд, а уже казалось, что дни его сочтены! Теперь он был длиной 574 байта.

Джонни гордился своими новыми яркими заголовками: ведь теперь достаточно было взглянуть на них, чтобы понять, куда он направляется. Он был благодарен за это – честно говоря, он не представлял, как самому это узнать, и ему на каждом шагу приходилось бы спрашивать, куда идти.

Слой IP передал Джонни дальше по стеку протоколов, где его обернули в кадр Ethernet, готовый для передачи по локальной сети на шлюз по умолчанию. В этом кадре были Ethernet­адреса источника и получателя, каждый по 6 байт, так что теперь Джонни достиг 588 байт и заметно отяжелел. Сам процесс передачи был довольно странным: в каждый момент времени передавался только один бит, и Джонни не мог засечь свое пребывание «в проводах»: все больше и больше его оказывалось на получателе и все меньше и меньше на источнике.

Потом Джонни угодил в ADSL­маршрутизатор Майка. Его Ethernet­кадр был разобран, и, к ужасу Джонни, маршрутизатор затеял менять адрес источника в его IP­заголовке и порт источника в TCP­заголовке. Маршрутизатор отверг его протесты: «Прости, приятель, – скорбно сказал он, – но ты пришел с частного IP­адреса, и выпускать тебя в Интернет в таком виде против правил. Боюсь, что ты немаршрутизируемый». Потом Джонни снова обернули для передачи по ADSL­соединению на первый из нескольких маршрутизаторов интернет­провайдера Майка.

Все это шлюзование – разборка внешнего кадра, принятие решения о маршрутизации и обертка в кадр – повторялось снова и снова, и Джонни уже начал терять ему счет. Он заметил, что его время жизни, начавшееся с 64, постепенно уменьшается. Джонни подивился, что же будет, когда оно достигнет нуля. Из киберпространства появится ужасный цифровой чистильщик и утащит его в /dev/null? Это больно?

Блуждая по главным шлюзам Интернета, он заинтересовался, что такое «ориентированность TCP­протокола на соединения». Ни один из шлюзов, которых расспрашивал Джонни, ничего не знал о соединении, частью которого он был. «Не все тебе равно, – говорили они, – мы лишь направляем тебя, а потом навек о тебе забываем». Вообще­то, пока он не достиг TCP­слоя сервера Linux Format, «соединения» как такового не было. По крайней мере, кажется, его ждали. И правда, ему были так рады, что даже сразу отправили компьютеру Майка подтверждение, что Джонни успешно прибыл. TCP­слой на конце Майка облегченно вздохнул и вычеркнул Джонни из списка. «Еще один добрался, босс», сказал он ядру.

Игра в ожидания

До прибытия в сетевой интерфейс получателя (web­сервер Linux Format) Джонни пересек 15 маршрутизаторов, и его возраст был уже 74 мс – неплохо для датаграммы, думал он. Отсюда он вывел, что потратил менее миллисекунды на «движение», а остальные 73 просидел в очередях и буферах шлюзов – опыт, в миниатюре иллюстрирующий современный перелет на самолете. Но Джонни еще не достиг тихой гавани, и на входе в цепочку сетевого фильтра INPUT на web­сервере Linux Format его посетило дурное предчувствие. Соответствует ли он правилу ACCEPT? Он был почти уверен, что политика по умолчанию будет DENY, потому что в очереди на отправку на компьютере Майка он наслушался грустных историй от обессиленных ICMP­пакетов «порт недоступен», вернувшихся с поля битвы, про храбрых датаграмм, с трудом пробившихся сквозь бесчисленные шлюзы лишь затем, чтобы бесследно исчезнуть во входной очереди получателя. Проходя по цепочке INPUT, правило за правилом, без единого совпа дения, он уже начал отчаиваться. Тут правило с совпа дением сжа лилось над ним, и его пропустили по стеку дальше к получателю.

Слой IP ласково удалил IP­заголовок Джонни и передал его на слой TCP, а тот, удалив TCP­заголовок, обнажил исходный заголовок HTTP­запроса и направил Джонни к последнему получателю – порту 80. В этот момент Джонни наконец вспомнил, зачем пришел. Теперь он мог передать свой GET­запрос очень восприимчивому web­серверу Apache! «Хорошо, Джонни, – дружелюбно сказал сервер Apache, – я его беру...»

История Джонни близится к концу, но она отнюдь не единична. Он был не первой датаграммой, появившейся на свет, когда Майк щелкнул по ссылке Linux Format. Еще до того, как Джонни мог начать свое путешествие, для установки соединения уже были переданы запросы и ответы DNS, ARP и три TCP­пакета. По сути, Джонни был одним из 52 пакетов HTTP­запроса GET, созданных просто для того, чтобы скачать домашнюю страницу Linux Format на компьютер Майка. Во время загрузки утилита перехвата пакетов Wireshark обнаружила в общей сложности более 1000 пакетов.

Вот такая жизнь Джонни­датаграммы. В следующий раз, щелкая по ссылке, подумайте о Джонни и его друзьях, путешествующих ради вас по киберпространству.

Зачем нужны слои?

С точки зрения администраторов Linux, в стеке протоколов существует четыре слоя.

Верхний – слой приложения; с ним взаимодействуют приложения клиента и сервера. Здесь на ходятся протоколы, исполняющие полезную работу: загрузку web­страниц, отправку электронной почты, поиск IP­адресов, синхронизацию часов, удаленный вход в систему и т. д.

Под ним на ходятся транспортный слой и протоколы TCP и UDP. Они реализуют концепцию номеров портов, чтобы пакеты доставлялись в заданную транспортную конечную точку на компьютере – ту, которую слушает сервер получателя. В случае UDP (User Datagram Protocol – Протокол пользовательских датаграмм) это и все, что делает слой. UDP предоставляет сервис доставки по принципу «делаем как можем», и у него нет встроенного механизма проверки, доставлены пакеты или нет, или отправки пакетов заново при их утрате.

Протокол TCP (Transmission Control Protocol – Протокол управления передачей) гораздо сложнее. В дополнение к номерам портов, задающих конечную точку, в TCP используется схема подтверждения приема (квитирование) и повторная передача. Она гарантирует доставку, даже если нижележащий сетевой слой теряет пакеты. В TCP так же есть необычные механизмы регулирования потока данных по сети. TCP – «протокол, ориентированный на соединение», и использует для его установки три пакета, прежде чем начнет передавать какие­либо данные. Однако, как показал опыт Джонни, только две конечные точки что­то об этом знают. Обеспечение TCP­соединения не использует никаких ресурсов на промежуточных шлюзах.

Копаем глубже

Под транспортным слоем лежит сетевой слой и протокол IP. За дача у IP только одна: маршрутизировать пакеты через Интернет так, чтобы они достигли нужного компьютера. Он не работает с номерами портов и не имеет механизма для подтверждения передачи или ее повтора.

Под транспортным слоем скрываются десятки незаметных протоколов. Они заботятся о физической передаче потока битов с одного компьютера на другой. Здесь расположены семейства протоколов 802.3 (Ethernet) и 802.11 (Wi­Fi). На этом уровне довольно сложная логика, но, к счастью, большинство системных администраторов общается с ним очень мало, разве что когда привязывают к проводам Ethernet веревки, чтобы протащить их через кабель­каналы в офисе!

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF129:DrBrown3&oldid=11644»
Персональные инструменты
купить
подписаться
Яндекс.Метрика