QUIC

作者 | L的存在 来源 | 我是程序员小贱 本文将从以下几个方面进行分享。其中包括 HTTP发展史，HTTP缓存代理机制，常用的web攻击，HTTP和HTTPS的流量识别 ，网络协议学习的 工具 推荐以及 高频HTTP与HTTPS的高频面试题 题解等，开工。 提纲 1989年，蒂姆·伯纳斯 - 李（Tim Berners-Lee）在论文中提出可以在互联网上构建超链接文档，并提出了三点： URI ：统一资源标识符。互联网的唯一ID HTML ：超文本文档 HTTP ：传输超文本的文本传输协议 HTTP应用在哪儿 学习一门知识，采用五分钟时间看看这个知识是干啥的可能会更加有目的性。HTTP可谓无处不在，这里例举出几个。 HTTP应用场景 HTTP是什么 HTTP(hypertexttransport protocol)翻译过来为" 超文本传输协议 "，文本可以理解为简单的字符文字组合，也可以理解为更为复杂的音频或者图像等。那么将这个词语拆分为三个部分。 超文本传输协议 "超文本" 和 "文本" 相比多了一个字"超"，这样看来比文本丰富，因为它可以将多种文本/图像等进行 混合 ，更重要的是可以从一个文本 跳转 到另一个文本(文本连接)。 "传输" ，传输的过程中需要沟通，沟通即可能一对一沟通也可能一对多沟通(进行内容协商)，无论怎么样，参加沟通的人数>1

我想用eBPF或者至少cBPF实现一个功能： 根据来源和目标IP地址来选择同一个reuseport组的socket。 比方说，我的服务器上有4个IP地址分别是10.0.0.1，10.0.0.2，10.0.0.3，10.0.0.4，我的服务侦听0.0.0.0:1234，分别有4个reuseport socket提供，我希望的select算法是： 访问10.0.0.1的分派给sk1。 访问10.0.0.2的分派给sk2。 访问10.0.0.3的分派给sk3。 访问10.0.0.4的分派给sk4。 不要问我这个需求哪来的，它是真实存在的，我的reuseport组三线连接三大运营商，每一个组内socket均有不同的策略，我受够了Netfilter，所以我必须用IP地址来进行socket查找。 然而这么简单的算法却无法实现！ 对于cBPF而言，bpf程序携带的skb参数是pull过的，一直pull到TCP/UDP的payload位置，因此bpf程序连TCP/UDP头都无法访问，就更别提IP头了。 对于eBPF而言，结构体sk_reuseport_md是eBPF程序的参数： struct sk_reuseport_md { /* * Start of directly accessible data. It begins from * the tcp/udp header. */ //

先引用自己的两篇文章： 流水线式的TCP中继代理是如何提高吞吐的 ： https://blog.csdn.net/dog250/article/details/83997773 eBPF/sockmap实现socket转发offload ： https://blog.csdn.net/dog250/article/details/103629054 TCP是一个对长距离大带宽(长肥管道)传输很不友好的端到端协议，它既保证不了效率(对丢包很敏感)，又保证不了公平性(对时延很不敏感)，它只是一个 收敛于刚刚可用 的协议，TCP，是垃圾！ 依靠数据中继，TCP可以将传输行为流水线化，慢启动窗口在短RTT内快速打开，对丢包的敏感通过对对时延的敏感来补偿，从而最大化吞吐，这是TCP性能优化的一个创举，而eBPF可以作为TCP数据中继实现的一个具体的技术。 两篇文章所谈的技术相结合，周末我来扯一下这背后的动机和意义。 当我们关注数据包是如何从起点到达终点的时候，我们被告知这一切都基于 IP路由！ TCP/IP分层模型让路由器在数据包逐跳选路的过程中扮演了核心角色。整个互联网看起来是由一堆路由器织成的： 上图中所示的最短路径是通过一种叫做动态路由的协议计算出来的，每一台路由器都会运行这类路由协议并且参与全网任意两点间最短路径的计算，这是一个 全网协作的分布式过程 。

1、引言 网络优化对于移动端App产品的用户体验至关重要，也与公司的运营和营收息息相关。 这里列举两个公开的数据： “ 《页面加载超过3秒，57%的用户会离开》 ” “ 《Amazon页面加载延长1秒，一年就会减少16亿美金营收》 ” 网络性能对于用户体验的影响，将非常直接地反馈到业务的运营上。 而且，移动网络固有的弱网问题、DNS问题、连接性能等等都无法跟传统的固定网络相比。所以，优化移动端网络，显的尤其必要。 对于即时通讯应用（IM、消息推送）的开发者来说，无论是短连接还是长连接优化，都会直接体现在APP的体验上，必竟IM或类IM应用都是用户使用频度很高的场景，网络有关的体验问题稍有懈怠，就会被用户无限放大，所以回避也不是解决问题的正确之道。 有鉴于此，即时通讯网整理收集了相当多有关移动弱网的文章（包括本篇），希望能为你移动端网络优化带来一些启发。 本文同步发布于“即时通讯技术圈”公众号，欢迎关注： 本文的来源是： http://www.52im.net/thread-3015-1-1.html 2、本文作者 周辉： 美团点评移动技术专家，移动架构负责人。移动端开发10年以上经验。 * 领导和参加过公司大部分移动客户端产品的架构设计和业务开发； * 2010 年加入原大众点评，现专注于美团点评客户端底层架构的开发和维护； * 2016

美国专利商标局裁定：人工智能不能被列为发明人 目前，只有“自然人”才有权利获得专利。去年，两项相对平凡的专利—一种可变形的食品容器和一种应急手电筒—给全世界的国际专利法规提出了一个存在的问题：发明人必须是人吗？ 来源：cnBeta.COM 比特币大涨 17%，超过 9000 美元 自 3 月瀑布式暴跌后，比特币价格已翻一番多。4 月 30 日，比特币价格重回 9000 美元。 来源：澎湃新闻 GitLab 向报告远程代码执行漏洞的研究员奖励 2 万美元 该漏洞由 William vakzz Bowling 发现，Bowling 既是一名程序员同时也是 Bug 赏金猎人，他于3月23日通过 HackerOne Bug 赏金平台私密披露了该漏洞。 来源： 开源中国 全球最大勒索病毒 Troldesh 终结：公开 75 万个密钥 制造 Troldesh 病毒的黑客团队在 Github 上发表了声明，宣布要金盆洗手，病毒已经在 2019 年停止传播了，他们决定再做最后一件事——公布团队拥有的所有解密密钥，总计超过 75 万个。 来源：快科技 LibreOffice 7.0 将最终取消对 Adobe Flash Player 的支持 LibreOffice 支持导出内容到 Adobe Flash。而根据 LibreOffice 7.0 的官方发布说明，从这次更新开始，你将无法再将内容导出为

我们都知道 HTTP 是基于 TCP 的，而 TCP 是面向连接的。当我们向服务器请求一个页面时，首先需要建立 TCP 连接，才能开始真正开始传输内容。 这个时间平时不容易被人察觉，因为开发场景下我们往往不需要重新建立连接。但是在有些场景（尤其是新用户场景、landing page 等）却会对页面的性能造成很大的影响。 图中 TCP 的部分为我们常说的建连时间（这里包含了 SSL 握手时间，下文的建连时间也指的是这段时间），前面的 DNS 时间往往和建连时间同时出现，后面会讲到这一点。 建连应该耗时多久 RTT 在介绍建连的耗时之前，我们先介绍一下 RTT(Round-Trip Time) 的概念。RTT，即往返时延。指的是从发送端发送数据开始，到发送端收到来自接收端的确认（ACK）的时间。一般来说这个时间是由物理距离，网络传输路径等决定的。 RTT 一般是多久 最简单的方式就是 Ping 一下，我们在 Ping 的时候看到的 time=xxms 一般 接近于一个 RTT ** PING 115.239.211.112 (115.239.211.112): 56 data bytes 64 bytes from 115.239.211.112: icmp_seq=0 ttl=55 time=4.411 ms 复制代码 Copy 实际上就是一来一回（下面是 tcpdump 抓到的

本文原始内容由爱奇艺技术产品团队原创分享，本次有修订和改动。 1、引言 由于移动网络的复杂性特点，编写高质量、体验好的具备网络通信能力的移动端应用（尤其是即时通讯这类网络质量高度敏感的应用）有很大的挑战性。 我们平时看到的移动网络主要有如下三个典型特点： 1）移动状态网络信号不稳定，高时延、易抖动丢包、通道狭窄； 2）移动状态网络接入类型和接入点变化频繁； 3）移动状态用户使用高频化、碎片化、非WIFI流量敏感。 （ ▲ 上述文字，引用自《 移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢” 》 ） 正是由于上述特点，移动端应用在进行网络数据通信时会面临各种复杂多变的问题。 无论后面的技术有多复杂，但对于普通用户使用APP来说，能顺畅的完成网络请求，是理所当然的事。换句话说，APP网络请求成功率，重要性直接体现在它能直接决定APP服务的可用性，直接影响到数据通信、视频播放、广告展现、支付便捷等服务质量。 本文将以爱奇艺的iOS端APP为例，分享对移动网络请求成功率优化方面的技术实践之路。 本文已同步发布于我的“即时通讯技术圈”公众号。 2、导致移动端网络请求失败的因素 想要优化移动端网络请求成功率，先来了解移动端网络请求全链条可能导致请求失败的环节有哪些。 这些环节往往由以下两类因素导致： 第一类：不可改善因素： 1）iOS系统对APP的网络访问权限控制

3 月，跳不动了？>>> Photo by Vlad Alexandru Popa from Pexels SRT协议是基于UDT的传输协议，保留了UDT的核心思想和机制，抗丢包能力强，适用于复杂的网络。在LiveVideoStack线上分享中，新浪音视频架构师 施维对SRT协议的原理、优缺点特性以及在流媒体中的应用进行了详细解析。 文 / 施维 整理 / LiveVideoStack 视频回放 https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=a1564111ef934005b4b1acf2105128e3 1. 为什么选择SRT？ 毋庸置疑，现今存量最大的直播协议是RTMP，但随着新技术的不断发展与使用场景的不断拓展，继续使用RTMP会令人感到有些力不从心。RTMP协议的缺陷主要有以下四个方面： RTMP协议缺陷 首先，RTMP协议太老，且最后一次更新是在2012年；同时HEVC/H.265/AV1等视频格式都没有官方定义，以至于需要国内CDN厂商自行定义。 RTMP连接过程较长，由于RTMP基于TCP（TCP存在三次握手），除此之外，其本身又存在c0/s0到c2/s2的三次握手，再加上connection，createstream，play/publish

3 月，跳不动了？>>> QUIC ，即 快速UDP网络连接 ( Quick UDP Internet Connections )， 是由 Google 提出的实验性网络传输协议 ，位于 OSI 模型传输层。 QUIC 旨在解决 TCP 协议的缺陷，并最终替代 TCP 协议， 以减少数据传输，降低连接建立延迟时间，加快网页传输速度。 QUIC 主要特点有： 多流设计； 低等待延迟； 加密性能更优； 前向纠错； 应用程序实现； 连接保持； 多流设计 采用 多路复用 思想，一个连接可以同时承载多个 流 ( stream )，同时发起多个请求。 请求间完全 独立 ，某个请求阻塞甚至报文出错均不影响其他请求。 对比 HTTP 长连接，由于 TCP 是只实现一个字节流，如果请求阻塞，新请求无法发起。 低等待延迟 先考察典型的 TLS 连接建立过程： 首先，执行三次握手，建立 TCP 连接(蓝色部分)； 然后，执行 TLS 握手，建立 TLS 连接(黄色部分)； 此后开始传输业务数据； 客户端和服务器之间要进行好几轮协议交互，才能建立 TLS 连接，延迟相当严重。 平时访问 https 网站明显比 http 网站慢，三次握手和 TLS 握手难辞其咎。 > 注解: > > 注意到，三次握手中的 ACK 包与 ClientHello 合并在一起发送。 这是 TCP 实现中使用的 延迟确认 技术

为什么这么设计(Why's THE Design)是一系列关于计算机领域中程序设计决策的一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。 TCP 协议可以说是今天互联网的基石，作为可靠的传输协议，在今天几乎所有的数据都会通过 TCP 协议传输，然而 TCP 在设计之初没有考虑到现今复杂的网络环境，当你在地铁上或者火车上被断断续续的网络折磨时，你可能都不知道这一切可能都是 TCP 协议造成的。本文会分析 TCP 协议为什么在弱网环境下有严重的性能问题。 底层的数据传输协议在设计时必须要对带宽的利用率和通信延迟进行权衡和取舍，所以想要解决实际生产中的全部问题是不可能的，TCP 选择了充分利用带宽，为流量而设计，期望在尽可能短的时间内传输更多的数据。 在网络通信中，从发送方发出数据开始到收到来自接收方的确认的时间被叫做往返时延(Round-Trip Time，RTT)。 弱网环境是丢包率较高的特殊场景，TCP 在类似场景中的表现很差，当 RTT 为 30ms 时，一旦丢包率达到了 2%，TCP 的吞吐量就会下降 89.9%[^3]，从下面的表中我们可以看出丢包对 TCP 的吞吐量极其显著的影响： 本文将分析在弱网环境下(丢包率高)影响 TCP 性能的三个原因： TCP 的拥塞控制算法会在丢包时主动降低吞吐量; TCP 的三次握手增加了数据传输的延迟和额外开销;