- 2019-10-17我的看法：这些年但凡觉得TCP不满足自己需求的人，基本都是在UDP上重新“发明”一套自己的流控和包顺序控制算法。说白了吧，就是重新造轮子再做一个（自己认为）更好的TCP。只是这类型的协议，目前没有一个能真的威胁到TCP的，固然有老师说的TCP协议僵化存在的原因，但是我也在想：TCP就真的这么不堪吗 3
2019-10-15能翻墙的同学推荐可以看看Revisiting HTTP2 https://youtu.be/wR1gF5Lhcq0 3
2019-10-15想知道那些网络游戏是如何保证高效传输，丢包那些处理的，感觉上不会用tcp, 网络游戏的实时性要求挺高的，猜测是不是也是udp，然后封装一层，来保证数据高效传输的 1 1
2020-02-04老师你好 ，你在上一节说http2通过多路复用解决队头阻塞，我不是很明白，既然http2还是基tcp协议，并且只有一条tcp链接，那么一旦出现丢包的情况，不是效果比http1.1还差吗（至少http1.1支持六条tcp链接），如果http2只是为了解决慢启动的问题而将http1.1的六条链接合成一条，会不会有种丢西瓜捡芝麻的感觉
2020-01-01Network面板看到的请求条数是tcp连接个数吗
2019-12-31有个问题，UDP本身是不保证可靠传输，因此有时候丢包率很高，您说HTTP/3在此基础上封装了一层QUIC保证了数据的可靠性，那这个也需要类似于TCP的可靠性校验吧，那这个数据包丢失，就不需要等待校验吗？这不阻塞吗？如果说是多链路，那这个是多少条链路呢？是有多少请求就有多少吗？
2019-12-17“实现了快速握手功能。由于 QUIC 是基于 UDP 的，所以 QUIC 可以实现使用 0-RTT 或者 1-RTT 来建立连接.......”，由于是基于UDP的，所以实现0～1个RTT，那我感觉就面临一个问题，相比于TCP的三次握手，它的准确性就有问题了，搞不好还有极小的概率“串台“。- 2019-12-17"实现了 HTTP/2 中的多路复用功能。和 TCP 不同，QUIC 实现了在同一物理连接上可以有多个独立的逻辑数据流（如下图）。实现了数据流的单独传输，就解决了 TCP 中队头阻塞的问题。",个人感觉不管怎么传输，还待保证数据包不会丢失，丢了还是要重新传输，重新传就会有队头阻塞问题，所以，文中说“数据流的单独传输，就解决了 TCP 中队头阻塞的问题”，感到疑惑，单独传就不阻塞了吗，丢了一堆包也不管了。 1
2019-10-24意思是H1.1到H2解决的队头阻塞，只是形式上的。因为这个问题本质上依旧没有解决，因为TCP特性就是这样的，是不是只要不摆脱TCP就意味着一直会有阻塞的问题？这个版本升级感觉更多的应该是减少长连接的个数，减少了带宽抢占，增加了资源优先级。而从H2到H3，骨子里就不想依赖TCP，使用UDP，并附上了TCP一些优秀特性，减少握手和增加可靠性。这是我对这几个版本迭代过程的理解。 1
2019-10-15老师您好，我想请问就是因为UDP本身是不保证可靠传输，因此有时候丢包率很高，您说HTTP/3在此基础上封装了一层，那封装后的丢包率和TCP封装的相比较相差多少？有数据对比吗
2019-10-15这章的概念都比较新 学习了