☰

Почему DHCP-запрос называется запросом?

tag-icon • tag-icon networking dhcp
Почему DHCP-запрос называется запросом?

В DHCP есть 4 шага: обнаружение, предложение, запрос и подтверждение.

Почему третий шаг называется "Запрос"? На этом шаге никто ничего не запрашивает, да?

Клиент просто говорит, что он примет IP-адрес, предоставленный DHCP-сервером.

Где на этом этапе находится часть «запрос»?

решение1

Да, что-то запрашивается.

Вы можете прочитать этот разговор следующим образом:

Computer:  "I need an IP address!"          <-- This is the discover
Server:    "I have 10.11.12.13 available."  <-- This is the offer
Computer:  "May I have have 10.11.12.13?"   <-- This is the request
Server:    "Yes, you may."                  <-- This is the ack

Это гораздо больше, чем это, но по сути это процесс. Это имеет смысл, когда вы рассматриваете coverationмогвыглядит так:

Computer:  "I need an IP address!"
Server1:   "I have 10.11.12.13 available."
Server2:   "I have 10.11.12.19 available."
Server3:   "I have 10.12.1.2 available."
Computer:  "May I have 10.11.12.13?"
Server1:   "Yes, you may."

В этом случае есть три DHCP-сервера, которые все услышали пакет обнаружения, и все три ответили предложением. Клиент «выбрал» первое полученное предложение и ответил запросом на Server1, который он предоставил, поскольку адрес был в его области действия и был доступен.

Server2 и Server3 никогда не получали запрос, поэтому они не выделяют IP-адреса, которые они предлагали, делая их доступными. Если бы у вас не было дополнительного шага запроса, один клиент исчерпал бы 3 IP-адреса вместо одного.

решение2

У клиента еще нет договора аренды, и он запрашивает его, поэтому это называется «Запрос». Он запрашивает выдачу, проверку или продление договора аренды.

решение3

Третий шаг: «Я (клиент) хотел бы использовать этот IP от вас (сервера)». Поскольку следующим шагом является подтверждение или неподтверждение сервером, то было бы глупо, что сервер должен подтвердить или принять.

решение4

мне действительно нравитсяОтвет Уэса Саида. Несколько DHCP-серверов могут быть одной из причин, по которой запрос полезен.

Вот еще одна причина: попытка повторно использовать тот же адрес, что и раньше.

Запрос представляет собой запрос на разрешение использовать адрес. Discover, Offer, Request, Acknowledgement иногда называют DORA.

#1: ОБНАРУЖЕНИЕ: Клиент запрашивает у сети (через широковещательное сообщение) сервер DHCP.

#2: ПРЕДЛОЖЕНИЕ: DHCP-сервер отвечает и предоставляет потенциальный адрес

#3: ЗАПРОС: Конечный пользователь отправляет запрос на сервер, требуя, чтобы DHCP-сервер выделил/зарезервировал/использовал запрошенный адрес для этого устройства.

#4: ACKnowledge: Если ответом является ACKnowledge, а не NACK (отрицательное подтверждение), то запрос считается удовлетворенным.

А вот тут-то и возникает сложность: запрос не обязательно должен соответствовать предложению.

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

#1: ОБНАРУЖЕНИЕ: 0.0.0.0 спрашивает 255.255.255.255: «Могу ли я получить адрес и узнать, кто вы?» Адрес уровня 2 отправляется с адреса MAC-48 устройства на FF-FF-FF-FF-FF-FF (широковещательный).

#2: ПРЕДЛОЖЕНИЕ: 192.168.0.10 говорит: «Я DHCP-сервер. Как насчет использования 192.168.0.235?» Это отправляется обратно на IP-адрес 0.0.0.0 и отправляется на MAC-48-адрес DHCP-клиента.

#3: ЗАПРОС: 0.0.0.0 говорит 192.168.0.10: «Могу ли я получить 192.168.0.117?» (Например, раньше ноутбук использовал 192.168.0.117.)

#4: NACK: 192.168.0.10 отвечает: «Нет» (Возможно, сейчас его использует другая система.)

#5: Ноутбук отказывается продолжать использовать желаемый адрес.

#6: (Возможно, после еще одного DISCOVER и OFFER?) Клиент DHCP делает еще один ЗАПРОС. Итак, используя числа, уже показанные в этом примере, 0.0.0.0 говорит 192.168.0.10: "Как насчет того, чтобы дать мне 192.168.0.235?"

#6: ACK: DHCP-сервер говорит: «Хорошо. 192.168.0.235 зарезервирован для вас на следующие 8 часов. Обязательно запросите продление до этого времени, если вы хотите, чтобы этот адрес оставался зарезервированным. В противном случае я могу передать этот адрес кому-то другому».

Итак, это демонстрирует еще одно преимущество, которое мы получаем благодаря шагу ЗАПРОС.

Теперь, поскольку ЗАПРОС является частью дизайна, этот шаг действительно является обязательной частью электронного разговора.

DISCOVER и OFFER и, в основном, разговоры о планировании. REQUEST — это фактическая попытка получить обязательство. Фактически ничего не зафиксировано, пока не будет сделано ACK. DHCP-сервер может законно ПРЕДЛОЖИТЬ один и тот же адрес нескольким машинам, пока он ACKnowledges только на назначение адреса только одной машине. (Я не говорю, что была бы веская причина для DHCP-сервера делать это. Я просто говорю, что протокол/стандарт допускает это, не вызывая конфликтов IP-адресов.) Клиенту не разрешено использовать адрес, пока он не получит ACKnowledgement, который приходит только после REQUEST. DHCP-сервер не будет беспокоиться об отправке ACKnowledgement перед REQUEST, потому что типичный DHCP-клиент не будет готов к ACKnowledgement, пока не отправит REQUEST, поэтому типичный DHCP-клиент проигнорирует и пропустит неожиданное ACKnowledgement.

Связанный контент