毕业半个多月了，许多当初一起保研的同学现在都有了导师布置的任务，有的同学已经在上暑课了，有的老师在组织他们自学课程然后线上互讲，而我的导师迟迟没有消息，按耐不住的我去问了下老师最近有没有什么建议可以让我提前接触下研究生的知识，老师说他打算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. 频繁切换网络的情况下，不会断线，不需要重连，用户无任何感知。
ipfs
IPFS (InterPlanetary File System) 中文名是 「星际文件系统」,本质上是一种内容可寻址、版本化、点对点超媒体的分布式存储、传输协议，目标是补充甚至取代过去20年里使用的超文本媒体传输协议（HTTP），希望构建更快、更安全、更自由的互联网时代。
- 其特点如下：
1. 内容可寻址
通过文件内容生成唯一的哈希标识，一定程度上节约了空间开销的成本
内容寻址会通过唯一的标识去访问，并且提前检验这个标识是否已经被存储过。如果被存储过，直接从其它节点读取它，不需要重复存储，一定意义上节约了空间。
HTTP 协议的寻址则是只关心 IP 下的某个主机中的某个目录，并不关心文件是否相同。
2. 文件切片
放到 IPFS 节点中的文件，会根据其内容生成出唯一的加密哈希值，我们不需要关心文件的存储路径或者名字，可以将一个大文件进行切片存储，使用的时候并行下载多个切片文件(并行速度大于串行速度)，最后本地拼装成一个完整的文件进行使用，比如我们想看一部电影。
3. 去中心化，区块链技术，分布式网络结构
区块链的本质是分布式账本，本身的瓶颈之一就是账本的存储能力，目前大部分公链的最大问题是没法存储大量的超媒体数据在自己的链上
4. 哈希加密存储，安全保证
基于SFS（自认证系统）命名体系
5.CDN加速
6.版本化：可追溯文件修改历史，类似于git
参考链接：
1.QUIC官方文档：https://www.chromium.org/quic
2.ipfs官方教程: https://ipfs.io/docs/getting-started/
3.一代通信协议Quic：https://knownsec-fed.com/2018-01-19-xia-yi-dai-tong-xin-xie-yi-quic
- QUIC协议是如何做到0RTT加密传输的
https://blog.csdn.net/dog250/article/details/80935534 - Web服务器快速启用QUIC协议: https://my.oschina.net/u/347901/blog/1647385
- QUIC协议原理分析：https://zhuanlan.zhihu.com/p/32553477
7.ipfs介绍：https://mp.weixin.qq.com/s/gAIHCWhSKvgGYKvJe_wRWg
8.QUIC的前世今生：https://mp.weixin.qq.com/s/liqaFbvshTnbHaFKEHeuNA
网友评论