accept Serialization - multiple sockets
Listen语句监听多个端口或者多个地址，Apache会使用select()以检测每个socket是否就绪。select()会表明一个socket有零或至少一个连接正等候处理。由于Apache的模型是多子进程的，所有空闲进程会同时检测新的连接。一个很天真的实现方法是这样的(这些例子并不是源代码，只是为了说明问题而已)：
for (;;) {
for (;;) {
fd_set accept_fds;
FD_ZERO (&accept_fds);
for (i = first_socket; i <= last_socket; ++i) {
FD_SET (i, &accept_fds);
}
rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
if (rc < 1) continue;
new_connection = -1;
for (i = first_socket; i <= last_socket; ++i) {
if (FD_ISSET (i, &accept_fds)) {
new_connection = accept (i, NULL, NULL);
if (new_connection != -1) break;
}
}
if (new_connection != -1) break;
}
process the new_connection;
}
这种天真的实现方法有一个严重的"饥饿"问题。如果多个子进程同时执行这个循环，则在多个请求之间，进程会被阻塞在select ，随即进入循环并试图accept此连接，但是只有一个进程可以成功执行(假设还有一个连接就绪)，而其余的则会被阻塞在accept 。这样，只有那一个socket可以处理请求，而其他都被锁住了，直到有足够多的请求将它们唤醒。此"饥饿"问题在PR#467中有专门的讲述。目前至少有两种解决方案。
一种方案是使用非阻塞型socket ，不阻塞子进程并允许它们立即继续执行。但是这样会浪费CPU时间。设想一下，select有10个子进程，当一个请求到达的时候，其中9个被唤醒，并试图accept此连接，继而进入select循环，无所事事，并且其间没有一个子进程能够响应出现在其他socket上的请求，直到退出select循环。总之，这个方案效率并不怎么高，除非你有很多的CPU，而且开了很多子进程。
另一种也是Apache所使用的方案是，使内层循环的入口串行化，形如(不同之处以高亮显示)：
for (;;) {
accept_mutex_on ();
for (;;) {
fd_set accept_fds;
FD_ZERO (&accept_fds);
for (i = first_socket; i <= last_socket; ++i) {
FD_SET (i, &accept_fds);
}
rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
if (rc < 1) continue;
new_connection = -1;
for (i = first_socket; i <= last_socket; ++i) {
if (FD_ISSET (i, &accept_fds)) {
new_connection = accept (i, NULL, NULL);
if (new_connection != -1) break;
}
}
if (new_connection != -1) break;
}
accept_mutex_off ();
process the new_connection;
}
函数accept_mutex_on和accept_mutex_off实现了一个互斥信号灯，在任何时刻只被为一个子进程所拥有。实现互斥的方法有多种，其定义位于src/conf.h(1.3以前的版本)或src/include/ap_config.h(1.3或以后的版本)中。在一些根本没有锁定机制的体系中，使用多个Listen指令就是不安全的。
AcceptMutex指令被用来改变在运行时使用的互斥方案。
AcceptMutex flock-
这种方法调用系统函数
flock()来锁定一个加锁文件(其位置取决于LockFile指令)。 AcceptMutex fcntl-
这种方法调用系统函数
fcntl()来锁定一个加锁文件(其位置取决于LockFile指令)。 AcceptMutex sysvsem-
(1.3及更新版本)这种方案使用SysV风格的信号灯以实现互斥。不幸的是，SysV风格的信号灯有一些副作用，其一是，Apache有可能不能在结束以前释放这种信号灯(见
ipcs()的man page)，另外，这种信号灯API给与网络服务器有相同uid的CGI提供了拒绝服务攻击的机会(所有CGI，除非用了类似suexec或cgiwrapper)。鉴于此，在多数体系中都不用这种方法，除了IRIX(因为前两种方法在IRIX中代价太高)。 AcceptMutex pthread-
(1.3 及更新版本)这种方法使用了POSIX互斥，按理应该可以用于所有完整实现了POSIX线程规范的体系中，但是似乎只能用在Solaris2.5及更新版本中，甚至只能在某种配置下才正常运作。如果遇到这种情况，则应该提防服务器的挂起和失去响应。只提供静态内容的服务器可能不受影响。译者注：此选项不能用于Linux。
AcceptMutex posixsem-
(2.0及更新版本)这种方法使用了POSIX信号灯。如果一个运行中的线程占有了互斥segfault ，则信号灯的所有者将不会被恢复，从而导致服务器的挂起和失去响应。
如果你的系统提供了上述方法以外的串行机制，那就可能需要为APR增加代码(或者提交一个补丁给Apache)。
还有一种曾经考虑过但从未予以实施的方案是使循环部分地串行化，即只允许一定数量的进程进入循环。这种方法仅在多个进程可以同时进行的多处理器的系统中才是有价值的，而且这样的串行方法并没有占用整个带宽。它也许是将来研究的一个领域，但是由于高度并行的网络服务器并不符合规范，所以其被优先考虑的程度会比较低。
当然，为了得到最佳性能，最后就根本不使用多个Listen语句。但是上述内容还是值得读一读。
单socket情况下的串行accept
上述对多socket的服务器进行了一流的讲述，那么对单socket的服务器又怎样呢？理论上似乎应该没有什么问题，因为所有进程在连接到来的时候可以由accept()阻塞，而不会产生进程"饥饿"的问题，但是在实际应用中，它掩盖了与上述非阻塞方案几乎相同的问题。按大多数TCP栈的实现方法，在单个连接到来时，内核实际上唤醒了所有阻塞在accept的进程，但只有一个能得到此连接并返回到用户空间，而其余的由于得不到连接而在内核中处于休眠状态。这种休眠状态为代码所掩盖，但的确存在，并产生与多socket中采用非阻塞方案相同的负载尖峰的浪费。
同时，我们发现在许多体系结构中，即使在单socket的情况下，实施串行化的效果也不错，因此在几乎所有的情况下，事实上就都这样处理了。在 Linux(2.0.30，双Pentium pro 166/128M RAM)下的测试显示，对单socket，串行化比不串行化每秒钟可以处理的请求少了不到3%，但是，不串行化对每一个请求多了额外的100ms的延迟，此延迟可能是因为长距离的网络线路所致，并且仅发生在LAN中。如果需要改变对单socket的串行化，可以定义SINGLE_LISTEN_UNSERIALIZED_ACCEPT ，使单socket的服务器彻底放弃串行化。
延迟的关闭
正如draft-ietf-http-connection-00.txt section 8所述，HTTP服务器为了可靠地实现此协议，需要单独地在每个方向上关闭通讯(重申一下，一个TCP连接是双向的，两个方向之间是独立的)。在这一点上，其他服务器经常敷衍了事，但从1.2版本开始被Apache正确实现了。
但是增加了此功能以后，由于一些Unix版本的短见，随之也出现了许多问题。TCP规范并没有规定FIN_WAIT_2必须有一个超时，但也没有明确禁止。在没有超时的系统中，Apache1.2经常会陷于FIN_WAIT_2状态中。多数情况下，这个问题可以用供应商提供的TCP/IP补丁予以解决。而如果供应商不提供补丁(指SunOS4 -- 尽管用户们持有允许自己修补代码的许可证)，那么只能关闭此功能。
实现的方法有两种，其一是socket选项SO_LINGER ，但是似乎命中注定，大多数TCP/IP栈都从未予以正确实现。即使在正确实现的栈中(指Linux2.0.31)，此方法也被证明其代价比下一种方法高昂。
Apache对此的实现代码大多位于函数lingering_close(位于http_main.c)中。此函数大致形如：
void lingering_close (int s)
{
char junk_buffer[2048];
/* shutdown the sending side */
shutdown (s, 1);
signal (SIGALRM, lingering_death);
alarm (30);
for (;;) {
select (s for reading, 2 second timeout);
if (error) break;
if (s is ready for reading) {
if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
break;
}
/* just toss away whatever is here */
}
}
close (s);
}
此代码在连接结束时多了一些开销，但这是可靠实现所必须的。由于HTTP/1.1越来越流行，而且所有连接都是稳定的，此开销将由更多的请求共同分担。如果你要玩火去关闭这个功能，可以定义NO_LINGCLOSE ，但绝不推荐这样做。尤其是，随着HTTP/1.1中管道化稳定连接的启用，lingering_close已经成为绝对必须。而且，管道化连接速度更快，应该考虑予以支持。
RelatedEntries：
gcc -fPIC/-fpic - 08 24, 2007
gcc浮点运算的一个编译选项 - 06 06, 2007
关于hash_map的一个例子 - 04 26, 2007
脚本 - 04 19, 2007
Internet Mathematics - 12 15, 2005