移动app网络优化

移动app网络优化的三个切入点:速度、弱网、网络安全

    本章主要讲如何优化网络请求速度。弱网和网络安全都是轻描淡写,主要是给大家拓展视野的,如果有哪些地方理解错了,欢迎大家指出,感激不尽。

一、速度

想要优化请求速度,首先必须先了解整个“请求-->响应”的过程,在这里我只分析这个过程中存在影响网络请求速度的三点因素:

    1. DNS解析,去DNS服务器解析域名,获取IP地址

    2. 与服务器建立连接,包括TCP的三次握手以及安全协议同步流程

    3. 建立完成,发送请求,接收响应数据,解析数据

1. DNS解析

DNS解析过程:

    当我们发起请求时,首先需要把域名解析为我们服务器对应的ip地址。解析的过程是首先从系统本地获取,如果没有就去就近的DNS服务器取,再没有就去主DNS服务器取。

DNS解析的缺点:

    1. DNS每一层获取ip都是有缓存的,缓存时间设置过长不利于ip的更新,设置过短需要频繁的去主DNS服务器解析,耗时长。

    2. DNS劫持:通过攻击营运商的DNS服务器,返回其他第三方服务器的ip,最后我们的请求是由第三方的服务器响应的,所以内容有可能是被篡改的,比如自己的app内嵌网页被搭载了不堪入目的广告。

    3. DNS获得的ip不能保证是速度最快的ip,而且每次解析只能解析一个域名。

DNS问题解决:HTTPDNS

    HTTPDNS使用HTTP协议进行域名解析,代替现有基于UDP的DNS协议,域名解析请求直接发送到自己的HTTPDNS服务器(其实就是自己存有ip<=>域名的映射),从而绕过运营商的Local DNS,能够避免Local DNS造成的域名劫持问题和调度不精准问题。

    这其中有个需要注意的问题是,在自己的服务器解析ip,需要使用安全连接(可以用HTTPS),否则也很容易被第三方攻击。

    具体的实现思路就是:通过安全连接请求自己的服务器获取ip(可以一次性请求多个域名解析ip),然后缓存到本地,定时更新。当然,如果跟服务器有长连接就更好了,如果有ip需要更新,服务器随时可以下发ip,也避免了客户端不必要的定时更新。

2、客户端与服务器建立连接

    由于TCP是面向连接的可靠性传输,TCP连接的建立,需要TCP的三次握手,保证可靠性传输,如果每次请求都需要三次握手来建立连接,就会造成网络延迟变大。但是在这里,我们可以干预的空间不大,所以这里我就只阐述一些本身具有的优化点

1. Keep-Alive

    顾名思义,就是建立完连接,网络请求结束之后,将这条连接通道加入到复用池进行保活,以便下次请求可以复用。在HTTP1.1默认开启Keep-Alive,不需要我们人为干预。

这其中还是存在不少问题的:

    1)复用连接,必须得在该连接请求结束之后,才能被复用,理解的话,可以比作我们多线程中的串行。

    2)如果复用池没有可用的连接,并发请求,同样需要建立新的连接。而且复用池保持的连接多了,会占用服务器过多的资源。当然服务器可以设置最大连接数,但是如果超过最大连接数的话,每次请求都需要重新建立新的连接,结果又回到了解放前。

    3)在一条连接的管道上,可以发送多个请求,但是响应的顺序是按照请求的顺序依次返回的,如果中间有一个请求过程中出错了,就会阻塞后面的响应返回。

2. 多路复用

    多路复用是一个连接可以并发多个请求,请请求数据封装成一个带标识的stream,响应顺序跟请求顺序无关,根据标识区分是哪个请求的响应。当然了,多路复用是HTTP2.0才开始支持的,客户端iOS9以上(微信的开源网络库mars)

    多路复用虽然解决了HTTP1.1的大部分问题,还是还有一个本命的问题无法避免,那就是TCP队头阻塞。什么是TCP队头阻塞呢?这是受限于 TCP 协议,TCP 协议为了保证数据的可靠性,若传输过程中一个 TCP 包丢失,会等待这个包重传后,才会处理后续的包。HTTP2的多路复用让所有请求都在同一条连接进行,中间有一个包丢失,就会阻塞等待重传,所有请求也就被阻塞了

    当然也有解决方案:自定义TCP协议。Google提出的QUIC协议就是为了解决TCP队头阻塞的,就是在DUP协议上自定义一套可靠传输协议QUIC(带来的提升有待研究)

二、弱网

    弱网环境下,我们能做的事情也比较少,宗旨就是指定合适的超时时间,尽早重试。

三、安全

    建议是直接使用HTTPS,既能保证网络传输安全,又能降低加密成本。

安全传输:

    对数据使用组合加密,降低被窃听和修改的风险。

    认证身份,避免被第三方冒用。

    加密算法实时更新,避免加密算法被破解无法实时更新算法,并禁用已被破解的算法。

降低加密成本:

    使用对称加密算法加密数据,解决使用非对称加密算法性能低下和长度限制的问题。

    缓存安全协议握手之后的密钥等数据,加快第二次建立连接的速度。

    加快握手速度,2RTT->0RTT。原本需要客户端商量好使用什么加密算法,才能把加密数据发送出去,限制可以通过网络库内置的公钥和默认的加密方式,在握手的同时把数据发送出去,达到0RTT。(什么是RTT?RTT(Round-Trip Time): 往返时延,在计算机网络中它也是一个重要的性能指标,它表示从发送端发送数据开始,到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认),总共经历的时延; RTT: 无线传输技术(RTT))

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,029评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,395评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,570评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,535评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,650评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,850评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,006评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,747评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,207评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,536评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,683评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,342评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,964评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,772评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,004评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,401评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,566评论 2 349

推荐阅读更多精彩内容