HTTP
超文本传输协议。HTTP是在计算机中用于
两点之间传输
文字、图片、音频、视频等超文本
数据的约定和规范
- 超文本:超越了普通文本的文本,是文字、图片、视频等的混合体。HTML是最常见的超文本,经过浏览器解释,呈现出有文字、画面的网页
- 传输:HTTP协议是双向协议,一方请求,另一方应答,在两点之间进行数据传输,
不局限于服务器→浏览器,也可以是服务器→服务器
- 协议:使用计算机能理解的语言确立了一种计算机之间交流通信的规范(两个以上的参与者),以及相关的各种控制和错误处理方式(行为约定和规范)
状态码
1xx
属于提示信息,是协议处理中的一种中间状态2xx
表示服务器成功处理了客户端的请求200 ok
成功状态码,表示一切正常,如果是非head请求,服务器返回的响应头都会有body数据204 no content
与200 ok
基本相同,但响应头没有body数据206 partial content
应用于HTTP分块下载或断点续传,表示响应返回部分body数据
3xx
表示客户端请求的资源发生了变动,需要客户端用新的url重新发送请求获取资源,即重定向。301 moved permanently
永久重定向,说明请求的资源已经不存在,需要改用新的url再次访问302 moved temporarily
临时重定向,说明请求的资源还在,暂时需要用另一个url来访问304 not modified
不具有跳转的含义,表示资源未修改,重定向已存在的缓存文件,即缓存重定向,用于缓存控制
4xx
表示客户端发送的报文有误,服务器无法处理400 bad request
客户端请求的报文有错误403 forbidden
服务器禁止访问资源404 not found
请求的资源在服务器上不存在或未找到,无法提供给客户端
5xx
表示客户端请求报文正确,但服务器在处理请求时发生了错误500 internal server error
与400 bad request
类似,笼统的错误码501 not implement
表示客户端请求的功能还不支持502 bad gateway
通常是服务器作为网关或代理时返回的错误码,表示服务器自身正常工作,访问后端服务器发生了错误503 service unavailable
表示服务器当前很忙,暂时无法响应服务器
常见字段
Host
客户端发送请求时,用于指定服务器的域名Content-Length
服务器在返回数据时,表面本次响应的数据长度Connection
常用于客户端要求服务器使用TCP持久连接,以便其他请求复用Connection:Keep-Alive
HTTP/1.1默认是持久连接,为了兼容,需要指定Connection
首部字段的值为Keep-Alive
Content-Type
用于服务器回应客户端,本次数据是什么格式- 客户端使用
Accept
告知服务器自己可以接受哪些数据格式 Content-Type:text/html; charset=utf-8
表明发送的是网页,编码格式为utf-8
- 客户端使用
Content-Encoding
说明数据的压缩方式,表示服务器返回的数据使用了什么压缩方式- 客户端使用
Accept-Encoding
告知服务器自己可以接受哪些数据压缩方式 Content-Encoding:gzip
表示服务器返回的数据采用了gzip
方式压缩
- 客户端使用
请求类型
- GET:请求从服务器获取资源。GET方法是
只读
操作,无论操作多少次,服务器上的数据都是安全的,且每次结果都是相同的,因此为安全且幂等的 - POST:向URL指定的资源提交数据,数据放在报文的body里。POST方法是
新增
或提交
数据的操作,会修改服务器上的资源,所以是不安全的,且多次提交数据就会创建多个资源,所以是不幂等的 - HEAD:类似GET请求,不过返回的响应中没有具体的内容,用于获取报头
以上为HTTP/1.0定义的请求方法
HTTP协议中的
安全
和幂等
安全:请求方法不会破坏服务器上的资源
幂等:多次执行相同的操作,结果都是相同的
- PUT:从客户端向服务器传送的数据取代指定的文档的内容
- DELETE:请求服务器删除指定的页面
- CONNECT:
HTTP/1.1
中预留给能够将连接改为管道方式的代理服务器 - OPTIONS:允许客户端查看服务器的性能
- TRACE:回显服务器收到的请求,用于测试或诊断
- PATCH:对PUT方法的补充,用来对已知资源进行局部更新
以上为HTTP/1.1新增的六种请求方法
HTTP/1 HTTPS HTTP/2 HTTP/3
HTTP/1.0
- 默认短连接,每发起一个请求,需要新建一次TCP连接,并且是串行请求
HTTP/1.1
- 优点:简单、灵活、易于扩展、应用广泛、跨平台
- 简单:报文格式是header+body,头部信息是key-value简单文本的形式,易于理解,降低学习和使用门槛
- 灵活、易于扩展:HTTP协议里的各类请求方法,URI/URL、状态码、头字段等每个组成要求没有固定,允许开发人员自定义和扩充。HTTP工作在应用层,下层可以任意变化
- 应用广泛、跨平台
- 缺点:无状态、明文传输、不安全
- 无状态:服务器不会记忆HTTP的状态,不需要额外资源记录状态信息,能减轻服务器的负担。但在完成有关联性的操作时会很麻烦,例如登录验证后的系列操作,每次都需要询问一遍身份信息。
- 明文传输:便于阅读,但信息容易被窃取
- 不安全:明文通信,容易被窃听;不验证通信方身份,容易冒充;无法证明报文的完整性,有可能被篡改
-
改进
-
长连接,默认持久连接,减少了TCP连接的重复建立和断开所造成的额外开销,减轻了服务端的负载。
持久连接的特点是只要一端没有明确提出断开连接,则保持TCP连接状态
-
可以进行管道网络传输。即在同一个TCP连接中,客户端可以发起多个请求,只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去,减少整体的响应时间
-
-
瓶颈
-
请求-应答
模式加剧了HTTP的性能问题,服务器按顺序响应请求,若某个请求由于某种原因阻塞,后面排队的请求一同被阻塞,会导致客户端一直请求不到数据,即队头阻塞
-
请求/响应头部未经压缩就发送,首部信息越多延迟越大。
-
发送冗长的首部,每次发送相同的首部造成浪费
-
没有请求优先级
-
请求只能从客户端开始,服务端被动响应
-
HTTPS
-
HTTP是超文本传输协议,信息是明文传输,存在安全风险。HTTPS为解决HTTP不安全的缺陷,在TCP和HTTP网络层之间加入了
SSL/TLS
安全协议,使得报文能够加密传输 -
HTTP连接建立相对简单,TCP三次握手后便可进行HTTP的报文传输。HTTPS在TCP三次握手之后,还需进行
SSL/TLS
的握手过程,才可进入加密报文传输 -
HTTP端口是80,HTTPS端口是443
-
HTTPS协议需要向CA(证书权威机构)申请数字证书,保证服务器的身份是可信的
-
HTTPS如何保证安全
- 混合加密:在通信建立前采用非对称加密方式交换会话密钥;通信过程中使用堆成加密的会话密钥加密明文数据
- 摘要算法:能够为数据生成独一无二的指纹,用于校验数据的完整性,解决了篡改的风险
- 数字证书:借助第三方权威机构CA(数字证书认证机构),将服务器公钥放在数字证书中,只要证书是可信的,公钥就是可信的。通过数字证书的方式保证服务器公钥的身份,解决冒充的风险
-
HTTPS如何建立
- 客户端向服务器索要并验证服务器的公钥
- 双方协商产生会话密钥
- 双方采用会话密钥进行加密通信
前两步为
SSL/TLS
的建立过程,即握手阶段 -
SSL/TLS
的建立过程- client Hello:客户端向服务器发起加密通信请求
- 客户端支持的
SSL/TLS
协议版本 - 客户端生成的随机数(
client random
) - 客户端支持的密码套件列表
- 客户端支持的
- server hello:服务器收到客户端请求时,向客户端发出以下响应
- 确认
SSL/TLS
协议版本,若浏览器不支持,则关闭加密通信 - 服务器生成的随机数(
server random
) - 确认的密码套件列表
- 服务器的数字证书
- 确认
- 客户端响应:客户端收到服务器响应后,首先通过浏览器或操作系统中的CA公钥,确认服务器的数字证书的真实性。若证书没问题,客户端会从数字证书中取出服务器的公钥,用其加密报文,向服务器发送以下信息
- 客户端生成的随机数(
pre-master key
),该随机数将被服务器公钥加密 - 加密通信算法改变通知。表示随后的信息都将使用会话密钥加密通信
- 客户端握手结束通知。表示客户端的握手阶段已经结束,同时把之前所有内容发生的数据做个摘要,供服务器校验
- 使用双方协商的加密算法加密
client random
、server random
、pre-master key
三个随机数,生成通信的会话密钥
- 客户端生成的随机数(
- 服务器响应
- 取出客户端发送的随机数,使用双方协商的加密算法加密
client random
、server random
、pre-master key
三个随机数,生成通信的会话密钥 - 加密通信算法改变通知。表示随后的信息都将使用会话密钥加密通信
- 服务器握手结束通知。表示服务器的握手阶段已经结束,同时把之前所有内容发生的数据做个摘要,供客户端校验
- 取出客户端发送的随机数,使用双方协商的加密算法加密
- client Hello:客户端向服务器发起加密通信请求
HTTP/2
- 改进
- 基于
HTTPs
的,安全性有保障 - 头部压缩:
HPACK
算法:在客户端和服务器同时维护一张头信息表,所有字段存入表中,生成索引号,之后就不会发送相同字段,只发送索引号,提高速度 - 二进制格式:头信息和数据体都是二进制,统称为帧,收到报文后,无需将明文转成二进制,而是直接解析二进制报文,提高了数据传输的效率
- 数据流:数据包不用按顺序发送,数据包会做标记,指明其属于哪个回应,每个请求或响应的所有数据包,称为一个数据流。每个数据流都有唯一编号,客户端发出的编号为奇数,服务器发出的数据编号为偶数。客户端还可以指定数据流的优先级。服务器优先响应优先级高的请求
- 多路复用:在一个TCP连接中并发多个请求或响应,不用按顺序一一对应
- 服务器推送:服务器可以主动向客户端发送消息
- 基于
- 瓶颈
- 多个HTTP请求复用一个TCP连接,下层的TCP协议不知道有多少个HTTP请求,一旦发生丢包现象,就会触发TCP的重传机制。
HTTP/3
- HTTP/3把下层的TCP协议改成了
UDP
,UDP
是无连接不可靠的协议,不会出现HTTP/1.1的队头阻塞和HTTP/2的丢包重传问题 - 基于
UDP
的QUIC
协议可以实现类似TCP的可靠性传输 QUIC
协议可以保证传输的可靠性,当某个流发生丢包时,只会阻塞这个流,其他流不会受到影响- HTTPS建立一个连接,需要6次交互:先是建立三次握手,如何是
TLS/1.3
的三次握手。QUIC将6次交互合并为3次,减少了交互次数