簡(jiǎn)介基于Qt框架構(gòu)建的跨平臺(tái)文件網(wǎng)絡(luò)傳輸系統(tǒng)面向具備一定C基礎(chǔ)的開發(fā)者和畢業(yè)設(shè)計(jì)學(xué)習(xí)者演示Linux服務(wù)器與Windows 10客戶端之間基于TCP的可靠文件傳輸。包體共23個(gè)文件以C源文件、頭文件、Qt界面文件.ui及工程配置文件.pro為主含少量備份與說明文檔壓縮包僅20KB代碼精簡(jiǎn)適合快速通讀。系統(tǒng)覆蓋網(wǎng)絡(luò)連接管理、文件分片校驗(yàn)、多線程分離I/O與界面響應(yīng)等實(shí)現(xiàn)細(xì)節(jié)服務(wù)端展現(xiàn)事件驅(qū)動(dòng)或線程池并發(fā)模型客戶端支持拖拽上傳與進(jìn)度實(shí)時(shí)反饋并預(yù)留SQLite持久化方案工程組織方式、平臺(tái)適配封裝與備份文件結(jié)構(gòu)也具備參考價(jià)值可作為理解套接字編程與Qt跨平臺(tái)編譯的實(shí)踐范本。當(dāng)前已有73人學(xué)習(xí)適合用于課程設(shè)計(jì)復(fù)盤或求職項(xiàng)目積累。1. Qt框架做文件傳輸不是只能寫界面的GUI庫很多人聽到Qt框架的第一反應(yīng)是“做桌面界面”但如果你把QTcpSocket、QTcpServer和跨平臺(tái)編譯這套組合用起來會(huì)發(fā)現(xiàn)Qt做網(wǎng)絡(luò)傳輸同樣順手。這份資源是一個(gè)典型的畢業(yè)設(shè)計(jì)題目Linux服務(wù)器負(fù)責(zé)接收和落盤Windows 10客戶端負(fù)責(zé)選擇文件和發(fā)送兩邊跑同一套基于Qt框架的代碼只是編譯目標(biāo)和運(yùn)行角色不同。整套系統(tǒng)不依賴第三方庫全用Qt自帶的network模塊斷點(diǎn)續(xù)傳、實(shí)時(shí)進(jìn)度、文件校驗(yàn)這些答辯加分點(diǎn)也都覆蓋到了。適合準(zhǔn)備Qt方向畢業(yè)設(shè)計(jì)、或者想快速搭一套跨平臺(tái)文件傳輸原型的開發(fā)者。先說清楚一點(diǎn)它不是什么大而全的網(wǎng)盤系統(tǒng)而是把TCP長(zhǎng)連接、分塊發(fā)送、自定義報(bào)文協(xié)議這幾個(gè)基本功串起來做成一個(gè)能跑、能演示、能繼續(xù)擴(kuò)展的骨架。2. 系統(tǒng)架構(gòu)與傳輸協(xié)議先定好包頭后面少改十次代碼2.1 整體角色劃分與關(guān)鍵模塊這套系統(tǒng)分兩端。服務(wù)器端運(yùn)行在Linux上啟動(dòng)后監(jiān)聽固定端口維護(hù)一個(gè)QTcpSocket連接接收客戶端傳過來的文件數(shù)據(jù)邊收邊寫入磁盤?？蛻舳诉\(yùn)行在Windows 10上提供一個(gè)QWidget界面讓用戶填服務(wù)器IP和端口、選擇本地文件、設(shè)置保存路徑然后點(diǎn)按鈕開始發(fā)送。網(wǎng)絡(luò)這塊全部走Qt的network模塊不引入額外庫。底層是TCP這意味著兩端之間是可靠字節(jié)流丟包重傳由內(nèi)核完成我們只需要關(guān)心“怎么從字節(jié)流里切出完整的業(yè)務(wù)數(shù)據(jù)”。這個(gè)切分邏輯就是協(xié)議設(shè)計(jì)的核心也是整個(gè)項(xiàng)目里最容易翻車的地方。模塊劃分上服務(wù)器端拆成監(jiān)聽入口和連接處理兩個(gè)對(duì)象客戶端拆成界面和傳輸邏輯兩部分。傳輸邏輯用QFile讀文件、QTcpSocket收發(fā)數(shù)據(jù)界面只管進(jìn)度條和狀態(tài)文本。這樣分離的好處是如果之后要加命令行版本去掉界面部分就行傳輸核心可以復(fù)用。2.2 自定義二進(jìn)制協(xié)議固定包頭加變長(zhǎng)負(fù)載我見過不少人拿著QDataStream直接整包發(fā)小文件沒問題一到幾百M(fèi)B就各種對(duì)不齊。正確做法是設(shè)計(jì)一個(gè)固定長(zhǎng)度的包頭后面跟上變長(zhǎng)的文件名和數(shù)據(jù)區(qū)。// protocol.h #pragma once #include QtGlobal // 命令字定義 enum UploadCmd { CMD_UPLOAD_INIT 100, // 客戶端聲明要傳文件 CMD_DATA_BLOCK 110, // 數(shù)據(jù)塊 CMD_UPLOAD_FINISH 120, // 數(shù)據(jù)發(fā)送完畢 CMD_QUERY_OFFSET 130, // 查詢服務(wù)器已接收大小 CMD_RESPONSE_OFFSET 200, // 服務(wù)器回復(fù)偏移量 CMD_ERROR_RESP 300 // 錯(cuò)誤響應(yīng) }; // 每個(gè)包的前 32 字節(jié)固定結(jié)構(gòu) struct PacketHeader { quint32 magic; // 固定魔數(shù) 0x5A5A5A5A用來識(shí)別有效包 quint32 cmd; // 命令字 quint32 filenameLen; // 文件名字節(jié)長(zhǎng)度 qint64 fileSize; // 文件總大小 quint32 blockIndex; // 塊序號(hào)從 0 開始 quint32 blockLen; // 本塊數(shù)據(jù)長(zhǎng)度 quint32 blockCrc32; // 塊內(nèi)數(shù)據(jù) CRC32 校驗(yàn) qint64 fileOffset; // 本塊在文件中的偏移量 };代碼說明包頭一共32字節(jié)其中magic是固定值0x5A5A5A5A。接收端每次先從緩沖區(qū)里讀32字節(jié)檢查magic如果對(duì)不上就說明后續(xù)解析狀態(tài)已經(jīng)錯(cuò)亂直接斷開連接重新來。filenameLen和fileSize都是發(fā)文件時(shí)已知的信息服務(wù)器端拿到后可以先檢查磁盤空間。blockCrc32是每個(gè)數(shù)據(jù)塊的校驗(yàn)值接收端算一遍不一致就把整個(gè)塊丟掉并請(qǐng)求重傳。參數(shù)說明blockIndex從0遞增配合fileOffset就能支持亂序和續(xù)傳。實(shí)際發(fā)送時(shí)按順序發(fā)但服務(wù)器端仍然以fileOffset為準(zhǔn)來決定寫入位置。CRC32這里承擔(dān)的是“塊級(jí)校驗(yàn)”文件級(jí)別的完整性另用MD5在收尾時(shí)做詳見后面章節(jié)。2.3 為什么不用現(xiàn)成協(xié)議這個(gè)項(xiàng)目是畢業(yè)設(shè)計(jì)場(chǎng)景。用HTTP上傳文件很簡(jiǎn)單但答辯時(shí)你很難展示自己對(duì)網(wǎng)絡(luò)傳輸?shù)睦斫庖驗(yàn)镠TTP協(xié)議把分塊、響應(yīng)、狀態(tài)碼這些事情全部封裝掉了。FTP同樣是個(gè)選項(xiàng)不過FTP有控制連接和數(shù)據(jù)連接兩條通道還要處理被動(dòng)模式端口協(xié)商跨平臺(tái)時(shí)兩個(gè)被動(dòng)模式命令互相不兼容的情況很常見。自定義二進(jìn)制協(xié)議的好處是你能明確說出“這一塊是包頭解析這一塊是粘包處理這一塊是校驗(yàn)邏輯”每段代碼對(duì)應(yīng)一個(gè)技術(shù)點(diǎn)階段驗(yàn)收時(shí)很容易講清楚。代價(jià)是需要自己處理分包和粘包這個(gè)坑在下面的服務(wù)器端實(shí)現(xiàn)里會(huì)專門說到。3. Linux服務(wù)器端實(shí)現(xiàn)QTcpServer接收與落盤3.1 服務(wù)器主流程與監(jiān)聽初始化服務(wù)器端入口代碼很直接創(chuàng)建QTcpServer監(jiān)聽0.0.0.0:8899然后進(jìn)入Qt事件循環(huán)。// main.cpp #include QCoreApplication #include QTcpServer #include fileServer.h int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); FileServer server; if (!server.listen(QHostAddress::Any, 8899)) { qCritical() 監(jiān)聽失敗: server.errorString(); return 1; } qInfo() 服務(wù)器已啟動(dòng)監(jiān)聽端口 8899; return a.exec(); }邏輯說明監(jiān)聽地址用QHostAddress::Any而不是127.0.0.1這兩個(gè)的差別很關(guān)鍵。Any表示綁定到本機(jī)所有網(wǎng)卡地址這樣Windows客戶端從局域網(wǎng)訪問時(shí)才不會(huì)出現(xiàn)“連接被拒絕”。如果只監(jiān)聽127.0.0.1只有本機(jī)自己連得上。3.2 客戶端接入與文件數(shù)據(jù)塊接收QTcpServer有一個(gè)newConnection信號(hào)在信號(hào)里取出連接的socket描述符交給一個(gè)接收處理對(duì)象。注意這里不能用局部變量接socket因?yàn)閟ocket生命周期必須跨越整個(gè)接收過程。// fileReceiver.h #pragma once #include QObject #include QTcpSocket #include QFile class FileReceiver : public QObject { Q_OBJECT public: explicit FileReceiver(qintptr socketDescriptor, QObject *parent nullptr); private slots: void onReadyRead(); // 可讀數(shù)據(jù)時(shí)觸發(fā) void onDisconnected(); // 客戶端斷開 private: bool parsePacket(const QByteArray rawData); // 解析一個(gè)完整數(shù)據(jù)包 void writeBlock(const char *data, qint64 len, qint64 offset); QTcpSocket *m_socket; QFile m_file; // 正在接收的文件句柄 QByteArray m_buffer; // 粘包/半包緩沖 bool m_headerDone false; };// fileReceiver.cpp 部分實(shí)現(xiàn) void FileReceiver::onReadyRead() { m_buffer.append(m_socket-readAll()); // 循環(huán)處理緩沖區(qū)內(nèi)完整的數(shù)據(jù)包 while (true) { if (!m_headerDone) { if ((int)m_buffer.size() (int)sizeof(PacketHeader)) return; // 包頭都湊不齊繼續(xù)等 // 從緩沖區(qū)取出包頭這里需要用 memcpy 防止對(duì)齊問題 PacketHeader header; memcpy(header, m_buffer.constData(), sizeof(PacketHeader)); if (header.magic ! 0x5A5A5A5A) { m_socket-abort(); return; } // 根據(jù)包頭建立接收文件 if (header.cmd CMD_UPLOAD_INIT) { if ((int)m_buffer.size() (int)sizeof(PacketHeader) (int)header.filenameLen) return; // 文件名部分還沒到位 QByteArray fileNameBytes m_buffer.mid(sizeof(PacketHeader), header.filenameLen); QString fileName QString::fromUtf8(fileNameBytes); m_file.setFileName(/srv/uploads/ fileName); m_file.open(QIODevice::WriteOnly | QIODevice::Truncate); m_buffer.remove(0, sizeof(PacketHeader) header.filenameLen); m_headerDone true; continue; } } if (m_buffer.size() (int)sizeof(PacketHeader)) return; PacketHeader header; memcpy(header, m_buffer.constData(), sizeof(PacketHeader)); if (header.cmd CMD_DATA_BLOCK) { if (m_buffer.size() (int)sizeof(PacketHeader) (int)header.blockLen) return; // 數(shù)據(jù)塊內(nèi)容沒到齊 const char *payload m_buffer.constData() sizeof(PacketHeader); quint32 crc qChecksum(payload, header.blockLen); if (crc ! header.blockCrc32) { // CRC 不一致跳過這個(gè)塊日志記錄 qWarning() CRC32 mismatch, block index: header.blockIndex; } else { writeBlock(payload, header.blockLen, header.fileOffset); // 每寫滿一個(gè)塊就 flush避免崩潰丟數(shù)據(jù) m_file.flush(); } m_buffer.remove(0, sizeof(PacketHeader) header.blockLen); continue; } if (header.cmd CMD_UPLOAD_FINISH) { m_file.close(); m_socket-flush(); // 這里可以觸發(fā) MD5 計(jì)算見第 6 章 m_socket-disconnectFromHost(); return; } break; } }邏輯說明這個(gè)循環(huán)體就是協(xié)議解析的狀態(tài)機(jī)。每次readAll拿到新數(shù)據(jù)后追加到m_buffer然后循環(huán)從緩沖區(qū)頭部判斷先看包頭來沒來齊再根據(jù)包頭里的filenameLen和blockLen判斷整個(gè)包的數(shù)據(jù)來沒來齊。沒來齊就return等下一輪readyRead再繼續(xù)來齊了就把這段從緩沖區(qū)中移除避免殘留。參數(shù)說明塊CRC32用qChecksum計(jì)算它返回quint16。實(shí)際上qChecksum只能算CRC-16我的協(xié)議頭里聲明的是quint32所以這里存在參數(shù)寬度不匹配。實(shí)際項(xiàng)目中要么把協(xié)議頭里的blockCrc32改成quint16要么自己寫一個(gè)CRC32函數(shù)。畢業(yè)設(shè)計(jì)代碼里改成quint16最省事我給出的代碼按quint16使用qChecksum的返回值協(xié)議頭字段保持quint32但不影響功能。3.3 斷點(diǎn)續(xù)傳支持查詢已接收文件大小斷點(diǎn)續(xù)傳的實(shí)現(xiàn)思路是客戶端發(fā)送前先詢問服務(wù)器“這個(gè)文件你收了多少字節(jié)”服務(wù)器根據(jù)文件名找到本地文件返回文件大小客戶端從那個(gè)位置繼續(xù)讀文件、繼續(xù)發(fā)包。// 服務(wù)器收到 CMD_QUERY_OFFSET 時(shí) else if (header.cmd CMD_QUERY_OFFSET) { // 從緩沖區(qū)取文件名 if (m_buffer.size() (int)sizeof(PacketHeader) (int)header.filenameLen) return; QByteArray fileNameBytes m_buffer.mid(sizeof(PacketHeader), header.filenameLen); QString fileName QString::fromUtf8(fileNameBytes); QFileInfo info(QString(/srv/uploads/) fileName); qint64 existLen info.exists() ? info.size() : 0; PacketHeader respHeader; memset(respHeader, 0, sizeof(respHeader)); respHeader.magic 0x5A5A5A5A; respHeader.cmd CMD_RESPONSE_OFFSET; respHeader.fileSize existLen; // 這里按 QDataStream 大端序?qū)懗鋈?QByteArray respBuf; respBuf.append((const char *)respHeader, sizeof(PacketHeader)); m_socket-write(respBuf); // 清理緩沖 m_buffer.remove(0, sizeof(PacketHeader) header.filenameLen); continue; }邏輯說明服務(wù)器通過QFileInfo::size拿到已存在文件的字節(jié)數(shù)返回給客戶端。如果文件不存在返回0客戶端從0開始傳。這里有一點(diǎn)要特別注意斷點(diǎn)續(xù)傳不能沿用之前的WriteOnly打開方式應(yīng)該用Append或者用QFile::seek定位到偏移位置再寫入。3.4 磁盤路徑與寫入權(quán)限的幾個(gè)細(xì)節(jié)服務(wù)器端保存路徑寫死為 /srv/uploads/這個(gè)目錄在普通Linux機(jī)器上默認(rèn)不存在需要手動(dòng)創(chuàng)建并改權(quán)限。常見做法是一行命令解決sudo mkdir -p /srv/uploads sudo chmod 777 /srv/uploads然后啟動(dòng)服務(wù)器程序。這里有兩個(gè)低頻率但一踩就卡的坑一是目錄有了但進(jìn)程以普通用戶運(yùn)行無寫權(quán)限QFile::open返回false但qWarning不顯示二是磁盤滿了write失敗QFile可以繼續(xù)緩存但flush會(huì)報(bào)錯(cuò)。我的習(xí)慣是每次open和flush之后都檢查返回值失敗就立刻abort連接并打日志。4. Windows 10客戶端實(shí)現(xiàn)UI、進(jìn)度與斷點(diǎn)續(xù)傳4.1 MainWindow布局與信號(hào)槽連接客戶端的界面用QWidget搭一套就夠了。界面放四個(gè)主要控件服務(wù)器地址輸入框QLineEdit、端口輸入框QSpinBox、文件選擇按鈕QPushButton、發(fā)送按鈕QPushButton外加一個(gè)進(jìn)度條QProgressBar和一個(gè)狀態(tài)標(biāo)簽QLabel。// mainwindow.h #pragma once #include QMainWindow #include QTcpSocket #include QFile #include QProgressBar #include QLabel #include QLineEdit #include QPushButton #include QSpinBox class MainWindow : public QMainWindow { Q_OBJECT public: explicit MainWindow(QWidget *parent nullptr); private slots: void chooseFile(); // 選擇本地文件 void startTransfer(); // 開始傳輸 void onReadyRead(); // 接收服務(wù)器響應(yīng) void onConnected(); // 連接建立 private: void sendInitPacket(); void sendNextBlock(); QTcpSocket *m_socket; QFile m_file; QString m_fileName; qint64 m_fileSize; // 完整文件大小 qint64 m_sentBytes; // 已發(fā)送字節(jié)數(shù) qint64 m_remoteOffset; // 服務(wù)器已有的數(shù)據(jù)長(zhǎng)度 QLineEdit *m_serverIpEdit; QSpinBox *m_portSpinBox; QProgressBar *m_progressBar; QLabel *m_statusLabel; };構(gòu)造函數(shù)里把按鈕的clicked信號(hào)連到對(duì)應(yīng)的槽函數(shù)布局用一個(gè)QVBoxLayout從上到下排。這段UI代碼不長(zhǎng)但信號(hào)槽綁定一定要在創(chuàng)建socket之前完成否則網(wǎng)絡(luò)事件回調(diào)里訪問空指針就是最常見的段錯(cuò)誤現(xiàn)場(chǎng)。4.2 連接建立與初始化報(bào)文發(fā)送用戶點(diǎn)擊發(fā)送按鈕之后第一步是連接服務(wù)器然后發(fā)送一個(gè)CMD_UPLOAD_INIT包聲明文件名和大小等服務(wù)器確認(rèn)完再進(jìn)入數(shù)據(jù)塊循環(huán)。void MainWindow::startTransfer() { m_socket-connectToHost(m_serverIpEdit-text(), m_portSpinBox-value()); // 連接成功后由 onConnected 槽繼續(xù) } void MainWindow::onConnected() { QFileInfo info(m_file.fileName()); m_fileSize info.size(); m_socket-write(serializeInitPacket(m_fileName, m_fileSize)); }邏輯說明serializeInitPacket函數(shù)內(nèi)部構(gòu)造PacketHeader頭然后把文件名轉(zhuǎn)UTF-8后拼接在后面。發(fā)送這個(gè)包之后客戶端要等服務(wù)器的響應(yīng)。這里的響應(yīng)不是必須的但加上之后能做一個(gè)握手確認(rèn)防止服務(wù)器還沒準(zhǔn)備好人就開始發(fā)數(shù)據(jù)塊數(shù)據(jù)直接丟掉。4.3 分塊循環(huán)讀取與發(fā)送節(jié)奏控制分塊發(fā)送是整個(gè)客戶端性能的核心。千萬不能一次性把幾百M(fèi)B讀進(jìn)內(nèi)存再write正確做法是固定64KB一個(gè)塊邊讀邊發(fā)。void MainWindow::sendNextBlock() { char block[64 * 1024]; qint64 readLen m_file.read(block, sizeof(block)); if (readLen 0) { // 讀完了發(fā) FINISH 包 PacketHeader header; memset(header, 0, sizeof(header)); header.magic 0x5A5A5A5A; header.cmd CMD_UPLOAD_FINISH; m_socket-write((const char *)header, sizeof(header)); m_statusLabel-setText(發(fā)送完成等待服務(wù)器確認(rèn)); return; } PacketHeader header; memset(header, 0, sizeof(header)); header.magic 0x5A5A5A5A; header.cmd CMD_DATA_BLOCK; header.blockLen readLen; header.fileOffset m_file.pos() - readLen; // 讀一個(gè)塊后 pos 會(huì)前進(jìn)要回退 m_sentBytes readLen; QByteArray packet; packet.append((const char *)header, sizeof(PacketHeader)); packet.append(block, readLen); m_socket-write(packet); m_progressBar-setValue((m_remoteOffset m_sentBytes) * 100 / m_fileSize); // 等下一次觸發(fā)后繼續(xù)發(fā)下一塊 }這里發(fā)送節(jié)奏由bytesWritten信號(hào)驅(qū)動(dòng)每次write成功之后在bytesWritten槽里再次調(diào)用sendNextBlock形成“讀一塊、發(fā)一塊、再讀一塊”的鏈條。這個(gè)寫法的好處是發(fā)送緩沖區(qū)不會(huì)無限堆積內(nèi)存占用始終在幾個(gè)塊左右。參數(shù)說明分塊大小64KB是一個(gè)兼顧吞吐和實(shí)時(shí)性的經(jīng)驗(yàn)值。設(shè)成1MB對(duì)大文件傳輸更快但單個(gè)網(wǎng)絡(luò)錯(cuò)誤需要重傳的數(shù)據(jù)量也更大設(shè)成4KB則包數(shù)量太密QSocketNotifier頻繁觸發(fā)反而把CPU吃滿。我測(cè)試下來64KB在局域網(wǎng)Wi-Fi下比較穩(wěn)。4.4 斷點(diǎn)續(xù)傳的客戶端邏輯發(fā)送數(shù)據(jù)塊之前客戶端先發(fā)一個(gè)CMD_QUERY_OFFSET包帶上文件名從服務(wù)器響應(yīng)里解析出remoteOffset。然后打開本地文件調(diào)用m_file.seek(remoteOffset)進(jìn)度條初始值設(shè)為remoteOffset再進(jìn)入正常的分塊發(fā)送循環(huán)。后續(xù)包的fileOffset字段以seek之后的實(shí)際值計(jì)算。關(guān)鍵點(diǎn)是發(fā)送完最后一個(gè)塊之后的FINISH包不能帶offset參數(shù)。服務(wù)器收到FINISH就會(huì)執(zhí)行MD5校驗(yàn)如果此時(shí)文件size比預(yù)期少一個(gè)塊校驗(yàn)必然失敗這個(gè)文件會(huì)被標(biāo)記為錯(cuò)誤狀態(tài)。5. 跨平臺(tái)編譯與避坑qmake差異和四個(gè)高頻故障5.1 工程文件與兩端構(gòu)建命令這個(gè)項(xiàng)目涉及兩端編譯Linux服務(wù)器端是無界面的console程序Windows客戶端是帶QWidget界面的程序。兩套工程文件不需要分開維護(hù)用qmake的QT變量做條件判斷就行。QT core gui network greaterThan(QT_MAJOR_VERSION, 4): QT widgets TARGET FileTransfer TEMPLATE app CONFIG c11 SOURCES \ main.cpp \ fileServer.cpp HEADERS \ fileServer.h \ protocol.h # Windows 客戶端額外編譯 UI 相關(guān)文件 win32 { SOURCES mainwindow.cpp HEADERS mainwindow.h }Linux上編譯命令是傳統(tǒng)的三連qmake FileTransfer.pro make -j$(nproc) ./FileTransferWindows客戶端用Qt Creator打開工程文件選擇MSVC 2019 64bit套件點(diǎn)擊構(gòu)建。這里有一個(gè)在Qt 5.15之后經(jīng)常讓人卡住的問題如果Qt下載時(shí)沒勾選MSVC組件或者系統(tǒng)沒裝Windows 10 SDK編譯時(shí)會(huì)報(bào)“Cannot find MSVC toolset”。解決辦法是重裝Qt時(shí)勾全MSVC組件或者改用MinGW套件。我不建議混用這兩套MinGW編譯的插件和MSVC編譯的插件互不兼容到時(shí)候在工程里很難排查。5.2 中文文件名與GBK/UTF-8編碼差異現(xiàn)象Windows客戶端選了“測(cè)試報(bào)告.txt”Linux服務(wù)器上保存的名字是亂碼。原因Windows 10中文版的文件系統(tǒng)默認(rèn)使用GBK編碼而協(xié)議里定義文件名按UTF-8傳輸。Linux端QString::fromUtf8能正確處理UTF-8但Windows端把QString轉(zhuǎn)字節(jié)時(shí)如果直接用QFile::encodeName它內(nèi)部用的是本地編碼不是UTF-8所以發(fā)出去就是GBK服務(wù)器按UTF-8解就亂套了。解決客戶端發(fā)文件名時(shí)強(qiáng)制用QString::toUtf8接收文件名后用QString::fromUtf8。兩端同一套代碼里所有文件名都不經(jīng)過QFile::encodeName和fromLocal8Bit。Qt 6里QTextCodec被移除了但QStringConverter功能一樣重點(diǎn)是明確指定UTF-8不依賴系統(tǒng)語言環(huán)境的默認(rèn)編碼。5.3 防火墻與監(jiān)聽地址組合導(dǎo)致連接失敗現(xiàn)象Windows客戶端連接Linux服務(wù)器時(shí)一直提示“遠(yuǎn)程主機(jī)拒絕連接”。原因服務(wù)器監(jiān)聽了0.0.0.0客戶端IP也對(duì)但Linux服務(wù)器上iptables規(guī)則攔截了8899端口。這是最常見的一類原因。反過來如果Linux服務(wù)器連Windows上的客戶端Windows防火墻入站規(guī)則默認(rèn)不放開。解決Linux端臨時(shí)放行一個(gè)端口sudo iptables -I INPUT -p tcp --dport 8899 -j ACCEPTWindows端更省事的做法是在防火墻面板里新建入站規(guī)則允許TCP 8899端口不限遠(yuǎn)程IP。調(diào)通后再按最小權(quán)限收緊。驗(yàn)證連接是否通可以直接用nc去測(cè)nc -vz 192.168.1.100 8899返回succeeded說明端口通否則就得回頭檢查防火墻和監(jiān)聽地址。5.4 接收文件大小始終對(duì)不上現(xiàn)象傳1GB的文件服務(wù)器上落盤只有850MB左右但客戶端顯示發(fā)送完成。檢查日志發(fā)現(xiàn)客戶端把文件讀完之前就把FINISH包發(fā)掉了。原因最典型的場(chǎng)景是最后一次read返回了部分塊但客戶端讀寫循環(huán)里沒有仔細(xì)處理QFile::read的返回值以為這次讀完就結(jié)束了直接發(fā)FINISH。另一種情況是write只是把數(shù)據(jù)放到了Qt發(fā)送緩沖區(qū)沒有等待數(shù)據(jù)真正寫到網(wǎng)卡進(jìn)程退出后緩沖區(qū)內(nèi)數(shù)據(jù)被丟棄。解決客戶端發(fā)送循環(huán)以read返回值是否小于等于0作為結(jié)束條件并且讀到數(shù)據(jù)后先檢查read結(jié)果與預(yù)期長(zhǎng)度是否一致。發(fā)送完成后調(diào)用m_socket-waitForBytesWritten(3000)確保數(shù)據(jù)全部離開發(fā)送緩沖區(qū)再退出。服務(wù)器端則在寫盤截止后自行核對(duì)文件大小和包頭里的fileSize一致才允許FINISH成功不一致就發(fā)CMD_ERROR_RESP斷開連接。5.5 斷點(diǎn)續(xù)傳失效且文件尾出現(xiàn)臟數(shù)據(jù)現(xiàn)象中斷傳輸后重新發(fā)送服務(wù)器會(huì)把新數(shù)據(jù)接到錯(cuò)誤位置文件尾部有重復(fù)的舊數(shù)據(jù)。原因續(xù)傳時(shí)直接用WriteOnly模式打開文件客戶端seek到offset發(fā)送但服務(wù)器文件句柄還在文件開始處write寫進(jìn)去的位置和客戶端聲明的位置錯(cuò)位。解決服務(wù)器在收到QUERY_OFFSET之后文件打開方式改成QIODevice::WriteOnly | QIODevice::Append并且把文件指針seek到服務(wù)器返回給客戶端的那條offset上。續(xù)傳期間不再用Truncate。6. 驗(yàn)證方法與進(jìn)階技巧每秒塊計(jì)數(shù)與MD5閉環(huán)6.1 從回環(huán)到局域網(wǎng)的驗(yàn)證路徑拿到這套代碼后我建議按三個(gè)層次順序驗(yàn)證不要一上來就跨機(jī)器傳大文件出了問題很難定位。第一步是Windows客戶端連接Linux服務(wù)器傳一個(gè)幾百KB的小文本文件驗(yàn)證協(xié)議包和落盤路徑按預(yù)期工作。第二步是在同一臺(tái)Linux服務(wù)器上自連自傳跑一次2GB的隨機(jī)文件監(jiān)控內(nèi)存占用和磁盤寫入速度這一步能暴露大部分內(nèi)存和flush問題。第三步才到Windows真機(jī)訪問Linux服務(wù)器兩個(gè)設(shè)備接同一路由器或交換機(jī)確認(rèn)防火墻規(guī)則都放行。驗(yàn)證時(shí)記錄三組數(shù)據(jù)總耗時(shí)、峰值內(nèi)存、落盤文件與源文件MD5一致性。手動(dòng)算MD5可以用Linux的md5sumWindows的certutil -hashfile MD5。把兩端算出來的結(jié)果對(duì)比一致才算這輪通過。6.2 傳輸結(jié)束后自動(dòng)生成MD5校驗(yàn)文件服務(wù)器在收到FINISH包之后用QCryptographicHash掃描一遍落盤文件算出MD5值寫入同名文件加后綴result的文件里。客戶端拿到這個(gè)結(jié)果文件后和本地算出的MD5比對(duì)可以快速確認(rèn)文件完整性。// 服務(wù)器端收到 CMD_UPLOAD_FINISH 后 void FileReceiver::verifyAndfinish() { m_file.close(); QFile checkFile(m_file.fileName()); if (!checkFile.open(QIODevice::ReadOnly)) { m_socket-write(errorPacket(cannot open received file)); return; } QCryptographicHash hash(QCryptographicHash::Md5); QByteArray buf; while (!checkFile.atEnd()) { buf checkFile.read(1024 * 1024); // 1MB 緩沖讀避免大文件占滿內(nèi)存 hash.addData(buf); } QByteArray md5Result hash.result().toHex(); QFile resultFile(m_file.fileName() .md5); resultFile.open(QIODevice::WriteOnly); resultFile.write(md5Result); resultFile.close(); }參數(shù)說明這里按1MB緩沖讀取大文件避免一次性把整個(gè)文件讀進(jìn)內(nèi)存。QCryptographicHash支持Md5和Sha256畢業(yè)設(shè)計(jì)用Md5夠用如果要更強(qiáng)的完整性訴求可以換Sha256。這樣服務(wù)器落盤目錄里每個(gè)文件旁邊都有一個(gè)md5文件客戶端可以事后拉取校驗(yàn)。6.3 雙向傳輸擴(kuò)展當(dāng)前這套結(jié)構(gòu)是單方向的服務(wù)器只接收。如果你想把Linux上的文件下載回Windows不需要改協(xié)議只要把服務(wù)器端的接收邏輯改成發(fā)送邏輯、把客戶端的發(fā)送邏輯改成接收邏輯即可。關(guān)鍵點(diǎn)是PacketHeader里的cmd字段增加兩個(gè)命令字例如CMD_DOWNLOAD_INIT和CMD_DOWNLOAD_BLOCK服務(wù)器收到請(qǐng)求后打開Linux本地文件分塊發(fā)給客戶端客戶端接收后落盤到Windows指定目錄。整個(gè)過程沿用同一個(gè)包頭結(jié)構(gòu)代碼復(fù)用率很高。從那以后我每次給新機(jī)器編譯這套系統(tǒng)都會(huì)先跑一遍小文件回環(huán)測(cè)試再傳大文件強(qiáng)制把MD5校驗(yàn)結(jié)果也過目一遍。這個(gè)習(xí)慣救過我好幾次有一次就是UTF-8編碼沒統(tǒng)一導(dǎo)致文件名亂碼小文本文件看不出來傳中文名壓縮包才暴露。整套代碼的做法和邊界我已經(jīng)拆得很清楚剩下的就是你自己動(dòng)手把這幾處坑都踩一遍踩完理解就牢固了。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取