当前位置: 首页 > news >正文

网络通信详细总结

目录

---------

网络通信超详细总结

1.UDP 与 TCP 超详细总结

2.最简单的 HTTP vs WebSocket 终极对比

3.WebSocket 与 TCP 在【多客户端收发数据】时的核心区别

4.Qt 内部已经帮你封装好了 select /poll/epoll /kqueue!

TCP 与 UDP 超详细终极总结

一、一句话本质区别

TCP:面向连接、可靠、像打电话

UDP:无连接、不可靠、像寄信

二、超全对比表(面试直接背)

三、TCP 详细讲解(可靠但复杂)

1. 特点

2. 核心机制

3. 优点

4. 缺点

5. 使用场景

四、UDP 详细讲解(简单、极速)

1. 特点

2. 核心机制

3. 优点

4. 缺点

5. 使用场景

五、最关键的 4 个底层区别(必须懂)

1. 面向连接 vs 无连接

2. 可靠 vs 不可靠

3. 字节流 vs 数据报

4. 速度

六、TCP 粘包 VS UDP 不粘包(超级重点)

TCP 会粘包

UDP 永远不会粘包

七、使用场景怎么选?(一句话判断)

选 TCP

选 UDP

八、满分回答

TCP 和 UDP 的区别:

九、总结

TCP:可靠、安全、慢、有连接、字节流、粘包。

UDP:快速、简单、不可靠、无连接、数据报、不粘包。

--------

最简单的 HTTP vs WebSocket 终极对比

一句话总结(最核心)

**HTTP 是短连接、一问一答;

WebSocket 是长连接、双向实时通信。**

一、最直观的区别(一看就懂)

1. HTTP (你平时上网用的)

2. WebSocket (你现在项目用的)

二、核心区别(企业面试标准答案)

1. 连接方式

2. 通信方式

3. 性能

4. 服务器能不能主动发消息

5. 用途

三、最关键区别(你项目最关心)

HTTP 不能实现多客户端实时互通!

WebSocket 可以!

四、用生活例子比喻(超级好记)

HTTP 像 寄信

WebSocket 像 打电话

五、技术底层区别(简单版)

HTTP

WebSocket

六、企业真实使用场景

什么时候用 HTTP?

什么时候用 WebSocket?

七、最终总结(背下来 = 面试满分)

HTTP vs WebSocket 5 大区别

八、你现在的项目为什么必须用 WebSocket?

因为你要实现:

最终结论(企业标准答案)

HTTP:请求 - 响应,短连接,单向,被动。

WebSocket:长连接,双向,实时,主动推送,企业实时系统标准!

---------

WebSocket 与 TCP 在【多客户端收发数据】时的核心区别

一句话总结

一、先看本质区别

1. TCP(原生套接字 QTcpSocket)

2. WebSocket(基于 TCP + HTTP 握手)

二、多客户端连接时,接收数据的区别(最重要!)

1. TCP 服务端(QTcpServer)

TCP 你必须自己处理:

2. WebSocket 服务端(QWebSocketServer)

WebSocket 不用处理:

三、最关键区别:数据接收方式

TCP 接收数据

WebSocket 接收数据

四、多客户端数据独立隔离的区别(你最关心)

TCP 要实现独立:

WebSocket 要实现独立:

五、企业真实使用场景

企业什么时候用 TCP?

企业什么时候用 WebSocket?

六、最终总结(面试必背)

TCP vs WebSocket(多客户端接收数据)

七、你最关心的答案

你现在的 WebSocket 多客户端独立数据方案,企业 100% 会用!

TCP 太重、太难、太容易出 bug,WebSocket 才是业务系统主流!

----------Qt 内部已经帮你封装好了 select /poll/epoll /kqueue!

一句话结论

** 因为 Qt 内部已经帮你封装好了 select /poll/epoll /kqueue!

一、先讲清楚:

select /poll/epoll 是什么?

二、那为什么 Qt 程序里看不到?

因为 Qt 的网络模块全封装了!

你写的 readyRead () → 本质就是 epoll 通知上来的!

三、我给你看真实对应关系

四、企业开发为什么不直接写 select/poll?

1. 难!非常难!

2. Qt 已经做得非常完美了

3. 企业开发 绝对不会自己手写 poll/select

五、最关键的区别(面试必问)

原生裸 TCP(C++)

Qt TCP

六、企业真实答案

**Qt 不是不用 select/poll/epoll,

而是把它们封装到底层,让你无感知使用。**

企业里 99% 的 Qt 网络程序都不会直接写 select/poll!

七、你可以这样回答面试官(满分答案)

八、最终总结

** 你现在写的 Qt TCP 代码,

底层 = select/poll/epoll

上层 = 简单好用的信号槽 **

企业就是这么用的!完全正确!


---------

网络通信超详细总结

1.UDP 与 TCP 超详细总结

2.最简单HTTP vs WebSocket 终极对比

3.WebSocket 与 TCP 在【多客户端收发数据】时的核心区别

4.Qt 内部已经帮你封装好了 select /poll/epoll /kqueue!

TCP 与 UDP 超详细终极总结

(工作必用、全网最清晰版本)

我给你整理成最完整、最系统、最好记的版本,包含:区别、原理、优缺点、使用场景、头部对比、底层机制


一、一句话本质区别

TCP:面向连接、可靠、像打电话

UDP:无连接、不可靠、像寄信


二、超全对比表(面试直接背)

表格

对比项TCPUDP
全称传输控制协议用户数据报协议
连接面向连接(必须先建立连接)无连接(发就完了)
可靠性可靠:不丢、不乱、不重、不錯不可靠:可能丢包、乱序
传输方式字节流(无边界)数据报(有边界)
粘包会粘包(必须处理)不会粘包
效率慢(握手、确认、重传)极快(无额外开销)
重传机制
拥塞控制
滑动窗口
首部大小20~60 字节8 字节(极小)
适用场景文件、网页、消息、指令视频、直播、游戏、实时数据

三、TCP 详细讲解(可靠但复杂)

1. 特点

  • 必须三次握手建立连接
  • 必须四次挥手断开连接
  • 自动重传丢失的包
  • 自动排序乱序包
  • 自动流量控制 / 拥塞控制
  • 保证数据绝对可靠

2. 核心机制

  1. 三次握手→ 建立连接
  2. 确认应答 ACK→ 保证收到
  3. 超时重传→ 丢包自动补发
  4. 滑动窗口→ 提高传输效率
  5. 拥塞控制→ 防止网络堵死
  6. 四次挥手→ 安全断开

3. 优点

  • 100% 可靠
  • 有序
  • 无重复
  • 无错误
  • 全双工通信

4. 缺点

  • 开销大
  • 占资源
  • 会粘包

5. 使用场景

  • HTTP/HTTPS
  • 文件传输
  • 邮件
  • 登录、指令、配置
  • 要求不能丢数据的场景

四、UDP 详细讲解(简单、极速)

1. 特点

  • 不需要连接
  • 发出去就不管
  • 不保证到达
  • 不保证顺序
  • 数据报有边界,不会粘包
  • header 只有8 字节,超级轻量

2. 核心机制

几乎没有机制!

  • 打包 → 发送 → 结束

3. 优点

  • 速度极快
  • 延迟极低
  • 资源占用小
  • 不会粘包
  • 支持一对一、一对多、多对多

4. 缺点

  • 可能丢包
  • 可能乱序
  • 不保证到达
  • 无拥塞控制

5. 使用场景

  • 直播
  • 视频会议
  • 游戏
  • 实时数据采集
  • DNS
  • 在线语音
  • 要求速度 > 可靠性的场景

五、最关键的 4 个底层区别(必须懂)

1.面向连接 vs 无连接

TCP:必须先连接,再传输。UDP:直接发,不需要建立连接。

2.可靠 vs 不可靠

TCP:丢包自动重传。UDP:丢了就丢了,不管。

3.字节流 vs 数据报

TCP:像水流,无边界 → 会粘包。UDP:像包裹,一个包一个包 → 不粘包

4.速度

UDP 比 TCP快很多


六、TCP 粘包 VS UDP 不粘包(超级重点)

TCP 会粘包

因为是流,无边界,多个数据包会连在一起,接收方分不清。

UDP 永远不会粘包

一个 UDP 包就是一个完整消息,收就是收,没收就是没收到,永远不会粘在一起!


七、使用场景怎么选?(一句话判断)

选 TCP

数据绝对不能丢

  • 文件传输
  • 登录
  • 指令
  • 消息
  • 网页

选 UDP

速度最重要,丢一点没关系:

  • 视频
  • 直播
  • 游戏
  • 实时数据
  • 语音

八、满分回答

TCP 和 UDP 的区别:

TCP 是面向连接的可靠传输协议,通过三次握手建立连接,提供确认应答、超时重传、流量控制和拥塞控制,保证数据不丢失、不乱序、不重复,但效率较低,会产生粘包。UDP 是无连接的不可靠协议,不需要建立连接,没有重传机制,速度极快,开销小,不会粘包,适合实时性要求高的场景。


九、总结

TCP:可靠、安全、慢、有连接、字节流、粘包。

UDP:快速、简单、不可靠、无连接、数据报、不粘包。

--------

最简单HTTP vs WebSocket 终极对比

一句话总结(最核心)

**HTTP 是短连接、一问一答;

WebSocket 是长连接、双向实时通信。**


一、最直观的区别(一看就懂)

1. HTTP (你平时上网用的)

  • 客户端问一下,服务器答一下
  • 说完就断开
  • 不能服务器主动发消息给你
  • 无状态,每次都要重新连接

场景:网页、登录、查询、下载、接口请求

2. WebSocket (你现在项目用的)

  • 一次连接,永远不断开
  • 客户端 ↔ 服务器双向随便发
  • 服务器可以主动推消息给客户端
  • 实时、低延迟

场景:聊天室、实时数据、多客户端交互、消息推送、组态、上位机、大屏


二、核心区别(企业面试标准答案)

1. 连接方式

  • HTTP:短连接,请求完就断
  • WebSocket:长连接,一次连接永久通信

2. 通信方式

  • HTTP:单向 → 只有客户端能发起请求
  • WebSocket:双向 → 客户端、服务器都能主动发

3. 性能

  • HTTP:每次请求带大量请求头(耗流量)
  • WebSocket:只握手一次,后续数据头极小(极快)

4. 服务器能不能主动发消息

  • HTTP:不能!
  • WebSocket:能!

5. 用途

  • HTTP:获取页面、接口、数据查询
  • WebSocket实时通信、多客户端、数据推送、聊天室、组态上位机

三、最关键区别(你项目最关心)

HTTP 不能实现多客户端实时互通!

WebSocket 可以!

因为:

  • HTTP 服务器不能主动找客户端
  • WebSocket 服务器可以随时给任意客户端发数据

所以:你的多客户端独立数据项目 → 必须用 WebSocketHTTP 做不到!


四、用生活例子比喻(超级好记)

HTTP 像寄信

  • 写一封信 → 寄出去 → 等回信
  • 寄完关系结束
  • 不能对方主动给你发

WebSocket 像打电话

  • 拨通后一直在线
  • 你随时说,对方随时说
  • 服务器可以主动说话
  • 实时、连续、双向

五、技术底层区别(简单版)

HTTP

  • 基于请求 / 响应
  • 无状态
  • 消耗高
  • 延迟高

WebSocket

  • 基于TCP 长连接
  • 双向全双工
  • 消耗极低
  • 延迟极低(实时)
  • 自带消息帧,不粘包

六、企业真实使用场景

什么时候用 HTTP?

  • 登录注册
  • 查询数据
  • 提交表单
  • 图片 / 文件上传
  • 网页展示

什么时候用 WebSocket?

  • 多客户端互通
  • 实时数据展示
  • 服务器主动推送
  • 聊天室
  • 组态软件、上位机、工控
  • 你的项目!

七、最终总结(背下来 = 面试满分)

HTTP vs WebSocket 5 大区别

  1. HTTP 短连接,WebSocket 长连接
  2. HTTP 单向通信,WebSocket 双向
  3. HTTP 服务器不能主动发消息,WebSocket 可以
  4. HTTP 消耗高延迟高,WebSocket 低消耗低延迟
  5. HTTP 适合请求数据,WebSocket 适合实时通信

八、你现在的项目为什么必须用 WebSocket?

因为你要实现:

✅ 多客户端连接✅ 服务器主动群发 / 单发消息✅ 实时展示数据✅ 客户端之间互相通信✅ 不卡顿、高并发

这些 HTTP 完全做不到!


最终结论(企业标准答案)

HTTP:请求 - 响应,短连接,单向,被动。

WebSocket:长连接,双向,实时,主动推送,企业实时系统标准!



---------

WebSocket 与 TCP 在【多客户端收发数据】时的核心区别

一句话总结

TCP 是裸奔的底层协议,你要自己干所有事;WebSocket 是封装好的应用层协议,帮你把脏活全干完了。


一、先看本质区别

1. TCP(原生套接字 QTcpSocket)

  • 底层传输协议
  • 只传字节流,没有格式、没有边界
  • 没有 “连接标识”“消息包”“路由” 这些概念
  • 你必须自己处理:粘包、拆包、客户端 ID、数据格式

2. WebSocket(基于 TCP + HTTP 握手)

  • 应用层协议(TCP 之上封装)
  • 自带消息帧(一收就是一条完整消息)
  • 自带连接建立 / 心跳 / 关闭
  • 自带文本 / 二进制区分
  • 不用处理粘包,不用定义协议,不用写头长度

二、多客户端连接时,接收数据的区别(最重要!)

1. TCP 服务端(QTcpServer)

每个客户端连上来 → 给你一个 QTcpSocket客户端发数据 → 触发 socket 的 readyRead ()问题:你不知道是谁发的!必须自己存:socket → 客户端 ID*

TCP 你必须自己处理:

  1. 谁发的数据?(自己做映射表)
  2. 数据从哪开始到哪结束?(粘包问题)
  3. 数据格式是什么?(自己定义协议头)
  4. 客户端断开?(自己监听信号)

TCP = 全手动挡


2. WebSocket 服务端(QWebSocketServer)

*每个客户端连上来 → 给你一个 QWebSocket客户端发数据 → 直接触发 textMessageReceived ()而且:一整条消息直接给你,不带粘包!**

WebSocket 不用处理:

  1. 粘包拆包 ✅ 不用管
  2. 消息边界 ✅ 不用管
  3. 协议解析 ✅ 不用管
  4. 握手 / 挥手 ✅ 不用管

WebSocket = 自动挡


三、最关键区别:数据接收方式

TCP 接收数据

cpp

运行

void onReadyRead() { QByteArray data = socket->readAll(); // 字节流,可能是一半,可能粘包 // 你要自己解析:长度、命令、数据、客户端ID }

❌ 不知道一条数据从哪开始到哪结束❌ 不知道这是第几条数据❌ 不知道是谁发的(除非自己存)

WebSocket 接收数据

cpp

运行

void onTextMessageReceived(const QString &msg) { // 直接就是一条完整数据! }

✅ 一条就是一条✅ 不粘包✅ 不丢包✅ 格式完整


四、多客户端数据独立隔离的区别(你最关心)

TCP 要实现独立:

你必须自己:

  1. 给每个客户端分配 ID
  2. 维护map<socket, id>
  3. 维护map<id, 数据>
  4. 处理数据归属
  5. 处理粘包后才能判断是谁的数据

WebSocket 要实现独立:

只需要做一件事:

plaintext

map<QWebSocket*, 客户端数据>

因为:

  • 消息完整
  • 不粘包
  • 发送者就是当前 socket
  • 直接存对应数据即可

五、企业真实使用场景

企业什么时候用 TCP?

  • 高性能游戏
  • 物联网设备通信
  • 视频 / 音频传输
  • 私有协议、高度定制

企业什么时候用 WebSocket?

  • 网页客户端通信
  • APP 后台通信
  • 实时通知、消息推送
  • 聊天室、在线协作
  • 组态软件、上位机、大屏展示
  • 你现在做的这种:多客户端、多数据、界面展示

六、最终总结(面试必背)

TCP vs WebSocket(多客户端接收数据)

  1. TCP 是字节流,WebSocket 是消息流
  2. TCP 有粘包,WebSocket 无粘包
  3. TCP 需要自定义协议,WebSocket 协议现成
  4. TCP 要自己管理客户端身份,WebSocket 直接通过 socket 区分
  5. TCP 难,WebSocket 简单
  6. TCP 适合底层设备,WebSocket 适合 Web / 界面 / 客户端
  7. 你现在做的项目,WebSocket 是企业标准选择!

七、你最关心的答案

你现在的 WebSocket 多客户端独立数据方案,企业 100% 会用!

TCP 太重、太难、太容易出 bug,WebSocket 才是业务系统主流!

----------
Qt 内部已经帮你封装好了 select /poll/epoll /kqueue!

一句话结论

** 因为 Qt 内部已经帮你封装好了 select /poll/epoll /kqueue!

你写的readyRead()newConnection()底层就是用这些实现的!**

你不用自己写 poll/select,不是没用,而是被 Qt 隐藏了。


一、先讲清楚:

select /poll/epoll 是什么?

它们是操作系统提供的 IO 多路复用机制作用:一个线程监听成千上万个 socket 的可读、可写、连接

如果没有它们:

  • 1 个客户端 = 1 个线程
  • 1000 个客户端 = 1000 个线程
  • 服务器直接崩溃

所以高并发 TCP 必须用 select/poll/epoll


二、那为什么 Qt 程序里看不到?

因为 Qt 的网络模块全封装了!

Qt 的 TCP 底层架构真实样子

plaintext

你的代码: connect(socket, &QTcpSocket::readyRead, this, &xxx); ↓ 调用 Qt 底层 Qt 内核: QAbstractSocketEngine QSelectEngine / QPollEngine / QEPollEngine ↓ 调用系统API 操作系统: select() poll() epoll() (Linux) kqueue() (macOS)

你写的 readyRead () → 本质就是 epoll 通知上来的!


三、我给你看真实对应关系

表格

你写的 Qt 代码底层实际调用的系统函数
QTcpServer::listen()内部调用socket()+bind()+listen()
newConnection()select/poll/epoll触发
readyRead()select/poll/epoll触发
write()select/poll/epoll管理

四、企业开发为什么不直接写 select/poll?

1. 难!非常难!

  • 要处理大量文件描述符
  • 要维护数组 / 集合
  • 要处理超时
  • 要处理错误
  • 要区分监听 socket 与客户端 socket
  • 要处理跨平台

2. Qt 已经做得非常完美了

Qt 网络模块是工业级的

  • 自动跨平台(Windows/Linux/mac 自动切换 select/epoll/kqueue)
  • 自动管理所有 socket
  • 自动分发事件(readyRead, disconnected…)
  • 自动维护并发
  • 信号槽机制让代码超级简单

3. 企业开发绝对不会自己手写 poll/select

除非你自研底层网络框架(如 Netty、muduo)

否则:用 Qt → 不写 poll/select用 MFC → 不写 poll/select用 ACE → 不写 poll/select用 Boost.Asio → 不写 poll/select


五、最关键的区别(面试必问)

原生裸 TCP(C++)

plaintext

while(1) { select(...) for(...) { if(FD_ISSET(...)) 处理数据 } }

自己写循环,自己管理 fd,自己处理所有事件。

Qt TCP

plaintext

connect(m_socket, &QTcpSocket::readyRead, this, &onData);

不用循环,不用 select,不用管理 fd,不用处理并发。


六、企业真实答案

**Qt 不是不用 select/poll/epoll,

而是把它们封装到底层,让你无感知使用。**

企业里 99% 的 Qt 网络程序都不会直接写 select/poll!

因为:

  • 没必要
  • 易出错
  • 重复造轮子
  • Qt 已经是工业级标准

七、你可以这样回答面试官(满分答案)

Qt 的 QTcpServer 和 QTcpSocket 底层已经封装了 IO 多路复用,在 Linux 上使用 epoll,Windows 使用 select,mac 使用 kqueue。上层通过信号槽(readyRead、newConnection)暴露给开发者,因此不需要手动调用 select/poll/epoll,框架已经自动实现了高并发、高可靠的网络处理。


八、最终总结

** 你现在写的 Qt TCP 代码,

底层 = select/poll/epoll

上层 = 简单好用的信号槽 **

企业就是这么用的!完全正确!

http://www.rkmt.cn/news/1456110.html

相关文章:

  • 终极指南:5分钟快速上手RPG Maker解密工具,轻松提取加密游戏资源
  • 终极指南:3分钟快速上手RPG Maker解密工具,轻松提取加密游戏资源
  • AI剪辑长视频做录播,重点从来不是画面!
  • 抖音下载器技术深度解析:多策略智能降级架构与高效内容管理方案
  • 从‘灰光’到‘彩光’:手把手图解光模块在OTN网络中的角色转换与配置要点
  • analysis-ik性能优化:亿级中文文本分词的最佳实践与调优策略
  • 终极指南:使用SMU Debug Tool深度优化AMD Ryzen处理器性能
  • gh_mirrors/role/roles高级技巧:中间件验证与权限异常处理最佳实践
  • 朱雀大模型检测对降AI改写内容的适配性实测与原理拆解
  • 新手必看:Topxtral-4x7B-v0.1环境配置与依赖安装的极简步骤
  • 从零搭建智能推送中枢:用LlamaIndex+RedisAI+自定义规则引擎,72小时内上线可商用版本
  • 2026 成都离婚律所实测测评|打离婚官司优先选四川颂贤律师事务所 - 新闻快传
  • Linux 内核中的 IO 调度优化:从信号捕获到自动维护监控系统
  • 2026破圈!5款AI论文写作工具亲测,告别推倒重来,初稿一气呵成
  • 效率直接起飞!2026年好用一键生成论文工具榜单,高质初稿轻松写
  • 高级java每日一道面试题-2026年01月18日-实战篇[Docker]-如何清理仓库中的旧镜像?
  • 回答简单描述
  • AI驱动的智能治理闭环构建(2024政企合规刚需版):从工具孤岛到动态风控中枢
  • 智能拼团合规红线预警(GDPR+《生成式AI服务管理暂行办法》双框架适配方案),法务+技术联合签发
  • ProteinMPNN:当AI学会“设计“蛋白质,生物医药的未来会怎样?
  • Laravel 5 角色权限管理终极指南:从 is() 到 allowed() 的完整 API 解析
  • DIY无绳工具电池适配器:跨品牌电池兼容改造实战指南
  • 终极音频编辑指南:如何用Audacity制作专业级音效
  • 如何优雅地在 Laravel 视图中控制权限:gh_mirrors/role/roles Blade 指令完全指南 [特殊字符]
  • 5分钟快速上手:Windows平台最强大的开源按键映射工具QKeyMapper终极指南
  • 2026 文旅游乐商户开店优选!景区电玩乐园智慧票务核销系统全解析 - 新闻快传
  • NuExtract-1.5未来路线图:AI信息提取技术的发展趋势与创新方向
  • 【电赛终极杀器】别再只会写裸机主循环了!STM32进阶修仙指南:双缓冲DMA、FreeRTOS避坑与HardFault死机抢救
  • 黑龙江全梦文化传播有限公司:深耕黑龙江的一站式活动服务商 - 新闻快传
  • 2026年入户门推荐:装甲门 vs 防盗门,不同预算怎么选? - 新闻快传