18,363
社区成员
发帖
与我相关
我的任务
分享UDP文件传输在什么场合有优势？
目前UDP传输文件的工具和协议都很多，说明还是有某些方面的优势的，但具体到UDP一定比TCP快，也没有确切的根据，至少像一些专门的下载网站，也没有去支持基于UDP的下载协议。恰巧本人最近之前了一段时间喷泉码，感觉这个东西可以应用于UDP文件传输，但是究竟UDP传输本身有多大价值，适用什么情况却不甚明了，希望和大家讨论讨论。
首先是在正常的独享有限带宽的网络环境下，目前的下载工具的速度是否能达到满负荷。单线程TCP肯定是不行的，多线程TCP理论上应该可以吧，但是线程开得太多的话，每个线程要在文件的不同位置写入，会造成磁头频繁的移动，磁盘IO也可能成为瓶颈，所以一般推荐5-10个线程，可能是因为多数硬盘是4-8个磁头吧（我猜的），这种情况下是不是能达到满负荷我就不清楚了。而UDP做到这一点应该不难吧，因为它不需要应答，想发多快都可以，超过负荷顶多是丢包，并不降低有效的数据传输速度。要搞清楚是否满负荷也不很容易，首先实际的带宽未必是供应商所号称的那么大，其次是目前带宽限制的机理我也不是太清楚，比如4M ADSL，是完全真正的限速还是和邻近的用户争夺有限的设备能力呢？争夺带宽的考虑后面会谈到。
第二是在不太理想的网络环境下，UDP所具有的优势。这些不理想的情况包括，丢包率较高、高延迟（PING值大）、可用带宽不稳定地抖动。高延迟似乎对TCP的影响是很大的，因为TCP需要应答，虽然有多线程和滑动窗口(Slide Window）的机制可以同时发送多个数据包，但是TCP的拥塞控制策略使得它的实际传输速率一直在随着丢包波动，当延迟较大时他就需要更长的时间才能从波谷回到波峰。当三个不理想的情况凑在一起时，TCP估计开多少线程都没办法了吧。有的下载工具是修改TCP底层参数来改善这些状况的，具体情况我就不太清楚了。对于UDP，还是以不变应万变，不受这些因素的影响。单向通讯和广播也是UDP方式下载的优势，但这种情况不太常见，就不多谈论了。
第三是在与其他用户争夺带宽的情况下。最常见的就是局域网用户共享一个出口了。（关于广域网用户，我曾见过老外写的比较有趣的实测，当两个特定子网的用互频繁通讯的时候，实际的带宽利用情况是像正弦波一样波动的，效率低的可怜。这是因为所有用户的延迟都一样，TCP的拥塞控制趋于同步，一起涨就阻塞，然后一起降就空闲，如此循环。题外话完毕）。在这种情况下，UDP的主要优势就是和TCP争抢带宽，如果不加任何的拥塞控制，不知是否能把TCP赶尽杀绝，独占所有带宽，也不知目前的UDP下载能否做到，是否有明显的效果。
本来想在最后简单介绍一下TCP的拥塞控制算法、滑动窗口机制，多线程下载原理，以及UDP文件传输如何处理丢包和重组的，但是因为前面写得太长了，估计没有人会有耐心看下去了，热心的朋友可以帮忙介绍一下。随时等候各位的宝贵建议。
首先是在正常的独享有限带宽的网络环境下，目前的下载工具的速度是否能达到满负荷。单线程TCP肯定是不行的，多线程TCP理论上应该可以吧，但是线程开得太多的话，每个线程要在文件的不同位置写入，会造成磁头频繁的移动，磁盘IO也可能成为瓶颈，所以一般推荐5-10个线程，可能是因为多数硬盘是4-8个磁头吧（我猜的），这种情况下是不是能达到满负荷我就不清楚了。而UDP做到这一点应该不难吧，因为它不需要应答，想发多快都可以，超过负荷顶多是丢包，并不降低有效的数据传输速度。要搞清楚是否满负荷也不很容易，首先实际的带宽未必是供应商所号称的那么大，其次是目前带宽限制的机理我也不是太清楚，比如4M ADSL，是完全真正的限速还是和邻近的用户争夺有限的设备能力呢？争夺带宽的考虑后面会谈到。
第二是在不太理想的网络环境下，UDP所具有的优势。这些不理想的情况包括，丢包率较高、高延迟（PING值大）、可用带宽不稳定地抖动。高延迟似乎对TCP的影响是很大的，因为TCP需要应答，虽然有多线程和滑动窗口(Slide Window）的机制可以同时发送多个数据包，但是TCP的拥塞控制策略使得它的实际传输速率一直在随着丢包波动，当延迟较大时他就需要更长的时间才能从波谷回到波峰。当三个不理想的情况凑在一起时，TCP估计开多少线程都没办法了吧。有的下载工具是修改TCP底层参数来改善这些状况的，具体情况我就不太清楚了。对于UDP，还是以不变应万变，不受这些因素的影响。单向通讯和广播也是UDP方式下载的优势，但这种情况不太常见，就不多谈论了。
第三是在与其他用户争夺带宽的情况下。最常见的就是局域网用户共享一个出口了。（关于广域网用户，我曾见过老外写的比较有趣的实测，当两个特定子网的用互频繁通讯的时候，实际的带宽利用情况是像正弦波一样波动的，效率低的可怜。这是因为所有用户的延迟都一样，TCP的拥塞控制趋于同步，一起涨就阻塞，然后一起降就空闲，如此循环。题外话完毕）。在这种情况下，UDP的主要优势就是和TCP争抢带宽，如果不加任何的拥塞控制，不知是否能把TCP赶尽杀绝，独占所有带宽，也不知目前的UDP下载能否做到，是否有明显的效果。
本来想在最后简单介绍一下TCP的拥塞控制算法、滑动窗口机制，多线程下载原理，以及UDP文件传输如何处理丢包和重组的，但是因为前面写得太长了，估计没有人会有耐心看下去了，热心的朋友可以帮忙介绍一下。随时等候各位的宝贵建议。
...全文
请发表友善的回复…
发表回复
舞夜幽灵之雏 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
- 打赏
- 举报
的确局域网广播用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
- 打赏
- 举报
你提到的关于开多少多少线程的问题，现在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]
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%以上的环境，跑我的程序完全没有问题。
目前是有这样情况，出图一半。谢谢指点。[/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
- 打赏
- 举报
你提到的关于开多少多少线程的问题，现在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]
8K够了，你的问题应该不在这，这只是表象[/quote]
能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote]
不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈[/quote]
目前是有这样情况，出图一半。谢谢指点。[/quote]
除了接收缓冲区，发送缓冲区也要设置的。
丢包是正常的，要传文件，丢包、乱序的处理是必需的，所以不建议全都自己做，可以从开源项目中拷贝一些代码过来。
处理丢包有三种方法，一种是每个包都要应答，这其实就和TCP差不多了；另一种是主动请求缺少的包；还有一种就是用纠错码，只要收到的包达到一定比例，就可以解出完整数据了。[/quote]
TCP之所以能检测到网络状态是拥塞的，就是发送一个包的数据，然后校验这个包的长度，如果长度和校验不对，说明包在传输过程中被插入了一些其他数据，也就是跟其他数据包冲突了，即拥塞了。丢包就是拥塞么？那断网不是要无限等。并且在一定间隔时间后，TCP同样会发送这样一个包，如果通不过就等待更长时间，直到通过检验再加快速度发包，主动被动什么的，我是不理解你想表达什么。同理在其他数据包拥塞时，UDP包会被插入其他数据，从而导致校验失败。是你自己提出UDP可以抢占TCP的带宽的，我并没有说哪个协议好坏，并且我是同意的，只是这是TCP的特性，UDP和其他数据没有这个机制，但UDP与其他数据拥塞时会造成带宽浪费而已。
目前是有这样情况，出图一半。谢谢指点。[/quote]
除了接收缓冲区，发送缓冲区也要设置的。
丢包是正常的，要传文件，丢包、乱序的处理是必需的，所以不建议全都自己做，可以从开源项目中拷贝一些代码过来。
处理丢包有三种方法，一种是每个包都要应答，这其实就和TCP差不多了；另一种是主动请求缺少的包；还有一种就是用纠错码，只要收到的包达到一定比例，就可以解出完整数据了。[/quote]
TCP之所以能检测到网络状态是拥塞的，就是发送一个包的数据，然后校验这个包的长度，如果长度和校验不对，说明包在传输过程中被插入了一些其他数据，也就是跟其他数据包冲突了，即拥塞了。丢包就是拥塞么？那断网不是要无限等。并且在一定间隔时间后，TCP同样会发送这样一个包，如果通不过就等待更长时间，直到通过检验再加快速度发包，主动被动什么的，我是不理解你想表达什么。同理在其他数据包拥塞时，UDP包会被插入其他数据，从而导致校验失败。是你自己提出UDP可以抢占TCP的带宽的，我并没有说哪个协议好坏，并且我是同意的，只是这是TCP的特性，UDP和其他数据没有这个机制，但UDP与其他数据拥塞时会造成带宽浪费而已。halleyzhang3 2013-08-09
- 打赏
- 举报
8K够了，你的问题应该不在这，这只是表象[/quote]
能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote]
不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈[/quote]
目前是有这样情况，出图一半。谢谢指点。[/quote]
除了接收缓冲区，发送缓冲区也要设置的。
丢包是正常的，要传文件，丢包、乱序的处理是必需的，所以不建议全都自己做，可以从开源项目中拷贝一些代码过来。
处理丢包有三种方法，一种是每个包都要应答，这其实就和TCP差不多了；另一种是主动请求缺少的包；还有一种就是用纠错码，只要收到的包达到一定比例，就可以解出完整数据了。
目前是有这样情况，出图一半。谢谢指点。[/quote]
除了接收缓冲区，发送缓冲区也要设置的。
丢包是正常的，要传文件，丢包、乱序的处理是必需的，所以不建议全都自己做，可以从开源项目中拷贝一些代码过来。
处理丢包有三种方法，一种是每个包都要应答，这其实就和TCP差不多了；另一种是主动请求缺少的包；还有一种就是用纠错码，只要收到的包达到一定比例，就可以解出完整数据了。halleyzhang3 2013-08-09
- 打赏
- 举报
你提到的关于开多少多少线程的问题，现在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
- 打赏
- 举报
你凌乱了，卡，无响应只是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
- 打赏
- 举报
你提到的关于开多少多少线程的问题，现在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
- 打赏
- 举报
8K够了，你的问题应该不在这，这只是表象[/quote]
能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote]
不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈[/quote]
目前是有这样情况，出图一半。谢谢指点。
目前是有这样情况，出图一半。谢谢指点。
木头菇 2013-08-09
- 打赏
- 举报
8K够了，你的问题应该不在这，这只是表象[/quote]
能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote]
不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈
木头菇 2013-08-09
- 打赏
- 举报
8K够了，你的问题应该不在这，这只是表象[/quote]
能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。[/quote]
传文件要保证一个字节也不丢呀，肯定得有重传，而且包到达是乱序的，起码的序列化还是要做的吧，你做了吗
UnkownState 2013-08-09
- 打赏
- 举报
8K够了，你的问题应该不在这，这只是表象[/quote]
能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。
加载更多回复（30）
