HTTP Protocal

HTTP协议简介

在网络中,我们所说的一次请求就是向目标服务器发送一串文本,这些文本都采用特定的协议。一般来说,常见的网络通信协议有HTTP、TCP、UDP 等,这里我们只介绍HTTP协议。

HTTP全称是HyperText Transfer Protocal,即:超文本传输协议。HTTP是应用层协议,当我们使用WEB浏览器浏览网页的时候,浏览器和服务器之间就会通过HTTP协议进行数据的发送和接收。我们先来看看HTTP协议的请求包结构:

HTTP请求包

上图第一行叫做“状态行”,最后一行是响应包体(当然实际中它一般不是一行,我们只是这里这样表示),中间部分称为响应头部。如果我们使用类似Fiddler等抓包工具,可以详细的看到每一次浏览器的WEB请求的数据包。下面通过一个详细的HTTP包来对比了解:

HTTP抓包

在上图中,中间部分是fiddler捕获了HTTP数据包的16进制显示,右边对应的是ASCII码对应的字符,组合起来也就构成了一次完整的HTTP请求包。请求包格式化显示后如下:

HTTP抓包

继续以登录学信息门户为例,举一个POST请求的HTTP请求包。

HTTP抓包

浏览器对服务器发出请求包后,服务器经过处理就会返回一个HTTP响应包。HTTP响应包的结构为:

HTTP请求包

继续举一个实际例子。针对刚才的登录请求包,服务器返回的响应包是:

HTTP抓包

很显然,我们随便输一个用户名和密码,服务器肯定会拒绝的:)

HTTP请求方法(所有方法全为大写)有多种,各个方法的解释如下:

HTTP抓包

可能大家也会注意到,我们虽然使用错误的账号和密码进行登录,服务器返回的响应报依然是“200”,描述是“ok”。是因为状态码描述的是本次请求的状态,而非请求结果的正确与否。状态码由三位数字组成,第一个数字定义了响应的类别,且有五种可能取值:

  • 1xx:指示信息–表示请求已接收,继续处理
  • 2xx:成功–表示请求已被成功接收、理解、接受
  • 3xx:重定向–要完成请求必须进行更进一步的操作
  • 4xx:客户端错误–请求有语法错误或请求无法实现
  • 5xx:服务器端错误–服务器未能实现合法的请求

我们在实际中经常用到的状态码和对应的说明如下:

HTTP抓包

在实际中,常用到的只有GET和POST两种请求方法。

在网络请求中,我们经常需要附带一些请求参数,那么如何使用GET方法和POST方法传输参数呢?

GET方法中的参数是直接附带在URL中的,像这样:
http://www.abc.com/?params1=val1&params2=val2
以“?”开头,以“&”连接各个请求参数,每个请求参数通过“key=value”这样的形式建立关系。如果数据是英文字母或数字,原样发送,如果是空格,转换为+,如果是中文或其他字符,则直接把字符串用BASE64加密。

POST方法中的参数是经过编码后放在HTTP包的请求体中的。编码方式有“x-www-form-urlencoded”和“form-data”。

x-www-form-urlencoded一般用来传输“key=value”键值对,如:
user=123&pwd=456

form-data与之不同的是可以传输二进制,在我们需要传输一些如图片等文件时,就需要使用form-data。

根据HTTP规范[1], GET方法和POST方法的区别是:

  • GET用于信息获取,同一个URL请求只会返回同一个结果。这里的“同一个”并不是指返回相同的结果,比如我们访问新闻网站,最新的新闻可能会更新或改变,但这个URL始终是返回的最新新闻这一栏目。
  • POST表示可能会修改服务器上资源的请求。就像我们在新闻网站上评论应该通过POST请求实现,因为提交评论后站点的资源已经不同了,或者说被修改了[2]。
  • 由于GET请求被放在了URL中,我们直接复制URL发送给其他人,这样其他人就可以打开我们想让他看到的页面,而POST请求是做不到这一点的,是因为POST请求的内容并不在URL中。
  • POST请求相对来说是不可见的,但不可见并不代表“安全”。HTTP协议中数据包均采用明文传输,一旦数据包被捕获,无论是GET请求还是POST请求都很容易清楚的被看到(实例可以参考我们上面的截图)。

由于一些浏览器对URL的长度做了限制,如过需要传输较多的数据,一般建议使用POST请求。

注:
[1] Hypertext Transfer Protocol – HTTP/1.1: https://www.w3.org/Protocols/rfc2616/rfc2616.html
[2] 《浅谈HTTP中Get与Post的区别》:http://www.cnblogs.com/hyddd/archive/2009/03/31/1426026.html

0%