网络学习笔记（2）

         没想到一个月的时间这么快就过去了，这期间被项目赶的没时间去做其他事情，如果我说我不是吊丝，恐怕老天都不答应吧，呵呵。不同的人生，不同的阶段，不求辉煌灿烂，但求个心安理得。

         上回只是写了些网络的基础内容，而且也是非常的不全面，想了解全面的，可以从tcp/ip协议详解系列看起。今天更想写下网络在实际项目中的应用。

          对于一般的客户端应用来说，网络其实处理起来比较简单，当然如果要考虑防止网络通信加密过程被跟踪还是很复杂的一门学问，但这已经超出了网络的范围了。所以对于一个纯粹的客户端来说，网络只需能与因特网上指定的主机产生连接与收发数据即可。

          但对于服务端来说，情况就非常的不好。服务端可能处理着大量复杂的逻辑，同时还要处理大量的客户端通信需求。从我最早接触的一本讲网络编程的书来说，那上面是说每当有一个新的客户端连接进来时，就创建一个新的进程或者线程处理，这简直是胡闹！后来又听到了有改进版的，说是用固定数量的线程池来来响应客户端的连接，情况一样糟糕，线程池数量有限而且大多数情况是肯定满足不了N多客户端的请求的，总不能让多出的客户端一直等待吧？要处理好服务端的通信处理问题，首先要明确的是资源是非常有限的，无论是进程还是线程，所以只有在有线的进程或线程里处理尽量多的通信，具体的做法像Reactor或者Proactor框架已经阐释了这点，原理也是非常简单的，在有限的每一个线程或进程里监听尽可能多的客户端socket，每当有数据到达或者数据已准备好时，就向监听的线程发一个事件，订阅了这个事件的所有的观察者，都处理这个事件，通常这样的事件处理或者是比较快的（至少相对于线程或进程的切换是非常快的）或者根本就是异步的（立刻返回），而更一般的情况是，客户端发包的频率也不应该过于频繁（否则这个客户端极有可能是有问题的！），所以在处理客户端socket事件时，立刻处理不见的是好，如果掌握好这个大概的频率，改成定时处理这些事件，一来所有的客户端消息都将会被正确的处理，二来则某种程度上缓解了部分异常客户端发包频率过大（这里头还有其他的处理机制，比如某客户端发包太过频率直接丢包），三则给cpu腾出了空闲去做其他也很重要的事情。

          Reactor/Proactor，翻译为反应器/异步反应器模式，Reactor在Linux下或者windows下，都有自己的一套实现方式，linux下通常选择epoll，windows下则非iocp莫属，很多人要么是黑windows，要么是完全反感linux，各有各的特点吧，linux的epoll是一有数据到达就会产生事件而不管这数据是否已接收完，而iocp则设计成当数据完全准备好了以后，再发事件，从这一层来看，iocp符合了简单的设计思路，但这被一些大牛认为不够灵活（不知道大牛是不是都对windows有意见，不过我没有，笑），理由说起来也很简单，因为不同的客户端网络环境也会非常的不一样，有慢必有快，对于那些比较慢的，用这种方式处理还比不上阻塞的通信模型，因此程序可以根据实际运行情况而将一些客户端连接投递到阻塞队列中。至于Proactor模式，目前还没看实现，没时间啊～

         做为刚从windows程序渐渐转向学习linux的程序员，我想先抱怨下，为何linux连线程都没有，这实在是有点费解，也许水平只有这么点，光抱怨也起不了什么作用，还是再认真的学吧。