linux下tcp并发服务器的几种设计灯的模式套路
Linux下tcp并发服务器的几种设计的模式套路
在做网络服务的时候tcp并发服务端程序的编写必不可少。tcp并发通常有几种固定的设计模式套路，他们各有优点，也各有应用之处。
下面就简单的讨论下这几种模式的差异：
1。 单进程，单线程模式
在accept之后，就开始在这一个连接连接上的数据收接收，收到之后处理，发送，不再接收新的连接，除非这个连接的处理结束。
优点：
简单。
缺点：
因为只为一个客户端服务，所以不存在并发的可能。
应用：
用在只为一个客户端服务的时候。
2。 多进程模式
accept返回成功时候，就为这一个连接fork一个进程，专门处理这个连接上的数据收发，等这个连接处理结束之后就结束这个进程。
优点：
编程相对简单，不用考虑线程间的数据同步等。
缺点：
资源消耗大。启动一个进程消耗相对比启动一个线程要消耗大很多，同时在处理很多的连接时候需要启动很多的进程多去处理，这时候
对系统来说压力就会比较大。另外系统的进程数限制也需要考虑。
应用：
在客户端数据不多的时候使用很方便，比如小于10个客户端。
3。 多线程模式
类似多进程方式，但是针对一个连接启动一个线程。
优点：
相对多进程方式，会节约一些资源，会更加高效一些。
缺点：
相对多进程方式，增加了编程的复杂度，因为需要考虑数据同步和锁保护。另外一个进程中不能启动太多的线程。在Linux系统下线程
在系统内部其实就是进程，线程调度按照进程调度的方式去执行的。
应用：
类似于多进程方式，适用于少量的客户端的时候。
4。 select + 多线程 模式
有一个线程专门用于监听端口，accept返回之后就把这个描述符放入 描述符集合 fd中，一个线程用select去轮训描述符集合，在有数据的
连接上接收数据，另外一个线程专门发送数据。当然也可以接收和发送用一个线程。描述符可以设置成非阻塞模式，也可以设置成阻塞模式。通常连接
设置成非阻塞模式，发送线程独立出来。
优点：
相对前几种模式，这种模式大大提高了并发量。
缺点：
系统一般实现描述符集合是采用一个大数组，每次调用select的时候都会轮询这个描述符数组，当连接数很多的时候就会导致效率下降。
连接数在1000以上时候效率会下降到不能接受。
应用：
目前windows 和一般的Unix上的tcp并发都采用select方式，应该说应用还是很广泛的。
5。 epoll方式
在Linux2.6版本之后，增加了epoll。具体的使用是：一个线程专门进行端口监听，accept接收到连接的时候，把该连接设置成非阻塞模式，
把 epoll事件设置成边缘触发方式，加入到epoll管理。接收线程阻塞在epoll的等待事件函数。另外一个线程专门用于数据发送。
优点：
由于epoll的实现方式先进，所以这种方式可以大规模的实现并发。我们现在的应用在一个3年前的dell的pc server可以实现2万个连接的并发，
性能也是很好的。
缺点：
由于涉及了线程和非阻塞，所以会导致编码的复杂度增大一些。这种方式只适用于Linux 2.6
内核以后。
注意：
1。 如果把epoll事件设置成水平触发效率就下降到类似采用select的水平。
2。 Unix系统下有单个进程打开的描述符数目限制，还有系统内打开的描述符数目限制。系统内打开的描述符数目限制由软硬限制两个。
硬限制是根据机器的配置而不同。软限制可以更改，但是必须小于系统的硬限制。在suse Linux下，可以在root用户下，通过ulimit -n 数目 去修改这个限制。
应用：
Linux下大规模的tcp并发。
当前 并发还有其他的方式，比如进程池，线程池等，每种模式都有它的优点和缺点，在适当的情况用合适的模式是最重要的。
如果需要很大规模的并发，经过测试，个人建议采用epoll方式，放弃通常的select方式。
【转载】配置开发支持高并发TCP连接的Linux应用程序全攻略
文章分类:操作系统
原文见：/flashboy/articles/47012.html
1、修改用户进程可打开文件数限制
在Linux平台上，无论编写客户端程序还是服务端程序，在进行高并发TCP连接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个socket句柄，每个socket句柄同时也是一个文件句柄)。可使用ulimit命令查看系统允许当前用户进程打开的文件数限制：
[speng@as4 ~]$ ulimit -n
1024
这表示当前用户的每个进程最多允许同时打开1024个文件，这1024个文件中还得除去每个进程必然打开的标准输入，标准输出，标准错误，服务器监听 socket，进程间通讯的unix域
1222
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
