图 1：本文封面，点明题目与「TLS 握手」这条主线。
先说明属性：这是一篇经典题解析，题目出自本地历史面试资料（见文末来源说明），与任何公司的当前招聘无关。这题人人都答得出「HTTPS 加密、HTTP 明文」，面试官追问一句「TLS 握手的过程说一下」，就能筛掉一半人——区别不在那个 S，在 S 背后建立安全通道的整套机制。
想象面试现场，面试官问：「HTTP 和 HTTPS 有什么区别？HTTPS 是怎么做到安全的？」
第一步，审题。
把答案组织成两层：先讲「有什么区别」（明文与加密、端口 80 与 443、是否需要证书、对中间人攻击的抵抗力），再讲「怎么做到的」（TLS 握手建立安全通道）。第二层是重心——只答第一层等于说「多了个 S」，正是标题里的陷阱。
第二步，基础回答：区别清单。
HTTP 是明文传输，链路上任何节点都能看见、篡改你的请求和响应；HTTPS 在 HTTP 之下垫了一层 TLS，提供三件事——加密（防窃听）、完整性校验（防篡改）、身份认证（证书证明对方是真的对方）。RFC 8446 对 TLS 1.3 的目标描述就是这三点：防止窃听、篡改和消息伪造。代价是真实存在的：证书要申请和维护，握手要多花网络往返。所以「区别」的本质是一句话：HTTPS 用一次握手的开销，换来整条连接的机密性与可信身份。
第三步，进阶回答：TLS 握手怎么建立安全通道。
经典握手（以 TLS 1.2 为代表的流程）按时间顺序走这几步。一，客户端发 ClientHello：支持的 TLS 版本、一个随机数、自己会的加密套件列表。二，服务端回 ServerHello：选定版本与套件、也发一个随机数，并附上服务器证书。三，客户端验证证书：证书链是否由可信 CA 签发、是否在有效期内、域名是否匹配——这一步解决的是「对方是不是真的对方」。四，客户端生成预主密钥，用证书里的公钥加密后发给服务端，只有持有私钥的服务端能解开。五，双方各自用两个随机数加预主密钥算出同一把会话密钥。六，此后的 HTTP 数据全部用这把会话密钥做对称加密传输。
这里的设计巧思值得点破：非对称加密又慢又贵，所以只用来安全地交换密钥；真正的数据传输用快得多的对称加密。两种算法各干各擅长的活。
要补充一个版本事实：RFC 8446 定义的 TLS 1.3 对握手做了大刀阔斧的简化——砍掉了不安全的算法组合，密钥交换改用 ECDHE 类方式（不再有 RSA 直接加密预主密钥这一步），握手压缩到一个往返就能开始发数据，还支持会话恢复。面试时讲清经典流程，再补一句 TLS 1.3 的演进方向，显得你知道协议的现在时。
图 2：TLS 握手的六步时序，与非对称加密换密钥、对称加密传数据的分工。
第四步，可能的追问。
「中间人攻击为什么防得住？」攻击者没有服务端私钥，伪造不了证书链；客户端验证证书这一步就是专门挡它的。「证书是怎么被信任的？」操作系统和浏览器内置根 CA，服务端证书要能被逐级签回某个根。「HTTPS 就绝对安全吗？」不是——它保护的是传输链路，钓鱼网站也可以有合法证书，本地被装恶意根证书也会失守。安全永远是分层的。
易错点清单。
一，把 HTTPS 说成「加密版的 HTTP」就停住，讲不出握手流程。二，以为全程都用非对称加密传数据——它只负责交换会话密钥。三，说不清证书的作用，把「加密」和「身份认证」混为一谈。四，忽略 TLS 1.3 的存在，还停留在旧版握手的描述上。
回到面试现场，建议的答题节奏：先一句话给区别清单（加密、端口、证书、防中间人），再按六步时序讲握手，点破非对称换密钥、对称传数据的分工，最后补 TLS 1.3 的简化方向。链路和身份两件事都讲到，这道题才算完整。
调用大模型 API、传输用户数据都跑在 HTTPS 上，TLS 握手与证书链是排查 API 连接问题的前提。你遇到过最头疼的 HTTPS 报错是什么——证书过期、域名不匹配，还是 TLS 版本协商失败？欢迎分享。
参考资料
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3（IETF 标准文档：TLS 的设计目标为防止窃听、篡改与消息伪造；TLS 1.3 的握手流程、密钥交换与 0-RTT 等机制） — https://www.rfc-editor.org/rfc/rfc8446