 云 知道  大家一般来说对于HTTP接口的理解就是一去一回，然后总体有一个耗时，但是实际上其中是有很多的步骤的，这些步骤的详细耗时从一定意义上来说，是有助于分析接口耗时原因的，比如到底是网络耗时，还是服务器处理慢，还是其他的原因导致的。通过耗时能进一步的发现性能瓶颈和优化方向。 先来一张HTTP实际在网络中交互的步骤图  这也是我们之前提到过的HTTP通信过程的内容 传送门 抓包只能得到传输的数据内容，那么通过哪些方式可以得到更细节的耗时呢？ 最简单的方式就是靠浏览器本身了，当然这需要开发者工具的支持  l Chrome自带的开发者工具（F12）   l Firefox自带的开发者工具（F12）   l Firefox也可以安装Firebug进行  但是这样只能对那些在浏览器上能打开的网页进行，如果需要对外部非浏览器的耗时监控就需要使用其他的专业抓包工具，比如WireShark，但这个工具的缺点是，只有时间点，需要自己一个个去计算时长。我们这里推荐使用Fiddler，专业对HTTP协议进行抓包分析。  知道怎么看了，我们就能来找原因了 1. DNS Lookup 域名解析耗时，一般都应该很短，小于20ms，内网的DNS服务器应该更小，如果耗时大了就需要考虑更换DNS服务器，如果无法解决，可以考虑直接做HOST来手动解析。 2.TCP Connect 连接握手耗时，只有在新建连接的时候会产生，否则为0，如果相对耗时较大，且单独访问都经常耗时很大，那么问题基本在于网络线路，但如果是在大量访问下耗时较大，那么说明服务器或者中间网络设备无法应对，可能连接池已用完或者无法处理。 3.Request Send iddlerBeginRequest→ServerGotRequest 发送数据耗时，TCP独有，数据发送到对方后会有一个自动空响应，所以可以计算耗时，如果发送内容不是太大，但耗时较大，那么基本可以定性为网络问题，但一些特殊的协议如果可以多次不断的发送数据而不等待服务器响应，那么也有可能是Socket接收数据的缓冲区已满，遭遇排队。 4.Wait Response ServerGotReques→ServerBeginResponse 响应等待耗时，也就是从发送完成后，到服务器响应第1个字消耗的时间，如果网络没有问题，那么这将是服务器处理接口数据的精确耗时。 5.Response Receive ServerBeginResponse→GotResponseHeaders→ServerDoneResponse 响应接收耗时，这个耗时只是接收数据传输和读取的耗时，已经不是服务器的处理耗时范围了，信息量越大，耗时也一定越长。 所 以说精确的耗时定位，对于很多情况下都是可以分析出更精准的问题，而不能单单靠一个请求总体耗时来看待一切，这会让你怀疑太多的内容，导致毫无方向甚至找错方向。 云知道 专业知识分享平台 |
|
|
来自： 飞翔羽翼j91cbz > 《接口测试》
