Appetizer APP 精细化 HTTP 分析 (二):响应性能分析与优化

appetizer.io for AppetizerIO · 发布于 2017年08月29日 · 216 次阅读

前排:正文中获取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 StartRequest SentWaiting,其中主要是来回的网络延时(俗称服务器ping值)和服务器处理时间
  • Transmission TimeContent Download,主要是服务器下行带宽

Latency 长为什么,怎么办

Latency 长主要是因为网络延时(服务器ping值)长或者服务器处理这个接口时间太久,以Appetizer官网为例,这个网站 评测了不同地区对Appetizer服务器的ping值:

这个主要是后台运营的问题,解决方法有:

  • 考虑合适的云服务以及服务器分布,对部分关切地区加服务器(广告位招租)
  • 如果云服务/自建服务器的ping值高,那么建议对部分经常访问的静态内容做CDN加速
  • 考虑是否可以对静态内容cache在APP端,见 okhttp APP端cache教程

此外,如果服务器处理时间长,通常就是服务端处理这个接口的响应速度太慢,这个应该交给服务端的同学,通常有以下常见问题:

Transmission Time 长为什么,怎么办

Transmission Time,主要就是APP下载服务端的Response Header和Response Body时间,如果比较慢可以考虑如下问题:

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册