在做网管系统系统设计时，考虑到要分布式，以及多层数据交换，评估监控的主机量会随着运营商每年的投入增加，现需要监控的机器数量都已经到500多台，除了采用SNMP协议外，还涉及了业务系统的监控数据交互，这2者都涉及到网络通信开发，以下是比较实在的技术文章.... 文章有一部分内容是网上转载内容有一部分是我自己体会总结的。
--------------------------------------------------------------------------------------------------
这方面的问题,我个人认为是很有意义的，随着internet的发展，更高效率、更多并发连接数的服务已经成为当前迫切的需要。我们虽然可以采用UDP这样的无连接协议来解除连接限制（事实上这个限制也同样是存在的，尤其是当一个UDP处理需要占用不少CPU处理时间的情况下其上限也就越小），但是这样的方案并不能解决所有问题（例如从服务端发出给连接客户端的及时消息）。
解决这个问题的一种途径是线程池（Thread Pool），并在各个线程中运行单独的select()以实现对网络事件的多路分离。select其实的内部机制依赖于fd_set，说白了就是一个数组，select通过遍历这个数组中的所有socket handle，通过ioctl判断该handle是否被激活的socket事件。因此，我们可以对select得出两个结论：
1）select可以在多线程中分离使用，但是我们需要实现一个机制，以便在多个线程之间平均的划分socket handles，从而在各个线程之间平均分摊负载。
2）由于需要不停的（循环的）遍历一个fd_set数组，当这个数组变得很大的时候select就会显得效率低下（简直难以忍受，这就是为什么在windows中FD_SETSIZE的缺省大小为64的原因）
从以上的结论我们看到，采用select和线程池的方式解决以上问题应该是一种方法。但是我想这个问题还没完，因为这还不是我看来最有高效的解决方案。为什么这么说呢，首先select的选择能力有限，假设我们使用最大的FD_SETSIZE=1024，这样，我们需要10个左右不停循环的线程，由于每个线程每次遍历fd_set所花费的时间较长，10个不停循环的线程将很有可能使服务进程阻塞，占用大量的CPU资源，由于我们不是单纯的保持这些TCP连接就万事大吉了，我们还得对这些连接的请求进行处理，而服务器恐怕此时已经难以承担（当然，采用提高硬件配置、多CPU的方式可以有效解决这一问题，但这不是我们做软件的应该带给系统的其他成员的。如果采用FD_SETSIZE=64的方案呢？这样我们将在线程池中运行大约16*10=160个线程，考虑线程间切换和同步开销，该方案仍然是比较难忍受的。
如何解决这个问题？从目前的情况看，问题主要还是存在于select这一古老socket api 函数的瓶颈上。（毕竟线程间切换和同步开销问题是无法解决的）。于是我们考虑是否可以用poll或epoll多路分离来解决这个瓶颈问题。poll和select其实是采用的同种机制，因此其效率不会比select高多少。epoll提供Edge Triggered ( ET ) 和Level Triggered ( LT )两种方式的多路事件分离方法，使用LT方式时，其效果与select和poll相似，顶多可以看成是一个更快的poll；但在使用ET方式时其效率在处理具有大量idle connection的时候明显高于select和poll,在处理always busy connection等情况时,效率与select和poll没有多大区别。（关于这些效能的比较可以参考[1]中的Fig5和Fig6）当然，epoll比起poll和select来说缺省的最大FD大小更大，不过这其实不是问题，因为我们都可以修改其水平边界的大小的。补充一点，由于epoll、poll和select都使用文件描述符fd作为数组的索引，而在普通系统中一个FD的定义是integer，也就是说它是存在上限的，在C中一个int通常是16位的，也就是说最大文件句柄数32768（不是65536哦;-)构成了单个fd_set的上限。见[2]
实际情况下，很少有服务的连接是always busy connection的，也就是说客户端一但建立和与服务端的TCP连接后，该连接在很多时侯是处于idle connection状态的，它只是在有数据需要传送的时候才处于busy connection状态的。换句话说，在实际服务情况下，使用ET模式的epoll（以下的epoll都是指在ET模式下的）比使用poll和select具有更高的效率。这样看来，使用epoll比使用select或poll在单线程中具有更高的处理效率和更大的处理连接数。它仅使用单个线程就已经能处理前面问题中所提到的并发10K连接数问题。
至此，前面提出的10K连接数问题已经基本解决。但是我认为这还只是个开始，我们常见一些服务能够支持1M以上的同时连接数。为达到这个目的，我们需要将线程池和epoll结合起来，即，在多个线程中使用epoll_wait[3]等待多个socket events的到达。这带来了另外一些深层次的问题：
1）socket descript的限制，在大多数系统中SOCKET对应的是integer，其连接数是有上限的；
2）线程间同步及流量分配问题，需要为每个线程合理的分配连接以达到负载平衡；
3）服务质量问题，防止出现饿死现象。
1、修改用户进程可打开文件数限制
在Linux平台上，无论编写客户端程序还是服务端程序，在进行高并发TCP连接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个socket句柄，每个socket句柄同时也是一个文件句柄)。可使用ulimit命令查看系统允许当前用户进程打开的文件数限制：
[speng@as4 ~]$ ulimit -n
1024
这表示当前用户的每个进程最多允许同时打开1024个文件，这1024个文件中还得除去每个进程必然打开的标准输入，标准输出，标准错误，服务器监听socket，进程间通讯的unix域socket等文件，那么剩下的可用于客户端socket连接的文件数就只有大概1024-10=1014个左右。也就是说缺省情况下，基于Linux的通讯程序最多允许同时1014个TCP并发连接。
对于想支持更高数量的TCP并发连接的通讯处理程序，就必须修改Linux对当前用户的进程同时打开的文件数量的软限制(soft limit)和硬限制(hardlimit)。其中软限制是指Linux在当前系统能够承受的范围内进一步限制用户同时打开的文件数；硬限制则是根据系统硬件资源状况(主要是系统内存)计算出来的系统最多可同时打开的文件数量。通常软限制小于或等于硬限制。
修改上述限制的最简单的办法就是使用ulimit命令：
[speng@as4 ~]$ ulimit -n
上述命令中，在中指定要设置的单一进程允许打开的最大文件数。如果系统回显类似于“Operation notpermitted”之类的话，说明上述限制修改失败，实际上是因为在中指定的数值超过了Linux系统对该用户打开文件数的软限制或硬限制。因此，就需要修改Linux系统对用户的关于打开文件数的软限制和硬限制。
第一步，修改/etc/security/limits.conf文件，在文件中添加如下行：
speng soft nofile 10240
speng hard nofile 10240
其中speng指定了要修改哪个用户的打开文件数限制，可用'*'号表示修改所有用户的限制；soft或hard指定要修改软限制还是硬限制；10240则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。
第二步，修改/etc/pam.d/login文件，在文件中添加如下行：
session required /lib/security/pam_limits.so
这是告诉Linux在用户完成系统登录后，应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制)，而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。修改完后保存此文件。
第三步，查看Linux系统级的最大打开文件数限制，使用如下命令：
[speng@as4 ~]$ cat /proc/sys/fs/file-max
12158
这表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)12158个文件，是Linux系统级硬限制，所有用户级的打开文件数限制都不应超过这个数值。通常这个系统级硬限制是Linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制，如果没有特殊需要，不应该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值。修改此硬限制的方法是修改/etc/rc.local脚本，在脚本中添加如下行：
echo 22158 > /proc/sys/fs/file-max
这是让Linux在启动完成后强行将系统级打开文件数硬限制设置为22158。修改完后保存此文件。
完成上述步骤后重启系统，一般情况下就可以将Linux系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值。如果重启后用ulimit-n命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值，这可能是因为在用户登录脚本/etc/profile中使用ulimit-n命令已经将用户可同时打开的文件数做了限制。由于通过ulimit-n修改系统对用户可同时打开文件的最大数限制时，新修改的值只能小于或等于上次ulimit-n设置的值，因此想用此命令增大这个限制值是不可能的。所以，如果有上述问题存在，就只能去打开/etc/profile脚本文件，在文件中查找是否使用了ulimit-n限制了用户可同时打开的最大文件数量，如果找到，则删除这行命令，或者将其设置的值改为合适的值，然后保存文件，用户退出并重新登录系统即可。
通过上述步骤，就为支持高并发TCP连接处理的通讯处理程序解除关于打开文件数量方面的系统限制。
2、修改网络内核对TCP连接的有关限制
在Linux上编写支持高并发TCP连接的客户端通讯处理程序时，有时会发现尽管已经解除了系统对用户同时打开文件数的限制，但仍会出现并发TCP连接数增加到一定数量时，再也无法成功建立新的TCP连接的现象。出现这种现在的原因有多种。
第一种原因可能是因为Linux网络内核对本地端口号范围有限制。此时，进一步分析为什么无法建立TCP连接，会发现问题出在connect()调用返回失败，查看系统错误提示消息是“Can't assign requestedaddress”。同时，如果在此时用tcpdump工具监视网络，会发现根本没有TCP连接时客户端发SYN包的网络流量。这些情况说明问题在于本地Linux系统内核中有限制。其实，问题的根本原因在于Linux内核的TCP/IP协议实现模块对系统中所有的客户端TCP连接对应的本地端口号的范围进行了限制(例如，内核限制本地端口号的范围为1024~32768之间)。当系统中某一时刻同时存在太多的TCP客户端连接时，由于每个TCP客户端连接都要占用一个唯一的本地端口号(此端口号在系统的本地端口号范围限制中)，如果现有的TCP客户端连接已将所有的本地端口号占满，则此时就无法为新的TCP客户端连接分配一个本地端口号了，因此系统会在这种情况下在connect()调用中返回失败，并将错误提示消息设为“Can't assignrequested address”。有关这些控制逻辑可以查看Linux内核源代码，以linux2.6内核为例，可以查看tcp_ipv4.c文件中如下函数：
static int tcp_v4_hash_connect(struct sock *sk)
请注意上述函数中对变量sysctl_local_port_range的访问控制。变量sysctl_local_port_range的初始化则是在tcp.c文件中的如下函数中设置：
void __init tcp_init(void)
内核编译时默认设置的本地端口号范围可能太小，因此需要修改此本地端口范围限制。
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：
net.ipv4.ip_local_port_range = 1024 65000
这表明将系统对本地端口范围限制设置为1024~65000之间。请注意，本地端口范围的最小值必须大于或等于1024；而端口范围的最大值则应小于或等于65535。修改完后保存此文件。
第二步，执行sysctl命令：
[speng@as4 ~]$ sysctl -p
如果系统没有错误提示，就表明新的本地端口范围设置成功。如果按上述端口范围进行设置，则理论上单独一个进程最多可以同时建立60000多个TCP客户端连接。
第二种无法建立TCP连接的原因可能是因为Linux网络内核的IP_TABLE防火墙对最大跟踪的TCP连接数有限制。此时程序会表现为在connect()调用中阻塞，如同死机，如果用tcpdump工具监视网络，也会发现根本没有TCP连接时客户端发SYN包的网络流量。由于IP_TABLE防火墙在内核中会对每个TCP连接的状态进行跟踪，跟踪信息将会放在位于内核内存中的conntrackdatabase中，这个数据库的大小有限，当系统中存在过多的TCP连接时，数据库容量不足，IP_TABLE无法为新的TCP连接建立跟踪信息，于是表现为在connect()调用中阻塞。此时就必须修改内核对最大跟踪的TCP连接数的限制，方法同修改内核对本地端口号范围的限制是类似的：
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：
net.ipv4.ip_conntrack_max = 10240
这表明将系统对最大跟踪的TCP连接数限制设置为10240。请注意，此限制值要尽量小，以节省对内核内存的占用。
第二步，执行sysctl命令：
[speng@as4 ~]$ sysctl -p
如果系统没有错误提示，就表明系统对新的最大跟踪的TCP连接数限制修改成功。如果按上述参数进行设置，则理论上单独一个进程最多可以同时建立10000多个TCP客户端连接。
3、使用支持高并发网络I/O的编程技术
在Linux上编写高并发TCP连接应用程序时，必须使用合适的网络I/O技术和I/O事件分派机制。
可用的I/O技术有同步I/O，非阻塞式同步I/O(也称反应式I/O)，以及异步I/O。在高TCP并发的情形下，如果使用同步I/O，这会严重阻塞程序的运转，除非为每个TCP连接的I/O创建一个线程。但是，过多的线程又会因系统对线程的调度造成巨大开销。因此，在高TCP并发的情形下使用同步I/O是不可取的，这时可以考虑使用非阻塞式同步I/O或异步I/O。非阻塞式同步I/O的技术包括使用select()，poll()，epoll等机制。异步I/O的技术就是使用AIO。
从I/O事件分派机制来看，使用select()是不合适的，因为它所支持的并发连接数有限(通常在1024个以内)。如果考虑性能，poll()也是不合适的，尽管它可以支持的较高的TCP并发数，但是由于其采用“轮询”机制，当并发数较高时，其运行效率相当低，并可能存在I/O事件分派不均，导致部分TCP连接上的I/O出现“饥饿”现象。而如果使用epoll或AIO，则没有上述问题(早期Linux内核的AIO技术实现是通过在内核中为每个I/O请求创建一个线程来实现的，这种实现机制在高并发TCP连接的情形下使用其实也有严重的性能问题。但在最新的Linux内核中，AIO的实现已经得到改进)。
综上所述，在开发支持高并发TCP连接的Linux应用程序时，应尽量使用epoll或AIO技术来实现并发的TCP连接上的I/O控制，这将为提升程序对高并发TCP连接的支持提供有效的I/O保证。
