放到搜索引擎里搜一下

如果是电脑+摄像头，可以用 ffmpeg 推 HTTP-FLV 流。
用 HTTP-FLV 流形式做直播，需要一个 web 服务器，网页端看起来就是一个无限大的 flv 文件，页面显示可以用 B 站开源的 flv.js 做，这样用户只需要有个浏览器即可连接。
至于连接控制就很容易了，每次有人来连接，检查是否已经被连接，如果有就返回错误提示，没有就返回能够直播的页面。

我也是，经常被教育机构推荐，因为原机主的儿子上高中了

以前冲了三年的，但是现在还有这个活动吗？有的话就该续费了，没有的话到期之后我就不用迅雷了

docker 解决你的问题

个人建议，不要瞎折腾，能用 IIS 就用 IIS，毕竟是付费产品，出事了微软给你擦屁股；自己折腾开源的东西，出事了顶锅的可是你。

@wangxiaoer
还真是简单粗暴啊……
如果是这个方案，那就很简单了，所有文件都用 HTTP 或者 FTP 拉取，比如 nginx 提供 HTTP 服务，一般 80 端口应该都会开吧？就算没开，随便找个端口开一下都可以提供服务。
按照一般的 web 应用做一下鉴权（如果你们需要的话）即可，反正内网环境带宽够高，HTTP 的性能可以接受。

虽然我更倾向于把文件的元信息保存在数据库，应用层查询数据库获取小文件的大小、偏移量以及宿主文件的 URL，然后用 HTTP 的 range 获取文件，性能上好太多，节省很多流量，当然，如果你们觉得麻烦，当我没说 233333

访问频率可能是根据访问时长来限制阈值的：正常人访问时间一般比较短，爬虫几乎必然是长时间、不间断访问。
也就是说你连续请求时间越长，针对你的访问频率阈值就会越低。
爬虫如果不限制频率，很短时间内就会触发短期阈值；即使限制了频率，长时间访问也会碰到长期阈值。
这种基本上无解，只能靠大量代理来解决。
当然，如果你能知道他们的具体函数的话那就美滋滋了，比如知道多久不请求就会重置阈值以及阈值和访问时长的联系。

另外部分网站出现过的情况，页面里一堆只有爬虫才能看到的数据，给你的数据投毒 2333 还会用 csv 画出来的价格标签，真人看起来没什么区别，爬虫爬回来就是一堆 csv，你还得跟验证码识别一样去识别价格标签。

另外有的网站随机请求间隔比固定间隔有更高的效率。

请问你们现有的方案是遇到了什么问题呢？权限控制过于复杂？文件共享有莫名其妙的 BUG ？还是性能跟不上？开发复杂度过高？

另外文件索引解析的流程是以下哪一个？
1. 大文件读取到应用服务器，解析出所需数据，抛弃其它部分
2. 调用文件服务器接口，文件服务器完成解析后传输所需数据
3. 从文件服务器获取索引信息，然后利用 Windows 文件共享协议提供的随机访问功能读取所需数据。

另外所有服务器应该是在局域网环境吧，也就是相互之间带宽很高？

生成 csv 然后用 MySQL 的 load data infile 功能
使用这个是单个事务且所有数据导入后才重建索引，比其他方法快很多。
注意处理唯一键冲突，选择 ignore 或者 replace

@cchange 就算加密，公安要调的时候也得给，不然不可能让苹果进来

持续写入，性能瓶颈主要在磁盘 IO。
猜测其中可优化点：
1. 使用 buffer 减少磁盘 IO 次数
2. 一次性创建所需大小的文件后再写入，在大多数文件系统上可以获得更好的效率

详细解释：
1. 磁盘每次写入，不管是写入 1 个字节还是 1K 字节，只要在一定范围内，时间相差不多，所以尽量攒够一波再写入
2. 每次都是追加文件尾，文件系统一开始并不知道你的文件大小，一开始先创建一个恰当大小的文件，文件系统更容易做出优化，不同的文件系统实现不同，此处略去。

相关参考：
1. 创建特定大小文件： http://jk-t.iteye.com/blog/1930414
2. 使用 BufferedWriter 写文件

使用 SSL pinning 技术增大抓包难度。
自增字段、加密网卡号等方式都可以增加破解难度。
破解难度高到一定程度即可，再费劲就得不偿失了。

http://sms.mob.com/
这家有免费的对象存储，应该可以满足需求

@searene 为了将来可能的修改啊，而且 Java 的很多框架都是依赖 set 和 get 方法做反射