Http協議3XX重定向介紹及301跳轉和302跳轉應用場景
一 總體介紹
Http協議中的3XX都是重定向(Redirection),在Http 1.1的rfc中介紹了300-307總共7個,它們分別是:
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
306 (Unused)
307 Temporary Redirect
二 各種跳轉的中文介紹
300 Multiple Choices
被請求的資源有一系列可供選擇的回饋資訊，每個都有自己特定的地址和瀏覽器驅動的商議資訊。使用者或瀏覽器能夠自行選擇一個首選的地址進行重定向。
除非這是一個HEAD請求，否則該響應應當包括一個資源特性及地址的列表的實體，以便使用者或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由Content-Type定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動作出最合適的選擇。當然，RFC 2616規範並沒有規定這樣的自動選擇該如何進行。
如果伺服器本身已經有了首選的回饋選擇，那麼在Location中應當指明這個回饋的URI；瀏覽器可能會將這個Location值作為自動重定向的地址。此外，除非額外指定，否則這個響應也是可快取的。
301 Moved Permanently
被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個URI之一。如果可能，擁有連結編輯功能的客戶端應當自動把請求的地址修改為從伺服器反饋回來的地址。除非額外指定，否則這個響應也是可快取的。
新的永久性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超連結及簡短說明。
如果這不是一個GET或者HEAD請求，因此瀏覽器禁止自動進行重定向，除非得到使用者的確認，因為請求的條件可能因此發生變化。
注意：對於某些使用HTTP/1.0協議的瀏覽器，當它們傳送的POST請求得到了一個301響應的話，接下來的重定向請求將會變成GET方式。
302 Found
請求的資源現在臨時從不同的URI響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址傳送以後的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可快取的。
新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超連結及簡短說明。
如果這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非得到使用者的確認，因為請求的條件可能因此發生變化。
注意：雖然RFC 1945和RFC 2068規範不允許客戶端在重定向時改變請求的方法，但是很多現存的瀏覽器將302響應視作為303響應，並且使用GET方式訪問在Location中規定的URI，而無視原先請求的方法。狀態碼303和307被添加了進來，用以明確伺服器期待客戶端進行何種反應。
303 See Other
對應當前請求的響應可以在另一個URI上被找到，而且客戶端應當採用GET的方式訪問那個資源。這個方法的存在主要是為了允許由指令碼啟用的POST請求輸出重定向到一個新的資源。這個新的URI不是原始資源的替代引用。同時，303響應禁止被快取。當然，第二個請求（重定向）可能被快取。
新的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超連結及簡短說明。
注意：許多HTTP/1.1版以前的瀏覽器不能正確理解303狀態。如果需要考慮與這些瀏覽器之間的互動，302狀態碼應該可以勝任，因為大多數的瀏覽器處理302響應時的方式恰恰就是上述規範要求客戶端處理303響應時應當做的。
304 Not Modified
如果客戶端傳送了一個帶條件的GET請求且該請求已被允許，而文件的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則伺服器應當返回這個狀態碼。304響應禁止包含訊息體，因此始終以訊息頭後的第一個空行結尾。
該響應必須包含以下的頭資訊：
Date，除非這個伺服器沒有時鐘。假如沒有時鐘的伺服器也遵守這些規則，那麼代理伺服器以及客戶端可以自行將Date欄位新增到接收到的響應頭中去（正如RFC 2068中規定的一樣），快取機制將會正常工作。
ETag和／或Content-Location，假如同樣的請求本應返回200響應。
Expires, Cache-Control，和／或Vary，假如其值可能與之前相同變數的其他響應對應的值不同的話。
假如本響應請求使用了強快取驗證，那麼本次響應不應該包含其他實體頭；否則（例如，某個帶條件的GET請求使用了弱快取驗證），本次響應禁止包含其他實體頭；這避免了快取了的實體內容和更新了的實體頭資訊之間的不一致。
假如某個304響應指明瞭當前某個實體沒有快取，那麼快取系統必須忽視這個響應，並且重複傳送不包含限制條件的請求。
假如接收到一個要求更新某個快取條目的304響應，那麼快取系統必須更新整個條目以反映所有在響應中被更新的欄位的值。
305 Use Proxy
被請求的資源必須通過指定的代理才能被訪問。Location域中將給出指定的代理所在的URI資訊，接收者需要重複傳送一個單獨的請求，通過這個代理才能訪問相應資源。只有原始伺服器才能建立305響應。
注意：RFC 2068中沒有明確305響應是為了重定向一個單獨的請求，而且只能被原始伺服器建立。忽視這些限制可能導致嚴重的安全後果。
306 Switch Proxy
在最新版的規範中，306狀態碼已經不再被使用。
307 Temporary Redirect
請求的資源現在臨時從不同的URI響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址傳送以後的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可快取的。
新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超連結及簡短說明。因為部分瀏覽器不能識別307響應，因此需要新增上述必要資訊以便使用者能夠理解並向新的URI發出訪問請求。
如果這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非得到使用者的確認，因為請求的條件可能因此發生變化。
三 301和302的選擇
如果從便於搜尋引擎友好的話當然是301最合適，一般情況下非特意臨時性URL轉移，都儘量用301跳轉，這樣的一個好處是搜尋引擎會把該URL的PR值都帶到跳轉後的地址，而302跳轉早期被很多網站當作作弊手段，已經被多數搜尋引擎重點盯查。
而效能方面原則上301跳轉和302跳轉沒有多大差別，不過考慮到搜尋引擎個案對待，也建議使用301跳轉，301跳轉搜尋引擎是不對原地址進行訪問的，而302跳轉除了象@張洪保所講可能被劫持之外，還有可能會加大對伺服器的URL請求數量。
搜尋引擎對302跳轉進行判斷的時候，如果發現跳轉目標頁面URL更加複雜，就會返回來對原URL進行訪問，尋取一個簡單友好的地址，這樣無形會加重伺服器性能損耗，因此301跳轉要比302跳轉靠普也對伺服器效能有保障。301的含義是“永久重定向”，而302的含義是“臨時重定向”。301代表永久性轉移是網頁更改地址後對搜尋引擎友好的最好方法，只要不是暫時搬移的情況,都建議使用301來做轉址。
由於搜尋引擎排名演算法只是程式而不是人，在遇到302重定向的時候，並不能像人一樣的去準確判定哪一個網址更適當，這就造成了網址URL劫持的可能性。也就是說，一個不道德的人在他自己的網址A做一個302重定向到你的網址B，出於某種原因， Google搜尋結果所顯示的仍然是網址A，但是所用的網頁內容卻是你的網址B上的內容，這種情況就叫做網址URL劫持。你辛辛苦苦所寫的內容就這樣被別人偷走了。