基于元信息写入的服务器压力测试

什么是元信息？

就是写入在文件二进制中，一般情况下正常打开看不到的信息。

更多详细答案请自行搜索，无论哪种方案肯定都比我说的详细

今天我想说的时这个东西：

很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为指数增长的运行时间~~