Http協(xié)議請(qǐng)求報(bào)文組成
HTTP請(qǐng)求報(bào)文由3部分組成（請(qǐng)求行+請(qǐng)求頭+請(qǐng)求體）：
下面是一個(gè)實(shí)際的請(qǐng)求報(bào)文：
請(qǐng)求頭字段解析
以這個(gè)報(bào)文為例：
POST /app/game/game_list/ HTTP/1.1
Content-Length: 10
Content-Type: application/x-www-form-urlencoded
Host: zhushou.72g.com
Connection: Keep-Alive
Accept-Encoding: gzip
platform=2
1.Post：代表請(qǐng)求寫協(xié)議，一般是get或post淘讥，區(qū)別：
- GET使用URL或Cookie傳參。而POST將數(shù)據(jù)放在BODY中悲关。
- GET的URL會(huì)有長(zhǎng)度上的限制，則POST的數(shù)據(jù)則可以非常大娄柳。
- POST比GET安全寓辱，因?yàn)閿?shù)據(jù)在地址欄上不可見(jiàn)。
/app/game/game_list/ HTTP/1.1：/app/game/game_list/ 是url中除服務(wù)器地址外的path赤拒，HTTP/1.1：使用的http協(xié)議版本
- Content-Length：body中內(nèi)容的長(zhǎng)度
3.Content-Type：body中內(nèi)容的類型秫筏，默認(rèn)為application/x-www-form-urlencoded，使用url編碼的表單數(shù)據(jù)類型挎挖，還可以指定內(nèi)容的編碼：Content-Type: application/x-www-form-urlencoded;charset=utf-8
其他常見(jiàn)類型：
- multipart/form-data
這又是一個(gè)常見(jiàn)的 POST 數(shù)據(jù)提交的方式这敬。我們使用表單上傳文件時(shí)，必須讓 form 的 enctyped 等于這個(gè)值蕉朵。直接來(lái)看一個(gè)請(qǐng)求示例（一個(gè)請(qǐng)求發(fā)送了兩段不一樣的數(shù)據(jù)鹅颊，一個(gè)是文本，一個(gè)是png圖片）：
POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--
這個(gè)例子稍微復(fù)雜點(diǎn)墓造。首先生成了一個(gè) boundary 用于分割不同的字段堪伍，為了避免與正文內(nèi)容重復(fù)，boundary 很長(zhǎng)很復(fù)雜觅闽。然后 Content-Type 里指明了數(shù)據(jù)是以 mutipart/form-data 來(lái)編碼帝雇，本次請(qǐng)求的 boundary 是什么內(nèi)容。消息主體里按照字段個(gè)數(shù)又分為多個(gè)結(jié)構(gòu)類似的部分蛉拙，每部分都是以 --boundary 開(kāi)始尸闸，緊接著內(nèi)容描述信息，然后是回車孕锄，最后是字段具體內(nèi)容（文本或二進(jìn)制）吮廉。如果傳輸?shù)氖俏募€要包含文件名和文件類型信息畸肆。消息主體最后以 --boundary-- 標(biāo)示結(jié)束宦芦。
這種方式一般用來(lái)上傳文件，各大服務(wù)端語(yǔ)言對(duì)它也有著良好的支持轴脐。
上面提到的這兩種 POST 數(shù)據(jù)的方式调卑，都是瀏覽器原生支持的，而且現(xiàn)階段原生 form 表單也只支持這兩種方式大咱。
- application/json
application/json 這個(gè) Content-Type 作為響應(yīng)頭大家肯定不陌生恬涧。實(shí)際上，現(xiàn)在越來(lái)越多的人把它作為請(qǐng)求頭碴巾，用來(lái)告訴服務(wù)端消息主體是序列化后的 JSON 字符串溯捆。
可以使用這種方式直接提交json請(qǐng)求，也可以把 JSON 字符串作為 val厦瓢，仍然放在鍵值對(duì)里提揍，以 x-www-form-urlencoded 方式提交
以下報(bào)文直接提交了json請(qǐng)求：
POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8
{"title":"test","sub":[1,2,3]}
- text/xml：
POST http://www.example.com HTTP/1.1
Content-Type: text/xml
<!--?xml version="1.0"?-->
<methodcall>
<methodname>examples.getStateName</methodname>
<params>
<param>
<value><i4>41</i4></value>
</params>
</methodcall>
- Host: zhushou.72g.com：服務(wù)器地址
- Connection: Keep-Alive :客戶端和服務(wù)器保持長(zhǎng)時(shí)間鏈接
- Accept-Encoding: gzip：接收的響應(yīng)數(shù)據(jù)，編碼格式應(yīng)該為gzip
HTTP的響應(yīng)報(bào)文結(jié)構(gòu)
HTTP的響應(yīng)報(bào)文也由三部分組成（響應(yīng)行+響應(yīng)頭+響應(yīng)體）
以下是一個(gè)實(shí)際的HTTP響應(yīng)報(bào)文：
①報(bào)文協(xié)議及版本旷痕；
②狀態(tài)碼及狀態(tài)描述碳锈；
③響應(yīng)報(bào)文頭，也是由多個(gè)屬性組成欺抗；
④響應(yīng)報(bào)文體售碳，即我們真正要的“干貨”。
響應(yīng)報(bào)文字段解析：
- 響應(yīng)狀態(tài)碼
HTTP的響應(yīng)狀態(tài)碼由5段組成：
- 1xx 消息绞呈，一般是告訴客戶端贸人，請(qǐng)求已經(jīng)收到了，正在處理佃声，別急...
- 2xx 處理成功艺智，一般表示：請(qǐng)求收悉、我明白你要的圾亏、請(qǐng)求已受理十拣、已經(jīng)處理完成等信息.
- 3xx 重定向到其它地方封拧。它讓客戶端再發(fā)起一個(gè)請(qǐng)求以完成整個(gè)處理。
- 4xx 處理發(fā)生錯(cuò)誤夭问，責(zé)任在客戶端泽西，如客戶端的請(qǐng)求一個(gè)不存在的資源，客戶端未被授權(quán)缰趋，禁止訪問(wèn)等捧杉。
- 5xx 處理發(fā)生錯(cuò)誤，責(zé)任在服務(wù)端秘血，如服務(wù)端拋出異常味抖，路由出錯(cuò)，HTTP版本不支持等
- Content-Type:響應(yīng)報(bào)文的類型
- Content-Encoding：響應(yīng)報(bào)文的編碼
