HTTP/HTTPS
HTTP / HTTPS
HTTP 1.x/ 2.0 / 3.0
3.1 HTTP 常见面试题 | 小林coding (xiaolincoding.com)
先说下我们熟悉的HTTP1.0
HTTP 1.0
浏览器与服务器只保持短暂的连接,每次请求都需要与服务器建立一个TCP
连接
服务器完成请求处理后立即断开TCP
连接,服务器不跟踪每个客户也不记录过去的请求
简单来说,就是每次与服务器交互,都需要新开一个连接
举个例子: 比如在解析html
文件的时候,当发现文件中存在资源文件的时候,这时候又创建单独的链接。最终导致,一个html
文件的访问包含了多次的请求和响应,每次请求都需要创建连接、关系连接。这种形式明显造成了性能上的缺陷
在HTTP1.1中支持长连接来解决这个问题 HTTP1.1是在一个TCP连接上可以传送多个HTTP
请求和响应,减少了建立和关闭连接的消耗和延迟,建立一次链接,
然后多次请求可以均由这个连接完成。
这样在加载html
文件的时候,文件中多个请求和响应就可以在一个连接中传输,减少了性能的浪费
HTTP 1.1
还允许客户端不用等待上一次请求结果返回
,就可以发出下一次请求
,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,
以保证客户端能够区分出每次请求的响应内容,这样也显著地减少了整个下载过程所需要的时间
在HTTP1.1
在HTTP1.0
的基础上,增加更多的请求头和响应头来完善的功能
- 引入了更多的缓存控制策略,如
If-Unmodified-Since, If-Match, If-None-Match
等缓存头来控制缓存策略 - 引入
range,
允许值请求资源某个部分 - 引入
host,
实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名
来创建多个虚拟WEB站点 - 还添加了其他的请求方法:
put
、delete
、options
HTTP2.0(高效)
HTTP2.0
在相比之前版本,性能上有很大的提升,添加了一些新特性
- 多路复用
- 二进制分帧
- 首部压缩
- 服务器推送 多路复用
HTTP/2
复用TCP
连接,在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应,这样就避免出现阻塞现象。
咱们可以从图中看到,第4步中客户端将css和js资源是同时发送到服务端的
二进制分帧 帧是HTTP2
通信中最小单位信息
HTTP/2
采用二进制格式传输数据,而非 HTTP 1.x
的文本格式,解析起来更高效
将请求和响应数据分割为更小的帧,并且它们采用二进制编码
HTTP2
中,同域名下所有通信都在单个连接上完成,该连接可以承载任意数量的双向数据流
每个数据流都以消息的形式发送,而消息又由一个或多个帧组成。多个帧之间可以乱序发送,根据帧首部的流标识可以重新组装,这也是多路复用同时发送数据的实现条件
首部压缩
HTTP/2
在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对,对于相同的数据,不再通过每次请求和响应发送
首部表在HTTP/2
的连接存续期内始终存在,由客户端和服务器共同渐进地更新
比如下面的的两个请求, 请求一发送了所有的头部字段,第二个请求则只需要发送差异数据,这样可以减少冗余数据,降低开销
服务器推送
1 |
|
总结
HTTP1.0
- 浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接 HTTP1.1
- 引入了持久连接,即TCP连接默认不关闭,可以被多个请求复用
- 在同一个TCP连接里面,客户端可以同时发送多个请求
- 虽然允许复用TCP连接,但是同一个TCP连接里面,所有的数据通信是按次序进行的,服务器只有处理完一个请求,才会接着处理下一个请求。如果前面的处理需要时间特别长特别慢,后面的请求只能排队等着
- 新增了一些请求方法
put
、delete
、options
- 新增了一些请求头和响应头 HTTP2.0
- 采用二进制格式而非文本格式
- 完全多路复用,而非有序并阻塞的、只需一个连接即可实现并行
- 使用报头压缩,降低开销
- 服务器可以推送
作者:二十世纪末的程序员
链接:https://juejin.cn/post/7089068858241515551
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
HTTPS
3.1 HTTP 常见面试题 | 小林coding (xiaolincoding.com)
TCP 建立连接过程
HTTPS 的连接建立过程
HTTPS 是啥
HTTP 是明文传输,意味着端到端之间的任意节点都知道内容是消息传输内容是啥,这些节点可以是 路由器,代理等。
HTTPS 就是来解决这个问题的,以安全为目的的 HTTP 通道,全称是 Hyper Text Transfer Protocol
SSL TLS 是啥
SSL (secure Sockets Layer 安全套接字)
TLS(Transport Layer security, TLS) 是为了网络通信提供安全与数据弯针行的一种安全协议。TLS/SSL 在传输网络层连接进行加密。TLS/SSL 是安全传输层协议 Transporter Layer Security 是介于 TCP 和 Http 之间的一层安全协议, 不影响原有的 TCP 协议和 Http 协议。
身份验证 CA 和证书之间的关系
- 服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
- CA通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等;
- 如信息审核通过,CA会向申请者签发认证文件-证书;
- 证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文,同时包含一个签名;
- 签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA的私钥对信息摘要进行加密,密文即签名;
- 客户端 C 向服务器 S 发出请求时,S 返回证书文件;
- 客户端 C读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法;
- 客户端然后验证证书相关的域名信息、有效时间等信息;
- 客户端会内置信任CA的证书信息(包含公钥),如果CA不被信任,则找不到对应 CA的证书,证书也会被判定非法。
需要注意如下:
- 申请证书不需要提供私钥,确保私钥永远只能服务器掌握;
- 证书的合法性仍然依赖于非对称加密算法,证书主要是增加了服务器信息以及签名;
- 内置 CA 对应的证书称为根证书,颁发者和使用者相同,自己为自己签名,即自签名证书(为什么说”部署自签SSL证书非常不安全”)
- 证书=公钥+申请者与颁发者信息+签名;
HTTP 单向认证
单向认证是指:客户端连接到某个域名或者 IP 时 ,客户端协议验证服务器的身份。服务器的身份一般是通过证书认证的,服务器的整数,一般都是通过权威的 CA 机构进行签名,客户端收到服务器证书后,获取对应的 CA 机构的证书,并使用 CA 证书进行解密。
身份认证过程
连接过程
HTTPS 双向认证
https 双向认证指除了客户端需要验证服务器之外,服务器也需要验证客户端
参考资料
TLS/SSL握手过程
基于RSA握手和密钥交换的客户端验证服务器为示例详解TLS/SSL握手过程:
第一步 client_hello
客户端发起请求,以明文传输请求信息,包含版本信息,加密套件候选列表,压缩算法候选列表,随机数,扩展字段等信息,相关信息如下:
- 支持的最高TSL协议版本version,从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2,当前基本不再使用低于 TLSv1 的版本;
- 客户端支持的加密套件 cipher suites 列表, 每个加密套件对应前面 TLS 原理中的四个功能的组合:认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验);
- 支持的压缩算法 compression methods 列表,用于后续的信息压缩传输;
- 随机数 random_C,用于后续的密钥的生成;
- 扩展字段 extensions,支持协议与算法的相关参数以及其它辅助信息等,常见的 SNI 就属于扩展字段,后续单独讨论该字段作用。
第二步 server_hello+server_certificate+sever_hello_done
- server_hello, 服务端返回协商的信息结果,包括选择使用的协议版本 version,选择的加密套件 cipher suite,选择的压缩算法 compression method、随机数 random_S 等,其中随机数用于后续的密钥协商;
- server_certificates, 服务器端配置对应的证书链,用于身份验证与密钥交换;
- server_hello_done,通知客户端 server_hello 信息发送结束;
第三步 证书校验
客户端验证证书的合法性,如果验证通过才会进行后续通信,否则根据错误情况不同做出提示和操作,合法性验证包括如下:
- [证书链]的可信性 trusted certificate path,方法如前文所述;
- 证书是否吊销 revocation,有两类方式离线 CRL 与在线 OCSP,不同的客户端行为会不同;
- 有效期 expiry date,证书是否在有效时间范围;
- 域名 domain,核查证书域名是否与当前的访问域名匹配,匹配规则后续分析;
第四步 client_key_exchange+change_cipher_spec+encrypted_handshake_message
- client_key_exchange,合法性验证通过之后,客户端计算产生随机数字 Pre-master,并用证书公钥加密,发送给服务器;
- 此时客户端已经获取全部的计算协商密钥需要的信息:两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master,计算得到协商密钥; enc_key=Fuc(random_C, random_S, Pre-Master)
- change_cipher_spec,客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
- encrypted_handshake_message,结合之前所有通信参数的 hash 值与其它相关信息生成一段数据,采用协商密钥 session secret 与算法进行加密,然后发送给服务器用于数据与握手验证;
第五步 change_cipher_spec+encrypted_handshake_message
- 服务器用私钥解密加密的 Pre-master 数据,基于之前交换的两个明文随机数 random_C 和 random_S,计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
- 计算之前所有接收信息的 hash 值,然后解密客户端发送的 encrypted_handshake_message,验证数据和密钥正确性;
- change_cipher_spec, 验证通过之后,服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
- encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥session secret 与算法加密并发送到客户端;
第六步 握手结束
客户端计算所有接收信息的 hash 值,并采用协商密钥解密 encrypted_handshake_message,验证服务器发送的数据和密钥,验证通过则握手完成;
第七步 加密通信
开始使用协商密钥与算法进行加密通信。
HTTP状态码
HTTP状态码是在HTTP协议中用于表示服务器对请求的处理结果的三位数字代码。每个状态码都有特定的含义,用于指示请求的成功、重定向、客户端错误或服务器错误等情况。以下是一些常见的HTTP状态码及其含义:
200 OK:请求成功。服务器成功处理了请求,并返回了请求的内容。
201 Created:请求已成功,并且服务器创建了新的资源。
204 No Content:服务器成功处理了请求,但没有返回任何内容。
301 Moved Permanently:请求的资源已永久移动到新的URL。客户端应该使用新的URL进行后续的请求。
302 Found:请求的资源临时移动到了新的URL。客户端应该继续使用原始URL进行后续的请求。
400 Bad Request:客户端发送的请求有错误,服务器无法理解。
401 Unauthorized:请求需要身份验证。客户端需要提供有效的身份验证信息才能访问请求的资源。
403 Forbidden:服务器拒绝了请求,因为客户端没有访问权限。
404 Not Found:请求的资源不存在。
500 Internal Server Error:服务器在处理请求时发生了错误。
这只是一小部分常见的HTTP状态码,实际上还有很多其他状态码,每个状态码都有其特定的含义。了解HTTP状态码可以帮助开发人员诊断和调试与服务器通信时可能出现的问题。如果需要更详细的信息,可以使用搜索引擎进行进一步的查询。