网络是极其复杂的，这种复杂包含混沌和不确定性，网络是一个典型的复杂系统。然而网络映射到程序员的心里，它只是一条确定的管道！这种思路会带来问题。程序员与运维/网管之间的斗争依然在继续，在这个无休止的争论中，我不断切换着自己的角色，这一次，我将站在程序员的对立面。
从我的故事说起，这些故事我故意打乱了时间顺序，请看到此文的人并且知道这些事的，不要往自己身上映射，纯技术讨论，无关褒贬！
我的故事一：手机访问慢
那是我刚毕业的时候了，在一家小公司做VOIP，我接手了一个Symbian UIQ程序的开发，这是一个联网的程序，经理的意思是，访问一定要快，绝不能慢。需求很明确，几乎所有的网络程序都是这么个需求。我于是就开始了没日没夜的奋战，我刚毕业时发誓要做一个标准程序员，我觉得这是一定可以完成的。然而，事后证明，这往往是程序员的通病。
...
后来我离职了。
因为，我无法做到访问不慢...其实这不是我的错，这是那个手机的错，那个手机买的带宽太低了，那时没有3G，那时只是GPRS，后来我知道，你只要换一张SIM卡，就快了，然而还是解决不了基站坏了导致的访问慢问题，事实上，我也解决不了由于地震海底缆线受损导致的访问慢问题，那时google还是可以用的...
我耿耿于怀，我离职了，因为我没有完成需求，这个需求是：必须快，不能慢！！PS：这个经理是一个当时有8年经验的老桌面程序(不怎么联网的那种)程序员。
我的故事二：弹证书慢
那时的我在搞SSL相关的，而且那个时候我已经是公司里相比其他程序员更懂一点网络的人了，于是很多网络方面的问题大家都会问我。和故事一相反，这里的程序员会认为一切慢的原因都是网络的原因，而不是程序的原因，于是这活儿自然就落到我头上了。
怎么个慢法？我们的服务器是双向SSL认证的，浏览器要上传一张证书，如果有多张，那就要选择，因此会弹出一个选择证书的框，弹这个框从连接开始计时，特别慢！
虽然并不是说我必须解决，但即便友情支持也要尽可能完美，我比较崇尚德国工匠精神，精确，完美！
于是我把自己关在机房一个下午，最终确认这是一个Linux内核BUG导致的问题，与网络无关！出来后眼都是疼的。为什么大家会认为这是网络问题，而我第一反应却是程序问题呢？
因为我在只有一跳的自建环境内可以100%重现该问题。
自那以后，我经历了无数次的此类过程，水平也因此逐渐长进，逐渐形成了我的价值观和方法论。
知道我想说什么了吗？
能100%重现的，就不是混沌的，那时确定的事情，按照程序员的思维，确定的事情一定是哪里的一个语句使然！然而网络是混沌的，是不确定的。
我的故事三：连接被重置
这可能是最近最近的事情了，我正反两面来讲。
我首先肯定一下自己。
多对多C/S环境，统计数据显示有大量的连接被重置，我第一时间分析的是数据的聚集特征，而不是去搞抓包这种细节。我是对的，因为根本无需抓包，大数据显示发生这类错误的服务器是同一台，和故事二一样，我直接盯上了那台服务器！然后从那台服务器作为一个新的开始，开始新的排查！最终，问题完美确认，请参考故事五。
然后我想说一下同事A。
和我的观点不同，同事A也有自己的方法论，他只是希望去分析抓包，我也照着比划了几下...不同点在于，我是自上而下的分析数据特征，他是自下而上的分析，所以，在这个场景下，我的效率会更加高些。这是为什么呢？因为网络是混沌的，是不确定的，但是主机是确定的，主机上跑的程序也是确定的，自上而下可以瞬间发现主机异常，而分析数据包则会湮没到茫茫海洋！这笔大数据是可贵的，它可以帮你发现每一个客户端的特征，只是还有大部分程序员不知道怎么用这笔数据。
我的故事四：nmap扫描
网络上获得任何数据，都是统计数据，都不是精确的，这是程序员所不想看到的事实，然而却必须正视！
多对多C/S环境，必须符合一定规则的客户端才能参与连接，我查出一大批伪造的客户端，但我不能确定还会不会有别的。我的证据是什么呢？程序员可能更希望我能拿出抓包数据板上钉钉，说：看，这就是你们伪造客户端的证据！
可是，一个pcap包能看出什么呢？答案是什么也看不出！
我的方法是nmap。然而程序员可能不太相信nmap的结果，因为中间经历了太多的设备，很多东西都是Guess，不是确定的，不符合程序员的价值观！这也是为什么一帮程序员加班到深夜去Debug，然后来了一个运维一个traceroute就查出问题的原因。程序员宁可相信自己的代码有问题，也不愿猜测是网络有问题，因为代码是确定的，traceroute或者nmap的结果是不确定的。
好吧，说下结论吧，我nmap的结果完全正确。在nmap过程中，我当然也不是一扫定乾坤，我也是扫了大量的地址，然后看数据聚集性的。
故事五：运营商不可信
接着故事三，当我查到异常设备后，我是怎么进一步分析的呢？由于异常设备只是一个代理，我需要去找原始主机，通过配置就能找到，很快，几乎不需要时间。然后呢？
然后我没有去查两台机器的日志，而是先去看两台机器的连通性！如果是程序员，为了尽快确认不是自己的问题，肯定会去查日志，查代码版本，查发布...
事实证明这是对的，两台机器之间的单向丢包率达到了90%+。然后呢？然后问题扔出去，就不管了，因为后面的事情我也关不着了，这是运营商的问题。
我为什么就知道连通性有问题，直觉吗？不是！还是那个观点，如果程序有问题，就不会在第二跳代码上发生错误聚集，而是普遍离散。所以一定是网络的问题。
故事六：Spanning Tree与网线插反
CCIE真的不是吹的。敲各种命令，然后得到各种结果，还好，我能看懂这些。
2013年年中，我与一群CCIE共事，与其说共事不如说对抗，我在怀疑自己程序问题的同时，他们在证明网络没有问题。最终的结论是，程序没问题，网络有故障。这个故障太低级，以至于CCIE们根本不屑！
网线插反了！
这个故事好像没有任何结论，但事实上，我想说的是，要不是思考过以及搞过一段时间真正的网络，我真的要被那些CCIE给坑惨了！
故事七：程序员看pcap包
这个不仅仅是我的故事，是所有程序员的故事。
程序员看数据包，一般都会集中于TCP或者应用层，展开点说不仅仅是看数据包，看日志也一样。而事实上如果已经发现聚集效应，IP头以及MAC头上的信息更加重要，因为IP和MAC是绑定于主机的。
故事八：统计意义
紧接着故事三，当我解决了大量(几乎所有)的连接重置问题后，接连几天平安无事。然而后面数据报表上有出现了连接被重置，于是被要求排查，但是我拒绝了。
拒绝的理由是，这些重置没有聚集效应，且数量太少，没有统计意义。互联网是一个没有法律的世界，如果有人违反了规则，谁也无法阻挡。所以我的理由是，解决这几起异常事件，出力不讨好，可能仅仅就是随机的恶意事件。
网络是一个统计实体，永远不要试图精确化，不然会死得很惨。世界上任何一个地方的任何一个事件都会让TCP/IP网络产生波动，比如英国有个傻逼上厕所忘了带纸，他会打电话给朋友，这么一件小事就会引起TCP/IP网络流量的波动，偶然间让你的数据从0.0035变成了0.0037，这是什么，这是蝴蝶效应！程序员经理会问，相差的那0.0002是怎么回事？然后有个人定位到英国那个傻逼在厕所拉完屎打了个电话...此乃真神！
故事九：端到端与骨干网
一个程序员写了一套程序，一个客户端，一个服务端，然后写完了就集成测试，在自己的网络内测试一切良好。然后最终，最终这套程序要部署在两个地点，一个青海，一个上海，结果呢？
其行为完全不符合预期。
我就干过这事，那是很早之前了。
程序员往往会忽略骨干网。因为他们根本没有机会接触真正的网络。真正的网络都是那些技校毕业然后在社会上考了个HCSE或者CCNP的人才会接触的，我就是其中半个，我的另外半身是程序员。
程序员永远都只会把网络当成一条理所当然的管道，当程序的行为与预期不同时，他们(我曾经是”他们“的一员，但现在我只是”他们“的半员)总是期待修改程序就能解决问题，因为程序是唯一他们能控制的，但是运维和网管却看清了一切，虽然也不是100%的看清，但起码比程序员看得清。当程序员越来越多的被那些所谓的”框架“引导到更加上层的位置时，他们失去的却是底层网络基本的知识。
这个现状正如当今的”女司机“一词一样，会开车，但只是简单的开车，没有解决突发情况问题的能力...引发车祸...
作为一个懂点(我很自信比大多数程序懂的更多)网络的程序员，我想说的是，不要当鸵鸟，把头埋在土里忽略网络，不要当”女司机“，只会开不会修...
此文以上，无论褒贬请勿对号入座。涉及到的事情都是真事，但只是想传达一种理念，无关褒贬。
Gaius Julius Caesar如是说：人们只想看到自己想看到的那部分，那就把这部分给他们看！(同时利用他们看不到的那部分奴役他们)
文章转载自 开源中国社区[http://www.oschina.net]
