對於HTTP 重定向，你一定不陌生，它可以將 HTTP 請求進行轉移，在 Web 開發中我們經常會用它來完成自動跳轉，比如使用者登入成功後跳轉到相應的管理頁面。
這種重定向完全由HTTP 定義，並且由HTTP 代理和Web 伺服器共同實現。
很簡單，當HTTP 代理（比如瀏覽器）向Web伺服器請求某個URL後，Web 伺服器可以通過HTTP 響應頭資訊中的Location 標記來返回一個新的URL，這意味著HTTP代理需要繼續請求這個新的URL ，這便完成了自動跳轉。
當然，如果你自己寫了一個 HTTP 代理，也可以不支援重定向，也就是對於Web 伺服器返回的Location 標記視而不見，雖然這可能不符合HTTP 標準，但這完全取決於你的應用需要。
也正是因為HTTP 重定向具備了請求轉移和自動跳轉的本領，所以除了滿足應用程式需要的各種自動跳轉之外，它還可以用於實現負載均衡，以達到Web 擴充套件的目的。
我們知道，DNS負責提供域名解析服務，當我們訪問某個站點時，實際上首先需要通過該站點域名的DNS伺服器來獲取域名指向的IP 地址，
在這一過程中，DNS伺服器完成了域名到IP 地址的對映，同樣，這種對映也可以是一對多的，這時候，DNS 伺服器便充當了負載均衡排程器（也稱均衡器），它就像前面提到的重定向轉移策略一樣，將使用者的請求分散到多臺伺服器上，但是它的實現機制完全不同。
反向代理伺服器的核心工作便是轉發 HTTP 請求，因此它工作在 HTTP 層面，也就是 TCP 七層結構中的應用層（第七層），所以基於反向代理的負載均衡也稱為七層負載均衡，實現它並不困難，目前幾乎所有主流的 Web 伺服器都熱衷於支援基於反向代理的負載均衡，隨後我們將進行Nginx反向代理負載均衡的實驗
事實上，在資料鏈路層（第二層）、網路層（第三層）以及傳輸層（四層）都可以實現不同機制的負載均衡，但有所不同的是，這些負載均衡排程器的工作必須由Linux 核心來完成，因為我們希望網路資料包在從核心緩衝區進入程式使用者地址空間之前，儘早地被轉發到其他實際伺服器上，沒錯，Linux 核心當然可以辦得到，位於核心的Netfilter和IPVS可以解決問題，而使用者空間的應用程式對此卻束手無策。 另一方面，也正是因為可以將排程器工作在應用層以下，這些負載均衡系統可以支援更多的網路服務協議，比如FTP 、SMTP 、DNS ，以及流媒體和Vo I P 等應用。