我目前正在阅读WCF和套接字（此处和MSDN上）。
从我看到的WCF比套接字慢但更容易使用。
具有以下情况：
服务器响应的范围可以从收到消息到传输200 MB数据。
所有通信都已加密（示例SSL）
我的目标是尽可能安全地处理所有通信（在例外，超时等问题方面是安全的），并且这很容易维护程序。
此外，数据越少传输密集请求/响应需要快速（因此只传输几KB数据）。
我的问题是，WCF比套接字慢.....将WCF仍然足够快以处理如此大的系统/情况，或者套接字是更好的方式吗？
编辑： 正如评论中所提到的，ASP.NET和其他基于Web的解决方案也可以做这些，所以不仅普通的套接字而且还有websockets感兴趣（web套接字与wcf不应该比套接字与wcf差别很大）。
答案 0 :(得分：1)
Websockets的工作级别低于WCF，因此在这个意义上它也会“更快”。
但首先我会质疑你是否真的需要这种额外的速度？ 这有点像问你是否应该购买法拉利而不是Mini，因为法拉利更快。
是的，但除非你总是需要以200公里/小时的速度比赛，否则你将无法获得任何好处，特别是在速度限制在50公里/小时的道路上！
您需要首先确定您的真正需求。客户端数量（500）以及偶尔大量响应的大小不会产生太大影响。您需要确定每秒需要处理的请求数。这些请求的平均大小。然后根据您所需的带宽。
请记住，无论您使用何种技术，物理电缆（或WiFi网络）都以完全相同的速度运行。所以实际上“速度”不是问题，但带宽或延迟可能是。
通过使用正确的架构来处理您的请求，可以解决这些问题。这意味着能够扩展您的应用程序以满足您的需求。
因此，您需要确定应用程序中的瓶颈是什么。 例如：您的服务器必须对收到的数据执行某些操作，或者将其写入数据库。这可能是您的瓶颈，因此Websockets或WCF对您每秒可处理的操作数没有影响。
同样，如果您的服务器是单线程的，那么它不会扩展，所以再次使用的技术没有区别，这不是您的问题。
也许你过分关注一个方面，而不是更大的方面。我想你这里可能有点XY problem！
我也发现了这些，这可能很有趣; https://msdn.microsoft.com/en-us/library/bb310550.aspx
WCF performance, latency and scalability
http://www.ganshani.com/blog/2014/02/optimizing-performance-of-your-wcf-services/
http://theburningmonk.com/2010/05/wcf-improve-performance-with-greater-concurrency/
我相信你能找到更多