一.HTTP協(xié)議

請求路徑的格式

請求協(xié)議://主鍵或IP地址:端口號/站點名（項目對外訪問路徑）/項目中的資源路徑[?參數(shù)名=參數(shù)值&參數(shù)名=參數(shù)值]

二、HTTP協(xié)議的演進

　　HTTP（HyperText?Transfer?Protocol）協(xié)議是基于TCP的應(yīng)用層協(xié)議，它不關(guān)心數(shù)據(jù)傳輸?shù)募毠?jié)，主要是用來規(guī)定客戶端和服務(wù)端的數(shù)據(jù)傳輸格式，最初是用來向客戶端傳輸HTML頁面的內(nèi)容。默認(rèn)端口是80。

　　1.HTTP 0.9版本　　1991年

　　這個版本就是最初用來向客戶端傳輸HTML頁面的，所以只有一個GET命令，然后服務(wù)器返回客戶端一個HTML頁面，不能是其他格式。利用這個版本完全可以構(gòu)建一個簡單的靜態(tài)網(wǎng)站了。

　　2.HTTP 1.0版本　　1996年

　　1.0版本是改變比較大的，奠定了現(xiàn)在HTTP協(xié)議的基礎(chǔ)。這個版本的協(xié)議不僅可以傳輸HTML的文本頁面，還可以傳輸其他二進制文件，例如圖片、視頻。而且還增加了現(xiàn)在常用的POST和HEAD命令。請求消息和響應(yīng)消息也不是單一的了，規(guī)定了一些元數(shù)據(jù)字段。例如字符集、編碼、狀態(tài)響應(yīng)碼等。

　　3.HTTP 1.1版本　　1997年

　　實際上是在1.0版本之后半年時間又發(fā)布了一個版本，這個版本在1.0版本的基礎(chǔ)上更加完善了。這個版本增加了持久連接，就是說之前版本的協(xié)議一次請求就是一次TCP連接，請求完成后這個連接就關(guān)閉掉了。眾所周知TCP協(xié)議是可靠的，建立連接需要3次握手，斷開連接需要4次揮手，并且TCP有流量控制和擁塞控制，有慢開始機制，剛建立連接時傳輸比較慢，這是比較耗費資源的。一個豐富的頁面會有許多圖片、表單和超鏈接。這樣的話就會有多次的HTTP請求，所以在這個版本上默認(rèn)不關(guān)閉TCP連接也不用聲明Connection: keep-alive字段。如果確實要關(guān)閉可以指定Connection: close字段。還引入了管道機制，就是說在一個TCP連接里可以同時發(fā)送多個HTTP請求，而不必等待上一個請求響應(yīng)成功再發(fā)送。還增加了PUT、PATCH、HEAD、 OPTIONS、DELETE等命令，豐富了客戶端和服務(wù)端交互動作。還增加了Host字段。

4.HTTP 2版本　　2015年

　　這個版本也是隨著互聯(lián)網(wǎng)的發(fā)展，有了新的需求制定了新的功能還有對上一個版本的完善。1.1版本有了管道機制，但是正在服務(wù)端還是要對請求進行排隊處理。這個版本可以多工的處理。還有了頭信息壓縮和服務(wù)器的主動推送。

http://localhost:8080/站點名/資源路徑?參數(shù)=參數(shù)值

三.HTTP協(xié)議的特點

1.HTTP協(xié)議是無狀態(tài)的

　　就是說每次HTTP請求都是獨立的，任何兩個請求之間沒有什么必然的聯(lián)系。但是在實際應(yīng)用當(dāng)中并不是完全這樣的，引入了Cookie和Session機制來關(guān)聯(lián)請求。

2.多次HTTP請求

　　在客戶端請求網(wǎng)頁時多數(shù)情況下并不是一次請求就能成功的，服務(wù)端首先是響應(yīng)HTML頁面，然后瀏覽器收到響應(yīng)之后發(fā)現(xiàn)HTML頁面還引用了其他的資源，例如，CSS，JS文件，圖片等等，還會自動發(fā)送HTTP請求這些需要的資源?，F(xiàn)在的HTTP版本支持管道機制，可以同時請求和響應(yīng)多個請求，大大提高了效率。

3.基于TCP協(xié)議

　　HTTP協(xié)議目的是規(guī)定客戶端和服務(wù)端數(shù)據(jù)傳輸?shù)母袷胶蛿?shù)據(jù)交互行為，并不負(fù)責(zé)數(shù)據(jù)傳輸?shù)募毠?jié)。底層是基于TCP實現(xiàn)的?，F(xiàn)在使用的版本當(dāng)中是默認(rèn)持久連接的，也就是多次HTTP請求使用一個TCP連接。

4、簡單快速

5、靈活

6、Http1.1 支持持續(xù)連接

四.請求協(xié)議

由三部分組成：

請求行

三部分構(gòu)成：請求方式（GET/POST）、請求路徑（get請求有參數(shù)則會有參數(shù)跟在路徑之后）、http協(xié)議版本（1.1）

請求行以一個方法符號開頭，以空格分開，后面跟著請求的 URI 和協(xié)議的版本，格式如 下：

Method Request-URI HTTP-Version CRLF

其中 Method 表示請求方法；Request-URI 是一個統(tǒng)一資源標(biāo)識符；

HTTP-Version 表示請 求的 HTTP 協(xié)議版本；CRLF 表示回車和換行

請求頭

鍵值對組成

請求正文

get請求沒有，只有post請求才有

響應(yīng)協(xié)議

由三部分組成：

響應(yīng)行（狀態(tài)行）

三部分構(gòu)成：http請求協(xié)議版本（1.1）、響應(yīng)狀態(tài)碼、響應(yīng)狀態(tài)碼的文本說明

響應(yīng)頭（消息報頭）

鍵值對組成

響應(yīng)正文

在瀏覽器中所見到的數(shù)據(jù)

消息頭

請求頭和響應(yīng)頭

每一個報頭域都是由名字+“：”+空格+值組成，消息報頭域的名字是大小寫無關(guān)的。

請求頭

Referer：該請求頭指明請求從哪里來

直接在地址欄輸入地址，沒有referer請求頭;常用于做百度競價、防盜鏈等

響應(yīng)頭

Refresh：自動跳轉(zhuǎn)（單位是秒），可以在頁面通過meta標(biāo)簽實現(xiàn)，也可在后臺實現(xiàn)。

<meta http-equiv=”refresh” content=”3;url=http://www.shsxt.com”>

1.簡單來說請求報文就是由請求行、請求頭、內(nèi)容實體組成的，注意，每一行的末尾都有回車和換行，在內(nèi)容實體和請求頭之間另有一個空行。其中請求行指定的是請求方法、請求URL、協(xié)議版本；請求頭是鍵值對的形式存在的，就是字段名：值；內(nèi)容實體就是要傳輸?shù)臄?shù)據(jù)。稍后會對方法、請求頭字段做詳細的說明。

2.簡單來說響應(yīng)報文由狀態(tài)行、響應(yīng)首部字段（響應(yīng)頭）、響應(yīng)實體組成，其中第一行是狀態(tài)行，依次包含HTTP版本，狀態(tài)碼和狀態(tài)短語組成；在一個回車換行之后是響應(yīng)頭，也是鍵值對的形式，字段名：值；然后會有一個空行也包含回車換行，之后是響應(yīng)實體，就是要傳輸?shù)臄?shù)據(jù)。在上面的例子當(dāng)中就是一個非常簡單的HTML頁面。對于響應(yīng)狀態(tài)碼，首部字段鍵值對稍后會有更加詳細的說明。

五、HTTP請求方法

　　請求方法是客戶端用來告知服務(wù)器其動作意圖的方法。就像下達命令一樣。在HTTP1.1版本中支持GET、POST等近10種方法。需要注意的是方法名區(qū)分大小寫，需要用大寫字母。下面詳細說明。

1.GET：獲取資源

　　GET方法用來請求訪問已被URI識別的資源。也就是指定了服務(wù)器處理請求之后響應(yīng)的內(nèi)容。

2.POST：傳輸實體主體

　　POST方法用來傳輸實體主體。POST與GET的區(qū)別之一就是目的不同，二者之間的區(qū)別會在文章的最后詳細說明。雖然GET方法也可以傳輸，但是一般不用，因為GET的目的是獲取，POST的目的是傳輸。

3.PUT：傳輸文件

　　PUT方法用來傳輸文件。類似FTP協(xié)議，文件內(nèi)容包含在請求報文的實體中，然后請求保存到URL指定的服務(wù)器位置。

4.HEAD：獲得報文首部

　　HEAD方法類似GET方法，但是不同的是HEAD方法不要求返回數(shù)據(jù)。用于確認(rèn)URI的有效性及資源更新時間等。

5.DELETE：刪除文件

　　DELETE方法用來刪除文件，是與PUT相反的方法。DELETE是要求返回URL指定的資源。

6.OPTIONS：詢問支持的方法

　　因為并不是所有的服務(wù)器都支持規(guī)定的方法，為了安全有些服務(wù)器可能會禁止掉一些方法例如DELETE、PUT等。那么OPTIONS就是用來詢問服務(wù)器支持的方法。

7.TRACE：追蹤路徑

　　TRACE方法是讓W(xué)eb服務(wù)器將之前的請求通信環(huán)回給客戶端的方法。這個方法并不常用。

8.CONNECT：要求用隧道協(xié)議連接代理

　　CONNECT方法要求在與代理服務(wù)器通信時建立隧道，實現(xiàn)用隧道協(xié)議進行TCP通信。主要使用SSL/TLS協(xié)議對通信內(nèi)容加密后傳輸。

六.HTTP的響應(yīng)狀態(tài)碼

1. 200：OK

　　這個沒有什么好說的，是代表請求被正常的處理成功了。

2. 204：No Content

　　請求處理成功，但是沒有數(shù)據(jù)實體返回，也不允許有實體返回。比如說HEAD請求，可能就會返回204 No Content，因為HEAD就是只獲取頭信息。這里簡單提一下205 Reset Content，和204 No Content的區(qū)別是不但沒有數(shù)據(jù)實體返回，而且還需要重置表單，方便用戶再次輸入。

3. 206：Partial Content

　　這是客戶端使用Content-Range指定了需要的實體數(shù)據(jù)的范圍，然后服務(wù)端處理請求成功之后返回用戶需要的這一部分?jǐn)?shù)據(jù)而不是全部，執(zhí)行的請求就是GET。返回碼就是206：Partial Content。

4. 301 ： Moved Permanently

　　代表永久性定向。該狀態(tài)碼表示請求的資源已經(jīng)被分配了新的URL，以后應(yīng)該使用資源現(xiàn)在指定的URL。也就是說如果已經(jīng)把資源對應(yīng)的URL保存為書簽了，這是應(yīng)該按照Location首部字段提示的URL重新保存。

5. 302：Found

　　代表臨時重定向。該狀態(tài)碼表示請求的資源已經(jīng)被分配了新的URL，但是和301的區(qū)別是302代表的不是永久性的移動，只是臨時的。就是說這個URL還可能會發(fā)生改變。如果保存成書簽了也不會更新。

　6. 303：See Other

　　和302的區(qū)別是303明確規(guī)定客戶端應(yīng)當(dāng)使用GET方法。

　　7. 304：Not Modified

　　該狀態(tài)碼表示客戶端發(fā)送附帶條件請求時，服務(wù)器端允許請求訪問資源，但是沒有滿足條件。304狀態(tài)碼返回時不包含任何數(shù)據(jù)實體。304雖然被劃分在3XX中但是和重定向沒有關(guān)系。

　　8. 307：Temporary Redirect

　　臨時重定向，與302 Found相同，但是302會把POST改成GET，而307就不會。

9. ?400：Bad Request

　　400表示請求報文中存在語法錯誤。需要修改后再次發(fā)送。

　　10. 401：Unauthorized

　　該狀態(tài)碼表示發(fā)送的請求需要有通過HTTP認(rèn)證的認(rèn)證信息。

11. 403：Forbidden

　　表明請求訪問的資源被拒絕了。沒有獲得服務(wù)器的訪問權(quán)限，IP被禁止等。

12. 404：Not Found

　　表明請求的資源在服務(wù)器上找不到。當(dāng)然也可以在服務(wù)器拒絕請求且不想說明理由時使用。

13.?408：Request Timeout

　　表示客戶端請求超時，就是在客戶端和服務(wù)器建立連接后服務(wù)器在一定時間內(nèi)沒有收到客戶端的請求。

14. 500：Internal Server Error

　　表明服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤，很有可能是服務(wù)端程序的Bug或者臨時故障。

15. 503：Service Unavailable

　　表明服務(wù)器暫時處于超負(fù)載或正在進行停機維護，現(xiàn)在無法處理請求。如果事先得知解除以上狀況需要的時間，最好寫入Retry-After字段再返回給客戶端。

16. 504：Getaway Timeout

　　網(wǎng)關(guān)超時，是代理服務(wù)器等待應(yīng)用服務(wù)器響應(yīng)時的超時，和408 Request Timeout的卻別就是504是服務(wù)器的原因而不是客戶端的原因

七、關(guān)于HTTP的常見問題及解答

?　　1.GET和POST的區(qū)別

　　A. 從字面意思和HTTP的規(guī)范來看，GET用于獲取資源信息而POST是用來更新資源信息。

　　B. GET提交請求的數(shù)據(jù)實體會放在URL的后面，用?來分割，參數(shù)用&連接，舉個栗子：/index.html?name=wang&login=1

　　C. GET提交的數(shù)據(jù)長度是有限制的，因為URL長度有限制，具體的長度限制視瀏覽器而定。而POST沒有。

　　D. GET提交的數(shù)據(jù)不安全，因為參數(shù)都會暴露在URL上。

　　2.408 Request Timeout和504 Gateway Timeout的區(qū)別

　　408是說請求超時，就是建立連接之后再約定的時間內(nèi)客戶端沒有發(fā)送請求到客戶端到服務(wù)端。本質(zhì)上原因在于客戶端或者網(wǎng)絡(luò)擁塞。504是網(wǎng)關(guān)超時，是說代理服務(wù)器把客戶端請求轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器后再約定的時間內(nèi)沒有收到應(yīng)用服務(wù)器的響應(yīng)。本質(zhì)上原因在于服務(wù)端的響應(yīng)過慢，也有可能是網(wǎng)絡(luò)問題。

3.Cookie和Session的區(qū)別和聯(lián)系

　　Cookie和Session都是為了保存客戶端和服務(wù)端之間的交互狀態(tài)，實現(xiàn)機制不同，各有優(yōu)缺點。首先一個最大的區(qū)別就是Cookie是保存在客戶端而Session就保存在服務(wù)端的。Cookie是客戶端請求服務(wù)端時服務(wù)器會將一些信息以鍵值對的形式返回給客戶端，保存在瀏覽器中，交互的時候可以加上這些Cookie值。用Cookie就可以方便的做一些緩存。Cookie的缺點是大小和數(shù)量都有限制；Cookie是存在客戶端的可能被禁用、刪除、篡改，是不安全的；Cookie如果很大，每次要請求都要帶上，這樣就影響了傳輸效率。Session是基于Cookie來實現(xiàn)的，不同的是Session本身存在于服務(wù)端，但是每次傳輸?shù)臅r候不會傳輸數(shù)據(jù)，只是把代表一個客戶端的唯一ID（通常是JSESSIONID）寫在客戶端的Cookie中，這樣每次傳輸這個ID就可以了。Session的優(yōu)勢就是傳輸數(shù)據(jù)量小，比較安全。但是Session也有缺點，就是如果Session不做特殊的處理容易失效、過期、丟失或者Session過多導(dǎo)致服務(wù)器內(nèi)存溢出，并且要實現(xiàn)一個穩(wěn)定可用安全的分布式Session框架也是有一定復(fù)雜度的。在實際使用中就要結(jié)合Cookie和Session的優(yōu)缺點針對不同的問題來設(shè)計解決方案。