套接字上的线程太慢

Question

我正在为移动机器开发一个服务器，该服务器使用Visual Studio Express 2013实现套接字服务器以接收其连接。

它使用Net.Sockets.TcpListener.AcceptSocket将连接分配给一个Net.Sockets.Socket。它为每个创建的新套接字启动一个新的Threading.Thread，并有一个while周期来接收、解析和写入数据到套接字。它使用属性x.Available获取数据计数，并使用x.Receive读取该数据。它解析接收到的数据并创建答案。最后它使用x.Send（应答缓冲区、应答数据、Net.Sockets.SocketFlags.None）来传输答案。

代码在接收和发送答案时工作正常，但速度很慢。

我对代码进行了一些检查，以获得代码每次操作所用的时间，并得到了平均值：-套接字从缓冲区读取并复制数据到（字节）列表：100-200毫秒-数据解析和创建应答缓冲区列表（字节）：150-300毫秒-将缓冲区列表转换为（字节）缓冲区数组，然后套接字发送：70-200毫秒

请记住，数据包的数据接收长度约为150字节，数据传输长度约为100字节，线程每个执行部分的时间都很高。因此，当服务器接收到更多的连接时，答案会减慢或停止一段时间。

这种为服务器上的每个连接使用Socket和Thread的方法不好吗？我是否要搜索其他类来管理数据流或线程并行执行？Visual Studio Express对使用线程有一些限制吗？

谢谢你的帮助。马提欧




Answer 1

这种对服务器上的每个连接使用套接字和线程的方法是否不好？

是的，非常糟糕。线程根本无法伸缩，另外：如果您在每个套接字上使用线程，则实际上可以保证会出现意外或恶意DDOS。

如果您只连接到几个套接字，您几乎可以在客户端摆脱每个套接字的线程。在服务器上：那只是死亡。

服务器套接字IO几乎总是使用异步IO来完成。这很快就变得复杂了，尤其是当谈到后台缓冲等时，但是:在modern中有一个全新的API可用。NET的这个场景:“管道”——为你处理所有的线程、内存池和后台缓冲管理。不过，它真的不能在Visual Studio 2013上运行，所以...可能的话更新？如果你感兴趣的话，我有一篇关于使用管道的文章。

如果这不可能，那么一个好的起点可能是类似SocketAsyncEventArgs的东西，但同样：这是一个非常深的兔子洞，坦白地说，它基本上是一个已解决的问题。如果您可以切换到预滚装实现，我建议您这样做。