为什么 DHCP 客户端监听 68 端口？
如果假设客户端没有监听 68 端口，当 DHCP 服务器收到请求时，它可以将其发送到接收请求的地址（客户端在发送时选择临时端口），那么为什么协议指定客户端为监听 68 端口？
If suppose client does not listen on 68 port,when DHCP server receives the request, it can send it to the address from where it received request (with ephemeral port chosen by client at time of sending), then why does protocol specifies client to be listening on port 68?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
主要原因是 DHCP 服务器可能会在 MAC 级别广播“DHCP Offer”，而不是将其单播发送到收到请求的 MAC 地址。
如果端口不是恒定的，一些偶然侦听同一随机端口的主机将接受数据包到第 5 层（应用程序层）。
换句话说，应用程序将从完全不同的应用程序获取消息，这不是一个健康的情况。
The main reason is that the DHCP server might broadcast the "DHCP offer" on the mac level, instead of sending it unicast to the mac address it had received the request.
If the port wasn't constant, some hosts that are listening by chance to the this same random port, will accept the packet to layer 5 - the application layer.
In other words, an application will get message from completely different application, not an healthy situation.
我自己也不得不面对同样的问题，经过一番研究，我在 RFC 上发现了以下内容2131，它描述了 DHCP 协议，第 1.6 节设计目标：
也位于 RFC 951，其中描述了 BOOTP 协议，我们可以找到以下内容：
UDP 标头包含源端口号和目标端口号。这
BOOTP 协议使用两个保留端口号，“BOOTP 客户端”(68)
和“BOOTP 服务器”(67)。客户端使用“BOOTP”发送请求
server' 作为目的端口；这通常是广播。这
服务器使用“BOOTP客户端”作为目标端口发送回复；
根据服务器中的内核或驱动程序设施，这可能
或者可能不是广播（这将在本节中进一步解释）
标题为“先有鸡还是先有蛋的问题”）。原因 两个保留端口
使用，是为了避免“唤醒”和调度 BOOTP 服务器
守护进程，当引导回复必须广播到客户端时。自从
服务器和其他主机不会侦听“BOOTP客户端”端口，
任何此类传入的广播都将在内核中被过滤掉
等级。我们不能简单地允许客户端选择“随机”端口
UDP 源端口字段的编号；因为服务器回复可能是
广播，随机选择的端口号可能会迷惑其他主机
碰巧正在监听该端口。
所以问题的答案来自上面。 DHCP 客户端需要使用 UDP 端口 68，以便 DHCP 与 BOOTP 协议兼容，并且 BOOTP 协议需要客户端使用特定端口，因为 BOOTPREPLIES 可以广播，并且如果为客户端选择随机端口，这可能会导致其他主机在同一端口上侦听的混乱。
I just had to face the same question myself, and after some research, I found the following on the RFC 2131, which describes the DHCP protocol, under section 1.6 Design Goals:
Also on the RFC 951, which describe the BOOTP protocol, we can find the following:
The UDP header contains source and destination port numbers. The
BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
and 'BOOTP server' (67). The client sends requests using 'BOOTP
server' as the destination port; this is usually a broadcast. The
server sends replies using 'BOOTP client' as the destination port;
depending on the kernel or driver facilities in the server, this may
or may not be a broadcast (this is explained further in the section
titled 'Chicken/Egg issues' below). The reason TWO reserved ports
are used, is to avoid 'waking up' and scheduling the BOOTP server
daemons, when a bootreply must be broadcast to a client. Since the
server and other hosts won't be listening on the 'BOOTP client' port,
any such incoming broadcasts will be filtered out at the kernel
level. We could not simply allow the client to pick a 'random' port
number for the UDP source port field; since the server reply may be
broadcast, a randomly chosen port number could confuse other hosts
that happened to be listening on that port.
So the answer to the question comes from the above. DHCP clients need to use the UDP port 68, in order for the DHCP to be compatible with the BOOTP protocol and the BOOTP protocol requires a specific port for the client, since BOOTPREPLIES can be broadcasted, and if a random port was chosen for the client, it could result in the confusion of other hosts listening on the same port.
因为它在 RFC（征求意见）中指定了 DHCP 的行为方式。 RFC 2131 是指定 DHCP 客户端和服务器必须如何运行的文档。
有关 DHCP 的详细信息，请参阅此处（特别是第 4.1 节）。有关 RFC 的信息，请参阅此处。
Because it's in the RFC (Request for Comments) that specifies how DHCP behaves. RFC 2131 is the document that specifies how a DHCP client and server must behave.
See here for more info on DHCP (section 4.1 in particular). See here for info on what the RFCs are.