nginx 反向代理原理解析

面試一個很糾結的問題，原本老師給講過這個原理，而且講的很是詳細，面試現場，我居然不知如何回答，好悲催

如今記錄一下，順便和squid對比記憶

squid同步傳輸：瀏覽器發起請求，然後請求會馬上被轉到後臺，因而在瀏覽器和後臺之間就創建了一個通道。在請求發起直到請求完成，這條通道都是一直存在的。
nginx異步傳輸：瀏覽器發起請求，請求不會馬上轉到後臺，而是將請求數據（header）先收到nginx上，而後nginx再把這個請求發到後端， 後端處理完以後把數據返回到nginx上，nginx將數據流發到瀏覽器，這點和lighttpd有點不一樣，lighttpd是將後端數據徹底接收後才發 送到瀏覽器。
那麼這到底有什麼好處呢？

1) 假設用戶執行一個上傳文件操做，由於用戶網速又比較慢，所以須要花半個小時才能把文件傳到服務器。squid的同步代理在用戶開始上傳後就和後臺創建了連 接，半小時後文件上傳結束，因而可知，後臺服務器鏈接保持了半個小時；而nginx異步代理就是先將此文件收到nginx上，所以僅僅是nginx和用戶 保持了半小時鏈接，後臺服務器在這半小時內沒有爲這個請求開啓鏈接，半小時後用戶上傳結束，nginx纔將上傳內容發到後臺，nginx和後臺之間的帶寬 是很充裕的，因此只花了一秒鐘就將請求發送到了後臺，因而可知，後臺服務器鏈接保持了一秒。同步傳輸花了後臺服務器半個小時，異步傳輸只花一秒，可見優化 程度很大。

2) 在上面這個例子中，假如後臺服務器由於種種緣由重啓了，上傳文件就天然中斷了，這對用戶來講是很是惱火的一件事情，想必各位也有上傳文件傳到一半被中斷的 經歷。用nginx代理以後，後臺服務器的重啓對用戶上傳的影響減小到了極點，而nginx是很是穩定的並不須要常去重啓它，即便須要重啓，利用kill -HUP就能夠作到不間斷重啓nginx。

3) 異步傳輸能夠令負載均衡器更有保障，爲何這麼說呢？在其它的均衡器（lvs/haproxy/apache等）裏，每一個請求都是隻有一次機會的，假如用 戶發起一個請求，結果該請求分到的後臺服務器恰好掛掉了，那麼這個請求就失敗了；而nginx由於是異步的，因此這個請求能夠從新發往下一個後臺，下一個 後臺返回了正常的數據，因而這個請求就能成功了。仍是用用戶上傳文件這個例子，假如不但用了nginx代理，並且用了負載均衡，nginx把上傳文件發往 其中一臺後臺，但這臺服務器忽然重啓了，nginx收到錯誤後，會將這個上傳文件發到另外一臺後臺，因而用戶就不用再花半小時上傳一遍。

4) 假如用戶上傳一個10GB大小的文件，然後臺服務器沒有考慮到這個狀況，那麼後臺服務器豈不要崩潰了。用nginx就能夠把這些東西都攔在nginx上， 經過nginx的上傳文件大小限制功能來限制，另外nginx性能很是有保障，就放心的讓互聯網上那些另類的用戶和nginx對抗去吧。
用異步傳輸會形成問題：
後臺服務器有提供上傳進度的功能的話，用了nginx代理就沒法取得進度，這個須要使用nginx的一個第三方模塊來實現。