套接字对HttpListener

Question

我正在创建一个代理，它侦听特定端口上的传入连接。连接通常是Http请求(GET/POST)。无法决定是选择HttpListener还是套接字。我将在代理中修改HttpRequests，然后将其中继到最终目的地。

你什么时候喜欢HttpListener而不是套接字。每种方法的好处是什么？

Answer 1

• HttpListener 的优势
  • 允许使用http.sys与其他进程共享端口(包括使用HttpListener或IIS的进程，只要前缀是唯一的)
  • Http.sys为您使用I/O完成端口，很难在不使用TcpListener的情况下自行设置
  • HttpListener解析headers并为响应创建headers
  • 提供一组类，这些类非常类似于ASP.Net中公开标题、cookie等的类。

​

• HttpListener 的缺点
  • 主要的- Localhost客户端通过发送大的有效载荷，与TcpListener或Mono的HttpListener相比，这些有效负载的多个副本将被复制。如果需要每个CPU的最大吞吐量，应避免在同一台计算机上的进程之间发送大型(例如5MB以上)的POST体。考虑使用内存映射文件(基本上是共享内存)。当客户端和服务器在不同的机器上时，这些额外的副本不是问题。
  • 不允许显式控制TCP套接字打开的时间；http.sys为您管理这一点(这通常不是一个巨大的缺点，但它只是需要注意的事情)。
  • header/cookie类中的任何but都会咬到您；例如设置多个Cookie将导致HttpListener返回一个包含多个Cookie的集合Cookie头，IE将处理这个问题，但Chrome将完全忽略(然后您必须手动滚动Cookie并添加您自己的集合-Cookie标头来处理这个问题)。

​

• TcpListener 的优势
  • 与HttpListener类似，它为您实现了I/O完成端口
  • 如果您想为一个连接执行一次(如check )，您可以这样做，因为您知道何时打开套接字；但是，出于其他原因，您可能不想依赖这个(代理和负载平衡器可能通过同一个套接字发送来自多个用户的请求)。

​

• TcpListener与HttpListener 的缺点
  • 您必须提供一个HTTP头解析器
  • 您必须验证HTTP请求是否有效

​

• 在你自己的上100%滚动这个的优点
  • 与使用TcpListener相比，我想不出任何

​

• 在你自己的上100%滚动这个的缺点
  • 您可能会在网络层代码中引入许多不必要的/不正确的锁，这不会在一次测试单个请求的性能时造成任何问题，但会导致负载下的性能严重受损。需要一段时间才能找到并修复它们。
  • 我们在一个项目中自己完成了这个任务，并且通过更多的几个月的编码和无法维护的代码库，我们实现了与HttpListener相同的性能。我们把它去掉，用HttpListener替换了所有的自定义代码，没有任何负面的性能影响，维护的代码也少了很多。

​

2016年11月更新:当接收远程计算机的流量时，HttpListener工作得很好。然而，当客户端在本地主机上时，HttpListener对于大的有效负载来说是一个糟糕的选择，从性能上讲。造成这种情况的部分原因是因为HttpListener使用了http.sys (这是一个内核模块)，而且很明显，实现会导致身体数据的几个额外副本被生成。例如，在C#中将100 MB从一个数组复制到另一个数组需要35 ms，而POSTing 100 MB从本地客户端复制到HttpListener需要350 ms (是的，长10倍)。在这种情况下，切换到Mono的HttpListener将时间缩短到250 ms。与套接字客户端一起使用TcpListener需要180 ms。使用CircularBuffer交换套接字使用MemoryMappedFiles需要55 ms。因此，当从本地机器访问时，HttpListener对于大的有效负载就不能很好地工作。注意:如果你试图复制这个测试，你需要注意测量时差。Stern开始发送数据，并且当数组在接收过程中完成填充时，一些发送/写入方法几乎立即返回，而不发送任何数据(您可以通过发送一个零数组，然后从数组的后面写入数据，使其成为前沿；您将接收几乎所有的数据，证明数据是在函数返回后很久才发送的)。

关于HttpListener对Mono的HttpListener的本地机器性能缺陷的更多详细信息，来自我的同事之一：https://www.linkedin.com/pulse/http-inefficiency-dominika-blach