简介天津理工大学计算机网络实验二实验报告——基于 TCP/UDP 的 Socket 编程是一份面向计算机网络课程学生和初学者的完整参考。报告详细说明了实验目的、环境与要求并完整记录了在 Linux Mint 系统下使用 Qt/C 实现聊天程序的整个过程包括服务端与客户端的源码、程序界面截图、状态图和测试用例。通过阅读可以掌握套接字的基本原理理解 TCP 与 UDP 的差异学习客户端/服务器结构软件的设计与开发方法。该资源以单个 PDF 文件打包大小仅 195KB内容紧凑清晰便于打印或在线阅读目前已有 288 人学习下载适合正在完成类似 Socket 实验的读者。此外报告还包含实验心得体会和 Socket、TCP/IP、Qt/C、客户端/服务器架构等知识点梳理能够帮助巩固网络编程基础加深对传输层协议的理解。1. 基于 TCP/UDP 的 Socket 编程这份实验报告到底在做什么拿到这份天津理工大学计算机网络实验二报告标题写着基于 TCP/UDP 的 Socket 编程我第一反应不是翻实验目的而是直接找源码。用 Qt/C 5.8.1 在 Linux Mint 上写一个聊天程序听起来只是常规课程作业但它恰好把计算机网络基础课程里最难落地的那部分串起来了三次握手、四次挥手能背可连接怎么建立、消息怎么收发、断开怎么感知一到动手就成了黑匣子。这份报告的价值在于它是一份能完整跑起来的工程服务端监听、客户端连接、双向收发、界面刷新都是现成的不是给你一堆截图和概念而是把传输层的功能真正落到了代码上。适合正在做课程实验的学生适合想把 Socket 机制弄透彻的自学者也适合需要快速搭一个客户端/服务器聊天 Demo 的开发者。期末复习时能背概念但这里解决的问题比概念更实际——程序跑起来链路通没通一看便知。2. 先读懂 Socket 机制再动手TCP 为什么是聊天程序的默认选择2.1 套接字是什么传输层给应用层开的门计算机网络自顶向下那套教材里套接字Socket的定义是应用进程与传输层协议之间的接口。这个定义容易背但动手写代码时经常露馅——它到底是函数库、文件还是一种协议从程序员角度看Socket 是操作系统提供的一组网络编程 API。你调用 socket() 创建套接字调用 bind() 绑定端口调用 listen() 进入监听状态调用 accept() 取出一个已完成连接的套接字收发数据靠 send()/recv() 或者 read()/write()。操作系统把数据从应用进程搬到网卡TCP/UDP 协议栈的细节确认号、窗口、重传由内核处理应用层感知不到也不需要感知。在 Linux 里socket() 返回的其实就是一个文件描述符所以你可以像读写文件一样用 read()/write() 操作它这解释了为什么很多网络程序的收发逻辑和文件读写长得一样。Qt 把这一套打包成 QTcpSocket 和 QTcpServer 类底层仍然是 socket、connect、accept 那套调用。实验报告里的 tcpSocket-write() 最终会落到内核发送缓冲区tcpSocket-readAll() 读的是内核接收缓冲区里已经到达的数据中间隔着一层完整的 TCP 协议栈。这个实验要求先理解原理再写代码就是因为 Qt 封装得比较严状态变化全靠信号通知。服务端调用 listen() 之后进入 LISTEN 状态客户端调用 connectToHost() 之后经历 SYN_SENT三次握手完成后服务端收到 newConnection 信号客户端进入已建立连接状态。这些状态变化在代码里就是一行 connect 信号槽的接线但背后的状态机是 TCP 协议定义的不理解状态机出问题就只能靠猜。提示做实验前建议先用 netstat -an 观察 6666 端口的状态变化把报文交互和程序行为对应起来对理解面向连接这个概念帮助很大。2.2 TCP 与 UDP 选型为什么聊天程序不用 UDP实验题目叫基于 TCP/UDP 的 Socket 编程但代码里全是 TCP。这不是偷懒是选型问题。聊天消息是文本要求不丢、不乱、不重复TCP 的可靠字节流天然匹配UDP 是尽力而为的报文传输丢包、乱序、重复都是常态适合音视频、DNS、游戏位置同步这类丢几帧无所谓、或者应用层自己处理丢失的场景。两个协议在网络编程层面有明确的边界。TCP 面向连接通信前先完成三次握手建立一条虚拟链路UDP 无连接每个数据报独立发往目标地址。这个差别反映到代码上TCP 需要服务端 listen、客户端 connect、服务端 accept而 UDP 只要 bind 一个端口就能收sendto/recvfrom 带上对方地址就能发。站在计算机网络应用层的视角看客户端/服务器架构里TCP 的连接特性让两端能维护同一个会话服务端不用每次从报文里解析来源UDP 则要自己在应用层记录每个报文从哪来要做可靠传输还得实现序号、确认、重传成本比 TCP 高一个量级。从传输层往下理解TCP 还有两个图表里看不到的好处。一是流量控制TCP 会根据接收方的窗口大小调整发送速率不会把对端缓冲区撑爆二是全双工同一个连接上双方可以同时读写聊天程序的服务端在转发消息时不需要额外加锁。UDP 虽然也有双工能力但没有拥塞控制发送端一急就狂发很容易在中间链路造成丢包。维度TCPUDP连接状态面向连接三次握手无连接发完即走可靠性可靠丢包重传、乱序重排不可靠丢包不负责数据边界字节流需要自己封帧数据报天然有边界典型场景文件传输、Web、聊天音视频、DNS、广播这个实验选 TCP就是因为聊天程序要的是字节流的可靠性。如果你把协议换成 UDP界面上打字发送倒是没问题但消息乱序、丢失、重复都会暴露出来还得自己加序号和确认机制复杂度不降反升。实验报告的题目里带着 UDP但代码没有偏离用 TCP 实现可靠聊天这个核心合理。2.3 Qt 的封装QTcpServer 与 QTcpSocket 的分工和信号时序Qt 网络模块把 Socket 编程拆成两个角色。QTcpServer 只负责监听和接受连接不参与数据收发QTcpSocket 才是真正干活的类客户端用它发起连接服务端 accept 之后从 QTcpServer 里取一个 QTcpSocket 出来收发数据。信号槽是事件通知机制关键信号有三个newConnection 表示有客户端完成了三次握手readyRead 表示接收缓冲区有数据可读error 表示底层 Socket 出错。这份实验报告里服务端的调用顺序是这样的newListen() 里调用 tcpServer-listen(QHostAddress::Any, 6666)监听本机所有网卡的 6666 端口有客户端连入时触发 newConnection 信号acceptConnection() 里用 nextPendingConnection() 取出对应的 QTcpSocket之后数据收发都走这个 socket。客户端的顺序更简单connectToHost() 发起连接连上后通过 readyRead 收数据write() 发数据。几个参数值得注意。QHostAddress::Any 表示监听任意网卡这样局域网内的其他机器也能连进来如果监听地址是 127.0.0.1那就只有本机能连。6666 是高端口号避开了 1024 以下的特权端口不需要 root 权限。客户端 connectToHost 的第一个参数写死为 127.0.0.1这是本机回环地址实验报告里服务端和客户端跑在同一台机器上没有问题跨机测试时要把这里改成服务端的局域网 IP否则客户端连的是自己。信号触发时序也是这个实验要理解的。客户端 connectToHost() 是异步的它只是发起连接请求立即返回服务端收到 newConnection 信号时三次握手已完成TCP 连接真正建立。之后任何一端 write() 的数据到达对端时对端的 readyRead 信号才会触发接收方在槽函数里 readAll() 读取。这个时序搞清楚了代码里的连接、收发顺序就有了依据后面判断问题也就有了方向。3. 把实验代码完整跑起来工程搭建、关键方法与测试用例3.1 环境准备Qt 5.8.1 工程怎么建实验报告写明的环境是 Linux Mint 18.1 64bit、内核 4.4.0、Qt/C 5.8.1。这套组合放现在偏旧但 Qt 5.8 的 QTcpServer/QTcpSocket 接口跟 5.15、6.x 几乎没变用新版 Qt 照样能跑。唯一必须注意的是 .pro 文件里要声明 network 模块不声明的话 QTcpServer 头文件都找不到编译直接报错。# chat.pro QT core gui network greaterThan(QT_MAJOR_VERSION, 4): QT widgets TARGET chat TEMPLATE app SOURCES main.cpp mainwindow.cpp HEADERS mainwindow.h这个 .pro 文件是 qmake 工程的入口。QT network 把 QtNetwork 模块加进工程QTcpServer、QTcpSocket、QHostAddress 都在这个模块里greaterThan 那两行是为了兼容 Qt4 和 Qt5 的差异Qt5 以后 widgets 模块要单独声明Qt Creator 新建工程时通常会自动带上。TARGET 是生成的可执行文件名SOURCE 和 HEADERS 列出项目源文件。工程里不需要额外链接 libQt 的模块依赖由 qmake 自动处理。编译用两条命令就够了qmake chat.pro make在终端里执行生成的可执行文件叫 chat。实验报告的服务端和客户端是两个独立程序最简单的方式是建两个子目录各自放一套 .pro、main.cpp、mainwindow.h、mainwindow.cpp分别编译出 server 和 client 两个二进制。如果你在 Qt Creator 里做新建两个 Console 或 Widgets 工程勾上 Network 模块把源码贴进去构建运行即可。这里提醒一句两个程序要分别启动先跑服务端再跑客户端顺序反了会触发第 4 章里说的问题。3.2 服务端代码拆解监听、接受连接与收发的顺序服务端的核心逻辑在 MainWindow 类里界面是 Qt Designer 拖出来的textEdit 显示聊天记录lineEdit 输入消息sendBtn 发送。初始化阶段干了三件事创建对象、启动监听、连接信号槽。void MainWindow::init() { tcpServer new QTcpServer; tcpSocket new QTcpSocket; newListen(); connect(tcpServer, SIGNAL(newConnection()), SLOT(acceptConnection())); connect(tcpSocket, SIGNAL(error(QAbstractSocket::SocketError)), SLOT(showError(QAbstractSocket::SocketError))); }init() 里先 new 出 server 和 socket 对象然后调用 newListen() 启动监听最后把 newConnection 信号和 error 信号分别接到对应槽函数上。有个细节要注意error 信号是在 init() 里 connect 到 showError 的但此时 tcpSocket 指向的是初始化时创建的那个空对象后面 acceptConnection() 会把指针覆盖成真正连接的 socket这个 error 连接是否还生效取决于覆盖后的对象有没有触发 error。一对一场景下问题不大多客户端场景就要重新接线。void MainWindow::newListen() { if(!tcpServer-listen(QHostAddress::Any, 6666)) { qDebug() tcpServer-errorString(); tcpServer-close(); } } void MainWindow::acceptConnection() { tcpSocket tcpServer-nextPendingConnection(); connect(tcpSocket, SIGNAL(readyRead()), SLOT(onReciveData())); }listen 的第一个参数是监听地址QHostAddress::Any 表示绑到本机所有网卡第二个参数 6666 是端口。监听失败会走 if 分支把错误信息打到终端并关闭 server常见原因是端口被占用后面避坑章会细说。acceptConnection 是 newConnection 信号触发后执行的槽函数nextPendingConnection() 从内核的连接队列里取出一个已经完成三次握手的 socket。取出来之后必须马上 connect readyRead否则对端数据到达时没有回调函数去读。void MainWindow::onReciveData() { QString data tcpSocket-readAll(); qDebug() data; mChat (Recv data); ui-textEdit-setText(mChat); } void MainWindow::sendMessage() { QString textEdit ui-lineEdit-text(); QString strData QString::fromLocal8Bit(Time: ) QTime::currentTime().toString() \n textEdit.toLocal8Bit() \n; QByteArray sendMessage strData.toLocal8Bit(); mChat (Send sendMessage); ui-textEdit-setText(mChat); tcpSocket-write(sendMessage); ui-lineEdit-clear(); }onReciveData 在 readyRead 信号触发后被调用readAll() 把内核接收缓冲区里的数据一次性读完。实验级写法直接 readAll 够用前提是对端一次只发一条完整消息一旦消息拆包或粘包readAll 读到的内容就不一定是完整的一条这个坑在第 4 章展开。sendMessage 是发送按钮的槽函数先拼字符串内容是Time: 时间戳 消息正文 换行再转成 QByteArray 发给对端同时追加到本机聊天记录 mChat 里。QString::fromLocal8Bit 表示按本地编码转换字符串Linux 下一般对应 UTF-8。发送成功后还调了 lineEdit-clear() 清空输入框这个小动作在客户端版本里没有体验上有差别。3.3 客户端代码拆解连接、发送与界面刷新顺序客户端结构更简单MainWindow 里只有一个 QTcpSocket没有 server。连接逻辑写在 init() 里程序一启动就自动尝试连服务端。void MainWindow::init() { tcpSocket new QTcpSocket; newTcpConnect(); connect(tcpSocket, SIGNAL(readyRead()), SLOT(onReciveData())); } void MainWindow::newTcpConnect() { tcpSocket-abort(); tcpSocket-connectToHost(127.0.0.1, 6666); }newTcpConnect() 里先 abort() 再 connectToHost()。abort() 的作用是清掉上一次连接遗留的状态避免 socket 还在旧连接上connectToHost 是异步发起连接不会阻塞等待握手完成函数立刻返回。这里硬编码的 127.0.0.1 是回环地址服务端和客户端在同一台机器上跑没问题跨机测试时改成服务端机器的局域网 IP。端口 6666 要和服务端 listen 的端口一致这个很容易被忽略。void MainWindow::onSendMessage() { QString textEdit ui-lineEdit-text(); QString strData QString::fromLocal8Bit(Time: ) QTime::currentTime().toString() \n textEdit.toLocal8Bit() \n; QByteArray sendMessage strData.toLocal8Bit(); mChat (Send sendMessage); ui-textEdit-setText(mChat); tcpSocket-write(sendMessage); } void MainWindow::onReciveData() { QString data tcpSocket-readAll(); mChat (Recv data); ui-textEdit-setText(mChat); }客户端发送逻辑和服务端几乎一样都拼时间戳和消息、追加到 mChat、写进 socket。这里的 mChat 是 QByteArray每次收到或发送数据都往后面累加。onSendMessage 里没有和服务端一样调用 lineEdit-clear()导致发送后输入框内容还在这是实验报告源码里一个明显的小疏漏不影响功能但影响体验。接收逻辑同样是 readAll 后追加显示。整个客户端只有 readyRead 连了槽函数error 信号声明了 onShowError 但没有 connect这是后面避坑章的重点案例。3.4 测试用例设计回环验证与跨机验证流程实验报告截图显示程序已经跑通。我复现时建议按这张顺序表走每一步对应一个明确的验证点步骤操作预期结果验证点1启动服务端终端无 errorString 输出listen 成功2netstat 查端口6666 处于 LISTEN 状态监听生效3启动客户端服务端界面出现新连接netstat 出现 ESTABLISHED三次握手完成4客户端发送一条消息服务端 textEdit 显示带 Time 前缀的消息客户端到服务端通路5服务端回复一条消息客户端 textEdit 同步显示服务端到客户端通路6关闭服务端再发消息客户端触发 error 信号有错误输出断开感知回环测试只能验证本机协议栈跨机测试还要额外确认三件事客户端 IP 改成服务端地址、防火墙放行 6666 端口、两个程序在不同机器上分别启动。服务端监听 QHostAddress::Any 已经为跨机做好了准备实验报告里唯一硬编码的是客户端的 127.0.0.1这是复现时最需要动的地方。4. Socket 编程避坑指南六个我在复现实验时踩过的坑4.1 服务端没启动客户端点发送毫无反应现象客户端先启动然后点发送按钮界面文本区没变化终端也没有任何报错程序像死了一样。原因服务端没监听 6666客户端的 connectToHost() 连接失败底层 socket 进入未连接状态write() 的数据被静默丢弃。客户端 init() 里只连接了 readyRead 信号onShowError 槽声明了但没接线error 信号没有人接收错误被吞掉了。解决在客户端 init() 里补一行 connect(tcpSocket, SIGNAL(error(QAbstractSocket::SocketError)), SLOT(onShowError(QAbstractSocket::SocketError)))并在 onShowError 里把 errorString() 用弹窗或 qDebug 输出。这是我复现时最后悔没早点发现的坑Qt 的异步错误信号不接上调试时间全耗在猜连接状态上。4.2 连续发两条消息对端只收到一条现象快速点两次发送对端 textEdit 里只显示一条消息或者两条消息连在一起没有换行。原因TCP 是字节流没有消息边界。两次 write() 的数据可能被 TCP 合并成一个段发出接收方的 readyRead 只触发一次readAll() 把两条内容一次性读完。这是传输层字节流的天然行为不是 bug。解决纯演示可以不做处理因为 mChat 是字符串拼接内容没丢只是显示成一条。要做可靠的消息边界最简做法是每条消息前加固定长度头比如 4 字节长度字段接收时先读 4 字节得到长度再按长度读正文。第 5 章会给具体实现这套封帧方案在真实项目里也很常用。4.3 服务端 accept 后覆盖 tcpSocket多客户端接入时数据串台现象第二个客户端连上来之后第一个客户端发的消息服务端不再显示甚至发给消息的客户端自己收不到回显服务端把数据全转发给了新连上的客户端。原因acceptConnection() 里每次执行 tcpSocket tcpServer-nextPendingConnection()都把成员指针指向最新的连接。前一个连接的 QTcpSocket 对象失去引用它的数据收发没人处理。实验只要求一对一覆写没问题但多客户端场景这个写法是致命的。解决用 QListQTcpSocket* 保存每个连接的指针readyRead 槽函数里通过 sender() 获取真正触发信号的 socket再用它判断是谁发来的、应该转发给谁。这个改动是实验到实战的分水岭第 5 章会展开。4.4 端口被占用服务端 listen 静默失败现象服务端启动后终端没有报错但客户端连接一直失败netstat 也看不到 6666 端口在监听。原因新 Listen() 里 listen 失败会打印 tcpServer-errorString() 到终端并调用 close()。但如果上一条连接断开后端口还在 TIME_WAIT或者别的进程占用了 6666listen 会返回 false而程序没有更明显的提示界面照常显示看起来就像没启动成功。解决启动服务端后用 netstat -an | grep 6666 确认端口状态。如果看到 TIME_WAIT等几十秒或换一个端口如果看到别的进程占着用 lsof -i :6666 查是谁kill 掉或者改端口号。实验里换个 6667、6668 就行代码里服务端和客户端的端口要同步改。4.5 程序崩溃或被杀后另一端收不到断开通知现象一端窗口关闭另一端还在正常打字发送界面也显示发送成功但收不到任何回复好一会后发送才失败。原因TCP 正常退出会发 FIN对端 readyRead 触发但 readAll() 返回空串代码里没有处理空串的情况空数据也被追加到聊天记录里。如果程序被 kill -9 或断网TCP 要等超时默认可能 2 小时才反应过来期间 send() 一直成功数据只进了本地缓冲区。解决在 onReciveData() 里判断 data 是否为空为空则调用 tcpSocket-disconnectFromHost() 并更新界面连接状态。需要更快的感知就给 socket 开启 QAbstractSocket::KeepAliveOption或者在协议层加心跳包服务端定期探测客户端存活状态。4.6 UI 线程里处理大块数据窗口拖拽卡顿现象对端一次性发来几 MB 数据readAll() 之后界面短暂无响应窗口拖不动。原因readyRead 信号默认在主线程触发readAll、字符串拼接、setText 全在同一线程里执行数据量大时 textEdit 刷新开销很高阻塞了 Qt 事件循环界面就卡住。解决实验规模不会触发这个问题但规范做法是重数据放工作线程处理用信号把结果抛回主线程只做一次 setText聊天记录用 QPlainTextEdit 追加而不是每次 setText 全量刷新。mChat 是只加不减的 QByteArray程序跑久了越占越多加个上限或定期清理是更稳妥的方案。注意第 4.2 和第 4.3 是最典型的网络程序玄学问题根源都不是代码逻辑难而是对 TCP 字节流模型和对象生命周期理解不到位。遇到这类问题先看报文和状态不要急着改代码。5. 从实验到实战多客户端聊天室、UDP 对照与粘包封帧5.1 多客户端转发用连接列表替代单一 tcpSocket 指针实验代码的服务端只能服务一个客户端因为成员变量 tcpSocket 永远指向当前 accept 出来的那个连接。改成多客户端核心是维护一个连接列表连接建立时添加断开时移除转发时遍历列表逐个 write。QListQTcpSocket* clients; void MainWindow::acceptConnection() { QTcpSocket *socket tcpServer-nextPendingConnection(); clients.append(socket); connect(socket, SIGNAL(readyRead()), this, SLOT(onReciveData())); connect(socket, SIGNAL(disconnected()), this, SLOT(removeClient())); } void MainWindow::onReciveData() { QTcpSocket *socket qobject_castQTcpSocket*(sender()); QByteArray data socket-readAll(); for (QTcpSocket *client : clients) { if (client ! socket) client-write(data); } } void MainWindow::removeClient() { QTcpSocket *socket qobject_castQTcpSocket*(sender()); clients.removeOne(socket); socket-deleteLater(); }这个版本有两个关键变化。每个新连接不仅要 connect readyRead还要 connect disconnected断开时调用 removeClient 从列表移除并用 deleteLater 释放对象避免野指针。接收时用 sender() 拿到真正触发信号的 socket而不是固定用成员变量转发时跳过来源客户端其他客户端都能收到消息这就是最简聊天室模型。deleteLater 而不是直接 delete是因为信号槽机制里还要留给事件循环处理当前事件的收尾。多客户端模式下QList 的操作都在主线程的槽函数里执行暂时不需要加锁如果数据收发挪到工作线程列表的增删和遍历就要用互斥锁保护否则多个线程同时操作 QList 会崩溃。5.2 UDP 对照实现一个 QUdpSocket 就能收发实验题目带了 UDP但代码里全是 TCP。用 Qt 实现 UDP 收发比 TCP 更简单一个 QUdpSocket 对象同时承担收发不需要 server 和 socket 两件套QUdpSocket *udpSocket; void initUdp() { udpSocket new QUdpSocket(this); udpSocket-bind(QHostAddress::Any, 7777); connect(udpSocket, SIGNAL(readyRead()), this, SLOT(onUdpReceive())); } void onUdpReceive() { while (udpSocket-hasPendingDatagrams()) { QByteArray datagram; datagram.resize(udpSocket-pendingDatagramSize()); udpSocket-readDatagram(datagram.data(), datagram.size()); // 处理 datagram } } void sendUdp() { QByteArray msg ui-lineEdit-text().toLocal8Bit(); udpSocket-writeDatagram(msg, QHostAddress(127.0.0.1), 7777); }bind 之后所有到达 7777 端口的 UDP 报文都会触发 readyReadhasPendingDatagrams 和 pendingDatagramSize 用来逐个取出完整报文。UDP 是数据报模型readDatagram 一次读一个完整报文天然保留消息边界不会有 TCP 那种粘包问题。sendUdp 的 writeDatagram 需要带目标地址和端口因为它无连接每个报文都要指定发往哪里。对照实验里可以做一个同样界面的 UDP 版聊天器把 QTcpSocket 换成 QUdpSocket去掉 listen/connect/accept 这一串两端都 bind 同一个端口发送时指定对方地址和端口。跑一遍就能直观感受到UDP 发消息不可靠体现在哪丢包没有重传报文不会按序到达这些在局域网里不明显把接收端关掉再发发送端是感知不到失败的。5.3 给消息加 4 字节长度前缀解决粘包的标准做法TCP 没有消息边界想可靠地切分消息最经典的做法是长度前缀封帧。发送端先用 4 字节写入消息长度再写消息内容接收端把数据累积到缓冲区按长度解析出完整消息。这里用 QDataStream 来封装长度字段它天然处理大小端跨机器通信不用手动转字节序。void sendMessageWithLength(QTcpSocket *socket, const QByteArray payload) { QByteArray block; QDataStream out(block, QIODevice::WriteOnly); out.setVersion(QDataStream::Qt_5_8); out quint32(payload.size()); block.append(payload); socket-write(block); } void receiveMessageWithLength(QTcpSocket *socket, QByteArray buffer) { buffer.append(socket-readAll()); while (buffer.size() 4) { QDataStream in(buffer); quint32 length; in length; if (buffer.size() 4 length) break; // 数据还没到齐等下一次 readyRead QByteArray payload buffer.mid(4, length); // 这里拿到一条完整消息交给业务层处理 buffer.remove(0, 4 length); } }setVersion 指定 QDataStream 的序列化版本不同 Qt 大版本之间的 QDataStream 格式不完全兼容两个通信端要用相同的版本。接收端 buffer 是外部维护的 QByteArray每次 readyRead 都追加解析出一条就移除一条直到剩余数据不足一个长度前缀的长度。这套封帧方案同时解决粘包和半包多包粘在一起会被循环拆开数据没到齐会自动等待下一次 readyRead。我在实际项目里一直沿用这个写法把 send 和 receive 封装成工具函数后业务层面对的就是完整消息流。6. 验证与收尾技巧用 netstat、tcpdump 和日志确认链路状态实验做完后真正有价值的一步是验证链路确实按理论走通了而不是界面能弹消息就算完。三个技巧值得每次都做。第一个netstat 观察端口状态。服务端启动后netstat -an | grep 6666 应该看到 LISTEN客户端连接成功后再执行一次能看到 127.0.0.1:6666 的 ESTABLISHED。这条记录意味着三次握手完成TCP 连接进入可用状态。程序退出后再看状态变成 TIME_WAIT说明四次挥手已经走完只是连接还在等待超时清理。把这些状态和教材上的状态机对应起来Socket 编程的黑匣子就打开了。第二个qDebug 打印关键事件。建议在 newListen、acceptConnection、onReciveData、sendMessage 入口各加一行带时间戳的日志。出问题时按日志时间线定位比盯着界面猜测强得多。我在复现这份实验时把日志打全后一眼看出客户端 onShowError 没接线——发送失败时界面没反应但日志里其实有 errorString 在输出。日志是最便宜的调试手段也是排查没反应类问题的第一步。第三个跨机测试前用 tcpdump 抓一次包。sudo tcpdump -i lo port 6666 能看到 SYN、SYN-ACK、ACK 三个报文依次出现配合 Wireshark 的 Follow TCP Stream 功能能清楚看到一条完整 TCP 流。这一步对理解面向连接非常有帮助报文时序和教材上的三次握手图完全对得上。这次复现下来我给自己定了个规矩凡是涉及网络的代码第一版跑通不算数必须把连接建立、数据收发、断开这三个时间点的日志和端口状态都核对过才算完。从那以后我每次做完实验都不急着写报告先在终端里把 netstat 和 qDebug 的输出过一遍确认链路真实状态再截图写实验结论。这份实验报告代码不大但该踩的坑一个不少对照着梳理一遍TCP 的可靠传输、UDP 的无连接特性、客户端/服务器架构的通信模型都会比单纯背教材清晰得多。希望帮到你。本文还有配套的精品资源点击获取