22-web通信协议篇

Web通信流程主要指客户端（如浏览器）与服务器之间进行数据交互的过程，涉及DNS解析、TCP连接、HTTP请求与响应等多个环节，下面为你详细介绍：

1.客户端发起请求

DNS解析

• 当用户在浏览器中输入一个网址（如 www.example.com）并回车后，浏览器首先会检查本地的 DNS 缓存（包括浏览器缓存、操作系统缓存），看是否已经有该域名对应的 IP 地址记录。
• a如果本地缓存中没有找到对应的 IP 地址，浏览器会向本地 DNS 服务器发送 DNS 查询请求。本地 DNS 服务器通常由用户的网络服务提供商（ISP）提供。
• 若本地 DNS 服务器也没有该域名的记录，它会根据配置，向根 DNS 服务器、顶级域名 DNS 服务器和权威 DNS 服务器依次进行查询，最终获取到该域名对应的 IP 地址，并将结果返回给浏览器。

DNS（Domain Name System）解析是将域名转换为 IP 地址的过程，以下为你详细介绍其解析流程并通过相应的 mermaid 代码进行图解。

2.DNS 解析流程概述

1. 客户端发起请求：当用户在浏览器中输入一个域名（如 www.example.com），浏览器会调用操作系统的 DNS 解析器，发起一个 DNS 查询请求。
2. 本地 DNS 缓存查询：操作系统首先会检查本地的 DNS 缓存（如 Windows 的 DNS 客户端缓存、Linux 的 /etc/resolv.conf 配置及相关缓存），看是否有该域名对应的 IP 地址。如果有且未过期，直接使用该 IP 地址进行访问。
3. 本地 DNS 服务器查询：如果本地缓存中没有，操作系统会将请求发送到本地 DNS 服务器（通常由你的网络服务提供商（ISP）提供）。本地 DNS 服务器也会先检查自己的缓存。
4. 根 DNS 服务器查询：如果本地 DNS 服务器没有该域名的记录，它会向根 DNS 服务器发送查询请求。根 DNS 服务器会返回负责该顶级域名（如 .com）的顶级域名服务器（TLD）的地址。
5. 顶级域名服务器查询：本地 DNS 服务器接着向对应的顶级域名服务器发送查询请求，顶级域名服务器会返回负责该域名的权威 DNS 服务器的地址。
6. 权威 DNS 服务器查询：本地 DNS 服务器再向权威 DNS 服务器发送查询请求，权威 DNS 服务器会返回该域名对应的 IP 地址。
7. 结果返回与缓存：本地 DNS 服务器将获取到的 IP 地址返回给客户端，并将该记录缓存起来，以便后续查询使用。客户端使用该 IP 地址访问目标网站。

mermaid 代码

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A([客户端输入域名]):::startend --> B(本地 DNS 缓存查询):::process
    B -->|命中| C(使用缓存 IP 访问网站):::process
    B -->|未命中| D(本地 DNS 服务器查询):::process
    D -->|命中| C
    D -->|未命中| E(根 DNS 服务器查询):::process
    E --> F(返回顶级域名服务器地址):::process
    D -->|向顶级域名服务器查询| G(顶级域名服务器查询):::process
    G --> H(返回权威 DNS 服务器地址):::process
    D -->|向权威 DNS 服务器查询| I(权威 DNS 服务器查询):::process
    I --> J(返回域名对应的 IP 地址):::process
    J --> K(本地 DNS 服务器缓存结果):::process
    K --> L(返回 IP 给客户端):::process
    L --> C

代码解释

• 客户端输入域名：用户在浏览器中输入要访问的域名。
• 本地 DNS 缓存查询：操作系统首先检查本地缓存。
• 本地 DNS 服务器查询：如果本地缓存未命中，将请求发送到本地 DNS 服务器。
• 根 DNS 服务器查询：本地 DNS 服务器向根 DNS 服务器查询顶级域名服务器地址。
• 顶级域名服务器查询：本地 DNS 服务器向顶级域名服务器查询权威 DNS 服务器地址。
• 权威 DNS 服务器查询：本地 DNS 服务器向权威 DNS 服务器查询域名对应的 IP 地址。
• 缓存与返回：本地 DNS 服务器缓存结果并返回给客户端，客户端使用该 IP 地址访问网站。

通过这个流程图，你可以清晰地看到 DNS 解析的整个过程。

TCP连接建立（TCP三次握手）

• 客户端发送 SYN 包：浏览器获取到服务器的 IP 地址和端口号（通常 Web 服务使用 80 端口用于 HTTP 协议，443 端口用于 HTTPS 协议）后，会向服务器发起一个 TCP 连接请求。客户端会随机选择一个初始序列号（ISN），并向服务器发送一个 SYN（同步）包，表示请求建立连接。
• 服务器发送 SYN + ACK 包：服务器接收到客户端的 SYN 包后，如果同意建立连接，会为该连接分配资源，并向客户端发送一个 SYN + ACK 包。其中 SYN 表示同意建立连接，ACK 表示对客户端 SYN 包的确认，同时服务器也会随机选择一个自己的初始序列号。
• 客户端发送 ACK 包：客户端收到服务器的 SYN + ACK 包后，会向服务器发送一个 ACK 包，表示对服务器 SYN 包的确认。至此，TCP 连接建立成功，双方可以开始进行数据传输。

TCP（Transmission Control Protocol）三次握手是 TCP 协议建立连接的重要过程，下面为你详细介绍该过程并通过 mermaid 代码进行图解。

3.TCP 三次握手流程概述

1. 客户端向服务器发送 SYN 包：客户端想要与服务器建立连接，会向服务器发送一个 SYN（Synchronize Sequence Numbers）包，其中包含客户端的初始序列号（ISN，Initial Sequence Number）$x$。此时客户端进入 SYN_SENT 状态，表示已发送同步请求。
2. 服务器发送 SYN + ACK 包：服务器收到客户端的 SYN 包后，会向客户端发送一个 SYN + ACK 包。SYN 表示服务器也同意建立连接，同时包含服务器自己的初始序列号 $y$；ACK 是对客户端 SYN 包的确认，确认号为 $x + 1$，表示服务器期望收到客户端的下一个序列号为 $x + 1$ 的数据包。此时服务器进入 SYN_RCVD 状态。
3. 客户端发送 ACK 包：客户端收到服务器的 SYN + ACK 包后，会向服务器发送一个 ACK 包，确认号为 $y + 1$，表示客户端期望收到服务器的下一个序列号为 $y + 1$ 的数据包。客户端进入 ESTABLISHED 状态，服务器收到该 ACK 包后也进入 ESTABLISHED 状态，此时连接建立成功。

mermaid 代码

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: SYN = 1, Seq = x
    activate Server
    Server-->>Client: SYN = 1, ACK = 1, Seq = y, Ack = x + 1
    deactivate Server
    activate Client
    Client-->>Server: ACK = 1, Seq = x + 1, Ack = y + 1
    deactivate Client
    Note right of Server: 连接建立成功

代码解释

• 客户端发送 SYN 包：Client->>Server: SYN = 1, Seq = x 表示客户端向服务器发送一个 SYN 包，其中 SYN = 1 表示这是一个同步请求，Seq = x 是客户端的初始序列号。
• 服务器发送 SYN + ACK 包：Server-->>Client: SYN = 1, ACK = 1, Seq = y, Ack = x + 1 表示服务器向客户端发送一个 SYN + ACK 包，SYN = 1 表示服务器同意建立连接，ACK = 1 表示对客户端 SYN 包的确认，Seq = y 是服务器的初始序列号，Ack = x + 1 是确认号。
• 客户端发送 ACK 包：Client-->>Server: ACK = 1, Seq = x + 1, Ack = y + 1 表示客户端向服务器发送一个 ACK 包，ACK = 1 表示确认，Seq = x + 1 是客户端的序列号，Ack = y + 1 是对服务器 SYN 包的确认号。

通过这个序列图，你可以清晰地看到 TCP 三次握手的整个过程，以及客户端和服务器之间的消息交互顺序。

抓包查看三次握手

在 Linux 中，可以通过抓包工具（如 tcpdump）直接观察 TCP 三次握手的过程。以下是详细步骤和解释：

1. 三次握手理论回顾

TCP 三次握手流程：

1. SYN：客户端发送 SYN（seq=x）到服务端，进入 SYN_SENT 状态。
2. SYN-ACK：服务端回复 SYN-ACK（seq=y, ack=x+1），进入 SYN_RCVD 状态。
3. ACK：客户端发送 ACK（ack=y+1），双方进入 ESTABLISHED 状态，连接建立。

2. 使用 tcpdump 抓包观察

步骤 1：安装抓包工具

sudo apt install tcpdump  # Debian/Ubuntu
sudo yum install tcpdump  # CentOS/RHEL

步骤 2：启动抓包

sudo tcpdump -i enp0s5 -S -nn 'tcp port 80 and host 10.211.55.20'

• -i any：监听所有网卡。
• -S：显示绝对序列号（非相对值）。
• -nn：禁用域名和端口解析（显示 IP 和端口号）。
• tcp port 80：过滤 HTTP 流量（以访问 Web 服务为例）。

步骤 3：触发 TCP 连接

打开另一个终端，用 curl 或 nc 发起 HTTP 请求：

http > tcp

curl http://目标IP         # 发起 HTTP 请求（触发三次握手）
# 或
nc -v 目标IP 80           # 手动建立 TCP 连接

3. 抓包输出示例

以下是 tcpdump 输出的三次握手过程：

# 1. 客户端 -> 服务端（SYN）
10:00:01.123456 IP 192.168.1.2.54321 > 目标IP.80: Flags [S], seq 1234567890, ... length 0

# 2. 服务端 -> 客户端（SYN-ACK）
10:00:01.123789 IP 目标IP.80 > 192.168.1.2.54321: Flags [S.], seq 987654321, ack 1234567891, ... length 0

# 3. 客户端 -> 服务端（ACK）
10:00:01.124000 IP 192.168.1.2.54321 > 目标IP.80: Flags [.], ack 987654322, ... length 0

字段解析

• Flags [S]：SYN 标志。
• Flags [S.]：SYN-ACK 标志（S 表示 SYN，. 表示 ACK）。
• seq：序列号（发送方的初始值）。
• ack：确认号（对方序列号 +1）。

4. 通过 netstat 或 ss 查看连接状态

在握手过程中，查看连接状态：

ss -tn sport = :80    # 查看所有目标端口为 80 的 TCP 连接

• SYN-SENT：客户端发送 SYN 后的状态。
• SYN-RECEIVED：服务端收到 SYN 后的状态。
• ESTABLISHED：三次握手完成后的状态。

5. 手动模拟握手（仅限调试）

使用 nc 或 socat 手动发送数据包：

# 客户端发送 SYN（需 root 权限）
sudo hping3 -S 目标IP -p 80 -c 1

• -S：发送 SYN 包。
• -c 1：发送一次后停止。

总结

• 核心工具：tcpdump 抓包观察，curl/nc 触发连接。
• 关键标志：SYN → SYN-ACK → ACK。
• 验证方法：通过序列号和状态变化确认握手逻辑。

通过实际抓包和命令操作，可以直观理解 TCP 三次握手的底层机制。

测试结果解读

1. 三次握手阶段

数据包 1：客户端 → 服务端（SYN）

15:36:46.174930 IP 10.211.55.20.53366 > 10.211.55.10.80: Flags [S], seq 3960767879, ...

• 行为：客户端（10.211.55.20:53366）向服务端（10.211.55.10:80）发送 SYN 包，发起连接。
• 关键字段：
  • Flags [S]：SYN 标志，表示同步序列号。
  • seq=3960767879：客户端初始序列号（ISN）。
  • win=64240：客户端接收窗口大小。
  • options [mss 1460,...]：最大报文段长度（MSS）为 1460 字节，支持时间戳（TS）和窗口缩放（wscale）。

数据包 2：服务端 → 客户端（SYN-ACK）

15:36:46.175000 IP 10.211.55.10.80 > 10.211.55.20.53366: Flags [S.], seq 1220595651, ack 3960767880, ...

• 行为：服务端响应 SYN-ACK，同意建立连接。
• 关键字段：
  • Flags [S.]：SYN 和 ACK 标志组合。
  • seq=1220595651：服务端初始序列号（ISN）。
  • ack=3960767880：确认客户端的 SYN（客户端初始序列号 3960767879 + 1）。

数据包 3：客户端 → 服务端（ACK）

15:36:46.175305 IP 10.211.55.20.53366 > 10.211.55.10.80: Flags [.], ack 1220595652, ...

• 行为：客户端发送 ACK，确认服务端的 SYN-ACK。
• 关键字段：
  • Flags [.]：纯 ACK 标志（无数据载荷）。
  • ack=1220595652：确认服务端初始序列号 1220595651 + 1。
• 结果：三次握手完成，连接进入 ESTABLISHED 状态。

2. HTTP 请求与响应

数据包 4：客户端 → 服务端（HTTP GET 请求）

15:36:46.175474 IP 10.211.55.20.53366 > 10.211.55.10.80: Flags [P.], seq 3960767880:3960767956, ... HTTP: GET / HTTP/1.1

• 行为：客户端发送 HTTP GET / 请求。
• 关键字段：
  • Flags [P.]：PUSH 标志（表示有数据传输）和 ACK。
  • seq=3960767880:3960767956：数据段序列号范围（长度 76 字节）。
  • length 76：HTTP 请求内容长度。

数据包 5：服务端 → 客户端（ACK 确认）

15:36:46.175496 IP 10.211.55.10.80 > 10.211.55.20.53366: Flags [.], ack 3960767956, ...

• 行为：服务端确认收到 HTTP 请求。
  • ack=3960767956：确认客户端已发送到 3960767956（即客户端下一序列号）。

数据包 6：服务端 → 客户端（HTTP 200 OK 响应）

15:36:46.175710 IP 10.211.55.10.80 > 10.211.55.20.53366: Flags [P.], seq 1220595652:1220596511, ... HTTP: HTTP/1.1 200 OK

• 行为：服务端返回 HTTP 响应（状态码 200）。
• 关键字段：
  • seq=1220595652:1220596511：服务端数据段序列号范围（长度 859 字节）。
  • length 859：HTTP 响应内容长度。

数据包 7：客户端 → 服务端（ACK 确认）

15:36:46.175911 IP 10.211.55.20.53366 > 10.211.55.10.80: Flags [.], ack 1220596511, ...

• 行为：客户端确认收到 HTTP 响应。
  • ack=1220596511：确认服务端已发送到 1220596511（即服务端下一序列号）。

3. 四次挥手阶段

数据包 8：客户端 → 服务端（FIN-ACK）

15:36:46.176052 IP 10.211.55.20.53366 > 10.211.55.10.80: Flags [F.], seq 3960767956, ack 1220596511, ...

• 行为：客户端发起连接关闭（主动发送 FIN）。
• 关键字段：
  • Flags [F.]：FIN 和 ACK 标志组合。
  • seq=3960767956：客户端最后一个数据包的序列号。

数据包 9：服务端 → 客户端（FIN-ACK）

服务器socket IP:Port > IP:Port

15:36:46.176107 IP 10.211.55.10.80 > 10.211.55.20.53366: Flags [F.], seq 1220596511, ack 3960767957, ...

• 行为：服务端同意关闭连接，并发送自己的 FIN。
• 关键字段：
  • Flags [F.]：服务端的 FIN-ACK。
  • ack=3960767957：确认客户端的 FIN（客户端序列号 3960767956 + 1）。

数据包 10：客户端 → 服务端（最终 ACK）

15:36:46.176438 IP 10.211.55.20.53366 > 10.211.55.10.80: Flags [.], ack 1220596512, ...

• 行为：客户端确认服务端的 FIN。
  • ack=1220596512：确认服务端序列号 1220596511 + 1。
• 结果：四次挥手完成，连接彻底关闭。

关键总结

1. 三次握手：SYN → SYN-ACK → ACK（数据包 1~3）。
2. HTTP 通信：客户端请求 → 服务端响应（数据包 4~7）。
3. 四次挥手：FIN-ACK → FIN-ACK → ACK（数据包 8~10）。
4. 序列号与确认号：始终遵循 ack = 对方 seq + 数据长度 的规则（例如 HTTP 请求长度 76，故 ack 增加 76）。

通过此过程，可以清晰看到 TCP 连接从建立到销毁的全生命周期。

4.发送HTTP请求

以下为你详细介绍发送 HTTP 请求的完整流程，并使用 Mermaid 绘制流程图来进行可视化展示。

HTTP 请求流程概述

1. DNS 解析：当用户在浏览器输入域名时，浏览器首先要通过 DNS 解析将域名转换为对应的 IP 地址。
2. TCP 连接：基于解析得到的 IP 地址和端口号（HTTP 默认端口是 80，HTTPS 默认端口是 443），客户端与服务器建立 TCP 连接，这通常通过 TCP 三次握手来完成。
3. HTTP 请求发送：连接建立后，客户端会根据用户的操作（如点击链接、提交表单等）构造 HTTP 请求消息，并发送给服务器。请求消息包含请求行、请求头和请求体。
4. 服务器处理请求：服务器接收到请求后，根据请求的内容进行相应的处理，可能涉及查询数据库、调用业务逻辑等操作。
5. HTTP 响应返回：服务器处理完请求后，会构造 HTTP 响应消息并返回给客户端。响应消息包含状态行、响应头和响应体。
6. TCP 连接关闭：客户端接收到响应后，通常会关闭与服务器的 TCP 连接（除非使用了持久连接）。
7. 浏览器解析渲染页面：客户端浏览器根据响应内容进行页面的解析和渲染，将网页展示给用户。

Mermaid 代码

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A([用户输入域名]):::startend --> B(DNS 解析):::process
    B --> C(TCP 连接建立):::process
    C --> D(客户端发送 HTTP 请求):::process
    D --> E(服务器接收并处理请求):::process
    E --> F(服务器返回 HTTP 响应):::process
    F --> G(客户端接收响应):::process
    G --> H(TCP 连接关闭):::process
    H --> I(浏览器解析渲染页面):::process
    I --> J([用户看到网页]):::startend

代码解释

1. 用户输入域名：整个流程的起始点，用户在浏览器地址栏输入要访问的域名。
2. DNS 解析：将域名转换为服务器的 IP 地址，以便后续建立网络连接。
3. TCP 连接建立：通过 TCP 三次握手，客户端与服务器建立可靠的连接。
4. 客户端发送 HTTP 请求：客户端根据用户的操作构造并发送 HTTP 请求消息。
5. 服务器接收并处理请求：服务器接收到请求后，进行相应的业务逻辑处理。
6. 服务器返回 HTTP 响应：服务器处理完请求后，构造并返回 HTTP 响应消息。
7. 客户端接收响应：客户端接收服务器返回的响应消息。
8. TCP 连接关闭：完成数据传输后，关闭 TCP 连接。
9. 浏览器解析渲染页面：客户端浏览器对响应内容进行解析和渲染，将网页呈现给用户。
10. 用户看到网页：整个流程的结束，用户在浏览器中看到最终的网页内容。

通过这个流程图，你可以清晰地了解发送 HTTP 请求的完整过程。

• 连接建立后，浏览器会根据用户的操作（如访问网页、点击链接等）构造一个 HTTP 请求消息。HTTP 请求通常由请求行、请求头和请求体三部分组成。
  • 请求行：包含请求方法（如 GET、POST 等）、请求的资源路径和 HTTP 协议版本。例如：GET /index.html HTTP/1.1 表示使用 GET 方法请求服务器上的 index.html 文件。
  • 请求头：包含一些关于请求的附加信息，如浏览器类型、接受的内容类型、字符编码等。例如：User - Agent: Mozilla/5.0 表示浏览器的类型和版本。
  • 请求体：对于一些需要向服务器提交数据的请求（如 POST 请求），请求体中会包含具体的数据内容，如表单数据、JSON 数据等。

服务器处理请求

• 服务器接收到客户端的 HTTP 请求后，会根据请求的内容进行相应的处理。这可能包括以下步骤：
  • 解析请求：服务器首先会解析 HTTP 请求消息，提取请求行、请求头和请求体中的信息，确定请求的方法、资源路径和数据内容。
  • 验证请求：服务器会对请求进行验证，检查请求的合法性，如请求的资源是否存在、请求的权限是否足够等。
  • 处理业务逻辑：如果请求合法，服务器会根据请求的资源路径和请求方法，调用相应的程序或脚本进行业务逻辑处理。例如，如果请求的是一个动态网页，服务器可能会执行相应的服务器端脚本（如 PHP、Python Flask 等），从数据库中获取数据并生成 HTML 页面。

服务器返回HTTP响应

• 服务器处理完请求后，会构造一个 HTTP 响应消息返回给客户端。HTTP 响应同样由响应行、响应头和响应体三部分组成。
  • 响应行：包含 HTTP 协议版本、状态码和状态描述。例如：HTTP/1.1 200 OK 表示请求成功，服务器可以正常返回资源。
  • 响应头：包含一些关于响应的附加信息，如响应的内容类型、字符编码、缓存策略等。例如：Content - Type: text/html; charset=UTF - 8 表示响应的内容类型是 HTML，字符编码为 UTF - 8。
  • 响应体：包含服务器返回给客户端的实际数据内容，如 HTML 页面、图片、JSON 数据等。

客户端处理响应

• 浏览器接收到服务器的 HTTP 响应后，会根据响应头中的信息对响应体进行处理。
  • 解析 HTML：如果响应的内容类型是 HTML，浏览器会对 HTML 代码进行解析，构建 DOM（文档对象模型）树。
  • 加载资源：在解析 HTML 的过程中，浏览器会发现其中引用的外部资源（如 CSS 文件、JavaScript 文件、图片等），并根据这些资源的 URL 再次发起 HTTP 请求，重复上述的 DNS 解析、TCP 连接和 HTTP 请求响应过程，获取这些资源。
  • 渲染页面：当所有的 HTML、CSS 和 JavaScript 资源都加载完成后，浏览器会根据 DOM 树和 CSS 样式规则进行页面渲染，将页面展示给用户。

5.TCP连接关闭（TCP四次挥手）

• 当浏览器和服务器完成数据交互后，双方会关闭 TCP 连接。关闭过程通常需要经过四次挥手：
  • 客户端发送 FIN 包：客户端向服务器发送一个 FIN（结束）包，表示请求关闭连接。
  • 服务器发送 ACK 包：服务器收到客户端的 FIN 包后，会向客户端发送一个 ACK 包，表示对客户端 FIN 包的确认。此时服务器还可以继续向客户端发送数据。
  • 服务器发送 FIN 包：当服务器也没有数据要发送时，会向客户端发送一个 FIN 包，表示请求关闭连接。
  • 客户端发送 ACK 包：客户端收到服务器的 FIN 包后，会向服务器发送一个 ACK 包，表示对服务器 FIN 包的确认。至此，TCP 连接正式关闭。

如果使用的是 HTTPS 协议，在 TCP 连接建立之后、HTTP 请求发送之前，还会进行 TLS 握手过程，用于建立安全的加密通道，确保数据在传输过程中的安全性和完整性。

\TCP 四次挥手是 TCP 协议中用于关闭连接的过程，确保双方都能正确地终止连接并释放资源。以下详细介绍 TCP 四次挥手的流程，并使用 Mermaid 绘制序列图进行可视化。

TCP 四次挥手流程概述

第一次挥手

客户端主动发起关闭连接的请求，向服务器发送一个 FIN（Finish）包，表示客户端已经没有数据要发送了，但仍可以接收数据。此时客户端进入 FIN_WAIT_1 状态。

第二次挥手

服务器收到客户端的 FIN 包后，向客户端发送一个 ACK 包作为确认，表示已经收到客户端的关闭请求。此时服务器进入 CLOSE_WAIT 状态，客户端收到 ACK 包后进入 FIN_WAIT_2 状态。

第三次挥手

服务器处理完剩余的数据后，也决定关闭连接，向客户端发送一个 FIN 包，表示服务器也没有数据要发送了。此时服务器进入 LAST_ACK 状态。

第四次挥手

客户端收到服务器的 FIN 包后，向服务器发送一个 ACK 包作为确认。此时客户端进入 TIME_WAIT 状态，服务器收到 ACK 包后进入 CLOSED 状态。客户端在 TIME_WAIT 状态停留一段时间（通常是 2 倍的最大段生命周期，即 2MSL）后，也进入 CLOSED 状态，连接彻底关闭。

Mermaid 代码

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: FIN = 1, Seq = u
    activate Server
    Server-->>Client: ACK = 1, Seq = v, Ack = u + 1
    deactivate Server
    Server->>Client: FIN = 1, ACK = 1, Seq = w, Ack = u + 1
    activate Client
    Client-->>Server: ACK = 1, Seq = u + 1, Ack = w + 1
    deactivate Client
    Note right of Client: 客户端进入 TIME_WAIT 状态
    Note right of Server: 服务器进入 CLOSED 状态
    Note right of Client: 等待 2MSL 后客户端进入 CLOSED 状态

代码解释

• 第一次挥手：Client->>Server: FIN = 1, Seq = u 表示客户端向服务器发送 FIN 包，FIN = 1 表明请求关闭连接，Seq = u 是客户端当前的序列号。
• 第二次挥手：Server-->>Client: ACK = 1, Seq = v, Ack = u + 1 表示服务器收到客户端的 FIN 包后，发送 ACK 包进行确认，ACK = 1 表示确认，Seq = v 是服务器的序列号，Ack = u + 1 是对客户端 FIN 包的确认号。
• 第三次挥手：Server->>Client: FIN = 1, ACK = 1, Seq = w, Ack = u + 1 表示服务器向客户端发送 FIN 包请求关闭连接，同时也对之前客户端的 FIN 包进行确认。
• 第四次挥手：Client-->>Server: ACK = 1, Seq = u + 1, Ack = w + 1 表示客户端收到服务器的 FIN 包后，发送 ACK 包进行确认。

通过这个序列图，你可以清晰地看到 TCP 四次挥手的完整过程以及客户端和服务器在不同阶段的状态变化。

web通信流程

在开始学web服务器之前，需要先理解web通信协议，才能够更好的吸收其中精华。

我们平时浏览⽹⻚的时候,会打开浏览器，输⼊⽹址后按下回⻋键，然后就会显示出你想要浏览的内容。在这个看似简单的⽤户⾏为背后，到底隐藏了些什么呢？

• 浏览器本身是⼀个客户端，当你输⼊URL的时候，⾸先浏览器会去请求DNS服务器，通过DNS获取相应的域名对应的IP

• 然后通过IP地址找到IP对应的服务器后，要求建⽴TCP连接

• 等浏览器发送完HTTP Request（请求）包后，服务器接收到请求包之后才开始处理请求包

• 服务器调⽤⾃身服务，返回HTTP Response（响应）包；

• 客户端收到来⾃服务器的响应后开始渲染这个Response包⾥的主体（body），等收到全部的内容随后断开与该服务器之间的TCP连接。

⼀个Web服务器也被称为HTTP服务器，它通过HTTP协议与客户端通信。

这个客户端通常指的是Web浏览器。

web服务器工作原理

Web服务器的核心工作是接收客户端（通常是浏览器）的请求，处理这些请求，并将相应的响应返回给客户端。下面将详细介绍其工作原理：

1. 启动与监听

• 初始化：在启动时，Web服务器会进行一系列初始化操作，包括加载配置文件，确定监听的IP地址和端口号（例如，HTTP服务默认端口是80，HTTPS服务默认端口是443），分配必要的系统资源，如内存和线程池等。
• 监听端口：Web服务器会创建一个套接字（socket），并将其绑定到指定的IP地址和端口上，然后开始监听该端口，等待客户端的连接请求。一旦有客户端尝试连接到这个端口，服务器就能感知到。

2. 接收客户端请求

• 建立连接：当客户端（如浏览器）向服务器的监听端口发起连接请求时，服务器会接受这个请求，通过TCP协议建立起与客户端之间的连接。这通常涉及TCP的三次握手过程，以确保连接的可靠性。
• 接收请求消息：连接建立后，客户端会向服务器发送HTTP请求消息。这个消息包含请求行（例如 GET /index.html HTTP/1.1 ，表明请求方法、请求的资源路径和HTTP协议版本）、请求头（包含关于请求的附加信息，如用户代理、接受的内容类型等），以及可能存在的请求体（如POST请求中提交的数据）。服务器会从网络套接字中读取这些数据。

3. 处理请求

• 解析请求：服务器接收到请求消息后，首先会对其进行解析，提取出请求行、请求头和请求体中的关键信息。通过解析请求行，服务器可以确定客户端请求的方法（GET、POST等）和请求的资源路径；解析请求头可以获取更多关于请求的上下文信息，如客户端的身份、缓存策略等。
• 验证请求：服务器会对请求进行合法性验证，检查请求的格式是否正确、请求的资源是否存在、客户端是否有访问该资源的权限等。例如，如果请求的资源不存在，服务器可能会返回一个404状态码。
• 执行相应操作：根据请求的方法和资源路径，服务器会执行不同的操作。
  • 静态资源请求：如果请求的是静态资源（如HTML文件、图片、CSS样式表、JavaScript脚本等），服务器会直接从文件系统中读取相应的文件，并准备将其作为响应内容返回。
  • 动态资源请求：对于动态资源请求（如访问一个由服务器端脚本生成的页面），服务器会调用相应的应用程序或脚本（如PHP、Python的Flask/Django框架等）来处理请求。这些应用程序可能会与数据库交互，执行一些业务逻辑，然后生成动态的内容作为响应。

4. 生成响应

• 构造响应消息：服务器处理完请求后，会构造一个HTTP响应消息返回给客户端。响应消息包括响应行（如 HTTP/1.1 200 OK ，包含协议版本、状态码和状态描述）、响应头（包含关于响应的附加信息，如内容类型、内容长度、缓存控制等）和响应体（即要返回给客户端的实际数据，如HTML页面内容、图片数据等）。
• 设置响应头：响应头中的信息对于客户端正确处理响应内容非常重要。例如，Content-Type 头指定了响应体的类型（如 text/html 表示HTML页面，image/jpeg 表示JPEG格式的图片），客户端可以根据这个信息来选择合适的方式显示或处理数据。

5. 返回响应

• 发送响应消息：服务器将构造好的HTTP响应消息通过之前建立的TCP连接发送回客户端。客户端接收到响应后，会根据响应头中的信息和响应体的内容进行相应的处理，如解析HTML页面、显示图片等。

6. 关闭连接

• 结束会话：在完成响应的发送后，服务器可以选择关闭与客户端的TCP连接，释放相关的系统资源。不过，现代的HTTP协议支持持久连接（如HTTP/1.1的 Keep - Alive 机制和HTTP/2的多路复用），允许在同一个连接上进行多次请求和响应，以提高效率。在这种情况下，连接可能会保持打开状态，等待客户端的下一个请求。

Web服务器的⼯作原理可以简单地归纳为:

• 客户端通过TCP/IP协议建⽴到服务器的TCP连接
• 客户端向服务器发送HTTP协议请求包，请求服务器⾥的资源⽂档
• 服务器向客户端发送HTTP协议应答包，如果请求的资源包含有动态语⾔的内容，那么服务器会调⽤动态语⾔ 的解释引擎负责处理“ 动态内容”，并将处理得到的数据返回给客户端
• 客户端与服务器断开。由客户端解释HTML⽂档，在客户端屏幕上渲染图形结果

小结

因此你会发现，web通信原理中，主要分两块协议的建立

• tcp/ip
• http

TCP/IP协议

TCP/IP（Transmission Control Protocol/Internet Protocol）协议是一个用于实现网络通信的协议族，它是互联网的基础通信协议，下面将从其定义、分层结构、主要协议、工作过程以及特点等方面进行详细介绍：

定义

TCP/IP协议是一组用于实现不同计算机之间数据通信和网络互联的协议集合。它定义了计算机如何连接到网络，以及数据如何在网络中传输和交换，确保了不同类型的计算机和网络设备能够在互联网上进行可靠、高效的通信。

分层结构

TCP/IP协议采用分层体系结构，通常分为四层，每一层都有特定的功能和协议：

• 网络接口层
  • 功能：负责将IP数据包封装成适合在物理网络上传输的帧，并处理与物理网络的接口细节，如以太网、Wi-Fi等。它与具体的硬件设备和网络介质密切相关，处理物理层和数据链路层的功能。
  • 相关协议：以太网协议、IEEE 802.11（Wi-Fi）协议等。
• 网络层
  • 功能：主要负责将数据包从源主机传输到目标主机，处理数据包的路由和转发。它通过IP地址来标识不同的主机，并根据路由表选择最佳的传输路径。
  • 相关协议：IP（Internet Protocol）协议，包括IPv4和IPv6；ICMP（Internet Control Message Protocol）协议，用于网络设备之间的错误报告和控制信息传递；ARP（Address Resolution Protocol）协议，用于将IP地址解析为物理MAC地址。
• 传输层
  • 功能：提供端到端的通信服务，确保数据在源端和目标端之间的可靠传输。它负责处理数据的分段、排序、确认和重传等问题，同时还能提供不同的服务质量，如TCP的可靠传输和UDP的高效传输。
  • 相关协议：TCP（Transmission Control Protocol）协议，提供面向连接的、可靠的字节流服务；UDP（User Datagram Protocol）协议，提供无连接的、不可靠的数据包服务。
• 应用层
  • 功能：为用户的应用程序提供网络服务接口，处理应用程序之间的通信。它定义了各种应用程序协议，使不同的应用程序能够通过网络进行数据交换。
  • 相关协议：HTTP（Hypertext Transfer Protocol）协议，用于在Web浏览器和Web服务器之间传输超文本数据；FTP（File Transfer Protocol）协议，用于文件的上传和下载；SMTP（Simple Mail Transfer Protocol）协议，用于电子邮件的发送；POP3（Post Office Protocol 3）和IMAP（Internet Message Access Protocol）协议，用于电子邮件的接收。

主要协议工作原理

• TCP协议
  • 连接建立（三次握手）：客户端向服务器发送一个SYN包，请求建立连接；服务器收到后，向客户端发送一个SYN + ACK包，表示同意建立连接；客户端再发送一个ACK包，确认连接建立。
  • 数据传输：建立连接后，双方可以进行数据传输。TCP将数据分割成多个数据包，并为每个数据包编号，确保数据的有序传输。接收方收到数据包后，会发送确认消息给发送方，如果发送方在一定时间内没有收到确认消息，会重传该数据包。
  • 连接关闭（四次挥手）：客户端向服务器发送一个FIN包，表示请求关闭连接；服务器收到后，发送一个ACK包确认；服务器再发送一个FIN包，表示自己也准备关闭连接；客户端发送一个ACK包确认，连接关闭。
• IP协议
  • 寻址：每个主机在网络中都有一个唯一的IP地址，IP协议根据这个地址将数据包从源主机路由到目标主机。IPv4地址是32位的，通常表示为四个用点分隔的十进制数（如192.168.1.1）；IPv6地址是128位的，采用十六进制表示。
  • 路由：当数据包在网络中传输时，路由器根据路由表选择最佳的传输路径，将数据包转发到下一个节点，直到到达目标主机。

工作过程

• 当应用程序需要发送数据时，首先在应用层将数据按照相应的应用层协议进行封装，形成应用层数据单元。
• 然后将应用层数据单元传递给传输层，传输层根据选择的协议（TCP或UDP）对数据进行分段，并添加相应的头部信息，形成传输层数据段（TCP段或UDP数据报）。
• 传输层数据段再传递给网络层，网络层将其封装成IP数据包，并添加IP头部，包含源IP地址和目标IP地址等信息。
• 网络层的IP数据包传递给网络接口层，网络接口层将其封装成适合物理网络传输的帧，并通过物理网络发送出去。
• 在接收端，数据按照相反的顺序进行处理，从网络接口层依次向上传递，经过各层的解封装和处理，最终将数据传递给相应的应用程序。

特点

• 开放性：TCP/IP协议是一个开放的标准，任何人都可以使用和实现这些协议，这使得不同厂商的计算机和网络设备能够方便地进行互联和通信。
• 可靠性：TCP协议通过三次握手、确认机制、重传机制等保证了数据传输的可靠性，确保数据能够准确无误地到达目标主机。
• 灵活性：TCP/IP协议的分层结构使得各层之间相对独立，便于进行修改和扩展。新的协议可以在不影响其他层的情况下添加到协议栈中。
• 可扩展性：随着互联网的发展，TCP/IP协议不断进行改进和扩展，如IPv6的引入解决了IPv4地址短缺的问题，同时也提供了更好的安全性和性能。

OSI七层模型

OSI（Open Systems Interconnection）七层模型是一个由国际标准化组织（ISO）定义的概念模型，用于理解和规范计算机网络通信的过程。它将网络通信划分为七个层次，每个层次都有特定的功能和职责，并且相邻层次之间通过接口进行交互。以下是对OSI七层模型各层的详细介绍：

物理层（Physical Layer）

• 功能：物理层是OSI模型的最底层，主要负责处理物理介质上的信号传输，包括电缆、光纤、无线等。它定义了传输介质的物理特性，如电缆的类型、接口的形状和尺寸、信号的编码方式、传输速率、传输距离等。物理层将数据以比特流的形式在物理介质上进行传输，确保信号的正确发送和接收。
• 示例：以太网电缆（如RJ - 45接口的网线）、光纤、无线Wi - Fi信号等都属于物理层的范畴。网卡也是物理层的设备，它负责将计算机内部的数字信号转换为适合在物理介质上传输的电信号或光信号。

数据链路层（Data Link Layer）

• 功能：数据链路层负责将物理层接收到的比特流组织成帧（Frame），并进行差错检测和纠正。

  • 它还负责在相邻节点之间建立、维护和释放数据链路连接，确保数据在链路层的可靠传输。数据链路层会为帧添加源地址和目标地址（通常是MAC地址），以便在局域网内进行数据的正确传输。

• 子层：数据链路层通常分为两个子层，即逻辑链路控制（LLC）子层和介质访问控制（MAC）子层。LLC子层负责提供逻辑链路的控制和管理，而MAC子层负责处理与物理介质的访问控制，如CSMA/CD（载波监听多路访问/冲突检测）协议用于以太网中的介质访问控制。

• 示例：以太网帧、Wi - Fi帧等都是数据链路层的帧格式。网桥和交换机是数据链路层的设备，它们根据MAC地址转发数据帧。

网络层（Network Layer）

​ 192.168.1.xx ,192.168.1.xx ,

小区，4号楼404，

4号楼404，

MAC地址

• 功能：网络层主要负责将数据从源主机传输到目标主机，处理数据包的路由和转发。它使用网络地址（如IP地址）来标识不同的主机和网络，并根据路由表选择最佳的传输路径。网络层将数据链路层的帧封装成数据包（Packet），并在数据包中添加源IP地址和目标IP地址等信息。
• 协议：主要的网络层协议包括IP（Internet Protocol），分为IPv4和IPv6；ICMP（Internet Control Message Protocol）用于网络设备之间的错误报告和控制信息传递；ARP（Address Resolution Protocol）用于将IP地址解析为物理MAC地址。
• 示例：路由器是网络层的典型设备，它根据IP地址转发数据包，实现不同网络之间的互联。

传输层（Transport Layer）

• 功能：传输层提供端到端的通信服务，确保数据在源端和目标端之间的可靠传输。它负责处理数据的分段、排序、确认和重传等问题，同时还能提供不同的服务质量，如可靠传输和高效传输。传输层通过端口号来区分不同的应用程序，使得多个应用程序可以同时在一台主机上进行通信。
• 协议：主要的传输层协议有TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）。TCP提供面向连接的、可靠的字节流服务，适用于对数据准确性要求较高的应用，如文件传输、电子邮件等；UDP提供无连接的、不可靠的数据包服务，适用于对实时性要求较高的应用，如音频和视频流、在线游戏等。
• 示例：当你使用浏览器访问网页时，浏览器和Web服务器之间通过TCP协议建立连接，确保网页数据的完整传输。而在在线视频播放时，可能会使用UDP协议来提高视频的实时性。

会话层（Session Layer）

• 功能：会话层负责建立、维护和管理不同应用程序之间的会话连接。它允许不同主机上的应用程序进行对话，并提供会话的同步和恢复机制。会话层可以控制会话的建立、拆除和同步，例如在两个应用程序之间进行文件传输时，会话层可以确保文件的正确传输和断点续传。
• 示例：远程登录协议（如Telnet和SSH）使用会话层来建立和管理用户与远程服务器之间的会话连接。在文件传输过程中，会话层可以确保传输的连续性和完整性。

表示层（Presentation Layer）

• 功能：表示层主要负责处理数据的表示和转换，确保不同系统之间的数据能够正确理解和交换。它可以对数据进行加密、解密、压缩、解压缩等操作，还可以进行数据格式的转换，如将ASCII码转换为EBCDIC码，或者将JPEG图像格式转换为PNG图像格式。
• 示例：当你在浏览器中访问一个加密的网站（使用HTTPS协议）时，表示层会对传输的数据进行加密和解密操作，确保数据的安全性。在文件传输中，如果文件进行了压缩，接收方的表示层会对文件进行解压缩操作。

应用层（Application Layer）

• 功能：应用层是OSI模型的最高层，直接为用户的应用程序提供网络服务接口。它定义了各种应用程序协议，使不同的应用程序能够通过网络进行数据交换。应用层协议通常与特定的应用程序相关，如Web浏览器、电子邮件客户端、文件传输工具等。
• 协议：常见的应用层协议包括HTTP（Hypertext Transfer Protocol）用于在Web浏览器和Web服务器之间传输超文本数据；FTP（File Transfer Protocol）用于文件的上传和下载；SMTP（Simple Mail Transfer Protocol）用于电子邮件的发送；POP3（Post Office Protocol 3）和IMAP（Internet Message Access Protocol）用于电子邮件的接收。
• 示例：当你使用浏览器访问网页时，浏览器使用HTTP协议与Web服务器进行通信，获取网页内容；使用电子邮件客户端发送和接收邮件时，客户端使用SMTP、POP3或IMAP协议与邮件服务器进行交互。

各层之间的关系

• OSI七层模型的各层之间是相互独立又相互协作的关系。上层依赖下层提供的服务来完成自身的功能，而下层则为上层提供必要的支持。数据在发送端从应用层开始，依次经过各层的处理和封装，最终通过物理层发送出去；在接收端，数据从物理层开始，依次经过各层的解封装和处理，最终到达应用层。

TCP/IP三次握手

TCP（Transmission Control Protocol）是一种面向连接的、可靠的传输层协议，三次握手是TCP建立连接的重要过程。该过程确保了通信双方都具备发送和接收数据的能力，并且就初始序列号达成一致，为后续的数据传输奠定基础。以下为你详细介绍TCP三次握手的具体步骤：

第一次握手：客户端向服务器发送SYN包

• 动作：客户端（通常是发起连接请求的一方，比如浏览器）想要与服务器建立TCP连接，会随机选择一个初始序列号（Initial Sequence Number，ISN），并向服务器发送一个带有SYN（Synchronize）标志位的TCP段。SYN标志位用于表示这是一个连接请求。这个TCP段中还包含客户端选择的初始序列号，假设为x。
• 含义：客户端向服务器表明自己有建立连接的意愿，并且告知服务器自己后续发送数据时的初始序列号。可以把这一步想象成客户端主动向服务器打招呼：“我想和你建立连接，我后面发数据会从序列号x开始。”

第二次握手：服务器向客户端发送SYN + ACK包

• 动作：服务器接收到客户端的SYN包后，如果同意建立连接，会为该连接分配必要的资源。服务器会选择自己的初始序列号，假设为y，然后向客户端发送一个带有SYN和ACK（Acknowledgment）标志位的TCP段。其中SYN标志位表示服务器也同意建立连接，ACK标志位用于确认收到客户端的SYN包。ACK确认号的值为客户端的初始序列号x加1（即x + 1），表示服务器期望客户端下一个发送的数据序列号是x + 1。
• 含义：服务器回应客户端，表示同意建立连接，同时告知客户端自己后续发送数据时的初始序列号是y，并且确认已经收到客户端的连接请求。就好像服务器回复客户端：“我同意和你建立连接，我后面发数据会从序列号y开始，我已经收到你从序列号x开始的请求啦，期待你下一个发序列号x + 1的数据。”

第三次握手：客户端向服务器发送ACK包

• 动作：客户端收到服务器的SYN + ACK包后，会向服务器发送一个带有ACK标志位的TCP段。ACK确认号的值为服务器的初始序列号y加1（即y + 1），表示客户端期望服务器下一个发送的数据序列号是y + 1。同时，客户端发送的数据序列号为x + 1，这是根据服务器在第二次握手中的确认信息来确定的。
• 含义：客户端确认收到服务器的同意连接信息，并且告知服务器自己已经做好接收服务器从序列号y + 1开始的数据的准备。相当于客户端再次回应服务器：“我收到你同意连接的消息了，我准备好接收你从序列号y + 1开始的数据啦，我现在开始发序列号x + 1的数据给你。”

三次握手的意义

• 同步初始序列号：通信双方通过三次握手交换并确认了各自的初始序列号，为后续的数据传输提供了基础。在数据传输过程中，序列号用于保证数据的有序性和可靠性。
• 确认双方的发送和接收能力：通过三次握手，客户端和服务器都向对方证明了自己具备发送和接收数据的能力。第一次握手证明客户端能发数据，第二次握手证明服务器能收能发数据，第三次握手证明客户端能收数据。
• 建立可靠连接：确保双方在正式进行数据传输之前，就连接的参数和状态达成一致，为后续的可靠数据传输提供保障。

TCP数据报文首部格式

TCP（Transmission Control Protocol）数据报文首部包含了TCP协议用于建立连接、传输数据、控制流量和确保数据可靠传输等重要信息。其首部格式固定部分有20字节，也可包含长度可变的选项部分，以下是详细介绍：

固定部分（20字节）

1. 源端口号（Source Port）
   • 长度：16位
   • 含义：标识发送该TCP报文的应用程序的端口号。端口号用于区分同一台主机上不同的应用程序，范围是0 - 65535。一些知名端口号被预留给特定的服务，例如HTTP服务使用端口80，HTTPS服务使用端口443。
2. 目的端口号（Destination Port）
   • 长度：16位
   • 含义：标识接收该TCP报文的应用程序的端口号。TCP通过源端口号和目的端口号将报文准确地交付给相应的应用程序。
3. 序列号（Sequence Number）
   • 长度：32位
   • 含义：表示本报文段所发送数据的第一个字节的序号。在建立连接时，双方会协商初始序列号（ISN），后续数据传输中，序列号依次递增，用于保证数据的有序性和可靠性。例如，如果一个TCP报文段携带了100字节的数据，其序列号为1000，那么下一个报文段的序列号通常为1100（假设无数据丢失或乱序）。
4. 确认号（Acknowledgment Number）
   • 长度：32位
   • 含义：期望收到对方下一个报文段的第一个数据字节的序号。如果确认号为N，则表示接收方已经成功接收了序号小于N的所有数据，期望接下来收到序号为N的数据。确认号用于实现TCP的可靠传输机制，发送方根据接收方返回的确认号来确认数据是否被正确接收。
5. 数据偏移（Data Offset）
   • 长度：4位
   • 含义：指出TCP报文段的数据起始处距离TCP报文段首部起始处的偏移量。由于首部长度可变（包含选项部分），数据偏移以4字节为单位，所以TCP首部的最大长度为60字节（15×4）。
6. 保留位（Reserved）
   • 长度：6位
   • 含义：保留给未来使用，目前必须置为0。
7. 控制位（Control Bits）
   • 长度：6位
   • 含义：包含多个标志位，用于控制TCP的连接建立、数据传输和连接关闭等操作。常见的标志位如下：
     • URG（Urgent Pointer field significant）：紧急指针标志，置为1表示紧急指针字段有效。
     • ACK（Acknowledgment field significant）：确认标志，置为1表示确认号字段有效，通常在建立连接后的正常数据传输中该标志都为1。
     • PSH（Push function）：推送标志，置为1表示接收方应尽快将数据交付给应用程序，而不是等到缓冲区满。
     • RST（Reset the connection）：复位标志，置为1表示复位连接，用于异常情况下强制关闭连接。
     • SYN（Synchronize sequence numbers）：同步标志，用于建立连接时同步序列号，第一次握手时该标志置为1。
     • FIN（No more data from sender）：结束标志，置为1表示发送方已经没有数据要发送，请求关闭连接。
8. 窗口大小（Window Size）
   • 长度：16位
   • 含义：表示发送方或接收方的接收窗口大小，用于流量控制。接收方通过这个字段告知发送方自己当前能够接收的数据量，发送方根据这个值来调整发送数据的速率，避免接收方缓冲区溢出。
9. 校验和（Checksum）
   • 长度：16位
   • 含义：用于检测TCP报文段在传输过程中是否发生错误。计算校验和时，不仅包括TCP首部和数据部分，还包括一个伪首部，伪首部包含了源IP地址、目的IP地址、协议号和TCP报文段的长度等信息，以确保TCP报文段在网络层的传输中不被篡改。
10. 紧急指针（Urgent Pointer）
    • 长度：16位
    • 含义：只有当URG标志置为1时，该字段才有意义。它指出本报文段中紧急数据的最后一个字节的序号相对于序列号字段的偏移量，用于处理紧急数据。

选项部分（可变长度）

• 含义：TCP首部可以包含可变长度的选项部分，用于提供额外的功能或信息。常见的选项包括最大报文段长度（MSS）选项，用于协商双方在传输过程中所能接受的最大报文段长度；窗口扩大选项，用于扩大窗口大小的表示范围，以支持更高的带宽；时间戳选项，用于计算往返时间（RTT）和防止序号绕回等。选项部分的长度通常是4字节的整数倍，最后可能会有填充字节，以确保首部长度是4字节的整数倍。

关于TCP首部重要字段的解释

• 源端口、目的端口

  • 各占 2 个字节，分别写入源端口和目的端口。IP 地址 + 端口号就可以确定一个进程地址

• 序号/序列号（Sequense Number）

  • 在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。该字段表示本报文段所发送的数据的第一个字节的序号。
  • 例如，一报文段的序号是 101，共有 100 字节的数据。（seq=101）
    • 这就表明：本报文段的数据的第一个字节的序号是 101，最后一个字节的序号是 200。
    • 显然，下一个报文段的数据序号应当从 201 开始，即下一个报文段的序号字段值应为 201。（seq=201）

  

• 确认号 ack（注意大小写）

  • 期望收到对方下一个报文段的第一个数据字节的序号。
  • 若确认号为ack=N，则表明：到序号 N-1 为止的所有数据都已正确收到。

TCP标志位解释

在TCP（Transmission Control Protocol）数据报文首部中，控制位部分包含6个标志位，这些标志位用于控制TCP的连接建立、数据传输和连接关闭等操作，以下是对每个标志位的详细解释：

SYN（Synchronize sequence numbers）：同步标志

• 作用：主要用于在建立TCP连接时同步序列号。在TCP三次握手的第一次和第二次握手中会使用到该标志位。
• 具体过程：客户端向服务器发起连接请求时，会将SYN标志位置为1，并随机选择一个初始序列号（ISN）发送给服务器。服务器收到该请求后，在第二次握手时也会将SYN标志位置为1，同时选择自己的初始序列号，并向客户端发送确认信息。通过这种方式，双方就序列号达成一致，为后续的数据传输做好准备。

ACK（Acknowledgment field significant）：确认标志

• 作用：用于确认收到的数据。当ACK标志位置为1时，表示确认号字段有效，接收方通过确认号告知发送方自己已经成功接收了哪些数据，并期望接收的下一个数据的序列号。
• 具体过程：在TCP三次握手的第二次和第三次握手中，ACK标志位都会被置为1。在数据传输过程中，接收方每收到一个有效的数据报文段，都会发送一个带有ACK标志位的确认报文给发送方，确认号为已接收数据的下一个字节的序列号。例如，如果接收方成功接收了序列号为1 - 100的字节数据，那么它发送的确认报文中的确认号将为101，表示期望接下来收到序列号为101的数据。

FIN（No more data from sender）：结束标志

• 作用：用于表示发送方已经没有数据要发送，请求关闭连接。在TCP四次挥手的过程中会使用到该标志位。
• 具体过程：当一方想要关闭连接时，会将FIN标志位置为1，并发送给对方。对方收到FIN报文后，会发送一个带有ACK标志位的确认报文进行响应，表示同意关闭连接。然后，对方如果也没有数据要发送了，也会发送一个带有FIN标志位的报文给发起关闭请求的一方，发起方再发送一个ACK报文进行确认，至此连接关闭。

RST（Reset the connection）：复位标志

• 作用：用于异常情况下强制关闭连接。当接收方收到一个不符合当前连接状态的报文或者检测到连接出现严重错误时，会发送一个带有RST标志位的报文来重置连接。
• 具体场景：例如，当客户端向一个不存在的端口发送连接请求时，服务器会返回一个带有RST标志位的报文，告诉客户端该连接无法建立；或者在连接过程中，如果一方检测到对方的行为异常，如违反协议规则，也可以发送RST报文来终止连接。

PSH（Push function）：推送标志

• 作用：提示接收方应尽快将数据交付给应用程序，而不是等到缓冲区满。通常在应用程序需要立即处理数据时使用。
• 具体场景：例如，当用户在终端上输入命令并按下回车键时，客户端会将PSH标志位置为1，请求服务器尽快处理该命令，而不是等待更多的数据填满缓冲区后再处理。这样可以减少数据在网络层和传输层的延迟，提高应用程序的响应速度。

URG（Urgent Pointer field significant）：紧急指针标志

• 作用：表示紧急指针字段有效。当URG标志位置为1时，紧急指针字段指出本报文段中紧急数据的最后一个字节的序号相对于序列号字段的偏移量。
• 具体场景：用于处理一些需要紧急处理的数据，如在文件传输过程中，如果需要中断当前的传输任务，可以发送一个带有URG标志位的报文，并在紧急指针中指定中断命令的位置，接收方在收到该报文后会优先处理紧急数据。

详解tcp握手、挥手

TCP（传输控制协议）是一种面向连接的、可靠的传输层协议，握手和挥手是TCP建立和关闭连接的重要过程，以下为你详细介绍：

TCP三次握手（建立连接）

TCP三次握手的目的是在客户端和服务器之间建立可靠的连接，并同步双方的初始序列号，为后续的数据传输做好准备。

第一次握手：客户端发送SYN包

• 动作：客户端向服务器发送一个TCP段，其中SYN（同步）标志位置为1，表示这是一个连接请求。同时，客户端会随机选择一个初始序列号（ISN），假设为x，并将其放在序列号字段中。
• 含义：客户端主动发起连接请求，告知服务器自己希望建立连接，并给出自己后续发送数据的起始序列号。

第二次握手：服务器发送SYN + ACK包

• 动作：服务器接收到客户端的SYN包后，如果同意建立连接，会为该连接分配资源。服务器会发送一个TCP段，其中SYN和ACK（确认）标志位都置为1。服务器也会随机选择一个自己的初始序列号，假设为y，放在序列号字段中；同时，确认号字段的值设置为客户端的初始序列号x加1（即x + 1），表示服务器已经收到客户端的连接请求，并期望客户端下一个发送的数据序列号是x + 1。
• 含义：服务器回应客户端，表示同意建立连接，同时告知客户端自己后续发送数据的起始序列号，并确认收到了客户端的请求。

第三次握手：客户端发送ACK包

• 动作：客户端收到服务器的SYN + ACK包后，会发送一个TCP段，其中ACK标志位置为1。确认号字段的值设置为服务器的初始序列号y加1（即y + 1），表示客户端已经收到服务器的同意连接信息，并期望服务器下一个发送的数据序列号是y + 1。同时，客户端发送的数据序列号为x + 1。
• 含义：客户端确认收到服务器的同意连接信息，并且告知服务器自己已经做好接收服务器数据的准备，此时连接正式建立。

TCP四次挥手（关闭连接）

TCP四次挥手用于在数据传输结束后，客户端和服务器双方有序地关闭连接。

第一次挥手：客户端发送FIN包

• 动作：客户端完成数据发送后，向服务器发送一个TCP段，其中FIN（结束）标志位置为1，表示客户端已经没有数据要发送了，请求关闭连接。同时，客户端会将当前的序列号u放在序列号字段中。
• 含义：客户端主动发起关闭连接的请求。

第二次挥手：服务器发送ACK包

• 动作：服务器收到客户端的FIN包后，会发送一个TCP段，其中ACK标志位置为1。确认号字段的值设置为客户端的序列号u加1（即u + 1），表示服务器已经收到客户端的关闭请求，并同意关闭客户端到服务器方向的连接。服务器的序列号为v。
• 含义：服务器确认收到客户端的关闭请求，但此时服务器可能还有数据要发送给客户端，所以只是先同意关闭客户端到服务器的单向连接。

第三次挥手：服务器发送FIN包

• 动作：当服务器完成数据发送后，会向客户端发送一个TCP段，其中FIN标志位置为1，表示服务器也没有数据要发送了，请求关闭连接。同时，服务器会将当前的序列号v放在序列号字段中。
• 含义：服务器主动发起关闭自己到客户端方向连接的请求。

第四次挥手：客户端发送ACK包

• 动作：客户端收到服务器的FIN包后，会发送一个TCP段，其中ACK标志位置为1。确认号字段的值设置为服务器的序列号v加1（即v + 1），表示客户端已经收到服务器的关闭请求，并同意关闭服务器到客户端方向的连接。客户端的序列号为u + 1。
• 含义：客户端确认收到服务器的关闭请求，至此，双方的连接全部关闭。客户端在发送完ACK包后，会等待一段时间（通常是2倍的最大段生存期，即2MSL），以确保服务器能够收到这个确认信息，防止因ACK包丢失导致服务器重发FIN包。

图解三次握手(真理)

三次握手的原文是 three-way handshake，整个名词的可以翻译为：需要三个步骤才能建立握手/连接的机制。当然，三次握手也可以叫 three-message handshake，通过三条消息来建立的握手/连接。

进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的 初始化序列号(Init Sequense Number, ISN) 为后面的可靠性传输做准备。

三次握手过程如下图：

抓包查看三次握手（真理）

鼎鼎大名的tcp/ip协议的三次握手、也就是关乎于syn、syn/ack、ack三个标识位

tcp是一个及其复杂的知识点，这里咱们通过wireshare来尽量的通过实践，理解tcp的序列号和确认号的关系。

TCP协议正在报文中使用了大量的标志位来控制tcp的连接状态；

最主要的三个标志位如下

• SYN、创建一个连接
• FIN、终止一个连接
• ACK、确认接收到了数据

第一次握手（SYN）

打开tcp层的数据包信息，展开TCP的标志位区域（flag），可以看到tcp用到的所有标志位。

第二次握手（SYN、ACK）

往下看

第三次握手（ACK）

TCP/IP四次挥手

数据传输完毕后，双方都可释放连接。

最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

抓包查看四次挥手

1.FIN、

2.ACK、

3.FIN

4.ACK

TCP连接状态报文

面试时候拿出来背诵即可

CLOSE 没有任何连接状态
LISTEN 监听状态、等待来自TCP的连接请求
SYN-SENT 发送连接请求后，等待对方确认
SYN-RECEIVED 收到、发送一个连接请求后，等待对方确认
ESTABLISHED   代表传输连接已经建立，双方进入数据传输状态
FIN-WAIT-1         主动关闭1，主机已发送关闭连接请求，等待对方确认
FIN-WAIT-2        主动关闭2，主机已收到对方关闭传输连接的确认，等待对方发送关闭传输连接请求

TIME-WAIT 完成双向传输连接关闭，等待服务端最终确认
CLOSE-WAIT 被动关闭连接，收到对方发来的关闭连接请求，且已经确认。
LAST-ACK  被动关闭，等待最后一个关闭传输连接的确认。
CLOSE        双方同时确认了关闭传输连接

常用端口号

端口号是计算机网络中用于区分不同应用程序或服务的标识。

饭店

银行

办事大厅。分窗口，分业务。具体的定位，场所。几号窗口办理xx业务。

有人来，有人走，人流量。

服务器，对外提供访问服务。公网IP地址，对外提供软件服务器。网站80，数据库。远程ssh链接22。

范围从 0 到 65535，其中 0 到 1023 被称为知名端口，通常由系统保留给一些常见的标准服务使用。以下为你介绍一些常用的端口号及其对应的服务：

应用层协议,相关端口

HTTP（超文本传输协议）

• 端口号：80 ,nginx
• 说明：是用于在 Web 浏览器和 Web 服务器之间传输超文本（如 HTML 页面）的协议。当你在浏览器中输入一个网址（如 http://www.example.com），默认会通过 80 端口与服务器建立连接并获取网页内容。

HTTPS（超文本传输安全协议）

• 端口号：443
• 说明：是 HTTP 协议的安全版本，通过使用 SSL/TLS 加密协议对数据进行加密传输，确保数据在传输过程中的安全性和完整性。现在大多数网站都采用 HTTPS 协议，以保护用户的隐私和数据安全。

FTP（文件传输协议）

• 端口号：20 和 21
• 说明：用于在客户端和服务器之间进行文件的上传和下载。其中，21 端口用于控制连接，客户端通过该端口与服务器建立连接并发送控制命令（如登录、列出文件目录等）；20 端口用于数据连接，在进行文件传输时使用。

SMTP（简单邮件传输协议）

• 端口号：25（非加密）、587（加密）
• 说明：主要用于发送电子邮件。邮件客户端（如 Outlook、Foxmail 等）通过该端口将邮件发送到邮件服务器，邮件服务器之间也使用 SMTP 协议进行邮件的转发。

POP3（邮局协议版本 3）

• 端口号：110（非加密）、995（加密）
• 说明：用于邮件客户端从邮件服务器接收电子邮件。当你设置邮件客户端接收邮件时，通常会配置 POP3 服务器地址和端口号。

IMAP（互联网消息访问协议）

• 端口号：143（非加密）、993（加密）
• 说明：也是用于邮件客户端从邮件服务器接收电子邮件的协议，但与 POP3 不同的是，IMAP 允许客户端在服务器上管理邮件，而不仅仅是下载邮件。

传输层协议相关端口

SSH（安全外壳协议）

• 端口号：22
• 说明：用于在不安全的网络中安全地远程登录和执行命令。通过 SSH 协议，用户可以在本地计算机上通过网络连接到远程服务器，并在远程服务器上执行各种操作，如文件管理、系统配置等。

Telnet

• 端口号：23
• 说明：是一种用于远程登录的协议，但由于它以明文形式传输数据，安全性较低，现在已经逐渐被 SSH 协议取代。

数据库相关端口

MySQL

• 端口号：3306
• 说明：是一种广泛使用的开源关系型数据库管理系统。客户端通过 3306 端口与 MySQL 服务器建立连接，进行数据库的查询、插入、更新等操作。

PostgreSQL

• 端口号：5432
• 说明：也是一种流行的开源关系型数据库管理系统，客户端使用 5432 端口与 PostgreSQL 服务器进行通信。

Redis

• 端口号：6379
• 说明：是一个开源的内存数据结构存储系统，常用于缓存、消息队列等场景。客户端通过 6379 端口与 Redis 服务器进行交互。

TCP与套接字(socket)

TCP（传输控制协议）和套接字（socket）在计算机网络通信中都扮演着关键角色，下面将从它们各自的概念、两者的关系以及使用示例等方面进行详细介绍。

概念

TCP

TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。它主要负责在网络中的两个应用程序之间建立可靠的数据传输通道。其显著特点包括：

• 面向连接：在进行数据传输之前，需要通过“三次握手”建立连接syn ack；数据传输完成后，通过“四次挥手”fin关闭连接，确保数据传输的有序性。seq序号。
• 可靠传输：采用确认机制、重传机制、滑动窗口机制等，保证数据在传输过程中不丢失、不重复且按序到达。
• 字节流传输：将应用层的数据看作无结构的字节流进行传输，会对数据进行分段和重组。

套接字（socket）

套接字是一种网络编程接口，它提供了应用程序与网络协议栈之间的编程接口，使得应用程序能够通过网络进行通信。套接字可以基于不同的传输层协议（如TCP或UDP）来实现不同类型的网络通信。它就像是应用程序与网络之间的“插座”，通过它应用程序可以方便地接入网络并进行数据交换。

TCP与套接字的关系

• 套接字基于TCP实现可靠通信：当使用TCP协议进行网络通信时，通常会使用套接字来创建、管理和操作TCP连接。套接字提供了一系列的函数和方法，允许开发者利用TCP的特性来实现可靠的数据传输。例如，在服务器端和客户端分别创建套接字，通过套接字进行连接的建立、数据的发送和接收等操作。
• 套接字抽象了TCP操作细节：对于开发者来说，套接字将TCP协议的底层操作细节进行了抽象和封装。开发者不需要深入了解TCP协议的“三次握手”“四次挥手”、确认机制等复杂的实现细节，只需要调用套接字提供的接口函数，就可以轻松实现基于TCP的网络通信。

使用示例（Python）

以下是一个简单的基于TCP套接字的客户端 - 服务器通信示例：

服务器端代码

# 导入python对底层网络驱动的加载，网卡，mac地址等。数据如何封装。
# 程序开发网站，地基中的一部分。
# 写代码，盖好的地基上，盖楼，盖应用，场所。
# 打地基，冲头，底层原理，c c++
# 成熟的框架，靠谱？
import socket

# 创建一个TCP套接字
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# 绑定IP地址和端口号
server_address = ('127.0.0.1', 8888)
server_socket.bind(server_address)

# 开始监听连接
server_socket.listen(1)
print('Waiting for a connection...')

# 接受客户端连接
client_socket, client_address = server_socket.accept() # for循环
print(f'Connected to {client_address}')

# 接收客户端消息
data = client_socket.recv(1024)
print(f'Received: {data.decode()}')

# 发送响应消息给客户端
message = 'Hello, client! I received your message.'
client_socket.sendall(message.encode())

# 关闭连接
client_socket.close()
server_socket.close()

客户端代码

import socket

# 创建一个TCP套接字
client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# 服务器的IP地址和端口号
server_address = ('10.211.55.10', 8888)

# 连接到服务器
client_socket.connect(server_address)

# 发送消息给服务器，转为字节码，网络传输
message = 'Hello, server! This is a test message.'
client_socket.sendall(message.encode())

# 接收服务器的响应
data = client_socket.recv(1024)
print(f'Received from server: {data.decode()}')

# 关闭连接
client_socket.close()

代码解释

• 服务器端：首先创建一个TCP套接字，绑定到指定的IP地址和端口号，然后开始监听客户端的连接请求。当有客户端连接时，接受连接并接收客户端发送的数据，最后发送响应消息并关闭连接。
• 客户端：创建一个TCP套接字，连接到服务器的指定地址和端口，发送消息给服务器，接收服务器的响应，最后关闭连接。

通过前面对OSI网络模型的学习，我们知道了在网络层中可以通过IP地址实现两个机器之间的通信。

但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。

为什么必须是TCP/IP俩协议的结合？

因为

IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。

而端到端的通信才应该是应用进程之间的通信，也就是port对port。

因此必须是tcp+ip协议的组合，才是一个可用的连接。

TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种端点我们叫作套接字（socket），它的定义为端口号拼接到IP地址即构成了套接字

例如，若IP地址为192.3.4.16 而端口号为80，那么得到的套接字为192.3.4.16:80

网络套接字的应用

网络套接字（Socket）作为网络编程的关键接口，在众多领域都有广泛应用，它为不同设备上的应用程序提供了便捷的网络通信方式。以下为你详细介绍其常见应用场景：

Web服务器与客户端通信

• 原理：Web服务器使用套接字监听特定端口（如HTTP的80端口、HTTPS的443端口），等待客户端（如浏览器）的连接请求。客户端通过创建套接字并连接到服务器的指定地址和端口，与服务器建立TCP连接，然后发送HTTP请求。服务器接收到请求后，处理请求并通过套接字返回HTTP响应给客户端。
• 示例：当你在浏览器中输入一个网址并回车，浏览器会创建一个套接字，向对应的Web服务器发送HTTP请求。服务器端的Web服务程序（如Nginx、Apache）使用套接字监听端口，接收到请求后，根据请求内容从文件系统或数据库中获取相应的网页资源，并将其封装成HTTP响应通过套接字返回给浏览器，浏览器再将网页内容解析并显示给用户。

即时通讯应用

• 原理：即时通讯应用（如QQ、微信等）的服务器端使用套接字监听客户端的连接，客户端通过套接字与服务器建立连接。当用户发送消息时，客户端将消息封装成特定的格式，通过套接字发送给服务器，服务器再将消息转发给目标客户端。
• 示例：在一个简单的即时通讯系统中，客户端A和客户端B都与服务器建立了套接字连接。当客户端A发送一条消息给客户端B时，客户端A将消息通过其套接字发送给服务器，服务器接收到消息后，根据消息中的目标信息，通过与客户端B的套接字连接将消息转发给客户端B。

文件传输

• 原理：文件传输协议（如FTP、SFTP）利用套接字实现文件在客户端和服务器之间的传输。服务器端使用套接字监听特定端口，等待客户端的连接请求。客户端通过套接字连接到服务器，然后可以发送上传或下载文件的请求，服务器根据请求进行相应的文件操作，并通过套接字将文件数据传输给客户端或接收客户端上传的文件数据。
• 示例：在使用FTP进行文件下载时，客户端通过套接字与FTP服务器建立连接，发送登录信息进行身份验证。验证通过后，客户端发送下载文件的请求，服务器通过套接字将文件数据逐块发送给客户端，客户端接收到数据后将其保存到本地文件系统中。

网络游戏

• 原理：网络游戏的服务器端使用套接字监听多个客户端的连接，客户端通过套接字与服务器建立连接。在游戏过程中，客户端和服务器之间通过套接字实时交换游戏数据，如玩家的位置、动作、状态等信息，以保证游戏的同步性和实时性。
• 示例：在一个多人在线角色扮演游戏中，每个玩家的客户端都通过套接字与游戏服务器建立连接。当玩家移动角色时，客户端将角色的移动信息通过套接字发送给服务器，服务器接收到信息后更新游戏世界中该玩家的位置，并将更新后的信息通过套接字广播给其他相关的客户端，使其他玩家能够看到该玩家的移动。

远程管理与控制

• 原理：通过套接字可以实现远程管理和控制功能。服务器端在远程设备上运行，监听特定端口，等待客户端的连接请求。客户端通过套接字连接到服务器，发送控制命令，服务器接收到命令后执行相应的操作，并将操作结果通过套接字返回给客户端。
• 示例：使用SSH（安全外壳协议）进行远程服务器管理时，客户端通过创建套接字并连接到服务器的SSH端口（默认22），与服务器建立安全的加密连接。客户端可以在本地终端输入命令，通过套接字将命令发送给服务器，服务器执行命令并将结果通过套接字返回给客户端，客户端在本地终端显示执行结果。

上面说了socket套接字，就是ip+port，具体的表现为如

mysql服务的运行

172.16.1.51:3306

nginx服务的运行

172.16.1.7:80

本地套接字的应用

本地套接字（Unix Domain Socket）是在同一台主机上进行进程间通信（IPC）的一种机制，与网络套接字不同，它不涉及网络协议栈，而是直接在操作系统内核中进行数据传输，因此具有更高的性能和安全性。以下是本地套接字的一些常见应用场景：

数据库服务器与客户端通信

• 原理：许多数据库管理系统（如 PostgreSQL、MySQL 在某些配置下）会使用本地套接字来实现服务器和客户端之间的通信。客户端进程通过本地套接字连接到数据库服务器进程，发送 SQL 查询语句，服务器进程接收并处理这些查询，然后将结果通过本地套接字返回给客户端。
• 优势：相比于通过网络套接字进行通信，本地套接字避免了网络传输的开销，提高了数据传输的速度和效率，同时也减少了网络延迟和潜在的安全风险。
• 示例：在使用 PostgreSQL 数据库时，客户端可以通过指定本地套接字文件的路径来连接到数据库服务器，而不是通过网络地址和端口。这样可以在同一台服务器上快速、安全地进行数据库操作。

系统服务间通信

• 原理：在操作系统中，不同的系统服务进程之间可能需要进行数据交换和协同工作。本地套接字提供了一种高效的方式来实现这些服务之间的通信。例如，一个系统监控服务可能需要与日志记录服务进行通信，将监控到的系统信息发送给日志记录服务进行存储。
• 优势：使用本地套接字可以确保服务之间的通信是可靠的，并且由于数据不经过网络传输，减少了数据被篡改或泄露的风险。同时，本地套接字的通信速度快，能够满足系统服务之间实时数据交换的需求。
• 示例：在 Linux 系统中，一些守护进程（如 systemd 服务）之间可能会使用本地套接字进行通信，以协调系统资源的管理和任务的执行。

图形界面程序与后台服务交互

• 原理：图形界面（GUI）程序通常需要与后台服务进行交互，以获取数据或执行一些耗时的任务。本地套接字可以作为它们之间的通信桥梁。例如，一个图形化的文件管理器程序可能需要与一个文件索引服务进行通信，以获取文件的详细信息。
• 优势：通过本地套接字，GUI 程序可以快速地与后台服务进行数据交换，而不会影响用户界面的响应性能。同时，本地套接字的使用使得 GUI 程序和后台服务可以独立开发和部署，提高了系统的可维护性和可扩展性。
• 示例：在一个图像编辑软件中，GUI 界面可能通过本地套接字与一个图像渲染服务进行通信，将用户的编辑操作传递给渲染服务，渲染服务处理后将渲染结果返回给 GUI 界面进行显示。

容器内部进程通信

• 原理：在容器化环境（如 Docker 容器）中，容器内部的不同进程之间可能需要进行通信。本地套接字可以用于实现容器内部的进程间通信，而无需暴露到容器外部的网络中。
• 优势：使用本地套接字可以提高容器内部通信的安全性和性能，因为数据不会通过容器的网络接口进行传输，减少了网络开销和潜在的安全漏洞。同时，本地套接字的使用符合容器的隔离性原则，使得容器内部的通信更加独立和可控。
• 示例：在一个 Docker 容器中运行的 Web 应用程序可能需要与一个数据库服务进行通信，它们可以通过本地套接字在容器内部建立连接，而不需要配置复杂的网络设置。

部署一些应用，如django也可以设置为本地socket套接字文件形式，而非ip+port的网络socket形式。这个以后学习nginx部署再说。

总之、socket都是能够具体定位到一个应用进程，获取数据。

例如mysql服务端的启动，有两种方式形式

1.远程的通过网络连接TCP/IP  ，进行 如123.206.16.61:3306访问

2.本地进程连接，比TCP更快，使用unix domain socket作为通信载体。

这个等学习mysql时候，于超老师再进行讲解。本次理解概念即可。

至此，关于网络连接的TCP原理结束，往下就是HTTP应用层的协议了。

HTTP协议。

HTTP协议简介

HTTP（Hypertext Transfer Protocol）即超文本传输协议，是用于在互联网上传输超文本的协议，它是万维网数据通信的基础，以下从协议概述、发展历程、协议特点、报文格式、工作流程等方面进行详细介绍：

协议概述

HTTP是一种应用层协议，主要用于在客户端（如浏览器）和服务器之间传输超文本数据，如HTML页面、图片、JSON数据等。它基于请求 - 响应模型，客户端向服务器发送请求，服务器接收到请求后进行处理，并返回相应的响应结果。

发展历程

• HTTP/0.9：最早的HTTP版本，功能非常简单，仅支持GET请求，用于传输纯文本的HTML页面。
• HTTP/1.0：引入了状态码、请求头和响应头，支持多种请求方法（如GET、POST等），并可以传输不同类型的数据（通过Content-Type头指定）。
• HTTP/1.1：是目前广泛使用的版本，在HTTP/1.0的基础上进行了许多改进，如支持持久连接（Keep - Alive）、分块传输编码、请求头压缩等，提高了传输效率和性能。
• HTTP/2：采用了二进制分帧、多路复用、头部压缩等新技术，进一步提高了传输性能和效率，减少了延迟。
• HTTP/3：基于QUIC协议，旨在解决HTTP/2在某些网络条件下的性能问题，提供更快、更可靠的传输。

协议特点

• 无状态：HTTP协议本身是无状态的，即服务器不会记录客户端的任何信息。每次请求都是独立的，服务器处理请求时不会考虑之前的请求。这使得服务器的处理更加简单和高效，但也带来了一些问题，如在需要保持用户会话状态的场景下，需要使用额外的技术（如Cookie、Session）来实现。
• 无连接：在HTTP/1.0及之前的版本中，每次请求都会建立一个新的TCP连接，请求处理完成后立即关闭连接。这种方式虽然简单，但会带来较大的开销。HTTP/1.1引入了持久连接，允许在同一个TCP连接上进行多次请求和响应，减少了连接建立和关闭的开销。
• 简单快速：HTTP协议的请求和响应格式简单，易于理解和实现。客户端只需要发送一个简单的请求行和请求头，服务器就可以快速处理并返回响应。这使得HTTP在互联网上得到了广泛的应用。
• 灵活：HTTP协议支持传输多种类型的数据，通过请求头和响应头中的Content - Type字段，可以指定传输的数据类型，如HTML、JSON、XML、图片等。

报文格式

请求报文

• 请求行：包含请求方法（如GET、POST等）、请求的资源路径和HTTP协议版本，例如：GET /index.html HTTP/1.1。
• 请求头：包含一些关于请求的附加信息，如用户代理（User - Agent）、接受的内容类型（Accept）、缓存控制（Cache - Control）等，每个请求头由字段名和字段值组成，中间用冒号分隔，例如：User - Agent: Mozilla/5.0。
• 空行：用于分隔请求头和请求体。
• 请求体：可选部分，用于携带请求的数据，如POST请求中提交的表单数据或JSON数据。

响应报文

• 响应行：包含HTTP协议版本、状态码和状态描述，例如：HTTP/1.1 200 OK。
• 响应头：包含一些关于响应的附加信息，如响应的内容类型（Content - Type）、内容长度（Content - Length）、缓存策略（Cache - Control）等。
• 空行：用于分隔响应头和响应体。
• 响应体：包含服务器返回给客户端的实际数据，如HTML页面内容、图片数据等。

工作流程

• 客户端发起请求：客户端（如浏览器）根据用户的操作（如输入网址、点击链接等）构造HTTP请求报文，并通过TCP连接发送给服务器。
• 服务器处理请求：服务器接收到客户端的请求报文后，解析请求行、请求头和请求体，根据请求的内容进行相应的处理。这可能包括从文件系统中读取文件、执行数据库查询、调用服务器端脚本等。
• 服务器返回响应：服务器处理完请求后，构造HTTP响应报文，包含响应行、响应头和响应体，并通过TCP连接返回给客户端。
• 客户端处理响应：客户端接收到服务器的响应报文后，解析响应行、响应头和响应体，根据响应的内容进行相应的处理。如果响应的内容是HTML页面，浏览器会对HTML代码进行解析和渲染，将页面展示给用户。

HTTP协议概述

HTTP是一个客户端终端（用户）和服务器端（网站）请求和应答的标准（TCP）。

• 通过使用网页浏览器、网络爬虫或者其它的工具，客户端发起一个HTTP请求到服务器上指定端口（默认端口为80）。

• 我们称这个客户端为用户代理程序（user agent）。

• 应答的服务器上存储着一些资源，比如HTML文件和图像。我们称这个应答服务器为源服务器（origin server）。

• 在用户代理和源服务器中间可能存在多个“中间层”，比如代理服务器、网关或者隧道（tunnel）。

• 通常，由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的TCP连接。
• HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息。

HTTP工作原理

HTTP（Hypertext Transfer Protocol）是用于在互联网上传输超文本的应用层协议，其工作原理基于请求 - 响应模型，以下将详细阐述其具体的工作流程：

1. DNS解析

当用户在浏览器中输入一个网址（如 www.example.com）并回车后，浏览器首先需要将域名解析为对应的IP地址，因为计算机在网络中是通过IP地址来识别和定位其他设备的。

• 浏览器会先检查本地的DNS缓存（包括浏览器缓存、操作系统缓存），看是否已经有该域名对应的IP地址记录。
• 如果本地缓存中没有找到对应的IP地址，浏览器会向本地DNS服务器发送DNS查询请求。本地DNS服务器通常由用户的网络服务提供商（ISP）提供。
• 若本地DNS服务器也没有该域名的记录，它会根据配置，向根DNS服务器、顶级域名DNS服务器和权威DNS服务器依次进行查询，最终获取到该域名对应的IP地址，并将结果返回给浏览器。

2. TCP连接建立

获取到服务器的IP地址后，浏览器会通过TCP协议与服务器建立连接。TCP是一种面向连接的、可靠的传输协议，它通过“三次握手”来建立连接：

• 客户端发送SYN包：浏览器（客户端）向服务器发送一个TCP段，其中SYN（同步）标志位置为1，表示这是一个连接请求。同时，客户端会随机选择一个初始序列号（ISN），并将其放在序列号字段中。
• 服务器发送SYN + ACK包：服务器接收到客户端的SYN包后，如果同意建立连接，会为该连接分配资源。服务器会发送一个TCP段，其中SYN和ACK（确认）标志位都置为1。服务器也会随机选择一个自己的初始序列号，并将客户端的初始序列号加1作为确认号，表示服务器已经收到客户端的连接请求，并期望客户端下一个发送的数据序列号是该确认号。
• 客户端发送ACK包：客户端收到服务器的SYN + ACK包后，会发送一个TCP段，其中ACK标志位置为1，确认号为服务器的初始序列号加1，表示客户端已经收到服务器的同意连接信息，并期望服务器下一个发送的数据序列号是该确认号。至此，TCP连接建立成功。

3. HTTP请求发送

连接建立后，浏览器会根据用户的操作（如访问网页、点击链接等）构造一个HTTP请求报文，并通过建立好的TCP连接发送给服务器。HTTP请求报文由三部分组成：

• 请求行：包含请求方法（如GET、POST等）、请求的资源路径和HTTP协议版本。例如：GET /index.html HTTP/1.1 表示使用GET方法请求服务器上的 index.html 文件。
• 请求头：包含一些关于请求的附加信息，如浏览器类型、接受的内容类型、字符编码等。例如：User - Agent: Mozilla/5.0 表示浏览器的类型和版本。
• 请求体：可选部分，对于一些需要向服务器提交数据的请求（如POST请求），请求体中会包含具体的数据内容，如表单数据、JSON数据等。

4. 服务器处理请求

服务器接收到客户端的HTTP请求后，会对请求进行解析和处理：

• 解析请求：服务器首先会解析HTTP请求报文，提取请求行、请求头和请求体中的信息，确定请求的方法、资源路径和数据内容。
• 验证请求：服务器会对请求进行合法性验证，检查请求的格式是否正确、请求的资源是否存在、客户端是否有访问该资源的权限等。例如，如果请求的资源不存在，服务器可能会返回一个404状态码。
• 处理业务逻辑：如果请求合法，服务器会根据请求的资源路径和请求方法，调用相应的程序或脚本进行业务逻辑处理。例如，如果请求的是一个动态网页，服务器可能会执行相应的服务器端脚本（如PHP、Python Flask等），从数据库中获取数据并生成HTML页面。

5. HTTP响应返回

服务器处理完请求后，会构造一个HTTP响应报文并通过TCP连接返回给客户端。HTTP响应报文也由三部分组成：

• 响应行：包含HTTP协议版本、状态码和状态描述。例如：HTTP/1.1 200 OK 表示请求成功，服务器可以正常返回资源。常见的状态码还有404（未找到资源）、500（服务器内部错误）等。
• 响应头：包含一些关于响应的附加信息，如响应的内容类型、字符编码、缓存策略等。例如：Content - Type: text/html; charset=UTF - 8 表示响应的内容类型是HTML，字符编码为UTF - 8。
• 响应体：包含服务器返回给客户端的实际数据内容，如HTML页面、图片、JSON数据等。

6. 客户端处理响应

浏览器接收到服务器的HTTP响应后，会根据响应头中的信息对响应体进行处理：

• 解析HTML：如果响应的内容类型是HTML，浏览器会对HTML代码进行解析，构建DOM（文档对象模型）树。
• 加载资源：在解析HTML的过程中，浏览器会发现其中引用的外部资源（如CSS文件、JavaScript文件、图片等），并根据这些资源的URL再次发起HTTP请求，重复上述的DNS解析、TCP连接和HTTP请求响应过程，获取这些资源。
• 渲染页面：当所有的HTML、CSS和JavaScript资源都加载完成后，浏览器会根据DOM树和CSS样式规则进行页面渲染，将页面展示给用户。

7. TCP连接关闭

当浏览器和服务器完成数据交互后，双方会关闭TCP连接。TCP连接的关闭通过“四次挥手”来实现：

• 客户端发送FIN包：客户端向服务器发送一个TCP段，其中FIN（结束）标志位置为1，表示客户端已经没有数据要发送了，请求关闭连接。
• 服务器发送ACK包：服务器收到客户端的FIN包后，会发送一个TCP段，其中ACK标志位置为1，表示服务器已经收到客户端的关闭请求，并同意关闭客户端到服务器方向的连接。
• 服务器发送FIN包：当服务器也没有数据要发送时，会向客户端发送一个TCP段，其中FIN标志位置为1，表示服务器也请求关闭连接。
• 客户端发送ACK包：客户端收到服务器的FIN包后，会发送一个TCP段，其中ACK标志位置为1，表示客户端已经收到服务器的关闭请求，并同意关闭服务器到客户端方向的连接。至此，TCP连接正式关闭。

需要注意的是，现代的HTTP协议（如HTTP/1.1和HTTP/2）支持持久连接，允许在同一个TCP连接上进行多次请求和响应，以提高效率，减少连接建立和关闭的开销。

HTTP 请求/响应的步骤

1. 客户端连接到Web服务器
一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.yuchaoit.cn

2. 发送HTTP请求
通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

3. 服务器接受请求并返回HTTP响应
10.21.55.10/index.html

Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。


4. 客户端浏览器解析HTML内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。
客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

5. 释放连接TCP连接
若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：

1. 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
2. 解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
3. 浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
4. 服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
5. 浏览器将该 html 文本并显示内容; 　
6. 释放 TCP连接;

总结

http协议是基于TCP/IP协议之上的应用层协议。

请求-响应的模式

HTTP协议规定,请求从客户端发出,最后服务器端响应该请求并 返回。

换句话说,肯定是先从客户端开始建立通信的,服务器端在没有接收到请求之前不会发送响应

HTTP无状态

HTTP（Hypertext Transfer Protocol）无状态是该协议的一个重要特性，下面从含义、优缺点、解决方案几个方面进行详细介绍：

含义

无状态指的是HTTP协议对于事务处理没有记忆能力，服务器不会记录客户端的任何信息。每次HTTP请求都是独立的，服务器处理请求时不会考虑之前的请求情况，也不会在不同请求之间保留用户的上下文信息。

例如，当你在浏览器中访问一个网站的多个页面时，对于服务器来说，每个页面的请求都是全新的，服务器不会知道你之前访问过哪些页面，也不清楚你在访问过程中的操作状态。即使你在短时间内连续向服务器发送多个请求，服务器也会将它们视为互不相关的独立事件进行处理。

优点

• 简单高效：由于服务器不需要记录客户端的状态信息，处理请求时无需维护复杂的状态数据，这使得服务器的设计和实现更加简单。服务器可以专注于当前请求的处理，减少了额外的开销，提高了处理请求的速度和效率，能够快速响应大量并发请求。
• 可扩展性强：无状态特性使得HTTP服务器更容易进行扩展。因为每个请求都是独立的，服务器可以很方便地进行分布式部署，将请求分发到不同的服务器节点上进行处理，而不需要考虑不同节点之间的状态同步问题。这样可以轻松应对高流量和大规模的访问需求。
• 易于缓存：无状态的请求更容易进行缓存。由于每个请求的结果不依赖于之前的请求状态，缓存系统可以根据请求的URL、请求方法等信息直接对响应结果进行缓存。当有相同的请求再次到来时，可以直接从缓存中获取响应，而无需再次向服务器发起请求，从而提高了系统的性能和响应速度。

缺点

• 缺乏上下文信息：在一些需要保持用户会话状态的场景下，HTTP的无状态特性会带来不便。例如，在电子商务网站中，用户将商品添加到购物车后，服务器需要知道用户的购物车状态，以便后续处理订单。但由于HTTP无状态，服务器无法自动记住用户的购物车信息，这就需要额外的机制来实现会话管理。
• 增加交互复杂度：为了实现一些需要状态保持的功能，开发者需要在应用层添加额外的逻辑和机制，这增加了开发的复杂度。例如，需要使用Cookie、Session等技术来跟踪用户的会话状态，处理这些技术的细节和安全问题需要花费更多的精力。

解决方案

• Cookie：Cookie是服务器发送到用户浏览器并保存在本地的一小块数据。它可以在客户端和服务器之间传递，服务器可以通过读取Cookie中的信息来识别用户和跟踪会话状态。例如，当用户登录网站时，服务器会生成一个包含用户标识的Cookie并发送给客户端，客户端在后续的请求中会自动携带这个Cookie，服务器通过解析Cookie就可以知道是哪个用户在发起请求。
• Session：Session是一种服务器端的会话管理机制。当用户访问网站时，服务器会为每个用户创建一个唯一的Session ID，并将其发送给客户端（通常通过Cookie）。服务器会在内存或数据库中保存与该Session ID对应的会话数据，客户端在后续请求中携带Session ID，服务器根据Session ID查找并更新相应的会话数据，从而实现状态的保持。
• URL重写：URL重写是将会话信息附加到URL后面，作为请求参数传递。当用户点击链接或提交表单时，URL中会包含会话标识，服务器可以从URL中提取会话信息来识别用户。这种方法适用于不支持Cookie的情况，但会使URL变得冗长，且安全性相对较低。

这种无状态设计是为了保证HTTP可以处理大量的请求响应；

cookie

Cookie是在Web应用中用于在客户端和服务器之间传递信息、实现会话跟踪和状态管理的一种机制。以下将从定义、工作原理、类型、使用场景、优缺点和安全问题等方面进行详细介绍。

定义

Cookie是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带上并发送到服务器上。这些数据可以是用户的身份信息、偏好设置、浏览历史等，服务器可以根据这些信息来识别用户和提供个性化的服务。

工作原理

1. 服务器发送Cookie：当用户通过浏览器访问一个网站时，服务器在响应头中添加Set - Cookie字段，该字段包含了要设置的Cookie信息，如Cookie的名称、值、过期时间、域名、路径等。例如：

   Set - Cookie: session_id=123456; Expires=Wed, 09 Jun 2025 10:18:14 GMT; Domain=example.com; Path=/
   

2. 浏览器保存Cookie：浏览器接收到服务器的响应后，会解析Set - Cookie字段，并将Cookie信息保存到本地的Cookie文件中。
3. 浏览器发送Cookie：当浏览器再次向同一服务器发起请求时，会在请求头中添加Cookie字段，将之前保存的Cookie信息发送给服务器。例如：

   Cookie: session_id=123456
   

4. 服务器读取Cookie：服务器接收到请求后，会解析Cookie字段，获取其中的Cookie信息，并根据这些信息来识别用户和处理请求。

类型

• 会话Cookie：也称为临时Cookie，它不会被存储在硬盘上，而是保存在浏览器的内存中。当用户关闭浏览器时，会话Cookie会被自动删除。会话Cookie通常用于跟踪用户在一次会话中的活动，如用户登录状态、购物车信息等。
• 持久Cookie：会被存储在用户的硬盘上，直到达到指定的过期时间才会被删除。持久Cookie可以在浏览器关闭后仍然存在，用于记录用户的长期偏好设置、登录信息等。例如，用户选择“记住我”登录选项后，服务器会设置一个持久Cookie，以便用户下次访问时无需再次输入用户名和密码。redis数据库，10分钟有效期。session就被删除了。浏览器刷新，携带过期cookie访问网站。重新生成。
• python web开发

使用场景

• 会话管理：用于跟踪用户的会话状态，如用户登录状态、购物车信息等。服务器可以通过Cookie来识别用户，确保用户在整个会话过程中能够保持登录状态，并对购物车中的商品进行管理。
• 个性化设置：记录用户的偏好设置，如语言选择、主题颜色、字体大小等。服务器可以根据这些设置为用户提供个性化的页面展示。
• 广告跟踪：广告商可以使用Cookie来跟踪用户的浏览行为，了解用户的兴趣爱好，从而向用户展示更相关的广告。

优点

• 实现状态管理：解决了HTTP协议无状态的问题，使得服务器能够识别和跟踪用户的会话状态，为用户提供连续的服务。
• 提高用户体验：通过记录用户的偏好设置和历史行为，服务器可以为用户提供个性化的服务，提高用户的满意度和忠诚度。
• 方便数据传递：Cookie可以在客户端和服务器之间传递少量的数据，避免了每次请求都需要用户手动输入信息的麻烦。

缺点

• 安全性问题：Cookie中可能包含用户的敏感信息，如登录凭证、个人身份信息等。如果Cookie被窃取或篡改，可能会导致用户的账户被盗用、个人信息泄露等安全问题。
• 存储空间有限：每个Cookie的大小通常有限制（一般不超过4KB），且浏览器对每个域名下的Cookie数量也有限制。因此，Cookie不适合存储大量的数据。
• 用户隐私问题：广告商和网站可能会滥用Cookie来跟踪用户的行为，侵犯用户的隐私。一些用户可能会对这种行为感到反感，并采取措施阻止Cookie的使用。

安全问题及防护措施

• 跨站脚本攻击（XSS）：攻击者可以通过注入恶意脚本获取用户的Cookie信息。防护措施包括对用户输入进行严格的过滤和验证，避免在页面中直接输出用户输入的内容。
• 跨站请求伪造（CSRF）：攻击者可以诱导用户在已登录的网站上执行恶意操作。防护措施包括使用验证码、验证请求来源、设置SameSite属性等。
• Cookie加密：对于包含敏感信息的Cookie，应该进行加密处理，确保数据在传输和存储过程中的安全性。例如，使用HTTPS协议可以对Cookie进行加密传输，防止中间人攻击。

但是如果HTTP完全无状态，你登录到淘宝网后，点击电子产品的跳转链接，它又提示你需要登录了，这就是一个无状态的实际效果。

因此此类需要保持用户身份信息的业务，必须要保存用户的状态。

于是引入了Cookie技术，能够保持用户的身份信息，下一次客户端发出请求，服务端能记忆客户端的身份。

没有cookie

有cookie

HTTP请求方法

HTTP（超文本传输协议）定义了多种请求方法，每种方法用于不同的目的，代表了对资源的不同操作方式。以下是一些常见的HTTP请求方法及其详细介绍：

GET

• 功能：GET方法是最常用的HTTP请求方法之一，主要用于从服务器获取资源。当你在浏览器中输入一个网址并回车，浏览器默认会使用GET方法向服务器请求该网页的内容。GET请求通常会将请求参数附加在URL的后面，以查询字符串的形式呈现。
• 示例： ```plaintext GET URL_PATH

GET /products?category=electronics&page=1 HTTP/1.1 Host: www.luffycity.com

这个请求表示从 `example.com` 服务器获取电子产品类别的第一页产品信息。
- **特点**：GET请求具有幂等性，即多次执行相同的GET请求所得到的结果应该是相同的，不会对服务器上的资源产生副作用。此外，由于请求参数会暴露在URL中，因此不适合用于传输敏感信息。

### POST
- **功能**：POST方法主要用于向服务器提交数据，通常用于创建新的资源或更新现有资源。与GET请求不同，POST请求将请求参数放在请求体中，而不是URL中，因此可以传输大量的数据，并且相对更安全。
- **示例**：
```plaintext
POST /user/register HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 32

{
    "username": "john_doe",
    "password": "123456"
}

这个请求表示向 example.com 服务器的用户注册接口提交一个新用户的信息。

• 特点：POST请求不具有幂等性，多次执行相同的POST请求可能会导致服务器上的资源发生多次创建或更新操作。

PUT

• 功能：PUT方法用于向服务器上传资源，通常用于更新现有资源。如果指定的资源不存在，服务器可能会创建该资源。PUT请求需要提供完整的资源数据，服务器会用新的数据替换原有的资源数据。
• WORDPRESS LNMP博客架构。php，python
• 示例： ```plaintext PUT /products/123 HTTP/1.1 Host: example.com Content-Type: application/json Content-Length: 25

{ "name": "New Product Name", "price": 99.99 }

这个请求表示更新 `example.com` 服务器上ID为123的产品信息。
- **特点**：PUT请求具有幂等性，多次执行相同的PUT请求对服务器资源的影响应该是相同的。

### DELETE
- **功能**：DELETE方法用于请求服务器删除指定的资源。
- **示例**：
```plaintext
DELETE /products/123 HTTP/1.1
Host: example.com

这个请求表示删除 example.com 服务器上ID为123的产品。

• 特点：DELETE请求具有幂等性，多次执行相同的DELETE请求对服务器资源的影响应该是相同的。如果资源已经被删除，再次执行DELETE请求通常不会产生额外的影响。

HEAD

• 功能：HEAD方法与GET方法类似，但服务器在响应HEAD请求时只返回响应头，而不返回响应体。HEAD请求通常用于获取资源的元信息，如资源的状态码、内容类型、内容长度等，而不需要获取整个资源。
• 示例：

  HEAD /image.jpg HTTP/1.1
  Host: example.com
  

  通过这个请求，客户端可以获取 example.com 服务器上 image.jpg 图片的元信息，而无需下载整个图片。

OPTIONS

• 功能：OPTIONS方法用于获取服务器支持的请求方法和其他相关信息。客户端可以通过发送OPTIONS请求来了解服务器对于特定资源所支持的操作，以及请求的一些限制和要求。
• 示例：

  OPTIONS /api HTTP/1.1
  Host: example.com
  

  服务器可能会返回类似以下的响应头，表明支持的请求方法：

  Allow: GET, POST, PUT, DELETE, OPTIONS
  

PATCH

• 功能：PATCH方法用于对资源进行部分更新。与PUT方法不同，PUT方法需要提供完整的资源数据来替换原有的资源，而PATCH方法只需要提供需要更新的部分数据。
• 示例： ```plaintext PATCH /products/123 HTTP/1.1 Host: example.com Content-Type: application/json Content-Length: 17

{ "price": 199.99 }

这个请求表示只更新 `example.com` 服务器上ID为123的产品的价格信息。 



# HTTP请求报文

HTTP请求报文是客户端向服务器发送请求时所使用的消息格式，用于传达客户端的请求意图和相关信息。它由请求行、请求头、空行和请求体四个部分组成，以下是对各部分的详细介绍：

### 请求行
请求行位于HTTP请求报文的第一行，它包含了三个重要信息，以空格分隔，格式为：`请求方法  请求的资源路径  HTTP协议版本`。
- **请求方法**：常见的请求方法有GET、POST、PUT、DELETE、HEAD、OPTIONS、PATCH等，每种方法代表了对服务器资源的不同操作方式。例如，GET方法用于从服务器获取资源，POST方法用于向服务器提交数据。
- **请求的资源路径**：指定了客户端请求的服务器上的资源位置。它是相对于服务器根目录的路径，不包含域名信息。例如，`/index.html` 表示请求服务器根目录下的 `index.html` 文件。如果请求包含查询参数，查询参数会附加在资源路径后面，以问号 `?` 分隔，多个参数之间用 `&` 连接。例如，`/products?category=electronics&page=1`。
- **HTTP协议版本**：指示了客户端使用的HTTP协议版本，常见的有 `HTTP/1.0`、`HTTP/1.1` 和 `HTTP/2` 等。不同的HTTP协议版本在功能和性能上可能存在差异。

**示例**：
```plaintext
GET /products?category=electronics&page=1 HTTP/1.1

请求头

请求头由多个字段组成，每个字段包含一个字段名和一个字段值，中间用冒号 : 分隔。请求头用于传递关于请求的附加信息，如客户端的身份、接受的内容类型、缓存策略等。常见的请求头字段包括：

• User - Agent：标识客户端的类型和版本信息，例如浏览器的类型和版本、操作系统等。服务器可以根据这个信息为不同的客户端提供不同的响应。

  User - Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
  

• Accept：指定客户端能够接受的响应内容类型，服务器会根据这个字段返回合适的内容。可以使用通配符 * 表示接受任意类型。

  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
  

• Accept - Encoding：指定客户端能够接受的响应内容编码方式，如 gzip、deflate 等。服务器可以根据这个字段对响应内容进行压缩，以减少传输数据量。

  Accept - Encoding: gzip, deflate, br
  

• Cookie：包含客户端之前从服务器接收的Cookie信息，用于实现会话跟踪和状态管理。

  Cookie: session_id=123456; user_token=abcdef
  

空行

空行是一个换行符，用于分隔请求头和请求体。它标志着请求头的结束，服务器通过检测空行来确定请求头的边界。

请求体

请求体是可选部分，并非所有的HTTP请求都包含请求体。它主要用于携带客户端向服务器提交的数据，常见于POST、PUT、PATCH等请求方法中。请求体的内容类型由请求头中的 Content - Type 字段指定，常见的内容类型有：

• application/x - www - form - urlencoded：用于表单数据的提交，数据以键值对的形式编码，键值对之间用 & 连接，键和值之间用 = 连接。

  username=john_doe&password=123456
  

• application/json：用于提交JSON格式的数据，适用于现代的Web应用和API接口。

  {
    "username": "john_doe",
    "password": "123456"
  }
  

• multipart/form - data：用于上传文件或包含二进制数据的表单提交。每个表单字段和文件都被封装成一个独立的部分，部分之间用分隔符分隔。

完整示例

以下是一个包含请求行、请求头、空行和请求体的完整HTTP请求报文示例：

POST /user/register HTTP/1.1
Host: example.com
Content - Type: application/json
Content - Length: 32
User - Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: application/json

{
    "username": "john_doe",
    "password": "123456"
}

这个请求报文表示客户端使用POST方法向 example.com 服务器的 /user/register 接口提交一个JSON格式的用户注册信息。

抓包HTTP请求

HTTP响应报文

HTTP响应报文是服务器在接收到客户端的HTTP请求后，向客户端返回的消息。它包含了服务器对请求的处理结果和相关信息，由响应行、响应头、空行和响应体四个部分组成。以下为你详细介绍各部分内容：

响应行

响应行位于HTTP响应报文的第一行，包含三个重要信息，以空格分隔，格式为：HTTP协议版本 状态码 状态描述。

• HTTP协议版本：表明服务器使用的HTTP协议版本，常见的有 HTTP/1.0、HTTP/1.1、HTTP/2 等，和客户端请求报文中的协议版本相互对应，反映了通信遵循的协议规范。
• 状态码：是一个三位数字，用于表示请求的结果状态。不同的状态码代表不同的含义，可分为五类，如以2开头的状态码表示成功，以3开头的表示重定向，以4开头的表示客户端错误，以5开头的表示服务器错误。
• 状态描述：用简短的文本对状态码进行描述，帮助用户理解状态码的含义。例如，状态码200对应的状态描述通常是 OK，表示请求成功。

示例：

HTTP/1.1 200 OK

响应头

响应头由多个字段组成，每个字段包含字段名和字段值，中间用冒号 : 分隔。响应头用于传递关于响应的附加信息，如响应的内容类型、缓存策略、服务器信息等。常见的响应头字段包括：

• Content - Type：指定响应体的内容类型，告知客户端如何解析响应体。常见的内容类型有 text/html（HTML页面）、application/json（JSON数据）、image/jpeg（JPEG图片）等。

  Content - Type: text/html; charset=UTF - 8
  

• Content - Length：表示响应体的字节长度，客户端可以根据这个字段确定接收数据的长度。

  Content - Length: 1234
  

• Set - Cookie：用于服务器向客户端发送Cookie信息，客户端会将这些Cookie保存下来，并在后续的请求中发送给服务器。

  Set - Cookie: session_id=123456; Expires=Wed, 09 Jun 2025 10:18:14 GMT; Domain=example.com; Path=/
  

• Cache - Control：用于控制缓存策略，指定响应的缓存方式和有效期。例如，Cache - Control: max - age=3600 表示响应可以被缓存，且缓存的有效期为3600秒。

  Cache - Control: no - cache
  

空行

空行是一个换行符，用于分隔响应头和响应体。它标志着响应头的结束，客户端通过检测空行来确定响应头的边界。

响应体

响应体包含了服务器返回给客户端的实际数据内容，具体内容取决于请求的资源和处理结果。响应体可以是HTML页面、JSON数据、图片、文件等。例如，当客户端请求一个网页时，响应体就是该网页的HTML代码；当请求一个JSON格式的API数据时，响应体就是JSON字符串。

完整示例

以下是一个包含响应行、响应头、空行和响应体的完整HTTP响应报文示例：

HTTP/1.1 200 OK
Content - Type: text/html; charset=UTF - 8
Content - Length: 256
Server: Apache/2.4.41 (Ubuntu)

<!DOCTYPE html>
<html>
<head>
    <title>Example Page</title>
</head>
<body>
    <h1>Welcome to the Example Page</h1>
    <p>This is a sample HTML page.</p>
</body>
</html>

这个响应报文表示服务器成功处理了客户端的请求，返回一个HTML页面作为响应体，同时通过响应头提供了关于响应的相关信息，如内容类型、长度和服务器信息等。

响应头解释
Connection            使用keep-alive特性
Content-Encoding      使用gzip方式对资源压缩
Content-Length: 主体的长度
Content-type          MIME类型为html类型，字符集是 UTF-8
Date                  响应的日期
Server                使用的WEB服务器
Last-Modified：最后一次修改的时间
Server：            服务器程序软件名称和版本

抓包HTTP响应

HTTP常见响应状态码

HTTP响应状态码是服务器返回给客户端的三位数字代码，用于表示HTTP请求的结果状态。状态码可以帮助客户端快速了解请求的处理情况，判断是成功、重定向、客户端错误还是服务器错误等。状态码分为五类，以下为你详细介绍：

1xx（信息性状态码）

这类状态码表示临时的响应，通常用于告知客户端请求已经收到，正在处理中。常见的1xx状态码有：

• 100 Continue：客户端在发送包含 Expect: 100 - continue 请求头的请求时，服务器如果愿意接受后续的数据，会返回这个状态码。客户端收到该状态码后，会继续发送请求体。

2xx（成功状态码）

表示请求已经成功被服务器接收、理解并处理。常见的2xx状态码有：

• 200 OK：最常见的成功状态码，表示请求成功，服务器已经根据请求返回了相应的资源。例如，客户端请求一个网页，服务器正常返回该网页的HTML内容时，就会返回200状态码。
• 201 Created：表示请求已经成功，并且服务器已经创建了新的资源。通常用于POST请求创建资源的场景，如用户注册新账号、创建新的文章等。服务器会在响应头中提供新创建资源的URL。
• 204 No Content：表示请求已经成功处理，但响应中没有返回任何内容。常用于DELETE请求删除资源成功后，或者客户端发送的请求只是触发服务器的某个操作，不需要返回具体数据的情况。

3xx（重定向状态码）

表示客户端需要采取进一步的操作才能完成请求，通常用于重定向到其他URL。常见的3xx状态码有：

• 301 Moved Permanently：表示请求的资源已经永久移动到了新的URL。客户端在收到该状态码后，应该记住这个新的URL，以后的请求都应该直接访问新的地址。搜索引擎在遇到301重定向时，会更新索引信息。
• 302 Found：表示请求的资源临时移动到了新的URL。客户端在后续的请求中仍然可以使用原来的URL。302重定向常用于临时的页面跳转，如网站维护期间的临时跳转页面。
• 304 Not Modified：表示客户端所请求的资源没有发生变化，可以使用客户端本地缓存的版本。服务器在响应中不会返回资源的内容，客户端直接使用本地缓存即可，这样可以减少数据传输，提高性能。通常与缓存相关的请求头（如 If - Modified - Since、If - None - Match）一起使用。

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

表示客户端的请求包含错误的语法或无法被服务器正确处理。常见的4xx状态码有：

• 400 Bad Request：表示客户端发送的请求存在语法错误，服务器无法理解。例如，请求参数格式不正确、请求头缺失必要信息等。
• 401 Unauthorized：表示请求需要用户进行身份验证，但客户端没有提供有效的身份凭证。通常服务器会在响应头中包含 WWW - Authenticate 字段，提示客户端需要进行何种方式的身份验证。
• 403 Forbidden：表示服务器理解请求客户端的请求，但是拒绝执行此请求。这可能是因为客户端没有足够的权限访问该资源，即使客户端已经进行了身份验证。例如，用户试图访问一个受保护的文件或目录，但没有相应的权限。
• 404 Not Found：表示请求的资源在服务器上不存在。这是一个非常常见的状态码，当用户输入的URL不正确或者请求的资源已经被删除时，服务器会返回404状态码。
• 405 Method Not Allowed：表示客户端使用的请求方法（如GET、POST等）不被服务器允许。例如，服务器只允许对某个资源使用POST方法，但客户端使用了GET方法，就会返回405状态码。

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

表示服务器在处理请求时发生了错误，无法完成请求。常见的5xx状态码有：

• 500 Internal Server Error：表示服务器内部发生了错误，无法处理请求。这是一个通用的错误状态码，可能是由于服务器端代码出现异常、服务器配置错误等原因导致的。
• 502 Bad Gateway：表示作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。例如，Web服务器作为代理向应用服务器转发请求时，应用服务器出现问题返回了错误的响应，Web服务器就会向客户端返回502状态码。
• 503 Service Unavailable：表示服务器目前无法处理请求，通常是由于服务器过载、维护或暂时不可用等原因导致的。服务器可以在响应头中包含 Retry - After 字段，提示客户端在多长时间后可以再次尝试请求。
• 504 Gateway Timeout：表示作为网关或者代理工作的服务器在等待上游服务器的响应时超时。例如，Web服务器作为代理向应用服务器转发请求，但应用服务器在规定时间内没有返回响应，Web服务器就会向客户端返回504状态码。

URL/URI理解

URL（Uniform Resource Locator）和 URI（Uniform Resource Identifier）是互联网中用于标识和定位资源的重要概念，二者既有联系又有区别，以下为你详细介绍：

URI（统一资源标识符）

• 定义：URI 是一个用于标识抽象或物理资源的字符序列，它是一种通用的资源标识机制，可以唯一地标识互联网上的任何资源，这些资源可以是网页、图片、文件、电子邮件地址等。从概念上来说，URI 是一个更宽泛的概念，它包括了所有能够标识资源的字符串。
• 组成结构：一个典型的 URI 由三个主要部分组成，即方案（Scheme）、权限（Authority）和路径（Path），其一般语法格式为 scheme:[//authority]path[?query][#fragment]。
  • 方案（Scheme）：指定了访问资源所使用的协议类型，例如 http、https、ftp、mailto 等。方案部分通常以字母开头，后面可以跟数字、加号、减号或点号，并且以冒号 : 结尾。例如，在 http://example.com 中，http 就是方案。
  • 权限（Authority）：包含了访问资源所需的授权信息，通常由主机名（Host）和可选的端口号（Port）组成，中间用冒号 : 分隔。例如，在 http://example.com:8080 中，example.com 是主机名，8080 是端口号。此外，权限部分还可以包含用户名和密码信息，格式为 username:password@host:port，不过这种方式在实际应用中较少使用，因为存在安全风险。
  • 路径（Path）：用于指定资源在服务器上的具体位置，它类似于文件系统中的文件路径。路径部分可以包含多个层次的目录和文件名，不同层次之间用斜杠 / 分隔。例如，在 http://example.com/path/to/resource.html 中，/path/to/resource.html 就是路径。
  • 查询（Query）：可选部分，用于向服务器传递额外的参数信息。查询部分以问号 ? 开头，后面跟着一系列的键值对，键值对之间用 & 分隔。例如，在 http://example.com/search?keyword=apple&page=1 中，keyword=apple&page=1 就是查询部分。https://www.luffycity.com/search?words=aiops
  • 片段（Fragment）：可选部分，用于指定资源内部的一个特定位置。片段部分以井号 # 开头，通常用于网页中的锚点定位。例如，在 http://example.com/page.html#section2 中，section2 就是片段，表示要定位到 page.html 页面中 id 为 section2 的元素位置。

URL（统一资源定位符）

• 定义：URL 是 URI 的一个子集，它不仅能够标识资源，还能提供找到该资源的具体位置和访问方式。简单来说，URL 是一种具体的 URI，它明确了如何通过网络协议来访问资源。
• 示例：http://www.example.com/index.html 就是一个典型的 URL，它使用 http 协议，通过访问 www.example.com 这个主机上的 index.html 文件来定位资源。

二者关系

• URL 是 URI 的一个特例，所有的 URL 都是 URI，但并非所有的 URI 都是 URL。例如，URN（统一资源名称）也是 URI 的一种类型，它使用名称来标识资源，而不指定资源的位置和访问方式。例如，urn:isbn:0451450523 是一个 URN，它通过国际标准书号来标识一本书，但并没有告诉我们如何获取这本书，所以它是 URI 但不是 URL。

实际应用

• URL 的应用：在日常的互联网使用中，URL 更为常见，我们在浏览器中输入的网址就是 URL。当我们访问网页、下载文件、发送电子邮件等操作时，都需要使用 URL 来定位和访问相应的资源。
• URI 的应用：URI 更多地用于在抽象层面标识资源，在一些标准规范和系统设计中使用。例如，在 XML 文档中，可能会使用 URI 来引用外部资源或定义命名空间。

统一资源标志符URI就是在某一规则下能把一个资源独一无二地标识出来。

例如身份证号，定位唯一的一个人，绝对不会重复，身份证号就好比是URI

统一资源定位符URL 定位到这个人，他在哪

住址协议://地球/中国/北京/昌平/沙河/于超老师

等于↓

http://yuchaoit.cn/upload/2025/03/Xnip2025-03-01_16-32-30-b82235c9b62c42af8ea25e0313ca42f7.jpg

url中文叫“统一资源标识符”，是一个用于标识某一互联网资源名称的字符串，在世界范围内标识定位某一个唯一信息资源。

其实这个资源就是在web服务器上
[root@yuchao-tx-server /opt]#find / -name 'Xnip2022-05-01_16-32-30-b82235c9b62c42af8ea25e0313ca42f7.jpg'

/root/.halo/upload/2022/05/Xnip2022-05-01_16-32-30-b82235c9b62c42af8ea25e0313ca42f7.jpg

url主要用在各种www客户端和服务器程序上，url可以用一种统一的格式来描述各种信息资源，包括文件，服务器地址和目录等

【url组成】

1. 协议
2. 主机ip或域名
3. 端口
4. 文件资源具体地址

第一部分用"://"隔开，第二部分用"/"符号隔开

web服务器与前端静态资源

Web服务器和前端静态资源在Web应用中扮演着不同但又紧密相关的角色，以下将详细介绍它们各自的概念、相互关系以及常见的应用场景。

概念

Web服务器

Web服务器是一种软件或硬件设备，用于处理客户端（通常是浏览器）的HTTP请求，并返回相应的HTTP响应。它监听特定的端口（通常是80或443，8080,8099，不冲突。），接收客户端的请求后，根据请求的内容和服务器的配置，从文件系统、数据库或其他后端服务中获取资源，并将其封装成HTTP响应返回给客户端。

常见的Web服务器软件有Apache、Nginx、IIS（Internet Information Services）等。

前端静态资源

前端静态资源是指在Web页面中不需要经过服务器端动态处理就可以直接展示给用户的资源，主要包括以下几类：

• HTML文件：超文本标记语言文件，用于构建网页的结构和内容，定义了网页中的文本、图片、链接、表单等元素的布局和显示方式。
• CSS文件：层叠样式表文件，用于控制网页的外观和样式，如字体、颜色、布局、边框等。通过CSS可以使网页更加美观和吸引人。
• JavaScript文件：一种脚本语言文件，用于为网页添加交互性和动态效果，如表单验证、菜单切换、动画效果等。JavaScript可以在浏览器中直接执行，增强用户体验。
• 图片文件：如JPEG、PNG、GIF等格式的图片，用于在网页中展示图像内容，使网页更加生动和丰富。
• 字体文件：用于在网页中使用特定的字体，确保网页在不同设备上都能以一致的字体显示文本内容。

相互关系

• Web服务器提供静态资源服务：Web服务器的一个重要功能是提供前端静态资源的服务。当客户端通过浏览器请求一个网页时，Web服务器会根据请求的URL定位到相应的静态资源文件（如HTML、CSS、JavaScript等），并将这些文件的内容以HTTP响应的形式返回给客户端。例如，当用户访问 http://example.com/index.html 时，Web服务器会在其文件系统中查找 index.html 文件，并将其内容发送给浏览器。
• 前端静态资源依赖Web服务器分发：前端静态资源需要通过Web服务器进行分发才能被客户端访问。这些资源通常存储在Web服务器的文件系统中，Web服务器负责管理和维护这些资源，并根据客户端的请求将它们准确地发送给客户端。没有Web服务器的支持，前端静态资源就无法在互联网上广泛传播和被用户访问。
• Web服务器可优化静态资源传输：Web服务器可以对前端静态资源的传输进行优化，以提高性能和用户体验。例如，Web服务器可以对静态资源进行压缩（如使用Gzip或Brotli压缩），减少数据传输量；可以设置缓存策略，让客户端在一定时间内缓存静态资源，避免重复请求，提高响应速度。

应用场景

小型网站和博客

对于小型网站和博客来说，通常只需要提供静态页面和一些简单的交互功能。这种情况下，可以使用轻量级的Web服务器（如Nginx）来提供前端静态资源服务。服务器将存储在本地的HTML、CSS、JavaScript和图片等静态资源直接返回给客户端，无需复杂的后端处理，具有部署简单、性能高的特点。

大型网站和应用

在大型网站和应用中，前端静态资源的管理和分发更为复杂。为了提高性能和可用性，通常会采用内容分发网络（CDN）来加速静态资源的传输。CDN是一种分布式的服务器网络，它将静态资源缓存到离用户较近的节点上，当用户请求静态资源时，CDN会从最近的节点返回资源，减少了传输延迟。同时，Web服务器仍然负责处理客户端的请求和提供动态内容，与CDN协同工作，为用户提供高效的服务。

单页面应用（SPA）

单页面应用是一种现代的Web应用架构，它通过JavaScript在浏览器中动态加载和渲染页面内容，减少了页面的刷新和跳转，提供了更流畅的用户体验。在SPA中，Web服务器通常只提供一个初始的HTML文件和相关的静态资源（如CSS、JavaScript），后续的页面内容更新和交互都由前端JavaScript代码完成。Web服务器需要确保这些静态资源能够快速、稳定地提供给客户端，以支持SPA的正常运行。

html

超文本标记语言（英语：HyperText Markup Language，简称：HTML）是一种用于创建网页的标准标记语言。

http服务器响应体，一般就是如下的html

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>chaoge.linux</title>
</head>
<body>
    <h1>我的第一个标题</h1>
    <p>我的第一个段落。</p>
</body>
</html>

光溜溜的小狗

css

光溜溜的小狗---穿衣服了，穿上绿色的夹克。。

CSS 指层叠样式表 (Cascading Style Sheets)

CSS作用是定义如何显示HTML元素样式

js

JavaScript 是互联网上最流行的脚本语言，这门语言可用于 HTML 和 web，更可广泛用于服务器、PC、笔记本电脑、平板电脑和智能手机等设备。

JavaScript 是一种轻量级的编程语言。

JavaScript 是可插入 HTML 页面的编程代码。

JavaScript 插入 HTML 页面后，可由所有的现代浏览器执行。

静态资源理解

在网页设计中，纯HTMl格式的网页（包含图片，视频，JS，CSS等样式）通常被称作“静态网页”。

静态网页是相对于动态网页而言的，是指没有后台数据库，不包含程序，不可交互的网页。

静态网页的特点
开发人员写了什么，显示就是什么，一旦编写完成，就不会有任何改变。静态网页一般适用于更新较少的展示型网页，例如（酒水，家具，水果等宣传页），是很多中小网站的展示方式。

静态网页资源对应文件扩展名为

• 纯文本文件，如.htm .html .xml .js .css
• 图片或数据文档，如 .jpg .gif .bmp .txt .ppt
• 视频类文件 .mp4 .avi .flv 等

静态网页重要特性

• 每个页面有一个固定的url地址，url地址不含有问号"?"或"&"等符号
• 网页一经发布到服务器，网页内容是保存在服务器文件系统上的，每个网页都是独立的一个文件
• 网页内容固定不变，容易被搜索引擎收录（优点）
• 网页没有数据库支撑，在网站制作和维护上工作量很大（缺点）
• 网页的交互性很差，缺少程序的功能实现（缺点）
• 客户端解析网址时，由于不需要读取数据库，因此服务器端可以接受更高的并发访问。请求到来时，直接从磁盘上返回数据。（优点）

动态资源理解

在Web开发的语境下，动态资源是与静态资源相对的概念，它在Web应用中扮演着至关重要的角色。下面从定义、特点、生成方式、应用场景和与静态资源的对比等方面详细介绍动态资源。

定义

动态资源指的是在服务器端根据不同的请求参数、用户信息、数据库内容等动态生成的资源。与静态资源（如固定内容的 HTML、CSS、图片等，其内容在文件创建后就固定不变）不同，动态资源每次被请求时可能会返回不同的内容。

特点

• 内容动态变化：动态资源的内容会根据不同的条件而改变。例如，新闻网站的首页会根据最新的新闻数据动态显示不同的新闻标题和摘要；电商网站的商品列表页会根据用户的搜索关键词、筛选条件等显示不同的商品信息。
• 实时性强：能够及时反映最新的数据和状态。比如股票交易网站，其页面上显示的股票价格、成交量等信息会实时更新，以确保用户获取到最新的市场动态。
• 依赖服务器端处理：需要服务器端进行复杂的逻辑处理和数据查询。服务器会根据客户端的请求，执行相应的程序代码，从数据库或其他数据源中获取数据，并将数据与页面模板进行组合，最终生成动态的响应内容。

生成方式

• 服务器端脚本语言：使用如 PHP、Python（结合 Django、Flask 等框架）、Java（结合 Spring、Struts 等框架）、Ruby（结合 Ruby on Rails 框架）等服务器端脚本语言。这些语言可以处理客户端的请求，访问数据库，执行复杂的业务逻辑，并动态生成 HTML、JSON 等格式的响应内容。例如，一个使用 PHP 编写的用户信息页面，会根据用户的 ID 从数据库中查询该用户的详细信息，并将信息填充到 HTML 模板中返回给客户端。

  <?php
  // 连接数据库
  $conn = mysqli_connect("localhost", "username", "password", "database");
  // 查询用户信息
  $sql = "SELECT * FROM users WHERE id = 1";
  $result = mysqli_query($conn, $sql);
  $user = mysqli_fetch_assoc($result);
  // 动态生成 HTML 内容
  echo "<h1>Welcome, ". $user['name']. "</h1>";
  echo "<p>Email: ". $user['email']. "</p>";
  // 关闭数据库连接
  mysqli_close($conn);
  ?>
  

• API 接口：服务器提供 RESTful API 或 GraphQL 等类型的接口，客户端通过发送请求调用这些接口获取动态数据。API 接口会根据请求的参数从数据库或其他数据源中获取数据，并以 JSON、XML 等格式返回给客户端。例如，一个天气应用会通过调用天气 API 获取实时的天气数据，并将数据展示在应用界面上。

应用场景

• 电子商务网站：商品详情页、购物车页面、订单页面等都会根据用户的操作和数据库中的商品信息、库存信息、订单状态等动态生成。例如，当用户将商品加入购物车时，购物车页面会实时更新商品数量和总价。
• 社交网络平台：用户的个人主页、好友动态、消息通知等内容都是动态生成的。服务器会根据用户的关注列表、好友关系、发布的内容等信息，为每个用户展示个性化的页面内容。
• 在线新闻媒体：新闻列表、文章详情页会根据新闻的发布时间、分类、热度等因素动态展示不同的新闻内容。同时，评论区会实时显示用户的评论信息。

与静态资源的对比

• 内容特性：静态资源内容固定，每次请求返回相同的结果；而动态资源内容根据不同条件动态变化。
• 处理方式：静态资源直接从服务器的文件系统中读取并返回，处理过程简单；动态资源需要服务器端进行复杂的逻辑处理和数据查询。
• 性能影响：静态资源由于内容固定，可以进行缓存，减少服务器负载和响应时间；动态资源的生成需要消耗服务器的计算资源和时间，可能会导致响应速度较慢，但可以通过缓存机制（如页面缓存、数据缓存）来优化性能。

服务端需要通过执行程序做出处理，发送给客户端的是程序的运行结果
动态网页是和静态网页相对而言的，动态网页的url后缀一般是.asp  .aspx  .php .js .cgi 
并且动态网页都有标志性的符号"? &"，后端都有数据库的支持。

动态网页地址

添加新随笔
https://i.cnblogs.com/EditPosts.aspx?opt=1

动态网页资源特点

1. 网页以数据库技术为支撑，大大降低网站维护的工作量
2. 动态网页技术的网站可以实现更多的功能，如用户注册，用户登录，投票，用户管理，博客管理等
3. 动态网页不是独立存在服务器上的网页文件，用户请求动态程序时，服务器解析程序并且可能读取数据库返回一个完整的网页内容
4. 搜索引擎（爬虫）一般不会抓取网址中的“？”后面的内容，因此企业都会做伪静态技术页面

不同编程语言，设计的动态url是不一样的，需要自行通过抓包工具，分析请求头信息。

部署网站了。。

url在浏览器回车之后，发生了什么（面试题）

当在浏览器地址栏输入URL并按下回车时，整个过程涉及计算机网络、操作系统、浏览器引擎等多个技术栈的协同工作。以下是一线大厂面试中的标准技术解析框架：

一、核心流程总览（分层模型）

graph LR
A[URL解析] --> B[DNS查询] --> C[建立TCP连接] --> D[TLS握手] --> E[发送HTTP请求] --> F[服务器处理] --> G[接收响应] --> H[渲染页面] --> I[连接终止]

二、关键技术分解

1. URL解析与预处理

• 协议推断：自动补全http/https（Chrome隐藏www逻辑）
• 编码转换：处理非ASCII字符（如%E4%B8%AD转中文）
• HSTS预加载：检查内置列表强制HTTPS（如google.com）

2. DNS解析（递归查询）

# 查询顺序示例
浏览器缓存 → 本地hosts文件 → 系统DNS缓存 → 
路由器缓存 → ISP DNS → 根域名服务器 → 顶级域 → 权威DNS

• 优化手段：DNS预解析<link rel="dns-prefetch">
• 安全防御：DNSSEC防劫持

3. 建立TCP连接（三次握手）

# 伪代码演示
客户端发送 SYN=1, Seq=x          → 服务器
客户端 ← 接收 SYN=1, ACK=1, Seq=y, Ack=x+1 ← 服务器
客户端发送 ACK=1, Seq=x+1, Ack=y+1 → 服务器

• 内核参数调优：tcp_syn_retries控制重试次数
• 协议升级：HTTP/3基于QUIC协议（UDP）

4. TLS安全握手（以RSA算法为例）

1. ClientHello：支持的密码套件 + 随机数
2. ServerHello：选定密码套件 + 证书 + 随机数
3. 客户端验证证书链（OCSP/CRL检查吊销状态）
4. 预主密钥加密传输 → 生成会话密钥
5. 完成握手，加密通信开始

5. HTTP请求处理

• 请求头关键字段：

  Connection: keep-alive
  Accept-Encoding: gzip, br
  Cookie: session_id=xyz
  

• 缓存策略：检查Cache-Control/ETag/Last-Modified

6. 服务器处理（以Nginx+PHP-FPM为例）

1. Nginx接收请求 → 匹配location规则
2. FastCGI协议转发到PHP-FPM进程池
3. PHP连接MySQL（连接池复用）
4. 生成响应内容 → 返回HTTP响应

7. 浏览器渲染（关键渲染路径）

graph TD
A[解析HTML构建DOM树] --> B[解析CSS构建CSSOM]
B --> C[合并生成渲染树]
C --> D[布局计算]
D --> E[分层绘制]
E --> F[栅格化]
F --> G[合成显示]

• 优化技巧：
  • 异步加载JS（async/defer）
  • 关键CSS内联
  • 避免强制同步布局

三、高阶扩展要点

1. 性能优化维度

• 网络层：TCP Fast Open、HTTP/2 Server Push
• 渲染层：will-change提示GPU加速
• 缓存策略：Service Worker离线缓存

2. 安全防护机制

• CSP策略：Content-Security-Policy防XSS
• SRI校验：integrity属性验证资源完整性
• CORP头：Cross-Origin-Resource-Policy防跨站请求

3. 监控指标

• FP/FCP：首次绘制/首次内容绘制时间
• TTFB：首字节到达时间
• LCP：最大内容元素加载时间

四、面试回答技巧

1. 结构化表达：按OSI模型分层描述（应用层→物理层）
2. 突出亮点：深入某个技术点（如TLS1.3握手优化）
3. 结合实践：举例真实优化案例（如CDN加速方案）
4. 前沿扩展：提及WebAssembly/HTTP3等趋势

示例回答模板

"整个过程可分为网络通信与页面渲染两大阶段。网络层面：首先浏览器通过DNS查询将域名解析为IP地址，期间涉及递归查询与缓存机制；接着通过TCP三次握手建立可靠连接，若为HTTPS会进行TLS密钥协商；然后构造HTTP请求并通过分层协议栈发送。服务端处理请求后返回响应数据。渲染层面：浏览器引擎解析HTML/CSS构建DOM与CSSOM树，合并渲染树后经过布局、绘制、合成等阶段最终呈现页面。其中性能优化关键点在于减少RTT次数与关键渲染路径长度。"

此回答框架既展示技术深度，又体现系统性思维，符合大厂对候选人知识体系化与细节把控能力的要求。建议根据面试官追问方向，选择2-3个技术点进行深入展开。