MUYI · 后端工程师的生产级知识体系

Appearance

HTTP和HTTPS区别 ​

看在前面 ​

  • [计算机网络常见面试题](（原链已失效 2026-10，内容已在本篇/本库）%80-osi%E4%B8%8Etcpip%E5%90%84%E5%B1%82%E7%9A%84%E7%BB%93%E6%9E%84%E4%B8%8E%E5%8A%9F%E8%83%BD%E9%83%BD%E6%9C%89%E5%93%AA%E4%BA%9B%E5%8D%8F%E8%AE%AE)

一句话答案 ​

  1. 端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。

  2. 安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文。客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密。加密采用对称加密。但对称加密的密钥用服务器方的证书做了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

    • 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法例如 DES、AES；

    • 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥）。加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密）。相对对称加密速度较慢。典型的非对称加密算法例如 RSA、DSA。

一、分层本质：HTTPS = HTTP + TLS ​

HTTPS 不是"另一个 HTTP"，而是在 HTTP 与 TCP 之间垫了一层 TLS。HTTP 的报文格式、方法、状态码一个都没变，变的只是"交给 TCP 之前先加密、从 TCP 收到之后先解密"：

        HTTP（应用语义不变：GET/POST、Header、状态码……）
          │                            ▲
        发送前：TLS 加密               接收后：TLS 解密 + 校验
          ▼                            │
        TLS（握手协商 + 记录加密：机密性/完整性/身份认证）
          │                            ▲
          ▼                            │
        TCP（可靠字节流，三次握手，和明文时代完全一样）
          │
          ▼
        IP

  • 联系：HTTPS 完整包含 HTTP——同一套报文、同一套语义，只是传输通道从明文 TCP 换成 TLS 通道；

  • 区别：HTTP 明文、不认证、80 端口；HTTPS 密文、防篡改、可验证服务器身份（证书）、443 端口；

  • TLS 握手干了三件事。①用证书+数字签名完成服务端身份认证（防中间人冒充）。②用非对称算法协商出对称会话密钥。③双方约定密码套件后进入对称加密通信。密码学细节（消息认证码、数字签名、证书链、RSA 示例）见同目录 HTTPS中的TLS。

二、加密套件：名字怎么读 ​

一次 TLS 连接的参数写在套件名里，以 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 为例：

片段含义作用
TLS协议——
ECDHE密钥交换双方用椭圆曲线 Diffie-Hellman 算出会话密钥，且每次会话都不同（前向安全：私钥泄露也解不开历史流量）
RSA身份认证用 RSA 私钥给握手签名，证明"我就是证书上的那个服务器"
AES_128_GCM对称加密会话数据用 128 位 AES-GCM 加密，GCM 自带完整性校验
SHA256摘要算法握手与记录层做散列

  • TLS 1.3 把套件精简为 TLS_AES_128_GCM_SHA256 这类形式。密钥交换固定为 ECDHE，不再支持 RSA 直接交换密钥（也就天然具备前向安全）；

  • 注意区分 RSA 的两个用途：密钥交换（TLS1.2 及以前的 rsa 模式，已被淘汰）与身份认证（给握手签名，至今常用）。

三、性能成本与优化 ​

  • 握手成本是大头：TLS 1.2 完整握手要 2-RTT（外加 TCP 的 1-RTT）；TLS 1.3 压到 1-RTT，会话恢复（session ticket/PSK）可到 0-RTT；

  • 非对称只在握手用：进入通信后全程对称加密。AES 在现代 CPU 上有 AES-NI 硬件指令，单次开销是微秒级，通常不是瓶颈；

  • 证书链校验：首连要验签、可能还要拉中间证书、早期还有 CRL/OCSP 查询（现多用 OCSP Stapling 由服务端代查）；

  • 常见优化：启用会话复用、HTTP/2 或 HTTP/3（QUIC 把握手合并进传输层，0/1-RTT）、TLS 1.3、部署 OCSP Stapling、CDN 边缘终结 TLS。浏览器只支持"HTTP/2 over TLS"，所以上 HTTPS 通常是上 HTTP/2 的前置条件。多路复用反而摊薄了握手成本，参见 HTTP1.0、HTTP1.1 和 HTTP2.0 的区别；

  • 长连接与 TLS 的关系：HTTPS 长连接上多次请求只付一次握手成本，这就是连接复用的价值。参见 HTTP长连接、短连接究竟是什么。

四、常见追问 ​

  • "HTTPS 加密了 URL 吗？"——路径与参数在 TLS 密文里，但域名会以明文出现在 DNS 查询与 TLS SNI 扩展里（ECH 正在解决后者）；

  • "HTTPS 防抓包吗？"——防第三方，不防"用户主动信任抓包工具证书"的场景。证书校验（域名匹配、有效期、信任链）做不严，中间人依然得逞；

  • "HTTP 完全没价值吗？"——内网、本地调试、性能极端敏感的静态分发仍会用，公网业务现在默认 HTTPS。

一句话总结：HTTPS 不是新协议，而是"HTTP 报文 + TLS 加密信道"的组合。端口、成本、安全性的差异都源于多出来的这一层 TLS。

延伸阅读：HTTPS中的TLS、TCP 三次握手和四次挥手、计算机网络常见面试题。

2026-10 扩充（Round1 查漏）。