优化HTTP等网络知识Android技术

Android高手笔记 - 网络优化

2021-08-30  本文已影响0人  今阳说

网络基础

Http & Https

定义:
  1. https:Hypertext Transfer Protocol over Secure Socket Layer 超文本传输协议的安全套接字层
  2. http:一种详细规定了浏览器和万维网服务器之间互相通信的规则
区别:
  1. https协议需要到ca申请证书,一般免费证书较少,因而需要一定费用。
  2. http是超文本传输协议,信息是明文传输,https则是具有安全性的SSL/TLS加密
    传输协议(在 HTTP 与 TCP 之间)。(SSL/TSL 的常见开源实现是 OpenSSL)
  3. http和https使用的是完全不同的连接方式,默认端口也不一样,前者是80,后者是443。
  4. http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、
    身份认证的网络协议,比http协议安全。
  5. 写法上的区别是前缀的不同,客户端处理的方式也不同;
SSL(Secure Sockets Layer)安全套接层
  1. 数据安全(保证数据不会被泄漏)与数据完整(保证数据不会被篡改);
  2. 对数据进行加密后传输;
https目的:
HTTPS 解决的问题:
  1. 信任主机问题(从CA申请证书);
  2. 防止通信过程中的数据的泄密和被篡改;
https实现原理:
  1. 客户使用https的URL访问Web服务器,要求与Web服务器建立SSL连接。
  2. Web服务器收到客户端请求后,会将网站的证书信息(证书中包含公钥)传送一份给客户端。
  3. 客户端的浏览器与Web服务器开始协商SSL连接的安全等级(交换协议版本号),也就是信息加密的等级。
  4. 客户端的浏览器根据双方同意的安全等级,建立临时会话密钥,然后利用网站的公钥将会话密钥加密,
    并传送给网站。
  5. Web服务器利用自己的私钥解密出会话密钥。
  6. Web服务器利用会话密钥加密与客户端之间的通信。

https加密原理

CA证书:

其实就是数字证书,是由 CA 机构颁发的,包括证书的颁发机构、版本,
使用者,公钥,有效时间,数字签名 Hash 值和签名 Hash 算法;

客户端如何校验CA证书

CA 证书中的 Hash 值,其实是用证书的私钥进行加密后的值(证书的私钥不在 CA 证书
中)。然后客户端得到证书后,利用证书中的公钥去解密该 Hash 值,得到 Hash-a ;然
后再利用证书内的签名 Hash 算法去生成一个 Hash-b 。最后比较 Hash-a 和 Hash-b 这
两个的值。如果相等,那么证明了该证书是对的,服务端是可以被信任的;如果不相等,那
么就说明该证书是错误的,可能被篡改了,浏览器会给出相关提示,无法建立起 HTTPS 连
接。除此之外,还会校验 CA 证书的有效时间和域名匹配等。

HTTPS中的SSL握手建立过程
  1. 客户端和服务端建立 SSL 握手,客户端通过 CA 证书来确认服务端的身份;
  2. 互相传递三个随机数,之后通过这随机数来生成一个密钥;
  3. 互相确认密钥,然后握手结束;
  4. 数据通讯开始,都使用同一个对话密钥来加解密;
    (简而言之,用非对称加密算法生成对称加密的秘钥,用对称加密算法加密通信内容)

分层:

OSI七层模型(物数网传会表应)
TCP/IP 四层模型
HTTP(应用层)》》TSL/SSL(安全层)》》TCP(传输层)》》IP(网络层)》》网络接口(数据链路层)
DNS(Domain Name System) 域名系统服务
域名:
DHCP(Dynamic Host Configuratin Protocol) 动态主机设置协议

为什么 TCP 要经过三次握手,四次挥手

三次握手:
  1. 第一次握手:建立连接。客户端发送连接请求报文段,将 SYN 位置为 1,Sequence Number为 x;然后,客户端进入 SYN_SEND 状态,等待服务器的确认。
  2. 第二次握手:服务器收到 SYN 报文段。服务器收到客户端的 SYN 报文段,需要对这个 SYN 报文段进行确认,设置 Acknowledgment Number 为 x+1(Sequence Number+1);同时,自己自己还要发送 SYN 请求信息,将 SYN 位置为 1,Sequence Number 为 y;服务器端将上述所有信息放到一个报文段(即 SYN+ACK 报文段)中,一并发送给客户端,此时服务器进入 SYN_RECV 状态;
  3. 第三次握手:客户端收到服务器的 SYN+ACK 报文段。然后将 Acknowledgment Number设置为 y+1,向服务器发送 ACK 报文段,这个报文段发送完毕以后,客户端和服务器端都进入 ESTABLISHED 状态,完成 TCP 三次握手。
四次挥手
  1. 第一次分手:主机 1(可以使客户端,也可以是服务器端),设置 Sequence Number 和Acknowledgment Number,向主机 2 发送一个 FIN 报文段;此时,主机 1 进入 FIN_WAIT_1状态;这表示主机 1 没有数据要发送给主机 2 了;
  2. 第二次分手:主机 2 收到了主机 1 发送的 FIN 报文段,向主机 1 回一个 ACK 报文段,Acknowledgment Number 为 Sequence Number 加 1;主机 1 进入 FIN_WAIT_2 状态;主机 2 告诉主机 1,我“同意”你的关闭请求;
  3. 第三次分手:主机 2 向主机 1 发送 FIN 报文段,请求关闭连接,同时主机 2 进入 LAST_ACK状态;
  4. 第四次分手:主机 1 收到主机 2 发送的 FIN 报文段,向主机 2 发送 ACK 报文段,然后主机1 进入 TIME_WAIT 状态;主机 2 收到主机 1 的 ACK 报文段以后,就关闭连接;此时,主机1 等待 2MSL 后依然没有收到回复,则证明 Server 端已正常关闭,那好,主机 1 也可以关闭连接了。(MSL是Maximum Segment Lifetime英文的缩写,中文可以译为“报文最大生存时间”,他是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃);
TCP 在三次握手的时候,IP 层和 MAC层在做什么?

TCP 和 UDP 的区别?

  1. TCP面向连接,UDP是无连接(即发送数据之前不需要建立连接);
  2. 对系统资源的要求(TCP 较多,UDP 少);
  3. UDP 程序结构较简单,不会对数据报进行任何的处理,即不合并,也不拆分数据,直接将应用层数据塞进报文里面。
  4. UDP 通常用于多媒体信息分发,即视频、语音、实时信息 等等。而 TCP 通常用于可靠信息的传输,应用场景包括金融交易、可靠通信、MQ 等等 ;
  5. TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;
    UDP没有拥塞控制,尽最大努力交付,不管网络是否拥塞,它都会把数据给交付出去,但不保证可靠交付
  6. UDP具有较好的实时性,工作效率比TCP高,适用于对高速传输和实时性有较高的通信或广播通信。
  7. 每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信
  8. TCP是全双工通信:两个设备在连接时,它们都可以同时地发送数据与接收数据。
  9. TCP是面向字节流的协议(可能出现黏包问题),UDP面向报文传输
  10. TCP 首部开销20字节;UDP 的首部开销小,只有 8 个字节。
TCP 协议的可靠传输
  1. 滑动窗口
  2. 累积确认
  3. 选择重传
TCP 协议的流量控制
  1. 滑动窗口: 接收方可以调整滑动窗口的大小来控制发送方发送数据的效率。
  2. 坚持定时器: 使用滑动窗口进行流量控制的时候设置:当接收到窗口为0的消息,则启动坚持定时器;坚持定时器每隔一段时间发送一个窗口探测报文;
TCP 协议的拥塞控制
  1. 慢启动算法:由小到大逐渐增加发送数据量;每收到一个报文确认,就加一;超过慢启动阈值(ssthresh) 则不再增长。
  2. 拥塞避免算法:维护一个拥塞窗口的变量;只要网络不拥塞,就试探着将拥塞窗口调大。
TCP 协议的四个定时器
  1. 超时定时器;
  2. 坚持定时器;
  3. 时间等待定时器;
  4. 保活定时器:
TCP可靠传输原理实现
  1. 确认和重传:接收方收到报文后就会进行确认,发送方一段时间没有收到确认就会重传。
  2. 数据校验。
  3. 数据合理分片与排序: TCP 会对数据进行分片,接收方会缓存为按序到达的数据,重新排序后再提交给应用层。
  4. 流程控制:当接收方来不及接收发送的数据时,则会提示发送方降低发送的速度,防止包丢失。
  5. 拥塞控制:当网络发生拥塞时,减少数据的发送。
    (http://blog.chinaunix.net/uid-26275986-id-4109679.html)

IP 协议

作用
  1. IP 协议 使得复杂的实际网络变为一个虚拟互连的网络;
  2. IP 协议 使得网络层可以屏蔽底层细节而专注网络层的数据转发;
  3. IP 协议 解决了在虚拟网络中数据报传输路径的问题;
IP 地址
MAC 地址与 IP 地址的区别
  1. 数据帧每一跳的 MAC 地址都在变化,而IP 数据报每一跳的 IP 地址始终不变。
  2. IP 地址具有远程定位功能,而 MAC 地址更像是身份证号,它的唯一性是为了组网时可以不用担心不同的网卡在一个网络里会产生冲突,从硬件角度保证不同的网卡有不同的标识。
  3. 相比于 IP 地址,MAC 地址的通信范围比较小,局限在一个子网里。例如:从 192.168.0.1/24 访问 192.168.0.9/24 是可以用 MAC 地址的。
ARP(Address Resolution Protocol)地址解析协议
RARP(Reverse Address Resolutioni Protocol)逆地址解析协议
网络地址转换 NAT(Network Address Translationn) 技术
内网地址
三类内网地址:
  1. A 类:10.0.0.0~10.255.255.255(支持千万数量级设备)。
  2. B 类:172.16.0.0~172.31.255.255(支持百万数据级设备)。
  3. C 类:192.168.0.0~192.168.255.255(支持万数量级设备)。
ICMP(Internet Control Message Protocol)协议
应用:使用 Ping 命令对网络故障进行排查
  1. ping 回环地址 127.0.0.1,不通,说明计算机使用的协议栈有问题,需要重装系统或协议栈。
  2. Ping 网关地址(路由地址),内网 ping 192.168.0.1/ 192.168.1.1,通,说明本机到路由器的地址是通的。不通,则说明 WIFI、网线是有问题的。
  3. Ping 远端地址 ping www.wanandroid.com,不通,则说明家中到 ISP 的网络之间是有故障的。这个时候就要从电信、联通、移动等 ISP 来排查问题了。
路由

GET 和 POST 的区别

  1. get参数通过url传递,post放在request body中。
  2. get请求在url中传递的参数是有长度限制的,而post没有。
  3. get比post更不安全,因为参数直接暴露在url中,所以不能用来传递敏感信息。
  4. get请求只能进行url编码,而post支持多种编码方式。
  5. get请求会浏览器主动cache,请求参数会被完整保留在浏览历史记录里,而post中的参数不会被保留。
  6. GET和POST本质上就是TCP链接,并无差别。但是由于HTTP的规定和浏览器/服务器的限制,导致他们在应用过程中体现出一些不同。

无线网络

电磁波

无线通信的频率

基站

天线去哪了

Massive MIMO(多天线技术)

千兆级 LTE

Link Turbo

网络I/O

Socket 描述符(socket fd)

同步

异步

阻塞

非阻塞

小明的故事

  1. 同步阻塞:小明一直盯着下载进度条,到 100% 的时候就完成。
  2. 同步非阻塞:小明提交下载任务后就去干别的,每过一段时间就去瞄一眼进度条,看到 100% 就完成。
  3. 异步阻塞:小明换了个有下载完成通知功能的软件,下载完成就“叮”一声。不过小明仍然一直等待“叮”的声音
  4. 异步非阻塞:仍然是那个会“叮”一声的下载软件,小明提交下载任务后就去干别的,听到“叮”的一声就知道完成了

网络I/O 模型

1. 阻塞I/O
2. 非阻塞I/O
3. 多路复用I/O
4. 信号驱动式I/O
5. 异步I/O

网络性能评估与优化

性能评估

延迟与带宽

不同网络制式的带宽与延迟参考值
网络制式       带宽(下行/上行)      延迟
2.75 G     384KB/48KB         600~700ms
3 G            7MB/2MB                150~400ms
4 G            128MB/56MB         40~50ms
5G         >100MB/>50MB       <10ms

弱网络

特点:
  1. 丢包率高:信号问题,用户过多,误码包,用户移动,基站切换
  2. 误码率高:环境电波,用户距离远
  3. 不稳定的延迟:用户数量,信令分配,丢包,误码包
  4. 不稳定的带宽:基站距离,用户数量,拥塞控制

性能测量

网络性能分析工具

TPC 优化

1. 重用连接
TFO(TCP Fast Open,TCP快速打开)
2. 拥塞预防及控制
流量控制
慢启动
拥塞预防
TCP PRR(Proportional Rate Reduction,比例降速)
客户端优化
  1. 少发或者不发网络情况(请求合并):消除不必要的数据传输本身就是很大的优化。比如,减少下载不必要的资源,或者通过压缩算法把要发送的比特数降到最低。
  2. 使用 CDN,让通信距离更短:通过在不同的地区部署服务器,把数据放到接近客户端的地方,可以减少网络往返的延迟,从而显著提升 TCP 性能。
  3. 重用 TCP 连接:把慢启动和其他拥塞控制机制的影响降到最低。

UDP 优化

在 RFC 5405 中,对设计单播 UDP 应用程序给出了很多设计建议(WebRTC 协议是下述规则的设计典范),如下所示:
1. 必须容忍各种因特网路径条件;
2. 应该控制传输速度;
3. 应该对所有流量进行拥塞控制;
4. 应该使用与 TCP 相近的带宽;
5. 应该准备基于丢包的重发计数器;
6. 应该不发送大于路径 MTU 的数据报;
7. 应该处理数据报丢失、重复和重排;
8. 应该足够稳定以支持 2 分钟以上的交付延迟;
9. 应该支持 IPv4 UDP 校验和,必须支持 IPv6 校验和;
10. 可以在需要时使用 keep-alive(最小间隔 15 秒)。

TLS(Transport Layer Security,传输层安全)

TLS 协议的目标是为在它之上运行的应用提供三个基本服务:
  1. 加密:混淆数据的机制。
  2. 身份验证:验证身份标识有效性的机制。
  3. 数据完整性:检测消息是否被篡改或伪造的机制。
TLS 优化
  1. 尽早完成握手
  2. 使用会话缓存与无状态恢复
  3. TLS 记录大小(小记录会造成浪费,大记录会导致延迟)
  4. 证书链的长度:如果证书链长度超过了 TCP 的初始拥塞窗口,那我们无意间就会让握手多了一次往返:证书长度超过拥塞窗口,从而导致服务器停下来等待 客户端的 ACK 消息。(解决方法:增大拥塞窗口,减少证书大小)
  5. OCSP 封套:服务器可以在证书链中包含(封套)证书颁发机构的 OCSP 响应,让浏览器跳过在线查询。把查询 OCSP 操作转移到服务器可以让服务器缓存签名的 OCSP 响应,从而节省很多客户端的请求。
  6. HTTP 严格传输安全:一种安全策略机制,让服务器通过简单的 HTTP 首部(如 Strict-Transport-Security: max-age=31536000) 对适用的浏览器声明访问规则。

移动端优化

何为网络库

网络库的核心作用
  1. 統一編程接口:简单易用,便于统一进行策略管理,流解析(JSON,XNML等)
  2. 全局网络控制:统一的网络调度,流量监控,容灾管理(跳维护页),控制日志输出,增加拦截器等
  3. 高性能:
网络库对比
xUtils:
Volley:
Retrofit:
okHttp:
Chromium 的Cronet:
微信 Mars:
大网络平台

为何优化

何为优化

影响网络请求速度的因素:
  1. 客户端网络库的内部设计和策略:IO并发模型,针对网络问题的优化
  2. 服务器性能:并发能力,带宽能力
  3. 网络相关:用户网络(弱网,强网),运营商,网络链路
网络优化的核心:
网络请求步骤:
  1. DNS解析:通过DNS服务器拿到对应域名的IP,需要关注 DNS解析耗时,运营商LocalDns劫持,DNS调度等;
  2. 创建连接:与服务器建连接,包括TCP三次握手,TLS密钥协商等,需要关注 多个IP/端口如何选择,是否使用HTTPS,能否减少创建连接的时间;
  3. 发送/接受数据:数据的组装,发送,接收,解析,需要关注 根据网络状况利用带宽,侦测网络延时,弱网下调整包大小;
  4. 关闭连接:需要关注 主动关闭和被动关闭两种情况;

HTTPDNS

LocalDNS存在的问题:
  1. 解析慢,4G约100ms,3G约200~300ms
  2. 稳定性:UDP协议,无状态,容易域名劫持(难复现,难定位,难解决)
  3. 准确性:调度经常不准确,跨地域,跨运营商调度会导致访问慢,甚至访问不了
  4. 及时性:运营商可能修改DNS的TTL,导致DNS修改生效延迟

连接复用

压缩与加密

对于HTTP请求数据主要有三部分:
  1. 请求header:HTTP/2.0本身有头部压缩技术
  2. 请求URL:一般我们会有很多公共参数,这些参数大部分是不变的,可以只上传一次,在统一接入层进行参数扩展
  3. 请求body:一是通信协议的选择,在网络传输中目前最流行的两种数据序列化方式是 JSON 和 Protocol Buffers,Protocol Buffers 使用起来更加复杂一些,但在数据压缩率、序列化与反序列化速度上面都有很大的优势。二是压缩算法的选择,通用的压缩算法主要是如 gzip,Google 的Brotli或者 Facebook 的Z-standard都是压缩率更高的算法。

安全

HTTPS 的优化

  1. 连接复用率:多个域名共用同一个 HTTP/2 连接、长连接等方式
  2. 减少握手次数:TLS 1.3可以实现 0-RTT 协商,事实上在 TLS 1.3 release 之前,微信的mmtls、Facebook 的fizz、阿里的 SlightSSL 都已在企业内部大规模部署。
  3. 性能提升:使用 ecc 证书代替 RSA,服务端签名的性能可以提升 4~10 倍,但是客户端校验性能降低了约 20 倍,从 10 微秒级降低到 100 微秒级。另外一方面可以通过 Session Ticket 会话复用,节省一个 RTT 耗时。
  4. 其他优化:一些方案可能是需要用钱堆出来的,比如部署跨国的专线、加速点,多 IDC 就近接入等。除此之外,使用CDN 服务、P2P 技术也是比较常用的手段,特别在直播这类场景。
    1. 异地多活:多个地区同时存在对等的多个机房,以用户维度划分,多机房共同承担全量用户的流量。
    2. 抗抖动优化:应用一种有策略的重试机制,将网络请求以是否发送到 socket 缓冲区作为分割
    3. SYNC 机制:同步差量数据,达到节省流量,提高通信效率与请求成功率。客户端用户不在线时,SYNC 服务端将差量数据保持在数据库中。当客户端下次连接到服务器时,再同步差量数据给用户。
    4. 高并发流量处理:服务端接入层多级限流,
    5. JobScheduler:结合 JobScheduler 来根据实际情况做网络请求. 比方说 Splash 闪屏广告图片, 我们可以在连接到 Wifi 时下载缓存到本地; 新闻类的 App 可以在充电, Wifi 状态下做离线缓存。
    6. 网络请求优先级排序:app应该对网络请求划分优先级尽可能快地展示最有用的信息给用户。(高优先级的服务优先使用长连接)
    7. 建立长连通道:将众多请求放入等待发送队列中,待长连通道建立完毕后再将等待队列中的请求放在长连通道上依次送出。
    8. 减少域名和避免重定向
    9. 没有请求的请求,才是最快的请求。

移动端监控

1. 插桩:
2. Native Hook:
3. 统一网络库

如何监控流量

getMobileRxBytes()        //从开机开始Mobile网络接收的字节总数,不包括Wifi
getTotalRxBytes()         //从开机开始所有网络接收的字节总数,包括Wifi
getMobileTxBytes()        //从开机开始Mobile网络发送的字节总数,不包括Wifi
getTotalTxBytes()         //从开机开始所有网络发送的字节总数,包括Wifi
//原理:读取 proc,并将目标 UID 下面所有网络接口的流量相加。
//Android 7.0 之后只能通过 TrafficStats 拿到自己应用的流量信息
网络测试模式:

参考

我是今阳,如果想要进阶和了解更多的干货,欢迎关注微信公众号 “今阳说” 接收我的最新文章

上一篇下一篇

猜你喜欢

热点阅读