1、HTTP和HTTPS的区别?
HTTP | HTTPS | |
安全性 | 不加密的协议,数据以明文形式在网络上传输 | 在HTTP的基础上加入了SSL/TLS加密层,确保了数据在网络上传输时的安全性 |
证书 | 不需要任何证书 | 需要从认证机构(CA)获取SSL证书 |
端口号 | 80端口 | 443端口 |
响应速度 | 比HTTPS快 | 比HTTP慢一点 |
服务器资源 | 比HTTPS少 |
HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议,要比较 HTTPS 比 HTTP 要更耗费服务器资源 |
URL前缀 | “http://” | “https://”,现代浏览器会在地址栏显示一个挂锁图标,表示连接是安全的 |
简要介绍一下SSL和TSL:
SSL(Secure Sockets Layer)和TLS(Transport Layer Security)是用于保障网络通信安全的加密协议。它们提供了在网络上传输数据时的保密性、完整性和身份验证功能,确保数据在客户端与服务器之间传输时不会被窃听或篡改。
TLS可以视为SSL的后继者,首次发布于1999年,由互联网工程任务组(IETF)制定标准。TLS 1.0实际上是基于SSL 3.0的一个增强版本,旨在解决其前身的安全缺陷。目前常用的TLS版本包括TLS 1.2和TLS 1.3,后者进一步改进了安全性并提高了性能。例如,TLS 1.3简化了握手过程,减少了延迟,并移除了旧的不安全算法的支持。
无论是SSL还是TLS,它们的工作流程大致相同,主要包括以下几个步骤:
-
握手协议:双方协商一个共同支持的加密套件,选择加密算法及密钥交换机制。同时,服务器向客户端提供其数字证书以证明其身份。
-
密钥交换:客户端和服务器通过非对称加密技术生成会话密钥。这个密钥将用于后续的数据传输过程中,采用对称加密方式提高效率。
-
记录协议:实际的数据传输在此层面上完成。所有信息都被分成小块,经过压缩(可选)、附加MAC(消息认证码)以保证完整性,最后使用会话密钥加密后发送。
-
警报协议:当检测到任何异常情况如解密失败、违反协议等,系统会发出警告信息,必要时终止连接。
2、HTTPS的加密与认证过程?
1.客户端Hello
首先,由客户端向服务端发起加密通信请求。客户端向服务器发送一条“Client Hello”消息,其中包括客户端支持的TLS版本、加密套件列表(如对称加密算法AES、非对称加密算法RSA等)、客户端产生的随机数(用于后续生成对称密钥)以及会话ID(如果有的话)。
2.服务器Hello
服务器收到客户端请求后,向客户端发出响应。服务器回应一条“Server Hello”消息,包括双方都支持的TLS版本和加密套件、服务端产生的随机数。服务器同时发送其数字证书给客户端。该证书包含服务器的公钥,并由权威的证书颁发机构(CA)签名,以证明服务器的身份。
3.认证阶段
客户端验证服务器提供的证书的有效性,包括检查证书是否是由可信的CA签发的,证书是否未过期,以及证书中的域名是否匹配正在访问的服务器地址。
4.密钥交换
无论最终的数据加密使用的是非对称加密算法还是对称加密算法,初始的密钥交换过程常常都依赖于非对称加密技术(如RSA、Diffie-Hellman或ECDH)来确保安全性。因为使用对称加密算法进行通信时,对称加密算法要求通信双方共享相同的密钥。然而,直接通过不安全的信道传输这个密钥是不安全的。
如果初始的密钥交换使用的是非对称加密算法(例如RSA),客户端生成一个预主密钥,并用服务器的公钥加密后发送给服务器。服务器用自己的私钥解密收到的信息,得到预主密钥。之后,双方根据这个预主密钥以及之前交换的随机数,通过伪随机函数(PRF)生成主密钥和会话密钥。
如果初始的密钥交换使用的是Diffie-Hellman密钥交换,则直接在客户端和服务器间进行密钥协商,无需传输预主密钥。
5.完成握手
客户端发送“Finished”消息,表明握手完成。此消息已使用会话密钥加密。
服务器同样发送“Finished”消息,表示握手成功完成。
接下来,客户端与服务器进入加密通信,就完全是使用普通的 HTTP 协议。
3、HTTP状态码的含义?
1、 100类状态码属于提示信息,是协议处理中的一种中间状态,实际用到的比较少。
- 100(继续):请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分,正在等待其余部分。
- 101(切换协议):请求者已要求服务器切换协议,服务器已确认并准备切换。
2、 200类状态码表示服务器成功处理了客户端的请求。
- 200(成功):表示服务器响应成功,也就是服务器找到了客户端请求的内容,并且将内容返回给客户端。
- 204(已创建):请求成功并且服务器创建了新的资源。
- 206(部分内容):服务器成功处理了部分GET请求。
3、 300类状态码表示客户端请求的资源发生了变动,需要客户端用新的 URL 重新发送请求获取资源,也就是重定向。
- 301(永久移动):代表永久性的重定向**,值得注意的是,这种重定向跳转,从严格意义来讲不是服务器跳转,而是客户端跳转**的。这个“跳”的动作是服务器是通过回传状态码301来下达给客户端的,让客户端完成跳转。
- 302(临时移动):代表临时跳转。例如:URL地址A可以向URL地址B上跳转,但这并不是永久性的,在经过一段时间后,URL地址A还可能向URL地址C上跳转。
- 304(未修改):服务器通过返回状态码304可以告诉客户端请求资源成功,但是这个资源不是由服务器提供返回给客户端的,而是客户端本地浏览器缓存中就有的这个资源,因为可以从缓存中获取这个资源,从而节省传输的开销。
301 和 302 都会在响应头里使用字段 Location
,指明后续要跳转的 URL,浏览器会自动重定向新的 URL。
4、400类状态码表示客户端发送的报文有误,服务器无法处理。
- 400(错误请求):服务器不理解请求的语法。
- 403(禁止):代表请求的服务器资源权限不够,也就是没有权限去访问服务器的资源,或者请求的IP地址被封掉了。
- 404(未找到):代表服务器上没有该资源,或者说服务器找不到客户端请求的资源,是最常见的请求错误码。
5、500类状态码表示客户端请求报文正确,但是服务器处理时内部发生了错误,属于服务器端的错误码。
- 500(服务器内部错误):代表程序错误,也就是说请求的网页程序本身报错了。在服务器端的网页程序出错。由于现在的浏览器都会对状态码500做一定的处理,所以在一般情况下会返回一个定制的错误页面。
- 501(尚未实施):服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码。
- 502(错误网关):通常是服务器作为网关或代理时返回的错误码,表示服务器自身工作正常,访问后端服务器发生了错误。
- 503(服务不可用):表示服务器当前很忙,暂时无法响应客户端。。
- 504(网关超时):服务器作为网关或代理,但是没有及时从上游服务器收到请求。
- 505(HTTP 版本不受支持):服务器不支持请求中所用的 HTTP 协议版本。
4、HTTP1.0、HTTP1.1、HTTP2.0和HTTP3.0的区别?
1、HTTP1.0
- 无连接:每次请求都要建立连接,需要使用 keep-alive 参数建立长连接,建立连接十分消耗资源。
- 队头阻塞:HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送,假设前一个请求响应一直不到达,那么下一个请求就不发送,后面的请求就阻塞了。
- 缓存:在HTTP1.0中主要使用header里的协商缓存 last-modified\if-modified-since,强缓存Expires来做为缓存判断的标准。
2、HTTP1.1
3、HTTP2.0
4、HTTP3.0(QUIC)
- 长连接:好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销,减轻了服务器端的负载。
- 支持管道(pipeline)网络传输:只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去,可以减少整体的响应时间。
- 缓存处理:HTTP1.1则引入了更多的缓存控制策略,多可供选择的缓存头来控制缓存策略。
- 断点续传:HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
- header压缩:HTTP1的header带有大量信息,而且每次都要重复发送,HTTP2.0使用encoder来减少需要传输的header大小,通讯双方各自cache一份header fields表,既避免了重复header的传输,又减小了需要传输的大小。
- 多路复用:使用多路复用的技术,做到同一个连接并发处理多个请求,而且并发请求的数量比HTTP1.1大了好几个数量级。
- 新的二进制帧格式:HTTP2.0把请求在应用层切分成二进制帧并标上序号,服务器接收到二进制帧后组装成请求进行处理,从而达到并发发送请求的效果,对于服务器端,响应可以通过序号确定是哪个请求,从而不会出现混乱的问题。
- 服务器推送:HTTP2.0引入了server push,它允许服务端推送资源给浏览器,在浏览器明确地请求之前,免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源,不用再通过网络。
-
HTTP/3.0直接放弃使用TCP,将传输层协议改成UDP,使用UDP实现可靠传输。
-
0-RTT:缓存当前会话的上下文,下次恢复会话的时候,只需要将之前的缓存传递给服务器,验证通过,就可以进行传输了。(这是QUIC协议相比HTTP2.0的最大优势)
-
多路复用:QUIC基于UDP,一个连接上的多个stream之间没有依赖,即使丢包,只需要重发丢失的包即可,不需要重传整个连接。
-
更好的移动端表现:QUIC在移动端的表现比TCP好,因为TCP是基于IP识别连接,而QUIC是通过ID识别链接。无论网络环境如何变化,只要ID不便,就能迅速重新连上。
-
加密认证的根文:TCP协议头没有经过任何加密和认证,在传输过程中很容易被中间网络设备篡改、注入和窃听。QUIC的packet除了个别报文,所有报文头部都是经过认证的,报文Body都是经过加密的。只要对 QUIC 做任何更改,接收端都能及时发现,有效地降低了安全风险。
-
向前纠错机制:向前纠错(Foward Error Connec,FEC),每个数据包除了它本身的内容之外还包括了其他数据包的数据,因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。向前纠错牺牲了每个数据包可以发送数据的上限,但是带来的提升大于丢包导致的数据重传,因为数据重传将会消耗更多的时间(包括确认数据包丢失,请求重传,等待新数据包等步骤的时间消耗)。
5、HTTP的GET和POST方法区别?
GET | POST | |
用途 | 从服务器上获取资源(不会改变服务器上的资源) | 更新服务器上的资源(会对服务器资源进行改变) |
参数传递 | 通过URL中的查询字符串(query string)传递参数。例如:http://example.com/page?key1=value1&key2=value2 | 通过请求体(request body)传递参数,不在URL中显示 |
缓存 | 可以被浏览器缓存 | 不会被浏览器缓存 |
历史记录 | 会被保留在浏览器的历史记录中 | 默认不会被保存到浏览器历史记录中 |
安全性 | 由于参数直接暴露在URL中,不适合传输敏感信息。同时,GET请求的数据大小通常受限于浏览器和服务器对URL长度的限制 | 相比GET,POST提供了更高的安全性,因为参数不是直接显示在URL中。但是,这并不意味着POST本身是安全的;对于敏感数据,仍需使用HTTPS协议来加密通信 |
幂等性 | GET请求是幂等的,即多次相同的GET请求应该产生相同的结果而不会对服务器资源造成影响 | POST请求不是幂等的,这意味着多次执行相同的POST请求可能会有不同的结果,并可能对服务器资源造成不同的影响(例如重复提交表单) |
名词解释:
幂等性(Idempotence) 是一个数学和计算机科学中的概念,指的是操作或函数可以被多次调用而不会产生不同的结果。换句话说,对于相同的输入,无论该操作被执行一次还是多次,其产生的效果或返回的结果都是相同的。在HTTP协议中,幂等性的概念主要用于描述某些HTTP方法的行为特性。