我正在备考，发现了这个问题:
A typical UDP server can be implemented using a single socket. Explain why, for a TCP driven server, I find that two sockets are created - one where all clients approach the server, and one specific (socket) for each client for further communication between the server and client.
这是(在我的理解中)由并发问题驱动的(希望不要在联系点地址上与单个客户端进行过多通信)。我知道UDP是无连接的，但是无法在脑海中说明。我看到，如果服务器是 UDP 驱动的，它可以执行单个操作(通过/向套接字/端口重复泵送内容)，然后可以由多个客户端收听。如果服务器可以对两个任务使用react - 获取和放置。客户端如何在不创建连接的情况下发出指令？客户端(在我看来)需要在已知端口上发送 get-request，并在同一端口上获得反馈。这将阻止服务器同时与多个客户端通信的能力。那么创建第二个套接字在双方之间进行通信是否会更好，这样服务器和其他客户端之间的潜在通信就不会受到阻碍？ (与 tcp 的情况一样)
最佳答案
对于 TCP，别无选择，套接字 API 将一个 TCP 连接映射到一个位于两个端点之间的套接字。
对于 UDP，套接字 API 允许一个套接字从多个端点接收，并发送到多个端点 - 因此许多服务器只使用一个套接字，因为不需要更多。
在某些情况下，协议(protocol)是一个简单的请求和回复。无需为此创建另一个套接字 - 只需记下源地址，然后将回复发送到那里 - 这就是一些服务器所做的。
对于其他人来说，该协议(protocol)可能需要更长时间的数据交换，这样创建新套接字会更方便，因此一些服务器会这样做。
This would block the servers ability to communicate with multiple clients at the same time.
不一定。如果服务器 CPU 正忙于执行指令，则无论它是否在同一个套接字上处理多个客户端，它都无法为其他任何人提供服务。如果服务器阻塞调用(例如数据库查询)，或者你想利用多个内核，你可以在多个线程中处理它，或者即使只有 1 个套接字也可以使用线程池模式。服务器只需要跟踪每个数据包的源 IP 地址和端口，以便知道将回复发送到何处。
但是如果使用多个套接字对特定协议(protocol)/应用程序更有意义，例如每个客户一个 - 这样做并没有错，在这种情况下通常的方法是:
- 客户端在其众所周知的端口上向服务器发送数据包
- 服务器记录客户端数据包的源端口
- 服务器创建一个新套接字，在该套接字上发送回复
- 客户注明回复的来源端口
- 客户端使用该端口而不是众所周知的端口与服务器进行进一步通信。
关于sockets - 为什么 UDP 服务器中只有一个套接字？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20165699/