【计算机网络之HTTP、TCP、UDP、HTTPS、Socket网络连接】

在理解HTTP以及网络传输之前先明确TCP/IP网络模型：

TCP/IP网络模型

TCP/IP 模型 是互联网实际在用的网络分层标准，所有网络通信（包括 HTTP、浏览器、接口、WebSocket）都跑在它上面。

它把网络分成 4 层：

应用层

应用层是网络协议栈的最上层，负责**应用程序之间的通信，**直接面向终端用户，提供各种网络应用服务。这一层是咱们前端人员最熟悉的层级，主要负责处理与用户直接交互的网络应用。你写的代码、浏览器、接口都在这一层。

典型应用层协议包括：

HTTP/HTTPS（网页浏览）

FTP（文件传输）

SMTP/POP3/IMAP（电子邮件）

DNS（域名解析）

WebSocket（实时通信）

前端开发中常见的应用场景：

网页开发：通过HTTP协议与服务器交互

移动应用：调用RESTful API获取数据

实时应用：使用WebSocket实现即时通讯

文件上传下载：利用FTP或其他文件传输协议

传输层（核心层）

主要负责端到端的数据传输，决定数据的传输方式。

核心协议：

TCP（传输控制协议，可靠传输）提供可靠的、面向连接的数据传输。通过三次握手建立连接，确保数据包的顺序和完整性，适用于需要高可靠性的场景，如网页浏览、文件传输。

UDP（用户数据报协议，快速传输）提供无连接的、快速的数据传输。不保证数据包的顺序或完整性，但延迟低、开销小，适用于实时性要求高的场景，如视频流、在线游戏。

QUIC 是运行在 UDP 之上、替代 TCP 的新一代传输层协议。多路复用 + 独立流，一个丢包只影响自己。

网络层

主要负责**寻址、路由，确定数据报的传输路径。**目的是找到对方在哪，走哪条路。

核心协议：

IP（IPv4 / IPv6）（互联网协议）：

IPv4使用32位地址，格式为192.168.1.1，地址空间有限。IPv6使用128位地址，格式为2001:0db8:85a3::8a2e:0370:7334，解决了IPv4地址耗尽的问题。

路由协议（如OSPF、BGP）动态选择最优路径，确保数据包高效到达目的地。

网络接口层（最底层）

网络接口层对应OSI模型的物理层和数据链路层，负责硬件层面的数据传输。

物理层涉及网卡、网线、Wi-Fi等硬件设备，将数据转换为电信号或光信号。数据链路层处理以太网帧，包含源MAC地址和目标MAC地址，确保数据在本地网络中的准确传输。

这一层与前端开发关系较小，但了解其存在有助于理解网络通信的完整流程。那么让我们开始HTTP的学习：

HTTP 的基本概念

HTTP（HyperText Transfer Protocol，超文本传输协议）是应用层 的无状态协议，基于 TCP/IP 协议簇实现客户端（浏览器 / 前端应用）与服务器的通信，核心作用是传输超文本（HTML、JSON、图片等），是 Web 通信的基础。

Http核心特性

特性	详细说明
无状态	服务器不保存客户端的任何会话信息（如登录状态），每次请求都是独立的
无连接（HTTP/1.0）	每次请求建立 TCP 连接，请求完成后立即断开，效率低
长连接（HTTP/1.1）	默认开启 `Connection: Keep-Alive`，一个 TCP 连接可处理多个 HTTP 请求
明文传输	数据以明文形式在网络中传输，无加密，存在窃听、篡改风险
简单可扩展	报文格式简单，通过请求头 / 响应头可灵活扩展功能（如 Cookie、缓存控制）

HTTP报文的组成成分：

请求报文{ 请求行、请求头、空行、请求体 } ，响应报文{ 状态行、响应头、空行、响应体 }。而其中请求行：{http方法、页面地址、http协议、http版本}。

HTTP工作原理

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。客户端向服务器发送一个请求报文，服务器以一个状态行作为响应。

补充：

建立 TCP 连接是 HTTP 通信的前提，因为 HTTP 本身不负责数据传输，依赖 TCP 保证数据可靠传输；

服务器处理请求的核心逻辑：匹配请求 URL 对应的接口 / 页面 → 校验请求参数 → 执行数据库 / 缓存操作 → 组装响应数据；

客户端解析响应：浏览器会根据 Content-Type（如 text/html/application/json）决定如何处理响应体。

HTTP请求/响应的步骤

1.客户端连接到Web服务器

2.发送HTTP请求

3.服务器接受请求并返回HTTP响应

4.释放TCP连接

5.客户端（浏览器）解析HTML内容
HTTP 的 5 种方法：GET，POST，PUT，DELETE，HEAD---获取报文首部。

补充：GET与POST的区别

浏览器回退表现不同 GET在浏览器回退时是无害的，而POST会再次提交请求

维度	GET	POST
语义	只读（查询）	写操作（增 / 改 / 删）
数据位置	URL 拼接（`?key=value`）	请求体（Body）
数据类型	仅支持 ASCII 字符	支持任意类型（JSON / 二进制 / 表单）
长度限制	因为在URL中拼接，故受浏览器 / 服务器 URL 长度限制（约 2KB）	无理论限制（服务器可配置上限）
缓存	GET请求地址会被浏览器主动缓存	默认不缓存（需手动设置 `Cache-Control`）
历史记录	参数保留在地址栏 / 历史记录	参数不保留
安全性	因为GET通过URL传递，明文暴露，低安全	相对安全（仍需 HTTPS 加密）
TCP 握手	一次 TCP 握手（请求 + 响应）	部分浏览器两次握手（先发送头，再发体）
幂等性	幂等（多次请求结果一致）	非幂等（多次提交可能重复创建数据）

【幂等性】是面试高频延伸考点：GET/PUT/DELETE 是幂等的，POST 非幂等；（具体在之前文章中详述）

【安全性】仅指【数据是否暴露】，POST 并非加密传输，需结合 HTTPS 才能保证数据安全。

TCP是什么

TCP是传输控制协议，可靠、面向连接、基于字节流的传输层协议。

TCP三大核心特点：

**面向连接：**必须先建立连接，才能通信。
可靠传输：
- 数据包丢失会重传
- 乱序会重排
- 重复会丢弃
- 校验和保证不篡改
字节流： 数据像水流一样连续，没有消息边界（ 这就是后面粘包的根源）。

既然知道TCP是什么，那就看一下TCP和UDP的区别：

对比维度	TCP	UDP
连接	面向连接（必须先建立连接）	无连接（发就完了）
可靠性	可靠：不丢包、不乱序、不重复	不可靠：可能丢包、乱序
传输方式	流式传输（没有边界）	数据报（有边界，一条一条）
拥塞控制	有（网络差会自动减速）	无
速度	较慢（握手、确认、重传）	极快
开销	大（头部 20 字节以上）	小（头部 8 字节）
适用场景	HTTP/HTTPS、文件传输、接口、登录	直播、游戏、视频通话、语音

拓展：为什么UDP能用于直播游戏等实时场景？

记住：TCP 怕丢包，不怕延迟； UDP 怕延迟，不怕丢包。

直播、游戏、视频通话、语音，全部都属于：实时性 > 可靠性。

TCP 为什么不能做直播 / 游戏 / 视频？

你先想想：如果视频 / 语音用 TCP 传输，会发生什么？

TCP 有三大机制：

丢包必须重传
数据必须按顺序
堵塞控制

这三个机制，对实时场景是致命的：

丢包重传 = 卡顿、延迟爆炸

网络一差，丢一个包，且TCP 必须等重传成功，才继续往后播放，结果就是：画面卡住、声音卡住、延迟越来越大。

顺序保证 = 必须排队

后面的包到了，前面的包没到，TCP 会卡住等前面的 ，对于直播 / 视频：直接卡顿。

拥塞控制 = 网络一差就减速

网络差 → TCP 自动降速，对于直播 / 游戏：越卡越慢，越慢越卡。

UDP 为什么天生适合直播、游戏、视频、语音？

UDP 的3 个特点，全踩中实时场景的需求：

无连接，发就完了；

不保证到达，不保证顺序；

不管网络好坏，只管拼命发

UDP 在直播 / 游戏 / 视频 / 语音里到底怎么工作？

1. UDP 在【视频直播】里的作用（抖音 / 快手 / B 站直播）

直播特点：一秒钟几十帧画面，丢一两帧根本看不出来。

UDP 做的事：

服务器疯狂推流，不管你收没收到
丢一帧？直接丢掉，播放下一帧
绝对不卡顿、不等重传
保证画面流畅、低延迟

你在直播里偶尔看到的花屏、模糊、卡顿一下 ，就是丢包，但不影响整体观看。

如果用 TCP：

丢包 → 重传 → 卡住
延迟从 1 秒变成 5 秒、10 秒
主播说 "扣 1"，你 5 秒后才看到，直播就废了。

2. UDP 在【实时游戏】里的作用（王者 / 吃鸡 / LOL）

游戏特点：操作必须实时，延迟高就会 "飘""瞬移""打不中"。

UDP 做的事：

你的位置、移动、攻击、技能，全部用 UDP 狂发
丢一个位置包？直接用最新位置覆盖
绝不等待旧包，保证操作跟手

例子：你往前走，网络抖了一下，丢了 2 个包。

TCP：卡住，等重传，你人物不动
UDP：直接用最新的位置，人物继续走，几乎无感

游戏里偶尔出现的 "瞬移一下"，就是丢包，但比卡顿强一万倍。

3. UDP 在【视频通话 / 语音通话】里的作用（微信 / 抖音 / 腾讯会议）

语音 / 视频特点：人对延迟非常敏感，但对偶尔丢帧 / 杂音容忍度很高。

UDP 做的事：

声音 / 画面持续不断发送
丢一帧声音？直接跳过，播放下一段
你只会听到极短的卡顿 / 杂音，但不会 "延迟对话"

如果用 TCP：

你说完话，对方3 秒后才听到
你俩不停抢话，根本没法聊

UDP 实时场景的核心逻辑

直播、游戏、视频通话、语音这类实时场景，

追求的是"低延迟、流畅"，而不是"100%不丢数据"。

TCP 丢包必须重传，会导致卡顿和延迟累积，不适合实时通信。

UDP 不保证可靠、不保证顺序、不阻塞，允许少量丢包，保证实时性优先，所以是实时音视频、游戏的最佳选择。

进阶拓展：UDP 不可靠，那视频通话怎么保证清晰？

答案：我们在 UDP 之上，自己实现一套 "轻量可靠"，不用 TCP 那套重的。

比如大名鼎鼎的：

WebRTC（浏览器视频通话标准）
RTMP（直播推流）
RTP/RTCP（音视频传输协议）

它们在 UDP 基础上，只做必要的保障：

只重传最重要的包（比如关键帧）
不重要的包（如普通画面）丢了就丢
自己控制速度，不搞 TCP 那种拥塞控制

一句话：UDP 提供底层高速通道，应用层自己控制可靠性。

极简总结

TCP：可靠、有序、重传 → 适合网页、接口、文件；

UDP ：快速、无阻塞、不重传 → 适合直播、游戏、视频、语音；

实时场景：延迟比不丢包更可怕，所以必须用 UDP。

拓展：HTTP/3 为什么基于 UDP？（超级重点）

**首先明确：HTTP/3底层：**HTTP/3 = HTTP + QUIC + UDP

复制代码

HTTP/3
↑
QUIC（可靠传输 + 加密 + 多路复用）
↑
UDP（只负责发包，不保证可靠）

原因：HTTP/3 放弃 TCP，改用基于 UDP 的 QUIC 协议，核心是为了解决 HTTP/2 仍然存在的【队头阻塞】问题，同时实现更快的连接、更低的延迟、更好的移动端网络切换体验。1. HTTP/2 基于 TCP，仍然存在 TCP 队头阻塞，无法解决；

TCP 在内核中，难以升级改造；

所以基于 UDP 实现了新的 QUIC 协议；

QUIC 解决了队头阻塞，实现了 0-RTT 快速握手，支持网络无缝切换；

UDP 只负责传输数据包，可靠性、加密、多路复用由 QUIC协议在应用层上保证。

重点：为什么 QUIC 一定要基于 UDP？

① UDP 无连接、无状态，方便自定义协议

TCP 是操作系统内核实现的，改不了 。UDP 就像一张白纸，应用层可以随便造协议 。QUIC 就是在 UDP 之上实现的用户态可靠传输。

② 彻底解决「队头阻塞」

QUIC 里：多个流完全独立 ，一个流丢包 不影响其他流 ，不会整个连接卡死。这是 TCP 永远做不到的。

③ 握手更快：0-RTT（1-RT建联，0-RT重连）

TCP + TLS 要 3~4 次握手 ，QUIC 建立加密连接 1 次就够 。重复连接，0 次延迟， 打开网页更快、首屏时间更短。

④ 支持网络无缝切换

手机从 WiFi 切到 5G：TCP：连接断开，重连；QUIC：Connection ID 标识，连接 ID 不变，**不断线、不重连。**对移动端体验提升巨大。
UDP 不是不可靠吗？怎么能用来做 HTTP？

可靠性不由 UDP 保证， 而是由 QUIC 协议在应用层自己保证。

TCP 三次握手

HTTP 基于 TCP 协议，「三次握手」是建立可靠连接的核心。

目的：确保客户端和服务器的「发送能力」和「接收能力」都正常，避免无效连接。

第一次握手：客户端喊「服务器，我要连你！」（告诉服务器：我能发消息）；

第二次握手：服务器喊「收到！我也能连你！」（告诉客户端：我能收 + 能发）；

第三次握手：客户端喊「收到！那开始通信吧！」（告诉服务器：我能收你的消息）。

为什么需要三次？

如果只有两次握手，服务器无法确认客户端能接收自己的消息，可能导致服务器向「收不到消息的客户端」持续发送数据，浪费资源。

TCP 四次挥手

「四次挥手」是断开 TCP 连接的流程，HTTP 长连接关闭时会触发。

目的：确保双方都完成数据传输，避免数据丢失。

HTTPS 的基本概念

HTTPS协议的作用：建立一个信息安全通道（以安全为目标的HTTP通道），来确保数据的传输，确保网站的真实性。

HTTPS（HyperText Transfer Protocol Secure）是「HTTP + SSL/TLS」的加密通信协议，通过加密解决 HTTP 明文传输的安全问题。

HTTPS 加密逻辑

非对称加密：用于交换「对称加密密钥」（公钥加密，私钥解密）；

对称加密：用于传输实际业务数据（速度快，效率高）；

数字证书：验证服务器身份，防止中间人攻击（由 CA 机构颁发）。

HTTPS完整通信流程：

HTTP和HTTPS的区别？

维度	HTTP	HTTPS
传输方式	明文传输	对称加密传输（非对称加密交换密钥）
端口	80（一般情况下）	443
证书	无需	需 CA 机构颁发的数字证书（收费 / 免费）
性能	无加密开销，速度快	加密 / 解密有开销，速度略慢（可优化）
安全性	低（易窃听、篡改、伪造）	高（防窃听、防篡改、防伪造）
资源消耗	服务器 / 客户端消耗低	服务器 / 客户端消耗高（加密计算）
SEO / 浏览器	部分浏览器标记【不安全】	搜索引擎优先收录，浏览器标记【安全】
配置复杂度	简单（无需证书）	复杂（需配置证书、SSL/TLS）

粘包问题分析与解决方案

TCP 是「流式协议」，无消息边界，当多个小数据包连续发送时，可能被合并成一个数据包传输，接收方无法区分边界，导致「粘包」。

前端直接接触粘包的场景较少，但在 WebSocket（基于 TCP）通信中可能遇到，例如：

连续发送两条 JSON 数据，服务器收到 {"a":1}{"b":2}，无法拆分；
游戏 / 实时通信场景，多条消息粘在一起，解析失败。

解决方案（前后端协同）：

方案	实现方式
固定长度分隔	每个数据包固定长度，不足补 0，接收方按长度截取
特殊分隔符	数据包末尾加分隔符（如 `\n`），接收方按分隔符拆分
消息头 + 消息体	头部标明消息长度（如 `length:10`），接收方先读长度，再按长度截取消息体

补充：分隔符

分隔符的核心要求是：不会出现在业务数据本身里（否则会误拆分），常用的分隔符主要分 3 类，按「使用频率」排序：

分隔符类型	具体示例	适用场景	优点	注意事项
换行类	`\n`（换行）、`\r\n`	文本协议（如日志、JSON、字符串）	简单、易识别、跨平台	业务数据里不能有裸换行符
特殊符号类	\|、#`、`$`、`∎	通用场景（游戏指令、短消息）	不易冲突、易解析	需约定好，避免和业务冲突
自定义边界字符串	`###END###`、`[SEP]`	复杂数据（含特殊符号 / 换行的文本）	几乎不会冲突	解析时需匹配完整字符串

HTTP/1、HTTP/2、HTTP/3整体架构图(详述见下一篇文章)：

客户端与服务端长连接的方式

**1.ajax 轮询的实现原理：**ajax 轮询指客户端每间隔一段时间向服务端发起请求，保持数据的同步。优点：可实现基础（指间隔时间较短）的数据更新。缺点：这种方法也只是尽量的模拟即时传输，但并非真正意义上的即时通讯，很有可能出现客户端请求时，服务端数据并未更新。或者服务端数据已更新，但客户端未发起请求。导致多次请求资源浪费，效率低下。即：【数据更新不及时，效率低下】。

ajax轮询的本质与 "实时性漏洞"：ajax 本身是 "异步 JavaScript 和 XML"，核心是客户端异步发起 HTTP 请求，而 ajax 轮询是利用 ajax 实现定时请求的逻辑。

ajax 轮询的逻辑：

javascript 复制代码

// 示例：每3秒发一次ajax请求
setInterval(() => {
  fetch('/get-data') // ajax请求
    .then(res => res.json())
    .then(data => {
      // 更新页面数据
      console.log('最新数据：', data);
    });
}, 3000);

本地没有 "暂存数据包"，到时间就发起新请求，服务端返回当前最新数据，客户端拿到后更新。

为什么实时性差（漏洞）：

假设轮询间隔 3 秒，若服务端在第 1 秒更新了数据，客户端要等到第 3 秒才能拿到，存在 2 秒延迟；
若服务端没更新数据，客户端的请求就是 "无效请求"，浪费带宽和服务器资源；
极端情况：客户端请求时服务端数据还没更，请求刚结束服务端数据就更了，导致数据同步完全错位。

这就是为什么 ajax 轮询只能做 "伪实时"，比如非核心的页面数据刷新（如商品库存，延迟几秒没关系），不能做聊天、实时通知等场景。

2.long poll 长轮询 实现原理： long poll 指的是客户端发送请求之后，如果没有数据返回，服务端会将请求挂起放入队列（不断开连接）处理其他请求，直到有数据返回给客户端。然后客户端再次发起请求，以此轮询。在 HTTP1.0 中客户端可以设置请求头 Connection:keep-alive(HTTP长连接)，服务端收到该请求头之后知道这是一个长连接，在响应报文头中也添加 Connection:keep-alive。客户端收到之后表示长连接建立完成，可以继续发送其他的请求。在 HTTP1.1 中默认使用Connection:keep-alive 长连接。优点：减少客户端的请求，降低无效的网络传输，保证每次请求都有数据返回，不会一直占用线程。缺点：无法处理高并发，当客户端请求量大，请求频繁时对服务器的处理能力要求较高。服务器一直保持连接会消耗资源，需要同时维护多个线程，服务器所能承载的 TCP 连接数是有上限的，这种轮询很容易把连接数顶满。每次通讯都需要客户端发起，服务端不能主动推送。【无法处理高并发，消耗服务器资源严重，服务端不能主动推送】

long poll 的核心问题是 TCP 队头阻塞吗?

long poll 基于 TCP（因为 HTTP 基于 TCP） ，但 long poll 的核心问题不是 TCP 队头阻塞 ，而是服务端资源占用和并发能力。

TCP 队头阻塞 ：TCP 是按序传输的，若一个数据包丢失，后续所有数据包都会等待重传，导致队列堵塞。但 long poll 的场景中，每个长轮询请求是独立的 TCP 连接，一个请求的堵塞不会影响另一个，所以队头阻塞不是它的主要问题。

long poll 的真正问题：

服务端要挂起大量请求（比如 1 万个客户端的长轮询请求），每个请求占用一个线程 / 连接，服务器的连接数上限很快被占满；

服务端有数据时，需要遍历挂起的请求队列，找到对应的客户端返回数据，高并发下效率极低；

依然是 "客户端主动发起"，服务端不能主动推（必须等客户端先请求）。

补充：虽然使用请求头 Connection:keep-alive（是 HTTP 长连接：复用同一个TCP，发送多次HTTP请求）（keep-alive只省握手不省头），但是每一次HTTP通信，依然要走：请求头->响应头->数据，即HTTP本身的开销并没有减少。

HTTP 长连接：复用 TCP 连接，减少握手开销；

long poll：单个 HTTP 请求长时间不返回，利用 HTTP 长连接的特性实现 "挂起"。单个 HTTP请求，服务端挂起延迟返回。
为什么说long poll利用HTTP长连接的特性实现挂起？

long poll想要实现稳定挂起，必须依赖keep-alive,保证TCP通道不断，以免TCP中途断掉导致挂起失败。

3.iframe长连接 实现原理： 在网页上嵌入一个 iframe 标签，该标签的 src 属性指向一个长连接请求。客户端页面嵌入 <iframe src="/long-connection"></iframe>，服务端接收到这个请求后，不会立即返回完整响应，而是持续向客户端输出数据（比如 <script>parent.updateData('新数据')</script>），客户端通过父页面监听脚本执行来更新数据，连接始终保持。这样服务端就可以源源不断地给客户端传输信息。保障信息实时更新。优点：消息及时传输。缺点：消耗服务器资源。

iframe 长连接的本质：不是框架，是 "伪装" 的长连接。

iframe 本身是 HTML 标签，核心作用是在当前页面嵌入另一个网页（可以理解成"网页框架" ），但它被用来做长连接是利用了一个特性：iframe 的 src 请求一旦建立，服务端可以持续向这个 iframe 输出数据（比如不断发送脚本标签），而不会断开连接。

和跨域的关系：iframe 本身和缓存、跨域的关联是 "附带属性"，不是它做长连接的核心。比如 iframe 加载跨域页面会有同源限制，但做长连接时是让iframe加载同域的、专门处理长连接的接口，所以跨域不是核心问题。

4.WebSocket **实现原理：**Websocket 实现了客户端与服务端的双向通信，只需要连接一次，就可以相互传输数据，很适合实时通讯、数据实时更新等场景。 Websocket 协议与 HTTP 协议没有关系，它是一个建立在 TCP 协议上的全新协议，为了兼容 HTTP 握手规范，先用 HTTP 协议发一次握手请求（带Upgrade），服务端同意升级，协议切换为WebSocket，之后数据通过 TCP 通道进行传输。 Websoket 数据传输是通过 frame 形式，一个消息可以分成几个片段传输。这样大数据可以分成一些小片段进行传输，不用考虑由于数据量大导致标志位不够的情况。也可以边生成数据边传递消息，提高传输效率。优点：双向通信。客户端和服务端双方都可以主动发起通讯。没有同源限制。客户端可以与任意服务端通信，不存在跨域问题。数据量轻。第一次连接时需要携带请求头，后面数据通信都不需要带请求头，减少了请求头的负荷（走TCP通道没请求头，响应头，Cookie,没有Method和状态码，因此WebSocket轻量）。传输效率高。因为只需要一次连接，所以数据传输效率高。缺点：长连接需要后端处理业务的代码更稳定，推送消息相对复杂；长连接受网络限制比较大，需要处理好重连。兼容性，WebSocket 只支持 IE10 及其以上版本。服务器长期维护长连接需要一定的成本，各个浏览器支持程度不一；成熟的 HTTP 生态下有大量的组件可以复用，WebSocket 则没有，遇到异常问题难以快速定位快速解决。【需要后端代码稳定，受网络限制大，兼容性差，维护成本高，生态圈小】

WebSocket 到底是什么？

WebSocket 是基于 TCP 协议的全双工通信协议，可以把它理解成：客户端和服务端之间建立了一条 "永久的双向管道 "，一旦连接建立，双方都能主动给对方发数据，不需要像 HTTP 那样每次请求都要 "握手 - 响应 - 断开"。

特点：兼容 HTTP 握手 ：第一次连接时，客户端发的是 HTTP 请求（带 Upgrade: websocket 头），服务端响应后，协议就升级为 WebSocket，后续数据直接通过 TCP 传输，不再走 HTTP 流程。举例：聊天软件中，服务端有新消息可以直接推给客户端，客户端也能随时发消息，不用客户端先问、服务端再答。

核心-实时性：和 ajax 轮询 / 长轮询的 "模拟实时" 不同，WebSocket 是真正的实时通信，因为连接一直保持，数据到达后能立即传输。

利用Socket建立网络连接的步骤

建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket 。套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。

流程如下：

服务端：启动 ServerSocket，绑定端口（比如 8080），开始监听（相当于接待员站在门口等客人）；

客户端：创建 ClientSocket，指定服务端的 IP 和端口（比如 192.168.1.1:8080），发起连接请求（客人上门）；

服务端：监听到请求后，创建一个新的 Socket（注意：不是新线程，线程是编程层面的处理方式）和客户端的 ClientSocket 建立连接（接待员带客人到单独的房间）；

服务端的 ServerSocket 继续监听，能和多个客户端建立连接（一对多）；连接建立后，客户端和服务端通过各自的 Socket 双向传数据。

套接字（Socket）是什么？

可以把 Socket 理解成：操作系统提供的、用于实现网络通信的 "接口 / 工具"。网络通信的本质是两台机器的进程之间传数据，Socket 就是让进程能 "抓住" 网络连接的 "把手"；比如：服务端的 ServerSocket 是 "监听门口的接待员"，客户端的 ClientSocket 是 "上门拜访的客人"，两者通过 Socket 完成连接和数据传输。

Socket 基于什么协议？

Socket 本身是接口，它可以基于不同的传输层协议：最常用的是 TCP：可靠、按序传输。WebSocket、HTTP、长轮询的底层都是 TCP Socket（所有网络通信，底层都是Socket+TCP/UDP）；也可以基于 UDP：不可靠、无连接，比如直播弹幕、游戏实时数据传输。

Socket 解决高并发的核心：不是 "多线程" 本身，而是通过IO 多路复用（比如 Linux 的 epoll、Java 的 NIO），让一个线程处理多个 Socket 连接，避免每个连接占用一个线程，从而支撑高并发。

总结

iframe长连接 ：利用 iframe 标签的持续加载特性实现长连接，本质还是 HTTP 请求，核心问题是消耗服务器资源；

WebSocket：基于 TCP 的全双工协议，一次连接双向通信，是真正的实时长连接，缺点是需要处理重连、兼容性稍差；

long poll 长轮询：HTTP 请求挂起直到有数据返回，核心问题是服务端连接数占用，而非 TCP 队头阻塞；

ajax 轮询：定时发起 ajax 请求，伪实时，存在数据延迟和无效请求，仅适用于低要求场景；Socket：是操作系统的网络通信接口，可基于 TCP/UDP，一对多连接靠 IO 多路复用支撑高并发。
核心区分：iframe/ajxa/long poll 都是基于 HTTP 的长连接模拟方案 ，而 WebSocket 是独立的实时通信协议，底层都依赖 Socket（套接字）实现网络连接。

主包到这里已经眼花缭乱神志不清了，晚安煲仔们~😀