这是一个创建于 520 天前的主题，其中的信息可能已经有所发展或是发生改变。
HTTP/3.0 ，使用了基于 UDP+迪菲赫尔曼算法之上实现的 QUIC 协议，抛弃了 TCP 协议。 维基百科： https://zh.wikipedia.org/wiki/HTTP/3
 |
1
mxT52CRuqR6o5 2023-06-26 10:51:17 +08:00
上层协议本来也不太会关注底层 tcp 的流啊，即使是 http1.0
|
 |
2
selca 2023-06-26 10:52:46 +08:00
粘包不粘包一般不是写 http service 的这群人关注的
|
 |
3
pkoukk 2023-06-26 10:58:23 +08:00
应用层不关注这些东西
|
 |
4
lambdaq 2023-06-26 11:02:35 +08:00
只要是流式协议，妄图通过间歇性数据收发代替「数据分隔符」都会遇到所谓的「粘包」问题
|
 |
5
monkeyWie 2023-06-26 11:09:32 +08:00  1
当你在谈论 http 的时候，你就已经在谈论粘包了
|
 |
6
hankai17 2023-06-26 11:13:26 +08:00 1
UDP 虽说发多少次 收多少次
但 streamFrame 就没有 length 跟 offset 了? 高丢包重传下收包时 一堆 gap("粘包")要处理 哈哈 我们粘包警察永不失业!!! 花了半年时间把 quic-go 的传控逻辑抽出来了 https://github.com/hankai17/quic-fiber 实现有 可靠传输 流量控制 拥塞控制(reno cubic bbr) 可以用协程很快的编写代码验证 拥塞控制算法逻辑 欢迎 star fork 测试 |
 |
7
yolee599 2023-06-26 12:00:34 +08:00
能提出粘包问题的人一般没有能力实现 http 协议，所以一般都是使用现成的库，而现成的库不会有这个问题
|
 |
8
Jirajine 2023-06-26 12:06:37 +08:00 2
quic 和 tcp 在这一点上没有什么区别，认为 tcp 存在“粘包”问题的人不会到了 quic 就有什么变化。
|
 |
9
mringg 2023-06-26 12:10:58 +08:00 1
我感觉会更迷惑的，从传输层迷惑到应用层了。
|
 |
10
sadfQED2 2023-06-26 12:39:55 +08:00 via Android
大哥，http 是应用层，粘毛线包啊。你这个粘包警察越权管理了，你知道不
|
 |
11
nothingistrue 2023-06-26 12:42:03 +08:00
只要你在流通道上传递「消息」这种非连续性的数据，你永远都需要分帧取帧。这个时候你用不用 TCP 都没区别。
另一方面，分帧取帧是应用层协议干得活，当你已经使用了作为应用层协议的 HTTP 时，不管用哪个版本，都不再需要自己处理分帧取帧，这不用等到 3.0 的到来。而如果你是直接在传输层之上做应用开发的话，那 HTTP 就是版本号刷到了五十万也跟你没关系。 |
 |
12
PVXLL 2023-06-26 13:33:29 +08:00
"沾包"这个词谁发明的，居然还这么流行。
|
 |
13
jiulang 2023-06-26 13:48:33 +08:00
沾包是假命题，警察也是假命题。
流是真的，tcp 流是真的，quic 流也是真的 |
 |
14
IvanLi127 2023-06-26 13:52:35 +08:00 via Android
人家自己创造的岗位，下不下岗也是人家说了算呀
|
 |
15
fgwmlhdkkkw 2023-06-26 16:44:04 +08:00
我上个号因为骂说这个词的人被封了。但是我还是想骂。
|
Select Language