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