.net NET中TCP应用服务器的技术

我们正在使用服务器组件扩展现有应用程序（.NET with SQL Server）。该组件扮演两个角色：它执行后台任务（长时间运行的计算和类似cron作业的任务），并通过向本地网络上运行的应用程序提供API，充当应用程序服务器

问题是：应该使用哪些技术（在.NET世界中）来实现应用服务器bit。要求如下：

• 应该易于安装，只有很少的依赖项
• 与服务器的所有通信应可靠、加密， 通过服务器和客户端的身份验证
• 吞吐量不如响应时间重要（<100次呼叫/分钟 其次，每个请求都应该毫不延迟地得到响应（比如 通过TCP连接使用SELECT 1查询sql server）；我猜 这意味着通过使用 发送/接收请求
• 许多调用将具有沉重的二进制负载（基本上是客户端） 请求或发送文件，主要在1到5 mb之间）
• 可扩展且经得起未来考验
• 有能力在将来的某个时候使API“公开” 未来，以便第三方应用程序可以使用它 （SOA风格），无需添加另一个服务器组件 （并在防火墙中打开另一个端口）

实际上，这个应用服务器目前最大的任务是提供文件，并允许上传这些文件的修订版

我花了相当多的时间环顾网络，并提出了以下可能的方法/技术列表：

• 纯TCP，其顶部有自己的协议。（往这边走是最好的 优点：经得起未来考验，灵活， 高效，SSL适度易于添加（）， 面向连接（即，在应用程序运行时打开TCP套接字） 启动、应用程序结束时关闭、SSL握手和 身份验证只执行一次）。缺点：没有标准 第三方可以很容易地与之集成 发展模式
• ASMX Web服务。优点：基于 WSDL/Soap、SSL易于添加，代码生成隐藏了混乱的实现细节。缺点：不是 经得起未来考验，只有HTTP上的SOAP，文件传输效率不高 （XML中的base64），需要IIS来承载（因此不容易安装）
强> Windows通信基础（WCF）。优点：很多人支持 绑定（其中一些是开放标准，如WSDL/Soap）， 由于可以同时公开多个接口，SSL很容易 添加，代码生成，可以托管在任何.NET进程中（因此易于 安装），使用NetTcpBinding WCF似乎非常有效（尽管第三方完全无法使用）。缺点：学习曲线
• ASP.NET Web Api。缺点：仅在托管时需要IIS REST/HTTP。虽然REST可能是提供文件的完美工具，但更丰富的 其他一些功能需要接口
• .NET远程处理。被WCF取代

基于这一点，似乎WCF是未来的发展方向

问题1:我是否遗漏了上述列表中的一些重要技术/缺点/优点

问题2:具有该领域专业知识的人是否同意WCF是实现上述要求的途径

---

问题3:WCF的效率如何？看到这样的问题，我不禁怀疑，不以连接为导向是否不会成为性能问题。这篇文章描述了在一段时间的不活动之后，响应时间如何增加到数百毫秒。此外，为每个请求创建SSL握手似乎效率很低。

使用您自己的协议不是未来的证明，因为您是唯一能够支持它的人。这也比必要的工作多得多

WCF是一个久经考验的真正的框架，它几乎可以满足您的任何服务需求。您可以创建单个服务（类/接口），并根据您的需求以不同的方式公开它，这意味着同一服务可以是外部客户端的Https外部端点、tcp.net内部端点和REST端点，所有这些都可以同时使用一些附加配置

---

WCF已经存在很长一段时间了，它不会去任何地方。除此之外，网络上还有大量的支持/信息

纯TCP有更多的缺点：您可能需要创建自己的主机。那么重新部署呢？需要先关机，然后停机

在我看来，下一步是测试WCF配置，看看是否可以降低延迟。显然，100毫秒不可能是“正常的”。使用连接池时，我希望使用通常的网络延迟加上少量的CPU时间来处理请求。可能小于1ms

---

如果你能让WCF工作，那么所有其他要点都将变得毫无意义，因为WCF显然是除了性能要求之外的最佳选择。

忘记Web服务吧，它们太慢了

我会在UDP或TCP之上使用自己的协议。它速度快，重量轻，易于伸展。你只需要很好地记录你的协议。 套接字通信是一个标准

---

我从未使用过WCF。

我不理解你的第一段。“创建您自己的主机”是什么意思？您可能需要创建一个Windows服务来打开套接字、接受连接并处理它们。如果您使用像IIS这样的现有主机，所有这些都是免费的。缓慢调用所有Web服务技术和实现是非常不具体的。每个Web服务技术和实现都会增加开销。当然，开发速度更快，但与普通套接字通信（UDP或TCP）相比，它的运行速度要慢得多，另一方面，开发时间要短得多