欢迎关注微信同名微信官方账号：【全栈攻略】
服务器端渲染React的功能是将数据转换成用户界面。我们还是要牺牲这个公式：
UI=F(data)\ n \ n既然对于React来说，你“吃”的是数据，你“吐”的是UI，那么，这个转换过程可以在浏览器端完成，当然也可以在服务器端完成。不同的是浏览器端的效果是直接操作DOM，服务器端没有DOM，是直接把HTML字符串吐出来。
为什么要服务器端渲染？浏览器端框架这几年蓬勃发展，以至于很多新开发者只知道浏览器端渲染框架，却不知道有服务器端渲染这种东西。其实网站应用一开始都是服务器端渲染，服务器端生成PHP、Java或者Python等其他语言的HTML进行浏览器端解析。
与浏览器端渲染相比，服务器端渲染的优势在于：
可以缩短首次有意义着色时间。如果完全依赖于浏览器端的渲染，那么服务器端返回的HTML就是一个空的框架和JavaScript的应用。然后浏览器下载JavaScript，根据JavaScript中的AJAX调用获取服务器端数据，然后渲染DOM填充网页内容，总共需要三次HTTP或HTTPS请求。
如果使用服务器端渲染，第一个HTTP/HTTPS请求返回的HTML中包含了可以渲染的内容，这样用户会在第一时间感觉到“画了什么东西”，这种感知表现更好。
更好的搜索引擎优化(SEO)。太多的网站希望自己能出现在搜索引擎的搜索页面的顶端。这个前提是网页的内容要被搜索引擎的爬虫正确抓取。虽然像Google这样的搜索引擎已经可以检索浏览器端渲染的网页，但毕竟不是所有的搜索引擎都能做到。如果搜索引擎的爬虫只能获取服务器端渲染的内容，那么全浏览器端渲染就不行了。
即使对于谷歌来说，网页的表现也是搜索排名的重要指标。如果通过服务器端渲染提高网页的性能，网页的排名就更有可能高。
以上两点是服务器端渲染的主要意义。
React对服务器端渲染的支持因为React是声明式框架，所以对服务器端渲染非常友好。
假设我们要渲染一个以App为根节点的组件树。浏览器端呈现的代码如下：
从“React”导入React；\ n从“react-dom”导入ReactDOMReactDOM.render(App /，document . getelementbyid(' root ')；\ n \ n \现在我们希望在服务器端呈现应用程序。如果我们使用React v16之前的版本，代码是这样的：
从“React”导入React；\ n从“react-dom/server”导入ReactDOMServer//将生成的html返回给浏览器。render tostring(hello/)；\ n \ n \从React v16开始，仍然可以使用上面的服务器端代码，但是您也可以使用以下代码将renderToString替换为renderToNodeStream:
从“React”导入React；\ n从“react-dom/server”导入ReactDOMServer//将呈现的内容插入response \ nreactatdomserver . rendertonodestream(hello/)。流形式的管道(响应);\ n \ n此外，浏览器端代码发生了一些变化。ReactDOM.render还是可以用的，但是官方的建议是用ReactDOM.hydrate代替，原来的ReactDOM.render以后会废弃。
renderToString的作用是一口气同步生成最终的HTML。如果React组件树很大，这样的同步过程可能会很耗时。假设渲染完整的HTML需要500毫秒，那么HTTP/HTTPS请求过来并在500毫秒后返回HTML是不合适的，这也是v16提供新API renderToNodeStream的原因。
RenderToNodeStream将渲染结果以“流”的形式推送到response对象中(这里response是express或者koa的概念)，也就是说你不用等到所有的HTML都渲染完了再将结果返回给浏览器。也许网页头会在10毫秒内渲染出来。那么就不需要等到500毫秒所有网页都出来再推送到浏览器。“流”的作用是有多少内容就给多少内容，让用户只需要10毫秒多一点就能看到网页内容，进一步提高了“第一次有意义的呈现时间”。
服务器端渲染的难点看到这里，你可能觉得服务器端渲染太简单了。事实上，因为React组件不必关心它正在呈现哪一面，所以它可以编写一次代码，然后在任何地方执行它。但是真的有那么简单吗？
为了简化问题，上面的代码示例故意忽略了应用程序经常需要外部服务器来获取数据的事实！
除非您的web应用程序根本没有动态内容，否则您必须考虑如何在服务器端为React组件获取数据。
比如为了渲染你看到的页面，你需要调用掘金小册子的服务器API来获取这篇文章的内容。浏览器端渲染，只需调用componentDidMount中的AJAX对于服务器端渲染，如果要生成HTML内容，必须提前准备好数据，也就是说代码应该是这样的：
从“React”导入React；\ n从“react-dom/server”导入ReactDOMServercallAPI()。然后(结果={ const props=结果；\ n reactdomserver . rendertonodestream(Hello {.道具}/)。管道(响应)；\ n })；\ n \ n \最大的问题是，如何获取数据并向组件提供数据？
只有解决了这个问题，才能真正解决服务器端渲染的问题。
“脱水”和“注水”反应的特点之一是将内容显示和动态功能集中在一个组件中。例如，计数器组件不仅负责如何绘制内容，还负责如何响应按键点击。这当然符合软件高内聚的原则，但也给服务器端渲染带来了更多的工作。
想象一下，如果只使用服务器端渲染，只会生成HTML。虽然浏览器可以绘制内容，但如果没有JavaScript的帮助，它无法响应用户交互事件。对应于计数器的示例，计数器组件在浏览器中呈现一个数字和两个按钮。当用户单击按钮或-按钮时，没有任何反应。
显然，我们必须在浏览器端赋予计数器组件一些“魔力”，使其能够响应事件。那么如何赋予反制组件“神力”呢？实际上，我们已经这样做了，计数器组件已经有了按钮事件的处理。我们要做的就是让计数器组件在浏览器端重新执行一次，也就是挂载一次。
也就是如果想要动态交互效果，使用 React 服务器端渲染，必须也配合使用浏览器端渲染。
现在这个问题变得更有趣了。在服务器端，我们给计数器一个初始值(这个值可能不是默认的0)，让计数器渲染生成HTML，要传递给浏览器端。为了使计数器的HTML“活”起来并点击相应的事件，必须在浏览器端重新呈现计数器组件。在浏览器端渲染计数器之前，用户可以看到计数器组件的内容，但是不能点击交互。如果要点击交互，就要等到浏览器端也渲染一次计数器。
下一个问题，如果服务器发送给计数器的数据和浏览器发送给计数器的数据不一样怎么办？
在React v16之前，React在浏览器端渲染后，会将内容与服务器端给出的HTML进行比较。如果完全一样，最好，那就用服务器端HTML就好；如果稍有差异，服务器端的HTML会被立即丢弃，浏览器端生成的内容会被重新渲染。因此，用户可以看到界面在闪烁。因为React舍弃了整个服务器端的渲染内容，组件树越大，这种闪烁效果越明显。
v16之后，React做了一些改进。它不再要求整个组件树两端的渲染结果都是精确的，但如果有任何不一致，本地服务器端的渲染结果仍然会被丢弃。
总之如果用服务器端渲染，一定要让服务器端塞给 React 组件的数据和浏览器端一致。
为了实现这个目标，传输到React组件的数据必须保留下来，并与HTML一起传输到浏览器网页。这个过程叫做脱水)；在浏览器端，“脱水”的数据直接用于初始化React组件。这个过程叫做“水合物”。
如前所述，React.hydrate用于替换React.render在React v16之后，这种水合物就是“注水”。
总之，为了实现React的服务器端渲染，我们必须处理好这两个问题：
脱水脸书不使用服务器端渲染。值得一提的是，虽然React从最初版本开始就支持“服务器端渲染”，React的创始人脸书也竭尽全力在自己的网站产品中使用React，但他们自己并没有使用React的服务器端渲染功能。原因是脸书在PHP上投入了大量的资源，并且不打算放弃这些投资。
我当然不是在批评脸书。事实上，脸书对React的支持是真诚的。它在自己的网站上广泛使用React，而不是在制作完成后让外部用户成为试验品。这种完全的承诺也给了React用户极大的信心。但另一方面，由于脸书本身不使用React的服务器端渲染，如何利用该功能缺乏官方参考标准。
也许是因为缺乏官方的脸书标准，服务器端渲染的解决方案在业界层出不穷。但是，到目前为止，next.js仍然是最好的解决方案。
搭建个人渲染服务器怎么弄
来源：蛋蛋球(ID: Dandan _ Tuan)
声明：部分图片来自网络，侵删。
本文为蛋球团云知识直播讲解两篇文章中的第一篇。更多精彩，请关注微信官方账号：蛋蛋团(ID: dandan _ tuan)
3.视频直播的精确定义
第三，直播协议和应用场景的区别
3.开源推拉流媒体软件推荐
第四，借助直播云快速搭建直播
在说直播之前，我们先来了解一下常见的视频结构。了解视频的结构有助于我们更好地理解直播。
实质上，直播是数据帧加上时间标签的流式传输。这里有一个悖论：容器打包后的视频是“结构化”的，也就是不可变的。
那直播是怎么产生的呢？或者说，你如何打破已经产生的“结果”，然后给它加上一个计时标签进行串流？
很简单，那就是“制作、传输、回放”。至于如何达到这个效果，我们继续往下看。
聊到直播，怎么突然聊到视频了？
很简单，视频和直播是密切相关的，就像两个相互联系的编码和压缩。这里的编码压缩是什么？
这里举个简单的例子。让我们假设采集设备(摄像机等。)捕获一帧图像并生成无损的。bmp文件格式。有损压缩得到6米的JPEG文件，压缩比为1/30。
而视频不需要单独传输压缩图像，只需要记录每帧之间的差异即可。
然后根据I帧(200K原始图像)生成差分文件P帧，由I帧和P帧重新生成B帧。这是H.264代码。
如上图所示，编码和压缩就像魔术一样。如果对视频进行编码和压缩，其体积可以大大减小。各种压缩算法都是编码格式。现在主流的音视频编码格式是H.264 AAC，这也是所有平台最好的编码格式方案。
视频经过编码压缩后，体积大大减小，有利于存储和压缩。但是，相应的，传输的也是被压缩算法“加密”的视频。所以在播放端也需要一个“解密”的过程。
在编码和解码之间，显然需要一个编码方和解码方都能够理解的协议。就图像而言，制作端的编码器对多幅图像进行编码，生成一组图片，而播放端的解码器对该组图片进行读取和解码，然后读取图片并渲染显示。
GOP=I(帧内编码帧)B(双向预测帧)P(前向预测帧)
I帧也叫关键帧，是一个完整的画面，而P帧记录的是I帧的变化(H.264中补偿算法从I帧得到的差异文件)，B帧也类似。
简单来说，如果没有I帧，P帧和B帧就无法解码。这也很好理解，没有原始的对比文件，只有差异文件是无法渲染图片的。
GOP的结构一般是两个数，比如M=1，N=2。指定m个I帧和p帧之间的距离，n指定两个I帧之间的距离，其余用B帧填充。如果M=1，N=2，这里的例子是IDR PB I排序。
有些地方会讲IDR帧，其实是GOP的第一个I帧。这个框架很重要，因为第一次开篇优化基本上都是尽量减少IDR框架的大小。
编码视频)=一组GOP图片=一组I帧、B帧和P帧。
如果用物理概念的类比，只是为了更好的理解，视频是“对象”，GOP就像“分子”，I/P/B帧的图像是“原子”。而直播就是视频的“原子”传输。
3.视频直播的精确定义
在这里，我们终于可以尝试给直播一个更准确的定义了。
直播是将每一帧数据(视频/音频/数据帧)以时间顺序标签进行流式传输的过程。
发送方不断采集音视频数据，经过编码、打包、推送，然后通过中继分发网络传播。播放端不断下载数据，按照时间顺序解码播放。从而完成“制作、传输、播放”的直播流程。
简而言之，视频直播技术是一种基于时间序列标签对视频内容的最小粒子(I/P/B帧)进行流式传输的技术。
GOP越长，包含的B帧和P帧越多，响应的压缩比越高。
GOP越短，I帧比和压缩比越高，相同码率下视频质量越低。
直播也有两种，一种是直播服务，一种是互动直播。
比如直播服务是信号塔，互动直播就是带舞台的剧院。
今天主要说前一种，也就是“信号塔”直播。
与“舞台式”互动直播相比，“信号塔”直播只要知道发射塔的信号频率(即频道号或链接)就可以观看其发送的节目，但无法实时互动。
对于互动直播来说，舞台上可以有很多演员，也可能邀请观众在舞台上面对面，所以互动直播的延迟会比直播低，甚至达到毫秒级(100ms)。
当然，互动直播也可以通过旁路转发后的“发射塔”进行播放，也就是“旁路转发”功能。
常见的直播业务逻辑如下：
推流：指的是将采集阶段的打包内容传输到服务器的过程。
流媒体：将服务器打包的内容拉到播放端进行解码播放的过程。
下面是一个当前主流的直播泳道，非常直白的表达了从主播端视频的采集到直播在观众端的播放的数据流。下面就按照主要模块逐一详细讲解吧。
数据采集数据预处理数据编码数据传输(流媒体服务器)数据解码直播。
1.数据采集(锚终端)
采集设备：手机、电脑、相机
相关功能：美颜、滤镜相关技术：SDK内置算法或第三方特效。
相关技术：编码器自带解码器。
6.数据回放(回放结束)
播放渠道：移动终端(手机、平板等。)、客户端(PC等。)和web终端(每个终端)