《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。
大家都知道音视频应用中的QoS策略是非常重要的部分，这里我简单为大家介绍一下WebRTC网关服务端的QoS内容，因为篇幅问题，具体的算法细节这里就不作阐述了。
本篇文章分享的内容会涉及：NACK、PLI、RTT、GCC算法、REMB与Transport-CC，ULP-FEC。
WebRTC的QoS是一个非常大的门类，也是非常重要的方向，它里面涵盖的内容非常多。有大量的QoS策略是在客户端上实现的。而对于Web来说，那些客户端侧的策略你是没办法修改的，只能通过SDP里面的配置项，来选择需要开启的策略。
《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。
在分享完端口方案与PeerConnection的方案后，本篇文章我们将讲解如何优化WebRTC网关服务器的线程方案。这个也是网关服务器架构设计的核心部分。
我们做WebRTC网关服务器的时候，不仅要考虑功能可用，还要考虑并发性能。有三种方案可以选择：
我们看一下这个方案具体是怎么做的？
《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。
《聊聊WebRTC网关服务器》第二篇文章将和大家分享如何选择PeerConnection方案。
ICE概要
一、ICE产生的背景
基于信令协议的多媒体传输是一个两段式传输。首先，通过信令协议（如SIP）建立一个会话连接，通过该连接，会话双方（Agent）通过SIP交互所承载的SDP消息彼此学习传输媒体时所必须的信息，针对媒体传输机制达成共识。然后，通常采用RTP协议进行媒体传输。
基于传输效率的考虑，通常在完成第一阶段的交互之后，通信双方另外建立一条直接的连接传输媒体。这样就会减少传输时延、降低丢包率并减少开销。这样，用于SIP传输的链路就不再用于传输媒体。现在，问题出现了，由于不采用原来的链路，当传输双方中任一方位于NAT之后，新的传输链接必须考虑NAT穿越问题。
通常有四种形式的NAT，对于每一中NAT方式，都有相应的解决方案。然而，每一种NAT穿越解决方案都局限于穿越对应得NAT方式，对于复杂的网络环境来说，将会出现无法进行媒体传输的情况，同时这些方案给整个系统带来了在不同程度上的脆弱性和复杂性。
在这种背景下，Interactive Connectivity Establishment（交互式连通建立方式）也即ICE解决方案应运而生。ICE方式能够在不增加整个系统的复杂性和脆弱性的情况下，实现对各种形式的NAT进行穿越，使得媒体流在通信双方顺利传输。
导读：疫情期间，视频会议等远程办公产品备受青睐，众多互联网玩家切入视频会议市场，加剧市场竞争。但是，产品虽多，能够带来稳定可靠体验的产品却凤毛麟角，它的难点在哪里？视频会议的门槛到底有多高，又能够做到怎样的极致体验？网易智慧企业流媒体服务器天团将会从0到1，和大家分享如何基于WebRTC来搭建一个视频会议。
先请出我们今天的主角 - WebRTC，它是由谷歌推广的实时音视频技术栈，是音视频领域搜索热度最高的技术。它有多重身份，既是W3C的标准，也是一个开源项目，还有一个对应的IETF工作组(RTCWEB)。在WebRTC出现之前，音视频通信是高不可攀的领域，需要大量的专业积累才能入门，而现在，越来越多的开发者通过WebRTC来深入了解RTC技术。
WebRTC技术的本质是构建点对点的实时通信，目前主流的浏览器，包括Chrome, Firefox, Edge等，天然就支持WebRTC协议。对入门开发者来说，选用这几款浏览器，连开发客户端的时间都省了。最简单的Web视频会议，只需要架设一个Web服务器，服务器兼具信令交换的能力(信令服务也可以独立部署)，两个浏览器通过Web Server交换会话信息，就能建立P2P通道来传输媒体流，进行1v1的视频会议。如下图所示。
《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。
《聊聊WebRTC网关服务器》第一篇文章将和大家分享如何选择服务端的端口方案。
在讨论如何选择服务器端的端口方案前，我们先来看看标准WebRTC的连接建立流程，这为我们理解这篇文章后续内容提供最基础的知识。
一、什么是SDP
SDP(Session Description Protocol)描述会话协议，它只是一种信息格式的描述标准，本身不属于传输协议，但是可以被其他传输协议用来交换必要的信息，用于两个会话实体之间的媒体协商。
SDP（Session Description Protocol）是一个用来描述多媒体会话的应用层控制协议，为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述；它是一个基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围；SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现。
会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。SDP 即用于将这种信息传输到接收端。在因特网组播骨干网（Mbone）中，会话目录工具被用于通告多媒体会议，并为参与者传送会议地址和参与者所需的会议特定工具信息，这由 SDP 完成。SDP 连接好会话后，传送足够的信息给会话参与者。SDP 信息发送利用了会话通知协议（SAP），它周期性地组播通知数据包到已知组播地址和端口处。这些信息是 UDP 数据包，其中包含 SAP 协议头和文本有效载荷（text payload）。这里文本有效载荷指的是 SDP 会话描述。此外信息也可以通过电子邮件或 WWW （World Wide Web） 进行发送。SDP 文本信息包括：会话名称和意图； 会话持续时间； 构成会话的媒体； 有关接收媒体的信息（地址等）。
写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析，
其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。
互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。
目录：
一、 WebRTC学习进阶之路 --- 概述、原理、源码目录结构与整体架构介绍
二、 WebRTC学习进阶之路 --- 网络编程基础、TCP/IP详解
三、 WebRTC学习进阶之路 --- WebRTC网络知识详解(一)(P2P/NAT/STUN/TURN/ICE)
四、 WebRTC学习进阶之路 --- WebRTC网络知识详解(二)(加解密/SSL/OpenSSL/TLS/DTLS/SRTP)
五、 WebRTC学习进阶之路 --- WebRTC网络知识详解(三)(最全流媒体协议(RTP/RTCP/RTSP/RTMP/MMS/HLS/HTTP/ HTTP-FLV(HDL)/SDP)
六、 WebRTC学习进阶之路 --- Web服务器原理、服务器基础编程知识
七、 WebRTC学习进阶之路 --- WebRTC核心之SDP详解、媒体协商
八、 WebRTC学习进阶之路 --- 信令服务器
九、 WebRTC学习进阶之路 --- 设备管理、音视频数据采集
十、 WebRTC学习进阶之路 --- 非音视频数据传输
十一、WebRTC学习进阶之路 --- 异步I/O时间处理、epoll
十二、WebRTC学习进阶之路 --- 下载源码及各操作系统的源码编译详细步骤
十三、WebRTC学习进阶之路 --- 分析源码音视频互动peerconnection-client+server实例
十四、WebRTC学习进阶之路 --- 源码分析之WebRTC中的线程详解-ThreadManager&Thread
十五、WebRTC学习进阶之路 --- 源码分析之WebRTC中的线程详解-MessageQueueManager&MessageQueue&Message&MessageHandler
十六、WebRTC学习进阶之路 --- 源码分析之最核心的内容PeerConnection
十七、WebRTC学习进阶之路 --- 源码分析之WebRTC的数据流水线详解&模块机制核心ProcessThread与ProcessThreadImpl
十八、WebRTC学习进阶之路 --- 源码分析之视频采集和视频数据的流水线分析