我试图从哪里开始了解什么可能会导致套接字停顿的起点，并希望你可能有任何见解。
因此，服务器是运行Windows 2012的现代双插槽至强（2 x 6核@ 3.5 GHz）。在一个进程中，有6个阻塞tcp套接字默认选项，其中每个都运行在自己的线程（不numa /核心指定）。 其中5个连接到相同的远程服务器，并承受非常沉重的负载（每秒数十万小~75字节）。 最后一个套接字连接到另一台服务器，具有非常轻的发送/接收负载，用于pipe理消息传递。
我遇到的问题是pipe理消息传递套接字中的5秒钟的停顿。 多次向套接字发送调用成功返回，但是没有收到远程服务器（应该在毫秒内接收到协议确认）或远程pipe理服务器接收到5秒。 就好像这个sockets刚closures了一下。 5秒钟后，所有的acks都爆了，之后一切正常。 在这期间，其他套接字接收的信息数量比正常多得多，但没有任何中断或停顿的迹象，因为数据日志没有任何exception（光logging，可能是500个信息/秒）。
据我所知，套接字发送调用不能确保数据已经在电线上，只是传输到TCP堆栈是成功的。 所以，我试图了解可能发生的不同情况，这将导致pipe理套接字上出现5秒的停顿。 是否有可能由于接收到大量的数据，tcp堆栈基本上已经不堪重负，并且优先考虑那些使用率最高的套接字？ 还有什么其他情况可能造成这种情况？
谢谢！
如果套接字每秒接收数十万个75字节的消息，那么服务器有可能使用一些资源达到最大容量。 也许不是带宽，比如10Kbps左右可能消耗的100K信息。 但是这可能是CPU利用率。
你应该使用两个工具来理解你的问题：
发送调用成功返回并不意味着数据立即发送。 在TCP数据将被存储在发送缓冲区，并从那里，TCP堆栈将数据发送到另一端。
如果你的系统是CPU绑定的（你可以用perfmon来看，如果这是真的），那么你应该注意@EJP写的注释，这是在机器负载很重时可能发生的事情。 通过我提到的工具，您可以看到管理套接字中的接收窗口是否关闭，或者是否只是该套接字读取在管理套接字中花费时间。