Apache之HTTP協議

時間 2020-07-23

標籤 apache http 協議欄目 Apache 简体版

原文原文鏈接

HTTP(Hypertext Transfer Protocol)超文本傳輸協議。是一種詳細規定了客戶端瀏覽器和萬維網服務器之間相互通信的規則，經過因特網傳送萬維網文檔的數據傳送協議。
html

HTTP的前世此生

超文本傳輸協議的前身是Xanadu項目，超文本的概念是泰德.納爾森在1960年提出的。而HTTP在1989年誕生在CERN(歐洲量子物理實驗室)。1990年12月，超文本協議在CERN首次上線。1991年夏天，繼Telnet等協議以後，超文本傳輸協議正式成爲互聯網諸多協議的一份子。nginx

HTTP誕生的緣由：爲了實現從一臺計算機上獲取並顯示存放在多臺計算機裏的文件、數據、圖片和其餘類型的文件而誕生HTTP協議。由於在當時其餘諸多已經誕生的協議解決不了這個問題。例如：Telnet、SMTP、POP三、IAMP四、FTP等。因此HTTP協議應運而生。web

HTTP協議的版本

HTTP 0.9chrome

HTTP 0.9做爲HTTP協議的第一個成熟版本。此版本功能很是薄弱。瀏覽器

1）請求只有一行緩存

2）沒有HTTP頭部信息和錯誤代碼信息安全

3）只能接收一種類型的數據：純文本服務器

4）只有一種方法：GETcookie

HTTP 1.0
網絡

隨着互聯網的發展，HTTP 0.9已經不能知足互聯網發展的需求。所以HTTP 1.0就這樣誕生了。HTTP 1.0的最大改變是引入了POST方法，使得客戶端經過HTML表單向服務器發送數據成爲可能。從而實現了客戶端和服務器端的數據交互。這是WEB應用程序的一個基礎。另外一個巨大的改變是引入了HTTP頭，使得HTTP協議不只能返回錯誤代碼，而且藉助於MIME技術可以傳輸更爲豐富的文件類型，再也不侷限於純文本。還能夠是圖片、動畫等其餘文件格式。

除此以外，還容許保持鏈接，即一次TCP鏈接，能夠實現屢次通信。HTTP 1.0默認是傳輸一次數據後就關閉鏈接。

HTTP 1.1

2000年5月，HTTP 1.1誕生。HTTP 1.1並不像HTTP 1.0對HTTP 0.9那樣的革命性。可是對HTTP 1.0作了不少功能性的加強。

1）增長了Host頭。

使得GET後面只需使用相對路徑

使得一臺主機可使用多個域名

2）引入了Range頭

使得客戶端經過HTTP下載時只下載內容的一部分，使得多線程下載成爲可能

HTTP協議的特色

1）支持C/S模式。支持基本認證和安全認證

2）簡單快速。

客戶端向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶端與服務器端聯繫的不一樣類型。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通信速度快。

3）靈活。

HTTP協議容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

4）HTTP 0.9和HTTP 1.0使用非持續鏈接：限制每次鏈接只處理一個請求，服務器處理完客戶端的請求，並收到客戶端的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

HTTP 1.1使用持續鏈接：沒必要爲每一個Web對象建立一個新的鏈接，一個鏈接能夠傳送多個對象。

5）無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事物處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。

HTTP實現原理

在TCP/IP協議棧中的位置：

HTTP協議一般承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了咱們常說的HTTPS。以下圖所示：

默認HTTP的端口號爲80，HTTPS的端口號爲443。

HTTP的請求響應模型：

HTTP協議永遠都是客戶端發起請求，服務器回送響應。以下圖所示：

這樣就限制了使用HTTP協議，沒法實如今客戶端沒有發起請求的時候，服務器將消息推送給客戶端。

HTTP協議是一個無狀態的協議，同一個客戶端的此次請求和上次請求是沒有對應關係。

工做流程：

一次HTTP操做稱爲一個事務，其工做過程可分爲四步：

1）首先客戶機與服務器須要創建鏈接。只要單擊某個超級連接，HTTP的工做開始。

2）創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。

3）服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。

4）客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。

若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來講，這些過程是由HTTP本身完成的，用戶只要用鼠標點擊，等待信息顯示就能夠了。

簡化版：

1，創建鏈接

2，接收請求

3，處理請求

4，獲取資源

5，構建響應

6，回送響應

7，記錄日誌

HTTP的幾個重要概念

URI、URL、URN：

URI：Uniform Resource Identifier，統一資源標識符；

URL：Uniform Resource Locator，統一資源定位符；

URN：Uniform Resource Name，統一資源命名符

其中，URL,URN是URI的子集。

Web上地址的基本形式是URI,它表明通用資源標識符。有兩種形式：

URL：目前URI的最廣泛形式就是無處不在的URL或統一資源定位器。

URN：URL的一種更新形式，統一資源名稱(URN, Uniform Resource Name)不依賴於位置，而且有可能減小失效鏈接的個數。可是其流行還需假以時日，由於它須要更精密軟件的支持。

URI格式：

scheme://[username:password@]HOST:port/path/to/source

鏈接(Connection)：

一個傳輸層的實際環流，它是創建在兩個相互通信的應用程序之間。

在http1.1，request和reponse頭中都有可能出現一個connection的頭，此header的含義是當client和server通訊時對於長連接如何進行處理。

在http1.1中，client和server都是默認對方支持長連接的，若是client使用http1.1協議，但又不但願使用長連接，則須要在header中指明connection的值爲close；若是server方也不想支持長連接，則在response中也須要明確說明connection的值爲close。不論request仍是response的header中包含了值爲close的connection，都代表當前正在使用的tcp連接在當天請求處理完畢後會被斷掉。之後client再進行新的請求時就必須建立新的tcp連接了.

消息(Message):

HTTP通信的基本單位，包括一個結構化的八元組序列並經過鏈接傳輸。

請求(Request):

一個從客戶端到服務器的請求信息包括應用於資源的方法、資源的標識符和協議的版本號。

響應(Response):

一個從服務器返回的信息包括HTTP協議的版本號、請求的狀態(例如「成功」或「沒找到」)和文檔的MIME類型。

資源(Resource):

由URI標識的網絡數據對象或服務。

實體(Entity):

數據資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應信息中。一個實體包括實體頭信息和實體的自己內容。

客戶機(Client):

一個爲發送請求目的而創建鏈接的應用程序。

用戶代理(UserAgent):

初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。

服務器(Server):

一個接受鏈接並對請求返回信息的應用程序。

源服務器(OriginServer):

是一個給定資源能夠在其上駐留或被建立的服務器。

代理(Proxy):

一箇中間程序，它能夠充當一個服務器，也能夠充當一個客戶機，爲其它客戶機創建請求。請求是經過可能的翻譯在內部或通過傳遞到其它的服務器中。一個代理在發送請求信息以前，必須解釋而且若是可能重寫它。

代理常常做爲經過防火牆的客戶機端的門戶，代理還能夠做爲一個幫助應用來經過協議處理沒有被用戶代理完成的請求。

網關(Gateway):

一個做爲其它服務器中間媒介的服務器。與代理不一樣的是，網關接受請求就好象對被請求的資源來講它就是源服務器；發出請求的客戶機並無意識到它在同網關打交道。

網關常常做爲經過防火牆的服務器端的門戶，網關還能夠做爲一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。

通道(Tunnel):

是做爲兩個鏈接中繼的中介程序。一旦激活，通道便被認爲不屬於HTTP通信，儘管通道多是被一個HTTP請求初始化的。當被中繼的鏈接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通信時通道被常用。

緩存(Cache):

反應信息的局域存儲。

HTTP協議頭

HTTP頭按照其不一樣的做用，分爲四類：

1）通用頭(General Header)

通用頭便可以包含在HTTP請求中，也能夠包含在HTTP響應中。通用頭的做用是描敘HTTP協議自己。好比描敘HTTP是否持續鏈接的Connection頭，HTTP發送日期的Date頭，描述HTTP所在的TCP鏈接時間的Keep-Alive頭，用於緩存控制的Cache-Control頭等。

2）實體頭(Entity Header)

實體頭是那些描敘HTTP信息的頭。便可出如今HTTP POST方法的請求中，也能夠出如今HTTP響應中。例如Content-Type和Content-length都是描述實體的類型和大小的頭都屬於實體頭。其它還有用於描述實體的Content-Language,Content-MD5,Content-Encoding以及控制實體緩存的Expires和Last-Modifies頭等。

常見的實體頭以下：

l Allow：服務器支持哪些請求方法（如GET、POST等）；

l Content-Encoding：文檔的編碼（Encode）方法，例如：gzip，見「2.5 響應頭」；

l Content-Language：內容的語言類型，例如：zh-cn；

l Content-Length：表示內容長度，eg：80，可參考「2.5響應頭」；

l Content-Location：表示客戶應當到哪裏去提取文檔

l Content-MD5：MD5 實體的一種MD5摘要，用做校驗和。發送方和接受方都計算MD5摘要，接受方將其計算的值與此頭標中傳遞的值進行比較。Eg1：Content-MD5: <base64 of 128 MD5 digest>。Eg2：dfdfdfdfdfdfdff==；

l Content-Range：隨部分實體一同發送；標明被插入字節的低位與高位字節偏移，也標明此實體的總長度。Eg1：Content-Range: 1001-2000/5000，eg2：bytes 2543-4532/7898

l Content-Type：標明發送或者接收的實體的MIME類型。Eg：text/html; charset=GB2312 主類型/子類型；

l Expires：爲0證實不緩存；

l Last-Modified：WEB 服務器認爲對象的最後修改時間，好比文件的最後修改時間，動態頁面的最後產生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT.

3）請求頭(HTTP Request Header)

請求頭是那些由客戶端發往服務器端以便幫助服務器端更好的知足客戶端請求的頭。請求頭只能出如今HTTP請求中。好比告訴服務器只接收某種響應內容的Accept頭，發送Cookies的Cookie頭，顯示請求主機域的HOST頭，用於緩存的If-Match,If-Match-Since,If-None-Match頭，用於只取HTTP響應信息中部分信息的Range頭，用於附屬HTML相關請求引用的Referee頭等。

常見請求頭以下：

l Accept：瀏覽器可接受的MIME類型；

l Accept-Charset：瀏覽器可接受的字符集；

l Accept-Encoding：瀏覽器可以進行解碼的數據編碼方式，好比gzip。Servlet可以向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這能夠減小5到10倍的下載時間；

l Accept-Language：瀏覽器所但願的語言種類，當服務器可以提供一種以上的語言版本時要用到；

l Authorization：受權信息，一般出如今對服務器發送的WWW-Authenticate頭的應答中；

l Connection：表示是否須要持久鏈接。若是Servlet看到這裏的值爲「Keep-Alive」，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久鏈接），它就能夠利用持久鏈接的優勢，當頁面包含多個元素時（例如Applet，圖片），顯著地減小下載所須要的時間。要實現這一點，Servlet須要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，而後在正式寫出內容以前計算它的大小；

l Content-Length：表示請求消息正文的長度；

l Cookie：這是最重要的請求頭信息之一；

l From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它；

l Host：初始URL中的主機和端口；

l If-Modified-Since：只有當所請求的內容在指定的日期以後又通過修改才返回它，不然返回304「Not Modified」應答；

l Pragma：指定「no-cache」值表示服務器必須返回一個刷新後的文檔，即便它是代理服務器並且已經有了頁面的本地拷貝；

l Referer：包含一個URL，用戶從該URL表明的頁面出發訪問當前請求的頁面。

l User-Agent：瀏覽器類型，若是Servlet返回的內容與瀏覽器類型有關則該值很是有用；

l UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標準的請求頭，表示屏幕大小、顏色深度、操做系統和CPU類型。

4）響應頭(HTTP Response Header)

HTTP響應頭是那些描述HTTP響應自己的頭，這裏並不包含描述HTTP響應中第三部分也就是HTTP信息的頭（這部分由實體頭負責）。好比說定時刷新的Refresh頭，當遇到503錯誤時自動重試的Retry-After頭，顯示服務器信息的Server頭，設置COOKIE的Set-Cookie頭，告訴客戶端能夠部分請求的Accept-Ranges頭等。

常見響應頭以下：

l Allow：服務器支持哪些請求方法（如GET、POST等）；

l 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頁面，爲其餘瀏覽器返回普通頁面；

l Content-Length：表示內容長度。只有當瀏覽器使用持久HTTP鏈接時才須要這個數據。若是你想要利用持久鏈接的優點，能夠把輸出文檔寫入ByteArrayOutputStram，完成後查看其大小，而後把該值放入Content-Length頭，最後經過byteArrayStream.writeTo(response.getOutputStream()發送內容；

l Content-Type：表示後面的文檔屬於什麼MIME類型。Servlet默認爲text/plain，但一般須要顯式地指定爲text/html。因爲常常要設置Content-Type，所以HttpServletResponse提供了一個專用的方法setContentTyep。可在web.xml文件中配置擴展名和MIME類型的對應關係；

l Date：當前的GMT時間。你能夠用setDateHeader來設置這個頭以免轉換時間格式的麻煩；

l Server：服務器軟件名稱及版本。

l Age：響應給客戶端的文檔能夠緩存多長時間

l Public：

l Vary：

l Set-Cookie：

l Set-Cookie2：

l Expires：指明應該在何時認爲文檔已通過期，從而再也不緩存它。

l Last-Modified：文檔的最後改動時間。客戶能夠經過If-Modified-Since請求頭提供一個日期，該請求將被視爲一個條件GET，只有改動時間遲於指定時間的文檔纔會返回，不然返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置；

l Location：表示客戶應當到哪裏去提取文檔。Location一般不是直接設置的，而是經過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼爲302；

l Refresh：表示瀏覽器應該在多少時間以後刷新文檔，以秒計。除了刷新當前文檔以外，你還能夠經過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。注意這種功能一般是經過設置HTML頁面HEAD區的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">實現，這是由於，自動刷新或重定向對於那些不能使用CGI或Servlet的HTML編寫者十分重要。可是，對於Servlet來講，直接設置Refresh頭更加方便。注意Refresh的意義是「N秒以後刷新本頁面或訪問指定頁面」，而不是「每隔N秒刷新本頁面或訪問指定頁面」。所以，連續刷新要求每次都發送一個Refresh頭，而發送204狀態代碼則能夠阻止瀏覽器繼續刷新，無論是使用Refresh頭仍是<META HTTP-EQUIV="Refresh" ...>。注意Refresh頭不屬於HTTP 1.1正式規範的一部分，而是一個擴展，但Netscape和IE都支持它。

HTTP請求

HTTP請求由三部分組成，分別是：請求行、消息報頭、請求正文

請求行以一個方法符開頭，以空格分開，後面跟着請求的URI和協議的版本，格式以下：

Method Request-URI HTTP-Version CRLF

Method表示請求方法；

Request-URI是一個統一資源標識符，也就是資源路徑；

HTTP-Version表示HTTP協議版本；

CRLF表示回車和換行。

請求方法：

GET 請求獲取Request-URI所標識的資源

POST 在Request-URI所標識的資源後附加新的數據,經常使用於提交表單

HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭

PUT 請求服務器存儲一個資源，並用Request-URI做爲其標識

DELETE 請求服務器刪除Request-URI所標識的資源

TRACE 請求服務器回送收到的請求信息，主要用於測試或診斷

能夠追蹤一次請求中間所通過的代理服務器有哪些

CONNECT 保留未來使用

OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求

能夠用來獲取服務器端資源支持的方法

HTTP響應

在接收和解釋請求消息後，服務器返回一個HTTP響應消息。

HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文

狀態行格式以下：

HTTP-Version Status-Code Reason-Phrase CRLF

HTTP-Version表示服務器HTTP協議的版本；

Status-Code表示服務器發回的響應狀態代碼；

Reason-Phrase表示狀態代碼的文本描述。

狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：

1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--信息不完整須要進一步補充
4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現
5xx：服務器端錯誤--服務器未能實現合法的請求

常見http響應狀態碼：

請求收到，繼續處理：

100 客戶端必須繼續發出請求

101 客戶端要求服務器根據請求轉換HTTP協議版本

操做成功收到，分析，接受：

200 交易成功

201 提示知道新文件的URL

202 接受和處理、但處理未完成

203 返回信息不肯定或不完整

204 請求收到，但返回信息爲空

205 服務器完成了請求，用戶代理必須復位當前已經瀏覽過的文件

206 服務器已經完成了部分用戶的GET請求

重定向：

300 請求的資源可在多處獲得

301 永久重定向，在Location響應首部的值仍爲當前URL(隱式重定向)

302 臨時重定向，在Location響應首部的值仍爲新的URL(顯示重定向)

303 建議客戶端訪問其餘URL或訪問方式

304 Not Modified 請求的資源沒有改變能夠繼續使用緩存

305 請求的資源必須從服務器指定的地址獲得

306 前一版本HTTP中使用的代碼，現行版本中再也不使用

307 聲明請求的資源臨時性刪除

客戶端錯誤：

400 錯誤請求，如語法錯誤

401 未受權

HTTP 401.1 未受權，登陸失敗

HTTP 401.2 未受權，服務器配置問題致使登陸失敗

HTTP 401.3 ACL 禁止訪問資源

HTTP 401.4 未受權受權被篩選器拒絕

HTTP 401.5 未受權 ISAPI或CGI受權失敗

402 保留有效ChargeTo頭響應

403 禁止訪問

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

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頭字段指定的指望值，若是是代理服務器，多是下一級服務器不能知足請求長

服務器端錯誤:

500 - 內部服務器錯誤

　　 HTTP 500.100 - 內部服務器錯誤

　　 HTTP 500-11 服務器關閉

　　 HTTP 500-12 應用程序從新啓動

　　 HTTP 500-13 - 服務器太忙

　　 HTTP 500-14 - 應用程序無效

　　 HTTP 500-15 - 不容許請求

501 - 未實現

502 - 網關錯誤

503 - 服務不可用

504 - 網關超時

使用Telnet手工獲取HTTP Server資源

1，發起鏈接請求：

2，請求並獲取HTTP資源:

HTTP狀態保持

HTTP 協議自己是無狀態的，這與HTTP協議原本的目的是相符的，客戶端只須要簡單的向服務器請求下載某些文件，不管是客戶端仍是服務器都沒有必要紀錄彼此過去的行爲，每一次請求之間都是獨立的，比如一個顧客和一個自動售貨機或者一個普通的（非會員制）大賣場之間的關係同樣。

然而聰明（或者貪心？）的人們很快發現若是可以提供一些按需生成的動態信息會使web變得更加有用，就像給有線電視加上點播功能同樣。這種需求一方面迫使HTML逐步添加了表單、腳本、DOM等客戶端行爲，另外一方面在服務器端則出現了CGI規範以響應客戶端的動態請求，做爲傳輸載體的HTTP協議也添加了文件上載、 cookie這些特性。其中cookie的做用就是爲了解決HTTP協議無狀態的缺陷所做出的努力。至於後來出現的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緩存的優勢：

1）減小相應延遲：由於請求從緩存服務器（離客戶端更近）而不是源服務器被相應，這個過程耗時更少，讓web服務器看上去相應更快。

2）減小網絡帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶能夠節省帶寬費用，控制帶寬的需求的增加並更易於管理。

與緩存相關的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的請求的話，緩存就會過時。

斷點續傳和多線程下載的實現原理

q HTTP協議的GET方法，支持只請求某個資源的某一部分；

q 206 Partial Content 部份內容響應；

q Range 請求的資源範圍；

q Content-Range 響應的資源範圍；

q 在鏈接斷開重連時，客戶端只請求該資源未下載的部分，而不是從新請求整個資源，來實現斷點續傳。

分塊請求資源實例：

Eg1：Range: bytes=306302- ：請求這個資源從306302個字節到末尾的部分；

Eg2：Content-Range: bytes 306302-604047/604048：響應中指示攜帶的是該資源的第306302-604047的字節，該資源共604048個字節；

客戶端經過併發的請求相同資源的不一樣片斷，來實現對某個資源的併發分塊下載。從而達到快速下載的目的。目前流行的FlashGet和迅雷基本都是這個原理。

多線程下載的原理：

q 下載工具開啓多個發出HTTP請求的線程；

q 每一個http請求只請求資源文件的一部分：Content-Range: bytes 20000-40000/47000；

q 合併每一個線程下載的文件。

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代理服務器至關於服務器。

而對於Web服務器而言，http代理服務器又擔當了客戶端的角色

虛擬主機的實現

什麼是虛擬主機：

虛擬主機：是在網絡服務器上劃分出必定的磁盤空間供用戶放置站點、應用組件等，提供必要的站點功能與數據存放、傳輸功能。

所謂虛擬主機，也叫「網站空間」就是把一臺運行在互聯網上的服務器劃分紅多個「虛擬」的服務器，每個虛擬主機都具備獨立的域名和完整的Internet服務器（支持WWW、FTP、E-mail等）功能。一臺服務器上的不一樣虛擬主機是各自獨立的，並由用戶自行管理。但一臺服務器主機只可以支持必定數量的虛擬主機，當超過這個數量時，用戶將會感到性能急劇降低。