我正在爲我的考試學習，發現這個問題 - 非典型的UDP服務器可以使用一個套接字來實現。解釋爲什麼。對於TCP驅動的服務器，我發現創建了兩個套接字 - 一個是所有客戶端接近服務器的套接字，另一個是每個客戶端的特定（套接字），用於服務器和客戶端之間的進一步通信。這是（在我的理解中）由併發問題驅動的（希望不要與接觸點地址上的單個客戶端進行太多的通信）。我知道UDP是無連接的，但在我的腦海中無法說明它。我發現如果一個服務器是UDP驅動的，它可以執行一個動作（通過一個套接字/端口反覆抽取一個內容），然後可以由多個客戶端監聽。如果服務器可以對兩個任務作出反應 - get和put。客戶如何在不建立連接的情況下發出指令？客戶端（在我看來）需要在已知端口上發送獲取請求，並在同一端口獲得反饋。這會阻止服務器同時與多個客戶端通信的能力。那麼創建第二個套接字在雙方之間進行通信會更好嗎，以便服務器和其他客戶端之間的潛在通信不受阻礙？ （如tcp的情況）爲什麼UDP服務器中有一個套接字？
對於TCP，沒有選擇，套接字API將一個TCP連接映射到兩個端點之間的一個套接字。
對於UDP，套接字API允許一個套接字從多個端點接收，併發送到許多端點 - 很多服務器只使用一個套接字，因爲不需要更多。
在某些情況下，協議是一個簡單的請求和答覆。沒有必要爲此創建另一個套接字 - 只需記下源地址，並在那裏發送回覆 - 這就是某些服務器所做的。
對於其他人，協議可能需要更長時間的數據交換，因爲創建新套接字更方便，所以有些服務器會這樣做。
這會阻止服務器同時與多個客戶端進行通信的能力。
不一定。如果服務器CPU忙於執行指令，則不管它是否處理同一套接口上的多個客戶端，都無法爲其他人服務。如果服務器阻塞呼叫（例如數據庫查詢），或者您想利用多個核心，則可以在多個線程中處理該呼叫，或者即使只使用一個套接字也可以使用線程池模式。服務器只需要跟蹤每個數據包的源IP地址和端口，以便知道將回復發送到哪裏。但是，如果特定的協議/應用使用多個套接字更有意義，例如，每個客戶端一個 - 有注意到錯這樣做，在這種情況下，通常的做法是：
客戶端（在我心中）需要發送一個已知端口上的GET請求，並得到相同的端口上的反饋。這會阻止服務器同時與多個客戶端通信的能力。
不，它不會。這是虛構的。
那麼創建第二個套接字在雙方之間進行通信以便服務器和其他客戶端之間的潛在通信不受阻礙會更好嗎？ （如tcp的情況下）
無論如何，'服務器和其他客戶之間的潛在溝通'並不是'阻礙'的。
創建第二個套接字沒有任何優勢，並且它沒有被API強制執行。而且，您希望客戶端發送和接收來自同一個遠程端口的請求與您希望在服務器上創建第二個套接字的願望相矛盾。第二個插座會有不同的端口。