很无语,就这么个问题反反复复排查了一个月?

事情要从测试妹妹开始

突然有个周四的下午,测试小妹妹蹦蹦跳跳的跑过来反馈,某些图片资源打不开了, 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 的要求完整输出本应该输出的内容长度 的原因。

测试小妹妹

"运维哥哥真厉害~"

故事的结束

今天的故事讲完了,如果你有兴趣,欢迎关注我的社交账号,交个朋友。

GithubGitee

相关推荐
IC 见路不走7 分钟前
LeetCode 第91题:解码方法
linux·运维·服务器
没有名字的小羊16 分钟前
8.Docker镜像讲解
运维·docker·容器·tomcat
翻滚吧键盘20 分钟前
查看linux中steam游戏的兼容性
linux·运维·游戏
Code季风32 分钟前
深入理解微服务中的服务注册与发现(Consul)
java·运维·微服务·zookeeper·架构·go·consul
java1234_小锋34 分钟前
解释一下NGINX的反向代理和正向代理的区别?
运维·nginx
汀沿河39 分钟前
8.1 prefix Tunning与Prompt Tunning模型微调方法
linux·运维·服务器·人工智能
zly35001 小时前
centos7 ping127.0.0.1不通
linux·运维·服务器
m0_653031362 小时前
腾讯云认证考试报名 - TDSQL数据库交付运维专家(TCCE MySQL版)
运维·数据库·腾讯云
biass3 小时前
jenkins角色权限
运维·jenkins
tomorrow.hello3 小时前
Jenkins Pipeline(二)
运维·jenkins