精华内容
下载资源
问答
  • 传输设备基础知识〖 一篇就看懂〗

    千次阅读 2020-06-02 15:55:26
    传输网概念1.1 传输设备在通信网的位置1.2 演进过程1.2.1 PDH(准同步数字系列)特点1.2.2 SDH(同步数字传输体制)特点1.3 SDH设备实现的要点1.4 PDH与SDH的标准速率等级1.5 帧结构二. 传输网特性2.1 SDH信号复用映射...

    一. 传输网概念

    1.1 传输设备在通信网的位置

    传输设备在通信网中主要作用是起到信息的输送
    在这里插入图片描述

    1.2 演进过程

    1.2.1 PDH(准同步数字系列)特点

    PDH主要有两大系列标准:

    • E1,即PCM30/32路,2.048Mbps,欧洲和我国采用此标准。

    • T1,即PCM24/路,1.544Mbps,北美采用此标准。

    • 采用同步复用方式和灵活的复用映射。

    • 没有世界性的标准

    • 没有世界性的标准光接口规范。

    • 由于建立在点对点的传输基础.上的复用结构缺乏灵活性,使得数字通道设备的利用率很低。

    1.2.2 SDH(同步数字传输体制)特点

    SDH全称为同步数字传输体制,它规范了数字信号的帧结构、复用方式、传输速率等级,接口码型等特性。同时,SDH改善了PDH的不利于大容量传输缺点。

    • 采用同步复用方式和灵活的复用映射。
    • SDH网具有信息净负荷的透明性。
    • SDH网还具有定时透明性。
    • SDH网能与现有PDH网络完全兼容。

    1.3 SDH设备实现的要点

    • 同步复用—处理简单
    • 块状帧结构—信息模块化
    • 字节间插—电路上下方便
    • 映射复用—灵活互通
    • 交叉连接—网路调度灵活
    • 指针调整—相位差吸收
    • 分层概念—高效处理
    • 开销字节—网管能力强
    • 分插复用—环网保护,拓扑灵活
    • 横向兼容—互连互通
    • 同步与定时—组网的关键

    1.4 PDH与SDH的标准速率等级

    PDHSDH
    等级速率(Kb/s)等级速率(Mb/s)
    基群2048STM-1155.520
    二次群8448STM-4622.080
    三次群34368STM-162488.320
    四次群139264STM-649953.280

    1.5 帧结构

    PDH帧结构
    在这里插入图片描述
    SDH帧结构
    在这里插入图片描述
    在这里插入图片描述

    SDH是一个将复接、线路传输、交叉连接及交换功能融为一体的,并由统一的网管系统进行管理的综合业务传送网络

    二. 传输网特性

    2.1 SDH信号复用映射结构

    在这里插入图片描述

    2.2 容器

    容器是一种信息结构,主要完成适配功能(速率调整),让那些最常使用的准同步数字体系信号能够进入有限数目的标准容器

    我国使用的其中三种容器

    种类装载信号种类结构速率(Mb/s)
    C-122 Mb/s9行×4列–22.176
    C-334 / 45 Mb/s9行×84列48.384
    C-4140 Mb/s9行×260列149.760

    2.3 虚容器

    由标准容器出来的数字流加上通道开销后就构成了虚容器(VC),这是SDH中最重要的一种信息结构,主要支持通道层连接。

    VC虚容器 是用来支持SDH通道层连接的信息结构
    
    种类装在信号种类结构速率(Mb/s)
    C-122Mb/s9行x4列-12.240
    C-334/45Mb/s9行x85列48.960
    C-4140Mb/s9行x261列150.336

    2.4 支路单元

    支路单元(TU)是一种为低阶通道层与高阶通道层提供适配功能的信息结构,它由低阶VC和支路指针(TU PTR)组成。

    种类构成结构速率(Mb/s)
    TU- 12VC12+TU PTR9行×4列2.304
    TU- 3VC3+TU PTR9行×85列+349.152

    2.5 管理单元

    • 管理单元(AU)是一种为高阶通道层与复用段层提供适配功能的信息结构,它由高阶VC和管理指针(AU PTR)组成。
    • 指针PTR用来指明浮动的VC在高阶VC或 STM-N帧内的起始位置,但PTR本身在高阶VC或 STM-N帧内位置是固定的。

    2.6 支路单元组和管理单元组

    • 同次一致的TU-11或TU-12组合成支路单元组TUG-2,同次的TUG-2或TU-3组合成支路单元组TUG-3。
    • 一个或多个在STM-N帧中占有固定位置的AU组成管理单元组(AUG),单个AU-4可组成一个管理单元组AUG。
    • AUG对于AU-3的复用是有其意义的,对于AU-4的复用意义不大。
    种类构成结构速率(Mb/s)
    TUG- 23×TU-129行×12列6.912
    TUG- 37×TUG-29行×86列49.536

    2.7 SDH传输网的网络管理

    在这里插入图片描述

    三. 网络举例

    在这里插入图片描述
    网络管理图
    在这里插入图片描述

    四. 传输网性能

    4.1 误码

    概念:

    • 误码
      经传输后,数字流的某些比特发生差错,使传输信息的质量
      发生损伤。

    影响:

    • 话音通信中表现为听简中的喀呖声:数据通信中表现为数据块的报废;
      图象通信中表现为画面的雪花干扰,多个线条干扰,画面滚动等

    4.2 传输网性能参数

    • 误码率
      错误比特数/传输比特总数 (特定时间段)。
    • 误块秒比(ESR)
      当某1S具有1个或多个差错块或至少-个缺陷(信号丢失,帧定位丢失,指针丢失,各级告警指示和信号标记失配等)时,称为误块秒(ES) 。ES数/总的可用时间(特定时间段)。
    • 严重误块秒比(SESR)
      当某1S内包含有不少于30%的差错块个或多个差错块或至少-个缺陷时,称为严重误块秒(ES)。SES數/总 的可用时间(特定时间段)。
    • 背景块差错比(BBER)
      扣除不可用时间和SES期间出现的差错块以后所剩下的差错块,称背景块差错(BBE)。BBE数/扣除不可用时间和SES期间所有块以后的总块数之比。

    在这里插入图片描述

    我国国内标准最长假设参考通道
    

    4.3 抖动

    概念:

    • 抖动
      数字信号的特定时刻相对其理想参考时间位置的短时间偏离
      (指变化频率高于10Hz的相位变化)。

    影响:

    • 对数字编码的模拟信号,抖动造成信号失真,形成抖动噪声。在再生
      器中,降低其信噪比余度,直至发生误码。对配有缓存器的网元,会
      产生滑动损伤。语声信号比图象信号更能忍受抖动影响。

    规范:

    • G.823将高于10Hz的相位变化称为抖动指标,低于的情况称为漂移指标,
      然后按业务量接口和同步接口分别给出指标。

    4.4 漂移

    概念:

    • 抖动
      数字信号的特定时刻相对其理想参考时间位置的长时间偏离
      (指变化频率低于10Hz的相位变化)。最普遍的原因是环境温度变化。

    影响:

    • 电话业务受漂移的影响类似于误码产生的脉冲噪声;传真业务的清晰度
      下降或质量严重恶化;图象业务会有图象冻结现象。

    规范:

    • G.823将高于10Hz的相位变化称为抖动指标,低于的情况称为漂移指标,然
      后按业务量接口和同步接口分别给出指标。

    4.5 延时

    概念

    • 延时
      信号传输需要时间发生延时。

    影响

    • 对电话业务,使收话方等待的时间过长,回波干扰使受话清晰度下降;
      对数据业务,延时越大,传输效率越低;对电视业务,产生画面和声
      音相脱节现象等。

    规范

    • ITU-T规定有网络性能的规范,另外还有电路性能的规范。

    五. 传输网建设全过程

    1. 规划/计划
    2. 可行性研究/方案设计
    3. 依规范书谈判/签约
    4. 初步设计/施工图设计
    5. 督导安装与调测
    6. 初步验收
    7. 试运行
    8. 最终验收
    9. 开通运行/保修期

    六. 传输网发展方向

    6.1 容量要足够大

    随着数据业务量特别是IP业务量的飞速增长,对于以电话业务为主的传统电信网络形成越来越大的压力,网络变化将向着宽带化、光纤化、智能化、网络接入的无线化及三网融合的大趋势发展,我国近期电信体制正在加大改革的力度,竞争在全方位展开,除了广电、联通外、随着移动从电信网中剥离,对于传输电路的建设使用产生影响。

    6.2 加速加大光缆网的投入

    根据当前的电信发展趋势及竞争方面的因素,不论从安全性、使用期限考虑(光缆的使用期限为20年),还是从出租光纤和波导等因素的考虑,我们都必须在加强规划的指导下,加大和完善光缆网络的投入,对光缆芯数进行合理的布置,使之适应技术业务发展的需要。G.655非零色散位移光纤适合传输TDM、WDM的2.5Gb/s、 10Gb/s及 更高速率的光纤通信系统。今后新建的光缆通信线路,尤其是业务量较大的光缆干线,为了能适应高速率多信道系统的传输要求,宜采用G.655非零色散位移光纤。

    6.3 自完善网络安全性方面的保护与恢复功能

    自每个节点出局应有两个以上的路由各个网络必须有双节点互通,自在长途网建设方面,从安全性考虑,应积极考虑各本地网设传输双节点,而不论TS2是否建设。自在环形网建设的基础上引入格形网结构,这样不仅可以提高网络的安全性,也可以提高通道的使用效率。

    6.4 部提高网络的可重塑性和提供各种接口

    自其业务增长有相当大的随机性,在时间或地域上都会变化,而传输网络的建设和扩容一般都需要较长的时间。对传输系统上的设备进行满容量的配置,这样就在容量所许可的范围内灵,活地改变业务的流量、流向。格形网方面进行考虑自在传输网络.上应提供各种业务的接入平台,以使各种业务能够方便地、及时地接入,这样也为网络应急条件下电路的调度带来好处。

    6.5 DXC设备的使用

    • DXC可以起到业务量疏导网络恢复保护,代替背对背复用器和配线架,传输检测中心等多种作用,但初期引入DXC时首先考虑的是其一 .两种功能。
    • 鉴于DXC设备尚在不断的演进过程中,特别是恢复算法和网管方面离标准化较远,多厂家互连困难较大。对DXC的引用应抱着积极稳妥的态度,逐步推广使用。
    • 配置DXC的节点一般在网路结构中处于重要的位置,要根据网路的总体规划要求分步配置。
    • 当以DXC组网时,必须考虑具有一定的网路冗余度
    • 本地网中当环间电路调度困难时,可根据具体情况设置DXC设备。考虑到本地网与干线网的密切关系,在网关局配置DXC时要统一考虑,合理配置,避免几个同类的DXC背对背运行,等等。

    6.6 同步

    SDH设备接受同步网提供定时基准,同时还担负着传递定时的重要任务。
    对于SDH传输网,应统一规定其同步性能、功能,为定时基准的可靠传递奠定良
    好的基础和环境。要求

    • SDH设备时钟SEC的标准化,应该统一规定符合ITU-T G. 813要求。
    • SDH设备的外同步输入、输出接口的统一 *规定。例如,外同步输出口输出的同步信号必须由STM-N直接倒出,以确保同步信号正常地往下传递
    • 同步状态信息SSM是使光纤网络恢复正常定时工作的主要方法。但目前SDH网元对SSM的一系列算法,ITU-T并 未规定,采用SDH传定时的安全可靠性还需进一步研究。

    推广使用SSM是保障定时链路畅通的主要手段

    6.7 网络管理

    • 由于网管系统的接口标准仍未完全统一,还在不断发展变化,功能仍不完善,各厂家网络管理上的互通仍属空中阁楼。
    • 国使用不够熟练,二次开发少,而且硬件、软件技术正不断升级,给应用者带来困难,网管的有效性没有想现中那么好。

    6.8 SDH横向兼容性

    需要在物理层和管理层上都满足才行。

    物理层

    • 目前物理层.上的信号速率、帧结构、复用结构和光接口都有了统一的规范。
    • 尚有不少字节尚未标准化,或标准化不彻底;
    • 再有,DCC的互通不仅涉及物理层,而且涉及7层协议互通问题,尽管协议可以一致,但信息模型难以统

    管理层

    • 要在管理层. 上实现互连互通、互操作很复杂,它要求不同设备和管理系统的协议和信息模型都一致。
    • MD-NE接口(Qx)涉及到具体SDH设备的管理,要实现不同厂家的设备和网管的横向兼容性十分困难。
    • OS-MD接口(Q3) ,只需知道业务点细节,无须了解设备细节,管理信息量大大减少,实现互通相对难度小一些。

    6.9 DWDM全光网络

    • 由于DWDM光传输系统的大量推广使用,将产生电传送层网络节点DXC的电子瓶颈,有必要在DXC.上再加一层OXC和OADM。
    • OXC及OADM网络节点是DWDM全光网的核心技术,能够对多波长的光信号进行交叉连接,具有透明的传输代码格式和比特率,交叉连接容量大,交叉连接速率和接入速率范围宽,无需进行时钟同步和开销处理,监控维护参数少,没有光电转换,避免电信号造成的瓶颈。
    • 全光网络分三层,分别是 ①光网层: 以DWDM为基础的结构可变的网络。②电子层: 各种电子交换,从程控交换、ATM交换到未来的某种交换。③应用层: 包括数据、话音到图像等各种业务之用。

    6.10 DWDM 全光网络

    在这里插入图片描述

    制作不易,转载请标注~

    展开全文
  • SRT互联网传输设备技术分享

    千次阅读 多人点赞 2019-06-07 15:06:27
    SRT互联网传输设备技术分享前 言序 言Chapter 1. 什么是SRT?1.1. SRT 联盟1.2. SRT传输技术1.3. SRT的典型应用模式1.3.1. 点对点单向传输和视频互动1.3.2. 点对多点传输1.3.3. 视频流协议转换与分发Chapter 2. SRT...

    SRT互联网传输设备技术分享


    前 言

    写这篇文章的初衷,是想把自己在使用SRT设备过程中的经验和想法分享给公司同事和一些用户。因为SRT对一些人来讲,还比较陌生,如果能够通过一篇文章,把简单的基础知识分享给大家,既能增加对SRT的理解,也可以了解SRT的简单原理,这样在工作中,无论是在搭建传输系统时,还是在使用设备的过程中,都能够游刃有余的解决问题;同时,如果要将这些知识清晰的梳理出来,对我自己也是一次系统学习SRT知识的机会,于公于私,这都是一件值得去做的事。

    当然,SRT Alliance提供了相应的指导文档《SRT Deployment Guide, v1.1, Issue 01》,我也是从这份文档开始学习起来的,但是截至到写这篇文章为止,我还没有看到相应的中文版本,这对于一部分国内的用户来说使用起来就会不太方便。

    于是,当这两件事同时出现的时候,我写这篇文档的思路也就逐渐清晰了:依托于SRT Alliance这篇指导文档的内容以及逻辑结构,同时加入我自己的思考和想法,再通过高骏SRT设备作为操作界面呈现出来,最终形成一篇中文版本的技术分享文档。

    在这篇文章中,我大量借鉴了《SRT Deployment Guide, v1.1, Issue 01》的内容,很多语句都是我将原文翻译过来的,所以难免会有翻译不准、措辞不当的地方;同时,在文中会涉及传输协议、传输纠错机制、防火墙等一些专业知识,其中大多是我通过自学的途径来掌握的,没办法做到准确无误。所以如果有各方面的专业人士发现了我在翻译、描述中的错误,非常希望您能帮我指出问题,我将感激不尽,您可以通过我的个人邮箱联系到我:lzrfighting@hotmail.com。

    原本为了让这篇文章更好的散播出去,我是将它分成四部分在高骏公司的微信公众号上连载发布的,但是弊端就是在推送时间之后,不方便大家再去查找相关的内容,所以这次主要是将原来的连载文章合并起来,并进行必要的修正,形成完整版的文档,分享给大家。

    如果您对SRT Alliance的原文文档感兴趣,可以从以下链接中下载阅读,本文参考、涉及的文档包括:
    《SRT Deployment Guide, v1.1, Issue 01》下载链接:www3.haivision.com/srt-alliance-guide
    《Haivision SRT Open Source White Paper》下载链接:www3.haivision.com/srt-open-source-wp

    最后,感谢以往教会我各种知识和技能的师傅、领导、同事、同学和朋友,你们给予我的每一点知识对我来说都非常重要!也感谢SRT Alliance给我们提供如此强大的技术以及相关的指导文档,使我们有机会在工作和生活中学习、应用到SRT技术,也希望你们不断壮大,给所有的使用者带来更多的便利。


    序 言

    传统的IP编解码器大多直接使用UDP等不可靠传输协议直接进行传输,无法解决公网环境下的抖动与丢包问题,因此,这类编解码器方案无法直接应用于普通互联网传输的场景。

    而高骏(北京)科技有限公司推出的使用SRT可靠传输技术的编解码器和媒体网关产品,可成功实现在普通互联网环境下、多地之间,安全可靠的高清视频传输、分发功能。

    那么,如此方便好用的功能究竟是如何实现的呢?

    为了让大家对SRT传输设备有更深入的了解,将这些看似深奥、复杂的技术和产品变得平易近人,我特意写了这篇文档,与大家分享和讨论SRT技术以及高骏互联网传输设备。文章将分为四部分:什么是SRT,SRT协议解析,实际使用场景和配置SRT传输参数,文章思路由浅入深,由理论到应用,尽可能地将SRT协议清晰地介绍给每一个阅读这篇文章的朋友,希望大家能够从中有所收获。


    Chapter 1. 什么是SRT?

    1.1. SRT 联盟

    想了解SRT技术,我们可以从SRT联盟说起,这是一个由Haivision和Wowza合作成立的,致力于管理和支持SRT协议开源应用的组织,这个组织致力于促进视频流解决方案的互通性,以及推动视频产业先驱协作前进,实现低延时网络视频传输。

    1.2. SRT传输技术

    SRT(Secure Reliable Transport)是一种能够在复杂网络环境下实时、准确地传输数据流的网络传输技术,它在传输层使用UDP协议,虽然UDP协议是一种不可靠传输协议,但是凭借SRT强大的数据恢复能力,再加上UDP协议自身速度快、开销低的特点,最终实现了SRT安全、稳定、快速的传输效果。
    SRT Open Source官方logo
    图1-2 SRT Open Source官方logo
    (图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》)

    SRT是一种面向连接的点对点协议,每一路SRT流仅需一个UDP连接,其中除了一路要传输的数据流外,还包含了双向的控制信息。
    SRT
    协议的特点有如其名字:通过加密保证传输内容的安全;在严重丢包的情况下可靠地恢复数据流;动态适应时刻变化地网络情况传输数据。

    得力于其可靠的传输质量和极低的传输延时,SRT技术被广泛应用于视频流传输领域。

    在音视频流从SRT源设备(如下图中编码器)传输到SRT目标设备(如下图中解码器)的过程中,SRT会实时地检测和适应两台设备间不断变化的网络状态,抵抗由于网络拥塞而导致的带宽抖动,凭借其强大的错误恢复机制,将网络丢包的可能性降到最低。同时SRT还可以进行AES加密,从而确保数据在传输过程中的信息安全。
    SRT技术的典型传输方式
    图1-3 SRT技术的典型传输方式
    *注: 文章中将分别以蓝、黄两种颜色强调SRT源设备和SRT目标设备,方便大家理解描述语句。

    1.3. SRT的典型应用模式

    由于SRT技术安全、可靠、快速的特点,它可以适应各种各样的使用需求。而且,有SRT协议的存在,即使你不掌握复杂的IP路由和交换知识,也可以快速地建立起视频传输通道,完成视频传输任务。

    这里,我简单列出几个最典型的应用模式:

    1.3.1. 点对点单向传输和视频互动

    SRT最简单的应用方式,就是在两点之间进行视频传输工作,比如进行单向视频传输,将视频从A地传输到B地;或者两地互传,实现两地间的双向视频互动。
    点对点单向视频传输
    图1-4 点对点单向视频传输
    点对点双向视频互动
    图1-5 点对点双向视频互动
    *注:
    1. HDE-650S:SRT互联网传输编码器,支持4:2:2编码;
    2. HDD-461:SRT互联网传输解码器;
    3. 两台设备搭配使用最低支持40ms超低编解码延时。

    这里对HDE-650S和HDD-461先做一个简要的介绍,它们是专业的视频编解码设备,分别可以输入和输出多种基带信号格式,支持ASI、UDP和SRT等多种码流格式的输出、输入,支持4:2:2编码,编解码延时最低可达40ms,是理想的编解码解决方案。
    HDE-650S和HDD-461的输入与输出
    图1-6 HDE-650S和HDD-461的输入与输出

    1.3.2. 点对多点传输

    通过使用高骏SMH媒体网关,可以将一个编码器发出地视频流,分发给多个解码器,以SMH媒体网关为中心节点,先接收编码器发出地视频流,再将其复制、分发给多个解码器,从而实现点到多点的视频传输。
    点对多点视频传输
    图1-7 点对多点视频传输
    *注:
    SMH:SRT媒体网关。在这里,SMH媒体网关既是SRT目标设备,接收来自编码器HDE-650S的视频流;同时也是SRT源设备,将视频流发送给多个解码器HDD-461。

    1.3.3. 视频流协议转换与分发

    凭借媒体网关设备,可以实现SRT、TS over UDP、RTMP PULL/PUSH等多种视频流协议的输入与输出,并对各路视频流进行复制、转换、分发等工作,这大大增加SRT系统的兼容性,使本地TS over UDP和RTMP流能够顺利融入SRT系统,提高视频转发的灵活性。
    通过SMH媒体网关完成视频流协议的转换与分发
    图1-8 通过SMH媒体网关完成视频流协议的转换与分发


    Chapter 2. SRT协议解析

    为了让各位对SRT有更深入的了解,下面让我们一起来看看SRT是如何工作的。

    2.1. SRT工作原理

    要说SRT的工作原理,我们先从其纠错机制说起。

    下图描述了在数据包传输过程中,不使用数据纠错,使用FEC(Forward Error Correction)纠错,和使用ARQ(Automatic Repeat request)纠错三种链路传输纠错方式的模式和结果。

    如果没有数据纠错,结果自不必说,一旦发生丢包,得到的就是不完整的数据流,如下图。
    数据包传输时没有纠错机制
    图2-1 数据包传输时没有纠错机制
    (图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》)

    如果使用FEC纠错,则会在传输的数据流中加入一定比例的前向纠错数据,当发生丢包时,接收端就可以根据前向纠错数据,恢复丢掉的数据包,如下图。

    但是使用FEC就必须面对这样的问题:无论是否产生丢包,前向纠错数据都需要占用一定的传输带宽;而且当丢包率超过前向纠错数据能够恢复的阈值时,FEC将无法恢复丢失的数据包。
    数据包传输时使用FEC纠错
    图2-2 数据包传输时使用FEC纠错
    (图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》)

    如果使用ARQ纠错,就需要在发送端和接收端之间建立双向连接。在接收端收到数据包后,会按照数据包的顺序进行排序(传输过程中数据包可能会发生乱序),如果发现其中有丢失的数据包,就会向发送端发出重传请求,由发送端将丢失的数据包重新发送到接收端,从而实现数据包的恢复,如下图。

    数据包传输时使用ARQ纠错
    图2-3 数据包传输时使用ARQ纠错
    (图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》)

    而我们说的SRT技术,正是使用的ARQ纠错机制,这主要是因为在网络传输时,带宽抖动和丢包通常都是随机发生的,只有在网络出现问题的时候才需要纠错机制的介入,只需要在发生丢包之后让发送端重传丢失的数据包就可以了,这样既保证了传输的质量,同时又能减少无谓地消耗传输带宽;除此之外,SRT会为数据包提供更精准的时间戳,让接收端能够准确校准媒体流的包顺序,保证传输正常。

    之前已经说过,SRT协议依靠双向传输的UDP流来保证公网环境下的视频传输质量。除了从SRT源设备到SRT目标设备持续发送视频数据外,在两台设备之间还会持续地交换SRT控制信息,以此来在两台设备之间实现以UDP为底层协议的连接,进行信息交互,确保视频数据能够准确地传输到接收端。
    SRT连接中的双向UDP流
    图2-4 SRT连接中的双向UDP流
    *注:
    1. SRT源设备发送的UDP流包含数据业务流和SRT控制信息;
    2. SRT目标设备接收源设备发来的UDP流,同时回复相应的SRT控制信息。

    为了让SRT保持连接状态,必须确保控制信息数据包的发送间隔不超过10ms。每当SRT目标设备收到一个数据包后,都会回复一个“ACK”确认控制信息数据包,告诉SRT源设备已经收到这个数据包了,如果在10ms内收到多个数据包,则只回复一个“ACK”,确认这期间收到的所有数据包;然而,数据包的到达时间间隔难免会超过10ms,这时就需要增加“keep alive”控制信息数据包,确保SRT连接不会断开。

    在SRT连接中,从目标设备返回源设备的控制信息通道也会占用一定的带宽。在业务数据完全正常传输的情况下(即没有错误信息需要返回到发送端),控制信息占用带宽大约为40Kbps;传输时丢失的数据包越多,目标设备发出的控制信息就越多,信息量会与丢包率线性相关,每丢失1个数据包,大约会消耗400bps的可用带宽。

    2.2. SRT握手模式

    现在我们已经知道SRT的工作原理了,那么一个SRT连接又是如何建立的呢?要清楚这个问题,我们就不得不了解SRT握手模式:Caller & Listener和Rendezvous。

    在讨论建立SRT连接时,我们不需要区分SRT源设备和SRT目标设备,发送端和接收端都可以发起建立SRT连接,我们只要知道哪端的设备满足设置相应模式的网络需求即可。

    2.2.1. Caller模式

    ✦ 功能:
    设置Caller模式的设备将作为SRT会话的发起者,它必须知道对应设置Listener模式的设备的公网IP地址及其监听的UDP端口。

    ✦ 使用场景:
    ①让一台设备发起建立一个点对点传输的SRT连接;
    ②设备所在的网络有防火墙,但没有防火墙操作权限;
    ③设备的IP地址是DHCP动态获取的;
    ④设备没有固定的公网IP地址。

    2.2.2. Listener模式

    ✦ 功能:
    设置Listener模式的设备会监听发起SRT会话的请求,它需要知道应该使用的UDP端口(如网络管理员分配给SRT传输使用的UDP端口),并一直在这个端口上监听发起SRT会话的请求。

    ✦ 使用场景:
    ①让一台设备监听发起SRT会话的请求;
    ②设备所在的网络有防火墙,并且可以控制防火墙,打开需要的UDP端口;
    ③设备直接暴露在公网环境下。

    2.2.3. Rendezvous模式

    ✦ 功能:
    两台设置Rendezvous模式的设备会共同协商,通过相同的UDP端口号建立一个SRT会话。

    ✦ 使用场景:
    ①两台设备所在的网络都有防火墙,但是没有防火墙的操作权限,如果防火墙设置了适当的工作模式(将在Chapter 3.实际应用场景中详细介绍),可通过此模式建立SRT会话。

    一旦完成SRT连接的建立,SRT源设备和SRT目标设备便开始交换控制信息,如网络状况信息、丢失的数据包等等,无论设备设置的是Caller、Listener还是Rendezvous模式都无关紧要了,直接利用建立起来的SRT通道去传输数据就可以了。

    2.3. SRT如何建立连接

    那么这三种握手模式实际又是如何把SRT会话建立起来的呢,下面我们通过简单的图示来了解这个过程。

    2.3.1. 由SRT源设备发起建立SRT连接

    如下图,将编码器HDE-650S设置为Caller模式,解码器HDD-461设置为Listener模式,编码器(Caller)将向设置的UDP端口连续发送控制信息数据包,请求建立SRT连接(图中①),当解码器(Listener)收到这些数据包后,便开始回复它自己的控制信息数据包(图中②),一旦握手成功,编码器便开始在UDP流中增加视频流,开始视频传输(图中③)。
    SRT源设备发起建立SRT连接的过程
    图2-5 SRT源设备发起建立SRT连接的过程

    2.3.2. 由SRT目标设备发起建立SRT连接

    如下图,将编码器HDE-650S设置为Listener模式,解码器HDD-461设置为Caller模式,解码器(Caller)将向设置的UDP端口连续发送控制信息数据包,请求建立SRT连接(图中①),当编码器(Listener)收到这些数据包后,便开始回复它自己的控制信息数据包(图中②),一旦握手成功,编码器便开始在UDP流中增加视频流,开始视频传输(图中③)。
    SRT目标设备发起建立SRT连接的过程
    图2-6 SRT目标设备发起建立SRT连接的过程

    2.3.3. 使用Rendezvous模式建立SRT连接

    如下图,SRT源设备和SRT目标设备同时设置为Rendezvous模式,两台设备一起向对方发送控制信息数据包,一旦握手成功,编码器便开始在UDP流中增加视频流,开始视频传输。
    使用Rendezvous模式建立SRT连接的过程
    图2-7 使用Rendezvous模式建立SRT连接的过程

    2.4. SRT与防火墙

    在实际使用场景中,特别是在通过互联网进行数据传输时,终端设备通常都会经过防火墙再连接到互联网,SRT流就必须穿过防火墙进行传输。这种情况下,我们就需要网络管理员来帮忙对防火墙进行适当的配置,尤其像网络地址转换(NAT)和数据包过滤的设置,防火墙的配置情况将会决定设备使用哪一种握手模式。

    下图中,一台编码器尝试通过互联网将视频流发送给解码器,两台设备都在防火墙后。我们不妨假设编码器使用Caller模式,解码器使用Listener模式,为了使它们握手成功,并建立SRT会话,就必须满足下列条件:
    ① 解码器端的防火墙需要允许某个供SRT使用的UDP端口可以从互联网接入;
    ② 编码器必须知道解码器端防火墙的公网IP和开放的UDP端口;
    ③ 两端的防火墙都要允许双向UDP传输;
    ④ 两端的防火墙都要配置端口转发,允许编码器和解码器之间的数据流传输;
    ⑤ 两端的防火墙都要关闭数据包过滤功能,允许编码器和解码器之间的交互数据包通过。
    经过防火墙进行视频传输
    图2-9 经过防火墙进行视频传输


    Chapter 3. 实际应用场景

    在了解SRT协议的基本原理后,我们可以尝试使用高骏公司的互联网编解码器模拟来进行视频传输,感受一下协议中提到的参数是如何在实际应用中体现的。

    3.1. 在公网环境下开启视频传输:Caller & Listener模式

    让我们再来简单复习一下Caller和Listener模式建立SRT连接的工作机制。其实直接从字面含义就能够对他们的关系有所认识了,SRT握手模式设置为Caller模式的一端,需要负责“呼叫”预先选定的UDP端口(即向Listener端公网IP的这个UDP端口发送数据包),从而发起一个SRT握手以建立连接;而SRT握手模式设置为Listener的一端,则需要负责“监听”预先选定的UDP端口,时刻准备回应Caller端发来的建立SRT握手请求的数据包。

    那么在实际应用时我们应该如何来将Caller + Listener模式的理论付诸实践呢?我们先来假设有这样一个应用场景:

    某公司有固定的视频传输任务,需要将视频从广州办事处实时传输到北京总部,由于资源问题,只有北京总部可以提供公网IP以及可用的UDP端口,而办事处只能提供互联网连接。
    使用互联网将视频从广州实时传输到北京
    图3-1 使用互联网将视频从广州实时传输到北京

    根据现有的资源条件,我们可以这样设置SRT来建立视频传输连接:

    由于北京总部可以提供公网IP(203.0.113.74)以及可用的UDP端口,这里假设防火墙打开的UDP端口号为12345,那么,我们就需要将北京的SRT设备(HDD-461)设置为Listener模式,并监听12345号UDP端口,准备建立SRT连接;相应的,广州的SRT 设备(HDE-650S)需要设置为Caller模式,只需要能够接入互联网即可,它将向北京总部的公网IP 203.0.113.74的UDP端口12345发送控制信息数据包,尝试通过此端口来建立SRT连接。

    按照以上描述,我们就可以得到这样一个SRT源设备(HDE-650S)和SRT目标设备(HDD-461)的网络关系图:
    HDE-650S和HDD-461的网络关系图
    图3-2 HDE-650S和HDD-461的网络关系图

    那么我们应该如何在编解码器中设置这些SRT参数呢?

    首先来看编码器HDE-650S,参考下图HDE-650S的SRT输出设置(编码器的其他参数设置不在此处表现):
    ①打开SRT输出,将“Output Enable”设置为“Enable”;
    ②编码器使用Caller模式,将“Connection Mode”设置为“Caller”;
    ③“Address”一项填入北京总部提供的公网IP地址“203.0.113.74”;
    ④“Destination Port”一项填入北京总部提供的UDP端口号“12345”;
    ⑤“Latency” (传输延时)、“Encryption”(加密)、“Bandwidth Overhead”(带宽开销)、“Time To Live”(TTL)、“Type of Service”(ToS)可使用默认值。
    HDE-650S的SRT输出设置
    图3-3 HDE-650S的SRT输出设置

    然后我们再来看解码器HDD-461,参考下图HDD-461的输入设置(解码器的其他参数设置不在此处表现):
    ①“Input Name”可以填写一个方便识别的任务名称,此处设置为“SRT_Listener”;
    ②“Input Source”选择“SRT”,设置为SRT模式;
    ③解码器使用Listener模式,“SRT Mode”设置为“Listener”;
    ④“Listener Port”一项填入选择的UDP端口号“12345”;
    ⑤“Latency” (传输延时)、“Encryption”(加密)、“Bandwidth Overhead”(带宽开销)、“Time To Live”(TTL)、“Type of Service”(ToS)可使用默认值。
    HDD-461的输入设置
    图3-4 HDD-461的输入设置

    正常情况下,完成上述配置后,编码器和解码器即可顺利完成SRT握手,并开始传输视频流,如下图,图中显示SRT状态为“Connected”,证明SRT连接正常,在解码器HDD-461中可以看到,正在对接收到的视频流进行解码。
    接成功后的编解码器状态
    图3-5 连接成功后的编解码器状态

    3.2. 在公网环境下开启视频传输:Rendezvous模式

    我们在上次的文章中说过,Rendezvous模式可以在两端防火墙都没有做端口转发规则时建立SRT连接,从而实现两点之间的视频传输。这时,需要在两端分别设置对方的出口公网IP以及相同的端口号,这样,两台设备将同时向对方的出口公网IP发送控制信息数据包,用来建立SRT连接。

    我们继续使用前面的例子来模拟,但是更换一个使用场景:

    某公司临时决定从广州办事处将视频信号实时传输到北京总部,来不及申请在防火墙中做端口转发规则,所以两端的设备都没办法通过对方公网IP的某个特定端口来直接找到对方。

    这时,就可以使用Rendezvous模式来建立SRT连接,我们需要将北京的SRT设备(HDD-461)设置为Rendezvous模式,并写入广州办事处SRT设备的出口公网IP地址和一个没有被使用的UDP端口号,同时,再将广州的SRT 设备(HDE-650S)也设置为Rendezvous模式,并写入北京总部SRT设备的出口公网IP地址和相同的UDP端口号,这样就可以建立起SRT连接了,我们同样画出一个SRT源设备(HDE-650S)和SRT目标设备(HDD-461)的网络关系图:
    HDE-650S和HDD-461的网络关系图
    图3-6 HDE-650S和HDD-461的网络关系图

    按照图中的相互关系,我们继续使用编解码器来设置相应的参数。

    首先来看编码器HDE-650S,参考下图HDE-650S的SRT输出设置(编码器的其他参数设置不在此处表现):
    ①打开SRT输出,将“Output Enable”设置为“Enable”;
    ②编码器使用Rendezvous模式,将“Connection Mode”设置为“Rendezvous”;
    ③“Address”一项填入北京总部解码器HDD-461的出口公网IP地址“203.0.113.74”;
    ④“Destination Port”一项填入一个没有被使用的UDP端口号“12345”;
    ⑤“Latency” (传输延时)、“Encryption”(加密)、“Bandwidth Overhead”(带宽开销)、“Time To Live”(TTL)、“Type of Service”(ToS)可使用默认值。
    HDE-650S的SRT输出设置
    图3-7 HDE-650S的SRT输出设置

    然后我们再来看解码器HDD-461,参考下图HDD-461的输入设置(解码器的其他参数设置不在此处表现):
    ①“Input Name”可以填写一个方便识别的任务名称,此处设置为“SRT_Rendezvous”;
    ②“Input Source”选择“SRT”,设置为SRT模式;
    ③解码器使用Rendezvous模式,“SRT Mode”设置为“Rendezvous”;
    ④“Address”一项填入广州办事处编码器HDE-650S的出口公网IP地址“198.51.100.182;
    ⑤“Listener Port”一项填入选择的UDP端口号“12345”;
    ⑥“Latency” (传输延时)、“Encryption”(加密)、“Bandwidth Overhead”(带宽开销)、“Time To Live”(TTL)、“Type of Service”(ToS)可使用默认值。
    HDD-461的输入设置
    图3-8 HDD-461的输入设置

    如果一切正常,完成这些配置后,这家公司北京的领导应该就能看到广州办的实时视频了。

    3.3. 探讨:Rendezvous模式与防火墙

    我们在前面的模拟场景中很轻松就完成了Rendezvous模式下的SRT连接,看似水到渠成,然而实际情况并不是这么简单,在这背后还隐藏着一些网络的相关知识,下面我们就来简单讨论一下SRT使用Rendezvous模式穿过防火墙建立连接的情况,毕竟知其然,也要知其所以然。

    当然,网络安全与防火墙是一门很深奥的专业网络知识,我的能力有限,就不跟大家讨论深层次的内容了,这里只针对和SRT相关的知识做简单的分享。
    在这里插入图片描述
    图3-9 负责网络安全的防火墙
    (图片来自网络)

    首先,我们需要知道,在使用Rendezvous模式时,设备发出的控制信息数据包的源端口与目的端口都是一样的。在之前的例子中,编码器发出的控制信息数据包的源端口为12345,目标端口也是12345,同样的,解码器发出的控制信息数据包的源端口和目标端口也都是12345。换句话说,这“四个”端口号相同是Rendezvous模式穿越防火墙建立SRT连接的必要条件。

    因此,在编解码器之间的防火墙就必须确保不转换数据包包头中的端口号。

    Rendezvous模式下两端使用相同的端口号穿过防火墙建立SRT连接
    图3-10 Rendezvous模式下两端使用相同的端口号穿过防火墙建立SRT连接

    现在市场上能够见到的防火墙,基本都是能够进行状态检测的状态防火墙(stateful firewall,现在由于这个功能过于普遍,也就不再有人特意提出这个概念了),它能够进行状态数据包检查或状态查看,实现连接追踪(connection tracking)的功能,而Rendezvous模式正是倚靠这个功能来创建一个贯穿两个防火墙的网络通道,并在其中进行数据传输。

    防火墙在工作时,会根据正在传输的流量,创建一个连接追踪表(connection tracking table),并保持动态更新。

    例如在上图中,在防火墙A中的连接追踪表会记录下源设备HDE-650S的内网IP和端口号、NAT转换后的公网IP和端口号、以及访问的目标设备HDD-461防火墙的公网IP和端口,如下表:
    防火墙A中创建的连接追踪记录1
    这时,当对端发来数据包时,防火墙A的连接追踪表还会记录下另一条反向入站信息,如下表:
    防火墙A中创建的连接追踪记录2
    当反向的数据包到达防火墙A时,发送数据与接收数据相同的端口号会对防火墙A产生“欺骗”效果,让它认为收到的入站数据是对出站数据的回复消息,从而允许数据包通过防火墙,一直到这个传输会话断开,SRT连接也就这样建立起来了。

    在大多数非专业场景中,我们用的网络设备都是使用PAT(NAT重载)进行公网IP到局域网IP的地址转换(如家用路由器等),这时,网络设备在转换地址时都会改变源端口号,所以Rendezvous模式大多无法使用,不如直接用路由器做静态端口映射规则来的方便,这样就可以在这端使用Listener的模式,监听映射的端口,另一端使用Caller模式建立连接;相比之下,Rendezvous模式反而是很少被用到。


    Chapter 4. 配置SRT传输参数

    当我们真正使用互联网去传输视频的时候,千变万化的网络环境是我们不得不面对的,要想在各种复杂的网络环境下都能顺利地传输视频,就必须要学会如何去优化SRT传输设置,还记得我们在上一章中使用默认配置的那些参数吗?他们就是让SRT工作在最佳状态的关键。

    4.1. 参数名称解析

    这一节,我将逐个向大家介绍会影响SRT传输性能的参数名称,他们包括:Round Trip Time(RTT,往返延时)、RTT Multiplier(RTT倍数)、Packet Loss Rate(丢包率)、Bandwidth Overhead(带宽开销)以及Latency(延时),SRT加密等。

    4.1.1. Round Trip Time (RTT)

    RTT(往返延时)表示从发送端发送数据开始,到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认),总共经历的时延。我们可以通过RTT知道两台设备(在我们的应用中,即为SRT源设备和SRT目标设备)在网络中的距离。在配置SRT传输时,我们就能以这个值为参考,设置带宽开销以及传输延时。

    当两台设备连接在局域网的同一台交换机上时,RTT值几乎为0(小于1 ms),而随着基础设施建设越来越完善,即使跨越大洋,也可能得到很低的RTT值。

    要想得到两台设备间的RTT值,我们可以使用ping命令。例如,如果我想知道我的电脑和Google在美国的免费DNS服务器8.8.8.8之间的RTT值,就可以使用电脑ping这个IP地址,从而得到他们之间的RTT值,如下图,我们从中可以知道,此时该网络链路RTT值平均约为50 ms。

    通过ping命令得到RTT的大小
    图4-1 通过ping命令得到RTT的大小

    除此之外,如果两台SRT设备已经建立连接,还可以在设备的“Statistics”统计信息中查看两台设备间的RTT值,如下图。

    在HDE-650S中SRT Statistics显示的RTT
    图4-2 在HDE-650S中SRT Statistics显示的RTT

    4.1.2. RTT Multiplier

    RTT Multiplier是一个用于计算SRT延时的数值,它可以反应出网络拥塞程度和RTT之间的关系,随着网络拥塞的增加,SRT控制信息数据包的交换量以及丢包的重传量也会随之增加,这些额外传输的数据包的传输时间都会受限于RTT,所以,为了抵消掉这些数据包的传输延时,就必须要增加SRT延时,而调整SRT延时的依据就是RTT Multiplier了,他们的关系如下:

    SRT Latency = RTT Multiplier * RTT

    我们也可以换一个RTT Multiplier的理解方式:它表示了在SRT传输中,对一个数据包的最大重传次数。当然,这个值不会直接出现在SRT的配置参数中,而是用于计算最理想的理论SRT延时。

    4.1.3. Packet Loss Rate

    Packet Loss Rate(丢包率)这个参数大家就再熟悉不过了,它通常表示丢掉的数据包占总发送数据包的百分比。在SRT传输中,我们可以把出现丢包的情况大致分为两种,在不同的情况下,分别会对我们设置Bandwidth Overhead有不同的影响:

    ✦ Constant loss(稳定的丢包)
    即链路的丢包率不会出现太大波动,基本处于一个恒定的数值。在这种情况下,要想稳定传输,就要求SRT开销应不小于此时的理论最小值(如下公式):

    Minimum Bandwidth Overhead = 1.65 * Packet Loss Rate

    ✦ Burst loss(爆发式丢包)
    即链路会出现大量连续的丢包,并且丢包量达到或超过SRT latency buffer(缓存区)内缓存的数据包量。在这种情况下,要想稳定传输,要求SRT开销应不小于此时的理论最小值(如下公式):

    Minimum Bandwidth Overhead = 100 ÷ RTT Multiplier

    这种爆发式丢包一旦持续时间超过了设置的SRT延时,将会导致接收端收到的流中断,所以,SRT传输延时应该保证永远大于最差网络环境下的网络持续丢包时间。

    4.1.4. Bandwidth Overhead

    Bandwidth Overhead(带宽开销)是一个根据网络链路质量设置的百分比值,用这个百分比值乘以编码器编码的视音频总码率,就可以得到Bandwidth Overhead允许的最大开销,这个值与视音频码率的总和就是当前SRT传输带宽的最大值了,也就是这个SRT通道可以使用的最大带宽。

    它的作用首先是传输伴随SRT流的控制信息数据包,另外还包括所有媒体数据包的重传,所使用的网络链路条件越差,就需要越多的控制信息数据包的交互以及媒体数据包的重传,也就需要设置越大的Bandwidth Overhead值。

    如果从“开销”的角度理解,它就是在传输所需的媒体内容(可以理解为载荷payload)外,额外要占用的“无效”带宽,但它与我们常见的协议开销、TCP首部开销、UDP首部开销有所区别,这里的带宽开销并不是固定的20~60字节TCP首部开销或8字节UDP首部开销,而是根据网络情况实时变化的,网络链路条件越差,正常传输所需的开销就越多。
    HDE-650S中的SRT Bandwidth Overhead设置
    图4-3 HDE-650S中的SRT Bandwidth Overhead设置

    在高骏SRT设备中,Bandwidth Overhead的设置范围是5%~100%,默认大小为25%。

    为了让大家对Bandwidth Overhead这个概念理解得更清晰,下面我们举个例子来说明。

    假如需要使用HDE-650S实时传输视频,设置视频编码码率为2000 kbps,音频码率为128 kbps(只使用一对立体声),所以视音频的总码率为2128 kbps,我们可以算上一些元数据和其他附加数据,向上取整为2200 kbps,如果我们设置Bandwidth Overhead为默认值25%,那么为传输这段视频所保留的总带宽则为:

    2200 + (25% * 2200) = 2750 kbps (2.75 Mbps)

    这个值表示的是SRT传输可以使用的最大带宽,如果在网络传输的过程中没有产生丢包,那么就只会使用很少量的开销来进行控制。通常只要能保证SRT总带宽不超过在两台SRT设备间的的可用带宽,数据流就能够保证顺利地传输。

    4.1.5. Latency

    Latency(延时)对大家也是一个很熟悉的概念了,具体来说,它在这里用来表示通过网络传输数据包的时间延迟。在高骏SRT设备中,Latency的设置范围是20 ms至8000 ms,而我们设置的这个延时大小,则代表了可用于管理SRT数据包的最大buffer(缓存区)的大小。

    在SRT传输中,SRT源设备需要将它发出的数据包在buffer内排序,用于进行传输和重传,在SRT源设备的buffer内会保存那些还没有被SRT目标设备确认收到的数据包。

    而SRT目标设备则需要将它收到的数据包(在收到时可能是乱序的)存储在buffer内,并以正确的顺序排列,确保之后的解码正常,在SRT目标设备的buffer内会保存那些已经收到并等待解码的数据包(包的顺序按16进制1到f)。

    SRT传输中的buffer
    图4-4 SRT传输中的buffer

    在传输过程中,我们应该确保SRT源设备缓存在buffer中的内容(换算成以毫秒为单位)始终低于设置的Latency值,同时保证SRT目标设备缓存在buffer中的内容不要减少到0,这样才能保证SRT目标设备正确的收到所有数据包。

    SRT Latency是基于当前网络链路的性能来设置的(如我们前面说到的RTT与网络丢包率等),例如在一个较好的网络环境中,丢包率为0.1%-0.2%,那么根据经验可能将RTT Multiplier选为4就可以了,也就是:

    SRT Latency = 4 * RTT

    在使用时,我们在SRT源设备和SRT目标设备两端都可以设置Latency的大小,最终将取两个值中较大的一个为SRT传输延时。

    在HDD-461中SRT Statistics显示的Latency-Buffer-RTT图表
    图4-5 在HDD-461中SRT Statistics显示的Latency-Buffer-RTT图表

    4.1.6. SRT加密

    在使用SRT传输时,高骏SRT设备可以使用AES加密算法进行128位或256位的内容加密,并在SRT目标设备中解密,确保传输内容的安全。

    要想打开加密功能,首先要在SRT源设备中选择“Encryption”项的加密类型(AES-128或AES-256),并在SRT源设备和SRT目标设备中的“Passphrase”栏内填写相同的加密口令。

    SRT中的AES加密
    图4-6 SRT中的AES加密

    4.1.7. 传输过程中的Latency、Buffer和BW Overhead

    了让前面介绍的几个参数更好理解,下面我们通过一张图表来将它们形象的表现出来,下图描述了在一次SRT传输过程中,传输数据量随着时间的变化图,期间由于一次网络问题,传输数据量降为零,短暂的链路断开后,又恢复了数据传输,具体如下:

    传输过程中的传输数据量变化图
    图4-7 SRT传输过程中的传输数据量变化图
    (图片来自SRT Alliance的指导文档《SRT Deployment Guide, v1.1, Issue 01》)
    *注:
    1. 绿色直线:表示该链路可用的最大带宽;
    2. 红色虚线(偏上):表示根据流量带宽和BW Overhead计算得到的SRT最大带宽;
    3. 红色虚线(偏下):表示正常情况下的流量带宽,即视频、音频、元数据等;
    4. 蓝色曲线:表示传输数据量随时间变化的曲线;
    5. 灰色区域:表示接收端buffer缓存的数据总量。

    我们首先来解释一下接收端buffer,它是SRT目标设备缓存的数据包,我们在前面说过,它可以换算成以毫秒为单位的时间值,具体是如何做的呢,中间有这样一个简单的数学公式:

    时间 = 缓存数据量大小 ÷ 流量带宽

    而在上图中,灰色区域的面积就表示buffer内缓存的数据量,由于在链路故障点之前始终保证了稳定的传输码率,将buffer缓存一直维持在“满”的状态,所以灰色区域对应的时间轴长度与SRT延时基本相同。

    在链路出现故障后,传输码率降为零,随后又重新建立起连接,再次开始传输,也就是说SRT目标设备在一段时间内没有收到任何数据包。

    当SRT传输出现这样的情况时,SRT目标设备将用buffer中缓存的数据来保证输出给解码部分的数据流,设置的SRT延时越长,buffer中就能缓存的数据就越多。

    随后,一旦链路恢复,SRT源设备就会重新开始传输数据,其中将包括重传在链路故障期间丢失的数据包,为了这部分重传数据,SRT就会使用到在正常流量带宽之外的“开销”部分。一般情况下,带宽开销的大小应该保证在可能出现的最坏的网络状态下,SRT源设备能够在爆发期(burst time,图中区域B)内传输链路故障期间传输失败的所有数据(图中区域A),也就是区域B的面积应与区域A的面积相等。

    在保证输出图像连贯的条件下,SRT连接能够承受的链路故障(完全没有数据传输)的最长时间为:

    SRT Latency (ms) * Bandwidth Overhead (%) ÷ 100

    4.2. 基本设置方法

    在我们设置SRT传输参数时,所使用的网络链路状态通常是千变万化,即便是相同的网络链路,不同时间也可能会有不同的网络状态,但是,不论何时,我们都要总结出一套通用的技巧,来有理有据地提供一系列初始设置参数,然后再根据实际的效果做出相应的调整,下面就让我来给大家介绍一些SRT的基本设置方法。

    设置过程可以分为以下七步:

    4.2.1. 检测网络链路的Round Trip Time(RTT)值

    ✦ 使用ping命令检测所使用的网络链路的RTT值;
    ✦ 如果已经建立起SRT连接,可以在SRT设备的Statistics统计页面中查询RTT值;
    ✦ 当RTT ≤ 20 ms时,应认为RTT值为20 ms,因为SRT不对时间单位低于20 ms的数据做出响应。

    4.2.2. 检测网络链路的Packet Loss Rate(丢包率)

    ✦ 网络链路的丢包率将直接影响SRT延时和BW Overhead的计算,我们通常可以使用iperf来检测网络丢包率。

    ✦ 如果已经建立起SRT连接,可以在SRT设备的Statistics统计页面中获取网络链路的丢包率, Resent Bytes和Sent Bytes两个统计数据的比值即为网络丢包率,为了保证准确性,应该至少保证数据的统计时间超过60秒,网络链路丢包率计算公式如下:

    Packet Loss Rate = Resent Bytes ÷ Sent Bytes * 100

    在HDE-650S中的SRT Statistics统计信息
    图4-8 在HDE-650S中的SRT Statistics统计信息

    4.2.3. 根据测得的网络丢包率,从下表中查找相应的RTT Multiplier和BW Overhead值

    不同丢包率时RTT Multiplier和BW Overhead的取值
    表4-1 不同丢包率时RTT Multiplier和BW Overhead的取值
    (表格来自SRT Alliance的指导文档《SRT Deployment Guide, v1.1, Issue 01》)

    *注:
    1. 表格中的BW Overhead取值同时考虑了前文提到的Constant Loss和Burst Loss两种情况,取两种情况下计算得到的较大值(较大值全部为100 ÷ RTT Multiplier);
    2. 表格中计算的最小SRT Latency为RTT ≤ 20 ms时(即RTT取值为20 ms),在实际使用时应代入实际测得的RTT值;
    3. 表格中所列的数值,基本代表了一般情况下最高效的SRT设置,如果网络环境变得更差,或者希望系统容错率更高,也可以取更大的RTT倍数和BW Overhead值。


    从表格中我们可以看到,随着网络丢包率的增高,RTT Multiplier顺理成章地逐渐变大,BW Overhead却在逐渐变小,为什么它会给出这样的建议呢?下面给大家分享一些我个人的想法。

    我们前面已经介绍过,RTT Multiplier表示了SRT连接中一个数据包的最大重传次数,也就是说,在网络丢包率不超过1%时,表格建议设置最大3次重传就可以基本保证数据包能够传输到接收端了,而经过3次重传数据包都没能到达接收端的概率就是 (1/100)^3×100%=0.0001%(一百万分之一);以此类推,我们可以得到数据包最终丢失的概率公式为:
    数据包最终丢失的概率公式
    将上述函数画在二象限图表中,可得下图:
    数据包最终丢失的概率图
    从上图中可知,如果按照表格中的RTT Multiplier值和BW Overhead值设置SRT传输参数,那么在传输过程中一个数据包最终没能到达接收端的概率将始终小于0.0002%(一百万分之二)。

    我们不妨主观地判断,这个表格建议我们能够认为概率为0.0002%的事件是几乎不可能发生的事件(即数据包几乎不可能无法到达接收端),从而认定此时的SRT传输是安全的。

    但是,为什么随着网络丢包率的增加,设置的BW Overhead值是在逐渐减小的呢?我们可以尝试按照表格中的规律,将网络丢包率、RTT Multiplier、BW Overhead的值继续推演下去,即以1%为单位逐渐增加网络丢包率,同时不断地增大RTT Multiplier值,来确保:

    p^(RTT Multiplier)≤0.0002%,p为网络最高丢包率

    并根据得到地网络丢包率和RTT Multiplier值,分别计算Constant Loss和Burst Loss两种情况下的BW Overhead的值,并将其绘制成图标如下(具体推演数据不在这里列出):
    两种丢包情况下的最小BW Overhead
    为了保证表格中的参数设置能够同时兼容Constant Loss和Burst Loss两种网络丢包情况下的SRT传输,BW Overhead应该取上图中较大的数值,而在网络丢包率不超过10%时,始终是Burst Loss状态下的BW Overhead的值更大,并且不断减小(上图中橙色线),所以我们才会看到表格中的BW Overhead值不断减小;而当网络丢包率超过10%后,就变成了Constant Loss状态下的BW Overhead的值更大,所以就应该选择数值较大的蓝色线,这之后BW Overhead将逐渐增大。

    以上这些内容完全是我根据《SRT Deployment Guide, v1.1, Issue 01》中的参数表格所做的猜想,无论正确与否,希望能够给大家一点启发。


    4.2.4. 通过以下公式确定SRT Latency

    SRT Latency = RTT Multiplier * RTT

    ✦ 当RTT ≤ 20 ms时,RTT取值统一为20 ms。

    4.2.5. 测试可用链路带宽

    ✦ 使用iperf测试;

    ✦ 如果已经建立起SRT连接,可以通过SRT设备Statistics统计页面中的Max Bandwidth和Path Max Bandwidth两个参数获取链路带宽信息。
    在HDE-650S中的SRT Statistics统计信息
    图4-9 在HDE-650S中的SRT Statistics统计信息

    4.2.6. 确定传输码率

    ✦ SRT传输码率将会包括视频、音频、元数据等有效数据,再加上SRT协议开销,我们可以得到如下关系式:
    Channel Capacity>SRT Stream Bandwidth * (100 + Bandwidth Overhead) ÷ 100

    ✦ 如果不满足上述关系式,应减小视音频码率,直到满足;

    ✦ 通常情况下,建议保留出更多的空余带宽来抵抗不断变化的链路带宽,所以下面这个关系式会具有更强的安全性:

    0.75 * Channel Capacity>SRT Stream Bandwidth * (100 + Bandwidth Overhead) ÷ 100

    4.2.7. 检查SRT传输参数设置是否正确

    ✦ 检查SRT传输参数最好的方法,就是在开始进行SRT传输后,查看SRT源设备的Statistics统计页面图表, Send Buffer数值应该保持始终不超过SRT Latency的值,如果两条线十分接近,应当适当增加SRT延时。

    4.2.8. 关于iPerf

    iPerf是一个网络性能测试工具,通过它我们能够得到网络链路的带宽、延迟、抖动以及丢包等信息,从而判断一个网络链路的性能状态。

    在常用的Windows平台中,我们可以在网上下载到iPerf应用程序,并放在系统目录 %systemroot% 中,通过命令行窗口来运行,需要注意,iPerf3(如iPerf 3.1.3)与iPerf(如iPerf 2.0.9)之间不兼容;除此之外,也可以选择带有用户界面的应用程序,这样就不需要牢记复杂的操作命令了,如下图:
    iPerf软件
    图4-10 iPerf软件

    这里,我只向大家介绍测试传输带宽所用的命令(使用iPerf 2.0.9),如果大家感兴趣,可以去研究iPerf更多的使用方式。

    在开始测试前,应该先确保打开防火墙相应的端口,同时停止其他数据流的传输,保证测试结果的准确性。

    在SRT传输的接收端,输入如下命令:

    iperf -s -u -i 1 -p “port#”
    -s:表示iperf为server模式;
    -u:表示使用UDP协议;
    -i 1:表示反馈信息的时间间隔为1秒;
    -p “port#”:表示通过某一个端口号进行测试。

    在SRT传输的发送端,输入如下命令:

    iperf -c “IP ADDRESS OF DESTINATION” -u -b “BW” -i 1 -p “port#”
    -c “IP ADDRESS OF DESTINATION”:表示iperf为client模式,访问server端的公网IP并进行测试;
    -u:表示使用UDP协议;
    -b “BW”:表示测试的带宽值;
    -i 1:表示反馈信息的时间间隔为1秒;
    -p “port#”:表示通过某一个端口号进行测试。

    然后我们就可以在窗口中看到测试结果了。例如,我在一台电脑上同时运行iperf server和iperf client,将得到下图中的结果:

    接收端的iPerf命令和测试结果
    图4-11接收端的iPerf命令和测试结果
    发送端的iPerf命令和测试结果
    图4-12 发送端的iPerf命令和测试结果

    从上图中可知,测试得到网络带宽能够满足5.5 Mbps(由命令中写的带宽值而来),网络抖动为0.000 ms,丢包率为0%。在真正的互联网环境下,我们就能够以此来判断网络链路的性能了。

    4.3. SRT统计信息和优化传输设置

    在进行SRT传输时,两端的设备会交互大量的网络条件信息和数据包传输信息,而正是这些重要的信息内容让SRT在传输视音频信息时能够使用最佳的传输策略,SRT设备会将其中一些重要的信息参数以曲线图的方式表现出来,让他们变得简单直观,而对于操作人员来说,能够理解这些参数所代表的意义对优化SRT传输设置至关重要。

    4.3.1. HDE-650S中的链路统计信息(Link Statistics)

    在HDE-650S的Statistics统计信息中,包含了SRT状态、传输和丢失的数据包数,码率、启动时长、网络状态信息等等参数,如下图:
    HDE-650S的Link Statistics统计信息
    图4-13 HDE-650S的Link Statistics统计信息

    其中,可选择查看SRT协议或简单UDP协议的输出统计信息,简单UDP协议的输出统计信息只包含状态和码率,这里就不介绍了。另外可以选择曲线图的取样时间范围,可选择最近5分钟、最近60分钟或最近24小时内的统计数据信息。

    Link Statistics中呈现的参数项包括:
    Link Statistics参数整理
    注意事项:
    ✦ 首先应注意Status保持Connected状态,即保持SRT连接正常;
    ✦ 当发现Reconnections值不断变大时,表明两台设备间的网络通讯异常;
    ✦ 当Received NAKs值保持稳定上升时,证明在传输链路中存在某些网络问题,导致始终有一定量的数据包无法正常到达接收端;
    ✦ 如果发现Skipped Packets值缓慢增加,通常可以增加一些SRT Latency来解决;但是如果发现Skipped Packets的值会快速变大,那么就应该降低一些视频码率,如果有足够的可用带宽,也可以适当的增加Bandwidth Overhead。

    在编码器HDE-650S的Link Statistics中,还可以看到两个曲线图,分别表现带宽和延时随时间变化的曲线,如下图:
    HDE-650S中的统计数据曲线
    图4-14 HDE-650S中的统计数据曲线

    在上方的Bandwidth Used图中,我们可以看到传输码率曲线,以及设备预测的最大链路带宽(仅供参考)。

    在Delays图中,则会体现在SRT传输过程中,buffer是如何来改善传输效果的,途中我们可以看到buffer和RTT随时间变化的曲线,而延时则作为基准线保持不动。

    注意事项:
    ✦ 在编码器中,buffer的数值(绿色曲线)通常不会超过SRT延时的值(黑色直线),如果编码器的发送buffer曲线越过了Latency线,那么就需要增加SRT Latency的值。
    ✦ 如果编码器的发送buffer曲线经常会到达或越过Latency线,那么基本可以证明当前的网络带宽不足以支撑所要求的视频码率,此时就应该降低视频码率;如果编码器的发送buffer曲线只是偶尔会超过Latency线,这时就应该增加SRT延时。

    4.3.2. HDD-461中的链路统计信息(Link Statistics)

    在HDD-461的Statist城市统计信息中,可以看到SRT状态、重传、丢包数、带宽信息、网络状态信息等等参数,如下图:
    HDD-461的Link Statistics统计信息图4-15 HDD-461的Link Statistics统计信息

    其中,可以选择曲线图的取样时间范围,可选择最近5分钟、最近60分钟或最近24小时内的统计数据信息。

    Link Statistics中呈现的参数项包括:
    Link Statistics参数整理
    注意事项:
    ✦ 首先应注意Status保持Connected状态,即保持SRT连接正常;
    ✦ 当发现Reconnections值不断变大时,表明两台设备间的网络通讯异常;
    ✦ 传输时出现少量的Lost Packets属于正常现象;
    ✦ 如果发现Skipped Packets值缓慢增加,通常可以增加一些SRT Latency来解决;但是如果发现Skipped Packets的值会快速变大,那么就应该降低一些视频码率,如果有足够的可用带宽,也可以适当的增加Bandwidth Overhead百分比。

    在解码器HDD-461的Link Statistics中,也有两个曲线图,同样表现带宽和延时随时间变化的曲线,如下图:
    HDD -461中的统计数据曲线
    图4-16 HDD -461中的统计数据曲线

    在上方的Bandwidth Used图中,我们可以看到传输码率曲线,丢包率曲线以及接收数据流传输所使用的带宽。

    注意事项:
    ✦ 如果在解码器输出画面中出现太多的跳帧或丢帧,那么应该增加SRT延时,降低视频码率,和/或增加Bandwidth Overhead百分比

    在Delays图中,同样会体现Buffer曲线与Latency线的关系。

    注意事项:
    ✦ 理想状态下,解码器的buffer值应该十分接近Latency值,如果解码器的接收buffer经常降到0,通常是因为链路带宽不足以支撑所要求的传输码率,此时应该调低传输码率;如果解码器的buffer只是偶尔下降到0,则可以通过增加SRT延时来解决

    结束语

    当大家看完前面的内容,可能会有各种各样的想法,或是为语言的漏洞而感到不满,或是因我的不专业而觉得滑稽,但是无论如何,我都希望每个人在读过这些文字之后,多多少少能够有所收获,从而让我觉得自己反复推敲的措辞并不是徒劳,也让我能感受到写作、分享是快乐的,毕竟这是我第一次自发的、有思想的写东西出来。当然,如果你能帮我发现这篇文章中有的错误,或是有任何的意见和建议,还是希望你能通过我的邮箱告知我:lzrfighting@hotmail.com。

    最后说回SRT这件事,我看到自SRT Alliance成立以来,已经有越来越多的公司和组织加入了这个联盟,如大家所熟识的微软、爱立信、IMT、罗德与施瓦茨等等,也有VLC这种开源媒体播放软件开始支持SRT,也许以后SRT真就成了手机和电脑上无处不在的东西了呢,到时候我写的这几段文字可能也就显得更加浅薄了,但是无论如何还是希望好的技术能够越来越强大,这样技术才能不断进步,人们的生活才能逐步改善。

    2019年6月7日记:
    就在我想要将这篇文档上传到CSDN的几天前,我看到SRT在官网上更新了一些新消息:一,是OBS将开始支持SRT ;二,SRT P2P,即SRT点到点传输;三,安全性提升;四,将支持FEC;五,将支持路由冗余。另外,Alliance官网上的Deployment Guide也对之前的版本做了更新,尤其在FQA部分增加了很多新的内容。我看到的SRT已经在开始逐步进化了,大家让它变得越来越强大、安全、稳定,也让它越来越具有普适性,我真心希望它能茁壮地成长起来。

    展开全文
  • 批量传输:批量传输一般用于批量的和非实时的数据传输,通俗的来说就是用于数据量大但对时间要求又不高的场合的一种传输方式,类似用于USB打印机和USB扫描仪等等。 中断传输:中断传输一般用于小批量的和非连续的...

    原文:https://blog.csdn.net/go_str/article/details/80782229 

    前言
        USB控制传输分为以下四种:
    批量传输:批量传输一般用于批量的和非实时的数据传输,通俗的来说就是用于数据量大但对时间要求又不高的场合的一种传输方式,类似用于USB打印机和USB扫描仪等等。
    中断传输:中断传输一般用于小批量的和非连续的数据传输,通俗的来说就是用于数据量小的数据不连续的但实时性高的场合的一种传输方式,类似用于USB鼠标和USB键盘等等。
    等时传输:等时传输也有“同步传输”的叫法,一般用于要求数据连续、实时且数据量大的场合,其对传输延时十分敏感,类似用于USB摄像设备,USB语音设备等等。
    控制传输:控制传输是一种特殊的传输方式,且传输过程相对以上三种而言更复杂一些,但也十分重要。当USB设备初次连接主机时,用控制传输传送控制命令等对设备进行配置。同时设备接入主机时,需要通过控制传输去获取USB设备的描述符以及对设备进行识别,在设备的枚举过程中都是使用控制传输进行数据交换。

    一、控制传输的结构
        一次完整控制传输可以分为三个阶段:初始设置阶段--->数据阶段(不必须)--->状态信息阶段。下面的

    1、初始设置阶段
        初始设置阶段用于固定建立SETUP事务,标志一次控制传输的开始。初始设置阶段为一个SETUP事务,同样分为三个阶段如下:
    令牌包阶段:
        主机会发送一个SETUP令牌包,如下:

    相当于告诉设备,我要跟你进行通讯请你做好准备。

    数据包阶段:
        发送DATA0数据包(注意SETUP只能使用DATA0包,8字节),让设备接收。例如发送获取设备描述符命令包:

    相当于告诉设备,请将设备描述符的内容发给我。

    握手包阶段:
        设备自动应答。


    结合上面的过程可以用下图表示初始设置阶段。


    2、数据阶段
        初始设置阶段中命令如果要求读/写数据,数据阶段就会在这一阶段来具体交换数据(如果没有数据交换要求则可省去该步骤,具体有SETUP事务标准请求命令决定)。在此需要做一些说明:传输控制在前言有说到控制传输的用途是获取设备信息与对设备进行配置。所以这些数据操作分为以下三类:
    1)、控制读传输;
    2)、控制写传输;
    3)、无数据控制传输。

        一次控制传输必定为上面三种中的其中一种,所以数据阶段中的数据事务也是根据该规则来决定数据事务的。
        此处还应该注意的是数据阶段是由一到多个IN/OUT事务组成。这是由于有时候存在一个事务传不完的数据,所以可能存在多个连续IN/OUT事务的情况。这也就决定了,在同一次数据传输阶段中事务类型必定相同(IN/OUT事务)。

    2.1、传输格式
        综上所述,所以从传输控制的不同类型来讲述数据阶段的格式会更好理解。
    1)、控制读传输
        控制读传输时数据阶段在整个传输的格式如下图蓝框部分:


    数据方向为:设备 —> 主机 (读取USB描述符)
        这里每个数据包是DATA0和DATA1交替出现的。需要注意的是当最后一个包刚好为允许的最大数据包大小时需要再传一个0长度的数据包,表示传输的结束。

    控制读传输的数据过程IN事务的三个阶段如下:
    令牌包阶段:
        主机会发送一个IN令牌包,触发设备产生IN包中断,如下:

    数据包阶段:
        设备回复主机请求,回应数据。例如回复设备描述符命令请求:

    握手包阶段:
        主机自动应答。

    2)、控制写传输
        控制写传输时数据阶段在整个传输的格式如下下图蓝框部分:

    数据方向为:主机 —> 设备(配置USB设备)

    传输过程和规则基本与读取相似,不多做赘述。


    3)、无数据控制
        控制传输不一定要传输很多数据,有些控制可能只是告诉设备要做一件事,这个命令包含在建立阶段的建立事务的8字节数据中即可,设备只需回复主机收到命令与否即可,所以就跳过数据阶段直接进入到状态阶段。无数据控制的格式如下图:

    所以注意在无数据控制传输时,是无数据阶段的!


    3、状态信息阶段
        状态信息阶段是要返回数据传输的成功与否,具体也需要看控制传输的类型。需要注意的是,状态信息的数据传输方向与数据阶段方向相反。例如,数据阶段为IN事务则状态信息阶段为OUT事务。

    3.1、控制读传输
        在控制读传输时,该阶段则为OUT事务,其中的数据包固定为DATA1数据包。返回数据成功与否以有以下情况:
        1)、读数据成功                      主机发送OUT令牌包(ping令牌包,高速情况下),主机发送0长度数据包,设备ACK。
        2)、数据传输出错                   主机发送OUT令牌包(ping令牌包,高速情况下),主机发送0长度数据包,设备STALL。
        3)、设备忙(比如正在写数据)   主机发送OUT令牌包(ping令牌包,高速情况下),主机发送0长度数据包,设备NAK。 

    控制读传输的状态信息阶段OUT事务的三个阶段如下(以ACK为例):
    令牌包阶段:
        主机会发送一个OUT令牌包,如下:

    数据包阶段:
        主机发送0字节数据包,作为状态正常信息回应:

    握手包阶段:
        设备自动应答。

    3.2、控制写传输
        在控制读传输时,该阶段则为IN事务,其中的数据包固定为DATA1数据包。返回数据成功与否以有以下情况:
        1)、写数据成功                      主机发送IN令牌包,主机发送0长度数据包,设备回复ACK。
        2)、数据传输出错                   主机发送IN令牌包,设备回复STALL。
        3)、设备忙(比如正在写数据)   主机发送IN令牌包,设备回复NAK。 

    控制读传输的状态信息阶段IN事务过程与读类似。

    3.3、无数据控制传输
        该阶段则为IN事务,其规则与控制写传输相似。

    至此,一次控制传输完成,整个过程结束。
        因为最近入门USB开发,该博文是经过看网上的资料结合自己的理解整理完成,如果有不得当的地方,希望大家多多指正,谢谢。
    --------------------- 
     

     

    展开全文
  • 敏感信息明文传输相关问题小结

    千次阅读 2018-12-24 09:41:16
    最近在工作,由于同事对敏感信息明文传输这个漏洞认识不深,导致工作出了一些问题。经过一番研究后,发现了其中的一些小知识点,在这里跟大家分享下,具体情况是这样的: 1.我们在做安全测试的时候,经常可以通过...

    最近在工作中,由于同事对敏感信息明文传输这个漏洞认识不深,导致工作出了一些问题。经过一番研究后,发现了其中的一些小知识点,在这里跟大家分享下,具体情况是这样的:

    1.我们在做安全测试的时候,经常可以通过Burpsuit抓包看到一些以明文方式呈现的敏感信息,比如在页面登陆处,我们输入账号密码,通过Burpsuit抓包,可以看到如下类似的数据包。

     

    可以看到在数据包中,用户登陆用的账号和密码都是以明文的形式呈现的,并未经过任何加密。

    但同事被他们内部评估标准洗脑,看到数据包中存在明文的敏感信息就认定此处存在敏感信息明文传输的问题。但这样的判断明显是存在问题的。

     

    1. 通过burpsuit抓到包含明文的数据包时,我们首先应该查看该网站使用的是HTTP协议还是HTTPS协议,如果使用HTTP协议传送明文的敏感信息,那一定的是有问题的。但是如果网站使用的是HTTPS协议,情况则有所不同。
    2. 在这里先介绍一下什么是HTTPS协议,HTTPS被称作安全的HTTP协议,百度上对它的解释如下:

    HTTPS,即超文本传输安全协议,是以安全为目标的HTTP通道,简单讲是HTTP的安全版。即HTTP下加入SSL层,HTTPS的安全基础是SSL。

    首先我们需要明白HTTP位于OSI模型的第七层,属于应用层协议。

    SSL位于OSI模型的第四层,属于传输层协议。

    通俗来说,HTTP协议在从应用层到达传输层时,经过SSL协议加密后就是HTTPS协议。

    需要注意的是:此处的加密并非针对数据包内单个的参数进行加密,而是将整个数据包加密。

    1. 说了这么多,部分萌新可能对我说的应用层和传输层有些疑惑,下面我来简单介绍下OSI七层模型每层的作用,以及数据包从终端A—到达终端B的过程。

    A--B的传输过程如下

    OSI七层模型每一层的作用如下:

    应用层:针对特定功能提供对应协议,比如邮件功能对应电子邮件协议(SMTP),远程登陆对应远程登陆协议(SSH、Telnet),文件传输对应文件传输协议(FTP、SFTP)。(协议就像语言一样,跟不同国家的人交流需要用到不同的语言,不同国家的人相当于各种各样的系统功能,语言就相当于协议,只有使用相同的协议进行通信才能完成特定的系统功能)

    表示层:将设备固有数据格式转换为网络标准数据格式。比如视频数据,表示层就是将Avi,RMVB,MP4等不同的格式的视频数据转换为,网络标准数据格式。感觉说的还是不好。

    举个例子:为了方便不同地区的人进行沟通。表示层可以将开封话,山西话,商丘话,浙江话转换成普通话后在进行传输。接收端接收到普通话后,可根据设备或软件需要将普通话在转换为开封话等。

    会话层:管理通信,负责建立和断开通信。制定通信方案,比如一共要发送6个数据包,会话层根据不同通信需求,控制数据包是一个一个发还是一起发还是3个3个发。

    传输层:管理两个节点间的数据传输。保证数据被可靠的传输到对端地址。

    网络层:提供地址和路由选择。也就是IP地址寻址。

    数据链路层:负责物理层面上互联的设备间的通信。也就是MAC地址寻址。

    物理层:将设备可识别的0、1串转换为电压的高低、灯光闪灭等物理信号。

    在以上过程中,数据只有在从应用层到达传输层之前,在计算机内存中存在短暂的明文状态。

    以OSI七层模型为例,数据每从高层向低层传输一层,低层都会在高层的发来的数据基础之上加上自己的协议包首部.

    使用HTTPS协议的数据包在到达传输层时,传输层除了在数据包之前加上该层协议对应的包首部之外,SSL协议会将此数据包(HTTP协议的数据包)加密,然后再传输。所以说HTTPS协议是基于HTTP协议的,且它的安全性依赖于SSL协议。

    经过SSL协议加密后的HTTP协议就是HTTPS协议.

    数据到达接收方,接收方在传输层经过SSL解密之后,在应用层呈现的就是明文数据.

    用户通过浏览器和服务器通信的正常过程:

    中间人欺骗的过程:

    这里的代理服务器就是实施中间人欺骗的攻击者。

    1、攻击者需要诱使正常用户A安装自己的证书,并将其设置为受信任的根证书颁发机构。

          然后将正常用户A的浏览器代理设置为攻击者的IP地址。

    2、用户发送HTTPS请求,攻击者生成公钥和私钥对1,将自己的证书和公钥发送给用户A,用户A验证攻击者证书的合法性之后,随机生成自己的公钥私钥对,然后用攻击者的公钥1将自己的公钥和HTTP请求发送给攻击者。

    3、攻击者收到用户A请求后,用自己的私钥1将数据包解密,得到用户A的请求和用户A的公钥,之后向服务器发送一个请求。服务器生成自己的公钥私钥对,然后将自己的证书和公钥发送给攻击者,攻击者浏览器验证服务器证书的合法性后,再随机生成公钥私钥对2,然后用服务器发送给自己的公钥将用户A的请求和自己的公钥2发送给服务器。

    4.服务器收到攻击者发来的请求后,用自己的私钥解密得到攻击者发来的HTTP请求和公钥2,然后处理HTTP请求,处理完成后将处理结果用攻击者的公钥加密发送给攻击者。

    5.攻击者收到服务器返回的结果后,用自己的私钥2进行解密,然后将结果用用户A的公钥加密,然后返回给用户A。

    6.用户A浏览器得到攻击者返回的结果后,用自己的私钥进行解密,得到响应明文,之后由浏览器处理,呈现给用户。

    由以上过程可以看出,使用HTTPS协议的网站,攻击者想使用中间人窃听的方式拿到用户明文数据,是有一定难度的。

    关于HTTPS中使用的SSL协议的理解,大家可以参考如下链接,下面这篇文章看起来很舒服且极易理解:

    https://www.cnblogs.com/hai-blog/p/8311671.html

    文字表达能力太差。在这里总结下吧
    使用Burp抓取数据包,看到数据包内的敏感信息以明文的方式存在,这里存在两种情况:

    1.如果网站使用HTTP协议传输数据,则存在敏感信息明文传输问题。攻击者如果使用中间人欺骗的方式可轻易获取明文数据。

    2.如果网站使用HTTPS协议,那么数据包在网络中传递时就是加过密的(这里的网络中是指数据包出了发送端A,但还未到达接收端B,这段时间)。攻击者如果使用中间人欺骗的方式获取数据包,拿到的也是经过加密后的数据包。如果攻击者想获得明文数据包,则需要在用户电脑上安装自己的HTTPS证书,并且需要将用户浏览器代理IP设置为攻击者自己的IP。

    为了防止攻击者通过更改用户代理的方式截获用户数据,在这里建议即便网站使用HTTPS协议进行数据传输,也要将数据在前端经过JS加密后再进行传输。这样即使攻击者通过上述方式截获用户流量,在经过HTTPS解密后拿到的依然是通过JS加密后的敏感数据。这样就进一步给攻击者增加了攻击成本。

     

     

    展开全文
  • 传输介质: 网络传输介质是指在网络中传输信息的载体,常用的传输介质分为有线传输介质(双绞线、同轴电缆和光纤等)和无线传输介质(无线电波、微波和红外线等)两大类。不同的传输介质,其特性也各不相同,它们不同的...
  • UNI使用蓝牙连接设备传输数据

    千次阅读 热门讨论 2020-04-19 02:28:49
    只需要把下面第二个文件复制到项目里面,然后引入就可以了 主要流程: 1.初始化蓝牙适配器openBluetoothAdapter,如果不成功就onBluetoothAdapterStateChange...3.onBluetoothDeviceFound监听寻找到新设备的事件...
  • 使用传真机传输秘密涉密移动存储设备严禁在与互联网连接的计算机上使用,非涉密移动存储设备不得处理和存储涉密信息。涉密计算机、涉密存储设备不得接入互联网及其他公共信息网络。()涉密信息不得在与国际互联网联接...
  • Android设备间USB传输(OTG)

    万次阅读 2014-09-09 11:11:48
     为了统一电脑和外围设备的接口标准,方便用户使用以及端口扩展,Intel和USB-IF组织于1994年开始开发一个通用总线标准-- USB(Universal Serial Bus),并在1995年发布USB1.0标准、2000年发展到USB2.0标准、目前已经...
  • Android Bluetooth蓝牙开发:Bluetooth蓝牙设备之间数据传输(4) 附录文章3简介了Android Bluetooth蓝牙设备之间的连接建立,和Java网络编程的socket套接字连接建立一样,Android不同的Bluetooth蓝牙设备间的...
  • 华为网络设备-FTP文件传输

    千次阅读 2021-01-28 14:09:14
    文章目录关于本实验实验目标实现方式实验拓扑图所需设备地址规划实验任务配置FTP Server 1配置FTP Client 配置新建文本文件设置FTP服务实验验证实验总结 关于本实验 文件传输协议(File Transfer Protocol,FTP)是...
  • 每个高端的程序员都有成为黑客...信息经过传输时,黑客有太多机会窃取经过网络传输信息了。(1)通过广播设备窃取集线器是一种广播设备,它将某个端口接收到的MAC帧从除了接收该MAC帧的端口以外的所有端口发送出去...
  • 在网络通信过程,通信双方要交换数据,需要高度的协同工作。为了正确的解释信号,接收方必须确切地知道信号应当何时接收和处理,因此定时是至关重要的。 在计算机网络,定时的因素称为位同步。同步是要接收方...
  • 一、前言 上一篇文章记录到如何在ubuntu 安装开源项目libusb,这篇将记录,如下使用libusb 提供的api 方便的与USB-HID 设备通讯,通讯方式为中断传输。二、中断传输方式原理,可以我写安卓的那边文章 Android USB ...
  • 工作时间不是很长,如以下观点出现不对的地方欢迎指正 目前在Android领域蓝牙有2.0和4.0,这篇文章只写一下2.0的 以后我会继续补充4.0的 2.0和4.0的区别还是很大的,首先说4.0的耗电量就是很低 当我们准备...
  • 图解数据在网络传输过程

    万次阅读 多人点赞 2020-10-30 10:50:31
    数据在网络传输过程 在计算机网络当中,数据是怎么样保证准确的从客户端发送到服务器端的,这是本文探究的重点。 下图是本文使用的网络拓扑图,数据从客户端发送给服务器端。 客户端各层对数据的封装 java...
  •  厂商自定义 USB 设备的端点可以自由地选择采用哪种传输方式(control transaction 控制传输、bulk transaction 批量传输、interrupt transaction 中断传输、isochronous transfer 实时传输
  • 网络数据传输的过程

    万次阅读 多人点赞 2018-05-23 18:17:56
    1. 数据传输的背景(1) 现在互联网使用的是基于OSI七层模型的TCP/IP模型。TCP/IP模型包括五层,即物理层,数据链路层,网络层,传输层,应用层;其中数据链路层又可以分为两个子层,即LLC(逻辑链路控制层)和MAC...
  • 如果说,传感器是物联网的触觉,那么,无线传输就是物联网的神经系统,将遍布物联网的传感器连接起来。在物联网出现以前,网络的接入需求主要体现在PC、移动终端对互联网的接入需求。如今,随着物联网技术的发展,...
  • 网络传输介质

    千次阅读 2018-10-02 20:57:10
    双绞线(twisted pair,TP)是一种综合布线工程最常用的传输介质,是由两根具有绝缘保护层的铜导线组成的。把两根绝缘的铜导线按一定密度互相绞在一起,每一根导线在传输中辐射出来的电波会被另一根线上发出的电波...
  • iOS蓝牙开发之数据传输精华篇

    千次阅读 2019-01-02 17:45:45
       最近对蓝牙传输比较感兴趣,所以抽时间研究了一下。由于身边没有合适的外部设备,我这边就一台手机作为中心设备,一台手机作为从设备来进行调试,开发。由于关于蓝牙设备配对,连接,简单发送数据网上相关的...
  • 1.什么是UCI在下行物理信道存在着PDCCH控制信道,根据其中承载信息的不同,携带着各种不同的DCI格式,比如DCI0、DCI1A等等,那么在上行物理信道也存在着类似的控制信道,我们叫做PUCCH(Physical Uplink Control...
  • 数据传输技术

    千次阅读 2018-12-09 16:21:06
    数据在通信信道上的各种传输方式及其所采用的技术。
  • 互联网几种常用的传输协议

    万次阅读 2018-11-10 16:27:09
    互联网几种常用的网络传输协议 网路传输协议多种多样,各有所长,学起来真的很让人头大。 对协议的学习需要不断地使用不断加深理解。本篇就是我的个人学习笔记。 --一个正在努力学习的码农新人 协议那么多...
  • 各位客官早,小店今日推出特色套餐“计算机网路基础之数据传输方式”,这道菜可以说是最近一段时间以来最硬的一道特色菜,还望各位走过路过的客官能暂缓脚步,尝一尝!当然了还是免费赠送哦!!! 一、数据传输方式...
  • 蓝牙之数据传输问题

    万次阅读 2017-01-13 16:43:08
    蓝牙数据传输问题对于蓝牙来说google已经封装好了很多api所以使用起来并不会很难,但是实际开发蓝牙开发最头疼的问题不是如何去调用api,而是数据的交互方面,如长连接,数据续传,硬件接受速率等问题.打开蓝牙有几种...
  • Socket传输中文乱码

    万次阅读 2015-07-17 09:49:00
    打开2个ecplise,分别写上客户端和服务器端,数据传输用的是PrintStream方法来传的,当客户端发送数据过去之后,服务器端再把得到的数据返回过来,于是客户端显示的中文就成了乱码 解决方案...
  • 想通过usb音频采集卡连接树莓派后实时采集音频,并通过音频流的方式将采集到的音频实时传输到另外一台电脑。 什么是树莓派? 树莓派是一款基于ARM的微型电脑主板,以SD/MicroSD卡为内存硬盘,卡片主板周围有1/2/4个...
  • 转载原作 信道极限容量 任何实际的信道都不是理想的,在传输信号时会产生各种失真以及带来多种干扰。 数字通信的优点就是在接受端只要能够从失真的波形识别出原来的...码元传输速度越高,或信号传输的距离越远,或噪...
  • 如何计算总线数据传输速率

    千次阅读 2021-07-31 04:54:37
    数据传输速率计算公式:R=(1/T)*log₂N (bps)其中:T为一个数字脉冲信号的宽度(全宽码)或重复周期(归零码),单位为秒;一个数字脉冲也称为一个码元,N为一个码元所取的有效离散值个数,也称调制电平数,N取2的整数...
  • (文章我将展示的是两个设备间的数据相互传输)。   首先要明确的是,我们要做的事情是什么。我将两个设备称为A和C,阿里云称为B。A和C都是订阅了B的设备。已经被订阅的B从设备A的topic获取数据(A和C的数据...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 434,011
精华内容 173,604
关键字:

向设备传输信息中