前排：正文中获取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也是一堆，其中比较重要的的有：
所以一个HTTP请求的耗时其实并不是一个整体，而是可以划分为多个阶段。以appetizer.io首页为例，利用Chrome开发者工具中的Network查看请求用时。
https://testerhome.com/uploads/photo/2017/f66c4e1d-fe36-4f58-bf67-fea095ca3472.png!large
其中 Resource Scheduling 是浏览器的事情，APP端没有； Connection Start 就是连接过程，值得注意的是 [Request/Response](<https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#timing>)，分为三段：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，主要是服务器下行带宽https://testerhome.com/uploads/photo/2017/1def14bf-8e14-4361-abc7-d73949e4b50d.png!large
Latency 长主要是因为网络延时（服务器ping值）长或者服务器处理这个接口时间太久，以Appetizer官网为例，这个网站评测了不同地区对Appetizer服务器的ping值：
https://testerhome.com/uploads/photo/2017/fc8efb1c-8997-47b3-8506-39fe7cbbb254.png!large
这个主要是后台运营的问题，解决方法有：
