网络基础扫盲篇1

“为什么用户报障节点丢包，从网关测试丢包IP不丢包？

为什么用户反馈tcpping loss比较高，icmp ping不见异常？

为什么用户反馈节点ICMP不通，ssh能正常登陆？

为什么我下载速度忽快忽慢？

为什么cdn节点用户server端无异常log但客户端失败率增加?”

这些貌似奇葩的问题想必每一个运维都曾遇到过。有些同学遇到这种问题直接将case给用户打回去，粗暴的回答，网络无故障，静默处理。诚然很多时候网络故障就像烦人的小妖精，不需要去搭理，睡了一觉可能就赌气走掉了。那么遇到不是那么Nice的大客户该怎么破呢？还有些同学看到这些问题会会心一笑，那么可以翻下去咱们可以相互印证一下。

在阐明上述问题之前，我们需要对ICMP以及TCP的协议层次和报文格式有最基本的了解。进而了解它们是如何在网络设备中传递的。

见图：

Note: ICMP虽说和IP层在一个级别，但是在数据传递中，也是需要IP来承载寻址的。

见图：

在这个文章里面， 我们暂不需要深入挖掘icmp类型代码。 TCP报文格式也仅需要的稍微多了一点， 即作为四层报文，比ICMP多了两个元素，源端口和目的端口。

显而易见ICMP和TCP的差异：在两种IP报文传输的过程中，ICMP报文，在网络设备传输过程中哈希元素只有三种：源IP，协议类型，目的IP。源IP就是发起ping请求的IP，协议自然是ICMP，然后是目的IP。所以譬如我们通过ping/mtr发送ICMP请求的时候，三元组是固定的。源IP协议类型以及目的IP不可能在发起请求的过程中发生变化。

而TCP则不全然。作为网络传输过程中的五元组，源IP源端口目的IP和目的端口以及协议虽然不会在单个会话传输过程中发生变化。但是真实的业务请求不像icmp一样维持一个长连接，长连接这个词不太恰当,更确切的说，用ICMP在监控的时候，对于目标设备而言，收到的ICMP请求是唯一的固定的三元组。而真正在作四层或者七层监控的时候，纵使保持监控设备IP的唯一性，每次tcp建连五元组中的源端口也会随机变化。源端口一般为大位非知名随机端口，目的端口或因业务不同而有差别，常用的有22 80 443 1935等。

那么网络设备是如何转发这些常见报文的？

基本原理：流量在网络设备中的转发是基于底层的FIB表项哈希转发。在进行负载分担的设定的时候网络设备的命令行一般可以选定流量分担模式SIP、DIP、SIP+DIP、SIP+DIP+SP+DP， 这些模式均有其对应的HASH算法， 网络设备根据需负载分担端口组成员生成哈希表。流量在转发时候通过哈希表现找到对应的出端口将报文转发出去。 如下表10G口1和10G口2做聚合，交换芯片上哈希index可保证流量尽量均衡。 对于路由接口负载均衡亦然。 所以， 交换机路由器只能控制其output方向的流量，intput的负载均衡需和局方协商。哈希并非万能的，在特殊业务模型下，流量也会极化到某单条接口上， 也会导致单端口打满的情况。 导致业务有损。

结合真实线上业务情况，去除协议这个固定无关选项，如果基于哈希的某端口的流量转发失效，我们会发现：

对于ICMP而言，部分IP不通。 Ping监控异常，如Ping一个IP不通， 或许换另一个源IP ping就通了。

对于TCP而言， tcp建连会有稳定的概率性的超时的情况。

产生转发失效的原因很多：

Case 1:（路由无关）如果接口状态出现异常，而路由表项， 或FIB表项未正常刷新, 导致流量无法正常转发， 造成业务有损。

Case 2:（路由无关）接口状态正常，但传输或者中继异常，接口未正常从成员组剔除，造成业务有损。

Case 3:通常发生在新上资源或网络变更， 路由聚合异常， 掩码与实际网络不匹配造成流量丢弃。

Case 4:资源冗余出口有严格的单播反向路由查找配置 strict uRPF, 非对称路径导致合法报文丢弃。

及其他。

那么解释一下为什么ping包会出现部分通部分不通的情况:

我们先设定一个场景，因现在的IDC带宽都比较大，譬如我接入交换机10个10G上联做负载均衡且分别接入两个IDC的主备接入交换机。我们假设每一组算一个故障因子。那么设备在做负载均衡的时候的时候就是10个故障因子，这还是在不考虑IDC出口以及大网的负载型的情况下， 那么如果一个故障因子生效，那么网络就部分不通， 无论是ICMP和TCP都会出现1/10比例部分不通的情况（或许更多）。

因为ICMP的流量哈希在每个网络设备上的哈希状态是固定的， 所以一旦match到这个故障链路， 就会百分之百不通。而tcp流量因为大多网络设备为了保持流量均衡，多采用五元组哈希， 在监控IP不变源端口随机的情况下出现建连失败的情况均是概率性出现。这也解释了为什么业务运维提供了不通的IP，报障节点失败率增加， 而网工们无法有效的定位到故障链路， 并对报障情况存疑。因为网络工程师多用网关IP或互联IP进行测试，源IP改变之后到不通的那个IP未必会哈希到了故障的链路/接口。

人们总是倾向于自己愿意相信的， 而总有一些我们不相信的故障在我们看不到的地方发生。

如果再扩散一下Case 1 &2，换成哈希接口有误码或者error包呢？好多问题顿时也有了答案。如报障的同学把丢包的IP提供了，但网工说ping这个IP不丢。报障的同学反馈下载慢，网工说是不是你资源的问题。

一个躺在系统底端故障里面痛不欲生，一个站在网络管道的上帝视角却茫茫然不知所措。