前言
关于网络的高频面试题，整理了了一下大部分网络层，传输层，应用层。所以这里只找面试可能出现的。关于答案相关的很多都来自网上整理的，还有就是谢希仁的计算机网络第七版，在最后面会给上参考资料。
关于计算机网络的体系结构
五层协议
- 应用层 ：为特定应用程序提供数据传输服务，例如 HTTP、DNS 等协议。数据单位为报文。
- 传输层 ：为进程提供通用数据传输服务。由于应用层协议很多，定义通用的传输层协议就可以支持不断增多的应用层协议。运输层包括两种协议：传输控制协议 TCP，提供面向连接、可靠的数据传输服务，数据单位为报文段；用户数据报协议 UDP，提供无连接、尽最大努力的数据传输服务，数据单位为用户数据报。TCP 主要提供完整性服务，UDP 主要提供及时性服务。
- 网络层 ：为主机提供数据传输服务。而传输层协议是为主机中的进程提供数据传输服务。网络层把传输层传递下来的报文段或者用户数据报封装成分组。
- 数据链路层 ：网络层针对的还是主机之间的数据传输服务，而主机之间可以有很多链路，链路层协议就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。
- 物理层 ：考虑的是怎样在传输媒体上传输数据比特流，而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异，使数据链路层感觉不到这些差异
OSI协议
多了表示层和会话层：
- 表示层 ：数据压缩、加密以及数据描述，这使得应用程序不必关心在各台主机中数据内部格式不同的问题。
- 会话层 ：建立及管理会话。
TCP/IP
只有四层，相当于五层协议中数据链路层和物理层合并为网络接口层。
网络层
网络层的设计思路是：“网络层只向上提供简单灵活的、无连接的、尽最大努力交付的服务。”关于网络层的知识点也很多，但是在面试中的高频知识点不多。
网络层里网际IP协议是TCP/IP体系中两个最重要的协议之一。与IP协议配套使用的还有三个协议：
- 地址解析协议ARP（Address Resolution Protocol）
- 网际控制报文协议ICMP（Internet Control Message Protocol）
- 网际组管理协议IGMP（Internet Group Management Protocol）
IP地址是如何分类的？
什么是私有/保留IP地址？
私有/保留就是在互联网上不使用，而被使用在局域网络中的地址或者做其他特殊用途。比如我们的联通运营商就是使用的10.开头的保留地址, 局域网组网，然后用户通过拨号的方式进入局域网，然后再通过访问网关访问Internet，这样做最大的好处就是节约了公网IP地址，极大的降低了成本。
有哪些私有/保留IP地址？
A类：10.0.0.0 ~ 10.255.255.255
B类：172.16.0.0 ~ 172.31.255.255
C类：192.168.0.0 ~ 192.168.255.255
ARP协议是如何解析MAC地址的，什么是ARP欺骗？
网络层的 ARP 协议完成了 IP 地址与物理地址的映射。
首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：如果有，就直接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发起一个 ARP 请求的广播包，查询此目的主机对应的 MAC 地址。此 ARP 请求数据包里包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址；源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。
ARP默认了其所在的网络是一个善良的网络，每台主机在向网络中发送应答信号时都是使用的真实身份。所以人们就发现ARP应答中的IP地址和MAC地址中的信息是可以伪造的，并不一定是自己的真实IP地址和MAC地址，由此，ARP欺骗就产生了。
什么是icmp协议，它的作用是什么？
它是TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。
运输层
从通信和信息处理两个角度看，运输层向它上面的应用层提供了通信服务。其主要的两个协议是UDP协议（用户数据报协议）和TCP协议（传输控制协议），重点在于TCP协议和可靠传输的原理。
TCP与UDP的特点和区别？
UDP的特点：
- UDP是无连接的。即发送数据之前不需要建立连接，所有也没有连接释放，减少了时延。
- UDP是尽最大努力交付的。即不保证可靠交付。
- UDP是面向报文的。
- UDP没有拥塞控制。因此网络出现的阻塞不会使源主机的发送效率降低。
- UDP支持一对一、一对多、多对一和多对多的交互通信。
- UDP的首部开销小。只有八个字节，比TCP的20个字节的首部短。
TCP的特点：
- TCP是面向连接的运输层协议。应用进程之间的通信好像在“打电话”：通话前要先拨号建立连接，通话结束后要挂机释放连接。
- 每一条TCP连接只能有两个端点。即TCP是点对点连接的。
- TCP提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复，并且按序到达。
- TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。
- TCP面向字节流。“面向字节流”的含义是虽然应用程序和TCP的交互是一次一个数据块，但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。
TCP与UDP的区别：
- UDP是无连接的，即发送数据之前不需要建立连接；TCP是面向连接的运输层协议。
- UDP使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制；TCP提供可靠的交付服务，提供全双工通信。
- UDP支持一对一，一对多，多对一和多对多的交互通信；TCP只能一对一连接。
- UDP首部开销小，只有8个字节；TCP 面向字节流，头部最低20个字节。
- TCP消耗更多的资源，传输速度慢，UDP相对较快，所以一些即时通讯软件使用UDP效果更好。
使用UDP和TCP协议的各种应用和应用层协议
| 应用 | 应用层协议 | 运输协议 |
|---|---|---|
| 名字转换 | DNS（域名系统） | UDP |
| 文件传送 | TFTP（简单文件传送协议） | UDP |
| 路由选择协议 | RIP（路由信息协议） | UDP |
| IP地址配置 | DHCP（动态主机配置协议） | UDP |
| 网络管理 | SNMP（简单网络管理协议） | UDP |
| 远程文件服务器 | NFS（网络文件系统） | UDP |
| IP电话 | 专用协议 | UDP |
| 流式多媒体通信 | 专用协议 | UDP |
| 多播 | IGMP（网际管理协议） | UDP |
| 电子邮件 | SMTP（简单邮件传送协议） | TCP |
| 远程终端接入 | TELNET（远程终端协议） | TCP |
| 万维网 | HTTP（超文本传送协议） | TCP |
| 文件传送 | FTP（文件传送协议） | TCP |
三次握手四次挥手全过程
三次握手
-
第一次握手，客户端给服务器发送一个SYN包，序号为x，等待服务器的响应。
-
第二次握手，服务器给客户端发送了有ACK/SYN标志的包，序号为y，确认号为x+1，并等待客户端响应。
-
第三次握手，客户端收到服务器的确认包后，给服务器发送了一个ACK包，序号为x+1，确认号为y+1。
三次握手完毕后，就可以正式传递数据了。
四次挥手
-
第一次挥手，客户端给服务器发送一个FIN包，此时客户端不会再向服务器发送数据，但客户端能接收服务器的数据。
-
第二次挥手，当服务器收到FIN包后，会给客户端发一个确认包，并传递剩下的数据。
-
第三次挥手，当服务器将剩余数据发送完后，就向发送方发一个FIN包。此时服务器也不会继续向客户端发送数据了。
-
第四次挥手，客户端收到服务器的FIN包后，就向服务器发送一个确认包。
服务端接收到后，完成四次挥手。服务器断开连接，客户端在等待一段时间后也断开连接。
为什么需要三次握手，四次挥手？
三次握手的目的是建立可靠的通信信道，无论是客户端，还是服务器都需要确保自己和对方的发送/接收功能都是正常的，三次握手的过程就能保证这一点。
-
第一次握手，服务器收到客户端发来的同步包后，能确定客户端的发送功能和自己的接收功能是正常的。
-
第二次握手，客户端收到服务器发来的确认包后，能确定自己的发送/接收功能，服务器的发送/接收功能是正常的。
-
第三次握手，服务器收到客户端的确认包后，能确定自己的发送/接收功能，服务器的发送/接收功能是正常的。
如果不进行挥手操作，比如客户端直接断开与服务器的连接，那么服务器不知情，还会继续向客户端发送数据，这就造成资源浪费。
为什么需要有Time_Wait状态和等待2MSL？
为了保证客户端发送的最后一个确认，能够达到服务器
这个ACK可能丢失，就会导致服务器在LAST-ACK状态,没办法正常结束,那么服务器收不到就会超时重传可以断开的消息。
那么A就能够在这个2MSL中收到这个重传的消息，并且重新计时2MSL。
而且，客户端持续2MSL时间后断开，就可以保证这个连接的所有报文都会死亡，可以看下MSL的含义，也就是2MSL之后，断开这个连接之后，肯定不会还存在这个连接的旧的报文了。
补充：MSL（最大报文段的生成时间）在RFC793中规定hi2分钟，实际应用是30秒，1分钟，2分钟等
为什么不能两次握手，或者三次挥手？
-
二次握手不行，假设客户端的一个SYN包在网络中滞留了很久，这就是个失效的报文段了，如果服务器收到这个报文段，就认为这是一个连接请求，并建立连接。这样，就会浪费服务器资源，采用三次握手就能避免这种情况。
-
三次挥手不行，如果没有最后一次挥手，即服务器在第三次挥手，即发送完FIN包后就断开连接，如果这个包丢失了，那么客户端就会一直等待，这显然是不行的。
TCP是如何保证可靠传输的？
- 超时重传，如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。
- 首部校验和，提供了差错检测功能。
- 确认与序号机制，能保证接收到数据的有序性。
- 流量控制，能控制端到端之间的数据传递速率，有效避免丢包。
- 拥塞控制，根据整个网络环境来条件传输速率，有效避免丢包。
介绍一下拥塞控制？
发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 ...
注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh（初始为16），当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。
如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。
应用层
URI和URL的区别？
URL我们说是叫统一资源定位符，URI我更愿意叫做统一资源标识符。
举个例子：
一个人，身份证是他的唯一标识，可以作为统一资源标识符，而地址是为了找到他，所以是统一资源定位符。
HTTP请求的GET与POST方式的区别?
-
GET在浏览器回退是无害的，而POST会再次提交请求
-
GET请求会被浏览器主动cache,而POST不会，除非手动设置
-
GET请求只能进行URL编码，而POST支持多种编码
-
GET请求参数会被完整保留在浏览器历史记录中，而POST中的参数不会被保留
-
GET请求在URL中传送参数是有大小限制的，不能大于2KB,而POST可以说没有
-
GET只接受ASCII字符，而POST没有限制
-
GET参数直接暴露在URL上，而POST将数据放在request body中
从输入网址到获取页面的过程?
本题摘抄自点击跳转
（1）将url转换成ip地址
我们如果想要访问百度网，肯定得先知道百度的ip地址，但是用户可记不住这么复杂的ip地址，baidu这个拼音就容易得多。但这样就必须有一种手段自动的将url转换成ip地址。在计算机中有一个DNS协议，它是用于将url转换成ip地址的，DNS是一个分布式的数据库，存储着所有有效的url对ip的映射。当我们往浏览器网址中输入url之后，浏览器首先会查看自己的缓存，即以前是否访问过该url，如果有则直接返回。如果没有，操作系统则会检查该url是否存在于本地DNS，如果有则返回，否则会查看host文件，如果有则返回，否则向本地DNS服务器发起请求，如果有则返回，否则，本地DNS服务器会请求根域名服务器获得顶级域名服务器ip，然后向顶级域名服务器请求返回得到权威域名服务器ip，再向权威域名服务器请求得到url->ip的映射返回给本地DNS服务器，本地DNS服务器将ip返回给操作系统并做缓存。
（2）建立连接
得到了ip地址之后我们就需要建立http连接了。因为http是基于tcp的，所以我们需要通过三次握手来建立连接，客户端将SYN置为1，将tcp报文发送给服务器，序列号为x，服务端收到了这个包，识别出是一个请求连接的包，如果同意连接，服务器也将SYN置为1，将ACK置为1，确认号为x+1，序列号为y，将该tcp包发送给客户端，客户端收到了这个包并识别，发现确认号为x+1，就知道了这个是回应包，于是再发送一个确认号为y+1的tcp包，表示自己确认收到了服务端的回应，请求建立成功。三次握手的作用是为了确保客户端和服务端双方都具有发送和接受数据的能力，同时可以防止脏连接的建立。
（3）发送http请求
接下来一步是发送http请求了，http请求包括请求行，请求头，请求体，但是一个http请求能够正确的到达服务器。是需要经过很多步骤的，比如必须要通过路由协议才能将这个http请求传达到服务器，路由协议的作用是找到最佳的一条路径快速的传送请求。
（4）服务端执行代码并返回http响应
因为建立tcp连接的机器可能只是一个代理服务器，所以可能需要将http请求转发到真实的web服务器中，web服务器收到了请求，会执行服务端代码，得到数据之后将会封装到一个http响应中，会传送给客户端（该响应可能会通过代理服务器也可能不需要通过代理服务器）
（5）浏览器收到http请求并进行渲染
以springmvc为例，http响应为ModelAndView，首先返回一个页面，然后再将数据渲染到页面形成我们的界面。
（6）断开连接
因为现在的http请求都是长连接的，并不会马上关闭，在一段时间没有进行交互之后，就会自动断开，时间大概为300秒左右。
常见的HTTP请求?
- GET：对服务器资源的简单请求-
- POST：用于发送包含用户提交数据的请求
- PUT：用来传输文件，但是不带有验证机制，任何人都可以上传，有安全隐患。除了REST风格API会发送这种请求，一般的网站不会使用该方法
- DELETE：发出一个删除指定文档的请求，和PUT一样，有安全隐患，除了REST API一般不会发送这种请求。
- HEAD：和 GET 方法一样，只是不返回报文主体部分，只返回报头。通常用来检验url的有效性或资源更新日期。
- OPTIONS：查询服务器对给定url支持的所有请求方法
- TRACE：查询发送出去的请求是怎样被加工修改的。
- CONNECT：要求与代理服务器通信时建立隧道。使用加密协议如SSL来进行TCP通信。
HTTP状态码有哪几类？常见的状态码有哪些？
200：请求成功状态码。
301：永久重定向。该资源已经分配了新的 URI，服务器返回301响应时，会自动将请求者转移到新URI。
302：临时重定向。表示请求的资源临时分配了新的 URI，希望用户（本次）能使用新的 URI 访问。
404：服务器找不到目标资源。
500：服务器内部出错，无法完成请求。
HTTP与HTTPS的区别？
- https协议要申请证书到ca，需要一定经济成本；
- http是明文传输，https是加密的安全传输；
- 连接的端口不一样，http是80，https是443；
- http连接很简单，没有状态；https是ssl加密的传输，身份认证的网络协议，相对http传输比较安全。
SSL四次握手过程？描述一下
TSL的三个随机数作用
其实TSL就是升级后的SSL，在上面介绍的SSL只是因为历史上习惯了SSL这个称呼，所以用的还是比较多。上面我们虽然介绍了SSL的四次握手，但是并没有详细介绍到里面涉及到的参数。这里呢主要涉及以下几个参数
三个随机数：Client random, Server random, Premaster secret
三个秘钥：公钥(public key)，私钥(private key)，对话密钥(session key)
我们的在具体的过程的使用如下：
- ClientHello：客户端生成一个随机数
random-client，传到服务器端（Say Hello) - ServerHello：服务器端生成一个随机数
random-server，和着公钥，一起回馈给客户端（I got it) - 客户端收到的东西原封不动，加上
premaster secret（通过random-client、random-server经过一定算法生成的东西），再一次送给服务器端，这次传过去的东西会使用公钥加密 - 服务器端先使用私钥解密，拿到
premaster secret，此时客户端和服务器端都拥有了三个要素：random-client、random-server和premaster secret - 此时安全通道已经建立，以后的交流都会校检上面的三个要素通过算法算出的
session key
详细一点的可以参考这一篇博文点击跳转
HTTP 1.0，1.1，2.0，3.0的变化历程？
本问题答案摘抄自（点击跳转）进行修改。。
HTTP/0.9
HTTP/0.9是第一个版本的HTTP协议，已过时。它的组成极其简单，只允许客户端发送GET这一种请求，且不支持请求头。由于没有协议头，造成了HTTP/0.9协议只支持一种内容，即纯文本。不过网页仍然支持用HTML语言格式化，同时无法插入图片。
HTTP/0.9具有典型的无状态性，每个事务独立进行处理，事务结束时就释放这个连接。由此可见，HTTP协议的无状态特点在其第一个版本0.9中已经成型。一次HTTP/0.9的传输首先要建立一个由客户端到Web服务器的TCP连接，由客户端发起一个请求，然后由Web服务器返回页面内容，然后连接会关闭。如果请求的页面不存在，也不会返回任何错误码。
HTTP/1.0
HTTP协议的第二个版本，第一个在通讯中指定版本号的HTTP协议版本，至今仍被广泛采用。相对于HTTP/0.9增加了如下主要特性：
- 请求与响应支持头域
- 响应对象以一个响应状态行开始
- 响应对象不只限于超文本
- 开始支持客户端通过POST方法向Web服务器提交数据，支持GET、HEAD、POST方法
- 支持长连接（但默认还是使用短连接），缓存机制，以及身份认证
HTTP/1.1
HTTP协议的第三个版本是HTTP/1.1，是目前使用最广泛的协议版本。HTTP/1.1是目前主流的HTTP协议版本，相对于HTTP/1.0新增了以下内容：
-
默认为长连接
HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection：keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
-
提供了范围请求功能(宽带优化)
HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。这是支持文件断点续传的基础。
-
提供了虚拟主机的功能(HOST域)
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
-
多了一些缓存处理字段
HTTP/1.1在1.0的基础上加入了一些cache的新特性，引入了实体标签，一般被称为e-tags，新增更为强大的Cache-Control头。
-
错误通知的管理
在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
HTTP/2.0
HTTP协议的第四个版本是HTTP/2.0，相对于HTTP/1.1新增了以下内容：
-
二进制分帧
HTTP 2.0 的所有帧都采用二进制编码
- 帧：客户端与服务器通过交换帧来通信，帧是基于这个新协议通信的最小单位。
- 消息：是指逻辑上的 HTTP 消息，比如请求、响应等，由一或多个帧组成。
- 流：流是连接中的一个虚拟信道，可以承载双向的消息；每个流都有一个唯一的整数标识符（1、2 … N）；
-
多路复用
多路复用允许同时通过单一的HTTP/2.0 连接发起多重的请求-响应消息。有了新的分帧机制后，HTTP/2.0不再依赖多个TCP 连接去处理更多并发的请求。每个数据流都拆分成很多互不依赖的帧，而这些帧可以交错（乱序发送），还可以分优先级。最后再在另一端根据每个帧首部的流标识符把它们重新组合起来。HTTP 2.0 连接都是持久化的，而且客户端与服务器之间也只需要一个连接（每个域名一个连接）即可。
-
头部压缩
HTTP/1.1 的首部带有大量信息，而且每次都要重复发送。HTTP/2.0 要求通讯双方各自缓存一份首部字段表，从而避免了重复传输。
-
请求优先级
浏览器可以在发现资源时立即分派请求，指定每个流的优先级，让服务器决定最优的响应次序。这样请求就不必排队了，既节省了时间，也最大限度地利用了每个连接。
-
服务端推送
服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。
HTTP/3.0
在这里需要先说一下2.0有什么缺点，我们才能知道3.0多了什么的改进：
-
底层基于TCP协议，需要TCP+TLS建立有两个握手的延迟过程
-
TCP的队头阻塞没有彻底解决。这里需要介绍一下，什么是队头阻塞：多个请求是跑在一个TCP管道中的，但是当出现了丢包时，因为TCP为了保证可靠传输，有个特别的“丢包重传”机制，丢失的包必须要等待重新传输确认，HTTP/2出现丢包时，整个 TCP 都要开始等待重传，那么就会阻塞该TCP连接中的所有请求（如下图）。而对于 HTTP/1.1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。
3.0的改进：
-
使用了基于UDP协议的QUIC协议。并有以下的好处。
-
实现了快速握手，避免了tcp和ssl重复握手的时延。加快了速度，提升首次打开页面的速度。
-
集成了TLS加密功能。在具有同样加密功能的情况下，减少了握手锁花费的时延。
-
多路复用，实现数据的单独传输，彻底解决了TCP中队头阻塞的问题。
-
实现了类似TCP的流量控制、传输可靠性的功能。虽然UDP不提供可靠性的传输，但QUIC在UDP的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性。
这里同样有几个问题，为什么我们的3.0要使用UDP可靠来替代我们的TCP链接？UDP是怎么实现可靠传输的呢？
其实呢，我们在上面也介绍到了。之所以不使用TCP协议，主要是因为TCP协议的握手和我们的TLS的握手重了，增大了我们的时延。而且使用TCP协议的话，还是解决不了我们的一个队头阻塞的问题，因为TCP它是始终要保持我们的面向可靠传输。而我们又不能直接去修改TCP协议，因为它存在的时间太长了，我们如果要去修改它的话，那么付出的代价也是极高的。
而我们也不是纯粹的使用UDP的协议，而是使用了基于UDP协议的QUIC协议。它在UDP协议上增加了许多的功能（在应用层实现），如确认机制、重传机制、窗口确认机制等，很好的解决了可靠传输，安全加密等我们原来支持的功能，并且还解决了我们的原来的队头阻塞等问题，实现既快又可靠的协议。
参考资料
计算机网络第七版-谢希仁