没有银弹
实际上，这取决于...
tl; dr-简单的解决方案，使用nginx ...
封锁：
例如，Apache默认使用阻塞方案，该过程为每个连接派生该进程。这意味着每个连接都需要自己的内存空间，并且随着连接数量的增加，上下文切换的开销也随之增加。但是好处是，一旦关闭连接，就可以处理上下文，并且可以轻松检索任何/所有内存。
多线程方法的相似之处在于上下文切换的开销随连接数的增加而增加，但在共享上下文中可能会提高内存效率。这种方法的问题在于，很难以安全的方式管理共享内存。解决内存同步问题的方法通常包括它们自己的开销，例如，锁定可能会冻结CPU密集型负载上的主线程，并且使用不可变类型会增加很多不必要的数据复制。
AFAIK在阻塞的HTTP服务器上使用多进程方法通常是首选，因为以安全的方式管理/恢复内存更安全/更简单。当恢复内存就像停止一个进程一样简单时，垃圾回收就不会成为问题。对于长时间运行的进程（即守护程序），该特性尤其重要。
尽管上下文切换的开销对于少量的工作人员而言似乎微不足道，但是随着负载扩展到数十万个并发连接，缺点变得更加重要。充其量，上下文切换将O（n）缩放为当前的工作人员数量，但实际上，情况最可能恶化。
在使用阻塞的服务器可能不是IO重负载的理想选择的情况下，它们是CPU密集型工作的理想选择，并且消息传递保持在最低限度。
非阻塞：
非阻塞将类似于Node.js或nginx。这些以在IO密集负载下将每个节点的连接数扩展到更多而特别众所周知。基本上，一旦人们达到了基于线程/进程的服务器可以处理的上限，他们便开始探索其他选择。否则，这称为C10K问题（即处理10,000个并发连接的能力）。
非阻塞异步服务器通常具有带锁多线程的方法，它们具有很多特性，因为您不希望使主线程超载，因此必须小心避免占用大量CPU资源。优点是，基本上消除了上下文切换所引起的开销，并且仅通过一个上下文消息传递就不会产生问题。
尽管HTTPs无状态性质可能不适用于许多网络协议，但它对于非阻塞体系结构尤其有效。通过结合使用反向代理服务器和多个非阻塞HTTP服务器，可以识别并在承受高负载的节点周围进行路由。
即使在只有一个节点的服务器上，通常也要在每个处理器内核中包含一台服务器以最大化吞吐量。
都：
“理想的”用例将是两者的结合。前端的反向代理致力于在顶部路由请求，然后是阻塞服务器和非阻塞服务器的混合。不阻塞IO任务，例如提供静态内容，缓存内容，html内容。阻止执行CPU繁重的任务，例如对图像/视频进行编码，流式传输内容，数字运算，数据库写入等。
在您的情况下：
如果您只是检查标头，但实际上并未处理请求，那么您实质上要描述的是反向代理。在这种情况下，我肯定会采用异步方法。
我建议您查看有关nginx内置反向代理的文档。
在旁边：
我从您提供的链接中阅读了本文，因此对于特定的实现，异步是一个糟糕的选择。这个问题可以用一个陈述来总结。
发现在客户端之间切换时，用于保存和恢复值/状态的代码很困难
他们正在建立一个有状态的平台。在这种情况下，异步方法将意味着您每次上下文切换时（即，事件触发时）都必须不断保存/加载状态。此外，在SMTP方面，他们正在做大量CPU密集型工作。
听起来他们对异步的掌握很差，结果做出了很多错误的假设。