DHCP에는 검색, 제안, 요청 및 승인의 4단계가 있습니다.
세 번째 단계를 '요청'이라고 부르는 이유는 무엇인가요? 이 단계에서는 아무도 요구하지 않죠?
클라이언트는 단순히 DHCP 서버가 제공한 IP를 수락하겠다고 말합니다.
이 단계에서 "요청" 부분은 어디에 있나요?
답변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
이것보다 훨씬 더 많은 것들이 있지만 본질적으로 이것이 프로세스입니다. 커버리지를 고려하면 이해가 됩니다.~할 수 있었다이렇게 가세요:
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."
이 경우 검색 패킷을 모두 수신한 3개의 DHCP 서버가 있으며 3개 모두 제안으로 응답했습니다. 클라이언트는 받은 첫 번째 제안을 "선택"하고 Server1에 대한 요청으로 응답했는데, 주소가 해당 범위 내에 있고 사용 가능했기 때문에 승인되었습니다.
Server2와 Server3은 요청을 받지 못했기 때문에 제공한 IP를 할당하지 않아 계속 사용할 수 있습니다. 추가 요청 단계가 없었다면 한 클라이언트가 IP 주소 1개가 아닌 3개를 고갈했을 것입니다.
답변2
클라이언트는 아직 임대가 없고 임대를 요청하고 있으므로 이를 "요청"이라고 합니다. 임대가 발행, 확인 또는 연장되도록 요청합니다.
답변3
세 번째 단계는 "나(클라이언트)가 귀하(서버)의 IP를 사용하고 싶습니다"입니다. 다음 단계는 서버가 이를 승인하거나 NotAcKnowleges하는 것이므로 서버가 승인을 승인해야 한다는 것은 어리석게 들릴 것입니다.
답변4
나는 정말 좋아한다웨스 사이드의 답변. 여러 DHCP 서버가 요청이 유용한 이유 중 하나일 수 있습니다.
또 다른 이유는 이전과 동일한 주소를 다시 사용하려는 것입니다.
요청은 주소 사용 권한을 요청하는 것입니다. Discover, Offer, Request, Acknowledgement를 DORA라고도 합니다.
#1: DISCOVER: 클라이언트가 브로드캐스트 메시지를 통해 네트워크에 DHCP 서버를 요청합니다.
#2: OFFER: DHCP 서버가 응답하고 잠재적인 주소를 제공합니다.
#3: REQUEST: 최종 사용자 기계/장치는 DHCP 서버가 해당 장치에 대해 요청된 주소를 할당/예약/사용하도록 요청하는 요청을 서버에 보냅니다.
#4: ACKnowledge: 응답이 NACK(부정 승인)가 아닌 ACKnowledge인 경우 요청이 승인된 것으로 간주됩니다.
까다로운 부분은 다음과 같습니다. 요청이 제안과 일치할 필요는 없습니다.
예: 랩톱이 한동안 네트워크 외부에 있다가 연결(동일한 네트워크 또는 다른 네트워크에)을 시도하는 경우 랩톱은 가능하면 동일한 주소를 사용하려고 할 수 있습니다. 다음은 구성된 대화의 샘플입니다.
#1: DISCOVER: 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으로 다시 전송되어 DHCP 클라이언트의 MAC-48 주소로 전송됩니다.
#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시간 동안 예약되어 있습니다. 해당 주소를 계속 예약하려면 해당 시간 전에 갱신을 요청하세요. 그렇지 않으면 포기할 수도 있습니다." 그 주소를 다른 사람한테 보내줘."
이는 REQUEST 단계 덕분에 우리가 얻을 수 있는 또 다른 이점을 보여줍니다.
이제 REQUEST는 디자인의 일부이기 때문에 해당 단계는 실제로 전자 대화의 필수 부분입니다.
DISCOVER 및 OFFER는 기본적으로 계획에 대한 대화입니다. REQUEST는 약속을 얻기 위한 실제 시도입니다. ACK가 만들어질 때까지는 실제로 아무 것도 커밋되지 않습니다. DHCP 서버는 하나의 시스템에 대한 주소 할당만 승인하는 한 여러 시스템에 동일한 주소를 합법적으로 제공할 수 있습니다. (DHCP 서버가 그렇게 하는 타당한 이유가 있을 것이라고 말하는 것이 아닙니다. 단지 프로토콜/표준이 IP 주소 충돌을 일으키지 않고 이를 허용한다는 것을 말하는 것입니다.) 클라이언트는 다음을 사용할 수 없습니다. REQUEST 다음에 오는 승인을 받을 때까지 주소를 지정합니다. 일반적인 DHCP 클라이언트는 REQUEST를 보낸 후까지 승인을 받을 준비가 되어 있지 않기 때문에 DHCP 서버는 REQUEST 전에 승인을 보내지 않습니다. 따라서 일반적인 DHCP 클라이언트는 예기치 않은 승인을 무시하고 놓칠 수 있습니다.