计算机网络八股文个人总结

1.TCP/IP模型和OSI模型的区别

在计算机网络中，TCP/IP 模型和 OSI 模型是两个重要的网络协议模型。它们帮助我们理解计算机通信的工作原理。以下是它们的主要区别，以通俗易懂的方式进行解释：

1. 模型层数

OSI 模型：有 7 层，分别是：
1. 物理层（Physical Layer）
2. 数据链路层（Data Link Layer）
3. 网络层（Network Layer）
4. 传输层（Transport Layer）
5. 会话层（Session Layer）
6. 表示层（Presentation Layer）
7. 应用层（Application Layer）
TCP/IP 模型：有 4 层，分别是：
1. 网络接口层（Network Interface Layer）
2. 网络层（Internet Layer）
3. 传输层（Transport Layer）
4. 应用层（Application Layer）

2. 层次结构

OSI 模型：层次清晰，强调每层的功能和服务。每一层都有明确的职责，通常在设计和理解网络协议时使用。
TCP/IP 模型：层次较少，层之间的界限不如 OSI 清晰。它更关注于实际的网络实现，很多协议可以跨越多个层次。

3. 发展背景

OSI 模型：由国际标准化组织（ISO）于 1984 年提出，旨在提供一个通用的网络通信框架。因为其复杂性和实现难度，实际应用较少。
TCP/IP 模型：由美国国防部开发，最初用于 ARPANET（互联网的前身）。它是基于实际的网络协议，广泛应用于现代互联网。

4. 具体功能

应用层：该层与OSI模型的应用层和表示层以及会话层类似，提供直接与用户应用程序交互的接口。它为网络上的各种应用程序提供服务，如电子邮件（SMTP）、网页浏览（HTTP）、文件传输（FTP）等。
传输层：该层对应OSI模型的传输层。它负责端到端的数据传输，提供可靠的、无连接的数据传输服务。主要的传输层协议有TCP和UDP。TCP提供可靠的数据传输，确保数据的正确性和完整性；而UDP则是无连接的，适用于不要求可靠性的传输，如实时音频和视频流。
网络层：该层对应OSI模型的网络层。主要协议是IP，它负责数据包的路由和转发，选择最佳路径将数据从源主机传输到目标主机。IP协议使用IP地址来标识主机和网络，并进行逻辑地址寻址。
网络接口层：该层对应OSI模型的数据链路层和物理层。它负责物理传输媒介的传输，例如以太网、Wi-Fi等，并提供错误检测和纠正的功能。此外，网络接口层还包含硬件地址（MAC地址）的管理。

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

1. 浏览器解析 URL

浏览器首先解析你输入的 URL。URL 通常由协议（如 HTTP 或 HTTPS）、域名（如 www.example.com）和路径（如 /page）组成。

2. DNS 解析

浏览器需要将域名转换为 IP 地址。这个过程称为 DNS（域名系统）解析。
浏览器会向 DNS 服务器发送请求，询问 www.example.com 对应的 IP 地址。DNS 服务器返回 IP 地址（例如 192.0.2.1）。

3. 与服务器建立连接

一旦获得 IP 地址，浏览器会与目标服务器建立连接。对于 HTTPS，浏览器会执行以下步骤：
- TCP 连接：通过三次握手（Three-way Handshake）建立 TCP 连接。
- SSL/TLS 握手：如果使用 HTTPS，浏览器和服务器会进行 SSL/TLS 握手，以建立安全连接。

4. 发送 HTTP 请求

建立连接后，浏览器会发送一个 HTTP 请求给服务器。请求中包含请求类型（如 GET 或 POST）、请求头（如 User-Agent、Cookie 等）以及请求的 URL。

5. 服务器处理请求

服务器接收到请求后：
- 根据请求的 URL 和其他信息，查找对应的资源（如 HTML 页面）。
- 处理请求，可能需要查询数据库或执行其他逻辑。

6. 服务器返回响应

服务器将处理结果返回给浏览器，通常是一个 HTTP 响应，包含：
- 状态码（如 200 表示成功，404 表示未找到）。
- 响应头（如内容类型、缓存策略等）。
- 响应体（如 HTML 内容、JSON 数据等）。

7. 浏览器渲染页面

浏览器接收到响应后，开始渲染页面：
- 解析 HTML 文档，构建 DOM（文档对象模型）树。
- 解析 CSS，构建 CSSOM（CSS 对象模型）树。
- 结合 DOM 和 CSSOM，生成渲染树。
- 计算布局，确定每个元素的大小和位置。
- 绘制内容到屏幕上。

8. 加载其他资源

在解析 HTML 的过程中，浏览器可能会遇到其他资源（如图片、CSS 文件、JavaScript 文件）。浏览器会并行请求这些资源，并在加载完毕后进行渲染。

9. 执行 JavaScript

如果页面中包含 JavaScript，浏览器会执行这些脚本，可能会改变页面的内容或样式，甚至发起新的网络请求。

3.HTTP请求报文和响应报文是怎样的，有哪些常见的字段？

HTTP 请求报文和响应报文

在 Web 开发中，HTTP（超文本传输协议）是客户端（通常是浏览器）与服务器之间通信的主要协议。HTTP 通信通过请求报文和响应报文进行。以下是对这两者的通俗易懂的解释，以及它们常见字段的介绍。

1. HTTP 请求报文

当你在浏览器中输入 URL 并按下 Enter 键时，浏览器会生成一个 HTTP 请求报文。这个请求报文用于告诉服务器你想要什么资源。请求报文的结构通常包括以下几个部分：

请求行：包含请求方法、请求路径和 HTTP 版本。
- 请求方法：常见的方法有：
  - GET：请求数据。
  - POST：提交数据。
  - PUT：更新数据。
  - DELETE：删除数据。
- 请求路径：例如 /index.html。
- HTTP 版本：如 HTTP/1.1。
请求头：包含一些额外的信息，常见字段有：
- Host：请求的服务器的域名。
- Accept：客户端能够处理的媒体类型。
- Accept-Encoding：客户端能够解码的内容编码。
- Authorization：用于认证的凭证信息，比如token数据。
- Content-Length：请求体的长度。
- Content-Type：请求体的媒体类型。
- Cookie：存储在客户端的cookie数据。
- If-None-Match：资源的ETag值，用于缓存控制。
- Connection：管理连接的选项，如 keep-alive。
请求体（可选）：一些请求（如 POST）可能包含请求体，用于发送数据给服务器（例如表单数据）。

示例请求报文：

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

2. HTTP 响应报文

服务器处理完请求后，会返回一个 HTTP 响应报文，告知客户端请求的结果。响应报文的结构通常包括以下几个部分：

状态行：包含 HTTP 版本、状态码和状态描述。
- HTTP 版本：如 HTTP/1.1。
- 状态码：如:
  - 200：成功。
  - 404：未找到。
  - 500：服务器内部错误。
- 状态描述：对状态码的文字描述。
响应头：包含一些元信息，常见字段有：
- Content-Type：指定响应主体的媒体类型。
- Content-Length：指定响应主体的长度（字节数）。
- Server：指定服务器的信息。
- Expires: 响应的过期时间，之后内容被认为是过时的。
- ETag: 响应体的实体标签，用于缓存和条件请求。
- Last-Modified：资源最后被修改的日期和时间。
- Location：在重定向时指定新的资源位置。
- Set-Cookie：在响应中设置Cookie。
- Access-Control-Allow-Origin: 跨源资源共享（CORS）策略，指示哪些域可以访问资源。
响应体：实际的数据内容，比如 HTML 页面、JSON 数据或图片等。

示例响应报文：

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234<!DOCTYPE html>
<html>
<head><title>Example</title></head>
<body><h1>Hello, World!</h1></body>
</html>

4.HTTP有哪些请求方式

HTTP 协议定义了多种请求方式（也称为请求方法），用于指定客户端对服务器的不同操作。以下是几种常见的 HTTP 请求方式以及它们的用途：

1. GET

功能：请求从服务器获取数据。
特点：
- 请求参数通常附加在 URL 后面（例如 ?key1=value1&key2=value2）。
- 安全且幂等（多次请求不会影响服务器状态）。
- 请求内容不应包含敏感信息，因为 URL 会被记录在浏览器历史和服务器日志中。
使用场景：获取页面、图片、数据等。

2. POST

功能：向服务器提交数据。
特点：
- 请求体中可以包含大量数据，适合发送复杂的表单数据或文件。
- 非幂等（多次请求可能会导致不同的结果），例如提交表单可能会多次创建条目。
使用场景：提交表单、上传文件、发送 JSON 数据等。

3. PUT

功能：更新服务器上的资源。
特点：
- 请求体中包含要更新的完整资源数据。
- 如果资源不存在，则会创建新的资源。
- 幂等性：多次请求会产生相同的结果（更新同样的数据不会影响结果）。
使用场景：更新用户信息、修改文件等。

4. DELETE

功能：删除服务器上的资源。
特点：
- 通常不需要请求体，只需指定要删除的资源的 URL。
- 幂等性：多次请求同样的删除操作，结果不变（资源已经被删除）。
使用场景：删除用户、删除文件等。

5. HEAD

功能：类似于 GET，但只请求响应头，不请求响应体。
特点：
- 用于获取资源的元信息，如内容类型、内容长度等。
- 常用于检查资源是否存在或获取更新信息。
使用场景：检查某个 URL 的有效性。

6. OPTIONS

功能：请求服务器支持的 HTTP 方法。
特点：
- 可用于了解服务器的功能和跨域请求的支持情况。
使用场景：在进行跨域请求时，浏览器会先发送 OPTIONS 请求以确认请求的安全性。

7. PATCH

功能：部分更新服务器上的资源。
特点：
- 请求体中只包含要更新的字段，而不是整个资源。
- 非幂等性：多次请求可能会导致不同的结果。
使用场景：更新资源的某些字段，如更新用户的部分信息。

5.GET请求和POST请求的区别

在 HTTP 协议中，GET 和 POST 是两种最常用的请求方式。它们用于向服务器发送请求，但在使用方式、目的和数据处理上有明显的区别。以下是对这两种请求的通俗易懂的解释和比较：

1. 请求目的

GET 请求：
- 主要用于获取数据。
- 请求的目标是从服务器获取资源（如网页、图片、数据等）。
POST 请求：
- 主要用于向服务器提交数据。
- 请求的目标是将数据发送到服务器进行处理（如表单提交、文件上传等）。

2. 数据传输方式

GET 请求：
- 数据通过 URL 传递，附加在请求的查询字符串中（例如 https://www.example.com/search?query=java）。
- URL 有长度限制（大约 2048 个字符），适合传递少量数据。
POST 请求：
- 数据通过请求体传递，不在 URL 中。
- 没有数据长度限制，适合传输大量数据（如文件、复杂的表单数据）。

3. 安全性

GET 请求：
- 不适合传输敏感信息（如密码），因为数据暴露在 URL 中，容易被记录在浏览器历史、服务器日志等。
POST 请求：
- 相对更安全，数据不直接显示在 URL 中，但仍需注意使用 HTTPS 以保证数据的安全性。

4. 幂等性

GET 请求：
- 是幂等的：多次请求同样的 URL 不会改变服务器的状态（例如，多次刷新页面只会获取相同的数据）。
POST 请求：
- 非幂等的：多次提交同样的数据可能会导致不同的结果（例如，重复提交表单可能创建多个记录）。

5. 缓存

GET 请求：
- 可以被缓存：浏览器和代理服务器可以缓存 GET 请求的结果，提高性能。
POST 请求：
- 通常不被缓存：提交的数据通常是独特的，不会被缓存。

总结

特点	GET 请求	POST 请求
主要用途	获取数据	提交数据
数据传输方式	URL 查询字符串	请求体
安全性	不适合敏感信息	相对安全，但仍需注意
幂等性	是幂等的	非幂等的
是否缓存	可以缓存	通常不缓存

6.HTTP中常见的状态码有哪些？

在 HTTP 协议中，状态码用于表示服务器对客户端请求的处理结果。状态码由三位数字组成，通常分为五类，每类代表不同的响应类型。以下是一些常见的 HTTP 状态码及其含义：

1. 1xx：信息性状态码

100 Continue：客户端可以继续发送请求。通常在发送大请求时使用，表示服务器已经接收到请求的初始部分，可以继续发送后续数据。
101 Switching Protocols：服务器已理解客户端的请求，并将协议切换到客户端所请求的协议。

2. 2xx：成功状态码

200 OK：请求成功，服务器已成功处理请求，返回所请求的数据。
201 Created：请求成功并创建了新的资源，通常在使用 POST 方法时返回，表示资源已创建成功。
204 No Content：请求成功，但没有返回任何内容。常用于 DELETE 请求。

3. 3xx：重定向状态码

301 Moved Permanently：请求的资源已永久移动到新位置，响应中会包含新的 URL，客户端应使用新 URL 进行后续请求。
302 Found：请求的资源临时移动，客户端应使用新 URL 进行临时请求，但未来请求仍应使用原 URL。
304 Not Modified：资源未被修改，客户端可以使用缓存的版本。常用于优化性能，减少不必要的数据传输。

4. 4xx：客户端错误状态码

400 Bad Request：请求格式错误，服务器无法理解请求。通常是客户端发送的数据不符合要求。
401 Unauthorized：请求未授权，客户端需要提供身份验证信息。常用于需要登录的资源。
403 Forbidden：服务器理解请求，但拒绝执行。即使提供了身份验证，访问仍被禁止。
404 Not Found：请求的资源不存在。常见的错误，表示服务器上找不到请求的页面或文件。

5. 5xx：服务器错误状态码

500 Internal Server Error：服务器内部发生错误，无法完成请求。表示服务器遇到了意料之外的情况。
502 Bad Gateway：作为网关或代理的服务器无法获得有效的响应。通常发生在后端服务出现问题时。
503 Service Unavailable：服务器当前无法处理请求，可能是由于过载或维护。客户端可以稍后重试。

7.什么是强缓存和协商缓存

在 Web 开发中，缓存是提高性能和用户体验的重要技术。HTTP 协议定义了两种主要的缓存机制：强缓存和协商缓存。下面我们来详细解释这两种缓存及其工作原理。

1. 强缓存

强缓存是指在客户端和服务器之间直接缓存资源，避免了去服务器请求的过程。强缓存通过 HTTP 头部中的 Expires 和 Cache-Control 来控制缓存。

工作原理：
- 当客户端请求资源时，浏览器首先检查是否有可用的强缓存。
- 如果缓存有效，浏览器直接从缓存中读取资源，而不向服务器发送请求。
- 如果缓存失效，浏览器会向服务器发送请求。
头部字段：
- Cache-Control: 现代浏览器更倾向于使用这个字段来控制缓存。
  - max-age=<seconds>: 指定资源可以被缓存的最大时间（秒）。
  - no-cache: 表示强制重新验证。
  - no-store: 禁止缓存。
- Expires: 旧版 HTTP 头部，指定缓存过期的具体日期和时间。
示例：
- 如果 Cache-Control: max-age=3600，表示该资源可以在缓存中存储 1 小时（3600 秒）。

2. 协商缓存

协商缓存是指在缓存失效后，客户端向服务器发送请求，询问资源是否可以使用缓存。协商缓存通过 HTTP 头部中的 Last-Modified 和 ETag 来实现。

工作原理：
- 当客户端请求资源时，如果强缓存已失效，浏览器会发送请求，但会附带上次请求时的缓存信息。
- 服务器根据这些信息决定是否返回新的资源。
- 如果资源未修改，服务器返回状态码 304 Not Modified，客户端可以继续使用缓存的版本。
头部字段：
- Last-Modified: 服务器上次修改资源的时间。
- If-Modified-Since: 客户端发送的请求头，表示客户端上次缓存的时间。
- ETag: 资源的唯一标识符。
- If-None-Match: 客户端发送的请求头，带有上次缓存的 ETag。
示例：
- 客户端请求资源时，发送 If-Modified-Since: Mon, 29 Mar 2021 12:00:00 GMT。
- 如果资源在此时间之后未被修改，服务器返回 304 Not Modified，客户端继续使用缓存。

8.HTTP1.0和HTTP1.1的区别

持久连接（长连接）：HTTP/1.1 默认支持持久连接，允许在一个TCP连接上发送多个HTTP请求和响应，减少了连接建立和关闭的开销。而HTTP/1.0 默认为短连接，每次请求都需要建立一个TCP连接，并通过Connection: keep-alive头来实现持久连接。
管道化：HTTP/1.1 支持管道化(不是默认开启)，允许客户端在第一个请求的响应到达之前发送多个请求，这可以减少等待时间，提高效率。但是相应只能按顺序接收否则会造成队头阻塞，HTTP/1.0不支持管道化。
缓存控制：HTTP1.0主要使用If-Modified-Since/Expires来做为缓存判断的标准，而HTTP1.1则引入了更多的缓存控制策略例如Etag / Cache-Control等更多可供选择的缓存头来控制缓存策略。
错误处理：HTTP/1.1 增加了一些新的HTTP状态码，如100 Continue，用于增强错误处理和请求的中间响应。
Host 头：1.HTTP/1.0 不支持 Host 头部，导致在同一个 IP 地址上不能托管多个网站。HTTP/1.1：强制要求 Host 头部，允许在同一个服务器上托管多个网站（虚拟主机），通过 Host 头部来区分。
带宽优化：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，而HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content）

总结

特性	HTTP/1.0	HTTP/1.1
连接管理	每个请求新建连接	持久连接，复用 TCP 连接
带宽优化	简单	增强，支持分块传输
缓存处理	基本，依赖 Expires,modifid	复杂，支持 Cache-Control,etag
管道化	不支持	支持但是不默认启动，且队头阻塞
Host 头部	不支持	强制要求，支持虚拟主机

9.HTTP2.0与HTTP1.1的区别？

1. 传输方式

HTTP/1.1：
- 使用文本格式，所有的请求和响应都是以可读的文本形式传输。
- 每个请求都需要完整的请求头，且每个请求都是独立的。
HTTP/2.0：
- 使用二进制格式，数据以二进制帧的形式传输，减少了传输的开销，并提高了解析效率。
- 将请求和响应分割成多种类型的帧（如数据帧、头帧等），使得多路复用成为可能，加入stream流信息。

2. 多路复用

HTTP/1.1：
- 使用单个连接处理请求，存在“队头阻塞”问题。即使一个请求被阻塞，其他请求也无法继续处理。
- 为了避免这个问题，通常需要建立多个连接，但这会增加资源消耗。
HTTP/2.0：
- 支持多路复用，多个请求和响应可以在同一个连接上并发传输，而不会互相阻塞。根据stream流信息在客户端进行信息拼接。保证请求端不会存在1.1的队头阻塞。请求端的队头阻塞问题解决了，但是tcp端的队头阻塞问题依然存在。这大大提高了网络的利用率和速度。

3. 头部压缩

HTTP/1.1：
- 每次请求都需要发送完整的头部，尤其在请求很多时，头部占用了很大一部分带宽。
HTTP/2.0：
- 引入了头部压缩（HPACK），通过压缩请求和响应的头部信息，减少了传输的数据量，提高了效率。

4. 服务器推送

HTTP/1.1：
- 客户端发送请求，服务器只能对请求做出响应，无法主动推送数据。
HTTP/2.0：
- 支持服务器推送，服务器可以在客户端请求资源之前，主动推送相关资源（如 CSS、JavaScript 文件），减少了请求的延迟。

5. 连接管理

HTTP/1.1：
- 每个连接都是独立的，客户端需要管理多个连接以处理多个请求，增加了复杂性。
HTTP/2.0：
- 引入了更高效的连接管理，允许在单个连接中处理多个流，简化了连接的管理。

总结

特性	HTTP/1.1	HTTP/2.0
传输方式	文本格式	二进制格式
多路复用	不支持，存在队头阻塞	支持，多个请求并发处理，tcp端依然有队头阻塞
头部压缩	不支持	支持，使用 HPACK 压缩
服务器推送	不支持	支持
连接管理	独立连接，复杂管理	单个连接，简化管理

10.HTTP3.0有了解过吗？

无队头阻塞: QUIC 使用UDP协议来传输数据。一个连接上的多个stream之间没有依赖, 如果一个stream丢了一个UDP包，UDP不管是否丢包，只管数据都传输到。不会影响后面的stream，不存在队头阻塞问题。
零 RTT 连接建立：QUIC 允许在首次连接时进行零往返时间连接建立，从而减少了连接延迟，加快了页面加载速度。2.0时三次tcp握挥，TLS三次握挥，QUIC进行融合，更快的链接
连接迁移：QUIC 允许在网络切换（如从 Wi-Fi 到移动网络）时，识别一个唯一的IP值。将连接迁移到新的 IP 地址，从而减少连接的中断时间。
向前纠错机制：每个数据包除了它本身的内容之外，还包括了部分其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。向前纠错牺牲了每个数据包可以发送数据的上限，但是减少了因为丢包导致的数据重传。
安全性：HTTP/3默认使用TLS加密，确保了数据传输的安全性。

11. HTTPS和HTTP有哪些区别

两者的主要区别在于安全性和数据加密：

加密层：HTTPS 在HTTP 的基础上增加了SSL/TLS 协议作为加密层，确保数据传输的安全性。而HTTP 数据传输是明文的，容易受到攻击。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
端口：HTTPS 通常使用端口443 ，而HTTP 使用端口80。
HTTPS 协议需要向 CA 申请数字证书，来保证服务器的身份是可信的。

12.HTTPS工作原理

1. HTTPS 的安全性

2. SSL/TLS 握手过程

SSL/TLS 握手是建立安全连接的过程，主要包括以下步骤：

客户端问候（Client Hello）：
- 客户端向服务器发送请求，包含支持的 SSL/TLS 版本、加密算法和一个随机数。
服务器问候（Server Hello）：
- 服务器回复客户端，选择 SSL/TLS 版本和加密算法，并发送自己的随机数。
证书交换：
- 服务器发送数字证书给客户端。证书中包含服务器的公钥和由受信任的证书颁发机构（CA）签名的信息，用于验证服务器的身份。
证书验证：
- 客户端验证服务器的证书是否有效（如是否过期、是否由受信任的 CA 签发）。
密钥交换：
- 客户端生成一个随机的“会话密钥”，使用服务器的公钥加密后发送给服务器。只有服务器能用其私钥解密这个会话密钥。
加密确认：
- 客户端和服务器使用会话密钥进行加密通信，双方发送“完成”消息，表示握手完成。

3. 加密类型

非对称加密：
- 在握手过程中使用，确保安全密钥的传输。使用一对密钥（公钥和私钥），公钥加密的信息只能用私钥解密。
对称加密：
- 在数据传输过程中使用，利用会话密钥进行加密和解密。速度快，适合大量数据传输。

4. 数据完整性和身份验证

数字证书：
- HTTPS 使用数字证书验证服务器身份，确保用户连接到合法的网站。
数据完整性：
- 使用消息认证码（MAC）或数字签名来确保数据在传输过程中未被篡改。

5. 性能影响和优化

性能影响：
- SSL/TLS 握手和加密过程会增加延迟，影响加载速度。
优化方法：
- 使用 HTTP/2 可以减少握手次数。
- 使用会话恢复（Session Resumption）减少握手次数。
- 启用 HTTP 缓存以减少重复请求。
- 使用 CDN 来加速内容交付。

13.TCP和UDP的区别

1. 基本概念

TCP（传输控制协议）：
- 面向连接的协议，确保数据的可靠传输。
- 数据在传输前需要建立连接，通过三次握手过程完成。
UDP（用户数据报协议）：
- 无连接的协议，数据传输不需要建立连接，效率更高。
- 数据发送后不保证到达，不进行重传机制。

2. 报文结构和传输方式

TCP 报文结构：
- TCP 报文包含序列号、确认号、标志位等，确保数据的顺序和完整性。
UDP 报文结构：
- UDP 报文较小，包含源端口、目的端口、长度和校验和，结构简单，传输效率高。

3. 基本特性和区别

可靠性：
- TCP：提供可靠性，保证数据的顺序和完整性，使用确认应答机制和重传机制。
- UDP：不保证数据的可靠性，数据包可能丢失、重复或乱序。
效率：
- TCP：由于需要建立连接和维护状态，开销较大，适合对可靠性要求高的应用。
- UDP：开销小，适合实时性要求高的应用，如视频流、在线游戏。

4. 适用场景

TCP 适用场景：
- 文件传输（FTP）、网页浏览（HTTP/HTTPS）、电子邮件（SMTP/IMAP）等需要保证数据完整性的应用。
UDP 适用场景：
- 实时应用，如视频会议、VoIP、在线游戏等对延迟敏感的场合。

5. 协议细节

TCP 三次握手：
- 客户端发送 SYN，服务器回复 SYN-ACK，客户端发送 ACK，建立连接。
UDP 校验和：
- UDP 使用校验和来检测数据传输中的错误，校验和在发送时计算，并在接收时验证。

6. 流量控制和拥塞控制

TCP 流量控制：
- 使用滑动窗口机制，控制数据发送的速率，避免接收方被淹没。
TCP 拥塞控制：
- 通过慢启动、拥塞避免和快速重传等机制，确保网络不被过度拥塞。

7. 优化选择

在实际应用中，根据需求选择 TCP 或 UDP：
- 需要可靠性：选择 TCP，确保数据传输的完整性。
- 需要实时性：选择 UDP，减少延迟，适应快速变化的网络环境。

14.TCP连接如何确保可靠性

TCP（传输控制协议）是一种面向连接的协议，提供可靠的数据传输服务。它的关键特性包括：

连接管理：
- 三次握手：在建立连接时，客户端和服务器之间会进行三次消息交换，以确保双方都能接收和发送数据。流程如下：
  1. 客户端发送一个 SYN（同步）包请求建立连接。
  2. 服务器回应一个 SYN-ACK（同步-确认）包表示同意连接。
  3. 客户端再次发送一个 ACK（确认）包，连接建立完成。
- 四次挥手：关闭连接时，双方需要进行四次消息交换，以确保所有数据都被传输完毕。流程如下：
  1. 一方发送 FIN（结束）包，表示想要关闭连接。
  2. 对方回应一个 ACK，确认接收到 FIN。
  3. 对方再发送 FIN，表示也要关闭连接。
  4. 最后，发送方回应 ACK，连接正式关闭。
差错控制：
- 序列号：每个TCP段都有一个序列号，用于标识数据的顺序。接收方可以根据序列号重新排序接收到的数据，以确保数据的完整性。
- 确认应答机制：接收方在成功接收到数据后，会发送一个确认应答（ACK）包，告知发送方数据已成功接收。
超时重传机制：
- 如果发送方在一定时间内没有收到ACK，它会重传数据段。这种机制确保了丢失的数据能够被重新发送，从而提高了可靠性。
流量控制：
- TCP使用流量控制来防止发送方发送数据过快，导致接收方处理不过来。通过调整窗口大小，TCP可以控制在网络中可以发送的未确认数据的数量，确保接收方有足够的缓冲区来处理Incoming数据。
拥塞控制：
- 拥塞控制用于避免网络过载。TCP通过监测丢包和延迟情况，动态调整发送速率。这是通过算法（如慢启动、拥塞避免等）来实现的，确保网络在高负载情况下也能平稳运行。

TCP的流量控制和拥塞控制对网络性能的影响

流量控制：通过动态调整发送速率，流量控制可以有效防止接收方的缓冲区溢出，确保数据的平稳传输。
拥塞控制：通过避免网络的过度拥塞，拥塞控制确保了在高流量情况下，数据仍然能够有效传输，减少了丢包和重传的概率，从而提高了整体的网络性能。

15.既然提到了拥塞控制，那你能说说说拥塞控制是怎么实现的嘛

拥塞控制的必要性

TCP拥塞控制的主要目的是：

动态调整发送速率：在网络中，数据的发送速率需要根据网络的当前状态进行动态调整。过快的数据发送可能导致网络拥塞，进而导致数据丢失和延迟。
防止网络过载：通过控制发送速率，拥塞控制有助于避免网络过载，确保网络的稳定性和高效性。这对于保证用户体验和应用性能至关重要。

拥塞控制的主要算法

TCP拥塞控制主要使用以下几种算法：

慢启动（Slow Start）：
- 在连接开始时，TCP的发送窗口大小设置为一个小值（通常为1或2个最大报文段）。
- 每当收到一个ACK确认，窗口大小就加倍（指数增长），这样可以快速探测网络的带宽。
- 这个过程会持续进行，直到达到一个设定的阈值（慢启动阈值）。
拥塞避免（Congestion Avoidance）：
- 一旦窗口大小超过慢启动阈值，TCP进入拥塞避免阶段。
- 在这个阶段，窗口大小的增长速度减慢，采用线性增长（每经过一个RTT增加1个MSS），以避免网络的进一步拥塞。
快重传（Fast Retransmit）：
- 当接收方检测到数据包的丢失（通常是通过收到三个重复的ACK）时，会立即告知发送方。
- 发送方在收到这些重复确认后，会立即重传丢失的数据包，而不是等待超时，这样可以更快地恢复丢失的数据。
快恢复（Fast Recovery）：
- 在快重传发生后，发送方不会立即回到慢启动阶段，而是尝试继续以当前的窗口大小发送数据。
- 窗口大小会在检测到丢包时稍微减小（通常减半），然后在快速重传后进行线性增长。这种方法有助于快速恢复数据传输，同时避免网络再次拥塞。

16.TCP流量控制是怎么实现的？

流量控制的目的

TCP流量控制的主要目的是：

防止数据溢出：确保发送方不会以超过接收方处理能力的速度发送数据，避免接收方的缓冲区溢出，导致数据丢失或错误。

TCP流量控制的基本工作原理

TCP流量控制通过滑动窗口机制来实现，具体包括以下几个关键组件和步骤：

滑动窗口机制：
- 窗口大小：接收方会向发送方通告一个窗口大小，表示它当前可以接收的字节数。这个大小根据接收方的缓冲区情况动态调整。
- 数据流动：发送方根据接收方通告的窗口大小来决定可以发送的数据量。只有在收到确认（ACK）后，发送方才能继续发送新的数据。
窗口的通告和更新：
- 当接收方接收到数据并处理后，会更新其窗口大小，并通过ACK包将新的窗口大小发送给发送方。
- 发送方在接收到这个更新后，会相应调整发送的数据量。这种机制确保了数据的流动是自适应的。

流量控制与拥塞控制的区别

流量控制：主要关注的是发送方与接收方之间的速率匹配，确保发送方不会发送超过接收方处理能力的数据。它侧重于端到端的有效数据传输。
拥塞控制：主要关注的是网络的整体状况，防止网络过载。当网络出现拥塞时，TCP会降低发送速率，确保网络能够正常运转。拥塞控制通常通过算法（如慢启动、拥塞避免等）来实现。

TCP报文结构与流量控制相关的字段

在TCP报文中，有几个字段与流量控制直接相关：

窗口大小字段：这个字段用于表示接收方当前的缓冲区大小，告诉发送方可以发送多少字节的数据。
序列号：用于标识数据的顺序，确保数据能够按正确的顺序到达。
确认号：指明接收方期待下一个字节的序列号，帮助发送方确认哪些数据已经成功接收。

17.UDP怎么实现可靠传输

UDP的特点

无连接：UDP是一种无连接的协议，不需要在发送数据之前建立连接。
不可靠：UDP本身不提供可靠性保障，数据包可能会丢失、重复或乱序到达。

如何实现UDP的可靠传输

虽然UDP本身不具备可靠性，但可以通过一些机制和技术在应用层实现可靠传输。以下是常用的方法：

应用层确认（ACK）：
- 在发送数据后，接收方可以发送确认（ACK）消息回给发送方，告知数据包已成功接收。
- 发送方在未收到ACK的情况下，可以重传数据，确保数据最终到达。
重传机制：
- 如果发送方在一定时间内没有收到ACK，可以设置一个超时重传机制，重新发送未确认的数据包。
序列号：
- 在每个数据包中添加序列号，接收方可以根据序列号判断数据包的顺序，确保数据的正确排序。
- 这样可以处理乱序问题，保证数据的完整性。
数据包完整性校验：
- UDP本身提供了校验和功能，用于检测数据传输中的错误。应用层可以实现更复杂的错误检测和校正机制，确保数据的完整性。
流量控制与拥塞控制：
- 尽管UDP是无连接的，但在应用层可以实现流量控制和拥塞控制机制，防止网络拥塞和数据丢失。

18.三次握手

TCP三次握手的步骤和目的

TCP三次握手是建立TCP连接的重要过程，主要包括以下三个步骤：

第一步：SYN
- 发送方（客户端）向接收方（服务器）发送一个SYN（同步）包，表示请求建立连接。
- 目的：通知接收方，客户端希望建立连接，并开始同步序列号。
第二步：SYN-ACK
- 接收方（服务器）收到SYN包后，回应一个SYN-ACK包，表示同意建立连接。这个包中包含接收方的序列号和对客户端SYN的确认号（ACK）。
- 目的：确认收到客户端的请求，并向客户端发送自己的序列号。
第三步：ACK
- 发送方（客户端）收到SYN-ACK包后，发送一个ACK（确认）包，确认连接建立。此包中包含接收方的序列号的确认号。
- 目的：完成连接建立的确认，双方都可以开始数据传输。

序列号和确认号的重要性

序列号：每个TCP段都有一个序列号，用于标识数据的顺序。三次握手中，序列号用于确保双方的连接状态和同步。
确认号：确认号用于告知对方已成功接收的数据的下一个期望序列号。在三次握手中，确认号帮助确认双方的连接请求和响应，确保连接的有效性。

安全问题及防范

在三次握手过程中，可能存在一些安全问题，最常见的是SYN洪泛攻击：

SYN洪泛攻击：攻击者向目标服务器发送大量的SYN请求，但不发送ACK响应，导致服务器保持大量半开连接，资源耗尽，最终可能导致拒绝服务。

防范措施

SYN Cookies：通过不为每个SYN请求分配资源，而是使用数学算法生成的Cookie，确保在收到ACK时才真正分配资源，这样可以有效防止洪泛攻击。
连接限速：限制每个IP地址在一定时间内可以发起的连接请求数量，减少攻击的可能性。
防火墙和入侵检测系统：使用防火墙和入侵检测系统监控和过滤异常流量，及时识别和阻止攻击。

19.四次挥手的过程

TCP四次挥手的过程

TCP连接的关闭需要通过四次挥手来完成，主要包括以下步骤：

第一步：FIN
- 发送方（主动关闭连接的一方）发送一个FIN（结束）包，表示希望关闭连接。
- 原因：发送方已经完成数据传输，希望终止连接。
第二步：ACK
- 接收方收到FIN包后，发送一个ACK（确认）包，确认收到关闭请求。
- 原因：接收方确认已收到发送方的关闭请求，但仍然可以继续发送数据。
第三步：FIN
- 接收方在完成剩余的数据传输后，发送一个FIN包给发送方，表示也希望关闭连接。
- 原因：接收方已经完成数据传输，并希望关闭连接。
第四步：ACK
- 发送方收到接收方的FIN包后，发送ACK包确认。
- 原因：确认接收方的关闭请求，连接正式关闭。

TIME-WAIT状态的重要性

在四次挥手的过程中，发送方在发送最后的ACK包后，会进入TIME-WAIT状态。这个状态的重要性和作用包括：

确保最后的ACK到达：TIME-WAIT状态持续一段时间（通常为2MSL，MSL为最大报文段生存时间），确保接收方能收到最后的ACK。如果接收方没有收到，可能会重发FIN请求。
避免旧连接干扰新连接：TIME-WAIT状态可以防止旧的重复报文影响后续的新连接。如果没有这个等待期，旧的报文可能会被错误地解释为新连接的数据，导致混乱。

2MSL等待期的作用

2MSL：是指等待的时间长度，通常是两个最大报文段生存时间（MSL）。这个时间的设置确保网络中的所有数据包都有足够的时间被处理和消失，防止网络中的旧数据包干扰新的连接。

20.HTTP的Keep-Alive是什么？TCP 的 Keepalive 和 HTTP 的 Keep-Alive 是一个东西吗？

HTTP的Keep-Alive

概念：

HTTP的Keep-Alive是一种机制，允许客户端和服务器在同一个TCP连接上发送多个HTTP请求和响应，而不是在每个请求/响应后关闭连接。

目的：

提高性能：通过重用连接，减少连接建立和关闭的开销，从而提高网络通信的效率。
降低延迟：减少在多个请求之间的延迟，因为不需要为每个请求重新建立TCP连接。

如何启用：

HTTP的Keep-Alive通过HTTP头部进行配置：
- 客户端在请求中可以添加头部 Connection: keep-alive，表示希望保持连接。
- 服务器在响应中也会返回相应的头部，确认支持Keep-Alive，例如 Connection: keep-alive。
通过设置 Keep-Alive 头部，可以指定连接的最大存活时间及最大请求数。

TCP的Keepalive

概念：

TCP的Keepalive是一个机制，用于检测和清除死TCP连接。它通过定期发送探测包来判断连接是否仍然有效。

目的：

连接管理：确保双方之间的连接是活跃的，有助于及时清除因网络问题或一方崩溃而导致的无效连接。
资源释放：通过检测死连接，避免服务器资源的浪费，确保可以为新的连接释放资源。

如何配置：

TCP的Keepalive通常通过操作系统的网络设置进行配置，或者通过编程接口在应用层设置。
在Linux中，可以通过调整 /proc/sys/net/ipv4/tcp_keepalive_time 等参数来设置Keepalive的时间间隔。

HTTP的Keep-Alive与TCP的Keepalive的区别

目的不同：
- HTTP的Keep-Alive：旨在提高HTTP请求的效率，减少连接的建立和关闭次数。
- TCP的Keepalive：旨在检测连接的有效性，及时清理无效连接。
实现层面不同：
- HTTP的Keep-Alive：工作在应用层，依赖HTTP协议的头部设置。
- TCP的Keepalive：工作在传输层，依赖TCP协议的底层机制。
数据传输方式：
- HTTP的Keep-Alive允许多个请求/响应在同一连接上进行传输。
- TCP的Keepalive则是通过发送小的探测包，确保连接仍然活跃。

21.DNS查询过程

DNS概念及其作用

**DNS（域名系统）**是互联网的重要组成部分，它的主要作用是将用户友好的域名（如 www.example.com）转换为计算机可以理解的IP地址（如 192.0.2.1）。这使得用户在浏览网站时，无需记住复杂的数字地址。

DNS查询的基本过程

DNS查询可以分为两种主要类型：递归查询和迭代查询。

1. 递归查询

过程：
1. 客户端（通常是用户的计算机）向本地DNS解析器发送一个域名查询请求。
2. 本地DNS解析器如果没有缓存该域名的IP地址，就会向根DNS服务器发送请求。
3. 根DNS服务器返回该域名的顶级域（如 .com 或 .org）的DNS服务器的地址。
4. 本地DNS解析器接着向该顶级域DNS服务器发送请求。
5. 顶级域DNS服务器返回该域名的权威DNS服务器的地址。
6. 本地DNS解析器最终向权威DNS服务器发送请求，获得该域名的IP地址，并将结果缓存。
7. 最后，本地DNS解析器将IP地址返回给客户端。
特点：
- 客户端只需等待最终的结果。
- 本地DNS解析器承担了多个步骤的责任。

2. 迭代查询

过程：
1. 客户端向本地DNS解析器发送域名查询请求。
2. 本地DNS解析器如果没有缓存的结果，会向根DNS服务器发送请求。
3. 根DNS服务器返回顶级域DNS服务器的地址。
4. 本地DNS解析器再直接向顶级域DNS服务器发送请求。
5. 顶级域DNS服务器返回权威DNS服务器的地址。
6. 本地DNS解析器向权威DNS服务器发送请求，获得域名的IP地址。
7. 最后，IP地址被返回给客户端。
特点：
- 客户端可能需要向多个DNS服务器发送请求。
- 本地DNS解析器每次查询都需要明确指定下一个DNS服务器。
- 何时使用
- 当DNS解析器或客户端希望逐步获取结果，而不是依靠解析器完成所有的查询时，使用迭代查询。
- 迭代查询常用于服务器之间的通信，或者在DNS解析器无法完成整个查询时。
- 工作原理：
- 本地DNS解析器向根DNS服务器发送请求。如果根服务器知道答案，它会直接返回；如果不知道，它会返回一个指向下一级DNS服务器的地址。
- 解析器再向这个新的DNS服务器发送请求，依此类推，直到获得最终结果。
- 总结
- 递归查询：适合客户端需要得到最终结果，并将所有查询责任委托给本地DNS解析器的情况。
- 迭代查询：适合服务器之间逐级查询的情况，允许DNS服务器返回下一个可查询的DNS服务器地址，直到找到最终结果。

DNS查询涉及的不同层级的DNS服务器

根DNS服务器：
- 处于DNS层级的最顶端，负责引导查询请求到对应的顶级域DNS服务器。
顶级域DNS服务器（TLD DNS）：
- 管理特定顶级域（如 .com、.org、.net 等）的DNS服务器，指向相关的权威DNS服务器。
权威DNS服务器：
- 存储特定域名的DNS记录（如A记录、CNAME记录等），提供最终的IP地址或其他相关信息。

22.CDN 是什么

CDN的概念

**CDN（Content Delivery Network）**是一种分布式的网络架构，旨在通过将内容存储在靠近用户的多个服务器上，提高内容的传输速度和可靠性。CDN可以加速网站的访问速度，减轻源服务器的负担，并提高用户体验。

CDN的工作原理

内容缓存：CDN会将静态内容（如图片、视频、样式表和JavaScript文件等）缓存到全球范围内的边缘服务器上。这些边缘服务器分布在离用户较近的地理位置。
用户请求：当用户访问网站时，其请求会被定向到离用户最近的CDN边缘服务器，而不是直接请求源服务器。
内容交付：边缘服务器会快速响应用户请求，提供已缓存的内容。如果边缘服务器没有所需的内容，它会向源服务器请求并缓存这个内容，以备后续用户访问。

CDN的主要优势

提高网站性能：
- 缓存内容在离用户更近的地方，减少了网络延迟和加载时间，提升了页面加载速度。
减轻源服务器负担：
- 通过分散请求到多个边缘服务器，减少了源服务器的流量，降低了带宽成本。
增强可靠性和可用性：
- CDN可以在某个服务器出现故障时，自动将请求转发到其他可用的边缘服务器，确保内容始终可用。
支持高并发：
- CDN可以处理大量并发用户请求，避免源服务器因流量激增而崩溃。

CDN的关键组件和缓存策略

边缘服务器：
- 分布在各个地理位置的服务器，负责缓存和交付内容。
源服务器：
- 原始内容存储的位置，CDN会定期从源服务器更新缓存内容。
缓存策略：
- TTL（生存时间）：设置缓存内容的有效时间，过期后会重新从源服务器获取。
- 缓存失效：根据内容更新的频率，动态管理缓存内容，确保用户获取的是最新版本。

CDN在提高网站性能和用户体验方面的作用

快速加载时间：CDN通过将内容分发到离用户最近的服务器，显著减少了加载时间，提升了用户体验。
稳定性：在流量高峰期，CDN能保证网站的稳定性，避免因流量过大导致的崩溃。
全球覆盖：无论用户身处何地，CDN都能提供快速和一致的访问速度，使得网站在全球范围内的用户体验更加流畅。

23.Cookie和Session是什么？有什么区别？

Cookie和Session的定义

Cookie：
- Cookie是由服务器发送到客户端并存储在用户浏览器中的小数据片段。它们通常用于存储用户的偏好设置、登录信息和跟踪用户行为。
Session：
- Session是一种在服务器端存储用户会话信息的机制。每个用户会话都有一个唯一的Session ID，服务器通过这个ID来识别和管理用户的状态。

存储位置

Cookie：
- 存储在用户的浏览器中，用户可以查看和修改这些数据。
Session：
- 存储在服务器的内存或数据库中，用户不可直接访问，通常通过Session ID与浏览器的Cookie关联。

生命周期和大小限制

Cookie：
- 生命周期由设置的过期时间决定，可以是会话级（关闭浏览器后失效）或持久级（在指定时间后失效）。
- 大小限制通常为4KB，且总数在每个域名下有一定限制（通常为20个）。
Session：
- 生命周期通常在用户关闭浏览器后失效，但也可以设置过期时间（如30分钟无操作后失效）。
- 大小限制由服务器配置决定，通常可以存储更多的数据。

安全性

Cookie：
- Cookie容易受到XSS（跨站脚本）和CSRF（跨站请求伪造）攻击的威胁。
- 应该使用HttpOnly和Secure标志，提高安全性。
Session：
- Session ID必须安全存储，避免被盗用。若Session ID被攻击者获取，可能导致会话劫持。

使用场景和不同作用

Cookie的使用场景：
- 存储用户偏好设置（如主题、语言）。
- 记录用户登录状态（如“记住我”功能）。
Session的使用场景：
- 处理登录状态和用户身份验证。
- 存储用户在网站上的活动（如购物车内容）。

安全性问题及提高安全性的方法

Cookie的安全性：
- HttpOnly：防止JavaScript访问Cookie，降低XSS攻击风险。
- Secure：仅在HTTPS连接中发送Cookie，防止中间人攻击。
- SameSite：限制跨站请求时Cookie的发送，防止CSRF攻击。
Session的安全性：
- 使用加密的Session ID，确保即使被截获也难以使用。
- 定期更新Session ID，降低Session劫持的风险。
- 设置Session过期时间，定期清理无效会话。

案例讨论

假设一个电商网站使用Cookie和Session来管理用户登录和购物车：

Cookie：用来存储用户的语言偏好和“记住我”选项。即使用户关闭浏览器，下一次访问时仍能保留这些设置。
Session：在用户登录后，存储用户的身份信息和购物车内容。用户在购物过程中，Session ID会关联到其浏览器的Cookie中，保持状态。