逻辑当然可以程序化，但问题是，逻辑需要的数据，以目前的技术来说，存不下。

楼主是不是觉得，带宽、硬盘、服务器，是天上掉下来的？

C 或 C++，通信原理（主要是 udp 与 tcp ），数据结构。

我觉得这三样能达到 80 分就可以完成接口的基础设计与实现。

如果你真想分享，你应该把这些数据，整理成通用数据库的数据，最后把数据打包分享。

你现在自己搞一个接口，鬼知道什么性能，有没有调用限制，以及能用多久。

@tctc4869 帖子一张表，评论一张表。

能直接教会徒弟的技术，说明这技术本身没门槛，不值钱。

举个反例：如果你能写一个搜索引擎原型，能搜到百度和谷歌搜不到的东西，但这套理论，从电路到分布式技术都至少要熟悉，你觉得几个徒弟能听得懂这完整的知识链条？

@leekafai 如果这两个问题都无法自行解决的话，那就只能建议换个行业了。

1.帖子与回复，统一 varchar 就行了，1GB 的最大长度足够了。

2.帖子与回复当然要分表，因为业务逻辑与功能都不一样。

3.nosql 选 MongoDB 就好，简单又方便，但要注意选择安全的策略，以及数据落地后最好在代码层校验一下，因为 MongoDB 有遗漏数据的恶习。

鼓励一下。

但这类需求，最佳实践是：

本地图片批量转换、缩放、格式转换，简单需求，直接用老版本的 ACDSee 就好，它还可以一键改名。

如果需求复杂了，一般是编程调用 ffmpeg 来实现。

上面所有回答，全部答错。我来终结此贴。

原因有 2：

1.GFW 的拦截。

2.国外这种软件机构并不愿意花钱在大陆做高速 CDN。

因此，解决的方案其实也很简单，那就是准备一个高速的梯子就行了。这样，从 Google 里搜 jdk 版本，然后 oracle 登陆，最后下载，几分钟就能搞定。包括你说的其他那些事情，都一样。

@asdfjkl 公网 IP 与 NAT 子网通信，理论上来说，只要暴露了服务端地址，那么通信就能成立。但这只是理论上的，就看网络设备商的程序猿会不会偷懒。因为不偷懒的话，NAT 设备还需要涉及到一次地址记录与查找。如果程序猿偷懒，那仍然是无法通信。

而且其实这都不重要，重要的是，暴露了服务端地址，隐藏通信的想法在实际应用中，根本就不可靠。因为网安要求电信的上端仍然有记录设备，会记录当前链路发的包。所以无论包里如何填 IP head，被记录后都能查出是谁发的。具体来说：

家庭光纤或拨号上网用户，上级的 EPON 之类的设备会能够把数据库与线路记下来，存储到电信的网安设备里。
学校或大型单位用户，网安会要求在 NAT 设备与用户之间安装网安设备来记录这些东西。

总之，只要网安想查，这种协议是无法避免被查水表的。

真正想逃避这种检查，只能采用洋葱路由的思路，这种思路的本质是查证成本太高，导致实际上就没办法查。

它这个协议根本就是错的。

公网 ip <---> 公网 ip，这一条没问题，原理很简单，就像收发邮件一样。一般发邮件，发件人，会在邮件的发件人一栏，写上自己的名字、地址、电话。但是，发件人信息其实是可以不写的，因为只要有收件地址，对方就可以收到邮件。这个协议就是模拟了这个特性。就像很多淘宝发货商，在包裹的发件人信息一栏，不会写具体发件人的位置，而是用店铺名与手机号取代。



公网 IP <---> NAT 子网，这就全错了。

首先，它要求客户端与服务器进行正常通信，那就暴露了客户端的地址。

其次，这个协议的作者，没搞懂 [NAT 打洞] 是怎么回事。NAT 有多种模型，它提的这种方法只对于全锥形 NAT 才有效，但问题是，大部分民用以及低端商用路由器或 NAT 设备，是不支持全锥形 NAT 的。所以协议用全锥形 NAT，对于大部分民用设备是无法通信的。如果改为其他 NAT 模型又必须暴露服务端的地址。

套壳后稍加处理，于是你们就觉得这不是套壳，真的不担心谷歌的律师函？

不要感觉压力大不大，要进行计算压力大不大。包括内存与带宽。

其实用 360 安全浏览器就行了，少见多怪。