Поток богатств теряется в песках расточительности.

Новость: На сайте Федерального казначейства размещены образцы банкнот нового дизайна. ...

Второй кандидат в релизы инсталлятора Debian 10 "Buster"
Wed, 26 Jun 2019 23:08:37 +0300

Релиз JPype 0.7, библиотеки для доступа к Java-классам из Python
Wed, 26 Jun 2019 22:46:07 +0300

Релиз Chrome OS 75
Wed, 26 Jun 2019 19:50:38 +0300

Разработчики из Google предложили разработать свою libc для LLVM
Wed, 26 Jun 2019 12:36:50 +0300

Уязвимость в AMD SEV, позволяющая определить ключи шифрования
Wed, 26 Jun 2019 10:21:13 +0300

Выпуск nginx 1.17.1 и njs 0.3.3
Wed, 26 Jun 2019 08:50:32 +0300

Обновление Solaris 11.4 SRU 10
Wed, 26 Jun 2019 02:28:47 +0300

Выпуск пакетного фильтра nftables 0.9.1
Tue, 25 Jun 2019 23:20:26 +0300

Совет директоров Apache Software Foundation покинули три видных участника
Tue, 25 Jun 2019 21:08:22 +0300

Доступна бета-версия Linux-редакции игрового движка OpenXRay
Tue, 25 Jun 2019 17:35:02 +0300

Выпуск PyOxidizer для упаковки Python-проектов в самодостаточные исполняемые файлы
Tue, 25 Jun 2019 12:52:38 +0300

Доступен дистрибутив SUSE Linux Enterprise 15 SP1
Tue, 25 Jun 2019 11:11:52 +0300

Утечка BGP-маршрутов привела к массовому нарушению связности в интернете
Tue, 25 Jun 2019 09:41:14 +0300

Представлена плата Raspberry Pi 4
Mon, 24 Jun 2019 23:24:16 +0300

Представлен people.kernel.org, сервис блогов для разработчиков ядра Linux
Mon, 24 Jun 2019 21:58:05 +0300

Canonical пересмотрела планы по прекращению поддержки архитектуры i386 в Ubuntu
Mon, 24 Jun 2019 21:07:39 +0300

Открыты исходные тексты языка программирования V
Mon, 24 Jun 2019 10:32:15 +0300

Поддержка 32-разрядных библиотек в Ubuntu 19.10+ будет заимствована из Ubuntu 18.04
Sun, 23 Jun 2019 22:07:09 +0300

Выпуск файлового менеджера Midnight Commander 4.8.23
Sun, 23 Jun 2019 21:15:58 +0300

В рамках проекта TinyWare подготовлена новая сборка Slackware
Sun, 23 Jun 2019 20:37:24 +0300

Выпуск GNU APL 1.8
Sun, 23 Jun 2019 20:29:05 +0300

Miсrosoft открыл код системы распределения памяти mimalloc
Sun, 23 Jun 2019 09:15:24 +0300

Инициатива для защиты Linux от патентных претензий преодолела отметку в 3000 участников
Sun, 23 Jun 2019 08:01:16 +0300

Выпуск libhandy 0.0.10, библиотеки для создания мобильных вариантов приложений GTK/GNOME
Sat, 22 Jun 2019 21:02:40 +0300

Valve отказывается от официальной поддержки Steam в Ubuntu 19.10+
Sat, 22 Jun 2019 17:35:07 +0300

Взлом внутренней сети NASA через плату Raspberry Pi
Sat, 22 Jun 2019 10:24:07 +0300

Выпуск Wine 4.11
Sat, 22 Jun 2019 09:00:28 +0300

В OpenSSH добавлена защита от атак по сторонним каналам
Sat, 22 Jun 2019 05:06:15 +0300

Проект VKHR развивает систему рендеринга волос в режиме реального времени
Fri, 21 Jun 2019 20:13:25 +0300

Для Firefox развивается режим блокировки виджетов социальных сетей и Firefox Proxy
Fri, 21 Jun 2019 11:50:12 +0300

Началась работа по переводу GNOME Mutter на многопоточную отрисовку
Fri, 21 Jun 2019 11:09:18 +0300

Открыт код Sorbet, системы статической проверки типов для Ruby
Fri, 21 Jun 2019 10:31:38 +0300

Прекращение поддержки i386 в Ubuntu приведёт к проблемам с поставкой Wine
Fri, 21 Jun 2019 09:02:12 +0300

Percona проведёт открытые семинары в Санкт-Петербурге, Ростове-на-Дону и Москве
Fri, 21 Jun 2019 03:56:43 +0300

Google открыл систему для анализа наборов данных без нарушения конфиденциальности
Thu, 20 Jun 2019 23:09:39 +0300

Обновление PostgreSQL 11.4, 10.9, 9.6.14, 9.5.18 и 9.4.23
Thu, 20 Jun 2019 21:57:10 +0300

В Firefox 67.0.4 и 60.7.2 устранена ещё одна 0-day уязвимость
Thu, 20 Jun 2019 20:53:38 +0300

Выпуск HTTP/TCP-балансировщика HAProxy 2.0
Thu, 20 Jun 2019 12:05:12 +0300

Обновление DNS-сервера BIND 9.14.3, 9.11.8, 9.15.1 с устранением DoS-уязвимости
Thu, 20 Jun 2019 10:02:28 +0300

Релиз минималистичного дистрибутива Alpine Linux 3.10
Thu, 20 Jun 2019 09:47:21 +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-адресом. Если такой запрос не был сделан или в просьбе было отказано, хост не имеет права продолжать использование выданного ранее адреса.

НОВОСТИ: Выпуск libhandy 0.0.10, библиотеки для создания мобильных вариан ... Sat, 22 Jun 2019 21:02:40 +0300

Компания Purism, развивающая смартфон Librem 5 и свободный дистрибутив PureOS, представила выпуск библиотеки libhandy 0.0.10, в рамках которой развивается набор виджетов и объектов для создания интерфейса пользователя для мобильных устройств при помощи GTK и технологий GNOME. Библиотека развивается в процессе портирования приложений GNOME для пользовательского окружения смартфона Librem 5.

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