阿里云服务器ECS如何选择？性能测试PTS助你测试和选择阿里云服务器

阿里云服务器ECS如何选择？很多新手用户并不知道PTS是什么，如果你不知道如何选择阿里云服务器ECS产品，性能测试PTS可以很好的帮助你快速对云服务器进行压力测试，从而助你选择适合自己的阿里云服务器ECS，下面是性能测试PTS详解！

阿里云开发者社区最近推出了一个“ ECS 选款利器！PTS助您快速上云 ”活动，PTS性能压测包仅需099/月起，真实模拟，免去繁琐的搭建和维护成本！现在您可以只支付10块钱不到的试用成本，即可体验使用 PTS 来帮助 ECS 进行容量规划选择合适规格的整个流程！

完成动手实验的同学，即可参与抽奖活动，小米手环 6、蓝牙键盘、掌上游戏机、笔记本支架、 数据线、优惠券等丰富奖品等您来拿！限量 1500 份，抽奖即得，百分百中奖哦！

性能测试PTS（Performance Testing Service）是具备强大的分布式压测能力的SaaS压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。

PTS旨在简化性能压测本身的工作。

PTS目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。在PTS平台上，您可以用较低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量配比、全链路压测的流量构造提供最好的帮助。进而提升用户体验，促进业务发展，最大程度实现企业的商业价值。

业务场景

PTS广泛应用于各种压力测试和性能测试场景，包括但不限于以下场景：

PTS孵化于服务阿里巴巴全生态五年以上的单链路、全链路压测平台，是阿里巴巴内部最佳实践的输出。该平台对内除了支持日常的外部流量压测之外，同时支持了大大小小的促销活动，如天猫双11、双12和年货节等。

压测流程

PTS提供全面高效的压测流程：

压测流程说明：

1在PTS控制台上，准备压测API数据，构造压测场景，定义压测模式、量级等；支持随时启停压测，压测过程中可调速。

2压测启动后，PTS后台的压测控制中心将自动调度压测数据、压测任务和压测引擎。

3通过随机调度全国上百个城市和运营商的内容分发网络CDN （Content Delivery Network）节点，发起压测流量。保证从虚拟用户并发量、压测流量的分散度等维度都接近真正的用户行为，压测结果更加全面和真实可信。

4通过压测引擎向您指定的业务站点发起压测。

5压测过程中，通过集成云监控、ARMS（应用实时监控服务）产品，结合PTS自有的监控指标，实时采集压测数据。

6在PTS控制台，实时展现压测数据，进行过程监控；压测结束后，生成压测报告。基于整个压测场景的性能表现，定位性能问题、发现系统瓶颈。

压测创建方式

PTS支持以下4种方式创建压测场景（或称压测用例），如下图所示：

说明：

方式一：PTS自研零编码可视化编排，使用自研强大引擎压测。

方式二： 使用PTS自研云端录制器，零侵入录制业务请求并导入1中的自研交互中进行进一步设置。

方式三： 将导入脚本压测 1中的PTS自研交互中，使用PTS自研引擎。

方式四：JMeter压测并使用原生JMeter引擎进行压测，PTS提供自定义的压力构造和监控数据汇聚等产品服务。

其中，方式一、二、三由于使用了PTS的自研引擎，具备RPS（Requests per Second）吞吐量压测模式、秒级启动、实时控制、定时压测和流量遍布全国运营商网络的差异化能力。

方式一是PTS最核心的一种压测场景创建方式，所有资源包均可使用。其他几种创建方式面向不同规格资源包开放。

适用于多业务场景

不论您处于哪个行业，在以下业务场景（但不限于），PTS都是您值得信赖的性能测试工具。

适用行业广泛

PTS应用行业广泛，涉及电商、多媒体、金融保险、物流快递、广告营销、社交等等。

PTS服务阿里巴巴全生态多年，支持了天猫双11、双12、年货节等大促活动。植根于电商行业的PTS，对电商的典型业务模型支持得更友好，压测来源更广泛，脉冲能力和流量掌控能力更强。

PTS自商业版发布以来，吸引了来自多媒体、金融保险、政务等众多行业的用户，以其强大的压测场景编排能力和报表能力，帮助用户快速发现问题，进行针对性地调优，提升了系统承压能力。

适用于多种网络环境

不论您的业务位于公有云、专有云、混合云或者自建IDC中，只要能够通过公网访问，PTS都能够通过遍布全国上百个城市和各运营商的CDN节点发起压测流量，最大程度地模拟真实业务场景。

适用于使用HTTP/HTTPS/WebSocket等协议的客户端

PTS本身的GUI模式支持HTTP/HTTPS协议的压测，无论您的客户端是自研的App、移动端网页、PC端网页、微信小程序还是C/S结构的软件，都可以使用PTS进行压测。PTS同时集成了开源JMeter，支持更多的协议和场景，例如您可以通过“JMeter + WebSocket插件”的方式，对使用WebSocket协议的客户端进行压测（在PTS上传相应的插件JAR文件即可），其他协议以此类推。

下面以电商典型业务场景为例，为您介绍如何在PTS中编排压测场景。

什么是压测场景

要发起一次性能压测，首先需要创建一个压测场景。压测场景中包含一个或多个并行的业务，每个业务包含一个或多个串行的请求。

示例

淘宝网需要对产品A和B相关的页面（即存在多个API）进行压测，假设其主要业务场景为：

业务A：浏览产品A。

业务B：购买产品B（登录 → 浏览产品B → 加入购物车 → 提交订单）。

那么在压测场景中的设置如下。

串联链路1：浏览产品A 和串联链路2：购买产品B是并行关系。

根据业务逻辑，一部分用户在浏览产品A，另一部分用户在进行购买产品B的一系列操作，即两个业务是同时发生的，所以将它们设置为两个串联链路，压测中会并行发起请求。

串联链路中的多个API是串行关系。

根据业务逻辑，串联链路2：购买产品B中的一系列用户行为是存在先后顺序的，所以将这些存在先后关系的API添加到一个串联链路中，PTS压测中会按照顺序发起压测。

综合来看，在压测中，示例中的浏览产品A的API和登录的API，会同时发起压测流量。更多性能测试PTS场景示例，可参考阿里云帮助资料： 性能测试 PTS>最佳实践

HTTP 是客户端-服务器计算模型中的请求-响应协议。要开始交换，客户端向服务器提交请求。为了完成交换，服务器向客户端返回响应。服务器只能向一个客户端发送响应 （发出请求的那个） 。在 HTTP 协议中，客户端是消息交换的发起者。

服务器发送事件 (SSE) 是一种简单的技术，用于为特定的 Web 应用程序实现服务器到客户端的异步通信。

有多种技术允许客户端从服务器接收有关异步更新的消息。它们可以分为两类： 客户端拉取 和 服务器推送 。

在客户端拉取技术中，客户端会定期向服务器请求更新。服务器可以使用更新或尚未更新的特殊响应进行响应。有两种类型的客户端拉取：短轮询和长轮询。

客户端定期向服务器发送请求。如果服务器有更新，它会向客户端发送响应并关闭连接。如果服务器没有更新，它也会向客户端发送一个响应并关闭连接。

客户端向服务器发送请求。如果服务器有更新，它会向客户端发送响应并关闭连接。如果服务器没有更新，它会保持连接直到更新可用。当更新可用时，服务器向客户端发送响应并关闭连接。如果更新在某个超时时间内不可用，服务器会向客户端发送响应并关闭连接。

在服务器推送技术中，服务器在消息可用后立即主动向客户端发送消息。其中，有两种类型的服务器推送：SSE和 WebSocket。

SSE 是一种在基于浏览器的 Web 应用程序中仅从服务器向客户端发送文本消息的技术。SSE基于 HTTP 协议中的持久连接， 具有由 W3C 标准化的网络协议和 EventSource 客户端接口，作为 HTML5 标准套件的一部分。

WebSocket 是一种在 Web 应用程序中实现同时、双向、实时通信的技术。WebSocket 基于 HTTP 以外的协议（TCP），因此可能需要额外设置网络基础设施（代理服务器、NAT、防火墙等）。

客户端通过Http协议请求，在握手阶段升级为WebSocket协议。

在数据字段中，服务器可以发送事件数据

服务器可以发送唯一的事件标识符（id字段）。如果连接中断，客户端会 自动重新连接 并发送最后接收到的带有header的 Last-Event-ID 的事件 ID。

在重试字段中，服务器可以发送超时（以毫秒为单位），之后客户端应在连接中断时自动重新连接。如果未指定此字段，则标准应为 3000 毫秒。

如果一行以冒号字符 : 开头，客户端应该忽略它。这可用于从服务器发送评论或防止某些代理服务器因超时关闭连接。

要打开连接，应创建一个 EventSource 对象。

尽管 SSE 旨在将事件从服务器发送到客户端，但可以使用 GET 查询参数将数据从客户端传递到服务器。

要关闭连接，应调用方法 close()。

有表示连接状态的 readyState 属性：

客户端接收消息并处理他们，可以使用onmessage方法

SSE可被大多数浏览器支持：

Spring Web MVC 框架 520 是基于 Servlet 31 API 且用线程池实现异步应用程序 所以应用能够被使用在 Servlet 31+ 的容器，比如：Tomcat 85 和 Jetty 93

使用Spring MVC来发送事件:

示例：

在这个例子中，服务器每秒发送一个持续时间短的周期性事件流 - 一个有限的词流，直到词完成。

示例：

运行效果：

客户端示例（wordshtml）：

运行效果：

在此示例中，服务器发送持久的周期性事件流 - 每秒可能无限的服务器性能信息流：

效果预览（每秒输出一次）：

非周期性是指没有固定的时间周期，可能由其他因素在任意时刻都可能触发，下面示例通过spring event来模拟触发因子。

效果:

模拟触发动作：调用 http://localhost:8080/sse/mvc/triggereventType=customer

客户端收到数据：

Spring Web Flux 框架 520 是基于 Reactive Streams API 且使用 event-loop 计算模型来实现异步java应用程序。 此类应用程序可以在非阻塞 Web 服务器（例如 Netty 41 和 Undertow 14）和 Servlet 31+ 容器（例如 Tomcat 85 和 Jetty 93）上运行。

使用 Spring Web Flux 框架实现发送事件：

简单示例：

和上面spring mvc的示例一样，也是每秒输出数据，实现如下：

效果：

对比spring mvc的实现，我们改为flux实现，如下：

效果和上面是一样的，可以看出，reactive api是非常的简洁。

后台更改前台的内容，常用的方法有两种，一是通过AJAX方式完成页面的局部刷新，二是通过WebSocket实现服务器主动推送数据到前台。

在前台使用AJAX时，可以通过监控后台发送过来的返回数据，然后更新前台的内容。在服务器端修改数据时，前端页面可以实时响应，不需要刷新整个页面。通过AJAX方式可以实现前后端分离，提高了系统的性能和页面的友好度。

如果使用WebSocket实现服务器主动推送数据到前台，则需要在前后端同时建立WebSocket连接，当后台修改数据时，便可以主动向前端发送消息，以实现实时更新前端页面内容的效果。

无论哪种方法，前台都需要通过不同的技术手段从后台获取数据，并且格外注意安全性，以避免可能的安全问题。

问题解答

目前，EasyWebsocket不仅存在兼容性问题，而且，还无法解决复杂系统的兼容性问题。事实上，

EasyWebsocket将WebSocket封装成了一个库, 如果浏览器支持WebSocket则直接使用HTML5 WebSocket, 如果不支持它会将你的Socket请求发送给它用nodejs写的中转服务器上, 然后再通过Ajax方法从它的Server返回到用户的浏览器上

先说结论，对于容量和性能：

服务器资源： 8核16G内存， 6个机械磁盘，每个磁盘100G， 用于mongo分片，10MB带宽。

容量：用户容量10万以上，消息条数10亿条。

性能评估：同时在线用户10万，每秒钟发送消息900条，消息延时1秒（从发送者发出消息到接收到消息）

启动sdk，模拟50个用户在线、离线情况，消息可靠性100%。

发送10万消息，有3条失败，其他消息都能被对方精确收到，并成功落地本地db。对于失败的3条消息，接收方确实没有收到，系统消息是一致的。

OpenIM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包括IM服务端和客户端SDK，是一套整体的解决方案，代码开源，一切可控，

OpenIM可以实现全平台支持，目前支持Android，iOS，Flutter，Uni-app，react-native, JSSDK等。

OpenIM可以应用在企业内部办公，dating交友，在线客服等项目，也可以用于元宇宙。

github地址：https://githubcom/OpenIMSDK/Open-IM-Server

开发者中心: https://docrentsoftcn/#/

在单机的情况下，模拟线上用户发消息流程，在线用户量和消息量达到一定量级后，系统CPU、内存、磁盘占用、以及消息时延情况。以确定用户群体达到一定量级后，对服务器资源的预先评估。本次测试并不极限测试，一是因为生产环境本来都会有用户量和消息量的限制，二是因为OpenIM的消息模型，消息发送首先都会通过websocket入库kafka，理论上发送消息的写入性能是两者的组合，而消息发送的真正瓶颈实际在mongodb的随机读写。

服务器资源： 腾讯云主机（香港）1台：linux Ubuntu 18044系统，4核8G内存，单块机械硬盘。5Mb带宽。

测试条件：去掉消息入库mysql（因mysql仅用于管理后台，不影响线上用户服务）。日志级别调整为4或更低。kafka设置2个分区，msg_transfer 2个。

测试流程：1个客户端（成都，window pc，4核16G内存）启动1万个协程，模拟用户与服务器建立websocket长连接，间隔时间为随机50-100秒之间。两个客户端共模拟2万用户同时在线，发送消息，观察消息流转各个模块的处理能力，共计2500万条消息，观察系统内存、磁盘资源使用情况。

mongodb数据情况

redis数据情况

磁盘状态

资源占用分析

（1）redis内存消耗极小，一个用户一条数据（包括token和seq），和用户量成正比，3万用户占用几十M内存。

（2）mongodb如果去掉cache，内存消耗极小，每个document存放5000条消息，与用户量和消息量成正比，3万用户，2500万消息，索引才950K（更好的方式查看mongo消耗cache之外的内存）

（3）2500万消息，磁盘空间占用10G。

（4）每秒钟150条消息，cpu整体占用50%，即2核。

性能分析

（1）性能瓶颈在mongodb写入操作，1条消息，需要按照发送者和接收者拆分2次，mongodb写入2次，未来可以针对mongodb读写进一步优化。

（2）对于cpu消耗较大的模块，未来做一次整体优化。

（3）性能很平稳，不会随着数据量增加而降低。机械磁盘iops 达到200基本达到了设备的极限

服务器资源： 8核16G内存， 6个磁盘，每个磁盘100G， 用于mongo分片，10MB带宽。

性能评估：同时在线用户10万，每秒钟发送消息900条，消息延时1秒（从发送者发出消息到接收到消息）

（1）mongo集群部署，支持上亿用户同时在线，千亿级消息；

（2）简化集群部署；

（3）数据备份、恢复工具；

以上主要对服务端性能做了一个大致测试，但一套完整的IM解决方案，不仅仅是服务端的工作。实际上，客户端重要性毋庸置疑，具体包括如何利用seq和服务端同步消息，如果保证消息收发的时序，如何回调客户端（会话改变、新增，新消息），消息落地本地db，seq同步，消息推拉如何结合以确保消息收发可靠性。

相比于性能测试，实际上，消息的可达性（可靠性）更为重要。所以，我们在做性能测试的同时，也要对消息的可达性（可靠性）进行测试，如果不能保证消息收发的正确性，再高的性能也是徒劳。本文重点总结关于OpenIM对于消息可达性测试的方案、过程以及结果。先说结论，OpenIM消息可达率100%，大家可以放心使用在生产环境中。seq对齐和同步机制，保证了OpenIM的消息可达性是业界领先的。

IM消息系统的可靠性，通常就是指消息投递的可靠性，即我们经常听到的“消息必达”，通常用消息的不丢失和不重复两个技术指标来表示。确保消息被发送后，能被接收者收到。由于网络环境的复杂性，以及用户在线的不确定性，消息的可靠性（不丢失、不重复）无疑是IM系统的核心指标，也是IM系统实现中的难点之一。总体来说，IM系统的消息“可靠性”，通常就是指聊天消息投递的可靠性（准确的说，这个“消息”是广义的，因为还存用户看不见的各种指令和通知，包括但不限于进群退群通知、好友添加通知等，为了方便描述，统称“消息”）。

从消息发送者和接收者用户行为来讲，消息“可靠性”应该分为以下几种情况：

（1）发送失败，对于这种情况IM系统必须要感知到，明确反馈发送方。如果此消息没有发送成功，发送方可以选择重试或者稍后再试。

（2）发送成功，如果接收方处在“在线”状态，应该立即收到此消息。如果接收方处在“离线”状态不能收到消息，一旦上线则立刻收到消息。

（3）消息不能重复，用数学术语表示：“有且仅有这条消息”，如果重复了，可能表达的意思就变了。 总之，一个商用 IM系统，必须包含消息“可靠性”逻辑，才能谈基本可用，这是IM系统最基本也是最核心的逻辑。

互联网真实场景复杂，但客户端大体可以分为两种情况：（1）发送消息时，接收方在线，能收到消息；（2）发送消息时接收方不在线，登录后能收到离线消息。我们用测试程序模拟互联网客户端各种场景，按照登录、发送消息、接收消息的情况，把测试客户端分为以下2种类型：

（1）启动测试时离线，随机sleep 0-60 秒后登录，发送消息，且接收消息

（2）启动测试时离线，随机sleep 0-60 秒后登录，不发送消息，只接收消息

在实际测试中共计50个客户端，约25个（50%概率）客户端不发送只接收消息，约25个（50%概率）客户端发送且接收消息 。

发送模式：每个客户端随机选择其他客户端作为消息接收者；

测试预期： 每一条发送成功的MsgID，都能在接收的消息列表中找到，同样，每一条接收到的MsgID，都能在发送成功的消息列表中找到。

具体做法：（1）消息发送成功后，通过OnSuccess回调，记录MsgID； 收到新消息后回调OnRecvNewMessage，记录MsgID；（2）周期性对比两个消息列表，确认是否完全一致；

发送数据100000条，其中失败3条，9999997条成功，接收方成功接收9999997条消息（接收方成功接收到消息，写入本地db，并能触发消息回调）

每一条发送成功的消息，对方都能准确接收到，无论接收方在消息发送时的登录状态是在线还是离线。

每一条发送失败的消息，对方都不会收到。

注意事项：

（1）控制压力，因为sdk需要写本地db，客户端会成为压力瓶颈。

（2）压测客户端日志会影响测试性能。

此表格是某IM云平台的价格，如果按照10万月活，存储三年消息来算，大概每年需要支付15万。而采用OpenIM只需要采购云主机，每年成本约08万。

云服务器有什么作用？

1Web服务

对于有网站空间需求的中小企业和个人建站来说，租用云服务器是个不错的选择。云服务器即买即用，拥有多种带宽选择，还可使用独立的IP，省钱而又享有独立主机的各种资源，满足中小企业网站发展需求。

2Email邮件服务器

云服务器拥有高性能的数据处理能力，不仅能够储存数据，而且还能够快速的处理数据，所以云服务器用来作为Email邮件服务器使用也是一个不错的选择。

3小程序后端

在小程序的生产环境中，如果需要调用服务器的RESTAPI或WebSocket，服务器必须提供安全的链接地址。也就是说，服务器需要使用SSL加密数据。因此，我们需要在服务器中配置SSL加密。

4APP后端

搞软件开发的人都知道，对于一些网络应用软件必须要租用服务器存放才能被更多用户使用。如一些应用于浏览软件、传输软件、远程登录软件等。如果是像以往那样租用物理机服务器，成本费用非常高昂。但是现在有云服务器的选择可以节约了不少成本。

云服务器其实和虚拟主机的作用差不多，但采用集群式的方式，让使用更加的安全。相比来说，使用起来也方便很多，而且灵活很多，但本质还是一样的。运算能力超强，用户通过电脑等方式接入数据中心，按自己的需求进行运算。提供了便捷的、高效的网络访问。搭配其他云计算资源即可轻松搭建IT架构，满足不同量级需求。

云服务器的特点:

1．稳定性和安全性高。云服务器采用分布式存储，支持云镜像，同时存储4份数据，确保数据安全性。

2．灵活性好。云服务器升级灵活，配置可以随意调节。

3．可靠性高。支持热迁移，支持快速故障迁移。

4自助服务性。支持在线重置服务器密码，支持多服务器内网连接，支持用户自主安装系统。

5支持负载均衡解决方案。

使用云服务器作用与好处：

1、多地域性覆盖

丰富的地域选择为业务保驾护航：华北、华东、华南三大地域全面覆盖国内业务需求，境外香港、北美、新加坡等地域满足业务出海需求。

2、稳定可靠

基于成熟的kvm虚拟化技术；提供9995%服务可用性；提供配置更高、性能更强的二代系列，以及标准型、高IO型、内存型、计算型等不同机型满足不同需求

3、高质量网络

BGP网络支持国内所有主流运营商接入，覆盖全国的极速公网体验；公网入口故障时跨域秒级调度

4、成本低廉

提供两种计费方式，满足不同应用场景－包年包月：平均单价较低，适合较长时间需要计算资源的用户；按量计费：适合秒杀大促等突发资源需求，阶梯收费、使时间越长单价越低

   原生支持： iOS13开始，使用URLSessionWebSocketTask类可实现像发送HTTP请求一样的WebSocket功能。如果要对Web套接字（包括客户端和服务器支持）进行较低级别的控制，请查看Network框架： https://developerapplecom/documentation/network 。

一、Socket

    是对TCP/IP 协议的封装，本质并不是一个协议，是应用层与 TCP/IP 协议族通信的中间软件抽象层（类似于对底层的封装），它是一组接口，让你在使用的时候更方便操作。

二、WebSocket协议

    是HTML5下一种新的协议，也是基于TCP的一种网络协议，它实现了 浏览器/客户端 与 服务器 全双工(full-duplex)通信——连接成功以后允许服务器或客户端的任何一方主动发送信息给对方。WebSocket协议由两部分组成： 握手 和 数据传输 。Websocket是一个持久化的协议，只需要一次成功的HTTP握手，服务端会一直保留握手成功时的信息，直到客户端或服务端关闭请求。

    创建了WebSocket后，会有一个HTTP请求发送到服务器以发起连接。取得服务器响应后，建立的连接使用HTTP升级，从 HTTP协议 交换为 WebSocket协议 。WebSocket使用了自定义的协议，未加密的连接不再是 http:// ，而是 ws:// ，默认端口为 80 ；加密的连接也不是 https:// ，而是 wss:// ，默认端口为 443 。即，使用标准的HTTP服务器无法实现WebSocket，只有支持WebSocket协议的服务器才能正常工作。一旦WebSocket连接建立后，后续数据都以 帧序列 的形式传输。

    WebSocket协议的特点包括：

    （1）建立在 TCP 协议之上。

    （2）与 HTTP 协议有着良好的兼容性。握手阶段采用 HTTP 协议，默认端口也是80和443，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

（3）数据格式比较轻量，性能开销小，通信高效。如何体现通信高效？WebSocket通信格式没有HTTP协议那么多的固定报头，且不用重复建立连接。

（4）可以发送文本，也可以发送二进制数据。

（5）没有同源限制，客户端可以与任意服务器通信。（什么是同源限制？协议相同，域名相同，端口相同。目的是为了保证用户信息的安全，防止恶意的网站窃取数据。）

（6）协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。

（7）WebSocket通信协议于2011年被IETF定为标准RFC 6455，WebSocket API被W3C定为标准。

WebSocket如何实现长链接 ？创建了WebSocket后，会有一个HTTP请求发送到服务器以发起连接。取得服务器响应后，建立的连接使用HTTP升级，从HTTP协议交换为WebSocket协议。只需要一次成功的HTTP握手，服务端会一直保留握手成功时的信息，直到客户端或服务端关闭请求。WebSocket之所以能持久连接原因是它运行在TCP协议上，TCP协议自身是长连接协议，所以WebSocket当然可以长连接啦。

WebSocket如何管理连接 ？RFC6455-55意见稿指明：WebSocket协议定义了Control Frame 控制帧。WebSocket的控制帧有： Close 、 Ping 、 Pong 。

Close帧 ：发起关闭请求；

Ping帧 ：通信发起方确认链路是否畅通的报文；

Pong帧 ：通信接收方回应链路是否畅通的报文。

WebSocket在建立连接之后，通信的基本数据帧格式如下图（来源RFC6455-52）没有Http协议那么多固定的报头，且不用重复建立连接，所以通信效率高：

WebSocket连接的生命周期：

CONNECTING ：使用Http发起请求，RFC6455-4（ https://toolsietforg/html/rfc6455#section-4 ）规定了Client和Server的报文格式。Server在响应时使用Http状态码是101（切换协议）。在握手时，WebSocket连接处于CONNECTING状态。

OPEN ：握手成功之后，进入OPEN状态。

CLOSING ：如果一方发起了CLOSE帧，那么便标志着WebSocket连接进入了CLOSING状态；

CLOSED ：当TCP连接关闭之后，那么WebSocet连接便进入了CLOSED状态。

三、WebRTC

    名称源自 网页实时通信 （Web Real-Time Communication）的缩写，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术，由Google、Mozilla和Opera等支持的、免费的开放式项目。通过简单的API为浏览器和移动应用程序提供跨平台的 音视频实时通信 （RTC：Real-Time Communications ）功能。WebRTC使得开发者在浏览器无需安装任何插件就可以实现音视频通信。

    WebRTC提供了跨平台的音视频核心技术，包括音视频的采集、编解码、网络传输、显示等功能，支持的平台：Windows、Linux、Mac、Android及iOS。RTCPeerConnection是用于进行WebRTC调用以流式传输视频和音频以及交换数据的API，WebRTC使用RTCPeerConnection(对等连接)在浏览器之间传递 流数据 ，但也需要一种协调通信和发送控制消息的机制，这一过程称为 信令 。信令处理过程需要客户端之间来回传递消息，这个过程在WebRTC里面是没有实现的，需要自己创建。即WebRTC未指定信令方法和协议，需要开发者确保使用安全协议。所有WebRTC组件都必须进行加密，即 WebRTC是安全的 （如何保证安全？）。WebRTC这种技术可以让开发者的精力集中在用户体验上而不是媒体流本身，因为API就会处理好媒体引擎的相关工作。

    WebRTC 10 的重点是提供给开发者更多对媒体、数据通道的控制。而根据此前的提案（见后面的提案连接）显示，下一版本的 WebRTC 将有可能使数据处理脱离主线程。使用 RTCDataChannels 传输数据，相比使用 WebSocket 会有更好的拥塞控制。（该段内容笔者未确认）

参考连接： http://wwwsohucom/a/275427719_458408

提案连接： https://wwww3org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19pdf

如何保证安全 ：当连通性检测完成后，WebRTC会开启 DTLS （Datagram TLS）握手，用于协商出SRTP中加密RTP包的 对称秘钥 。该过程称为DTLS-SRTP，保证了数据传输的安全性。

参考： https://imwebio/topic/5a4a6cb2a192c3b460fce37f

RTP/RTCP 和 SRTP/SRTCP协议是什么？参考： https://blogcsdnnet/thinkerleo1997/article/details/80233530

基本概念：

SDP ： 即会话描述协议（Session Description Protocol ），主要保存当前会话的媒体和传输信息，其中媒体信息包括 媒体类型 、 传输协议 、 媒体格式 等，传输信息包括媒体的远程 地址信息 、 带宽 等；它由多行KV格式的文本信息组成，具体可参考这里（ https://toolsietforg/pdf/draft-nandakumar-rtcweb-sdp-08pdf ）。WebRTC通过 信令 建立一个SDP握手的过程，只有通过SDP握手，双方才知道对方的信息，这是建立p2p通道的基础。

Offer ： 通信的发起方对自己的sdp描述

Answer ： 通信的接收方对自己的sdp描述

信令 ：协商通信过程，传递基本的数据信息，其中包括SDP描述信息、会话控制信息（节点加入、退出及各类的业务控制信息等）、网络信息、错误信息等。是指控制建立连接和断开连接的状态的数据。在建立连接之前，信令必须发生在 带外 （通过服务器），但一旦建立连接，就可以通过已经建立的通道发送更新信令（如挂断）。（这里要了解一下什么叫“带外（OOB：Out-Of-Band）”，： https://baikebaiducom/item/out-of-band/15801641fr=aladdin ）

OOB概述 ：传输层协议使用 带外数据 （out-of-band，OOB）来发送一些重要的数据，如果通信一方有重要的数据需要通知对方时，协议能够将这些数据快速地发送到对方。为了发送这些数据，协议一般不使用与 普通数据 相同的通道，而是使用另外的通道。linux系统的套接字机制支持低层协议发送和接受带外数据。但是TCP协议没有真正意义上的带外数据。为了发送重要协议，TCP提供了一种称为 紧急模式 （urgent mode）的机制。TCP协议在数据段中设置 URG 位，表示进入紧急模式。接收方可以对紧急模式采取特殊的处理。很容易看出来，这种方式数据不容易被阻塞，并且可以通过在我们的服务器端程序里面捕捉 SIGURG 信号来及时接受数据。

信令通道 ：与服务端建立连接和断开连接的通道，对于WebRTC而言就是信令通道。

STUN 服务器：是用来取外网地址的。

TURN 服务器：是在P2P失败时进行转发的，中继转发。

STUN 和 TURN 服务器的作用主要处理打洞与转发，配合完成 ICE协议 。

ICE ：Interactive Connectivity Establishment，交互式连接建立。

WebRTC通信

基于WebRTC的点对点音视频通信流程如下：

1）客户端A初始化本地音视频设备，创建一个用于Offer的SDP对象，该对象中保存当前音视频的相关信息；

2）客户端A通过信令服务器将SDP信息发送给客户端B；

3）客户端B接收到A的SDP信息后保存，初始化本地音视频设备并创建用于Answer的SDP对象；

4）客户端B通过信令服务器将SDP信息发送给客户端A；

5）客户端A、B通过交换SDP等信息，建立P2P通道进行音视频传输；

示意图如下图所示：

WebRTC ICE（交互式连接建立）(ICE：Interactive Connectivity Establishment)

    以下是呼叫信令期间发生的消息交换的高级过程，即： WebRTC 信令交互流程图 ：

开始

##关键词

--[SOMETHING]-->：表示从主叫方发送给被叫方的“SOMETHING”类型的消息。另一解释是： 主叫方所要执行操作 。

<--[SOMETHING]--：表示从被叫方发送给主叫方的“SOMETHING”类型的消息。另一解释是： 被叫方所要执行的操作 。

SS (Signal Service)：通过服务器发送的信息（通过BCM 服务器发送的信息）

DC (Data Channel)：通过WebRTC 数据通道 发送的消息

### Message Exchange / State Flow Overview （消息交换/状态流概述）

|          Caller（主叫方）          |          Callee（被叫方）    |

+----------------------------+-------------------------+

开始拨出电话：`handleOutgoingCall`

                        --[SSCallOffer]-->

…并开始生成iceCandidate候选，先保存在本地。iceCandidate里面包含了SDP、公网地址、用来标识当前ice中流媒体的id(sdpMid)，这个公网地址是由STUN、TURN Server发过来的。

当生成iceCandidate候选后，将会调用方法`handleLocalAddedIceCandidate` ，并把这些iceCandidate保存起来。

                                                    被叫方收到来电，通过 `handleReceivedOffer` 发送呼叫应答

                                                    <--[SSCallAnswer]--

                                                    1 开始生成iceCandidate候选。

                                                    2 立即通过`handleLocalAddedIceCandidate` 将它们发送给主叫方。

                                                    <--[SSICEUpdate]-- (多次发送)

主叫方收到应答后调用方法: `handleReceivedAnswer`，接着发送所有前面保存的iceCandidate候选 (在此之后生成的iceCandidate候选会立即发送)

--[SSICEUpdates]--> (多次发送)

完成交换iceCandidate候选后…（此时表示双方身份已确认，接下来会通过P2P通道建立音视频会话，这里会涉及NAT技术，有可能失失败。如果失败，主叫方会一直显示呼叫中，被叫方不会显示任何界面）双方都调用方法: `handleIceConnected`

显示远程铃声用户界面

1连接到提供的数据通道

2显示来电界面

3如果被叫人接听电话

4发送连接消息

                                                    <--[DCConnectedMesage]--

接收到的连接消息后显示呼叫已连接。

主叫方挂断（被叫方同样可以挂断）调用方法：

--[DCHangup]-->

--[SSHangup]-->

结束

上面的消息交换可以整理为如下的简化版的WebRTC建立连接过程：

1）主叫方通过 createOffer 生成 SDP 描述

2）主叫方通过 setLocalDescription，设置本地的描述信息

3）主叫方将 offer SDP 发送给被叫方

4）被叫方通过 setRemoteDescription，设置远端的描述信息

5）被叫方通过 createAnswer 创建出自己的 SDP 描述

6）被叫方通过 setLocalDescription，设置本地的描述信息

7）被叫方将 anwser SDP 发送给主叫方

8）主叫方通过 setRemoteDescription，设置远端的描述信息。

只有通过 SDP握手 ，双方才知道对方的信息，这是建立p2p通道的基础。 通过SDP握手后，客户端之间就会建立起一个点对点的直接通讯通道。但是由于我们所处的网络环境错综复杂，用户可能处在私有内网内，使用p2p传输时，将会遇到 NAT (网络地址转换)以及防火墙等阻碍。这个时候我们就需要在SDP握手时，通过STUN/TURN/ICE相关 NAT穿透技术 (也有称为 打洞 或 穿墙 技术)来保障p2p链接的建立。

WebRTC的视频部分 ，包含采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。

    视频采集支持多种媒体类型，比如I420、YUY2、RGB、UYUY等，并可以进行帧大小和帧率控制。

    WebRTC采用I420/VP8编解码技术。VP8是Google收购ON2后的开源实现，并且也用在WebM项目中。VP8能以更少的数据提供更高质量的视频，特别适合视频会议这样的需求。

    视频加密是WebRTC的video_engine一部分，相当于视频应用层面的功能，给点对点的视频双方提供了数据上的安全保证，可以防止在Web上视频数据的泄漏。

    视频加密在发送端和接收端进行加解密视频数据，密钥由视频双方协商，代价是会影响视频数据处理的性能；也可以不使用视频加密功能，这样在性能上会好些。

视频加密的数据源可能是原始的数据流，也可能是编码后的数据流。估计是编码后的数据流，这样加密代价会小一些，需要进一步研究。

WebRTC的音频部分 ，包含设备、编解码(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控(RTP/RTCP)等功能。

    WebRTC采用iLIBC/iSAC/G722/PCM16/RED/AVT编解码技术。

    WebRTC还提供NetEQ功能---抖动缓冲器及丢包补偿模块，能够提高音质，并把延迟减至最小。

    另外一个核心功能是基于语音会议的混音处理。

    声音处理针对音频数据进行处理，包括回声消除(AEC)、AECM(AEC Mobile)、自动增益(AGC)、降噪(NS)、静音检测(VAD)处理等功能，用来提升声音质量。

丢包补偿原理是什么？

自动增益（AGC：Automatic Gain Control）概念？

TCP协议 ：属于传输层，是可靠的、面向连接的。主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。TCP连接的建立依靠“三次握手”，而释放则需要“四次握手”。

IP协议 ：属于网络层，主要解决 网络路由和寻址 问题。

Http协议 ：属于应用层协议，一个简单的请求-响应协议，是一种无状态、非持久的协议，是被动性的，也就是只能客户端发起。服务端不保留上一次与客户端交互时的任何状态，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁。HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP11支持keep-alive。

Http与WebSocket区别与联系

（1）Http与WebSocket是两个完全不同的协议，都是基于TCP的。两者唯一的联系是WebSocket利用Http进行握手；具体说明请看：RFC6455-17( https://toolsietforg/html/rfc6455#section-55 )

（2）WS默认也使用80端口；WSS默认也使用443端口。

（3）Http协议局限性一大堆，比如明文传输、无法保证信息完整性、没有身份验证等。而WebSocket的出现则是为了解决Http协议只能由Client发起通信请求的问题。WebSocket是 全双工通信 。

（4）HTTP是运行在TCP协议传输层上的应用协议，而WebSocket是通过HTTP协议协商如何连接，然后独立运行在TCP协议传输层上的应用协议。

    WebSocket仅仅是利用了HTTP协议做连接请求。WebSocket相当于一个简化版的TCP传输子层（实际上WebSocket也是应用层协议）。WebSocket之所以能持久连接原因是它运行在TCP协议上，TCP协议自身是长连接协议，所以WebSocket当然可以长连接啦。如果你要问为什么HTTP不是长连接，原因是早期的HTTP在发起每个请求，响应完成后就会关闭Socket。但是后来加了多路复用KeepAlive协议后HTTP协议已经可以实现长连接了，可以处理长连接事务了。至于添加WebSocket特性，是为了更好、更灵活，轻量的与服务器通讯。因为WebSocket提供了简单的消息规范，可以更快的适应长连接的环境，其实现在HTTP协议自身就可以做，但是不太轻便，因为HTTP是一种无状态、非持久的协议，是被动性的，也就是只能客户端发起。服务端不保留上一次与客户端交互时的任何状态，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁，每次请求和应答都带有完整的Http头，占用网络传输带宽，增加了每次传输的数据量。为什么HTML4不支持WebSocket？原因是WebSocket的协商机制HTML4底层API没有实现。

WebSocket与Socket是没什么关系的

WebSocket协议 和 Http协议： 都是基于TCP的，所以他们都是可靠的协议，是在应用层。

Socket： 是对TCP/IP 协议的封装，本质并不是一个协议，是应用层与 TCP/IP 协议族通信的中间软件抽象层（类似于对底层的封装），它是一组接口，让你在使用的时候更方便操作。

WebSocket与WebRTC(Web Real-Time Communication)是什么关系？

WebSocket： 是WebRTC的基础，为WebRTC负责客服端发现和数据转发。

TCP协议 ：参考 https://blogcsdnnet/Awille/article/details/79748193

SocketRocket ：Facebook的开源框架

WebRTC开发和VoIP开发之间有什么区别与联系？

待完善知识点：WebRTC移动端兼容性检测，如何配置MediaStreamConstraints， 信令(iceCandidate, sessionDescription)传输方式的选择，iceCandidate和sessionDescription设置的先后顺序，STUN和TURN的概念，如何实现截图及录制视频及上传和视频功能，如何高效跟踪错误？

WebRTC拥塞控制和码率调节策略是怎么样的？在弱网环境下如何保证图像不失真？

猜：好像是改RTCRtpEncodingParameters这个类里的ssrc参数。是改采样频率？

参考资料：

WebRTC百科： https://baikebaiducom/item/WebRTC/5522744fr=aladdin

WebRTC基础知识： https://webrtcorgcn/category/basic/

GoogleWebRTC-pod安装文档：https:// cocoapodsorg/pods/GoogleWebRTC

GoogleWebRTC-iOS官网： https://webrtcorg/native-code/ios/