2.1.4. Стек TCP/IP

2.1.4. Стек TCP/IP

Физический и канальный уровни полностью реализуются сетевой картой или модемом (или другим устройством, выполняющим ту же функцию) и ее драйвером. Здесь действительно достигнута настолько полная абстракция, что программист обычно не задумывается о том, какая используется сеть. Поэтому мы также не будем останавливаться на этих двух уровнях. В реальной жизни не все протоколы, особенно старые, соответствуют модели OSI. Существует такое понятие, как стек протоколов — набор протоколов разных уровней, которые совместимы друг с другом. Эти уровни не всегда точно соответствуют тем, которые предлагает модель OSI, но определенное разделение задач на уровни в них присутствует. Здесь мы сосредоточимся на стеке протоколов, который называется TCP/IP (нередко можно услышать словосочетание "протокол TCP/IP", что не совсем корректно: TCP/IP не протокол, а стек протоколов). Название этот стек получил по наименованию двух самых известных своих протоколов: TCP и IP.

Протокол сетевого уровня IP расшифровывается как Internet Protocol. Это название иногда ошибочно переводят как "протокол Интернета" или "протокол для Интернета". На самом деле, когда разрабатывался этот протокол, никакого Интернета еще и в помине не было, поэтому правильный перевод — межсетевой протокол. История появления этого протокола связана с особенностями работы сети Ethernet. Эта сеть строится по принципу шины, когда все компьютеры подключены, грубо говоря, к одному проводу. Если хотя бы два компьютера попытаются одновременно передавать данные по общей шине, возникнет неразбериха, поэтому все шинные сети строятся по принципу "один говорит — все слушают". Очевидно, что требуется какая-то защита от так называемых коллизий (ситуаций, когда два узла одновременно пытаются передавать данные).

Разные сети решают проблему коллизий по-разному. В промышленных сетях, например, обычно имеется маркер — специальный индикатор, который показывает, какому узлу разрешено сейчас передавать данные. Узел, называемый мастером, следит за тем, чтобы маркер вовремя передавался от одного узла к другому. Маркер исключает возможность возникновения коллизий. Ethernet же является одноранговой сетью, в которой нет мастера, поэтому в ней реализован другой подход: коллизии допускаются, но существует механизм их разрешения, заключающийся в том, что, во-первых, узел не начинает передачу данных, если видит, что другой узел уже что-то передает, а во-вторых, если два узла одновременно пытаются начать передачу, то оба прекращают попытку и повторяют ее через случайный промежуток времени. У кого этот промежуток окажется меньше, тот и захватит сеть (или за этот промежуток времени сеть будет захвачена кем-то еще).

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

На канальном уровне существует адресация узлов, основанная на так называемом MAC-адресе сетевой карты (MAC — это сокращение Media Access Control). Этот адрес является уникальным номером карты, присвоенной ей производителем. Очевидно неудобство такого способа адресации, т. к. по MAC-адресу невозможно определить положение компьютера в сети, т. е. выяснить, куда направлять пакет. Кроме того, при замене сетевой карты меняется адрес компьютера, что также не всегда удобно. Поэтому на сетевом уровне определяется собственный способ адресации, не связанный с аппаратными особенностями узла. Отсюда следует, что маршрутизатор должен понимать протокол сетевого уровня, чтобы принимать решение о передаче пакета из одной сети в другую, а протокол, в свою очередь, должен учитывать наличие маршрутизаторов в сети и предоставлять им необходимую информацию. IP был одним из первых протоколов сетевого уровня, который решал такую задачу и с его помощью стала возможной передача пакетов между сетями. Поэтому он и получил название межсетевого протокола. Впрочем, название прижилось: в некоторых статьях MSDN сетевой уровень (network layer) называется межсетевым уровнем (internet layer). В протоколе IP. в частности, вводится важный параметр для каждого пакета: максимальное число маршрутизаторов, которое он может пройти, прежде чем попадет к адресату (этот параметр носит не совсем удачное название TTL — Time То Live, время жизни). Это позволяет защититься от бесконечного блуждания пакетов по сети.

Примечание

Здесь следует заметить, что сеть Ethernet ушла далеко вперёд по сравнению с моментом создания протокола IP и теперь организована сложнее, поэтому не следует думать, что в предыдущих абзацах изложены все принципы работы этой сети (это выходит за рамки данной книги). Тем не менее протокол IР по-прежнему используется, а компьютеры по-прежнему видят в сети не только свои, но и чужие пакеты. На этом основана работа так называемых снифферов — программ, позволяющих одному компьютеру читать пакеты пересылаемые между двумя другими компьютерами.

Для адресации компьютера протокол IP использует уникальное четырёхбайтное число, называемое IP-адресом. Впрочем, более распространена форма записи этого числа в виде четырех однобайтных значений. Система назначения этих адресов довольно сложна и призвана оптимизировать работу маршрутизаторов, обеспечив прохождение широковещательных пакетов только внутри определенной части сети и т. п. Мы здесь не будем подробно останавливаться на этом, потому что в правильно настроенной сети программисту не нужно знать всех этих тонкостей: достаточно помнить, что каждый узел имеет уникальный IP-адрес, для которого принята запись в виде четырех цифровых полей, разделенных точками, например, 192.168.200.217. Также следует знать, что адреса из диапазона 127.0.0.1—127.255.255.255 задают так называемый локальный узел: через эти адреса могут связываться программы, работающие на одном компьютере. Таким образом, обеспечивается прозрачность местонахождения адресата. Кроме того, один компьютер может иметь несколько IP-адресов, которые могут использоваться для одного и того же или разных сетевых интерфейсов.

Кроме IP, в стеке TCP/IP существует еще несколько протоколов — ICMP, IGMP и ARP, — решающих задачи сетевого уровня. Эти протоколы не являются полноценными и не могут заменить IP. Они служат только для решения некоторых частных задач.

Протокол ICMP (Internet Control Message Protocol — протокол межсетевых управляющих сообщений) обеспечивает диагностику связи на сетевом уровне. Многим знакома утилита ping, позволяющая проверить связь с удаленным узлом. В основе ее работы лежат специальные запросы и ответы, определяемые в рамках протокола ICMP. Кроме того, этот же протокол определяет сообщения, которые получает узел, отправивший IP-пакет, если этот пакет по каким-то причинам не доставлен.

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

Протокол IGMP (Internet Group Management Protocol — протокол управления межсетевыми группами) предназначен для управления группами узлов, которые имеют один групповой IP-адрес. Отправку пакета по такому адресу можно рассматривать как нечто среднее между адресной и широковещательной рассылкой, т. к. такой пакет будет получен сразу всеми узлами, входящими в группу.

Протокол ARP (Address Resolution Protocol — протокол разрешения адресов) необходим для установления соответствия между IP- и MAC-адресами. Каждый узел имеет таблицу соответствия. Исходящий пакет содержит два адреса узла: MAC-адрес для канального уровня и IP-адрес для сетевого. Отправляя пакет, узел находит в своей таблице MAC-адрес, соответствующий IP-адресу получателя, и добавляет его к пакету. Если в таблице такой адрес не найден, отправляется широковещательное сообщение, формат которого определяется протоколом ARP. Получив такое сообщение, узел, чей IP-адрес соответствует искомому, отправляет ответ, в котором указывает свой MAC-адрес. Этот ответ также широковещательный, поэтому его получают все узлы, а не только отправивший запрос, и все узлы обновляют свои таблицы соответствия.

Строго говоря, обеспечение правильного функционирования протоколов сетевого уровня — задача администратора системы, а не программиста. В своей работе программист чаще всего сталкивается с более высокоуровневыми протоколами и не интересуется деталями реализации сетевого уровня.

Протоколами транспортного уровня в стеке TCP/IP являются протоколы TCP и UDP. Строго говоря, они решают не только задачи транспортного уровня, но и небольшую часть задач уровня сессии. Тем не менее они традиционно называются транспортными. Эти протоколы мы рассмотрим детально в следующих разделах.

Уровни сессии, представлений и приложений в стеке TCP/IP не разделены: протоколы HTTP, FTP, SMTP и т. д., входящие в этот стек, решают задачи всех трех уровней. Мы здесь не будем рассматривать эти протоколы, потому что при использовании сокетов они в общем случае не нужны: программист сам определяет формат пакетов, отправляемых с помощью TCP или UDP.

Новички нередко думают, что фраза "программа поддерживает соединение через TCP/IP" полностью описывает то, как можно связаться с программой и получить данные. На самом деле необходимо знать формат пакетов, которые эта программа может принимать и отправлять, т. е. должны быть согласованы протоколы уровня сессии и представлений. Гибкость сокетов дает программисту возможность самостоятельно определить этот формат, т. е., по сути дела, придумать и реализовать собственный протокол поверх TCP или UDP. И без описания этого протокола организовать обмен данными с программой невозможно.

Данный текст является ознакомительным фрагментом.