QUIC

原文地址 https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit QUIC是一个谷歌提出的新的互联网协议。 QUIC解决出现在现在网络协议的一些传输层和应用层的问题，而且几乎不需要应用更改。QUIC和 TCP+TLS+HTTP2十分相似，但是基于UDP实现。使用QUIC作为一个独立的协议可以做到一些别的协议做不到的创新，因为它们受到传统客户端和中间件的阻碍。 和 TCP+TLS+HTTP2相比，QUIC的核心优势有以下几点： 连接建立延迟 提升拥塞控制 无需排头阻塞的多路复用 向前纠错 连接迁移 连接建立 简单来说，在发送有效负载前，和 TCP+TLS的1~3rt相比， QUIC通常需要0rt。 当QUIC客户端第一次链接到服务端时，客户端必须执行1rt的握手来获取完成握手的所有必要信息。客户端发送一个 CHLO，服务端返回一个带有客户端用来继续执行的拒信，包括源地址令牌和服务器证书。下次客户端发送CHLO时，可以使用上次连接缓存的证书来立刻返回一个加密的消息。 拥塞控制 QUIC有可插拔的拥塞控制，而且比TCP给拥塞控制提供更丰富的信息。这允许一个QUIC发送者识别重发的ACK和原始的ACK避免TCP的重发歧义问题。QUIC ACK还明确传输数据包发送和接收的延时

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Photo by Thomas William on Unsplash 从2016年至今，流量的增长基本进入到了平稳期，此时，面向产业界和开发者，我们如何提供更多、更新的能力给到他们，提升平台的用户体验？本文来自腾讯云视频业务产品总监黄斌在LiveVideoStackCon 2019深圳站上的精彩分享，希望和业界一起探讨视频云下半场的方向与定位，也希望与产业界同仁一道，共建更好的大视频生态。 文 / 黄斌 整理 / LiveVideoStack 1.直播行业中的难点 腾讯云内部最早在2015年下半年开始进入视频云领域，将腾讯多年在音视频编解码、音视频通信以及海量并发业务的经验逐渐开放，当时我们也是新进者，定位是在OVP（在线视频平台），类似国外的brightcove及国内的CC视频，我们在教育、在线视频等领域进行了尝试。不过真正确定业务重点方向是在2016年，2016年也是国内的直播元年，行业的爆发让团队意识到直播的流量是非常大的，在高并发情况下如何能做到视频流畅无卡顿、并能提供丰富的IM通信、保证互动连麦等环节的正常进行，这正是我们的技术优势所在，我们抓住了直播的这个风口。 我自己将市面上的产品按照碎片消费、按需点播、实时互动和定时播放四个维度分为四个部分，右上象限这类实时性高，低制作成本的这些应用

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Android平台HTTPS抓包解决方案及问题分析 HTTP协议发展至今已经有二十多年的历史，整个发展的趋势主要是两个方向：效率和安全。效率方面，从HTTP1.0的一次请求一个连接，到HTTP1.1的连接复用，到SPDY/HTTP2的多路复用，到QUIC/HTTP3的基于UDP传输，在效率方面越来越高效。安全方面，从HTTP的明文，到HTTP2强制使用TLSv1.2，到QUIC/HTTP3强制使用TLSv1.3，越来越注重数据传输的安全性。总而言之，HTTP协议的发展对用户是友好的，但是对开发者而言却不那么友善。 抓包是每个程序员的必修技能之一，尤其是在接口调试和程序逆向方面具有广阔的用途。但是，随着越来越多的通信协议使用加密的HTTPS，而且系统层面也开始强制规定使用HTTPS，抓包似乎是显得越来越难了。 本篇博客，主要详解Android平台下，HTTPS抓包的常见问题以及解决办法。工欲善其事必先利其器，博客中以HttpCanary作为抓包工具进行讲解。更多HttpCanary的资料，请见：github.com/MegatronKin… 抓包原理 几乎所有网络数据的抓包都是采用中间人的方式（MITM），包括大家常用的Fiddler、Charles等知名抓包工具

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文由云+社区发表 作者：腾讯云游戏行业资深架构师 余国良 MOBA类和“吃鸡”游戏为什么对网络延迟要求高？ 我们知道，不同类型的游戏因为玩法、竞技程度不一样，采用的同步算法不一样，对网络延迟的要求也不一样。例如，MOBA类游戏多使用帧同步为主要同步算法，竞技性也较高，无论从流畅性，还是从公平性要求来说，对响应延迟的要求都最高，根据业内经验，当客户端与服务器的网络延迟超过150ms时，会开始出现卡顿，当延迟超过250ms时，会对玩家操作造成较大影响，游戏无法公平进行。类似地，“吃鸡”游戏（如《绝地求生》）玩法对玩家坐标、动作的同步要求极高，延迟稍大导致的数据不一致对体验都会造成较大影响，其实时性要求接近MOBA类游戏。而对于传统mmorpg来说，多采用状态同步算法，以属性养成和装备获取为关注点，也有一定竞技性，出于对游戏流畅性的要求，对延迟也有一定要求，同步算法的优化程度不一样，这一要求也不一样，一般情况下为保证游戏正常进行，需要响应延迟保持在300ms以下。相比之下，对于炉石传说、斗地主、梦幻西游等回合制游戏来说，同时只有一个玩家在操作双方数据，无数据竞争，且时间粒度较粗，甚至可通过特效掩盖延迟，因此对网络延迟的要求不高，即便延迟达到500ms~1000ms，游戏也能正常进行。这里

QUIC(Quick UDP Internet Connection)是谷歌制定的一种基于UDP的低时延的互联网传输层协议。 1、避免前序包阻塞 HTTP2的最大特性就是多路复用，而HTTP2最大的问题就是队头阻塞。 首先了解下为什么会出现队头阻塞。比如HTTP2在一个TCP连接上同时发送3个Stream，其中第2个Stream丢了一个Packet，TCP为了保证数据可靠性，需要发送端重传丢失的数据包，虽然这时候第3个数据包已经到达接收端，但被阻塞了，这就是所谓的队头阻塞。 而QUIC多路复用可以避免这个问题，因为QUIC的丢包、流控都是基于Stream的，所有Stream是相互独立的，一条Stream上的丢包，不会影响其他Stream的数据传输。 2、零RTT建连： 如果是客户端首次连接到服务器，由于QUIC将传输与加密结合在一起的特性所在，一般来说正常情况下初次握手只需要1个RTT就可以完成握手；但是对于触发版本协商、证书无法解密等问题当然也会导致多个RTT的产生。 而重复连接的情况下握手，如果在证书有效的情况下，客户端发送Hello包并不用等待回复就可以直接发数据加密包，也就是实现了传说中的0RTT。 3、FEC前向纠错 QUIC协议的每个数据包除了本身的数据以外，会带有其他数据包的部分数据，在少量丢包的情况下，可以使用其他数据包的冗余数据完成数据组装而无需重传

Facebook的测试结果显示，COPA较于常用算法CUBIC及BBR v1存在一定优势，来看看具体表现。 文 / Nitin Garg 译 / Adrian Ng 原文 https://engineering.fb.com/video-engineering/copa/ 在对互联网应用进行性能优化时，可能会涉及一些复杂的权衡。在传输大量数据的时候，如果传输速度过快，可能会因为丢包而产生重传，从而随着时间流逝导致性能损失。同时，如果发送数据的速度太慢则可能会导致延迟和卡顿，对性能也有很大的损害。此外，不同的视频体验需要针对质量与延迟进行不同的权衡。对于交互式体验，其应用程序可通过降低视频质量，避免卡顿。但当视频的高质量是最重要的因素时，应用程序可以在合理的范围内的保持一定延迟。此时，应用通常会在几种不同的拥塞控制算法中进行选择，找到最适合当前目标的优化算法进行优化。 尽管在拥塞控制领域上我们已进行了广泛的研究，但若要将研究付诸实践一直以来都会涉及到修改Linux内核。使用QUIC可以在无需修改内核的情况下，在用户空间中实现整个传输堆栈，简化整个部署和实验的流程。而COPA 与 QUIC 的耦合可以为我们提供一种算法，该算法可适用于各种视频体验，并且可以合理地遵循一种部署策略。在实际测试中，测试结果显示COPA较于常用算法CUBIC及BBR v1存在一定优势

QUIC(Quick UDP Internet Connections，快速UDP互联网连接)是Google提出的一种基于UDP改进的通信协议，其目的是降低网络通信的延迟，提供更好的用户互动体验。 QUIC的主要特点包括：具有SPDY(SPDY是谷歌研制的提升HTTP速度的协议，是HTTP/2.0的基础)所有的优点；0-RTT连接；减少丢包；前向纠错，减少重传时延；自适应拥塞控制， 减少重新连接；相当于TLS加密。 1.重传与恢复 与TCP类似，QUIC每发送一个包后，都会等待回复一个确认包。当丢包率超过协议的纠错门限时，会显式或隐式地进行重传 对于某些重要的数据包，如初始密钥协商时的数据包，在建立连接时非常重要，如果这类包丢失会阻塞整体数据流。QUIC对于这一类数据包在确认发生丢失前就会尝试重传，通常是等待较短的时间(如20ms)没收到确认后就马上再次发送。这样在网络中会有若干个相同的包同时传输，只要有一个能成功抵达就完成了连接，这样降低了丢包率。接收方对于关键数据包的多次发送和普通数据包的超时重传，都采用相同的重复包处理机制 QUIC在拥塞避免 算法 的基础上还加入了心跳包，用于减少丢包率 QUIC使用了FEC(前向纠错码)来恢复数据，FEC采用简单异或的方式。每次发送一组数据，包括若干个数据包后，并对这些数据包依次作异或运算，最后的结果作为一个FEC包再发送出去

HTTP 协议 HTTP 协议是TCP/IP 网络协议中的应用层协议。 URL - 统一资源定位符 DNS 的作用 将域名 转为 IP 地址 在发送HTTP 协议之前要建立TCP 连接，HTTP 是建立在TCP 连接之上的 HTTP 1.1 版本默认开启Keep-alive，建立一次TCP 连接，可以重复使用 HTTP 请求的构建 建立TCP 连接后需要构建HTTP 报文，其报文大概分为三个部分 第一部分：请求行 第二部分：首部 第三部分：正文实体 第一部分：请求行 方法有几种类型： Get，获取资源，通常是一个网页，也可能是一个JSON 字符串。 Post，主动告诉服务器一些信息，这些信息放到实体中，正文的格式通常是JSON。 Put，向指定的资源位置上传新内容， 但HTTP 的服务器通常不允许上传文件，所以在实际应用中，Post通常用来创建一个资源，Put 用来修改一个资源。 Delete，用来删除资源的。 第二部分：首部字段 首部是key value，通过冒号分隔。通常保存重要字段。 例如，Accept-Charest，表示客户端可以接受的字符集。 例如，Content-Type 指出正文的格式，如果我们进行Post的请求，如果正文是JSON，，那么这个值就是JSON。 缓存的使用，缓存网页中静态的部分，例如图片等。这样可以在更新数据时不必每次都刷新整个页面。

HTTP 协议 HTTP 协议是TCP/IP 网络协议中的应用层协议。 URL - 统一资源定位符 DNS 的作用 将域名 转为 IP 地址 在发送HTTP 协议之前要建立TCP 连接，HTTP 是建立在TCP 连接之上的 HTTP 1.1 版本默认开启Keep-alive，建立一次TCP 连接，可以重复使用 HTTP 请求的构建 建立TCP 连接后需要构建HTTP 报文，其报文大概分为三个部分 第一部分：请求行 第二部分：首部 第三部分：正文实体 第一部分：请求行 方法有几种类型： Get，获取资源，通常是一个网页，也可能是一个JSON 字符串。 Post，主动告诉服务器一些信息，这些信息放到实体中，正文的格式通常是JSON。 Put，向指定的资源位置上传新内容， 但HTTP 的服务器通常不允许上传文件，所以在实际应用中，Post通常用来创建一个资源，Put 用来修改一个资源。 Delete，用来删除资源的。 第二部分：首部字段 首部是key value，通过冒号分隔。通常保存重要字段。 例如，Accept-Charest，表示客户端可以接受的字符集。 例如，Content-Type 指出正文的格式，如果我们进行Post的请求，如果正文是JSON，，那么这个值就是JSON。 缓存的使用，缓存网页中静态的部分，例如图片等。这样可以在更新数据时不必每次都刷新整个页面。