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

事情要从测试妹妹开始

突然有个周四的下午,测试小妹妹蹦蹦跳跳的跑过来反馈,某些图片资源打不开了, 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

相关推荐
Clain2 分钟前
在多机运维过程中,最容易踩的几个坑
linux·运维·服务器
DARLING Zero two♡12 分钟前
【Linux操作系统】简学深悟启示录:Linux环境基础开发工具使用
linux·运维·服务器
程序员JerrySUN19 分钟前
Linux内核驱动开发核心问题全解
linux·运维·驱动开发
EulerBlind25 分钟前
【运维】HuggingFace缓存目录结构详解
运维·深度学习
幻雨様1 小时前
UE5多人MOBA+GAS 30、技能升级机制
运维·服务器·ue5
love530love2 小时前
Windows 11 下 Anaconda 命令修复指南及常见问题解决
运维·ide·人工智能·windows·python·架构·conda
(Charon)3 小时前
【C语言网络编程基础】TCP并发网络编程:io多路复用
运维·服务器
zc-code3 小时前
HTTP性能优化实战:从协议到工具的全面加速指南
网络·网络协议·http·缓存·性能优化·html
字节高级特工4 小时前
【Linux篇】进程间通信:进程IPC
linux·运维·服务器
随风fraya5 小时前
<七> CentOS 8 安装最新版本Docker
运维·docker·容器