Linux

TCP_DEFER_ACCEPT 的實際使用?

  • April 7, 2014

我正在線上閱讀 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有一個專門用於此的選項,它必須與 Web 伺服器有一定的相關性。我還假設它是一個選項,而不僅僅是httpd網路連接的方式,還有一些你想要它的案例和其他你不想要的案例。

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

對於這篇文章,在我看來,無論TCP_DEFER_ACCEPT套接字的狀態如何,您仍然需要四個數據包(在每種情況下握手然後數據)。我不知道他們如何將計數減至三,也不知道這如何提供有意義的增強。

所以我的問題基本上是:這只是一個過時的選項還是這個選項有實際的案例?

(總結我對 OP 的評論)

他們所指的三次握手是 TCP 連接建立的一部分,所討論的選項與此無關。另請注意,數據交換不是三向握手的一部分,這只是在打開/建立狀態下創建 TCP 連接。

關於這個選項的存在,這不是套接字的傳統行為,通常套接字處理程序的執行緒在連接被接受時被喚醒(這仍然是在三向握手完成之後),並且對於某些協議活動從這裡開始(例如,SMTP 伺服器發送 220 問候行),但對於 HTTP,會話中的第一條消息是 Web 瀏覽器發送其 GET/POST/etc 行,在此之前,HTTP 伺服器對連接不感興趣(除了時間它出來),因此當套接字接受完成時喚醒 HTTP 程序是一種浪費的活動,因為該程序將立即再次進入睡眠狀態等待必要的數據。

雖然肯定有人認為喚醒空閒程序可以使它們“準備好”進行進一步處理(我特別記得在非常舊的機器上喚醒登錄終端並讓它們從交換中突入),但您也可以爭辯說,任何具有換出的所述程序已經對其資源提出了要求,並且進一步提出不必要的要求可能會整體降低系統性能 - 即使您的單個執行緒的明顯性能有所提高(也可能不會,一台非常繁忙的機器會在磁碟 IO 上出現瓶頸,這將如果您換了進來,請放慢其他事情的速度,如果它很忙,則立即睡眠可能會立即將其換回來)。這似乎是一場賭博,最終“貪婪”的賭博不一定會在繁忙的機器上得到回報,

關於該級別的性能調整,我的一般建議是不要對什麼是最好的做出程序化決策,而是允許系統管理員和作業系統一起工作來處理資源管理問題——這是他們的工作,他們很重要更適合了解整個系統及其他系統的工作負載。給出選項和配置選擇。

為了具體回答這個問題,該選項對所有配置都有好處,除非在 HTTP 流量的極端負載下,否則不會達到您可能注意到的水平,但從理論上講,這是“正確”的做法。這是一個選項,因為並非所有 Unix(甚至不是所有 Linux)版本都具有該功能,因此為了可移植性,可以將其配置為不包含在內。

引用自:https://unix.stackexchange.com/questions/94104