这是一个创建于 1784 天前的主题，其中的信息可能已经有所发展或是发生改变。
以下仅为个人猜想，部分设计的知识点本人并没有掌握，仅仅只是发表一个理论上可能实现的东西
本贴想要讨论的是极限压缩后再实现压缩（即本身已经无法通过现有的任何压缩算法减小体积）
与其说是奇思妙想不若说是异想天开！欢迎各位指正~
先说说压缩吧，压缩的原理是将重复的 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 个文件，每个文件代表其所属的字典！ 二，将两个字节转化为字典与索引的形式！ 三，将索引写入字典
这里还原时会有一个难点，那就是怎样判断写入顺序？
所以文件压缩的实现可能很难实现吧
 | 1 Lax 2020-11-27 12:29:25 +08:00 即使不是大流量高延时，到达顺序也保证不了。而且你这里的传输开销很大，每两个字节就要一个 TCP 报头，流量会高于现在 TCP 实现 |
 | 2 shyrock 2020-11-27 12:52:23 +08:00 兄弟，你的索引数据长度也是 2 个字节。。。哪里压缩了。。。 既然要压缩数据，建议先了解一下香农的《通信的数学原理》中信息熵的定义。 |
 | 3 TransAM 2020-11-27 13:00:37 +08:00 via Android 你那个是文本的压缩原理。图像的压缩主要是函数变换。 |
 | 4 rekulas 2020-11-27 13:06:14 +08:00 tcp 概念是多余的， 延迟流量顺序等概念都可以去掉干扰信息， 你这个设想基本原理就是索引查找内容，用在固定内容上面没有问题，但用在不限定内容内容上就无法实现了，如同二楼所说，你无法让索引的总数小于内容的总变化数(如果可以的话，信息就可以无限压缩很明显这是错的) 我觉得更现实的方法是, 你用一台超算找到 2 个数让他们的除小数部分 0 开始的值刚好包含你的数据，这样你只需要发送 2 个数加长度就可以发送几百 G 的数据了，可能更靠谱 - - |
 | 5 nanometer 2020-11-27 13:11:11 +08:00 且不说别的，TCP 包头就 8 个字节，也就说，以你的方式，每发送 2 个字节的信息，就需要发送 10 个 byte 。好样的！ |
 | 6 no1xsyzy 2020-11-27 13:18:19 +08:00 这也能民科？ |
| 7 no1xsyzy 2020-11-27 13:20:52 +08:00 开 256 个 SRC-IP 和 DST-IP 相同的链接，就意味着你需要 256 个不同的端口号，同时你还需要每次发送这个端口号。 |
 | 8 est 2020-11-27 13:51:47 +08:00 楼主这想法怕不是受了 Pi 的小数后面包含了所有信息的启发。你只需要记住是从第几位开始多少长度就行了。说不定 Pi 从第 m 位到 第 n 位包含了一部 GBK 编码的《金瓶梅.txt 》呢。 |
 | 9 kop1989 2020-11-27 14:02:43 +08:00 这不就是我先给你买本书，然后把我想说的压缩成：第五页第二段+第十页第一段。 这个完全没有现实意义啊。 1 、你这本书（字典）要提前传递。 2 、要包括所有可能的排列组合。 这就像是，我为了把一封信压缩到短信里（ 70 个字），先给你物流了一座图书馆。 |
 | 10 TtTtTtT 2020-11-27 14:08:42 +08:00 楼主说的挺好的呀，只不过现在越来越不倾向于这么做了。 过去一根线一个用途，现在一根线上跑所有数据。 这样能够有效降低你所说的研发成本和运维成本，而实际上压缩率没有你想象的那么重要。 |
 | 11 8520ccc OP @kop1989 有所不同 一个字节代表两个字节时其实根本不需要字典，因为每个字节本身就是 256 个可能直接通过序号代表第一个字节就行了，发送的代表第二个字节。。。。当 |
| 12 8520ccc OP @TtTtTtT 确实没那么重要吧 我就是灵光一现想看看能否实现罢了 脑袋中总会徘徊这个问题~纯粹是想看看这个问题是否可能有解而已~ |
| 14 8520ccc OP @no1xsyzy 这不算名科啥的吧 有想法畅所欲言有何不可？我只是有一个想法，分享出来大家一起讨论而已，我也没说自己是对的，我开头也说了仅仅是我的理论上可行的可能而已，你没必要来这里来显示你多有文化吧？ |
| 15 8520ccc OP @shyrock 索引长度是一个字节啊，索引最长就是 255 最小为 0 一个字节刚好能表示他的所有可能，或者换一种说法用链接序号做第一个字节，用发送的字节做第二个字节！ |
| 19 kop1989 2020-11-27 14:25:27 +08:00 @8520ccc #11 我理解你的意思，你的意思是说，可以用一些传输过程中的、或者收发者理应同时持有的客观信息来当作传递数据的一部分。在你的例子中你利用了“通道数量”和“顺序”这两个额外属性来传递信息。 但你要反过来思考，提供额外的连接和保证顺序，这不也是一种“字典”么，只不过你忽略了创建，或者说传递这个“字典”的成本而已。 换句话说，你为了压缩狭义的数据量，增加了广义的数据量（而且总体上而言还是信息量增加的）。 |
 | 20 XiaoxiaoPu 2020-11-27 14:29:58 +08:00  1 如果不同端口是共用相同的物理信道（例如在 TCP 构建在 IP 之上，IP 构建在以太网之上），那么为了区分不同端口，传输层必然引入额外的信令来标识端口，你所谓的只传输一个字节，在物理信道上仍然要占用两个字节。 如果不同端口是独立的物理信道，那相当于用 256 倍物理信道，实现 2 倍物理信道的带宽，效率只有原本的 1/128，低到令人发指。 |
| 21 kop1989 2020-11-27 14:35:38 +08:00 @XiaoxiaoPu #20 lz 的这个例子简单点就是，东西抱着沉，但背着就不沉了（因为看不见）。 |
| 22 no1xsyzy 2020-11-27 14:37:15 +08:00 1 |
 | 23 si 2020-11-27 14:47:55 +08:00 我刚刚查了一下，“每发一个包，不论大小协议头会占用一定的空间 TCP 头 20 字节，IP 头 20 字节，MAC 头 14 字节，共 54 字节”。相当于用几十个字节表示一个字节了。好像要 256*54=13824 个连接才能抵得过，而且还没考虑其他问题。 |
 | 24 shuax 2020-11-27 14:48:33 +08:00 1 支持楼主，香农算什么，他根本不懂什么叫信息。（狗头） |
 | 25 yolee599 2020-11-27 16:35:40 +08:00 字典快递过去吗？ |
 | 26 CrazyRundong 2020-11-27 17:58:47 +08:00 指出一下主要的 flaw 吧： “用一个字节来传输两个字节的效果” 是错误的。按照你的算法，虽然虚构的 “TCP 链接” 里只传输了 1 字节，但是为了让远端知道用来解码的字典序号，还需要在协议中规定按照 “接受数据的 TCP 链接代表的字典序号” 来确定字典也就是说，256 个信道，每一时间槽只有 1 个信道有效，这不就是把第 1 字节的信息用时分复用传输嘛到头来 2 个源字节的信息你都得发出去。 你自己提到的 “接收数据很难高效的判断先后顺序”，就是时分复用模式的问题。LZ 愿意想这些问题是值得鼓励的，但毕竟思而不学则殆。建议 LZ 去搜一些严肃的课程材料，譬如通信原理和信息论，稍微了解下信息熵、时分 /频分复用这些基本概念。 不要低估聪明人（我是指，历史上 *真正的* 那部分聪明人）在闲得无聊时候做的思维体操，更不要低估 *理论上* 这三个字的重量 :) 祝 LZ 学习愉快 |
 | 27 garipan 2020-11-27 18:29:07 +08:00 Pied Piper 准备上线 |
 | 28 zckevin 2020-11-27 18:33:18 +08:00 少想多读书 |
 | 29 GeruzoniAnsasu 2020-11-27 18:54:57 +08:00 香农就是个种花的农民，懂个屁的信息论（ |
 | 31 vindurriel 2020-11-27 19:45:43 +08:00 via iPhone 楼主这个问题本身挺好的 不连续的数据当然也可以压缩 可以查下 柯氏复杂性 和 霍夫曼编码 但是纯随机数据的压缩极限 shannon 在数学上已经证明了 目前还没有传输算法达到这个极限 甚至没有接近 因为还要容错 |
 | 32 liukangxu 2020-11-27 20:51:00 +08:00 香农的棺材板压不住了（ doge |
Select Language