【计算机基础】计算机网络知识点②

二、基本概念

2.1 Socket原理

1.什么是Socket

我们经常把socket翻译为套接字，socket是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用，实现进程在网络中通信。

所有的网络协议都是基于Socket进行通信的，不管是TCP还是UDP协议，应用层的HTTP协议也不例外。这些协议都需要基于Socket实现网络通信。5种网络IO模型也都要基于Socket实现网络通信。实际上，HTTP协议是建立在TCP协议之上的应用层协议。HTTP协议负责如何包装数据，而TCP协议负责如何传输数据。

socket 是处于传输层之上封装的网络接口，是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），方便应用层、会话层等使用。socket 的本意是“插口或插槽”，顾名思义，可以将 socket 想象成一根网线，一头插在客户端，一头插在服务端，然后进行通信，故客户端与服务端在通信之前必须要创建一个 socket。

一个连接可以由它两端的套接字地址唯一确定：(客户端地址:客户端端口号，服务端地址:服务端端口号)
有了通信双方的地址信息之后，就可以进行数据传输了。那么我们现在需要一个规范，来规定通信双方的连接及数据传输过程。在Unix系统中，实现了一套套接字接口，用来描述和规范双方通信的整个过程。

• socket()：创建一个套接字描述符
• connect()：客户端通过调用connect函数来建立和服务器的连接
• bind()：告诉内核将socket()创建的套接字与某个服务端地址与端口连接起来，后续会对这个地址和端口进行监听
• listen()：告诉内核，将这个套接字当成服务器这种被动实体来看待(服务器是等待客户端连接的被动实体，而内核认为socket()创建的套接字默认是主动实体，所以才需要listen()函数，告诉内核进行主动到被动实体的转换)
• accept()：等待客户端的连接请求并返回一个新的已连接描述符

socket 其实就是一个五元组，包括：源IP, 源端口, 目的IP, 目的端口, 类型(TCP or UDP) . 这个五元组，即标识了一条可用的连接。 需要注意是是，经常有很多人把一个socket定义成四元组，也就是源IP:源端口+目的IP:目的端口，这个定义是不正确的。

比如说，如果本地出口IP是110.122.144.166，那么你的浏览器在连接某一个Web服务器，例如百度的时候，这条socket连接的四元组可能就是：[110.122.144.166:45678, tcp, 110.88.92.104:80] , 源IP为你的出口IP地址 110.122.144.166，源端口为随机端口 45678，目的IP为百度的某一个负载均衡服务器IP 110.88.92.104，端口为HTTP标准的80端口。

https://www.cnblogs.com/dolphinx/p/3460545.html

socket fd（文件描述符）是什么？

内核（kernel）利用文件描述符（file descriptor）来访问文件。文件描述符是非负整数。打开现存文件或新建文件时，内核会返回一个文件描述符。读写文件也需要使用文件描述符来指定待读写的文件。

对于每个进程，操作系统内核在u_block结构中维护文件描述符表，所有的文件描述符（fd）都在该表中建立索引。

文件描述符是操作系统为了管理文件和其他 I/O 设备而分配的一种标识符。在 UNIX-like 系统中，一切皆文件，包括磁盘上的文件、设备、网络连接等，而文件描述符就是对这些文件的引用。当程序需要读取或写入文件时，它首先需要打开文件，操作系统会为此分配一个文件描述符，之后程序就可以使用这个文件描述符来操作文件，例如读取数据、写入数据等。

文件描述符是一个非负整数，通常是程序运行时的一个序号，操作系统将它映射到相应的文件或设备上。程序可以通过文件描述符来识别并访问已经打开的文件，每个文件描述符都对应着一个已经打开的文件或设备。通常情况下，文件描述符是顺序分配的，从0开始递增，0、1、2 分别是标准输入、标准输出和标准错误。

在 UNIX-like 系统中，文件描述符的范围通常是从 0 到 ulimit -n，其中 ulimit -n 是当前用户进程的最大文件描述符数量限制。因此，操作系统所能支持的文件描述符数量取决于系统的资源限制和配置。

Socket 标记为可读或可写 是什么意思？

• 当套接字标记为"可读"时，这意味着可以从该套接字读取数据而不会被阻塞，即套接字的接收缓冲区中有数据可供读取。

• 当套接字标记为"可写"时，这意味着可以向该套接字写入数据而不会被阻塞，即套接字的发送缓冲区有足够的空间可以写入数据。

2.SOCKET连接与TCP连接

创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。

3. Socket连接与HTTP连接

由于通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。

而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数据传送给客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求，不仅可以保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。

Socket是一个针对TCP和UDP编程的接口，你可以借助它建立TCP连接等等。而TCP和UDP协议属于传输层 。
而http是个应用层的协议，它实际上也建立在TCP协议之上。

(HTTP是轿车，提供了封装或者显示数据的具体形式；Socket是发动机，提供了网络通信的能力。)

网络 I/O 模型

什么是I/O？

所谓的I/O（Input/Output）操作实际上就是输入输出的数据传输行为。程序员最关注的主要是磁盘IO和网络IO，因为这两个IO操作和应用程序的关系最直接最紧密。

• 磁盘IO：磁盘的输入输出，比如磁盘和内存之间的数据传输。
• 网络IO：不同系统间跨网络的数据传输，比如两个系统间的远程接口调用。

一个请求过程可能会发生很多次的IO操作：
1，页面请求到服务器会发生网络IO
2，服务之间远程调用会发生网络IO
3，应用程序访问数据库会发生网络IO
4，数据库查询或者写入数据会发生磁盘IO

网络IO模型

网络 I/O的定义

在套接字接口抽象下，网络 I/O 的出入口就是 Socket 的读和写，Socket 在操作系统接口中被抽象为数据流，网络 I/O 可以理解为对流的操作。

每一次网络访问，从远程主机返回的数据会先存放到操作系统内核的缓冲区中，然后内核的缓冲区复制到应用程序的地址空间，所以当发生一次网络请求发生后，将会按顺序经历“等待数据从远程主机到达缓冲区”和“将数据从缓冲区拷贝到应用程序地址空间”两个阶段，根据实现这两个阶段的不同方法，人们把网络 I/O 模型总结为两类、五种模型

网络IO 两分类五模型

Linux下主要的IO模型分为:

• Blocking IO - 同步阻塞IO
• Nonblocking IO - 同步非阻塞IO
• IO multiplexing - IO多路复用
• Signal-driven IO - 信号驱动式IO（异步阻塞）
• Asynchronous IO - 异步IO

同步：调用端会一直等待服务端响应，直到返回结果
异步：调用端发起调用之后不会立刻返回，不会等待服务端响应
阻塞：服务端返回结果之前，客户端线程会被挂起，此时线程不可被 CPU 调度，线程暂停运行
非阻塞：在服务端返回前，函数不会阻塞调用端线程，而会立刻返回

同步阻塞IO

我们先看一下传统阻塞IO。在Linux中，默认情况下所有socket都是阻塞模式的。当用户线程调用系统函数read()，内核开始准备数据（从网络接收数据），内核准备数据完成后，数据从内核拷贝到用户空间的应用程序缓冲区，数据拷贝完成后，请求才返回。从发起read请求到最终完成内核到应用程序的拷贝，整个过程都是阻塞的。为了提高性能，可以为每个连接都分配一个线程。因此，在大量连接的场景下就需要大量的线程，会造成巨大的性能损耗，这也是传统阻塞IO的最大缺陷。

同步非阻塞IO

用户线程在发起Read请求后立即返回，不用等待内核准备数据的过程。如果Read请求没读取到数据，用户线程会不断轮询发起Read请求，直到数据到达（内核准备好数据）后才停止轮询。非阻塞IO模型虽然避免了由于线程阻塞问题带来的大量线程消耗，但是频繁的重复轮询大大增加了请求次数，对CPU消耗也比较明显。这种模型在实际应用中很少使用。

多路复用IO模型

多路复用IO模型，建立在多路事件分离函数select，poll，epoll之上。

在发起read请求前，先更新select的socket监控列表，然后等待select函数返回（此过程是阻塞的，所以说多路复用IO并非完全非阻塞）。当某个socket有数据到达时，select函数返回。此时用户线程才正式发起read请求，读取并处理数据。这种模式用一个专门的监视线程去检查多个socket，如果某个socket有数据到达就交给工作线程处理。由于等待Socket数据到达过程非常耗时，所以这种方式解决了阻塞IO模型一个Socket连接就需要一个线程的问题，也不存在非阻塞IO模型忙轮询带来的CPU性能损耗的问题。

多路复用IO模型的实际应用场景很多，比如大家耳熟能详的Java NIO，Redis，Nginx以及Dubbo采用的通信框架Netty都采用了这种模型。

不管是select、poll 和 epoll，本质上都差不多。
当我们调用select、poll 和 epoll函数时，程序会阻塞。直到发生IO事件时，即某个socket有数据（通过网卡）到达时，才会返回。
在select模式下，发生IO事件时，事件中并没有标示他属于哪个socket，所以此时应用程序需要轮训所有socket，找到那些发生IO事件的socket并处理他们的数据。
epoll在select的基础上做了明显的改进。在epoll模式下，发生IO事件时，事件中标示了他属于哪个socket，所以此时应用程序可以直接从该事件中获取到对应的socket，避免了无效的轮训。

异步IO与NIO区别

NIO（Non-blocking I/O，非阻塞 I/O）和异步 I/O 是两种不同的 I/O 模型，它们有一些区别，但也有一些相似之处。

1. NIO（Non-blocking I/O）：

   • NIO 是一种 I/O 模型，它允许程序在等待数据就绪时执行其他操作，而不是阻塞等待。在 NIO 中，可以使用单个线程同时管理多个通道（Channel），当一个通道的数据准备就绪时（Selector监控），程序会收到通知并处理缓冲区（Buffer）数据，而不需要等待其他通道的数据。NIO 主要涉及的类有 Selector、Channel、Buffer 等。
   • NIO 是同步的，因为程序仍然需要显式地等待数据准备就绪，但是它是非阻塞的，因为在等待数据就绪时程序可以执行其他操作。NIO 适用于管理大量连接，如服务器端的网络编程，可以用较少的线程处理大量的并发连接。

2. 异步 I/O：

   • 异步 I/O 是一种 I/O 模型，它允许程序在发起 I/O 操作后继续执行其他操作，而不需要等待 I/O 操作完成。在异步 I/O 中，可以使用回调函数或事件处理机制来处理 I/O 操作完成的通知。异步 I/O 主要涉及的类有 CompletionHandler、Future 等。
   • 异步 I/O 是真正的非阻塞，因为程序在发起 I/O 操作后可以立即执行其他操作，而不需要等待 I/O 操作完成。异步 I/O 适用于需要高并发和高吞吐量的场景，如网络服务器和高性能计算。

主要区别在于 NIO 是一种半同步、半异步的模型，程序仍然需要显式地等待数据就绪；而异步 I/O 是一种完全异步的模型，程序在发起 I/O 操作后可以立即执行其他操作，不需要显式地等待操作完成。根据具体的需求和场景，可以选择合适的模型来实现高效的 I/O 操作。

阻塞和非阻塞、同步和异步的关系

阻塞和非阻塞 强调的是程序在等待调用结果（消息，返回值）时的状态. 阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。 对于同步调用来说，很多时候当前线程还是激活的状态，只是从逻辑上当前函数没有返回而已，即同步等待时什么都不干，白白占用着资源。

同步和异步强调的是消息通信机制 (synchronous communication/ asynchronous communication)。所谓同步，就是在发出一个"调用"时，在没有得到结果之前，该“调用”就不返回。但是一旦调用返回，就得到返回值了。换句话说，就是由“调用者”主动等待这个“调用”的结果。而异步则是相反，"调用"在发出之后，这个调用就直接返回了，所以没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在"调用"发出后，"被调用者"通过状态、通知来通知调用者，或通过回调函数处理这个调用

I/O 多路复用

I/O 多路复用的定义

I/O多路复用，I/O就是指的我们网络I/O,多路指多个TCP连接(或多个Channel)，复用指复用一个或少量线程。串起来理解就是很多个网络I/O复用一个或少量的线程来处理这些连接。

所谓 I/O 多路复用指的就是 select/epoll 这一系列的多路选择器：支持单一线程同时监听多个文件描述符（I/O 事件），进程阻塞等待，并在其中某个文件描述符可读写时收到通知。

ngnix、redis等 会有很多链接进来， epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。

为什么需要I/O 多路复用？

应对多用户的请求，基于进程或者线程模型的，其实还是有问题的。新到来一个 TCP 连接，就需要分配一个进程或者线程，那么如果要达到 C10K，意味着要一台机器维护 1 万个连接，相当于要维护 1 万个进程/线程，操作系统就算死扛也是扛不住的。

那么，我们可以使用线程池的方式来避免线程的频繁创建和销毁，所谓的线程池，就是提前创建若干个线程，这样当由新连接建立时，将这个已连接的 Socket 放入到一个队列里，然后线程池里的线程负责从队列中取出已连接 Socket 进程处理。

为每个请求分配一个进程/线程的方式不合适，那有没有可能只使用一个进程来维护多个 Socket 呢？答案是有的，那就是 I/O 多路复用技术。

select

select 是一个主动模型，实现多路复用的方式是，将已连接的 Socket 都放到一个文件描述符集合，然后调用 select函数将文件描述符从用户集合拷贝到内核里（从用户态到内核态），让内核来检查是否有网络事件产生，检查的方式很粗暴，就是通过遍历文件描述符集合的方式，当检查到有事件产生后，将此 Socket 标记为可读或可写， 接着再把整个文件描述符集合拷贝回用户态里，然后用户态还需要再通过遍历的方法找到可读或可写的Socket，然后再对其处理。

所以，对于 select 这种方式，需要进行 2 次「遍历」文件描述符集合，一次是在内核态里，一个次是在用户态里 ，而且还会发生 2 次「拷贝」文件描述符集合，先从用户空间传入内核空间，由内核修改后，再传出到用户空间中。

Select的缺点

• 监听能力有限 — 最多只能监听 1024 个文件描述符（BitsMap）；
• 内存拷贝开销大 — 需要维护一个较大的数据结构存储文件描述符，该结构需要拷贝到内核中；（每次调用 select，都需要把 fd 集合从用户态拷贝到内核态，这个开销在 fd 很多时会很大;）
• 时间复杂度 𝑂(𝑛) — 返回准备就绪的事件 (当检查到有事件产生后，将此 Socket 标记为可读或可写)个数后，需要遍历所有的文件描述符；

poll

poll 不再用 BitsMap 来存储所关注的文件描述符，取而代之用动态数组，以链表形式来组织，突破了 select 的文件描述符个数限制，当然还会受到系统文件描述符限制。

但是 poll 和 select 并没有太大的本质区别，都是使用「线性结构」存储进程关注的 Socket 集合，因此都需要遍历文件描述符集合来找到可读或可写的 Socket（两次），时间复杂度为 O(n)，而且也需要在用户态与内核态之间拷贝文件描述符集合（两次拷贝），这种方式随着并发数上来，性能的损耗会呈指数级增长。

epoll

• 文件描述符维护在系统内核中，不用再传递给系统内核，

• epoll是基于事件驱动， 是selec的增强版本，避免了“性能开销大”和“文件描述符数量少”两个缺点。

事件驱动

• 事件机制：避免线性扫描，为每个 fd，注册一个监听事件，fd 变更为就绪时，将 fd 添加到就绪链表。

• fd 数量：无限制（OS 级别的限制，单个进程能打开多少个 fd）。

epoll实例内部存储：

• 监听列表：所有要监听的文件描述符，使用红黑树；
• 就绪列表：所有就绪的文件描述符，使用链表；

epoll具体是如何解决Select 的问题？

• 第一点，epoll 在内核里使用红黑树来跟踪进程所有待检测的文件描述（维护了一个内核事件表），把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里（系统去检测有事件发生的时候触发回调），红黑树是个高效的数据结构，增删查一般时间复杂度是 O(logn)，通过对这棵黑红树进行操作，这样就不需要像 select/poll 每次操作时都传入整个 socket 集合，只需要传入一个待检测的 socket，减少了内核和用户空间大量的数据拷贝和内存分配。(水平触发和边沿触发的区别。(依赖红黑树))

• 第二点， epoll 使用事件驱动的机制（每个fd指定一个回调函数），内核里维护了一个链表来记录就绪事件，当某个 socket 有事件发生时（当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数）， 通过回调函数 内核会将其加入到这个就绪事件列表（链表）中，当用户调用 epoll_wait() 函数时，只会返回有事件发生的文件描述符的个数（有没有就绪的fd），不需要像 select/poll 那样轮询扫描整个 socket 集合，大大提高了检测的效率。

为什么要用红黑树？
当现在要在内核中长久的维护一个数据结构来存放文件描述符，并且时常会有插入，查找和删除的操作发生，这对内核的效率会产生不小的影响，因此需要一种插入，查找和删除效率都不错的数据结构来存放这些文件描述符，那么红黑树当然是不二的人选。

因此，在 Linux 的 epoll 模型中，选择了红黑树。红黑树是二叉搜索树的一种，红与黑是红黑树的实现者才关心的内容，对于我们使用者来说不用关心颜色，Java 中的 TreeMap 底层就是红黑树。

https://www.zhihu.com/question/32163005

select、poll、epoll 区别总结：

• 1、支持一个进程所能打开的最大连接数

  select：单个进程所能打开的最大连接数有FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是3232，同理64位机器上FD_SETSIZE为3264），当然我们可以对进行修改，然后重新编译内核，但是性能可能会受到影响，这需要进一步的测试。

  poll：poll本质上和select没有区别，但是它没有最大连接数的限制，原因是它是基于链表来存储的。

  epoll：虽然连接数有上限，但是很大，1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接。

• 2、FD剧增后带来的IO效率问题

  select：因为每次调用时都会对连接进行线性遍历，所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。

  poll：同上

  epoll：因为epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，使用epoll没有前面两者的线性下降的性能问题，但是所有socket都很活跃的情况下，可能会有性能问题。

• 3、 消息传递方式

  select：内核需要将消息传递到用户空间，都需要内核拷贝动作

  poll：同上

  epoll：epoll通过内核和用户空间共享一块内存来实现的。

DNS解析

https://zhuanlan.zhihu.com/p/471712872?utm_id=0

域名的构成

下图为域名的结构。其实每个域名都是有根域的，如 http://www.volcengine.com 其实应该是 www.volcengine.com.，域名末尾的点就是根域名，很多情况下根域名是可以省略掉的。

在上述例子中，com 为顶级域名，http://volcengine.com 是二级域名或主域名，http://www.volcengine.com 是子域名或分域名。

值得注意的是，顶级域名不一定只由一个域名构成，也可以由两个域名构成。虽然.com、.cn 都是顶级域名，但是.http://com.cn 也是顶级域名。

DNS种类

线上 DNS 解析主要包含：Local DNS 服务器、根域 DNS 服务器、顶级域 DNS 服务器、权威域 DNS 服务器。

Local DNS（递归DNS）

Local DNS 服务器不在客户端本地，一般为运营商提供的线上 DNS 服务器，主要作用是代理用户进行迭代解析。

递归DNS也叫local dns，其核心功能一个是缓存、一个是递归查询。

收到域名查询请求后其首先看本地缓存是否有记录，如果没有则一级一级的查询根、顶级域、二级域……直到获取到结果然后返回给用户。日常上网中运营商分配的DNS即这里所说的递归DNS。

根域名服务器（ROOT）

根服务器主要用来管理互联网的主目录，全世界IPv4根服务器只有13台（这13台IPv4根域名服务器名字分别为“A”至“M”），1个为主根服务器在美国。其余12个均为辅根服务器，其中9个在美国，欧洲2个，位于英国和瑞典，亚洲1个位于日本。根服务器中有经美国政府批准的260个左右的互联网后缀（如．com、．net、.cn等）。

顶级域名服务器

负责解析本身顶级域名下一级域名对应的权威DNS服务器地址。

权威 DNS

权威 DNS 是特定域名记录在域名注册商处所设置的 DNS 服务器，用于特定域名本身的管理。

权威DNS负责管理一个域名，在他所管理的域名里，具有权威性，通俗一点就是在这个域名里，他说了算。

解析记录的类型

DNS 解析是将域名解析为 IP 地址的过程，那域名和 IP 地址的映射关系存在哪里呢？答案是 DNS 权威服务器。用户通过在 DNS 管理平台添加域名的解析记录，管理平台将该记录同步到权威 DNS 服务器，实现域名与最终 IP 地址的绑定。

DNS 解析的过程

这是一个很经典的 DNS 解析流程图。

DNS 解析的过程可以分为本地查询(1、2）与线上查询（3-11）。

本地、线上查询流程

本地查询

本地查询可以分为 host 文件查询与本地缓存查询。

当用户在浏览器中访问域名时，会先进行本地查询，

• 若本地查询命中，则直接返回；
• 未命中，则需要访问线上的 DNS 服务器进行解析。

线上查询

线上查询主要分为递归查询和迭代查询：

• 递归查询是浏览器把任务交给 Local DNS ，然后等待 Local DNS 返回结果；
• 迭代查询是 Local DNS 分别向各级 DNS 服务器发送查询请求，直到获取 DNS 解析结果为止。

总的来说，客户端向 Local DNS 服务器进行查询，如果命中 Local DNS 服务器的缓存，直接返回 IP；没有命中，Local DNS 服务器会向各级域名服务器进行查询，直到最终解析出 IP 为止。

相关问题

Local DNS劫持

LocalDNS缓存问题

LocalDNS解析转发

高可用DNS

实例分析

bogon:~:% dig www.aplum.com

; <<>> DiG 9.10.6 <<>> www.aplum.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32783
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.aplum.com.			IN	A

;; ANSWER SECTION:
www.aplum.com.		600	IN	A	39.107.106.99

;; Query time: 12 msec
;; SERVER: 202.106.0.20#53(202.106.0.20)
;; WHEN: Wed Sep 20 12:36:27 CST 2023
;; MSG SIZE  rcvd: 47

• 当中国内地用户在浏览器输入访问 gtm-test.wenteng.site 时，本地缓存未命中，会去查询 Local DNS 服务器；
• 若 Local DNS 服务器中没有该域名的缓存记录，则会依次去查询根域 DNS 服务器、顶级域 DNS 服务器、权威 DNS 服务器；
• 根域 DNS 服务器会告知.com 顶级域对应的顶级域解析服务器地址；
• 之后顶级域服务器会告知 wenteng.site 二级域名对应的权威 DNS 服务器地址；
• 最终从权威域名服务器中查询到 gtm-test.wenteng.site 这个域名对应的记录值；
• 查询到的记录类型为 CNAME 类型，非 IP，之后会对这个结果进行又一次的 5-10 过程解析，最终返回 A 类型的 IP 76.76.21.61、76.76.21.22。

实际情况中，因为 Local DNS 服务器有缓存，每一次的查询过程不是一定都要走根域名这个过程的，不然根域 DNS 服务器的流量就太大了。

CDN

cdn系统架构

选择最近节点，最近的运营商

cdn数据一致性

比如前段文件，加上MD5摘要，如a.js,编程a.md5.js

可以用前端的一些工具脚手架 自动替换，增量发布，让CDN回源，去源站拉pull最新的数据

动态CDN加速

connection management

边缘节点做连接，边缘节点回源时与源站做长连接（几个连接池）

http1.1 几个连接池
http2.0可以建一个连接池