簡(jiǎn)介Indy 10.6.3.3 是面向 Delphi 與 CBuilder 開(kāi)發(fā)者的跨平臺(tái)網(wǎng)絡(luò)組件庫(kù)源碼包適合需要快速實(shí)現(xiàn) TCP/IP、HTTP、FTP 等通信功能的中高級(jí)開(kāi)發(fā)者。它把多種互聯(lián)網(wǎng)協(xié)議封裝成可直接拖放的組件包含連接管理與網(wǎng)頁(yè)請(qǐng)求等常用部件并支持異步執(zhí)行和事件回調(diào)可用于郵件客戶(hù)端、Web 服務(wù)、文件傳輸與聊天程序等場(chǎng)景。壓縮包共 2000 個(gè)文件約 9.67MB以 pas 源碼、dpk 包文件、dproj 工程、bmp 與 ico 資源以及 txt、rc、res 等說(shuō)明和構(gòu)建文件為主目錄兼顧編譯安裝、示例參考與資源生成。包內(nèi)保留核心協(xié)議單元、設(shè)計(jì)期包與多版本工程文件便于在 RAD Studio 中按需編譯和二次開(kāi)發(fā)完整源碼也方便按項(xiàng)目需求裁剪、修改和擴(kuò)展協(xié)議實(shí)現(xiàn)并對(duì)照組件結(jié)構(gòu)排查連接、收發(fā)與超時(shí)等問(wèn)題。已有 362 人學(xué)習(xí)適合作為 Delphi 網(wǎng)絡(luò)應(yīng)用開(kāi)發(fā)的基礎(chǔ)組件資料對(duì)理解組件化網(wǎng)絡(luò)編程與協(xié)議封裝亦有參考價(jià)值。1. 解壓先別急著點(diǎn) InstallIndy 10.6.3.3 換掉的是 Delphi 12 的整套網(wǎng)絡(luò)底座Delphi 控件里最容易被低估的一類(lèi)是那種平時(shí)看不見(jiàn)、一旦出問(wèn)題就全盤(pán)停擺的底層庫(kù)Indy 就是典型。IndyInternet Direct本來(lái)是 Delphi 12 安裝包里自帶的網(wǎng)絡(luò)組件集TIdHTTP、TIdFTP、TIdSMTP、TIdTCPClient、TIdTCPServer 這一批控件全出自它而隨 IDE 預(yù)裝的那份版本往往偏舊碰上 TLS 1.3、新版 SSL 運(yùn)行庫(kù)或者某些服務(wù)端不常見(jiàn)的握手方式就容易出問(wèn)題。這份 Indy-10.6.3.3 給的是完整源碼加設(shè)計(jì)期包覆蓋上去等于給整個(gè)網(wǎng)絡(luò)層換發(fā)動(dòng)機(jī)——協(xié)議實(shí)現(xiàn)和 SSL 后端都更新了代價(jià)是 IDE 本身也依賴(lài)這套包裝錯(cuò)順序連 Delphi 都打不開(kāi)。它適合手里有存量 Delphi 項(xiàng)目、被 HTTPS 或長(zhǎng)連接折騰過(guò)、又不想引入第三方網(wǎng)絡(luò)框架的人。2. 編譯與安裝六個(gè)包的設(shè)計(jì)期與運(yùn)行期順序不能亂Indy 不是一個(gè) dpk 包打包全部而是按「基礎(chǔ) → 核心 → 協(xié)議」切成三層每層再分運(yùn)行期包和設(shè)計(jì)期包。很多人解壓后直接在 IDE 里雙擊 dclIndyProtocols.dpk 點(diǎn) Install然后報(bào)一堆「Cannot load package」原因幾乎都是跳過(guò)了下層的運(yùn)行期包。這一章先把包組結(jié)構(gòu)拆清楚再給一套可以照著敲的命令行編譯流程最后才是 IDE 里掛包和清 DCU。2.1 包組結(jié)構(gòu)與依賴(lài)方向先把解開(kāi)后的目錄看一眼Core、System、Protocols 三個(gè)源碼目錄配上根目錄下若干 dpk/dproj。它們的依賴(lài)是單向的編譯順序不能反。包文件類(lèi)型依賴(lài)主要內(nèi)容IndySystem.dpk運(yùn)行期無(wú)IdGlobal、IdException、IdStack、IdResourceStrings 等基礎(chǔ)單元IndyCore.dpk運(yùn)行期IndySystemIdTCPClient、IdTCPServer、IdIOHandler、IdContext、IdThreadIndyProtocols.dpk運(yùn)行期IndyCoreIdHTTP、IdFTP、IdSMTP、IdPOP3、IdSSLOpenSSL 等協(xié)議單元dclIndySystem.dpk設(shè)計(jì)期IndySystem.bpl注冊(cè)基礎(chǔ)控件到工具面板dclIndyCore.dpk設(shè)計(jì)期IndyCore.bpl注冊(cè) TIdTCPClient、TIdTCPServer 等dclIndyProtocols.dpk設(shè)計(jì)期IndyProtocols.bpl注冊(cè) TIdHTTP、TIdFTP、TIdSSLIOHandlerSocketOpenSSL 等三條判斷依據(jù)值得記住。第一運(yùn)行期包產(chǎn)出的是 .bpl程序運(yùn)行時(shí)要么靜態(tài)鏈接要么帶著這些 bpl 走所以它必須先于設(shè)計(jì)期包編譯出來(lái)。第二設(shè)計(jì)期包只負(fù)責(zé)把組件注冊(cè)進(jìn) IDE它自己不包含實(shí)現(xiàn)代碼只是引用運(yùn)行期包所以 IDE 位數(shù)決定設(shè)計(jì)期包只能編 Win32。第三Indy 的單元之間存在大量隱式引用比如 IdHTTP 引用了 IdIOHandler、IdSSLOpenSSL 又引用 IdSSLOpenSSLHeaders如果只編了 IndyProtocols 而 IndyCore 的 DCU 是舊版鏈接階段就會(huì)報(bào)「Unit IdIOHandler was compiled with a different version of IdGlobal」。2.2 用命令行把三個(gè)運(yùn)行期包先編出來(lái)比在 IDE 里點(diǎn) Build 更可控的做法是走 msbuild尤其當(dāng)你需要同時(shí)出 Win32 和 Win64、或者要寫(xiě)自動(dòng)化腳本的時(shí)候。Delphi 安裝時(shí)會(huì)往系統(tǒng)環(huán)境里寫(xiě)一個(gè) BDS 變量指向 Studio 的安裝根目錄rsvars.bat 就在它的 bin 下作用是初始化編譯所需的環(huán)境變量。:: 1) 初始化編譯環(huán)境BDS 由安裝程序?qū)懭霙](méi)寫(xiě)就手動(dòng) set 一下 call %BDS%\bin\rsvars.bat :: 2) 嚴(yán)格按依賴(lài)順序編譯路徑切到解壓后的 Indy 根目錄 cd /d D:\src\Indy-10.6.3.3 :: 3) 先基礎(chǔ)層再核心層最后協(xié)議層 msbuild IndySystem.dproj /t:Build /p:ConfigRelease /p:PlatformWin32 msbuild IndyCore.dproj /t:Build /p:ConfigRelease /p:PlatformWin32 msbuild IndyProtocols.dproj /t:Build /p:ConfigRelease /p:PlatformWin32這三條命令的邏輯是串行的IndyCore 編譯時(shí)需要讀 IndySystem 產(chǎn)出的 .dcu 和 .bpl所以上一條不成功就不要往下走。參數(shù)上ConfigRelease是為了讓設(shè)計(jì)期掛進(jìn) IDE 的那份包體積小、斷言少調(diào)試信息留給項(xiàng)目自己的 Debug 配置PlatformWin32是因?yàn)?Delphi 12 的 IDE 進(jìn)程本身是 32 位設(shè)計(jì)期包必須是 Win32運(yùn)行期包才可以按目標(biāo)平臺(tái)再編一遍 Win64。如果你只關(guān)心 64 位程序也要先把 Win32 的三個(gè)運(yùn)行期包和設(shè)計(jì)期包編出來(lái)否則 IDE 里根本拖不出 TIdHTTP。編譯完檢查輸出目錄應(yīng)該能看到 IndySystem.bpl、IndyCore.bpl、IndyProtocols.bpl 以及對(duì)應(yīng)的 .dcp。少了任何一個(gè)下一步掛設(shè)計(jì)期包一定失敗。2.3 在 IDE 里掛設(shè)計(jì)期包并清掉舊 DCU命令行編完只是有了文件IDE 還不知道。掛載這一步有幾個(gè)順序上的講究第一步關(guān)掉所有打開(kāi)的項(xiàng)目先備份%BDS%\bin目錄下所有 Indy 開(kāi)頭的 bpl。Delphi 12 的 IDE 自身就鏈接了 Indy替換失敗會(huì)導(dǎo)致 IDE 啟動(dòng)報(bào)錯(cuò)有備份才不至于重裝。第二步Component → Install Packages在列表里把已有的 Indy 相關(guān)設(shè)計(jì)期包逐個(gè) Remove。這一步不做新包和舊包會(huì)同時(shí)注冊(cè)同名組件工具面板上出現(xiàn)兩個(gè) TIdHTTP編譯時(shí)報(bào)「Duplicate identifier」。第三步Add依次選 dclIndySystem.bpl、dclIndyCore.bpl、dclIndyProtocols.bpl。順序不能反因?yàn)?dclIndyProtocols 加載時(shí)會(huì)去解析對(duì) IndyProtocols.bpl 的引用而 IndyProtocols.bpl 又依賴(lài) IndyCore.bpl。第四步Tools → Options → Language → Delphi → Library把 System、Core、Protocols 三個(gè)源碼目錄加到 Library path 的最前面。放在最前面是關(guān)鍵否則編譯器會(huì)優(yōu)先命中 IDE 自帶路徑下的舊 DCU編譯通過(guò)但行為還是舊版。第五步清 DCU。搜一遍項(xiàng)目目錄和公共 DCU 輸出目錄把 Id 開(kāi)頭的 .dcu 全刪掉。Indy 的單元名很集中Id*.dcu通配基本不會(huì)誤傷。清完重新 Build All再拖一個(gè) TIdHTTP 到空窗體上能編譯、能出現(xiàn)屬性編輯器安裝就算過(guò)了。3. TIdTCPClient 與 TIdTCPServer一條能收發(fā)的閉環(huán)怎么搭I(lǐng)ndy 里最容易被新手跳過(guò)的其實(shí)是 TCP 這一層大家都直奔 TIdHTTP因?yàn)?HTTP 簡(jiǎn)單。但只要涉及長(zhǎng)連接、私有協(xié)議、需要服務(wù)端主動(dòng)推送最后還是要回到 TIdTCPClient/TIdTCPServer。這兩個(gè)組件看似只有幾個(gè)屬性真正會(huì)出問(wèn)題的地方集中在三處超時(shí)、報(bào)文邊界、以及 OnExecute 到底跑在哪個(gè)線程里。3.1 長(zhǎng)連接場(chǎng)景為什么優(yōu)先選 TCP 組件而不是 HTTP選型上有個(gè)樸素判斷如果你的交互是「客戶(hù)端發(fā)一次、服務(wù)端答一次然后結(jié)束」用 TIdHTTP 最省事它幫你處理了連接復(fù)用、重定向、分塊傳輸。但如果服務(wù)端需要在沒(méi)有請(qǐng)求的時(shí)候主動(dòng)下發(fā)消息或者一次交互里有多輪往返鑒權(quán)、訂閱、心跳HTTP 就要靠輪詢(xún)或長(zhǎng)輪詢(xún)?nèi)ツM成本和不確定性都上去了。TIdTCPClient 給的是裸的字節(jié)流好處是完全可控什么時(shí)候連、連多久、發(fā)什么、等多久、斷了怎么重連全在你手里。代價(jià)是報(bào)文邊界要自己定。TCP 本身是字節(jié)流沒(méi)有消息的概念一次 WriteLn 發(fā)出去的內(nèi)容對(duì)端可能分兩次收到也可能和下一次的內(nèi)容粘在一起。這就是為什么 Indy 提供了 ReadLn 這種帶終止符的讀法——它在幫你把字節(jié)流切回消息。還有個(gè)實(shí)際因素TIdTCPServer 自帶連接上下文管理、最大連接數(shù)限制、線程池調(diào)度這些在 TIdHTTP 里是隱藏的。你需要看「當(dāng)前有多少個(gè)客戶(hù)端連著」的時(shí)候IdTCPServer1.Contexts.LockList一句就能拿到比在 HTTP 層自己數(shù)會(huì)話簡(jiǎn)單得多。3.2 客戶(hù)端超時(shí)、編碼與連接生命周期客戶(hù)端的坑幾乎全在超時(shí)上。TIdTCPClient 有兩個(gè)獨(dú)立超時(shí)ConnectTimeout 管建連ReadTimeout 管讀阻塞。默認(rèn)值給得比較寬松在弱網(wǎng)或者對(duì)端假死的時(shí)候一個(gè) Read 能掛很久。uses IdTCPClient, IdGlobal, IdException; function TcpPing(const AHost: string; APort: Integer): string; var Client: TIdTCPClient; begin Client : TIdTCPClient.Create(nil); try Client.Host : AHost; Client.Port : APort; Client.ConnectTimeout : 3000; // 建連上限含 DNS 解析時(shí)間 Client.ReadTimeout : 5000; // 單次 Read 阻塞上限超時(shí)拋 EIdReadTimeout try Client.Connect; try // 顯式指定 UTF-8避免中文在兩端編碼不一致時(shí)變成亂碼 Client.IOHandler.WriteLn(PING, IndyTextEncoding_UTF8); Result : Client.IOHandler.ReadLn(LF, Client.ReadTimeout, 4096, IndyTextEncoding_UTF8); finally Client.Disconnect; end; except on E: EIdConnectTimeout do Result : CONNECT_TIMEOUT on E: EIdReadTimeout do Result : READ_TIMEOUT on E: EIdSocketError do Result : SOCKET_ERROR: IntToStr(E.LastError); end; finally Client.Free; end; end;這段代碼有幾個(gè)點(diǎn)值得說(shuō)明。ConnectTimeout單位是毫秒它覆蓋的不只是三次握手DNS 解析也在這個(gè)預(yù)算里所以填 3000 意味著解析慢的域名會(huì)直接判超時(shí)。ReadLn的四個(gè)參數(shù)依次是終止符、超時(shí)、單行最大字節(jié)數(shù)、文本編碼把AMaxLineLength填成 4096 是一種防御防止對(duì)端發(fā)來(lái)一條幾十兆、沒(méi)有換行的「臟數(shù)據(jù)」把內(nèi)存打滿(mǎn)。異常類(lèi)型上連接超時(shí)拋 EIdConnectTimeout讀超時(shí)拋 EIdReadTimeout兩者都繼承自 EIdException但分開(kāi)捕獲能讓你在日志里一眼看出是網(wǎng)絡(luò)沒(méi)通還是對(duì)端不回。連接生命周期上Connect和Disconnect要成對(duì)出現(xiàn)而且 Disconnect 放在內(nèi)層 finallyFree 放在外層 finally。原因是 Connect 拋異常時(shí)連接根本沒(méi)建立此時(shí)調(diào) Disconnect 雖然無(wú)害但沒(méi)意義而一旦連上無(wú)論讀寫(xiě)是否異常都必須斷開(kāi)否則套接字句柄會(huì)泄漏。3.3 服務(wù)端OnExecute 在哪個(gè)線程里跑這是 Indy 新手翻車(chē)率最高的一點(diǎn)。TIdTCPServer 的 OnExecute 不是主線程回調(diào)而是在每條連接自己的上下文線程里執(zhí)行。也就是說(shuō)你在這個(gè)事件里碰任何 VCL 控件改 Label.Caption、往 Memo 里追加日志、彈 MessageBox輕則界面卡住重則訪問(wèn)違例或者隨機(jī)崩潰——因?yàn)?VCL 的窗口句柄有線程親和性。uses IdContext, IdTCPConnection, IdGlobal, IdException; procedure TForm1.FormCreate(Sender: TObject); begin IdTCPServer1.Bindings.Clear; with IdTCPServer1.Bindings.Add do begin IP : 0.0.0.0; // 監(jiān)聽(tīng)所有網(wǎng)卡只給本機(jī)用就填 127.0.0.1 Port : 9000; end; IdTCPServer1.MaxConnections : 200; // 超過(guò)直接拒絕防止連接打滿(mǎn) IdTCPServer1.ListenQueue : 50; // 已完成握手但未被取走的隊(duì)列長(zhǎng)度 IdTCPServer1.TerminateWaitTime : 5000; // 停服時(shí)等各線程收尾的上限 IdTCPServer1.Active : True; end; procedure TForm1.IdTCPServer1Execute(AContext: TIdContext); var Req: string; begin try // 讀一行5 秒沒(méi)等到換行就按超時(shí)處理單行上限 4KB Req : AContext.Connection.IOHandler.ReadLn(LF, 5000, 4096, IndyTextEncoding_UTF8); except on E: EIdReadTimeout do Exit; // 客戶(hù)端連上不發(fā)數(shù)據(jù)直接放棄這條連接 end; if SameText(Trim(Req), PING) then AContext.Connection.IOHandler.WriteLn(PONG, IndyTextEncoding_UTF8) else AContext.Connection.IOHandler.WriteLn(ERR UNKNOWN, IndyTextEncoding_UTF8); // 需要更新界面時(shí)必須切回主線程不能直接寫(xiě)控件屬性 TThread.Queue(nil, procedure begin Memo1.Lines.Add(recv: Req); end); end;邏輯上有幾處需要展開(kāi)。Bindings是監(jiān)聽(tīng)地址列表默認(rèn)可能綁在 127.0.0.1 上做成服務(wù)端給別的機(jī)器連就會(huì)發(fā)現(xiàn)連不通所以先 Clear 再顯式 Add 是穩(wěn)妥寫(xiě)法。MaxConnections是硬上限超過(guò)之后新連接會(huì)被直接關(guān)掉不給 OnConnect 機(jī)會(huì)這在被掃描或者被壓測(cè)的時(shí)候很有用。ListenQueue對(duì)應(yīng)底層 listen 的 backlog短連接高并發(fā)場(chǎng)景下如果偏小會(huì)出現(xiàn)客戶(hù)端已經(jīng)握手成功但服務(wù)端遲遲不取的情況。異常處理那一層是必須的。OnExecute 里拋出的異常如果不捕獲Indy 會(huì)把它吞掉并斷開(kāi)連接表面看是「客戶(hù)端莫名其妙掉了」日志里什么都沒(méi)有。顯式捕獲 EIdReadTimeout 并 Exit至少能讓「對(duì)端連上不發(fā)數(shù)據(jù)」這種情況可控。TThread.Queue 那一段是線程安全的寫(xiě)法Queue 是異步投遞不阻塞工作線程對(duì)應(yīng)的 TThread.Synchronize 是同步等待在主線程忙的時(shí)候會(huì)把工作線程一起拖住連接數(shù)一多就雪崩。所以除了極小規(guī)模的工具都建議用 Queue。3.4 報(bào)文邊界ReadLn 的終止符與最大長(zhǎng)度ReadLn 的兩個(gè)參數(shù)——終止符和最大長(zhǎng)度——決定了你的協(xié)議能不能穩(wěn)定工作。終止符默認(rèn)是 LF#10但很多設(shè)備端發(fā)的是 CRLF#13#10。這時(shí)候如果兩邊不約定清楚服務(wù)端會(huì)讀到「PING」后面跟一個(gè) #13Trim之后才能比對(duì)上一旦業(yè)務(wù)數(shù)據(jù)里本身包含 #13切分就亂了。常見(jiàn)做法是協(xié)議頭里帶長(zhǎng)度字段或者用定長(zhǎng)頭 變長(zhǎng)體。如果堅(jiān)持用行協(xié)議務(wù)必在兩邊統(tǒng)一成 LF服務(wù)端讀到的內(nèi)容末尾不要做隱式 Trim 之外的任何處理。最大長(zhǎng)度一定要設(shè)置Indy 允許傳 -1 表示不限這在實(shí)際部署里等于給了一個(gè)內(nèi)存炸彈——對(duì)端只要持續(xù)發(fā)不含終止符的字節(jié)緩沖區(qū)就一直漲。大包場(chǎng)景不適合 ReadLn。行讀取是逐字節(jié)掃描找終止符幾 MB 的報(bào)文用它會(huì)明顯變慢正確做法是用ReadBytes或者ReadStream先讀 4 字節(jié)長(zhǎng)度頭再按長(zhǎng)度讀體。4. TIdHTTP 與 SSL把 HTTPS 請(qǐng)求真正跑通的參數(shù)清單TIdHTTP 是 Indy 里使用頻率最高的組件也是「看起來(lái)一行就能跑、實(shí)際各種報(bào)錯(cuò)」的典型。它本身的封裝很薄幾乎所有行為都由 IOHandler 和 Request 上的屬性決定。這一章按「歸屬權(quán) → 參數(shù) → 落地代碼 → SSL 運(yùn)行庫(kù)」的順序走前三步?jīng)Q定你的代碼會(huì)不會(huì)崩第四步?jīng)Q定 HTTPS 能不能通。4.1 IOHandler 的歸屬權(quán)一個(gè) double free 的經(jīng)典現(xiàn)場(chǎng)TIdHTTP 自己會(huì)創(chuàng)建一個(gè)默認(rèn)的 IOHandler純 socket不帶 SSL。當(dāng)你要訪問(wèn) HTTPS就必須手動(dòng)掛一個(gè) TIdSSLIOHandlerSocketOpenSSL 上去。問(wèn)題出在釋放上TIdHTTP 的析構(gòu)函數(shù)里會(huì) Free 掉當(dāng)前的 IOHandler所以如果你在 finally 里既Http.Free又SSL.Free第二次釋放就是訪問(wèn)違例而且崩的位置往往在程序退出時(shí)堆棧看著跟 HTTP 毫無(wú)關(guān)系。正確做法是要么把 SSL 的 Owner 設(shè)成 HttpTIdSSLIOHandlerSocketOpenSSL.Create(Http)要么創(chuàng)建時(shí) Owner 給 nil、但只 Free Http。兩種都行核心原則是同一個(gè)對(duì)象只能有一個(gè)釋放者。我一般用前者因?yàn)閷?duì)象樹(shù)清晰出問(wèn)題看 Owner 就知道誰(shuí)管誰(shuí)。順帶一提給Http.IOHandler賦值時(shí)Indy 內(nèi)部會(huì)把舊的默認(rèn) handler 釋放掉所以你不需要也不應(yīng)該自己去釋放它。4.2 關(guān)鍵參數(shù)表下面這張表是我在幾個(gè)項(xiàng)目里反復(fù)調(diào)出來(lái)的常用值具體數(shù)字按你的服務(wù)端 SLA 調(diào)整但項(xiàng)目別留空。參數(shù)常用取值說(shuō)明ConnectTimeout3000 ~ 5000建連階段上限含 DNS單位毫秒ReadTimeout15000 ~ 30000單次讀阻塞上限超時(shí)拋 EIdReadTimeoutHandleRedirectsTrue自動(dòng)跟隨 301/302注意 POST 被重定向后可能退化成 GETRedirectMaximum5重定向次數(shù)上限防止循環(huán)跳轉(zhuǎn)Request.ContentTypeapplication/json; charsetutf-8POST 時(shí)必須顯式設(shè)置否則服務(wù)端可能按表單解析Request.Acceptapplication/json影響服務(wù)端的內(nèi)容協(xié)商Request.UserAgent自定義字符串留空會(huì)被部分網(wǎng)關(guān)直接拒絕SSLOptions.SSLVersions[sslvTLSv1_2, sslvTLSv1_3]不要留空留空走庫(kù)默認(rèn)值可能協(xié)商到不再被接受的舊協(xié)議SSLOptions.ModesslmClient客戶(hù)端固定這個(gè)值SSLOptions.VerifyMode[sslvrfPeer]空集合等于不校驗(yàn)服務(wù)端證書(shū)生產(chǎn)環(huán)境不要這么干SSLOptions.VerifyDepth3證書(shū)鏈校驗(yàn)深度SSLOptions.RootCertFileCA 證書(shū)路徑留空則用系統(tǒng)證書(shū)存儲(chǔ)IOHandler.Deflate.CompressionLevel0 或 6開(kāi)啟 gzip 壓縮服務(wù)端支持時(shí)能顯著減小正文SSLVersions這一項(xiàng)值得單獨(dú)說(shuō)。很多人為了「兼容性」把 SSLv3、TLSv1.0 全塞進(jìn)去結(jié)果服務(wù)端反而拒絕握手因?yàn)楝F(xiàn)代網(wǎng)關(guān)會(huì)直接拒掉低版本協(xié)議。反過(guò)來(lái)只寫(xiě) sslvTLSv1_3 也不行一些內(nèi)網(wǎng)服務(wù)還停留在 1.2。給 [sslvTLSv1_2, sslvTLSv1_3] 是最穩(wěn)的起點(diǎn)。4.3 GET 與 POST 的落地寫(xiě)法先看一個(gè)帶 JSON 體的 POST涵蓋超時(shí)、頭部、編碼三件事。uses IdHTTP, IdSSLOpenSSL, IdSSL, IdGlobal, SysUtils, Classes; function HttpPostJson(const AUrl, AJson: string; out AStatus: Integer): string; var Http: TIdHTTP; SSL: TIdSSLIOHandlerSocketOpenSSL; Src: TStringStream; begin Http : TIdHTTP.Create(nil); try // Owner 交給 Http由 TIdHTTP 在析構(gòu)時(shí)統(tǒng)一釋放避免 double free SSL : TIdSSLIOHandlerSocketOpenSSL.Create(Http); SSL.SSLOptions.Mode : sslmClient; SSL.SSLOptions.SSLVersions : [sslvTLSv1_2, sslvTLSv1_3]; SSL.SSLOptions.VerifyMode : [sslvrfPeer]; Http.IOHandler : SSL; Http.ConnectTimeout : 5000; Http.ReadTimeout : 20000; Http.HandleRedirects : True; Http.RedirectMaximum : 5; Http.Request.ContentType : application/json; charsetutf-8; Http.Request.Accept : application/json; Http.Request.UserAgent : DelphiClient/1.0; Http.Request.CustomHeaders.Values[X-Trace-Id] : demo-0001; // TStringStream 顯式指定 UTF-8中文才不會(huì)按 ANSI 發(fā)出去 Src : TStringStream.Create(AJson, TEncoding.UTF8); try Result : Http.Post(AUrl, Src); AStatus : Http.ResponseCode; finally Src.Free; end; finally Http.Free; // IOHandler 隨 Http 一起釋放不要再 Free SSL end; end;幾個(gè)參數(shù)的作用ReadTimeout設(shè) 20 秒是因?yàn)椴簧俳涌谠诶鋯?dòng)時(shí)首字節(jié)要等十幾秒設(shè)太短會(huì)頻繁誤判超時(shí)CustomHeaders用來(lái)塞鏈路追蹤 ID排查跨服務(wù)問(wèn)題時(shí)能對(duì)上日志TStringStream的編碼參數(shù)不能省默認(rèn)會(huì)用系統(tǒng) ANSI 頁(yè)JSON 里只要有中文服務(wù)端收到的就是一堆問(wèn)號(hào)。GET 加查詢(xún)參數(shù)時(shí)不要手動(dòng)拼字符串用TIdURI.ParamsEncode做轉(zhuǎn)義否則參數(shù)里帶、、中文就會(huì)把請(qǐng)求拆壞。下載文件用Http.Get(AUrl, AFileStream)的重載配合OnWork事件可以拿到進(jìn)度在OnWork里判斷超時(shí)或者用戶(hù)取消拋一個(gè)自定義異常就能中斷傳輸這是 Indy 提供的少數(shù)幾個(gè)中斷點(diǎn)之一。4.4 SSL 運(yùn)行庫(kù)放哪、怎么確認(rèn)加載成功HTTPS 報(bào)「Could not load SSL library」幾乎是必踩的一關(guān)。原因通常只有三種位數(shù)不對(duì)、文件名不對(duì)、搜索路徑不對(duì)。位數(shù)上32 位程序必須配 32 位運(yùn)行庫(kù)64 位配 64 位。文件名上Indy 會(huì)按一串候選名去試3.x 系列是 libssl-3.dll / libcrypto-3.dll64 位版本帶 -x64 后綴1.1 系列是 libssl-1_1.dll 這一類(lèi)。搜索路徑上最省事的做法是把兩個(gè) DLL 放到 exe 同目錄這樣不依賴(lài)系統(tǒng)目錄部署也好打包。確認(rèn)是否加載成功別靠猜uses IdSSLOpenSSLHeaders; procedure TForm1.CheckSSL; begin if not LoadOpenSSLLibrary then raise Exception.Create(SSL 運(yùn)行庫(kù)加載失敗: WhichFailedToLoad); Memo1.Lines.Add(SSL 版本: OpenSSLVersion); end;WhichFailedToLoad會(huì)直接告訴你它試過(guò)的候選名里哪些失敗了對(duì)著這個(gè)名字去補(bǔ) DLL 就行比反復(fù)重啟程序快得多。另外還有一個(gè)容易忽略的點(diǎn)如果程序目錄里同時(shí)存在 1.1 和 3.x 兩套 DLLIndy 會(huì)按內(nèi)部順序挑一個(gè)可能出現(xiàn)「本機(jī)好好的、客戶(hù)機(jī)器上握手失敗」統(tǒng)一成一套、刪掉多余的能省掉很多玄學(xué)問(wèn)題。5. 避坑與排查五個(gè)讓我返工的現(xiàn)場(chǎng)前面幾章講的是「怎么裝、怎么寫(xiě)」這一章講「為什么照寫(xiě)了還是不對(duì)」。下面五條都是我在實(shí)際項(xiàng)目里返工過(guò)的按「現(xiàn)象 → 原因 → 解決」寫(xiě)遇到癥狀對(duì)得上的可以直接跳。5.1 編譯報(bào)「compiled with a different version of IdGlobal」現(xiàn)象新裝的包新建空項(xiàng)目拖一個(gè) TIdHTTP編譯立刻報(bào)單元版本不一致提示的卻是 IdGlobal 這種基礎(chǔ)單元。原因舊 DCU 殘留。Delphi 的編譯緩存是按單元名找的項(xiàng)目搜索路徑、公共 DCU 輸出目錄、IDE 自帶路徑里任意一處有舊版 IdGlobal.dcu編譯器就可能先命中它然后和新建的 IndyCore.dcp 對(duì)不上。解決先把 Library path 里 Indy 的三個(gè)源碼目錄頂?shù)阶钋懊嬖偃P(pán)搜Id*.dcu刪掉最后 Project → Build All不是 CompileCompile 不會(huì)重新鏈接。如果還不行檢查是不是同時(shí)裝了 32 位和 64 位包而當(dāng)前編譯目標(biāo)選錯(cuò)了平臺(tái)。5.2 裝完設(shè)計(jì)期包IDE 啟動(dòng)報(bào)「Cannot load package dclIndyCore」現(xiàn)象包在 IDE 里點(diǎn) Install 成功了關(guān)掉重開(kāi) Delphi彈窗說(shuō)某個(gè) Indy 包加載失敗工具面板上組件全沒(méi)了。原因設(shè)計(jì)期包的加載順序或者依賴(lài)沒(méi)滿(mǎn)足。Indy 的設(shè)計(jì)期包依賴(lài)對(duì)應(yīng)的運(yùn)行期 bpl如果運(yùn)行期 bpl 沒(méi)在系統(tǒng)能找到的路徑里通常是 IDE 的 bin 目錄加載時(shí)解析不到依賴(lài)就失敗。另一種情況是 32 位和 64 位混裝把 Win64 的 bpl 塞進(jìn)了 32 位 IDE。解決先備份%BDS%\bin下所有 Indy 開(kāi)頭的 bpl再把編譯出來(lái)的三個(gè)運(yùn)行期 bpl 復(fù)制進(jìn)去設(shè)計(jì)期包只放 Win32 版本。然后用%BDS%\bin\bds.exe -rXXX起一個(gè)干凈注冊(cè)表配置驗(yàn)證確認(rèn)是包的問(wèn)題還是注冊(cè)表殘留。這一步別嫌麻煩直接在主配置上反復(fù)試很容易把 IDE 搞到起不來(lái)。5.3 服務(wù)端 OnExecute 里更新界面跑一會(huì)兒就崩現(xiàn)象單客戶(hù)端測(cè)試完全正常壓到幾十個(gè)連接后隨機(jī)訪問(wèn)違例崩的位置在 VCL 內(nèi)部堆?？床怀龊途W(wǎng)絡(luò)有關(guān)。原因OnExecute 在連接上下文線程里執(zhí)行直接寫(xiě) Label.Caption 或者 Memo.Lines 屬于跨線程操作 VCL。單連接時(shí)主線程恰好空閑看起來(lái)沒(méi)事并發(fā)一上來(lái)就撞車(chē)。解決所有界面更新走 TThread.Queue參數(shù)在進(jìn)入 Queue 之前拷貝好閉包里捕獲的是變量引用循環(huán)里尤其容易出錯(cuò)。如果只是記日志干脆別碰界面寫(xiě)到一個(gè)線程安全的隊(duì)列里主線程用 Timer 批量刷。5.4 ReadLn 一直阻塞到超時(shí)對(duì)端明明發(fā)了數(shù)據(jù)現(xiàn)象服務(wù)端 ReadLn 每次都在 5 秒后拋 EIdReadTimeout抓包看數(shù)據(jù)確實(shí)到了。原因終止符不匹配。對(duì)端發(fā)的是 CRLF你按 LF 讀讀到的內(nèi)容里帶著 #13長(zhǎng)度也偏一位或者對(duì)端壓根沒(méi)發(fā)換行只是發(fā)了一段定長(zhǎng)報(bào)文。解決先抓一次原始字節(jié)確認(rèn)結(jié)束符再?zèng)Q定用 ReadLn(LF) 還是 ReadLn(#13#10)。定長(zhǎng)報(bào)文改用ReadBytes(N)。還有一種隱蔽情況是緩沖區(qū)里殘留了上一次的數(shù)據(jù)導(dǎo)致下一次讀到的「第一行」其實(shí)是上次的尾巴這種要在協(xié)議層加序號(hào)或者長(zhǎng)度頭來(lái)兜底。5.5 HTTPS 在本機(jī)能跑到客戶(hù)機(jī)器上報(bào) SSL 加載失敗現(xiàn)象開(kāi)發(fā)機(jī)一切正常部署到現(xiàn)場(chǎng)機(jī)器上所有 HTTPS 請(qǐng)求全部失敗錯(cuò)誤是 Could not load SSL library。原因DLL 沒(méi)跟著發(fā)布或者發(fā)布的是位數(shù)不對(duì)的版本。開(kāi)發(fā)機(jī)上系統(tǒng)目錄里恰好有運(yùn)行庫(kù)所以「看起來(lái)能跑」。解決把兩個(gè) DLL 和 exe 放同一目錄一起打包用WhichFailedToLoad打印實(shí)際嘗試的文件名做交叉驗(yàn)證。部署腳本里加一條校驗(yàn)文件缺失就直接在啟動(dòng)時(shí)報(bào)錯(cuò)別等到第一次發(fā)請(qǐng)求才暴露。6. 進(jìn)階心跳、重連與線程池把 Indy 用成能上線的樣子裝好、跑通只是及格線。真正上線要解決的是「斷了怎么辦」和「連太多怎么辦」。我的習(xí)慣是把 TCP 客戶(hù)端封在一個(gè)常駐線程里用短超時(shí)做心跳探測(cè)斷線走指數(shù)退避重連而不是在按鈕點(diǎn)擊里裸調(diào) Connect。type TTcpWorker class(TThread) private FHost: string; FPort: Integer; protected procedure Execute; override; public constructor Create(const AHost: string; APort: Integer); end; procedure TTcpWorker.Execute; var Client: TIdTCPClient; Backoff: Integer; begin Backoff : 1000; // 首次重連間隔 1 秒 while not Terminated do begin Client : TIdTCPClient.Create(nil); try Client.Host : FHost; Client.Port : FPort; Client.ConnectTimeout : 3000; Client.ReadTimeout : 8000; try Client.Connect; Backoff : 1000; // 連上就重置退避 while (not Terminated) and Client.Connected do begin Client.IOHandler.WriteLn(PING, IndyTextEncoding_UTF8); if Client.IOHandler.ReadLn(LF, 8000, 256, IndyTextEncoding_UTF8) PONG then Break; // 應(yīng)答不對(duì)主動(dòng)斷開(kāi)重連 Sleep(15000); // 心跳間隔 end; except on E: EIdException do ; // 斷線統(tǒng)一落到重連邏輯 end; finally Client.Free; end; if Terminated then Break; Sleep(Backoff); Backoff : Min(Backoff * 2, 30000); // 指數(shù)退避封頂 30 秒 end; end;這段骨架的關(guān)鍵在三個(gè)數(shù)字心跳間隔 15 秒、讀超時(shí) 8 秒、退避封頂 30 秒。讀超時(shí)要小于心跳間隔否則上一次讀還沒(méi)返回下一次寫(xiě)就排隊(duì)了退避要封頂不然服務(wù)端故障恢復(fù)之后客戶(hù)端還在一分鐘一次的節(jié)奏上慢慢爬。Terminated在每個(gè)可能長(zhǎng)阻塞的位置都檢查一次是因?yàn)?Sleep 和 ReadLn 都不會(huì)響應(yīng)線程終止信號(hào)不加檢查就會(huì)出現(xiàn)「關(guān)了程序進(jìn)程還在」的情況。服務(wù)端側(cè)如果連接數(shù)上到幾百默認(rèn)的「一連接一線程」會(huì)開(kāi)始吃?xún)?nèi)存這時(shí)候換 TIdSchedulerOfThreadPool把IdTCPServer1.Scheduler指向一個(gè)線程池實(shí)例配好MaxThreads和MinThreads空閑線程會(huì)被復(fù)用上下文切換成本明顯下降。配置項(xiàng)單機(jī)工具建議值對(duì)外服務(wù)建議值MaxConnections50500 ~ 2000ListenQueue20100TerminateWaitTime300010000Scheduler默認(rèn)每連接一線程TIdSchedulerOfThreadPoolMaxThreads不適用CPU 核數(shù) × 4有一件事我一直保持任何走 Indy 的對(duì)外接口上線前必須做一次「拔網(wǎng)線」測(cè)試——物理斷網(wǎng)、服務(wù)端假死、DNS 解析失敗三種場(chǎng)景各跑一遍看客戶(hù)端會(huì)不會(huì)卡死、會(huì)不會(huì)無(wú)限重連打滿(mǎn) CPU、日志里能不能看出是哪一層超時(shí)。這套檢查我吃過(guò)虧早期一個(gè)版本只測(cè)了正常路徑現(xiàn)場(chǎng)網(wǎng)絡(luò)抖動(dòng)時(shí)客戶(hù)端卡在 ReadLn 里整整一個(gè)下午界面完全無(wú)響應(yīng)。從那以后我每次封網(wǎng)絡(luò)組件都強(qiáng)制走一遍斷網(wǎng)、假死、拒絕連接三連測(cè)才算完。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取