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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2350 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

Mbps

udp

传输

机器

71 条回复 • 2018-06-25 16:23:00 +08:00

exkernel

2018-06-23 13:24:34 +08:00 via iPhone

没有改善 udp 也只能 125M/s 最多而且 udp 还是可能拥堵而丢包

msg7086

2018-06-23 13:26:47 +08:00

代替有什么好处？理想环境下每个包都能完美到达，无需重传，你用 UDP 解决了什么问题呢？

realpg

2018-06-23 13:31:13 +08:00

随便搭个万兆局域网就好了
而且就这网络环境也没啥拥塞的，TCP 轻松跑满

missdeer

2018-06-23 13:32:59 +08:00

用 UDP 组播大概可以只用点对点传输的 1 ／ 3 的传输时间，但得找个 UDP 可靠传输的协议来做

lihongjie0209

2018-06-23 13:38:15 +08:00

主要瓶颈难道不是在你交换机上吗, 换协议也没用啊

a7a2

2018-06-23 13:53:32 +08:00

我认为是以用 UDP 完全替代 TCP。

应该还有些更尖端的技术可以做到基于数据块的变动而自动同步该块，这样就可以做到无需中断服务

@gaayyy

swulling

2018-06-23 13:55:56 +08:00 via iPhone

理想环境 TCP 很完美，就是世界不理想，所以大家才用 UDP

DevNet

2018-06-23 14:01:59 +08:00 via Android

大兄 dei，你这个瓶颈在网卡，跟协议就没关系了。推荐使用网卡绑定，需要在服务器和交换机上分别设置，4 网口绑成负载均衡模式就是 4 千兆的速度了。

另外，一般说的 TCP 慢，是指在数据的刚开始发送的阶段，需要经过 3 个包的握手，之后发包大小根据滑动窗口大小递增 1,2,4,8...这样，直到达到最大带宽，之后速度跟 UDP 就没区别了。UDP 发包不需要经过这个过程，可以直接从最大带宽开始发。

希望我理解的没错。

lslqtz

2018-06-23 14:05:20 +08:00

@msg7086 TCP 要 ACK 吧

nazor

2018-06-23 14:05:40 +08:00 via iPhone

局域网的网络状况很好，换个协议也不会有提升的。

tao1991123

2018-06-23 14:25:24 +08:00 via Android

了解一下阿里开源的文件分发系统 Drangonfly 继续 P2P 技术加速分发

hrong

2018-06-23 14:36:14 +08:00 via Android

有这时间研究，赶紧跑起来也就十来个小时吧。。。。

likuku

2018-06-23 14:45:18 +08:00

买不起 /不愿投资搞比较高标准的 NAS (冗余度至少达到可承受 2 块硬盘同时坏掉)，还得有可靠备份，那么可以：

人力资源丰富，吩咐小弟去找一堆机器组 Hadoop 鸡群吧，设定好冗余策略(随时都可以改)只要不断增添机器，
HDFS 整体容量就能不断扩张，就是用起来比较麻烦，不像共享磁盘，更像个 RSYNC 服务器。

Livid

MOD

2018-06-23 14:47:06 +08:00

https://github.com/mholt/caddy/wiki/QUIC

确实有人在做这样的试验。

likuku

2018-06-23 14:49:11 +08:00

多网卡绑定...只给存储器服务器作，也只是提高了服务器的带宽，客户机输出带宽并无改善。

RAID 写入足够？你真的这么看？绑 4 块网卡，至少峰值就是 400Mbytes/sec 了...

MeteorCat

2018-06-23 14:51:52 +08:00 via Android

UDP 可有保证传输可靠性的处理方法，但是完全替代也不好说，理论上速度会有所改善，但是丢包风险上面 UDP 也不低

hsuan

2018-06-23 14:55:54 +08:00 via Android

局域网应该不会丢包，用 udp 完全可以

ryd994

2018-06-23 15:07:15 +08:00 via Android

说 UDP 卖笑低可真未必，TCP 可以用 tso，内存里全是 65k 的大包，让网卡硬件分包，对 CPU 压力反而更小
你这个需求，应该服务器做 bonding 或者直接就多 IP
客户端上传随机挑一个

或者有 USB3 的话，买一堆移动硬盘，直接插上去拷就是了。跑一圈全部插上去开始，再跑一圈收回来就是了。USB3 就是每台 5G，并行肯定比你千兆网快。就算做 bonding，也会遇到交换机背板能力的瓶颈

还可以 rsync，只要每天变动不大的话，慢慢 sync 就是了，管它要几天

@lslqtz delayed ACK，实际 ACK 数量很少

@a7a2 恭喜你重新发明 TCP

ryd994

2018-06-23 15:07:48 +08:00 via Android

-卖笑
+开销

aru

2018-06-23 15:10:28 +08:00

内网环境 TCP 基本可以达到理论速度，协议消耗并不多，优化余地有限。
网络拓扑预测是多个接入交换机通过一个汇聚交换机互联，互联带宽为 1Gbps。
网络硬件是主要瓶颈。
可能的优化途径：
不增加硬件投入
1. 存储服务器通过多网卡绑定，将带宽由 1Gbps 提升到 2Gbps 或更高
2. A. 存储服务器网卡接在汇聚交换机或
B. 存储服务器尽量和上传数据的服务器在同一个交换机下（即减少跨交换机网络传输）

增加投入
接入交换机换成万兆上联，汇聚交换机全万兆，存储服务器升级为万兆网卡并接入到汇聚交换机

gamexg

2018-06-23 15:23:43 +08:00 via Android

经验上内网千兆 tcp 可以跑满，换 udp 优化余地应该很小。

lslqtz

2018-06-23 15:31:33 +08:00

@ryd994 虽然数量较少，也可以说成是一种微小的开销吧。
实际上如果是绝对理想的环境，我觉得 UDP 也未尝不可，不过实际上没有这么理想的环境。。。

msg7086

2018-06-23 15:37:44 +08:00

@lslqtz 现实环境里，UDP 为了保证不丢，一样需要类似 ACK 的机制。
还要加上包编号什么的，我觉得和重新发明一遍 TCP 差距真的不大。
能提升 1%的效能？都到不了吧我觉得。
这么折腾一遍下来远不如加两块网卡揉一起来得好用……

jedihy

2018-06-23 15:48:05 +08:00 via iPhone

这样的环境关掉 tcp 时间戳可以略微提升性能。其他没什么好折腾的了。

a7a2

2018-06-23 16:24:20 +08:00

@ryd994 你理解错了。

udp 确实比 tcp 要快传大文件大量数据的时候并且在稳定的网络环境中，udp 相对 tcp 需要三次握手已经可以分析出，当然在丢包严重的环境中肯定 tcp 好如果 udp 没有改造的话。

还有 rsync 是基于文件同步的，就是说如果这个文件 1tb 大小因为修改了其中 1 点点儿重新同步整个文件一次

msg7086

2018-06-23 16:33:24 +08:00

@a7a2
> rsync 是基于文件同步的，就是说

然而 rsync 的帮助文件并不同意你的说法。

-W, --whole-file copy files whole (without delta-xfer algorithm)
也就是不指定-W 的话就是差异传输。

请问你这个说法是哪来的？

yippees

2018-06-23 16:35:44 +08:00

飞鸽 PK FTP

msg7086

2018-06-23 16:36:21 +08:00

其实说了这么多，还是拿几块移动硬盘拷起来最快了。你 128MB/s 是完全没考虑到分包 overhead 的情况，实际能跑出来的也就 110MB/s 上下。要我的话就挂着慢慢跑就是了，你要实在等不及那就移动硬盘拷。

ucanuup

2018-06-23 16:40:52 +08:00

@a7a2 rsync 使用了非常牛逼的算法，只会同步文件差异。算法见： https://coolshell.cn/articles/7425.html

a7a2

2018-06-23 16:43:11 +08:00

@msg7086 学到了，以前使用不求甚解。

ucanuup

2018-06-23 16:44:30 +08:00

@msg7086 那你得用 SSD 的移动硬盘，因为机械硬盘拷贝速度也不快。

silencefent

2018-06-23 16:46:41 +08:00

1Gbps/8 = 128M/s
机械硬盘速度写入大文件在 160M/s
但是！！！图片小文件远小于 20M/s
所以 100 来台电脑同时使用，万兆网络基本满足需要，如果资金紧张，分拆 3 条千兆网络对应接收端也可以满足，这瓶颈和 TCP/UDP 无关，接收端需要上 intel 的傲腾 900P 会好一点

msg7086

2018-06-23 16:48:17 +08:00

@ucanuup SSD 也不是必须。移动硬盘可以买不止一块，拷起来速度是算并发的，这和带宽有限的交换机不一样。

msg7086

2018-06-23 16:50:07 +08:00

@silencefent 人家存储服务器也没说只插了一块硬盘啊……
而且人家也说了是较大的数据文件啊……

silencefent

2018-06-23 17:13:32 +08:00

@msg7086 一些较大的数据文件有两种释义：单个文件较大 /文件夹较大，没给明确的条件就不用去臆测了，跟我无关

reus

2018-06-23 18:36:50 +08:00

一来 UDP 也不比 TCP 快，二来就算本机，UDP 也会丢包。
总之就是不能。

x7395759

2018-06-23 19:15:46 +08:00

不是

niubee1

2018-06-23 19:33:36 +08:00

等你写好了数据都传完了

3dwelcome

2018-06-23 19:36:19 +08:00 via Android

@a7a2 说反了吧，tcp 在掉包环境上表现很差，所以才有 bbr 之类补丁。

newmlp

2018-06-23 19:44:15 +08:00

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

fuyufjh

2018-06-23 20:32:47 +08:00

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

likuku

2018-06-23 21:12:45 +08:00

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

likuku

2018-06-23 21:17:51 +08:00

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

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

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

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

likuku

2018-06-23 21:24:19 +08:00

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

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

likuku

2018-06-23 21:30:55 +08:00

@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

2018-06-23 21:41:04 +08:00 via Android

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

mamax

2018-06-23 21:42:37 +08:00 via Android

@a7a2 丢包严重用 udp 好吧

qile1

2018-06-23 22:02:38 +08:00 via Android

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

yylucifer

2018-06-24 01:21:32 +08:00

额。。自己写一个？

还是 scp 搞定？

ryd994

2018-06-24 02:18:00 +08:00 via Android

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

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

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

ryd994

2018-06-24 02:22:10 +08:00 via Android

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

msg7086

2018-06-24 04:39:35 +08:00

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

kennylam777

2018-06-24 05:04:52 +08:00

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

plko345

2018-06-24 06:51:51 +08:00 via Android

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

jimzhong

2018-06-24 06:52:46 +08:00

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

ericls

2018-06-24 07:03:27 +08:00 via iPhone

TCP 有 HOL

mamax

2018-06-24 08:21:37 +08:00 via Android

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

znood

2018-06-24 11:39:36 +08:00

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

likuku

2018-06-24 13:09:19 +08:00

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

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

eurokingbai2

2018-06-24 13:26:25 +08:00

用 mpi 呗。。

ryd994

2018-06-24 14:52:30 +08:00

@likuku 你说的这是 smartnic，是另一回事了。我说的 tcp 性能问题局限于单核下。使用支持 receive side scaling 的网卡，利用多队列多连接完全可以跑满。
smartnic 普通企业用户用不到的，基本上是云厂商为主。实现虚拟网络，隔离不同用户的虚拟机，这个工作以前是由宿主机的虚拟路由器完成。到了高速网卡时代，这样做技术上不是不可以，但是要消耗大量的主机性能，成本太高了。smartnic 的硬件加速，主要是这些对 SDN 处理的加速。
也并不只是 AWS，国内外各大云的所谓“高性能网络”、“优化网络”，基本上都是这个。

dorothyREN

2018-06-24 19:36:01 +08:00

自己压一根 AB 线不就行了，为什么要搞这么麻烦
@gaayyy @exkernel @msg7086 @realpg @missdeer @lihongjie0209 @a7a2 @swulling @DevNet @lslqtz @nazor @tao1991123 @hrong @likuku @Livid @MeteorCat @hsuan @ryd994 @aru @gamexg @jedihy @yippees @ucanuup @silencefent @reus @x7395759 @niubee1 @3dwelcome @newmlp @fuyufjh @mamax @qile1 @yylucifer @kennylam777 @plko345 @jimzhong @ericls @znood @eurokingbai2

gamexg

2018-06-24 20:57:33 +08:00

@dorothyREN #63 不理解什么意思，硬件上已经是千兆网络了，想继续提升硬件只能上万兆网络或者多网卡聚合，用 AB 线看起来不会提升多少。

likuku

2018-06-24 21:21:24 +08:00

@dorothyREN
@gamexg 就是交叉对联线，普通常用网线两头都一样的线序标准(586A/586B)，若一头是 A，另一头是 B，即 AB 线

AB 线可以让两张网卡直接通讯(里面一对数据收发线对掉，让两张网卡收发对应起来)

千兆网卡的标准内置了“线序自动侦测和自动翻转"，其实已经可以用一根普通网线对联两张网卡。

我实践中也遇到过两张千兆网卡(最近 3 年内)，使用优质网线(超五类,六类)直接对联，实际传输速率却非常低，
直到用两根网线和一台交换机把它们连起来才达到正常速度(Debian/Ubuntu)。

gamexg

2018-06-24 21:26:26 +08:00

@likuku #65 明白 AB 线的意思，不理解的是目前已经是千兆网络了，改成网线直连比较麻烦效果应该也有限。
而且如果本身已经是多网卡聚合，那么这么做还会是负面效果。

DevNet

2018-06-24 23:01:41 +08:00 via Android

@dorothyREN 现在网卡都是自动反转了，而且服务器用网线直连也解决不了网卡瓶颈。

不考虑成本的话，合理的办法就是给存储网络单独新建一套 SAN，服务器插 HBA 卡，全光纤存储交换。也不用改变现有的 LAN。

楼上大部分都被协议带偏了，内网传输基本上不需要考虑协议快慢吧。公网的话，其实可以看看谷歌的 QUIC，基于 UDP，又做了一些可靠性的保证，比 TCP 快，比 UDP 可靠。chrome 浏览器和谷歌服务器通讯一直在用这个协议。这个协议也已经提交到 IETF，应该不久之后就会标准化。

Reficul

2018-06-24 23:46:04 +08:00 via Android

非要重新发明 TCP 的话，有个叫 udt 的协议。rsync 其实挺好的

msg7086

2018-06-25 01:46:21 +08:00

@dorothyREN
这都 8012 年了，我以为大家都知道网卡支持自动翻转了呢……
这还需要单独拿出来 at 所有人提一遍？侮辱人也要有个限度。

@likuku 服务器级的一般没这个问题吧。

@DevNet 如果能加钱的话，应该单独给存储上万兆，然后用千兆交换机级联口连上，只要背板速度够，还是能跑出万兆速度的。
QUIC 我是等了太久了，好几年前就想上的，一直没见广泛实现。
Caddy 真的是牛逼，各种新特性都是他先上的。

webjin1

2018-06-25 03:24:58 +08:00 via Android

如果是局域网，每个传输节点网络可控的话，还不如把交换机每个端口启用巨型帧，电脑网卡也启用。

yippees

2018-06-25 16:23:00 +08:00

@dorothyREN 另外 100 多台机器