UDP文件传输在什么场合有优势？-CSDN社区

舞夜幽灵之雏 2013-09-26

打赏
举报

高手好，我现在也在研究用喷泉码改善UDP传输文件的性能方面的问题，我觉得如果做好了会很有前景，不知道你对这个还有没有研究的兴趣。如果有的话可以加我QQ：931080784

Squall_zy 2013-08-13

打赏
举报

UDP传输文件是可以的，但是并不主流。至少制定TCP/IP的人并不希望用UDP来干这个。至于你们说UDT之类的有市场，那仅仅是特定情况下、特定需求下罢了。毕竟，你在应用层做“顺序到达、重传机制、保证正确性”的工作，肯定要比在传输层同样的事情效率低多了。

Sandrer 2013-08-13

打赏
举报

参照Windows，网络传输文件都是用TCP

halleyzhang3 2013-08-12

打赏
举报

引用 46 楼 Sandrer 的回复:

UDP 是广播 TCP 是点对点一个 TCP 连接只能对另一个 TCP（多一个客户端就要再+一个 TCP 连接）而 UDP 可以用广播功能，客户端不用连接到服务器，只需读相应地址及端口就会有数据

的确局域网广播用UDP更好，但用UDP传文件的也不都是广播。广播方案的话，丢包怎么解决是个问题，一对一的时候可以重传。我的对策是喷泉码，广播没问题。

Sandrer 2013-08-12

打赏
举报

UDP 是广播 TCP 是点对点一个 TCP 连接只能对另一个 TCP（多一个客户端就要再+一个 TCP 连接）而 UDP 可以用广播功能，客户端不用连接到服务器，只需读相应地址及端口就会有数据

halleyzhang3 2013-08-12

打赏
举报

就这样吧，明天结贴了

tcmakebest 2013-08-11

打赏
举报

单线程的TCP操作简单啊，太简单了，而且速度也不慢，就那么几M带宽，全速的TCP，只需要一个

halleyzhang3 2013-08-10

打赏
举报

基本搞清楚了，主要是三种需求：广域网上的GB级网速时的大文件传输；向大量用户的广播传输；半双向或高延迟的网络环境，如卫星。抽取了几个这类工具自己的介绍 ExpeDat is high-performance file transfer software. Fast Reliable Easy 100% utilization of available bandwidth. ExpeDat keeps data moving when others fail. Self-contained clients require no installers, setup, or admin rights. UDT: Breaking the Data Transfer Bottleneck GB Network，网站被墙了，差不多也是高速网络大尺寸传输 filecatalyst There exist a number of open source projects trying to tackle accelerated file transfer via UDP. Some solutions are more mature than others and also use different technologies to solve the same problem of large data transfer over WAN. Tsunami UDP is an open source file transfer protocol that enables high-speed data transfer over network paths with a large bandwidth delay product. UFTP http://uftp-multicast.sourceforge.net UFTP is an encrypted multicast file transfer program, designed to securely, reliably, and efficiently transfer files to multiple receivers simultaneously. This is useful for distributing large files to a large number of receivers, and is especially useful for data distribution over a satellite link (with two way communication), where the inherent delay makes any TCP based communication highly inefficient. 基本上好像就是这几种需求了

halleyzhang3 2013-08-09

打赏
举报

其实TCP很多地方是需要改进的，毕竟他岁数太大了，有四十年了吧，和它同时代出现的技术差不多都更新换代了吧。曾经有过SCTP，标准都出了，但是没有推广起来。估计TCP不能换代的原因使大量的中间设备的更换吧，所以能用就一直用下来了。其实从TCP的api接口上就可以看出来，一个端口等着一堆用户来连接，连接了以后就是一个端口对应着一堆与不同用户的链接，这完全就是Client和Server通讯用的，那时候还没有想到P2P应用也很重要。

woshinia 2013-08-09

打赏
举报

"TCP判断拥塞的依据是没有收到应答"看来你是认为网络拥塞跟堵车一样吧。好吧，等待别人来解答吧，我是说服不了你了。

halleyzhang3 2013-08-09

打赏
举报

引用 39 楼 woshinia 的回复:

[quote=引用 37 楼 halleyzhang3 的回复:] [quote=引用 35 楼 woshinia 的回复:] [quote=引用 26 楼 halleyzhang3 的回复:] [quote=引用 21 楼 woshinia 的回复:] [quote=引用 18 楼 halleyzhang3 的回复:] [quote=引用 16 楼 woshinia 的回复:] [quote=引用 9 楼 spirit008 的回复:] [quote=引用 7 楼 halleyzhang3 的回复:] UDP文件传输的价值应该是不可否认的，因为在这方面有开源项目，有协议，也有商业软件。开源项目我知道的大概有四五个吧，协议有UDT,UFTP，商业软件从他的网站看起来也是赚钱的样子。没有价值的事情不会有那么多的社会力量投入其中。用UDP实现可靠的文件交付，这个根本不是问题，不需要重新发明轮子，现成的开源就有。 UDP实现了可靠传输，并不等于TCP，这个不用说了吧。喷的同学请先确认你至少理解我帖子中所说的概念，原理就不强求了。没有人可以讨论这个问题吗

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。 udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。[/quote] TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。[/quote] 对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他[/quote] 如果你指的抢夺是UDP频繁发送，导致TCP一直需要等待重传的话，好吧，那TCP估计是所有协议中最弱的了。[/quote] 没必要意气用事，其实你只要听从我的建议百度一下TCP的拥塞控制，就全都明白了。既然你不愿意去，那我就简单形象地介绍一下。TCP并不知道你有多少带宽可用，所以也不知道以多大的速度发包合适，他采取的对策是一点一点增长，发现不对就快速降下来（linux是减半），降下来的依据是丢包率。他的这种机制就像谦谦君子，生怕妨碍别人，一旦妨碍了就马上退开。UDP自身没有拥塞控制，如果他不停地发，TCP就会发现他的包大量的丢失，就会降低速率，让出来的带宽就被UDP抢占了。[/quote] 我就是这个意思，但是UDP这不叫抢占，因为其他类型的数据包都会使TCP等待重传，而UDP在其他数据拥塞的情况下基本不是丢包就是校验不过，也就是说是这些UDP包都是无效的，带宽都用来传递无效的包，效率并没有提高。也就是说UDP和其他协议传输包都比TCP强，也就是TCP最弱。[/quote] 这个理解完全错了，我也快无言以对了。TCP的拥塞控制不是被动等待导致的，是主动放弃。UDP丢包是正常的，而网络拥塞和校验过不过完全没有关系，你看到的被动丢包是中间设备的主动丢弃。这里不存在哪个协议好的问题，他相应的设计都是恰当的，只是用途不同[/quote]

引用 38 楼 halleyzhang3 的回复:

[quote=引用 34 楼 andrew57 的回复:] [quote=引用 33 楼 spirit008 的回复:] [quote=引用 31 楼 andrew57 的回复:] [quote=引用 28 楼 spirit008 的回复:] [quote=引用 27 楼 andrew57 的回复:] 讨论太精彩了，各位牛人，我没有做过udp开发，最近做一个udp收图片，开始用默认接收缓冲大小，丢数据厉害，后来设置为32K就好多了，中间使用了暂时缓冲收到的数据，没有从缓冲区读出就处理。请问一下udp接收缓冲开多大为好，太小了，怕缓冲太小，丢数据频繁。或者有什么的建议？

8K够了，你的问题应该不在这，这只是表象[/quote] 能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote] 不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈[/quote]

目前是有这样情况，出图一半。谢谢指点。[/quote] 除了接收缓冲区，发送缓冲区也要设置的。丢包是正常的，要传文件，丢包、乱序的处理是必需的，所以不建议全都自己做，可以从开源项目中拷贝一些代码过来。处理丢包有三种方法，一种是每个包都要应答，这其实就和TCP差不多了；另一种是主动请求缺少的包；还有一种就是用纠错码，只要收到的包达到一定比例，就可以解出完整数据了。[/quote] TCP之所以能检测到网络状态是拥塞的，就是发送一个包的数据，然后校验这个包的长度，如果长度和校验不对，说明包在传输过程中被插入了一些其他数据，也就是跟其他数据包冲突了，即拥塞了。丢包就是拥塞么？那断网不是要无限等。并且在一定间隔时间后，TCP同样会发送这样一个包，如果通不过就等待更长时间，直到通过检验再加快速度发包，主动被动什么的，我是不理解你想表达什么。同理在其他数据包拥塞时，UDP包会被插入其他数据，从而导致校验失败。是你自己提出UDP可以抢占TCP的带宽的，我并没有说哪个协议好坏，并且我是同意的，只是这是TCP的特性，UDP和其他数据没有这个机制，但UDP与其他数据拥塞时会造成带宽浪费而已。[/quote] TCP/UDP层不存在插入其他数据的问题，也不存在长度和校验的问题。这些都是链路层的工作，其实链路层也不需要做多少工作，有线网络误码的概率几乎为零，是典型的二进制删除信道（Binary erase channel)。也就是说，发出的包要么由于中间设备处理不过来而丢弃了，要么就收到了，收到的都是可用的无错误数据。TCP判断拥塞的依据是没有收到应答，超时没应答就认为是丢了。如果网路过分拥塞，TCP会无法工作，因为即使接收端收到了，应答包也可能丢失，网络上会被无用的重传占满。UDP没有这个问题，丢包率99%一样可用，不存在浪费，我就模拟过丢包率50%以上的环境，跑我的程序完全没有问题。

woshinia 2013-08-09

打赏
举报

引用 37 楼 halleyzhang3 的回复:

[quote=引用 35 楼 woshinia 的回复:] [quote=引用 26 楼 halleyzhang3 的回复:] [quote=引用 21 楼 woshinia 的回复:] [quote=引用 18 楼 halleyzhang3 的回复:] [quote=引用 16 楼 woshinia 的回复:] [quote=引用 9 楼 spirit008 的回复:] [quote=引用 7 楼 halleyzhang3 的回复:] UDP文件传输的价值应该是不可否认的，因为在这方面有开源项目，有协议，也有商业软件。开源项目我知道的大概有四五个吧，协议有UDT,UFTP，商业软件从他的网站看起来也是赚钱的样子。没有价值的事情不会有那么多的社会力量投入其中。用UDP实现可靠的文件交付，这个根本不是问题，不需要重新发明轮子，现成的开源就有。 UDP实现了可靠传输，并不等于TCP，这个不用说了吧。喷的同学请先确认你至少理解我帖子中所说的概念，原理就不强求了。没有人可以讨论这个问题吗

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。 udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。[/quote] TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。[/quote] 对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他[/quote] 如果你指的抢夺是UDP频繁发送，导致TCP一直需要等待重传的话，好吧，那TCP估计是所有协议中最弱的了。[/quote] 没必要意气用事，其实你只要听从我的建议百度一下TCP的拥塞控制，就全都明白了。既然你不愿意去，那我就简单形象地介绍一下。TCP并不知道你有多少带宽可用，所以也不知道以多大的速度发包合适，他采取的对策是一点一点增长，发现不对就快速降下来（linux是减半），降下来的依据是丢包率。他的这种机制就像谦谦君子，生怕妨碍别人，一旦妨碍了就马上退开。UDP自身没有拥塞控制，如果他不停地发，TCP就会发现他的包大量的丢失，就会降低速率，让出来的带宽就被UDP抢占了。[/quote] 我就是这个意思，但是UDP这不叫抢占，因为其他类型的数据包都会使TCP等待重传，而UDP在其他数据拥塞的情况下基本不是丢包就是校验不过，也就是说是这些UDP包都是无效的，带宽都用来传递无效的包，效率并没有提高。也就是说UDP和其他协议传输包都比TCP强，也就是TCP最弱。[/quote] 这个理解完全错了，我也快无言以对了。TCP的拥塞控制不是被动等待导致的，是主动放弃。UDP丢包是正常的，而网络拥塞和校验过不过完全没有关系，你看到的被动丢包是中间设备的主动丢弃。这里不存在哪个协议好的问题，他相应的设计都是恰当的，只是用途不同[/quote]

引用 38 楼 halleyzhang3 的回复:

[quote=引用 34 楼 andrew57 的回复:] [quote=引用 33 楼 spirit008 的回复:] [quote=引用 31 楼 andrew57 的回复:] [quote=引用 28 楼 spirit008 的回复:] [quote=引用 27 楼 andrew57 的回复:] 讨论太精彩了，各位牛人，我没有做过udp开发，最近做一个udp收图片，开始用默认接收缓冲大小，丢数据厉害，后来设置为32K就好多了，中间使用了暂时缓冲收到的数据，没有从缓冲区读出就处理。请问一下udp接收缓冲开多大为好，太小了，怕缓冲太小，丢数据频繁。或者有什么的建议？

8K够了，你的问题应该不在这，这只是表象[/quote] 能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote] 不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈[/quote]

目前是有这样情况，出图一半。谢谢指点。[/quote] 除了接收缓冲区，发送缓冲区也要设置的。丢包是正常的，要传文件，丢包、乱序的处理是必需的，所以不建议全都自己做，可以从开源项目中拷贝一些代码过来。处理丢包有三种方法，一种是每个包都要应答，这其实就和TCP差不多了；另一种是主动请求缺少的包；还有一种就是用纠错码，只要收到的包达到一定比例，就可以解出完整数据了。[/quote] TCP之所以能检测到网络状态是拥塞的，就是发送一个包的数据，然后校验这个包的长度，如果长度和校验不对，说明包在传输过程中被插入了一些其他数据，也就是跟其他数据包冲突了，即拥塞了。丢包就是拥塞么？那断网不是要无限等。并且在一定间隔时间后，TCP同样会发送这样一个包，如果通不过就等待更长时间，直到通过检验再加快速度发包，主动被动什么的，我是不理解你想表达什么。同理在其他数据包拥塞时，UDP包会被插入其他数据，从而导致校验失败。是你自己提出UDP可以抢占TCP的带宽的，我并没有说哪个协议好坏，并且我是同意的，只是这是TCP的特性，UDP和其他数据没有这个机制，但UDP与其他数据拥塞时会造成带宽浪费而已。

halleyzhang3 2013-08-09

打赏
举报

引用 34 楼 andrew57 的回复:

[quote=引用 33 楼 spirit008 的回复:] [quote=引用 31 楼 andrew57 的回复:] [quote=引用 28 楼 spirit008 的回复:] [quote=引用 27 楼 andrew57 的回复:] 讨论太精彩了，各位牛人，我没有做过udp开发，最近做一个udp收图片，开始用默认接收缓冲大小，丢数据厉害，后来设置为32K就好多了，中间使用了暂时缓冲收到的数据，没有从缓冲区读出就处理。请问一下udp接收缓冲开多大为好，太小了，怕缓冲太小，丢数据频繁。或者有什么的建议？

8K够了，你的问题应该不在这，这只是表象[/quote] 能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote] 不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈[/quote]

目前是有这样情况，出图一半。谢谢指点。[/quote] 除了接收缓冲区，发送缓冲区也要设置的。丢包是正常的，要传文件，丢包、乱序的处理是必需的，所以不建议全都自己做，可以从开源项目中拷贝一些代码过来。处理丢包有三种方法，一种是每个包都要应答，这其实就和TCP差不多了；另一种是主动请求缺少的包；还有一种就是用纠错码，只要收到的包达到一定比例，就可以解出完整数据了。

halleyzhang3 2013-08-09

打赏
举报

引用 35 楼 woshinia 的回复:

[quote=引用 26 楼 halleyzhang3 的回复:] [quote=引用 21 楼 woshinia 的回复:] [quote=引用 18 楼 halleyzhang3 的回复:] [quote=引用 16 楼 woshinia 的回复:] [quote=引用 9 楼 spirit008 的回复:] [quote=引用 7 楼 halleyzhang3 的回复:] UDP文件传输的价值应该是不可否认的，因为在这方面有开源项目，有协议，也有商业软件。开源项目我知道的大概有四五个吧，协议有UDT,UFTP，商业软件从他的网站看起来也是赚钱的样子。没有价值的事情不会有那么多的社会力量投入其中。用UDP实现可靠的文件交付，这个根本不是问题，不需要重新发明轮子，现成的开源就有。 UDP实现了可靠传输，并不等于TCP，这个不用说了吧。喷的同学请先确认你至少理解我帖子中所说的概念，原理就不强求了。没有人可以讨论这个问题吗

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。 udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。[/quote] TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。[/quote] 对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他[/quote] 如果你指的抢夺是UDP频繁发送，导致TCP一直需要等待重传的话，好吧，那TCP估计是所有协议中最弱的了。[/quote] 没必要意气用事，其实你只要听从我的建议百度一下TCP的拥塞控制，就全都明白了。既然你不愿意去，那我就简单形象地介绍一下。TCP并不知道你有多少带宽可用，所以也不知道以多大的速度发包合适，他采取的对策是一点一点增长，发现不对就快速降下来（linux是减半），降下来的依据是丢包率。他的这种机制就像谦谦君子，生怕妨碍别人，一旦妨碍了就马上退开。UDP自身没有拥塞控制，如果他不停地发，TCP就会发现他的包大量的丢失，就会降低速率，让出来的带宽就被UDP抢占了。[/quote] 我就是这个意思，但是UDP这不叫抢占，因为其他类型的数据包都会使TCP等待重传，而UDP在其他数据拥塞的情况下基本不是丢包就是校验不过，也就是说是这些UDP包都是无效的，带宽都用来传递无效的包，效率并没有提高。也就是说UDP和其他协议传输包都比TCP强，也就是TCP最弱。[/quote] 这个理解完全错了，我也快无言以对了。TCP的拥塞控制不是被动等待导致的，是主动放弃。UDP丢包是正常的，而网络拥塞和校验过不过完全没有关系，你看到的被动丢包是中间设备的主动丢弃。这里不存在哪个协议好的问题，他相应的设计都是恰当的，只是用途不同

woshinia 2013-08-09

打赏
举报

引用 25 楼 spirit008 的回复:

[quote=引用 23 楼 halleyzhang3 的回复:] [quote=引用 15 楼 spirit008 的回复:] [quote=引用 13 楼 woshinia 的回复:] [quote=引用 8 楼 spirit008 的回复:] [quote=引用 6 楼 woshinia 的回复:] 在网游中UDP用的比较多，丢包的话，就变现为卡，点击无响应等。如果长期一个包都收不到就会掉线，但对网络不稳定的情况有较好的容错性。但如果用TCP的话，网络一旦不稳定就会直接掉线。

你凌乱了，卡，无响应只是ui线程阻塞，是你写程序的方式问题，和网络本质上没毛关系。网络不稳定和掉线，跟用tcp和udp没关系。掉线重连好了。大型服务，包括网游，用udp是因为需要一台机器撑更多的客户端。tcp的话，2w基本上限了。[/quote] 1，在支撑更多的客户端方面，tcp和udp是一样的，都需要用网络模型优化，不要认为udp是广播，udp跟tcp一样需要为每一个用户发送和接受。 2，ui线程的阻塞在单机里当然是这样的，但网游需要根据服务器发来的响应更新ui，所以不流畅的话，网速是关键因素。 3，网络不稳定的话，tcp会无限重传，直到超时，而udp不会，只会表现为丢包，在网游中表现为卡顿，就像有人说的“像看幻灯片一样”。 [/quote] 无言以对[/quote] 这个问题据我所知是这样：如果不采取特别的优化措施，那么TCP仅为每一个用户建立一个长链接就是一个不小的开销，在Windows上到了一定数目就不行了，linux能比windows多20%左右。不过我这个信息比较陈旧了，现在的情况可能会有改善吧。关于网络状况与UI卡顿之间的关系，对客户端来说，可以在一定程度上处理一下，但是有限的，流畅度完全不受网络影响是很困难的，毕竟正常的逻辑是收到什么包做什么事，至于什么包该来而没来，考虑这些会很麻烦的[/quote] 支撑用户量的问题是源于fd有限，有状态链接占用系统资源，但资源有限，倒不是链接的开销，链接的开销就是交换几个包而已。udp的话，无需系统层面保存状态，如果协议是无状态的，即整个交互无状态，业务层也无需保存什么了。另，tcp打洞还是不要想了，实测没什么设备支持，而且也不是麻烦一点点，网上写的那些东西，不知道谁写论文胡侃一通，姑且看看理论就可以了。udp打洞的成功率都不是很高，70%差不多吧。但是udp的有一个很大的好处，支撑100w的同时在线，2台打洞服务器就搞定了，成本小太多了。[/quote] 打洞在于让处于局域网的主机可以作为服务器，所谓的“支撑100w的同时在线，2台打洞服务器就搞定了”，只能是对战类游戏，让其中一个玩家做主机，服务器只是中转，当然压力就小了。并且udp打动需要路由器的支持，所以不是一定能成功的。还有我并不认为所谓的“系统保存链接状态”对连接数的限制很大，内存对连接数的制约是很小的而且内存便宜不够用就加呗，内存的申请和释放通过内存池管理，也很快。主要是看CPU的负荷，而CPU的主要用在处理逻辑任务上，即用户的请求对于CPU的消耗才是最主要的因素。现在服务器基本都是IOCP或差不多的模型，线程不会太多，所以线程也不影响。因此连接数大多是决定于CPU的性能，至于你说的fd，我不知道你指的什么。

woshinia 2013-08-09

打赏
举报

引用 26 楼 halleyzhang3 的回复:

[quote=引用 21 楼 woshinia 的回复:] [quote=引用 18 楼 halleyzhang3 的回复:] [quote=引用 16 楼 woshinia 的回复:] [quote=引用 9 楼 spirit008 的回复:] [quote=引用 7 楼 halleyzhang3 的回复:] UDP文件传输的价值应该是不可否认的，因为在这方面有开源项目，有协议，也有商业软件。开源项目我知道的大概有四五个吧，协议有UDT,UFTP，商业软件从他的网站看起来也是赚钱的样子。没有价值的事情不会有那么多的社会力量投入其中。用UDP实现可靠的文件交付，这个根本不是问题，不需要重新发明轮子，现成的开源就有。 UDP实现了可靠传输，并不等于TCP，这个不用说了吧。喷的同学请先确认你至少理解我帖子中所说的概念，原理就不强求了。没有人可以讨论这个问题吗

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。 udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。[/quote] TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。[/quote] 对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他[/quote] 如果你指的抢夺是UDP频繁发送，导致TCP一直需要等待重传的话，好吧，那TCP估计是所有协议中最弱的了。[/quote] 没必要意气用事，其实你只要听从我的建议百度一下TCP的拥塞控制，就全都明白了。既然你不愿意去，那我就简单形象地介绍一下。TCP并不知道你有多少带宽可用，所以也不知道以多大的速度发包合适，他采取的对策是一点一点增长，发现不对就快速降下来（linux是减半），降下来的依据是丢包率。他的这种机制就像谦谦君子，生怕妨碍别人，一旦妨碍了就马上退开。UDP自身没有拥塞控制，如果他不停地发，TCP就会发现他的包大量的丢失，就会降低速率，让出来的带宽就被UDP抢占了。[/quote] 我就是这个意思，但是UDP这不叫抢占，因为其他类型的数据包都会使TCP等待重传，而UDP在其他数据拥塞的情况下基本不是丢包就是校验不过，也就是说是这些UDP包都是无效的，带宽都用来传递无效的包，效率并没有提高。也就是说UDP和其他协议传输包都比TCP强，也就是TCP最弱。

UnkownState 2013-08-09

打赏
举报

引用 33 楼 spirit008 的回复:

[quote=引用 31 楼 andrew57 的回复:] [quote=引用 28 楼 spirit008 的回复:] [quote=引用 27 楼 andrew57 的回复:] 讨论太精彩了，各位牛人，我没有做过udp开发，最近做一个udp收图片，开始用默认接收缓冲大小，丢数据厉害，后来设置为32K就好多了，中间使用了暂时缓冲收到的数据，没有从缓冲区读出就处理。请问一下udp接收缓冲开多大为好，太小了，怕缓冲太小，丢数据频繁。或者有什么的建议？

8K够了，你的问题应该不在这，这只是表象[/quote] 能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote] 不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈[/quote]

目前是有这样情况，出图一半。谢谢指点。

木头菇 2013-08-09

打赏
举报

引用 31 楼 andrew57 的回复:

[quote=引用 28 楼 spirit008 的回复:] [quote=引用 27 楼 andrew57 的回复:] 讨论太精彩了，各位牛人，我没有做过udp开发，最近做一个udp收图片，开始用默认接收缓冲大小，丢数据厉害，后来设置为32K就好多了，中间使用了暂时缓冲收到的数据，没有从缓冲区读出就处理。请问一下udp接收缓冲开多大为好，太小了，怕缓冲太小，丢数据频繁。或者有什么的建议？

8K够了，你的问题应该不在这，这只是表象[/quote] 能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote] 不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈

木头菇 2013-08-09

打赏
举报

引用 31 楼 andrew57 的回复:

[quote=引用 28 楼 spirit008 的回复:] [quote=引用 27 楼 andrew57 的回复:] 讨论太精彩了，各位牛人，我没有做过udp开发，最近做一个udp收图片，开始用默认接收缓冲大小，丢数据厉害，后来设置为32K就好多了，中间使用了暂时缓冲收到的数据，没有从缓冲区读出就处理。请问一下udp接收缓冲开多大为好，太小了，怕缓冲太小，丢数据频繁。或者有什么的建议？

8K够了，你的问题应该不在这，这只是表象[/quote] 能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote] 传文件要保证一个字节也不丢呀，肯定得有重传，而且包到达是乱序的，起码的序列化还是要做的吧，你做了吗

UnkownState 2013-08-09

打赏
举报

引用 28 楼 spirit008 的回复:

[quote=引用 27 楼 andrew57 的回复:] 讨论太精彩了，各位牛人，我没有做过udp开发，最近做一个udp收图片，开始用默认接收缓冲大小，丢数据厉害，后来设置为32K就好多了，中间使用了暂时缓冲收到的数据，没有从缓冲区读出就处理。请问一下udp接收缓冲开多大为好，太小了，怕缓冲太小，丢数据频繁。或者有什么的建议？

8K够了，你的问题应该不在这，这只是表象[/quote] 能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。