💕"Echo"💕
作者：Mylvzi
文章主要内容：网络原理(4)HTTP协议
HTTP协议是应用层协议中非常重要的一个协议,诞生于1991年,迄今为止发展出很多的http版本,但是目前仍在大规模使用的诞生于1999年的1.1版本
一.HTTP协议简介
http协议主要应用在两个方面:
- 浏览器打开网站
- 通过手机app访问服务器
上述两种场景基本上都需要通过http协议来进行访问.和之前学习过的协议不同的是,http协议是一个理论 + 实践的协议,实践性更强.同时学习http最重要还是学习http协议的报文格式
http协议的报文格式和之前学习过的协议还有所不同,准确的说http协议的报文格式有两种:
- 请求报文格式(request)
- 响应报文格式(response)
这两种报文格式并不是完全相同的,在结构和内容上有所区别.http是一种一问一答结构模型的协议,除了一问一答这种结构,还有一问多答(下载文件),多问一答(上传文件),多问多答(串流/远程桌面)
补充:浏览器打开网站的全过程:
- 浏览器先向对应的服务器发送请求
- 服务器根据请求返回一个html数据的响应
- 浏览器下载好这个数据,就能打开网站
- 每次打开网站都要重复上述过程,所以打开网站就会占用网络带宽
二.HTTP协议报文格式
想要获取http协议的报文格式,可以通过抓包来实现,所谓抓包,就是获取通过网卡的数据,网卡又被称为网络接口,客户端的请求和服务器的响应在传输的过程中都要通过网卡,抓包可以通过各种专业的抓包工具实现,如fiddler,wireshark等,以下介绍fiddler的具体使用
首先我们去fidder的官网进行软件的下载:https://www.telerik.com/fiddler
下载完毕之后就可以直接打开,打开之后我们先进行https协议的认证(都打上勾)
fiddler界面各个部分介绍:
在查看具体的报文格式时,需要点击右侧栏的RAW选项(原生)
直接在fiddler中查看不太方便的话,还可以点击VIEW IN NOTEPAD在记事本中进行查看:
下面就可以开始进行抓包了,以下通过抓包工具fiddler演示http请求和响应的报文格式
补充:fiddler本质上是一个正向代理软件(客户端的代理软件),客户端的请求发送给服务器时会先通过fiddler,服务器的响应传输回来时也会先通过fiddler,所以fiddler既可以获取到请求报文格式和响应报文格式/要注意,fiddler可能会和其他的代理软件发生冲突,在使用时最好关闭其他的代理软件(如vpn)
1.请求报文
利用记事本查看请求报文
以上就是一个完整的请求报文,具体来说,请求报文可以分为四部分:
1.首行
- GET:http方法(method) 表示客户端"想干什么"
- 中间部分:中间的一长串字符串都是URL 表示资源唯一定位符 描述用户访问资源的具体位置
- HTTP/1.1:http的版本号
2.请求头(header)
以一系列的键值对组成,键和值之间通过:空格来连接,键和值是早已被规定好的
3.空行
请求头的结束标志,一个行空行作为结束,空行下面就是主体
4.主体(body)
请求的具体内容,有的请求可能没有主体,有的请求有主体
2.响应报文
利用记事本查看响应报文
以上就是一个完整的响应报文,具体来说,响应报文也可以分为四部分:
1.首行
- HTTP/1.1:版本号
- 200:http的状态码 描述http的状态
- OK:状态码描述 OK代表"好,可以,允许"
HTTP状态码是在客户端发起请求后，由服务器返回的一个三位数字的代码，用于表示服务器对请求的处理结果。每个结果都对应着不同的含义,用于指示请求的成功(2xx)、重定向(3xx)、客户端错误(4xx)或者服务器错误(5xx)等情况。
对于不同的状态码,也有不同的解决方案:例如，对于2xx状态码，客户端可以继续处理响应结果；对于4xx状态码，客户端通常需要采取一些纠正行动，例如修正URL、检查权限等(往往是属于域名错误)；对于5xx状态码，客户端通常需要等待服务器修复问题或者采取备用方案。
2.响应头(header)
以一系列的键值对组成,键和值之间通过:空格来连接,键和值是早已被规定好的
3.空行
响应头的结束标志,一个行空行作为结束,空行下面就是主体
4.主体(body)
响应的主体非常复杂,有时候需要通过压缩的方式来减少对网络带宽的占用,正文中内容也十分复杂,且有多种格式,如:html,json等
总的来说,请求报文和响应报文的格式虽然有所差别,但是大致上的组成是相同的,下面进行详细的介绍
三.报文格式的详细介绍
1.URL
URL（Uniform Resource Locator），统一资源定位符
URL也可以叫做资源唯一定位符,用于描述资源在网络中的位置,URL是计算机中重要的一个概念,不仅仅在http中使用,之前学习过的mysql在设置数据源时也了解过,如
URL由多部分组成,以下是一个URL示例:
- http:协议方案名 描述URL采用的协议方案名称 此处表示采用的方案是http 上述的jdbc:mysql 也是一种方案名
- user:pass:登录信息(认证) 这个字段现在不经常使用了,尤其是面向用户使用的网站更没有这样的要求 程序员自己设定的一些网站可以添加 在访问此URL时只能有特定信息才能访问
- www.example.ip:服务器地址,可以使ip地址,也可以是域名,一般是通过域名来描述服务器的位置(更加易于理解记忆)
- 80:服务器端口号:ip地址是计算机设备的地址,但是一个计算机中可能有多个服务器,此处的端口号就是确定要访问的是哪一个服务器
- /dir/index.htm:带层次的文件路径,描述要访问资源在服务器中的具体位置 虽然这里通过目录这种结构表示资源的具体位置,但资源实际的存储位置可能不是目录(硬盘/内存/cpu计算等)
- uid = 1:查询字符串(query string):对 请求的补充说明 query string是键值对结构的字符串,以
?开头,键值对之间通过&连接,键和值之间通过=相连,这里的键值对结构程序猿是可以自定义进行设定的(和http报文的请求头部分的键值对不同),例如 ?id=123&name=example表示向服务器传递了两个参数id和name。 - #ch1:片段标识符:显示界面的特定部分,#符号开头，常用于指示HTML页面中的锚点位置,如
#ch1就是界面的ch1部分(这个部分也是可有可无的~)
URL格式看似很长很复杂,实际上 是对要访问资源的一步步地详细描述,比如你要去餐厅买馋嘴饼,首先你就要确定买黄焖鸡米饭的具体位置(URL),URL可以这样写:
补充:
URL中的端口号不是必须要有的,如果不写就是默认的端口号,对于http版本的URL来说,默认端口号是80,https的默认端口号是443,这些默认端口号是浏览器提供的
在URL中,有些特定的字符是有特殊作用的,不能直接作为字符串中的内容,URL中使用%作为特殊字符的转移符号,进行urlencode(url解析的工作)如: 
(+ ? : / 都是URL中的特殊字符),对于输入的中文也有相同的urlencode的过程,转化为汉字对应的utf8码表
查询字符串是由一个一个的键值对组成,这些键值对的结构,内容,组成都是可以由程序员自定义实现的~
2.方法
方法(method)
用于描述本次请求的具体操作,常见的http方法中的方法有:
这里面最常用的两种方法是GET和POST方法,实际开发中也是经常使用到这两个方法
需要说明的一点是,上述的各种方法最开始被发明出来是为了实现不同的语义,但是随着历史的发展,这些方法可能都不在遵守初心,实际上现在程序员对这些方法的使用可能更加的随意,方法之间也没有比较明显的区别(比如POST的方法和PUT方法,双方的适用场景基本相同),但是有一些使用上的习惯作为一种约定俗成的东西保存了下来,在使用的过程中就要遵守上述的约定
GET:用于请求数据
大多数的请求报文中都是GET方法,表示尝试向服务器索要数据
现在尝试打开必应网站,通过抓包工具fiddler工具获取到的请求报文如下:
此处就是使用GET方法
POST:用于提交数据
POST的出现场景比GET要少一些,经常用于向服务器提交数据时,如:
- 登录
- 上传文件
现在在edge中尝试打开microsoft账户
此时显示的就是POST方法,其他使用POST方法的场景还有:提交图片/上传视频等(你尝试上传一个b站视频时就是向b站的服务器POST了一个数据)
GET方法和POST方法的主要区别:
- GET方法通常将要传输的数据放在URL的query string之中,POST方法通常放在报文的主体中
这其实就是一种约定俗成的习惯,GET方法也可以将传输的数据放在body之中,POST方法也可以将数据放到URL之中,但是接收和发送双发的格式要是相同的,不能是发送方的GET方法的数据放在URL之中,接收方的GET方法的数据放在body之中,所以一般还是采用约定俗成的这种习惯
- 语义上的差距:GET方法适用于请求数据,POST方法适用于提交数据
以下是几种常见的错误理解:
1.GET方法可以传输的数据是有限的,POST可以传输的数据没有大小约束
这种说法其实是一个历史遗留问题,在早期的浏览器中,因为硬件资源的匮乏,可以传输的数据有限,所以对URL的长度做出了限制,但是发展到现在,在RFC标准文档中并没有明确规定URL的长度,实际上URL的长度可以很长,甚至可以传输像图片这样的数据
注:RFC（Request for Comments）标准文档是由互联网工程任务组（IETF）发布的一系列文档，用于描述互联网的各种协议、技术和相关主题。(其中就规定了http协议相关的规范)
2.GET方法传输是不安全的,POST的传输是安全的
这里的误解在于对安全一词的理解,错误想法认为:GET方法的数据存储在URL中,可以很容易的看到,所以不安全,POST方法的数据存储在body之中,不容易被看到,所以安全.但是对于一个黑客来说,数据的位置并不会影响他获取你要的传输数据,也不会影响对数据的篡改,真正的安全应该是让黑客更不容易获取到数据,更不容易篡改数据,仅仅通过数据的位置来判断安全性是不科学的(采用https协议就是一种更加安全的方法)
3,GET方法只能传输文本数据,POST方法可以传输文本数据和二进制数据
实际上,GET方法也可以传输二进制数据,比如;
- 将要传输的二进制数据放在body之中
- 将要传输的二进制数据进行base64转码,转化为全是字符串的数据,存储在query string之中
Base64转码是一种将二进制数据编码为ASCII字符集的方法，以便在网络传输或存储中使用。比如在传输图片时(图片是二进制的数据),就会将图片进行Base64转码,存储在报文之中
为什么一定要进行转码呢?实际上http协议是基于文本的协议,二进制数据中的某些数据可能是http协议中不存在,无法识别的(如控制字符非ascii码字符),如果直接传输二进制数据可能会导致接收方解析错误
4.GET请求是幂等的,POST请求是不幂等的
幂等是高等数学中的一个概念,表示输入相同的内容,输出内容的稳定性
GET请求通常是幂等的,常用于请求获取服务器资源,不会对服务器的资源进行改变,所以对同一资源进行多次GET请求,得到的结果都是相同的
POST请求通常是不幂等的,常用于提交数据(如提交表单等),通常会导致服务器资源状态的改变,因此对同一个资源进行多次POST请求得到的结果可能是不同的
举一个简单的例子,你尝试获取你B站的头像,进行多次GET操作,得到的头像都是相同的,但如果你尝试多次POST操作,其中有一次POST操作提交了新的头像,那么获得数据就出现了不同
其实,GET请求的幂等还是非幂等是取决于具体的代码实现的,只不过是RFC标准文档中建议GET请求是幂等的
5.缓存处理
GET请求的数据通常可以被浏览器进行缓存,因为他不会改变服务器的状态
POST请求的数据通常不可以被浏览器进行缓存,因为可能会改变服务器的状态
网络原理(4)HTTP协议（下）https://developer.aliyun.com/article/1480754?spm=a2c6h.13148508.setting.28.361f4f0eyTL4lb
