关于网络编程.docx

1、关于网络编程网络编程是什么？网络编程是什么？是熟练使用Sockets API吗？说实话，在实际项目里我只用过两次Sockets API，其他时候都是使用封装好的网络库。 第一次是2005年在学校做一个羽毛球赛场计分系统：我用C# 编写运行在PC机上的软件，负责比分的显示；再用C# 写了运行在PDA上的计分界面，记分员拿着PDA记录比分；这两部分程序通过 TCP协议相互通信。这其实是个简单的分布式系统，体育馆有不止一片场地，每个场地都有一名拿PDA的记分员，每个场地都有两台显示比分的PC机（显示器是42吋平板电视，放在场地的对角，这样两边看台的观众都能看到比分）。这两台PC机功能不完全一样，一台

2、只负责显示当前比分，另一台还要负责与PDA通信，并更新数据库里的比分信息。此外，还有一台PC机负责周期性地从数据库读出全部7片场地的比分，显示在体育馆墙上的大屏幕上。这台PC上还运行着一个程序，负责生成比分数据的静态页面，通过FTP上传发布到某门户网站的体育频道。系统中还有一个录入赛程（参赛队，运动员，出场顺序等）数据库的程序，运行在数据库服务器上。算下来整个系统有十来个程序，运行在二十多台设备（PC和PDA）上，还要考虑可靠性。将来有机会把这个小系统仔细讲一讲，挺有意思的。 这是我第一次写实际项目中的网络程序，当时写下来的感觉是像写命令行与用户交互的程序：程序在命令行输出一句提示语，等待客户

3、输入一句话，然后处理客户输入，再输出下一句提示语，如此循环。只不过这里的“客户”不是人，而是另一个程序。在建立好TCP连接之后，双方的程序都是read/write循环（为求简单，我用的是blocking读写），直到有一方断开连接。 第二次是2010年编写muduo网络库，我再次拿起了Sockets API，写了一个基于Reactor模式的C+ 网络库。写这个库的目的之一就是想让日常的网络编程从Sockets API的琐碎细节中解脱出来，让程序员专注于业务逻辑，把时间用在刀刃上。Muduo 网络库的示例代码包含了几十个网络程序，这些示例程序都没有直接使用Sockets API。 在此之外，无论是

4、实习还是工作，虽然我写的程序都会通过TCP协议与其他程序打交道，但我没有直接使用过Sockets API。对于TCP网络编程，我认为核心是处理“三个半事件”，见Muduo 网络编程示例之零：前言中的“TCP 网络编程本质论”。程序员的主要工作是在事件处理函数中实现业务逻辑，而不是和Sockets API较劲。 这里还是没有说清楚“网络编程”是什么，请继续阅读后文“网络编程的各种任务角色”。 学习网络编程有用吗？以上说的是比较底层的网络编程，程序代码直接面对从TCP或UDP收到的数据以及构造数据包发出去。在实际工作中，另一种常见 的情况是通过各种 client library 来与服务端打交道，

5、或者在现成的框架中填空来实现server，或者采用更上层的通信方式。比如用libmemcached与memcached打交道，使用libpq来与PostgreSQL 打交道，编写Servlet来响应http请求，使用某种RPC与其他进程通信，等等。这些情况都会发生网络通信，但不一定算作“网络编程”。如果你的工作是前面列举的这些，学习TCP/IP网络编程还有用吗？ 我认为还是有必要学一学，至少在troubleshooting 的时候有用。无论如何，这些library或framework都会调用底层的Sockets API来实现网络功能。当你的程序遇到一个线上问题，如果你熟悉Sockets API

6、，那么从strace不难发现程序卡在哪里，尽管可能你没有直接调用这些Sockets API。另外，熟悉TCP/IP协议、会用tcpdump也大大有助于分析解决线上网络服务问题。 在什么平台上学习网络编程？对于服务端网络编程，我建议在Linux上学习。 如果在10年前，这个问题的答案或许是FreeBSD，因为FreeBSD根正苗红，在2000年那一次互联网浪潮中扮演了重要角色，是很多公司首选的免费服务器操作系统。2000年那会儿Linux还远未成熟，连epoll都还没有实现。（FreeBSD在2001年发布4.1版，加入了kqueue，从此C10k不是问题。） 10年后的今天，事情起了变化，Li

7、nux成为了市场份额最大的服务器操作系统(http:/en.wikipedia.org/wiki/Usage_share_of_operating_systems)。在Linux这种大众系统上学网络编程，遇到什么问题会比较容易解决。因为用的人多，你遇到的问题别人多半也遇到过；同样因为用的人多，如果真的有什么内核bug，很快就会得到修复，至少有work around的办法。如果用别的系统，可能一个问题发到论坛上半个月都不会有人理。从内核源码的风格看，FreeBSD更干净整洁，注释到位，但是无奈它的市场份额远不如Linux，学习Linux是更好的技术投资。 可移植性重要吗？写网络程序要不要考虑移植

8、性？这取决于项目需要，如果贵公司做的程序要卖给其他公司，而对方可能使用Windows、Linux、FreeBSD、Solaris、AIX、HP-UX等等操作系统，这时候考虑移植性。如果编写公司内部的服务器上用的网络程序，那么大可只关注一个平台，比如Linux。因为编写和维护可移植的网络程序的代价相当高，平台间的差异可能远比想象中大，即便是POSIX系统之间也有不小的差异（比如Linux没有SO_NOSIGPIPE选项），错误的返回码也大不一样。 我就不打算把muduo往Windows或其他操作系统移植。如果需要编写可移植的网络程序，我宁愿用libevent或者Java Netty这样现成的库，

9、把脏活累活留给别人。 网络编程的各种任务角色计算机网络是个 big topic，涉及很多人物和角色，既有开发人员，也有运维人员。比方说：公司内部两台机器之间 ping 不通，通常由网络运维人员解决，看看是布线有问题还是路由器设置不对；两台机器能ping通，但是程序连不上，经检查是本机防火墙设置有问题，通常由系统管理员解决；两台机器能连上，但是丢包很严重，发现是网卡或者交换机的网口故障，由硬件维修人员解决；两台机器的程序能连上，但是偶尔发过去的请求得不到响应，通常是程序bug，应该由开发人员解决。 本文主要关心开发人员这一角色。下面简单列出一些我能想到的跟网络打交道的编程任务，其中前三项是面向网

10、络本身，后面几项是在计算机网络之上构建信息系统。 1. 开发网络设备，编写防火墙、交换机、路由器的固件 firmware 2. 开发或移植网卡的驱动 3. 移植或维护TCP/IP协议栈（特别是在嵌入式系统上） 4. 开发或维护标准的网络协议程序，HTTP、FTP、DNS、SMTP、POP3、NFS 5. 开发标准网络协议的“附加品”，比如HAProxy、squid、varnish等web load balancer 6. 开发标准或非标准网络服务的客户端库，比如ZooKeeper客户端库，memcached客户端库 7. 开发与公司业务直接相关的网络服务程序，比如即时聊天软件的后台服务器，网游

11、服务器，金融交易系统，互联网企业用的分布式海量存储，微博发帖的内部广播通知，等等 8. 客户端程序中涉及网络的部分，比如邮件客户端中与 POP3、SMTP通信的部分，以及网游的客户端程序中与服务器通信的部分 本文所指的“网络编程”专指第7项，即在TCP/IP协议之上开发业务软件。 面向业务的网络编程的特点跟开发通用的网络程序不同，开发面向公司业务的专用网络程序有其特点： 业务逻辑比较复杂，而且时常变化 如果写一个HTTP服务器，在大致实现HTTP /1.1标准之后，程序的主体功能一般不会有太大的变化，程序员会把时间放在性能调优和bug修复上。而开发针对公司业务的专用程序时，功能说明书（spec

12、）很可能不如HTTP/1.1标准那么细致明确。更重要的是，程序是快速演化的。以即时聊天工具的后台服务器为例，可能第一版只支持在线聊天；几个月之后发布第二版，支持离线消息；又过了几个月，第三版支持隐身聊天；随后，第四版支持上传头像；如此等等。这要求程序员能快速响应新的业务需求，公司才能保持竞争力。 不一定需要遵循公认的通信协议标准 比方说网游服务器就没什么协议标准，反正客户端和服务端都是本公司开发，如果发现目前的协议设计有问题，两边一起改了就是了。 程序结构没有定论 对于高并发大吞吐的标准网络服务，一般采用单线程事件驱动的方式开发，比如HAProxy、lighttpd等都是这个模式。但是对于专用

13、的业务系统，其业务逻辑比较复杂，占用较多的CPU资源，这种单线程事件驱动方式不见得能发挥现在多核处理器的优势。这留给程序员比较大的自由发挥空间，做好了横扫千军，做烂了一败涂地。 性能评判的标准不同 如果开发httpd这样的通用服务，必然会和开源的Nginx、lighttpd等高性能服务器比较，程序员要投入相当的精力去优化程序，才能在市场上占有一席之地。而面向业务的专用网络程序不一定有开源的实现以供对比性能，程序员通常更加注重功能的稳定性与开发的便捷性。性能只要一代比一代强即可。 网络编程起到支撑作用，但不处于主导地位 程序员的主要工作是实现业务逻辑，而不只是实现网络通信协议。这要求程序员深入理

14、解业务。程序的性能瓶颈不一定在网络上，瓶颈有可能是CPU、Disk IO、数据库等等，这时优化网络方面的代码并不能提高整体性能。只有对所在的领域有深入的了解，明白各种因素的权衡(trade-off)，才能做出一些有针对性的优化。 几个术语互联网上的很多口水战是由对同一术语的不同理解引起的，比我写的多线程服务器的适用场合就曾经人被说是“挂羊头卖狗肉”，因为这篇文章中举的 master例子“根本就算不上是个网络服务器。因为它的瓶颈根本就跟网络无关。” 网络服务器 “网络服务器”这个术语确实含义模糊，到底指硬件还是软件？到底是服务于网络本身的机器（交换机、路由器、防火墙、NAT），还是利用网络为其他

15、人或程序提供服务的机器（打印服务器、文件服务器、邮件服务器）。每个人根据自己熟悉的领域，可能会有不同的解读。比方说或许有人认为只有支持高并发高吞吐的才算是网络服务器。 为了避免无谓的争执，我只用“网络服务程序”或者“网络应用程序”这种含义明确的术语。“开发网络服务程序”通常不会造成误解。 客户端？服务端？ 在TCP网络编程里边，客户端和服务端很容易区分，主动发起连接的是客户端，被动接受连接的是服务端。当然，这个“客户端”本身也可能是个后台服务程序，HTTP Proxy对HTTP Server来说就是个客户端。 客户端编程？服务端编程？ 但是“服务端编程”和“客户端编程”就不那么好区分。比如 Web crawler，它会主动发起大量连接，扮演的是HTTP客户端的角色，但似乎应该归入“服务端编程”。又比如写一个 HTTP proxy，它既会扮演服务端被动接受 web browser 发起的连接，也会扮演客户端主动向 HTTP server 发起连接，它究竟算服务端还是客户端？我猜大多数人会把它归入服务端编程。 那么究竟如何定义“服务端编程”？ 服务端编程需要处理大量并发连接？也许是，也许不是。比如云风在一篇介绍网游服务器的博客 我认为，“服务端网络编程”指的是编写