[奇思妙想] 网络传输中的乱序压缩实现？

[8520ccc]

以下仅为个人猜想，部分设计的知识点本人并没有掌握，仅仅只是发表一个理论上可能实现的东西

本贴想要讨论的是极限压缩后再实现压缩（即本身已经无法通过现有的任何压缩算法减小体积）

与其说是奇思妙想不若说是异想天开！欢迎各位指正~

先说说压缩吧，压缩的原理是将重复的 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 个文件，每个文件代表其所属的字典！ 二，将两个字节转化为字典与索引的形式！ 三，将索引写入字典

这里还原时会有一个难点，那就是怎样判断写入顺序？

所以文件压缩的实现可能很难实现吧

[Lax]

即使不是大流量高延时，到达顺序也保证不了。而且你这里的传输开销很大，每两个字节就要一个 TCP 报头，流量会高于现在 TCP 实现

[shyrock]

兄弟，你的索引数据长度也是 2 个字节。。。哪里压缩了。。。
既然要压缩数据，建议先了解一下香农的《通信的数学原理》中信息熵的定义。

[TransAM]

你那个是文本的压缩原理。图像的压缩主要是函数变换。

[rekulas]

tcp 概念是多余的， 延迟流量顺序等概念都可以去掉干扰信息， 你这个设想基本原理就是索引查找内容，用在固定内容上面没有问题，但用在不限定内容内容上就无法实现了，如同二楼所说，你无法让索引的总数小于内容的总变化数(如果可以的话，信息就可以无限压缩很明显这是错的)

我觉得更现实的方法是, 你用一台超算找到 2 个数让他们的除小数部分 0 开始的值刚好包含你的数据，这样你只需要发送 2 个数加长度就可以发送几百 G 的数据了，可能更靠谱 - -

[nanometer]

且不说别的，TCP 包头就 8 个字节，也就说，以你的方式，每发送 2 个字节的信息，就需要发送 10 个 byte 。好样的！

[no1xsyzy]

这也能民科？

[no1xsyzy]

开 256 个 SRC-IP 和 DST-IP 相同的链接，就意味着你需要 256 个不同的端口号，同时你还需要每次发送这个端口号。

[est]

楼主这想法怕不是受了 Pi 的小数后面包含了所有信息的启发。你只需要记住是从第几位开始多少长度就行了。说不定 Pi 从第 m 位到 第 n 位包含了一部 GBK 编码的《金瓶梅.txt 》呢。

[kop1989]

这不就是我先给你买本书，然后把我想说的压缩成：第五页第二段+第十页第一段。
这个完全没有现实意义啊。
1 、你这本书（字典）要提前传递。
2 、要包括所有可能的排列组合。
这就像是，我为了把一封信压缩到短信里（ 70 个字），先给你物流了一座图书馆。

[TtTtTtT]

楼主说的挺好的呀，只不过现在越来越不倾向于这么做了。
过去一根线一个用途，现在一根线上跑所有数据。
这样能够有效降低你所说的研发成本和运维成本，而实际上压缩率没有你想象的那么重要。

[8520ccc]

@kop1989 有所不同 一个字节代表两个字节时其实根本不需要字典，因为每个字节本身就是 256 个可能直接通过序号代表第一个字节就行了，发送的代表第二个字节。。。。当

[8520ccc]

@TtTtTtT 确实没那么重要吧 我就是灵光一现想看看能否实现罢了 脑袋中总会徘徊这个问题~纯粹是想看看这个问题是否可能有解而已~

[8520ccc]

@est 完全不同 但是我想过你说的这种

[8520ccc]

@no1xsyzy 这不算名科啥的吧 有想法畅所欲言有何不可？我只是有一个想法，分享出来大家一起讨论而已，我也没说自己是对的，我开头也说了仅仅是我的理论上可行的可能而已，你没必要来这里来显示你多有文化吧？

[8520ccc]

@shyrock 索引长度是一个字节啊，索引最长就是 255 最小为 0 一个字节刚好能表示他的所有可能，或者换一种说法用链接序号做第一个字节，用发送的字节做第二个字节！

[8520ccc]

@rekulas 其实不必引入索引这个说法，直接用链接序号做第一个字节用发送的哪个字节做第二个字节就行了

[8520ccc]

@Lax 嗯纯粹一个想法 想发出来大家讨论而已

[8520ccc]

@rekulas 你的这个想法不错的~

[kop1989]

@8520ccc #11 我理解你的意思，你的意思是说，可以用一些传输过程中的、或者收发者理应同时持有的客观信息来当作传递数据的一部分。在你的例子中你利用了“通道数量”和“顺序”这两个额外属性来传递信息。

但你要反过来思考，提供额外的连接和保证顺序，这不也是一种“字典”么，只不过你忽略了创建，或者说传递这个“字典”的成本而已。

换句话说，你为了压缩狭义的数据量，增加了广义的数据量（而且总体上而言还是信息量增加的）。

[XiaoxiaoPu]

如果不同端口是共用相同的物理信道（例如在 TCP 构建在 IP 之上，IP 构建在以太网之上），那么为了区分不同端口，传输层必然引入额外的信令来标识端口，你所谓的只传输一个字节，在物理信道上仍然要占用两个字节。
如果不同端口是独立的物理信道，那相当于用 256 倍物理信道，实现 2 倍物理信道的带宽，效率只有原本的 1/128，低到令人发指。