3) 單socket中的accept串行化

　　以上言及的方案對多socket服務(wù)器是相當(dāng)不錯(cuò)的，但只有一個(gè)socket的情況又如何呢？理論上，由于在連接請求到來之前所有子進(jìn)程將阻塞在accept中，單個(gè)socket不會(huì)產(chǎn)生上述種種問題。但實(shí)際上，上述非阻塞解決方案所帶來的"回旋（spinning）"問題在這里只不過被掩蓋起來了。在絕大多數(shù)TCP協(xié)議棧的實(shí)現(xiàn)中，一個(gè)接請求到來時(shí)內(nèi)核將喚醒所有阻塞在accept中的進(jìn)程。它們之一將得到此請求并返回用戶空間，其余的進(jìn)程將返回內(nèi)核重新休眠。這將帶來與多socket非阻塞解決方案相同的資源浪費(fèi)。

　　由于這點(diǎn)原因，我們發(fā)現(xiàn)如果為socket串行化，許多系統(tǒng)表現(xiàn)得更"友好"--即使是一個(gè)socket的情況。這是單個(gè)socket串行化作為絕大多數(shù)情況的缺省配置的原因。在Linux上不甚精確的（Linux 2.0.30 / 雙Pentium Pro 166 w / 128Mb內(nèi)存）實(shí)驗(yàn)表明，對每次請求而言，串行化的單個(gè)socket僅比沒有串行化的socket損失不到3%的性能。但未串行化的socket顯示出每次連接請求100毫秒的延時(shí)。這也可能僅僅由于過長的通訊距離造成的。如果您不想串行化單個(gè)socket，可以定義宏SINGLE_LISTEN_UNSERIALIZED_ACCEPT。這樣，僅有一個(gè)socket的服務(wù)器將不會(huì)串行化。

　　4) 延遲關(guān)閉（Lingering Close）

　　就象draft-ietf-http-connection-00.txt第8節(jié)討論的那樣，為了使服務(wù)器能夠可靠地實(shí)現(xiàn)HTTP協(xié)議，有必要獨(dú)立地關(guān)閉每個(gè)方向上的通訊（每個(gè)TCP連接有兩個(gè)方向，每個(gè)方向是分別獨(dú)立的）。這個(gè)事實(shí)往往被其他服務(wù)器所忽視，而Apache 1.2就已經(jīng)正確地處理了。

　　當(dāng)這個(gè)特性增加到Apache中時(shí)卻在許多版本的Unix中引起了問題。這是TCP規(guī)范的短見造成的--它沒有聲明FIN_WAIT_2有超時(shí)，但也沒有阻止這樣的實(shí)現(xiàn)。在沒有超時(shí)的系統(tǒng)中，Apache 1.2將導(dǎo)致許多socket將永遠(yuǎn)處于FIN_WAIT_2的狀態(tài)。這可以簡單地用打最新TCP/IP補(bǔ)丁的方法避免。然而在提供商從不發(fā)行補(bǔ)丁的系統(tǒng)上（也就是SunOS4--雖然得到源代碼許可證的人可以自己打補(bǔ)丁），我們決定不直接使用這一特性。