基于元信息写入的服务器压力测试
什么是元信息？
就是写入在文件二进制中，一般情况下正常打开看不到的信息。
更多详细答案请自行搜索，无论哪种方案肯定都比我说的详细
今天我想说的时这个东西：
基于元信息写入的服务器压力测试
很Boring的一个东西，不是吗？😛
其实测试的本质就是EXIFtool，FFmpeg往文件里面写入元信息，但当数据量上来以后，将足够跑满整台服务器
适用于以下场景：
某天收到某些不可抗力的某些不明要求，要求你的文件写入特定标识的元信息，表明这个文件是你提供的。
你需要出一些比较奇怪的CTF MISC题目，存在需要同时大量写入元信息的情况
除此之外我也想不到有什么应用场景了😂
关于如何使用的信息已经写在Readme里了，需要的话自取
一个图像/视频能写入多少元信息？
PNG 无理论上限
JPG 无理论上限
MP3
- ID3v1: 这是最老的ID3标签版本，它在MP3文件的末尾固定占用128字节。ID3v1标签包含诸如曲目名称、艺术家、专辑、年份、流派和注释等基本信息，但由于空间非常有限，每个字段的长度都受到了严格限制，例如曲目名称和艺术家名称字段各限制为30个字符。
- ID3v2: 理论上ID3v2标签的大小仅受限于文件系统对文件大小的限制
MP4： 无理论上限
MOV：无理论上限
需要指出，过量的元数据会影响播放器的播放视频的性能
但是实际上，写入的元信息量会受限于系统命令行允许的最大长度，否则就会收到无情的OSError: [Errno 7] Argument list too long
听起来很不靠谱?😂但如果用ExifTool和FFmpeg你就会遇到这样的问题，差不多也就些个200KB就顶天了
遇到这种情况，只能你自己写程序绕过
可以看到我仓库里的PNG就是使用Python写入，通过这种方式，你就可以获得一个100M大小的，720P分辨率PNG图片🤣
Note：为了做这个测试，我踩了一个Python关于循环的坑😅，可以看看仓库里的LargeTextGeneration.py，试试看用循环写入会发生什么事情
你会收获一个大O为指数增长的运行时间
插入元信息是否有什么技术力要求？
约等于无，PhotoShop，GIMP这类软件都可以编辑
结语
今天就写到这里，上班就是这点不太好，有些奇怪的想法需要回家才能实现😛