如何在Linux里安装chrome？

在Linux里安装chrome的 *** 作步骤如下：

一、添加PPA

从Google Linux Repository（http://www.google.com/linuxrepositories/）下载安装Key，或把下面的代码复制进终端，回车，需要管理员密码

wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -

Key安装好后，在终端输入：

sudo sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >>/etc/apt/sources.list.d/google-chrome.list'

二、更新

在终端输入：sudo apt-get update

三、安装

安装稳定版Chrome，在终端输入：sudo apt-get install google-chrome-stabl

安装Beta版Chrome，在终端输入：sudo apt-get install google-chrome-bet

安装不稳定版Chrome，在终端输入：sudo apt-get install google-chrome-unstable

HTTP 3 ，它来了，QUIC（quick udp internet connection “快速 UDP 互联网连接”）正如其名一样，它就是快。其正在标准化为新一代的互联网传输协议。是由google提出的使用udp进行多路并发的传输协议。

QUIC解决了什么问题呢？从上世纪90年代至今，互联网一直按照一成不变的模式发展着。使用ipv4进行路由，使用tcp进行连接层面的拥塞控制，并保证其传输的可靠性，使用tls层进行安全加密和身份验证，使用http进行应用的数据传输。

这么多年的发展，这些协议只是小部分或者细节上有了改变，tcp提出了几个新的拥塞控制算法，tls改变了加密方式，http层进化出了h2。但是互联网发展至今，网络传输的内容越来越大，用户对传输的时延，带宽提出越来越大的要求。

tcp虽然也在拥塞控制上提出了一些优秀的拥塞控制算法，如BBR但是限制于其对 *** 作系统内核版本的要求，tcp 的 TFO，windows *** 作系统又支持不好等。导致想要切换成更高效的协议成本巨大。

这里列出几个主要的矛盾。

1、协议历史悠久导致中间设备僵化。

2、依赖于 *** 作系统的实现导致协议本身僵化。

3、建立连接的握手延迟大。

4、队头阻塞。

QUIC孕育而生，其抛开了TCP直接采用UDP，如一些拥塞算法，可靠性保证机制，不再依赖 *** 作系统内核，而是可以自定义。

Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势：

1、减少了 TCP 三次握手及 TLS 握手时间。

2、改进的拥塞控制。

3、避免队头阻塞的多路复用。

4、连接迁移。

5、前向冗余纠错。

有些防火墙只允许通过 80 和 443，不放通其他端口。NAT 网关在转换网络地址时重写传输层的头部，有可能导致双方无法使用新的传输格式。因为通信协议栈都是固化到 *** 作系统中的，只能通过内核参数进行调整，但是这样的调整极其有限，如果想要新加协议，只能重新编译内核。而现实是，可能还有一些Centos5 还作为某些古董公司的线上服务器。另外，windows xp 可能还是某些事业单位的办公电脑上装的 *** 作系统，尽管xp的时代已经过去20年了。另外TCP Fast Open 也在2013年就提出了，但是windows *** 作系统也有些不支持。

知道一个首次https网站的访问都要有哪些步骤吗？dns解析需要1个RTT，TCP三次握手，HTTP 302 跳转 HTTPS又需要RTT，TCP重新握手。TLS握手再消耗2个。解析CA的DNS（因为浏览器获取到证书后，有可能需要发起 OCSP 或者 CRL 请求，查询证书状态）再对CA进行TCP握手，OCSP响应。密钥协商又是RTT。当然这种情况是最极端的，大部分情况下不是所有流程都需要走一遍的。（参考 大型网站的 HTTPS 实践（二）-- HTTPS 对性能的影响 ）

基于以上的原因，QUIC选择了UDP。没有了三次握手，在应用层面完成了传输的可靠性，拥塞控制还有TLS的安全性。只要应用软件的客户端和服务端支持就行，绕开了 *** 作系统内核版本这个硬骨头。

在HTTPS over TCP+TLS的时代。HTTPS需要3个RTT，在session 复用的情况下是2个RTT。而QUIC做到了1RTT和会话复用的0RTT。

QUIC的TLS只能使用TLS1.3，这就可以做到PSK的0RTT。

TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复。其中TCP中拥塞控制是被编译进内核中的，如果想要更改就需要改变内核参数，但是想要对已有的拥塞控制算法进行更改就需要重新编译内核，Linux 4.9 中引入了基于时延的拥塞控制算法 BBR，这打破了以往是靠丢包驱动的拥塞控制算法，但是想要在TCP中使用，就必须升级内核至4.9以上。

QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法 [6]，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。

QUIC和TCP的对比

其中α 从 0到 1（RFC 推荐 0.9），越大越平滑

如 UBOUND为1分钟，LBOUND为 1 秒钟， β从 1.3 到 2 之间

对于QUIC

参考： 科普：QUIC协议原理分析 罗成

---