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
我上个号因为骂说这个词的人被封了。但是我还是想骂。
|