Все разряды, относящиеся к network- и subnet-части, заменим на 1, все значения, относящиеся к host-части,– на 0. В результате получим маску подсети.
Например, маска подсети для целой сети класса A будет выглядеть как 255.0.0.0, для сети класса B: 255.255.0.0, для сети класса C – 255.255.255.0. Для разделения на подсети, как было сказано выше, нужно некоторые биты хост-части выделить для поля подсети. Например, маска 255.255.255.192 определяет подсеть класса C, для которой количество хостов будет равно 62.
Протоколы ARP, RARP
Когда формируется пакет для отправления, на сетевом уровне закладывается IP-адрес получателя. Однако для передачи на нижестоящий канальный уровень также нужно знать MAC-адрес. Для определения соответствия IP-адресу MAC-адреса существует ARP-протокол (Address Resolution Protocol, протокол определения адресов). Он работает следующим образом.
Формируется специальный широковещательный ( broadcast ) запрос. Он рассматривался выше, его особенность в том, что его получают все устройства, подключенные к этой локальной сети. В таком запросе MAC-адрес получателя состоит из одних бинарных единиц, а в поле IP-адреса записывается именно тот адрес, для которого требуется определить MAC-адрес. Когда некий компьютер получает такой запрос, он сравнивает указанный IP-адрес со своим. Если они различаются, сообщение игнорируется. Если они равны, то формируется ответ, в котором по всем правилам указаны IP- и MAC-адреса отправителя, то есть искомой машины.
Для того, чтобы не нагружать широковещательными запросами сеть, ARP-протокол поддерживает специальную ARP-таблицу, которая находится в оперативной памяти и хранит соответствие между IP- и MAC-адресами. После удачного определения MAC-адреса какого-нибудь узла сети делается соответствующая запись в таблицу, чтобы при следующей отсылке пакета не пришлось снова рассылать broadcast -запросы. Спустя некоторое время запись удаляется. Это позволяет автоматически подстраиваться под изменения в сети, ведь у какого-то узла могли изменить MAC- или IP-адрес. Если отправитель не находит IP-адрес получателя в ARP-таблице, то снова формируется и отправляется ARP-запрос.
Протокол RARP (Reverse ARP – обратный ARP) действует наоборот – он известному MAC-адресу сопоставляет IP-адрес. Это необходимо, например, для работы таких протоколов, как BOOTP (Bootstrap Protocol, протокол автоматической настройки) и DHCP (Dynamic Host Configuration Protocol, протокол динамической конфигурации хостов). Их назначение – облегчить задачи системному администратору. Они позволяют не вводить IP-адрес в каждый компьютер локальной сети, а назначают их сами в автоматическом режиме. При загрузке очередной машины посылается broadcast -запрос – противоположный ARP-запросу. Если в ARP-запросе идет опрос 'IP получателя известен, MAC получателя – ???', то в RARP-запросе 'MAC получателя известен, IP - ???'. Если в сети есть DHCP-сервер, он отвечает на RARP-запрос, указывая IP-адрес для этого компьютера (особенно это эффективно при большом количестве компьютеров).
Оба эти протокола работают в рамках лишь локальной сети, поскольку все пакеты, направляемые в другие сети, обрабатываются и маршрутизируются роутером, поэтому знать MAC-адрес не требуется (отправитель указывает MAC-адрес самого роутера).
Transport layer (layer 4)
Рассмотрим протокол 4-го транспортного уровня модели OSI. Семейство TCP/IP включает в себя два таких протокола – TCP и UDP. TCP (Transmission Control Protocol, протокол управления передачей) обеспечивает виртуальные соединения между пользовательскими приложениями и гарантирует точную доставку данных. UDP (User Datagram Protocol, протокол передачи датаграмм пользователя) служит для быстрого обмена специальными сообщениям (датаграммами) без гарантии доставки.
Основные характеристики TCP и UDP показаны в табл. 16.3.
Таблица 16.3. Основные характеристики TCP и UDP.TCPUDPДля работы устанавливает соединениеРаботает без соединенийГарантированная доставка данныхГарантий доставки нетРазбивает исходное сообщение на сегментыПередает сообщения целиком в виде датаграммНа стороне получателя сообщение заново собирается из сегментовПринимаемые сообщения не объединяютсяПересылает заново потерянные сегментыПодтверждений о доставке нетКонтролирует поток сегментовНикакого контроля потока датаграмм нет
TCP
TCP/IP представляет собой комбинацию двух уровней, TCP и IP. IP – протокол третьего уровня – обеспечивает наилучшую, но не гарантированную доставку данных через сеть. TCP – протокол четвертого уровня – позволяет эту гарантию обеспечить. Поэтому совместно они могут предоставить большее количество сервисов.
Работа по TCP-протоколу начинается с установления соединения. Два компьютера (один из них инициатор соединения, второй – принимающий) обмениваются специальными пакетами в три этапа. Условно их можно назвать 'запрос', 'подтверждение' и 'подтверждение на подтверждение'. Такая процедура необходима, чтобы при получении какого-нибудь старого пакета (например, делается вторая попытка установить соединение) не возникало никаких неоднозначностей.
После успешного установления соединения участники могут начать обмениваться данными. Рассмотрим пример HTTP-сервера, который отправляет HTML-страницу клиенту. Текст может быть слишком длинным, чтобы уместиться в один пакет, поэтому первая задача уровня TCP – разбить сообщение на несколько пакетов, а на стороне отправителя – собрать их опять в единое целое. Поскольку очередность пакетов несомненно важна, каждый получает порядковый номер.
Следующая задача протокола – обеспечить гарантированную доставку. Делается это с помощью следующей процедуры. Отправитель посылает пакет с номером n и начинает ждать. Получатель в случае успешного прихода пакета n, отправляет подтверждение о получении ('квитанцию'), в котором также указывает номер n. Если отправитель в течение определеннного времени (тайм-аута) не получает подтверждения, он считает пакет n потерянным и отсылает его еще раз.
Разумеется, отправителю неэффективно просто ждать, пока получатель получит и обработает каждый пакет по одному. Поэтому процедура усложняется, вводится специальное понятие – 'окно' (window). Окно
