原文：

Nginx upstream目前只有短連線，通過HTTP/1.0向後端發起連線，並把請求的"Connection" header設為"close"。Nginx與前端的連線預設為長連線，一個使用者跟Nginx建立連線之後，通過這個長連線傳送多個請求。如果Nginx只是作為reverse proxy的話，可能一個使用者連線就需要多個向後端的短連線。如果後端的伺服器（源站或是快取伺服器）處理併發連線能力不強的話（比如單程序的squid），就可能導致瓶頸的出現。

Nginx目前的upstream連線建立和獲取的機制如下圖。Nginx會在一開始建立connection pool（程序間不共享，可以避免鎖），提供給所有向前/後的連線。

如果要實現upstream長連線，則每個程序需要另外一個connection pool，裡面都是長連線。一旦與後端伺服器建立連線，則在當前請求連線結束之後不會立即關閉連線，而是把用完的連線儲存在一個keepalive connection pool裡面，以後每次需要建立向後連線的時候，只需要從這個連線池裡面找，如果找到合適的連線的話，就可以直接來用這個連線，不需要重新建立socket或者發起connect()。這樣既省下建立連線時在握手的時間消耗，又可以避免TCP連線的slow start。如果在keepalive連線池找不到合適的連線，那就按照原來的步驟重新建立連線。假設連線查詢時間可以忽略不計，那麼這種方法肯定是有益而無害的（當然，需要少量額外的記憶體）。

具體如何來設計這個keepalive connection pool，不同人有不同的選擇。比如Nginx目前的第三方模組upstream keepalive（作者Maxim Dounin）使用了一個queue來做。因為upstream的伺服器很可能是多個，所以可能當保持的連線數多的時候，查詢的時間可能會較長。可以給每個upstream伺服器都分配一個pool（queue），縮短查詢時間。但是總體來說記憶體操作很快，影響不會很大。upstream keepalive模組目前只支援memcached，但是可以重用其程式碼來達到對http upstream的長連線。在upstream模組和反向代理（二）裡面highlight了一些改動的地方。由於Nginx作者之前沒有考慮upstream的長連線，所以在設計上要把http upstream keepalive模組化可能比較難，只能通過手動修改程式碼來做到。