Existem 4 etapas no DHCP: Descobrir, Oferecer, Solicitar e Reconhecer.
Por que a terceira etapa é chamada de “Solicitação”? Ninguém está solicitando nada nesta etapa, não é?
O cliente está simplesmente dizendo que aceitará o IP fornecido pelo servidor DHCP.
Onde está a parte “solicitação” nesta etapa?
Responder1
Sim, algo está sendo solicitado.
Você pode ler a conversa assim:
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
Há muito mais do que isso, mas essencialmente este é o processo. Faz sentido quando você considera a coberturapoderiavá assim:
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."
Nesse caso, há três servidores DHCP que ouviram o pacote de descoberta e todos os três responderam com uma oferta. O cliente “selecionou” a primeira oferta que recebeu e respondeu com uma solicitação ao Servidor1, que atendeu porque o endereço estava dentro do seu escopo e estava disponível.
Server2 e Server3 nunca receberam uma solicitação, portanto não alocam os IPs que ofereceram, tornando-os ainda disponíveis. Se você não tivesse a etapa de solicitação extra, um cliente teria esgotado três endereços IP em vez de apenas um.
Responder2
O cliente ainda não possui locação e está solicitando, por isso é chamado de “Solicitação”. Ele solicita que um arrendamento seja emitido, verificado ou prorrogado.
Responder3
O terceiro passo é “Eu (cliente) gostaria de usar esse ip seu (servidor)”. Como a próxima etapa é o servidor ACKnowledges ou NotAcKnowleges, pareceria bobagem que o servidor tivesse que reconhecer uma aceitação.
Responder4
Eu realmente gostoA resposta de Wes Sayeed. Vários servidores DHCP podem ser um dos motivos pelos quais a solicitação é útil.
Aqui está outro motivo: tentar reutilizar o mesmo endereço de antes.
A solicitação é uma solicitação de permissão para usar o endereço. A descoberta, oferta, solicitação e reconhecimento às vezes é chamada de DORA.
#1: DESCOBRIR: O cliente solicita à rede (via mensagem de difusão) um servidor DHCP
#2: OFERTA: O servidor DHCP responde e fornece um endereço potencial
#3: PEDIDO: A máquina/dispositivo do usuário final envia uma solicitação ao servidor, solicitando que o servidor DHCP aloque/reserve/use o endereço solicitado para esse dispositivo
#4: ACKnowledge: Se a resposta for um ACKnowledge, não um NACK (reconhecimento negativo), então a solicitação é considerada concedida.
Aqui está a parte complicada: a solicitação não precisa corresponder à oferta.
Por exemplo: se um laptop ficou fora da rede por um tempo e depois tentou se conectar (à mesma rede ou a uma rede diferente), o laptop pode querer usar o mesmo endereço, se possível. Aqui está um exemplo de conversa inventada:
#1: DISCOVER: 0.0.0.0 pergunta 255.255.255.255: "Posso oferecer um endereço e saber quem você é?" O endereço da Camada 2 envia do endereço MAC-48 do dispositivo para FF-FF-FF-FF-FF-FF (transmissão).
#2: OFERTA: 192.168.0.10 diz: "Sou um servidor DHCP. Que tal usar 192.168.0.235?" Isso é enviado de volta ao endereço IP 0.0.0.0 e enviado ao endereço MAC-48 do cliente DHCP.
#3: PEDIDO: 0.0.0.0 diz para 192.168.0.10: "Posso ter 192.168.0.117?" (Por exemplo, o laptop usava 192.168.0.117 antes.)
#4: NACK: 192.168.0.10 responde: "Não." (Talvez outro sistema esteja usando isso agora.)
#5: Laptop desiste de poder continuar usando o endereço que queria.
#6: (Talvez depois de outro DISCOVER e OFFER?) O cliente DHCP faz outro REQUEST. Então, usando números já mostrados neste exemplo, 0.0.0.0 diz para 192.168.0.10: "Que tal me deixar ficar com 192.168.0.235?"
#6: ACK: O servidor DHCP diz: "Ok. 192.168.0.235 está reservado para você, pelas próximas 8 horas. Certifique-se de solicitar uma renovação antes desse horário se quiser continuar tendo esse endereço reservado. Caso contrário, posso divulgar esse endereço para outra pessoa."
Isso demonstra outro benefício que temos, graças à etapa REQUEST.
Agora, como REQUEST faz parte do design, a etapa é realmente uma parte obrigatória da conversação eletrônica.
O DESCOBRIR e OFERTAR e basicamente conversas sobre planejamento. O PEDIDO é a tentativa real de obter um compromisso. Nada é realmente confirmado até que o ACK seja feito. Um servidor DHCP poderia OFERECER legitimamente o mesmo endereço para várias máquinas, desde que apenas RECONHEÇA a atribuição do endereço a apenas uma máquina. (Não estou dizendo que haveria um bom motivo para um servidor DHCP fazer isso. Só estou dizendo que o protocolo/padrão permitiria isso sem causar conflitos de endereço IP.) O cliente não tem permissão para usar o endereço até obter o ACKnowledgement, que só vem após o REQUEST. Um servidor DHCP não se preocuparia em enviar uma confirmação antes de uma PEDIDO, porque o cliente DHCP típico não estaria pronto para a confirmação até depois de enviar a PEDIDO, de modo que o cliente DHCP típico ignoraria e perderia a confirmação inesperada.