http请求报文和响应报文

http请求报文和响应报文

前言

http协议是一个应用层协议，其报文分为请求报文和响应报文
当客户端请求一个网页时，会先通过http协议将请求的内容封装在http请求报文之中，服务器收到该请求报文后根据协议规范进行报文解析，然后向客户端返回响应报文。

http报文结构为：

• 起始行
  对报文进行描述
• 头部
  向报文中添加了一些附加信息，是一个名/只的列表，头部和协议配合工作，共同决定了客户端和服务器能做什么事情
  例如：Content-Length（主体长度），Content-Type（主体类型）等。
• 主体
  包含数据的主体部分

接下来详细介绍一下http请求报文和响应报文。

请求报文

下面是我用wireshark捕捉到的一个http请求报文，我们来分析一下它。

起始行

在请求报文中，起始行包括了3个部分：

• 请求的方法（POST）
• 请求的URL(/cgi-bin/qqshow_user_props_info)
• 协议类型及版本(HTTP/1.1)

请求方法

在本例中请求的方法是POST，http中请求方法有以下8种（其中比较常用的是GET,POST,HEAD）：

1.OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
2.HEAD
向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3.GET
向特定的资源发出请求。它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现数据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。
4.POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
5.PUT
向指定资源位置上传其最新内容
6.DELETE
请求服务器删除Request-URL所标识的资源
7.TRACE
回显服务器收到的请求，主要用于测试或诊断
8.CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。


这里着重讲解一下GET和POST之间的区别

• GET方法的数据参数是暴露在起始行的URL中的，而POST方法的数据参数是在报文主体中的。
• GET方法相对来说没有POST安全，因为它的数据参数可以直接从URL中获取，但是GET的效率更高。
• GET方法的数据参数大小有一定的限制（1024）（原因也是因为它的数据参数是放在URL中的），而POST对数据大小是没有限制的。

其实他们的本质区别是GET是从服务器上请求数据，而POST是向服务器发送数据

头部

以下只列出部分请求报文头部所独有的信息：

Client-IP：提供了运行客户端的机器的IP地址
From：提供了客户端用户的E-mail地址
Host：给出了接收请求的服务器的主机名和端口号
Referer：提供了包含当前请求URI的文档的URL
UA-Color：提供了与客户端显示器的显示颜色有关的信息
UA-CPU：给出了客户端CPU的类型或制造商
UA-OS：给出了运行在客户端机器上的操作系统名称及版本
User-Agent：将发起请求的应用程序名称告知服务器
Accept：告诉服务器能够发送哪些媒体类型
Accept-Charset：告诉服务器能够发送哪些字符集
Accept-Encoding：告诉服务器能够发送哪些编码方式
Accept-Language：告诉服务器能够发送哪些语言
TE：告诉服务器可以使用那些扩展传输编码
Expect：允许客户端列出某请求所要求的服务器行为
Range：如果服务器支持范围请求，就请求资源的指定范围
COOKIE：客户端用它向服务器传送数据
COOKIE2：用来说明请求端支持的COOKIE版本


应答报文

和上面一样，下面是我用wireshark捕获到的一个http应答报文

起始行

应答报文的起始行也包含了3个部分

• 协议类型及版本号
• 状态码
• 状态码的文字描述

状态码

在http协议中，状态码被分为了5大类

• 100~199（信息性状态码）
• 200~299（成功状态码）
• 300~399（重定向状态码）
• 400~499（客户端错误状态码）
• 500~599（服务器端错误状态码）

常见的状态码

100：继续 客户端应当继续发送请求。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。101： 转换协议 在发送完这个响应最后的空行后，将会切换到在Upgrade 消息头中定义的那些协议。只有在切换新的协议更有好处的时候才应该采取类似措施。102：继续处理 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。200：请求成功 处理方式：获得响应的内容，进行处理201：请求完成，结果是创建了新资源。新创建资源的URI可在响应的实体中得到 处理方式：爬虫中不会遇到202：请求被接受，但处理尚未完成 处理方式：阻塞等待204：服务器端已经实现了请求，但是没有返回新的信 息。如果客户是用户，则无须为此更新自身的文档视图。 处理方式：丢弃300：该状态码不被HTTP/1.0的应用程序直接使用， 只是作为3XX类型回应的默认解释。存在多个可用的被请求资源。 处理方式：若程序中能够处理，则进行进一步处理，如果程序中不能处理，则丢弃
301：请求到的资源都会分配一个永久的URL，这样就可以在将来通过该URL来访问此资源 处理方式：重定向到分配的URL302：请求到的资源在一个不同的URL处临时保存 处理方式：重定向到临时的URL304：请求的资源未更新400：非法请求401：未授权 处理方式：丢弃403：禁止 处理方式：丢弃404：没有找到 处理方式：丢弃500：服务器内部错误 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在的源代码出现错误时出现。501：服务器无法识别 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。502：错误网关 作为网关或者工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。503：服务出错 由于临时的维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。


头部

响应报文首部提供的额外信息：

Age：(从最初创建开始)响应持续时间Public：服务器为其资源支持的请求方法列表Retry-After：如果资源不可用的话，在此日期或时间重试Server：服务器应用程序软件的名称和版本Title：对HTML文档来说，就是HTML文档的源端给出的标题Warning：比原因短语更详细一些的警告报文Accept-Ranges：对此资源来说，服务器可接受的范围类型Vary：服务器会根据这些首部的内容挑选出最适合的资源版本发送给客户端Proxy-Authenticate：来自代理的对客户端的质询列表Set-COOKIE：在客户端设置数据，以便服务器对客户端进行标识Set-COOKIE2：与Set-COOKIE类似WWW-Authenticate：来自服务器的对客户端的质询列表


总结

以上我们了解了http两种不同报文的结构，其主要差异在于起始行的不同。

其中值得我们关注的是GET和POST之间的区别，以及了解常用的状态码。