這篇文章寫的很好，對大家很有用，所以就貼過來了。本來要收藏的，因爲不想破壞博客堅持原創的原則。但是忽然發現文章在結構上可以修改一下，所以不破壞原則。原文出處已經忘記了，但是不是楊小一。我只是做了換湯不換藥的修改。這個問題實際工作和麪試的時候經常會被用到，這樣解釋我覺得非常好。
一句話，轉發是服務器行爲，重定向是客戶端行爲。
例子:
解釋一 （最好懂）
假設你去辦理某個執照，
重定向:你先去了A局，A局的人說:“這個事情不歸我們管，去B局”，然後，你就從A退了出來，自己乘車去了B局。
轉發:你先去了A局，A局看了以後，知道這個事情其實應該B局來管，但是他沒有把你退回來，而是讓你坐一會兒，自己到後面辦公室聯繫了B的人，讓他們辦好後，送了過來。
解釋二 （面試足以）
重定向
其實是兩次request,
第一次，客戶端request
A,服務器響應，並response回來，告訴瀏覽器，你應該去B。這個時候IE可以看到地址變了，而且歷史的回退按鈕也亮了。重定向可以訪問自己web應用以外的資源。在重定向的過程中，傳輸的信息會被丟失。
請求轉發
是服務器內部把對一個request/response的處理權，移交給另外一個
對於客戶端而言，它只知道自己最早請求的那個A，而不知道中間的B，甚至C、D。
傳輸的信息不會丟失。
解釋三（高大上）
重定向過程:客戶瀏覽器發送http請求----》web服務器接受後發送302狀態碼響應及對應新的location給客戶瀏覽器--》客戶瀏覽器發現是302響應，則自動再發送一個新的http請求，請求url是新的location地址----》服務器根據此請求尋找資源併發送給客戶。在這裏location可以重定向到任意URL，既然是瀏覽器重新發出了請求，則就沒有什麼request傳遞的概念了。在客戶瀏覽器路徑欄顯示的是其重定向的路徑，客戶可以觀察到地址的變化的。重定向行爲是瀏覽器做了至少兩次的訪問請求的。
轉發過程:客戶瀏覽器發送http請求----》web服務器接受此請求--》調用內部的一個方法在容器內部完成請求處理和轉發動作----》將目標資源發送給客戶;在這裏，轉發的路徑必須是同一個web容器下的url，其不能轉向到其他的web路徑上去，中間傳遞的是自己的容器內的request。在客戶瀏覽器路徑欄顯示的仍然是其第一次訪問的路徑，也就是說客戶是感覺不到服務器做了轉發的。轉發行爲是瀏覽器只做了一次訪問請求。