3) 单socket中的accept串行化
以上言及的方案对多socket服务器是相当不错的，但只有一个socket的情况又如何呢？理论上，由于在连接请求到来之前所有子进程将阻塞在accept中，单个socket不会产生上述种种问题。但实际上，上述非阻塞解决方案所带来的"回旋（spinning）"问题在这里只不过被掩盖起来了。在绝大多数TCP协议栈的实现中，一个接请求到来时内核将唤醒所有阻塞在accept中的进程。它们之一将得到此请求并返回用户空间，其余的进程将返回内核重新休眠。这将带来与多socket非阻塞解决方案相同的资源浪费。
由于这点原因，我们发现如果为socket串行化，许多系统表现得更"友好"--即使是一个socket的情况。这是单个socket串行化作为绝大多数情况的缺省配置的原因。在Linux上不甚精确的（Linux 2.0.30 / 双Pentium Pro 166 w / 128Mb内存）实验表明，对每次请求而言，串行化的单个socket仅比没有串行化的socket损失不到3%的性能。但未串行化的socket显示出每次连接请求100毫秒的延时。这也可能仅仅由于过长的通讯距离造成的。如果您不想串行化单个socket，可以定义宏SINGLE_LISTEN_UNSERIALIZED_ACCEPT。这样，仅有一个socket的服务器将不会串行化。
4) 延迟关闭（Lingering Close）
就象draft-ietf-http-connection-00.txt第8节讨论的那样，为了使服务器能够可靠地实现HTTP协议，有必要独立地关闭每个方向上的通讯（每个TCP连接有两个方向，每个方向是分别独立的）。这个事实往往被其他服务器所忽视，而Apache 1.2就已经正确地处理了。
当这个特性增加到Apache中时却在许多版本的Unix中引起了问题。这是TCP规范的短见造成的--它没有声明FIN_WAIT_2有超时，但也没有阻止这样的实现。在没有超时的系统中，Apache 1.2将导致许多socket将永远处于FIN_WAIT_2的状态。这可以简单地用打最新TCP/IP补丁的方法避免。然而在提供商从不发行补丁的系统上（也就是SunOS4--虽然得到源代码许可证的人可以自己打补丁），我们决定不直接使用这一特性。
