Android网络
文章整理自内部网络模块同事一些课程的分享时所做的一些笔记
I. 无线网络的影响
1) 无线网络物理影响:
- 丢包多
- 带宽受限
2) 无线网络第三方影响:
- 第三方运营商中间做手脚
II. 解决不稳定手段–TCP
TCP在移动网络中的缺陷
不是基于移动网络优化的
最优网络的关键点
- 超时
- 重试
- 间隔设计
TCP自带可靠性保障
序号 确认
检验和（但不可靠)
可以保证每个包是对的，10G左右的文件就会出现错误（检验和的错误（几种不通过的检验和达到一个对的/第三方运营商做手脚））超时重传(TCP中最重要与复杂的问题)
发送每个报文都有计时器保障在计时器的时间里 是否有答复（无答复重发） (3s/6s/12s/24s/48s/96s 3*2^n)
重发：无网络感知，网络断开会无限重发，所以需要做超时处理
ps: 网络有可能出现雪崩（网络资源供不应求（所以TCP是
指数退避的机制BLG））
针对关键点策略
Connect超时
(ios TCP: 6s前 重试: 每次间隔1s)首包超时
发一个数据出去，服务器的答复时间，来确定是否网络有问题ps: 微信是 (数据长度/估计速度(根据网络类型估算) + 服务器处理时间(Wechat Server(10s))) 相关于 (并行处理的系数(竞争任务数*系数))
分包超时
解决网络偶断的问题
wechat : GPRS: 10s、 Wifi: 8s读写超时
（微信 64k回包）(2g 10k/s 6s服务器处理时间，要30s)
通过首包超时与分包超时减少 TCP重试间隔 来加快读写ps: 微信是 首包超时 + 接收数据长度/估算速度
重试次数
两次（因为第一次失败可能是偶然，第二次偶然失败概率很低（那就很有可能必然失败））重试间隔
第一次重试快重试（间隔小），第二重试慢重试（间隔大）任务超时
统一的返回时间，无论以上任何因素的表现如何，任务超时时间统一。
III. 处理带宽受限问题
解决问题关键字
- 速度(发图)
- 最低失败成本（断点续传）
两点场景
- 接收方处理能力不足
- 线路内部堵塞
TCP自带的解决方案
滑动窗口协议
发送窗口长度 计算： Min[rwnd(接收端窗口)(TCP中的一个字段从服务器带回来), cwnd(拥塞端口（通过探测获得）)]慢开始和拥塞避免
避免算法快重传
最高速因数
减少send调用次数
写满TCP发送buffer（填满发送窗口）
控制好数据处理线程（提高处理能力来提高速度）（接收方策略）(接收方每次读一次数据，接收窗口就会变大，(Android写磁盘效率低，秒级))
单socket vs 多 socket
IV. 长链接需要注意
DNS特点:
不可靠
运营商劫持、运营商控制超时控制（域名解析更新）、可用信息、批量解释的优化。
ps: 微信是自建DNS服务器
长链接
为什么需要心跳:
保证连接有效（防止中间与微信后台 资源回收）
TCP在链路层上需要发送数据的时候，才会得到信令
ps: 微信心跳时间: 5min
信令风暴
心跳等导致频繁的请求信令。（目前在国内是移动渠道比较多）
资源回收情况:
3/4G网络
国内情况：移动之前是5min，目前10min。
国外情况: google是10min/28min智能心跳
自己探测处理移动在5min、10min、15min。
联通与电信都在: 10min
V. 应用层协议设计
网络协议:
- HTTP、TCP、FTP….
内容组织 => 网络通道 => 服务器 => 回包
网络协议关键字
1. 语法（如何组织表达的内容）
文本:
diy、k-v、xml(编解码慢)、json二进制(需要自描述(类型、长度)):
TLV(Tag-Length-Value)、Protobuf其他
2. 语义（表达内容(格式的设计)）
需要考虑的: 可扩展、兼容、并发、高效实时、省流量
协议内容:
业务数据
信令数据:
分包(octet-stuffing、octet-counting、connect-blasting)、并发处理(序列号、命令号)、兼容性&拓展性（版本号，压缩算法、加密算法）、精简(严格按照packed所需大小)