简介IndyInternet Direct10.6.3.3 版本的完整源码与组件包面向使用 Delphi 12 或 CBuilder 开发网络程序的开发者可解决 TCP/IP、UDP、HTTP、SMTP、POP3、FTP 等协议组件的获取与集成问题适合需要自行编译或改造控件库的中级读者。压缩包约 2000 个文件、9.67MB以 pas 源码单元、dpk 与 dproj 安装工程文件、res 与 dcr 资源、bmp 图标素材、txt 说明和 inc 头文件为主另含 bat 编译脚本与多版本 bdsproj 工程便于按 Delphi 版本分别构建。已有 362 人学习。包内保留 IdBaseComponent、IdTCPConnection 等核心单元与 TIdTCPClient、TIdHTTP 组件的实现可据此配置服务器地址与端口实现 OnExecute 异步收发、进度显示与错误处理也可直接修改源码扩展协议目录中的批量编译脚本与 IndyProtocols、IndyCore 工程文件便于复现官方编译流程并核对组件安装结果。1. Indy 10.6.3.3 装进 Delphi 12老项目升级卡住的那一步前段时间又碰到一个典型的升级场景一个跑了七八年的 Delphi 客户端要迁到 Delphi 12 编译业务代码基本没动唯独网络层一片报错——Indy 9 时代的TIdTCPConnection写法在 Indy 10 里全变了签名。这类存量项目里Indy 几乎是绕不开的 Delphi 控件TCP、HTTP、FTP、SMTP 一套全给你不用买商业库也不用自己封 WinSock。Indy-10.6.3.3 这个包就是它的完整源码加安装工程带 Delphi 12 的 290 系包文件。它解决的不是「能不能联网」而是联网这件事能不能在 IDE 里拖控件配属性、能不能在老代码上平滑换代。适合三类人维护存量 Delphi 项目的、给工控上位机加通信模块的、以及不想引一堆外部依赖的独立开发者。2. 装包与工程接线从编译 dpk 到库路径的四道关卡拿到压缩包先别急着双击安装。Indy 的包结构是分层的编错顺序会得到一堆「Unit was compiled with a different version」的链接错误而这类报错信息几乎不告诉你真正的原因。下面按我实际装一遍的顺序走。2.1 解压后先看清目录源码、预编译 DCU、包工程三者的关系解压出来大致是这么个结构不同小版本可能略有出入但骨架一致Indy-10.6.3.3/ ├── Lib/ # 预编译 DCU 与 .inc 配置文件 │ ├── System/ # 基础单元IdGlobal、IdStack 等 │ ├── Core/ # 核心通信TIdTCPClient、TIdTCPServer │ ├── Protocols/ # 协议层HTTP、SMTP、FTP、POP3 │ └── Security/ # OpenSSL 头文件与 SSL IOHandler ├── Source/ # 对应的 .pas 源码 │ ├── System/ │ ├── Core/ │ ├── Protocols/ │ └── Security/ └── Packages/ # 各 IDE 版本的 .dpk 设计期/运行期包三块内容的分工要理清楚。Source是真源码排错时要能翻进去看Lib是预编译产物加编译开关Packages里的.dpk才是往 IDE 里装的东西。关键判断在于Lib下的 DCU 是不是你这版编译器的产物。Delphi 的 DCU 和编译器版本强绑定Delphi 12 的编译器版本是 36包后缀 29011 是 28010.4 是 270对着自己手上的版本改数字。如果包里带的 DCU 是更早的编译器编的链接阶段就会炸。稳妥做法是忽略预编译 DCU全部用源码重编一遍——多花五分钟省掉半天排查。提示解压路径别带中文和空格。Indy 的包工程里有相对路径引用路径里有空格时某些版本的 msbuild 会把参数切断报出来的错跟路径毫无关系。2.2 编包顺序System → Core → Protocols一步都不能跳Indy 拆成六个包运行期三个、设计期三个依赖是单向的包名Delphi 12类型依赖内容indySystem290运行期无基础单元、平台抽象indyCore290运行期indySystem290Socket 核心、IOHandlerindyProtocols290运行期indyCore290HTTP/SMTP/FTP 等协议dclIndySystem290设计期indySystem290组件注册dclIndyCore290设计期indyCore290组件注册dclIndyProtocols290设计期indyProtocols290组件注册IDE 里操作就是依次打开、右键 Build、再右键 Install。但更省事的是命令行批处理尤其是要给多台机器装同一套环境时# 先让 RAD Studio 的环境变量生效路径按自己的安装位置改 call RADStudio\bin\rsvars.bat # 按依赖顺序编Config 用 Release 减少调试信息体积 msbuild indySystem290.dpk /t:Build /p:ConfigRelease /p:PlatformWin32 msbuild indyCore290.dpk /t:Build /p:ConfigRelease /p:PlatformWin32 msbuild indyProtocols290.dpk /t:Build /p:ConfigRelease /p:PlatformWin32 # 设计期包编完会自动往 IDE 注册装完重启 IDE 才能在面板看到 msbuild dclIndyCore290.dpk /t:Build /p:ConfigRelease /p:PlatformWin32 msbuild dclIndyProtocols290.dpk /t:Build /p:ConfigRelease /p:PlatformWin32/p:PlatformWin32这行别漏。默认可能编成 Win64结果 32 位工程引用时找不到 DCU报「找不到单元」但又不说找的是哪个平台。64 位工程要单独再编一遍 Win64 的三个运行期包设计期包只需要一份。编的过程中如果提示缺IdCompilerDefines.inc基本可以确定是Lib\System没进搜索路径或者这个 inc 被解压工具改了大小写。Windows 上不区分但 Indy 的部分{$I}引用写的是大小写敏感的路径跨平台同步过的包偶尔会踩到。2.3 库路径与「两套 Indy」冲突最隐蔽的一道坎Delphi 12 自带一份 Indy版本号通常比 10.6.3.3 略旧或略有差异。你编完自己的包、装上设计期包之后IDE 里可能出现两个 Indy 页签或者拖出来的控件行为对不上预期——这就是两套共存了。处理分两步。第一步把搜索路径顶到最前Tools → Options → Language → Delphi → Library → Library path 把 Indy\Lib\Win32\Release 放到列表最上方路径顺序决定编译器先命中哪份 DCU。放最后面等于没放因为自带的路径在前面同名单元永远先被找到。第二步禁用自带的包。Component → Install Packages里把 Embarcadero 自带的那几个 Indy 设计期包取消勾选只留自己编的。这一步不做组件面板上的控件仍然指向旧 BPL运行时加载的却是新 DLL出现「属性设了不生效」这种问题。注意改完路径一定要关掉 IDE 重开。库路径是启动时读进内存的改完不重启编译行为还是旧的很容易误判成「改了没用」。2.4 最小验证五分钟确认这套东西真的能用装完先别急着上业务代码。新建一个空 VCL 工程拖一个TIdTCPClient和一个TIdHTTP到窗体上只做一件事——确认组件面板上的控件能被创建、能访问属性。procedure TForm1.FormCreate(Sender: TObject); var C: TIdTCPClient; begin C : TIdTCPClient.Create(nil); try // 能读到属性就说明单元链接成功不用真连 C.ConnectTimeout : 3000; C.ReadTimeout : 8000; Caption : Indy OK, port IntToStr(C.Port); finally C.Free; end; end;这段代码没有任何网络行为纯粹验证IdTCPClient单元能不能被正确链接和实例化。如果这里就报「找不到单元」或者运行时报抽象错误说明包装错或者路径没生效后面写再多业务代码也是白搭。这一步我每次装新环境都会跑只花一分钟但能挡掉后面八成环境问题。3. 阻塞式 Socket 的真相TIdTCPClient 与 TIdTCPServer 的最小骨架Indy 的全套组件都是阻塞式 IO这个设计取向决定了你写出来的代码长什么样也决定了它会以什么方式坑你。很多人第一次用 Indy 觉得「怎么一读就卡死」本质是没接受这个前提。3.1 阻塞模型不是缺陷是设计取向TIdTCPClient.Connect会一直等到握手完成或者超时IOHandler.ReadLn会一直等到读到一行或者超时TIdHTTP.Get会一直等到响应体收完。这期间调用线程是挂起的不处理任何消息。这套模型的好处是代码线性、逻辑清晰不用回调也不用状态机读一行写一行跟操作文件差不多。代价是任何阻塞调用都不能放在主线程里。TIdTCPServer的处理方式是把每个连接丢进独立线程OnExecute事件就在那个线程里反复触发。所以服务端代码天然是并发的你不写线程也得面对线程问题。客户端相反TIdTCPClient本身不创建线程谁调谁阻塞。至于TIdAntiFreeze它的作用是在阻塞调用期间插入Application.ProcessMessages让界面看起来不卡。这个组件能救急但代价很大消息重入会让用户在阻塞期间再次点按钮触发第二次阻塞调用然后就是经典的「窗口白屏 栈溢出」。我一般的做法是客户端所有网络操作放独立线程结果用TThread.Queue回主线程更新界面TIdAntiFreeze只在维护老代码时留着。3.2 客户端连接、超时、心跳、自动重连超时参数是这套东西里最容易被忽略、又最容易出事的地方。两个值必须显式设type TNetClient class private FClient: TIdTCPClient; public constructor Create; function Connect: Boolean; procedure Send(const S: string); procedure Disconnect; end; constructor TNetClient.Create; begin FClient : TIdTCPClient.Create(nil); FClient.Host : 127.0.0.1; FClient.Port : 9000; end; function TNetClient.Connect: Boolean; begin Result : False; if FClient.Connected then Exit(True); try FClient.ConnectTimeout : 3000; // 握手最长等 3 秒 FClient.ReadTimeout : 8000; // 单次读最长等 8 秒0 无限等 FClient.Connect; Result : True; except on E: Exception do // 异常信息一定要落日志别只吞掉 WriteLog(Format(connect fail: %s / %s, [E.ClassName, E.Message])); end; end; procedure TNetClient.Send(const S: string); begin if not FClient.Connected then if not Connect then Exit; try FClient.IOHandler.WriteLn(S); except // 写失败通常意味着连接已断主动断开让下次重连 FClient.Disconnect; end; end;ConnectTimeout默认值是 0 还是某个非零值不同版本不一样别赌显式写。ReadTimeout设 0 意味着「一直等到有数据」在网络抖动或者服务端半开连接的情况下这个线程就永久挂住了而且不报错。我见过最难受的线上问题就是这种连接看着还在心跳也在发就是收不到回包因为读线程早就挂死了。心跳单独说。TCP 本身有 KeepAlive但系统级的 KeepAlive 默认两小时才探测一次业务上根本等不起。常见做法是应用层心跳procedure TNetClient.OnHeartbeat(Sender: TObject); begin if not FClient.Connected then Exit; try FClient.IOHandler.WriteLn(PING); // 注意这里不要直接 ReadLn 等 PONG会阻塞定时器线程 // 回包由独立的接收线程处理收到 PONG 就更新最后活跃时间 FLastActive : Now; except FClient.Disconnect; end; end;心跳发送和回包接收要分开。心跳只管发接收线程读到PONG就刷新FLastActive主循环定期检查Now - FLastActive 阈值就判定断线并触发重连。这个组合比「发完就等回包」稳得多因为等待回包本身就是一次阻塞。3.3 服务端Contexts 的锁、会话挂载与广播TIdTCPServer的Contexts属性是所有活跃连接的列表类型是TListTIdContext。这个列表属于服务端内部读写必须配对加锁否则并发连接一多就会出现访问违例而且是那种偶发的、难复现的。每个连接要挂业务数据用TIdContext.DataTObject类型最直接procedure TForm1.IdTCPServer1Connect(AContext: TIdContext); begin AContext.Data : TSession.Create; // 每个连接一份独立会话 end; procedure TForm1.IdTCPServer1Disconnect(AContext: TIdContext); begin TSession(AContext.Data).Free; AContext.Data : nil; end; procedure TForm1.IdTCPServer1Execute(AContext: TIdContext); var Line: string; begin // 第二个参数是读超时超时会抛异常触发 OnException Line : AContext.Connection.IOHandler.ReadLn(#10, 30000); if Line PING then AContext.Connection.IOHandler.WriteLn(PONG) else HandleBusiness(AContext, Line); end;OnConnect和OnDisconnect成对出现但要注意OnDisconnect不保证一定触发——进程被强杀、网线被拔服务端可能过很久才感知。所以会话对象里最好带一个创建时间定期清理超时的僵尸会话。广播是这样写的procedure TForm1.Broadcast(const S: string); var List: TListTIdContext; Ctx: TIdContext; begin List : IdTCPServer1.Contexts.LockList; // 加锁拿快照 try for Ctx in List do begin try Ctx.Connection.IOHandler.WriteLn(S); except // 单个连接写失败不能影响其他人交给 OnException 处理 end; end; finally IdTCPServer1.Contexts.UnlockList; // 必须配对 end; end;LockList会在整个循环期间持有锁连接数上百时广播会有明显延迟。要优化的话先在锁内把 Context 复制到临时数组解锁后再逐个发。这个改动不大但在几百连接的场景下差别很明显。线程边界这条要反复强调OnExecute跑在工作线程里里面绝对不能直接碰 VCL 控件。更新界面统一走TThread.Queueprocedure TForm1.PostLog(const S: string); begin TThread.Queue(nil, procedure begin Memo1.Lines.Add(S); // 这段在主线程执行 end); end;用Queue不用Synchronize。Synchronize会等待主线程执行完工作线程被挂起高并发时直接拖垮吞吐。Queue是投递完就返回。4. 上层协议组件落地HTTP、SMTP、FTP 的参数怎么设协议层组件把 Socket 的细节包掉了但参数没设对一样出问题。这一章按实际使用频率排HTTP 最多SMTP 次之FTP 最少但坑最集中。4.1 TIdHTTP请求头、重定向、流式下载先说选型。Delphi 自带TNetHTTPClient底层走平台原生实现不用带 OpenSSL DLLTIdHTTP的优势是行为可控、能直接拿到原始响应头、能自定义 IOHandler、能和 Indy 其余组件共用一套连接管理。需要精细控制比如抓取特定响应头、做流式大文件下载、走自定义 SSL 配置时选TIdHTTP。基本用法var HTTP: TIdHTTP; FS: TFileStream; begin HTTP : TIdHTTP.Create(nil); try HTTP.ConnectTimeout : 5000; HTTP.ReadTimeout : 30000; // 大文件下载要放宽 HTTP.HandleRedirects : True; HTTP.MaximumRedirects : 5; // 默认值偏小跳转链路长会提前放弃 HTTP.Request.UserAgent : MyApp/1.0; HTTP.Request.CustomHeaders.Values[X-Auth-Token] : token-value; HTTP.Request.Accept : application/octet-stream; FS : TFileStream.Create(download.bin, fmCreate); try HTTP.Get(https://your-host/api/download, FS); finally FS.Free; end; finally HTTP.Free; end; end;几个点。Get的重载里传TStream那个版本才是流式的传字符串的版本会把整个响应体读进内存几十兆的文件直接吃满。HandleRedirects打开后OnRedirect事件可以用来处理需要携带 Cookie 的跳转但事件里改NewURL时要注意只改一次改多次会被忽略。状态码处理TIdHTTP在 4xx/5xx 时会抛EIdHTTPProtocolException异常对象里有ErrorCode和ErrorMessage响应体在E.Message里。要拿原始响应体捕获这个异常然后读E.Messagetry HTTP.Get(URL, Stream); except on E: EIdHTTPProtocolException do WriteLog(Format(HTTP %d: %s, [E.ErrorCode, E.Message])); on E: EIdConnectTimeout do WriteLog(连接超时检查网络或目标端口); on E: EIdReadTimeout do WriteLog(读超时服务端响应过慢或数据未收完); end;分开捕获EIdConnectTimeout和EIdReadTimeout很值得这两种超时指向完全不同的排查方向混在一起看日志时会绕远路。4.2 TIdSMTP TIdMessage中文编码的三个位置发邮件这套组件本身不难难在中文和编码。三个地方要一起设对缺一个就乱码。var SMTP: TIdSMTP; SSL: TIdSSLIOHandlerSocketOpenSSL; Msg: TIdMessage; begin SMTP : TIdSMTP.Create(nil); SSL : TIdSSLIOHandlerSocketOpenSSL.Create(nil); Msg : TIdMessage.Create(nil); try // 第一处传输层加密587 端口一般是显式 TLS SSL.SSLOptions.SSLVersions : [sslvTLSv1_2]; SMTP.IOHandler : SSL; SMTP.UseTLS : utUseExplicitTLS; SMTP.Host : smtp.your-host.com; SMTP.Port : 587; SMTP.Username : user; SMTP.Password : pass; // 第二处主题和正文的字符集 编码方式 Msg.From.Address : useryour-host.com; Msg.Recipients.EMailAddresses : toyour-host.com; Msg.Subject : 测试邮件; Msg.Body.Text : 这是一封中文正文。; Msg.CharSet : utf-8; Msg.ContentType : text/plain; Msg.ContentTransferEncoding : base64; SMTP.Connect; try SMTP.Authenticate; SMTP.Send(Msg); finally SMTP.Disconnect; end; finally Msg.Free; SSL.Free; SMTP.Free; end; end;第三处也是最容易漏的收件人显示名。Msg.Recipients.EMailAddresses只放地址要带中文显示名得操作TIdEmailAddressItem并且给它单独设Name编码由TIdMessage统一处理。ContentTransferEncoding用base64而不是quoted-printable是因为部分老邮件客户端对 QP 编码的中文处理不一致。代价是体积大三分之一但对内部通知类邮件完全可以接受。UseTLS有三个值utNoTLSSupport、utUseExplicitTLS、utUseImplicitTLS。587 端口配utUseExplicitTLS先明文连接再 STARTTLS465 端口配utUseImplicitTLS连上就是 TLS。配错的表现是连接建立后卡在认证阶段然后超时。4.3 TIdFTP被动模式与传输类型FTP 现在用得少但设备对接、内网文件同步还是常见。两个参数必须改FTP.Host : ftp.your-host.com; FTP.Port : 21; FTP.Passive : True; // 默认值在部分版本是 False内网有 NAT 时必改 FTP.TransferType : ftBinary; // 传压缩包、图片必须是二进制ASCII 模式会改字节 FTP.Username : user; FTP.Password : pass; FTP.Connect; try FTP.Login; FTP.ChangeDir(/upload); FTP.Put(local.zip, remote.zip); finally FTP.Quit; end;Passive设 False 走主动模式服务端要反向连客户端客户端在 NAT 后面基本连不通表现是「登录成功、列目录卡住、然后超时」。这是 FTP 最经典的坑Passive : True一句话解决。TransferType设错的表现更隐蔽传上去的文件大小对得上但打开报损坏。ASCII 模式会把 CRLF 做转换二进制文件一转换就废了。5. 避坑与排查Indy 在 Delphi 12 上最容易翻车的五件事下面五条都是我在实际项目里踩过或帮别人定位过的按「现象 → 原因 → 解决」写。5.1 一调 HTTPS 就报「Could not load SSL library」现象HTTP 请求只要目标地址是 https立刻抛出这个异常换成 http 就正常。原因Indy 自己不实现 TLS靠外挂 OpenSSL 动态库。DLL 缺失、位数不匹配32 位程序配 64 位 DLL、版本对不上都会报这一句。Indy 10.6.x 里对 OpenSSL 1.0.2 和 3.x 的文件名要求不一样1.0.2 是libeay32.dll/ssleay32.dll3.x 是libcrypto-3.dll/libssl-3.dll。解决先调IdSSLOpenSSLHeaders.WhichFailedToLoad拿到具体缺哪个文件别猜。DLL 放在 exe 同目录位数跟进程一致。生产环境我一般把 DLL 一起打进安装包不依赖系统目录里已有的版本因为别的软件装过一份旧版就会互相打架。5.2 点一下按钮界面就白屏几秒现象点了「查询」按钮窗口变白、拖动无响应几秒后数据出来。原因网络调用写在了按钮的OnClick里主线程阻塞消息循环停摆。解决把调用挪进TThread或者TTask结果用TThread.Queue回主线程。临时救急可以拖一个TIdAntiFreeze但要清楚它是靠插入ProcessMessages实现的用户在阻塞期间能再点一次按钮重入的问题迟早会来。5.3 收到的中文全是问号或者方块现象HTTP 响应、Socket 报文、邮件正文总有一处中文不对。原因Indy 的字符串处理链路里字符集声明有三层IOHandler 的DefStringEncoding、协议组件的ContentCharset、以及数据本身的字节编码。任何一层声明和实际字节不一致就会在转换时丢字符。解决先确认服务端返回的Content-Type里带的 charset再决定客户端怎么解。TIdHTTP.Response.ContentType和Response.CharSet都能读到。如果服务端不声明最稳的是按字节流接收然后自己按 UTF-8 解不要让它自动猜。5.4 连接看着还在但消息发出去没反应现象日志里心跳一直在发业务消息也写成功了但服务端就是收不到。重启客户端立刻恢复。原因ReadTimeout设成了 0或者接收线程早就因为异常退出但没人发现。TCP 半开连接对端已经没了本端还没感知在移动网络和长连接场景里非常普遍。解决ReadTimeout永远不要设 0给一个业务能接受的上限接收线程用try..finally包住退出时打日志应用层心跳配合「最后活跃时间」判定超时就主动Disconnect再重连。不要指望系统级 KeepAlive。5.5 服务端跑一段时间就少几个连接没有任何报错现象TIdTCPServer运行几小时后活跃连接数对不上也没有异常日志。原因OnExecute里抛出的异常被 Indy 内部捕获默认走OnException事件如果这个事件没处理异常就被静默吞掉了对应线程跟着结束。解决一定要挂OnException把E.ClassName、E.Message和当前AContext.Binding.PeerIP一起记下来。另外OnExecute内部自己也要try..except业务异常就地处理不要让一条脏数据把整条连接干掉。6. 进阶把 Indy 用到生产环境的三个硬技巧基础跑通之后真正决定这套东西能不能上生产的是连接复用、TLS 配置和验证手段这三件事。先说连接复用。TIdHTTP的实例创建成本不低尤其带 SSL 的时候每次Create都要重新初始化 IOHandler。高频请求场景下我一般做成对象池一个TIdHTTP实例处理完一批请求再释放池大小按并发数配。要注意的是TIdHTTP不是线程安全的一个实例同一时刻只能被一个线程用池里取用必须加锁。再看 TLS 配置。默认配置能连通但不等于安全。生产环境我一般显式限定协议版本同时打开证书校验SSL.SSLOptions.SSLVersions : [sslvTLSv1_2]; SSL.SSLOptions.Mode : sslmClient; // 需要双向认证时挂证书 SSL.SSLOptions.CertFile : client.crt; SSL.SSLOptions.KeyFile : client.key;如果编译器提示sslvTLSv1_3未定义说明这版 Indy 还没暴露 TLS 1.3 常量只保留sslvTLSv1_2就行别硬写。协议版本限得太死会连不上只支持新版本的对端限得太松又可能协商到不安全的套件这个得按对端实际情况调。最后是验证手段。这套东西出问题的时候日志往往不够用得有独立于业务代码的探测方式排查目标手段关注点端口是否可达telnet host port或 PowerShellTest-NetConnection连接建立耗时TLS 是否能握手openssl s_client -connect host:443 -tls1_2证书链、协议版本连接是否泄漏netstat -ano按 PID 过滤TIME_WAIT 数量趋势服务端并发上限自己写个循环建连的小脚本第几个连接开始失败那张表里我最常用的是第三个。长连接项目跑一晚上第二天netstat一看 TIME_WAIT 几千个基本就能确定是客户端没正确Disconnect或者异常路径上漏了finally。从那以后我每次接新的通信模块都强制先把「连接、超时、日志」这三件套抽成一个独立单元用上面的探测手段单独验证一遍再接业务逻辑。这么做的直接原因是早年在客户现场排查一个「偶发断线」业务代码翻了两天最后发现是ReadTimeout没设、接收线程静默退出。希望帮到你。本文还有配套的精品资源点击获取
简介IndyInternet Direct10.6.3.3 版本的完整源码与组件包面向使用 Delphi 12 或 CBuilder 开发网络程序的开发者可解决 TCP/IP、UDP、HTTP、SMTP、POP3、FTP 等协议组件的获取与集成问题适合需要自行编译或改造控件库的中级读者。压缩包约 2000 个文件、9.67MB以 pas 源码单元、dpk 与 dproj 安装工程文件、res 与 dcr 资源、bmp 图标素材、txt 说明和 inc 头文件为主另含 bat 编译脚本与多版本 bdsproj 工程便于按 Delphi 版本分别构建。已有 362 人学习。包内保留 IdBaseComponent、IdTCPConnection 等核心单元与 TIdTCPClient、TIdHTTP 组件的实现可据此配置服务器地址与端口实现 OnExecute 异步收发、进度显示与错误处理也可直接修改源码扩展协议目录中的批量编译脚本与 IndyProtocols、IndyCore 工程文件便于复现官方编译流程并核对组件安装结果。1. Indy 10.6.3.3 装进 Delphi 12老项目升级卡住的那一步前段时间又碰到一个典型的升级场景一个跑了七八年的 Delphi 客户端要迁到 Delphi 12 编译业务代码基本没动唯独网络层一片报错——Indy 9 时代的TIdTCPConnection写法在 Indy 10 里全变了签名。这类存量项目里Indy 几乎是绕不开的 Delphi 控件TCP、HTTP、FTP、SMTP 一套全给你不用买商业库也不用自己封 WinSock。Indy-10.6.3.3 这个包就是它的完整源码加安装工程带 Delphi 12 的 290 系包文件。它解决的不是「能不能联网」而是联网这件事能不能在 IDE 里拖控件配属性、能不能在老代码上平滑换代。适合三类人维护存量 Delphi 项目的、给工控上位机加通信模块的、以及不想引一堆外部依赖的独立开发者。2. 装包与工程接线从编译 dpk 到库路径的四道关卡拿到压缩包先别急着双击安装。Indy 的包结构是分层的编错顺序会得到一堆「Unit was compiled with a different version」的链接错误而这类报错信息几乎不告诉你真正的原因。下面按我实际装一遍的顺序走。2.1 解压后先看清目录源码、预编译 DCU、包工程三者的关系解压出来大致是这么个结构不同小版本可能略有出入但骨架一致Indy-10.6.3.3/ ├── Lib/ # 预编译 DCU 与 .inc 配置文件 │ ├── System/ # 基础单元IdGlobal、IdStack 等 │ ├── Core/ # 核心通信TIdTCPClient、TIdTCPServer │ ├── Protocols/ # 协议层HTTP、SMTP、FTP、POP3 │ └── Security/ # OpenSSL 头文件与 SSL IOHandler ├── Source/ # 对应的 .pas 源码 │ ├── System/ │ ├── Core/ │ ├── Protocols/ │ └── Security/ └── Packages/ # 各 IDE 版本的 .dpk 设计期/运行期包三块内容的分工要理清楚。Source是真源码排错时要能翻进去看Lib是预编译产物加编译开关Packages里的.dpk才是往 IDE 里装的东西。关键判断在于Lib下的 DCU 是不是你这版编译器的产物。Delphi 的 DCU 和编译器版本强绑定Delphi 12 的编译器版本是 36包后缀 29011 是 28010.4 是 270对着自己手上的版本改数字。如果包里带的 DCU 是更早的编译器编的链接阶段就会炸。稳妥做法是忽略预编译 DCU全部用源码重编一遍——多花五分钟省掉半天排查。提示解压路径别带中文和空格。Indy 的包工程里有相对路径引用路径里有空格时某些版本的 msbuild 会把参数切断报出来的错跟路径毫无关系。2.2 编包顺序System → Core → Protocols一步都不能跳Indy 拆成六个包运行期三个、设计期三个依赖是单向的包名Delphi 12类型依赖内容indySystem290运行期无基础单元、平台抽象indyCore290运行期indySystem290Socket 核心、IOHandlerindyProtocols290运行期indyCore290HTTP/SMTP/FTP 等协议dclIndySystem290设计期indySystem290组件注册dclIndyCore290设计期indyCore290组件注册dclIndyProtocols290设计期indyProtocols290组件注册IDE 里操作就是依次打开、右键 Build、再右键 Install。但更省事的是命令行批处理尤其是要给多台机器装同一套环境时# 先让 RAD Studio 的环境变量生效路径按自己的安装位置改 call RADStudio\bin\rsvars.bat # 按依赖顺序编Config 用 Release 减少调试信息体积 msbuild indySystem290.dpk /t:Build /p:ConfigRelease /p:PlatformWin32 msbuild indyCore290.dpk /t:Build /p:ConfigRelease /p:PlatformWin32 msbuild indyProtocols290.dpk /t:Build /p:ConfigRelease /p:PlatformWin32 # 设计期包编完会自动往 IDE 注册装完重启 IDE 才能在面板看到 msbuild dclIndyCore290.dpk /t:Build /p:ConfigRelease /p:PlatformWin32 msbuild dclIndyProtocols290.dpk /t:Build /p:ConfigRelease /p:PlatformWin32/p:PlatformWin32这行别漏。默认可能编成 Win64结果 32 位工程引用时找不到 DCU报「找不到单元」但又不说找的是哪个平台。64 位工程要单独再编一遍 Win64 的三个运行期包设计期包只需要一份。编的过程中如果提示缺IdCompilerDefines.inc基本可以确定是Lib\System没进搜索路径或者这个 inc 被解压工具改了大小写。Windows 上不区分但 Indy 的部分{$I}引用写的是大小写敏感的路径跨平台同步过的包偶尔会踩到。2.3 库路径与「两套 Indy」冲突最隐蔽的一道坎Delphi 12 自带一份 Indy版本号通常比 10.6.3.3 略旧或略有差异。你编完自己的包、装上设计期包之后IDE 里可能出现两个 Indy 页签或者拖出来的控件行为对不上预期——这就是两套共存了。处理分两步。第一步把搜索路径顶到最前Tools → Options → Language → Delphi → Library → Library path 把 Indy\Lib\Win32\Release 放到列表最上方路径顺序决定编译器先命中哪份 DCU。放最后面等于没放因为自带的路径在前面同名单元永远先被找到。第二步禁用自带的包。Component → Install Packages里把 Embarcadero 自带的那几个 Indy 设计期包取消勾选只留自己编的。这一步不做组件面板上的控件仍然指向旧 BPL运行时加载的却是新 DLL出现「属性设了不生效」这种问题。注意改完路径一定要关掉 IDE 重开。库路径是启动时读进内存的改完不重启编译行为还是旧的很容易误判成「改了没用」。2.4 最小验证五分钟确认这套东西真的能用装完先别急着上业务代码。新建一个空 VCL 工程拖一个TIdTCPClient和一个TIdHTTP到窗体上只做一件事——确认组件面板上的控件能被创建、能访问属性。procedure TForm1.FormCreate(Sender: TObject); var C: TIdTCPClient; begin C : TIdTCPClient.Create(nil); try // 能读到属性就说明单元链接成功不用真连 C.ConnectTimeout : 3000; C.ReadTimeout : 8000; Caption : Indy OK, port IntToStr(C.Port); finally C.Free; end; end;这段代码没有任何网络行为纯粹验证IdTCPClient单元能不能被正确链接和实例化。如果这里就报「找不到单元」或者运行时报抽象错误说明包装错或者路径没生效后面写再多业务代码也是白搭。这一步我每次装新环境都会跑只花一分钟但能挡掉后面八成环境问题。3. 阻塞式 Socket 的真相TIdTCPClient 与 TIdTCPServer 的最小骨架Indy 的全套组件都是阻塞式 IO这个设计取向决定了你写出来的代码长什么样也决定了它会以什么方式坑你。很多人第一次用 Indy 觉得「怎么一读就卡死」本质是没接受这个前提。3.1 阻塞模型不是缺陷是设计取向TIdTCPClient.Connect会一直等到握手完成或者超时IOHandler.ReadLn会一直等到读到一行或者超时TIdHTTP.Get会一直等到响应体收完。这期间调用线程是挂起的不处理任何消息。这套模型的好处是代码线性、逻辑清晰不用回调也不用状态机读一行写一行跟操作文件差不多。代价是任何阻塞调用都不能放在主线程里。TIdTCPServer的处理方式是把每个连接丢进独立线程OnExecute事件就在那个线程里反复触发。所以服务端代码天然是并发的你不写线程也得面对线程问题。客户端相反TIdTCPClient本身不创建线程谁调谁阻塞。至于TIdAntiFreeze它的作用是在阻塞调用期间插入Application.ProcessMessages让界面看起来不卡。这个组件能救急但代价很大消息重入会让用户在阻塞期间再次点按钮触发第二次阻塞调用然后就是经典的「窗口白屏 栈溢出」。我一般的做法是客户端所有网络操作放独立线程结果用TThread.Queue回主线程更新界面TIdAntiFreeze只在维护老代码时留着。3.2 客户端连接、超时、心跳、自动重连超时参数是这套东西里最容易被忽略、又最容易出事的地方。两个值必须显式设type TNetClient class private FClient: TIdTCPClient; public constructor Create; function Connect: Boolean; procedure Send(const S: string); procedure Disconnect; end; constructor TNetClient.Create; begin FClient : TIdTCPClient.Create(nil); FClient.Host : 127.0.0.1; FClient.Port : 9000; end; function TNetClient.Connect: Boolean; begin Result : False; if FClient.Connected then Exit(True); try FClient.ConnectTimeout : 3000; // 握手最长等 3 秒 FClient.ReadTimeout : 8000; // 单次读最长等 8 秒0 无限等 FClient.Connect; Result : True; except on E: Exception do // 异常信息一定要落日志别只吞掉 WriteLog(Format(connect fail: %s / %s, [E.ClassName, E.Message])); end; end; procedure TNetClient.Send(const S: string); begin if not FClient.Connected then if not Connect then Exit; try FClient.IOHandler.WriteLn(S); except // 写失败通常意味着连接已断主动断开让下次重连 FClient.Disconnect; end; end;ConnectTimeout默认值是 0 还是某个非零值不同版本不一样别赌显式写。ReadTimeout设 0 意味着「一直等到有数据」在网络抖动或者服务端半开连接的情况下这个线程就永久挂住了而且不报错。我见过最难受的线上问题就是这种连接看着还在心跳也在发就是收不到回包因为读线程早就挂死了。心跳单独说。TCP 本身有 KeepAlive但系统级的 KeepAlive 默认两小时才探测一次业务上根本等不起。常见做法是应用层心跳procedure TNetClient.OnHeartbeat(Sender: TObject); begin if not FClient.Connected then Exit; try FClient.IOHandler.WriteLn(PING); // 注意这里不要直接 ReadLn 等 PONG会阻塞定时器线程 // 回包由独立的接收线程处理收到 PONG 就更新最后活跃时间 FLastActive : Now; except FClient.Disconnect; end; end;心跳发送和回包接收要分开。心跳只管发接收线程读到PONG就刷新FLastActive主循环定期检查Now - FLastActive 阈值就判定断线并触发重连。这个组合比「发完就等回包」稳得多因为等待回包本身就是一次阻塞。3.3 服务端Contexts 的锁、会话挂载与广播TIdTCPServer的Contexts属性是所有活跃连接的列表类型是TListTIdContext。这个列表属于服务端内部读写必须配对加锁否则并发连接一多就会出现访问违例而且是那种偶发的、难复现的。每个连接要挂业务数据用TIdContext.DataTObject类型最直接procedure TForm1.IdTCPServer1Connect(AContext: TIdContext); begin AContext.Data : TSession.Create; // 每个连接一份独立会话 end; procedure TForm1.IdTCPServer1Disconnect(AContext: TIdContext); begin TSession(AContext.Data).Free; AContext.Data : nil; end; procedure TForm1.IdTCPServer1Execute(AContext: TIdContext); var Line: string; begin // 第二个参数是读超时超时会抛异常触发 OnException Line : AContext.Connection.IOHandler.ReadLn(#10, 30000); if Line PING then AContext.Connection.IOHandler.WriteLn(PONG) else HandleBusiness(AContext, Line); end;OnConnect和OnDisconnect成对出现但要注意OnDisconnect不保证一定触发——进程被强杀、网线被拔服务端可能过很久才感知。所以会话对象里最好带一个创建时间定期清理超时的僵尸会话。广播是这样写的procedure TForm1.Broadcast(const S: string); var List: TListTIdContext; Ctx: TIdContext; begin List : IdTCPServer1.Contexts.LockList; // 加锁拿快照 try for Ctx in List do begin try Ctx.Connection.IOHandler.WriteLn(S); except // 单个连接写失败不能影响其他人交给 OnException 处理 end; end; finally IdTCPServer1.Contexts.UnlockList; // 必须配对 end; end;LockList会在整个循环期间持有锁连接数上百时广播会有明显延迟。要优化的话先在锁内把 Context 复制到临时数组解锁后再逐个发。这个改动不大但在几百连接的场景下差别很明显。线程边界这条要反复强调OnExecute跑在工作线程里里面绝对不能直接碰 VCL 控件。更新界面统一走TThread.Queueprocedure TForm1.PostLog(const S: string); begin TThread.Queue(nil, procedure begin Memo1.Lines.Add(S); // 这段在主线程执行 end); end;用Queue不用Synchronize。Synchronize会等待主线程执行完工作线程被挂起高并发时直接拖垮吞吐。Queue是投递完就返回。4. 上层协议组件落地HTTP、SMTP、FTP 的参数怎么设协议层组件把 Socket 的细节包掉了但参数没设对一样出问题。这一章按实际使用频率排HTTP 最多SMTP 次之FTP 最少但坑最集中。4.1 TIdHTTP请求头、重定向、流式下载先说选型。Delphi 自带TNetHTTPClient底层走平台原生实现不用带 OpenSSL DLLTIdHTTP的优势是行为可控、能直接拿到原始响应头、能自定义 IOHandler、能和 Indy 其余组件共用一套连接管理。需要精细控制比如抓取特定响应头、做流式大文件下载、走自定义 SSL 配置时选TIdHTTP。基本用法var HTTP: TIdHTTP; FS: TFileStream; begin HTTP : TIdHTTP.Create(nil); try HTTP.ConnectTimeout : 5000; HTTP.ReadTimeout : 30000; // 大文件下载要放宽 HTTP.HandleRedirects : True; HTTP.MaximumRedirects : 5; // 默认值偏小跳转链路长会提前放弃 HTTP.Request.UserAgent : MyApp/1.0; HTTP.Request.CustomHeaders.Values[X-Auth-Token] : token-value; HTTP.Request.Accept : application/octet-stream; FS : TFileStream.Create(download.bin, fmCreate); try HTTP.Get(https://your-host/api/download, FS); finally FS.Free; end; finally HTTP.Free; end; end;几个点。Get的重载里传TStream那个版本才是流式的传字符串的版本会把整个响应体读进内存几十兆的文件直接吃满。HandleRedirects打开后OnRedirect事件可以用来处理需要携带 Cookie 的跳转但事件里改NewURL时要注意只改一次改多次会被忽略。状态码处理TIdHTTP在 4xx/5xx 时会抛EIdHTTPProtocolException异常对象里有ErrorCode和ErrorMessage响应体在E.Message里。要拿原始响应体捕获这个异常然后读E.Messagetry HTTP.Get(URL, Stream); except on E: EIdHTTPProtocolException do WriteLog(Format(HTTP %d: %s, [E.ErrorCode, E.Message])); on E: EIdConnectTimeout do WriteLog(连接超时检查网络或目标端口); on E: EIdReadTimeout do WriteLog(读超时服务端响应过慢或数据未收完); end;分开捕获EIdConnectTimeout和EIdReadTimeout很值得这两种超时指向完全不同的排查方向混在一起看日志时会绕远路。4.2 TIdSMTP TIdMessage中文编码的三个位置发邮件这套组件本身不难难在中文和编码。三个地方要一起设对缺一个就乱码。var SMTP: TIdSMTP; SSL: TIdSSLIOHandlerSocketOpenSSL; Msg: TIdMessage; begin SMTP : TIdSMTP.Create(nil); SSL : TIdSSLIOHandlerSocketOpenSSL.Create(nil); Msg : TIdMessage.Create(nil); try // 第一处传输层加密587 端口一般是显式 TLS SSL.SSLOptions.SSLVersions : [sslvTLSv1_2]; SMTP.IOHandler : SSL; SMTP.UseTLS : utUseExplicitTLS; SMTP.Host : smtp.your-host.com; SMTP.Port : 587; SMTP.Username : user; SMTP.Password : pass; // 第二处主题和正文的字符集 编码方式 Msg.From.Address : useryour-host.com; Msg.Recipients.EMailAddresses : toyour-host.com; Msg.Subject : 测试邮件; Msg.Body.Text : 这是一封中文正文。; Msg.CharSet : utf-8; Msg.ContentType : text/plain; Msg.ContentTransferEncoding : base64; SMTP.Connect; try SMTP.Authenticate; SMTP.Send(Msg); finally SMTP.Disconnect; end; finally Msg.Free; SSL.Free; SMTP.Free; end; end;第三处也是最容易漏的收件人显示名。Msg.Recipients.EMailAddresses只放地址要带中文显示名得操作TIdEmailAddressItem并且给它单独设Name编码由TIdMessage统一处理。ContentTransferEncoding用base64而不是quoted-printable是因为部分老邮件客户端对 QP 编码的中文处理不一致。代价是体积大三分之一但对内部通知类邮件完全可以接受。UseTLS有三个值utNoTLSSupport、utUseExplicitTLS、utUseImplicitTLS。587 端口配utUseExplicitTLS先明文连接再 STARTTLS465 端口配utUseImplicitTLS连上就是 TLS。配错的表现是连接建立后卡在认证阶段然后超时。4.3 TIdFTP被动模式与传输类型FTP 现在用得少但设备对接、内网文件同步还是常见。两个参数必须改FTP.Host : ftp.your-host.com; FTP.Port : 21; FTP.Passive : True; // 默认值在部分版本是 False内网有 NAT 时必改 FTP.TransferType : ftBinary; // 传压缩包、图片必须是二进制ASCII 模式会改字节 FTP.Username : user; FTP.Password : pass; FTP.Connect; try FTP.Login; FTP.ChangeDir(/upload); FTP.Put(local.zip, remote.zip); finally FTP.Quit; end;Passive设 False 走主动模式服务端要反向连客户端客户端在 NAT 后面基本连不通表现是「登录成功、列目录卡住、然后超时」。这是 FTP 最经典的坑Passive : True一句话解决。TransferType设错的表现更隐蔽传上去的文件大小对得上但打开报损坏。ASCII 模式会把 CRLF 做转换二进制文件一转换就废了。5. 避坑与排查Indy 在 Delphi 12 上最容易翻车的五件事下面五条都是我在实际项目里踩过或帮别人定位过的按「现象 → 原因 → 解决」写。5.1 一调 HTTPS 就报「Could not load SSL library」现象HTTP 请求只要目标地址是 https立刻抛出这个异常换成 http 就正常。原因Indy 自己不实现 TLS靠外挂 OpenSSL 动态库。DLL 缺失、位数不匹配32 位程序配 64 位 DLL、版本对不上都会报这一句。Indy 10.6.x 里对 OpenSSL 1.0.2 和 3.x 的文件名要求不一样1.0.2 是libeay32.dll/ssleay32.dll3.x 是libcrypto-3.dll/libssl-3.dll。解决先调IdSSLOpenSSLHeaders.WhichFailedToLoad拿到具体缺哪个文件别猜。DLL 放在 exe 同目录位数跟进程一致。生产环境我一般把 DLL 一起打进安装包不依赖系统目录里已有的版本因为别的软件装过一份旧版就会互相打架。5.2 点一下按钮界面就白屏几秒现象点了「查询」按钮窗口变白、拖动无响应几秒后数据出来。原因网络调用写在了按钮的OnClick里主线程阻塞消息循环停摆。解决把调用挪进TThread或者TTask结果用TThread.Queue回主线程。临时救急可以拖一个TIdAntiFreeze但要清楚它是靠插入ProcessMessages实现的用户在阻塞期间能再点一次按钮重入的问题迟早会来。5.3 收到的中文全是问号或者方块现象HTTP 响应、Socket 报文、邮件正文总有一处中文不对。原因Indy 的字符串处理链路里字符集声明有三层IOHandler 的DefStringEncoding、协议组件的ContentCharset、以及数据本身的字节编码。任何一层声明和实际字节不一致就会在转换时丢字符。解决先确认服务端返回的Content-Type里带的 charset再决定客户端怎么解。TIdHTTP.Response.ContentType和Response.CharSet都能读到。如果服务端不声明最稳的是按字节流接收然后自己按 UTF-8 解不要让它自动猜。5.4 连接看着还在但消息发出去没反应现象日志里心跳一直在发业务消息也写成功了但服务端就是收不到。重启客户端立刻恢复。原因ReadTimeout设成了 0或者接收线程早就因为异常退出但没人发现。TCP 半开连接对端已经没了本端还没感知在移动网络和长连接场景里非常普遍。解决ReadTimeout永远不要设 0给一个业务能接受的上限接收线程用try..finally包住退出时打日志应用层心跳配合「最后活跃时间」判定超时就主动Disconnect再重连。不要指望系统级 KeepAlive。5.5 服务端跑一段时间就少几个连接没有任何报错现象TIdTCPServer运行几小时后活跃连接数对不上也没有异常日志。原因OnExecute里抛出的异常被 Indy 内部捕获默认走OnException事件如果这个事件没处理异常就被静默吞掉了对应线程跟着结束。解决一定要挂OnException把E.ClassName、E.Message和当前AContext.Binding.PeerIP一起记下来。另外OnExecute内部自己也要try..except业务异常就地处理不要让一条脏数据把整条连接干掉。6. 进阶把 Indy 用到生产环境的三个硬技巧基础跑通之后真正决定这套东西能不能上生产的是连接复用、TLS 配置和验证手段这三件事。先说连接复用。TIdHTTP的实例创建成本不低尤其带 SSL 的时候每次Create都要重新初始化 IOHandler。高频请求场景下我一般做成对象池一个TIdHTTP实例处理完一批请求再释放池大小按并发数配。要注意的是TIdHTTP不是线程安全的一个实例同一时刻只能被一个线程用池里取用必须加锁。再看 TLS 配置。默认配置能连通但不等于安全。生产环境我一般显式限定协议版本同时打开证书校验SSL.SSLOptions.SSLVersions : [sslvTLSv1_2]; SSL.SSLOptions.Mode : sslmClient; // 需要双向认证时挂证书 SSL.SSLOptions.CertFile : client.crt; SSL.SSLOptions.KeyFile : client.key;如果编译器提示sslvTLSv1_3未定义说明这版 Indy 还没暴露 TLS 1.3 常量只保留sslvTLSv1_2就行别硬写。协议版本限得太死会连不上只支持新版本的对端限得太松又可能协商到不安全的套件这个得按对端实际情况调。最后是验证手段。这套东西出问题的时候日志往往不够用得有独立于业务代码的探测方式排查目标手段关注点端口是否可达telnet host port或 PowerShellTest-NetConnection连接建立耗时TLS 是否能握手openssl s_client -connect host:443 -tls1_2证书链、协议版本连接是否泄漏netstat -ano按 PID 过滤TIME_WAIT 数量趋势服务端并发上限自己写个循环建连的小脚本第几个连接开始失败那张表里我最常用的是第三个。长连接项目跑一晚上第二天netstat一看 TIME_WAIT 几千个基本就能确定是客户端没正确Disconnect或者异常路径上漏了finally。从那以后我每次接新的通信模块都强制先把「连接、超时、日志」这三件套抽成一个独立单元用上面的探测手段单独验证一遍再接业务逻辑。这么做的直接原因是早年在客户现场排查一个「偶发断线」业务代码翻了两天最后发现是ReadTimeout没设、接收线程静默退出。希望帮到你。本文还有配套的精品资源点击获取
