微服务解决单体应用瓶颈的同时也引入了新的问题，即远程方法调用过程中协议约定、服务发现以及网络传输的复杂度增加，必须要解决这些问题才能保证远程方法调用的可靠性，在工程实践中，我们通常使用一些优秀的开源 RPC 框架来处理这些底层问题（如 Spring Cloud、Dubbo、gRRC、Thrift、Hprose 等），作为一般开发者，只需要基于这些框架专注上层服务实现即可，但是作为一个有追求的开发者，最好能够理解 RPC 框架底层的实现，这样才能更好的使用这些框架。
所谓 RPC 指的是 Remote Procedure Call，即远程方法调用（也叫远程服务调用、远程过程调用），这也是微服务架构的前导篇，因为微服务里面远程服务之间就是通过 RPC 协议进行数据传输的。
多数情况下，CDN 相当于一个代理，从上一级缓存读取内容，然后转发给用户。
主播在客户端采集视频后，照例客户端软件会对视频进行编码以压缩视频，然后通过 RTMP 协议将这个二进制的视频流打包成网络包发送给服务器，这个过程对应上述流程图中的推流（在实际开发中，通常通过 FFmpeg 进行推流）。
HTTP 视频协议是在互联网普及之后在互联网上看视频的需求下形成的。最初的 HTTP 视频协议，没有任何特别之处，就是通用的 HTTP 文件渐进式下载，但是在这种情况下，视频无法快进或者跳转到文件尚未被下载到的部分，这就对 HTTP 协议提出了范围请求（Range Request）的要求，目前几乎所有 HTTP 服务器都支持范围请求。所谓范围请求指的是请求文件的部分数据，这可以在 HTTP 请求头中通过 Range 字段设置偏移量来实现。
说到视频播放，其实就是快速播放一系列连续的图片而已，其中的每一张图片称之为一帧，只要每秒钟帧的数量足够多，也即播放得足够快，比如每秒 30 帧，以人眼的敏感程度，就看不出这是一张张独立的图片，我们把每秒的帧数叫做帧率（FPS）。
目前主流的 HTTP 通信都是基于 HTTP/1.1 的，而 HTTP/1.1 自 1999 年发布的 RFC2616 之后再未进行过修订，而随着互联网的蓬勃发展，HTTP/1.1 自身所暴露的问题也越来越多，于是负责互联网技术标准的 IETF 组织创建了专门的工作组来推进下一代 HTTP —— HTTP/2.0 的标准化，其首要目标就是解决 HTTP 的性能瓶颈，缩短 Web 页面的加载时间。
WebSocket 复用了 HTTP 协议来实现握手，通过 Upgrade 字段将 HTTP 协议升级到 WebSocket 协议来建立 WebSocket 连接，一旦 WebSocket 连接建立之后，就可以在这个长连接上通过 WebSocket 数据帧进行双向通信，客户端和服务端可以在任何时候向对方发送报文，而不是 HTTP 协议那种服务端只有在客户端发起请求后才能响应，从而解决了在 Web 页面实时显示最新资源的问题。
在建立 HTTP 标准规范的时候，设计者的初衷主要是想把 HTTP 当做传输静态 HTML 文档的协议，但是随着互联网的发展，Web 应用的用途更加多样性，逐渐诞生了电商网站（如淘宝、亚马逊）、社交网络（如Facebook、Twitter）等功能更加复杂的应用，这些网站的功能单纯靠静态 HTML 显然是实现不了的，因此又产生了通过 CGI 将 Web 服务器与后台动态应用连接起来
非对称加密在性能上不如对称加密，但是安全性上要更好，因此 HTTPS 综合运用了这两种加密方式的优势，使用非对称加密传输对称加密需要用到的密钥，而真正的双方大数据量的通信都是通过对称加密进行的，结合数字证书（包含公钥信息）验证服务端公钥的真实性，HTTPS 的底层原理如下：
