网络编程高频总结三

发表于 2025/01/10 更新于 2025/01/10

作者 匆匆那年 34 分钟阅读

dns服务器用的是什么协议

DNS（Domain Name System）服务器主要使用以下协议：

1. UDP

用途:
- DNS 查询（如 A、AAAA、MX 记录等）默认使用 UDP 协议。
- UDP 是无连接协议，通信开销低，适合短小的数据传输（如 DNS 请求和响应）。
端口:
- 默认使用 53 端口。
优势:
- 速度快，适合多数 DNS 查询。
限制:
- 数据包大小限制为 512 字节（扩展机制 EDNS0 可突破此限制）。
- 无连接的设计使其容易受到 DNS 放大攻击。

2. TCP

用途:
- 在以下场景下，DNS 会切换到 TCP协议：
  1. 数据包超过 512 字节（如 DNSSEC 或复杂的查询结果）。
  2. 区域传送（Zone Transfer），即服务器之间同步 DNS 区域数据。
- 使用 TCP 连接确保数据完整性和可靠性。
端口:
- 同样使用 53 端口。
优势:
- 提供可靠传输，适合大数据量的场景。
限制:
- 相比 UDP，通信开销更大，效率较低。

3. HTTPS 和 TLS（DoH 和 DoT）

随着隐私和安全性需求的增加，现代 DNS 还支持以下安全协议：

DNS over HTTPS (DoH):

用途:
- 通过 HTTPS 协议对 DNS 查询加密，避免被第三方窃听或篡改。
端口:
- 使用 HTTPS 的默认端口 443。
优点:
- 提供更强的隐私保护，数据传输被加密。
- 容易穿透防火墙（因为与普通 HTTPS 流量难以区分）。
限制:
- 实现复杂度较高，对某些设备兼容性不佳。

DNS over TLS (DoT):

用途:
- 通过 TLS 加密 DNS 查询，确保隐私性和完整性。
端口:
- 使用 853 端口。
优点:
- 专用端口使其易于配置和识别。
- 加密传输提高安全性。
限制:
- 不如 DoH 普及，某些网络可能对端口 853 限制较多。

总结

协议	用途	端口	特点
UDP	默认的 DNS 查询	53	低开销，高效率，数据包大小有限。
TCP	大型查询或区域传送	53	可靠传输，适合复杂数据或大数据包。
DoH	加密 DNS 查询（基于 HTTPS）	443	提供隐私保护，易穿透防火墙。
DoT	加密 DNS 查询（基于 TLS）	853	提供隐私保护，但专用端口易被限制。

常见场景:

普通查询: UDP。
大数据包或复杂操作: TCP。
隐私保护需求: DoH 或 DoT。

ping命令用的是什么协议。在哪一层

Ping 命令的协议和所在层

1. 使用的协议:

Ping 使用的是 ICMP (Internet Control Message Protocol) 协议。

2. 所在层:

ICMP 是网络层协议，属于 TCP/IP 协议栈的网络层。

详细解析

ICMP 协议:
- ICMP 是网络层协议，主要用于在网络设备之间发送控制消息、错误报告和状态信息。
- Ping 是 ICMP 的一种常见使用场景，具体依赖以下消息类型：
  - ICMP Echo Request (回显请求): 由客户端发出，测试目标主机的连通性。
  - ICMP Echo Reply (回显应答): 由目标主机返回，用于确认目标主机是否可达。
Ping 工作流程:
- 用户输入 ping 命令，指定目标 IP 地址或域名。
- 主机发送 ICMP Echo Request 消息到目标主机。
- 目标主机收到后，返回 ICMP Echo Reply 消息。
- Ping 根据往返时间（RTT）和丢包率，判断目标主机的连通性和网络质量。
所在层:
- 网络层:
  - ICMP 是网络层协议，和 IP 协议一起工作。
  - ICMP 消息直接封装在 IP 数据包中，不依赖于传输层（如 TCP、UDP）。

Ping 与协议栈的关系

层次	协议	Ping 的作用
应用层	无	用户通过命令行直接调用 `ping`。
传输层	无	Ping 不使用 TCP 或 UDP。
网络层	ICMP	使用 Echo Request 和 Echo Reply。
数据链路层	Ethernet 等	承载 ICMP 消息的帧传输。
物理层	光纤、电缆、无线信号等	传输比特流。

补充信息

端口号:
- Ping 不使用传输层协议（TCP/UDP），因此没有端口号概念。
Ping 的作用:
- 测试主机是否连通。
- 测试网络延迟（RTT）。
- 检查网络质量（丢包率）。
ICMP 的局限性:
- 某些防火墙或网络配置可能会阻止 ICMP 消息（如丢弃 Echo Request），导致 Ping 无法正常工作，但目标主机可能仍可用。

Ping 是基于网络层的工具，简单但有效，广泛用于网络诊断和故障排查。

能详细讲一下有限状态机怎么解析http报文吗

用有限状态机解析 HTTP 报文

HTTP 报文解析通常基于有限状态机（Finite State Machine, FSM）的设计思想，将解析过程分解为若干状态，每个状态处理特定的内容，根据输入数据的特征和状态迁移规则切换状态。下面详细讲解如何通过有限状态机解析 HTTP 报文。

1. HTTP 报文解析简介

HTTP 报文的基本结构

请求报文:

<请求行>       : GET /index.html HTTP/1.1
<头部字段>     : Host: example.com
                 Content-Type: text/plain
<空行>         : (CRLF)
<实体主体>     : (可选，POST/PUT 请求可能包含)

响应报文:

<状态行>       : HTTP/1.1 200 OK
<头部字段>     : Content-Type: text/html
                 Content-Length: 123
<空行>         : (CRLF)
<实体主体>     : (实际内容)

2. 用有限状态机解析 HTTP 报文

设计思路

将报文分解为逻辑部分：请求行/状态行、头部字段、空行、实体主体。
为每个部分定义一个状态。
逐字节（或逐字符）读取输入，根据当前状态和输入内容，决定下一个状态。

状态设计

假设我们解析的是 HTTP 请求报文，状态设计如下：

状态名	说明
`METHOD`	解析请求方法（如 GET、POST）。
`URL`	解析 URL（路径部分）。
`VERSION`	解析 HTTP 版本（如 HTTP/1.1）。
`HEADER_KEY`	解析头部字段的键（如 Host）。
`HEADER_VALUE`	解析头部字段的值（如 example.com）。
`HEADER_END`	检测到空行，头部解析完成。
`BODY`	解析请求体（如果有）。
`DONE`	解析完成。

状态转移规则

初始状态: 从 METHOD 开始。
根据输入的字符：
- 遇到空格，切换到下一个部分（如从 METHOD 转到 URL）。
- 遇到 :，从 HEADER_KEY 转到 HEADER_VALUE。
- 遇到连续的 \r\n，从 HEADER_VALUE 转到 HEADER_END。
- 根据 Content-Length 或其他头部字段的值，判断是否需要进入 BODY 状态。
结束状态: 解析完成后进入 DONE。

状态机的伪代码实现

以下是一个解析 HTTP 请求的有限状态机的简化伪代码：

  
enum State {
    METHOD,
    URL,
    VERSION,
    HEADER_KEY,
    HEADER_VALUE,
    HEADER_END,
    BODY,
    DONE
};

State currentState = METHOD;
std::string buffer;
std::string method, url, version;
std::map<std::string, std::string> headers;
std::string body;
std::string currentKey;

for (char ch : input) {
    switch (currentState) {
        case METHOD:
            if (ch == ' ') {
                currentState = URL;
            } else {
                method += ch;
            }
            break;

        case URL:
            if (ch == ' ') {
                currentState = VERSION;
            } else {
                url += ch;
            }
            break;

        case VERSION:
            if (ch == '\r') {
                // Ignore \r
            } else if (ch == '\n') {
                currentState = HEADER_KEY;
            } else {
                version += ch;
            }
            break;

        case HEADER_KEY:
            if (ch == ':') {
                currentState = HEADER_VALUE;
            } else if (ch == '\r') {
                // Empty line, end of headers
                currentState = HEADER_END;
            } else {
                currentKey += ch;
            }
            break;

        case HEADER_VALUE:
            if (ch == '\r') {
                // Ignore \r
            } else if (ch == '\n') {
                headers[currentKey] = buffer;
                buffer.clear();
                currentKey.clear();
                currentState = HEADER_KEY;
            } else {
                buffer += ch;
            }
            break;

        case HEADER_END:
            if (headers.find("Content-Length") != headers.end()) {
                currentState = BODY;
            } else {
                currentState = DONE;
            }
            break;

        case BODY:
            body += ch;
            if (body.size() == std::stoi(headers["Content-Length"])) {
                currentState = DONE;
            }
            break;

        case DONE:
            // Parsing is complete
            break;
    }
}

3. 特殊情况处理

非法报文:
- 如果某状态下接收到不符合预期的输入（如 METHOD 中遇到 \r\n），可以进入错误状态，记录错误日志。
分块传输（Chunked Transfer-Encoding）:
- 需要设计额外状态解析每个块的大小和数据。
异步数据:
- 在流式数据环境（如 socket）中，每次可能只收到部分报文，需要额外缓冲未完成的数据。

4. 状态机的优势

清晰的逻辑: 将解析过程分成明确的状态，易于维护。
高效性: 逐字节解析，减少内存开销。
可扩展性: 增加状态可以支持更多功能（如分块传输、HTTP/2 等）。

5. 示例流程

假设解析以下 HTTP 请求：

GET /index.html HTTP/1.1
Host: example.com
Content-Length: 5

hello

状态机的执行过程：

METHOD: 解析出 GET，遇到空格切换到 URL。
URL: 解析出 /index.html，遇到空格切换到 VERSION。
VERSION: 解析出 HTTP/1.1，遇到 \r\n 切换到 HEADER_KEY。
HEADER_KEY: 解析出 Host，遇到 : 切换到 HEADER_VALUE。
HEADER_VALUE: 解析出 example.com，遇到 \r\n 切换回 HEADER_KEY。
HEADER_KEY: 解析出 Content-Length，遇到 : 切换到 HEADER_VALUE。
HEADER_VALUE: 解析出 5，遇到 \r\n 切换到 HEADER_END。
HEADER_END: 检测到需要解析 body，进入 BODY 状态。
BODY: 读取 5 个字节 hello，完成后切换到 DONE。

最终解析完成！

如果解析http请求的时候，用户一次性没传完数据，（如果头部都没传完，请求报文长度字段都没传完，怎么办）

当解析 HTTP 请求时，如果用户一次性没有传完数据（例如，头部信息或者请求体未完整接收），这是典型的 流式数据解析 场景。此时，需要对有限状态机进行增强，支持分片数据解析。

以下是详细处理方式：

1. 使用缓冲区处理未完成的数据

在解析 HTTP 报文时，维护一个缓冲区来存储接收到的部分数据：

增量读取: 将每次收到的网络数据追加到缓冲区中。
增量解析: 逐字节解析缓冲区内容，状态机根据当前状态继续处理。

如果数据不足以完成当前解析阶段，就等待下次数据到达。

2. 增强状态机的逻辑

有限状态机的每个状态需要支持 部分解析 和 等待更多数据 的逻辑。以下是增强后的机制：

步骤 1：接收不完整头部时

如果头部未解析完成，缓冲区中可能只包含部分字段。
解析到字段结束标志（如 \r\n）之前，如果数据不足，则保存当前缓冲区并等待新数据到来。

步骤 2：处理动态头部长度

头部中的 Content-Length字段可能不完整：
- 如果未接收到 Content-Length 的完整值，则记录当前位置，等待更多数据。
- 在下次接收到的数据中继续从当前位置解析。

步骤 3：处理跨数据包的解析

如果解析需要读取多个数据包（如请求头跨越多个网络数据块），状态机应支持以下逻辑：
- 当前状态不切换，直到本次任务完成。
- 不完整的数据存入缓冲区，后续数据到达后继续处理。

3. 实现细节

以下是增强状态机的伪代码逻辑：

  
enum State {
    METHOD,
    URL,
    VERSION,
    HEADER_KEY,
    HEADER_VALUE,
    HEADER_END,
    BODY,
    WAIT_DATA,
    DONE
};

State currentState = METHOD;
std::string buffer;  // 缓冲区，存储未处理的网络数据
std::map<std::string, std::string> headers;
std::string body;
size_t contentLength = 0;
size_t bodyReceived = 0;

void parseHTTP(const std::string& data) {
    buffer += data;  // 将新收到的数据追加到缓冲区中

    while (!buffer.empty()) {
        switch (currentState) {
            case METHOD:
                // 解析请求方法
                if (buffer.find(' ') != std::string::npos) {
                    method = buffer.substr(0, buffer.find(' '));
                    buffer.erase(0, buffer.find(' ') + 1);
                    currentState = URL;
                } else {
                    return;  // 数据不足，等待更多
                }
                break;

            case URL:
                // 解析 URL
                if (buffer.find(' ') != std::string::npos) {
                    url = buffer.substr(0, buffer.find(' '));
                    buffer.erase(0, buffer.find(' ') + 1);
                    currentState = VERSION;
                } else {
                    return;  // 数据不足，等待更多
                }
                break;

            case VERSION:
                // 解析 HTTP 版本
                if (buffer.find("\r\n") != std::string::npos) {
                    version = buffer.substr(0, buffer.find("\r\n"));
                    buffer.erase(0, buffer.find("\r\n") + 2);
                    currentState = HEADER_KEY;
                } else {
                    return;  // 数据不足，等待更多
                }
                break;

            case HEADER_KEY:
                // 解析头部字段键
                if (buffer.find(':') != std::string::npos) {
                    currentKey = buffer.substr(0, buffer.find(':'));
                    buffer.erase(0, buffer.find(':') + 1);
                    currentState = HEADER_VALUE;
                } else if (buffer.find("\r\n\r\n") == 0) {
                    currentState = HEADER_END;  // 检测到空行，头部结束
                } else {
                    return;  // 数据不足，等待更多
                }
                break;

            case HEADER_VALUE:
                // 解析头部字段值
                if (buffer.find("\r\n") != std::string::npos) {
                    headers[currentKey] = buffer.substr(0, buffer.find("\r\n"));
                    buffer.erase(0, buffer.find("\r\n") + 2);
                    currentState = HEADER_KEY;
                } else {
                    return;  // 数据不足，等待更多
                }
                break;

            case HEADER_END:
                // 检查是否有请求体
                if (headers.find("Content-Length") != headers.end()) {
                    contentLength = std::stoi(headers["Content-Length"]);
                    currentState = BODY;
                } else {
                    currentState = DONE;  // 无请求体，直接完成
                }
                break;

            case BODY:
                // 解析请求体
                size_t toRead = std::min(buffer.size(), contentLength - bodyReceived);
                body += buffer.substr(0, toRead);
                bodyReceived += toRead;
                buffer.erase(0, toRead);

                if (bodyReceived == contentLength) {
                    currentState = DONE;
                } else {
                    return;  // 数据不足，等待更多
                }
                break;

            case DONE:
                // 解析完成
                return;
        }
    }
}

4. 关键点

缓冲区管理:
- 确保缓冲区中未解析的数据始终保留，避免丢失。
- 在解析完成后删除已处理的数据。
状态保持:
- 如果数据不足，不切换状态，保持当前解析上下文，等待后续数据。
边界条件处理:
- 检测 \r\n、\r\n\r\n 等特殊标志。
- 遇到超长头部或不合理数据，进入错误处理状态。
超时机制:
- 如果在一定时间内未接收到完整数据，可以中止解析，释放资源。

5. 总结

通过使用 有限状态机 + 缓冲区 的组合方法，可以高效地解析分片 HTTP 报文，解决数据不完整的问题。实际网络应用中，这种增量式解析是实现高性能 HTTP 服务器（如 Nginx）的重要基础。

路由表说一下

路由表简介

路由表是网络设备（如路由器、主机）中用于指引数据包传输路径的数据结构。它包含目标网络的相关信息以及到达这些网络的最佳路径，保证数据包能够被正确地转发到目的地。

1. 路由表的作用

路径选择: 确定数据包发送到目的地所需的下一跳地址（Next Hop）。
转发决策: 根据目标 IP 地址匹配路由表中的条目，决定如何转发数据包。
网络管理: 提供设备之间的连接状态和路径信息。

2. 路由表的组成

路由表中的每一条记录通常包括以下信息：

字段	说明
目标网络	数据包的目的网络（通常用 IP 地址和子网掩码表示）。
子网掩码	用于标识目标网络的网络部分和主机部分。
下一跳	转发数据包的下一个设备的 IP 地址（或直接连接）。
出接口	数据包转发时所需使用的网络接口（如 `eth0`、`wlan0`）。
度量值（Metric）	到达目标的成本或优先级（值越小优先级越高）。

3. 路由表的分类

路由表中的路由条目可以按来源分为以下几类：

直接连接路由:
- 指设备直接连接的网络。
- 通常自动生成，无需手动配置。
- 例如，主机 IP 为 192.168.1.1/24，会自动生成 192.168.1.0/24 的路由。
静态路由:
- 管理员手动配置的固定路由。
- 优点: 稳定、可控。
- 缺点: 难以应对动态网络环境。
动态路由:
- 通过动态路由协议（如 OSPF、RIP、BGP）自动学习和更新。
- 优点: 灵活、高效。
- 缺点: 配置复杂，协议运行需要额外开销。
默认路由:
- 当目标地址不匹配任何具体路由时，数据包会被转发到默认路由。
- 通常写作 0.0.0.0/0（IPv4）或 ::/0（IPv6）。

4. 路由表匹配过程

路由表匹配过程基于最长前缀匹配规则（Longest Prefix Match）：

步骤:
1. 根据目标 IP 地址，匹配路由表中最长的前缀（网络号匹配的位数最多）。
2. 如果有多个匹配条目，则选择度量值最小的路由。
3. 找到对应的下一跳地址和出接口，转发数据包。

5. 示例路由表

以下是一台主机的路由表示例：

目标网络	子网掩码	下一跳	出接口	度量值
192.168.1.0	255.255.255.0	-（直连）	eth0	0
10.0.0.0	255.0.0.0	192.168.1.254	eth0	1
0.0.0.0	0.0.0.0	192.168.1.1	eth0	5

说明:

192.168.1.0/24: 直连网络，直接通过 eth0 访问。
10.0.0.0/8: 需要通过网关 192.168.1.254 转发。
0.0.0.0/0: 默认路由，目标不匹配时，转发到 192.168.1.1。

6. 路由表相关命令

Linux 系统

查看路由表:
1 route -n
或使用：
1 ip route show

添加静态路由:

ip route add <目标网络>/<掩码> via <下一跳> dev <接口>

示例:

ip route add 10.0.0.0/8 via 192.168.1.254 dev eth0

删除静态路由:
1 ip route del <目标网络>/<掩码>
设置默认路由:
1 ip route add default via <网关IP>

Windows 系统

查看路由表:
```
route print
```

添加静态路由:

route add <目标网络> mask <子网掩码> <下一跳>

示例:

route add 10.0.0.0 mask 255.0.0.0 192.168.1.254

删除静态路由:
```
route delete <目标网络>
```

7. 路由表的关键特性

动态更新:
- 在使用动态路由协议时，路由表会随着网络拓扑的变化自动更新。
冗余路由:
- 如果一个路由不可用（如下一跳设备断线），可以切换到备用路由。
多路径路由:
- 支持多路径（Multipath）转发，分摊负载，提高可靠性。
安全性:
- 静态路由配置较为安全，不易受动态路由协议中的欺骗攻击影响。

8. 路由表的优化

减少路由条目: 聚合路由（Route Aggregation）以减少路由表大小。
调整度量值: 优化路径选择，优先选择延迟较低的链路。
监控动态变化: 使用动态路由协议监控网络变化，避免路由循环。

总结

路由表是网络设备高效转发数据的核心机制。通过静态路由和动态路由的结合，可以适应各种复杂的网络拓扑结构，为数据传输提供稳定可靠的路径。

路由表为空怎么找到下一跳

如果路由表为空，一般设备无法找到下一跳，数据包也无法被正确转发。但在某些情况下，设备可能仍有机制找到下一跳或处理这种情况。以下是详细分析：

1. 路由表为空的常见情况

误配置: 静态路由或默认路由未配置。
路由协议未生效: 动态路由协议（如 OSPF、BGP）未启动或未学习到路由。
路由清空: 例如管理员手动清空路由表或网络设备刚启动。
新设备初始化: 路由表尚未生成。

2. 设备行为分析

（1）直接连接路由

即使路由表为空，但网络设备通常会知道它自身连接的网络（即直接连接路由）。这些路由信息通常是设备初始化时自动添加的。例如：

设备的 IP 地址为 192.168.1.1/24，则设备会认为 192.168.1.0/24 是直连网络。

在这种情况下，如果目标地址属于直连网络，设备可以直接找到目标，下一跳就是目标设备本身。

（2）默认路由

如果设备有一个默认路由（0.0.0.0/0），即使其余路由表为空，也可以通过默认路由转发数据包。

默认路由的下一跳通常是网关设备（例如 192.168.1.254）。
默认路由的作用是作为兜底方案，将无法匹配的目标地址转发到一个固定网关。

（3）ARP 协议（针对直连网络）

如果目标地址在直连网络中，设备可以通过 ARP (Address Resolution Protocol) 找到目标设备的 MAC 地址，并直接发送数据包，而无需明确的路由条目。

3. 特殊机制处理空路由表

（1）本地转发

如果目标地址是设备自身的 IP 地址：

数据包会被直接处理，而不需要查找路由表。

（2）广播/多播

某些协议允许在没有明确路由时发送广播或多播包，例如：

ARP 请求：查找目标设备的 MAC 地址。
DHCP 请求：动态获取 IP 和网关。

（3）静态或动态路由更新

当路由表为空时，设备可以通过以下方式获取路由：

手动添加静态路由:
- 管理员使用命令手动配置下一跳，例如：
  1 ip route add 0.0.0.0/0 via 192.168.1.1
动态路由协议:
- 如果设备启用了动态路由协议（如 OSPF、BGP），路由表会通过协议逐步填充。

4. 下一跳查找失败时的行为

（1）ICMP 错误消息

当路由表为空且目标地址无法匹配时，设备通常会返回一个 ICMP 错误消息 给源设备：

消息类型: Destination Unreachable (目标不可达)。
原因码: Network Unreachable (网络不可达) 或 No Route to Host (没有到主机的路由)。

（2）丢弃数据包

如果没有任何匹配的路由规则，数据包会被丢弃。这是大多数网络设备的默认行为。

（3）日志记录和告警

某些设备在路由失败时会生成日志或告警信息，提示管理员路由配置有误。

5. 如何解决路由表为空的问题

（1）检查路由配置

验证静态路由是否正确配置：
1 ip route show
如果需要默认路由，确保已正确设置：
1 ip route add default via <网关地址>

（2）启动动态路由协议

如果使用动态路由协议，确保协议已启动并正确配置。例如：
- 启动 OSPF 协议：
  1 2 router ospf 1 network 192.168.1.0 0.0.0.255 area 0

（3）检查接口状态

确保设备的网络接口已启用并处于 UP 状态。

（4）使用 DHCP 自动配置

如果手动配置路由表困难，启用 DHCP 客户端以自动获取 IP 和默认网关：
1 dhclient <接口名>

6. 总结

路由表为空时，能找到下一跳的条件:
- 目标在直连网络中: 通过 ARP 查找目标 MAC 地址。
- 存在默认路由: 使用默认网关作为下一跳。
- 动态路由协议生效: 动态学习到新的路由条目。
如果上述条件均不满足，设备会返回错误消息或丢弃数据包。因此，正确配置静态或动态路由，以及直连网络的默认网关，是确保网络通信正常的关键。

网络编程, 网络编程面经

网络编程面经

本文由作者按照 CC BY 4.0 进行授权