awesome-fenix
awesome-fenix copied to clipboard
fenixsoft
「Comment」https://icyfenix.cn/architect-perspective/general-architecture/diversion-system/transmission-optimization.html
https://icyfenix.cn/architect-perspective/general-architecture/diversion-system/transmission-optimization.html
"因此，把小文件合并成大文件，在HTTP/2下是毫无好处的。" 把小文件合并成大文件对于HTTP/2来说有什么坏处吗？无论是否合并都只有一个TCP连接，而且也都是要等出错的TCP包，似乎在多个小文件的情况下即使有出错的TCP包也可以先显示一部分？
@UUNNFLY "因此，把小文件合并成大文件，在HTTP/2下是毫无好处的。" 把小文件合并成大文件对于HTTP/2来说有什么坏处吗？无论是否合并都只有一个TCP连接，而且也都是要等出错的TCP包，似乎在多个小文件的情况下即使有出错的TCP包也可以先显示一部分？
浏览器读一个大文件只有一个连接，读多个小文件则是有可能并发的，现在浏览器一般都支持对同个域名至少6个连接。
出错重传方面的影响存在但其实很理论化，实际中影响并算不大；实际影响最大的是用户观感上的原因，分散的小文件允许先显示一部分，哪个文件下载完了就显示哪个，而大文件必须等到整个文件都下完后才能用CSS切图，然后再显示。
wiki 上QUIC的主要优点：
Instead, each QUIC stream is separately flow controlled and lost data retransmitted at the level of QUIC, not UDP. This means that if an error occurs in one stream, like the favicon example above, the protocol stack can continue servicing other streams independently
这里我有个人的不同观点，我们一直称赞OSI 7层协议的优点在于每层之间松耦合，各自负责承担不同的责任。UDP和TCP都是传输控制层的协议，滑动窗口、拥塞窗口、三次握手等等特点，虽然某些场景下的缺点，但是却适应了广大的场景。
但是像QUIC这种在http协议中(应用层)来解决传输层的问题(separately flow controlled and lost data retransmitted at the level of QUIC)，是不是违背了OSI 协议一直以来的优点呢？
wiki 上QUIC的主要优点：
Instead, each QUIC stream is separately flow controlled and lost data retransmitted at the level of QUIC, not UDP. This means that if an error occurs in one stream, like the favicon example above, the protocol stack can continue servicing other streams independently
这里我有个人的不同观点，我们一直称赞OSI 7层协议的优点在于每层之间松耦合，各自负责承担不同的责任。UDP和TCP都是传输控制层的协议，滑动窗口、拥塞窗口、三次握手等等特点，虽然某些场景下的缺点，但是却适应了广大的场景。
但是像QUIC这种在http协议中(应用层)来解决传输层的问题(separately flow controlled and lost data retransmitted at the level of QUIC)，是不是违背了OSI 协议一直以来的优点呢？
确实可以理解为丢失重传可以说并不符合OSI模型的导向，但OSI不是协议，不带有强制性，还是那句话，打破固有的原则，只要合理，便是创新。 况且，这种例子并不需要追溯到QUIC，在HTTP/2中的多路复用，乃至于HTTP/1中的持久链接机制，都说得清楚这算是传输层还是应用层的特性。
在另一方面，HTTP 的设计者们并不是没有尝试过在协议层面去解决连接成本过高的问题，即使是 HTTP 协议的最初版本（指 HTTP/1.0，忽略非正式的 HTTP/0.9 版本）就已经支持了（连接复用技术在 HTTP/1.0 中并不是默认开启的，是在 HTTP/1.1 中变为默认开启）连接复用技术
在另一方面，HTTP 的设计者们并不是没有尝试过在协议层面去解决连接成本过高的问题，即使是 HTTP 协议的最初版本（指 HTTP/1.0，忽略非正式的 HTTP/0.9 版本）就已经支持了连接复用技术（连接复用技术在 HTTP/1.0 中并不是默认开启的，是在 HTTP/1.1 中变为默认开启）
调整下顺序感觉更好
周老师，QUIC网络切换那里：只需向服务端发送一个包含此标识符的数据包即可重用既有的连接，因为即使用户的 IP 地址发生变化，原始连接连接标识符依然是有效的。-------一个连接不是一个五元组么，ip变了连接不就没了么
HTTP 是应用层协议而不是传输层协议，它的设计原本并不应该过多地考虑底层的传输细节，从职责上讲，持久连接、多路复用、分块编码这些能力，已经或多或少超过了应用层的范畴。要从根本上改进 HTTP，必须直接替换掉 HTTP over TCP 的根基，即 TCP 传输协议，这便最新一代 HTTP/3 协议的设计重点。
QUIC 在设计上也考虑了流量控制、可靠传输等内容，感觉 HTTP3 基于 UDP 也依旧会和 TCP 一样考虑不少底层的传输细节？有点小疑惑
这对提高易出错链路的性能非常有用，因为在大多数情况下，TCP 协议接到数据包丢失或损坏通知之前，可能已经收到了大量的正确数据，但是在纠正错误之前，其他的正常请求都会等待甚至被重发。
这里的描述是不是有点问题？为什么是大量正确的数据，tcp 的快速重传 最多几次错误ack便会被识别。此时启动拥塞控制，开始限流，防止错误持续。主要是限流而非大量错误吧。
一个最显著的问题是互联网基础设施中的许多中间设备，都只面向 TCP 协议去建造，仅对 UDP 提供很基础的支持，有的甚至完全阻止 UDP 的流量。
上述原文中，仅对 UDP 提供很基础的支持 是否应该是仅对TCP提供很基础的支持。
