第17篇_Client 06｜chunked、关闭和 keep-alive 边界

适合谁收藏正在让 PLC 主动访问 HTTP 服务的工程师。需要处理请求构造、响应边界、超时与连接复用的人。希望把 Client 故障定位到确定状态和错误出口的读者。本篇位置客户端篇第 6/7 篇主系列第 17/28 篇。现场问题同一个 API用测试服务返回 Content-Length 时正常换成代理服务器后 Client 一直等待。抓包会发现代理改成了Transfer-Encoding: chunked。另一个隐患是连接复用。上一条响应如果没有完全消费下一条请求就可能把残留字节当成新状态行。先给结论Client 必须先按 Header 选择响应边界策略。只有当前响应完整、缓冲区干净且状态复位后受控 keep-alive 才能发送下一条请求当前实现不支持 pipeline。读图重点这张图只压缩本篇的判断路径。读图时先找“Content-Length”对应的输入边界再沿着“顺序复用同一连接”检查状态怎样推进最后用“禁止并发 pipeline”确认输出是否已经形成验收证据。把对象和边界分开对象或阶段工程职责现场观察点Content-Length读取固定字节数最容易诊断chunked逐块解码到 0 块支持真实代理响应Connection: close对端关闭提供结束信号需要区分正常关闭和错误keep-alive顺序复用同一连接禁止并发 pipeline从协议约束到代码职责协议约束Client 必须先按 Header 选择响应边界策略。只有当前响应完整、缓冲区干净且状态复位后受控 keep-alive 才能发送下一条请求当前实现不支持 pipeline。 这条结论先限定消息什么时候成立再限定哪个角色可以消费结果。若绕过协议边界直接驱动业务半包、超时、重复执行和连接残留就会进入应用层。工程抽象Parser 将bTransferChunked、bHasContentLength和bConnectionClose分开保存。状态机依据这些字段决定继续读、解码、完成或等待关闭。首版的目标是可诊断不是追求最大吞吐。顺序 keep-alive 已经能减少频繁建连但每次只允许一个在途事务避免跨请求边界污染。Content-Length工程职责是“读取固定字节数”。它不能只停留在命名层面运行时必须能通过“最容易诊断”观察到输入、状态或结果否则这一层即使有代码也没有形成可验证边界。chunked工程职责是“逐块解码到 0 块”。它不能只停留在命名层面运行时必须能通过“支持真实代理响应”观察到输入、状态或结果否则这一层即使有代码也没有形成可验证边界。Connection: close工程职责是“对端关闭提供结束信号”。它不能只停留在命名层面运行时必须能通过“需要区分正常关闭和错误”观察到输入、状态或结果否则这一层即使有代码也没有形成可验证边界。keep-alive工程职责是“顺序复用同一连接”。它不能只停留在命名层面运行时必须能通过“禁止并发 pipeline”观察到输入、状态或结果否则这一层即使有代码也没有形成可验证边界。程序单元本篇主证据来自FB_HttpClient.st中以bTransferChunked为定位点的连续源码。这里不是为了展示语法而是把协议约束落到确定程序单元输入先进入结构体或缓冲区状态机只在本周期处理可确认的部分长度和结束条件决定能否前进错误码与指标负责把失败原因带出对象边界。这样一来“响应边界策略由 Header 决定。”可以在代码、在线变量和外部报文之间逐项对照而不是依赖经验猜测。本篇核心源码片段下面两段代码来自同一个真实文件FB_HttpClient.st以bTransferChunked为中心连续截取没有改写变量、删除分支或用伪代码替代。第一段用于确认入口与前置条件第二段用于确认状态、边界和输出。核对时重点看“读取固定字节数”怎样进入对象以及“禁止并发 pipeline”怎样证明本次处理已经结束。若两段之间的连续关系无法解释“首版不支持 pipeline要明确写出。”就不能把局部代码截图当成实现证据。片段一入口、声明与前置条件{attribute hide_all_locals} METHOD PUBLIC M_Reset // IMPLEMENTATION // 工程说明本段集中处理状态、边界或诊断避免跨周期残留。 // 边界说明执行前后保持输出和错误码可被在线诊断追踪。 M_ResetTransaction(); hConnection : 0; bTcpConnected : FALSE; xActive : FALSE; xConnected : FALSE; xBusy : FALSE; xDone : FALSE; xError : FALSE; bBusy : FALSE; bDone : FALSE; bError : FALSE; diErrorID : 0; sDiagMsg : ; eLastError : E_HttpError.iNoError; eState : E_HttpClientState.iDisabled; stResponse.sVersion : HTTP/1.1; stResponse.uiStatusCode : 0; stResponse.sReason : ; stResponse.sContentType : GVL_Http.cnDefaultContentType; stResponse.sAdditionalHeader : ; stResponse.sRawHeaders : ; stResponse.sBody : ; stResponse.bHasContentLength : FALSE; stResponse.bTransferChunked : FALSE; stResponse.bConnectionClose : FALSE; stResponse.udiContentLength : 0; uiStatusCode : 0; sTxMessage : ; sRxMessage : ; sResponseBody : ; sResponseHeader : ; // METHOD M_SetClientError /// /// 名称 : M_SetClientError /// 功能 : 统一锁存 Client 错误。 /// 说明 : 所有故障路径必须写入诊断文本和统计错误码。这一段先回答对象在什么输入和状态下开始工作。阅读时要核对变量的初值、长度上限和启动条件不能只看某个布尔量是否变成 TRUE。片段二状态推进、边界与输出/// {attribute hide_all_locals} METHOD PRIVATE M_SetClientError : BOOL VAR_INPUT eError : E_HttpError : E_HttpError.iNoError; // 枚举状态或错误码。 sMessage : STRING(255) : ; // 诊断或协议文本字段。 END_VAR // IMPLEMENTATION // 工程说明本段集中处理状态、边界或诊断避免跨周期残留。 eLastError : eError; stMetrics.eLastError : eError; bError : TRUE; diErrorID : TO_DINT(eError); sDiagMsg : sMessage; M_SetClientError : TRUE; // METHOD M_UpdateClientOutputs /// /// 名称 : M_UpdateClientOutputs /// 功能 : 同步 Client 在线输出。 /// 说明 : 输出统一在主状态机末尾刷新减少分支遗漏。 /// {attribute hide_all_locals} METHOD PRIVATE M_UpdateClientOutputs // IMPLEMENTATION // 工程说明本段集中处理状态、边界或诊断避免跨周期残留。 bTcpConnected : fbTcpClient.xActive AND (hConnection 0) AND (eState E_HttpClientState.iDisabled) AND (eState E_HttpClientState.iFault); bBusy : (eState E_HttpClientState.iTcpConnect) OR (eState E_HttpClientState.iSend) OR (eState E_HttpClientState.iReceive); xActive : bTcpConnected; xConnected : bTcpConnected; xBusy : bBusy; xDone : bDone; xError : bError; uiStatusCode : stResponse.uiStatusCode; sResponseBody : stResponse.sBody; sResponseHeader : stResponse.sRawHeaders; diErrorID : TO_DINT(eLastError);第二段继续展示同一连续源码范围。把它与第一段合起来才能判断输入怎样被锁存、状态何时推进、边界何时满足以及错误出口是否保留了足够诊断信息。验证路径场景操作通过口径固定长度连续两次顺序请求第二次无残留字节chunked多块响应解码结果和长度正确服务端关闭响应后主动断开Client 正常收口并可重连坏 chunk长度或 CRLF 非法协议错误而非静默完成场景 1固定长度在同一条 keep-alive 连接上连续请求两个资源。第一条响应完成后记录接收缓冲区长度必须回到零、Parser 状态必须复位再写入第二条请求并检查新状态行从缓冲区首字节开始。只要第二条解析前仍有残留数据就停止复用连接并回到上一笔响应的边界诊断。场景 2chunked用代理服务返回三块 chunked 数据例如4\r\nWiki\r\n5\r\npedia\r\n0\r\n\r\n。逐块确认十六进制长度、块内容和末尾 0 块前两块到达时不得 Done0 块及终止 CRLF 到达后才输出拼接后的 Body。该测试的重点是解码状态而不是单纯比较最终字符串。场景 3服务端关闭让服务端在未声明长度的响应 Body 后主动关闭连接。Client 只能在已确认 Header 允许以关闭作为边界时把 EOF 解释为本次响应结束随后释放套接字并允许下一轮重新连接。若在 Header 尚未完整时先收到关闭必须保留为协议或传输错误不能伪装成正常完成。场景 4坏 chunk分别注入非法 chunk 长度和缺失 CRLF 的响应。Parser 应给出明确协议错误清理本次接收状态并禁止把不完整数据交给业务层下一次新连接仍需可以正常处理一条合法响应。这样才能确认错误出口没有把坏报文遗留到后续事务。常见误判没有 Content-Length 就判定响应无 Body漏掉代理返回的 chunked 数据。上一条响应未消费干净就复用连接残留字节被当成下一条状态行。把 Connection: close 一律当故障忽略它可能正是本次消息的结束策略。这些误判的共同点是拿一个局部现象替代完整事务。定位时必须回到本篇的输入、状态、边界和输出四个坐标并用相同输入完成回归。这一篇你最该记住响应边界策略由 Header 决定。keep-alive 必须建立在缓冲区干净之上。首版不支持 pipeline要明确写出。系列导航系列CodeSys HTTP 系列教程第 17/28 篇。阶段客户端篇职责线位置 6/7。上一篇第16篇下一篇第18篇发布顺序基础认知 - Server - Client - 完整源码加更 - 综合收束。