趣谈网络协议
学习曲线:
-
2021年11月30日16:42:07,学习了(0-4),一个小时整,共计五节课,没兴趣了。
-
2021年12月1日11:00:15,开始,2021年12月1日12:03:38结束,学习了5章节,共计学习一个小时整
-
2021年12月1日17:51:48,结束,学习了8个章节,共计学习;三个小时整
-
2021年12月3日15:20:46,开始,学习了4个章节,共计学习:一个小时整
-
2021年12月10日11:22:22,开始,学习结束
想成为技术牛人?先搞定网络协议!
为什么网络协议这么重要呢?为什么“计算机组成与系统结构”“数据结构与算法”“操作系统”“计算机网络”“编译原理”,会成为大学计算机的核心课程呢?至少看起来,这些内容没有“多少天搞定MFC、Structs”这样的内容更容易帮你找到工作。
随着见过的世面越来越多,我渐渐发现,无论是对于大规模系统的架构,还是对于程序员的个人职业生涯,网络和网络协议都是绕不过去的坎儿。 集群规模一大,我们首先想到的就是网络互通的问题;应用吞吐量压不上去,我们首先想到的也是网络互通的问题。 不客气地讲,很多情况下,只要搞定了网络,一个大型系统也就搞定了一半。所以,要成为技术牛人,搞定大系统,一定要过网络这一关,而网络协议在网络中占有举足轻重的地位。
相信大部分人都思考过“技术变化太快,容易过时”的问题。毕竟,技术浪潮一浪接一浪,新技术层出不穷。从搜索引擎、大数据、云计算,到人工智能、区块链,简直就是“你方唱罢我登场”。这里面究竟有没有最本质的东西,使得你掌握了它,就能在新技术的滚滚浪潮中,保持快速学习的能力? 通过对大量开源技术的代码进行分析,我发现很多技术看起来轰轰烈烈,扒下外衣,本质的东西其实就是基础知识和核心概念。想要不被滚滚而来的新技术淘汰,就要掌握这些可以长久使用的知识,而网络协议就是值得你学习,而且是到40岁之后依然有价值的知识。
一看觉得懂,一问就打鼓,一用就糊涂
-
网络协议知识点太多,学完记不住。
-
看上去懂了,但是经不住问。
-
知识学会了,实际应用依旧不会。
千里之行,始于足下。不管何时,我相信,扎实的功底和过硬的技术,都会是你职业发展的助力器。
希望不仅可以帮你理清繁杂的网络协议概念,帮你构建一个精准的网络协议知识框架,帮你在热门领域应用这些底层知识,更重要的是给你一种学习知识的方法和态度:看似最枯燥、最基础的东西往往具有最长久的生命力。
为什么要学习网络协议?
《圣经》中有一个通天塔的故事,大致是说,上帝为了阻止人类联合起来,就让人类说不同的语言。人类没法儿沟通,达不成“协议”,通天塔的计划就失败了。但是千年以后,有一种叫“程序猿”的物种,敲着一种这个群体通用的语言,连接着全世界所有的人,打造这互联网世界的通天塔。如今的世界,正是因为互联网,才连接在一起。
协议三要素
当然,这种协议还是更接近人类语言,机器不能直接读懂,需要进行翻译,翻译的工作教给编译器,也就是程序员常说的compile。这个过程比较复杂,其中的编译原理非常复杂,我在这里不进行详述。
-
语法,就是这一段内容要符合一定的规则和格式。例如,括号要成对,结束要使用分号等。
-
语义,就是这一段内容要代表某种意义。例如数字减去数字是有意义的,数字减去文本一般来说就没有意义。
-
顺序,就是先干啥,后干啥。例如,可以先加上某个数值,然后再减去某个数值。
会了计算机语言,你就能够教给一台计算机完成你的工作了。恭喜你,入门了!
但是,要想打造互联网世界的通天塔,只教给一台机器做什么是不够的,你需要学会教给一大片机器做什么。这就需要网络协议。只有通过网络协议,才能使一大片机器互相协作、共同完成一件事。
双11 简简单单的下单过程涉及的协议?
DNS、HTTP、HTTPS所在的层我们称为应用层。经过应用层封装后,浏览器会将应用层的包交给下一层去完成,通过socket编程来实现。下一层是传输层。传输层有两种协议,一种是无连接的协议UDP,一种是面向连接的协议TCP。对于支付来讲,往往使用TCP协议。所谓的面向连接就是,TCP会保证这个包能够到达目的地。如果不能到达,就会重新发送,直至到达。
TCP协议里面会有两个端口,一个是浏览器监听的端口,一个是电商的服务器监听的端口。操作系统往往通过端口来判断,它得到的包应该给哪个进程。
传输层封装完毕后,浏览器会将包交给操作系统的网络层。网络层的协议是IP协议。在IP协议里面会有源IP地址,即浏览器所在机器的IP地址和目标IP地址,也即电商网站所在服务器的IP地址。
操作系统既然知道了目标IP地址,就开始想如何根据这个门牌号找到目标机器。操作系统往往会判断,这个目标IP地址是本地人,还是外地人。如果是本地人,从门牌号就能看出来,但是显然电商网站不在本地,而在遥远的地方。
操作系统知道要离开本地去远方。虽然不知道远方在何处,但是可以这样类比一下:如果去国外要去海关,去外地就要去网关。而操作系统启动的时候,就会被DHCP协议配置IP地址,以及默认的网关的IP地址192.168.1.1。
操作系统如何将IP地址发给网关呢?在本地通信基本靠吼,于是操作系统大吼一声,谁是192.168.1.1啊?网关会回答它,我就是,我的本地地址在村东头。这个本地地址就是MAC地址,而大吼的那一声是ARP协议。
于是操作系统将IP包交给了下一层,也就是MAC层。网卡再将包发出去。由于这个包里面是有MAC地址的,因而它能够到达网关。
网关收到包之后,会根据自己的知识,判断下一步应该怎么走。网关往往是一个路由器,到某个IP地址应该怎么走,这个叫作路由表。
路由器有点像玄奘西行路过的一个个国家的一个个城关。每个城关都连着两个国家,每个国家相当于一个局域网,在每个国家内部,都可以使用本地的地址MAC进行通信。
一旦跨越城关,就需要拿出IP头来,里面写着贫僧来自东土大唐(就是源IP地址),欲往西天拜佛求经(指的是目标IP地址)。路过宝地,借宿一晚,明日启程,请问接下来该怎么走啊?
城关往往是知道这些“知识”的,因为城关和临近的城关也会经常沟通。到哪里应该怎么走,这种沟通的协议称为路由协议,常用的有OSPF和BGP。
城关与城关之间是一个国家,当网络包知道了下一步去哪个城关,还是要使用国家内部的MAC地址,通过下一个城关的MAC地址,找到下一个城关,然后再问下一步的路怎么走,一直到走出最后一个城关。
最后一个城关知道这个网络包要去的地方。于是,对着这个国家吼一声,谁是目标IP啊?目标服务器就会回复一个MAC地址。网络包过关后,通过这个MAC地址就能找到目标服务器。
目标服务器发现MAC地址对上了,取下MAC头来,发送给操作系统的网络层。发现IP也对上了,就取下IP头。IP头里会写上一层封装的是TCP协议,然后将其交给传输层,即TCP层。
在这一层里,对于收到的每个包,都会有一个回复的包说明收到了。这个回复的包绝非这次下单请求的结果,例如购物是否成功,扣了多少钱等,而仅仅是TCP层的一个说明,即收到之后的回复。当然这个回复,会沿着刚才来的方向走回去,报个平安。
因为一旦出了国门,西行路上千难万险,如果在这个过程中,网络包走丢了,例如进了大沙漠,或者被强盗抢劫杀害怎么办呢?因而到了要报个平安。
如果过一段时间还是没到,发送端的TCP层会重新发送这个包,还是上面的过程,直到有一天收到平安到达的回复。这个重试绝非你的浏览器重新将下单这个动作重新请求一次。对于浏览器来讲,就发送了一次下单请求,TCP层不断自己闷头重试。除非TCP这一层出了问题,例如连接断了,才轮到浏览器的应用层重新发送下单请求。
当网络包平安到达TCP层之后,TCP头中有目标端口号,通过这个端口号,可以找到电商网站的进程正在监听这个端口号,假设一个Tomcat,将这个包发给电商网站。
电商网站的进程得到HTTP请求的内容,知道了要买东西,买多少。往往一个电商网站最初接待请求的这个Tomcat只是个接待员,负责统筹处理这个请求,而不是所有的事情都自己做。例如,这个接待员要告诉专门管理订单的进程,登记要买某个商品,买多少,要告诉管理库存的进程,库存要减少多少,要告诉支付的进程,应该付多少钱,等等。
如何告诉相关的进程呢?往往通过RPC调用,即远程过程调用的方式来实现。远程过程调用就是当告诉管理订单进程的时候,接待员不用关心中间的网络互连问题,会由RPC框架统一处理。RPC框架有很多种,有基于HTTP协议放在HTTP的报文里面的,有直接封装在TCP报文里面的。
当接待员发现相应的部门都处理完毕,就回复一个HTTPS的包,告知下单成功。这个HTTPS的包,会像来的时候一样,经过千难万险到达你的个人电脑,最终进入浏览器,显示支付成功。
当网络包到达一个城关的时候,可以通过路由表得到下一个城关的IP地址,直接通过IP地址找就可以了,为什么还要通过本地的MAC地址呢?
网络分层的真实含义是什么?
长时间从事计算机网络相关的工作,我发现,计算机网络有一个显著的特点,就是这是一个不仅需要背诵,而且特别需要将原理烂熟于胸的学科。很多问题看起来懂了,但是就怕往细里问,一问就发现你懂得没有那么透彻。
我们上一节列了之后要讲的网络协议。这些协议本来没什么稀奇,每一本教科书都会讲,并且都要求你背下来。因为考试会考,面试会问。可以这么说,毕业了去找工作还答不出这类题目的,那你的笔试基本上也就挂了。
当你听到什么二层设备、三层设备、四层LB和七层LB中层的时候,是否有点一头雾水,不知道这些所谓的层,对应的各种协议具体要做什么“工作”?
从你的电脑,通过SSH登录到公有云主机里面,都需要经历哪些过程?或者说你打开一个电商网站,都需要经历哪些过程?说得越详细越好。
网络为什么要分层?
复杂的程序都要分层,这是程序设计的要求。
这里我们先探讨第一个问题,网络为什么要分层?因为,是个复杂的程序都要分层。
理解计算机网络中的概念,一个很好的角度是,想象网络包就是一段Buffer,或者一块内存,是有格式的。同时,想象自己是一个处理网络包的程序,而且这个程序可以跑在电脑上,可以跑在服务器上,可以跑在交换机上,也可以跑在路由器上。你想象自己有很多的网口,从某个口拿进一个网络包来,用自己的程序处理一下,再从另一个网口发送出去。
当然网络包的格式很复杂,这个程序也很复杂。复杂的程序都要分层,这是程序设计的要求。比如,复杂的电商还会分数据库层、缓存层、Compose层、Controller层和接入层,每一层专注做本层的事情。
程序是如何工作的?
当一个网络包从一个网口经过的时候,你看到了,首先先看看要不要请进来,处理一把。有的网口配置了混杂模式,凡是经过的,全部拿进来。
拿进来以后,就要交给一段程序来处理。于是,你调用process_layer2(buffer)。当然,这是一个假的函数。但是你明白其中的意思,知道肯定是有这么个函数的。那这个函数是干什么的呢?从Buffer中,摘掉二层的头,看一看,应该根据头里面的内容做什么操作。
假设你发现这个包的MAC地址和你的相符,那说明就是发给你的,于是需要调用process_layer3(buffer)。这个时候,Buffer里面往往就没有二层的头了,因为已经在上一个函数的处理过程中拿掉了,或者将开始的偏移量移动了一下。在这个函数里面,摘掉三层的头,看看到底是发送给自己的,还是希望自己转发出去的。
如何判断呢?如果IP地址不是自己的,那就应该转发出去;如果IP地址是自己的,那就是发给自己的。根据IP头里面的标示,拿掉三层的头,进行下一层的处理,到底是调用process_tcp(buffer)呢,还是调用process_udp(buffer)呢?
假设这个地址是TCP的,则会调用process_tcp(buffer)。这时候,Buffer里面没有三层的头,就需要查看四层的头,看这是一个发起,还是一个应答,又或者是一个正常的数据包,然后分别由不同的逻辑进行处理。如果是发起或者应答,接下来可能要发送一个回复包;如果是一个正常的数据包,就需要交给上层了。交给谁呢?是不是有process_http(buffer)函数呢?
没有的,如果你是一个网络包处理程序,你不需要有process_http(buffer),而是应该交给应用去处理。交给哪个应用呢?在四层的头里面有端口号,不同的应用监听不同的端口号。如果发现浏览器应用在监听这个端口,那你发给浏览器就行了。至于浏览器怎么处理,和你没有关系。
浏览器自然是解析HTML,显示出页面来。电脑的主人看到页面很开心,就点了鼠标。点击鼠标的动作被浏览器捕获。浏览器知道,又要发起另一个HTTP请求了,于是使用端口号,将请求发给了你。
你应该调用send_tcp(buffer)。不用说,Buffer里面就是HTTP请求的内容。这个函数里面加一个TCP的头,记录下源端口号。浏览器会给你目的端口号,一般为80端口。
然后调用send_layer3(buffer)。Buffer里面已经有了HTTP的头和内容,以及TCP的头。在这个函数里面加一个IP的头,记录下源IP的地址和目标IP的地址。
然后调用send_layer2(buffer)。Buffer里面已经有了HTTP的头和内容、TCP的头,以及IP的头。这个函数里面要加一下MAC的头,记录下源MAC地址,得到的就是本机器的MAC地址和目标的MAC地址。不过,这个还要看当前知道不知道,知道就直接加上;不知道的话,就要通过一定的协议处理过程,找到MAC地址。反正要填一个,不能空着。
万事俱备,只要Buffer里面的内容完整,就可以从网口发出去了,你作为一个程序的任务就算告一段落了。
揭秘层与层之间的关系
只要是在网络上跑的包,都是完整的。可以有下层没上层,绝对不可能有上层没下层。
所以,对TCP协议来说,三次握手也好,重试也好,只要想发出去包,就要有IP层和MAC层,不然是发不出去的。
经常有人会问这样一个问题,我都知道那台机器的IP地址了,直接发给他消息呗,要MAC地址干啥?这里的关键就是,没有MAC地址消息是发不出去的。
所以如果一个HTTP协议的包跑在网络上,它一定是完整的。无论这个包经过哪些设备,它都是完整的。
所谓的二层设备、三层设备,都是这些设备上跑的程序不同而已。一个HTTP协议的包经过一个二层设备,二层设备收进去的是整个网络包。这里面HTTP、TCP、 IP、 MAC都有。什么叫二层设备呀,就是只把MAC头摘下来,看看到底是丢弃、转发,还是自己留着。那什么叫三层设备呢?就是把MAC头摘下来之后,再把IP头摘下来,看看到底是丢弃、转发,还是自己留着。
小结
总结一下今天的内容,理解网络协议的工作模式,有两个小窍门:
-
始终想象自己是一个处理网络包的程序:如何拿到网络包,如何根据规则进行处理,如何发出去;
-
始终牢记一个原则:只要是在网络上跑的包,都是完整的。可以有下层没上层,绝对不可能有上层没下层。
ifconfig:最熟悉又陌生的命令行
-
IP是地址,有定位功能;MAC是身份证,无定位功能;
-
CIDR可以用来判断是不是本地人;
-
IP分公有的IP和私有的IP
DHCP与PXE:IP是怎么来的,又是怎么没的?
动态主机配置协议(DHCP)
原来配置IP有这么多门道儿啊。你可能会问了,配置了IP之后一般不能变的,配置一个服务端的机器还可以,但是如果是客户端的机器呢?我抱着一台笔记本电脑在公司里走来走去,或者白天来晚上走,每次使用都要配置IP地址,那可怎么办?还有人事、行政等非技术人员,如果公司所有的电脑都需要IT人员配置,肯定忙不过来啊。
因此,我们需要有一个自动配置的协议,也就是动态主机配置协议(Dynamic Host Configuration Protocol),简称DHCP。
有了这个协议,网络管理员就轻松多了。他只需要配置一段共享的IP地址。每一台新接入的机器都通过DHCP协议,来这个共享的IP地址里申请,然后自动配置好就可以了。等人走了,或者用完了,还回去,这样其他的机器也能用。
所以说,如果是数据中心里面的服务器,IP一旦配置好,基本不会变,这就相当于买房自己装修。DHCP的方式就相当于租房。你不用装修,都是帮你配置好的。你暂时用一下,用完退租就可以了。
UDP协议
UDP和TCP是传输层的网络协议
UDP的三大特点
UDP就像小孩子一样,有以下这些特点:
第一,沟通简单,不需要一肚子花花肠子(大量的数据结构、处理逻辑、包头字段)。前提是它相信网络世界是美好的,秉承性善论,相信网络通路默认就是很容易送达的,不容易被丢弃的。
第二,轻信他人。它不会建立连接,虽然有端口号,但是监听在这个地方,谁都可以传给他数据,他也可以传给任何人数据,甚至可以同时传给多个人数据。
第三,愣头青,做事不懂权变。不知道什么时候该坚持,什么时候该退让。它不会根据网络的情况进行发包的拥塞控制,无论网络丢包丢成啥样了,它该怎么发还怎么发。
UDP的三大使用场景
第一,需要资源少,在网络情况比较好的内网,或者对于丢包不敏感的应用。
第二,不需要一对一沟通,建立连接,而是可以广播的应用。
第三,需要处理速度快,时延低,可以容忍少数丢包,但是要求即便网络拥塞,也毫不退缩,一往无前的时候。
基于UDP的“城会玩”的五个例子
“城会玩”一:网页或者APP的访问
原来访问网页和手机APP都是基于HTTP协议的。HTTP协议是基于TCP的,建立连接都需要多次交互,对于时延比较大的目前主流的移动互联网来讲,建立一次连接需要的时间会比较长,然而既然是移动中,TCP可能还会断了重连,也是很耗时的。而且目前的HTTP协议,往往采取多个数据通道共享一个连接的情况,这样本来为了加快传输速度,但是TCP的严格顺序策略使得哪怕共享通道,前一个不来,后一个和前一个即便没关系,也要等着,时延也会加大。
而QUIC(全称Quick UDP Internet Connections,快速UDP互联网连接)是Google提出的一种基于UDP改进的通信协议,其目的是降低网络通信的延迟,提供更好的用户互动体验。
QUIC在应用层上,会自己实现快速连接建立、减少重传时延,自适应拥塞控制,是应用层“城会玩”的代表。这一节主要是讲UDP,QUIC我们放到应用层去讲。
“城会玩”二:流媒体的协议
现在直播比较火,直播协议多使用RTMP,这个协议我们后面的章节也会讲,而这个RTMP协议也是基于TCP的。TCP的严格顺序传输要保证前一个收到了,下一个才能确认,如果前一个收不到,下一个就算包已经收到了,在缓存里面,也需要等着。对于直播来讲,这显然是不合适的,因为老的视频帧丢了其实也就丢了,就算再传过来用户也不在意了,他们要看新的了,如果老是没来就等着,卡顿了,新的也看不了,那就会丢失客户,所以直播,实时性比较比较重要,宁可丢包,也不要卡顿的。
另外,对于丢包,其实对于视频播放来讲,有的包可以丢,有的包不能丢,因为视频的连续帧里面,有的帧重要,有的不重要,如果必须要丢包,隔几个帧丢一个,其实看视频的人不会感知,但是如果连续丢帧,就会感知了,因而在网络不好的情况下,应用希望选择性的丢帧。
还有就是当网络不好的时候,TCP协议会主动降低发送速度,这对本来当时就卡的看视频来讲是要命的,应该应用层马上重传,而不是主动让步。因而,很多直播应用,都基于UDP实现了自己的视频传输协议
“城会玩”三:实时游戏
“城会玩”四:IoT物联网
“城会玩”五:移动通信领域
TCP协议
通过对TCP头的解析,我们知道要掌握TCP协议,重点应该关注以下几个问题:
-
顺序问题 ,稳重不乱;
-
丢包问题,承诺靠谱;
-
连接维护,有始有终;
-
流量控制,把握分寸;
-
拥塞控制,知进知退。
TCP的连接建立,我们常常称为三次握手。
A:您好,我是A。
B:您好A,我是B。
A:您好B。
我们也常称为“请求->应答->应答之应答”的三个回合。
-
你需要记住TCP和UDP的Socket的编程中,客户端和服务端都需要调用哪些函数;
-
写一个能够支撑大量连接的高并发的服务端不容易,需要多进程、多线程,而epoll机制能解决C10K问题。
HTTP协议
开始应用层协议,上面是传输层的协议。
HTTP是基于TCP协议的,当然是要先建立TCP连接了,怎么建立呢?还记得第11节讲过的三次握手吗? 目前使用的HTTP协议大部分都是1.1。在1.1的协议里面,默认是开启了Keep-Alive的,这样建立的TCP连接,就可以在多次请求中复用。
HTTPS协议
流媒体协议(RTMP协议)
编码是一个压缩的过程
每一张图片,我们称为一帧。只要每秒钟帧的数据足够多,也即播放得足够快。比如每秒30帧,以人的眼睛的敏感程度,是看不出这是一张张独立的图片的,这就是我们常说的帧率(FPS)。
每一张图片,都是由像素组成的,假设为1024*768(这个像素数不算多)。每个像素由RGB组成,每个8位,共24位。
我们来算一下,每秒钟的视频有多大?
30帧 × 1024 × 768 × 24 = 566,231,040Bits = 70,778,880Bytes
如果一分钟呢?4,246,732,800Bytes,已经是4个G了。
视频和图片的压缩过程有什么特点?
之所以能够对视频流中的图片进行压缩,因为视频和图片有这样一些特点。
-
空间冗余:图像的相邻像素之间有较强的相关性,一张图片相邻像素往往是渐变的,不是突变的,没必要每个像素都完整地保存,可以隔几个保存一个,中间的用算法计算出来。
-
时间冗余:视频序列的相邻图像之间内容相似。一个视频中连续出现的图片也不是突变的,可以根据已有的图片进行预测和推断。
-
视觉冗余:人的视觉系统对某些细节不敏感,因此不会每一个细节都注意到,可以允许丢失一些数据。
-
编码冗余:不同像素值出现的概率不同,概率高的用的字节少,概率低的用的字节多,类似霍夫曼编码(Huffman Coding)的思路。
总之,用于编码的算法非常复杂,而且多种多样,但是编码过程其实都是类似的。
ITU-T(国际电信联盟电信标准化部门,ITU Telecommunication Standardization Sector)与MPEG联合制定了H.264/MPEG-4 AVC,这才是我们这一节要重点关注的
如何在直播里看到帅哥美女?
当然,这个二进制也可以通过某种网络协议进行封装,放在互联网上传输,这个时候就可以进行网络直播了。
网络协议将编码好的视频流,从主播端推送到服务器,在服务器上有个运行了同样协议的服务端来接收这些网络包,从而得到里面的视频流,这个过程称为接流。
服务端接到视频流之后,可以对视频流进行一定的处理,例如转码,也即从一个编码格式,转成另一种格式。因为观众使用的客户端千差万别,要保证他们都能看到直播。
流处理完毕之后,就可以等待观众的客户端来请求这些视频流。观众的客户端请求的过程称为拉流。
如果有非常多的观众,同时看一个视频直播,那都从一个服务器上拉流,压力太大了,因而需要一个视频的分发网络,将视频预先加载到就近的边缘节点,这样大部分观众看的视频,是从边缘节点拉取的,就能降低服务器的压力。
当观众的客户端将视频流拉下来之后,就需要进行解码,也即通过上述过程的逆过程,将一串串看不懂的二进制,再转变成一帧帧生动的图片,在客户端播放出来,这样你就能看到美女帅哥啦。
整个直播过程,可以用这个的图来描述。
编码:如何将丰富多彩的图片变成二进制流?
虽然我们说视频是一张张图片的序列,但是如果每张图片都完整,就太大了,因而会将视频序列分成三种帧。
-
I帧,也称关键帧。里面是完整的图片,只需要本帧数据,就可以完成解码。
-
P帧,前向预测编码帧。P帧表示的是这一帧跟之前的一个关键帧(或P帧)的差别,解码时需要用之前缓存的画面,叠加上和本帧定义的差别,生成最终画面。
-
B帧,双向预测内插编码帧。B帧记录的是本帧与前后帧的差别。要解码B帧,不仅要取得之前的缓存画面,还要解码之后的画面,通过前后画面的数据与本帧数据的叠加,取得最终的画面。
可以看出,I帧最完整,B帧压缩率最高,而压缩后帧的序列,应该是在IBBP的间隔出现的。这就是通过时序进行编码。
一个视频,可以拆分成一系列的帧,每一帧拆分成一系列的片,每一片都放在一个NALU里面,NALU之间都是通过特殊的起始标识符分隔,在每一个I帧的第一片前面,要插入单独保存SPS和PPS的NALU,最终形成一个长长的NALU序列。
推流:如何把数据流打包传输到对端?
那这个格式是不是就能够直接在网上传输到对端,开始直播了呢?其实还不是,还需要将这个二进制的流打包成网络包进行发送,这里我们使用RTMP协议。这就进入了第二个过程,推流。
RTMP是基于TCP的,因而肯定需要双方建立一个TCP的连接。在有TCP的连接的基础上,还需要建立一个RTMP的连接,也即在程序里面,你需要调用RTMP类库的Connect函数,显示创建一个连接。
RTMP为什么需要建立一个单独的连接呢?
因为它们需要商量一些事情,保证以后的传输能正常进行。主要就是两个事情,一个是版本号,如果客户端、服务器的版本号不一致,则不能工作。另一个就是时间戳,视频播放中,时间是很重要的,后面的数据流互通的时候,经常要带上时间戳的差值,因而一开始双方就要知道对方的时间戳。
未来沟通这些事情,需要发送六条消息:客户端发送C0、C1、 C2,服务器发送S0、 S1、 S2。
首先,客户端发送C0表示自己的版本号,不必等对方的回复,然后发送C1表示自己的时间戳。
服务器只有在收到C0的时候,才能返回S0,表明自己的版本号,如果版本不匹配,可以断开连接。
服务器发送完S0后,也不用等什么,就直接发送自己的时间戳S1。客户端收到S1的时候,发一个知道了对方时间戳的ACK C2。同理服务器收到C1的时候,发一个知道了对方时间戳的ACK S2。
于是,握手完成。
视频名词比较多,编码两大流派达成了一致,都是通过时间、空间的各种算法来压缩数据;
压缩好的数据,为了传输组成一系列NALU,按照帧和片依次排列;
排列好的NALU,在网络传输的时候,要按照RTMP包的格式进行包装,RTMP的包会拆分成Chunk进行传输;
推送到流媒体集群的视频流经过转码和分发,可以被客户端通过RTMP协议拉取,然后组合为NALU,解码成视频格式进行播放。
FTP协议
如果你想下载一个电影,一般会通过什么方式呢?
当然,最简单的方式就是通过HTTP进行下载。但是相信你有过这样的体验,通过浏览器下载的时候,只要文件稍微大点,下载的速度就奇慢无比。
还有种下载文件的方式,就是通过FTP,也即文件传输协议。FTP采用两个TCP连接来传输一个文件。
-
控制连接:服务器以被动的方式,打开众所周知用于FTP的端口21,客户端则主动发起连接。该连接将命令从客户端传给服务器,并传回服务器的应答。常用的命令有:list——获取文件目录;reter——取一个文件;store——存一个文件。
-
数据连接:每当一个文件在客户端与服务器之间传输时,就创建一个数据连接。
P2P协议
-
下载一个文件可以使用HTTP或FTP,这两种都是集中下载的方式,而P2P则换了一种思路,采取非中心化下载的方式;
-
P2P也是有两种,一种是依赖于tracker的,也即元数据集中,文件数据分散;另一种是基于分布式的哈希算法,元数据和文件数据全部分散。
DNS协议
传统的DNS有很多问题,例如解析慢、更新不及时。因为缓存、转发、NAT问题导致客户端误会自己所在的位置和运营商,从而影响流量的调度。
HttpDNS通过客户端SDK和服务端,通过HTTP直接调用解析DNS的方式,绕过了传统DNS的这些缺点,实现了智能的调度。
-
CDN和电商系统的分布式仓储系统一样,分为中心节点、区域节点、边缘节点,而数据缓存在离用户最近的位置。
-
CDN最擅长的是缓存静态数据,除此之外还可以缓存流媒体数据,这时候要注意使用防盗链。它也支持动态数据的缓存,一种是边缘计算的生鲜超市模式,另一种是链路优化的冷链运输模式。2021年12月3日17:48:41
(by 极客时间课程)