UDP标头包含源和目标端口号 . BOOTP协议使用两个保留端口号，'BOOTP client'（68）和'BOOTP server'（67） . 客户端使用'BOOTP server'作为目标端口发送请求;这通常是广播 . 服务器使用'BOOTP client'作为目标端口发送回复;根据服务器中的内核或驱动程序设施，这可能是也可能不是广播（这将在下面 Headers 为'Chicken/Egg issues'的部分中进一步解释） . 使用TWO保留端口的原因是，当必须向客户端广播bootreply时，应避免'waking up'并调度BOOTP服务器守护进程 . 由于服务器和其他主机为UDP源端口字段赢得了't be listening on the ' BOOTP客户端' port, any such incoming broadcasts will be filtered out at the kernel level. We could not simply allow the client to pick a '随机'端口号;由于服务器回复可能是广播的，因此随机选择的端口号可能会混淆恰好正在该端口上侦听的其他主机 .
3 回答
因为它在RFC（Request for Comments）中指定了DHCP的行为方式 . RFC 2131是指定DHCP客户端和服务器必须如何运行的文档 .
有关DHCP的更多信息，请参阅here（特别是4.1节） . 有关RFC的信息，请参见here .
主要原因是DHCP服务器可能在mac级别上广播“DHCP offer”，而不是将其单播发送到它收到请求的mac地址 . 如果端口不是常量，那么一些正在侦听同一随机端口的主机将接受数据包到第5层 - 应用层 . 换句话说，应用程序将从完全不同的应用程序获取消息，而不是 Health 的情况 .
我自己不得不面对同样的问题，经过一些研究，我在RFC 2131上找到了以下内容，它描述了DHCP协议，在1.6设计目标下：
同样在描述BOOTP协议的RFC 951上，我们可以找到以下内容：
UDP标头包含源和目标端口号 . BOOTP协议使用两个保留端口号，'BOOTP client'（68）和'BOOTP server'（67） . 客户端使用'BOOTP server'作为目标端口发送请求;这通常是广播 . 服务器使用'BOOTP client'作为目标端口发送回复;根据服务器中的内核或驱动程序设施，这可能是也可能不是广播（这将在下面 Headers 为'Chicken/Egg issues'的部分中进一步解释） . 使用TWO保留端口的原因是，当必须向客户端广播bootreply时，应避免'waking up'并调度BOOTP服务器守护进程 . 由于服务器和其他主机为UDP源端口字段赢得了't be listening on the ' BOOTP客户端' port, any such incoming broadcasts will be filtered out at the kernel level. We could not simply allow the client to pick a '随机'端口号;由于服务器回复可能是广播的，因此随机选择的端口号可能会混淆恰好正在该端口上侦听的其他主机 .
所以问题的答案来自上述问题 . DHCP客户端需要使用UDP端口68，以使DHCP与BOOTP协议兼容，并且BOOTP协议需要客户端的特定端口，因为BOOTPREPLIES可以被广播，并且如果为客户端选择了随机端口，它可能导致在同一端口上侦听的其他主机混淆 .