我正在创建一个代理，它在特定端口上监听传入连接。连接通常是 Http 请求 (GET/POST)。无法决定我应该选择 HttpListener 还是 Sockets。我将修改代理中的 HttpRequests，然后将其中继到最终目的地。
什么时候你更喜欢 HttpListener 而不是 Sockets。各有什么好处？
HttpListener 的优点
允许与其他使用 http.sys 的进程共享端口(包括使用 HttpListener 或 IIS 的进程，只要前缀是唯一的) Http.sys 为您使用 I/O 完成端口；如果不使用 TcpListener 自己设置它是非常困难的
HttpListener 解析 HTTP header 并为响应创建 HTTP header 为您提供一组与 ASP.Net 中的类非常相似的类，用于公开标题、cookie 等。 HttpListener 的缺点
专业 - 与 Windows 上的 TcpListener 或 Mono 的 HttpListener 相比，Localhost 客户端通过 HTTP 发送大型有效载荷会导致这些有效载荷的几个额外副本。如果需要每个 CPU 的最大吞吐量，则应避免在同一台机器上的进程之间发送大型(例如超过 5 MB)POST 正文。考虑改用内存映射文件(本质上是共享内存)。当客户端和服务器在不同的机器上时，这些额外的副本不是问题。 不允许显式控制 TCP 套接字打开的时间； http.sys 为您管理这个(这通常不是一个巨大的缺点，但它只是需要注意的事情)头文件/cookie 类中的任何错误都会咬你；例如设置多个 cookie 会导致 HttpListener 返回一个包含多个 cookie 的单个 Set-Cookie header 的问题，IE 将处理该 header ，但 Chrome 将完全忽略(然后您必须手动滚动 cookie 并添加您自己的 Set- Cookie header 来解决此问题) TcpListener 的优点
和 HttpListener 一样，它为你实现了 I/O 完成端口 如果你想为一个连接做一次(比如检查身份验证)，你可以这样做，因为你知道套接字是什么时候打开的；但是，由于其他原因，您可能不想依赖它(代理和负载均衡器可能会通过同一个套接字发送来自多个用户的请求) TcpListener 与 HttpListener 的缺点
你必须提供一个 HTTP 头解析器 您必须验证 HTTP 请求是否有效 自己滚动 100% 的优势
与使用 TcpListener 相比，我无法想到
自己滚动 100% 的缺点
您可能会在您的网络层代码中引入许多不必要/不正确的锁，这在一次测试单个请求的性能时不会造成任何问题，但会导致负载下的性能真正受到影响。找到这些并修复它们需要一段时间。 我们确实在一个项目中自己实现了这一点，我们实现了与 HttpListener 相同的性能，但需要更多的编码时间和无法维护的代码库。我们删除了它并用 HttpListener 替换了所有自定义代码，而没有任何负面性能影响，并且需要维护的代码大大减少。 2016 年 11 月更新:HttpListener 在接收来自远程机器的流量时运行良好。但是，当客户端位于本地主机上时，对于大型有效负载，HttpListener 在性能方面是一个糟糕的选择。部分原因是 HttpListener 使用 http.sys，它是一个内核模块，显然该实现导致要制作多个额外的正文数据副本。例如，在 C# 中将 100 MB 从一个数组复制到另一个数组需要 35 毫秒，而从本地客户端向 HttpListener POST 100 MB 需要 350 毫秒(是的，长 10 倍)。在这种情况下切换到 Mono 的 HttpListener 会将时间降低到 250 毫秒。将 TcpListener 与 Socket 客户端一起使用需要 180 毫秒。使用 MemoryMappedFiles 为 CircularBuffer 交换套接字的使用需要 55 毫秒。因此，当从本地机器访问时，HttpListener 对于大型有效负载不能很好地工作。注意:如果您尝试重现此测试，则需要注意测量时间差。 Stern 开始发送数据，当数组在接收过程中完成填充时，因为一些发送/写入方法几乎立即返回而不发送任何数据(您可以通过发送一个零数组然后从数组的后面朝向前面；您将收到几乎所有的数据，证明数据是在函数返回后很久才发送的)。
我的一位同事提供了有关 HttpListener 与 Mono 的 HttpListener 的本地机器性能缺陷的更多详细信息:
https://www.linkedin.com/pulse/http-inefficiency-dominika-blach