简介Delphi 12 平台下的 Indy 10.6.3.3 网络组件包面向使用 Delphi 或 CBuilder 构建网络应用的开发者提供 TCP/IP、UDP、HTTP、SMTP、POP3、FTP 等协议的完整实现可用于邮件客户端、Web 服务、FTP 工具及聊天程序等场景。压缩包共 2000 个文件约 9.67MB以 pas 源码、dpk 包工程、dproj 项目文件、res/rc 资源、bmp 图示及 txt 说明为主并含跨版本编译脚本与多版本工程配置便于按协议模块查阅、编译和复用。已有 362 人学习下载。其价值在于同时给出组件源码、设计期包与多版本工程配置开发者可据此理解 TIdTCPClient、TIdHTTP 等组件的属性、事件与异步执行机制也可按需修改或扩展协议实现适合需要稳定网络通信能力、希望深入掌握 Indy 组件结构的中高级 Delphi 开发者参考。1. 拿到 Indy 10.6.3.3 压缩包先别急着装它到底解决了什么问题手上这份 Delphi 控件包解开之后只有两样东西一堆 Source 目录下的 .pas 源文件和 Packages 目录下几个 .dpk 工程。看着朴素但它解决的问题一点都不小——Delphi 12 Athens 里做 TCP 长连接、HTTP 接口对接、FTP 上传、SMTP 发信绕不开 Indy 这一族组件TIdTCPClient、TIdTCPServer、TIdHTTP、TIdFTP、TIdSMTP。IDE 里自带的那套往往落后几个小版本遇到 TLS 版本协商、IPv6 地址解析、大包读取超时这几类现场问题时改不动源码就只能绕路。10.6.3.3 这版把源码全给了出问题能直接下断点进 IdTCPConnection.pas 里看这是它最值钱的地方比组件面板上多几个图标实在得多。适合两类人一类是手里有 Delphi 12 项目、需要自己控制网络层细节的客户端/服务端开发者另一类是想把 Indy 当学习样本、看清楚阻塞式 socket 怎么封装的工程师。不适合只想拖个控件发个 HTTP 请求就完事的人那种场景用 IDE 自带的就够装新版反而要处理路径冲突。2. 装进 Delphi 12从解压目录到组件面板的四步落地Indy 的安装不算难难在「装完之后用的到底是哪一版」。Delphi 12 自带一份 Indy你把新源码解压到任意目录、编译出新的 bpl如果库路径顺序没调对编译时链接进去的可能还是 IDE 自带的那份旧单元组件面板看着是新的跑起来行为还是旧的这种玄学问题排查起来很费时间。所以下面按「目录分层 → 路径顺序 → 运行期包 → 设计期包」四步走每一步都给出可验证的结果。2.1 目录结构的分层Core、Protocols、SuperCore 各管什么解开压缩包Source 目录下通常按职责分成几个子目录粗略对应关系如下表。理解这个分层不是为了背目录而是为了在编译报「找不到 IdContext」时知道该往哪条路径上补。目录主要内容典型单元System基础类型、字符串、编码、字节序转换IdGlobal、IdStrings、IdTextEncodingCoreTCP/UDP 传输层、IOHandler、上下文与线程模型IdTCPConnection、IdTCPClient、IdTCPServer、IdIOHandlerStackProtocols应用层协议实现IdHTTP、IdFTP、IdSMTP、IdPOP3、IdDNSResolverSuperCore对 Core 的扩展与增强实现IdContext、IdCustomTCPServer 等增强单元Packages 目录下则是工程文件运行期包IndySystem、IndyCore、IndyProtocols和设计期包dclIndyCore、dclIndyProtocols文件名后面一般带 IDE 版本后缀你解压出来的这一份对应哪个版本看文件名就知道了。运行期包负责把源码编成 bpl 供程序链接设计期包负责往组件面板注册图标两者编译顺序不能颠倒。先把整个 Source 目录复制到一个固定位置比如D:\Libs\Indy\Source不要放在桌面或者带中文、空格的路径下后面库路径里要写绝对路径路径里带空格很容易在命令行编译时出岔子。复制完先别急着开 IDE把 IDE 关掉——Delphi 启动时会加载已注册的设计期包开着 IDE 覆盖 bpl 会提示文件占用。2.2 库路径的顺序比路径本身更重要打开 Delphi 12进 Tools → Options → Language → Delphi → Library在 Selected Platform 里分别给 Win32 和 Win64 各配一遍。把下面几条按顺序加进去并且用向上移动按钮把它们顶到列表最前面D:\Libs\Indy\Source\System D:\Libs\Indy\Source\Core D:\Libs\Indy\Source\Protocols D:\Libs\Indy\Source\SuperCore顺序的意义在于编译器按列表从上往下找单元先命中的胜出。IDE 自带的 Indy 路径一般挂在安装目录下如果你把新路径追加在末尾编译时先命中旧单元于是你改了 IdHTTP 的源码、加了日志运行起来一行日志都没有——这不是代码写错了是根本没编进去。我一般会把旧路径直接从列表里删掉而不是靠排序压制删掉之后如果编译报缺单元说明新路径没配全问题立刻暴露比藏着掖着强。Win32 和 Win64 要分别配很多人只配了当前平台切到 64 位一编译就报找不到单元。2.3 编译顺序先运行期后设计期打开 Packages 目录下对应版本后缀的工程组按下面的顺序逐个 Build不要用 Install 去编译运行期包1. IndySystemXXX.dpk Build 2. IndyCoreXXX.dpk Build 3. IndyProtocolsXXX.dpk Build 4. dclIndyCoreXXX.dpk Install 5. dclIndyProtocolsXXX.dpk Install第 1 到第 3 步只 Build 不 Install因为运行期包不需要注册到 IDE它只提供编译期的单元和运行期的 bpl。第 4、5 步才是设计期包点 Install 之后组件面板才会出现 Indy 那一页。编译过程中如果弹出「Unit xxx was compiled with a different version of yy」八成是某个中间 bpl 还是旧的Project → Build All Projects 重来一次或者手动删掉C:\Users\Public\Documents\Embarcadero\Studio\版本\Bpl下对应的 bpl 再编。安装完打开组件面板Indy 分类下应该能看到 TIdTCPClient、TIdTCPServer、TIdHTTP、TIdFTP、TIdSMTP 这一批。看不到就回退检查设计期包是否真的 Install 成功——IDE 底部消息窗会打印注册了多少个组件数字是 0 就是没注册上通常是设计期包引用的运行期包路径不对。2.4 用一个最小 Demo 验证装的是新版装完别急着往正式项目里搬先建一个空 VCL 工程验一下。窗体上放 TIdHTTP、TButton、TMemo按钮里发一个请求到你本地或内网的任意一个 HTTP 服务procedure TForm1.Button1Click(Sender: TObject); begin IdHTTP1.HandleRedirects : True; // 跟随 301/302 IdHTTP1.ConnectTimeout : 5000; // 建连超时毫秒 IdHTTP1.ReadTimeout : 10000; // 单次读超时毫秒 try Memo1.Text : IdHTTP1.Get(http://127.0.0.1:9000/ping); except on E: EIdException do Memo1.Text : E.ClassName : E.Message; end; end;ConnectTimeout管的是三次握手阶段网络不通时到你设定的毫秒数就抛 EIdConnectTimeoutReadTimeout管的是连上之后每次读数据的最长等待服务端处理慢但一直在发数据的话不会触发。这两个值不设默认是 0 表示无限等界面上就是一个转不出来的圈。异常这里只捕获 EIdException能覆盖 Indy 自己的超时、连接重置、协议错误捕获 Exception 会把访问违例一起吞掉调试时反而看不清。跑通之后在IdHTTP1.Get上按 Ctrl点击进入源码看标题栏显示的路径是不是D:\Libs\Indy\Source\Protocols\IdHTTP.pas。如果是 IDE 安装目录下的路径说明路径顺序还没生效回 2.2 重来。这一步花两分钟能省掉后面几小时的「改了没效果」。3. TIdTCPClient 与 TIdTCPServer 的收发模型把「能连上」变成「能收全」Indy 是阻塞式 socket 的封装所有读写方法调用后会一直等到条件满足或超时才返回代码写起来像顺序流程但前提是你得知道每次调用到底在等什么。现场最常见的抱怨是「连上了但收不到数据」和「数据收了一半」这两个问题基本都出在对 IOHandler 读写原语的理解偏差上而不是网络本身。3.1 IOHandler 的三个读原语ReadLn、ReadBytes、ReadStream 的边界TIdTCPConnection 上的 ReadLn、ReadBytes 最终都转给 IOHandler 执行区别在于「什么时候算读完」。ReadLn读到行结束符默认 #10可用 LFOnly、LineFeed 属性调整为止返回字符串。它适合文本协议比如 RESP、SMTP 那种以换行分帧的。坑在于如果对端只发了半行、后面永远不发换行符ReadLn 会一直阻塞到 ReadTimeout 触发抛 EIdReadTimeout你拿到的不是半行数据而是异常。所以处理不可信的对端时ReadLn 外面必须包 try/except。ReadBytes(ABuffer, AByteCount, AAppend)读固定字节数读满才返回读不满同样抛 EIdReadTimeout。第三个参数 AAppend 决定是追加到 ABuffer 尾部还是覆盖循环读大包时容易忘忘了就只剩最后一段。ReadStream(AStream, AByteCount, AReadUntilDisconnect)是往流里写第三个参数为 True 时会一直读到对端断开用它收未知长度的响应很方便但如果对端不断开就一直挂着。提示三个原语都是「要么读够要么抛异常」不存在「读了一部分安静返回」的情况这一点和有些语言的 socket recv 语义不同写重连逻辑时要按异常来分支不能按返回值判断。3.2 服务端 OnExecute 的线程上下文你在哪个线程里写代码TIdTCPServer 的 OnExecute 不是主线程回调每个客户端连接对应一个 TIdContextOnExecute 在这个上下文的线程里反复执行。这意味着两件事第一OnExecute 里访问窗体控件必须用 TThread.Synchronize 或 TThread.Queue直接改 Label.Caption 就是标准的跨线程访问轻则界面卡顿重则随机崩溃第二OnExecute 里的阻塞读不会卡住其他客户端因为每个连接一个线程但会卡住这个连接自己的线程所以里面的循环必须能被 Active : False 打断。procedure TForm1.IdTCPServer1Execute(AContext: TIdContext); var Cmd: string; begin // 设置本连接的读超时避免线程永久挂死 AContext.Connection.IOHandler.ReadTimeout : 30000; try Cmd : AContext.Connection.IOHandler.ReadLn; // 阻塞直到一行到达 except on E: EIdReadTimeout do begin AContext.Connection.Disconnect; // 超时即断开 Exit; end; end; // 业务处理放到这里耗时操作不要持锁 TThread.Queue(nil, procedure begin Memo1.Lines.Add(AContext.Binding.PeerIP - Cmd); end); end;ReadTimeout设在这里而不是在设计器里是因为它是 IOHandler 的属性每个连接一份在 OnConnect 或 OnExecute 开头设最稳妥。TThread.Queue是异步投递不阻塞工作线程Synchronize会等主线程处理完再返回在高并发下容易把工作线程拖成串行。AContext.Binding.PeerIP拿对端地址注意在 OnDisconnect 之后这个对象可能已经失效别在断开之后再取。3.3 超时、心跳与断线检测的参数组合TCP 连接在物理断开拔网线、对端进程被杀时本端不会立刻知道因为 TCP 本身没有主动通知机制。Indy 层面能做的是三件事设读超时、发心跳、开 KeepAlive。读超时前面说了服务端在 OnExecute 里设客户端在连上后设IdTCPClient1.IOHandler.ReadTimeout。心跳一般是自己定一条业务消息客户端每隔 N 秒发一次服务端在 OnExecute 里读到就刷新时间戳超过 3N 秒没收到就主动 Disconnect。KeepAlive 走的是 Socket 层Indy 里通过TIdSocketHandle的 SetSockOpt 设置 SO_KEEPALIVE但默认探测间隔是两小时改起来要动注册表或者平台相关 API跨平台项目里不划算所以实际项目中我更倾向业务层心跳。参数位置建议值作用ConnectTimeout客户端3000~5000 ms建连阶段超时ReadTimeout客户端/服务端10000~30000 ms单次读等待上限心跳间隔业务层15~30 s保活与断线感知最大帧长协议层按业务定如 8 MB防止恶意长度头撑爆内存3.4 长度前缀分帧一个能直接抄的收发实现文本协议用 ReadLn 就行二进制或者消息体里本身含换行的协议必须自己做分帧。最常见的是「4 字节大端长度 消息体」收发两端用同一套编解码// 4 字节大端长度编码避免依赖 IOHandler 的字节序设置 function EncodeLen(N: UInt32): TIdBytes; begin SetLength(Result, 4); Result[0] : Byte(N shr 24); Result[1] : Byte(N shr 16); Result[2] : Byte(N shr 8); Result[3] : Byte(N); end; function DecodeLen(const B: TIdBytes; Offset: Integer 0): UInt32; begin Result : (UInt32(B[Offset]) shl 24) or (UInt32(B[Offset 1]) shl 16) or (UInt32(B[Offset 2]) shl 8) or UInt32(B[Offset 3]); end; procedure SendFrame(AConn: TIdTCPConnection; const ABody: TIdBytes); begin AConn.IOHandler.Write(EncodeLen(Length(ABody))); AConn.IOHandler.Write(ABody); end; function RecvFrame(AConn: TIdTCPConnection): TIdBytes; var LenBuf: TIdBytes; Len: UInt32; begin AConn.IOHandler.ReadBytes(LenBuf, 4, False); // 读满 4 字节不够则抛超时 Len : DecodeLen(LenBuf); if Len 8 * 1024 * 1024 then raise Exception.CreateFmt(帧长异常: %d, [Len]); // 防长度头攻击 AConn.IOHandler.ReadBytes(Result, Len, False); end;EncodeLen手动移位而不是调IOHandler.Write(Integer)是为了绕开字节序设置的隐式转换收发两端行为完全确定。RecvFrame里那条长度上限判断不能省一个被篡改或者版本不匹配的长度头能让服务端一次性申请几个 G 内存进程直接被杀。ReadBytes的第二处调用第三个参数为 False表示覆盖而不是追加这样每次返回的都是干净的一帧。服务端用的时候把OnExecute里的 ReadLn 换成RecvFrame(AContext.Connection)外面套 try/except 捕获 EIdReadTimeout 和 EIdConnClosedGracefully后者在对端正常关闭时抛出不是错误安静退出即可。4. HTTPS 与 SSL 运行库Indy 里最容易翻车的一段TIdHTTP 发 http 请求一路顺风改成 https 立刻报「Could not load SSL library」这条报错几乎是每个用 Indy 的人都会遇到一次的。原因不复杂Indy 自己不实现 TLS它通过 IOHandler 去调用外部的 SSL 动态库库文件位数不对、文件名不对、放的位置不对三种情况都会落到同一条报错上所以光看报错文字没法定位得逐项核。4.1 位数、文件名、搜索路径三件事第一是位数。Win32 程序必须配 32 位 DLLWin64 必须配 64 位混用不会有任何提示只会加载失败。项目从 32 位切到 64 位调试时最常见的翻车点就在这。第二是文件名。Indy 加载时会按一组候选名字依次尝试不同大版本的库文件名规则不同1.0.x 系列叫ssleay32.dll、libeay32.dll1.1.x 系列叫libssl-1_1.dll、libcrypto-1_1.dll3.x 系列带位数后缀形如libssl-3-x64.dll、libcrypto-3-x64.dll。你要放的这一份 Indy 支持到哪个系列看 Source 目录下 IdSSLOpenSSLHeaders.pas 里的常量定义那里把候选文件名和版本号都写死了比任何文档都准。放错系列的文件程序会当成没找到。第三是位置。优先放在 exe 同目录其次才是系统目录或 PATH。放系统目录在开发机上能跑换一台机器就崩部署时最容易漏。我一般会在程序启动时打印一行日志把IdSSLOpenSSL.Loaded之类的状态和实际加载路径打出来线上出问题直接看日志不用猜。4.2 TIdHTTP 走 HTTPS 的完整配置procedure TForm1.InitHttp; begin if IdSSLIOHandler nil then IdSSLIOHandler : TIdSSLIOHandlerSocketOpenSSL.Create(Self); // 只允许 TLS 1.2 / 1.3老协议在多数服务端已被禁用 IdSSLIOHandler.SSLOptions.SSLVersions : [sslvTLSv1_2, sslvTLSv1_3]; IdSSLIOHandler.SSLOptions.Mode : sslmClient; IdSSLIOHandler.SSLOptions.VerifyMode : [sslvrfPeer]; // 校验证书链 IdSSLIOHandler.SSLOptions.VerifyDepth : 2; IdHTTP1.IOHandler : IdSSLIOHandler; IdHTTP1.HandleRedirects : True; IdHTTP1.ConnectTimeout : 5000; IdHTTP1.ReadTimeout : 15000; IdHTTP1.Request.UserAgent : MyClient/1.0; end;SSLVersions用集合赋值而不是老的Method : sslvTLSv1_2单值写法后者在新版本里已被标记为过时混用会出现「协商成功但握手失败」的怪现象。VerifyMode包含sslvrfPeer表示校验服务端证书去掉它就变成不校验——很多人第一次跑不通就顺手去掉本地能过上线后被中间设备劫持也不会有任何提示属于典型的后悔药。真遇到自签证书的内网服务正确做法是把这个自签根证书导出成 pem赋给SSLOptions.RootCertFile保留校验。4.3 SNI 与 Host 头一个域名多个站点时必看现代服务端基本都靠 SNI 决定返回哪张证书。Indy 在发起请求时会把 URL 里的主机名带进 SNI 扩展但如果你手动改过Request.Host或者用 IP 直连再加 Host 头的方式访问SNI 里带的可能是 IP服务端返回默认证书校验就对不上报「certificate verify failed」。判断方法很简单用域名访问正常、用 IP Host 头访问失败基本就是这个问题。处理方式是不用 IP 直连或者把IdHTTP1.Host设成域名让 Indy 自己解析。反过来做内网多站点跳转测试时会故意改 Host 头这时候记得把证书校验相应放宽两端配置要匹配。4.4 报错对照表现象大概率原因处理方式Could not load SSL libraryDLL 缺失、位数不符、文件名不匹配按 IdSSLOpenSSLHeaders.pas 里的候选名核对放 exe 同目录SSL handshake failed协议版本不匹配SSLVersions 加上 TLS1.2/1.3去掉 SSLv3certificate verify failed证书链不全或 SNI 带错主机名配 RootCertFile改用域名访问Connection closed gracefully对端在读完响应前关闭检查 Content-Length 与 chunked 处理捕获该异常视为正常结束请求卡住不返回ReadTimeout 为 0显式设置 ConnectTimeout 与 ReadTimeout5. 避坑与排查五个反复出现的现场问题这一节里的五条每一条都在实际项目里出现过不止一次按「现象 → 原因 → 解决」记下来下次遇到能少花半天。5.1 组件面板是新的行为还是旧的现象装完 10.6.3.3新建工程拖 TIdHTTP行为和老版本一模一样自己在源码里加的日志一行都不打。原因库路径里 IDE 自带的 Indy 路径排在前面编译器先命中了旧单元或者设计期包引用的还是旧 bpl。解决删掉 IDE 自带路径只保留新 Source 的四条Project → Build All Projects 重编运行期包再重新 Install 设计期包在单元里 Ctrl点击进入源码确认标题栏路径。5.2 服务端能连上但一条数据都收不到现象客户端 connect 成功发送也返回成功服务端 OnExecute 里的 ReadLn 一直阻塞直到超时。原因客户端 Write 之后没有 Flush或者 Nagle 算法把小包攒着没发另一种是客户端发的是\r\n结尾服务端 ReadLn 默认只认\n理论上也能断但如果协议里发的是别的分隔符就永远等不到。解决IOHandler.Write之后确认数据确实出去了必要时IOHandler.WriteBufferFlush核对IOHandler.LFOnly、LineFeed与对端分隔符一致对实时性要求高的场景设IOHandler.WriteBufferSize或直接用 Write 不走缓冲。5.3 传大文件时内存暴涨现象用 TIdTCPClient 下载一个几百兆的文件进程内存一路涨到几个 G最后 Out of memory。原因用 TMemoryStream 接数据或者用IdHTTP1.Get(URL)返回字符串——后者会把整个响应读成 string二进制内容还会被编码转换破坏。解决改用IdHTTP1.Get(URL, TFileStream)直接落盘自己写 socket 收的时候用ReadStream(FileStream, Size, False)配合文件流别在内存里攒完整包分块收的时候设个合理的缓冲区比如 64 KB 一轮。5.4 关闭程序时卡死或报访问违例现象点关闭按钮程序界面消失但进程还在任务管理器里或者弹出「Cannot terminate an externally created thread」。原因TIdTCPServer 还处于 Active 状态就释放窗体工作线程还在 OnExecute 里阻塞读或者 OnExecute 里 Synchronize 到主线程时主线程已经销毁。解决FormClose 里先IdTCPServer1.Active : False这会触发所有上下文的断开并等待线程退出然后再释放组件OnExecute 里用TThread.Queue代替 Synchronize并在投递前判断Application.Terminated。5.5 中文乱码两端各说各话现象本机测试正常连上另一台服务器后收到的中文全是问号或者方块。原因Indy 的字符串读写默认按 IOHandler 的 DefStringEncoding 转换服务端用 GBK、客户端按 UTF-8 解或者干脆按 ASCII 截断。解决两端统一显式设置编码IOHandler.DefStringEncoding : IndyTextEncoding_UTF8HTTP 场景检查响应头里的 charsetIdHTTP1.Response.CharSet和ContentType一起看实在拿不准就把原始字节读出来自己转别让组件替你做决定。6. 进阶把 Indy 封成一层薄壳再谈复用直接用 TIdHTTP、TIdTCPClient 写业务代码很快就会散落在各个窗体里超时值五花八门重试逻辑各写各的。我的做法是包一层薄壳不追求大而全只统一三件事超时、异常分类、日志。type TNetResult (nrOk, nrTimeout, nrRefused, nrProtocol); function TNetHelper.GetText(const AUrl: string; out AErr: string): TNetResult; var Http: TIdHTTP; SSL: TIdSSLIOHandlerSocketOpenSSL; begin Result : nrProtocol; AErr : ; Http : TIdHTTP.Create(nil); SSL : TIdSSLIOHandlerSocketOpenSSL.Create(nil); try SSL.SSLOptions.SSLVersions : [sslvTLSv1_2, sslvTLSv1_3]; SSL.SSLOptions.VerifyMode : [sslvrfPeer]; Http.IOHandler : SSL; Http.ConnectTimeout : 5000; Http.ReadTimeout : 15000; try AErr : Http.Get(AUrl); Result : nrOk; except on E: EIdConnectTimeout do begin Result : nrTimeout; AErr : E.Message; end; on E: EIdReadTimeout do begin Result : nrTimeout; AErr : E.Message; end; on E: EIdSocketError do begin Result : nrRefused; AErr : E.Message; end; on E: EIdException do begin Result : nrProtocol; AErr : E.Message; end; end; finally Http.Free; SSL.Free; end; end;返回枚举而不是抛异常调用方按nrTimeout决定重试、按nrProtocol决定记日志告警业务代码里就不用到处写 try/except 了。Http和SSL每次新建看起来有点浪费但避免了共享实例上的状态残留——同一个 TIdHTTP 实例被多线程共用是 Indy 项目里最隐蔽的一类 bug症状是「偶尔返回上一个请求的内容」查起来极其费劲。配套的自检清单我一般贴在项目 README 里每次改网络层都过一遍检查项通过标准超时连接、读、写三类超时都有显式值没有 0编码收发两端 DefStringEncoding 一致且显式设置分帧有长度上限校验异常帧直接断开SSLVerifyMode 保留 sslvrfPeerDLL 与位数匹配线程工作线程不直接碰控件服务端关闭前先 Active : False释放每个 Create 都有对应 Free异常路径也覆盖最后说个习惯。早些年我图省事装完控件包直接往项目里搬结果在一个跨平台项目上吃了大亏32 位调试一切正常出 64 位包后所有 HTTPS 请求全挂日志里只有一句「Could not load SSL library」半夜对着服务器翻来覆去查了两小时最后发现就是 DLL 位数不对。从那以后我每次装完 Indy都强制走一遍第 2 章那个最小 Demo再单独跑一个 https 请求验证 SSL 库加载两分钟的事比事后排查省太多。这个压缩包里 Source 和 Packages 都是齐的按第 2 章的顺序编一遍、跑通验证剩下的坑基本都在第 3 到第 5 章里了。希望帮到你。本文还有配套的精品资源点击获取
简介Delphi 12 平台下的 Indy 10.6.3.3 网络组件包面向使用 Delphi 或 CBuilder 构建网络应用的开发者提供 TCP/IP、UDP、HTTP、SMTP、POP3、FTP 等协议的完整实现可用于邮件客户端、Web 服务、FTP 工具及聊天程序等场景。压缩包共 2000 个文件约 9.67MB以 pas 源码、dpk 包工程、dproj 项目文件、res/rc 资源、bmp 图示及 txt 说明为主并含跨版本编译脚本与多版本工程配置便于按协议模块查阅、编译和复用。已有 362 人学习下载。其价值在于同时给出组件源码、设计期包与多版本工程配置开发者可据此理解 TIdTCPClient、TIdHTTP 等组件的属性、事件与异步执行机制也可按需修改或扩展协议实现适合需要稳定网络通信能力、希望深入掌握 Indy 组件结构的中高级 Delphi 开发者参考。1. 拿到 Indy 10.6.3.3 压缩包先别急着装它到底解决了什么问题手上这份 Delphi 控件包解开之后只有两样东西一堆 Source 目录下的 .pas 源文件和 Packages 目录下几个 .dpk 工程。看着朴素但它解决的问题一点都不小——Delphi 12 Athens 里做 TCP 长连接、HTTP 接口对接、FTP 上传、SMTP 发信绕不开 Indy 这一族组件TIdTCPClient、TIdTCPServer、TIdHTTP、TIdFTP、TIdSMTP。IDE 里自带的那套往往落后几个小版本遇到 TLS 版本协商、IPv6 地址解析、大包读取超时这几类现场问题时改不动源码就只能绕路。10.6.3.3 这版把源码全给了出问题能直接下断点进 IdTCPConnection.pas 里看这是它最值钱的地方比组件面板上多几个图标实在得多。适合两类人一类是手里有 Delphi 12 项目、需要自己控制网络层细节的客户端/服务端开发者另一类是想把 Indy 当学习样本、看清楚阻塞式 socket 怎么封装的工程师。不适合只想拖个控件发个 HTTP 请求就完事的人那种场景用 IDE 自带的就够装新版反而要处理路径冲突。2. 装进 Delphi 12从解压目录到组件面板的四步落地Indy 的安装不算难难在「装完之后用的到底是哪一版」。Delphi 12 自带一份 Indy你把新源码解压到任意目录、编译出新的 bpl如果库路径顺序没调对编译时链接进去的可能还是 IDE 自带的那份旧单元组件面板看着是新的跑起来行为还是旧的这种玄学问题排查起来很费时间。所以下面按「目录分层 → 路径顺序 → 运行期包 → 设计期包」四步走每一步都给出可验证的结果。2.1 目录结构的分层Core、Protocols、SuperCore 各管什么解开压缩包Source 目录下通常按职责分成几个子目录粗略对应关系如下表。理解这个分层不是为了背目录而是为了在编译报「找不到 IdContext」时知道该往哪条路径上补。目录主要内容典型单元System基础类型、字符串、编码、字节序转换IdGlobal、IdStrings、IdTextEncodingCoreTCP/UDP 传输层、IOHandler、上下文与线程模型IdTCPConnection、IdTCPClient、IdTCPServer、IdIOHandlerStackProtocols应用层协议实现IdHTTP、IdFTP、IdSMTP、IdPOP3、IdDNSResolverSuperCore对 Core 的扩展与增强实现IdContext、IdCustomTCPServer 等增强单元Packages 目录下则是工程文件运行期包IndySystem、IndyCore、IndyProtocols和设计期包dclIndyCore、dclIndyProtocols文件名后面一般带 IDE 版本后缀你解压出来的这一份对应哪个版本看文件名就知道了。运行期包负责把源码编成 bpl 供程序链接设计期包负责往组件面板注册图标两者编译顺序不能颠倒。先把整个 Source 目录复制到一个固定位置比如D:\Libs\Indy\Source不要放在桌面或者带中文、空格的路径下后面库路径里要写绝对路径路径里带空格很容易在命令行编译时出岔子。复制完先别急着开 IDE把 IDE 关掉——Delphi 启动时会加载已注册的设计期包开着 IDE 覆盖 bpl 会提示文件占用。2.2 库路径的顺序比路径本身更重要打开 Delphi 12进 Tools → Options → Language → Delphi → Library在 Selected Platform 里分别给 Win32 和 Win64 各配一遍。把下面几条按顺序加进去并且用向上移动按钮把它们顶到列表最前面D:\Libs\Indy\Source\System D:\Libs\Indy\Source\Core D:\Libs\Indy\Source\Protocols D:\Libs\Indy\Source\SuperCore顺序的意义在于编译器按列表从上往下找单元先命中的胜出。IDE 自带的 Indy 路径一般挂在安装目录下如果你把新路径追加在末尾编译时先命中旧单元于是你改了 IdHTTP 的源码、加了日志运行起来一行日志都没有——这不是代码写错了是根本没编进去。我一般会把旧路径直接从列表里删掉而不是靠排序压制删掉之后如果编译报缺单元说明新路径没配全问题立刻暴露比藏着掖着强。Win32 和 Win64 要分别配很多人只配了当前平台切到 64 位一编译就报找不到单元。2.3 编译顺序先运行期后设计期打开 Packages 目录下对应版本后缀的工程组按下面的顺序逐个 Build不要用 Install 去编译运行期包1. IndySystemXXX.dpk Build 2. IndyCoreXXX.dpk Build 3. IndyProtocolsXXX.dpk Build 4. dclIndyCoreXXX.dpk Install 5. dclIndyProtocolsXXX.dpk Install第 1 到第 3 步只 Build 不 Install因为运行期包不需要注册到 IDE它只提供编译期的单元和运行期的 bpl。第 4、5 步才是设计期包点 Install 之后组件面板才会出现 Indy 那一页。编译过程中如果弹出「Unit xxx was compiled with a different version of yy」八成是某个中间 bpl 还是旧的Project → Build All Projects 重来一次或者手动删掉C:\Users\Public\Documents\Embarcadero\Studio\版本\Bpl下对应的 bpl 再编。安装完打开组件面板Indy 分类下应该能看到 TIdTCPClient、TIdTCPServer、TIdHTTP、TIdFTP、TIdSMTP 这一批。看不到就回退检查设计期包是否真的 Install 成功——IDE 底部消息窗会打印注册了多少个组件数字是 0 就是没注册上通常是设计期包引用的运行期包路径不对。2.4 用一个最小 Demo 验证装的是新版装完别急着往正式项目里搬先建一个空 VCL 工程验一下。窗体上放 TIdHTTP、TButton、TMemo按钮里发一个请求到你本地或内网的任意一个 HTTP 服务procedure TForm1.Button1Click(Sender: TObject); begin IdHTTP1.HandleRedirects : True; // 跟随 301/302 IdHTTP1.ConnectTimeout : 5000; // 建连超时毫秒 IdHTTP1.ReadTimeout : 10000; // 单次读超时毫秒 try Memo1.Text : IdHTTP1.Get(http://127.0.0.1:9000/ping); except on E: EIdException do Memo1.Text : E.ClassName : E.Message; end; end;ConnectTimeout管的是三次握手阶段网络不通时到你设定的毫秒数就抛 EIdConnectTimeoutReadTimeout管的是连上之后每次读数据的最长等待服务端处理慢但一直在发数据的话不会触发。这两个值不设默认是 0 表示无限等界面上就是一个转不出来的圈。异常这里只捕获 EIdException能覆盖 Indy 自己的超时、连接重置、协议错误捕获 Exception 会把访问违例一起吞掉调试时反而看不清。跑通之后在IdHTTP1.Get上按 Ctrl点击进入源码看标题栏显示的路径是不是D:\Libs\Indy\Source\Protocols\IdHTTP.pas。如果是 IDE 安装目录下的路径说明路径顺序还没生效回 2.2 重来。这一步花两分钟能省掉后面几小时的「改了没效果」。3. TIdTCPClient 与 TIdTCPServer 的收发模型把「能连上」变成「能收全」Indy 是阻塞式 socket 的封装所有读写方法调用后会一直等到条件满足或超时才返回代码写起来像顺序流程但前提是你得知道每次调用到底在等什么。现场最常见的抱怨是「连上了但收不到数据」和「数据收了一半」这两个问题基本都出在对 IOHandler 读写原语的理解偏差上而不是网络本身。3.1 IOHandler 的三个读原语ReadLn、ReadBytes、ReadStream 的边界TIdTCPConnection 上的 ReadLn、ReadBytes 最终都转给 IOHandler 执行区别在于「什么时候算读完」。ReadLn读到行结束符默认 #10可用 LFOnly、LineFeed 属性调整为止返回字符串。它适合文本协议比如 RESP、SMTP 那种以换行分帧的。坑在于如果对端只发了半行、后面永远不发换行符ReadLn 会一直阻塞到 ReadTimeout 触发抛 EIdReadTimeout你拿到的不是半行数据而是异常。所以处理不可信的对端时ReadLn 外面必须包 try/except。ReadBytes(ABuffer, AByteCount, AAppend)读固定字节数读满才返回读不满同样抛 EIdReadTimeout。第三个参数 AAppend 决定是追加到 ABuffer 尾部还是覆盖循环读大包时容易忘忘了就只剩最后一段。ReadStream(AStream, AByteCount, AReadUntilDisconnect)是往流里写第三个参数为 True 时会一直读到对端断开用它收未知长度的响应很方便但如果对端不断开就一直挂着。提示三个原语都是「要么读够要么抛异常」不存在「读了一部分安静返回」的情况这一点和有些语言的 socket recv 语义不同写重连逻辑时要按异常来分支不能按返回值判断。3.2 服务端 OnExecute 的线程上下文你在哪个线程里写代码TIdTCPServer 的 OnExecute 不是主线程回调每个客户端连接对应一个 TIdContextOnExecute 在这个上下文的线程里反复执行。这意味着两件事第一OnExecute 里访问窗体控件必须用 TThread.Synchronize 或 TThread.Queue直接改 Label.Caption 就是标准的跨线程访问轻则界面卡顿重则随机崩溃第二OnExecute 里的阻塞读不会卡住其他客户端因为每个连接一个线程但会卡住这个连接自己的线程所以里面的循环必须能被 Active : False 打断。procedure TForm1.IdTCPServer1Execute(AContext: TIdContext); var Cmd: string; begin // 设置本连接的读超时避免线程永久挂死 AContext.Connection.IOHandler.ReadTimeout : 30000; try Cmd : AContext.Connection.IOHandler.ReadLn; // 阻塞直到一行到达 except on E: EIdReadTimeout do begin AContext.Connection.Disconnect; // 超时即断开 Exit; end; end; // 业务处理放到这里耗时操作不要持锁 TThread.Queue(nil, procedure begin Memo1.Lines.Add(AContext.Binding.PeerIP - Cmd); end); end;ReadTimeout设在这里而不是在设计器里是因为它是 IOHandler 的属性每个连接一份在 OnConnect 或 OnExecute 开头设最稳妥。TThread.Queue是异步投递不阻塞工作线程Synchronize会等主线程处理完再返回在高并发下容易把工作线程拖成串行。AContext.Binding.PeerIP拿对端地址注意在 OnDisconnect 之后这个对象可能已经失效别在断开之后再取。3.3 超时、心跳与断线检测的参数组合TCP 连接在物理断开拔网线、对端进程被杀时本端不会立刻知道因为 TCP 本身没有主动通知机制。Indy 层面能做的是三件事设读超时、发心跳、开 KeepAlive。读超时前面说了服务端在 OnExecute 里设客户端在连上后设IdTCPClient1.IOHandler.ReadTimeout。心跳一般是自己定一条业务消息客户端每隔 N 秒发一次服务端在 OnExecute 里读到就刷新时间戳超过 3N 秒没收到就主动 Disconnect。KeepAlive 走的是 Socket 层Indy 里通过TIdSocketHandle的 SetSockOpt 设置 SO_KEEPALIVE但默认探测间隔是两小时改起来要动注册表或者平台相关 API跨平台项目里不划算所以实际项目中我更倾向业务层心跳。参数位置建议值作用ConnectTimeout客户端3000~5000 ms建连阶段超时ReadTimeout客户端/服务端10000~30000 ms单次读等待上限心跳间隔业务层15~30 s保活与断线感知最大帧长协议层按业务定如 8 MB防止恶意长度头撑爆内存3.4 长度前缀分帧一个能直接抄的收发实现文本协议用 ReadLn 就行二进制或者消息体里本身含换行的协议必须自己做分帧。最常见的是「4 字节大端长度 消息体」收发两端用同一套编解码// 4 字节大端长度编码避免依赖 IOHandler 的字节序设置 function EncodeLen(N: UInt32): TIdBytes; begin SetLength(Result, 4); Result[0] : Byte(N shr 24); Result[1] : Byte(N shr 16); Result[2] : Byte(N shr 8); Result[3] : Byte(N); end; function DecodeLen(const B: TIdBytes; Offset: Integer 0): UInt32; begin Result : (UInt32(B[Offset]) shl 24) or (UInt32(B[Offset 1]) shl 16) or (UInt32(B[Offset 2]) shl 8) or UInt32(B[Offset 3]); end; procedure SendFrame(AConn: TIdTCPConnection; const ABody: TIdBytes); begin AConn.IOHandler.Write(EncodeLen(Length(ABody))); AConn.IOHandler.Write(ABody); end; function RecvFrame(AConn: TIdTCPConnection): TIdBytes; var LenBuf: TIdBytes; Len: UInt32; begin AConn.IOHandler.ReadBytes(LenBuf, 4, False); // 读满 4 字节不够则抛超时 Len : DecodeLen(LenBuf); if Len 8 * 1024 * 1024 then raise Exception.CreateFmt(帧长异常: %d, [Len]); // 防长度头攻击 AConn.IOHandler.ReadBytes(Result, Len, False); end;EncodeLen手动移位而不是调IOHandler.Write(Integer)是为了绕开字节序设置的隐式转换收发两端行为完全确定。RecvFrame里那条长度上限判断不能省一个被篡改或者版本不匹配的长度头能让服务端一次性申请几个 G 内存进程直接被杀。ReadBytes的第二处调用第三个参数为 False表示覆盖而不是追加这样每次返回的都是干净的一帧。服务端用的时候把OnExecute里的 ReadLn 换成RecvFrame(AContext.Connection)外面套 try/except 捕获 EIdReadTimeout 和 EIdConnClosedGracefully后者在对端正常关闭时抛出不是错误安静退出即可。4. HTTPS 与 SSL 运行库Indy 里最容易翻车的一段TIdHTTP 发 http 请求一路顺风改成 https 立刻报「Could not load SSL library」这条报错几乎是每个用 Indy 的人都会遇到一次的。原因不复杂Indy 自己不实现 TLS它通过 IOHandler 去调用外部的 SSL 动态库库文件位数不对、文件名不对、放的位置不对三种情况都会落到同一条报错上所以光看报错文字没法定位得逐项核。4.1 位数、文件名、搜索路径三件事第一是位数。Win32 程序必须配 32 位 DLLWin64 必须配 64 位混用不会有任何提示只会加载失败。项目从 32 位切到 64 位调试时最常见的翻车点就在这。第二是文件名。Indy 加载时会按一组候选名字依次尝试不同大版本的库文件名规则不同1.0.x 系列叫ssleay32.dll、libeay32.dll1.1.x 系列叫libssl-1_1.dll、libcrypto-1_1.dll3.x 系列带位数后缀形如libssl-3-x64.dll、libcrypto-3-x64.dll。你要放的这一份 Indy 支持到哪个系列看 Source 目录下 IdSSLOpenSSLHeaders.pas 里的常量定义那里把候选文件名和版本号都写死了比任何文档都准。放错系列的文件程序会当成没找到。第三是位置。优先放在 exe 同目录其次才是系统目录或 PATH。放系统目录在开发机上能跑换一台机器就崩部署时最容易漏。我一般会在程序启动时打印一行日志把IdSSLOpenSSL.Loaded之类的状态和实际加载路径打出来线上出问题直接看日志不用猜。4.2 TIdHTTP 走 HTTPS 的完整配置procedure TForm1.InitHttp; begin if IdSSLIOHandler nil then IdSSLIOHandler : TIdSSLIOHandlerSocketOpenSSL.Create(Self); // 只允许 TLS 1.2 / 1.3老协议在多数服务端已被禁用 IdSSLIOHandler.SSLOptions.SSLVersions : [sslvTLSv1_2, sslvTLSv1_3]; IdSSLIOHandler.SSLOptions.Mode : sslmClient; IdSSLIOHandler.SSLOptions.VerifyMode : [sslvrfPeer]; // 校验证书链 IdSSLIOHandler.SSLOptions.VerifyDepth : 2; IdHTTP1.IOHandler : IdSSLIOHandler; IdHTTP1.HandleRedirects : True; IdHTTP1.ConnectTimeout : 5000; IdHTTP1.ReadTimeout : 15000; IdHTTP1.Request.UserAgent : MyClient/1.0; end;SSLVersions用集合赋值而不是老的Method : sslvTLSv1_2单值写法后者在新版本里已被标记为过时混用会出现「协商成功但握手失败」的怪现象。VerifyMode包含sslvrfPeer表示校验服务端证书去掉它就变成不校验——很多人第一次跑不通就顺手去掉本地能过上线后被中间设备劫持也不会有任何提示属于典型的后悔药。真遇到自签证书的内网服务正确做法是把这个自签根证书导出成 pem赋给SSLOptions.RootCertFile保留校验。4.3 SNI 与 Host 头一个域名多个站点时必看现代服务端基本都靠 SNI 决定返回哪张证书。Indy 在发起请求时会把 URL 里的主机名带进 SNI 扩展但如果你手动改过Request.Host或者用 IP 直连再加 Host 头的方式访问SNI 里带的可能是 IP服务端返回默认证书校验就对不上报「certificate verify failed」。判断方法很简单用域名访问正常、用 IP Host 头访问失败基本就是这个问题。处理方式是不用 IP 直连或者把IdHTTP1.Host设成域名让 Indy 自己解析。反过来做内网多站点跳转测试时会故意改 Host 头这时候记得把证书校验相应放宽两端配置要匹配。4.4 报错对照表现象大概率原因处理方式Could not load SSL libraryDLL 缺失、位数不符、文件名不匹配按 IdSSLOpenSSLHeaders.pas 里的候选名核对放 exe 同目录SSL handshake failed协议版本不匹配SSLVersions 加上 TLS1.2/1.3去掉 SSLv3certificate verify failed证书链不全或 SNI 带错主机名配 RootCertFile改用域名访问Connection closed gracefully对端在读完响应前关闭检查 Content-Length 与 chunked 处理捕获该异常视为正常结束请求卡住不返回ReadTimeout 为 0显式设置 ConnectTimeout 与 ReadTimeout5. 避坑与排查五个反复出现的现场问题这一节里的五条每一条都在实际项目里出现过不止一次按「现象 → 原因 → 解决」记下来下次遇到能少花半天。5.1 组件面板是新的行为还是旧的现象装完 10.6.3.3新建工程拖 TIdHTTP行为和老版本一模一样自己在源码里加的日志一行都不打。原因库路径里 IDE 自带的 Indy 路径排在前面编译器先命中了旧单元或者设计期包引用的还是旧 bpl。解决删掉 IDE 自带路径只保留新 Source 的四条Project → Build All Projects 重编运行期包再重新 Install 设计期包在单元里 Ctrl点击进入源码确认标题栏路径。5.2 服务端能连上但一条数据都收不到现象客户端 connect 成功发送也返回成功服务端 OnExecute 里的 ReadLn 一直阻塞直到超时。原因客户端 Write 之后没有 Flush或者 Nagle 算法把小包攒着没发另一种是客户端发的是\r\n结尾服务端 ReadLn 默认只认\n理论上也能断但如果协议里发的是别的分隔符就永远等不到。解决IOHandler.Write之后确认数据确实出去了必要时IOHandler.WriteBufferFlush核对IOHandler.LFOnly、LineFeed与对端分隔符一致对实时性要求高的场景设IOHandler.WriteBufferSize或直接用 Write 不走缓冲。5.3 传大文件时内存暴涨现象用 TIdTCPClient 下载一个几百兆的文件进程内存一路涨到几个 G最后 Out of memory。原因用 TMemoryStream 接数据或者用IdHTTP1.Get(URL)返回字符串——后者会把整个响应读成 string二进制内容还会被编码转换破坏。解决改用IdHTTP1.Get(URL, TFileStream)直接落盘自己写 socket 收的时候用ReadStream(FileStream, Size, False)配合文件流别在内存里攒完整包分块收的时候设个合理的缓冲区比如 64 KB 一轮。5.4 关闭程序时卡死或报访问违例现象点关闭按钮程序界面消失但进程还在任务管理器里或者弹出「Cannot terminate an externally created thread」。原因TIdTCPServer 还处于 Active 状态就释放窗体工作线程还在 OnExecute 里阻塞读或者 OnExecute 里 Synchronize 到主线程时主线程已经销毁。解决FormClose 里先IdTCPServer1.Active : False这会触发所有上下文的断开并等待线程退出然后再释放组件OnExecute 里用TThread.Queue代替 Synchronize并在投递前判断Application.Terminated。5.5 中文乱码两端各说各话现象本机测试正常连上另一台服务器后收到的中文全是问号或者方块。原因Indy 的字符串读写默认按 IOHandler 的 DefStringEncoding 转换服务端用 GBK、客户端按 UTF-8 解或者干脆按 ASCII 截断。解决两端统一显式设置编码IOHandler.DefStringEncoding : IndyTextEncoding_UTF8HTTP 场景检查响应头里的 charsetIdHTTP1.Response.CharSet和ContentType一起看实在拿不准就把原始字节读出来自己转别让组件替你做决定。6. 进阶把 Indy 封成一层薄壳再谈复用直接用 TIdHTTP、TIdTCPClient 写业务代码很快就会散落在各个窗体里超时值五花八门重试逻辑各写各的。我的做法是包一层薄壳不追求大而全只统一三件事超时、异常分类、日志。type TNetResult (nrOk, nrTimeout, nrRefused, nrProtocol); function TNetHelper.GetText(const AUrl: string; out AErr: string): TNetResult; var Http: TIdHTTP; SSL: TIdSSLIOHandlerSocketOpenSSL; begin Result : nrProtocol; AErr : ; Http : TIdHTTP.Create(nil); SSL : TIdSSLIOHandlerSocketOpenSSL.Create(nil); try SSL.SSLOptions.SSLVersions : [sslvTLSv1_2, sslvTLSv1_3]; SSL.SSLOptions.VerifyMode : [sslvrfPeer]; Http.IOHandler : SSL; Http.ConnectTimeout : 5000; Http.ReadTimeout : 15000; try AErr : Http.Get(AUrl); Result : nrOk; except on E: EIdConnectTimeout do begin Result : nrTimeout; AErr : E.Message; end; on E: EIdReadTimeout do begin Result : nrTimeout; AErr : E.Message; end; on E: EIdSocketError do begin Result : nrRefused; AErr : E.Message; end; on E: EIdException do begin Result : nrProtocol; AErr : E.Message; end; end; finally Http.Free; SSL.Free; end; end;返回枚举而不是抛异常调用方按nrTimeout决定重试、按nrProtocol决定记日志告警业务代码里就不用到处写 try/except 了。Http和SSL每次新建看起来有点浪费但避免了共享实例上的状态残留——同一个 TIdHTTP 实例被多线程共用是 Indy 项目里最隐蔽的一类 bug症状是「偶尔返回上一个请求的内容」查起来极其费劲。配套的自检清单我一般贴在项目 README 里每次改网络层都过一遍检查项通过标准超时连接、读、写三类超时都有显式值没有 0编码收发两端 DefStringEncoding 一致且显式设置分帧有长度上限校验异常帧直接断开SSLVerifyMode 保留 sslvrfPeerDLL 与位数匹配线程工作线程不直接碰控件服务端关闭前先 Active : False释放每个 Create 都有对应 Free异常路径也覆盖最后说个习惯。早些年我图省事装完控件包直接往项目里搬结果在一个跨平台项目上吃了大亏32 位调试一切正常出 64 位包后所有 HTTPS 请求全挂日志里只有一句「Could not load SSL library」半夜对着服务器翻来覆去查了两小时最后发现就是 DLL 位数不对。从那以后我每次装完 Indy都强制走一遍第 2 章那个最小 Demo再单独跑一个 https 请求验证 SSL 库加载两分钟的事比事后排查省太多。这个压缩包里 Source 和 Packages 都是齐的按第 2 章的顺序编一遍、跑通验证剩下的坑基本都在第 3 到第 5 章里了。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
