太诡异了，居然TCP也会丢包啊~~哪位牛人来解释一下！

[BORLANDSUN]

在写一个客户端，通过TCP协议实时接收远程的视频录播服务器传来的视频流。今天把图像调出来了，但是断断续续的，不很流畅。统计了下结果，丢包率大约在15%左右。
客户端用TClientSocket接收的，接收部分放在单独的一个线程中，处理部分也放在单独的一个线程中。CPU占用率很低，不到5%，真是怪呀。似乎线程的负载都不大，但丢包的确是发生了。
又作测试，把服务端的码流调低约1倍，这时客户端就基本上不丢包了，这是怎么回事呢？我猜是不是客户端的缓冲区太小了，给塞满了还是怎么回事。但如果塞满了，服务端应该会等我把数据取走才会继续发，也不应该丢包啊。不然他那边一直发，这不就变成UDP了吗。奇怪。
我把接收部分大致的代码也帖出来：

DWORD WINAPI OnFrame(PVOID pvParam)
{
	static ReceivedLen = 0;
	static char ReceiveBuffer[MaxBufLen];
	while(true)
	{
		int Len = sktClient->Socket->ReceiveBuf(&ReceiveBuffer[ReceivedLen], 1024000 - ReceivedLen);
		if(Len > 0)
		{
			ProcessData(CmdData, pos);    // 这个处理又是在另一个线程中做的
		}
	}
}

[BORLANDSUN]

[Quote=引用 1 楼 my_love 的回复:]
看SendBuf的返回值是-1，则过会而重发。
要不设成阻塞式，就不用管返回值。
[/Quote]
服务端对我来说是黑盒，不知道里边的运作模式。
[Quote=引用 2 楼 jonix 的回复:]
排除网络原因以外，一般都是程序自身的问题。
[/Quote]
这话说得太精辟了，但对于分析解决问题似乎没有帮助。

[My_Love]

看SendBuf的返回值是-1，则过会而重发。
要不设成阻塞式，就不用管返回值。

[Jonix]

排除网络原因以外，一般都是程序自身的问题。

[周药师]

用抓包工具看看,看实际收到的是不是 你发出的总和 ，这样就知道问题在哪里了

[My_Love]

[Quote=引用 3 楼 borlandsun 的回复:]

引用 1 楼 my_love 的回复:
看SendBuf的返回值是-1，则过会而重发。
要不设成阻塞式，就不用管返回值。

服务端对我来说是黑盒，不知道里边的运作模式。
引用 2 楼 jonix 的回复:
排除网络原因以外，一般都是程序自身的问题。

这话说得太精辟了，但对于分析解决问题似乎没有帮助。
[/Quote]
我想说的是，这个丢包十有八九不是在网络传输时丢的，而是服务器压根就没有发出去。

[BORLANDSUN]

[Quote=引用 4 楼 boyla 的回复:]

　　楼主，在TCP上传输实时视频数据，你也太牛了吧！不好意思，问你一个小问题：有哪家成熟的视频网站或视频服务商是用的TCP传输数据？我的答案是没有！视频数据天生就是要用UDP传输的！

如果是局域网环境，TCP可能勉强能用，这还要取决于程序实现的如何，反正我是没这么干过。

说一点基本认识吧：之所以视频数据要用UDP协议处理，一个原因就是因为视频数据量很大，要快，另一个原因是因为视频数据……
[/Quote]
这位大哥：
1. 我不牛，那家提供视频服务器的公司提供的的确是TCP接口
2. 你的“小问题”在1.我已经回答了

[aranjuze]

是不是带宽的原因啊！

[土著巫师]

　　楼主，在TCP上传输实时视频数据，你也太牛了吧！不好意思，问你一个小问题：有哪家成熟的视频网站或视频服务商是用的TCP传输数据？我的答案是没有！视频数据天生就是要用UDP传输的！

　　如果是局域网环境，TCP可能勉强能用，这还要取决于程序实现的如何，反正我是没这么干过。

　　说一点基本认识吧：之所以视频数据要用UDP协议处理，一个原因就是因为视频数据量很大，要快，另一个原因是因为视频数据丢帧影响相对有限，因为前一帧丢了，后一帧补上了不影响视觉效果，只有连续的丢帧才会有问题（如果你传一个文件哪怕丢了一个字节，后果是什么不用我来说，所以FTP是建立在TCP协议上工作的，所有用UDP传输文件的都要程序员引入流控制和丢包处理，相当于自己在应用层实现了部分TCP协议功能）；另一个原因，UDP的组播特性设计就是为视频服务设计的：数据只发送一次，大家都收到，想想看同一个子网上不可能１００个用户，发送１００次同样的视频数据吧？

　　简单聊几句，希望对楼主在总体设计（不是实现）思路上有帮助。：）

[日立奔腾浪潮微软松下联想]

[Quote=引用 5 楼 my_love 的回复:]
我想说的是，这个丢包十有八九不是在网络传输时丢的，而是服务器压根就没有发出去。
[/Quote]

正确，应该是TCP流量控制造成的。

[BORLANDSUN]

问题找到了，还真是视频服务器的问题。唉，那帮鸟人们，在外企拿那么高的工资，写这么烂的代码，换我早自杀了。
大学里老师没教好啊，放出来这样一帮渣子来到社会上，毒害人类！
结帖，放分！

[BORLANDSUN]

[Quote=引用 9 楼 zhouzhangkui 的回复:]

用抓包工具看看,看实际收到的是不是 你发出的总和 ，这样就知道问题在哪里了
[/Quote]
那边发包不是我控制的，所以不知道到底发多少
手头没有抓包工具，但从任务管理器中看，画面卡住的时候，网络流量的确是下去了。