计算机网络常见知识点总结(上)

上篇主要是计算机网络基础和应用层相关的内容。

一、计算机网络基础

网络分层模型

OSI 七层模型

OSI（开放系统互联）七层模型 是国际标准化组织（ISO）提出的网络通信模型，它定义了从物理传输到应用层的各个网络功能。每一层的功能是独立的，同时也需要和相邻层协作。它包括以下七层：

1. 物理层（Physical Layer）

   • 作用：负责网络硬件的实际传输，即电信号或光信号的传输。物理层定义了电缆、网络接口卡等硬件设备的电气规范、物理地址（MAC）等。
   • 示例：以太网、光纤、无线网络。

2. 数据链路层（Data Link Layer）

   • 作用：确保数据在物理层的可靠传输，提供错误检测与校正、流量控制以及帧的分隔。它确保数据可以无误地从源设备到达目标设备。
   • 示例：Ethernet、PPP、MAC 地址。

3. 网络层（Network Layer）

   • 作用：负责数据的路由和转发，确保数据从源端到达目的端，通常涉及IP地址和路由选择。它的关键任务是根据网络拓扑进行数据包的寻址与路由。
   • 示例：IP 协议、路由器。

4. 传输层（Transport Layer）

   • 作用：负责端到端的通信，提供可靠的数据传输功能，管理数据的顺序、重发、错误检测等。它将上层的数据分段并交给网络层传输。
   • 示例：TCP、UDP。

5. 会话层（Session Layer）

   • 作用：管理会话的建立、维护和终止。它确保数据在不同应用之间传输时不会发生冲突，并能够恢复因故障中断的会话。
   • 示例：NetBIOS、RPC。

6. 表示层（Presentation Layer）

   • 作用：处理数据的编码、压缩和加密等，确保数据能被应用层正确解析。它负责数据格式的转换，如从 ASCII 到 Unicode，或解密数据。
   • 示例：SSL/TLS、JPEG。

7. 应用层（Application Layer）

   • 作用：直接面向用户应用，提供网络服务。应用层通过协议与网络进行交互，满足具体应用需求。
   • 示例：HTTP、FTP、SMTP。

TCP/IP 四层模型

TCP/IP 四层模型 是实际互联网通信中广泛采用的网络模型。它比 OSI 模型简单，适应性更强，通常用于描述互联网中的数据传输。它包括以下四层：

1. 应用层（Application Layer）

   • 作用：直接与用户交互，负责提供各种网络服务，如文件传输、网页浏览、邮件通信等。
   • 示例：HTTP、FTP、SMTP。

2. 传输层（Transport Layer）

   • 作用：提供端到端的通信，确保数据的可靠性和顺序，常见协议有 TCP 和 UDP。
   • 示例：TCP、UDP。

3. 网络层（Network Layer）

   • 作用：负责路由选择和寻址，确保数据包能够跨越不同的网络进行传输。其核心协议为 IP 协议。
   • 示例：IP、ICMP。

4. 网络接口层（Network Interface Layer）

   • 作用：处理物理和数据链路层的功能，负责实际的数据传输和网络设备之间的通信。
   • 示例：Ethernet、Wi-Fi。

为什么网络要分层？

网络分层的原因与开发中的分层设计理念相似，主要有以下几点：

1. 降低复杂性：

   • 每一层专注于自己的功能，减少了系统的复杂度，使得每个层次的功能清晰易懂。例如，物理层只关注硬件的信号传输，网络层只处理路由问题，不需要关心下层的物理实现。

2. 灵活性和可扩展性：

   • 每一层独立工作，层与层之间通过标准接口进行交互。这使得各层可以独立更新或替换。例如，我们可以在不改变网络协议栈其余部分的情况下，升级物理层技术。

3. 提高互操作性：

   • 分层允许不同厂商提供的设备和技术能够在同一网络中互操作。比如，一台设备可以使用不同厂商的硬件和协议，但它们依然能够通过标准化的网络层协议进行通信。

4. 故障定位和维护：

   • 网络分层使得故障定位更加容易。当问题发生时，网络管理员可以通过查看具体的层次来快速诊断问题所在，避免了“黑盒子”式的复杂性。

总的来说，网络分层使得网络设计更加模块化、易于管理，并且可以在复杂的网络环境中保证系统的高效性和灵活性。

常见网络协议

应用层常见的协议

1. HTTP（Hypertext Transfer Protocol，超文本传输协议）

   • 作用：用于客户端和服务器之间交换超文本（如网页、图像、视频等）。HTTP 通过请求-响应模型进行工作，浏览器与 Web 服务器之间的通信通常使用 HTTP 协议。HTTP 是无状态的，不保留会话信息。
   • 示例：Web 浏览、API 请求。

2. SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）

   • 作用：用于电子邮件的发送。SMTP 负责将邮件从发送方传输到接收方的邮件服务器上。它不涉及邮件的接收，接收邮件通常使用 POP3 或 IMAP 协议。
   • 示例：发送电子邮件。

3. POP3 / IMAP（邮件接收协议）

   • 作用：两者都用于邮件接收，但 POP3 会将邮件下载到本地并删除服务器上的副本，而 IMAP 会将邮件保留在服务器上，允许在多个设备之间同步邮件。
   • 示例：接收电子邮件、同步邮件状态。

4. FTP（File Transfer Protocol，文件传输协议）

   • 作用：用于在计算机之间传输文件。FTP 是基于 TCP 的协议，通常用于文件上传、下载、删除等操作。
   • 示例：网站文件上传、文件共享。

5. Telnet（远程登录协议）

   • 作用：用于通过命令行访问远程计算机，主要用于远程管理设备。由于数据不加密，Telnet 在安全性上存在问题，因此大多数情况下已被 SSH 替代。
   • 示例：远程登录 Linux 服务器。

6. SSH（Secure Shell Protocol，安全外壳协议）

   • 作用：提供一个安全的远程登录方式，通过加密通信防止数据泄露。它用于远程登录、文件传输等操作。
   • 示例：远程访问服务器、安全的文件传输。

7. RTP（Real-time Transport Protocol，实时传输协议）

   • 作用：用于在互联网上进行实时数据传输，特别适合音频、视频流等多媒体内容的传输。
   • 示例：视频会议、VoIP（语音通信）。

8. DNS（Domain Name System，域名系统）

   • 作用：用于将域名转换为 IP 地址，实现域名和 IP 地址的映射。DNS 是互联网上不可或缺的一部分。
   • 示例：解析域名，访问网站时自动转换为 IP 地址。

传输层常见的协议

1. TCP（Transmission Control Protocol，传输控制协议）

   • 作用：面向连接的协议，提供可靠的、顺序的数据传输。通过数据包重传、校验、流量控制等机制，确保数据可靠到达。
   • 示例：Web 页面加载、文件传输（FTP）、电子邮件。

2. UDP（User Datagram Protocol，用户数据协议）

   • 作用：无连接协议，不保证数据传输的可靠性。它速度较快，适用于实时性要求高的应用，如视频、音频流。
   • 示例：视频会议、在线游戏、DNS 查询。

网络层常见的协议

1. IP（Internet Protocol，网际协议）

   • 作用：负责数据包的寻址和路由。IP 协议定义了如何将数据包从源发送到目的地，它包括 IPv4 和 IPv6 两种版本。
   • 示例：IP 地址的分配和路由选择。

2. ARP（Address Resolution Protocol，地址解析协议）

   • 作用：用于将 IP 地址解析为 MAC 地址，使得数据包能够通过局域网（LAN）正确发送。
   • 示例：通过 IP 地址获取 MAC 地址以实现本地通信。

3. ICMP（Internet Control Message Protocol，互联网控制报文协议）

   • 作用：用于传输控制消息，通常用于错误报告和网络诊断。最常用的 ICMP 消息是 ping。
   • 示例：网络诊断工具 ping、traceroute。

4. NAT（Network Address Translation，网络地址转换）

   • 作用：用于在局域网和公网之间进行地址转换。NAT 使得多个私有地址共享一个公共 IP 地址，提高了网络安全性。
   • 示例：家庭或公司网络中，多个设备通过一个公网 IP 上网。

5. OSPF（Open Shortest Path First，开放最短路径优先）

   • 作用：一种动态路由协议，使用链路状态算法，根据网络拓扑和带宽选择最佳路径。
   • 示例：大型企业内部网络中的路由协议。

6. RIP（Routing Information Protocol，路由信息协议）

   • 作用：一种基于距离向量的路由协议，通过跳数选择最短路径。相比 OSPF，RIP 更简单但不适应大规模网络。
   • 示例：小型网络中的路由选择。

7. BGP（Border Gateway Protocol，边界网关协议）

   • 作用：用于在不同自治系统（AS）之间交换路由信息，是互联网中最主要的外部路由协议。
   • 示例：不同运营商之间的路由选择和数据传输。

二、HTTP

从输入 URL 到页面展示到底发生了什么？

当我们在浏览器中输入一个 URL 并按下回车时，整个过程涉及多个网络协议和通信步骤，直到网页显示出来。以下是详细的步骤：

1. 输入 URL 和域名解析

• 步骤：在浏览器的地址栏中输入网址（如 http://www.example.com）并按下回车。
• 涉及协议：DNS（域名系统）协议。
• 说明：浏览器首先需要将域名 www.example.com 转换成计算机可以识别的 IP 地址。此时，浏览器会向 DNS 服务器发起查询请求，DNS 服务器返回相应的 IP 地址（例如 192.168.1.1）。

2. 建立 TCP 连接

• 步骤：浏览器通过 TCP/IP 协议与目标服务器建立连接。
• 涉及协议：TCP（传输控制协议）。
• 说明：浏览器根据 DNS 返回的 IP 地址与目标服务器建立 TCP 连接。连接是通过三次握手过程完成的：
  • 客户端（浏览器）发送一个 SYN 包，表示请求连接。
  • 服务器响应一个 SYN-ACK 包，表示同意建立连接。
  • 客户端再次发送一个 ACK 包，确认建立连接。

3. 发送 HTTP 请求

• 步骤：浏览器向服务器发送一个 HTTP 请求，询问获取网页的内容。
• 涉及协议：HTTP（超文本传输协议）。
• 说明：浏览器通过已经建立的 TCP 连接，发送一个 HTTP 请求报文，内容通常包括：
  • 请求方法（如 GET 或 POST）
  • 请求的 URL 路径（如 /index.html）
  • HTTP 版本（如 HTTP/1.1）
  • 请求头部信息（如浏览器类型、接受的内容类型等）

4. 服务器处理请求并返回响应

• 步骤：服务器处理浏览器的请求，并返回一个 HTTP 响应报文。
• 涉及协议：HTTP。
• 说明：服务器接收到请求后，处理请求（例如读取网页文件或数据库查询等），并生成一个 HTTP 响应。响应报文的内容包括：
  • HTTP 状态码（如 200 表示成功）
  • 响应头部信息（如内容类型 text/html，内容长度等）
  • 响应体（网页的 HTML 内容）

5. 浏览器解析 HTML 内容

• 步骤：浏览器收到 HTTP 响应报文后，解析 HTML 内容并渲染网页。
• 涉及协议：无（浏览器内部处理）。
• 说明：浏览器根据响应报文中的 HTML 内容，开始渲染网页结构，同时处理嵌入的 CSS、JavaScript、图片等资源。如果 HTML 中有外部资源（如 CSS、JS 文件、图片等），浏览器会继续发起请求。

6. 请求并加载其他资源

• 步骤：浏览器加载网页的其他资源（如 CSS、JS、图片等）。
• 涉及协议：HTTP。
• 说明：浏览器在解析 HTML 文件时，会发现需要加载其他资源（例如 style.css、app.js、logo.png 等），于是它会再次发起 HTTP 请求来获取这些资源。这个过程可能会有多个请求，直到所有资源都加载完毕。

7. 关闭连接

• 步骤：所有资源加载完毕后，浏览器可以关闭 TCP 连接。
• 涉及协议：TCP。
• 说明：浏览器在不再需要与服务器通信时，主动关闭 TCP 连接，或者等待服务器关闭请求。在现代浏览器中，为了提高性能，HTTP/1.1 和 HTTP/2 协议常常使用持久连接，以减少重复连接的开销。

总结

整个过程涉及的协议有：

• DNS：用于域名解析。
• TCP：用于建立和管理连接。
• HTTP：用于请求和响应网页内容。
• 其他协议：如 SSL/TLS（加密传输），或其他特定的传输协议。

通过这一系列的步骤，最终用户能够看到一个完整的网页展示。

常见 HTTP 状态码

HTTP 状态码是用于指示 HTTP 请求的处理结果，通常分为五个类别，每个类别代表不同类型的响应。以下是常见的 HTTP 状态码及其含义：

1. 1xx（信息性状态码）

表示请求已接收，继续处理。

• 100 Continue：客户端应继续发送请求。
• 101 Switching Protocols：服务器接受客户端的协议切换请求。

2. 2xx（成功状态码）

表示请求已成功处理。

• 200 OK：请求成功，服务器返回请求的资源。
• 201 Created：请求成功并且服务器创建了新的资源。
• 202 Accepted：请求已接受，但尚未处理完成。
• 204 No Content：请求成功，但没有返回任何内容。

3. 3xx（重定向状态码）

表示请求需要进一步的操作才能完成。

• 301 Moved Permanently：请求的资源已被永久移除到新位置，后续请求应使用新 URL。
• 302 Found：请求的资源临时移动，客户端应继续使用原 URL。
• 304 Not Modified：请求的资源未修改，客户端可以使用缓存的副本。

4. 4xx（客户端错误状态码）

表示请求有语法错误或请求无法完成。

• 400 Bad Request：请求无效，服务器无法理解。
• 401 Unauthorized：请求未经授权，用户需要认证。
• 403 Forbidden：服务器拒绝请求，用户没有足够的权限。
• 404 Not Found：请求的资源未找到。
• 405 Method Not Allowed：请求方法被禁止，服务器不允许使用指定的方法。
• 408 Request Timeout：请求超时，服务器未能在规定的时间内接收到完整的请求。

5. 5xx（服务器错误状态码）

表示服务器处理请求时发生了错误。

• 500 Internal Server Error：服务器内部错误，无法完成请求。
• 502 Bad Gateway：服务器作为网关或代理时收到无效响应。
• 503 Service Unavailable：服务器当前无法处理请求，通常是由于过载或维护。
• 504 Gateway Timeout：作为网关或代理的服务器未能及时从上游服务器获取响应。

这些状态码可以帮助开发者和用户了解请求的结果，并根据不同的状态码采取不同的行动。

关于 HTTP 状态码更详细的总结，可以看我写的这篇文章：HTTP 常见状态码总结（应用层）。

HTTP 请求头字段常见类型

HTTP 请求头字段包含了客户端请求中传递的多种信息，以下是一些常见的请求头字段及其说明：

请求头字段名	说明	示例
Accept	能够接受的响应内容类型（Content-Types）。	Accept: text/plain
Accept-Charset	能够接受的字符集。	Accept-Charset: utf-8
Accept-Datetime	能够接受的按时间表示的版本。	Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
Accept-Encoding	能够接受的编码方式列表。参考 HTTP 压缩。	Accept-Encoding: gzip, deflate
Accept-Language	能够接受的回应内容的自然语言列表。	Accept-Language: en-US
Authorization	用于 HTTP 认证的认证信息。	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	用来指定在请求/响应链中的缓存机制必须遵守的指令。	Cache-Control: no-cache
Connection	请求中希望使用的连接类型。	Connection: keep-alive
Content-Length	请求体的长度（以八位字节表示）。	Content-Length: 348
Content-MD5	请求体内容的二进制 MD5 散列值，以 Base64 编码表示。	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Type	请求体的多媒体类型（用于 POST 和 PUT 请求）。	Content-Type: application/x-www-form-urlencoded
Cookie	之前由服务器通过 Set-Cookie 发送的 Cookie 信息。	Cookie: $Version=1; Skin=new;
Date	发送请求的日期和时间（按照 RFC 7231 定义的格式）。	Date: Tue, 15 Nov 1994 08:12:31 GMT
Expect	客户端要求服务器做出特定的行为。	Expect: 100-continue
From	发起请求的用户的邮件地址。	From: user@example.com
Host	服务器的域名以及服务器监听的端口号。	Host: en.wikipedia.org
If-Match	仅当客户端提供的实体与服务器上的实体相匹配时，才进行请求的操作。	If-Match: "737060cd8c284d8af7ad3082f209582d"
If-Modified-Since	允许服务器在指定日期以来未修改的情况下返回 304 Not Modified 状态码。	If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match	允许服务器在请求的资源的 ETag 未发生变化时返回 304 Not Modified 状态码。	If-None-Match: "737060cd8c284d8af7ad3082f209582d"
If-Range	如果实体未修改，则返回缺少的部分；否则，返回整个实体。	If-Range: "737060cd8c284d8af7ad3082f209582d"
If-Unmodified-Since	仅当实体自特定时间以来未修改时，才发送响应。	If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Max-Forwards	限制请求经过代理和网关转发的次数。	Max-Forwards: 10
Origin	发起跨来源资源共享的请求。	Origin: http://www.example-social-network.com
Pragma	服务器实现特定的字段，可能在请求/响应链中产生多种效果。	Pragma: no-cache
Proxy-Authorization	用于代理认证的认证信息。	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	仅请求实体的部分内容，字节偏移量从 0 开始。	Range: bytes=500-999
Referer	表示当前请求页面的前一个页面，通常由上一个页面中的链接指向当前页面。	Referer: http://en.wikipedia.org/wiki/Main_Page
TE	客户端预期接受的传输编码方式。	TE: trailers, deflate
Upgrade	请求服务器升级到另一个协议。	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent	浏览器的身份标识字符串。	User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0
Via	代理服务器的转发信息。	Via: 1.0 fred, 1.1 example.com (Apache/1.1)
Warning	一般性警告，提示在响应体中可能存在错误。	Warning: 199 Miscellaneous warning

这些请求头字段在客户端与服务器通信时传递了重要信息，可以帮助服务器处理请求，进行认证、缓存控制等操作。

HTTP 和 HTTPS 的区别

1. 端口号

• HTTP：默认端口号是 80。
• HTTPS：默认端口号是 443。

2. URL 前缀

• HTTP：URL 前缀是 http://。
• HTTPS：URL 前缀是 https://。

3. 安全性和资源消耗

• HTTP：运行在 TCP 之上，数据传输是明文的，没有加密，客户端和服务器不能验证对方的身份，容易受到中间人攻击。
• HTTPS：基于 SSL/TLS 加密协议，数据在传输过程中是加密的，提供了身份验证、数据完整性和加密保护。HTTPS 使用对称加密和非对称加密技术，非对称加密用于密钥交换，数据使用对称加密进行传输。虽然安全性高，但加密和解密过程需要更多的计算资源，因此 HTTPS 会比 HTTP 消耗更多的服务器资源。

4. SEO（搜索引擎优化）

• HTTP：搜索引擎对 HTTP 的网站的优先级较低。
• HTTPS：由于其更高的安全性和隐私保护，搜索引擎如 Google 更青睐 HTTPS 网站，使用 HTTPS 的网站在搜索结果中可能会获得更高的排名。

总结：

HTTPS 相较于 HTTP 提供了更强的数据安全保障，尤其是在传输敏感信息时（如登录凭证、支付信息等），但其更高的安全性也带来了更高的计算开销。

HTTP/1.0 和 HTTP/1.1 的区别

1. 连接方式

• HTTP/1.0：使用短连接，即每次请求和响应都会建立新的 TCP 连接，处理完请求后会关闭连接。
• HTTP/1.1：支持长连接，即同一连接可以发送多个请求和响应，直到客户端或服务器主动关闭连接。这样可以减少连接建立和关闭的开销，提升性能。

2. 状态响应码

• HTTP/1.0：状态码较为简单，主要用于指示请求是否成功。
• HTTP/1.1：增加了许多新的状态码，例如：
  • 100 (Continue)：用于大文件请求时的预热请求。
  • 206 (Partial Content)：支持范围请求，允许下载文件的部分内容。
  • 409 (Conflict)：请求与当前资源的冲突。
  • 410 (Gone)：资源已被永久删除且没有转发地址。

3. 缓存机制

• HTTP/1.0：缓存机制较为简单，主要通过 If-Modified-Since 和 Expires 等头字段来判断资源是否更新。
• HTTP/1.1：引入了更多的缓存控制策略，如：
  • Entity tag（ETag）：标识资源的唯一性。
  • If-Unmodified-Since、If-Match、If-None-Match 等头字段，用于更加精确地控制缓存行为。

4. 带宽利用

• HTTP/1.0：存在浪费带宽的现象，如果客户端只需要资源的一部分，服务器也会返回整个资源，且不支持断点续传。
• HTTP/1.1：引入了 Range 头字段，支持部分内容请求，返回状态码 206 (Partial Content)，允许客户端请求资源的特定部分，避免浪费带宽。

5. Host 头字段

• HTTP/1.0：不支持 Host 头字段，无法在同一 IP 地址上托管多个域名。
• HTTP/1.1：引入了 Host 头字段，允许在同一 IP 地址上托管多个域名，支持虚拟主机功能。

总结：

HTTP/1.1 在性能、缓存控制、带宽利用等方面进行了显著改进，特别是在长连接、范围请求和虚拟主机支持上提供了更好的功能，使得它在现代 Web 中被广泛采用。

HTTP/1.1 和 HTTP/2.0 的区别

1. 多路复用（Multiplexing）

• HTTP/1.1：每个请求和响应都需要独立的连接，虽然支持长连接，但在同一连接上只能处理一个请求和响应。为了提高并发性能，浏览器通常会使用多个 TCP 连接（6-8 个连接限制），这可能导致资源的重复请求和高延迟。
• HTTP/2.0：在同一连接上可以同时处理多个请求和响应，使用多路复用技术。这避免了 HTTP/1.1 中多个 TCP 连接的问题，显著减少了网络延迟，并提高了并发性能。

2. 二进制帧（Binary Frames）

• HTTP/1.1：数据通过文本格式的报文进行传输，每个请求和响应都由可读的文本组成。这种方式在处理复杂的内容时，效率较低，传输量大。
• HTTP/2.0：数据通过二进制帧进行传输。二进制格式相比文本格式更加紧凑和高效，减少了传输的数据量和带宽消耗。二进制帧也更加易于解析和处理，提升了性能。

3. 头部压缩（Header Compression）

• HTTP/1.1：只支持请求体（Body）的压缩，不支持头部的压缩。因此，对于重复的头部信息，可能会带来不必要的带宽开销。
• HTTP/2.0：使用 HPACK 算法对请求和响应头进行压缩。通过对重复的头部字段进行压缩，HTTP/2.0 减少了网络开销，提高了传输效率。

4. 服务器推送（Server Push）

• HTTP/1.1：客户端需要发送多个请求来获取网页上的所有资源（如图片、CSS、JS 文件等）。每个资源请求都需要独立发起。
• HTTP/2.0：支持服务器推送功能。当客户端请求一个资源时，服务器可以主动推送其他相关资源。这样，客户端无需再次请求这些资源，从而减少了请求次数和延迟。

总结：

HTTP/2.0 相比 HTTP/1.1 引入了多路复用、二进制帧、头部压缩和服务器推送等新特性，极大地提升了性能和网络效率。特别是在减少网络延迟、减少带宽占用和提升并发性能方面，HTTP/2.0 显示出显著的优势。

HTTP/2.0 和 HTTP/3.0 的区别

1. 传输协议

• HTTP/2.0：基于传统的 TCP 协议来传输数据。虽然支持多路复用，但由于 TCP 在处理丢包时存在队头阻塞问题，性能可能受到影响。
• HTTP/3.0：使用全新的 QUIC 协议（Quick UDP Internet Connections），基于 UDP 协议改进而来，具有更低的连接和传输延迟。QUIC 不仅支持加密功能，还能有效避免传统 TCP 协议中的一些性能瓶颈。

2. 连接建立

• HTTP/2.0：连接建立依赖于经典的 TCP 三次握手 过程，以及在 HTTPS 下额外的 TLS 握手，通常需要 3 个往返时间（RTT）才能建立连接。
• HTTP/3.0：QUIC 协议的引入使得连接建立更加高效。QUIC 使用 TLS 1.3，支持 0-RTT 或 1-RTT 握手，从而极大地减少了连接建立的时间，提高了响应速度。

3. 头部压缩

• HTTP/2.0：使用 HPACK 算法进行头部压缩，能有效减少重复头部的带宽开销。
• HTTP/3.0：采用更高效的 QPACK 算法进行头部压缩，相比 HPACK，在处理 HTTP/3 的多路复用时，能够更好地避免潜在的性能瓶颈。

4. 队头阻塞（HOL Blocking）

• HTTP/2.0：多个请求共享同一个 TCP 连接，但如果一个请求丢包，所有后续请求都会被阻塞，造成延迟。
• HTTP/3.0：由于使用了 QUIC 协议，HTTP/3.0 能在多个独立的数据流之间进行多路复用，即便某个数据流发生丢包，也不会阻塞其他数据流，从而避免了队头阻塞问题。

5. 连接迁移

• HTTP/2.0：连接是基于 TCP 四元组（源 IP，源端口，目标 IP，目标端口）的，一旦连接的任意部分发生变化（如切换网络），现有连接就会中断。
• HTTP/3.0：由于 QUIC 使用 连接 ID 来标识连接，支持 连接迁移。即使用户切换网络（例如从 Wi-Fi 切换到移动数据），连接 ID 不变，连接可以持续保持，无需重新建立。

6. 错误恢复

• HTTP/2.0：依赖于 TCP 的错误恢复机制，如果发生丢包或延迟，可能需要较长时间来进行恢复。
• HTTP/3.0：QUIC 协议通过内置的流量控制和拥塞控制机制，能够更快速地进行错误恢复，减少丢包或延迟带来的性能损失。

7. 安全性

• HTTP/2.0：虽然支持 TLS 进行加密，但 TLS 是在 TCP 层之上进行的，TCP 本身的协议头并不加密，仍然可能受到攻击。
• HTTP/3.0：QUIC 协议直接集成了 TLS，加密覆盖了整个数据包（包括头部和数据体），增强了通信安全性。

总结：

• HTTP/2.0 改进了传统的 HTTP/1.x，使用了 TCP、多路复用、头部压缩等优化，但仍受限于 TCP 协议的队头阻塞和连接建立延迟等问题。
• HTTP/3.0 引入了 QUIC 协议，彻底改变了底层传输机制，具有更低的延迟、更强的安全性和更好的性能，尤其在移动网络和不稳定网络环境下表现尤为突出。

如何保存用户状态

由于 HTTP 是无状态的协议，意味着每次请求都是独立的，服务器并不知道不同请求之间的关联。因此，需要一种机制来存储和追踪用户状态，通常通过 Session 机制来实现。

1. Session 机制

Session 是一种用于保存用户状态的机制。其工作原理如下：

• 用户在第一次访问服务器时，服务器会为该用户生成一个唯一的 Session ID。
• 服务器将这个 Session ID 与用户的相关数据（如购物车内容、登录状态等）绑定，并将其保存在服务器的内存或数据库中。
• 每次用户发送请求时，客户端（通常是浏览器）都会将 Session ID 作为标识，发送给服务器。服务器通过这个 ID 查找到该用户的状态。

2. Session 存储位置

• 内存：可以将 Session 数据直接保存在服务器的内存中（如使用 Java 中的 HttpSession）。这种方式适用于数据量较小的场景，且不要求数据持久化。
• 数据库：对于需要持久化存储 Session 数据的场景，可以将 Session 信息存储在数据库中（如 MySQL、PostgreSQL 等）。
• 内存数据库：为了提升性能，很多场景会使用内存数据库（如 Redis）来存储 Session 数据。Redis 支持高效的读写和过期策略，非常适合 Session 存储。

3. Session 跟踪方式

为了实现 Session 跟踪，最常用的方式是通过 Cookie 发送 Session ID：

• 当服务器生成一个 Session ID 后，会将其通过 Set-Cookie 发送到客户端。客户端会将该 ID 存储在本地的 Cookie 中。
• 随后的每次请求中，浏览器会自动将该 Cookie 中的 Session ID 附加在请求中，服务器根据该 ID 查找并维护用户的状态。

4. Cookie 被禁用怎么办?

如果用户禁用了浏览器的 Cookie，传统的 Session ID 跟踪方式 会失效。此时可以采用以下方式：

• URL 重写：将 Session ID 直接附加在 URL 中。在用户请求 URL 时，Session ID 会随着 URL 一同传递到服务器。比如，URL 可以变成 http://example.com/product?id=123&sessionid=xyz，服务器可以根据 sessionid 参数来识别用户的状态。

  但这种方法有安全隐患，因为 Session ID 可能暴露在 URL 中，容易被泄露或窃取。

总结：

• HTTP 协议本身是无状态的，但通过 Session 机制，可以在服务端保存用户状态。
• 服务器通过生成和维护 Session ID 来追踪用户，常见的存储方式包括内存、数据库和 Redis 等。
• 客户端通常通过 Cookie 来保存 Session ID，但当 Cookie 被禁用时，可以通过 URL 重写 来传递 Session ID。

URI 和 URL 的区别

1. URI（统一资源标识符）

• 定义：URI 是一种用于标识资源的字符串，可以唯一标识某个资源。URI 不一定提供该资源的具体定位方式，它只需要唯一标识资源。

• 作用：URI 类似于身份证号，能够唯一标识一个资源，不关心如何定位这个资源。

  示例：

  • isbn:978-3-16-148410-0（一个书籍的 ISBN 号码作为 URI）
  • mailto:someone@example.com（一个邮箱地址作为 URI）

2. URL（统一资源定位符）

• 定义：URL 是一种特定的 URI，它不仅唯一标识资源，还提供了如何定位该资源的信息，包括协议、主机、路径等。

• 作用：URL 更像家庭住址，提供了访问该资源的具体方式。它不仅能标识资源，还能告诉我们如何找到该资源并访问它。

  示例：

  • https://www.example.com/index.html（指向一个网页资源的 URL，提供了协议、主机和资源路径）
  • ftp://ftp.example.com/file.txt（指向 FTP 服务器上的一个文件的 URL）

3. 关系：

• URL 是 URI 的一种：所有的 URL 都是 URI，因为它们唯一标识了一个资源并提供了定位信息。
• URI 包含更广泛的范畴：URI 既可以是 URL，也可以是 URN（统一资源名称）。URN 用于标识资源，但不提供定位信息。例如 urn:isbn:0451450523 是一个 URN，它标识了一本书，但没有提供如何访问这本书的路径。

总结：

• URI 只是一个通用的标识符，可以标识任何资源。
• URL 是一种特殊类型的 URI，它不仅标识资源，还提供了如何定位该资源的信息。

Cookie 和 Session 有什么区别？

准确点来说，这个问题属于认证授权的范畴，你可以在 认证授权基础概念详解 这篇文章中找到详细的答案。

GET 和 POST 的区别

1. 语义上的区别：

• GET：用于从服务器获取资源或查询信息。它通常是安全的，不会对服务器上的数据产生副作用，也不会改变服务器的状态。
• POST：用于向服务器提交数据，创建或修改资源。POST 请求通常会导致数据的改变，可能会影响服务器上的资源状态。

2. 幂等性：

• GET：GET 请求是幂等的，即多次重复执行相同的 GET 请求不会改变服务器上的资源状态。
• POST：POST 请求不是幂等的，每次执行 POST 请求可能会产生不同的结果，比如多次提交相同的表单可能会导致多个记录被创建。

3. 参数传递方式：

• GET：GET 请求的参数通过 URL 传递，在 URL 后面以查询字符串的形式附加（例如：https://example.com/page?name=John&age=30）。
• POST：POST 请求的参数通过请求体传递。参数可以有多种编码格式，例如 application/x-www-form-urlencoded、multipart/form-data、application/json 等。

4. 请求长度限制：

• GET：由于 URL 有长度限制，GET 请求的参数数量和长度受到浏览器和服务器的限制，通常限制在 2048 字符以内（这因浏览器和服务器配置不同而有所差异）。
• POST：POST 请求的数据大小没有明确限制，理论上可以提交较大的数据（例如上传文件）。实际上，服务器会根据配置限制 POST 请求的最大数据量。

5. 缓存：

• GET：GET 请求通常是缓存的，因为它是幂等的，不会改变资源的状态。浏览器、代理等中间节点可能会缓存 GET 请求的响应，以提高性能和响应速度。
• POST：POST 请求不适合缓存，因为它可能会对服务器上的资源进行修改，每次执行都需要获得最新的响应。

6. 安全性：

• GET：GET 请求的参数暴露在 URL 中，容易被浏览器历史记录、日志文件或其他中间人捕获，因此不适合传递敏感信息。即使是使用 HTTPS 加密传输，GET 请求的 URL 仍然可能被记录下来。
• POST：POST 请求的参数放在请求体中，相较于 GET 更不容易被外部观察到，因此在一定程度上比 GET 更安全。但它仍然不意味着绝对安全，需要通过 HTTPS 进行加密传输。

7. 典型使用场景：

• GET：用于获取数据或查询信息，例如：
  • 查询某个网页或 API 返回的数据。
  • 获取某个资源的内容，如图片、文本、JSON 等。
• POST：用于提交数据，创建或修改资源，例如：
  • 提交表单、上传文件、登录操作等。

总结：

• GET 用于获取数据，具有幂等性，参数通过 URL 传递，适用于不改变服务器资源的操作。
• POST 用于提交数据，可能改变服务器资源的状态，参数通过请求体传递，适用于需要提交表单、上传文件、登录等操作。

两者的选择通常基于操作的语义，决定是否会改变资源的状态。如果是获取数据，使用 GET；如果是提交或修改数据，使用 POST。

三、WebSocket

什么是 WebSocket?

WebSocket 是一种基于 TCP 连接的全双工通信协议，允许客户端和服务器在单个连接上进行持续的双向数据传输。与传统的 HTTP 请求-响应模型不同，WebSocket 建立连接后，客户端和服务器可以实时地相互发送数据，而无需每次都重新建立连接。

WebSocket 协议于 2008 年首次提出，2011 年成为国际标准。它几乎被所有主流的浏览器和现代开发框架所支持，也不仅限于浏览器应用程序，许多编程语言和服务器端平台也提供了对 WebSocket 的支持。

WebSocket 的特点：

• 全双工通信：WebSocket 允许客户端和服务器同时发送和接收数据，实现了双向通信。
• 持久连接：WebSocket 连接建立后是持久的，客户端和服务器之间不需要不断建立和关闭连接，减少了连接建立的延迟和资源消耗。
• 低延迟：相比于 HTTP 请求，WebSocket 几乎没有请求-响应延迟，可以进行实时通信。
• 节省带宽：WebSocket 连接保持持久，不需要频繁的 HTTP 请求头，节省了带宽。

WebSocket 的工作流程：

1. 握手阶段：

   • 客户端通过 HTTP 请求发起 WebSocket 握手，服务器响应一个 WebSocket 协议的确认消息（HTTP 协议的升级请求）。
   • 握手成功后，连接转为 WebSocket 协议，通信双方可以通过这个持久连接进行双向数据传输。

2. 数据传输阶段：

   • 一旦握手成功，WebSocket 连接保持打开状态，双方可以随时向对方发送数据。数据传输采用帧的方式，WebSocket 支持文本帧、二进制帧等。

3. 关闭连接：

   • 当任意一方希望关闭连接时，可以发送关闭帧，另一方接收到关闭帧后，也会返回关闭帧，完成 WebSocket 连接的关闭。

WebSocket 的应用场景：

• 实时消息推送：WebSocket 非常适合用在需要实时推送数据的应用场景，例如在线聊天、股票行情推送等。
• 视频弹幕：在视频播放中，WebSocket 可以实现实时弹幕显示，使得用户之间的互动更加流畅。
• 实时游戏对战：WebSocket 可用于实时多人在线游戏的互动数据传输，确保数据的实时性和低延迟。
• 多用户协同编辑：例如 Google Docs 中的多人同时编辑功能，WebSocket 可以确保用户的修改实时同步给其他用户。
• 社交聊天：社交媒体应用中的实时聊天功能，可以利用 WebSocket 进行双向通信，确保消息即时送达。

WebSocket 作为一种非常高效的通信协议，广泛应用于各种实时性要求较高的应用中。

WebSocket 和 HTTP 的区别

WebSocket 和 HTTP 都是基于 TCP 协议的应用层协议，但它们在通信模式、性能和用途上有显著的区别。以下是两者的主要区别：

1. 通信方式

• WebSocket：支持双向通信，客户端和服务器可以在同一连接上同时发送和接收数据。WebSocket 连接建立后，通信是持久的，双方可以在不重新建立连接的情况下实时交换数据。
• HTTP：采用单向通信模型，客户端发起请求，服务器返回响应。每次客户端发送请求时，都会建立一个新的连接，通信结束后连接关闭。

2. 连接类型

• WebSocket：连接是持久的，一旦建立连接，双方可以持续传输数据，直到手动关闭连接。
• HTTP：连接是短暂的，每次请求都需要重新建立连接（虽然 HTTP/1.1 引入了持久连接，但它仍然是基于请求-响应的模型）。

3. 协议前缀

• WebSocket：使用 ws:// 或 wss://（加密连接）作为协议前缀，类似于 HTTP 和 HTTPS 的关系。
• HTTP：使用 http:// 或 https:// 作为协议前缀。

4. 数据格式与开销

• WebSocket：协议数据包头部较小，通信数据格式轻量，因此 WebSocket 在进行大量数据交换时比 HTTP 更加高效，尤其是对于需要实时交互的应用场景。
• HTTP：每次请求都需要携带完整的请求头和响应头，数据包相对较大，带来更高的网络开销。HTTP/2 通过二进制帧传输数据并支持头部压缩，减少了部分开销。

5. 扩展性

• WebSocket：支持协议扩展，允许在 WebSocket 协议的基础上添加自定义的功能，如数据压缩、加密等。
• HTTP：虽然 HTTP 协议本身没有直接支持扩展，但通过 HTTP 头部可以使用一些扩展特性，如自定义头部字段和协议版本标识。

6. 使用场景

• WebSocket：特别适合实时应用，如实时聊天、游戏对战、股票行情、视频流等，能够提供低延迟、高效的数据交换。
• HTTP：适用于传统的请求-响应场景，如网页浏览、API 调用等，通常用于不需要实时互动的应用。

7. 连接建立

• WebSocket：需要通过 HTTP 协议进行一次握手（Upgrade 请求），成功后切换到 WebSocket 协议，并保持连接。
• HTTP：每次请求都会建立新的连接，且通信结束后立即关闭连接。

总结

• WebSocket：适用于需要实时、双向通信的场景，支持持久连接，减少了频繁连接的开销。
• HTTP：适用于传统的请求-响应场景，每次请求都需要建立新的连接，且主要用于单向数据传输。

WebSocket 和 HTTP 各有其优劣，选择哪种协议通常取决于应用的需求，尤其是是否需要高效的实时通信。

WebSocket 的工作过程

WebSocket 的工作过程可以简洁地分为以下几个步骤：

1. 建立连接：客户端发起 WebSocket 握手请求

• 客户端通过 HTTP 协议向服务器发起一个请求，并在请求头中添加 Upgrade: websocket 和 Sec-WebSocket-Key 等字段，表示请求切换到 WebSocket 协议。
• 示例请求头：

  GET /chat HTTP/1.1
  Host: example.com
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Key: x3JJHMbDL1EzLkh9K1hZ6nE9iL6bmDa5M1mlc0i2+g
  Sec-WebSocket-Version: 13

• 这里的 Sec-WebSocket-Key 是客户端生成的一个随机值，用来确保握手过程的安全性。

2. 服务器响应：协议升级

• 服务器收到客户端的请求后，如果支持 WebSocket 协议，并且处理请求通过了验证，它将会返回一个 101 状态码（Switching Protocols），表示协议升级成功。
• 响应头会包含 Connection: Upgrade 和 Sec-WebSocket-Accept 等字段，Sec-WebSocket-Accept 是通过特定算法计算出的值，用来确认协议的安全性。
• 示例响应头：

  HTTP/1.1 101 Switching Protocols
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Accept: 4r92zP9OXGJbD2lpmk6tD0x1A0mTkfk9VgnQGrAGcZ8=

3. 数据传输：双向通信

• 一旦握手完成，客户端和服务器之间就建立了一个持久的 WebSocket 连接，双方可以随时发送数据。
• 数据通过 WebSocket 帧（frames）进行传输，消息通常会被切分成多个帧发送。每个 WebSocket 帧包含控制信息（如数据的类型）和数据本身。
• 发送端将消息切割成多个帧，通过 TCP 连接传输给接收端，接收端收到后会将帧重新组装成完整的消息。
• 这种方式比 HTTP 的每次请求和响应更加高效，适合实时应用。

4. 关闭连接：断开连接

• 当客户端或服务器希望关闭连接时，可以主动发送一个关闭帧（Close Frame）。该帧告知另一方希望终止连接。
• 另一方接收到关闭帧后，也会响应一个关闭帧，表示确认断开连接。
• 此时，WebSocket 连接关闭，双方会通过 TCP 协议断开连接。

5. 心跳机制（可选）

• 为了保持 WebSocket 连接的稳定性，客户端和服务器可能会使用心跳机制定期发送ping帧和pong帧，检查连接是否活跃。
• 如果在一定时间内没有收到对方的响应帧，连接可以被认为已经丢失或中断。

总结

WebSocket 协议的工作过程包括通过 HTTP 协议升级连接、建立双向通信、实时传输数据以及关闭连接。它通过帧传输和心跳机制来确保连接的高效性和稳定性，适合于需要实时交互的应用场景。

SSE 与 WebSocket 的区别

1. 协议基础

• SSE (Server-Sent Events)：基于 HTTP 协议，无需额外的协议或服务器支持即可工作。它通过在一个持续的 HTTP 连接上向客户端推送数据来实现。
• WebSocket：基于 TCP 协议，需要专门的 WebSocket 协议和支持的服务器来建立持久的双向连接。

2. 通信方式

• SSE：单向通信，只允许服务端向客户端推送消息，客户端无法直接发送消息给服务端。
• WebSocket：全双工通信，客户端和服务端都可以随时发送和接收消息。

3. 开发复杂度

• SSE：实现简单，客户端只需要打开一个 HTTP 连接，服务器通过流数据发送信息。开发成本低，适合需要单向通信的应用场景。
• WebSocket：实现复杂，需要处理协议解析、连接建立与维护、消息传递等。开发门槛较高，但适合需要双向实时通信的场景。

4. 连接和断线重连

• SSE：默认支持断线重连，浏览器会自动处理重连，确保连接在掉线后能恢复。
• WebSocket：不自动支持重连，需要在应用层自行实现重连机制。

5. 数据格式

• SSE：仅支持文本消息，二进制数据需要经过编码后传输。
• WebSocket：支持文本和二进制数据的双向传输，能够更高效地处理媒体、文件等大容量数据。

6. 适用场景

• SSE：适用于服务端推送、单向数据流的场景，如股票行情、实时通知、监控系统等。因为其基于 HTTP，兼容性更好，且不需要太复杂的后端支持。
• WebSocket：适用于需要双向通信的实时交互场景，如即时聊天、多人游戏、实时协作编辑等。

选择建议

• 选择 SSE：当你的应用场景是单向通信（如推送消息、实时更新等），并且你不需要客户端向服务端频繁发送数据时，SSE 更加合适。它实现简单、支持自动重连，开发成本低，适合轻量级的实时更新。
• 选择 WebSocket：如果你的应用需要双向通信，并且客户端和服务端需要频繁地交换数据（如在线聊天、实时协作、多玩家游戏等），WebSocket 提供了更强大的功能和更高效的双向通信机制。虽然它的开发门槛较高，但能提供更丰富的交互和更低的延迟。

总结

• SSE：适合单向消息推送，简单、低成本、自动重连。
• WebSocket：适合双向实时通信，功能强大但开发更复杂。

四、PING

PING 命令的作用

PING 命令是一种用于测试网络中主机之间连通性和网络延迟的诊断工具。它基于 ICMP 协议，通过发送 Echo 请求报文并等待 Echo 响应报文来检查网络连接的状态。以下是 PING 命令的一些主要作用和常见用途：

1. 测试网络连通性

PING 最基本的作用是检查目标主机是否可以通过网络到达。如果目标主机能正常响应 PING 请求，说明两者之间的网络是通的。

2. 测量网络延迟

通过计算发送 ICMP Echo 请求报文到接收到响应报文的时间，PING 命令可以帮助衡量网络的延迟（即往返时间 RTT）。较低的 RTT 值表示网络连接比较快，而较高的 RTT 值可能表示网络拥塞或其他问题。

3. 检查网络丢包

PING 还能够显示数据包丢失的情况。如果发送的请求包没有返回响应，PING 会报告丢包情况，从而可以判断网络是否稳定或存在丢包现象。

4. 确定网络故障的原因

在排除网络问题时，PING 命令常用于定位问题，确定网络是否中断、目标主机是否在线，或是路径上是否有阻塞。

5. 检查目标主机或路由器的健康状况

网络管理员通常会使用 PING 命令来检查网络设备（如路由器、交换机等）是否正常工作，或检测设备的响应时间是否过长。

PING 命令的输出分析

以下是一个 PING 命令的输出示例：

❯ ping -c 4 www.baidu.com

PING www.a.shifen.com (14.119.104.189): 56 data bytes
64 bytes from 14.119.104.189: icmp_seq=0 ttl=54 time=27.867 ms
64 bytes from 14.119.104.189: icmp_seq=1 ttl=54 time=28.732 ms
64 bytes from 14.119.104.189: icmp_seq=2 ttl=54 time=27.571 ms
64 bytes from 14.119.104.189: icmp_seq=3 ttl=54 time=27.581 ms

--- www.a.shifen.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 27.571/27.938/28.732/0.474 ms

输出结果包括以下内容：

1. ICMP Echo Request 信息：

   • icmp_seq：序列号，表示这是第几个请求报文。
   • ttl：Time to Live，表示数据包可以经过的最大路由跳数。TTL 值可以帮助确定数据包在网络中通过的路由数量。
   • time：表示往返时间（RTT，Round-Trip Time），即从发送请求到接收到响应所用的时间，单位是毫秒。

2. 目标主机的信息：

   • PING www.a.shifen.com：显示目标主机的域名或 IP 地址。

3. 统计信息：

   • 4 packets transmitted, 4 packets received：表示发送和接收到的数据包数量，通常用于检查丢包情况。
   • 0.0% packet loss：丢包率，0% 表示没有丢包，表示网络是可靠的。
   • round-trip min/avg/max/stddev：显示往返时间的最小值、平均值、最大值和标准差，帮助衡量网络性能。

总结

PING 命令是一个非常实用的网络诊断工具，能够帮助网络管理员和用户快速检查网络的连通性、延迟情况以及是否存在丢包。通过分析 PING 的结果，可以更好地理解网络状况，并做出相应的优化或故障排除。

PING 命令的工作原理

PING 命令利用 ICMP（Internet Control Message Protocol，互联网控制报文协议） 来测试网络连通性。它主要通过发送和接收 ICMP 报文来判断目标主机是否在线以及网络延迟。下面是 PING 命令的详细工作过程：

1. 发送 ICMP Echo Request 报文

当执行 PING 命令时，源主机会向目标主机发送一个 ICMP Echo Request 报文。这是一种查询报文，类型为 8。此报文通常会携带一些信息，如标识符、序列号、时间戳等，用于后续的往返时间（RTT）计算。

• 类型 8：表示 Echo Request，要求目标主机返回响应。
• 标识符：通常用来标识请求和响应的匹配，帮助源主机区分多个并发的请求。
• 序列号：表示请求报文的顺序号，确保目标主机能够区分多个请求。

2. 接收 ICMP Echo Reply 报文

如果目标主机在线且能够正常响应，它将返回一个 ICMP Echo Reply 报文。此报文的类型为 0，与 Echo Request 报文一一对应。目标主机在回应时，会将原始的标识符、序列号和时间戳等信息返回给源主机，确保双方能够正确匹配请求和响应。

• 类型 0：表示 Echo Reply，响应源主机的请求。
• 往返时间（RTT）：源主机会计算从发送 Echo Request 到接收到 Echo Reply 所经历的时间，通常以毫秒为单位表示延迟。

3. 计算网络延迟和丢包情况

源主机根据收到的 Echo Reply 报文计算往返时间（RTT），即从发送请求到接收响应的时间。这个时间值反映了网络延迟。如果丢失了部分请求（即没有收到 Echo Reply），则表明网络出现了丢包。

4. 报文格式和响应信息

每次收到响应后，PING 命令会显示 ICMP Echo Reply 中的相关信息，如目标主机的 IP 地址、往返时间（RTT）、TTL（Time to Live）等。

• TTL：表示数据包能够经过的最大跳数，每经过一个路由器或网关，TTL 值会减 1。如果 TTL 值为 0，数据包会被丢弃。
• RTT：网络请求的往返时间，通常是从发送请求到收到响应所花费的时间。

如果目标主机没有回应请求（例如主机关闭、网络不可达或中间设备丢弃 ICMP 报文），PING 将报告请求超时或丢包情况。

5. ICMP 的差错报文类型

除了 Echo Request 和 Echo Reply，ICMP 还定义了很多差错报文类型，用于报告网络中的错误或不可达情况。例如，Destination Unreachable（目的不可达）和 Time Exceeded（超时）是常见的 ICMP 错误报文。

总结

PING 命令通过发送 ICMP Echo Request 和接收 ICMP Echo Reply 来测试主机间的连通性，并计算网络延迟。它帮助网络管理员诊断网络问题，检查目标主机是否在线、网络是否稳定，是否存在丢包或高延迟等问题。

五、DNS

DNS 的作用

DNS（Domain Name System，域名系统）是一个分布式的命名系统，它的主要作用是将 域名（如 www.example.com）转换为 IP 地址（如 192.0.2.1）。这是因为计算机网络通信依赖于 IP 地址，而人们更容易记住域名。通过 DNS，用户可以通过输入域名来访问网站，而不需要记住复杂的 IP 地址。

1. 域名到 IP 地址的映射

当用户在浏览器中输入一个网址时，DNS 的作用是将该域名解析为对应的 IP 地址，浏览器再根据 IP 地址与目标服务器建立连接。比如，访问 www.baidu.com 时，DNS 会将其转换为对应的 IP 地址（如 14.119.104.189）。

2. DNS 工作流程

• 本地缓存：当用户访问某个网站时，浏览器、操作系统和路由器等都会缓存 DNS 解析结果。如果缓存中已经存在该域名的解析结果，就直接使用缓存中的 IP 地址。
• 递归查询：如果缓存中没有对应的 DNS 记录，操作系统会向指定的 DNS 服务器发起请求。DNS 服务器会查询根域名服务器、顶级域名（TLD）服务器、权威域名服务器，最终返回正确的 IP 地址。

3. 分布式和层次化结构

DNS 采用分布式、层次化的数据库结构，以提高效率和可扩展性。它由多个层次的服务器组成：

• 根域名服务器：负责管理所有顶级域（TLD）服务器的地址信息。
• 顶级域名（TLD）服务器：管理具体的域名，如 .com、.org、.cn 等。
• 权威域名服务器：提供具体的域名和 IP 地址映射。

4. 协议与端口

• DNS 是 应用层协议，它运行在 UDP 或 TCP 之上，通常使用 端口 53 进行通信。
• 在大多数情况下，DNS 使用 UDP 协议，因为它的查询和响应通常较小，UDP 可以更快速地传输数据。但是在需要较大数据传输的情况下，DNS 也可以使用 TCP 协议，特别是在进行区域传输时。

5. 其他功能

除了最基本的域名解析，DNS 还支持以下功能：

• 负载均衡：DNS 可以将多个 IP 地址与一个域名关联，从而实现简单的负载均衡。
• 反向解析：通过 IP 地址查询对应的域名，通常用于日志分析等用途。
• 邮件交换：DNS 提供 MX（Mail Exchange）记录，用于邮件服务器的定位。

总结来说，DNS 是实现 域名和 IP 地址映射 的核心协议，它使得用户可以方便地使用域名访问网站，而无需记住复杂的 IP 地址。

DNS 服务器分类

DNS 服务器从底层到高层依次可以分为以下四种类型：

1. 根 DNS 服务器：

   • 根 DNS 服务器是 DNS 层级结构的最上层，负责提供顶级域 DNS 服务器（TLD 服务器）的 IP 地址。
   • 目前，虽然最初只有 13 个根 DNS 服务器的 IP 地址，但实际上这些 IP 地址背后有多个实际的服务器。截止到 2023 年底，根服务器的数量已超过 1700 台，以提高可靠性、性能和安全性。
   • 根服务器的作用是将请求指引到合适的 TLD 服务器。全球根服务器负责管理全局的 DNS 根域。

2. 顶级域 DNS 服务器（TLD 服务器）：

   • 顶级域是域名的后缀部分，如 .com、.org、.net、.edu，以及国家顶级域，如 .cn、.uk 等。
   • TLD 服务器的作用是提供权威 DNS 服务器的 IP 地址。比如当请求的域名为 www.example.com 时，根服务器会将请求指引到 .com 顶级域的 TLD 服务器。

3. 权威 DNS 服务器：

   • 权威 DNS 服务器存储着域名与 IP 地址的映射信息。它们为域名提供权威的解析。
   • 例如，当请求域名 www.example.com 时，TLD 服务器会指向该域名的权威 DNS 服务器，该服务器返回 www.example.com 的具体 IP 地址。

4. 本地 DNS 服务器：

   • 本地 DNS 服务器通常由互联网服务提供商（ISP）提供，作为客户端的 DNS 查询代理。
   • 当用户发出 DNS 请求时，本地 DNS 服务器会先查询自己的缓存，如果缓存中没有结果，则会将请求递交给上层的 DNS 服务器（如权威 DNS 服务器）来进行解析。

根 DNS 服务器的数量

虽然最初根 DNS 服务器只有 13 个 IP 地址，并且对应 13 台服务器，但实际上，根 DNS 服务器的部署已经远远超出这个数字。这是因为为了提高可用性、可靠性和性能，每个根 DNS 服务器的 IP 地址背后都有多个实例（通常在不同的地理位置）。通过这种方式，可以分散负载，提高响应速度。

截至 2023 年底，根 DNS 服务器的数量已经超过 1700 台，这些服务器采用任何cast 技术部署，意味着它们的多个实例共享同一个 IP 地址，通过路由协议将请求引导到离用户最近的服务器。

因此，尽管根服务器的 IP 地址最初是 13 个，但实际的根 DNS 服务器数量已经大大增加，以满足全球日益增长的网络需求。

DNS 解析的过程是什么样的？

整个过程的步骤比较多，我单独写了一篇文章详细介绍：DNS 域名系统详解（应用层） 。

DNS 劫持了解吗？如何应对？

DNS 劫持概述

DNS 劫持 是一种通过篡改 DNS 服务器的解析结果，使得用户访问的域名被错误地指向恶意或不正确的 IP 地址的攻击方式。其后果可能是：

1. 用户无法访问正常网站，如被劫持的 DNS 无法解析合法域名。
2. 用户被引导到恶意网站，可能导致用户信息泄露、账户盗用、下载恶意软件等安全风险。

DNS 劫持的工作原理

1. 篡改 DNS 服务器：攻击者通过不同的手段修改本地 DNS 缓存或 DNS 服务器的记录，改变特定域名对应的 IP 地址。
2. 重定向流量：用户请求访问某个网站时，DNS 服务器返回错误的 IP 地址，使得用户被引导到恶意网站。
3. 中间人攻击：攻击者可以通过伪造的 DNS 响应，使得流量经过攻击者的服务器，再转发给目标网站，从而获取敏感信息。

DNS 劫持的常见方式

1. 本地 DNS 缓存劫持：攻击者通过在本地计算机上篡改 DNS 缓存，改变对某些域名的解析结果。
2. 路由器劫持：攻击者入侵用户路由器，将其配置成使用恶意 DNS 服务器。当用户访问网站时，流量会被引导到攻击者控制的服务器。
3. ISP 劫持：一些互联网服务提供商（ISP）可能会通过修改用户请求的 DNS 解析结果，强制用户访问特定的广告或恶意网站。
4. 中间人攻击（MITM）：攻击者通过拦截用户与 DNS 服务器之间的通信，伪造 DNS 响应，诱导用户访问恶意网站。

如何应对 DNS 劫持

1. 使用加密的 DNS 服务：

   • DNSSEC（DNS Security Extensions）：DNSSEC 是一种防止 DNS 篡改的安全扩展，能够确保 DNS 响应的数据完整性和真实性。通过数字签名验证 DNS 数据，防止篡改和伪造。
   • DoH（DNS over HTTPS）和 DoT（DNS over TLS）：这两种技术通过加密 DNS 请求和响应，防止 DNS 查询过程中的数据被窃取或篡改。DoH 使用 HTTPS 加密 DNS 请求，DoT 则通过 TLS 加密 DNS 通信。

2. 定期清理 DNS 缓存：

   • 通过定期清理本地计算机的 DNS 缓存，减少 DNS 劫持的影响。可以在操作系统中使用 ipconfig /flushdns（Windows）或 sudo systemd-resolve --flush-caches（Linux）命令来清除 DNS 缓存。

3. 使用可信的 DNS 服务器：

   • 使用受信任的公共 DNS 服务，如 Google Public DNS（8.8.8.8、8.8.4.4）、Cloudflare DNS（1.1.1.1）等，这些 DNS 服务器提供了更高的安全性和隐私保护。

4. 更改默认 DNS 设置：

   • 改变本地网络设备（如路由器）的 DNS 设置，确保使用可信的 DNS 服务器。
   • 路由器密码应设置强密码，以防止攻击者通过暴力破解或其他方式入侵路由器。

5. 启用 HTTPS 和证书验证：

   • 网站应强制启用 HTTPS，并确保所有的 HTTP 请求都被重定向到 HTTPS。即使 DNS 劫持攻击将流量指向恶意服务器，HTTPS 可以加密通信，防止敏感信息泄露。
   • 用户访问时可以检查网站是否使用有效的 SSL/TLS 证书，从而判断连接是否安全。

6. 监控 DNS 流量和日志：

   • 使用 DNS 安全监控工具，定期查看 DNS 查询日志和流量，发现异常活动（例如，向不常用的 IP 地址发送大量 DNS 请求）可以帮助提前发现 DNS 劫持攻击。

总结

DNS 劫持是严重的网络安全威胁，攻击者通过篡改 DNS 响应，将用户引导到恶意网站或中断正常的网络服务。应对 DNS 劫持的最佳方式是使用加密的 DNS 服务（如 DNSSEC、DoH、DoT）、定期清理缓存、使用可信的 DNS 服务器、确保网站使用 HTTPS 加密通信等。