QUIC

还是这篇文章： http://sites.inka.de/sites/bigred/devel/tcp-tcp.html 有100个理由说TCP在某种场景下不好，就有100个理由说TCP在同样的场景了好的不得了，这就好像面对中医或者传统武术一样， 古老陈旧的东西总是被拿来被吹捧或者被打压。 TCP是个30年前陈旧的协议，在计算机网络的编年史中，TCP是一个古代的协议。 TCP在长距离传输时窗口打开太慢； TCP对丢包无法预测； TCP对RTT测不准； TCP对网络拥塞事件反应迟钝； … 这是一个保守的协议。 数据要传输到另一个地方，中间要经过一个隧道，如何构建这个隧道是一个技术问题。 考虑TCP over TCP会怎样？ TCP作为一个按序接收的有状态可靠的端到端传输协议，是因为它对下层的链路做了一个假设： 下层是不可靠的！！ TCP的很多特性都源自于这个 不可靠假设 。所以TCP屏蔽掉这个假设之后， TCP是可靠的！ TCP over TCP？TCP同时作为链路协议和负载协议？是的！ 那么 在TCP over TCP中，不可靠假设就失效了！ ，因为 TCP是可靠的！ 只要内层TCP的RTO超时时间小于外层TCP的RTO超时时间，悲剧就发生了，指数退避会让连接崩溃。 但是，这很少发生，在支持FACK/SACK/RACK的 现代TCP 中，RTO很少被触发

本文由手机淘宝技术团队原创分享，吴志华（天施）、洪海（孤星）、陈虓将（仲升）等专家参与了本文创作，首次发表于公众号“淘系技术”，收录整理时有修订和改动。 1、引言 移动端网络的优化是超级APP们永恒的话题，而对于无线电商来说这更为重要，因为网络请求体验跟用户的购买行为息息相关。 手机淘宝从过去的HTTP API网关，到后来扛住双十一战场主要流量的自研高性能、全双工、安全的ACCS（阿里云通道服务），无论是基础架构的演进、网络调优、协议的优化、异地多活、网络调度上，都有不少宝贵的经验与大家分享，本文借此机会总结了整个技术演进过程。 * 阅读对象： 本文属于移动端网络优化的深水区总结性文章，适合有一定移动端网络应用经验的开发者阅读（尤其对移动弱网有一定了解的），初学者如果没有相关知识积累的话，可以简单了解无需深入。如果你对移动弱网很有兴趣，可以进一步阅读本文末尾“附录”部分的推荐文章。 2、相关文章 《 Netty干货分享：京东京麦的生产级TCP网关技术实践总结 》 《 知乎技术分享：知乎千万级并发的高性能长连接网关技术实践 》 《 手机淘宝消息推送系统的架构与实践(音频+PPT) [附件下载] 》 3、技术背景 回想移动电商在双十一业务开始兴起的时候，当时双十一当天移动成交243亿占整体571亿的42.6%。 业务高速发展希望更多主动推送去触达用户，一些新的玩法和互动形式

2018 年世界杯前， StarTimesOn App 在非洲正式上线，全程直播 32 个球队的 64 场比赛，获得了广泛的关注和大量用户。目前StarTimesOn App除了转播体育赛事，还有 140 多个国际顶级的直播频道，以及数万小时的影视剧内容。 然而在非洲的网络条件下，交付良好的视频播放体验绝非易事，所以这几年张亮的工作就是从各个角度探索问题的解决方案，以保障非洲地区的视频播放体验。 采访讲师： 张亮 ，四达时代研发总监，毕业于北京科技大学，拥有超过十年的视频处理与CDN行业经验，对视频关键技术和大型系统架构设计有较深入的理解，近几年专注于海外弱网下的视频播放体验优化。目前主要负责“StarTimes On视频基础平台”的建设与技术管理工作。 LiveVideoStack：请您简单为读者介绍一下“StarTimesOn视频基础平台”及其亮点。 张亮： StarTimesOn视频基础平台包含了视频处理、视频分发、用户请求调度、视频QoE与QoS分析四大模块，每一部分均为非洲的独特挑战量身定制。 说到亮点，首先应该是 0-RTT起播的特性 ，用户在播放视频之前无需与后台和CDN进行多次交互，而是直接下载视频内容开始播放，这个特点使用户免受高RTT带来的首屏时间较长问题。 在 视频处理 部分，我们针对非洲相对较差的网络环境，设计了针对性的转码算法和封装格式

本文通过比喻的方式介绍了什么是HTTP，并阐述了从HTTP/1.0 到HTTP/3各个版本的区别和特点，值得一看。以下是原文： 周末一大早，我正在电脑前面浏览一些技术网站，突然女朋友大喊起来：哇，杭州又下大雪啦，快来看啊。我并没有理她，于是她跑过来拉我。  图，雪后杭州 由这次下雪将要介绍的HTTP和RPC也有点关系，都是通信方式。 什么是HTTP协议 HTTP是HyperText Transfer Protocol的缩写，中文翻译为 超文本传输协议 。他是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。 说的简单点， 其实HTTP协议主要就是用来进行客户端和服务器之间进行通信的标准协议 。HTTP主要规定了客户端如何与服务器建立 链接 、客户端如何从服务器请求数据、服务器如何响应请求，以及最后连接如何关闭。 当我们在浏览器中输入一个url，如http://www.taobao.com ，然后按下回车，一直到页面显示淘宝网的首页的过程就是一次HTTP的网络通信。 这次通信过程中，我们查看淘宝使用的电脑就是 客户端 ，而搭建淘宝网的那些计算机机器就是 服务器 。 这个过程有点像老板通过电话给员工下达命令。当我们在浏览器输入网址并按下回车之后，共发生了以下四件事： 1、建立连接：老板拨通手下员工的电话 2、进行请求：老板提出自己的要求 3、响应

网络数据安全得到前所未有的重视 HTTPS成为解决传输安全问题利器 大家都知道，HTTP 本身是明文传输的，没有经过任何安全处理，网站HTTPS解决方案通过在HTTP协议之上引入证书服务，完美解决网站的安全问题。 下图左侧表示Chrome浏览器在HTTPS页面时会显示安全挂锁图标，这是在2016年Chrome55版本上的新增功能，用于引导互联网向安全的HTTPS协议转变。右侧是截止2020年1月，Chrome平台上HTTPS流量占比已经超过90%，另外通过Chrome平台的HTTPS浏览时间占比也超过90%，这些数据都表明网络数据安全得到了前所未有的重视。 HTTPS的实现原理是什么？ HTTPS协议通过TCP层之上引入TLS/SSL协议，来实现对HTTP数据的保护，实现数据加密、完整性校验以及防篡改。整个HTTPS过程包括：TCP建联、SSL握手、应用数据加密传输阶段。其中SSL握手的目的是为了在服务端和客户端协商出一个对称密钥，在应用数据传输阶段使用这对称密钥进行数据的加密和解密。 在HTTPS交互过程中主要使用三种算法，首先SSL握手阶段用到非对称加密的算法，通过公钥和私钥对数据记性加密解密。在应用数据加密传输的阶段，主要使用的是对称加密的算法和hash算法。 目前，国际上通用的非对称加密算法包括rsa算法和ecdsa算法

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

“直播带货”可能是2020年最具代表性的词汇之一，那么传统电商该如何融合直播系统，直播过程如何保障用户的最佳观看体验？本文由腾讯云资深架构师何书照在LiveVideoStack线上分享中的内容整理而成，详解了大规模、低延时电商直播系统架构设计以及电商直播的难点、技术挑战与突破。 文 / 何书照 整理 / LiveVideoStack 直播回放： http://scrmtech.gensee.com/webcast/site/vod/play-6ced83f94af24094b6d8329948addb09 本次主要为大家分享最近腾讯云在低延时电商直播系统架构的设计与弱网优化实践。 电商直播的难点、挑战与技术突破 大规模、低延时电商直播系统架构设计 低延时直播系统弱网优化与互动连麦实践 电商直播的难点、挑战与技术突破 电商直播主要分为两种：其一，当前直播或短视频公司正在拥抱电商，其面临的挑战并非直播相关技术，反而是电商系统的设计架构。其二，线下电商类客户正在接触直播，拥抱疫情期间出现的新形势，其面临的挑战是如何将直播引入到电商系统中。 电商直播其实是“电商+直播”的过程，直播过程是实时的流媒体，该流媒体强烈依赖从主播端到观众端的整条链路，整条链路中任何一个环节出问题，都可能导致用户无法抢购商品、转化率降低。 大规模、低延时电商直播系统架构设计 标准的电商系统的设计流程有7步：浏览产品

网络数据安全得到前所未有的重视 HTTPS成为解决传输安全问题利器 大家都知道，HTTP 本身是明文传输的，没有经过任何安全处理，网站HTTPS解决方案通过在HTTP协议之上引入证书服务，完美解决网站的安全问题。 下图左侧表示Chrome浏览器在HTTPS页面时会显示安全挂锁图标，这是在2016年Chrome55版本上的新增功能，用于引导互联网向安全的HTTPS协议转变。右侧是截止2020年1月，Chrome平台上HTTPS流量占比已经超过90%，另外通过Chrome平台的HTTPS浏览时间占比也超过90%，这些数据都表明网络数据安全得到了前所未有的重视。 HTTPS的实现原理是什么？ HTTPS协议通过TCP层之上引入TLS/SSL协议，来实现对HTTP数据的保护，实现数据加密、完整性校验以及防篡改。整个HTTPS过程包括：TCP建联、SSL握手、应用数据加密传输阶段。其中SSL握手的目的是为了在服务端和客户端协商出一个对称密钥，在应用数据传输阶段使用这对称密钥进行数据的加密和解密。 在HTTPS交互过程中主要使用三种算法，首先SSL握手阶段用到非对称加密的算法，通过公钥和私钥对数据记性加密解密。在应用数据加密传输的阶段，主要使用的是对称加密的算法和hash算法。 目前，国际上通用的非对称加密算法包括rsa算法和ecdsa算法

随着网络上自治的和可能是异构的分散系统之间信息交换的兴起，对等数据库已经出现。OrbitDB源自Orbit聊天应用程序，是基于IPFS协议（行星际文件系统）的对等数据库。OrbitDB为不同的数据模型和用例提供了各种类型的数据库。它是为去中心化应用程序（dApps），区块链应用程序和一线Web应用程序而构建的。 OrbitDB还是一个分布式无服务器数据库。根据项目存储库，它使用IPFS作为数据存储，并使用IPFS Pubsub自动将数据库与对等方同步。它使用CRDT（无冲突复制数据类型）进行无冲突的数据库合并。CRDT（无冲突复制的数据类型）是数据结构的类型，其网络副本可以同时且独立地更新，而无需副本的协调。 它是一种做事方法，具有许多优点。另外，OrbitDB使用IPFS协议，该协议充当分布式CDN。它是一种对等协议，用于分发可以由超媒体解决的内容。IPFS不依赖集中式服务器。它旨在将一组IT设备与同一文件系统连接。IPFS与万维网相似，不同之处在于IPFS可以看作是在Git存储库中的单个BitTorrent Swarm交换对象。 IFPS 0.5.0于上周发布，这得益于DHT逻辑的改进，使得在网络上搜索和共享数据的速度比以前快得多。从此版本开始，更有效的路由和配置可减少带宽使用和后台流量。IFPS团队还更新了QUIC实验性传输，以减少连接等待时间和往返，以使其成为下一个默认版本

点击上方“朱小厮的博客”，选择“ 设为星标” 后台回复" 加群 "，加入新技术 2015 年 HTTP/2 标准发表后，大多数主流浏览器也于当年年底支持该标准。此后，凭借着多路复用、头部压缩、服务器推送等优势，HTTP/2 得到了越来越多开发者的青睐，不知不觉的 HTTP 已经发展到了第三代。本文基于兴趣部落接入 HTTP/3 的实践，聊一聊 HTTP/3 的原理以及业务接入的方式。 1. HTTP/3 原理 1.1 HTTP 历史 在介绍 HTTP/3 之前，我们先简单看下 HTTP 的历史，了解下 HTTP/3 出现的背景。 随着网络技术的发展，1999 年设计的 HTTP/1.1 已经不能满足需求，所以 Google 在 2009 年设计了基于 TCP 的 SPDY，后来 SPDY 的开发组推动 SPDY 成为正式标准，不过最终没能通过。不过 SPDY 的开发组全程参与了 HTTP/2 的制定过程，参考了 SPDY 的很多设计，所以我们一般认为 SPDY 就是 HTTP/2 的前身。无论 SPDY 还是 HTTP/2，都是基于 TCP 的，TCP 与 UDP 相比效率上存在天然的劣势，所以 2013 年 Google 开发了基于 UDP 的名为 QUIC 的传输层协议，QUIC 全称 Quick UDP Internet Connections，希望它能替代 TCP