我在寻求建筑方面的建议。我为一位客户建了一个网站，基本上可以让用户远程查看他们的网络摄像头。
目前的数据流如下：
用户打开页面查看网络摄像头图像。Javascript 脚本每 1000 毫秒轮询一次服务器上的 URL（附加唯一时间戳）
为相机 ftp 用户启用 ftp 连接。网络相机打开与服务器的 ftp 连接。网络相机开始拍照。网络相机将照片发送到 ftp 服务器。
在图像 URL 请求时：服务器读取硬盘上通过 ftp 上传的最新图像。服务器从服务器上删除所有旧图像。
目前，对于少量用户/摄像机（大约 10 个用户和大约相同数量的摄像机），这种方法运行正常，但我们开始担心这种方法的可扩展性。
我最初的计划是，不从服务器读取文件，而是由 Web 服务器打开 ftp 连接，直接从那里读取最新图像，这意味着我们应该能够相当轻松地进行水平扩展。但是 ftp 连接建立时间太慢（主要是因为 ox 之外的 PHP 无法持久保存 ftp 连接），所以我们放弃了这种方法，直接从硬盘读取。
相机固件提供商表示，他们可以构建一个 http 客户端，无需使用 ftp 上传图像，而是将图像发布到 Web 服务器。这对我来说似乎很合理，但我正在寻找一些架构建议。
我目前的想法是一个简单的 Nginx/PHP/Redis 堆栈。
网络摄像头向 Nginx/PHP 发出最新图像的 post 请求，并且该摄像头的最新图像存储在 Redis 中。
然后，客户端可以从 Redis 中提取最新的图像，这应该非常快，因为图像始终存储在内存中。
数据流将变成：
用户打开页面查看网络摄像头图像。Javascript 脚本每 1000 毫秒轮询一次服务器上的 URL（附加唯一时间戳）
相机收到 http 请求，开始将图像发布到提供的 URL 网络摄像头开始拍照。网络摄像头会尽快向服务器发送发布请求
在图像 URL 请求时：服务器从 redis 读取最新图像，服务器告诉 redis 删除后续图像
我的问题是：
- 通过 HTTP 而不是 FTP 传输图像的开销是否会更大？
- 有没有一种简单的方法可以计算出有多少个潜在摄像机可以同时进行流媒体播放？
- 有没有什么方法可以防止由于网络摄像头请求而可能对我们自己的服务器造成 DOS 攻击？
- Redis 能很好地解决这个问题吗？
- 我是否应该放弃 PHP/Ngix 组合并选择其他组合？
- 这个提出的解决方案真的好吗？
- 添加 HTTPs 是否会导致发布图像的速度太慢？
提前致谢
艾伦
答案1
通过 HTTP 而不是 FTP 传输图像的开销是否会更大？
不是。HTTP 比 FTP 更容易加速和缓存。
有没有一种简单的方法可以计算出有多少个潜在摄像机可以同时进行流媒体播放？
1080p 的单个 MPEG4 流大约为 10Mbit。这是大概的数字。您应该能够将其缩减回实际分辨率。
有没有什么方法可以防止由于网络摄像头请求而可能对我们自己的服务器造成 DOS 攻击？
扩展。有一个好的 Node.js MJPEG 代理我过去曾使用过，它比摄像机的板载视频服务器扩展性更好。
Redis 能很好地解决这个问题吗？
可能和其他的一样好。YMMV。做一些测试。
我是否应该放弃 PHP/Nginx 组合并选择其他组合？
坚持做你觉得舒服的事。
这个提出的解决方案真的好吗？
听起来很有道理，但需要进行一些概念验证测试和基准测试
添加 HTTPS 是否会导致发布图像的速度太慢？
可能有一点，但可能不会很明显。同样，您需要进行一些测试。您可能可以使用单独的反向代理来终止 SSL 连接，这样，就能够使用 HTTPS 访问图像，但上传不会通过 HTTPS 进行（如果您想要的话）。
还有一些HTTPS加速卡您可以获得真实的服务器。