事情要从测试妹妹开始
突然有个周四的下午，测试小妹妹蹦蹦跳跳的跑过来反馈，某些图片资源打不开了， Chrome直接访问图片的地址全是空白。
第一次排查问题
接到问题之后，随机复制几个图片的 URL 到 Chrome 中测试， 发现确实都是白屏状态， 于是查看 NetWork，返回全是 200 状态码， 照理来说， 应该能正常访问才对。
这里很尴尬的是，因为测试服务器是测试自行部署的，没有部署一些监控和告警服务。
于是运维的同学开始登录服务器，导出了后端同学需要的所有日志文件给到后端的同学自己分析，然后下班了。
后端同事排查到凌晨三点，还是没有找到问题。
解决问题
第二天上班后，后端的同学跟运维说，"要不你重启一下测试服务器吧～"
测试小妹妹："咦，好了耶！"
第二次出问题
一个月后，测试小妹妹又反馈了，图片又又又又又打不开了～。
运维的同学表示，"不正常，一点都不正常！"
于是职业习惯性的在 shell 中敲了
df -h
？？？！！！
排查发现被后端的同事打测试的日志把磁盘打满了。
直接把没用的日志删了，就正常了，你说气不气。
上次重启服务器，缓存文件没了空间多了，又挺了一个月，你说气不气。
问题原因追溯
非4xx/5xx， 说明服务器和浏览器都没有问题， 查了下
ERR_HTTP2_PROTOCOL_ERROR的解释， 都在说http2的配置有问题， 但能确定的是， 测试服务器已经很久没有人登上去过了。
然后复制图片地址到 命令行中 curl， 发现了猫腻：
ok, 继续搜索 HTTP/2 stream 0 was not closed cleanly 相关的问题， 没找到答案。
运维小哥盲猜后给出了一个结论：
服务响应的 HTTP 请求头的
content-length承诺的输出字节数 与 实际输出的内容长度 不一致，导致触发了 MITM 的安全策略。然后磁盘被打满了，就是造成 没法按照
content-length的要求完整输出本应该输出的内容长度 的原因。
测试小妹妹
"运维哥哥真厉害～"
故事的结束
今天的故事讲完了，如果你有兴趣，欢迎关注我的社交账号，交个朋友。