网络软件工程师的N种境界

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




之所以说网络软件开发,是因为本人以前,以及目前的工作是这个,做网络软件开发。如果说其他领域的软件开发,由于对领域知识不是很熟悉,评价有可能不太客观。所以还是在自己的本行发发议论最好。
做网络软件开发,就我所做的这个领域,缩小一下范围:是网络安全方面,再缩小一下范围,是防火墙,VPN之类的东西。本人在N个做安全的公司从业过,基本上一直做到就是网络协议栈,以及filter,routing等等。更高级的安全话题,比如web firewall, ids/ips等等。没有做过。以前见过,都是拿snort改的,加上界面,估计设计到engine以及signature开发的也少。以前在国产安全公司工作,基本上就是ipchains, iptables, netfilter等等。虽然有现成的东西,但是在上面做产品,需要做的事情也很多。最起码需要一个好的用户界面WEBUI/CLI之类的需要考虑,做好了也不容易。再者就是功能的集成,把许多东西集成到一起,能跑起来,不出错,不crash,这个还是需要一些技术的。在这个层次,需要了解的知识包括:
a) 内核。由于ipchains/iptables/netfilter都是在内核空间里实现的。所以要对内核提供的机制和api需要了解。这是一个基本的要求。因为不能指望什么事情都是ready,所以很多时候需要亲自动手。Get hands dirty,从open source做东西,基本都是这样。
b) RFC。需要对网络协议很熟,最起码的要求,ip/tcp/udp要熟。但是这个相对简单的要求,很多从业人员是达不到的,很多人可能没有仔细看过RFC,对一些细节的定义模糊,导致做产品不能符合要求。
c) 协议栈。RFC有N种实现方式,至少应该熟悉一种,多看看代码,多想想如何从协议映射到代码。
d) 业界最佳实践。最简单的,data plane/control plane分离。这是一个很基本的常识。由此引申出,用netfilter做东西,需要做大改动,因为它和协议栈结合的太紧密了。最好是把ip层分离出来,直接在用户空间里实现firewall,而不是纠结于linux stack的代码迷宫之中。
以上只是一个搞网络开发的基本境界。如果做来做去离不开这些。职业如何发展。要明白,任何代码都是为功能服务的,任何功能都是为产品服务的,任何产品都是为客户服务的。只有为客户服务,才有钱可赚。从这个角度来说,做开发的,里离客户太远了,有时候就不太明白自己的价值。客户的环境,客户的服务,如何为客户创造价值。这些事情是只懂一点内核和协议的人无法参悟得了的,所以需要多了解客户的环境,客户的服务。先放下技术的细节,从应用角度来考虑问题。

不知道真正的大牛是否关注一行代码如何写了?大牛在规划产品时需要考虑这些吗?以此为目标,努力前进。

(4个打分, 平均:5.00 / 5)

雁过留声

“网络软件工程师的N种境界”有58个回复

  1. 陈怀临 于 2010-06-09 9:07 下午

    为什么没有谈到QoS?

  2. addison.zhenghu@gmail.com 于 2010-06-09 11:21 下午

    这篇文章质量不高

    不能让弯曲评论质量开始下滑哦…

  3. asdfer 于 2010-06-10 2:13 上午

    ‘network algorithmics’看了几遍就是第几重境界了:)

  4. ccc-net 于 2010-06-10 3:08 上午

    写的很好啊

  5. ShadowStar 于 2010-06-10 3:09 上午

    很不幸,我目前就是从事droplet所说的这种工作的,基本上abcd都涉及了。
    刚刚完成了一个QoS模块,可以支持大量IP的每IP控制,支持多规则设定。
    虽然是个人兴趣所在,但是我还是觉得这个方向很没前途。

    原因是网络这部分在Linux kernel中算是最简单的了(个人认为),没有做不到,只有想不到;入门的门槛太低了。

    前途很迷茫啊

  6. 理客 于 2010-06-10 3:29 上午

    现在网络对防火墙的有什么QOS要求?
    富士康12跳是一个研究社会学和人类学的最好的例子,如果一个人在一个公司做R&D 10年,其中大部分时间在工作,经常加班,之外就是回家老婆孩子,真正接触社会的时间很难有多少,这样的生活模式,如果生活10年,对一个人会造成什么影响呢?可能和富士康12跳是类似的。对于做研发的大部分不能升职到中层及以上的,需要考虑社会生活的比例,在单纯的环境中生活久了不一定是好事,这是个人的事,公司是很少去考虑的,但对于社会和政府,是需要考虑这些模式的深远影响的,比如美国人写的《菊花与剑》来分析日本人的社会生活模式下对整个政治经济等等的影响,这个模式是否健康和谐,才是一个社会长期稳定的真正基础,12跳如果分开来看,可能跳跳不同,以致无可厚非,当如果合在一起看,则肯定有深层的共性,像概率事件单看每一次发生,都是可能的,但如果概率很高,那一定有共性的原因。对于一辈子不能到中层及以上的工人,社会生活广泛一些,会发现更多自己的乐趣和机会,和升职到中高层职位,只是方向不同,不再互羡

  7. cracked 于 2010-06-10 4:41 上午

    不是吧 这么牛?网络部分都和内核有关系的 你都搞懂了吗

  8. droplet 于 2010-06-10 6:45 上午

    从以前的评论里面,对某某人景仰,都是产品规划的如何如何好。事实也是这样,知道一个东西怎么做很简单,但是知道做什么却很难,这往往不是靠积累就能得到的能力。没有好的产品规划,也就没有了前进的目标和方向。从倒下去的公司来看,大多数并不是东西很烂,而是做的东西跟不上潮流,跟不上时代。做产品规划,技术只是基本的素养,对其他领域的了解也很重要。比较客户不是和自己一个背景。

  9. 黄岩 于 2010-06-10 7:11 上午

    to ShadowStart: 您的看法值得商榷。数据面的协议栈想要做好,还是不太容易的。Linux协议栈还有很多值得改进和挖掘的地方。也有一些专业公司做这个事情,例如:InterPeak,6wind,也有另外一些安全协议栈公司。真的能够把这些事情做好了,就能够开个小规模的软件公司。过几年转手卖掉,就能小赚一笔:)
    InterPeak就卖给WRS了。

  10. ShadowStar 于 2010-06-10 11:56 上午

    to cracked: 不敢说牛。不过在工作中遇到的问题和新项目(功能)开发,倒是没遇到什么搞不定的。大概是我们的层次比较低吧。PS. 我们是做防火墙的,话说现在防火墙的功能需求是越来越多,都在往UTM发展了。

  11. ShadowStar 于 2010-06-10 12:05 下午

    to 黄岩:Linux的协议栈确实有很多值得改进的地方。比如说,Linux是为了通用来设计的;但是,对于网络安全设备来说,链接跟踪应该算是最基本的,但是现有的基于netfilter的conntrack实在是不怎么样。甚至是netfilter架构本身都有点过于低效了。我想把链接跟踪直接嵌入到协议栈很久了,但是由于我们是小公司,测试人员太少了;如果做较大改动,需要的测试周期太长,工作量太大,现在都是以项目为本,无法接受。所以一直没有改动。

    我的看法是针对国内这些网络安全公司的实际情况而论的。

  12. Multithreaded 于 2010-06-10 12:46 下午

    即使最简单的防火墙, 要做到10G也是不容易的。注意是小包10G。

    网络产品除了功能外,还要关注性能。 做工程师的应该在提高性能上多下功夫。network algorithmics’可以作为入门的书来读,对具体工作的指导用途不是太大。

  13. silent stone 于 2010-06-10 4:48 下午

    to ShadowStar:
    如果只是关注功能,的确是没什么搞不定的。但是关注到性能,要搞定就不是那么容易了。不过水平的高下,还是通过性能高低区分的。

  14. fra 于 2010-06-10 7:18 下午

    我认识droplet,技术水平很高,当时在公司是No.1,为人各方面都很谦虚。

  15. ShadowStar 于 2010-06-10 8:05 下午

    To silent stone & Multithreaded:
    首先说明,我是做软件的,不是硬件设计。

    我曾经也十分注重性能的优化和提升。但是经过一段时间发现,其实对于用户来说,最关注的是功能,其次才是性能。
    我们做出来的产品,首先要满足用户的功能需求,这是前提。如果一味的为了性能而降低了功能,就有些舍本逐末了。

    我认为不要小看现在编译器的优化能力,以及CPU的处理速度。如果为了提高1%的性能,而在代码中采用了大量的奇技淫巧,造成阅读、调试的困难,就得不偿失了。

    Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

    另外,性能的问题完全可以通过硬件的提升来解决,ASIC、MCore、NP都可以作为手段。但是功能的提升只有人可以来完成。

    当然,我的意思并不是说,代码写的再烂都可以。基本的代码级的优化,以及适合算法的选用都是应该的。

  16. SRX 于 2010-06-10 8:18 下午

    我也顶一下 droplet吧 呵呵

  17. 陈怀临 于 2010-06-10 8:24 下午

    我也顶一下掉链子(droplet)。我也认识他。很厚道的一个家伙。爱思考。这篇文章里有一点,我个人认为是网络工程师的一个境界,要提到:性能调优的把控能力。

    另外,能不做复杂就尽量简单的能力也是一种境界。。。

    我不认为工程师的境界里有什么商业分析的成分。那是a different topic.

  18. yunhaid 于 2010-06-10 8:43 下午

    毕竟是搞IT的,不是搞文学的,文章结构有点摸不懂。在国内搞Linux Kernel是死路.

  19. Daniel 于 2010-06-10 10:05 下午

    To droplet:

    最好是把ip层分离出来,直接在用户空间里实现firewall

    何解? 似乎你对data plane很有想法, 不过这个似乎很难吧.

  20. 打酱油的 于 2010-06-10 11:30 下午

    七七八八的说了这么多,写了这么多,我更关注的是最后哪个问题,大牛如何规划产品?有没有真正考虑到需求、功能、性能、技术难度、研发成本,全部了然于胸的大牛。
    还有一点,这个产业还有希望吗?混下去是不是会被边缘化?

  21. 理客 于 2010-06-11 6:46 上午

    男怕入错行,女怕嫁错郎,虽然是对很多普通百姓很好的道理,但是不希望有志男女青年以这个为目标,年轻人机会无限,要有四海的大志

  22. 知迷不悟 于 2010-06-11 7:04 上午

    文章内容含糊不清,软件认识水准一般,鉴于是陈首席的熟人,就不拍砖了。

  23. multithreaded 于 2010-06-11 7:06 上午

    不要过分相信编译器和硬件对性能提高的影响力。

    比如在多核上编程,这两个都靠不住!要有新的思维和不同的算法。

    当你把你的防火墙能在多核上跑到10G时,你就会体会到性能优化的重要性。还有一个问题,如何防止10G的SYNC类型的DDOS攻击?

    这两个问题,顺序程序都有解答,你可能也知道如何做。但在10G多核的条件下还无解。

  24. fra 于 2010-06-11 8:32 上午

    以一个大牛的身份要求网络软件工程师的话,首席是榜样,脑子精明能干能忽悠、讲信用说道做到、热心爱帮忙、遇到难啃的骨头不怕硬、做技术风格一丝不苟,他的这些风格全用在了系统架构和网络上,是个典型的大牛例子,嫉妒华为能把首席挖过去。任正非,确实牛!

  25. fra 于 2010-06-11 8:34 上午

    哈哈,闲扯。

  26. igp2bgp 于 2010-06-11 9:21 上午

    路过。

  27. mpc8240 于 2010-06-11 2:44 下午

    Linux的协议栈做得其实真不怎么样,根本不commercial ready。
    比如routing table,竟然用的是hash table array。还有kernel里根本没有priority的概念。想要QoS?自己加queue吧。至少2.4是如此的。

    BTW, 首席加入华为了??

  28. 毛毛虫 于 2010-06-11 5:53 下午

    @理客,在广义的firewall或者说utm里头,Qos可以被用于per role或者per application的流量控制。

  29. 陈怀临 于 2010-06-11 9:44 下午

    FW里,如果从狭义的QoS范畴,比较简单。主要是一些简单的shapping,policying then drop。基本上不mark。TM的层面基本上没有。

    但从广义而言,QoS是无处不在的。换言之,只要存在Queue,就存在QoS。

  30. cracked 于 2010-06-12 12:12 上午

    首席加入华为 这个网站还办下去吗

  31. 忘了名字 于 2010-06-12 1:19 上午

    最好是把ip层分离出来,直接在用户空间里实现firewall何解?
    同样的疑问。性能怎样?

  32. 阿尔吉侬 于 2010-06-12 4:22 上午

    一直等着首席写的ASR9000呢,不知道还有没有这个计划?

  33. droplet 于 2010-06-12 6:57 上午

    linux内核api不够稳定,经常变动,而且内核api没有标准,写出来的程序不好移植。最好是在用户空间实现转发,基于posix的api,这样移植起来比较方便。用户空间的程序,调试,跟踪都比较方便。一般data plane的程序,用到的诸如调度,内存之类的东西都比较简单,不需要内核那么复杂的服务。

  34. Panabit 于 2010-06-12 7:01 上午

    我建议大家多看看FreeBSD的代码,也许你看了FreeBSD的代码后,也会像我一样,再也不想看Linux代码了。不知道现在的Linux代码怎么样,我是很多年没有看过了。

  35. 陈怀临 于 2010-06-12 10:08 上午

    我最近也在想一个设计:完全的用户态的Data Plane转发。In-Kernel Stuff确实是一个不好的东西。

    你们对mmap的usage vs 直接hack MMU TLB mapping锁定一块Virtual Space(out of the 4Gkongj)的优缺点有没有什么看法?

  36. 打酱油的 于 2010-06-12 5:44 下午

    完全的用户态的Data Plane转发。如果只考虑L2、L3的转发,难度还勉强可以接受,但一想到要重新实现TCP,头就大了,但当前安全网关一定是要考虑L7,否则就没必要做了。
    那位高人或者那个公司把这个搞定了么?非常有意义。

  37. Shawn 于 2010-06-12 7:19 下午

    我有个可能很幼稚的问题:

    如果Data Plane转发,如何保证Data Plane 的Daemon 总是被实时调度? 然后就是包从Kernel到User Space, 查表转发,然后再从User Space到Kernel。这个两次Space转换代价是不是有些大?

  38. yfydz 于 2010-06-12 7:35 下午

    用linux内核来转发那只能是x86的吧?在多核下linux内核协议栈只要处理自身的数据包就够了,转发由数据平面处理,也不用实现TCP,L2~L7全搞定。不过有人用多核做出小包10G么?山石啥的好像都只是3G

  39. 0xff 于 2010-06-12 9:37 下午

    标题党。内容较差。做网络开发软件工程师,脑子里要有系统的进程、线程调度,要有数据的流处理模型,一次从模块到单板,到整机,到网络。脑子就是最小系统,脑子就是路由器,一个报文进去,大致就要知道过了哪些模块,做了哪些处理。一个BUG产生,就能感觉到什么地方可能出问题。

  40. julang3 于 2010-06-12 9:44 下午

    to Shawn
    1. 如果将处理线程绑定到1个core上,个人觉得实时调度的问题不大,没有实测过
    2.解决kernel空间和user space空间切换的问题,可以通过mmap网上的recevie,send ring buferr以及控制寄存器来实现,现存的案例见pf_ring作者的DNA网卡驱动;
    http://luca.ntop.org/IM2009_Tutorial.pdf

    完全用户态data plane ,tilera已经使用其NETIO库及Zero overhead of linux 实现了;难度确实比较高,不过非常意义;期待大牛们能实现X86平台上的完全用户态data plane

  41. xy 于 2010-06-12 10:06 下午

    国内做FreeBSD内核的还是少,Linux更容易混口饭吃。

  42. mpc8240 于 2010-06-12 11:32 下午

    其实最高境界是这样的:一个BUG产生,就是不能感觉到倒底什么地方出了问题,可能性太多。这才说明系统够复杂,积累够精深。这样的系统才可能是真正成功的系统。:)

  43. hehe 于 2010-06-13 4:32 上午

    # mpc8240 于 2010-06-12 11:32 pm

    其实最高境界是这样的:一个BUG产生,就是不能感觉到倒底什么地方出了问题,可能性太多。这才说明系统够复杂,积累够精深。这样的系统才可能是真正成功的系统。:)
    ===========================

    前提是这个BUG不用搞定也无大碍

  44. 理客 于 2010-06-13 4:56 上午

    好的商业系统一定是对BUG预防、监控、隔离、应急、修复等有充分的系统的设计,做得越好,系统的HA越高,反之,是要死人的。从技术角度做好不容易,从系统架构到函数设计甚至每一句编码,从管理角度做起来也很难,对大型系统,具有这种素质和能力的一个百人级别以上的团队绝对是战斗力极强的产品团队,这样才能让高层和市场敢于放心的规模销售这个产品,因为出现问题不可怕,可怕的是不能在市场允许的时间内使产品进入稳定的质量状态,这样会夭折一个本来可以正常结束生命周期的好产品

  45. benjiaming 于 2010-06-13 8:09 下午

    控制层面和数据层面分离---个人观点:网络设备永远的话题,说易做难

  46. 抛砖引玉 于 2010-06-14 6:23 上午

    文章和评论都很精彩

  47. 陈怀临 于 2010-06-14 7:07 上午

    Control being seperated from Data is more of 数通产品。。。我最近设计一个系统,。。。基本上脑袋转了个。。。很有意思。。。许多以前的设计假设不适用。

  48. Shawn 于 2010-06-15 7:02 下午

    谢谢julang3 的回答。这里真是高手如云,受教了。

  49. mips 于 2010-06-16 1:14 上午

    乍看到droplet的境界说
    还以为是把做软件归结为王国维的人生三境界呢个人倒希望大家 都讨论讨论我们在职业和研发过程中的一些心态思想方面的演进~~

    附王国维的“悬思——苦索——顿悟”的治学三重境:
    “昨夜西风凋碧树,独上高楼望尽天涯路。
    衣带渐宽终不悔,为伊消得人憔悴。
    众里寻她千百度,蓦然回首,那人却在灯火阑珊处”

  50. HJ 于 2010-06-18 10:04 上午

    这年头,网络软件工程师的境界最好是能2~7层通吃,光做4层以下就要沦为“管道工程师”了。^_^

    呵呵,玩笑,其实哪一层做到深都不容易,能够具备一定的大局观和专精某一(些)领域就能称得上“牛人”了。

  51. zeroflag 于 2010-06-20 6:34 上午

    说到产品规划,这应该是市场部门的事情吧,毕竟市场更加了解客户需要什么,市场竞争中哪些特性是好卖的。市场提出需求后研发要不要响应,怎样响应,做成什么样子,才是系统规划的工作吧。

    最近设想了一个全新的硬件体系架构,YY的自己很爽,但是太过突兀,估计没人会那么做产品的。这种事情还是自己YY一下好了。

  52. HJ 于 2010-06-20 4:36 下午

    如果只是做一个follow 别人的产品,那么产品规划很简单。但是如果要想做点新东西的话,光懂技术和光懂市场都是不够的,必须有两者结合。

    在很多公司里,都有产品经理这个职位,而这个职位就是负责定义产品的。对于产品经理来说,就必需“两手都得硬”

  53. LeadFrenzy 于 2010-06-23 11:34 下午

    文章能引出这么多讨论和思考,很不错了。 学习了各位大牛的境界,差距很大啊! 我还在“悬思”阶段

  54. cracked 于 2010-06-24 5:30 上午

    自己还是想学些系统软件 可是都怪这网络 好看的新闻太多了 自己管不住自己 郁闷 无可救药了:)

  55. 理客 于 2010-06-24 12:30 下午

    其实没有好看的新闻,还会有别的吸引你,有大辽科学实验,弄两堆小孩,观察小时候的自控能力,再跟踪长大后的出息,发现小时候自动能力强的成才纪律远高于自控能力差的。

  56. liizuu 于 2010-06-24 5:56 下午

    大辽真厉害,什么实验都有,不知道有没有我大宋的算命占卜之类的,呵呵

  57. shawn 于 2010-07-06 1:24 下午

    to julang3:

    仔细看了这个驱动,确实很有收益。

    另外,在Linux下,如何将处理线程绑定到1个core上? 还望各位不吝赐教。

  58. droplet 于 2010-07-07 6:31 下午

    cpu affinity,搜一下看看有没有收获。