當listen()是TCP中第一個涉及的時候，為什么accept()會阻塞？

Question

accept()阻塞，直到建立另一個連接並且返回 sockfd 可以通信雙方。 但是為什么accept()會阻塞，當第一件事要做的是三次握手時。 握手不是由accept()完成的，而是由listen()完成的。 所以我希望listen()塊而不是accept() ，因為它首先涉及 TCP。 我知道 kernel 對傳入連接進行了一些排隊，但仍然涉及的第一個 function 是listen() ，然后連接在隊列中向前移動到accept() 。 因此，當我進行第一次連接時， listen()將執行 3whs，並且服務器在accpet()中阻塞。 所以另一個連接不能再做 3whs，因為服務器沒有 go返回到listen() ，3whs 是哪個？ 或者為什么accept()阻塞而不是listen() ？

Answer 1

listen()和accept()是兩個完全不同的操作。 您對它們如何工作的理解是不正確的。

listen()只是設置監聽套接字的 backlog 並打開綁定端口，因此客戶端可以開始連接到套接字。 那個打開是一個非常快速的操作，不用擔心它會被阻塞。

listen()不執行 3 次握手。 它由 kernel 在客戶端嘗試連接到打開的端口並被放入偵聽套接字的積壓中時執行。 每個新的客戶端連接都執行自己的 3 次握手。

一旦客戶端連接完全握手，該連接就可供accept()從積壓中提取。 只有當新的客戶端連接可用於后續通信時，accept( accept()才會阻塞（或者，如果您使用非阻塞偵聽套接字， accept()會成功）。

您只調用了 1 次listen()來打開監聽端口，這就是它所做的一切。 然后，您必須為要與之通信的每個客戶端調用accept() 。 這就是為什么accept()會阻塞而listen()不會。