nginx 反向代理(Reverse Proxy)與耗時記錄


          反向代理服務器位於實際的服務器之前,他能夠緩存服務器響應,加速訪問,同時也啟到了負載均衡服務器的效果。反向代理服務器解析客戶端請求,根據負載均衡算法轉發到不同的后台服務器上。用戶和后台服務器之間不再有直接的鏈接。請求,響應都由反向代理服務器進行轉發。優點是和負載均衡服務集成在一起,部署簡單。缺點是所有的請求回應都需要經過反向代理服務器。其本身可能會成為性能的瓶頸。著名的 Nginx服務器就可以部署為反向代理服務器,實現WEB 應用的負載均衡。

image

代理模式的含義如下圖,接受和返回都轉發:

image

nginx 的反向代理業務流程圖如下圖:

image

通過wireshark監控可以看到,返回的確實是無法看到代理之后的。

image

需要注意的是:反向代理負載均衡是工作在OSI網絡模型中的應用層,我們可以統稱為應用層負載均衡(七層負載均衡)。

 

image

注意:

反向代理負載均衡不是數據鏈路層的負載均衡,數據鏈路層的負載均衡可以實現三角傳輸。

image

數據鏈路層負載均衡,顧名思義,就是工作在TCP/IP協議最底層的數據鏈路層,進行負載均衡。我們常用的以太網中,在這一層主要采用數據幀進行通信,每個網卡都具有唯一的MAC地址,數據幀用MAC地址來標識數據的來源與目的地。數據鏈路層負載均衡通過修改數據包的MAC地址,實現負載均衡。


這種數據傳輸方式又稱為三角傳輸,負載均衡數據分發過程中不修改IP地址,只修改目的MAC地址,通過配置真實物理服務器集群所有機器虛擬IP和負載均衡服務器IP一致,從而達到不修改數據包的源地址和目的地址就可以進行數據分發的目的,由於實際處理請求的真實物理服務器IP和數據請求目的IP一致,不需要通過負載均衡服務器進行地址交換,可將響應數據包直接返回給用戶,避免負載均衡服務器網卡帶寬成為瓶頸。這種負載均衡方式又稱之為直接路由方式(DR).


如上圖所示,用戶請求到達負載均衡服務器114.100.20.200后,負載均衡服務器將數據包的目的MAC地址更改為00:1e:ec:bc:5e:03,並不修改數據包目的IP,由於服務器集群所有服務器的虛擬IP地址和負載均衡服務器IP地址一致,因此數據可以正常傳輸到達MAC地址為00:1e:ec:bc:5e:03的機器上,該服務器處理完之后,將響應數據包發送到網關服務器,網關服務器直接將數據包發送給用戶,響應數據不需要通過負載均衡服務器,這樣就避免了負載均衡服務器成為傳輸瓶頸的可能。


數據鏈路層負載均衡是目前使用最廣泛的一種負載均衡方式。著名的負載均衡開源產品LVS(Linux Virtual Server),同時支持上面的IP負載均衡和數據鏈路層負載均衡。

 

nginx的負載均衡是通過nginx的upstream模塊和proxy_pass反向代理來實現的。

nginx模塊一般被分成三大類:handler、filter和upstream。從本質上說,upstream屬於handler,只是他不產生自己的內容,而是通過請求后端服務器得到內容,所以才稱為upstream(上游)。這個請求並取得響應內容的整個過程已經被封裝到nginx內部。

參考:
http://tengine.taobao.org/book/chapter_05.html  
http://wiki.jikexueyuan.com/project/nginx/load-balancing-module.html 

在負載均衡時,upstream指令一般用於定義的后端主機列表和負載算法。

 

proxy_pass URL 指定代理的后端主機,可以指定 "http" 或 "https" 協議,域名可以是 ip 地址,也可以是 upstream 池名字

    參考: http://liaoph.com/nginx-tutorial/

     

    nginx 的請求配置參考下圖:

    image

    nginx日志的耗時

     

    官方文檔:
    http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format
    
    ||
    |$request_time|
        request processing time in seconds with a milliseconds resolution;
        time elapsed between the first bytes were read from the client and
        the log write after the last bytes were sent to the client
    
    |$request_time指的就是從接受用戶請求數據到發送完回復數據的時間。|
    
    http://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables
    
    ||
    |$upstream_response_time|
        keeps servers response times in seconds with a milliseconds
        resolution. Several responses are also separated by commas and colons.
    
    |$upstream_response_time說的有點模糊,它指的是從Nginx向后端建立連接開始 
    到接受完數據然后關閉連接為 止的時間。||因為會有重試,||它可能有多個時間 
    段。一般來說,||$upstream_response_time 會比||$request_time時間短。|
    
    對於HTTP POST的請求,兩者相差特別大。因為Nginx會把HTTP request body緩存 
    住,接受完畢后才會把數據一起發給后端。
    參考:
    http://code.taobao.org/pipermail/tengine-cn/2012-May/000295.html
    http://wuzhangshu927.blog.163.com/blog/static/114224687201310674652147/
    http://blog.chinaunix.net/uid-22312037-id-4089710.html
     

    參考資料:

    構建負載均衡服務器之一 負載均衡與集群詳解
    http://linuxnote.blog.51cto.com/9876511/1654565


    免責聲明!

    本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



     
    粵ICP備18138465號   © 2018-2025 CODEPRJ.COM