Http协议请求和响应报文字段详解

Http协议请求报文组成

HTTP请求报文由3部分组成（请求行+请求头+请求体）：

下面是一个实际的请求报文：

请求头字段解析

以这个报文为例：

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：代表请求写协议，一般是get或post，区别：

GET使用URL或Cookie传参。而POST将数据放在BODY中。
GET的URL会有长度上的限制，则POST的数据则可以非常大。
POST比GET安全，因为数据在地址栏上不可见。
/app/game/game_list/ HTTP/1.1：/app/game/game_list/ 是url中除服务器地址外的path，HTTP/1.1：使用的http协议版本

Content-Length：body中内容的长度
3.Content-Type：body中内容的类型，默认为application/x-www-form-urlencoded，使用url编码的表单数据类型，还可以指定内容的编码：Content-Type: application/x-www-form-urlencoded;charset=utf-8
其他常见类型：

multipart/form-data
这又是一个常见的 POST 数据提交的方式。我们使用表单上传文件时，必须让 form 的 enctyped 等于这个值。直接来看一个请求示例（一个请求发送了两段不一样的数据，一个是文本，一个是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--

这个例子稍微复杂点。首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。然后 Content-Type 里指明了数据是以 mutipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary 开始，紧接着内容描述信息，然后是回车，最后是字段具体内容（文本或二进制）。如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。
这种方式一般用来上传文件，各大服务端语言对它也有着良好的支持。
上面提到的这两种 POST 数据的方式，都是浏览器原生支持的，而且现阶段原生 form 表单也只支持这两种方式。

application/json
application/json 这个 Content-Type 作为响应头大家肯定不陌生。实际上，现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。
可以使用这种方式直接提交json请求，也可以把 JSON 字符串作为 val，仍然放在键值对里，以 x-www-form-urlencoded 方式提交
以下报文直接提交了json请求：

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：服务器地址
Connection: Keep-Alive :客户端和服务器保持长时间链接
Accept-Encoding: gzip：接收的响应数据，编码格式应该为gzip

HTTP的响应报文结构

HTTP的响应报文也由三部分组成（响应行+响应头+响应体）
以下是一个实际的HTTP响应报文：

①报文协议及版本；
②状态码及状态描述；
③响应报文头，也是由多个属性组成；
④响应报文体，即我们真正要的“干货”。

响应报文字段解析：

响应状态码
HTTP的响应状态码由5段组成：

1xx 消息，一般是告诉客户端，请求已经收到了，正在处理，别急...
2xx 处理成功，一般表示：请求收悉、我明白你要的、请求已受理、已经处理完成等信息.
3xx 重定向到其它地方。它让客户端再发起一个请求以完成整个处理。
4xx 处理发生错误，责任在客户端，如客户端的请求一个不存在的资源，客户端未被授权，禁止访问等。
5xx 处理发生错误，责任在服务端，如服务端抛出异常，路由出错，HTTP版本不支持等

Content-Type:响应报文的类型
Content-Encoding：响应报文的编码