蚂蚁网-多维人生，三实而立！

HTTP chunked编码异常导致业务下载附件慢故障案例

作者：易隐者 发布于：2012-12-18 9:32 Tuesday 分类：案例讨论

故障现象

       某业务应用系统基于B/S架构开发，其应用页面打开正常，但是该应用在下载附件时，速度非常慢。

故障分析

       在下载附件很慢时，在服务器上捕获客户端与服务器业务交互的报文。其TCP会话交互的情况如下图所示： 

       我们首先分析客户端与服务器三次握手建立连接的情况，查看客户端、服务器协商的MSS值是否正常，我们首先查看客户端SYN报文，其TCP MSS协商为1460，如下图所示： 

       接下来查看服务器SYN/ACK报文，其TCP MSS也为1460，如下图所示： 

       这说明双方协商的MSS值不存在问题，另服务器对客户端的get请求的第一个应用响应报文长度为248B，如下图所示： 

       这也充分说明业务服务器在给客户端发送报文时并不是一直只能发送9字节的报文。那么是什么原因导致业务服务器突然之间只能每次发送9字节的应用层数据呢？

       我们注意到服务器给客户端的第一个HTTP应用响应报文，如下图所示： 

        其Transfer-Enconding是chunked。

        HTTP为什么会使用chunked传输编码？我直接引用《HTTP1.1中CHUNKED编码解析》一文中的描述来说明：“一般HTTP通信时，会使用Content-Length头信息性来通知用户代理（通常意义上是浏览器）服务器发送的文档内容长度，该头信息定义于HTTP1.0协议RFC  1945  10.4章节中。浏览器接收到此头信息后，接受完Content-Length中定义的长度字节后开始解析页面，但如果服务端有部分数据延迟发送吗，则会出现浏览器白屏，造成比较糟糕的用户体验。
        解决方案是在HTTP1.1协议中，RFC  2616中14.41章节中定义的Transfer-Encoding: chunked的头信息，chunked编码定义在3.6.1中，所有HTTP1.1 应用都支持此使用trunked编码动态的提供body内容的长度的方式。进行Chunked编码传输的HTTP数据要在消息头部设置：Transfer-Encoding: chunked表示Content Body将用chunked编码传输内容。根据定义，浏览器不需要等到内容字节全部下载完成,只要接收到一个chunked块就可解析页面.并且可以下载html中定义的页面内容,包括js,css,image等。”

        “Chunked编码一般使用若干个chunk串连而成，最后由一个标明长度为0的chunk标示结束。每个chunk分为头部和正文两部分，头部内容指定下一段正文的字符总数（非零开头的十六进制的数字）和数量单位（一般不写,表示字节）.正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的chunk中的内容是称为footer的内容，是一些附加的Header信息（通常可以直接忽略）。”

       《HTTP1.1中CHUNKED编码解析》一文中使用了下图作为chunked解码的示意： 

       通过这张示意图，我们可以清晰的了解到，chunked解码主要由2块组成，一块为指定数据块长度，以\r\n回车换行作为结束符，另一块为实际的应用数据，也以\r\n回车换行作为结束符。
       知道了chunked解码的组成，我们再来看看业务服务器给客户端发送的应用层长度仅9字节的报文解码： 

       根据这9个字节的应用字段解码，我们将其十六进制换算为正常的十进制，如下表所示：

        我们根据上图即可解码服务器发往客户端的chunked编码报文，其意义为：
1，指明长度为0001，即为1字节；
2，该报文真正的应用数据仅为1字节的“R”！

       服务器每次仅传输一个字节给客户端！其报文的有效载荷率仅为：   1/63=0.015873015873015873015873015873016！
       如果客户端下载一个1MB大小的附件，服务器端将产生1*1024*1024=1048576个报文，如果客户端每个报文都确认的话，一个下载将产生1048576次交互，即使往返时间RTT值非常小，再乘以1048576的基数之后，也将是个难以接收的数值。
       如此，我们终于明白下载附件慢的原因了。

分析结论

       此为业务服务器HTTP chunked编码传输时，自己指定的数据块长度值太小（为1字节）导致的故障。

参考文档

1，《HTTP1.1中CHUNKED编码解析》
2，RFC 2616《超文本传输协议》

阅读全文>>

标签: 疑难故障 MSS RTT 往返时间 HTTP chunked编码 交互次数

评论(3) 引用(0) 浏览(12042)

由TCP保活引起的业务访问故障案例

作者：易隐者 发布于：2012-12-7 15:18 Friday 分类：网络分析

1 故障环境

1.1  故障拓扑

       故障发生的网络拓扑结构如下图所示： 

1.2  业务报文交互路径

1，客户端通过网闸映射地址218.X.X.151访问内部业务服务器10.X.X.209；
2，客户端经过网闸后，源地址变为网闸内口地址10.X.X.160访问真实的业务服务器。

2  故障现象

       故障现象主要表现为：
 客户端访问业务服务器出现中断现象，并且故障基本都发生是在夜间12点以后；
 第二天重启网闸后，业务访问恢复正常，但是到夜间12点左右业务连接会再次中断；
 在业务访问出现中断以后，偶尔会不定时的可以成功进行连接，但是持续时间不长就再次中断；
 仅此业务应用存在这个异常，其他的业务基本正常。

3 故障分析

3.1 分析思路

       考虑到故障都发生在夜间12点左右，因此在网闸内外网口同时部署网络分析产品，对内外网口交互的报文进行长时间的捕获存储，第二天，我们分别选取故障发生时间内的报文进行关联分析和对比分析。

3.2 分析过程

3.2.1 异常出现时，网闸外口的报文交互情况
       我们选取故障发生时，网闸外网口的交互报文进行查看，我们在“TCP会话”视图中，发现了大量交互报文少、流量小、收发报文特征明显的TCP会话，如下图所示： 

       我们选取其中任意一个TCP会话，查看其详细的报文交互情况，如下图所示： 

       我们可以清楚地看到，客户端与服务器映射的外网地址通过三次握手建立TCP连接之后，服务器映射地址立即向客户端发送了FIN报文，主动释放TCP连接，后续的带有应用字段的客户端报文到达后，服务器直接向客户端回应RST报文。
       我们查看了其他的TCP会话的详细报文交互情况，基本与上述情况一样。由此来看，似乎是网闸主动发送FIN报文导致了业务应用出现异常，网闸为什么会在已经建立三次握手之后立即主动发送FIN报文呢？难道是服务器主动发送的FIN报文？或者是网闸的BUG导致网闸主动发送FIN报文？我们需要在内网端做个关联对比分析才能确定。

3.2.2 在网闸内口发现保活报文
       当我们取故障时内网的报文时，发现内网在做捕包存储时出现异常，抓包工具在故障出现之前崩溃了，并未将故障发生时的网闸内口报文捕获保存下来，而由于时间紧急，我们没有机会再花费一天的时间去捕获内网的报文，这些故障现场的不确定性现象发生了，我们只能抓取当下的网闸内口报文进行辅助分析。
       我们在网闸内网口抓包发现大量的特征明显的TCP会话，如下图所示：

       这些TCP会话仅有几个报文的交互，不像正常的业务数据交互报文，我们选择其中一个TCP会话查看其具体的交互报文，如下图所示： 

       这是服务器发给客户端的报文，下面是客户端给服务器的报文： 

       结合这两个报文，我们可以肯定，这是一个TCP保活报文。这些仅交互2个报文的TCP会话是服务器发给客户端的TCP保活行为！

3.2.3合理推测
       这些数量众多的保活行为的TCP会话，引起了我们的关注，那么是否是保活行为导致业务应用出现问题呢？保活的功能之一是维持已有TCP连接，关于TCP保活的详尽描述大家可参考我博客的文章《TCP保活（TCP keepalive）》。
       TCP保活的这个特性很自然的让我们想到可能是TCP保活功能引起网闸连接表满从而导致业务异常。但是网闸作为一个网关类设备一般都支持几十万甚至数百万的连接数，在无异常攻击报文的情况下不至于24小时连接表就全部满了，并且也只有这个业务应用出现异常，其他应用都是正常的。
       我们发现外网的客户端访问到内网时，其源地址全部转换为网闸内口地址10.X.X.160，至此我们恍然大悟：源IP、源端口、目的IP、目的端口、协议类型等五元组信息决定一个连接，而在网闸内口，源IP、目的IP、目的端口、协议类型都已经确定，只有源端口是变换的，而端口范围只能在0-65535之间，还要去除一些常用的端口，如此一来，网闸内口跟服务器之间能够建立的TCP连接数只能在65535以内！
       在这种情况下，客户端访问业务服务器的TCP连接在24小时内达到近65535个，从而导致后续的客户端与业务服务器无法正常建立连接，引起业务访问故障。
       至于故障后又能偶尔连接正常但很快再次异常的原因也很好解释，那就是网闸内口在维护如此众多的连接时，总会由于各种原因导致几个连接异常释放，如此一来则紧接着的业务访问连接会正常建立，但是一旦用完为数不多的几个连接后，后续的业务连接将再次出现异常。
       整个交互过程涉及到的客户端、网闸外口、网闸内口、服务器的状态变化如下图所示： 

3.2.4验证
       我们建议用户在下班后手动清空网闸内口已有连接，观察夜间12点故障是否出现来验证我们的推测。后经用户反馈，在清空连接后夜间12点左右故障未再现，如此充分证明我们上述的推测是正确的。

3.3 分析结论

       服务器端设置了TCP保活功能，对所有的TCP连接主动实行TCP保活探测，这导致网闸内口与服务器建立的TCP连接无法得到释放，在24小时以内，TCP连接数接近65535个，而此时客户端再次发起与服务器之间的业务连接之后，网闸内口已经无法再与服务器新建TCP连接，如此导致业务连接无法建立。

4 故障解决

       在找到导致此业务故障的真正原因之后，我们就可以对症下药，通过任意选择如下几种方式之一来彻底解决这个故障：
1， 可以在服务器上关闭TCP保活功能；
2， 在网闸内口关闭源地址转换（SNAT）功能；
3， 将网闸内口TCP连接释放时间调整至小于服务器发送TCP保活的间隔时间，这样可以在服务器发送保活报文之前，让网闸内口提前释放该连接；
4， 网闸内口使用TCP连接复用功能，让大部分的外网客户端访问连接仅通过少量的内部连接实现正常的业务交互，而服务器则可以与网闸内口之间少量连接保持保活。

阅读全文>>

标签: 疑难故障 五元组 连接表 TCP保活 TCP keepalive 连接复用 网闸 SNAT

评论(0) 引用(0) 浏览(6472)

更换设备后业务访问故障案例

作者：易隐者 发布于：2012-12-5 19:18 Wednesday 分类：网络分析

故障环境

网络拓扑

       故障环境下的拓扑结构如下图所示： 

1，分公司与中转区域通过互联网建立VPN隧道；
2，中转区域通过专线与总部业务服务器区域互联；

业务访问流程

       中转区域机器通过专线直接访问总部业务服务区域的服务器，而分公司则先通过互联网与中转区域建立VPN隧道，经中转区域CISCO VPN设备后，再访问总部业务服务区域的服务器。

故障现象

       此次故障现象主要表现为：
1，分公司只有极少数机器可以正常访问总部的业务服务器，绝大部分机器都不能访问总部的服务器；
2，中转区域全部无法正常访问总部业务服务器；
3，出现上述故障现象时，使用ping命令做连通性测试，都是正常的，无较大延时也无丢包现象；
4，上述现象发生在中转区域更换新的CISCO VPN设备之后，使用以前老的CISCO VPN设备未出现任何问题；
5，新的CISCO VPN设备的配置是从老设备上的配置导入的，因此可以肯定配置完全一致。

故障分析

1 分析过程

       根据故障现象以及前期的测试情况来看，该故障属于业务应用故障，我们认为站在数据报文交互的角度进行分析比单纯猜测和毫无根据的做各种测试更有效率。

 故障重现
       我们首先选择一台IP地址为10.18.3.22的机器作为测试机，并在测试机器上使用IE浏览器访问10.3.3.21服务器，以便在故障现象出现时，我们捕获测试机与服务器业务交互的报文。

近故障点抓包，分析交互过程
       考虑到服务器端在总部，在服务器近端抓包难度很大，我们决定先在客户端近端抓包。
在测试机访问服务器故障重现时，我们在测试机近端捕获了测试机与服务器间的业务交互报文，如下图所示：  

测试机与服务器的交互报文
 
对应的TCP数据流图

       通过对这个报文交互过程的分析，我们发现，测试机与服务器的TCP三次握手建立连接正常，客户端向服务器发送“GET”请求也正常，问题出现在服务器给测试机的响应报文，我们在测试机近端抓包，只看到了服务器向客户端发送的28字节的报文，而我们通过该TCP报文的Seq=1433可以计算出，在这个报文之前，还有一个载荷长度为Len=1433-28-1=1404字节的TCP报文未正常到达测试机。测试机在等待45秒后，由于一直未收到该报文，其主动向服务器发送FIN报文，正常释放了这个TCP连接。
       纵观整个过程，我们可以自然的得出结论：服务器端的报文在网络中被中间设备丢弃，导致了故障的产生。
一般而言，偶尔丢包是正常的，TCP会通过重传机制，保证应用正常交互，但是在这个故障交互的报文中，我们仅看到有报文被丢弃，并且这个报文在45秒的时间内，一直未到达测试机，这不符合TCP重传的工作机制，只有一种情况可以解释这种现象，那就是这个一直未到达测试机的报文，其原始报文和重传报文都被中间设备丢弃了。
       结合故障现象是在更换为新的CISCO VPN设备后出现的，我们很自然的想到，应该是新更换的CISCO VPN设备丢弃这个报文。那么CISCO VPN设备并未做特殊的设置，一般不会丢弃特定报文，联想到这个被丢弃的报文应用字段长度为1404字节，加上20字节的TCP报头和20字节的IP报头，其IP报文长度应该有1444字节，是否有可能是其超出了CISCO VPN设备的某些接口的MTU呢？
       对CISCO VPN设备的特性并不了解，那么我们还是做一个简单的测试，验证我们的分析和推论是否正确。

验证
       将测试机网卡的MTU值修改为1400之后，再次尝试通过IE访问总部的服务器，访问完全正常，下面为修改MTU值之后的测试机与总部服务器之间正常交互的报文： 

       上述正常交互的报文，充分验证了我们前面的推论。

2 分析结论

       老CISCO VPN设备的tunnel接口MTU等属性并没有保存在配置文件里，因此虽然将老设备的配置直接导入到新设备中，但是新更换的CISCO VPN设备VPN tunnel接口MTU较小，导致服务器发给客户端的TCP大包报文被丢弃，引发业务访问故障的产生。
       而分公司极少数机器在更好新设备后仍然能够正常访问服务器，是因为这些机器本身网卡的MTU值较小，因此虽然新的设备上线，但并不影响这些机器对服务器的正常访问。

故障解决

      调整CISCO VPN设备相关tunnel口MTU值，此故障解决。

阅读全文>>

标签: 疑难故障 丢包 MTU VPN

评论(0) 引用(0) 浏览(5019)

【转】上网认证页面无法打开案例

作者：易隐者 发布于：2012-11-25 10:40 Sunday 分类：案例讨论

【说在之前】：

1，该案例的确属于疑难故障范畴，若不是通过抓包方式，站在数据包交互的角度进行分析是无法定位、解决该故障的，因此，该案例具有学习参考价值；

2，案例的分析用到了关联分析法和对比分析法，思路非常清晰，但整个文档在图文编辑和措词这块还可以做进一步的加强，考虑到原文的完整性，我不对该文档做任何修改；

3，难能可贵的是作者在找到故障原因并解决故障之后，没有像大部分人那样将这个故障束之高阁， 而是将自己的分析思路、过程整理成文档，分享给大家，另外，发现其中难以解释的、存在疑问的地方，供大家一起讨论，这正是我一直倡导的“自我总结、无私分享、共同探讨、共同进步”的学习方式；

4，针对该案例后面的疑问，我就我的理解作出相关解答，供大家参考。

     针对第一个疑问：AC在此处工作在透明模式下，正常情况下其对报文的干预和处理根本不需要经过路由，也就是说，AC在做HTTP重定向的时候，根本不需要根据路由表，将这个HTTP重定向报文转发给PIX防火墙，而应该直接构造相应HTTP重定向报文发往核心交换机，因此，此处出现这样的问题，我个人认为如果AC是按照路由方式处理的话，其应该有相应的转发表，转发表中会有下一跳、转发接口等相关信息，而出现此案例中的问题，说明AC的转发表出现了异常，可能是其上联口和下联口是属于同一网段，而AC转发表未对其进行区分导致的；

     针对第二个疑问：这里需要明确，AC的管理口和业务口是否是完全独立的，如果是，那么所谓的两条默认路由是完全分开的，没有任何问题，如果不是，那么根据不同的系统处理方式，负载均衡（根据报文或其他）或者选择其中一条都是有可能的，多年前我曾写过一篇《供电局调度所前置机故障解决说明》的文档，就是两条默认路由导致异常的案例，过段时间我把这个案例共享到我的博客供大家参考。

5，该案例作者肖鉴为我以前推出《合肥网络分析技术团队招募学徒》的第一个学员。他不远千里从福建专程请假几十天跟随我学习相关知识，当我第一眼看到他时，我就被他的这种对技术执着追求的行为所感动，他基础不错，学习踏实认真，我个人认为我真正给他的帮助不在于具体技术的成长和进步，而在于影响他对技术的自信、清晰的职业发展方向规划以及行事的风格，在他身上我能看到我以前的影子，他现在深信服的总代，刚获得深信服深信服华南区技术大比武冠军，看到他的成长，我的内心是无比的欣慰。

【原文全文】

1. 网络环境

        故障网络环境如下图所示： 

说明：
1． 出口防火墙工作在路由模式做NAT代理内网上网，E1口IP地址192.168.247.1/24。
2． 上网行为管理工作的网桥模式下，为其网桥IP地址配置192.168.247.3/24、网关IP地址为192.168.247.1用于设备管理，下联三层交换机IP地址为192.168.247.2/24。由于，前置PIX防火墙为阻止192.168.247.0/24网段上网，所以为了上网行为管理能够更新内置规则库，上网行为管理口下联三层核心交换机为其配置IP地址192.168.20.250网关IP地址192.168.20.1。
3．上网行为管理对内网部分网段实行认证上网。

2. 故障现象

       内网无须进行认证PC机访问互联网正常，需进行认证网段PC机上网在正常情况必须得先进行认证输入用户名和密码后方可访问互联网，故障表现为认证网段PC机无法正常跳转至认证界面输入用户名和密码。如下图所示： 

3. 故障分析

3.1 常规分析

       在PC上访问网络时无法跳出登陆界页时，我们手动输入http://192.168.247.3认证登陆页面是正常，如下图所示，并且，输入完认证用户名和密码后可以正常访问互联网。说明网络中并不存在路由问题。那么是否可能是设备本身处理机制出现问题呢？还是，PC机与上网行为管理设备通信出现了其它的异常导致PC机无法正常弹出认证页面？。 

阅读全文>>

标签: 交换机 团队 疑难故障 TCP 网络分析 负载均衡 抓包 深信服 上网行为管理 HTTP重定向 AC 路由表 转发表

评论(0) 引用(0) 浏览(13221)

某业务系统由于连接数限制导致间歇性访问慢故障分析案例

作者：易隐者 发布于：2012-9-26 18:05 Wednesday 分类：网络分析

【说在之前】：

1，该案例为端系统设置连接数限制导致的应用间歇性缓慢故障，在实际工作环境下，我们更容易遇到的是中间系统对连接数限制导致的一些范访问异常，令人头疼的是，并不是所有开启连接数限制功能的中间系统在丢包后都会向源主机发送ICMP差错报文，这会给大家分析定位带来难度，大家在实际工作中需要留意；

2，该案例涉及到的知识点主要为“ICMP主机管理性禁止差错报文”和“连接数限制”，关于ICMP主机管理性禁止差错报文，大家可参考本博客《ICMP通讯管理性过滤禁止差错报文（type 3，code 13）》一文，虽然“type 3，code 10”与“type3，code 13”有些差异，但是差别不大，可以借鉴；关于连接数相关知识点，大家可参考本博客《连接数相关知识》一文；

【我的案例】：

1 故障环境

网络拓扑：

说明：
1，内部办公机器都是192.168.1.0/24段的，内部办公主机通过防火墙做NAT，转换为X.X.X.138访问互联网；
2，内部办公服务器的地址为192.168.1.191，其通过防火墙映射为公网地址X.X.X.139对外提供6888端口的web服务。
业务访问流程：
       内部办公机器都是通过NAT后的公网地址X.X.X.138访问办公服务器的公网地址X.X.X.139。其流程如下图所示： 

2 故障现象

       故障现象主要表现为：
1，部分内网办公主机经常出现打开主页慢、登录慢或者某些页面不显示的情况，如下图所示： 

打开主页时的长时间等待页面截图 

登录时长时间等待页面截图

2，这些故障现象间歇性出现，有时多刷新几次页面后，打开的速度会恢复正常。
3，外网用户访问业务系统一直正常，该故障已经持续数月。

3 故障分析

       通过故障现象，我们可以看出，这是比较典型的部分系统出现问题的案例，由于其不具备全体的故障特征，又是间歇性的发生，因此，此类故障按照常规的分析方法很难找到真正的故障原因，我们还是先在客户端抓取一下故障时交互的数据包，站在数据包的角度来分析一下可能的原因。
1，找一台出现故障的主机192.168.1.167，捕获其打开主页面缓慢时的数据包。
2，查看缓慢时的数据交互情况，如下图所示： 

       我们通过delta tima值可以看到，这个交互的过程存在较大的延时，并且我们发现，在交互的过程中存在数个“ICMP主机通讯管理性禁止”的差错报文，这些报文都是X.X.X.139发给故障主机192.168.1.167的。
3，我们双击其中一个ICMP主机通讯管理性禁止报文，查看其封装的被过滤的原报文相关信息，如下图所示：

       我们发现，被X.X.X.139管理性过滤掉的报文是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文。
4，我们再结合上下数据包交互的情况，我们可以发现，这个ICMP主机通讯管理性禁止报文的前一个报文正是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文，如下图所示： 

       这充分说明当故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求时，被服务器管理性过滤禁止了。
5，那么服务器为什么会管理性禁止故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求报文呢？难道服务器上设有针对源端口为4075的禁止访问策略吗？服务器显然没有做这种针对源端口过滤的必要，另外，我们还发现除了故障主机以源端口4075访问服务器的SYN报文被管理性禁止外，还有其他源端口的SYN请求报文被服务器管理性禁止，如下图所示： 

       这里被服务器禁止的报文的源端口有4078、4083、4086等。
       另外，通过上图中的“delta time”值，我们也可以发现正是这些报文导致了故障主机在建立新的TCP连接之前花费了数秒的连接建立尝试时间（SYN重传时间，大家可参考本博客《TCP重传》一文），从而导致了页面打开缓慢的现象出现。
6，这个现象具有明显的针对TCP的随机性的过滤特性，因此，我们很容易就可以联想到是否是服务器在TCP传输层存在某些检测过滤机制？而在传输层最为常见的就是TCP连接数限制了。
       一般而言，在服务器上实现针对单IP访问服务器的TCP连接数进行限制是一件简单的事情，一个独立的IP只允许与服务器建立少量的TCP连接，这对于那些对外提供服务的服务器来说是一种较为常见的防护措施，在正常情况下，单个客户端与服务器的正常交互所需要的TCP连接数并不是很多，而限制的数值一般都会高于正常的需求，但是在有些情况（如经过NAT或代理后对业务的访问）下，这将导致问题的产生。
7， 上述推理非常合理，我们通过检查服务器的相关设置，验证了我们的分析和推论结果。
8， 分析结论：
       这个故障是由于业务服务器端设置了针对单IP访问连接数限制功能，而内部办公网主机都是通过防火墙NAT地址转换后对业务服务器进行访问，这直接导致在业务访问高峰时，出口NAT IP地址访问业务服务器的连接数超出限制，业务服务器对后续的TCP连接建立请求发出ICMP差错报文，等一些TCP连接释放后，才允许新建TCP连接，这导致访问业务系统非常缓慢。并且这种特性决定了故障现象表现为间歇性发生。

4 故障解决

       通过修改服务器Apach对单一IP地址的连接数的限制后，故障得到解决。

阅读全文>>

标签: 疑难故障 TCP icmp差错 SYN 连接数 NAT 地址转换 业务慢 连接数限制 ICMP主机管理性禁止差错报文 Type 3 Code 13 type 3 code 10

评论(2) 引用(0) 浏览(11330)