☰

TCP_DEFER_ACCEPT 的實際使用？

tag-icon • tag-icon linux networking tcp webserver
TCP_DEFER_ACCEPT 的實際使用？

我正在閱讀Apache httpd 線上手冊並遇到了啟用此功能的指令。在手冊頁中找到了以下描述tcp：

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

然後我發現本文但我仍然不清楚這對什麼樣的工作負載有用。我假設如果httpd有一個專門用於此目的的選項，它一定與網頁伺服器有一定的相關性。我還假設它是一個選項，而不僅僅是httpd網路連接，在某些用例中您需要它，而在其他用例中您不需要它。

即使讀完這篇文章後，我也不清楚等待三向握手完成有什麼好處。確保httpd在握手仍在進行時不需要交換相關實例似乎是有利的，而不是在連接形成後可能導致延遲。

對於本文，在我看來，無論TCP_DEFER_ACCEPT套接字的狀態如何，您仍然需要四個資料包（每種情況下握手然後資料）。我不知道他們如何將倒數減至三，也不知道這如何提供有意義的增強。

所以我的問題基本上是：這只是一個過時的選項還是這個選項有實際用例？

答案1

（總結我對OP的評論）

他們所指的三向握手是 TCP 連線建立的一部分，所討論的選項與此沒有具體關係。另請注意，資料交換不是三向握手的一部分，這只是在開啟/已建立狀態下建立 TCP 連線。

關於此選項的存在，這不是套接字的傳統行為，通常套接字處理程序的線程在連接被接受時被喚醒（這仍然是在三次握手完成之後），並且對於某些協議活動從這裡開始（例如，SMTP 伺服器會傳送220 問候語行），但對於HTTP，會話中的第一則訊息是Web 瀏覽器會傳送其GET/POST/etc 行，在這種情況發生之前，HTTP 伺服器對連線不感興趣（除了計時） ），因此當套接字接受完成時喚醒 HTTP 進程是一種浪費的活動，因為該進程將立即再次進入休眠狀態以等待必要的資料。

雖然肯定有人認為喚醒空閒進程可以使它們“準備好”進行進一步處理（我特別記得喚醒非常舊的機器上的登錄終端並讓它們從交換中突突突進），但您也可以爭辯說，任何具有交換出的進程已經對其資源提出了要求，並且進一步提出不必要的要求可能會總體降低系統性能- 即使您的單個線程的明顯性能有所提高（也可能不會，一台非常繁忙的機器將在磁碟IO 上出現瓶頸，這將導致如果你換入，會減慢其他事情的速度，如果它那麼忙，立即睡眠可能會立即將其換入）。這似乎是一場賭博，最終“貪婪”的賭博不一定會在繁忙的機器上得到回報，並且肯定會在已經交換了進程的機器上造成額外不必要的工作- 您的方法針對具有以下功能的機器進行了優化大部分處於休眠狀態的大內存進程集，將一個休眠狀態交換為另一個休眠狀態並不是什麼大問題，但是具有大內存活動進程集的機器將遭受額外的IO 影響，並且任何不受記憶體限制的機器都會受到影響，任何受 CPU 限制的機器都會變得更糟。

對於這種程度的效能調整，我的一般建議是不要做出關於什麼是最好的程序性決策，而是允許系統管理員和作業系統一起工作來處理資源管理問題- 這是他們的工作，他們的職責很多。提供選項和配置選擇。

為了具體回答這個問題，該選項對所有配置都是有利的，除了在HTTP 流量的極端負載下之外，它不會達到您可能注意到的水平，但從理論上講，這是「正確」的方法。這是一個選項，因為並非所有 Unix（甚至不是所有 Linux）風格都具有該功能，因此為了可移植性，可以將其配置為不包含。

答案2

我不清楚等待三次握手完成有什麼好處。

三向握手是語音電話中常見的協議：

  1. 伺服器：“下午好，Epiphyte Corp。”
  2. 呼叫者：“你好，我是蘭迪。”
  3. 伺服器：“是的，需要什麼幫助嗎？”
  4. 呼叫者:通話內文開始請求笑話

它們在 TCP 中對於確保通道的建立非常重要。如果客戶端開始發送通話內文在聽到 (3) 之前，伺服器可能尚未偵聽或尚未準備好。聽證會（3）並不能保證伺服器在傳輸後不會立即自燃，但它確實增加了伺服器已準備好接收的信心。

如中所述維基百科上關於握手的內容:

  1. Alice [伺服器] 使用確認號碼 y + 1 的確認訊息進行回复，Bob [客戶端] 收到該訊息並將其發送給他不需要回复。

因此，如果您願意放棄伺服器已準備就緒的一點額外確定性，則伺服器可以跳過步驟（3），並且客戶端將假設伺服器已準備就緒。這將上面的協定交換變成：

  1. 伺服器：“下午好，Epiphyte Corp。”
  2. 呼叫者：“你好，我是蘭迪。”
  3. 呼叫者：“你知道關於伊梅爾達·馬科斯的笑話嗎？”

相關內容