ipfs和quic知识点

2020-08-14 本文已影响0人 ALISA199812

毕业半个多月了，许多当初一起保研的同学现在都有了导师布置的任务，有的同学已经在上暑课了，有的老师在组织他们自学课程然后线上互讲，而我的导师迟迟没有消息，按耐不住的我去问了下老师最近有没有什么建议可以让我提前接触下研究生的知识，老师说他打算8月份给手下的学生开个会到时候在布置任务，如果自己有时间的话可以先看看quic和ipfs【星际文件系统】。
从未听说过这两个东东的我，开始着手查资料。百度、微信公众号一系列阅读后，整理如下：

先来说下http协议存在的劣势
相较于quic
(1) 数据传输前 TCP 先要进行"三次握手"，建立连接后才开始传输应用数据，这无疑增加了网络延时; 在采用 TLS 协议时需要交换密钥，这又增加了一次往返时延 (Round-Trip Time，RTT)。
(2) HOL (Head-of-line) blocking，前序包阻塞。TCP 保证有序传输，所以当一个数据包丢失时，其他所有的包都要等它重传整理后才会交给应用层，对于多路复用共享一个 TCP 连接的 SPDY 和 HTTP/2 来说，这无疑影响更大。
相较于npfc
传统的中心化架构依赖单个服务器、有限的集群以及 Internet 主干网
容易遭受 DDOS 攻击(亦或是自然灾害、战争导致的)，出现单点故障
比较浪费带宽
中心化相比之下的低效率
不可追述文件的修改历史

QUIC协议

QUIC（Quick UDP Internet Connections）协议是一种全新的基于UDP的web开发协议。可以用一个公式大致概括：
TCP + TLS + HTTP2 = UDP + QUIC + HTTP2's API

从公式可看出：QUIC协议虽然是基于UDP，但它不但具有TCP的可靠性、拥塞控制、流量控制等，且在TCP协议的基础上做了一些改进，比如避免了队首阻塞；另外，QUIC协议具有TLS的安全传输特性，实现了TLS的保密功能，同时又使用更少的RTT建立安全的会话。可见QUIC可以很好的解决前述基于TCP的HTTP协议所面临的困难。

协议原理

低建立连接延迟 (Connection Establishment Latency)
建立一个TCP连接需要进行三次握手，这意味着每次连接都会产生额外的RTT，从而给每个连接增加了显著的延迟（如图2所示）。

图2 QUIC和TCP及TCP+TLS的建立时间对比

QUIC协议第一次Client和Server建立连接还是会走正常的TLS握手流程，但过了一会儿或者一段时间后，Client又想和Server通信，此时Client已经有了刚刚和Server协商出来的密钥（可能是存在内存也可能swap到硬盘）。Client就会利用刚刚的密钥K1来和Server加密首次数据，在第二个RTT期间，Server会和Client协商出新的密钥K2，作为接下来的通信密钥。如果一对使用QUIC进行加密通信的双方此前从来没有通信过，0 RTT是不可能的。
改进的拥塞控制 (Improved Congestion Control)
QUIC协议当前默认使用TCP协议的Cubic拥塞控制算法。并在TCP拥塞算法基础上做了些改进：
(1) 可插拔
· 应用程序层面就能实现不同的拥塞控制算法，不需要操作系统或内核支持。
· 单个应用程序的不同连接也能支持配置不同的拥塞控制。
· 不需要停机和升级就能实现拥塞控制的变更。
(2) 单调递增的Packet Number
(3) 更多的ACK块
QUIC ACK帧支持256个ACK块，相比TCP的SACK在TCP选项中实现，有长度限制，最多只支持3个ACK块
(4) 精确计算RTT时间
QUIC ACK包同时携带了从收到包到回复ACK的延时，这样结合递增的包序号，能够精确的计算RTT。

图5 QUIC精确计算RTT
TCP的RTT计算：

RTT=timestamp2-timestamp1

Quic的RTT计算：

RTT=timestamp2-timestamp1-Ack Delay

无队头阻塞的多路复用 (Multiplexing without head-of-line blocking)
HTTP2的最大特性就是多路复用，而HTTP2最大的问题就是队头阻塞。首先了解下为什么会出现队头阻塞。比如HTTP2在一个TCP连接上同时发送3个stream，其中第2个stream丢了一个Packet，TCP为了保证数据可靠性，需要发送端重传丢失的数据包，虽然这时候第3个数据包已经到达接收端，但被阻塞了。这就是所谓的队头阻塞。而QUIC多路复用可以避免这个问题，因为QUIC的丢包、流控都是基于stream的，所有stream是相互独立的，一条stream上的丢包，不会影响其他stream的数据传输。

TCP导致队头阻塞
QUIC无队头阻塞
保证包的顺序
假设Packet N丢失了，发起重传，重传的Packet Number是N+2，但是它的Stream的Offset依然是x，这样就算Packet N + 2是后到的，依然可以将Stream x和 Stream x+y 按照顺序组织起来。

引入Stream Offset保证包的顺序
前向纠错 (Forward Error Correction)
QUIC使用了FEC（前向纠错码）来恢复数据，FEC采用简单异或的方式，每发送一组数据，包括若干个数据包后，并对这些数据包依次做异或运算，最后的结果作为一个FEC包再发送出去。接收方收到一组数据后，根据数据包和FEC包即可以进行校验和纠错。比如：10个包，编码后会增加2个包，接收端丢失第2和第3个包，仅靠剩下的10个包就可以解出丢失的包，不必重新发送，但这样也是有代价的，每个UDP数据包会包含比实际需要更多的有效载荷，增加了冗余和CPU编解码的消耗。
连接迁移 (Connection Migration)
TCP的连接是基于4元组的，而QUIC使用64为的Connection ID进行唯一识别客户端和服务器的逻辑连接，这就意味着如果一个客户端改变IP地址或端口号，TCP连接不再有效，而QUIC层的逻辑连接维持不变，仍然采用老的Connection ID。
QUIC应用场景
1. 长距离传输
2. 手机网络
3. 请求的页面资源数较多，并发的连接数多
4. 要求加密传输
5. 弱网环境的时候能够提升 20% 以上的访问速度。
6. 频繁切换网络的情况下，不会断线，不需要重连，用户无任何感知。