做一个视频站，要什么配置的服务器？

最近听说了“两微一抖”这个词。很容易联想到，“两微”指的是微信和微博，“一抖”指的是抖音，它描述的是今年开始互联网行业呈现的一种新的变化。抖音奇迹般地杀出重围，与微博、微信一起造就了流量市场“三权分立”的现象，这一现象跟IDC行业视频服务器租用业务需求不断增长的行情是相关的。小视频服务器的需求有多大很多人咨询过来就是想要搭建自己的小视频、短视频app，和视频会议、游戏直播、在线教育等视频点播平台，这热度快赶上金融行业了。而不管是视频网站、直播平台还是短视频app都需要放置在服务器上，视频服务器，或者说流媒体服务器就是可以承载这些应用的专用服务器。视频服务器和一般服务器有所区别，它主要包含存储设备、高速缓存和控制管理单元，并增加了许多专用的软硬件功能设备，以应对媒体数据的压缩、存储、传输等功能。

当我们说到小视频、短视频这种点播平台视频服务器的配置，有三点是必须要考虑的:

一、小视频服务器的带宽需求是怎样的

首先，我们可以来看一个数据:通常一个在线观众要流畅的观看高清(480P)视频大概需要300k~400k的带宽流量。由于服务器所要负载的带宽是按可承载的最高并发流量计算出来的，所以我们假设网站同时在线人数是10人左右，那大概3M的带宽可以保证这10人能达到完全流畅播放这个视频的程度。根据带宽的换算方式:128k的流量需要1M的网络带宽，那么这时候带宽的需求至少需要20M以上。

当然视频网站就重要的就是带宽，带宽越大，承载人数就越大，网站运行起来速度流畅，用户体验度就越高。但是这里有一个问题，带宽的成本是很高的，10M、20M可能还能承受，再往上加，成本控制就很成问题了。那么要怎么解决这个问题呢答案是做CDN加速，CDN加速技术是能提高流媒体加速服务的一种关键技术。它要分发的内容预先发送到CDN节点网络，根据网络情况和节点的负载情况，自动将用户的请求引导至离客户最近的节点服务器上，从而达到解决网络拥挤，提高客户的访问速度的问题。这样做有两个好处，一是节省成本;二是更稳定的网络大大提升了用户体验。

二、部署一个短视频app服务器需要多少钱

前面说了带宽的问题，除开服务器硬件的成本，部署视频服务器要“出血”的大头算是解决了。还有什么需要花钱的地方呢视频服务器还要处理音视频存储管理、音视频转码处理、音视频加速播出等问题，具体到细节的问题，比如说滤镜、贴纸、音效等，这些都需要做特殊处理。我大致看了一下，一个要包含录制、导入、贴纸、MV、字幕功能的基础服务器，阿里云官网的报价是16万，这还不包括带宽和做CDN加速的价格!还要专门弄个存储的服务器吧总得搞个安全防护防一防网络攻击吧那这一套下来得多少钱啊不敢想，不敢想。我只是想当个短视频届的网红，你却告诉我要倾家荡产。看来下一个抖音app要拱手相让了

当然，还是有省钱的解决办法的。不过得说，该省的不能省。在前期选择做短视频app时，我们要假定我们的客户群体的数量，一般来说前期人数是很少的，这样的话我们可以选择稍微低配的服务器，在后期推广开了，人数上来之后，我们可以再重新部署嘛。

一、项目背景

最近很多朋友希望我的 Flamingo 服务器支持 http 协议，我自己也想做一个微信小程序，小程序通过 http 协议连接通过我的 Flamingo 服务器进行聊天。

Flamingo 是一个开源的即时通讯软件，目前除了服务器端，还有 PC 端、Android 端，后面会支持更多的终端。

关于 Flamingo 的介绍和最新源码： https://githubcom/balloonwj/flamingo 更新日志：https://githubcom/balloonwj/fl

二、http 协议介绍

http 协议是应用层协议，一般建立在 TCP 协议的基础之上（当然你的实现非要基于 UDP 也是可以的），也就是说 http 协议的数据收发是通过 TCP 协议的。

http 协议分为 head 和 body 两部分，但是我们一般说的 html 文档中的 和 部分是 html 文档的 head 和 body，它们都是 http 协议的 body 部分。

http协议的格式如下：

GET或POST 请求的URL路径（一般是去掉域名的路径） HTTP协议版本号\r\n

字段1名: 字段1值\r\n

字段2名: 字段2值\r\n

字段n名 : 字段n值\r\n

\r\n

http协议包体内容

也就是说 http 协议由两部分组成：包头和包体，包头与包体之间使用一个\r\n分割，由于 http 协议包头的每一行都是以\r\n结束，所以 http 协议包头一般以\r\n\r\n(两个 \r\n )结束。

三、http 客户端实现

如果您能掌握以上说的 http 协议，你就可以自己通过代码组装 http 协议发送 http 请求了（也是各种开源 http 库的做法）。

四、http 服务器实现

我们这里简化一些问题，假设客户端发送的请求都是 GET 请求，当客户端发来 http 请求之后，我们拿到 http 包后就做相应的处理。我们以为我们的 Flamingo 服务器实现一个支持 http 格式的注册请求为例。感兴趣的话点击此处，了解一下

视频服务器可以看作是不带镜头的网络摄像机，或是不带硬盘的DVR，它的结构也大体上与网络摄像机相似，是由一个或多个模拟视频输入口、图像数字处理器、压缩芯片和一个具有网络连接功能的服务器所构成。视频服务器将输入的模拟视频信号数字化处理后，以数字信号的模式传送至网络上，从而实现远程实时监控的目的。由于视频服务器将模拟摄像机成功地“转化”为网络摄像机，因此它也是网络监控系统与当前CCTV模拟系统进行整合的最佳途径。视频服务器除了可以达到与网络摄像机相同的功能外，在设备的配置上更显灵活。网络摄像机通常受到本身镜头与机身功能的限制，而视频服务器除了可以和普通的传统摄像机连接之外，还可以和一些特殊功能的摄像机连接，例如：低照度摄像机、高灵敏度的红外摄像机等。

网络视频服务器的价格都是不等的，还要看要购买的是几路的视频服务器以及是什么压缩方式的视频服务器。

随着VOD日益流行以及服务供应商、技术设计商与媒体拥有者不断融合，交付架构也在不断发展。目前大型网络中采用的最著名的VOD架构通常称为SHE-VHO-VSO模型。

SHE-VHO-VSO模型——这种架构是一种层级架构：“超级头端”(SHE)汇集大范围内或全国的内容并且在大范围内提供实时全国内容，通常采用IP作为网络层协议。“视频中心局”（VHO）与SHE一起把本地与区域内容整合到内容组合中，从而确保全国与本地内容的供应。最后，“视频交换局”（VSO）把不同内容从网络映射到接入域，以便发送给用户。

这种模型很适应传统内容交付；但是，随着大家对点播业务的兴趣不断提高并且其在收入流中的比重日益加大，开始出现多种业务问题。由于所有VOD分配模型的整体目标都是最小化交付延迟、最大化网络服务可靠性、创建易于管理（因此也易于计费）的业务环境，以及确保可靠、可预测的媒体流环境，因此出现了不同的架构方案。由于流量瓶颈是基于服务器的网络中最常见、最棘手的问题，因此抛弃单一服务器解决方案是一种自然而然的选择。

分布式服务器模型——理想情况下这种模型可以很好地运行。不过，由于大部分网络都非常复杂，来自单个站点的内容存在一些潜在问题。为此，通常会部署一种多服务器架构，从多台服务器向单个客户端发送内容。这样可以把故障风险分散到多台设备，同时消除服务器的进出瓶颈。这种模型中的内容下载由接收器驱动，而非由发射器驱动，从而可以无需协调参与下载的各台服务器。此外，对服务器内容的请求在块级进行，这样可以消除对复杂、耗时的分组处理的需求。最后，在参与的服务器群之间可以对带宽占用进行自适应管理，这样一方面可以保持服务器负载相对均衡，另一方面也可以消除服务器故障造成严重业务中断的可能性。

点对点传输——紧随分布式服务器模型而来的是主题的变化。最终负责把内容传输给用户的服务器常称为流引擎。在点对点环境中，主要流引擎与对等服务器合作，从合作设备下载相关数据块，用于发送给用户，这样可以使不同服务器与路径分担传输责任，从而提高系统整体效率。