#1 楼
DHCP无法将TCP用作传输协议，因为TCP要求两个端点都具有唯一的IP地址。在要求主机使用DHCP时，它没有可从其获取数据包的IP地址，也没有DHCP服务器的IP地址。因此，它使用0.0.0.0作为源IP地址，并使用255.255.255.255（广播）作为目标IP地址（这对于DHCP-DHCPv6存在类似行为）。这些IP地址不是有效的主机IP地址，可以随时供多个客户端使用。因此，由于缺少更好的术语，TCP连接不会“唯一”。评论
“必须使用DHCP，它没有IP” –我认为在讨论协议时，最好用地址而不是协议来明确说出“ IP地址”。
–俄罗斯
20年1月8日在18:58
只是要注意，在客户端已经有地址的情况下，有时也会使用DHCP。参见RFC 2131第3.4节。但是它仍然使用广播，因为它不一定知道DHCP服务器的地址。
– jonathanjo
20年1月9日，9：32
@jonathanjo不仅如此。客户端拥有的IP地址可能不再有效。
–Tonny
20年1月9日在16:26
#2 楼
由于源没有IP地址（0.0.0.0），目标是所有人（255.255.255.255），因此很难看到如何标识特定会话。但是即使可以，这样做的好处是什么？ DHCP消息中的数据非常小（〜300字节），因此可以轻松放入单个段中。建立TCP会话不值得花费任何开销。 DHCP就是一个很好的例子。评论
补充一点，这只是UDP的一点。其他用途包括比TCP更可预测的延迟，以及易于使用的广播功能。
– jonathanjo
20年1月8日在10:54
UDP的另一点是媒体流。如果其中一个数据包丢失并到达较晚，则没有必要阻止整个数据流-只需将其丢弃，在数据流中稍许毛刺，然后继续处理下一个数据包即可。
–马丁·邦纳（Martin Bonner）支持莫妮卡（Monica）
20年1月8日在13:08
@MartinBonnersupportsMonica更准确地说，流式传输时的UDP仅对低延迟，实时流才有意义。例如，视频聊天和VoIP这样的用例，对于这些用例，您不能在流前面进行缓冲，与对话保持同步比滞后要好。对于非低延迟，非实时流媒体（例如与Youtube这样的视频流媒体），如果您提前缓冲媒体并在下载无法跟上而不是跳过帧的情况下暂停播放，则可以提供更好的体验。
– Lie Ryan
20年1月8日在13:53
同样，您以“ no ip”开头，然后以新的IP地址结尾。 TCP连接将如何精确切换IP地址？那有可能吗？
–卡塔斯航行
20年1月9日在19:38
#3 楼
TCP无法用于DHCP（v4。）的原因有很多，首先，TCP是面向连接的。在两个特定主机之间定义了TCP连接。但是，当DHCP客户端首次启动时，它不知道要与哪个主机通信。它唯一的选择是向本地网络上的所有主机广播DHCP DISCOVER消息。广播本质上与TCP的面向连接的本质不兼容，因为它不是1：1的关系。由于DHCP本质上是无连接的，因此UDP更有意义。其次，在DHCP进程完成之前，DHCP客户端不会分配IP地址。即使DHCP客户端已经知道要向其请求地址的特定DHCP服务器（通常是不知道）并且知道其IP地址，它也将无法与其建立TCP连接，因为客户端没有尚有IP地址供服务器响应。到客户端确实有分配的IP地址时，DHCP的工作已经完成。
第三，虽然不像上述问题那么重要，但避免TCP也会减少所需的往返次数一个。典型的DHCP交换需要两个往返：DISCOVER（客户端->服务器），OFFER（服务器->客户端），REQUEST（客户端->服务器）和ACK（服务器->客户端）。建立TCP连接将需要在开始时为TCP SYN和SYN-ACK连接建立消息进行一次额外的往返。在三向TCP握手的最终ACK消息之前，无法通过TCP连接发送数据。
评论
以及FIN和ACK的更多往返行程。
–user207421
20年1月7日在22:59
@ user207421好吧，无论如何，要多花一半的往返费用，但是，是的，这很不错。从理论上讲，客户端可以将FIN与DHCPREQUEST一起发送，而服务器可以将FIN-ACK与DHCPACK一起发送，但是客户端仍然需要将最终的ACK发送回服务器以符合要求。
– reirab
20年1月7日在23:07
#4 楼
主机启动时，不知道应使用的网络地址或掩码。它唯一的通信方式是通过IP广播（255.255.255.255）到本地网络。 DHCP客户端在UDP端口67上发起广播请求。该客户端无法使用TCP，因为它没有自己的IP地址，也不知道DHCP服务器地址。DHCP服务器在UDP端口67上侦听广播。接收到dhcp客户端请求后，它将启动使用客户端的MAC地址将配置信息传递到客户端的bootp序列。
为客户端分配IP地址，网关，子网掩码等后，便可以启动或接收TCP连接。
希望有帮助的
#5 楼
只是简单.... dhcp使用广播，但我们在TCP中没有任何广播#6 楼
只需添加将UDP用于DHCP的真正原因（tm）：在为您的应用选择最佳传输协议时，您要权衡简单性
效率
鲁棒性
功能性
与DHCP相比，UDP比DHCP更简单，更强大，更有效，更实用。其他答案已经充分指出，甚至不可能使用TCP-基本上，TCP需要双向连接，并且在获得IP地址之前是不可能的。
#7 楼
UDP不是可靠的协议。对于给定的请求响应，必须在该时间范围内具有时间范围。否则包。被丢弃。当客户端从DHCP服务器请求IP时整个D =发现
O =提供
R =请求
A =确认
这整个过程应完成我们建议的时间表否则数据包将被丢弃。 udp协议如果丢包的话不会在队列中等待。由于此udp功能，它将继续进行，它用于DHCP，dns和语音通信中。
评论
请记住：除非有使用TCP的理由，否则UDP通常比TCP更可取，因为UDP的开销较低。为了简化处理多个数据包的流控制，许多可能传输大量数据（超过一个数据包）的协议都使用TCP。 DNS就像DHCP，因为传统DNS（不涉及DNSSEC密钥等）最常使用UDP，因为整个对话可能在TCP的开销有用之前就结束了。客户端可能不必像接收端报告重新发送TCP数据包的请求那样高效地启动新的DHCP请求（几乎）主要原因有两个：一是DHCP（BOOTP的超集）使用广播流量，因此必须无连接。另一个主要原因（历史性）是因为TCP / IP堆栈不适合网卡上资源受限的ROM环境，而UDP / IP则不适合；这就是TFTP是UDP的原因。
这两个注释都不是实际原因，这是因为TCP需要单播IP，如果您还没有IP地址，则不可能。
同样最重要的是，TCP是可靠，无损的协议，而udp不是。这样就发送了udp数据包，仅此而已，谁知道它会发生什么。如果需要，tcp将重新发送到哪里，并且数据包必须到达。某些应用不需要此功能，例如实时视频等。如果说有些像素丢失得很好，那么演出必须继续进行为时已晚。但是其他诸如银行交易之类的事情很重要，需要重新发送。然后tcp具有优势，因为较低的osi级别可以处理它，甚至是硬件。使其成为无损最快的产品。
@marshalcraft“因为tcp使用单向连接或单向连接的概念。它总是由子网上的客户端启动的。”那简直是不对的。 TCP连接在对等点之间是双向的。 TCP没有客户端或服务器的概念。客户端/服务器概念是一个应用程序概念。在TCP连接上，两端是相等的对等端，可以发送，接收甚至关闭连接。 RFC没有提及客户端或服务器。