1. 为什么CanTp总让人从入门到放弃第一次接触AUTOSAR CanTp的人十个里有八个会在两周内产生强烈的挫败感。这不是因为CanTp本身有多复杂而是因为它卡在一个非常尴尬的位置上往下它要跟CAN控制器、CAN驱动、硬件过滤器打交道往上它要伺候CAN Interface、PduR、诊断栈UDS/OBD。任何一层出问题现象都表现为诊断发不出去或者收不到回复你根本不知道是哪一层在捣鬼。我见过太多人卡在这一步用CANoe或者PCAN发一帧诊断请求总线上明明能看到报文但ECU就是没反应。于是开始怀疑波特率、怀疑硬件、怀疑接线折腾一整天最后发现是CanTp的N_As超时设成了0或者STmin配成了非法值。这类问题在文档里往往只有一句话带过但实际调试时能耗掉你一整个下午。CanTpCAN Transport Layer的本质工作其实很朴素CAN一帧最多8字节经典CAN而UDS诊断请求动辄几十上百字节CanTp就是负责把长报文切成小段发出去分段/Segmentation在接收端再拼回来重组/Reassembly。它还要处理流控Flow Control防止发送方把接收方的缓冲区冲爆。听起来简单但魔鬼全在状态机和定时参数里。这篇文章适合谁看如果你是刚接触AUTOSAR诊断的嵌入式工程师或者被安排去调CAN TP层但完全没头绪的人又或者是想从零手写一个CanTp模块来理解协议的人那接下来的内容应该能帮你少走至少两周弯路。我不会只给你贴标准文档的原文而是把那些文档里不写、但实际调试中一定会遇到的坑一个个拆开讲清楚。2. CanTp在AUTOSAR通信栈里的真实位置2.1 上下层关系谁给谁递数据要理解CanTp先得把它的上下游关系理清楚。在AUTOSAR经典平台里通信栈是分层的CanTp夹在中间上层是PduRPDU RouterPduR负责把不同来源的PDU路由到正确的目标模块。诊断报文从DcmDiagnostic Communication Manager下来经过PduR被路由到CanTp。下层是CanIfCAN InterfaceCanTp把切好的段交给CanIfCanIf再调用CAN驱动把数据真正写到硬件邮箱里。关键点在于CanTp不直接碰硬件。它只跟CanIf打交道通过CanIf的API发送和接收PDU。这意味着如果你在CanTp层看到报文发出去了但总线上没有问题很可能在CanIf或更底层。我刚开始的时候犯过一个典型错误以为CanTp配置好了就能收发结果CanIf里的CAN ID过滤没配对接收中断根本没触发。CanTp的状态机一直停在等待接收的状态日志里什么都看不到。所以调试CanTp的第一步永远是确认CanIf和底层驱动是通的。2.2 PDU与N-PDU两个容易混淆的概念CanTp处理的数据单元叫N-PDUNetwork Protocol Data Unit而它从上层收到的是PDU也就是诊断报文。这两者的关系是上层给CanTp一个完整的诊断请求比如10 02会话控制或者22 F1 90读VIN这是一个PDU。CanTp根据PDU的长度决定用单帧SF还是多帧FF/CF发送。每个CAN帧里承载的那部分数据就是一个N-PDU。单帧情况下一个PDU就是一个N-PDU直接塞进8字节的CAN帧里。多帧情况下一个PDU被拆成多个N-PDU每个N-PDU占一个CAN帧。这里有个细节CAN FD和经典CAN的N-PDU长度不同。经典CAN的N-PDU最大8字节CAN FD可以到64字节。CanTp配置里有个参数叫CanTpRxDl和CanTpTxDl就是用来指定这个长度的。如果你用的是CAN FD但配置里还写着8那超过8字节的报文会被截断现象就是诊断响应不完整。2.3 寻址模式物理寻址与功能寻址CanTp支持两种寻址方式物理寻址Physical Addressing一对一通信诊断仪发给某个特定ECU。CAN ID是唯一的比如0x7A0发给ECU0x7A8是ECU的回复。功能寻址Functional Addressing一对多广播诊断仪发一个请求总线上所有ECU都能收到。通常用于OBD的0x7DF。这两种寻址在CanTp里的处理逻辑不同。功能寻址通常只支持单帧因为广播场景下做流控没有意义多个ECU同时回复会冲突。物理寻址才支持完整的多帧传输和流控。配置的时候要注意CanTp的Rx和Tx通道是分开配的每个通道可以独立设置寻址模式。如果你把功能寻址的通道配成了支持多帧可能会在总线上产生意外的流控帧干扰其他ECU。3. 分段与重组CanTp最核心的机制拆解3.1 四种帧类型的分工CanTp定义了四种帧类型每种帧的第一个字节PCI字节的高4位用来标识类型帧类型PCI高4位含义数据长度单帧 SF0x0完整报文在一帧内1-7字节经典CAN首帧 FF0x1多帧报文的第一个帧6字节经典CAN连续帧 CF0x2多帧报文的后续帧7字节经典CAN流控帧 FC0x3接收方控制发送节奏3字节单帧的PCI字节低4位表示数据长度。比如03 22 F1 90PCI是0x03表示后面有3个字节的数据22 F1 90。首帧的PCI是两个字节高4位是0x1低4位加上第二个字节组成12位的长度。比如10 14 22 F1 90 ...表示总长度是0x01420字节。连续帧的PCI只有一个字节高4位是0x2低4位是序列号SN从1开始递增到15后回绕到0。流控帧的PCI是三个字节第一个字节高4位是0x3低4位是流控状态FS第二个字节是块大小BS第三个字节是最小间隔时间STmin。3.2 发送端状态机从请求到完成的完整流程发送端的逻辑可以简化为这样一个状态机空闲状态等待上层发来发送请求。判断长度如果PDU长度小于等于单帧容量直接发单帧发完回到空闲。否则进入多帧流程。发送首帧把总长度和第一部分数据打包成FF发出去。等待流控帧发完FF后启动N_Bs定时器等待接收方的FC。解析流控帧收到FC后根据FS字段决定下一步FS0CTSContinue To Send可以继续发按BS和STmin控制节奏。FS1Wait接收方还没准备好继续等重启N_Bs定时器。FS2Overflow接收方缓冲区不够中止发送。发送连续帧按BS指定的数量发送CF每发一帧启动N_As定时器。发完BS个CF后再次等待FC。完成所有数据发完通知上层发送确认。这个流程里最容易出问题的是定时器管理。N_As是发送方等待CAN帧发送完成的超时N_Bs是等待流控帧的超时。如果这两个值设得太小在网络负载高的时候会频繁超时设得太大又会导致错误恢复太慢。我的经验是N_As一般设1000msCAN帧发送通常几毫秒就完成1000ms足够宽松N_Bs设1000ms取决于接收方的处理速度如果接收方是慢速ECU可以适当加大到2000ms。N_Cr是接收方等待连续帧的超时通常设1000ms。3.3 接收端状态机流控策略的取舍接收端的逻辑同样是一个状态机空闲状态等待接收。收到单帧直接上报给上层回到空闲。收到首帧解析总长度检查缓冲区是否够用。够用则发送FCCTS进入接收连续帧状态不够用则发送FCOverflow。接收连续帧每收到一个CF检查序列号是否正确存入缓冲区重启N_Cr定时器。收到BS个CF后发送下一个FC。完成收齐所有数据上报给上层。流控策略里最关键的参数是BSBlock Size和STmin。BS0表示接收方不限制发送方连续发送发送方可以一直发到结束。BS0表示每发BS个CF就要等一个FC。BS设太小会导致频繁的流控交互降低传输效率设太大又可能撑爆接收方缓冲区。STmin是接收方要求发送方在两帧CF之间的最小间隔。经典CAN下STmin的单位是毫秒范围0-127ms。有些实现还支持微秒级0xF1-0xF9表示100-900微秒。STmin0表示可以连续发但实际受限于CAN控制器的发送能力。我踩过的一个坑STmin设成了0x80。按照标准0x80-0xF0是保留值接收方应该按0x7F127ms处理。但有些ECU的实现直接忽略了非法值导致发送方以为可以快速发接收方却处理不过来丢帧。所以配置STmin时一定要用合法值推荐从10ms开始调。4. 定时参数与缓冲区那些文档不会告诉你的细节4.1 四个定时器的实际意义与推荐值CanTp标准定义了四个定时器但文档里往往只给一个范围不告诉你实际该设多少定时器作用标准范围推荐值说明N_As发送方等待帧发送完成0-1000ms1000ms本地发送通常很快N_Ar接收方等待帧发送完成0-1000ms1000ms接收方发FC时的超时N_Bs发送方等待流控帧0-1000ms1000ms取决于接收方速度N_Br接收方等待首帧后发FC0-1000ms1000ms接收方内部处理时间N_Cs发送方等待下一个CF发送0-1000ms1000ms发送方内部处理时间N_Cr接收方等待连续帧0-1000ms1000ms取决于发送方速度实际项目中N_Bs和N_Cr是最需要关注的。如果接收方是诊断仪PC端处理速度很快N_Bs可以设小一点比如500ms。如果接收方是资源紧张的ECUN_Cr要适当加大给发送方留足时间。有个反直觉的点定时器设得太大反而不好。因为一旦通信异常定时器超时是唯一的恢复机制。如果N_Bs设了5000ms意味着发送方要等5秒才知道对方没回复这5秒里诊断仪可能已经超时退出了。所以推荐值都在1000ms左右平衡了容错和恢复速度。4.2 缓冲区大小的计算逻辑CanTp的接收缓冲区大小决定了能接收多长的诊断报文。计算逻辑是经典CAN下首帧携带6字节每个连续帧携带7字节。如果最大诊断报文长度是L需要的缓冲区至少是L字节。但实际配置时缓冲区大小通常是固定的比如CanTpRxBufferSize。假设你要支持读VIN22 F1 90响应约20字节和读DTC可能上百字节缓冲区至少要设到256字节。如果设小了收到首帧后发现长度超过缓冲区只能回Overflow诊断就失败了。发送缓冲区同理。CanTpTxBufferSize要能容纳最大的诊断请求。通常诊断请求不会太长128字节够用但如果你要支持刷写Flash Programming请求可能上千字节这时候缓冲区要相应加大。注意缓冲区大小是在配置阶段静态分配的运行时不能动态扩展。所以项目初期就要评估好最大诊断报文长度留足余量。4.3 CAN FD带来的变化CAN FD的N-PDU最大64字节这改变了CanTp的分段逻辑单帧可以携带最多62字节PCI占2字节。首帧可以携带最多62字节PCI占2字节。连续帧可以携带最多63字节PCI占1字节。这意味着很多原本需要多帧的报文在CAN FD下可以单帧发完。比如读VIN的响应20字节经典CAN下需要FF2个CFCAN FD下直接一个SF就搞定了。但CAN FD也带来了新问题长度字段的编码。经典CAN的首帧长度是12位最大4095字节。CAN FD下如果报文超过4095字节需要用扩展长度编码。不过实际诊断报文很少超过4KB这个问题不常见。配置CAN FD的CanTp时要确保CanTpRxDl和CanTpTxDl设成64而不是默认的8。我见过有人用CAN FD但CanTp配置没改结果超过8字节的报文全被截断诊断响应永远不完整。5. 手写一个CanTp模块从零实现的完整思路5.1 数据结构设计如果要自己实现一个CanTp模块核心数据结构大概是这样的typedef enum { CANTP_RX_IDLE, CANTP_RX_WAIT_CF, CANTP_RX_WAIT_FC // 接收方一般不需要等FC } CanTp_RxState; typedef enum { CANTP_TX_IDLE, CANTP_TX_WAIT_FC, CANTP_TX_SENDING_CF } CanTp_TxState; typedef struct { CanTp_RxState rxState; uint8_t rxBuffer[256]; uint16_t rxLength; uint16_t rxExpected; uint8_t rxSN; uint8_t rxBS; uint8_t rxSTmin; uint32_t rxTimer; } CanTp_RxContext; typedef struct { CanTp_TxState txState; uint8_t txBuffer[256]; uint16_t txLength; uint16_t txOffset; uint8_t txSN; uint8_t txBS; uint8_t txSTmin; uint32_t txTimer; } CanTp_TxContext;每个通道物理寻址、功能寻址需要独立的上下文。如果支持多通道用数组管理。5.2 发送流程的代码骨架发送端的核心逻辑void CanTp_Transmit(uint8_t channel, uint8_t *data, uint16_t length) { CanTp_TxContext *ctx txContext[channel]; if (length 7) { // 单帧 uint8_t frame[8]; frame[0] (0x0 4) | length; memcpy(frame[1], data, length); CanIf_Transmit(channel, frame, 8); // 通知上层发送完成 PduR_TxConfirmation(channel); } else { // 多帧 ctx-txState CANTP_TX_WAIT_FC; ctx-txLength length; ctx-txOffset 0; ctx-txSN 1; // 发送首帧 uint8_t frame[8]; frame[0] (0x1 4) | ((length 8) 0x0F); frame[1] length 0xFF; memcpy(frame[2], data, 6); ctx-txOffset 6; CanIf_Transmit(channel, frame, 8); // 启动N_Bs定时器 ctx-txTimer N_BS_TIMEOUT; } }收到流控帧后的处理void CanTp_RxFlowControl(uint8_t channel, uint8_t *data) { CanTp_TxContext *ctx txContext[channel]; uint8_t fs data[0] 0x0F; uint8_t bs data[1]; uint8_t stmin data[2]; if (fs 0) { // CTS ctx-txBS bs; ctx-txSTmin stmin; ctx-txState CANTP_TX_SENDING_CF; CanTp_SendContinuousFrames(channel); } else if (fs 1) { // Wait // 重启N_Bs定时器继续等 ctx-txTimer N_BS_TIMEOUT; } else if (fs 2) { // Overflow // 中止发送通知上层 ctx-txState CANTP_TX_IDLE; PduR_TxConfirmation(channel, E_NOT_OK); } }发送连续帧void CanTp_SendContinuousFrames(uint8_t channel) { CanTp_TxContext *ctx txContext[channel]; uint8_t count 0; while (ctx-txOffset ctx-txLength) { if (ctx-txBS ! 0 count ctx-txBS) { // 发完一个块等下一个FC ctx-txState CANTP_TX_WAIT_FC; ctx-txTimer N_BS_TIMEOUT; return; } uint8_t frame[8]; frame[0] (0x2 4) | (ctx-txSN 0x0F); uint16_t remaining ctx-txLength - ctx-txOffset; uint8_t payload (remaining 7) ? 7 : remaining; memcpy(frame[1], ctx-txBuffer[ctx-txOffset], payload); if (payload 7) { memset(frame[1 payload], 0, 7 - payload); // 填充 } CanIf_Transmit(channel, frame, 8); ctx-txOffset payload; ctx-txSN (ctx-txSN 1) 0x0F; if (ctx-txSN 0) ctx-txSN 1; // SN从1到15循环 count; // 按STmin延时 if (ctx-txSTmin 0 ctx-txSTmin 0x7F) { DelayMs(ctx-txSTmin); } } // 发送完成 ctx-txState CANTP_TX_IDLE; PduR_TxConfirmation(channel); }5.3 接收流程的代码骨架接收端的核心逻辑void CanTp_RxIndication(uint8_t channel, uint8_t *data, uint8_t length) { CanTp_RxContext *ctx rxContext[channel]; uint8_t pciType (data[0] 4) 0x0F; switch (pciType) { case 0x0: { // 单帧 uint8_t sfLength data[0] 0x0F; memcpy(ctx-rxBuffer, data[1], sfLength); PduR_RxIndication(channel, ctx-rxBuffer, sfLength); break; } case 0x1: { // 首帧 uint16_t ffLength ((data[0] 0x0F) 8) | data[1]; if (ffLength sizeof(ctx-rxBuffer)) { // 缓冲区不够发Overflow CanTp_SendFlowControl(channel, 2, 0, 0); return; } ctx-rxExpected ffLength; ctx-rxLength 6; memcpy(ctx-rxBuffer, data[2], 6); ctx-rxSN 1; ctx-rxState CANTP_RX_WAIT_CF; ctx-rxTimer N_CR_TIMEOUT; // 发送CTS流控帧 CanTp_SendFlowControl(channel, 0, ctx-rxBS, ctx-rxSTmin); break; } case 0x2: { // 连续帧 if (ctx-rxState ! CANTP_RX_WAIT_CF) return; uint8_t sn data[0] 0x0F; if (sn ! ctx-rxSN) { // 序列号错误中止 ctx-rxState CANTP_RX_IDLE; return; } uint16_t remaining ctx-rxExpected - ctx-rxLength; uint8_t payload (remaining 7) ? 7 : remaining; memcpy(ctx-rxBuffer[ctx-rxLength], data[1], payload); ctx-rxLength payload; ctx-rxSN (ctx-rxSN 1) 0x0F; if (ctx-rxSN 0) ctx-rxSN 1; ctx-rxTimer N_CR_TIMEOUT; if (ctx-rxLength ctx-rxExpected) { // 接收完成 PduR_RxIndication(channel, ctx-rxBuffer, ctx-rxExpected); ctx-rxState CANTP_RX_IDLE; } else if (ctx-rxBS ! 0 (ctx-rxSN % ctx-rxBS) 1) { // 收到一个块发下一个FC CanTp_SendFlowControl(channel, 0, ctx-rxBS, ctx-rxSTmin); } break; } case 0x3: { // 流控帧 CanTp_RxFlowControl(channel, data); break; } } }5.4 定时器管理的实现要点定时器管理是CanTp实现里最容易出bug的地方。我的做法是用一个周期性的任务比如1ms调用一次来递减所有定时器void CanTp_MainFunction(void) { for (int i 0; i CHANNEL_COUNT; i) { if (txContext[i].txTimer 0) { txContext[i].txTimer--; if (txContext[i].txTimer 0) { // 超时处理 CanTp_TxTimeout(i); } } if (rxContext[i].rxTimer 0) { rxContext[i].rxTimer--; if (rxContext[i].rxTimer 0) { // 超时处理 CanTp_RxTimeout(i); } } } }超时处理要区分状态如果发送方在等FC时超时应该中止发送并通知上层如果接收方在等CF时超时应该丢弃已接收的数据并回到空闲。提示定时器的递减周期决定了定时精度。如果MainFunction是10ms调用一次那N_As1000ms实际可能是990-1010ms之间。对CanTp来说这个精度足够了但如果你的系统对时间敏感可以用1ms周期。6. 调试实战从现象反推问题的排查链路6.1 诊断请求发不出去从上层往下查现象诊断仪发送请求ECU无响应总线上看不到ECU的回复。排查链路确认CanTp是否收到请求在CanTp的RxIndication里打断点或加日志。如果没收到问题在CanIf或更底层。检查CanIf的接收过滤确认CAN ID是否在接收过滤列表里。很多CanIf配置默认只接收特定ID诊断ID需要单独添加。检查CanTp的通道配置确认Rx通道的寻址模式、CAN ID、N-PDU长度是否正确。确认PduR路由CanTp收到数据后要经过PduR路由到Dcm。如果PduR配置里没有对应的路由表数据会被丢弃。我遇到过一次CanTp配置全对但PduR的路由表里诊断PDU的目标模块写成了Com而不是Dcm结果诊断请求被路由到了通信模块Dcm根本收不到。6.2 多帧传输中途卡死流控帧去哪了现象单帧诊断正常多帧诊断发到一半卡住发送方一直等FC。排查链路抓总线报文确认首帧是否发出接收方是否回了FC。如果接收方没回FC检查接收方的缓冲区是否够用。如果首帧声明的长度超过接收方缓冲区接收方会回Overflow而不是CTS。如果接收方回了FC但发送方没收到检查FC的CAN ID是否正确。FC应该用接收方的发送ID也就是发送方的接收ID。如果FC收到了但发送方没继续发检查FC的FS字段。FS1Wait时发送方应该继续等FS0CTS才继续发。有些实现把FS解析错了把Wait当成了CTS。我踩过的一个坑FC的STmin设成了0xF1。按照标准0xF1-0xF9表示100-900微秒。但我的发送方实现只支持毫秒级遇到0xF1直接当成了241ms0xF1241导致发送速度极慢诊断仪等不及超时了。后来改成只发0x00-0x7F范围内的STmin问题解决。6.3 序列号错误导致重组失败现象多帧传输到某个CF时突然中止接收方丢弃了所有数据。排查链路检查SN递增逻辑SN从1开始每发一个CF递增1到15后回绕到0然后下一个是1。注意0是跳过的。检查SN回绕有些实现回绕时从15直接到0但标准要求0之后是1。如果接收方期望1但收到0会判定SN错误。检查BS边界如果BS4发送方发完4个CF后要等FC。如果发送方发了第5个CF接收方可能因为状态不对而丢弃。注意SN错误是CanTp里最隐蔽的bug之一。因为单帧测试永远正常只有多帧且长度超过一个BS块时才会暴露。建议在开发阶段就用长报文比如200字节以上做压力测试。6.4 定时器超时引发的连锁反应现象诊断偶尔失败重试又正常没有规律。排查链路检查N_Bs和N_Cr是否设得太小如果总线负载高FC或CF的传输可能延迟。N_Bs1000ms通常够用但如果接收方处理慢可能需要加大。检查MainFunction的调用周期如果MainFunction被高优先级任务阻塞定时器递减会延迟导致实际超时时间比配置的长。检查是否有中断竞争CanTp的RxIndication通常在中断上下文里调用如果MainFunction也在操作同一个上下文需要加锁保护。我的经验是定时器超时问题优先怀疑MainFunction的调度。如果MainFunction不是周期精确调用的定时器就不准。可以在MainFunction里加一个计数器统计实际调用间隔确认是否稳定。7. 配置参数速查与常见错误对照7.1 关键配置参数一览参数含义典型值注意事项CanTpRxDl接收N-PDU长度8或64CAN FD必须设64CanTpTxDl发送N-PDU长度8或64同上CanTpRxBufferSize接收缓冲区256-4096按最大诊断报文评估CanTpTxBufferSize发送缓冲区256-4096刷写场景要加大N_As发送超时1000ms本地发送通常够用N_Bs等FC超时1000ms接收方慢时加大N_Cr等CF超时1000ms发送方慢时加大BS块大小0或80表示不限8是常见值STmin最小间隔10ms避免用保留值7.2 常见错误与解决方案现象可能原因解决方案单帧正常多帧失败流控帧配置错误检查FC的CAN ID和FS字段诊断响应不完整N-PDU长度配置错误CAN FD下设为64偶发超时定时器太小或MainFunction阻塞加大定时器检查调度SN错误SN递增逻辑bug确认0跳过15后回1缓冲区溢出缓冲区太小评估最大报文长度加大缓冲区功能寻址无响应功能寻址不支持多帧功能寻址只用单帧7.3 实测中的经验技巧技巧一用CANoe的TP面板辅助调试。CANoe有专门的CanTp解析功能能把原始CAN帧解析成SF/FF/CF/FC直观看到传输流程。比自己手动解析十六进制高效得多。技巧二在CanTp里加状态日志。每个状态转换都打一条日志包括时间戳、通道、状态、SN、剩余长度。出问题时看日志就能定位到具体哪一步卡住。技巧三先用短报文验证基本流程再用长报文压测。短报文比如10 02走单帧验证链路通不通。长报文比如22 F1 90的响应走多帧验证分段重组和流控。最后用超长报文比如刷写数据验证边界条件。技巧四注意字节序。首帧的长度字段是大端高字节在前但有些实现会搞反。如果接收方解析出的长度是乱值先检查字节序。技巧五STmin不要设0。虽然标准允许STmin0但实际中发送方连续发帧可能导致接收方来不及处理。建议至少设1ms给接收方留出中断处理时间。8. 从CanTp延伸到诊断栈的整体理解CanTp只是诊断栈的一环单独调通它不代表诊断功能就完整了。往上还有Dcm诊断通信管理负责会话管理、安全访问、DTC读取等再往上还有Dcm的应用层回调需要项目自己实现。我见过有人CanTp调通了但Dcm的会话状态机没配对诊断仪发10 03进入扩展会话后ECU回了肯定响应但后续的27 01安全访问却返回了否定响应原因是Dcm的安全状态没跟着会话切换。这类问题不在CanTp层但现象看起来像是CanTp的问题。所以调试诊断功能时建议分层排查先确认CanTp层能正常收发再确认Dcm层能正确解析和响应最后确认应用层的回调逻辑正确。每一层都加日志出问题时看日志定位到具体哪一层。另外CanTp的性能直接影响诊断速度。如果STmin设得太大刷写一个大文件可能要几十分钟。优化方向包括加大BS减少流控交互、减小STmin提高发送频率、使用CAN FD减少帧数。但优化时要平衡可靠性和速度不能为了快而丢帧。最后说一个我自己的体会CanTp的难点不在协议本身而在调试。协议就那么几种帧、几个状态、几个定时器看两遍标准就能理解。但实际调试时问题往往出在配置、集成、时序这些非协议的地方。所以与其花时间背协议细节不如把调试工具和日志做好让问题自己暴露出来。
