套接字編程 - listen() 和 accept() 之間有什么區別？

Question

我一直在閱讀本教程以了解套接字編程。 似乎listen()和accept()系統調用都做同樣的事情，即阻塞並等待客戶端連接到使用socket()系統調用創建的socket() 。 為什么你需要兩個單獨的步驟呢？ 為什么不只使用一個系統調用？

順便說一句，我在谷歌上搜索了這個問題並發現了類似的問題，但沒有一個答案令人滿意。 例如，其中一個說accept()創建套接字，這沒有意義，因為我知道套接字是由socket()創建的。

Answer 1

這是歷史建築的一部分。 listen為下一個accept電話准備套接字。 Listen還允許人們設置積壓 - 系統將接受的連接數，而不是讓你的程序真正接受它們。 積壓完成之后的所有內容都會被系統立即拒絕。 listen never塊，而accept將阻塞（除非套接字處於非阻塞模式），直到下一個連接出現。 顯然，這並不一定是兩個獨立的功能-可以想象， accept()函數可以做一切listen呢。

Answer 2

listen()函數基本上在內部套接字結構中設置一個標志，將套接字標記為被動偵聽套接字，可以調用accept 。 它打開綁定端口，以便套接字可以開始接收來自客戶端的連接。

accept()函數要求偵聽套接字接受下一個傳入連接並返回該連接的套接字描述符。 因此，從某種意義上說， accept() 確實創建了一個套接字，而不是用於listen()傳入連接的套接字listen() 。

Answer 3

以上兩個答案清楚地說明了接受和傾聽之間的區別。 回答你的另一個問題 - 為什么我們需要兩個獨立的功能？

一個用例是，例如，如果您只想測試一個端口是否仍然可用/可訪問，您只需要監聽端口然后關閉它而不接受任何連接即可。

例如https://github.com/coolaj86/golang-test-port使用listen調用來測試端口的可用性。

Answer 4

listen()使用backlog 參數指定排隊連接的最大數量，並且應該至少為 0。它的值隨着服務器同時接收大量連接請求而增加。

accept()等待傳入的連接。 當客戶端連接時，它返回一個表示連接的新套接字對象。

另一個需要注意的重要事項是accept()創建一個新的套接字對象，該對象將用於與客戶端進行通信。 它不同於服務器用來接受新連接的偵聽套接字。

應用程序和 TCP/IP 套接字接口之間的每個連接允許的最大套接字數為 65535。