在比较理想的环境下传输大量数据，是否可以用 UDP 完全替代 TCP？

[gaayyy]

简单来说，就是内网大约 100 多台机器分布存放了一些较大的数据文件，每台大概有 2T 的样子，现在想把这些分散的文件集中备份到三套专用的存储服务器上。没办法拆硬盘，也没办法改变网络结构，大致计算了一下数据量，理想状态下，等待传输的数据量是：2TB * 1024 * 1024 = 2097152 MB, 而千兆以太网 1Gbps / 8 = 128MBps，存储服务器都是走的硬盘 RAID，硬盘写速率应该能跟上，所以一台机器时间大约是 2097152 MB / 128MBps / 3600 = 4.55 小时。

环境是纯内部网络，没介入互联网，机器都是 DELL 和 hp 的机器，交换机用的是 NetGear 千兆，硬件应该都没问题。但是时间限制只能在周末或者晚上操作。现在主要是考虑到千兆网的 128MBps 是理想状态下的速率，如果自己写一个文件传输的小工具，用 UDP 替代 TCP，这样对数据传输速率是否有改善？想了解一下是否有 v 友处理过类似的案例。

[newmlp]

用 tcp，这么多的数据丢个包就完蛋了，而且理想环境下，二者速度没差别

[fuyufjh]

内在逻辑有问题啊。再理想的环境，到达带宽上限都会丢包的；如果一个包都不丢，那链路使用率肯定不够高。

[likuku]

去年碰巧也遇到过有相当长一段时间里，几乎每周都会有总量 2-3TB 的大文件(视频为主)产生，几十 TB 的 NAS

[likuku]

#43 没敲完，按错键被快速发出了

几十 TB 的 NAS 勉强够用，设备间导入导出的确是个麻烦，即便可用 SSD 作移动硬盘传递，设备间传输还是太慢。

做过一些勘查，发觉能满足需求(拆硬盘没问题，只要快就行)，唯有 Type-C 物理接口的雷电 3 的速率才可以满足。

因为可动用的资金有限，最后还是委屈用 USB-3.0

[likuku]

我们 NAS 是将 4 个网口在千兆交换机上绑定聚合的，所以 NAS 单 IP 总带宽就是千兆 x4，
实际使用中的确是可以接近 400Mbytes/sec 的速率读写数据，但对于我们动辄需要读写上 TB 的单一大文件，
依然是缓慢(视频处理任务里，很多时间耗在数据传输上)，

客户端(工作机)主板所限制(最终还是成本所限)，PCI-E 剩余插口不足，没办法插 4 块网卡，用不起 4 口网卡，
所以最终工作机还是被局限在千兆网络上。

[likuku]

@a7a2 很早以前看过一些介绍 rsync 比对 /传输 算法的文，记得它们都介绍 rsync 是基于存储块的分析比对来高效查分传输的，并不是针对文件对象来比对。

"无论是本地或远程文件传输，rsync 首先创建每个源文件块校验的索引。此索引用于查找可能存在于目标中的任何相同数据块。一旦这种块存在，块就被就地使用，而不是从源复制。这大大加快了存在小差异的大文件的同步。"
from: https://wiki.archlinux.org/index.php/Rsync_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)

"rsync 实用程序使用由澳洲计算机程序师安德鲁·垂鸠（ Andrew Tridgell ）发明的算法，在当接受端计算机已经有相同结构（例如文件）但不同版本时，有效的将结构传输过通信连接。

接受端将文件拷贝打散成固定大小为 {\displaystyle S} S 的不重叠片段，并对每个片段计算两个校验和：MD4 散列函数与一个较弱的轮替校验和（ rolling checksum ）。它将这些校验和送给发送者。通信协议版本 30 （与 rsync 版本 3.0.0 一并发行）现在使用 MD5 散列函数以替代 MD4"
from:
https://zh.wikipedia.org/wiki/Rsync#%E6%BC%94%E7%AE%97%E6%B3%95

[mamax]

网络环境比较差的时候才会用 udp，参考以前的 qq，网络环境好 tcp 更好

[mamax]

@a7a2 丢包严重用 udp 好吧

[qile1]

@mamax 丢包严重用 tcp 吧？
udp 是在数据不敏感的传输上，如语音视频流
tcp 保证传输两端数据一样

[yylucifer]

额。。自己写一个？

还是 scp 搞定？

[ryd994]

我觉得说用 UDP 的各位是不是都有一种错觉？我能比设计协议的大佬做的更好？大量数据的可靠传输，这就是 TCP 的目的啊。UDP 的主要应用不是数据传输，而是无连接，短会话，低延迟。或者某些情况下允许丢包，比如直播、语音。

@a7a2 udp 相对 tcp 需要三次握手已经可以分析出
这和握手有什么关系？你传文件当然是长连接啊，两个包有多少开销？
你说的是协议数据开销，我说的是高速网络下 CPU 才是瓶颈
没见过高速网络的人可能没感觉。如果没有 jumbo frame，只用单核，就算有 tso，也只能跑 20-30G。UDP 更低，10G 都未必到。

@gaayyy 数据少的机器，走网络，数据多的机器，用 USB3 的移动硬盘或者 U 盘。
永远不要低估一辆装满磁带在高速公路上飞驰的小货车的传输带宽。—— 安德鲁·塔能鲍姆（ Andrew Tanenbaum，1981 ）

[ryd994]

@ucanuup 机械硬盘也可以
重点是，你可以用很低的成本买一堆硬盘 u 盘。他们是可以并行工作的。单机是比网络慢。但是量大肯定超过网络。
走两圈就可以了。跑一圈把 U 盘插上网，然后再跑一圈收回来就是了。不怕被盗的话白天再收都可以。

[msg7086]

@qile1 只要完整实现了重传功能，TCP 和 UDP 没有本质上的差别。
差别在于高丢包环境下你可以用 UDP 自己实现重传算法，而不是用 TCP 自己的（理想化的）重传机制。
丢包严重的时候 TCP 的带宽会比是自己实现重传功能的 UDP 的带宽小得多。

[kennylam777]

打算重新發明 TCP 前, 請閱讀一下 DCTCP
https://tools.ietf.org/html/rfc8257

[plko345]

好像 nfs 是自身验证数据完整的，而不是通过 tcp 协议，还有不少工具也是

[jimzhong]

现在的 TCP 拥塞控制算法已经挺先进的了，如果网络比较稳定，是可以跑满千兆的，没必要自己做基于 UDP 的可靠传输协议。

[ericls]

TCP 有 HOL

[mamax]

@qile1 不敏感数据确实 udp 好。但是 tcp 的确认机制造成了它在丢包严重环境下的传输效率极低，确认不了又要重传，搞不好连三次握手都建立不起来。qq 当年好像就因为网络环境差选择了 udp。至于说保证数据一直行，我觉得在应用层做会更好，比如每个 udp 尾都加上检验。你觉得呢？

[znood]

按照楼主说的 TCP 根本到不了瓶颈，在大块数据传输时 TCP 轻松跑满带宽，UDP 你要自己做校验

[likuku]

@ryd994 是的，假若只是传统的网卡设计，的确高速网卡(10Gbps 起步)，是网卡没跑满但 CPU 因为要参与网络传输给耗得差不多了（某年某会议上某电商巨头的技术大佬分享经验时特别提吐过这个槽点）。

这两年一些大厂(amazon 已经开始用)出了一些“自带硬件加速”的高速网卡，来极大减轻网络传输时 CPU 的负载。