在网游中UDP用的比较多，丢包的话，就变现为卡，点击无响应等。如果长期一个包都收不到就会掉线，但对网络不稳定的情况有较好的容错性。
但如果用TCP的话，网络一旦不稳定就会直接掉线。

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

Quote: 引用 6 楼 woshinia 的回复:

在网游中UDP用的比较多，丢包的话，就变现为卡，点击无响应等。如果长期一个包都收不到就会掉线，但对网络不稳定的情况有较好的容错性。
但如果用TCP的话，网络一旦不稳定就会直接掉线。

你凌乱了，卡，无响应只是ui线程阻塞，是你写程序的方式问题，和网络本质上没毛关系。
网络不稳定和掉线，跟用tcp和udp没关系。掉线重连好了。
大型服务，包括网游，用udp是因为需要一台机器撑更多的客户端。tcp的话，2w基本上限了。

Quote: 引用 8 楼 spirit008 的回复:

Quote: 引用 6 楼 woshinia 的回复:

在网游中UDP用的比较多，丢包的话，就变现为卡，点击无响应等。如果长期一个包都收不到就会掉线，但对网络不稳定的情况有较好的容错性。
但如果用TCP的话，网络一旦不稳定就会直接掉线。

你凌乱了，卡，无响应只是ui线程阻塞，是你写程序的方式问题，和网络本质上没毛关系。
网络不稳定和掉线，跟用tcp和udp没关系。掉线重连好了。
大型服务，包括网游，用udp是因为需要一台机器撑更多的客户端。tcp的话，2w基本上限了。

网游、实时视频这些是一定要用UDP的，TCP由于要等待应答，不适用对实时性要求高的场合。
点对点应用也常有人用UDP，这是因为UDP实现NAT穿越比TCP方便一些，成功率也要高一点。
至于文件传输用UDP，现象是大量存在，原因却不是很清楚，而我最近研究的一些东西则可以顺便用于改进UDP文件传输，在考虑是否有价值做一个，大概就是这么个关系吧。

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

Quote: 引用 6 楼 woshinia 的回复:

在网游中UDP用的比较多，丢包的话，就变现为卡，点击无响应等。如果长期一个包都收不到就会掉线，但对网络不稳定的情况有较好的容错性。
但如果用TCP的话，网络一旦不稳定就会直接掉线。

你凌乱了，卡，无响应只是ui线程阻塞，是你写程序的方式问题，和网络本质上没毛关系。
网络不稳定和掉线，跟用tcp和udp没关系。掉线重连好了。
大型服务，包括网游，用udp是因为需要一台机器撑更多的客户端。tcp的话，2w基本上限了。

Quote: 引用 9 楼 spirit008 的回复:

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

这个我确实没多想，最初人们也许是真的用多线程分别取请求文件的不同部份，但你这么一说，的确单线程完全可以实现，异步写入也是支持的。为了简便，这里我们还是称它为线程数吧，那么线程数是不是可以一直开下去，直到用尽网络的带宽呢？我还是怀疑关于线程数5－10个的说法是有实测根据的，关于磁头移动的问题是我自己猜想的

Quote: 引用 8 楼 spirit008 的回复:

Quote: 引用 6 楼 woshinia 的回复:

在网游中UDP用的比较多，丢包的话，就变现为卡，点击无响应等。如果长期一个包都收不到就会掉线，但对网络不稳定的情况有较好的容错性。
但如果用TCP的话，网络一旦不稳定就会直接掉线。

你凌乱了，卡，无响应只是ui线程阻塞，是你写程序的方式问题，和网络本质上没毛关系。
网络不稳定和掉线，跟用tcp和udp没关系。掉线重连好了。
大型服务，包括网游，用udp是因为需要一台机器撑更多的客户端。tcp的话，2w基本上限了。

1，在支撑更多的客户端方面，tcp和udp是一样的，都需要用网络模型优化，不要认为udp是广播，udp跟tcp一样需要为每一个用户发送和接受。
2，ui线程的阻塞在单机里当然是这样的，但网游需要根据服务器发来的响应更新ui，所以不流畅的话，网速是关键因素。
3，网络不稳定的话，tcp会无限重传，直到超时，而udp不会，只会表现为丢包，在网游中表现为卡顿，就像有人说的“像看幻灯片一样”。

Quote: 引用 7 楼 halleyzhang3 的回复:

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

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

Quote: 引用 9 楼 spirit008 的回复:

Quote: 引用 7 楼 halleyzhang3 的回复:

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

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

Quote: 引用 9 楼 spirit008 的回复:

Quote: 引用 7 楼 halleyzhang3 的回复:

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

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

Quote: 引用 16 楼 woshinia 的回复:

Quote: 引用 9 楼 spirit008 的回复:

Quote: 引用 7 楼 halleyzhang3 的回复:

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

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。
对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他

Quote: 引用 18 楼 halleyzhang3 的回复:

Quote: 引用 16 楼 woshinia 的回复:

Quote: 引用 9 楼 spirit008 的回复:

Quote: 引用 7 楼 halleyzhang3 的回复:

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

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。
对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他

我的理解是，只在p2p有意义，即打洞，以适应更多的网络环境

Quote: 引用 16 楼 woshinia 的回复:

Quote: 引用 9 楼 spirit008 的回复:

Quote: 引用 7 楼 halleyzhang3 的回复:

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

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。
对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他

Quote: 引用 19 楼 spirit008 的回复:

Quote: 引用 18 楼 halleyzhang3 的回复:

Quote: 引用 16 楼 woshinia 的回复:

Quote: 引用 9 楼 spirit008 的回复:

Quote: 引用 7 楼 halleyzhang3 的回复:

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

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。
对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他

我的理解是，只在p2p有意义，即打洞，以适应更多的网络环境

打洞的意义可能没有想象得那么大，因为TCP也是可以打洞的，只是麻烦一点点。成功率也许低一点，但这一点应该是可以忽略不计的。
我现在能想到的是，在网络不好的情况下应该会快一些，但这个快的前提是不控制收发速度，在原本拥挤的互联网上，是建立在抢了他人的资源的基础上的，只有在局域网、广域网这些环境才具有把空闲的带宽充分利用起来的价值

Quote: 引用 13 楼 woshinia 的回复:

Quote: 引用 8 楼 spirit008 的回复:

Quote: 引用 6 楼 woshinia 的回复:

在网游中UDP用的比较多，丢包的话，就变现为卡，点击无响应等。如果长期一个包都收不到就会掉线，但对网络不稳定的情况有较好的容错性。
但如果用TCP的话，网络一旦不稳定就会直接掉线。

你凌乱了，卡，无响应只是ui线程阻塞，是你写程序的方式问题，和网络本质上没毛关系。
网络不稳定和掉线，跟用tcp和udp没关系。掉线重连好了。
大型服务，包括网游，用udp是因为需要一台机器撑更多的客户端。tcp的话，2w基本上限了。

1，在支撑更多的客户端方面，tcp和udp是一样的，都需要用网络模型优化，不要认为udp是广播，udp跟tcp一样需要为每一个用户发送和接受。
2，ui线程的阻塞在单机里当然是这样的，但网游需要根据服务器发来的响应更新ui，所以不流畅的话，网速是关键因素。
3，网络不稳定的话，tcp会无限重传，直到超时，而udp不会，只会表现为丢包，在网游中表现为卡顿，就像有人说的“像看幻灯片一样”。

无言以对

Quote: 引用 20 楼 halleyzhang3 的回复:

Quote: 引用 19 楼 spirit008 的回复:

Quote: 引用 18 楼 halleyzhang3 的回复:

Quote: 引用 16 楼 woshinia 的回复:

Quote: 引用 9 楼 spirit008 的回复:

Quote: 引用 7 楼 halleyzhang3 的回复:

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

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。
对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他

我的理解是，只在p2p有意义，即打洞，以适应更多的网络环境

打洞的意义可能没有想象得那么大，因为TCP也是可以打洞的，只是麻烦一点点。成功率也许低一点，但这一点应该是可以忽略不计的。
我现在能想到的是，在网络不好的情况下应该会快一些，但这个快的前提是不控制收发速度，在原本拥挤的互联网上，是建立在抢了他人的资源的基础上的，只有在局域网、广域网这些环境才具有把空闲的带宽充分利用起来的价值

你实际用过tcp打洞吗？有没有和udp打洞的统计数据对比？我没尝试过这个。
另，局域网里，其实反而用什么都一样，网络状况太好了。

Quote: 引用 15 楼 spirit008 的回复:

Quote: 引用 13 楼 woshinia 的回复:

Quote: 引用 8 楼 spirit008 的回复:

Quote: 引用 6 楼 woshinia 的回复:

在网游中UDP用的比较多，丢包的话，就变现为卡，点击无响应等。如果长期一个包都收不到就会掉线，但对网络不稳定的情况有较好的容错性。
但如果用TCP的话，网络一旦不稳定就会直接掉线。

你凌乱了，卡，无响应只是ui线程阻塞，是你写程序的方式问题，和网络本质上没毛关系。
网络不稳定和掉线，跟用tcp和udp没关系。掉线重连好了。
大型服务，包括网游，用udp是因为需要一台机器撑更多的客户端。tcp的话，2w基本上限了。

1，在支撑更多的客户端方面，tcp和udp是一样的，都需要用网络模型优化，不要认为udp是广播，udp跟tcp一样需要为每一个用户发送和接受。
2，ui线程的阻塞在单机里当然是这样的，但网游需要根据服务器发来的响应更新ui，所以不流畅的话，网速是关键因素。
3，网络不稳定的话，tcp会无限重传，直到超时，而udp不会，只会表现为丢包，在网游中表现为卡顿，就像有人说的“像看幻灯片一样”。

无言以对

这个问题据我所知是这样：如果不采取特别的优化措施，那么TCP仅为每一个用户建立一个长链接就是一个不小的开销，在Windows上到了一定数目就不行了，linux能比windows多20%左右。不过我这个信息比较陈旧了，现在的情况可能会有改善吧。
关于网络状况与UI卡顿之间的关系，对客户端来说，可以在一定程度上处理一下，但是有限的，流畅度完全不受网络影响是很困难的，毕竟正常的逻辑是收到什么包做什么事，至于什么包该来而没来，考虑这些会很麻烦的

Quote: 引用 18 楼 halleyzhang3 的回复:

Quote: 引用 16 楼 woshinia 的回复:

Quote: 引用 9 楼 spirit008 的回复:

Quote: 引用 7 楼 halleyzhang3 的回复:

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

你提到的关于开多少多少线程的问题，现在api都有异步接口，网络一样，写文件也一样，总之归为io都是有异步的，如果客户端要高性能，还是要单线程的。
udp对带宽是一种高效的争夺，如果要和其他软件拼命的话，比tcp是要猛的。
你提到下载工具队磁盘xxxxx，单线程不行xxxxx。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。
对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他

如果你指的抢夺是UDP频繁发送，导致TCP一直需要等待重传的话，好吧，那TCP估计是所有协议中最弱的了。

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

Quote: 引用 23 楼 halleyzhang3 的回复:

Quote: 引用 15 楼 spirit008 的回复:

Quote: 引用 13 楼 woshinia 的回复:

Quote: 引用 8 楼 spirit008 的回复:

Quote: 引用 6 楼 woshinia 的回复:

在网游中UDP用的比较多，丢包的话，就变现为卡，点击无响应等。如果长期一个包都收不到就会掉线，但对网络不稳定的情况有较好的容错性。
但如果用TCP的话，网络一旦不稳定就会直接掉线。

你凌乱了，卡，无响应只是ui线程阻塞，是你写程序的方式问题，和网络本质上没毛关系。
网络不稳定和掉线，跟用tcp和udp没关系。掉线重连好了。
大型服务，包括网游，用udp是因为需要一台机器撑更多的客户端。tcp的话，2w基本上限了。

1，在支撑更多的客户端方面，tcp和udp是一样的，都需要用网络模型优化，不要认为udp是广播，udp跟tcp一样需要为每一个用户发送和接受。
2，ui线程的阻塞在单机里当然是这样的，但网游需要根据服务器发来的响应更新ui，所以不流畅的话，网速是关键因素。
3，网络不稳定的话，tcp会无限重传，直到超时，而udp不会，只会表现为丢包，在网游中表现为卡顿，就像有人说的“像看幻灯片一样”。

无言以对

这个问题据我所知是这样：如果不采取特别的优化措施，那么TCP仅为每一个用户建立一个长链接就是一个不小的开销，在Windows上到了一定数目就不行了，linux能比windows多20%左右。不过我这个信息比较陈旧了，现在的情况可能会有改善吧。
关于网络状况与UI卡顿之间的关系，对客户端来说，可以在一定程度上处理一下，但是有限的，流畅度完全不受网络影响是很困难的，毕竟正常的逻辑是收到什么包做什么事，至于什么包该来而没来，考虑这些会很麻烦的

支撑用户量的问题是源于fd有限，有状态链接占用系统资源，但资源有限，倒不是链接的开销，链接的开销就是交换几个包而已。udp的话，无需系统层面保存状态，如果协议是无状态的，即整个交互无状态，业务层也无需保存什么了。另，tcp打洞还是不要想了，实测没什么设备支持，而且也不是麻烦一点点，网上写的那些东西，不知道谁写论文胡侃一通，姑且看看理论就可以了。udp打洞的成功率都不是很高，70%差不多吧。但是udp的有一个很大的好处，支撑100w的同时在线，2台打洞服务器就搞定了，成本小太多了。

Quote: 引用 27 楼 andrew57 的回复:

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

8K够了，你的问题应该不在这，这只是表象

Quote: 引用 28 楼 spirit008 的回复:

Quote: 引用 27 楼 andrew57 的回复:

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

8K够了，你的问题应该不在这，这只是表象

能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。

Quote: 引用 28 楼 spirit008 的回复:

Quote: 引用 27 楼 andrew57 的回复:

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

8K够了，你的问题应该不在这，这只是表象

能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。

Quote: 引用 31 楼 andrew57 的回复:

Quote: 引用 28 楼 spirit008 的回复:

Quote: 引用 27 楼 andrew57 的回复:

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

8K够了，你的问题应该不在这，这只是表象

能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。

不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈

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。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。
对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他

如果你指的抢夺是UDP频繁发送，导致TCP一直需要等待重传的话，好吧，那TCP估计是所有协议中最弱的了。

没必要意气用事，其实你只要听从我的建议百度一下TCP的拥塞控制，就全都明白了。既然你不愿意去，那我就简单形象地介绍一下。TCP并不知道你有多少带宽可用，所以也不知道以多大的速度发包合适，他采取的对策是一点一点增长，发现不对就快速降下来（linux是减半），降下来的依据是丢包率。他的这种机制就像谦谦君子，生怕妨碍别人，一旦妨碍了就马上退开。UDP自身没有拥塞控制，如果他不停地发，TCP就会发现他的包大量的丢失，就会降低速率，让出来的带宽就被UDP抢占了。

Quote: 引用 23 楼 halleyzhang3 的回复:

Quote: 引用 15 楼 spirit008 的回复:

Quote: 引用 13 楼 woshinia 的回复:

Quote: 引用 8 楼 spirit008 的回复:

Quote: 引用 6 楼 woshinia 的回复:

在网游中UDP用的比较多，丢包的话，就变现为卡，点击无响应等。如果长期一个包都收不到就会掉线，但对网络不稳定的情况有较好的容错性。
但如果用TCP的话，网络一旦不稳定就会直接掉线。

你凌乱了，卡，无响应只是ui线程阻塞，是你写程序的方式问题，和网络本质上没毛关系。
网络不稳定和掉线，跟用tcp和udp没关系。掉线重连好了。
大型服务，包括网游，用udp是因为需要一台机器撑更多的客户端。tcp的话，2w基本上限了。

1，在支撑更多的客户端方面，tcp和udp是一样的，都需要用网络模型优化，不要认为udp是广播，udp跟tcp一样需要为每一个用户发送和接受。
2，ui线程的阻塞在单机里当然是这样的，但网游需要根据服务器发来的响应更新ui，所以不流畅的话，网速是关键因素。
3，网络不稳定的话，tcp会无限重传，直到超时，而udp不会，只会表现为丢包，在网游中表现为卡顿，就像有人说的“像看幻灯片一样”。

无言以对

这个问题据我所知是这样：如果不采取特别的优化措施，那么TCP仅为每一个用户建立一个长链接就是一个不小的开销，在Windows上到了一定数目就不行了，linux能比windows多20%左右。不过我这个信息比较陈旧了，现在的情况可能会有改善吧。
关于网络状况与UI卡顿之间的关系，对客户端来说，可以在一定程度上处理一下，但是有限的，流畅度完全不受网络影响是很困难的，毕竟正常的逻辑是收到什么包做什么事，至于什么包该来而没来，考虑这些会很麻烦的

支撑用户量的问题是源于fd有限，有状态链接占用系统资源，但资源有限，倒不是链接的开销，链接的开销就是交换几个包而已。udp的话，无需系统层面保存状态，如果协议是无状态的，即整个交互无状态，业务层也无需保存什么了。另，tcp打洞还是不要想了，实测没什么设备支持，而且也不是麻烦一点点，网上写的那些东西，不知道谁写论文胡侃一通，姑且看看理论就可以了。udp打洞的成功率都不是很高，70%差不多吧。但是udp的有一个很大的好处，支撑100w的同时在线，2台打洞服务器就搞定了，成本小太多了。

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。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。
对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他

如果你指的抢夺是UDP频繁发送，导致TCP一直需要等待重传的话，好吧，那TCP估计是所有协议中最弱的了。

没必要意气用事，其实你只要听从我的建议百度一下TCP的拥塞控制，就全都明白了。既然你不愿意去，那我就简单形象地介绍一下。TCP并不知道你有多少带宽可用，所以也不知道以多大的速度发包合适，他采取的对策是一点一点增长，发现不对就快速降下来（linux是减半），降下来的依据是丢包率。他的这种机制就像谦谦君子，生怕妨碍别人，一旦妨碍了就马上退开。UDP自身没有拥塞控制，如果他不停地发，TCP就会发现他的包大量的丢失，就会降低速率，让出来的带宽就被UDP抢占了。

我就是这个意思，但是UDP这不叫抢占，因为其他类型的数据包都会使TCP等待重传，而UDP在其他数据拥塞的情况下基本不是丢包就是校验不过，也就是说是这些UDP包都是无效的，带宽都用来传递无效的包，效率并没有提高。也就是说UDP和其他协议传输包都比TCP强，也就是TCP最弱。

Quote: 引用 33 楼 spirit008 的回复:

Quote: 引用 31 楼 andrew57 的回复:

Quote: 引用 28 楼 spirit008 的回复:

Quote: 引用 27 楼 andrew57 的回复:

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

8K够了，你的问题应该不在这，这只是表象

能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。

不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈

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

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。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。
对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他

如果你指的抢夺是UDP频繁发送，导致TCP一直需要等待重传的话，好吧，那TCP估计是所有协议中最弱的了。

没必要意气用事，其实你只要听从我的建议百度一下TCP的拥塞控制，就全都明白了。既然你不愿意去，那我就简单形象地介绍一下。TCP并不知道你有多少带宽可用，所以也不知道以多大的速度发包合适，他采取的对策是一点一点增长，发现不对就快速降下来（linux是减半），降下来的依据是丢包率。他的这种机制就像谦谦君子，生怕妨碍别人，一旦妨碍了就马上退开。UDP自身没有拥塞控制，如果他不停地发，TCP就会发现他的包大量的丢失，就会降低速率，让出来的带宽就被UDP抢占了。

我就是这个意思，但是UDP这不叫抢占，因为其他类型的数据包都会使TCP等待重传，而UDP在其他数据拥塞的情况下基本不是丢包就是校验不过，也就是说是这些UDP包都是无效的，带宽都用来传递无效的包，效率并没有提高。也就是说UDP和其他协议传输包都比TCP强，也就是TCP最弱。

这个理解完全错了，我也快无言以对了。TCP的拥塞控制不是被动等待导致的，是主动放弃。UDP丢包是正常的，而网络拥塞和校验过不过完全没有关系，你看到的被动丢包是中间设备的主动丢弃。这里不存在哪个协议好的问题，他相应的设计都是恰当的，只是用途不同

Quote: 引用 34 楼 andrew57 的回复:

Quote: 引用 33 楼 spirit008 的回复:

Quote: 引用 31 楼 andrew57 的回复:

Quote: 引用 28 楼 spirit008 的回复:

Quote: 引用 27 楼 andrew57 的回复:

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

8K够了，你的问题应该不在这，这只是表象

能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。

不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈

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

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

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。其实迅雷是单线程的。所谓的多线程下载，是指文件分块而已，不是我们程序意义上的多线程。

TCP、UDP只是IP层上的协议，你所谓的对带宽的争夺只会发生在链路或者物理层，所以谈论这个没意义。
迅雷之所以分块下载，主要是分担服务器的压力，选择较小的负荷的服务器，速度就会更快。跟磁盘无关，因为中国的网速比硬盘写的速度慢的多，并且即使考虑硬盘写入速度，也不会考虑磁道之类，主需要考虑写入的时机和频率，只要先用内存保存着，最后写入硬盘就可以了，内存不够大的话就分批保存。

对带宽的争夺是实实在在的，并非没有意义，你了解一下TCP的拥塞控制策略就会明白这一点。
对迅雷这样的下载软件来说，应该是和磁盘无关。其实大概是我没说清楚，我也在想局域网上的大文件传输，这种情况下磁盘IO恐怕需要考虑了。总之我是在想UDP传输文件到底有什么用，为什么这么多人去做他

如果你指的抢夺是UDP频繁发送，导致TCP一直需要等待重传的话，好吧，那TCP估计是所有协议中最弱的了。

没必要意气用事，其实你只要听从我的建议百度一下TCP的拥塞控制，就全都明白了。既然你不愿意去，那我就简单形象地介绍一下。TCP并不知道你有多少带宽可用，所以也不知道以多大的速度发包合适，他采取的对策是一点一点增长，发现不对就快速降下来（linux是减半），降下来的依据是丢包率。他的这种机制就像谦谦君子，生怕妨碍别人，一旦妨碍了就马上退开。UDP自身没有拥塞控制，如果他不停地发，TCP就会发现他的包大量的丢失，就会降低速率，让出来的带宽就被UDP抢占了。

我就是这个意思，但是UDP这不叫抢占，因为其他类型的数据包都会使TCP等待重传，而UDP在其他数据拥塞的情况下基本不是丢包就是校验不过，也就是说是这些UDP包都是无效的，带宽都用来传递无效的包，效率并没有提高。也就是说UDP和其他协议传输包都比TCP强，也就是TCP最弱。

这个理解完全错了，我也快无言以对了。TCP的拥塞控制不是被动等待导致的，是主动放弃。UDP丢包是正常的，而网络拥塞和校验过不过完全没有关系，你看到的被动丢包是中间设备的主动丢弃。这里不存在哪个协议好的问题，他相应的设计都是恰当的，只是用途不同

引用 38 楼 halleyzhang3 的回复:

Quote: 引用 34 楼 andrew57 的回复:

Quote: 引用 33 楼 spirit008 的回复:

Quote: 引用 31 楼 andrew57 的回复:

Quote: 引用 28 楼 spirit008 的回复:

Quote: 引用 27 楼 andrew57 的回复:

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

8K够了，你的问题应该不在这，这只是表象

能否详细说说，因为我一直怀疑是处理不够快导致的，所以才加二级缓冲。但偶尔还有丢失，毕竟没有tcp那样的重传机制，自己也没做。

不做重传，我踩一脚网线，你图片上的人头岂不是丢了，哈哈

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

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

TCP之所以能检测到网络状态是拥塞的，就是发送一个包的数据，然后校验这个包的长度，如果长度和校验不对，说明包在传输过程中被插入了一些其他数据，也就是跟其他数据包冲突了，即拥塞了。丢包就是拥塞么？那断网不是要无限等。并且在一定间隔时间后，TCP同样会发送这样一个包，如果通不过就等待更长时间，直到通过检验再加快速度发包，主动被动什么的，我是不理解你想表达什么。同理在其他数据包拥塞时，UDP包会被插入其他数据，从而导致校验失败。是你自己提出UDP可以抢占TCP的带宽的，我并没有说哪个协议好坏，并且我是同意的，只是这是TCP的特性，UDP和其他数据没有这个机制，但UDP与其他数据拥塞时会造成带宽浪费而已。

UDP 是广播
TCP 是点对点

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