NET中的TCP应用程序服务器的技术

Question

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

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

• 应该很容易安装，只有很少的依赖关系。
• 与服务器的所有通信应该是可靠的，加密的， 与服务器和客户端验证。
• 吞吐量不如响应时间（< 100次调用每 秒），每个请求都应该没有延迟地应答（例如当通过TCP连接向SELECT服务器查询SQL服务器时）。我想 这意味着尽可能少的开销 发送/接收请求的技术。
• 许多调用将有一个沉重的二进制有效载荷（基本上客户端 请求或发送文件，主要在1和5 MB之间）。
• 是可扩展的和未来的证明。
• 有能力使API在未来某个时间点处于“公开”状态，以便第三方应用程序可以使用它（SOA风格），而无需添加另一个服务器组件 （并打开防火墙中的另一个端口）。

实际上，此应用程序服务器的最大任务（目前）是提供文件，并允许上传这些文件的修订。

我花了相当长的时间环视网，并与可能的方法/技术的下面的列表上来：

• 纯TCP，顶部自己的协议。 （这种方式是我的情况下的 膝盖反应）优点：面向未来，灵活，高效，SSL适中易于添加（described here）， 面向连接（即在打开TCP套接字时应用程序 启动，当应用程序结束时关闭它，SSL握手和 验证只执行一次）。缺点：没有什么标准 与第三方可以轻松整合，原始 发展模式。
• ASMX Webservice。优点：基于标准接口的WSDL/Soap基于 ，SSL易于添加，代码生成隐藏了凌乱的实现细节。缺点：不是 面向未来，只有基于HTTP的SOAP，对于文件传输效率不高 （XML中的base64），需要IIS进行托管（因此不易安装）。
• Windows Communication Foundation（WCF）。优点：许多支持 的绑定（其中一些是像WSDL/Soap这样的开放标准）， 可能同时暴露几个接口，SSL很容易添加，代码生成，可以托管在任何。NET进程（因此很容易到 安装），使用NetTcpBinding WCF看起来非常有效（尽管第三方完全无法使用）。缺点：学习曲线。
• ASP.NET Web Api。缺点：需要IIS进行托管，只有 REST/HTTP。虽然REST可能非常适合用于提供文件，但其他一些功能需要更丰富的接口 。
• .NET Remoting。被WCF所取代。

基于此，它看起来好像是WCF的路要走。

问题1：我是否在上面的列表中缺少一些重要的技术/缺陷/优点？

问题2：那些在该领域具有专业知识的人是否同意WCF是完成所述要求的方式？

问题3： WCF的效率如何？看到诸如this one这样的问题，让我怀疑是否面向连接不会是一个性能问题。这篇文章描述了在一段时间不活动之后，响应时间如何增加到几百毫秒。而且，为每个请求创建SSL握手似乎效率非常低。

Answer 1

使用自己的协议不是未来的证明，因为你是唯一可以支持它的人。这也是比必要的更多的工作。

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

WCF已经存在很长时间了，它不会去任何地方。最重要的是，网络上有大量的支持/信息。

Answer 2

纯TCP有更多的缺点：您可能需要创建自己的主机。怎么样重新部署？需要先关机并停机。

在我看来，你的下一步将是测试WCF配置，并找出是否可以使延迟下降。显然，几百毫秒不能“正常”。通过连接池，我希望通常的网络延迟加上少量的CPU时间来处理请求。可能< 1ms。

如果你可以让WCF工作，所有其他的点将变得没有意义，因为除了性能要求外，WCF显然是最好的选择。

Answer 3

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

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

WCF我从来没有用过。