- HTTP基本概念
- Get和Post
- HTTP特性
- HTTPS与HTTP
- HTTP/1.1 HTTP/2 HTTP/3演变
HTTP基本概念
HTTP基本概念
HTTP:超文本传输协议(HyperText Transfer Protocol),是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范
HTTP常见的状态码
200 OK:一切正常,返回响应头有body数据
204 No Content:与200基本一致,响应头无body数据
206 Partial Content:响应返回的body数据并不资源的全部
301 Moved Permanently:永久重定向,资源已不存在
302 Found:临时重定向,资源存在
304 Not Modified:301和302在响应头里有Location字段,浏览器会自动重定向新的URL,但304不具有跳转含义,表示资源未修改,也称缓存重定向和缓存控制
400 Bad Request:表示请求报文有错误
403 Forbidden:表示服务器禁止访问资源
404 Not Found:请求的资源在服务器上不存在
500 Internal Server Error:表示服务器有错误
501 Internal Server Error:表示客户端请求功能还不支持
502 Bad Gateway:表示服务器自身工作正常,访问后端服务器发生错误
503 Service Unavailable:表示服务器很忙,暂时无法响应
HTTP常用字段
-
Host:客户端发送请求时,用来指定服务器的域名(有了该字段,可以将请求发送到同一台服务器上的不同网站)
-
Content-Length:服务器返回数据时表明本次回应的数据长度
-
Connection:最常用于客户端要求服务器使用TCP持久连接,以便其他请求复用
Connection:keep-alive
- Content-Type:用于服务器回应客户端本次数据格式
Contnet-Type:text/html;charset=utf-8
//客户端请求时,可以使用Accept字段声明自己可以接受哪些数据格式
Accept:*/*
- Content-Encoding:说明服务器返回的数据使用的压缩格式
Contnet-Encoding:gzip
//客户端请求时,可以使用Accept字段声明自己可以接受哪些数据格式
Accept-Encoding:gzip,deflate
GET与POST
两者的区别
-
Get:从服务器获取资源,包括静态文本、页面、图片
-
Post:向服务器提交数据,数据放在报文的body里
两者方法都是安全和幂等的吗?
安全和幂等:
- 所谓安全是指请求方法不会破坏服务器上的资源
- 所谓幂等是指多次执行相同的操作,结果都是相同
显然,GET方法是安全且幂等的,但POST不是
HTTP/1.1特性
HTTP(以下都指1.1版本)优点
- 简单:基本报文格式是header+body
- 灵活和易于拓展:HTTP协议允许开发人员自定义和扩充
- 应用广泛和跨平台:天然具有跨平台优越性
HTTP缺点
-
无状态双刃剑
- 无状态好处:服务器不会记忆HTTP的状态,不需要额外的资源来记录状态信息
- 无状态坏处:在完成关联性操作时非常麻烦,解决方法是用Cookie技术
Cookie通过在请求和响应报文中写入Cookie信息控制客户端状态(在客户端第一次请求,服务器会下发一个装有客户信息的「小贴纸」,后续客户端请求服务器的时候,带上「小贴纸」,服务器就能认得了)
-
不安全:(可以通过HTTPS解决)
- 通信使用明文传输不加密(窃听风险)
- 不验证通信方的身份(篡改风险)
- 无法证明报文的完整性(冒充风险)
HTTP性能
-
长连接:早期HTTP/1.0是短连接,每发起一个请求都要建立一次TCP连接(三次握手),增加了很多通信开销,后期提出长连接通信方式,也称之为持久连接,特点是只要任意一端没有明确提出断开连接,则保持TCP连接状态。
-
管道网络传输:即在同一个TCP连接里面,客户端可以同时发起多个请求,服务器按照顺序响应,减少整体的响应时间。
-
队头阻塞:是指顺序发送的请求序列中的一个请求因为某种原因被阻塞,后面排队的所有请求都一同被阻塞,会导致客户端一直请求不到数据。
HTTP与HTTPS
两者区别
-
HTTP 是超文本传输协议,信息是明文传输,存在安全风险的问题。HTTPS 是在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议,使得报文能够加密传输。
-
HTTP 连接建立相对简单, TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后,还需进行 SSL/TLS 的握手过程,才可进入加密报文传输。
-
HTTP 的端口号是 80,HTTPS 的端口号是 443。
-
HTTPS 协议需要向 CA(证书权威机构)申请数字证书,来保证服务器的身份是可信的。
HTTP/1.1有哪些问题?HTTPS是如何解决的?
-
窃听风险:明文传输容易泄露信息
- 混合加密
原理:1)加密:通信过程使用对称密钥对明文进行加密,使用公钥对会话密钥进行加密;2)解密:用私钥对加密过的会话密钥进行解密,使用解密后的会话密钥对密文进行解密。
-
篡改风险:没有校验机制,内容会被篡改
-
摘要算法
能够为数据生成独一无二的指纹,用于校验数据的完整性,解决篡改风险
客户端在发送明文之前会通过摘要算法算出明文的摘要,服务器解密之后会用同样的摘要算法算出发送过来的明文,两者进行比较判断有无数据篡改。
-
-
冒充风险:不进行身份验证
-
数字证书
将服务器公钥放在数字证书中,只要证书是可信的,公钥就是可信的,流程如下:
-
HTTPS如何建立连接,其间交互了什么?
SSL/TLS协议基本流程:
-
客户端像服务器索要并验证服务器的公钥
-
双方协商生产会话密钥
-
双方采用会话密钥进行加密通信
-
ClientHello
客户端首先向服务器发起加密通信请求,也就是CLientHello请求,发送以下信息:
- 客户端支持的SSL/TLS协议版本
- 客户端生产的随机数(Client Random),用于生产会话密钥
- 客户端支持的密码套件列表,如RSA加密算法
-
SeverHello
服务器收到客户端请求后,向客户端发出SeverHello响应,回复如下内容:
- 确认SSL/TLS协议版本,不支持则关闭加密通信
- 服务器生产的随机数(Server Random),用于生产会话密钥
- 确认密码套件列表,如RSA加密算法
- 服务器的数字证书
-
客户端回应
首先确认数字证书的真实性,若没有问题则使用服务器公钥加密报文,并发送如下信息:
- 一个随机数(pre-master key)。该随机数会被服务器公钥加密。至此,服务器和客户端有3个随机数,使用双方协商的加密算法各自生成本次通信的会话密钥。
- 加密通信算法改变通知,表示随后的信息都将用会话密钥加密通信。
- 客户端握手结束通知,表示客户端的握手阶段已经结束。并把之前所有内容发生的数据做个摘要,用来供服务端校验。
-
服务器的最后回应
服务器收到客户端的第三个随机数之后,通过协商的加密算法,计算出本次通信的会话密钥,然后向客户端发送最后的信息:
- 加密通信算法改变通知,接下来的信息都将用会话密钥加密通信
- 服务器握手结束通知,并把之前所有内容发生的数据做个摘要,用来供客户端校验。
至此,整个SSL/TLS握手阶段全部结束,接下来就是客户端和服务器的加密通信,就是普通的HTTP协议。
HTTP/1.1、HTTP2、HTTP3演变
HTTP/1.1相比于HTTP/1.0的改进
- 使用TCP长连接改善HTTP/1.0短连接造成的性能开销
- 支持管道(pipeline)网络传输,可以减少响应时间
HTTP/2相比于HTTP/1.1的改进
HTTP/2是基于HTTPS的,所以HTTP/2具有保障
-
头部压缩
HTTP/1.1中请求/响应头部(Header)未经压缩就发送,首部信息越多延迟越大。每次互相发送相同的首部造成的浪费较多。
HTTP/2会压缩头,如果同时发送多个请求,Header一样或相似,则协议会消除重复的部分,即所谓HPACK算法,在客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号提高速度。
-
二进制格式
HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文,而是全面采用了二进制格式。
头信息和数据体都是二进制,并且统称为帧(frame):头信息帧和数据帧。
这样可以大大提高数据传输的效率。
-
数据流
HTTP/1.1中服务器是按请求的顺序响应的,如果服务器响应慢会导致客户端一直请求不到数据,造成队头阻塞,且没有请求优先级控制。
HTTP/2的数据包不是按顺序发送的,每个请求或回应的数据包被称为一个数据流(Stream),且有独一无二的编号,规定客户端发出的数据流为奇数,服务器发出的数据流编号为偶数,客户端还可以指定数据流的优先级,服务器会先响应优先级高的请求。
-
多路复用
HTTP/1.1中采用串行请求,需排队等候,会造成队头阻塞等问题。
HTTP/2可以在一个连接中并发多个请求或回应,而不用按照顺序一一对应。
-
服务器推送(Server Push 也叫 Cache Push)
HTTP/1.1中请求只能从客户端开始,服务器只能被动响应。
HTTP/2在一定程度上改善了传统的请求-应答工作模式,服务器可以主动向客户端发送消息。
HTTP/3相比于HTTP/2的改进
HTTP/2主要问题是:对于多个HTTP请求在复用一个TCP连接时,下层TCP协议不知道有几个HTTP请求,一旦出现丢包现象就会触发TCP重传机制,这样所有的HTTP请求都必须等待这个丢了的包被重传回来。
由于UDP不管顺序也不管丢包,所以不会出现队头阻塞和丢包重传问题。
但UDP是不可靠传输,但是基于UDP的QUIC协议可以实现类似TCP的可靠性传输
-
QUIC中当某个流丢包时,只会阻塞这个流,其他流不会受到影响
-
TLS升级到1.3版本,头部压缩算法也升级到QPack
QUIC实际上是一个在UDP上的伪TCP+TLS+HTTP/2的多路复用协议,但现在普及仍非常慢。
参考整理自 程序员小吴 微信公众号(五分钟学算法)