前排：正文中获取APP端所有HTTP请求的方法请参考 APP精细化HTTP分析（一）：别再只是代理抓个包了
上篇讲到接口错误代码，这次说到响应性能，首先需要仔细了解一下HTTP请求响应的过程。一次完整的请求响应过程有这么几个过程：[连接建立过程]
-> 发送 Request Header -> [发送 Request Body] -> 等待 Response Header -> [下载 Response Body]
其中 []是可选的，其中连接建立我们不会过多涉及，一般是DNS和TCP三次握手，如果已经连接（比如连续向同一个服务器发多个http请求）则不会有这个过程。 Request
Header包括了请求的方法，就是我们常说的GET、POST；请求URL；还有一堆Headers；可选的有一个 Request
Body，比如一个 POST 请求的表单内容就是存在 Request
Body 里，或者上传的文件也会放在 Request
Body。
服务器收到这个Request，就会进行处理，最终给APP一个Response （header + 可选body）；Response Header包括状态码（如200/404/500），一般4xx表示APP请求错误，5xx表示服务端错误；Response Header也是一堆，其中比较重要的的有：
- Content-Length: Response Body的长度
- Content-Type: Response Body的 MIME类型，可以依此判断 Response body的文件类型
- Cache-Control: 缓存控制信息，告诉APP端如何缓存该请求
所以一个HTTP请求的耗时其实并不是一个整体，而是可以划分为多个阶段。以appetizer.io首页为例，利用Chrome开发者工具中的Network查看请求用时。
其中 Resource
Scheduling 是浏览器的事情，APP端没有； Connection
Start 就是连接过程，值得注意的是 Request/Response，分为三段：1. Request
Sent: APP发送Request Header + Body的时间；2. Waiting （学名TTFB，Time To First Byte）：指APP接收到Response第一个字节的时间，一般包括服务器处理时间以及来回的网络延时； 3. Content Download：就是APP下载完Response Header和Body的总共时间；
Appetizer依此抽象了两个概念：
-
Latency包括Connection Start，Request Sent和Waiting，其中主要是来回的网络延时（俗称服务器ping值）和服务器处理时间 -
Transmission Time即Content Download，主要是服务器下行带宽
Latency 长为什么，怎么办
Latency 长主要是因为网络延时（服务器ping值）长或者服务器处理这个接口时间太久，以Appetizer官网为例，这个网站评测了不同地区对Appetizer服务器的ping值：
这个主要是后台运营的问题，解决方法有：
- 考虑合适的云服务以及服务器分布，对部分关切地区加服务器（广告位招租）
- 如果云服务/自建服务器的ping值高，那么建议对部分经常访问的静态内容做CDN加速
- 考虑是否可以对静态内容cache在APP端，见 okhttp APP端cache教程
此外，如果服务器处理时间长，通常就是服务端处理这个接口的响应速度太慢，这个应该交给服务端的同学，通常有以下常见问题：
- 服务端是否对Session有合适的cache，比如一个已经登录的用户是否服务器已经cache需要的信息在内存 Express性能调优
-
如果这个接口主要是数据库操作，那么是否对相关的表进行了indexing操作
MongoDb indexing
MySQL vs TiDb
MySQL慢查询优化 -
如果这个接口访问的是非常通用的内容（比如当天最热销的商品列表），服务端是否使用了in-memory caching，例如memcached之类的服务？
Redis/Memcache做MySQL caching
Redis vs. Memcache
Transmission Time 长为什么，怎么办
Transmission Time，主要就是APP下载服务端的Response Header和Response Body时间，如果比较慢可以考虑如下问题：
-
这个接口是否返回了比较大的Response Body（比如图片, html，JSON），是否考虑将返回内容压缩一下
什么时候要gzip 响应数据 -
这个接口如果是返回查询内容，是否考虑增加一个批量查询功能