應用層重定向主要利用了HTTP、MMS、RTSP等協議本身的重定向機制來實現，由於各種應用層協議的重定向機制基本相同，因此以HTTP協議為例，介紹相關的知識。

1. HTTP重定向基本原理

在HTTP協議中，有三類重定向狀態碼：301 redirect、302 redirect與meta fresh。
1）301 redirect代表永久性轉移（Permaneutly Moved）
2）302 redirect代表暫時性轉移（Temporarily Moved）
3）meta fresh代表在特定時間後重定向到新的網頁。

HTTP狀態程式碼是在伺服器返回資料的第一行實現的，比如你訪問www.g.cn這個網址．Google的伺服器返回的資料第一行是：HTTP/1.1 301 Moved Permanently，頁面自動眺轉到http://www.google.cn，表示g.cn這個URL被永久重定向到http://www.google.cn。

三類重定向的作用都是將使用者的資源請求轉向到另外一個URL，而這一節所說的HTTP重定向，是用於CDN均衡排程的，顯然應該選擇302 redirect。因為負載均衡系統需要實現的是將使用者立刻且暫時性地重定向到另一臺服務裝置上去。

比如瀏覽器請求www.tanxingcai.com這個域名，伺服器返回應答訊息如下：

HTTP/1.1 302 Found
Date: Wed, 17 Mar 2010 08:11:11 GMT
Server: Apache/2.2.15 (Unix) mod_ssl/2.2.15 0penSSL/0.9.7a DAV/2
PHP/5.2.9
X-Powered-By, PHP/5.2.9

Content-Length: 0

瀏覽器得到這個應答後，會再次發起請求，只不過請求的域名替換成http://bj.tanxingcai.com。有時候，域名替代也直接使用IP地址。

利用HTTP重定向的GSLB工作過程大致是：

1. 使用者在瀏覽器位址列裡輸入一個域名，如HTTP://www.tanxingcai.com；
2. 本地DNS伺服器返回的解析結果是GSLB的IP地址；
3. 使用者端瀏覽器會向GSLB發起HTTP請求，GSLB向瀏覽器返回響應請求的HTTP資料包；
   這個HTTP資料包的頭資訊（Header）中會包含一條“302 found”資訊，告訴使用者向某個IP地址的伺服器請求內容。在這個過程中，GSLB還會做一個動作，就是修改原來的URL，把它改寫成另一個URL’
   ，這個URL’中的域名就是使用者要去進行內容請求的服務裝置的主機名。使用者向這個伺服器請求內容得到應答後，才是真正開始瀏覽網頁內容的過程。

與智慧DNS方式相似，GSLB在做HTTP重定向時，也就是在為使用者選擇最佳伺服器時，也會綜合考慮很多條件，比如伺服器的負載情況、使用者與各個伺服器之間的鏈路質量、使用者請求的內容所在位置等。區別在於，相比較於DNS方式，基於HTTP重定向方式的GSLB系統能夠看到使用者的IP地址，以及使用者請求的具體內容，所以能夠進行更精細的定位，這是HTTP重定向方式的最大優點。

當然HTTP重定向也有其不足：
1)這種方法只適用於HTTP應用，不適用於任何其他應用。比如微軟的MMS協議、RTSP協議，就不能使用這種方式進行重定向。
2)其次，由於HTTP重定向過程需要額外解析域名URL’，還需要與URL’建立TCP連線並且傳送HTTP請求，使得響應時間加長。
3)第三，不同於DNS方式，沒有任何使用者請求能被外部系統終結，所有請求都必須進入 GSLB系統，這將成為效能和可靠性的瓶頸。

2. 基於HTTP重定向的GSLB工作流程

1. 由於網站已經預先進行了域名CNAME指向服務CDN的GSLB域名和IP，所以本地DNS會向用戶返回GSLB裝置的IP地址。（注意，是一個具體的IP地址，這樣DNS解析過程就終結了。當然，如果GSLB系統本身是有負載均衡的，那麼返回的這個IP地址就是經過GSLB系統自身負載均衡後的某臺具體裝置的IP地址。）

2. 使用者向這臺GSLB裝置發起HTTP GET請求，請求該網站某個網頁的內容。應該注意的是，在使用者瀏覽一個完整的網頁時，事實上是發起了多個HTTP請求，針對某個獨立的物件，比如一張圖片、一段視訊、一段文字，都會存在這樣一個獨立的HTTP請求。

3. GSLB裝置將綜合分析使用者IP、內容分佈、裝置負載、鏈路狀況等實時資訊，為使用者選擇一個合適的服務單元。之所以稱為“單元”而不是“裝置”，是因為很多實際的CDN系統的GSLB只魚貴負載均衡的第一步，將使用者訪問請求排程到一個合適的服務區，或者一個叢集，再由區域均衡或本地均衡裝置做下一步負載均衡工作。GSLB裝置向用戶返回HTTP 302重定向應答，告知
   使用者下一次請求應該傳送的目的IP地址。如步驟(3)所述，這個IP地址可以是一臺具體服務裝置的IP地址，也可以是一個區域均衡裝置的IP地址，或者一個叢集的L4交換機的IP地址。

   如果GSLB在自己的靜態路徑表中沒有查到使用者IP所在網段的資訊，可以通過兩種方式完成路由策略。方式一，GSLB將使用者請求通過輪詢的方式定向到其他節點。方式二，GSLB會以同樣方式去查動態最近路徑表，如仍沒有記錄，GSLB會通知各POP點的SLB一同去測各POP點離使用者的距離及時延，並報告核心節點確定最優站點，該IP地址所在的網段會被新增至動態最近路徑
   表，供今後使用者直接與最優的分配層節點的SLB裝置建立連線。某些情況，也可採用輪詢方式選擇SLB裝置。

4. 使用者根據得到的IP地址向CDN節點發出媒體訪問請求。

5. 如果這個IP地址的節點裝置仍然是一個負載均衡裝置，則通過負載均衡選擇一臺合適的服務裝置，將其IP地址返回給使用者。

6. 使用者根據得到的IP地址向CDN服務裝置發出媒體訪問請求。

3. HTTP重定向方式的侷限性體現在以下三個方面。

第一，GSLB效能壓力大。GSLB作為所有使用者請求進人CDN系統的第一跳，所有使用者請求無一例外地都會到達這裡，隨著使用者請求數量級的增加，GSLB的壓力也隨之增大。同時GSLB作為全網的核心部件很容易受到攻擊，有較大的安全隱患。

第二，協議擴充套件性較差。這一條從實現原理上也能理解，GSLB是通過分析和改寫伺服器與客戶端之間的應用協議互動資訊實現重定向功能的，可能還要疊加一些許可權判斷、防盜鏈之類的定製功能。也就是說，應用屢負載均衡需要對應用有一定的瞭解。所以對於新增加的應用協議，需要進行開發升級。而對那些不支援重定向的應用，還需要在GSLB/SLB上開發新的重定向介面。

第三，安全性問題。在這種方式下，每次重定向都會通過與客戶端之間的應用協議互動完成，所以在客戶端可以通過協議分析瞭解到整個伺服器架構，這會導致一定的安全隱患。