我知道这是一个普遍的问题，但我需要您对TCP服务器/客户端应用程序的建议。
服务器一次只能处理一个连接。 服务器正在向连接的客户端发送实时图像（一帧约为50K，每秒20帧）。
实际上，在服务器和客户端应用程序的启动时建立连接，理论上这个连接应该永远保持活着。
我的观点是，由于服务器正在发送实时图像，因此延迟必须最小，因此编写此类（简单）tcp服务器和客户端的最佳做法是什么，以及如何序列化/反序列化图像以便“最小化”推迟“目标实现？
提前致谢，
此致
答案 0 :(得分：1)
一种方法是使用UDP而不是TCP发送数据。
如果这样做，可能会丢失一些UDP数据包（由网络丢弃），因此您的代码需要一种方法（例如数据包标头中的序列号）来检测丢失的数据包。
如果TCP数据包丢失，则TCP将重新传输它，这会导致延迟。对于您的应用程序，有可能在数据包丢失时您可能只想做没有丢失的数据包，不重新发送它，不显示此视频帧（或仅显示部分帧），然后继续显示下一个数据包帧。
这取决于应用程序：
您是否正在流式传输预制/预录/非实时视频，您希望接收/显示每个帧，即使其中一些会导致延迟？
< / LI>您是否正在直播视频，您希望以近乎实时的方式显示当前帧（即使之前的某些帧丢失，您也不希望在重新传输时延迟）？
就winsock体系结构而言，TransmitFile或TransmitPackets API非常有效：它们在内核中执行，而不是导致用户模式代码和O / S内核模式之间的往返传输每个缓冲区的代码。
实现“最小延迟”目标
您可能需要一些延迟，以避免抖动：更好的是具有小的（例如150毫秒）固定延迟，而不是从2到120毫秒的延迟。见http://www.google.ca/search?hl=en&q=jitter+network
答案 1 :(得分：0)
我不是超级权威，但是......
我们做一些数学运算。每个图像50K（这个字节，对吧？），每秒20帧，大约是每秒1兆字节。在通信方面，这是每秒10兆比特。这是一个公平的，但非常可行。确保你有100兆位的设备。
最快的API是无聊的旧阻止“发送”和“recv”调用（* 1）。还有其他调用Windows IO类型完成端口和诸如此类的东西;不要将它们用于此应用程序（因为（a）它们是过度的，（b）它们使应用程序更具可扩展性）
考虑关闭Nagle（NODELAY选项）。
（* 1）可能。关于实际最快的Winsock呼叫的实际文献严重缺乏。