以下仅为个人猜想，部分设计的知识点本人并没有掌握，仅仅只是发表一个理论上可能实现的东西
本贴想要讨论的是极限压缩后再实现压缩（即本身已经无法通过现有的任何压缩算法减小体积）
如果这种都要喷，请您滚
与其说是奇思妙想不若说是异想天开！
先说说压缩吧，压缩的原理是将重复的N个字节X缩短为NX来达到缩短信息长度却不损失信息的效果！
但是这个很明显在一个极限后就无法压缩了，那就是当信息基本无重复的字节的时候，压缩算法就会失效！
那么有没有可能实现无序信息的压缩呢，即在不损失信息的情况下缩短信息长度
在下提出这么一个想法！
首先创建256个字典，每个字典长度为256！每个字典的元素为0-255的两两组合！0-255的全部组合刚好是65536个！
256个256长度的字典刚好包含他的全部组合！
以下是网络TCP传输时的实现（仅为假设，本人对TCP这个并不熟悉，仅为举例，我想表达的是这个理论压缩实现，而非TCP这个）：
第一步：同时打开256个TCP链接！并且它们各自都有一个标识符号！代表0-255，分别代表他们所指向的字典
第二步：准备发送数据！先将原始数据分割为两个字节为一个元素的数组！然后去找到他们所在的字典序号与所在字典内的索引！
第三步：发送数据，按先后顺序把字节通过元素所在字典序号的TCP链接发送其所在的字典索引！
第四步：接受数据，接收者收到数据后根据收到的索引与接受数据的TCP链接代表的字典序号将其重新转化为两个字节的元素！
如此可以达到用一个字节来传输两个字节的效果！
这样的话 1G/s的宽带就传输2G/s的内容了！
同理，只要增加同时的链接数，就可以无限提高效率，例如直接65536个链接！1个字节直接代表4个字节~
但是会有问题存在！
那就是但是接收数据很难高效的判断先后顺序，特别是大流量，高延迟时，达到的先后顺序很有可能出错~
理论上来说这个方案是可以实现的。但是实用性与可靠性就需要实际测试了~
以下是文件压缩的实现：
一，首先创建256个文件，每个文件代表其所属的字典！
二，将两个字节转化为字典与索引的形式！
三，将索引写入字典
这里还原时会有一个难点，那就是怎样判断写入顺序？
所以文件压缩的实现可能很难实现吧
-----------------------------------------------------
**网友回复**:
引用:h20发表于2020-11-2711:51
你这是来搞笑的吗？
文件压缩算法本身就是建立在字典的基础上的
网友回复:
你这是来搞笑的吗？
主流文件压缩算法本身就是建立在字典的基础上的，网络传输一般使用流式压缩算法
另外TCP本身就是可靠的连接，你要分片请使用UDP，人家已经给你做好了
网友回复:
引用:adminii发表于2020-11-2712:00
弱弱问一句，我先本地压缩完成再发送？或者边压边送有什么区别？
网友回复:
弱弱问一句，我先本地压缩完成再发送？或者边压边送有什么区别？
网友回复:
同時打開256個tcp連結，意味著需要256個端口。你這個做法只是把一部分資訊轉移到端口號上面去了。別忘了網路封包，端口號佔了2個字節...
网友回复:
引用:s920361发表于2020-11-2712:08
同時打開256個tcp連結，意味著需要256個端口。你這個做法只是把一部分資訊轉移到端口號上面去了。別忘了網...
网友回复:
想法是好想法，实现不了，因为还要考虑字节的顺序。以及每个封包的大小及发送一个封包的overhead.
网友回复:
基于π是无限不循环小数，那么π的中间某段是否就包含一组完整信息呢？比如π[5854855589786:955367435677437]可能就是一部电影的十进制文件，所以只要两台电脑算力无限大或者足够强就能把一个电影压缩成几十个字节？
网友回复:
引用:jhu发表于2020-11-2712:16
想法是好想法，实现不了，因为还要考虑字节的顺序。以及每个封包的大小及发送一个封包的overhead....
网友回复:
引用:s920361发表于2020-11-2713:08
我覺得也不算。
就算是最理想的情況，完全沒有握手開銷啥的，封包抵達順序也都剛好有序，沒有亂掉