我正在准备考试，发现了这个问题：
可以使用单个套接字来实现典型的 UDP 服务器。解释为什么，对于 TCP 驱动的服务器，我发现创建了两个套接字 - 一个用于所有客户端都接近服务器，一个用于每个客户端的特定（套接字），用于服务器和客户端之间的进一步通信。
这（在我的理解中）是由并发问题驱动的（希望不与接触点地址上的单个客户进行过多沟通）。我知道 UDP 是无连接的，但无法在我的脑海中说明它。我看到如果服务器是 UDP 驱动的，它可以执行单个操作（通过/到套接字/端口重复泵送内容），然后可以由多个客户端监听。如果服务器可以对两个任务做出反应 - 一个 get 和一个 put。客户端如何在不创建连接的情况下发出指令？客户端（在我看来）需要在已知端口上发送获取请求，并在同一端口上获得反馈。这将阻止服务器同时与多个客户端通信的能力。那么创建第二个套接字来在双方之间进行通信会更好，这样服务器和其他客户端之间的潜在通信就不会受到阻碍吗？ （与 tcp 一样）
【问题讨论】：
对于 TCP，没有选择，套接字 API 将一个 TCP 连接映射到一个套接字，它位于两个端点之间。
对于 UDP，套接字 API 允许一个套接字从多个端点接收，并发送到多个端点 - 很多服务器只使用一个套接字，因为不需要更多。
在某些情况下，协议是一个简单的请求和回复。无需为此创建另一个套接字 - 只需记下源地址，然后将回复发送到那里 - 这就是某些服务器所做的。
对于其他人，该协议可能需要更长时间的数据交换，以便更方便地创建新套接字，因此一些服务器会这样做。
这会阻止服务器与多个服务器进行通信 客户同时。
不一定。如果服务器 CPU 忙于执行指令，则无论它是否在同一个套接字上处理多个客户端，它都无法为其他任何人提供服务。如果服务器确实阻塞调用（例如数据库查询），或者您想利用多个内核，您可以在多个线程中处理它，或者即使只有 1 个套接字也可以使用线程池模式。服务器只需要跟踪每个数据包的源 IP 地址和端口，以便知道将回复发送到哪里。
但如果特定协议/应用程序使用多个套接字更有意义，例如每个客户一个 - 这样做有问题，在这种情况下通常的方法是：
【讨论】：
客户端（在我看来）需要在已知端口上发送 get-request，并在同一端口上获得反馈。这将阻止服务器同时与多个客户端通信的能力。
不，它不会。这是虚构的。
那么创建第二个套接字来在双方之间进行通信会不会更好，这样服务器和其他客户端之间的潜在通信就不会受到阻碍？ （与 tcp 一样）
“服务器和其他客户端之间的潜在通信”无论如何都不会受到“阻碍”。
创建第二个套接字没有任何好处，API 也没有强制要求。并且您对客户端向同一个远程端口发送和接收的正确愿望与您在服务器上创建第二个套接字的愿望相矛盾。第二个套接字会有不同的端口。
【讨论】：