nginx 反向代理（Reverse Proxy）與耗時記錄

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

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

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

注意：

反向代理負載均衡不是資料鏈路層的負載均衡，資料鏈路層的負載均衡可以實現三角傳輸。

資料鏈路層負載均衡，顧名思義，就是工作在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內部。
 

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

proxy_pass URL 指定代理的後端主機，可以指定 "http" 或 "https" 協議，域名可以是 ip 地址，也可以是 upstream 池名字
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快取 住，接受完畢後才會把資料一起發給後端。