Nginx upstream 長鏈接

原文：

http://bollaxu.iteye.com/blog/900424

 

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模塊化可能比較難，只能經過手動修改代碼來作到。