回顾
前面我们说到了数据链路层,网络层IP协议,传输层的TCP/UDP协议一些知识点,现在让我们谈谈 应用层的HTTP协议的知识点.
这篇我们先从大局入手,仍然是对总体报文进行全局分析,再对细节报文进行拆解分析
版本
首先我们谈谈HTTP协议的版本
HTTP 0.9 (1991)
HTTP 1.0 (1992 - 1996)
HTTP 1.1 (1997 - 1999) 常用
HTTP 2.0 (2012 - 2014) 常用
HTTP 3.0 (未完全完善)
这里的前面的HTTP版本一直到2.0都是基于TCP协议来实现的,然而3.0版本的协议是基于UDP版本的协议实现的/
目前讨论的是HTTP1.1协议,因为它是最常用的
2.0和3.0就是引入了一系列的机制提高传输数据和安全性
3.0基于UDP实现了一些更复杂的机制
例子
比如当前我们在浏览器输入一个网址,假设是搜狗搜索的网址,这里浏览器就会给搜狗的服务器发送一个HTTP请求,搜狗的服务器返回一个 HTTP响应,这个响应被浏览器解析之后,就展示成我们所看到的页面内容了,这就包含了HTML,CSS,JS等信息,所以称HTTP协议为超文本传输协议,就是能传输图片这样的能表达更多信息的内容
这里的响应就是指HTML+CSS+JS写成的网页
这里的文本指的是 字符串,能用utf8或gbk表示的合法字符串
超文本就是在这个基础上加上了图片等特殊格式
富文本 就是类似于word这种对格式有强要求的数据
HTTP协议的交互过程基本上也是一问一答的形式
但是点进去一个网页,如果出现这样的交互式窗口,称之为消息推送
HTTP抓包
为了更好地理解HTTP协议的报文内容,我们选择抓取传输的数据包来分析内容数据
这里推荐使用Fiddler(专注HTTP协议,使用更便捷)
官网 Fiddler | Web Debugging Proxy and Troubleshooting Solutions (telerik.com)
点击社区版本
然后填写信息无脑安装即可
安装好之后,点击Tools
将这里的都勾选,就可以开始简单的抓包了
记得弹出的窗口问你是否同意证书记得得勾选
注:除了上述操作以外,电脑上的代理记得关闭,fiddler本质上也是一个代理程序,之间可能会产生冲突.
正确配置之后,程序中就会抓取到很多的数据包
肯呢个并不是浏览器的数据包
电脑上后台也会有很多应用程序在你感知不到的情况下做很多事情,比如向服务器发送一些HTTP/HTTPS请求
通常来说打开一个浏览器,浏览器和服务器之间的交互不仅仅只有一次,通常来说是有很多次的
比如说第一次拿到页面的HTML
在拿到CSS,JS等
当执行JS的时候又出现了很多http请求,获取到一些数据,经过这样的反复拉扯,就出现了呈现在你面前的网页
fiddler抓取的蓝色的往往是返回的HTML,往往是网站入站请求
双击就可以查看明细
点击这两个之后就可以看到HTTP请求的组成格式
上面的raw表示的是显示原始数据,这里的请求会一定程度的压缩,因为网络带宽是有限的
下面那个是在记事本中查看,这样更加方便
下面的就是显示响应的报文 (记得点击黄色的框decode)
这里就是被压缩了,为了减少占用的网络带宽
为什么发送的请求报文没有压缩呢?
因为请求的报文本来就很短 就不需要压缩了
HTTP请求报文简介
首先我们从整体上来看HTTP请求报文就是首行 + 请求头 + 空行 + 正文(可有可无)
这里首行就表示了 使用的请求方法 + URL + 请求使用的协议以及版本号
这里上文的请求报文从第二行到最后一行表示的就是 请求头
类似于TCP协议,包含着一些重要的属性信息 以键值对的方式呈现
最后是一个空行,代表报文的结束标记
大部分的请求不包含正文部分
HTTP响应报文简介
和请求的报文类似
以 首行 + 响应头 + 空行 + 正文 组成
这里的正文一般是存在的
首行包含的是 版本号 状态码 状态描述
比如 HTTP/1.1 200 OK
响应头仍然是以键值对方式来描述的一些属性信息
这里空行就不能作为结束标记了
这里的结束标记是以Content-Length来标记的
这就表示如何区分响应报文的结束标志
URL(网络资源定位符)
这里HTTP协议中的URL就描述了网络上唯一定位某个资源的定位符
这里的URL不仅仅只是在HTTP协议中使用到
像我们之前使用JDBC链接数据库也是使用到类似的内容的
下面我们来介绍一下HTTP协议中的URL的具体组成部分
一般常见的URL是以上的组成方式
协议方案名:HTTP/HTTPS
登录信息:user:pass 放在URL中对于现在来说不太安全,现在的登录信息都是有另外的页面来完成身份验证的
服务器ip:定位服务器地址
服务器端口号:确定应用程序,如果URL中不包含端口就会配置默认端口
带层次的文件路径:表示待访问资源的位置
查询字符串:对于资源地址查询的补充(不同的网站定义的规则不同)
片段标识符:一般是小说页面使用的,用通过不同的片段符能表示页面的跳转
下面还是以一家店铺买吃的来举例
eg:http://上海某饭店:18/招牌菜/红烧肉?餐具=需要&外带=是
URL encode
这里的URL encode一般是在query string 这里使用
在URL中一般会有很多字符代表着特殊的含义
比如 + / @ 等 或者是汉字也是需要转义的,如果直接使用就会导致浏览器的解析失败等等
所以我们常常就是将字符的ASCII码拿出来然后转为16进制加上%进行分割
这里搜索的C++ 就转义成了C%2B%2B
实际开发中,在URL中需要包含中文的时候一定要进行encode
HTTP方法
常见的方法如下,但是最常用的还是get方法(相对更多)和post方法
注:这里的方法使用说明只是编辑标注文档的作者的一厢情愿,其实我们可以任意搭配和使用这些方法
post方法常常有body,get方法常常没有body,假设一个登录的场景
post方法常常会将登录信息放到body中
get方法则会放到URL中
我们可以通过抓包查看(这里不做演示了)
post方法常用于登录,上传
get和post方法的区别
定论:两个没有啥区别,可以相互替代使用(大部分可以相互替代使用)
小部分浏览器不支持
但是两者在使用习惯上还是有区别的
1.post请求常常将数据写到body中传输,而get请求常常将数据放到URL中传输
2.语义的区别
get请求常常用来获取数据,post请求常常用来传输数据给服务器
3.标准文档中get请求要求是幂等的,post请求没有要求
幂等:输入内容一定,输出的内容也是一定的,称为幂等
4.get请求是可以被浏览器收藏的
post请求不可以被浏览器收藏的
关于post请求个get请求在互联网上广为流传的一些误解
1.post请求比get请求更安全???
论据:get请求的数据和登录信息放在URL,可以之间看到,所以不安全
结论:这完全就是扯,假设是post,我抓个包还不是能看到嘛,所以真正重要的是以什么方式来加密的
2.get传输的数据量小,post传输的数据量大?
这描述的是以前,以前的浏览器对URL是有大小限制的,现在则没有
3.get只能携带文本信息,post可以携带二进制数据?
这个结论不完全错误,其实URL通过query string携带数据
这里我们将二进制数据进行 URL encode,然后服务器进行decode就可以还原成二进制数据了post请求一般也不是直接携带二进制数据的,而是以base64编码或者是urlencode进行携带
报头简单解释(header)
1.Host 表示服务器的地址和端口
2.Content-Type Content-Length
这两个属性就表示了正文body中的内容长度和编码格式
也就是标志着结束在哪里,避免粘包问题
注:如果没有body部分其实就是空行作为结束标志
Type类型
1.application/json json格式
2.application/x-www-form-urlencoded form表单,通过HTML中的form标签构造的一种格式
可以认为是把query string 放到body里
3.multipart / form-data
上传文件的时候使用的,暂时不做过多介绍
响应中的报头格式
3.UA(user-agent)
也可以表示浏览器的使用设备是什么,就能依据这个信息来给不同的设备来匹配不同的页面显示,这样只需维护一套代码即可,但是现在越来越多的网站不使用UA进行区分了,因为CSS3出现了一个新特性,"媒体查询",可以根据不同的设备的尺寸大小来匹配不同的设备
5.referer
可以表示是从哪个页面来跳转过来的,比方说很多公司接广告,在早期移动这些网络运营商会在路由器上面搞小动作,修改成自己的referer,从而就能获取一定的广告费用,这样就很舒服
这是通过点击量来赚钱的.
现在就有了HTTPS 这个s可以理解为SSL(加密协议)
这里的正文信息等都是有密文加密的,不容易破解
就算破解了也很容易被感知到
6.cookie
cookie本质上是一个将数据持久化在硬盘上的一种方案
浏览器是可以读写电脑硬盘设备的,调用操作系统的api即可
其实理论上网页也是可以这样执行操作的,但是浏览器禁止了这种操作,为了安全起见
所以就提供了这样的api来退而求其次,能有限度的存储数据,而不是无限度的访问文件系统
重要结论:
1.cookie是服务器返回给客户端的,通常是首次访问或者登录之后
2.cookie会存储在浏览器本地硬盘中,后续访问服务器会带有cookie
3.cookie中存储的信息和query string样是程序员自定义的键值对信息
4.cookie在浏览器中的组织方式按照不同的域名为维度存储的,可以这样查看
5.cookie一般是保存用户的身份标识,这样服务器就可以通过不同的身份标识来区分用户了
注:HTTPS关注的是不能被篡改而不是不能被解密,所以密码放到cookie中不合适
