大带宽服务器对 tcp/udp 传输理解的不深,突发奇想,这样解释对吗,望大佬来解释一下

握手完了后面就是 2 倍了（因为要 ACK ）

握手过程只会让 TCP 在建立连接的时候比 UDP 多发几个建连包而已，并不会影响真正数据传输时的延时。而像 1 楼说的因为 ACK 所以两倍时延其实也不对，TCP 是全双工的协议，ACK 本身就可以作为一个标记包含在数据包内。真正造成 TCP 比 UDP 延时高的是因为 TCP 的流量控制和拥塞控制，也就是常说的滑动窗口 Reno 算法等等

理想状态下没有差别，udp 要实现可靠性也需要自己实现 ack

月经贴

这个问题估计论坛里%95 的人都打不上来（包括我。。。）。我的理解是你要基于使用场景来问，应用层协议比如 http 的长链接和短连接都是 TCP 延迟都是不一样的，而且三次握手也仅限于建立连接的时候。此外拥塞控制流量控制这些都是基于高数和统计得出来的结论，你要往深了挖得找 phd 。

我想的是在握手的这个时间内是不是要白白等着连接建立好才能发数据,假设客户端信号从光纤传出去到另一台服务器需要耗时 5ms,三次握手是不是就相当于 5*3=15ms,然后再加上连接后数据传输的 5ms,总共是不是算 20ms, udp 的话是不是就是直接 5ms 就行了,不知道这样理解对不对

简单理解的话，是这样没错，建连会增加主链路耗时，这也是为什么 https 比 http 耗时要高，因为需要先交换秘钥实现 ssl 握手

这个握手可以是一次性的，连接完成之后一直复用，延时就没区别了。另外 ACK 不是两倍时延，因为 TCP 是全双工的而且有发送窗口，一次性发多个包，不是一个确认完了再发下一个。真正影响 tcp 发包速率的是拥塞控制，TCP 是慢启动，窗口达到实际允许的最大值需要很多个周期，一旦丢包了就会回到解放前

ack 不会造成额外的延迟，只有网络质量差，需要频繁重传的时候才会造成延迟高

从一条流上统计出来是 1RTT，单个包看的话都是 2RTT，因为没有 ACK 等于没收到，说不定还有等重发（

不是。

买本教材看看吧

tcp 对比 udp 的耗时，和几次握手没关系。主要是确保不丢失和时序。

可以对照看下 QUIC 基于 udp 重写的 tcp 简化握手 提高容错

哈哈哈哈哈哈哈哈哈哈楼主真可爱~

协商的时候是的，协商完后没什么区别

看场景

感觉限制只发一个字节数据，还可以讨论讨论