上一篇介紹了HTTP協(xié)議的版本迭代歷史，本篇繼續(xù)深入介紹一下HTTP協(xié)議的規(guī)范蚕甥，本文主要介紹它的URI蝌以、Request炕舵、Response、狀態(tài)碼等等信息跟畅，通過了解這些具體的內(nèi)容咽筋，可以更直觀的理解HTTP的協(xié)議格式，以及工作原理碍彭。
一晤硕、URI結(jié)構(gòu)
HTTP使用統(tǒng)一資源標(biāo)識符（URI）來傳輸數(shù)據(jù)和建立連接。URL（統(tǒng)一資源定位符）是一種特殊種類的URI庇忌，包含了用于查找的資源的足夠的信息，我們一般常用的就是URL舰褪，而一個(gè)完整的URL包含下面幾部分：
http://www.fishbay.cn:80/mix/76.html?name=kelvin&password=123456#first
1.協(xié)議部分
該URL的協(xié)議部分為http:皆疹，表示網(wǎng)頁用的是HTTP協(xié)議，后面的//為分隔符
2.域名部分
域名是www.fishbay.cn占拍，發(fā)送請求時(shí)略就，需要向DNS服務(wù)器解析IP。如果為了優(yōu)化請求晃酒，可以直接用IP作為域名部分使用
3.端口部分
域名后面的80表示端口表牢，和域名之間用:分隔，端口不是一個(gè)URL的必須的部分贝次。如果端口是80崔兴，也可以省略不寫
4.虛擬目錄部分
從域名的第一個(gè)/開始到最后一個(gè)/為止，是虛擬目錄的部分蛔翅。其中敲茄，虛擬目錄也不是URL必須的部分，本例中的虛擬目錄是/mix/
5.文件名部分
從域名最后一個(gè)/開始到?為止山析，是文件名部分堰燎；如果沒有?，則是從域名最后一個(gè)/開始到#為止笋轨，是文件名部分秆剪；如果沒有?和#赊淑，那么就從域名的最后一個(gè)/從開始到結(jié)束，都是文件名部分仅讽。本例中的文件名是76.html陶缺，文件名也不是一個(gè)URL的必須部分，如果沒有文件名何什，則使用默認(rèn)文件名
6.錨部分
從#開始到最后组哩，都是錨部分。本部分的錨部分是first处渣，錨也不是一個(gè)URL必須的部分
7.參數(shù)部分
從?開始到#為止之間的部分是參數(shù)部分伶贰，又稱為搜索部分、查詢部分罐栈。本例中的參數(shù)是name=kelvin&password=123456黍衙，如果有多個(gè)參數(shù)，各個(gè)參數(shù)之間用&作為分隔符荠诬。
二琅翻、Request
HTTP的請求包括：請求行(request line)、請求頭部(header)柑贞、空行 和 請求數(shù)據(jù) 四個(gè)部分組成方椎。
抓包的request結(jié)構(gòu)如下：
GET /mix/76.html?name=kelvin&password=123456 HTTP/1.1
Host: www.fishbay.cn
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
1.請求行
GET為請求類型，/mix/76.html?name=kelvin&password=123456為要訪問的資源钧嘶，HTTP/1.1是協(xié)議版本
2.請求頭部
從第二行起為請求頭部棠众，Host指出請求的目的地（主機(jī)域名）；User-Agent是客戶端的信息有决，它是檢測瀏覽器類型的重要信息闸拿，由瀏覽器定義，并且在每個(gè)請求中自動(dòng)發(fā)送书幕。
3.空行
請求頭后面必須有一個(gè)空行
4.請求數(shù)據(jù)
請求的數(shù)據(jù)也叫請求體新荤，可以添加任意的其它數(shù)據(jù)。這個(gè)例子的請求體為空台汇。
Response
一般情況下苛骨，服務(wù)器收到客戶端的請求后，就會有一個(gè)HTTP的響應(yīng)消息励七，HTTP響應(yīng)也由4部分組成智袭，分別是：狀態(tài)行、響應(yīng)頭掠抬、空行 和 響應(yīng)體吼野。
抓包的數(shù)據(jù)如下：
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 20 Feb 2017 09:13:59 GMT
Content-Type: text/plain;charset=UTF-8
Vary: Accept-Encoding
Cache-Control: no-store
Pragrma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Content-Encoding: gzip
Transfer-Encoding: chunked
Proxy-Connection: Keep-alive
{"code":200,"notice":0,"follow":0,"forward":0,"msg":0,"comment":0,"pushMsg":null,"friend":{"snsCount":0,"count":0,"celebrityCount":0},"lastPrivateMsg":null,"event":0,"newProgramCount":0,"createDJRadioCount":0,"newTheme":true}
1.狀態(tài)行
狀態(tài)行由協(xié)議版本號、狀態(tài)碼两波、狀態(tài)消息組成
2.響應(yīng)頭
響應(yīng)頭是客戶端可以使用的一些信息瞳步，如：Date（生成響應(yīng)的日期）闷哆、Content-Type（MIME類型及編碼格式）、Connection（默認(rèn)是長連接）等等
3.空行
響應(yīng)頭和響應(yīng)體之間必須有一個(gè)空行
4.響應(yīng)體
響應(yīng)正文单起，本例中是鍵值對信息
三抱怔、狀態(tài)碼
HTTP協(xié)議的狀態(tài)碼由3位數(shù)字組成，第一個(gè)數(shù)字定義了響應(yīng)的類別嘀倒，共有5中類別：
1.1xx: 指示信息--表示請求已接收屈留，繼續(xù)處理
2.2xx: 成功--表示請求已被成功接收、理解测蘑、接受
3.3xx: 重定向--要完成請求必須進(jìn)行更進(jìn)一步的操作
4.4xx: 客戶端錯(cuò)誤--請求有語法錯(cuò)誤或請求無法實(shí)現(xiàn)
5.5xx: 服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請求
其中灌危，常用的狀態(tài)碼如下：
200 OK //客戶端請求成功
400 Bad Request //客戶端請求有語法錯(cuò)誤，不能被服務(wù)器所理解
401 Unauthorized //請求未經(jīng)授權(quán)碳胳，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用
403 Forbidden //服務(wù)器收到請求勇蝙，但是拒絕提供服務(wù)
404 Not Found //請求資源不存在，eg：輸入了錯(cuò)誤的URL
500 Internal Server Error //服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤
503 Server Unavailable //服務(wù)器當(dāng)前不能處理客戶端的請求挨约，一段時(shí)間后可能恢復(fù)正常
如需了解更多的狀態(tài)碼味混，請參考這個(gè)網(wǎng)址：HTTP狀態(tài)碼
四、請求方法
HTTP定義了多種請求方法诫惭，來滿足各種需求翁锡。HTTP/1.0定義了三種請求方法：GET、POST 和 HEAD夕土，到了HTTP/1.1盗誊，新增了五種請求方法：OPTIONS、PUT隘弊、DELETE、TRACE 和 CONNECT荒适。各個(gè)請求方法的具體功能如下：
GET 請求指定的頁面信息梨熙，并返回實(shí)體主體。
HEAD 類似于get請求刀诬，只不過返回的響應(yīng)中沒有具體的內(nèi)容咽扇，用于獲取報(bào)頭
POST 向指定資源提交數(shù)據(jù)進(jìn)行處理請求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請求體中陕壹。POST請求可能會導(dǎo)致新的資源的建立和/或已有資源的修改质欲。
PUT 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
DELETE 請求服務(wù)器刪除指定的頁面糠馆。
CONNECT HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器嘶伟。
OPTIONS 允許客戶端查看服務(wù)器的性能。
TRACE 回顯服務(wù)器收到的請求又碌，主要用于測試或診斷九昧。
實(shí)際應(yīng)用過程中绊袋，GET和POST使用的比較多，下面主要介紹一下二者的區(qū)別：
1.請求參數(shù)的區(qū)別
GET請求會把請求的參數(shù)拼接在URL后面铸鹰，以?分隔癌别，多個(gè)參數(shù)之間用&連接；如果是英文或數(shù)字蹋笼，原樣發(fā)送展姐，如果是空格或中文，則用Base64編碼
POST請求會把提交的數(shù)據(jù)放在請求體中剖毯，不會在URL中顯示出來
2.傳輸數(shù)據(jù)的大小
GET: 瀏覽器和服務(wù)器會限制URL的長度圾笨，所以傳輸?shù)臄?shù)據(jù)有限，一般是2K
POST: 由于數(shù)據(jù)不是通過URL傳遞速兔，所以一般可以傳輸較大量的數(shù)據(jù)
3.數(shù)據(jù)解析
GET: 通過Request.QueryString獲取變量的值
POST: 通過Request.form獲取變量的值
4.安全性
GET: 請求參數(shù)在URL后面墅拭，可以直接看到，尤其是登錄時(shí)涣狗，如果登錄界面被瀏覽器緩存谍婉，其他人就可以通過查看歷史記錄，拿到賬戶和密碼
POST: 請求參數(shù)在請求體里面?zhèn)鬏敹频觯瑹o法直接拿到穗熬，相對GET安全性較高；但是通過抓包工具丁溅，還是可以看到請求參數(shù)的
五唤蔗、工作原理
HTTP協(xié)議采用請求/響應(yīng)模式，客戶端向服務(wù)器發(fā)送一個(gè)請求報(bào)文窟赏，然后服務(wù)器響應(yīng)請求妓柜。下面介紹一下一次HTTP請求的過程：
- 在瀏覽器中輸入
URL，并按下回車鍵 - 瀏覽器向
DNS服務(wù)器請求解析該URL中的域名對應(yīng)的IP地址(如果是IP請求涯穷，則不需要該步驟) - 解析出
IP后棍掐，根據(jù)IP和端口號，和服務(wù)器建立TCP連接 - 瀏覽器向服務(wù)器發(fā)送請求拷况，該請求報(bào)文作為
TCP三次握手的第三個(gè)報(bào)文發(fā)送給服務(wù)器 - 服務(wù)器做出響應(yīng)作煌，把數(shù)據(jù)發(fā)送給瀏覽器
- 通信完成，斷開
TCP連接 - 瀏覽器解析收到的數(shù)據(jù)并顯示
六赚瘦、HTTPS簡介
HTTPS是安全的HTTP通道粟誓，即在HTTP通信中加入了SSL層（當(dāng)前版本是TLS1.2），通信的數(shù)據(jù)被加密了起意，防止被竊取鹰服，具體的通信流程如下：
HTTPS使用的加密方式結(jié)合了對稱加密和不對稱加密的特點(diǎn)，在保證安全的情況下杜恰，又提高了傳輸效率获诈。HTTP和HTTPS的區(qū)別如下：
1.https協(xié)議需要到ca申請證書仍源，一般免費(fèi)證書很少，需要交費(fèi)舔涎。
2.http的信息是明文傳輸笼踩，https 則是具有安全性的ssl加密傳輸協(xié)議。
3.http和https用的端口不一樣亡嫌，前者是80嚎于，后者是443。
4.http的連接很簡單挟冠，是無狀態(tài)的于购；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議知染，比http協(xié)議安全
至此肋僧，HTTP的介紹就告一段落了，當(dāng)然HTTP協(xié)議的內(nèi)容還是很多的控淡，本文只是涉及了常用的部分嫌吠，文中不足之處，還請各位看官指出掺炭。(文中圖片來自互聯(lián)網(wǎng)辫诅，如有侵權(quán)，請告知涧狮，我怕賠不起)
參考資料
