[开发前准备]
在进行linux服务器开发之前，必须很清楚地了解所开发的对象需要考虑的相关问题
比如：
功能架构：提供服务的模块体系结构
稳定性：服务器的出core率，内存泄露情况
性能：请求与返回的速度与正确性
负载能力：能同时访问的最大数量和频度
根据不同服务器对象的环境和应用，服务器开发的对应手段相差甚远。比如就客户端连接时间较短却又比较频繁的服务器（例如HTTP服务器）而言，
在可选的服务器结构中，预先派生进/线程的结构就要比并发式结构高效
总之，在开发服务器之前，必须进行完整的服务器开发需求分析，否则一旦你的服务器开发完成而因为效率或者其他某项事物不能满足你的客户，那么很有可能失败！
[服务器让我明白了这件事情]
服务器一般在后台运行，与客户端的交互通过请求和返回两种方式进行通信。
以epoll为例，一个epoll开发的服务器程序，等待着一百万的客户端用户的请求，轮询观察某个时刻是否有客户端发来的请求；排队依次处理发来的请求，并将结果返回给
客户端应用程序。
涉及到几个技术问题：
第一，客户端访问进入epoll轮询队列的优先级是否需要控制。比如甲是我们的vip白金用户，那么，我始终先处理甲发来的请求，不然白金用户要生气的。
第二，极大可能程度上优化处理请求的速度，这是服务器设计的核心业务。
第三，如果客户端请求了这样一个事情：我需要看这一百年来某企业所有的信息，那么我想这个信息量是很大的，也就是现在很热门的大数据大文件传输问题，如何快速
将服务端的这些结果传给客户端，在带宽允许的情况下当然越快越好！这里会有很多处理措施，当然你可以打成一个包直接扔过去，但是这样是愚蠢的，像蜗牛背着一个
重壳在挪动，用户可等不了这么久；聪明的做法当然很多，根据你的实际需要，比如，你可以压缩，你可以分批，等等。
等等，其实服务器的整个开发，每个细节都决定了你的服务器的成败优劣。在开发linux服务器的项目后，我个人决定，一个让你的服务器变得强大的很重要的因素是——
——你不愿意放弃任何一个可以挺高性能的因素，即使是快0.01ms或者少传1bt的数据！
[流行的服务器模型]
1 PPC/TPC 模型
这两种模型思想类似，就是让每一个到来的连接一边自己做事去，别再来烦我 。只是 PPC 是为它开了一个进程，而 TPC 开了一个线程。可是别烦我是有代价的，
它要时间和空间啊，连接多了之后，那么多的进程 / 线程切换，这开销就上来了；因此这类模型能接受的最大连接数都不会高，一般在几百个左右。
2 select 模型
2.1. 最大并发数限制，因为一个进程所打开的 FD （文件描述符）是有限制的 由 FD_SETSIZE 设置，默认值是 1024/2048 ，因此 Select 模型的最大并发数就被相应限制了。
自己改改这个 FD_SETSIZE ？想法虽好，可是先看看下面吧 …
2.2. 效率问题， select 每次调用都会线性扫描全部的 FD 集合，这样效率就会呈现线性下降，把 FD_SETSIZE 改大的后果就是，大家都慢慢来，什么？都超时了？？！！
2.3. 内核 / 用户空间 内存拷贝问题，如何让内核把 FD 消息通知给用户空间呢？在这个问题上 select 采取了内存拷贝方法。
3 poll 模型
基本上效率和 select 是相同的， select 缺点的 2 和 3 它都没有改掉。
4 Epoll 模型
把其他模型逐个批判了一下，再来看看 Epoll 的改进之处吧，其实把 select 的缺点反过来那就是 Epoll 的优点了。
3.1. Epoll 没有最大并发连接的限制，上限是最大可以打开文件的数目，这个数字一般远大于 2048, 一般来说这个数目和系统内存关系很大 ，
具体数目可以 cat /proc/sys/fs/file-max 察看。
3.2. 效率提升， Epoll 最大的优点就在于它只管你“活跃”的连接 ，而跟连接总数无关，因此在实际的网络环境中， Epoll 的效率就会远远高于 select 和 poll 。
3.3. 内存拷贝， Epoll 在这点上使用了“共享内存 ”，这个内存拷贝也省略了。
等等。
在开发你的服务器之前，应根据自己的业务需求和实际情况，恰当地选择服务器的模型，这对这个服务器的功能效率都是具有很重要的意义的。
