Основы TCP/IP

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

1. Определение типа носителя данных, то есть среды передачи данных. Передача может вестись по медным проводам различных типов, по оптоволокну, по радиоволнам, или, например, при помощи голубиной почты --- как предлагает один юмористический стандарт. Чем больше размер сети, тем больше вероятность того, что в ней используется различные типы носителей данных.

Предположим для определенности, что данные в сети передаются по кабелю с четырьмя проводам. Тогда необходимо также выяснить, как выглядит этот носитель, какие его физические характеристики, какие провода используются для передачи, а какие --- для приема данных, и как выглядит представление двоичных данных в носителе. Кроме того, нужно отличать факт передачи от отсутствия передачи: допустим, наличие напряжения --- есть данные (+5 вольт --- единица, -5 вольт --- ноль), отсутствие напряжения --- нет данных.

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

2. Интерфейс между компьютером и средой передачи данных обеспечивается сетевой картой, часто интегрированной в материнскую плату компьютера. После создания адаптера, преобразующего электрический сигнал в среде передач данных в передаваемые на системную шину данные и наоборот, уже можно обмениваться данными между двумя компьютерами. Но изначально планировалось обеспечить доступ к среде передачи данных для множества машин, а не только двух. Для решения этой проблемы надо разработать дисциплину доступа нескольких компьютеров к общей среде передачи данных. Даже если к среде подключены только два компьютера, то всё равно надо договориться, например, о том, как выглядит отсутствие данных (как абонент поймет, что сейчас передача не идет), и как определяется начало передачи. Например, для начала передачи можно использовать некие последовательности из нулей и единиц. Когда же компьютеров несколько, то надо точно указывать адресата передаваемых данных. Также дисциплина должна обеспечивать одновременную (или псевдо-одновременную) передачу данных от нескольких компьютеров друг другу.

Однако и после решения этих проблем задача объединения большого количества компьютеров в одну вычислительную сеть еще не решена. Мы решили задачу объединения лишь небольшого числа компьютеров в рамках одной среды, внутри которой каждый компьютер может непосредственно связаться с каждым, или, другими словами, каждый виден другому. Как только появится несколько таких сред передачи данных, то мы вернемся к первой из описываемых нами проблем, а именно: придется снова налаживать передачу между абонентами этих сред. Для этого необходимо всех подключенных абонентов проидентифицировать.

3. Класс задач уровня организации сети содержит две задачи.

• Идентификация всех компьютеров сети, например, присвоение им уникального номера.
• Объединение разных сред передачи данных. Когда сетей много, в каждой все подключенные устройства пронумерованы, и возникает задача передача информации от компьютера одной сети компьютеру другой, то, очевидно, что данные будут переброшены через несколько сред передачи. В частности, на пути будут несколько устройств, которые и занимаются передачей из одной среды в другую. Такие устройства в ряде случаев называются маршрутизаторами, а данная задача называется задачей маршрутизации.

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

4. Контроль за доставкой информации. Способов нарушить сохранность данных немного: данные можно либо изменить при передаче, т.е. испортить, либо вообще потерять, т.е. адресат их не получит. Есть и такой изощренный способ, когда вы отправляете один массив данных, а приходит два. Такое случается, когда какое-либо устройство послало данные, а ему вдруг пришло сообщение об ошибке и оно отправило их еще раз, а на самом деле ошибки не случилось. Потому в задачу контроля качества доставки (QoS --- Quality of Service) входят следующие компоненты.

• Доставка в целости и сохранности (security & integrity). Данные должны быть защищены от случайных изменений при передаче, а так же, желательно, от преднамеренных изменений и от просмотра третьими лицами. Сюда также входят такие компоненты, как обязательное оповещение отправителя об успешной доставке или наоборот, запрос на повторную посылку в случае неудачи.

• Отслеживание состояния канала передачи данных. Приведем пример ситуации, когда это жизненно важно: пусть отправитель подключен в сеть через очень быстрый интерфейс и извергает гигабитный поток данных, а на стороне получателя находится обычный модем. Было бы неплохо не только сообщать отправителю, его данные никуда не пришли и произошла ошибка по дороге, но еще и отслеживать параметры качества этого виртуального канала, организованного между двумя компьютерами, и регулировать скорость передачи данных соответствующим образом.
• Управление потоками данных (идентификация разных потоков и предотвращение их смешивания). Между двумя компьютерами могут передаваться несколько независимых потоков данных: например, программа-броузер загружает параллельно несколько изображений на одной странице. Эта задача решается при пакетной передаче данных. Если в потоке есть несколько элементов (пакетов), которые передаются от одного компьютера другому, то каждый пакет содержит информацию о том, к какому потоку он сам относится.

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

Схема TCP/IP

Общепринятым стандартом на организацию сетей передачи данных в настоящий момент является набор протоколов, называемых "схемой TCP/IP". IP и TCP --- названия двух ключевых протоколов схемы. Сетевой протокол определяется:

• своим назначением и предоставляемым возможностями;
• типами сообщений и правилами обмена ими;
• используемым нижестоящим протоколом или протоколами.

Перечисленные выше пять задач соответствуют четырехуровневой схеме TCP/IP. Уровень физического носителя иногда так же относят к интерфейсному уровню TCP/IP.

Схему TCP/IP иногда также называют стеком TCP/IP или моделью TCP/IP.

Независимость уровней схемы TCP/IP

Одна из важных характеристик схемы TCP/IP --- высокая независимость уровней друг от друга.

• Если обеспечен интерфейс между компьютером и средой передачи данных (например, установлена сетевая карта Gigabit-Ethernet), то при решении задачи маршрутизации пакетов на сетевом уровне можно не беспокоиться о свойствах кабеля или радиосигнала.
• Транспортный уровень, организуя надёжный канал передачи данных, может не заботиться о том, по каким маршрутам передаются отдельные пакеты на сетевом уровне.
• Когда программа прикладного уровня, например, веб-браузер, получает некоторую страничку, она может не беспокоиться, сколько раз на транспортном уровне пришлось запрашивать повторные пакеты для обеспечения надёжной доставки.

Понятия пакета

Необходимо отметить, что существуют две фундаментально разных дисциплины передачи данных.

• Сети с коммутацией каналов. В качестве примера можно рассмотреть аналоговую телефонную сеть. Два абонента арендуют канал для звонка. Этот канал в некотором смысле виртуальный --- он состоит из цепочки физических каналов, арендованных на каждом участке сети, однако абоненты этого не замечают. Во время звонка каждый из абонентов занят и не может осуществить другой звонок. Достоинством подобных сетей является то, что на время соединения качество связи более или менее гарантировано. Основной их недостаток --- возможные перегрузки сети, при которых из-за нехватки физических каналов на том или ином участке сети, не обязательно ближайшем к абоненту, абонент может быть "занят", хотя сам и не совершает звонка.

• Сети с коммутацией пакетов в настоящий момент. Единицей передачи данных является пакет. Один абонент может отправить другому абоненту пакет в любой момент. Время между отправками отдельных пакетов определяется дисциплиной передачи пакетов, например, нужно ли дождаться ответного пакета от получателя или серию пакетов можно послать без подтверждения. Возможна ситуация, когда качество существующего соединения между абонентами ухудшится, например из-за перегрузки пакетами на каком-то из промежуточных узлов.

Уже на канальном уровне в свое время было принято решение использовать сеть с коммутацией пакетов. Понятие пакета встречается на каждом уровне. Для физического уровня это может быть кадр Ethernet, он же Ethernet-фрейм (от англ. frame), для сетевого --- IP-пакет, для траспортного --- TCP-пакет, для прикладного --- например, DNS-пакет.

Для сложных протоколов верхнего уровня вместо понятия пакета обычно используются понятия сообщения, запроса и ответа (например, HTTP-запрос и HTTP-ответ) или команды (например, команда FTP).

Понятие адреса

На каждом из уровней схемы TCP/IP используются своя система адресов отправителя и получателя.

На прикладном уровне используются так же символьные DNS-адреса (например, edu.ru) и адреса ресурсов (например, http://edu.ru/new.php).

Инкапсуляция протоколов TCP/IP

Пакеты протоколов более высокого уровня прозрачно передаются в качестве данных в пакетах протокола более низкого уровня. Именно поэтому используется понятие "стек TCP/IP".

Например, пусть у нас есть HTTP-клиент (веб-броузер) и HTTP-сервер, протокол HTTP относится к прикладному уровню. Допустим, сервер приготовил HTTP-специфический массив данных --- веб-страницу, и собирается его передать, воспользовавшись услугами транспортного уровня. Для передачи по протоколу TCP этот файл должен быть разбит на фрагменты определенного размера. Каждый такой фрагмент инкапсулируется в TCP-пакет и снабжается дополнительной служебной информацией, характерной для протокола TCP. На этом дело не останавливается. Для передачи каждого TCP-пакета средствами IP он должен быть, в свою очередь разбит на фрагменты определенного размера, характерного для протокола IP. Каждый из этих фрагментов инкапсулируется в IP-пакет и снабжается своей служебной информацией, на этот раз характерной для протокола IP. Допустим, по правилам маршрутизации выяснилось, что нам нужно передать этот пакет нашему ближайшему соседу по сети. Операция повторяется снова --- IP-пакет разбивается и инкапсулируется в несколько пакетов физического уровня, например, ethernet-фреймов.

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

В некоторых случаях, в частности, когда это связано с ретрансляцией через сетевые экраны, решение о судьбе пакета может приниматься на TCP-уровне.

Инкапсуляция протколов приводит к накладным расходам: фактически по сети передаётся существенно больше данных, чем было запланировано прикладном уровне.

В качестве примера протокола физического и канального уровней рассмотрим группу стандартов, в совокупности называемых Ethernet.

Физический носитель данных

В стандартах Ethernet первых версий (v1.0 и v2.0) использовался коаксиальный кабель. Позже появилась возможность использовать в качестве кабеля связи также витую пару и оптический кабель. В настоящее время наиболее часто используется витая пара. Существует восемь спецификаций витой пары, включая подкатегории: cat1-cat6, cat5e, cat6a. Кабель пятой категории обычно используется для сетей с пропускной способностью до 100 МБит/с, для сетей с большей пропускной способностью используются категории 6, 6a, 5e. Кабель пятой категории состоит из четырех пар изолированных проводников, переплетенных между собой с разным шагом. В каждой паре один провод используется для передачи данных, другой для заземления, что позволяет уменьшить помехи. В следствие такой схемы появляется ограничение на длину расплетенной части кабеля. В сетях с пропускной способностью до 100 МБит используются только две пары, в гигабитных --- все четыре. В кабелях 6-й категории между парами проложена крестообразная (в сечении) вставка, обеспечивающая лучшую защиту от помех. Также, на них накладываются более сильные ограничения на допустимый изгиб.

Дисциплина передачи

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

1. Определение состояния среды передачи данных. Прежде чем что-либо передавать, сетевое устройство определяет, свободна ли среда. Если свободна, то происходит передача, в противном случае передача откладывается на некоторое, случайное время. При каждой неудачной попытке срок ожидания удваивается. Это позволяет избежать так называемого request storm, когда после долгого ожидания сразу много участников посылают свои запросы. Случайность времени ожидания обеспечивается простейшим встроенным в сетевую карту генератором псевдослучайных чисел, инициализируемым, например, MAC-адресом.

2. Разрешение коллизий при попытке одновременной передачи данных. Если два участника одновременно проверили, что среда свободна, и два фрейма начинают передаваться одновременно, то возникает коллизия. Устройства должны уметь распознавать возникновение коллизий. В такой ситуации обе стороны вновь используют алгоритм из первого пункта и откладывают передачу на случайное время. Следует отметить, что в полно-дуплексных вариантах Ethernet (например, 100Mbit/s full-fuplex) прием и передача ведется параллельно по разным парам кабеля и коллизии не возникают, для чего используется соответствующее сетевое оборудование.

3. Уникальная адресация. В сети Ethernet каждое устройство имеет уникальный идентификатор --- MAC-адрес, состоящий из 6 байт. Обычно записывается в шестнадцатеричном виде, байты отделяются символов ":". Первые три байта соответствуют коду производителя, последние --- уникальному коду самого устройства. Современные сетевые адаптеры позволяют изменять MAC-адрес, однако необходимость в этом возникает редко.

В каждом Ethernet-фрейме (пакете канального уровня), помимо прочей служебной информации, содержатся MAC-адреса отправителя и получателя фрейма. В пределах данной среды передачи данных MAC-адреса уникальны, что обеспечивает работоспособность дисциплины передачи. Однако, то, что существуют и другие виды сред передачи, помимо Ethernet, делает невозможным использование MAC-адресов для универсальной нумерации всех устройств в сети. Кроме того, некоторые производители могут нарушать соглашения о распределении MAC-адресов, а пользователи --- менять MAC-адреса своих сетевых карт.

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

Сетевые интерфейсы

Сетевой интерфейс --- способ подключения компьютера к среде передач данных. Увидеть доступные сетевые интерфейсы можно воспользовавшись, например, командами ip link или, сокращенно, ip l. Пример:

# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 08:00:27:50:7a:b1 brd ff:ff:ff:ff:ff:ff

В данном примере в системе есть два интерфейса: lo и eth0. Обычно в GNU/Linux имеется хотя бы один сетевой интерфейс --- так называемый loopback (обратная петля). Этот интерфейс предоставляет возможность подключения компьютера только к самому себе. Подобное необходимо для отладки работающих с сетью программ в условиях отсутствия сети и для простого ограничения некоторой сетевой службы только локальным взаимодействием, недопускающим подключения внешних клиентов.

Традиционно для именования интерфейсов Ethernet-адаптеров используются комбинации префикса eth и порядкового номера, начиная с 0: eth0, eth1 и т.д.

После строк link/loopback и link/ether в результатах команды ip link указаны MAC-адреса соответствующих интерфейсам сетевых адаптеров. MAC-адрес интерфейса lo (обратной петли) полагается нулевым.

Адрес brd (broadcast --- широковещательный) используется для того, чтобы послать данные сразу всем адаптерам, подключенным к данной среде. У сетевого интерфейса lo этот адрес, естественно, отсутствует. У Ethernet интерфейсов он равен FF:FF:FF:FF:FF:FF.

Особенности широковещательной среды передачи данных

При некоторых условиях Ethernet-фрейм, посланный отправителем, не попадает напрямую только получателю, а становится доступен всем компьютерам, объединенным в сеть. Это происходит с широковещательными фреймами, при использовании сети с концентраторами и в ряде других случаев. Каждый сетевой адаптер принимает фрейм и анализирует MAC-адрес предполагаемого получателя. Дальнейшее поведение сетевого адаптера зависит от режима, в котором он находится. В обычном режиме адаптер отбрасывает все фреймы, MAC-адрес которых не является широковещательным и не совпадает с его собственным. Кроме обычного, существует неразборчивый (promiscuous) режим, в нем сетевой адаптер фильтрацию по MAC-адресам не производит. Неразборчивый режим может использоваться злоумышленником для сканирования сетевого трафика с целью выделения паролей. Для обнаружения подобной атаки можно использовать генерацию большего количества пакетов, адресованных несуществующим получателям. Нагрузка на нефильтрующий адаптер значительно увеличится по сравнению с нагрузкой на устройства, работающие в обычном режиме, и поэтому некоторые наблюдаемые свойства атакующей системы изменятся.

Задачи сетевого уровня

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

1. Однозначно идентифицировать все компьютеры в глобальной сети, чтобы их можно было адресовать и отличать друг от друга.
2. Организовать маршрутизацию данных от одного компьютера к другому через некоторое количество промежуточных узлов.

С развитием концепции глобальной сети на сетевом уровне стека TCP/IP были реализованы возможности по передаче данных из любой сети в любую сеть, независимо от протоколов нижнего уровня. Задачей протокола сетевого уровня IP (Internet Protocol) является обмен между устройствами, которые, вообще говоря, не находятся в одной среде передачи данных. Для этого необходимо определить, во-первых, механизм адресации, чтобы можно было выделить среди множества компьютеров тот, которому предназначены данные, и, во-вторых, механизм маршрутизации, отвечающий за доставку пакетов между различными сетями. Рассмотрим подробнее каждую из этих двух функций протокола IP.

IP-адресация

Адрес устройства в сети, использующий протокол IP версии 4, состоит из четырёх байт, которые обычно записываются как четыре десятичных числа от 0 до 255, разделённые точками. Распределением IP-адресов в масштабах земного шара занимается организация IANA. Эта организация выделяет диапазоны адресов другим организациям, затем эти диапазоны делятся на более мелкие диапазоны и в конце концов присваиваются компьютерным сетям, и внутри сети устройствам присваиваются адреса из присвоенного этой сети диапазона.

Диапазоны IP-адресов организуются так, что у всех компьютеров одной сети первые несколько бит адреса совпадают. Таким образом, IP-адрес можно разделить на две части. Первая из них адресует сеть и одинакова для всех устройств, подключённых к данной среде передачи данных, а вторая -- хост в сети, т. е. конкретное устройство, например компьютер или сетевой принтер. Записывается это следующим образом: после собственно адреса указывается количество бит, адресующих сеть, например 127.0.0.1/8 или 192.168.200.10/24. Количество бит идентификатора хоста (k) позволяет вычислить максимально возможное количество машин в сети: оно равно 2^k-2. Кроме приведённой краткой формой записи маски, существует и другая, когда маску, подобно адресу, записывают в виде четырёх десятичных чисел. При этом равный единице двоичный разряд соответствует адресу сети, а равный нулю --- адресу хоста. Таким образом, краткой записи маски /24 соответствует полная маска 255.255.0.0.

Назначение масок и адресов сети следующее: если адрес сети двух компьютеров совпадает, то они подключены к одной среде передачи данных, и передача между ними является локальной. Если адреса сети назначения отличается от адреса сети отправителя, то речь необходимо определить маршрут следования IP-пакета с данными. Для решения этой задачи существует IP-маршрутизация.

Ранее использовалась несколько иная, классовая, система IP-адресов. В соответствии с ней IP-адреса делятся на четыре класса: A, B, C, D и E. Принадлежность к тому или иному классу определяется следующим образом: рассмотрим IP-адреса как строку битов и выберем те, у которых первый (старший) бит --- 0. Сети с такими адресами являются сетями класса А; их адрес может быть представлен в виде N.H.H.H, где N --- cеть (network), H --- хост (host). Под адрес хоста отводится 3 байта, это означает, что внутри локальной сети может находиться примерно 16 млн компьютеров. Соответственно, адрес сети занимает оставшийся 1 байт. В связи с тем, что адреса класса А имеют 8-разрядный сетевой префикс (т.е. сеть идентифицируется 8 битами), их обозначают записью /8. Cетям класса B (N.N.H.H) соответствуют IP-адреса, начальные биты которых --- 10, сетям класса C (N.N.N.H) --- адреса, начальные биты которых --- 110. Аналогично обозначению сетей класса А, сети классов B, C, D обозначаются /16 и /24.

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

Рассмотрим примеры IP-адресов с указанием маски сети и их связь с классами сетей: 127.0.0.1/8 --- IP-адрес класса А, 192.168.10.2/24 -- адрес в сети класса С, 10.1.2.15/24 --- адрес в подсети с маской /24 в сети класса А.

Настройка IP-адреса

Для операций с IP-адресами машины в системе Linux можно использовать команду ip addr. Примерный вывод этой команды имеет следующий вид:

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 08:00:46:43:09:11 brd ff:ff:ff:ff:ff:ff

Как видно из вывода команды ip addr, вся сеть класса А 127.0.0.1/8 по стандарту распределения адресов отведена под локальный сетевой интерфейс, через который данные передаются только в пределах одного компьютера.

Одним из способов задания IP-адреса сетевому интерфейсу является использование команды ip. Выполним команду ip addr add 192.168.200.117/24 dev eth0, после этого введем ip addr, чтобы посмотреть, что получилось.

# ip addr add 192.168.200.117/24 dev eth0
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 08:00:46:43:09:11 brd ff:ff:ff:ff:ff:ff
    inet 192.168.200.117/24 scope global eth0

Мы научились вручную настраивать IP-адрес и маску компьютера в сети. В соответствии с маской /24 все компьютеры с адресами 192.168.200.xxx будут считаться принадлежащим нашей же сети, а с другими IP-адресами --- каким-то другим сетям. Однако, мы не указали компьютеру, как следует передавать данные, если их получатель находится в не нашей сети. Для этого нужно рассмотреть IP-маршрутизацию.

Отображение IP-адреса в MAC-адрес

Прежде чем переходить к маршрутизации, рассмотрим вопрос передачи данных в пределах одной сети. В случае, если несколько компьютеров объединены средой передачи данных, то каждое устройство может каждому передавать некоторые данные через канальный уровень, при этом определяющим является не IP-адрес хоста, а его MAC-адрес, обычно закреплённый за сетевой картой. Более того, может случиться, что MAC-адрес может связываться с различными IP-адресами с течением времени, как и IP-адрес может связываться с различными MAC-адресами. Поэтому необходимо выяснить, кому передавать фрейм протокола Ethernet, зная только IP абонента. Для этого, прежде чем начнётся передача полезных данных, следует выяснить, на какой MAC-адрес необходимо отправить данные.

Для хранения данных о том, какому IP соответствуют какие MAС, служат ARP-таблицы. При выполнении команды ip n, то можно увидеть ARP-таблицу с адресами соседей по среде передачи данных. Обычно мы увидим там компьютер с адресом 1 в нашей же сети.

# ip n
dev eth0 lladdr 00:10:dc:63:fc:c0 REACHABLE

Если выполнить команду tcpdump arp, то при начале передачи данных какой-то машине можно увидеть, что происходит в сети. Для сброса ARP-таблицы перед экспериментом следует выполнить команду ip n flush all.

# ip n flush all
# tcpdump arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:38:02.331053 arp who-has 192.168.200.1 tell pspo.local
18:38:02.331257 arp reply 192.168.200.1 is-at 00:a0:c9:b2:ef:c4 (oui Unknown)
18:38:07.331993 arp who-has pspo.local tell 192.168.200.1
18:38:07.332021 arp reply pspo.local is-at 08:00:46:43:09:11 (oui Unknown)

4 packets captured
4 packets received by filter
0 packets dropped by kernel

Команда tcpdump arp говорит, что мы слушаем протокол ARP, предназначенный для выяснения MAC-адреса по известному IP-адресу. В момент начала передачи данных хосту с адресом 192.168.200.1 произошло следующее:

• Протокол IP установил, что адрес получателя находится в локальной сети, и можно передавать данные непосредственно через среду передачи данных;
• Для выяснения MAC-адреса получателя всем узлам, подключённым к среде передачи данных, посылается eth-фрейм. Он представляет собой широковещательный ARP-запрос, который сообщает всем остальным машинам примерно следующее: "кому принадлежит адрес 192.168.200.1 - отзовитесь".
• Получатели принимают этот eth-фрейм, и хост с IP-адресом 192.168.200.1 сообщает в ответе свой MAC-адрес.
• Инициатор процесса запоминает выясненный IP-адрес в своей ARP-таблице.

Отметим, что сам протокол ARP относится к канальному уровню, поскольку в нем происходит обмен фреймами протокола Ethernet без использования протокола IP.

IP-маршрутизация

Основная задача на сетевом уровне --- организовать маршрутизацию между двумя компьютерами в разных точках земного шара. Для этого требуется пронумеровать все компьютеры уникальными IP-адресами, что практически невозможно. Поэтому все возможные IP-адреса были разделены на две большие группы: внешние (иногда называемые "белыми") и внутренние ("серые"). Последние не являются уникальными и могут назначаться компьютерам локальной сети по желанию администратора. Для них выделены следующие диапазоны адресов: 127.0.0.0/8 для передачи только в пределах одного хоста и 172.16.0.0/12, 192.168.0.0/16 и 10.0.0.0/8 для выделения адресов в локальных сетях. При этом каждый маршрутизатор в интернете считает, что компьютеров с такими адресами быть не может. Для связи между компьютерами с внутренними и внешними адресами существует специальный механизм трансляции сетевых адресов, который будет рассмотрен позднее.

Итак, что же будет, если мы захотим переслать по протоколу IP данные машине, подключённой к другой среде передаче данных и имеющей другой адрес сети? Ни одной машине в локальной сети этот пакет пересылаться не должен, вместо этого он должен быть отправлен специальному компьютеру или устройству, называемому IP-маршрутизатором. Поэтому для связи с внешним миром в сети должна быть как минимум одна машина, которая занимаются тем, что перекладывает пакеты с одного своего сетевого интерфейса на другой.

Таким образом, для передачи данных в другие сети необходимо знать адрес как миниму одного маршрутизатора, подключённого к этой же сети. Существуют некие правила, по которым в локальной сети выбираются машины, которым передаются пакеты, не адресованные машинам данной сети. Эти правила и называются маршрутизацией. Простейшим правилом будет выбор для всех внешних адресов единственного маршрутизатора, называющегося маршрутизатором по-умолчанию (default gateway). В общем же случае необходимо написать таблицу, определяющую, какая машина отвечает за пересылку пакетов в Интернет или в другую сеть. У обычных хостов содержимое таблицы ограничивается одним или, реже, несколькими локальными маршрутизаторами.

Для указания маршрутизатора по умолчанию в случае ручной конфигурации интерфейса необходимо указать IP-адрес машины, которая им является. Команда ip route add default via 192.168.200.1 устанавливает 192.168.200.1 в качестве адреса маршрутизатора по умолчанию. После чего, выполнив команду ip route, мы увидим два маршрута; второй, для локальных адресов, появился автоматически. В таблице маршрутизации указывается, каким маршрутизаторам посылать IP-пакеты для разных адресов назначения.

# ip route add default via 192.168.200.1
# ip route
192.168.200.0/24 dev eth0  proto kernel  scope link  src 192.168.200.117
default via 192.168.200.1 dev eth0

Как в результате формируется весь маршрут пакета? Это выполняется динамически: в каждой точке маршрутизации принимается решение, куда IP-пакет отправить дальше. Но что делать очередному маршрутизатору, если пакет отправлять некуда, например маршрутизатор по умолчанию не задан, а адресат в таблице маршрутизации не обнаружен? Для ответа на этот вопрос следует рассмотреть протокол ICMP.

Диагностика сетевого соединения

После настройки IP-адреса машины маски следует проверить работоспособность маршрутизатора по умолчанию, например, отдав команду ping.

$ ping 192.168.200.1
PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data.
64 bytes from 192.168.37.1: icmp_seq=1 ttl=255 time=1.26 ms
64 bytes from 192.168.37.1: icmp_seq=2 ttl=255 time=0.892 ms
64 bytes from 192.168.37.1: icmp_seq=3 ttl=255 time=0.880 ms

Чтобы пояснить происходящее при её выполнении, уместно вспомнить о таком понятии, как протокол. Протокол --- это документ, который описывает, как происходит взаимодействие в сети в различных ситуациях. Таких протоколов очень много, и на каждом из уровней стека TCP/IP действуют свои протоколы. Так, на сетевом уровне существуют протоколы, которые из которых позволяет решать определённый круг задач. Основной протокол сетевого уровня --- IP --- предназначен для передачи полезных данных. Другой задачей сетевого уровня является передача диагностических сообщений. Например, маршрутизатор должен уведомить отправителя, если невозможна организация маршрута до получателя, причем это может обнаружить машина в середине маршрута. В таком случае ей необходимо послать диагностическое сообщение о том, что пакет не будет доставлен. Это одна из многих задач, которые надо решать, когда нам нужно выслать сведения о сложившейся ситуации. Протокол, решающий эти задачи прямо на уровне IP, называется ICMP (Internet Connection Management Protocol). В частности, команда ping  пользуется одним из типов таких сообщений --- эхо-запросами (ICMP Echo Request). Она посылает специальный ICMP-пакет в котором содержится информация о его номере и нечто вроде "ответь мне пожалуйста". Согласно протоколу ICMP получатель обязан отослать по получении эхо-ответ (ICMP Echo Reply).

Несмотря на очевидный системный характер протокола ICMP --- он не несёт никаких данных --- чрезвычайно вредно отключать или ограничивать его. При этом нужно знать, какие типы ICMP действительно нужны, а какие --- нет.

Чтобы проследить весь путь пакета от маршрутизатора к маршрутизатору, можно воспользоваться командой traceroute с указанием IP-адреса пункта назначения, например:

$ traceroute 194.107.17.137
1  192.168.1.1 (192.168.1.1)  2.825 ms  3.585 ms  4.160 ms
2  ppp83-237-4-1.pppoe.mtu-net.ru (83.237.4.1)  14.061 ms  15.617 ms  17.048 ms
...
8  te2-3.cerber.citytelecom.ru (217.65.1.246)  23.526 ms  23.508 ms  23.900 ms
9  altlinux-gw.datahouse.su (89.188.100.246)  24.386 ms  25.619 ms  27.260 ms
10  jabber.altlinux.org (194.107.17.137)  28.575 ms  30.186 ms  31.362 ms

В ответ будут выведены адреса и имена маршрутизаторов, через которые проходит маршрут. Как же это реализовано? Для этого используется специальное поле в IP-пакете, называющееся ttl (Time To Live), которое уменьшается на единицу каждую секунду жизни пакета или при каждом прохождении через маршрутизатор. Соответственно, сначала посылается ICMP-пакет с ttl=1, и при первом прохождении через маршрутизатор ttl обнуляется, о чём маршрутизатор посылает ICMP-сообщение в связи с истечением времени жизни IP-пакета. Далее посылается пакет с ttl=2, и так далее. Это позволяет определить место разрыва сети, если проблема связана, например, с работой интернет-провайдера.

Задачи транспортного уровня

Рассмотрим теперь четвертый уровень стека TCP/IP --- уровень протоколов TCP и UDP. Предыдущий уровень --- сетевой --- дал нам теоретическую возможность доставить пакет до любого получателя. На транспортом уровне решается вопрос реализации этой возможности, для чего необходимо обеспечить подтверждение получения данных получателем. Иными словами, мы должны решить следующий вопрос: доставлен ли IP-пакет?

Получение подтверждения о приеме переданных данных крайне важно, как для отслеживания качества взаимодействия по сети, так и по ряду других причин. Механизм подтверждения, казалось бы, прост: когда абонент получает данные, он отправляет подтверждение, а когда подтверждение получено, можно отправлять следующий фрагмент данных. Однако такой подход неэффективен, поэтому в протоколе TCP для ускорения работы используются одно подтверждение на несколько принятых пакетов и посылка некоторого объема данных без ожидания подтверждения предыдущих.

Кроме подтверждения доставки, транспортный протокол должен предоставлять следующие возможности. Если исходное сообщение большое, требуется разбить его на пакеты так, чтобы абонент затем мог восстановить исходные данные. На стороне абонента при этом должен быть механизм проверки, все ли пакеты пришли, и механизм сборки сообщения из пакетов. Возможна такая ситуация: данные были отправлены, но абонент ничего не получил. Пусть передаваемая информация разделена, скажем, на четыре пакета, которые отправляются последовательно, один за другим. Допустим, что абонент получает 1-й, 2-й и 4-й пакеты (3-й потерялся "по пути"). Нужно разработать механизм объединения этих четырех пакетов в поток так, чтобы получатель понял, что он не получил именно 3-й пакет (то есть тот 4-й, который он получил, есть именно 4-й, а не 3-й). В противном случае при "перемешивании" пакетов (например, в результате причуд маршрутизации вначале придет 4-й пакет, а только потом - 3-й) будет невозможно восстановить исходный порядок пакетов, а следовательно, и передаваемую информацию. Итак, необходимо решить вопрос манипулирования потоками данных. В случае, когда мы передаем сразу два потока данных, нужно сделать так, чтобы эти потоки друг от друга отличались.

Обеспечение надежной передачи должно начинаться с решения вопроса о подключении. Иными словами, перед тем как данные передавать, следует убедиться в том, что их кто-то будет принимать. К примеру, мы хотим отправить данные абоненту с адресом 158.250.10.1. Однако "существует" ли он для нас --- априори неизвестно. Даже в случае его существования мы не можем гарантировать, что маршрут, по которому пойдет пакет, функционирует корректно. Прежде чем начать передачу данных данному абоненту, следует обменяться с ним вспомогательной информацией. Если абонент не отвечает, то "добраться" до него мы не сможем, так что передавать данные бессмысленно.

Как видно даже из краткого описания возможностей протокола TCP, он передает заметное количество служебной информации. Однако всегда ли необходимо решение всех перечисленных задач? К примеру, если вся информация, которую надо передать, помещается в один пакет, то можно пойти более простым путем. Чтобы была возможность выбора, на транспортном уровне поддерживается два протокола: надежный протокол TCP и ненадежный протокол UDP. Пакеты протокола UDP обычно называют датаграммами.

Итак, можно выделить пять задач надежного транспортного протокола:

• установка соединения;
• подтверждение доставки;
• контроль за целостностью данных;
• манипуляция потоками данных;
• отслеживание качества канала.

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

Как уже было сказано, помимо протокола TCP существует еще и протокол UDP. Следует разобраться, в каких ситуациях какой транспортный протокол предполагается использовать. Разберем подробнее указанный пример. Допустим, мы хотим послать ровно один пакет. Нужны ли нам в этом случае организация из него потока данных, отслеживание качества канала, или даже установка соединения? Если вся информация, которую мы собираемся передавать, умещается в один акт передачи данных, то ничего из перечисленного организовывать не нужно. В крайнем случае, повтор пересылаемых данных можно переложить на вышестоящий прикладной протокол. Поскольку проверка контрольной суммы осуществляется и при использовании протокола UDP, то единственная возможная проблема --- потеря пакета. Но в случае соединения по протоколу TCP дела обстоят не лучше: если первые пакеты при попытке установить соединение не дошли до абонента, то соединение просто не установится. Следовательно, в нашем случае разумно использовать UDP, а потом просто проверить: дошел ли наш пакет? К примеру, именно так устроен протокол DNS: на UDP-запрос должен прийти ответ, который, во-первых, подтверждает корректную доставку и, во-вторых, несет содержательную информацию.

Именно по этой причине на транспортном уровне всего два протокола передачи данных: один из них пять перечисленных свойств надежного протокола поддерживает --- это протокол TCP. Другой же не поддерживает ни одного из них, потому что все заключено в одной посылке данных, --- это протокол UDP.

Протокол TCP

Рассмотрим, как устроен трехуровневое подключение по протоколу TCP с точки зрения требований к надежному транспортному протоколу.

1. Все начинается с установления подключения. Подключение по TCP двустороннее, то есть данные передаются в обе стороны. Клиент --- это тот, кто инициирует подключение ("программа, которая хочет"), а сервер --- тот, кто на него отвечает ("программа, которая может"). Итак, инициатор --- клиент --- подключается к серверу. Данные в дальнейшем передаются как от клиента к серверу, так и от сервера к клиенту.
2. TCP устроен по принципу подтверждения: на каждый TCP-пакет (а он может быть гораздо больше, чем IP-пакет!), после того как он принят сервером, генерируется подтверждение, если все принято (все хорошо), или сообщение об ошибке, в случае если пакет "побился" по дороге. Сообщение об ошибке отправляется также в том случае, когда приходит что-то из того же потока данных, но не соответствующее ожиданиям. Это возможно, к примеру, когда в некоторый момент происходит timeout и некоторого пакета (или группы пакетов) внутри потока данных не приходит вообще: "Ты что мне шлешь 12-й? Я хочу 3-й!" Процесс это симметричный, подобно игре в волейбол. Данные, связанные с управлением, и собственно передаваемые данные можно объединять. Разумеется, может прийти и просто подтверждение, если посылать ничего не требуется.
3. В каждом пакете передается также так называемая контрольная сумма, которая позволяет осуществлять контроль за целостностью данных. Все TCP-пакеты перенумерованы: в каждом соединении есть два счетчика SEQN (sequence number) --- по одному на каждое направление передачи. Счетчик инициализируется произвольно взятым числом при подключении и в дальнейшем увеличивается на объем передаваемых данных при каждой отсылке пакета. Такая схема позволяет, с одной стороны, определять последовательность пакетов и, с другой стороны, выяснять, что пропало и не задублировался ли пакет.
4. Для того чтобы выполнить задачу разделения потоков данных, пары "адрес отправителя - адрес получателя" недостаточно. На транспортном уровне вводится новое понятие --- порт. Оно участвует в TCP и UDP и, кроме того, оказывается полезным на уровне интерпретации данных. Придумано оно по аналогии с портами ввода-вывода обычного компьютера. Когда происходит установление соединения, клиент подключается не просто к IP-адресу сервера, но к паре "IP сервера + некоторый порт", причем клиенту так же присваивается некоторый номер порта отправителя.
5. Что касается отслеживания качества канала, то в TCP используется довольно хитрая технология. Не вдаваясь в ее описание, заметим, что главная используемая идея такова: вначале обмен идет маленькими пакетами, а далее этот обмен происходит чем успешнее, тем быстрее: чем больше данных готова принять принимающая сторона, тем больше данных отправляет отправитель.

Применение утилиты tcpdump

Откроем окно эмулятора терминала, перейдем в режим суперпользователя и запустим программу tcpdump со следующими параметрами:

# tcpdump -n  host 89.188.104.91
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

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

$ netcat 89.188.104.91 80
(UNKNOWN) [89.188.104.91] 80 (www) : Connection refused

Как видно, в подключении нам отказали, а tcpdump тем временем выведет примерно следующий текст:

17:07:02.427692 IP 192.168.1.7.50898 > 89.188.104.91.80: S 2822348305:2822348305(0) win 5840 <mss 1460,sackOK,timestamp 4478628 0,nop,wscale 7>
17:07:02.439917 IP 89.188.104.91.80 > 192.168.1.7.50898: R 0:0(0) ack 2822348306 win 0

Попробуем иначе:

$ netcat 89.188.104.91 22
SSH-2.0-OpenSSH_4.3p2 Debian-9

На этот раз все получилось лучше: мы видим приглашение для входа сервиса SSH. Не будем продолжать "разговор" с 89.188.104.91 и завершим соединение, нажав Ctrl+C. Что же за это время выведет tcpdump?

17:08:30.366846 IP 192.168.1.7.42542 > 89.188.104.91.22: S 4202224582:4202224582(0) win 5840 <mss 1460,sackOK,timestamp 4500612 0,nop,wscale 7>
17:08:30.378474 IP 89.188.104.91.22 > 192.168.1.7.42542: S 2533826825:2533826825(0) ack 4202224583 win 5792 <mss 1360,sackOK,timestamp 353673920 4500612,nop,wscale 6>
17:08:30.378533 IP 192.168.1.7.42542 > 89.188.104.91.22: . ack 1 win 46 <nop,nop,timestamp 4500615 353673920>
17:08:30.394466 IP 89.188.104.91.22 > 192.168.1.7.42542: P 1:32(31) ack 1 win 91 <nop,nop,timestamp 353673924 4500615>
17:08:30.394528 IP 192.168.1.7.42542 > 89.188.104.91.22: . ack 32 win 46 <nop,nop,timestamp 4500619 353673924

Что это означает? Вначале мы подключились по IP-адресу 89.188.104.91 на 80-й порт, а потом по тому же адресу, но на 22-й порт. Во втором случае, как видно, нас ожидал OpenSSH-сервер на Debian.

Поскольку установление подключения двустороннее, то когда происходит ответное установление подключение от сервера к клиенту, оно происходит также по определенному порту. Его номер сообщается клиентом в самом начале соединения. В данном случае порт получателя имеет номер 22, а клиент передает номер порта отправителя --- 42542. Как видно, эти номера портов сохраняются и в дальнейшем. Если теперь мы будем устанавливать следующее подключение к тому же самому серверу, в качестве порта отправителя будет использовано другое число. Именно это число и будет отличать соответствующие потоки данных: IP-адрес получателя, порт получателя и IP-адрес отправителя не поменялись, а вот порт отправителя у них разный. Иными словами, каждое TCP-соединение использует свой собственный порт для идентификации отправителя.

Распределение портов транспортного уровня

Для использования портов TCP и UDP отправитель и получатель должны иметь некоторые одинаковые предположения, какая сетевая прикладного уровня служба с каким портом связана. Согласно некоторой договоренности, разные типы приложений традиционно принимают соединения на разных портах. Поэтому данные, приходящие на разные порты, естественно интерпретировать по-разному. При подключении по 80 порту то, что мы передаем, будет интерпретироваться как HTTP-запросы, а по порту 22 нас ждет Secure Shell (SSH). Несложно понять, зачем это соглашение понадобилось. Дело в том, что никакого другого способа указать клиенту, по какому порту подключаться, не существует (кроме, разумеется, словесного описания: "У меня есть сервер, подключайся, пожалуйста, по порту 9090").

Существует организация IANA, в которой можно зарегистрировать свое приложение, сказав: пусть теперь теперь такой-то порт исключительно вот для этого используется. Список зарегистрированных портов можно посмотреть в файле /etc/services:

$ head -35 /etc/services
# /etc/services:
#
# Network services, Internet style
#
# The latest IANA port assignments can be gotten from
#       http://www.iana.org/assignments/port-numbers
# (last updated 8 November 2004)
#
# The port numbers are divided into three ranges: the Well Known Ports,
# the Registered Ports, and the Dynamic and/or Private Ports.
#
# The Well Known Ports are those from 0 through 1023.
# The Registered Ports are those from 1024 through 49151.
# The Dynamic and/or Private Ports are those from 49152 through 65535.
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
#
# Not all ports are included, only the more common ones.
#
# Each line describes one service, and is of the form:
#
# service-name  port/protocol  [aliases ...]   [# comment]

tcpmux          1/tcp                           # TCP port service multiplexer
tcpmux          1/udp                           # TCP port service multiplexer
rje             5/tcp                           # Remote Job Entry
rje             5/udp                           # Remote Job Entry
echo            7/tcp                           # Echo
echo            7/udp                           # Echo
discard         9/tcp           sink null       # Discard
discard         9/udp           sink null       # Discard
systat          11/tcp          users           # Active Users
systat          11/udp          users           # Active Users
$ grep ^ssh /etc/services
ssh             22/tcp                          # SSH Remote Login Protocol
ssh             22/udp                          # SSH Remote Login Protocol

Можно заметить, что временный порт для клиента всякий раз выбирается достаточно большим, согласно рекомендациям из /etc/services он должен выбираться, начиная с 49152, но часто --- начиная с 32000.

Протокол UDP

Скажем несколько слов и о протоколе UDP. На самом деле в TCP-пакетах и UDP-датаграммах нет почти ничего общего, кроме IP-адресов и портов получателя и отправителя. Если на прикладном уровне не организовано специальной поддержки подтверждений, UDP-датаграмма может уйти "в никуда". И, разумеется, есть класс задач, где это единственно возможная организация передачи данных. Классический пример --- широковещание. Никому не придет в голову от всех клиентов, которые смотрят потоковое видео, получать подтверждения и сообщения об ошибках и обрабатывать их. Другая область применения --- случай, когда сам факт обмена данных заключается в посылке очень маленьких пакетов, а работа на прикладном уровне подразумевает, что ответ будет отправлен. Типичный пример --- служба доменных имен DNS. Если мы ждем ответа от DNS-сервера, то его можно ждать и на прикладном уровне - с таким же успехом, как и на уровне установления TCP-соединения. Незачем из одного пакета делать четыре - разумнее экономить трафик, причем чем выше уровень DNS-сервера, тем это выгодней.

Есть и еще одно соображение, которое стоит рассмотреть. Предположим, у нас есть очень медленный (по времени отклика) канал. Оказывается, по такому каналу удобнее "гонять" UDP. Это хорошо видно из следующей схемы:

Но в реальном использовании необходимо оценивать и вероятность возникновения ошибки: если мы узнаем о ней слишком поздно, то будет послано много лишних пакетов. В современном мире среды передачи данных и компьютеры работают все быстрее, а уровень надежности принципиально не повышается. Поэтому и в таких случаях становится все выгоднее использовать протокол с установлением соединения. Классический пример --- сетевая файловая система NFS, переходящая c UDP на TCP в качестве основного протокола.