HTTP与HTTPS详解

java_小白
176 阅读8分钟

HTTP

超文本传输协议（HTTP） 是一个用于传输超媒体文档（例如 HTML）的应用层协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。HTTP 遵循经典的客户端-服务端模型，客户端打开一个连接以发出请求，然后等待直到收到服务器端响应。HTTP 是无状态协议，这意味着服务器不会在两个请求之间保留任何数据（状态）。

HTTP有多个版本，目前广泛使用的是HTTP1.1版本。

HTTP是一个基于TCP/IP通信协议来传递数据的协议，传输的数据类型为HTML 文件,、图片文件, 查询结果等。

HTTP协议一般用于B/S架构，浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。

HTTP协议特点

HTTP 是简单的

虽然下一代HTTP/2协议将HTTP消息封装到了帧（frames）中，HTTP大体上还是被设计得简单易读。HTTP报文能够被人读懂，还允许简单测试，降低了门槛，对新人很友好。

HTTP 是可扩展的

在 HTTP/1.0 中出现的 HTTP headers 让协议扩展变得非常容易。只要服务端和客户端就新 headers 达成语义一致，新功能就可以被轻松加入进来。

HTTP 是无状态，有会话的

HTTP是无状态的：在同一个连接中，两个执行成功的请求之间是没有关系的。这就带来了一个问题，用户没有办法在同一个网站中进行连续的交互，比如在一个电商网站里，用户把某个商品加入到购物车，切换一个页面后再次添加了商品，这两次添加商品的请求之间没有关联，浏览器无法知道用户最终选择了哪些商品。而使用HTTP的头部扩展，HTTP Cookies就可以解决这个问题。把Cookies添加到头部中，创建一个会话让每次请求都能共享相同的上下文信息，达成相同的状态。

注意，HTTP本质是无状态的，使用Cookies可以创建有状态的会话。

HTTP 和连接

一个连接是由传输层来控制的，这从根本上不属于HTTP的范围。HTTP并不需要其底层的传输层协议是面向连接的，只需要它是可靠的，或不丢失消息的（至少返回错误）。在互联网中，有两个最常用的传输层协议：TCP是可靠的，而UDP不是。因此，HTTP依赖于面向连接的TCP进行消息传递，但连接并不是必须的。

在客户端（通常指浏览器）与服务器能够交互（客户端发起请求，服务器返回响应）之前，必须在这两者间建立一个 TCP 链接，打开一个 TCP 连接需要多次往返交换消息（因此耗时）。

HTTP/1.0 默认为每一对 HTTP 请求/响应都打开一个单独的 TCP 连接。当需要连续发起多个请求时，这种模式比多个请求共享同一个 TCP 链接更低效。

为了减轻这些缺陷，HTTP/1.1引入了流水线（被证明难以实现）和持久连接的概念：底层的TCP连接可以通过Connection头部来被部分控制。HTTP/2则发展得更远，通过在一个连接复用消息的方式来让这个连接始终保持为暖连接。

为了更好的适合HTTP，设计一种更好传输协议的进程一直在进行。Google就研发了一种以UDP为基础，能提供更可靠更高效的传输协议QUIC（http3.0）。

HTTP默认端口号

HTTP的默认端口号为80， HTTPS的默认端口号为443

HTTP的一些不足

  • 请求信息明文传输，容易被窃听截取
  • 没有验证对方身份，存在冒充危险
  • 数据的完整性未校验，容易被篡改

所以呢，才有了HTTPS的出现来弥补这些不足。

HTTPS

HTTPS协议（Hypertext Transfer Protocol over Secure Socket Layer）简单讲是HTTP的安全版，在HTTP协议的基础上加入SSL层(HTTP+SSL) 。 SSL（Secure Sockets Layer 安全套接层）主要用于Web的安全传输协议，在传输层对网络连接进行加密，保障在Internet上数据传输的安全。

SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间的会话层，为数据通讯提供安全支持。

TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。

TLS 的作用是在可靠的 TCP 协议上构建安全的传输通道，其本身是不提供可靠性保障的，我们还是需要下层可靠的传输层协议。在通信双方建立可靠的 TCP 连接之后，我们就需要通过 TLS 握手交换双方的密钥了，在这里我们将介绍 TLS 1.2 的连接建立过程：

image.png

  1. 客户端向服务端发送 Client Hello 消息，其中携带客户端支持的协议版本、加密算法、压缩算法以及客户端生成的随机数；
  2. 服务端收到客户端支持的协议版本、加密算法等信息后；
  3. 向客户端发送 Server Hello 消息，并携带选择特定的协议版本、加密方法、会话 ID 以及服务端生成的随机数；
  4. 向客户端发送 Certificate 消息，即服务端的证书链，其中包含证书支持的域名、发行方和有效期等信息；
  5. 向客户端发送 Server Key Exchange 消息，传递公钥以及签名等信息；
  6. 向客户端发送可选的消息 CertificateRequest，验证客户端的证书；
  7. 向客户端发送 Server Hello Done 消息，通知服务端已经发送了全部的相关信息；
  8. 客户端收到服务端的协议版本、加密方法、会话 ID 以及证书等信息后，验证服务端的证书；
  9. 向服务端发送 Client Key Exchange 消息，包含使用服务端公钥加密后的随机字符串，即预主密钥（Pre Master Secret）；
  10. 向服务端发送 Change Cipher Spec 消息，通知服务端后面的数据段会加密传输；
  11. 向服务端发送 Finished 消息，其中包含加密后的握手信息；
  12. 服务端收到 Change Cipher Spec 和 Finished 消息后；
  13. 向客户端发送 Change Cipher Spec 消息，通知客户端后面的数据段会加密传输；
  14. 向客户端发送 Finished 消息，验证客户端的 Finished 消息并完成 TLS 握手；

对称密钥建立过程

image.png

如何验证证书合法性

（1）首先浏览器校验证书的网站域名是否与证书颁发的域名一致，再检查SSL证书中的证书吊销列表，校验证书是否在有效期内
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
（4）如果找到，那么浏览器就会从操作系统中取出颁发者CA 的公钥(多数浏览器开发商发布
版本时，会事先在内部植入常用认证机关的公开密钥)，然后对服务器发来的证书里面的签名进行解密
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充

HTTPS优势

  • 内容加密建立一个信息安全通道，来保证数据传输的安全
  • 身份认证确认网站的真实性
  • 数据完整性防止内容被第三方冒充或者篡改

HTTPS劣势

  • HTTPS协议多次握手，导致页面的加载时间延长
  • HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗
  • 需要专业机构颁发CA证书，一般都是收费的，功能越强大的证书费用越高
  • SSL涉及到的加密算法会消耗一部分 CPU 资源
avatar
文章
阅读
粉丝