你想弄明白这三者的关联，核心结论先给到你：TCP 是底层基础传输协议，HTTPS 和 WebSocket 都是基于 TCP 实现的上层应用层协议 ，且 WebSocket 还和 HTTP/HTTPS 有「亲缘 + 升级」关系，三者是层层依赖、从上到下归属的关系，不存在互斥，而是「地基 - 楼层」的逻辑。
一、先明确核心层级关系（最重要，一眼看懂）
计算机网络通信遵循 TCP/IP 五层模型 （应用层 → 传输层 → 网络层 → 数据链路层 → 物理层），这三者的固定归属层级 是：✅ TCP → 属于「传输层」核心协议，是整个互联网可靠通信的底层地基 ✅ HTTPS → 属于「应用层」协议✅ WebSocket → 属于「应用层」协议
三者的核心依赖关系：
TCP 是 HTTPS 和 WebSocket 的共同底层支撑 ，WebSocket 又基于 HTTP/HTTPS 协议完成「握手升级」，最终全部的传输数据，都要通过 TCP 协议在网络中可靠传输。
二、逐个讲透：TCP / HTTPS / WebSocket 分别是什么
✅ 1. TCP：传输层的「可靠通信地基」，所有的基础
TCP (Transmission Control Protocol，传输控制协议)，是传输层的核心可靠协议 ，也是互联网通信的基石。它不关心上层传输的「内容」（是网页、聊天消息、文件都无所谓），只负责解决一个核心问题：在不可靠的网络中，实现「两台设备之间的可靠、有序、双向的字节流传输」。
TCP 的核心特性（为什么所有上层协议都依赖它）
- 可靠传输：丢包会重传、数据错序会重新排序、数据重复会去重；
- 面向连接：通信前必须先「三次握手」建立连接，通信结束要「四次挥手」断开连接；
- 双向通信：连接建立后，双方可以同时发送和接收数据；
- 字节流传输：把数据当成连续的字节串传输，没有消息边界限制。
补充：传输层还有一个协议叫 UDP（无连接、不可靠、快），但 HTTPS、WebSocket 都不用 UDP，必须基于 TCP，因为网页、即时通信都需要「可靠传输」，丢包会导致页面加载失败、消息丢失。
✅ 2. HTTPS：应用层的「加密版 HTTP」，基于 TCP 封装
HTTPS (Hyper Text Transfer Protocol Secure)，本质是 HTTP + TLS/SSL 加密层 ，标准的应用层协议，100% 基于 TCP 协议实现。
关键前置：HTTP 与 TCP 的关系
HTTP（明文版网页协议）是直接建立在 TCP 之上的：
- 浏览器访问网页时，先和服务器基于 TCP 三次握手建立连接；
- 然后在这个 TCP 连接上，发送 HTTP 请求、接收 HTTP 响应；
- HTTP 1.0/1.1 默认是「短连接」：一次请求响应完成后，就断开 TCP 连接；HTTP 2/3 支持长连接，但核心逻辑不变。
HTTPS 就是「加密的 HTTP」
HTTP 的问题是明文传输 ，数据在网络中传输时，任何人都能抓取并看懂内容（账号密码、请求参数等），非常不安全。而 HTTPS 就是在「HTTP 和 TCP 之间」加了一层 TLS/SSL 加密协议：
TCP 连接建立后 → 先完成 TLS/SSL 握手，生成加密密钥 → 后续所有 HTTP 的请求 / 响应数据，都会被加密后再通过 TCP 传输 → 服务器解密后处理请求。
简单理解：HTTPS = HTTP + TLS/SSL（加密），全部基于 TCP 可靠传输 ，它的核心场景是「网页浏览、接口调用」这类一问一答、单向 / 双向但非实时的通信。
✅ 3. WebSocket：应用层的「全双工实时通信协议」，双依赖（TCP + HTTP/HTTPS）
WebSocket 是 HTML5 提出的专为「实时双向通信」设计的应用层协议，它的依赖关系是「双重的」：
✅ 底层传输：必须基于 TCP 协议 （继承 TCP 的可靠、面向连接特性）；✅ 连接建立：必须通过 HTTP/HTTPS 协议完成「握手升级」；升级成功后，就彻底脱离 HTTP 协议的束缚，进入独立的 WebSocket 通信阶段。
WebSocket 的核心特性（解决 HTTP 的痛点）
HTTP 协议的核心是「半双工通信 」：客户端发请求 → 服务器回响应，只有客户端主动发起，服务器才能回应，服务器不能主动给客户端发消息，而且每次请求都要带大量冗余头信息，效率极低。
而 WebSocket 是「全双工通信 」：连接建立后，客户端和服务器可以随时、主动、双向地给对方发送数据，没有「请求 - 响应」的束缚，且后续传输只有极简的帧头，传输效率极高，延迟极低。
三、最核心的「三者完整工作链路」（必看，彻底理清）
分两种常见场景，链路完整且连贯，看完就彻底懂了：
✅ 场景 1：浏览器访问一个 HTTPS 网页（只有 TCP + HTTPS）
- 客户端（浏览器）与目标服务器，基于 TCP 协议完成「三次握手」，建立一条可靠的 TCP 连接；
- 基于这条 TCP 连接，双方完成 TLS/SSL 加密握手，协商加密密钥，确认加密方式；
- 加密通道建立后，客户端通过 HTTPS 协议发送 HTTP 请求（请求头 + 请求体被加密）；
- 服务器解密后处理请求，通过 HTTPS 协议返回 HTTP 响应（响应头 + 响应体被加密）；
- 通信完成后，双方基于 TCP 协议「四次挥手」，断开 TCP 连接。
✅ 场景 2：网页中建立 WebSocket 实时连接（TCP + HTTPS + WebSocket，完整闭环）
这是最能体现三者关系的场景，比如：网页聊天、股票行情实时刷新、直播间弹幕、游戏实时交互，都是这个链路，一步都不能少：
- 第一步：建立 TCP 连接 → 客户端和服务器先通过 TCP 三次握手，建立基础的 TCP 连接（地基）；
- 第二步：HTTPS 加密握手 → 基于这条 TCP 连接，完成 TLS/SSL 加密握手，建立加密通道（HTTPS 的核心）；
- 第三步：HTTP 握手升级 → 客户端通过 HTTPS 协议 ，向服务器发送一个「特殊的 HTTP GET 请求」，请求头里必须包含
Upgrade: websocket和Connection: Upgrade，意思是：「我想把当前的 HTTPS 连接，升级成 WebSocket 连接」； - 第四步：服务器确认升级 → 服务器收到升级请求后，返回一个 HTTP 101 状态码（Switching Protocols），表示「同意升级」；
- ✅ 关键转折点 ：此时，HTTP/HTTPS 协议退场，WebSocket 协议正式登场，但底层的「TCP 加密连接」保持不变，不会断开；
- 全双工通信阶段 → 基于这条永久保持的 TCP 加密连接 ，客户端和服务器通过 WebSocket 协议，随时双向发消息（比如客户端发聊天内容，服务器实时推送其他人的消息），没有任何束缚；
- 通信结束（比如关闭网页）→ 双方基于 TCP 协议四次挥手，断开连接。
四、补充 2 个高频易混点（避坑，面试常考）
✅ 易混点 1：WebSocket 有两个对应协议，和 HTTPS 一一对应
- 基于 HTTP 升级的 WebSocket → 协议标识：
ws://（比如ws://localhost:8080），底层是 TCP 明文传输； - 基于 HTTPS 升级的 WebSocket → 协议标识：
wss://（比如wss://api.xxx.com），底层是 TCP + TLS/SSL 加密传输；
生产环境中只使用 wss://，和 HTTPS 一样，都是为了防止数据被窃听、篡改。
✅ 易混点 2：三者不是「并列关系」，而是「包含 / 依赖关系」
很多人会把三者当成平级的协议，这是最大的误区，正确的逻辑是：
所有的 HTTPS 通信，都包裹在 TCP 连接里 ；所有的 WebSocket 通信，先包裹在 HTTP/HTTPS 里完成升级，之后永久包裹在 TCP 连接里；TCP 是「容器」，HTTPS 和 WebSocket 是「容器里的内容」，WebSocket 还需要先借 HTTPS 的「门」进来。
五、总结（精炼版，背诵级，所有核心都囊括）
- 层级与归属 ：TCP 是「传输层」可靠协议，HTTPS、WebSocket 是「应用层」协议，三者从上到下是 应用层 → 传输层 的依赖关系；
- 核心依赖 ：TCP 是 HTTPS 和 WebSocket 的共同底层基础，没有 TCP 就没有后两者的可靠传输；WebSocket 额外依赖 HTTP/HTTPS 完成连接升级；
- 功能定位：TCP 管「可靠传」，HTTPS 管「加密的一问一答」，WebSocket 管「实时的双向互发」；
- 使用场景：网页浏览用 HTTPS，实时聊天 / 弹幕 / 行情用 WebSocket（wss://），两者底层全是 TCP。
希望这个梳理能帮你彻底理清三者的关系，逻辑清晰不混淆 ✅