记一次http请求页面卡死问题排查过程
问题：开发和生产上线的代码一样，但是不通环境的页面请求响应时间差别很大（生产正常，开发普通接口正常，但是开发环境上只要是文件上传就会页面卡顿很久，生产是好的）。开始是让后端排查问题，没有发现可疑地方，领导让前端配合定位一下问题，通过Chrome的network发现请求Stalled竟然达到了恐怖的2min。
请求描述：前端上传文件前期是和表单字段一起提交，使用的FormData形式，后期搭建了文件服务器，表单和文件上传是分开的，此次解决的API都是FormData形式的提交。
Chrome浏览器查看请求时间分布
Chrome浏览器Console中自带的Network可以查看http请求相关的东西，点开一个请求会有4个选项：Headers，Preview，Response，Timing，其中Timing标签下就是请求整个用时分段展示：
- Queueing
- Stalled
- Request sent
- Waiting（TTFB）
- Content Download
Queueing是在HTTP1.0版本下Chrome浏览器默认对同一个域名同时支持6个并发，如果超过这个限制就会阻塞最近的请求等待有用连接释放，不同浏览器限制不通，大致在2-8之间，HTTP2.0是没有这种限制的；Stalled就是在等待Queueing的时间；Request sent是请求开始发送，这个时间一般都在1ms之内；Waiting就是请求发出后直到服务器返回第一个字节为止的时间，这个时间越短越好，Chrome官方文档上建议这个时间应该控制在300ms以内。
看到这结合实际出现的场景，理所当然的把问题定位在了并发连接问题上，但是理性分析一波，用户在本地单操作，不会存在超过6个并发限制的操作，而且从Time Line上并没有发现这一阻塞情况。经过多次反复测试，发现这个阻塞时间有时在stalled，有时在sent上，这时候要是能看到请求的具体分段时间就可以很容易定位问题所在。
Chrome浏览器官方插件提取请求具体时间文件
照着官方文档步骤获取一次file上传请求的时间提取文件，然后打开文档中提到的文件分析在线地址，导入刚才的文件进行查看，直接点击左侧菜单中的Events选项进去可以看到刚才的请求，点选请求后在右侧可以查看具体的过程：
- t=19381
- [st = 0]
- [dt = 31005]
时间单位时ms，第一列应该是绝对时间，也就是当前时间戳，第二列就是这个请求到每个阶段所花时间的累积，第三列是第二列的反向记录。
同时提取生产和开发环境的同一个的file上传请求，对两个文件进行对比分析法下，请求过程中都没有出错，上传文件大小一样，开始发送请求之前的时间差距在100ms之内，请求返回开发是300ms，生产是30ms，这也没有太大差距，但是开发完成整个请求花费31s，而正式只需要1s，只要差距就在HTTP_TRANSACTION_SEND_REQUEST_BODY（UPLOAD_DATA_STREAM_READ）这个动作上，同样的文件，都是在本地测试，代码一样，不同的是服务器，所以定位到是开发服务器带宽和性能问题。