题记

最近在极客时间上面学习了刘超老师的《趣谈网络协议》，深入浅出的介绍了网络协议的原理和应用，受益匪浅。这里把文章的一些精髓，结合自己的见解，整理成学习笔记，希望能帮助到大家。

网络协议为什么要分层？

互联网世界中，有千千万万台网络设备，他们彼此是不知道的。当我们需要访问其中一台设备的时候，最笨的方法就是每台设备都去询问一下：你是不是我要找的设备啊？这样的做法显然是低效的。

为了解决这个问题，所以就有了网络协议分层，最底层物理层，通讯方式就是像上面说的那种，一个个设备去敲门，因为一个一层网络的机器并不多，所以这种做法是可以接受的。协议越往上走，会聪明灵活。至于怎么个灵活法，我就来试试看，看我能不能把这个问题讲清楚。

网络协议分层.jpg

网络设备

为了实现网络协议分层，离不开网络设备的帮助，下面我们就先来介绍一下这些常见的网络设备：

1. 一层网络设备

   1. 中继器

      早期用于网络信号放大的机器。

   2. HUB（集线器）

      当A机器发送信号的时候，集线器会将信号广播给每一个机器。

   一层网络设备，因为不知道谁是谁，集线器也只是一个广播站而已，所以可以说：一层协议通讯基本靠吼。

2. 二层网络设备

   1. 网卡

      记录机器的mac地址，他是二层协议到一层协议的转换者。

   2. L2交换机

      工作在数据链路层的交换机，内置MAC学习机制，他能记录每一个端口的mac地址。

   3. 网桥

      连接两个局域网的一种存储/转发设备，它能将一个大的LAN分割为多个网段，或将两个以上的LAN互联为一个逻辑LAN，使LAN上的所有用户都可访问服务器。

   二层网络设备（L2交换机和网桥）和一层网络设备（HUB）有点像，但是不同点在于，HUB只是将多个设备连接到同一个子网中，每个接口连接的是一个机器，而二层网络设备，是连通多个子网的，每个接口连接的一个子网，或者是一张网卡。

   一层网络设备是没有地址的，只能广播，二层网络设备是有地址的，就是mac地址。

3. 三层网络设备

   1. 网关（Gateway）

      网关往往是一个路由器，是一个三层转发设备，他会把mac头和ip头取下来，然后根据里面的内容，决定接下来包往哪里发。

   2. 路由器

      路由器是一台设备，它有五个网口或者网卡，相当于有五只手，分别连着五个局域网。每只手的ip地址都和局域网的ip地址处于相同的网段，每只手都是他握住的那个局域网的网关。

   路由器相比于网关，功能更加强大一些，网关是三层到二层的出入口，而路由器，可以是三层到三层，也可以是三层到二层，也就是说，路由器上的端口，可以是路由器，也可以是网关。

   三层设备同二层设备一样，都是有地址的设备，二层设备是mac地址，三层设备是ip地址。

网络协议

从数据链路层开始，因为层级越来越复杂，就需要规定一些越来越复杂的网络协议。

下面就介绍一下这些协议，其中重点部分会重点来讲：

网络层协议

IP协议

IP协议是网络层协议，是Internet中最重要的协议。网络层的作用，是给数据包选择路由，而IP协议，就是给每一个机器定义一个唯一的门牌号，这个门牌号可以是什么路多少号（公网IP），也可以是多少栋的什么房号（局域网IP）。

ARP协议

Address Resolution Protocol，地址解析协议。他是工作在网络层的协议，职责是将IP地址转换成mac地址。

每台安装TCP/IP协议的计算机或者路由器里面，都维护一张IP-MAC映射表，当发送数据时，源主机就会在表里面找IP对应的mac地址，当源主机不知道目标主机的mac地址的时候，通过广播的方式给局域网内所有机器发广播的方式，机器收到广播后，不是该mac地址的机器不处理响应，是该mac地址的机器，向主机报告自己的mac地址，这样子主机就获得了这个ip的mac地址映射，然后更新到映射表。

实践一下

七层网络协议里面，下三层的主要作用是寻址，上四层才是负责交互。上面已经介绍了下三层的协议类型和网络设备，下面就来实践一下，看看在一次寻址过程中，都会怎么使用这些协议和设备，把上面的知识串起来。

首先看一下MAC头和IP头的数据结构，如下图：

MAC头和IP头

刨去一些校验位和配置信息等，这两个头最重要的数据是以下四个：

• 源MAC
• 目标MAC
• 源IP
• 目标IP

在一次网络数据传输过程中，这些数据会怎么变，然后各个网络协议和网络设备又起到什么作用？看下面这个例子：

网络包传输Demo

服务器A想访问服务器B的80端口，但是他们不再同一个局域网，这个时候，服务器A是知道服务器B的公共IP是192.168.56.2，这个时候他想要把包发给服务器B，会经过哪些步骤呢？

首先，通过分析网段知道，服务器A跟服务器B不是同一个网段的（服务器A的网段是192.168.1.0/24，服务器B的网段是192.168.56.0/24），所以要想访问到服务器B，就要先出网关。这个时候，通过ARP协议，服务器A知道网段的MAC地址，通过静态配置信息，知道网关IP是192.168.1.1，然后就开始发送包了。包的内容是这样的：

• 源MAC：服务器A的MAC
• 目标MAC：192.168.1.1这个网口的MAC
• 源IP：192.168.1.101
• 目标IP：192.168.56.2

这个时候，因为这个包已经出了192.168.1.0/24这个局域网，所以这个包就有了一个国际身份，就是192.168.56.1，而帮他安排上这个国际身份的就是192.168.1.1这个网关。在这里，网络地址发生了一次转换，我们称这个网关为NAT网关（Network Address Translation）。

192.168.56.1这是个路由器，通过他的路由规则，发现想要到192.168.56.2这个地址，就要从自己右边这个口出去，通过ARP协议，他知道了192.168.56.2这台设备的MAC地址，然后就开始发送包了。包的内容是这样的：

• 源MAC：192.168.56.1的MAC
• 目标MAC：192.168.56.2这个网口的MAC
• 源IP：192.168.56.1
• 目标IP：192.168.56.2

这个时候，包已经到了192.168.56.2这台路由器，通过检查自身的端口映射，发现要访问80端口，就要转发到国内身份是192.168.1.101的这台机器，而访问192.168.1.101，就要不能使用自己的国际身份192.168.56.2，而要使用192.168.1.1。所以就使用了通过ARP协议，得到了该机器的MAC地址，然后就开始发送包了。包的内容是这样的：

• 源MAC：192.168.56.2的MAC
• 目标MAC：192.168.1.101这个网口的MAC
• 源IP：192.168.1.1
• 目标IP：192.168.1.101

以上就是一个网络包在网络中传输的简化过程，简而言之，就是首先在网络层不断的通过网关和路由器，找到通往目标机器的路径，中间的数据链路层又通过使用ARP协议来知道目标MAC，然后在物理层传输信号。

传输层协议

UDP协议

UDP协议头

UDP协议的协议头比TCP协议头简单，它继承了IP的特性，基于数据包的，一个一个地发，一个一个地收，不保证不丢失，不保证顺序到达。基于简单的特性，他有以下常用的使用场景：

1. 网页或者APP的访问，特别适用于移动端

   因为移动中的关系，网络会出现不稳定，如果是TCP协议，断了还会重连，就会很耗时。为此，Google推出了QUIC（全称Quick UDP Internet Connections，快速UDP互联网连接），其目的是降低网络通信的延迟，提供更好的用户互动体验。

2. 流媒体协议

   比如直播这种场景，用户不需要补发，中间丢一两个包没关系，用户也不会看了，关键是要实时。而网络不好的时候，TCP协议的补发机制就会影响最新数据包的接收，所以很多直播应用，都是基于UCP实现了自己的视频传输协议。

3. 实时对战游戏

   实时游戏和直播类似，也是强调实时，因为如果为了过期数据的补发而延迟一秒，很可能恢复的时候就挂了。所以，像这种对实时性要求较为严格的情况下，使用UDP协议，自定义重传策略，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏造成的影响。

4. IoT物联网

5. 移动通信领域

简而言之，如果你的场景对实时性要求很高，并且能够接受过期包丢失的情况下，那么使用UDP协议的灵活性会对你有帮助，而TCP协议的严格有序而造成的数据延迟，就会成为你的负担。

TCP协议

TCP协议头

对比UDP协议的包头可以发现，TCP协议头比UDP协议头会复杂很多，而这些复杂的头部数据，就给TCP 提供了可靠交付。通过 TCP 连接传输的数据，无差错、不重复、并且按序到达。TCP还提供拥塞控制，如果网络环境不好，会控制发送的速度。

TCP三次握手

TCP三次握手

为什么TCP是三次握手，不是两次或四次？

因为TCP是基于连接的，那怎么样才能算是连接？那就是我的包确认你收到了，还有你的包确认我收到了。完成确认收到这个动作需要两个步骤，首先是我发送包，然后是你告诉我你收到了我的包，所以一次确认收到就要两次握手，要想双方都能确认收到，简单做法就是像TCP那样三次握手，分别是：

1. 客户端发送SYN，告诉服务端我发送包给你了，自身进入SYN-SENT状态。
2. 服务端收到SYN，给客户端发送SYN-ACK，告诉客户端你的包我收到了，这是我的包，请查收，然后进入SYN-RCVD状态。
3. 客户端收到SYNC-ACK，给服务端发送ACK，告诉服务端我收到你的包了，开始通信吧。自身进入ESTABLISHED状态。
4. 服务端收到客户端的ACK，自身进入ESTABLISHED状态。

除了确认连接之外，三次握手的另一个重要目的就是确认序号（seq），因为网络是有可能断开的，断开之后，我想要恢复连接，那么就要双方确认我从X开始发，你从Y开始发，而三次握手就能完成序号的确认。

TCP四次挥手

TCP四次挥手

为什么TCP是四次回收，不是三次或五次？

TCP挥手的目的，是要双方确认对方都不再发送数据了。既然也是双方确认，为什么不能像三次握手一样，也只发送三次呢？因为服务端关闭之前，可能还有一些其他事情要做，因为双方之前通信过，不能像建立连接的时候一样，可以什么都不用做，SYN-ACK一起发，所以这里，服务端再发送ACK之后，还需要再发送一个FIN-ACK，用来做最后的了断。

然后我们再来梳理一下四次挥手的流程：

1. 客户端发送FIN，告诉服务端我准备断开了，然后自身进入FIN-WAIT1状态。
2. 服务端收到客户端发送的FIN，发送ACK给客户端，告诉客户端我收到你的FIN了，然后自身进入CLOSED-WAIT状态，准备做最后的了断。
3. 客户端收到服务端的ACK，确认服务端已经知道自己准备断开了，进入FIN-WAIT2状态。
4. 服务端处理完自己的事情之后，给客户端发送FIN-ACK，告诉客户端我这边已经处理完了，我也准备断开了。
5. 客户端收到FIN-ACK，返回ACK给服务端，自身进入TIME-WAIT状态，等待2MSL之后主动断开，进入CLOSED状态。MSL是Maximum Segment Lifetime，报文最大生存时间，这是任何报文在网络上存在的最长时间，超过这个时间的报文将被丢弃。
6. 服务端收到客户端的ACK之后，确认双方都已经了结了，进入CLOSED状态。

TCP状态机

TCP状态机

这个图中，加黑加粗的部分，是上面说到的主要流程，其中阿拉伯数字的序号，是连接过程中的顺序，而大写中文数字的序号，是连接断开过程中的顺序。加粗的实现是客户端A的状态变迁，加粗的虚线是服务器B的状态变迁。

TCP的高级特性

确认收到机制

TCP为了保证消息的顺序性，会给每个包分配一个id。建立连接的时候，双方会规定一个起始id，发送方会按照ID一个个发送，而接收方也会应答某个之前的ID，表示确认收到。这种模式被称为累计确认和累计应答（cumulative acknowledgment）。

所以，发送方的数据会分为四个部分，ID从小到大分别是：

1. 发送已确认
2. 发送未确认
3. 未发送可发送
4. 未发送不可发送

其中，为了做好流量控制，不过多发送包而导致流量超标，接收端会报给发送端一个窗口大小，叫做Advertised Window，超过这个窗口大小的流量，接收端会收不过来。

所以，发送端会保持一个这样的数据结构：

发送端确认收到模型

• LastByteAcked：服务端确认的最后一个ID
• LastByteSent：发送端最后一个发送ID
• LastByteAcked + AdvertisedWindow：发送端应该发送的最后一个ID

而服务端要保持的数据结构就会简单一些：

服务端确认收到模型

1. 接收已确认
2. 等待接收未确认
3. 不能接收

而AdvertisedWindow的大小，就是等待接收未确认的大小，也就是第二部分的长度。

而第一部分加第二部分的长度，就是接收端的MacRcvBuffer。

重传机制

TCP是一个可靠的通信协议，因为他在网络包超时的时候会进行重传。下面介绍两种重传机制：

1. 自适应重传

   发送端根据每一个包的RTT（Round-Trip Time, 往返时间）和波动范围，通过加权平均求得一个超时时间，每当过了超时时间还没收到ACK的时候，就会进行重传。

   每当遇到一次超时的时候，下次的超时时间就会加倍。

   而超过两次超时的时候，代表网络环境过差，不宜进行反复重发。

2. 快速重传

   接收方收到一个序号大于下一个所期望的报文段时，就检测到了这个中间出现了数据丢失，于是发送三个冗余的ACK，当发送端收到这三个ACK的时候，代表这个ACK ID的下一个包出现了丢失，于是不等超时，马上进行重传。

   举个例子，发送端发送了6 7 8 9，服务端收到了6 8 9，于是检测到7丢失了，于是发送了三个6的ACK，发送端收到之后，就知道7丢失了，于是不等7的超时时间，马上重传7。

流量控制机制

流量控制的目的，是因为接收端有自己的缓存（MaxRcvBuffer），为了避免发送端发送过猛，发送了过多自己接收不过来的数据，所以就有了流量控制机制。这个流量控制机制，是针对发送方的，这个机制的名称，叫做滑动窗口协议。

滑动窗口协议

我们拿上面确认收到模型来介绍。所谓滑动窗口，就是一段长度为Advertised Window的窗口，他的起始位置是最早那个发送了但是没收到ack的id，终止位置是最后一个可以发送但是没发送的id。每当窗口最左边的数据收到的时候，滑动窗口向右移一格，当窗口到达最右端的时候，窗口会越来越小（因为左端一直向右移，右端不动），直到所有的数据都收到ack，窗口size为0，数据发送完毕。

发送的过程中不可避免的会出现丢包，就拿上图来说，当4出现丢包的时候，滑动窗口不会移动，直到4收到了才动，因为这个时候，即使发送了13，受限于服务端的MaxRcvBuffer，服务端也不一定收的到，同时也避免了多余的数据包的发送。这就是滑动窗口协议用来控制流量的原理。

拥塞控制机制

同滑动窗口（rwnd）一样，TCP在建立连接的时候也会维护一个拥塞窗口（cwnd）。而拥塞窗口的目的，就是为了避免包丢失和超时重传。拥塞窗口通过慢启动的方式来增长拥塞窗口的大小。

一开始拥塞窗口很小，但是增长极快，是采用指数级增长的方式，一旦这个包没有超时，那么cwnd = cwnd *2，直到增长超过一定数值的时候（这个数值叫sshthresh，65535个字节），就采用线性增长的方式，即cwnd = cwnd + 1 / cwnd。而一旦出现超时，就将cwnd置为1，重新开始增长拥塞窗口。这种反馈控制算法我们成为线增积减（AIMD，additive-increase/multiplicative-decrease），即线性增加，积式减小。

上面这种算法有点极端，因为一旦出现包丢失，cwnd就会置为1，等于一夜回到解放前。

之前我们介绍了一种快速重传算法。就是接收方认为中间某个ID丢失的时候，会连续发送三个ID-1的ACK，不必等待超时重传。这种情况下，TCP会认为这个超时不严重，因为只丢了一小部分，大部分没丢，所以cwnd减半，然后sshthresh = cwnd，当三个包返回的时候，cwnd = sshthresh + 3，还是在比较高的值。两种算法的cwnd增长图如下：

拥塞控制算法

仔细想想，其实这两种算法都是有问题的，因为他们都会逐步把TCP的带宽占满，占满之后就很容易出现超时，那么发送速度最少都会减半。

为了这个问题，后面就有了TCP BBR拥塞控制算法。他会找到一个平衡点，逐步将TCP的带宽占满，但是不会占满中间设备的缓存，这样就能很好的达到高带宽和低延时的平衡。如下图所示：

TCP BBR算法

应用层协议

应用层协议，我们最熟悉的就是HTTP协议了。下面就来介绍一下HTTP协议的进化史以及他后面可能出现的替代品。下图就是HTTP协议的发展史

HTTP进化史

HTTP1.1 VS HTTP1.0

HTTP1.1是目前使用最广的HTTP协议版本，它和1.0版本的区别主要体现在：

• 长连接

最早大规模应用的HTTP协议版本是HTTP 1.0，1.0版本有一个问题，在于每请求一个资源，就要重新建立一条TCP连接，因为TCP连接建立和销毁都是一个比较耗时的过程，所以HTTP1.1为了解决这个问题，就默认使用了keep-alive（注意是默认使用，1.0也是有keep-alive的，只是设置起来比较麻烦），这样多个资源就能共享一条TCP连接，避免了TCP建连所造成的延时。

• 缓存优化

1.1相对于1.0支持更多的缓存策略。在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

• 分段请求

HTTP1.0中的存在一些浪费带宽的现象，即没请求一个资源，都要将一个资源完完整整的返回，而1.1则支持分段请求，即请求资源的某一段数据，就是我们看到的206返回码。

HTTP2.0 VS HTTP1.1

二进制方式传输

HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。

多路复用

多路复用

在HTTP1.1中采用的是Pipeline模式，比如我们要请求一个界面的三个文件，那么会串行发三个请求，并且第二个请求要等第一个请求回来之后才会发送。

但是如果是HTTP2.0，那么这三个请求会在一个连接里打散成数据帧发过来。如下：

image

服务端推送

服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。具体如下：

• 普通的客户端请求过程：

img

• 服务端推送的过程：

img

头部压缩

假定一个页面有100个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1kb的消息头（这同样也并不少见，因为Cookie和引用等东西的存在）, 则至少需要多消耗100kb来获取这些消息头。HTTP2.0通过HPACK头部压缩算法，维护一个字典，差量更新HTTP头部，大大降低因头部传输产生的流量。

HPACK的详细介绍，参考：HPACK 完全解析

QUIC协议

​ QUIC协议，全称quick udp internet connection，是google开发的一套基于UDP的应用层协议；Google Chrome于2012年开始开发QUIC协议并且于Chromium 版本 29 (2013年8月20日释出) 发布 ；2018 年 10 月，互联网工程任务组 HTTP 及 QUIC 工作小组正式将基于 QUIC 协议的 HTTP (英语：HTTP over QUIC) 重命名为 HTTP/3 以为确立下一代规范做准备。

它具备以下特点：

自定义连接机制

QUIC自定义连接.png

HTTP是基于TCP协议的，TCP建立连接，首先要进行3次握手，加上现在一般都是采用HTTPS链接，那么又要进行4次握手，然后才是真正的开始传输HTTP数据，那么中间就要经过4个RTT。

QUIC是基于UDP的，本身是没有连接这个概念的，加上QUIC自身的安全校验方式，是可以在请求数据的过程中完成校验，也就是说，他的安全校验和数据请求可以在1个RTT里面完成，而RTT越少，网络的延时就越短，所以在建联这一块，QUIC相比于HTTP在建连上花费的时间要少得多。

QUIC协议自身的安全校验方式存在缺陷，所以一般在实践上都是QUIC+TLS1.3，TLS1.3是首次建立连接的时候1个RTT，之后就是0RTT，相比于HTTP，延时还是要更短。

自定义重传机制

image

TCP采用的是自适应重传算法，即计算每个包的RTT时间（往返时间），如果中间发生了数据包的重传，那么就会如上图左边所示——如果是resp1 - req2就太小，如果是resp2 - req1就太大，进而导致计算出来的RTT时间不准确，从而影响到后续重传策略的准确性。

QUIC的解决方法是在每个包上加索引和偏移量，索引表示这个包是发送方第几个发送的包，偏移量表示这个包是从哪一段的数据。每个包的索引不同，偏移量可能相同，相同的时候表示这两个包请求的内容是一样的，这样就在计算RTT时间的时候更加准确。

无阻塞多路复用

HTTP协议不可避免的一个问题就是队头阻塞的问题（HOLB，Head of Line Blocking），在Http1.1里面，是前一个资源会阻塞后一个资源，在Http2.0里面，是前一个TCP包会阻塞后面的TCP包，虽然相比于Http1.1更加高级（因为TCP包即使阻塞了，也不会影响后面TCP包的接收，只是滑动窗口不会动而已），还没有从根本上解决队头阻塞问题。

这点QUIC是怎么处理的呢？见下图：

QUIC无阻塞多路复用.png

Http2.0中，因为中间有一个包没收到，即使stream3和stream4的包都到了，受限于TCP机制，这里是不会通知上层的。而QUIC基于UDP协议，更加灵活，后面的包收到了是可以通知到上层的，这样就从根本上解决了队头阻塞的问题。

自定义流量控制

image

TCP的流量控制是基于滑动窗口协议。TCP连接的发送方维护一个滑动窗口，窗口的起始位置，是发送方发送了但是还没收到ack的最小index，这样的坏处是，即使中间的包收到了，滑动窗口也不会滑动，而是等待最开始那个包收到ack之后，才会发下一个包的请求。

QUIC相较于TCP，他不同的地方就是窗口的起始位置是已接收ack的最大值，因为他认为，如果我收到后面包的ack了，那么前面的包一定是发送回来的状态，没必要等了，而之前没收到的包待会自己做重发就行了，这样能节省传输数据的时间。

后话

• 腾讯在2018年5月使用了QUIC来改造QQ黄钻业务，经过对比，发现QUIC相比于Http2.0在稳定性和延时上都有较好的表现。
• QUIC协议虽然看上去有很多优点，但是受限于运营商的限制，运营商会误以为网络攻击，所以UDP包相比于TCP包更容易出现丢包，从而导致QUIC协议到目前为止还没有大规模应用。

HTTPS协议

1. 加密分对称加密和非对称加密。对称加密效率高，但是解决不了密钥传输的问题；非对称加密可以解决这个问题，但是效率不高。

2. 非对称加密需要通过证书和全为机构来验证公钥的合法性。

3. HTTPS是总和了对称加密和非对称加密算法的HTTP协议。既保证传输安全，也保证传输效率。

   因为HTTPS是在建立连接的时候使用非对称加密，然后双方生成随机数，根据随机数生成对称密钥，后续传输的时候使用新生成的对称密钥进行传输。如下图所示：
   HTTPS握手流程

流程如下：

• 客户端发送Client Hello，并且明文传输TLS版本、加密套件候选列表、压缩算法候选列表等信息，另外，还会发送一个随机数
• 服务端收到Client Hello之后，返回Server Hello，并且告诉客户端，服务器选择使员工的协议版本、加密套件和压缩算法，并且也返回一个随机数
• 然后服务端会给一个服务端的证书，返回Server Hello Done
• 客户端首先会从自己的CA仓库中，去校验这个证书，如果不成功，则向上追溯CA，直到CA是一个授信的CA
• 证书校验完毕后，客户端计算产生随机数字Pre-master，发送Client Key Exchange，用证书中的公钥加密，发给服务器，服务器可以通过私钥解密出来
• 有了对称密钥，客户端就说Change Cipher Spec，以后就采用写上的密钥和加密算法进行通信了
• 然后客户端发送一个Encrypted Handshake Message，将已经商定好的参数，采用写上密钥进行加密，发给服务端用于数据与握手验证
• 同样，服务端也可以发送Change Cipher Spec和Encrypted Handshake Message进行握手验证
• 双方我收验证结束之后，就可以通过对称密钥进行加密传输了

其他常用协议

流媒体协议

流媒体视频本质上是一张张图片，如果将图片原封不动的传输，占用的流量太大，所以就需要压缩视频文件大小。那么图片是怎么背压缩的呢？这里会有三种帧：

• I帧，也成关键帧。这里是完整的图片，只需要本帧数据，就可以完成解码。
• P帧，前向预测编码帧，表示这一帧和之前的一个关键帧（或P帧），解码时需要之前缓存的画面，叠加上和本帧定义的差别，生成最终画面。
• B帧，双向预测内插编码帧。与P帧不一样的是，B帧需要前后缓存的数据与本帧数据叠加，来取的最终的画面。

可以看出，I帧最完整，B帧压缩率最高，而压缩后的序列，应该是在IBBP的间隔出现的。这就是通过时序进行编码。

image

P2P协议

P2P协议有两种。

• 传统的P2P协议，依赖于tracker服务器，元数据都是集中在tracker服务器里面的，用户通过请求tracker服务器，获取下载地址，然后再开始下载，一旦tracker服务器关闭了，那这个torrent文件就不能下载了。
• 另一种是DHT协议，即分布式服务器的方式，元数据信息分散在DHT网络的各个节点中，通过哈希算法，找到这个文件元数据的目标节点，目标节点不止一个，然后从目标节点拿到元数据信息，开始下载。

HTTPDNS

HTTPDNS是本地DNS的一种优化方案，客户端在本地写死HTTPSDNS的地址，通过HTTP请求的方式，向HTTPDNS服务器获取最优的目标域名地址，用更简单有效的方式来解决本地DNS解析速度慢、更新不及时的问题。

VPN协议

• VPN将一个机构的多个数据中心以隧道的方式连接起来，让机构感觉在一个数据中心里面。
• IPSec是隧道协议，他是完全基于软件的，外层ip头先到达vpn接入点，vpn接入点通过ipsec头到达数据出口，出口再通过内层IP包到达指定的内层终点。

image

• 在VPN过隧道的过程中，可能会经过多个路由器，经过这些路由器的方法有两种，一种是IP转发协议，一种是ATM标签转发协议。

  • IP转发协议，是只在经过隧道内层路由器的时候，使用IP的方式进行转发，IP协议在设计的时候就是不可靠的，所以有可能每次都要重新寻址，效率较低。

    image

  • ATM（标签转发模式）是基于连接的，连接建立之后，之后的通讯都会走这条连接，效率较高。

    image

• MPLS-VPN综合了IP转发模式和ATM的标签转发模式的优势，性能较好，但是需要从运营商购买。

参考链接：

《趣谈网络协议》

地址解析协议

HTTP1.0、HTTP1.1 和 HTTP2.0 的区别