HTTP協議學習——基礎篇
HTTP概述
- HTTP是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫。它的發展是萬維網協會（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結果，（他們）最終發佈了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。
- HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。
- HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。
在TCP/IP協議棧中的位置
HTTP協議通常承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了我們常說的HTTPS。如下圖所示：
默認HTTP的端口號爲80，HTTPS的端口號爲443。
爲什麼需要http協議？
HTTP的請求響應模型
HTTP協議永遠都是客戶端發起請求，服務器回送響應。見下圖：
這樣就限制了使用HTTP協議，無法實現在客戶端沒有發起請求的時候，服務器將消息推送給客戶端。
HTTP協議是一個無狀態的協議，同一個客戶端的這次請求和上次請求是沒有對應關係。
工作流程
一次HTTP操作稱爲一個事務，其工作過程可分爲四步：
1）首先客戶機與服務器需要建立連接。只要單擊某個超級鏈接，HTTP的工作開始。
2）建立連接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號， 後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。
3）服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。
4）客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然後客戶機與服務器斷開連接。
如果在以上過程中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標點擊，等待信息顯示就可以了。
HTTP協議之請求篇
HTTP請求由三部分組成，分別是：
- 請求行
- 消息報頭
- 請求正文
請求行
請求行以一個方法符號開頭，以空格分開，後面跟着請求的URL和協議的版本，格式如下：
GET /index.html HTTP/1.1
HTTP請求方法有以下幾種
| GET | 請求獲取URL所標識的資源 |
|---|---|
| POST | 請求URL所標識的資源，並請求服務器接收附加在請求後面的數據，常用於表單提交。 |
| HEAD | 請求獲取由URL所標識的資源的響應消息報頭 |
| PUT | 請求服務器存儲一個資源，並用URL作爲其標識 |
| DELETE | 請求服務器刪除URL所標識的資源 |
| TRACE | 請求服務器回送收到的請求信息，主要用於測試或診斷 |
| CONNECT | 保留將來使用 |
| OPTIONS | 請求查詢服務器的性能，或者查詢與資源相關的選項和需求 |
常用的請求方式是GET和POST：
- GET方式：是以實體的方式得到由請求URI所指定資源的信息，如果請求URI只是一個數據產生過程，那麼最終要在響應實體中返回的是處理過程的結果所指向的資源，而不是處理過程的描述。
- POST方式：用來向目的服務器發出請求，要求它接受被附在請求後的實體，並把它當作請求隊列中請求URI所指定資源的附加新子項，Post被設計成用統一的方法實現下列功能：
1：對現有資源的解釋；
2：向電子公告欄、新聞組、郵件列表或類似討論組發信息；
3：提交數據塊；
4：通過附加操作來擴展數據庫 。
從上面描述可以看出，Get是向服務器發索取數據的一種請求；而Post是向服務器提交數據的一種請求，要提交的數據位於信息頭後面的實體中。
GET與POST方法有以下區別：
（1）在客戶端，Get方式在通過URL提交數據，數據在URL中可以到；POST方式，數據放置在HTML HEADER內提交。
（2）GET方式提交的數據最多隻能有1024字節，而POST則沒有此限制。
（3）安全性問題。正如在（1）中提到，使用 Get 的時候，參數會顯示在地址欄上，而 Post 不會。所以，如果這些數據是中文數據而且是非敏感數據，那麼使用 get；如果用戶輸入的數據不是中文字符而且包含敏感數據，那麼還是使用 post爲好。
（4）安全的和冪等的。所謂安全的意味着該操作用於獲取信息而非修改信息。冪等的意味着對同一 URL 的多個請求應該返回同樣的結果。完整的定義並不像看起來那樣嚴格。換句話說，GET 請求一般不應產生副作用。從根本上講，其目標是當用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。比如，新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認爲是安全的和冪等的，因爲它總是返回當前的新聞。反之亦然。POST 請求就不那麼輕鬆了。POST 表示可能改變服務器上的資源的請求。仍然以新聞站點爲例，讀者對文章的註解應該通過 POST 請求實現，因爲在註解提交之後站點已經不同了。
舉例
GET /index.html HTTP/1.1
INPUT /index.html HTTP/1.1
Delete /index.html HTTP/1.1
HTTP請求舉例
HTTP協議之響應篇
在接收和解釋請求消息後，服務器返回一個HTTP響應消息。 HTTP響應也是由三部分組成，分別爲：
- 狀態行
- 消息報頭
- 響應正文
狀態行
狀態行格式如下：
HTTP版本 狀態碼 狀態代碼的文本描述 回車換行
例如：
HTTP/1.1 200 OK
HTTP/1.1 404 Not Found
HTTP/1.1 500 Internet Server Error
常見狀態碼
1**：請求收到，繼續處理
100——客戶必須繼續發出請求
101——客戶要求服務器根據請求轉換HTTP協議版本
2**：操作成功收到，分析，接受
200——交易成功(OK，客戶端請求成功)
201——提示知道新文件的URL
202——接受和處理、但處理未完成
203——返回信息不確定或不完整
204——請求收到，但返回信息爲空
205——服務器完成了請求，用戶代理必須復位當前已經瀏覽過的文件
206——服務器已經完成了部分用戶的GET請求
3**：完成此請求必須進一步處理
300——請求的資源可在多處得到
301——刪除請求數據
302——在其他地址發現了請求數據（Move Temporarily 請求的資源現在臨時從不同的URL響應請求）
303——建議客戶訪問其他URL或訪問方式
304——客戶端已經執行了GET，但文件未變化
305——請求的資源必須從服務器指定的地址得到
306——前一版本HTTP中使用的代碼，現行版本中不再使用
307——申明請求的資源臨時性刪除
4**：請求包含一個錯誤語法或不能完成
400——錯誤請求，如語法錯誤（Bad Request客戶端請求有語法錯誤，不能被服務器所理解）
401——未授權（Unauthorized 請求未經授權，這個狀態代碼必須和WWW Authorized報頭域一起使用）
HTTP 401.1 - 未授權：登錄失敗
HTTP 401.2 - 未授權：服務器配置問題導致登錄失敗
HTTP 401.3 - ACL 禁止訪問資源
HTTP 401.4 - 未授權：授權被篩選器拒絕
HTTP 401.5 - 未授權：ISAPI 或 CGI 授權失敗
402——保留有效ChargeTo頭響應
403——禁止訪問（Forbidden 服務器收到請求，但是拒絕提供服務）
HTTP 403.1 禁止訪問：禁止可執行訪問
HTTP 403.2 - 禁止訪問：禁止讀訪問
HTTP 403.3 - 禁止訪問：禁止寫訪問
HTTP 403.4 - 禁止訪問：要求 SSL
HTTP 403.5 - 禁止訪問：要求 SSL 128
HTTP 403.6 - 禁止訪問：IP 地址被拒絕
HTTP 403.7 - 禁止訪問：要求客戶證書
HTTP 403.8 - 禁止訪問：禁止站點訪問
HTTP 403.9 - 禁止訪問：連接的用戶過多
HTTP 403.10 - 禁止訪問：配置無效
HTTP 403.11 - 禁止訪問：密碼更改
HTTP 403.12 - 禁止訪問：映射器拒絕訪問
HTTP 403.13 - 禁止訪問：客戶證書已被吊銷
HTTP 403.15 - 禁止訪問：客戶訪問許可過多
HTTP 403.16 - 禁止訪問：客戶證書不可信或者無效
HTTP 403.17 - 禁止訪問：客戶證書已經到期或者尚未生效
404——沒有發現文件、查詢或URl（Not Found 請求資源不存在 eg：輸入了錯誤的URL）
405——用戶在Request-Line字段定義的方法不允許
406——根據用戶發送的Accept拖，請求資源不可訪問
407——類似401，用戶必須首先在代理服務器上得到授權
408——客戶端沒有在用戶指定的餓時間內完成請求
409——對當前資源狀態，請求不能完成
410——服務器上不再有此資源且無進一步的參考地址
411——服務器拒絕用戶定義的Content-Length屬性請求
412——一個或多個請求頭字段在當前請求中錯誤
413——請求的資源大於服務器允許的大小
414——請求的資源URL長於服務器允許的長度
415——請求資源不支持請求項目格式
416——請求中包含Range請求頭字段，在當前請求資源範圍內沒有range指示值，請求也不包含If-Range請求頭字段
417——服務器不滿足請求Expect頭字段指定的期望值，如果是代理服務器，可能是下一級服務器不能滿足請求長。
5**：服務器執行一個完全有效請求失敗
HTTP 500 - 內部服務器錯誤（500 Internet Server Error 服務器發生不可預期的錯誤）
HTTP 500.100 - 內部服務器錯誤 - ASP 錯誤
HTTP 500-11 服務器關閉
HTTP 500-12 應用程序重新啓動
HTTP 500-13 - 服務器太忙
HTTP 500-14 - 應用程序無效
HTTP 500-15 - 不允許請求 global.asa
Error 501 - 未實現
HTTP 502 - 網關錯誤
HTTP 503 （Server Unavailable 服務器當前不能處理客戶端的請求，一段時間後可能恢復正常）
HTTP響應舉例
HTTP協議之消息報頭篇
請求報頭
請求報頭允許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。
HTTP最常見的請求頭如下：
- Accept：瀏覽器可接受的MIME類型(Multipurpose Internet Mail Extensions多用途互聯網郵件擴展類型）；
- Accept-Charset：瀏覽器可接受的字符集；
- Accept-Encoding：瀏覽器能夠進行解碼的數據編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間；
- Accept-Language：瀏覽器所希望的語言種類，當服務器能夠提供一種以上的語言版本時要用到；
- Authorization：授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中；
- Connection：表示是否需要持久連接。如果Servlet看到這裏的值爲「Keep-Alive」，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小；
- Content-Length：表示請求消息正文的長度，只適用於POST請求，用來給定POST數據的大小，以字節爲單位；
- Cookie：這是最重要的請求頭信息之一；
- From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它；
- Host：初始URL中的主機和端口；
- If-Modified-Since：只有當所請求的內容在指定的日期之後又經過修改才返回它，否則返回304「Not Modified」應答；
- Pragma：指定「no-cache」值表示服務器必須返回一個刷新後的文檔，即使它是代理服務器而且已經有了頁面的本地拷貝；
- Referer：包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面。
- User-Agent：瀏覽器類型，如果Servlet返回的內容與瀏覽器類型有關則該值非常有用；
- UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標準的請求頭，表示屏幕大小、顏色深度、操作系統和CPU類型。
響應報頭
HTTP最常見的響應頭如下所示：
- Allow：服務器支持哪些請求方法（如GET、POST等）；
- Cache-Control：告訴瀏覽器或者其他客戶，什麼環境可以安全的緩存文檔。
- Connection：close值，指定瀏覽器不用使用持續性的HTTP連接。
- Content-Disposition：要求瀏覽器詢問客戶，將響應存儲在磁盤上給定名稱的文件中。
- Content-Encoding：文檔的編碼（Encode）方法。只有在解碼之後纔可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader(「Accept-Encoding」)）檢查瀏覽器是否支持gzip，爲支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，爲其他瀏覽器返回普通頁面；
- Content-Language：文檔使用的語言。
- Content-Length：表示內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢，可以把輸出文檔寫入ByteArrayOutputStram，完成後查看其大小，然後把該值放入Content-Length頭，最後通過byteArrayStream.writeTo(response.getOutputStream()發送內容；
- Content-Type： 表示後面的文檔屬於什麼MIME類型。Servlet默認爲text/plain，但通常需要顯式地指定爲text/html。由於經常要設置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentTyep。 可在web.xml文件中配置擴展名和MIME類型的對應關係；
- Date：當前的GMT時間。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩；
- Expires：指明應該在什麼時候認爲文檔已經過期，從而不再緩存它。
- Last-Modified：文檔的最後改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視爲一個條件GET，只有改動時間遲於指定時間的文檔纔會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置；
- Location：表示客戶應當到哪裏去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼爲302；
- Refresh：表示瀏覽器應該在多少時間之後刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader(「Refresh」, 「5; URL=http://host/path」)讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設置HTML頁面HEAD區的實現，這是因爲，自動刷新或重定向對於那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對於Servlet來說，直接設置Refresh頭更加方便。注意Refresh的意義是「N秒之後刷新本頁面或訪問指定頁面」，而不是「每隔N秒刷新本頁面或訪問指定頁面」。因此，連續刷新要求每次都發送一個Refresh頭，而發送204狀態代碼則可以阻止瀏覽器繼續刷新，不管是使用Refresh頭還是<META HTTP-EQUIV=「Refresh」 …>。注意Refresh頭不屬於HTTP 1.1正式規範的一部分，而是一個擴展，但Netscape和IE都支持它。
- Set-Cookie：指定一個同頁面相關的cookie。
實體頭
實體頭用做實體內容的元信息，描述了實體內容的屬性，包括實體信息類型，長度，壓縮方法，最後一次修改時間，數據有效性等。
- Allow：GET,POST
- Content-Encoding：文檔的編碼（Encode）方法，例如：gzip；
- Content-Language：內容的語言類型，例如：zh-cn；
- Content-Length：表示內容長度，eg：80
- Content-Location：表示客戶應當到哪裏去提取文檔
- Content-MD5：MD5 實體的一種MD5摘要，用作校驗和。發送方和接受方都計算MD5摘要，接受方將其計算的值與此頭標中傳遞的值進行比較。Eg1：Content-MD5: <base64 of 128 MD5 digest>。Eg2：dfdfdfdfdfdfdff==；
- Content-Range：隨部分實體一同發送；標明被插入字節的低位與高位字節偏移，也標明此實體的總長度。Eg1：Content-Range: 1001-2000/5000，eg2：bytes 2543-4532/7898
- Content-Type：標明發送或者接收的實體的MIME類型。Eg：text/html; charset=GB2312 主類型/子類型；
- Expires：爲0證明不緩存；
- Last-Modified：WEB 服務器認爲對象的最後修改時間，比如文件的最後修改時間，動態頁面的最後產生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT.
擴展頭
在HTTP消息中，也可以使用一些再HTTP1.1正式規範裏沒有定義的頭字段，這些頭字段統稱爲自定義的HTTP頭或者擴展頭，他們通常被當作是一種實體頭處理。
現在流行的瀏覽器實際上都支持Cookie,Set-Cookie,Refresh和Content-Disposition等幾個常用的擴展頭字段。
- Refresh：1;url=http://www.dfdf.org //過1秒跳轉到指定位置；
- Content-Disposition：頭字段
- Content-Type：WEB 服務器告訴瀏覽器自己響應的對象的類型。
eg1：Content-Type：application/xml ；
eg2：applicaiton/octet-stream；
Cookie和Session
Cookie和Session
Cookie和Session都爲了用來保存狀態信息，都是保存客戶端狀態的機制，它們都是爲了解決HTTP無狀態的問題而所做的努力。
Session可以用Cookie來實現，也可以用URL回寫的機制來實現。用Cookie來實現的Session可以認爲是對Cookie更高級的應用。
兩者比較
Cookie和Session有以下明顯的不同點：
1）Cookie將狀態保存在客戶端，Session將狀態保存在服務器端；
2）Cookies是服務器在本地機器上存儲的小段文本並隨每一個請求發送至同一個服務器。Cookie最早在RFC2109中實現，後續RFC2965做了增強。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies並將它們保存爲一個本地文件，它會自動將同一服務器的任何請求縛上這cookies。Session並沒有在HTTP的協議中定義；
3）Session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置爲由get來返回給服務器；
4）就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在服務器端的session機制更安全些，因爲它不會任意讀取客戶存儲的信息。
Session機制
Session機制是一種服務器端的機制，服務器使用一種類似於散列表的結構（也可能就是使用散列表）來保存信息。
當程序需要爲某個客戶端的請求創建一個session的時候，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識 ——稱爲 session id，如果已包含一個session id則說明以前已經爲此客戶端創建過session，服務器就按照session id把這個 session檢索出來使用（如果檢索不到，可能會新建一個），如果客戶端請求不包含session id，則爲此客戶端創建一個session並且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個 session id將被在本次響應中返回給客戶端保存。
Session的實現方式
- 使用Cookie來實現
服務器給每個Session分配一個唯一的JSESSIONID，並通過Cookie發送給客戶端。
當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務器能夠找到這個客戶端對應的Session。
流程如下圖所示：
- 使用URL回顯來實現
URL回寫是指服務器在發送給瀏覽器頁面的所有鏈接中都攜帶JSESSIONID的參數，這樣客戶端點擊任何一個鏈接都會把JSESSIONID帶會服務器。
如果直接在瀏覽器輸入服務端資源的url來請求該資源，那麼Session是匹配不到的。
Tomcat對Session的實現，是一開始同時使用Cookie和URL回寫機制，如果發現客戶端支持Cookie，就繼續使用Cookie，停止使用URL回寫。如果發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到Session的時候，對頁面中的鏈接記得使用response.encodeURL() 。
與Cookie相關的HTTP擴展頭
1）Cookie：客戶端將服務器設置的Cookie返回到服務器；
2）Set-Cookie：服務器向客戶端設置Cookie；
3）Cookie2 (RFC2965)：客戶端指示服務器支持Cookie的版本；
4）Set-Cookie2 (RFC2965)：服務器向客戶端設置Cookie。
Cookie的流程
服務器在響應消息中用Set-Cookie頭將Cookie的內容回送給客戶端，客戶端在新的請求中將相同的內容攜帶在Cookie頭中發送給服務器。從而實現會話的保持。
流程圖如下所示：
Web緩存
什麼是Web緩存？
WEB緩存(cache)位於Web服務器和客戶端之間。
緩存會根據請求保存輸出內容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：如果是相同的URL，緩存直接使用副本響應訪問請求，而不是向源服務器再次發送請求。
HTTP協議定義了相關的消息頭來使WEB緩存儘可能好的工作。
緩存的優點
- 減少相應延遲：因爲請求從緩存服務器（離客戶端更近）而不是源服務器被相應，這個過程耗時更少，讓web服務器看上去相應更快。
- 減少網絡帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶可以節省帶寬費用，控制帶寬的需求的增長並更易於管理。
與緩存相關的HTTP擴展消息頭
- Expires：指示響應內容過期的時間，格林威治時間GMT
- Cache-Control：更細緻的控制緩存的內容
- Last-Modified：響應中資源最後一次修改的時間
- ETag：響應中資源的校驗值，在服務器上某個時段是唯一標識的。
- Date：服務器的時間
- If-Modified-Since：客戶端存取的該資源最後一次修改的時間，同Last-Modified。
- If-None-Match：客戶端存取的該資源的檢驗值，同ETag。
客戶端緩存生效的常見流程
服務器收到請求時，會在200 OK中回送該資源的Last-Modified和ETag頭，客戶端將該資源保存在cache中，並記錄這兩個屬性。當客戶端需要發送相同的請求時，會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的值分別是響應中Last-Modified和ETag頭的值。服務器通過這兩個頭判斷本地資源未發生變化，客戶端不需要重新下載，返回304響應。常見流程如下圖所示：
Web緩存機制
HTTP/1.1中緩存的目的是爲了在很多情況下減少發送請求，同時在許多情況下可以不需要發送完整響應。前者減少了網絡迴路的數量；HTTP利用一個「過期（expiration）」機制來爲此目的。後者減少了網絡應用的帶寬；HTTP用「驗證（validation）」機制來爲此目的。
HTTP定義了3種緩存機制：
1）Freshness：允許一個迴應消息可以在源服務器不被重新檢查，並且可以由服務器和客戶端來控制。例如，Expires迴應頭給了一個文檔不可用的時間。Cache-Control中的max-age標識指明瞭緩存的最長時間；
2）Validation：用來檢查以一個緩存的迴應是否仍然可用。例如，如果一個迴應有一個Last-Modified迴應頭，緩存能夠使用If-Modified-Since來判斷是否已改變，以便判斷根據情況發送請求；
3）Invalidation： 在另一個請求通過緩存的時候，常常有一個副作用。例如，如果一個URL關聯到一個緩存迴應，但是其後跟着POST、PUT和DELETE的請求的話，緩存就會過期。
HTTP代理
http代理服務器
代理服務器英文全稱是Proxy Server，其功能就是代理網絡用戶去取得網絡信息。形象的說：它是網絡信息的中轉站。
代理服務器是介於瀏覽器和Web服務器之間的一臺服務器，有了它之後，瀏覽器不是直接到Web服務器去取回網頁而是向代理服務器發出請求，Request信號會先送到代理服務器，由代理服務器來取回瀏覽器所需要的信息並傳送給你的瀏覽器。
而且，大部分代理服務器都具有緩衝的功能，就好像一個大的Cache，它有很大的存儲空間，它不斷將新取得數據儲存到它本機的存儲器上，如果瀏覽器所請求的數據在它本機的存儲器上已經存在而且是最新的，那麼它就不重新從Web服務器取數據，而直接將存儲器上的數據傳送給用戶的瀏覽器，這樣就能顯著提高瀏覽速度和效率。
更重要的是：Proxy Server(代理服務器)是Internet鏈路級網關所提供的一種重要的安全功能，它的工作主要在開放系統互聯(OSI)模型的對話層。
http代理服務器的主要功能
主要功能如下：
1）突破自身IP訪問限制，訪問國外站點。如：教育網、169網等網絡用戶可以通過代理訪問國外網站；
2）訪問一些單位或團體內部資源，如某大學FTP(前提是該代理地址在該資源的允許訪問範圍之內)，使用教育網內地址段免費代理服務器，就可以用於對教育 網開放的各類FTP下載上傳，以及各類資料查詢共享等服務；
3）突破中國電信的IP封鎖：中國電信用戶有很多網站是被限制訪問的，這種限制是人爲的，不同Serve對地址的封鎖是不同的。所以不能訪問時可以換一個國 外的代理服務器試試；
4）提高訪問速度：通常代理服務器都設置一個較大的硬盤緩衝區，當有外界的信息通過時，同時也將其保存到緩衝區中，當其他用戶再訪問相同的信息時， 則直接由緩衝區中取出信息，傳給用戶，以提高訪問速度；
5）隱藏真實IP：上網者也可以通過這種方法隱藏自己的IP，免受攻擊。
http代理圖示
http代理的圖示見下圖：
對於客戶端瀏覽器而言，http代理服務器相當於服務器。
而對於Web服務器而言，http代理服務器又擔當了客戶端的角色。
虛擬主機
什麼是虛擬主機
虛擬主機：是在網絡服務器上劃分出一定的磁盤空間供用戶放置站點、應用組件等，提供必要的站點功能與數據存放、傳輸功能。
所謂虛擬主機，也叫「網站空間」，就是把一臺運行在互聯網上的服務器劃分成多個「虛擬」的服務器，每一個虛擬主機都具有獨立的域名和完整的Internet服務器（支持WWW、FTP、E-mail等）功能。一臺服務器上的不同虛擬主機是各自獨立的，並由用戶自行管理。但一臺服務器主機只能夠支持一定數量的虛擬主機，當超過這個數量時，用戶將會感到性能急劇下降。
虛擬主機的實現原理
虛擬主機是用同一個WEB服務器，爲不同域名網站提供服務的技術。Apache、Tomcat等均可通過配置實現這個功能。
相關的HTTP消息頭：Host。
例如：Host: www.baidu.com
客戶端發送HTTP請求的時候，會攜帶Host頭，Host頭記錄的是客戶端輸入的域名。這樣服務器可以根據Host頭確認客戶要訪問的是哪一個域名。