事情要从测试妹妹开始
突然有个周四的下午,测试小妹妹蹦蹦跳跳的跑过来反馈,某些图片资源打不开了, 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
的要求完整输出本应该输出的内容长度 的原因。
测试小妹妹
"运维哥哥真厉害~"
故事的结束
今天的故事讲完了,如果你有兴趣,欢迎关注我的社交账号,交个朋友。