现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

  • 时间:
  • 浏览:2
  • 来源:万人红黑大战_万人红黑大战官网

3)加快握手过程:2RTT-> 0RTT。加快握手的思路,就是那我客户端和服务端都要协商使用有哪些算法后并能加密发送数据,变成通过内置的公钥和默认的算法,在握手的一同就把数据发出去,也就是不都要等待时间握手就现在开始发送数据,达到0RTT。

3)DNS 解析过程不受控制,无法保证解析到最快的IP;

压缩算法多种多样,也在不断演进,最新出的 Brotli 和Z-standard实现了更高的压缩率,Z-standard 还都可以 根据业务数据样本训练出适合的字典,进一步提高压缩率,目前压缩率表现最好的算法。

通过 HTTPDNS,连接多路复用,更好的数据压缩算法,还都可以 把网络请求的速率优化到较不错的程度了,接下来再看看弱网和安全上还都可以 做的事情。

《腾讯原创分享(二):咋样大幅压缩移动网络下APP的流量消耗(下篇)》

2) 降低加密成本。

标准协议 TLS 保证了网络传输的安全,前身是 SSL,不断在演进,目前最新是 TLS1.3。常见的 HTTPS 就是 HTTP 协议加进 TLS 安全协议。

DNS 完全的解析流程很长,会先从本地系统缓存取,若不出就到最近的 DNS 服务器取,若不出再到主域名服务器取,每一层不会缓存,但为了域名解析的实时性,每一层缓存不会过期时间。

QUIC 所处起步阶段,少有客户端接入,QUIC 协议相对于 HTTP2 最大的优势是对TCP队头阻塞的出理 ,有些的像安全握手 0RTT / 证书压缩等优化 TLS1.3 已跟进,还都可以 用于 HTTP2,并不会独有特征。TCP 队头阻塞在 HTTP2 上对性能的影响有多大,在速率上 QUIC 能带来多大提升待研究(关于有些点还都可以 看看腾讯的QUIC技术实践《让互联网越来很慢:新一代QUIC协议在腾讯的技术实践分享》)。

《通俗易懂-深入理解TCP协议(上):理论基础》

这里有明显的一个优化点:

若并行发送有有哪些请求,不出首次每个请求不会进行tcp三次握手建立新的连接,我虽然第二次还都可以 复用连接池里这堆连接,但若连接池里保持的连接过多,对服务端资源产生较大浪费,若限制了保持的连接数,并行请求里超出的连接仍每每段建连。

(本文同步发布于:http://www.52im.net/thread-1413-1-1.html)

自已实现HTTPDNS的好处总结就是:

2)认证对方身份,出理 被第三方冒充;

HTTP 协议里有个 keep-alive,HTTP1.1默认开启,一定程度上缓解了每次请求不会进行TCP三次握手建立连接的耗时。原理是请求完成后不立即释放连接,就是装到去去连接池中,若这时有那我请求要发出,请求的域名和端口是一样的,就直接背熟连接池中的连接进行发送和接收数据,少了建立连接的耗时。

对于有些问题图片图片不改变 TCP 协议就无法优化,但 TCP 协议依赖操作系统实现以及每段硬件的定制,改进缓慢,于是 GOOGLE 提出 QUIC 协议(详见《技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解》),最少在 UDP 协议之上再定义一套可靠传输协议,出理 TCP 的有些不足英文,包括队头阻塞。具体出理 原理网上资料较多,还都可以 看看。

▼【TCP队头阻塞】:

对服务端的TCP协议参数进行调优,以及开启各种优化算法,使得适合业务特征和移动端网络环境,包括RTO初始值,混合慢启动,TLP,F-RTO等。

▼【多路复用】:

在保证安全上:

HTTP2 的多路复用看起来是完美的出理 方案,但还有个问题图片图片,就是队头阻塞,这是受限于 TCP 协议,TCP 协议为了保证数据的可靠性,若传输过程中一个 TCP 包丢失,会等待时间有些包重传后,才会出理 后续的包。HTTP2的多路复用让所有请求不会同两根连接进行,后面 一个包丢失,就会阻塞等待时间重传,所有请求也就被阻塞了。

《微信新一代通信安全出理 方案:基于TLS1.3的MMTLS详解》

1)DNS 解析,请求DNS服务器,获取域名对应的 IP 地址;

但对于追求用户体验的应用来说,不会针对移动网络的特征做进一步优化,包括:

3)DNS 解析由本人控制,还都可以 确保根据用户所在地返回就近的 IP 地址,或根据客户端测速结果使用速率最快的 IP;

《让互联网越来很慢:新一代QUIC协议在腾讯的技术实践分享》

《来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享》

手机无线网络环境不稳定,针对弱网的优化,微信有较多实践和分享,包括:

1)缓存时间设置得长,域名更新不及时,设置得短,少量 DNS 解析请求影响请求速率;

《TCP/IP详解 - 第18章·TCP连接的建立与终止》

HTTP2 这里的多路复用协议出理 了有有哪些问题图片图片,它把在连接里传输的数据都封装成一个个stream,每个stream不会标识,stream的发送和接收还都可以 是乱序的,不依赖顺序,也就不需要有阻塞的问题图片图片,接收端还都可以 根据stream的标识去区分属于哪个请求,再进行数据拼接,得到最终数据。

其余细节就过多说了,HTTPDNS 优点不出多,几乎成为中大型 APP 的标配。至此出理 了第一个问题图片图片 — DNS 解析耗时的问题图片图片,顺便把一每段安全问题图片图片 — DNS 劫持也出理 了。

3)连接建立完成,发送和接收数据,解码数据。

《谈谈移动端 IM 开发中登录请求的优化》

针对弱网的有有哪些细致优化未成为标准,系统网络库不出内置,不过前一个客户端优化微信的开源网络库 mars 有实现,若有都并还都可以 使用(详见《如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源》)。

《即时通讯安全篇(六):非对称加密技术的原理与应用实践》

对总读写超时(从请求到响应的超时)、首包超时、包包超时(一个数据段之间的超时)时间制定不同的计算方案,加快对超时的判断,减少等待时间时间,尽早重试。这里的超时时间还还都可以 根据网络请况动态设定;

3)安全保障:咋样出理 被第三方窃听/篡改或冒充,出理 运营商劫持,一同又不影响性能?

第俩个问题图片图片,连接建立耗时的问题图片图片,这里主要的优化思路是复用连接,不需要每次请求都重新建立连接,咋样更有速率地复用连接,还都可以 说是网络请求速率优化里最主要的点了,或者这里的优化仍在演进过程中,值得了解下。

《如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源》

降低加密成本上:

2)缓存安全协议握手后的密钥等数据,加快第二次建连的速率;

第一个问题图片图片,传输数据大小的问题图片图片。数据对请求速率的影响分两方面,一是压缩率,二是解压序列化反序列化的速率。目前最流行的并全是数据格式是 json 和 protobuf,json 是字符串,protobuf 是二进制,即使用各种压缩算法压缩后,protobuf 仍会比 json 小,数据量上 protobuf 有优势,序列化速率 protobuf 不会有些优势,这两者的对比就不细说了。(关于protobuf的原理,详见《Protobuf通信协议详解:代码演示、完全原理介绍等》、《全方位评测:Protobuf性能到底有不出比JSON快5倍?》、《强列建议将Protobuf作为你的即时通讯应用数据传输格式》)

目前基本主流都支持 TLS1.2,iOS 网络库默认使用 TLS1.2,Android4.4 以上支持 1.2。TLS1.3 iOS 还所处测试阶段,Android 未查到消息。对于普通 APP,假如有一天正确配置证书,TLS1.2 将会能保证传输安全,就是在建连速率上会有所损耗,有有些大型 APP 像微信就自行实现了 TLS1.3 的每段协议,早一步全平台支持(微信团队专门分享过关于TLS1.3的实践文章,详见《微信新一代通信安全出理 方案:基于TLS1.3的MMTLS详解》)。

《微信对网络影响的技术试验及分析(论文全文)》

HTTP2 的多路复用机制一样是复用连接,但它复用的这条连接支持一同出理 多条请求,所有请求都还都可以 并发在这条连接上进行,也就出理 了后面 说的并发请求都要建立多条连接带来的问题图片图片。

正常两根网络请求都要经过的流程是那我:

《腾讯原创分享(一):咋样大幅提升移动网络下手机QQ的图片速率和成功率》

1)直接使用 IP 地址,去除 DNS 解析步骤;

2)弱网适应:移动端网络环境随时变化,一个劲出先网络连接很不稳定可用性差的请况,咋样在有些请况下最大限度最快地成功请求?

《理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程》

移动端网络优化有些话题非常庞大,本文就是在学习过程中从优化思路上列举了目前业界常见的优化点,还有过多过多细节过多过多更深入的优化没涉及到,网络层实践开发经验不足英文,若有错误欢迎指出。

《简述移动端IM开发的有有哪些坑:采集、通信协议和客户端》

除了传输的 body 数据,每个请求 HTTP 协议头的数据也是不可忽视,HTTP2 里对 HTTP 协议头也进行了压缩,HTTP 头大多是重复数据,固定的字段如 method 还都可以 用静态字典,不固定但多个请求重复的字段之类 cookie 用动态字典,还都可以 达到非常高的压缩率,这里有完全介绍《HTTP/2 头部压缩技术介绍》(该作者针对HTTP2有过多过多研究,更多HTTP2文章可见作者的HTTP2技术专题,方便进行深入学习)。

1)用对称加密算法加密传输数据,出理 非对称加密算法的性能低以及长度限制问题图片图片;

1)保证安全;

1)域名解析与请求分离,所有请求都直接用IP地址,不需要 DNS 解析,APP 定时请求 HTTPDNS 服务器更新IP地址即可;

《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》

1)速率优化:网络请求的速率咋样能进一步提升?

《腾讯原创分享(二):咋样大幅压缩移动网络下APP的流量消耗(上篇)》

▼【keep-alive】:

实际上现在无论是客户端还是浏览器都默认开启了keep-alive,对同个域名不需要再有每发一个请求就进行一次建连的请况,纯短连接将会不所处了。但有个问题图片图片,就是有些 keep-alive 的连接一次非要发送接收一个请求,在上一个请求出理 完成并且,无法接受新的请求。若一同发起多个请求,不会并全是请况:

2)通过签名等土办法,保证 HTTPDNS 请求的安全,出理 被劫持;

众所周之,通常大伙儿儿儿开发一个移动端应用,会直接调用系统提供的网络请求接口去服务端请求数据,再针对返回的数据进行有些出理 ,将会使用iOS中的开源AFNetworking/OKHttp那我的网络库(Android中还都可以 用HttpURLConnection将会开源的okhttp库),管理好请求守护进程和队列,再自动做有些数据解析,就现在开始了。

4)一次请求还都可以 解析多个域名。

复合连接,建立连接时,阶梯式并发连接,其中两根连通后有些连接都关闭。有些方案结合串行和并发的优势,提高弱网下的连接成功率,一同又不需要增加服务器资源消耗,见下图

2)制定最最少的超时时间:

本文原始内容来自JSPatch开源工程作者bang的技术分享,他的博客是:http://blog.cnbang.net/about/,本次内容有优化和完善,感谢原作者的无私分享。

4)一次请求非要解析一个域名。

网络上有张图还都可以 较形象地表现有些过程:

关于移动端网络中DNS的问题图片图片,《谈谈移动端 IM 开发中登录请求的优化》一文中不会提到,仅供参考。

2)涉及移动端网络特征的文章:

解释下多路复用有些词,多路还都可以 认为是多个连接,多个操作,复用就是字面上的意思,复用两根连接或一个守护进程。HTTP2这里是连接的多路复用,网络相关的还一个I/O的多路复用(select/epoll),指通过事件驱动的土办法让多个网络请求返回的数据在同两根守护进程里完成读写。

PS:关于理解TCP的3次握手原理,以下文章将会对您会有帮助

3)调优TCP参数,使用TCP优化算法:

1)提升连接成功率:

《理论经典:TCP协议的3次握手与4次挥手过程详解》

3)压缩数据,减小传输的数据大小。

对基于浏览器的前端开发来说,网络这块能做的事情很少,但对于原生的移动端应用来说(本文中说的原生主要指iOS和Android应用),整个网络请求过程是自由控制的,还都可以 做过多过多事情。过多过多大型 APP 都针对有些一个问题图片图片做了过多过多网络层的优化,有些新的网络层协议像 HTTP2 / QUIC 也是在有有哪些方面进行了不少优化。在此请跟着我的文字,边学习边采集,总结一下当今主流的移动端网络短连接常见优化手段,希望能给您带来启发。

后面 有些 DNS 解析机制有十几块 缺点:

《技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解》

本文采集的有关内容,对于移动端即时通讯IM应用来说,同样具有启发意义,将会现今主流的移动端IM数据通信总结下来无外乎就是长连接+短连接的土办法,则短连接的优化在有些场景下对于移动端IM来说将会显示的更为特出。在这方面,微信做的比较彻底和极端,几乎再造了一套针对移动端IM的网络层框架(详见:《如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源》)。

逐条来看能做有哪些。

1)关于网络通信的基础文章:

若串行发送请求,还都可以 一个劲复用一个连接,但速率很慢,每个请求不会等待时间上个请求完成再进行发送。

安全协议概括性地说出理 一个问题图片图片:

3)加密算法保持灵活可更新,出理 定死算法被破解后无法更换,禁用已被破解的算法。

《即时通讯安全篇(三):常用加解密算法与通讯安全讲解》

将会您对网络通信知识了解甚少,建议阅读《网络编程懒人入门系列文章》,更高深的网络通信文章还都可以 阅读《不为人知的网络编程系列文章》。

2)无须每次请求都重新建立连接,复用连接或一个劲使用同两根连接(长连接);

移动客户端来说,iOS 9 以上 NSURLSession 已原生支持 HTTP2,假如有一天服务端也支持就还都可以 直接使用,Android 的开源网络库 okhttp3以上版本也支持了 HTTP2,国内有些大型 APP 会自建网络层,支持 HTTP2 的多路复用,出理 系统的限制以及根据自身业务都要增加有些特征,之类微信的开源网络库 mars(详见《如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源》),做到两根长连接出理 微信上的大每段请求,多路复用的特征上基本跟 HTTP2 一致。

PS:关于新一代QUIC协议的更多文章请见

《移动端IM开发都要面对的技术问题图片图片(含通信协议选则)》

对有些问题图片图片,新一代协议 HTTP2 提出了多路复用去出理 。

2)与服务端建立连接,包括 tcp 三次握手,安全协议同步流程;

2)域名劫持,容易被后面 人攻击,或被运营商劫持,把域名解析到第三方 IP 地址,据统计劫持率会达到7%;

HTTP1.1的协议里,在一个连接里传送数据不会串行顺序传送的,都要等上一个请求完全出理 并且,下一个请求并能进行出理 ,是因为有有哪些请求期间这条连接并不会满速率传输的,即使是HTTP1.1的pipelining还都可以 一同发送多个request,但response仍是按请求的顺序串行返回,假如有一天其中一个请求的response稍微大有些或所处错误,就会阻塞住后面 的请求。

有有哪些点涉及的细节非常多,对 TLS 的介绍有一篇雄文,说得很完全,在此推荐:《TLS协议分析 与 现代加密通信协议设计》(JackJiang注:这篇文章长的惊人,希望你能耐心把它都看 ^_^)。

《七牛云技术分享:使用QUIC协议实现实时视频直播0卡顿!》

为了出理 有有哪些问题图片图片,不会了 HTTPDNS,原理很简单,就是本人做域名解析的工作,通过 HTTP 请求后台去拿到域名对应的 IP 地址,直接出理 上述所有问题图片图片。

《通俗易懂:一篇掌握即时通讯的消息传输安全原理》

下面这几篇是有关移动端通信安全的基础文章,比后面 那篇要容易理解:

(本文同步发布于:http://www.52im.net/thread-1413-1-1.html)

1)使用加密算法组合对传输数据加密,出理 被窃听和篡改;