- 主题:为什么说HTTP2 比HTTP1.*快呢
根本原因是http1没有标识请求包,响应包编号的字段,可能引起队头堵塞
--
FROM 223.160.129.*
说穿了是在应用层重新寨了一套IP协议……
【 在 deusomax 的大作中提到: 】
: 说复用连接的都没看到本质,http1.1可以复用连接,keep-alive也是啊.
: 本质是,1.1是个同步的协议,一个连接在未收到响应前,是不会next请求的.
: 而2,是个异步的协议,客户端可以一下狂发成千上万个请求在一个连接上,提高了连接的利用率.
: ...................
--
FROM 222.70.18.*
支持zip?
【 在 chzhang7901 的大作中提到: 】
: 网络上传的不是大部分是字符串吗?
: 字符串二进制和文本没区别啊。
: --
:
发自「今日水木 on iOS」
--
FROM 120.7.12.*
有个疑问,TCP协议中,并不需要对方ACK后,再发送请求,
对于同一个连接,假设传输数据很大,实际上TCP的窗口可能也很大。如果是局域网(低延时,高带宽),我不知道效率提升点在哪?
如果是说对于同一个网站访问。(不同资源的请求),那么确实可以做到复用在一个连接上,相当于在客户端打包了请求。但是,这样做,实际上未必比每一个资源请求使用一个连接来的快(前提是,连接数不能过多),因为这个在服务器端也是并行处理,甚至是多机处理;当然合并复用的一个巨大优势是服务端可以提供更多的连接数,所谓耳闻能详的高并发。
【 在 deusomax 的大作中提到: 】
: 说复用连接的都没看到本质,http1.1可以复用连接,keep-alive也是啊.
: 本质是,1.1是个同步的协议,一个连接在未收到响应前,是不会next请求的.
: 而2,是个异步的协议,客户端可以一下狂发成千上万个请求在一个连接上,提高了连接的利用率.
--
FROM 120.244.162.*
QUIC选UDP好像是因为TCP的慢启动无法简单规避
【 在 lushan5436 的大作中提到: 】
: 有个疑问,TCP协议中,并不需要对方ACK后,再发送请求,
: 对于同一个连接,假设传输数据很大,实际上TCP的窗口可能也很大。如果是局域网(低延时,高带宽),我不知道效率提升点在哪?
: 如果是说对于同一个网站访问。(不同资源的请求),那么确实可以做到复用在一个连接上,相当于在客户端打包了请求。但是,这样做,实际上未必比每一个资源请求使用一个连接来的快(前提是,连接数不能过多),因为这个在服务器端也是并行处理,甚至是多机处理;当然合并复用的
: ...................
--
修改:oldwatch FROM 222.70.18.*
FROM 222.70.18.*
本质是移动互联网时代终端最后一跳连接的可靠性和以前比是下降了的
丢包和换IP变得很常见
而TCP应对这些问题的开销都比较大
还不如直接UDP然后上层花式规避来得方便
【 在 oldwatch 的大作中提到: 】
: QUIC选UDP好像是因为TCP的慢启动无法简单规避
: 的
--
FROM 220.250.21.*
嗯,说穿了就是基于UDP在应用层重新发明了一遍“自主可控”的TCP
【 在 cybereagle 的大作中提到: 】
: 本质是移动互联网时代终端最后一跳连接的可靠性和以前比是下降了的
: 丢包和换IP变得很常见
: 而TCP应对这些问题的开销都比较大
: ...................
--
FROM 222.70.18.*
了解了,多谢了,那这个慢启动,感觉最不适合的场景是,高带宽,低延时,但网络不稳定,时好时坏
【 在 oldwatch 的大作中提到: 】
: QUIC选UDP好像是因为TCP的慢启动无法简单规避
:
--
FROM 120.244.162.*
慢启动增加往返,往返带来硬延时,延时对用户感知的影响远胜带宽
又查了一下,Http/2在应用层作分包的另一个优势就是
可以在网络层实现多路复用,而不是一个资源一个请求
【 在 lushan5436 的大作中提到: 】
: 了解了,多谢了,那这个慢启动,感觉最不适合的场景是,高带宽,低延时,但网络不稳定,时好时坏
--
FROM 222.70.18.*