Java Web開發(fā)實戰(zhàn)—HTTP協(xié)議—HTTP協(xié)議概述、HTTP請求、HTTP響應(yīng)、HTTP其他消息頭
時間：2023-07-18 17:36:02 | 來源：網(wǎng)站運營
時間：2023-07-18 17:36:02 來源：網(wǎng)站運營
Java Web開發(fā)實戰(zhàn)—HTTP協(xié)議—HTTP協(xié)議概述、HTTP請求、HTTP響應(yīng)、HTTP其他消息頭：
HTTP協(xié)議概述HTTP協(xié)議簡介https://www.zhihu.com/video/1575493347980009472HTTP是超文本傳輸協(xié)議（HyperText Transfer Protocol）的縮寫，它定義了客戶端和Web服務(wù)器相互通信的規(guī)則。
作為被Web應(yīng)用廣泛采納的數(shù)據(jù)傳輸協(xié)議，HTTP協(xié)議具有以下三個特點：
（1）HTTP協(xié)議基于標準的客戶端服務(wù)器模型，主要由請求和響應(yīng)構(gòu)成。與其他傳輸協(xié)議相比，它永遠都是客戶端發(fā)起請求，服務(wù)器接收到請求后做出響應(yīng)，如圖6.1所示。
圖6.1 HTTP的請求響應(yīng)模型
（2）HTTP協(xié)議允許傳輸任意類型的數(shù)據(jù)，它的傳輸速度很快，當客戶端向服務(wù)器請求服務(wù)時，需傳送請求方法和路徑。請求方法常用的有GET、POST等，每種方法規(guī)定了客戶端與服務(wù)器聯(lián)系的類型。
（3）HTTP協(xié)議是一個無狀態(tài)的協(xié)議。無狀態(tài)是指HTTP協(xié)議對于數(shù)據(jù)處理沒有記憶能力。這意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這導致每次連接傳送的數(shù)據(jù)量增大。
HTTP與TCP/IPhttps://www.zhihu.com/video/1575493405567864832講到HTTP協(xié)議，大家可能會將它和TCP/IP協(xié)議混淆。其實，它們之間有著嚴格區(qū)別。簡單概括，HTTP協(xié)議是TCP/IP協(xié)議的應(yīng)用層協(xié)議，是TCP/IP協(xié)議大家族的一員。
TCP/IP協(xié)議是互聯(lián)網(wǎng)最基本的協(xié)議，它規(guī)定了計算機相互通信所涉及的各個方面的內(nèi)容，如電纜的規(guī)格、IP地址的選定、尋找異地用戶的方法、雙方建立通信的順序等?？梢哉f，TCP/IP協(xié)議是互聯(lián)網(wǎng)相關(guān)的各類協(xié)議族的集合，其涵蓋的各類協(xié)議如圖6.2所示。
圖6.2 TCP/IP涵蓋的各類協(xié)議
TCP/IP協(xié)議最重要的特點是分層管理，按照分層結(jié)構(gòu)，TCP/IP協(xié)議自下而上可分為數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、應(yīng)用層，具體如表6.1所示。
表6.1 get與post方法的區(qū)別
| TCP/IP協(xié)議 | 相關(guān)通訊協(xié)議 |
| 應(yīng)用層 | HTTP | FTP | SMTP |
| POP3 | NFS | SSH |
| 傳輸層 | TCP | UDP | |
| 網(wǎng)絡(luò)層 | IP | ICMP | |
| 數(shù)據(jù)鏈路層 | LAN | ARP | WAN |
TCP/IP協(xié)議的每一層分別完成不同的功能，上層協(xié)議使用下層協(xié)議提供的服務(wù)。其中，數(shù)據(jù)鏈路層用來處理連接網(wǎng)絡(luò)的硬件范疇，包括硬件的設(shè)備驅(qū)動、網(wǎng)卡、光纖等物理可見部分。網(wǎng)絡(luò)層用來實現(xiàn)數(shù)據(jù)的選路和轉(zhuǎn)發(fā)，確定通信路徑。傳輸層用于定義數(shù)據(jù)封包的傳送、流程的控制、傳輸過程的偵測等。應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時通信的活動，HTTP即位于該層。
作為TCP/IP應(yīng)用層的協(xié)議，HTTP的實現(xiàn)建立在下層協(xié)議的服務(wù)之上，一次HTTP請求要通過從上到下多層協(xié)議才能完成，如圖6.3所示。
圖6.3 一次HTTP請求的過程
從圖6.3中可以看出，一次HTTP請求要經(jīng)過以下幾個步驟。
l 客戶端在應(yīng)用層（HTTP協(xié)議）發(fā)出獲取某個Web頁面的HTTP請求。
l 在傳輸層（TCP協(xié)議）把從應(yīng)用層收到的數(shù)據(jù)進行分割，并打上標記序號及端口號后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。
l 在網(wǎng)絡(luò)層（IP協(xié)議）增加通信目的地MAC地址后轉(zhuǎn)發(fā)給數(shù)據(jù)鏈路層。
l 接收端的服務(wù)器在數(shù)據(jù)鏈路層收到數(shù)據(jù)，按照順序往上層發(fā)送，一直到應(yīng)用層。當傳輸?shù)綉?yīng)用層，才算真正接收到由客戶端發(fā)過來的HTTP請求。
由此可見，HTTP協(xié)議的實現(xiàn)無法離開TCP/IP各層協(xié)議的支持。
HTTP的版本https://www.zhihu.com/video/1575493452556546048HTTP自誕生以來已經(jīng)歷了多個版本，這從側(cè)面反映了Web技術(shù)的快速發(fā)展。接下來，本書將對HTTP的相關(guān)版本做詳細講解。
1. HTTP 0.9HTTP 0.9是第一個版本的HTTP協(xié)議，它的結(jié)構(gòu)簡單，不支持請求頭，只允許獲取一種請求方法，同時也無法向服務(wù)器傳送太多信息。由于HTTP 0.9的功能單一，現(xiàn)在已很少使用，這里不再過多講解。
2. HTTP 1.0HTTP 1.0是第二個版本的HTTP協(xié)議。與HTTP0.9相比，它增加了如下特性。
l 增加請求的類型，如 HEAD、POST等。
l 添加請求和響應(yīng)消息的協(xié)議版本，響應(yīng)消息第一行以“HTTP/1.0”開始。
l 使用響應(yīng)碼來表示請求響應(yīng)消息的成功與否，如200表示成功。
l 請求與響應(yīng)支持頭域。
l 擴大了處理的數(shù)據(jù)類型，支持對多媒體流信息的處理。
與HTTP 0.9相比，HTTP 1.0版本擴展了功能，增加了應(yīng)用場景，因而被廣泛應(yīng)用。但隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，HTTP 1.0的不足之處也漸漸凸顯。按照TCP/IP協(xié)議，HTTP的請求響應(yīng)要建立在TCP連接之上，HTTP 1.0版本下的請求響應(yīng)過程如圖6.4所示。
圖6.4 HTTP 1.0版本下的請求響應(yīng)過程
從圖6.4可以看出，在HTTP 1.0條件下，一次TCP連接只能支持一次HTTP請求響應(yīng)，當服務(wù)器完成響應(yīng)后，當前TCP連接就要關(guān)閉，如果想要再次發(fā)送HTTP請求，需要重新建立一個TCP連接。假如現(xiàn)在有如下一段HTML代碼。
上面的HTML代碼中有三個<img>標記，并且這三個<img>標記指向了圖像的URL地址，當客戶端訪問這個HTML文件時，它首先要發(fā)出針對該網(wǎng)頁文件的HTTP請求，然后，它還要發(fā)出三個訪問圖片的HTTP請求，并且每次請求都要重新建立TCP連接，如此一來，勢必會影響系統(tǒng)的性能。
3. HTTP 1.1HTTP 1.1是第三個版本的HTTP協(xié)議，也是目前主流的HTTP協(xié)議版本。HTTP 1.1的一個重要特性是支持持久連接，也就是說，同一個TCP連接，可以同時處理多個請求并用一定的機制來保證各個請求之間的分離性。在HTTP 1.1版本下，客戶端與服務(wù)器的交互過程如圖6.5所示。
圖6.5 HTTP 1.1版本下的請求響應(yīng)過程
從圖6.5可以看出，服務(wù)器在給客戶端返回第一個HTTP響應(yīng)之后，TCP連接并沒有馬上關(guān)閉，瀏覽器可以在該TCP連接上繼續(xù)發(fā)送HTTP 請求。這種運作模式減少了網(wǎng)絡(luò)包，降低了新建和關(guān)閉連接造成的消耗和延遲。
HTTP與HTTPShttps://www.zhihu.com/video/1575493492658397184HTTP協(xié)議以明文方式傳送內(nèi)容，如果攻擊者截取了客戶端和服務(wù)器之間的傳輸報文，就可能竊取和篡改其中的信息。因此 HTTP 不適用于敏感信息的傳播，例如銀行卡、郵箱密碼等，這時就需要引入 HTTPS。
HTTPS是超文本傳輸安全協(xié)議(HyperText Transfer Protocol over Secure Socket Layer)的縮寫，是基于HTTP的安全信息通道，它使用安全套接字層（SSL）進行信息交換，簡而言之，HTTPS就是HTTP的安全版。
HTTPS協(xié)議的作用如下。
l 建立一個信息安全通道，保證數(shù)據(jù)傳輸?shù)陌踩?br>
l 認證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶端或服務(wù)器
與HTTP相比，HTTPS具有以下特點。
l 使用HTTPS協(xié)議需要到CA申請證書，一般免費證書較少，因此需要一定費用。
l HTTP采用明文傳輸傳輸數(shù)據(jù)，HTTPS 則是采用SSL對內(nèi)容加密后再傳輸。
l HTTPS使用和HTTP不同的連接方式，HTTP建立在TCP連接之上，HTTPS除了建立TCP連接之外，還要建立SSL連接。
l HTTPS與HTTP使用不同的端口，前者是443，后者是80。
簡而言之，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，大家應(yīng)注意理解它與HTTP協(xié)議的聯(lián)系與區(qū)別。
HTTP報文https://www.zhihu.com/video/1575493527324323840HTTP報文是客戶端和服務(wù)端相互通信時發(fā)送的數(shù)據(jù)塊。當客戶端訪問Web資源時，它會向服務(wù)器發(fā)送HTTP請求報文。服務(wù)器接收到請求消息后，會向客戶端返回HTTP響應(yīng)報文。HTTP請求報文和HTTP響應(yīng)報文統(tǒng)稱為HTTP報文。
HTTP報文是HTTP協(xié)議的重要環(huán)節(jié)，它傳遞著客戶端和服務(wù)端交互的細節(jié)。只有深入理解HTTP報文，才能更好的掌握和使用HTTP協(xié)議。由于HTTP報文對用戶是不可見的，開發(fā)者要想對其進行研究，需要借助專用的網(wǎng)絡(luò)查看工具，本書將使用版本為56.0的FireFox瀏覽器。FireFox瀏覽器從
http://www.firefox.com.cn/下載，下載完成后將其安裝到操作系統(tǒng)上。打開FireFox瀏覽器，界面如圖6.6所示。
圖6.6 FireFox瀏覽器打開界面
單擊右上角的
圖標，在菜單中選擇“開發(fā)者”→“附加組件”選項，瀏覽器出現(xiàn)“附件組件管理器”頁面，如圖6.7所示。
圖6.7 附加組件管理器
在附件組件管理器中選擇擴展選項，然后在頁面右上角
圖標右側(cè)的組件搜索框中輸入Firebug，出現(xiàn)Firebug的搜索結(jié)果，如圖6.8所示。
圖6.8 附加組件管理器
點擊Firebug右側(cè)的“安裝”按鈕，安裝完成后，在FireFox瀏覽器的工具欄出現(xiàn)
圖標，如圖6.9所示。
圖6.9 FireFox瀏覽器出現(xiàn)Firebug圖標
點擊瀏覽器工具欄中的Firebug圖標，啟動Firebug工具，這時在瀏覽器的下方出現(xiàn)Firebug的工具欄，如圖6.10所示。
圖6.10 Firebug工具欄
在瀏覽器的地址欄中輸入
http://www.qfedu.com訪問千鋒教育首頁，在Firebug工具欄可以看到瀏覽器與服務(wù)器的互動信息列表，如圖6.11所示。
圖6.11 使用FireFox查看HTTP信息
單擊URL地址左邊的“+”號，在展開的頭信息選項卡中可以看到HTTP報文，HTTP報文包含格式化后的響應(yīng)頭信息和請求頭信息。其中，請求頭具體如下。
響應(yīng)頭具體如下所示。
HTTP請求HTTP請求方法https://www.zhihu.com/video/1575493586694750208HTTP的請求方法規(guī)定了客戶端操作Web資源的方式，隨著版本的更新，HTTP 支持的請求方法越來越多。目前主流的HTTP1.1版本支持八種請求方法，具體如下。
l GET，向指定的URL請求Web資源。
l POST，向指定的URL提交數(shù)據(jù)（提交表單或上傳文件等），請求服務(wù)器處理。
l HEAD，從指定的資源獲取響應(yīng)消息頭。
l PUT，將網(wǎng)頁放置到指定URL位置。
l DELETE，請求服務(wù)器刪除指定URL標識的資源。
l OPTIONS，請求服務(wù)器告知其支持的功能，檢查服務(wù)器的性能。
l TRACE，請求服務(wù)器返回客戶端發(fā)送的請求信息，主要用于測試。
l CONNECT，請求服務(wù)器代替客戶端去訪問其它資源，主要用于HTTP代理。
下面通過一個表格對比它們的特性，具體如表6.2所示，大家在實際開發(fā)中應(yīng)根據(jù)功能需求酌情使用。
表6.2 get與post方法的區(qū)別
| 對比項 | GET | POST |
| 頁面刷新 | 沒有影響 | 數(shù)據(jù)會被再次提交 |
| 傳輸數(shù)據(jù)的大小 | 有限制 | 沒有限制 |
| 傳輸數(shù)據(jù)的類型 | 只允許ASCII字符 | 沒有限制，也允許二進制數(shù)據(jù) |
| 可見性 | 傳遞的參數(shù)在URL中顯示，對所有人可見 | 傳遞的參數(shù)不顯示在URL中 |
| 安全性 | 安全性較差，發(fā)送密碼等敏感信息不使用 | 安全性較好，發(fā)送的數(shù)據(jù)被隱藏 |
以上列舉了HTTP請求的八種方法，其中最常用的是GET和POST，接下來通過實例對這兩種請求方法進行演示。
（1）打開Eclipse，新建Web工程chapter06，在該工程的WebContent目錄下分別新建login01.html和login02.html，具體代碼如例書中6.1和例6.2所示。
兩個HTML文檔都定義了一個表單，不同的是，login01.html文檔采用GET方式提交，login02.html采用POST方式提交。
（2）將工程chapter06添加到Tomcat服務(wù)器，啟動Tomcat，打開Firefox瀏覽器，開啟Firebug工具，訪問http://localhost:8080/chapter06/login01.html，瀏覽器顯示的頁面如圖所示。
（3）在login01.html頁面中填寫姓名abc和密碼12345，單擊“提交” 按鈕，這時瀏覽器地址欄里的URL發(fā)生了變化，如圖所示。
從圖中可以看出，當提交login01.html頁面中的表單時，原有的URL后面加上了表單中的參數(shù)信息。這時，查看Firebug顯示的請求報文，發(fā)現(xiàn)請求行中的URL后也增加了表單中的參數(shù)信息，具體如下。
（4）接下來演示用POST方式提交表單，訪問http://localhost:8080/chapter06/login02.html，在login02.html頁面中填寫姓名def和密碼56789，單擊提交按鈕，這時瀏覽器地址欄里的URL沒有變化，如下圖所示。
5）點擊Firebug的POST標簽，發(fā)現(xiàn)請求報文中增加了表單中的參數(shù)信息，具體如下。
由此可見，在POST請求方式中，表單中的參數(shù)被作為實體內(nèi)容傳遞給服務(wù)器。
通過案例演示，大家應(yīng)該對GET和POST有了基本了解，下面通過一個表格來對比它們的特性，具體如表所示，大家在實際開發(fā)中應(yīng)根據(jù)功能需求選擇使用。
HTTP請求行https://www.zhihu.com/video/1575493622115594241HTTP請求行位于請求報文的第一行，由請求方法、URL、協(xié)議版本三個部分組成，具體示例如下。
POST /login.html HTTP/1.1
以上示例中，POST是請求方法，告訴服務(wù)器要執(zhí)行怎樣的操作，/login.html是URL，一般是服務(wù)器根目錄下的相對目錄，要以“/”開頭，HTTP/1.1是指這次請求采用的協(xié)議版本，各個部分之間以空格分割。
HTTP請求頭HTTP請求頭位于請求行之后，實際上是一個鍵/值對的列表，它包含了很多關(guān)于客戶端環(huán)境和請求內(nèi)容的附加信息。例如，請求頭可以聲明瀏覽器所用的語言、瀏覽器的類型、請求正文的長度、請求正文的類型等，具體示例如下。
在以上示例中，每個請求頭字段都由一個字段名和一個值構(gòu)成，中間用冒號隔開，頭字段之間以換行符分開。
為實現(xiàn)不同的功能，HTTP協(xié)議提供了多種請求頭字段，接下來，將對一些常用的請求頭字段進行講解。
1. Host在HTTP1.1版本中，當客戶端（通常是瀏覽器）發(fā)送請求時，該頭字段是必須要有的，它通常從URL中提取出來，用于指定被請求資源的主機名和端口號。例如，用戶在瀏覽器中輸入
http://www.qfedu.com，這次請求的HOST頭字段如下。
Host：
http://www.qfedu.com:80由于瀏覽器默認的端口是80，所以此處的80可以省略。
2. AcceptAccept用于指定客戶端可以接收的媒體類型。假如，瀏覽器希望接收gif格式的文件，可以發(fā)送包含image/gif的Accept請求頭，服務(wù)器檢測到瀏覽器的請求信息，可以在網(wǎng)頁中的img元素中使用gif類型的文件。
能作為Accept頭字段的媒體類型很多，常用的幾種如下。
Accept：text/html
表示客戶端希望接收HTML文本
Accept：application/xml
表示客戶端希望接收XML文本
Accept：image/jpg
表示客戶端希望接收jpg圖片
Accept：video/mpeg
表示客戶端希望接收mpeg視頻文件
Accept：application/zip
表示客戶端希望接收zip文件
Accept：image/*
表示客戶端希望接收所有image格式的圖片
Accept：*/*
表示客戶端希望接收所有格式的內(nèi)容
3. Accept-CharsetAccept-Charset用于指定客戶端可以接收的字符編碼。假如瀏覽器使用的是utf-8的字符集，則Accept-Charset頭字段的格式如下。
Accept-Charset: utf-8
常用的字符集還有ISO-8859-1、GB2312等，這里要提醒大家的是，Accept-Charset的字段值可以設(shè)置為多個，只需將它們以逗號分開即可。如果客戶端沒有發(fā)送Accept-Charset請求頭，則默認客戶端能接受任意字符集的數(shù)據(jù)。
4. Accept-EncodingAccept-Encoding用于指定客戶端有能力解碼的壓縮編碼類型，常用的壓縮編碼類型有g(shù)zip,、deflate等。Java語言中的Servlet能夠向支持gzip的客戶端返回經(jīng)gzip編碼的HTML頁面，這可以縮短下載時間，提升響應(yīng)速度。Accept-Encoding頭字段的格式如下。
Accept-Encoding: gzip, deflate
5. Accept-LanguageAccept-Language用于指定客戶端支持的語言類型，它可以指定多個國家或地區(qū)的語言，語言之間用逗號分開，Accept-Language頭字段的格式如下。
Accept-Language: zh-cn,zh-hk，en-us
其中，zh-cn代表簡體中文，zh-hk代表繁體中文，en-us代表美國英語，服務(wù)器會按照Accept-Language請求頭中設(shè)置的語言的順序，優(yōu)先返回位于前面的國家語言的網(wǎng)頁文檔。
6. User-AgentUser-Agent用于向服務(wù)器告知客戶端的名稱、版本、操作系統(tǒng)等信息。用戶在訪問某些網(wǎng)頁時，可能會看到一些歡迎信息，其中列出了當前用戶的操作系統(tǒng)信息以及瀏覽器屬性等，這些就是從User-Agent這個請求報頭中獲取的。User-Agent頭字段的格式如下。
7. Referer瀏覽器通過Referer請求頭向Web 服務(wù)器表明當前請求的超鏈接所在的URL，例如，如果用戶在千鋒教育主頁單擊扣丁學堂的鏈接，那么此次請求包含的Referer請求頭如下。
Referer:
http://www.qfedu.com/index.html如果本次請求不是通過超鏈接而是直接在瀏覽器地址欄輸入URL，那它就沒有Referer請求頭。
在開發(fā)中，Referer請求頭常被用于追蹤網(wǎng)站訪問者的來源，如果訪問者屬于惡意訪問，就可以對其進行阻止或屏蔽。
8. If-Match為減少網(wǎng)絡(luò)延遲、提升響應(yīng)速度，當用戶訪問已被客戶端緩存的頁面時，服務(wù)器會檢索該頁面是否有更新，如果沒有更新，服務(wù)器會通知客戶端訪問本地已緩存的頁面，這是HTTP的緩存機制。
HTTP的緩存機制可以通過If-Match請求頭和ETag響應(yīng)頭實現(xiàn)。當服務(wù)器向客戶端響應(yīng)網(wǎng)頁文件時，會傳送一些代表實體內(nèi)容特征的頭字段，具體如下。
ETag: “mark”
當客戶端再次向服務(wù)器請求這個頁面時，會使用If-Match頭字段附帶以前緩存的內(nèi)容，具體如下。
If-Match: “mark”
服務(wù)器收到請求后，會將If-Match請求頭的內(nèi)容和當前網(wǎng)頁中的實體內(nèi)容做比較，如果兩者相同，會直接通知客戶端訪問本地已緩存頁面；否則，返回新的頁面文件和ETag頭字段內(nèi)容。
9. If-Modified-Since和If-Match 類似，If-Modified-Since請求頭也用于實現(xiàn)HTTP的緩存機制。當服務(wù)器向客戶端響應(yīng)網(wǎng)頁文件時，會傳送該網(wǎng)頁文件的最后修改時間，具體如下。
Last-Modified: Thu, 30 Nov 2017 08:41:19 GMT
當客戶端再次向服務(wù)器請求這個頁面時，會使用If-Match頭字段告訴服務(wù)器它上次訪問該頁面的最后修改時間，具體如下。
If-Modified-Since： Thu, 30 Nov 2017 08:41:19 GMT
服務(wù)器收到請求后，會將If-Modified-Since請求頭傳遞的最后修改時間和當前網(wǎng)頁實際的最后修改時間做比較，如果兩者相同，會返回一個304狀態(tài)碼，表示客戶端緩存的文件是最新的，這時，客戶端仍使用本地已緩存頁面。
HTTP響應(yīng)HTTP響應(yīng)行https://www.zhihu.com/video/1575493705410318336HTTP響應(yīng)行位于響應(yīng)報文的第一行，由HTTP協(xié)議版本、狀態(tài)碼和狀態(tài)碼描述信息組成，具體如下。
HTTP/1.1 200 OK
其中，HTTP/1.1是通訊使用的協(xié)議版本，200是狀態(tài)碼，OK是狀態(tài)描述，請求行每個部分需要用空格分隔。
對于協(xié)議版本，大家已經(jīng)比較熟悉，這里不再過多陳述，接下來對HTTP的狀態(tài)碼進行詳細講解。
HTTP狀態(tài)碼反映了Web服務(wù)器處理客戶端請求的狀態(tài)，由三位數(shù)字組成，其中首位數(shù)字規(guī)定了狀態(tài)碼的類型，具體如下。
1xx:信息類(Information)，表示收到Web瀏覽器請求，正在進一步的處理中。
2xx:成功類(Successful)，表示用戶請求被正確接收、解析和處理。例如：200 OK。
3xx:重定向類(Redirection)，表示請求沒有成功，客戶必須采取進一步的動作。
4xx:客戶端錯誤(Client Error)，表示客戶端提交的請求有錯誤。
5xx:服務(wù)器錯誤(Server Error)，表示服務(wù)器不能完成對請求的處理。
以上列舉了狀態(tài)碼的五種類型，其中每種類型都有若干個狀態(tài)碼，為了便于大家理解和查詢，下面通過表格對不同類型的狀態(tài)碼進行解釋說明，如表6.3~表6.7所示。
表6.3 1xx狀態(tài)碼
| 狀態(tài)碼 | 說明 |
| 100（繼續(xù)） | 告知客戶端應(yīng)當繼續(xù)發(fā)送請求 |
| 101（切換協(xié)議） | 表示服務(wù)器遵從客戶端要變換通訊協(xié)議的請求，切換到另外一種協(xié)議 |
表6.4 2xx狀態(tài)碼
| 狀態(tài)碼 | 說明 |
| 200（成功） | 請求已成功，請求所希望的響應(yīng)頭或數(shù)據(jù)體將隨此響應(yīng)返回 |
| 201（已創(chuàng)建） | 請求已被實現(xiàn)，新的資源已經(jīng)依據(jù)請求建立，且其 URL已經(jīng)隨Location 響應(yīng)頭返回 |
| 202（已接受） | 服務(wù)器已接受請求，但尚未完成處理。最終該請求可能會也可能不會被執(zhí)行。這樣做的目的是允許服務(wù)器接受其他過程的請求，而不必讓客戶端一直保持與服務(wù)器的連接直到處理全部完成 |
| 203（非權(quán)威信息） | 服務(wù)器已成功處理請求，但返回的實體頭部元信息不是在原始服務(wù)器上有效的確定集合，而是來自本地或者第三方 |
| 204（無內(nèi)容） | 服務(wù)器成功處理了請求，但不需要返回任何實體內(nèi)容 |
| 205（重置內(nèi)容） | 服務(wù)器成功處理了請求，且沒有返回任何內(nèi)容，主要用于重置表單 |
| 206（部分內(nèi)容） | 服務(wù)器成功返回部分內(nèi)容，還有剩余內(nèi)容沒有返回。大文件分段下載、斷點續(xù)傳等通常使用此類響應(yīng)方式 |
表6.5 3xx狀態(tài)碼
| 狀態(tài)碼 | 說明 |
| 300（多項選擇） | 被請求的資源有一系列可供選擇的回饋信息，每個都有自己特定的地址和瀏覽器驅(qū)動的商議信息。用戶或瀏覽器能夠自行選擇一個首選的地址進行重定向 |
| 301（永久移動） | 請求的資源已被永久移動到新的URL，響應(yīng)信息會包含新的URL，客戶端會自動定向URL |
| 302（臨時移動） | 資源被臨時移動，客戶端繼續(xù)使用原有URL |
| 303（參見其他） | 與302類似，很多客戶端處理303狀態(tài)碼的方式和302相同 |
| 304（未修改） | 客戶端請求的資源未修改，服務(wù)器返回此狀態(tài)碼，不會返回任何資源 |
| 305（使用代理） | 告知客戶端其請求的資源必須通過代理訪問 |
| 307（臨時重定向） | HTTP 1.1版本新增的狀態(tài)碼，客戶端只能重定向GET請求 |
表6.6 4xx狀態(tài)碼
| 狀態(tài)碼 | 說明 |
| 400（請求無效） | 客戶端請求的語法錯誤，服務(wù)器無法理解 |
| 401（未經(jīng)授權(quán)） | 通知客戶端發(fā)送請求時要帶有身份認證信息 |
| 402（需要付款） | 保留備用的狀態(tài)碼 |
| 403（禁止） | 服務(wù)器理解客戶端的請求，但拒絕處理 |
| 404（找不到） | 服務(wù)器無法找到客戶端請求的資源 |
| 405（請求方法被禁止） | 客戶端本次使用的請求方法不被服務(wù)器允許 |
| 406（不能接受） | 服務(wù)器無法根據(jù)客戶端請求的內(nèi)容特性（如語言、字符集、壓縮編碼等）處理請求 |
| 407（需要驗證代理身份） | 請求要求代理的身份認證，與401類似，但請求者應(yīng)當使用代理進行授權(quán) |
| 408（請求超時） | 服務(wù)器等待客戶端發(fā)送的請求時間過長，超時 |
| 409（沖突） | 服務(wù)器完成客戶端的PUT請求時可能返回此狀態(tài)碼，請求的操作和當前資源狀態(tài)有沖突 |
| 410（離開） | 客戶端請求的資源已經(jīng)被移除，服務(wù)器不知道重定向到哪個位置 |
| 411（需要長度） | 服務(wù)器無法處理客戶端發(fā)送的不帶Content-Length請求頭的信息 |
| 412（先決條件錯誤） | 客戶端請求信息的先決條件在服務(wù)器中檢驗失敗 |
| 413（請求實體過大） | 由于請求的實體過大，服務(wù)器無法處理，因此拒絕請求 |
| 414（請求URI過長） | 請求的URI（通常是網(wǎng)址） 長度超過了服務(wù)器能夠解釋的長度，因此服務(wù)器拒絕對該請求 |
| 415（不支持的媒體類型） | 請求中提交的實體并不是服務(wù)器所支持的格式，因此請求被拒絕 |
| 416（請求的范圍無效） | 客戶端請求中指定的數(shù)據(jù)范圍與當前資源的可用范圍不重合 |
| 417（預期失?。?/td> | 服務(wù)器無法滿足請求頭Expect 中指定的預期內(nèi)容 |
表6.7 5xx狀態(tài)碼
| 狀態(tài)碼 | 說明 |
| 500（服務(wù)器內(nèi)部錯誤） | 服務(wù)器內(nèi)部出現(xiàn)錯誤，無法處理請求 |
| 501（未實現(xiàn)） | 服務(wù)器無法識別請求的方法，無法支持其對任何資源的請求 |
| 502（無效網(wǎng)關(guān)） | 作為網(wǎng)關(guān)或者代理的服務(wù)器發(fā)送請求時，從上游服務(wù)器接收到無效的響應(yīng) |
| 503（服務(wù)不可用） | 由于超載或系統(tǒng)維護，服務(wù)器當前無法處理請求 |
| 504（網(wǎng)關(guān)超時） | 作為網(wǎng)關(guān)或者代理的服務(wù)器，未及時從上游服務(wù)器獲取請求 |
| 505（HTTP版本不被支持） | 服務(wù)器不支持請求的HTTP協(xié)議的版本，無法完成處理 |
HTTP響應(yīng)頭https://www.zhihu.com/video/1575493746149474304HTTP響應(yīng)頭位于響應(yīng)行之后，和請求頭一樣，它實際上也是一個鍵/值對的列表，它包含了很多關(guān)于服務(wù)器屬性和響應(yīng)內(nèi)容的附加信息。例如，服務(wù)器名稱、頁面資源的最后修改時間、文檔編碼、內(nèi)容長度等，具體如下。
以上示例中，每個響應(yīng)頭字段都有一個字段名和一個值構(gòu)成，中間用冒號隔開，頭字段之間以換行符分開。
為實現(xiàn)不同的功能，HTTP協(xié)議提供了多種響應(yīng)頭字段，接下來，本節(jié)將對一些常用的響應(yīng)頭字段進行講解。
1. ServerServer頭字段用于指定服務(wù)器軟件名稱，它由Web服務(wù)器自己設(shè)置，Server頭字段的格式如下。
Server: Apache-Coyote/1.1
2. Accept-RangesAccept-Ranges頭字段用于指定服務(wù)器是否支持客戶端發(fā)送的Range請求頭請求資源，如果通知客戶端使用以bytes為單位的Range請求，則Accept-Ranges頭字段的格式如下。
Accept-Ranges: bytes
如果服務(wù)器通知客戶端不使用Range請求，則Accept-Ranges頭字段的格式如下。
Accept-Ranges: none
3. AgeAge頭字段用于指定頁面文件在客戶端或代理服務(wù)器中的緩存時間，值以秒為單位，具體格式如下。
Age: 12345
當客戶端訪問某個已緩存的頁面文件時，如果該頁面緩存在本地的持續(xù)時間小于Age頭字段的值，則客戶端直接使用緩存到本地的頁面內(nèi)容，否則，客戶端向服務(wù)器發(fā)出對該頁面文件的請求。
4. EtagEtag頭字段用于向客戶端傳遞代表實體內(nèi)容特征的標記信息，利用這些標記信息，客戶端可以識別在不同時間獲得的同一路徑下的資源是否相同。Etag頭字段通常和If-Match請求頭配合使用，實現(xiàn)HTTP的緩存機制。Etag頭字段的格式如下。
Etag: “mark”
5. LocationLocation頭字段通常與302狀態(tài)碼配合使用，用于通知客戶端獲取資源的新地址，將客戶端引向另一個資源，它的值通常是一個URL，具體格式如下。
Location:
http://www.qfedu.comHTTP其他消息頭通用消息頭https://www.zhihu.com/video/1575493781952069632在HTTP報文中，有些消息頭既可以用于請求，也可以用于響應(yīng)，下面，本書將對一些常用的通用消息頭作詳細講解。
1. Cache-ControlCache-Control消息頭用于控制請求和響應(yīng)遵循的緩存機制。Cache-Control的值可以為public、private、no-cache、no-store、max-age、must-revalidated等，在一個頭字段中可以設(shè)置多個值，這些值之間用逗號分隔，具體格式如下。
Cache-Control： no-cache,no-store,must-revalidated
根據(jù)瀏覽方式，Cache-Control消息頭的值的作用也不同，主要分為以下幾種。
1）打開新窗口
當Cache-Control消息頭的值為private、no-cache、must-revalidate時，打開新窗口訪問頁面文件時會重新訪問服務(wù)器。如果指定了max-age值，那么在此值內(nèi)的時間里就不會重新訪問服務(wù)器。
2）在地址欄回車
當Cache-Control消息頭的值為private或must-revalidate時，只有第一次請求頁面文件時會訪問服務(wù)器，以后就不再訪問，而是直接讀取本地緩存。當Cache-Control消息頭的值為no-cache時，每次都要訪問服務(wù)器。當Cache-Control消息頭的值為max-age時，在過期之前不會重復訪問。
3）按后退按扭
當Cache-Control消息頭的值為private、must-revalidate、max-age時，不會重復訪問服務(wù)器，當Cache-Control消息頭的值為no-cache，每次都重復訪問。
4）按刷新按扭
無論Cache-Control消息頭為何值，客戶端都會重復訪問服務(wù)器。
2. ConnectionConnection消息頭用于指定客戶端與服務(wù)器之間是否建立持久連接。Connection頭字段的格式如下所示。
Connection: keep-alive
keep-alive代表持久連接。當一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器，會繼續(xù)使用這條已經(jīng)建立的連接。
Connection: close
close代表服務(wù)器完成響應(yīng)后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會關(guān)閉，當客戶端再次發(fā)送請求，需要重新建立TCP連接。
3. DateDate消息頭表示消息發(fā)送的時間，它的值為GMT格式，具體格式如下。
Date: Thu, 30 Nov 2017 02:45:15 GMT
一般情況下，無論是請求還是響應(yīng)，都會傳送Date消息頭。
4. ViaVia消息頭用于指定HTTP請求途徑的代理服務(wù)器使用的協(xié)議和主機名。當HTTP請求到達第一個代理服務(wù)器時，該服務(wù)器會在自己發(fā)出的請求里面添加Via 消息頭并填上自己的相關(guān)信息，當下一個代理服務(wù)器收到第一個代服務(wù)器的請求時，會在自己發(fā)出的請求中復制前一個代理服務(wù)器的請求的Via頭部，并把自己的相關(guān)信息加到后面，依此類推，Via消息頭的具體格式如下所示。
Via: HTTP/1.1 Proxy1, HTTP/1.1 Proxy
5. WarningWarning消息頭主要用于提示一些警告信息，具體格式如下。
Warning: 110 Response is stale
以上Warning消息頭表示請求已過時。
實體消息頭實體消息頭用于描述HTTP傳送的實體內(nèi)容的屬性，它既可以包含在請求報文，也可以包含在響應(yīng)報文中，下面本書將對常用的實體消息頭作詳細講解。
1. Content-EncodingContent-Encoding消息頭用于表示實體內(nèi)容的編碼方式，客戶端應(yīng)按照指定編碼方式請求資源。Content-Encoding消息頭的格式如下。
Content-Encoding: gzip
2. Content-LanguageContent-Language消息頭用于告知客戶端實體內(nèi)容支持的國家或地區(qū)的語言類型，常見的有zh-cn、cn-us等。Content-Language消息頭的格式如下。
Content-Language: zh-cn
3. Content-LengthContent-Length消息頭用于告知客戶端實體內(nèi)容的長度，以方便客戶端辨別每個相應(yīng)內(nèi)容的開始和結(jié)束位置。Content-Length消息頭的格式如下所示。
Content-Length: 348
4. Content-LocationContent-Location消息頭用于給出與實體內(nèi)容相對應(yīng)的URL，具體格式如下。
Content-Location: /index.htm
5. Content-MD5Content-MD5消息頭用于提供實體內(nèi)容的MD5校驗值，驗證數(shù)據(jù)完整性以及確認傳輸是否到達。Content-MD5消息頭的格式如下。
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
6. Content-RangeContent-Range消息頭告知客戶端實體內(nèi)容的哪個部分符合HTTP請求的范圍。以字節(jié)為單位。Content-Range消息頭的格式如下。
Content-Range: bytes 21010-47021/47022
7. ExpiresExpires消息頭用來控制緩存的失效日期，它的值為GMT格式，其格式如下。
Expires: Thu, 30 Nov 2017 02:45:15 GMT
8. Last-ModifiedLast-Modified消息頭用于指明頁面文件最終修改的時間。在瀏覽器第一次請求某一個URL時，服務(wù)器響應(yīng)回頁面內(nèi)容，同時有一個Last-Modified消息頭標記此文件在服務(wù)器端最后被修改的時間。Last-Modified消息頭的格式如下。
Last-Modified: Thu, 30 Nov 2017 02:45:15 GMT
小結(jié) ：Java Web開發(fā)實戰(zhàn)—HTTP協(xié)議—HTTP協(xié)議概述、HTTP請求、HTTP響應(yīng)、HTTP其他消息頭主要講解了HTTP協(xié)議的相關(guān)知識，包括HTTP協(xié)議概述、HTTP請求、HTTP響應(yīng)、HTTP的其他消息頭等。通過本章知識的學習，大家要能夠理解HTTP的概念、特性及工作機制，區(qū)分HTTP與HTTPS，掌握HTTP的POST和GET請求方法，理解常用的HTTP消息頭的用法，為后面的學習做好準備。
關(guān)鍵詞：協(xié)議,響應(yīng),請求,實戰(zhàn)
在線咨詢