# HTTP常见知识点
# 1.HTTP常见的状态码
1xx
:一般为提示信息,是协议处理的一种中间状态
2xx
:表示服务器成功处理了客户端的请求
[200 OK]
最常见的成功状态码,表示一切正常,服务器返回的响应头部一般会有body数据[204 No Content]
成功状态码,响应头无body数据[206 Partial Content]
应用于HTTP分块下载或断点续传,返回的body只是一部分数据
3xx
:表示客户端请求的资源发生了变动,需要进行重定向
[301]
表示永久重定向[302]
表示临时重定向
4xx
:表示客户端请求报文有误,服务器无法处理
[400 Bad Request] 表示客户端请求报文有错误
[403 Forbidden] 表示服务器禁止访问资源
[404 Not Found] 表示请求的资源不存在
5xx
:表示服务端错误
[500] 与400类似,表示服务器发生错误
[501] 表示客户端请求的功能还不支持
[502] 通常是服务器作为网关或是代理时返回的错误码,表示服务器自身工作正常,访问后端服务发生了错误
[503] 表示服务器繁忙,无法响应
# 2.GET、POST、PUT、DELETE
# 2.1 GET
- GET的语义是从服务器获取指定的资源,且请求的参数位置一般写在URL中,URL规定只支持ASCII,所以GET请求的参数只允许ASCII字符,且浏览器会对URL的长度有限制。
- GET方法是安全且幂等的,所谓幂等就是无论做多少次相同的操作,结果都是不变的。故可以对GET请求的数据做缓存,可以缓存到浏览器本身、可以做到代理上
# 2.2 POST
POST的语义是根据请求负荷(报文body)对指定的资源做出处理。请求的参数一般写在报文body中,可以为任意格式的数据,且浏览器不会对body的大小做限制。一般用于修改和写入。
# 2.3 PUT
PUT请求用于向服务器段发送数据,从而改变信息,该请求类似于数据库中的update,用来修改数据的内容,但不会增加数据的种类。
# 2.4 DELETE
DELETE用于删除某一资源
# 3.HTTP的优缺点
优点
1.简单。 HTTP基本的报文格式为header+body,头部信息也是key-value简单文本的形式,易于理解,降低了学习和使用门槛。
2.灵活和易于拓展。
3.应用广泛和跨平台。
缺点
1.无状态。好处是不会记忆HTTP的状态,节省资源;坏处是在进行关联操作时会很麻烦。为了解决无状态的问题,可以使用cookie技术。
2.明文传输。
3.不安全。比如不验证通信方的身份、无法验证报文的完整性
# 3.1 性能问题(HTTP/1.1)
1.长连接
早期在HTTP/1.0时,每发起一次请求,都要新建一次TCP连接,而且是串行请求,增加了通信开销。于是在HTTP/1.1时提出了长连接,只要任意一端没有明确提出断开连接,就保持TCP连接状态,如果某个HTTP长连接超过一定时间没有任何数据交互,服务端就会主动断开连接。
2.管道网络传输
在同一个TCP连接里,以前的做法是先发送A请求,等服务器做出响应后,再发送B请求。现在的做法是可以发起多个请求,解决了发送端的队头阻塞,但是没有解决接收端的队头阻塞
# 4.HTTP与HTTPS的区别
1.HTTP为明文传输,存在安全风险。HTTPS解决了安全问题,在HTTP和TCP之间加入了SSL/TLS安全协议,让报文加密传输。
2.HTTP建立连接是TCP三次握手就可进行报文传输,HTTPS在三次握手之后,需要进行SSL/TSL的握手过程,才进行加密报文传输。
3.HTTP为80端口,HTTPS为443端口。
4.HTTPS需要向CA(证书权威机构)申请数字证书,保证服务器身份可信。
HTTPS解决了哪些问题:
- 混合加密实现了信息的机密性,解决了窃听风险
- 摘要算法实现了信息的完整性,可为数据生成独一无二的指纹,用于校验数据完整性,解决了篡改的风险
- 将服务器公钥放入到数字证书中,解决了冒充的风险
# 5.SSL/TSL建立的过程
1.ClientHello
首先,客户端向服务器发起加密通信请求,向服务器发送以下信息:
- 客户端支持的SSL/TSL协议版本
- 客户端生产的随机数(
Client Random
),后面用于生成会话密钥 - 客户端支持的密码套件列表,如RSA加密算法
2.ServerHello
服务器收到客户端请求之后,向客户端发出响应,有以下内容:
- 确认SSL/TSL协议版本,如果浏览器不支持,则关闭加密通信
- 服务器生成的随机数(
Server Random
),后面用于生成会话密钥 - 确认密码套件列表
- 服务器的数字证书
3.客户端回应
客户端收到服务器的回应之后,通过浏览器或操作系统中的CA公钥,确认服务器数字证书的真实性,若无问题,客户端会从数字证书中取出公钥,用它加密报文,向服务器发送如下信息:
- 一个随机数(
pre-master key
)。该随机数会被服务器公钥加密 - 加密通信算法改变通知,表示随后的信息都将用会话密钥加密通信
- 客户端握手结束,同时把之前发生的数据做个摘要,用于供服务端校验
客户端此时已经拥有三个随机数(Client Random、Server Random、pre-master key),接着就用双方协商的加密算法,生成本次通信的会话密钥。
4.服务端最后的回应
服务端收到客户端的第三个随机数(pre-mater key)之后,通过协商的加密算法,计算出本次通信的会话密钥,最后向客户端发送最后的信息:
- 加密算法改变通知,表示随后的信息将用会话密钥加密通信
- 服务器握手结束,同时把之前发生的数据做个摘要,用于客户端校验
至此,整个SSL/TSL的握手阶段全部结束。接下来,客户端和服务端进入加密通信,就完全是使用普通的HTTP协议,只不过用会话密钥加密内容。
# 6.HTTP/1.1、HTTP/2、HTTP/3演变
# HTTP/1.1相比于HTTP/1.0性能上的改进
- 使用TCP长连接的方式改善了HTTP/1.0短连接造成的性能开销
- 支持管道网络传输,只要第一个请求出去了,不用等他回来就可以发送第二个请求
但同时也存在性能瓶颈
- 请求头/响应头未经压缩就发送,首部信息越多延迟越大,只能压缩body部分
- 服务器是按接收到的请求的顺序响应的,如果服务器响应慢,会导致队头阻塞
- 没有请求优先级控制
- 请求只能从客户端开始,服务器只能被动响应
# HTTP/2的优化
HTTP/2协议基于HTTPS,所以HTTP/2的安全性是有保障的。HTTPS是在应用层HTTP协议与传输层协议TCP之间加入了SSL/TSL层,而HTTP/2是在TSL与HTTP层之间加入了HPack和Stream。
1.头部压缩
HTTP/2 会压缩头(Header),如果同时发出多个请求,他们的头是类似的,那么协议会消除重复的部分。
HPack算法:在客户端和服务端同时维护一张头信息表,所有字段会都存入这个表,生成索引号,这样之后就不用发送相同的字段了,只发送索引号,可以提高速度。
2.二进制格式
HTTP/2 的报文都是二进制格式,头信息和数据体都是二进制,并且统称为帧(frame):头信息帧和数据帧。计算机收到后,无需进行转换,直接解析二进制报文,增加了数据传输的效率
3.数据流
HTTP/2的数据包不是按顺序发送的,故需要对数据包做标记。每个请求对应的所有的数据包,称为一个数据流(stream)。每个数据流都有独一无二的编号(stream ID),不同stream的帧是可以乱序的,因为每个帧的头部都有stream ID信息。
同时,客户端和服务端都可以建立stream,客户端的stream ID必须为奇数,服务端的stream ID必须为偶数。客户端可以指定数据流的优先级,让服务器优先响应。
4.多路复用
HTTP/2 可以在一个连接中并发多个请求或回应,而不用按照顺序一一对应。
移除了HTTP/1.1 中的串行请求,不需要排队等待,不会出现队头阻塞,降低了延迟,大幅度提高了连接的利用率。
比如一个TCP连接中,服务器收到了来自客户端的A、B两个请求,其中A请求比较耗时,会先回应A请求中已经处理好的部分,接着回应请求B,最后回应请求A的剩下部分
5.服务器推送
HTTP/2 在一定程度上改善了传统的请求-应答模式,服务不再是被动回应请求,也可以主动向客户端发送消息。
# HTTP/2 存在的问题
HTTP/2 通过stream的并发能力,解决了HTTP/1 队头阻塞的问题,但在TCP层面也存在问题。
HTTP/2是基于TCP协议来传输数据的,TCP是字节流协议,TCP层必须保证收到的字节数据是完整且连续的,这样LINUX 的内核才会将缓冲区里的数据返回给HTTP应用,那么当前一个字节没有收到时,后收到的字节数据只能存放在内核缓冲区里,只有等到前一个字节数据到达时,HHTP/2 应用层才能从内核中拿到数据,这就是HTTP/2存在的问题。
一旦发生了丢包现象,就会触发TCP的重传机制,这样一个TCP连接中的所有HTTP请求都必须等待丢掉的包被重传回来。
← 你好,HTTP!