Правило Марса

Эксперт — любой человек не из нашего города.

- А ты знаешь почему мимо поста ГАИ нужно проезжать медленно? ...

Выпуск дистрибутива Ubuntu 19.04
Thu, 18 Apr 2019 16:19:40 +0300

Релиз OpenSSH 8.0
Thu, 18 Apr 2019 15:08:14 +0300

Oracle меняет лицензию на сборки Java SE. Red Hat взял на себя сопровождение OpenJDK 8 и 11
Thu, 18 Apr 2019 07:53:55 +0300

Компания Mozilla опубликовала систему локализации Fluent 1.0
Wed, 17 Apr 2019 22:48:43 +0300

Zend Framework перешёл под крыло организации Linux Foundation
Wed, 17 Apr 2019 20:07:21 +0300

Релиз Memcached 1.5.13 с поддержкой TLS
Wed, 17 Apr 2019 14:23:18 +0300

Выпуск VirtualBox 6.0.6
Wed, 17 Apr 2019 12:00:12 +0300

Обновление Java SE, MySQL, VirtualBox и других продуктов Oracle с устранением уязвимостей
Wed, 17 Apr 2019 11:11:11 +0300

Опубликован код старых игр Infocom, включая Zork
Tue, 16 Apr 2019 21:59:48 +0300

Выпуск nginx 1.15.12
Tue, 16 Apr 2019 19:17:57 +0300

Кандидат в релизы инсталлятора Debian 10 "Buster"
Tue, 16 Apr 2019 15:07:48 +0300

Уязвимость в Adblock Plus, позволяющая выполнить код при использовании сомнительных фильтров
Tue, 16 Apr 2019 07:31:43 +0300

Результаты совместного финансирования OpenNET в 2019 году
Mon, 15 Apr 2019 20:39:04 +0300

DXVK 1.0.3 с реализацией Direct3D 10/11 поверх API Vulkan
Mon, 15 Apr 2019 19:40:33 +0300

Проект NetBSD развивает новый гипервизор NVMM
Mon, 15 Apr 2019 14:20:21 +0300

Выпуск Bedrock Linux 0.7.3, сочетающего компоненты различных дистрибутивов
Mon, 15 Apr 2019 08:34:05 +0300

Выпуск языка программирования Rust 1.34
Sun, 14 Apr 2019 11:07:21 +0300

Релиз GhostBSD 19.04
Sun, 14 Apr 2019 08:17:08 +0300

Проект VSCodium развивает полностью открытый вариант редактора Visual Studio Code
Sat, 13 Apr 2019 11:53:48 +0300

NVIDIA открыла код системы машинного обучения, синтезирующей пейзажи по наброскам
Sat, 13 Apr 2019 08:58:21 +0300

Первый публичный выпуск дополнения NoScript для Chrome
Sat, 13 Apr 2019 08:17:37 +0300

Судебный иск против Adblock Plus, манипулирующий изменением кода на сайтах
Fri, 12 Apr 2019 23:53:15 +0300

Выпуск текстового редактора GNU Emacs 26.2
Fri, 12 Apr 2019 23:00:10 +0300

Выпуск Wine 4.6
Fri, 12 Apr 2019 22:49:33 +0300

Выпуск дистрибутива NixOS 19.03, использующего пакетный менеджер Nix
Fri, 12 Apr 2019 22:20:17 +0300

Новая версия интерпретатора GNU Awk 5.0
Fri, 12 Apr 2019 21:08:45 +0300

Релиз системы обнаружения атак Snort 2.9.13.0
Fri, 12 Apr 2019 20:29:36 +0300

Подробности про второй взлом Matrix. Скомпрометированы GPG-ключи проекта
Fri, 12 Apr 2019 19:31:29 +0300

Взлом инфраструктуры matrix.org
Fri, 12 Apr 2019 10:38:07 +0300

Выпуск системного менеджера systemd 242
Fri, 12 Apr 2019 10:04:31 +0300

Результат опроса предпочтений разработчиков от Stack Overflow
Thu, 11 Apr 2019 22:10:07 +0300

Релиз Proxmox VE 5.4, дистрибутива для организации работы виртуальных серверов
Thu, 11 Apr 2019 21:22:45 +0300

Google предложил блокировать загрузку некоторых файлов через HTTP по ссылкам с HTTPS-сайтов
Thu, 11 Apr 2019 14:43:18 +0300

Уязвимости в технологии защиты беспроводных сетей WPA3 и в EAP-pwd
Thu, 11 Apr 2019 13:44:29 +0300

Корректирующий выпуск Firefox 66.0.3
Wed, 10 Apr 2019 22:13:36 +0300

В Firefox Beta добавлен блокировщик скриптов майнинга и скрытой идентификации
Wed, 10 Apr 2019 13:47:46 +0300

Сбор средств на поддержание ленты новостей OpenNET в 2019 году (дополнено)
Tue, 09 Apr 2019 16:03:06 +0300

Около 5.5% сайтов используют уязвимые реализации TLS
Tue, 09 Apr 2019 13:52:32 +0300

Система управления конфигурацией Chef стала полностью открытым проектом
Tue, 09 Apr 2019 11:22:14 +0300

Выпуск облачной платформы Apache CloudStack 4.12
Tue, 09 Apr 2019 08:24:22 +0300

IP Управляющие ICMP, ARP, IGMP Транспортные UDP, TCP Работа ТСР RFC
Управляющие протоколы Интернета

Помимо протокола IP, используемого для передачи данных, в Интернете есть несколько управляющих протоколов, применяемых на сетевом уровне, к которым относятся ICMP, ARP, IGMP, RARP, ВООТР и DHCP. В данном разделе мы рассмотрим их все по очереди.

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

Основные типы ICMP сообщений

Тип сообщения

Описание

Адресат недоступен

Пакет не может быть доставлен

Время истекло

Время жизни пакета упало до нуля

Проблема с параметром

Неверное поле заголовка

Гашение источника

Сдерживающий пакет

Переадресовать

Научить маршрутизатор географии

Запрос отклика

Спросить машину, жива ли она

Отклик

Да, я жива

Запрос временного штампа

То же, что и Запрос отклика, но с временным штампом

Отклик с временным штампом

То же, что и Отклик, но с временным штампом

Сообщение АДРЕСАТ НЕДОСТУПЕН используется, когда подсеть или маршрутизатор не могут обнаружить пункт назначения или когда пакет с битом DF (не фрагментировать) не может быть доставлен, так как путь ему преграждает сеть с маленьким размером пакетов.

Сообщение ВРЕМЯ ИСТЕКЛО посылается, когда пакет игнорируется, так как его счетчик уменьшился до нуля. Это событие является признаком того, что пакеты двигаются по замкнутым контурам, что имеется большая перегрузка или установлено слишком низкое значение таймера.

Сообщение ПРОБЛЕМА ПАРАМЕТРА указывает на то, что обнаружено неверное значение в поле заголовка. Это является признаком наличия ошибки в программном обеспечении хоста, отправившего этот пакет, или промежуточного маршрутизатора.

Сообщение ГАШЕНИЕ ИСТОЧНИКА ранее использовалось для усмирения хостов, которые отправляли слишком много пакетов. Хост, получивший такое сообщение, должен был снизить обороты. В настоящее время подобное сообщение редко используется, так как при возникновении перегрузки подобные пакеты только подливают масла в огонь, еще больше загружая сеть. Теперь борьба с перегрузкой в Интернете осуществляется в основном на транспортном уровне. Это будет подробно обсуждаться в главе 6.

Сообщение ПЕРЕАДРЕСОВАТЬ посылается хосту, отправившему пакет, когда маршрутизатор замечает, что пакет адресован неверно.

Сообщения ЗАПРОС ОТКЛИКА и ОТКЛИК посылаются, чтобы определить, достижим ли и жив ли конкретный адресат. Получив сообщение ЗАПРОС ОТКЛИКА, хост должен отправить обратно сообщение ОТКЛИК. Сообщения ЗАПРОС ВРЕМЕННОГО ШТАМПА и ОТКЛИК С ВРЕМЕННЫМ ШТАМПОМ имеют то же назначение, но при этом в ответе проставляется время получения сообщения и время отправления ответа. Это сообщение используется для измерения производительности сети.

Кроме перечисленных сообщений, определены и другие. Их полный список хранится в Интернете по адресу www.iana.org/assignments/icmp-parameters.

Хотя у каждой машины в Интернете есть один (или более) IP-адресов, они не могут использоваться для отправки пакетов, так как аппаратура уровня передачи данных не понимает интернет-адресов. В настоящее время большинство хостов соединены с локальными сетями с помощью интерфейсных карт, понимающих только адреса данной локальной сети. Например, каждая когда-либо выпущенная сетевая карта Ethernet имеет 48-разрядный Ethernet-адрес. Производители сетевых карт Ethernet запрашивают у центра блок адресов, что гарантирует уникальность Ethernet-адресов (это позволяет избежать конфликтов при наличии одинаковых сетевых карт в одной ЛВС). Сетевые карты отправляют и принимают кадры, основываясь на 48-разрядных Ethernet-адресах. О 32-разрядных IP-адресах им ничего не известно.

Таким образом, возникает вопрос: как устанавливается соответствие IP-адресов и адресов уровня передачи данных, таких как Ethernet-адреса? Чтобы понять, как это работает, рассмотрим показанный на рисунке пример, в котором изображен небольшой университет с несколькими сетями класса С (ныне называемыми сетями класса /24). На рисунке мы видим две сети Ethernet: одна на факультете кибернетики с IP-адресом 192.31.65.0, а другая — с IP-адресом 192.31.63.0 на электротехническом факультете. Они соединены кольцом FDDI с IP-адресом 192.31.60.0. У каждой машины сетей Ethernet есть уникальный Ethernet-адрес (на рисунке — от El до Е6), а у каждой машины кольца FDDI есть FDDI-адрес (от F1 до F3).

Рассмотрим, как пользователь хоста 1 посылает пакет пользователю хоста 2. Допустим, отправителю известно имя получателя, например, al@eagle.uni.ru Сначала надо найти IP-адрес для хоста 2, известного как eagle.uni.ru Этот поиск осуществляется службой имен доменов DNS (Domain Name System). На данный момент мы просто предположим, что служба DNS возвращает IP-адрес для хоста 2 (192.31.65.5).

Теперь программное обеспечение верхнего уровня хоста 1 создает пакет со значением 192.31.65.5 в поле Адрес получателя и передает его IP-программе для пересылки. Программное обеспечение протокола IP может посмотреть на адрес и увидеть, что адресат находится в его собственной сети, но ему нужно как-то определить Ethernet-адрес получателя. Одно из решений состоит в том, чтобы хранить в системе конфигурационный файл, в котором были бы перечислены соответствия всех локальных IP-адресов Ethernet-адресам. Такое решение, конечно, возможно, но в организациях с тысячами машин обновление этих файлов потребует много времени и подвержено ошибкам.

Более удачное решение заключается в рассылке хостом 1 по сети Ethernet широковещательного пакета с вопросом: «Кому принадлежит IP-адрес 192.31.65.5?» Этот пакет будет получен каждой машиной сети Ethernet 192.31.65.0, а хост 2 ответит на вопрос своим Ethernet-адресом Е1. Таким образом, хост 1 узнает, что IP-адрес 192.31.65.5 принадлежит хосту с Ethernet-адресом Е2. Протокол, который задает подобный вопрос и получает ответ на него, называется ARP (Address Resolution Protocol — протокол разрешения адресов) и описан в RFC 826. Он ра­ботает почти на каждой машине в Интернете.

Преимущество протокола ARP над файлами конфигурации заключается в его простоте. Системный администратор должен всего лишь назначить каждой машине IP-адрес и решить вопрос с маской подсети. Все остальное сделает протокол ARP.

Затем программное обеспечение протокола IP хоста 1 создает Ethernet-кадр для Е2, помещает в его поле полезной нагрузки IP-пакет, адресованный 192.31.65.5, и посылает его по сети Ethernet. Сетевая карта Ethernet хоста 2 обнаруживает кадр, замечает, что он адресован ей, считывает его и вызывает прерывание. Ethernet-драйвер извлекает IP-пакет из поля полезной нагрузки и передает его IP-программе, которая, видя, что пакет адресован правильно, обрабатывает его.

Существуют различные методы повышения эффективности протокола АRР. Во-первых, машина, на которой работает протокол ARP, может запоминать результат преобразования адреса на случай, если ей придется снова связываться с той же машиной. В следующий раз она найдет нужный адрес в своем кэше, сэкономив, таким образом, на рассылке широковещательного пакета. Скорее всего, хосту 2 понадобится отослать ответ на пакет, что также потребует от него обращения к ARP для определения адреса отправителя. Этого обращения можно избежать, если отправитель включит в ARP-пакет свои IP- и Ethernet-адреса. Когда широковещательный ARP-пакет прибудет на хост 2, пара (192.31.65.7, El) будет сохранена хостом 2 в ARP-кэше для будущего использования. Более того, эту пару адресов могут сохранить у себя все машины сети Ethernet.

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

Чтобы разрешить изменение соответствий адресов, например, при поломке и замене сетевой карты на новую (с новым Ethernet-адресом), записи в ARP-кэше должны устаревать за несколько минут.

Посмотрим снова на рис. 5.53. На этот раз хост 1 хочет послать пакет хосту 4 (192.31.63.8). Обращение к ARP не даст результата, так как хост 4 не увидит широковещательного пакета (маршрутизаторы не переправляют широковещательные пакеты Ethernet-уровня). Есть два решения данной проблемы. Во-первых, маршрутизатор факультета кибернетики можно настроить так, чтобы он отвечал на ARP-запросы к сети 192.31.63.0 (а также к другим местным сетям). В таком случае хост 1 добавит в свой ARP-кэш строку (192.31.63.8, ЕЗ) и будет счастлив посылать весь трафик для хоста 4 локальному маршрутизатору. Такой метод называется ARP-прокси. Второе решение состоит в том, чтобы хост 1 сразу выявлял нахождение адресата в удаленной сети и посылал весь внешний трафик по Ethernet-адресу, обрабатывающему все пакеты для удаленных адресатов, то есть по адресу маршрутизатора ЕЗ. В этом случае маршрутизатору факультета кибернетики не нужно знать, какую именно удаленную сеть он обслуживает.

В любом случае хост 1 помещает IP-пакет в поле полезной нагрузки Ethernet-кадра, адресованного маршрутизатору ЕЗ. Получив Ethernet-кадр, маршрутизатор факультета кибернетики извлекает из поля полезной нагрузки IP-пакет и ищет его IP-адрес в своих таблицах. Он обнаруживает, что пакеты, адресованные сети 192.31.63.0, должны пересылаться маршрутизатору 192.31.60.7. Если ему еще не известен FDDI-адрес маршрутизатора 192.31.60.7, то он посылает по кольцу широковещательный ARP-пакет и узнает, что нужный ему адрес F3. Затем он помещает IP-пакет в поле полезной нагрузки FDDI-кадра, адресованного маршрутизатору F3, и отправляет его по кольцу.

Когда кадр попадает на маршрутизатор факультета электротехники, FDDI-драйвер извлекает из поля полезной нагрузки IP-пакет и передает его IP-программе, которая понимает, что этот пакет следует переслать 192.31.63.8. Если такого IP-адреса еще нет в ARP-кэше, маршрутизатор посылает широковещательный ARP-запрос по сети Ethernet факультета электротехники и узнает, что нужный ему адрес принадлежит хосту E6, поэтому он создает Ethernet-кадр, адресованный хосту Е6, помещает IP-пакет в поле полезной нагрузки и передает его по сети Ethernet. Получив Ethernet-кадр, хост 4 извлекает из поля полезной нагрузки IP-пакет и передает его IP-программе для обработки.

Пересылка хостом 1 пакетов в удаленную сеть по глобальной сети работает аналогично, с той разницей, что на этот раз маршрутизатор факультета кибернетики узнает из своих таблиц, что пакет следует переслать маршрутизатору глобальной сети, чей FDDI-адрес равен F2.

Групповое вещание (multicast) требует некоторых расширений в протоколах узлов, они описаны в RFC 1112. Там же описан и простой протокол IGMP (Internet Group Management Protocol — протокол управления группами). Поддержка группового вещания узлами может быть реализована на трех уровнях:

— не поддерживается.
— поддерживается передача групповых сообщений (необходимые допол­нительные средства минимальны).
— поддерживается передача и прием.

Каждый из адресов диапазона класса D (224.0.0.0—239.0.0.0) представляет идентификатор вещательной группы. Группы делятся на постоянные (permanent) и временные (transient). Адреса постоянных групп назначаются административно. Для временных групп адреса выделяются динамически из незанятых постоянными. Адрес 224.0.0.0 использовать запрещается. Адрес 224.0.0.1 (all-hosts address) используется как общий адрес для всех абонентов группового вешания, непосредственно подключенных к конкретной подсети. Адрес 224.0.0.2 (all routers) используется для обращения ко всем маршрутизаторам IGMP. Эти два адреса служат для распространения информации по протоколу IGMP. Нет способа задать групповой адрес сразу всех узлов глобальной сети. Группы получателей формируются динамически, узел может быть членом нескольких групп.

Трафик вещающего узла передается всем членам группы без гарантии доставки, но с «максимальным старанием». Передача группового трафика в сетях Ethernet использует присущий им механизм многоадресной передачи. При этом младшие 23 бита идентификатора многоадресной IP-группы помещаются в 23 младших бита группового адреса Ethernet 01-00-5Е-00-00-00. Поскольку IP-идентификатор имеет разрядность 28 бит (4 бита занимает признак класса D), возможно, что в одну группу Ethernet будут попадать сообщения нескольких (до 32) IP-групп. Это дает дополнительную нагрузку на нижний протокольный уровень узла, поскольку ему придется фильтровать приходящие пакеты.

Распространение межсетевого группового трафика управляется протоколом IGMP. Все сообщения этого протокола передаются по адресам 224.0.0.1 и 224.0.0.2, поле TTL=1, так что сообщение не выходит за пределы, доступные не­посредственно по локальному интерфейсу. Узел, желающий вступить в группу, передает сообщение Host Membership Report, в котором указывается идентификатор группы. Для верности это сообщение он повторяет 1-2 раза (подтверждений в IGMP не предусматривается). Маршрутизатор, поддерживающий IGMP, принимает это сообщение и заносит идентификатор в свою таблицу с привязкой к порту, от которого получено сообщение. Маршрутизатор периодически посылает запросы Host Membership Query, на которые отвечают узлы, считающие себя членами какой-либо группы. Если на пару опросов для определенной группы никто не отозвался, маршрутизатор исключает эту группу из своей таблицы. Для сокращения избыточного служебного трафика узлы отвечают не сразу, а через случайный интервал времени. Если за время этой задержки узел, собравшийся ответить, услышал такой же ответ от другого узла, он свой ответ аннулирует. О выходе из группы узел явно не сообщает, он просто перестает отвечать на опросы. Протокол IGMP используется и для обмена информацией об используемых группах между маршрутизаторами, поддерживающими групповую пересылку. Маршрутизаторы организуют пересылку пакетов группового вещания между портами, для которых в таблицы занесены соответствующие идентификаторы. Конечно же, распространение этого трафика контролируется и средствами сетевого администрирования.

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

После RFC 1112 появилась новая версия IGMP V.2, обратно совместимая с исходной. В версии 2 введены следующие изменения:

- Определен выбор маршрутизатора-опросчика IGMP — для каждой локальной сети им будет маршрутизатор с наименьшим IP-адресом.
- Определен новый тип сообщения — Group-Specific Query, в котором указывается список групп, принадлежность к которым интересует маршрутизатор в данный момент.
- Определено новое сообщение Leave Group, которым хост явно указывает на намерение выйти из группы (групп). Сообщение посылается по спецпальному адресу 224.0.0.2 (all routers).

Эти меры нацелены на экономию полосы пропускания — сокращение лишнего группового трафика.

Версия 3 предполагает возможность выбора источников, данные от которых интересуют групповых получателей. До сих пор, как только узлы заявляли о вхождении в какую-либо группу, маршрутизаторы доставляли им пакеты от всех источников (их может быть множество) данной группы. Теперь сообщением Inclusion Group-Source Report хост заказывает трафик интересующих источников, а сообщением Exclusion Group-Source Report отказывается от его получения. Таким образом сеть освобождается от ненужного трафика.

Для передачи группового трафика требуется сеть маршрутизаторов (и коммутаторов), поддерживающих протоколы IGMP. Поскольку' в глобальной сети на это способны далеко не все маршрутизаторы, применяют туннелированпе. Пакеты с групповыми адресами инкапсулируются в обычные одноадресные пакеты (IP-Over-IP) и в таком виде пересылаются между шлюзами. Туннели, по которым проходят инкапсулированные пакеты, соединяют шлюзы, расположенные в «островках» сети, на которых имеется полная поддержка группового вещания. В шлюзе на конце туннеля многоадресные пакеты извлекаются из одноадресных и далее рассылаются в пределах «островка» вышеописанным способом. Построение магистральной сети распространения группового трафика Multicast Backbone (MBONE), являющееся нетривиальной задачей, отметим лишь, что для передачи этого трафика используются протоколы DVMRP (Distance Vector Multicast Routing Protocol), MOSPF (Multicast OSPF) или PIM (Protocol-Independent Multicast).

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

Первым для решения проблемы был разработан протокол RARP (Reverse Address Resolution Protocol — протокол обратного определения адреса), описанный в RFC 903. Этот протокол позволяет только что загрузившейся рабочей станции разослать всем свой Ethernet-адрес и сказать: «Мой 48-разрядный Ethernet-адрес — 14.04.05.18.01.25. Знает ли кто-нибудь мой IP-адрес?» RARP-сервер видит этот запрос, ищет Ethernet-адрес в своих файлах конфигурации и посылает обратно соответствующий IP-адрес.

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

Недостаток протокола RARP заключается в том, что в нем для обращения к RARP-серверу используется адрес, состоящий из одних единиц (ограниченное широковещание). Однако эти широковещательные запросы не переправляются маршрутизаторами в другие сети, поэтому в каждой сети требуется свой RARP-сервер. Для решения данной проблемы был разработан альтернативный загрузочный протокол ВООТР. В отличие от RARP, он использует UDP-сообщения, пересылаемые маршрутизаторами в другие сети. Он также снабжает бездисковые рабочие станции дополнительной информацией, включающей IP-адрес файлового сервера, содержащего образ памяти, IP-адрес маршрутизатора по умолчанию, а также маску подсети. Протокол ВООТР описан в документах RFC 951, 1048 и 1084.

Серьезной проблемой, связанной с применением ВООТР, является то, что таблицы соответствия адресов приходится настраивать вручную. Когда к ЛВС подключается новый хост, протокол ВООТР невозможно использовать до тех пор, пока администратор сети не присвоит ему IP-адрес и не пропишет вручную в конфигурационных таблицах пару (Ethernet-адрес, IP-адрес). Для устранения влияния этого фактора протокол ВООТР был изменен и получил новое имя: DHCP (Dynamic Host Configuration Protocol — протокол динамической настройки хостов). DHCP позволяет настраивать таблицы соответствия адресов как вручную, так и автоматически. Этот протокол описан в RFC 2131 и 2132. В большинстве систем он уже практически заменил RARP и ВООТР.

Подобно RARP и ВООТР, DHCP основан на идее специализированного сервера, присваивающего IP-адреса хостам, которые их запрашивают. Такой сервер не обязательно должен быть подключен к той же ЛВС, что и запрашивающий хост. Поскольку сервер DHCP может быть недоступен с помощью широковещательной рассылки, в каждой ЛВС должен присутствовать агент ретрансляции.

Для отыскания своего IP-адреса загружаемая машина широковещательным способом распространяет специальный пакет DISCOVER (Поиск). Агент ретрансляции DHCP перехватывает все широковещательные пакеты, относящиеся к протоколу DHCP. Обнаружив пакет DISCOVER, он превращает его из широковещательного в одноадресный и доставляет DHCP-серверу, который может находиться и в другой ЛВС. Агенту ретрансляции необходимо знать всего одну деталь: IP-адрес DHCP-сервера.

Встает вопрос: на какое время можно выдавать в автоматическом режиме IP-адреса из пула? Если хост покинет сеть и не освободит захваченный адрес, этот адрес будет навсегда утерян. С течением времени будет теряться все больше адресов. Для предотвращения этих неприятностей нужно выдавать IP-адреса не навсегда, а на определенное время. Такая технология называется лизингом. Перед окончанием срока действия лизинга хост должен послать на DHCP-сервер запрос о продлении срока пользования IP-адресом. Если такой запрос не был сделан или в просьбе было отказано, хост не имеет права продолжать использование выданного ранее адреса.

НОВОСТИ: Выпуск nginx 1.15.12 Tue, 16 Apr 2019 19:17:57 +0300

Доступен выпуск основной ветки nginx 1.15.12, в рамках которой продолжается развитие новых возможностей (в параллельно поддерживаемой стабильной ветке 1.14 вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей.

???????@Mail.ru Opera Firefox INFOBOX - хостинг Google Chrome