没有背过黑锅的网工不是好网工，当然是一局自嘲的话。那么网工如何甩锅，甩得潇洒、霸气？
一、技能需求
1.tcpdump&wireshark
二、超时案例分析1
1.某天系统运维收到运营方的投诉：用户访问公司接口出错率太高，运维遍历zabbix，falcon等监控，无异常告警，立即甩锅：系统无异常，应该是网络问题！
时间长了，网络人员是很悲壮的，听到“网络问题”会引起极度不适，研发、系统反馈都无问题，那除了网络还能是什么问题？那么我们就需要证明网络没有问题！
出现问题需要用户侧收集的信息：
用户公网出口，出现异常时刻的mtr截图，异常截图，最好有tcpdump报文
假设外界网络一切都好的前提下，如何快速响应，公司都有防火墙吧？防火墙绝对有，没有防火墙也有nginx吧，在防火墙或者nginx上抓包（最好是通过交换机镜像，有一台服务器时候循环抓包，便于出现问题直接分析），通过tcp的三次握手，我们可以很容易发现会话建立过程中异常，如不回syn,ack报文，不回syn报文，为何突然发送rst报文等等，通过对应时间节点的报文截图，可以直接甩锅了，但是本着大家一起为公司服务，出现问题还是要一起解决的，若是能在多次异常中表现突出，加薪升职指日可待！
tcpdump之后保存的pcap文件用wireshark打开。看到如此庞大的信息有点头疼，别担心，有个简易方法：分析——专家信息
该视图可以很直观的看到报文的统计信息，如上图所示，有不少的syn重传，我们右键过滤tcp的流
很明显，服务器收到syn之后没有回syn,ack导致tcp握手失败，再对应下客户异常的时间，时间一致那就不是网络问题，立马转给系统运维人员，让对方排查为啥不回syn,ack。
其实这是个老生常谈的问题，很多蒙头大干或者研究自动化、开发的运维不太注重内核参数。
linux系统中输入netstat -s|grep reject，若随着时间变化，数字不停地往上冒，那基本定位问题了。
23381 passive connections rejected because of time stamp
3445 packets rejects in established connections because of timestamp
通过调整sysctl -w net.ipv4.tcp_timestamps=0或者sysctl -w net.ipv4.tcp_tw_recycle=0来解决这个问题。
根本原因
用户通过出口（NAT网关只有1个ip地址）访问公司的server，由于timestamp时间为系统启动到当前的时间，所以每个同事的timestamp不相同；根据新内核（2.6以后的）SYN包处理源码，在tcp_tw_recycle和tcp_timestamps同时开启的条件下，timestamp大的主机访问serverN成功，而timestmap小的主机访问失败，由于服务端需要时间戳的功能，常规办法就是把tw_recycle的功能关闭。
三、超时案例分析2
有了案例1也别得瑟，运维同事也在不断学习ing。
第二次发生不定时的超时异常后，运维同事自己先在服务器上抓包，发现收到syn之后已回复syn,ack，那很明显就不是系统问题，立即甩给网络人员，哈哈哈，具体问题具体分析吧。
网络同学也不甘示弱，在防火墙的出口、防火墙的内口分别做流量镜像，并在防火墙debug，通过三处的报文一对比（头发白了好几根），惊现问题根源，锅锅还是运维或研发的，只不过网络人员可以调优帮助他们。
服务器收到syn之后，过了3-5分钟才返回syn,ack报文，这段时间服务器或应用在干啥？（服务器资源，应用什么的都无问题），难以描述，过了3、5分钟才会syn,ack，此时防火墙已经把之前的session清除了，迟来的syn,ack只能丢弃了。延长防火墙默认的会话保持时间后，问题得到99%的解决，运维和研发都松了一口气，以后也不甩锅了。
其实在日常工作中有很多有意思的事件，若是大家在一个很好的氛围中工作，能力可以得到很大的提升！
,
