弱网搭建及模拟工具，弱网或无网状态下 App的优化，弱网优化，网络优化(DNS/HttpDNS)

现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障- http://www.52im.net/thread-1413-1-1.html
快速理解P2P技术中的NAT穿透原理- http://www.52im.net/thread-1055-1-1.html

 弱网测试工具Charles MAC.

> App 优化网络

- App 优化网络，先从优化 DNS 开始
  在 App 访问网络的时候，DNS 解析是网络请求的第一步，默认我们使用运营商的 LocalDNS 服务。有数据统计，在这一块 3G 网络下，耗时在 200~300ms，4G 网络下也需要 100ms。

- 在 OkHttp 中使用 HTTPDNS，有两种方式。
 1.通过拦截器，在发送请求之前，将域名替换为 IP 地址。
 2.通过 OkHttp 提供的 .dns() 接口，配置 HTTPDNS。

> 弱网环境搭建，弱网络模拟工具
  市面上已经有一些弱网络模拟工具，比如微软的Network Emulator for Windows Toolkit（NEWT），Facebook的Augmented Traffic Control（ATC），以及WANem，NEWT。NEWT是基于Windows的，通过图形化的界面，可以对该机器的网络参数进行设置，且模型较为丰富。  弱网模拟：Facebook最近也开源了他们的augmented traffic control: https://github.com/facebook/augmented-traffic-control 主要使用iptables和python实现。  Facebook的开源项目augmented-traffic-control可以模拟不同的网络环境，针对带宽、时延抖动、丢包率、错包率、包重排序率等方面，堪称弱网调试神器；
  如何度量和模拟“弱网络”对移动APP的开发有着重大的意义，比如：节约测试成本、易于问题重现、加快产品上线等。
一般的方法是使用“丢包率”和“网络延时”来定义和衡量“弱网络”。
  无线网络的一大特点：秒级状态管理，秒级状态转换。这两个操作都在几百ms到几秒之间进行，对于维持连接来说时间太短，对于从无连接到有连接的转换来说时间又太长。相比之下，有线网络的状态管理如ip分配、tcp连接释放，都是分钟级，而状态转换则是毫秒级。
App在弱网下的可用性，环境搭建- http://hugozhu.myalert.info/2015/03/28/59-use-raspberrypi-to-build-an-augmented-traffic-control-system.html

-- 自动化弱网测试，弱网模拟
Linux可以使用netem或iptables来实现以下网络模拟：
  packet delay 网络包延迟；packet loss 网络包丢失；packet corruption 错误的网络包；packet duplication 重复发送网络包；packet re-ordering 网络包传输顺序；bandwidth 带宽控制；

  弱网丢帧策略：丢弃原始队列未编码的数据帧，丢弃编码队列的数据帧。
> App 网络优化
美团点评移动网络优化实践- http://tech.meituan.com/SharkSDK.html

> App 弱网优化
弱网下移动端网络连接处理策略- https://segmentfault.com/a/1190000006733978
弱网下移动端网络连接处理策略- http://mobile.51cto.com/hot-557695.htm#topx
-- 弱网络下几点优化原则：
  1.接口设计优化，接口的优化理论上不属于APP弱网络的优化，但是这个的API性能的问题，确实在网络条件不好的情况下才暴露无遗。大家都在谈论服务器的好坏，设备的性能高低，其实，对于一个良好的Server来说，绝大部分拖延请求速度的地方都是在IO上。包括，磁盘读写的IO，SQL查询的IO等等。常用的优化点：慢查询监控 、多次查询优化、常用接口cache等。
  2.图片相关策略。
  3.使用更快的图片格式，严格说也不算弱网下的优化，但一个更快的图片格式真的很重要!这里建议采用WebP格式。(WebP格式，谷歌(google)开发的一种旨在加快图片加载速度的图片格式。图片压缩体积大约只有JPEG的2/3，并能节省大量的服务器带宽资源和数据空间。但WebP是一种有损压缩。相较编码JPEG文件，编码同样质量的WebP文件需要占用更多的计算资源。)
  4.不同网络的不同图片下发。如(对于原图是600X480的图片)：2/3G使用低清晰度图片——>下发300X240，精度为80的图片、4G普通清晰度图片——>下发600X480，精度为80的图片、WiFi高清晰度图片(最好根据网速来判断，wifi也有慢的)——>下发600X480，精度为100的图片。
  5.断线重连。这可能是最重的一个特性，因为在无线网络中有太多的原因导致数据连接中断了。这里可以使用CDN。(CDN 是构建在数据网络上的一种分布式的内容分发网。 CDN 的作用是采用流媒体服务器集群技术，克服单机系统输出带宽及并发能力不足的缺点，可极大提升系统支持的并发流数目，减少或避免单点失效带来的不良影响。)
  6.由于创建连接是一个非常昂贵的操作，所以应尽量减少数据连接的创建次数，且在一次请求中应尽量以批量的方式执行任务。如果多次发送小数据包，应该尽量保证在2秒以内发送出去。在短时间内访问不同服务器时，尽可能地复用无线连接。
  7.优化DNS查询。应尽量减少DNS查询、避免域名劫持、DNS污染，同时把用户调度到“最优接入点”。
  8.减小数据包大小和优化包量。通过压缩、精简包头、消息合并等方式，来减小数据包大小和包量。
  9.控制数据包大小不超过1500，避免分片。包括逻辑链路控制(Logic Link Control)分片、GGSN分片，以及IP分片。其中，当数据包大小超出GGSN所允许的最大大小时，GGSN的处理方式有以下三种：分片、丢弃和拒绝。
  10.优化TCP socket参数，包括：是否关闭快速回收、初始RTO、初始拥塞窗口、socket缓存大小、Delay-ACK、Selective-ACK、TCP_CORK、拥塞算法(westwood/TLP/cubic)等。做这件事情的意义在于：由于2G/3G/4G/WIFI/公司内网等接入网络的QoS差异很大，所以不同网络下为了取得较好的服务质量，上述参数的取值差异可能会很大。
  11.优化ACK包。在弱网络的情况下，TCP协议中的ACK包是非常昂贵的，延时甚至能够达到秒级别，而TCP协议的拥塞控制、快速重传、快速恢复等特性都非常依赖接收端反馈的ACK包。可想而知，如果发送端接收到的ACK包延时太长，会严重影响TCP协议的效率。但是如果发送ACK太多又会占用宝贵过多的无线资源。在移动网络下通信，“在可靠的连接上，如何在减少ACK包的情况下，降低数据包的延时”是研究的热点。基本的思想：平衡冗余包和ACK包个数，达到降低延时，提高吞吐量的目的。例如SGSN和GGSN之间的通信实现：二者之间通过UDP协议通信，发送者在无新的数据包的情况下，每隔一定的时间重试已发送的包，达到最大重试次数后，则丢弃该包。
  12.TCP的拥塞控制算法是以“丢包意味着网络出现拥塞”为假设设计的，很明显这个假设在无线网络环境下是不合适的。但是在无线网络环境下，在设计可靠UDP协议时是否能够完全丢弃拥塞控制呢?这里有其它的文章中提出了几种在无线网络环境下的TCP友好的拥塞控制算法，有兴趣可以自行查阅。
  13.灵活使用长连接/短连接，支持不同协议(TCP/UDP, http、二进制协议等)，支持不同端口等。
  14.让用户觉得快。到这里已经不能算是技术层面的方法了，属于一种心理层面的博弈，一种改善用户体验的方式。比如：
    a.不从0开始的进度条。不管网页的加载进度如何，不管网络条件如何，加载进度始终是从50%起，并且停留在大约98%进度左右的地方。
    b.先显示文字在加载图片。同样是在Webview之中，图片或者多媒体的加载速度肯定是远远慢过文字的加载速度的。由于不同的webview显示和渲染效果不同，我们可以先让webview先显示文字，在显示图片。给用户一种可以先预览整个网页概况的感觉。

-- DNS问题及优化
 a.对于DNS的问题，有两条主要的解决思路：
  1.减少DNS的请求、查询、更新，也就是做DNS缓存;
  2.在终端配置server list，直接访问IP，不用DNS;

 b.但仅仅这么做还不够，因为用户可能来自国内外不同的运营商，还需要进一步优化调度策略：
  1.DNS缓存需要多建立接入点，用不同域名区分;
  2.IP列表需要更新以适应不同网络情况，要做到主动调度。好比最早我们只服务好移动用户就行，保证移动用户的接入质量优先，因为绝大多数用户集中在移动；现在国内有三个运营商，用户分布的比例在慢慢接近，要区分清楚；智能手机会用wifi，接入的是电信、联通还是哪个运营商，不知道，所以你不可能预先设置场景再if then，必须通过后台调度能力来解决。

 c.再进一步优化，就产生一种融合的方式：
  1.先做域名解析，客户端直接连接解析的IP，可以用http协议，也可以用tcp socket
  2.多端口、多协议组合：不同协议有不同的限制，有些只能http，有些只能tcp socket，各种环境都要适应，客户端不能只支持一种协议
  3.终端测速：接入点越来越多，接入哪个合适，要选择，可以通过终端测速来选择最快的。你当然可以每一次新建连接都做测速，但是这样建立连接时间可能会很长；我们可以给用户先建立连接后，在后台根据长期速度监控、当前测速的结果，来做动态调度。也就是说，第一次连接可能不是最优，连接建立后动态测速，再转移到最快接入点。更进一步就是建立网络profile，终端学习的思路。

-- Android 网络优化，使用 HTTPDNS 优化 DNS，从原理到 OkHttp 集成- https://www.jianshu.com/p/940be2e758ee
DNS 服务器的要求，一定是高可用、高并发和分布式的服务器。它被分为多个层次结构。
根 DNS 服务器：返回顶级域 DNS 服务器的 IP 地址。
顶级域 DNS 服务器：返回权威 DNS 服务器的 IP 地址。
权威 DNS 服务器：返回相应主机的 IP 地址。

 DNS 不仅支持 UDP，它还支持 TCP，但是大部分标准的 DNS 都是基于 UDP 与 DNS 服务器的 53 端口进行交互。
 HTTPDNS 则不同，顾名思义它是利用 HTTP 协议与 DNS 服务器的 80 端口进行交互。不走传统的 DNS 解析，从而绕过运营商的 LocalDNS 服务器，有效的防止了域名劫持，提高域名解析的效率。

想在 OkHttp 中使用 HTTPDNS，有两种方式。
通过拦截器，在发送请求之前，将域名替换为 IP 地址。
通过 OkHttp 提供的 .dns() 接口，配置 HTTPDNS。
class HTTPDNSInterceptor : Interceptor{
    override fun intercept(chain: Interceptor.Chain): Response {
        val originRequest = chain.request()
        val httpUrl = originRequest.url()

        val url = httpUrl.toString()
        val host = httpUrl.host()

        val hostIP = HttpDNS.getIpByHost(host)
        val builder = originRequest.newBuilder()

        if(hostIP!=null){
            builder.url(HttpDNS.getIpUrl(url,host,hostIP))
            builder.header("host",hostIP)
        }
        val newRequest = builder.build()
        val newResponse = chain.proceed(newRequest)
        return newResponse
    }
}

HTTPS 是为了保证安全的，在发送 HTTPS 请求之前，首先要进行 SSL/TLS  握手，握手的大致流程如下：
 客户端发起握手请求，携带随机数、支持算法列表等参数。
 服务端根据请求，选择合适的算法，下发公钥证书和随机数。
 客户端对服务端证书，进行校验，并发送随机数信息，该信息使用公钥加密。
 服务端通过私钥获取随机数信息。
 双方根据以上交互的信息，生成 Session Ticket，用作该连接后续数据传输的加密密钥。

在做 App 的网络优化的时候，第一步就是使用 HTTPDNS 优化 DNS 的步骤。
所有的优化当然是以最终效果为目的，这里提两条大厂公开的数据，对腾讯的产品，在接入 HTTPDNS 后，用户平均延迟下降超过 10%，访问失败率下降超过五分之一。而百度 App 的 Feed 业务，Android 劫持率由 0.25% 降低到 0.05%。

-- 协议参数优化，长期运营过程中总结的一些经验，在启动移动互联网服务时作为运营的规范，可以少走很多弯路：
 1.关闭TCP快速回收; 2.Init RTO不低于3秒
 3.初始拥塞控制窗口不小于10。因为大部分页面在10kB以下，很多请求在慢启动阶段已经结束，改为10可以降低小页面资源传输时延。内容越大，这个选项的效果就比较不明显;
 4.Socket buffer > 64k; 5.TCP滑动窗口可变; 6.控制发包大小在1400字节以下，避免分片;
-- 协议优化的原则总结下来是这么几条：
 1.连接重用; 2.并发连接控制; 3.超时控制; 4.包头精简; 5.内容压缩;
 6.选择更高效率的协议。无论是TCP、HTTP、UDP、长连接、GZIP、SPDY、WUP还是WebP，每一种协议、方案都有其道理，没有最优，只有是否适合你的产品和服务特点，需要大家在运营过程验证和取舍。

-- html的加速方式有很多种：
1.使用gulpgrunt进行打包压缩：jscss资源压缩，CSS Sprites合并等。
2.使用font-awesome替换图片：字体可以很好的兼容，无限放大，常用的图片都有

一秒钟法则：来自腾讯无线研发的经验分享- http://djt.qq.com/article/view/1130
  QQ手机浏览器从4.5版本、5.0版本到5.1版本，我们对2G网络下的连接时间、3G网络下的首字耗时、wifi网络下的首屏耗时进行持续监控，耗时降到一秒钟以下还在不断的改进，每个新的版本平均值均有所压缩。这个结果是从每天用户实际使用的运营数据中得到的，覆盖到绝大多数的手机终端和网络环境。不过平均值只是一方面，我们另一方面还要看“有多少比例的数据满足了一秒钟法则”这个维度，因为无线网络的长尾数据波动很大，这一个维度也非常重要。目前现状是我们2G网络做到79%，3G网络做到73%，wifi网络做到69%。目前我们的目标是达到80%，实现之后，再进一步挑战90%的比例，不断追求极致。
  -- 总结的一秒钟法则：在一秒内要完成的规定动作：
 1.2g网络：1秒内完成dns查询、和后台服务器建立连接
 2.3g网络：1秒内完成首字显示(首字时间)
 3.wifi网络：1秒内完成首屏显示(首屏时间)
这些指标需要在终端度量，必须跟用户体验相关：首字时间、首屏时间都必须是用户可以直观感受到的。

APP弱网络条件下，体验优化之道- https://zhuanlan.zhihu.com/p/21615263
APP弱网络条件下，体验优化之道- https://blog.csdn.net/yzzst/article/details/51764909
  所谓的弱网络，也就是指在网络不好的条件下进行使用APP，如2G、3G网络，这类网络条件下，用户的网络速度基本维持在10K/S~60K/S。如此差的网络环境， 如果还希望给用户提供良好的用户体验，那么我们的APP就该想想如何优化了。

-- 弱网与缓存（文字、图片缓存，缓存清理等）
App缓存管理- http://blog.csdn.net/wuqingyidongren/article/details/51188822
  - 缓存带来的好处：
1. 服务器的压力大大减小
2. 客户端的响应速度大大变快(用户体验)
3. 客户端的数据加载出错情况大大较少，大大提高了应有的稳定性(用户体验)
4. 一定程度上可以支持离线浏览(或者说为离线浏览提供了技术支持)

两种比较常见的缓存管理方法是:数据库法和文件法。不变文件的缓存时间是永久，变化文件的缓存时间是最大忍受不变时间。
- 不同环境下的缓存时间标准不一样：
 1.无网络环境下，我们只能读取缓存文件，哪怕缓存早就过期。
 2.WiFi网络环境下，缓存时间可以设置短一点，一是网速较快，而是流量不要钱。
 3.移动数据流量环境下，缓存时间可以设置长一点，节省流量，就是节省金钱，而且用户体验也更好。
举个例子吧，应用在wifi环境下的缓存时间设置为5分钟，移动数据流量下的缓存时间设置为1小时。