在视频领域这个“压缩”可不是类似 winzip 、winrar 的压缩啊。
视频的压缩，普遍都是有损压缩，不存在“解压”这个概念，所谓的解压是基于有损的信息的重采样编码，效果肯定不行啊。

至于上传，上传分三步：客户端往服务器传，网络传输，服务器接收。那你觉得你所谓的“压缩”在哪一步完成呢？第一步？指望浏览器给你做视频压缩？第二步，网络交换机、路由器做压缩？第三步，服务器都已经接收到了原始数据，再压一遍，以后再“解压”，图啥？直接存储原始信息不好么。

然后客户端回显，现在 H5 的 video 标签，直接去服务器端请求数据，如果是本地能够解码的格式（比如 mp4 封装、h264 视频编码、mp3 音频编码）那就直接播放，如果不认编码格式，那就不能播放。

最后防盗链的一般手法是 host，二班手法是 header 里上 token，三班手法是 session，当然还有四五六班等等

@youngce 1# 把 javascript 作为字符串用对称加密（混淆），然后对称解密（反混淆）之后，eval 执行。
这是 js 混淆的手段之一。

从专业角度讲，能比气象台 NB，那我五体投地。路过过一次天天耳闻中的北京南郊观象台，自己可以卫星图看一下规模就知道了。
从自娱自乐角度讲，这事完全没难度，正如 @locoz 13#所述，简单地很。

A 口 B 口冲突了吧
按道理，掩码只负责子网判定，跟 IP 无关，所以按照 LZ 描述，A 口 B 口可以同时设置 192.168.128.5，那显然这是不允许的。

/'dΛb,lju:'e'sel/
大不 留 艾 赛欧

@yitingbai 2# 英雄所见略同

再补充一条，程序是一个逻辑性极强的事情，程序弄多了，思维方式也会跟着强逻辑性，推而广之，世界观方法论都会受其影响。
曾经有人评论过我：编程改变世界。进一步讲，现在的技术发展，单纯的硬件是不可能运行的，各级别的软件均通过程序实现，进而控制住所有事情。

我在二进制上只处理过混淆的 java class bytecode 文件，祝楼主保持满头秀发

frps 本身监听一个端口用于 frpc 接入。然后 frpc 连接后，根据配置文件，在 frps 的服务器端创建一个新端口连接 frpc （相当于将 frpc 的端口映射到 frps 的新端口上）。然后第二个 frpc 连接同一个 frps，将 frpc 本地的端口映射到 frps 服务器上的另外一个端口（即映射第二个端口）即可。

微软市场搜索 QuickLook

话都说到这份上了，还要咋说？
不就是破解、桥接、软路由，路由从光猫上拆解出来。所以光电转换还会热？还怕热？降维打击了。

@rrfeng 7# 所以根本就是芯片性能不行，热不热的，PL1 和 PL2 ？

就是个光电转换器，需要散热片？
除非 LZ 的光猫就是个路由，那也不是散热的问题，真的是累死那颗小小的芯片了。
[臣妾做不到啊]

@liuzh336 6# 你想干啥你不知道么？
看样子像是根据服务器的服务器状态来一级一级反代，而不是根据用户请求条件分流。
你给的案例，是根据用户请求来判定反代去向。所以跟你的期望应该不一致。

又不是 10*10*10——O(n^3)，仅是 O(n)而已，无所谓的

实例编号，UUID 一劳永逸。
递增的编号，除了人阅读起来好看，机器处理起来，1 和 2 这两个实例，哪台设备能知道这两个是有所谓的先后顺序，就是两个字符而已。

如果仅是 2#所述的根据服务器状态来执行，那还是得用 upstream，这就是负载均衡的概念了，而不是仅仅为反代

如果 uri 或者参数场景都不能实现。那你靠什么实现 if-else 呢？

好像以前 youku 是国内 youtube 的定义，现在看来，抖音更有潜力了。youku 下去之后，好像国内一直缺乏一个 youbute 样式的视频站。

所以那天才知道现在搜索不去百度什么的，而是上抖音搜索。其实本人也是这么搞，哪些不懂的事情，去 youtube 上搜索一些视频，答疑解惑比纯文字更直接。