关于mitmproxy截数据导致客户端响应被阻塞的问题

近期使用ffmpeg做android播放器, 来播放服务器端的mp4文件, 开发过程中习惯性的打开了mitmproxy来监控http数据包.

经过了几天的各种铺垫架设, 一切事情似乎都很顺利, 测试用的小视频文件在自己的播放器上一切正常. 又开始觉得自己牛逼了, 实现个自己的播放器也没有什么大不了啊. 然而, 悲剧总在天晴后:
无意中播放一个400M的视频文件时, 发现卡在loading界面要等待9秒后才开始播放, 看起来好像是ffmpeg在等待数据或是在分析数据, 黑灯瞎火, 束手无策, 只能再度进入暗黑模式啃代码了.

把ffmpeg的http数据接收部分代码看了个大概, 最后定位到poll一直在等待socket事件. 这就奇怪了, 为何要poll 9秒钟呢? 服务器干什么去了?
又把nginx的发送数据部分代码分析了个大概, 数据发送时该发送的马上就丢出去了啊, 到底是哪里没有搞清楚呢? 百思不得姐, 抓狂!!! 只得老牛反刍继续磨nginx的代码…

搞了3天有余, 想着用wireshark抓一下tcp包看看, 到底网络在磨叽什么东西, 如果实在不行是不是该开涮内核socket处理部分代码了. 结果, 万万想不到的是, 一打开播放器马上就秒播视频文件了. 居然就秒播了啊…
重复了好几次, 反复把mitmproxy给加上又断开, 果断的就是被mitmproxy给卡住了. 尼玛, 花了3天多的时间, 居然就是因为视频数据被代理服务器给截住了. 估计mitmproxy是为了分析协议, 它要把整个http数据包缓存下来后才传给接收端.

因为一直喜欢mitmproxy的分析http包的简单界面, 才舍不得使用wireshark, 没想到简单总被简单误, 出来混总是要还的…
写出来, 希望看到我这个提醒的同志, 不要再在这里栽跟头了.