程序员的价值观与网络的复杂性
网络是极其复杂的，这种复杂包含混沌和不确定性，网络是一个典型的复杂系统。然而网络映射到程序员的心里，它只是一条确定的管道！这种思路会带来问题。程序员与运维/网管之间的斗争依然在继续，在这个无休止的争论中，我不断切换着自己的角色，这一次，我将站在程序员的对立面。
从我的故事说起，这些故事我故意打乱了时间顺序，请看到此文的人并且知道这些事的，不要往自己身上映射，纯技术讨论，无关褒贬！
我的故事一：手机访问慢那是我刚毕业的时候了，在一家小公司做VOIP，我接手了一个SymbianUIQ程序的开发，这是一个联网的程序，经理的意思是，访问一定要快，绝不能慢。需求很明确，几乎所有的网络程序都是这么个需求。我于是就开始了没日没夜的奋战，我刚毕业时发誓要做一个标准程序员，我觉得这是一定可以完成的。然而，事后证明，这往往是程序员的通病。
后来我离职了。
因为，我无法做到访问不慢...其实这不是我的错，这是那个手机的错，那个手机买的带宽太低了，那时没有3G，那时只是GPRS，后来我知道，你只要换一张SIM卡，就快了，然而还是解决不了基站坏了导致的访问慢问题，事实上，我也解决不了由于地震海底缆线受损导致的访问慢问题，那时google还是可以用的...
我耿耿于怀，我离职了，因为我没有完成需求，这个需求是：必须快，不能慢！！PS：这个经理是一个当时有8年经验的老桌面程序(不怎么联网的那种)程序员。
我的故事二：连接被重置这可能是最近最近的事情了，我正反两面来讲。
我首先肯定一下自己。
多对多C/S环境，统计数据显示有大量的连接被重置，我第一时间分析的是数据的聚集特征，而不是去搞抓包这种细节。我是对的，因为根本无需抓包，大数据显示发生这类错误的服务器是同一台，和故事二一样，我直接盯上了那台服务器！然后从那台服务器作为一个新的开始，开始新的排查！最终，问题完美确认，请参考故事五。
然后我想说一下同事A。
和我的观点不同，同事A也有自己的方法论，他只是希望去分析抓包，我也照着比划了几下...不同点在于，我是自上而下的分析数据特征，他是自下而上的分析，所以，在这个场景下，我的效率会更加高些。这是为什么呢？因为网络是混沌的，是不确定的，但是主机是确定的，主机上跑的程序也是确定的，自上而下可以瞬间发现主机异常，而分析数据包则会湮没到茫茫海洋！这笔大数据是可贵的，它可以帮你发现每一个客户端的特征，只是还有大部分程序员不知道怎么用这笔数据。
我的故事三：nmap扫描网络上获得任何数据，都是统计数据，都不是精确的，这是程序员所不想看到的事实，然而却必须正视！
多对多C/S环境，必须符合一定规则的客户端才能参与连接，我查出一大批伪造的客户端，但我不能确定还会不会有别的。我的证据是什么呢？程序员可能更希望我能拿出抓包数据板上钉钉，说：看，这就是你们伪造客户端的证据！
可是，一个pcap包能看出什么呢？答案是什么也看不出！
我的方法是nmap。然而程序员可能不太相信nmap的结果，因为中间经历了太多的设备，很多东西都是Guess，不是确定的，不符合程序员的价值观！这也是为什么一帮程序员加班到深夜去Debug，然后来了一个运维一个traceroute就查出问题的原因。程序员宁可相信自己的代码有问题，也不愿猜测是网络有问题，因为代码是确定的，traceroute或者nmap的结果是不确定的。
好吧，说下结论吧，我nmap的结果完全正确。在nmap过程中，我当然也不是一扫定乾坤，我也是扫了大量的地址，然后看数据聚集性的。
程序员永远都只会把网络当成一条理所当然的管道，当程序的行为与预期不同时，他们(我曾经是”他们“的一员，但现在我只是”他们“的半员)总是期待修改程序就能解决问题，因为程序是唯一他们能控制的，但是运维和网管却看清了一切，虽然也不是%的看清，但起码比程序员看得清。当程序员越来越多的被那些所谓的”框架“引导到更加上层的位置时，他们失去的却是底层网络基本的知识。
----文章转自酷勤网，如若侵权请联系作者删除
尚观8月以下课程火热招生中
linux运维
Oracle数据库
嵌入式底层驱动
java+大数据开发
VR虚拟现实
详情咨询
一指禅戳戳戳!赞赏
转载请注明:http://www.ddnhj.com/wahl/8124.html
当前时间：