第47周：网络协议深度问答

字数统计: 3.8k字   |   阅读时长≈ 15分

第47周：网络协议深度问答

目标：掌握 TCP/IP 核心问题，能够清晰讲解从驱动到 socket 的完整调用链，定位常见网络故障。

1. TCP 高频问答

1.1 三次握手与四次挥手

Q: 为什么是三次握手而不是两次？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
三次握手的必要性：

  目的：双方确认双向通道都能用

  第一次：SYN（C → S）
    - C 确认：S 能收到（如果失败，连接不建）
  第二次：SYN+ACK（S → C）
    - S 确认：C 能收到
    - C 确认：S 收到了自己的 SYN
  第三次：ACK（C → S）
    - S 确认：C 收到了自己的 SYN+ACK

  两次为什么不行？
    - 客户端发的 SYN 因为网络延迟滞留
    - 重发 SYN 后连接建立
    - 旧 SYN 到达服务端后建立"幻影连接"
    - 三次握手让客户端最后发 ACK 确认

  异常情况：
    - 服务端返回 SYN+ACK 后客户端没回 ACK
    - 服务端重传 SYN+ACK（默认 5 次）
    - 达到上限后释放资源（避免半开连接耗尽）

Q: 为什么挥手是四次而不是三次？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
建立连接：服务端可以合并 SYN+ACK（被动）
关闭连接：服务端通常先回 ACK，单独发 FIN

客户端 FIN（请求关闭）
  ↓
服务端 ACK（确认客户端方向关闭）
服务端业务处理完，发送 FIN
  ↓
客户端 ACK

为什么不能合并 FIN+ACK？
  - 服务端可能还有数据要发
  - 收到 FIN 立刻发 FIN 会丢数据
  - 等待业务处理完再发 FIN

Q: TCP 握手队列

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Linux TCP 握手状态：

  1. SYN 队列（SYN Queue）
     - 收到 SYN，未完成握手
     - 状态：SYN_RCVD
     - 队列：半连接队列
     - 长度：tcp_max_syn_backlog

  2. Accept 队列（Accept Queue）
     - 完成三次握手
     - 状态：ESTABLISHED
     - 队列：等待应用 accept()
     - 长度：min(somaxconn, backlog)

  关键参数：
  - net.ipv4.tcp_max_syn_backlog（半连接）
  - net.core.somaxconn（accept 队列）

  SYN Cookie：
  - 队列满时启用
  - 不分配资源
  - cookie 在 ACK 中携带
  - 验证 cookie 后分配

  调优：
  - 提高 backlog
  - 启用 tcp_syncookies
  - 监控 syn/accept 队列

1.2 TIME_WAIT 问题

Q: 为什么需要 TIME_WAIT？为什么是 2MSL？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
TIME_WAIT 必要性：

  1. 可靠关闭四次挥手
     - 主动关闭方需要 ACK
     - 如果 ACK 丢失，被动方重传 FIN
     - TIME_WAIT 状态可以重发 ACK

  2. 防止"延迟的包"干扰新连接
     - 旧连接的包可能延迟到达
     - 如果立即用同一端口建新连接
     - 老包被当作新连接的数据 → 错乱
     - TIME_WAIT 等到这些包死亡

  2MSL：
  - MSL（Maximum Segment Lifetime）：包在网络中的最大存活时间
  - 经验值：30s ~ 2min（Linux 中 60s）
  - 2MSL = 2 倍：保证旧包都死亡
  - Linux 默认：net.ipv4.tcp_fin_timeout = 60s

Q: TIME_WAIT 太多怎么办？

1
2
3
4
5
6
7
8
9
10
11
12
TIME_WAIT 大量出现的常见场景：
  - 高并发短连接（如 HTTP 服务器）
  - 每个连接关闭都产生 TIME_WAIT
  - 端口耗尽

解决方案：
  1. 调整 tcp_fin_timeout（默认 60s，可以调到 30s）
  2. tcp_tw_reuse = 1（主动方可用）
  3. tcp_tw_recycle = 1（NAT 场景禁用）
  4. tcp_max_tw_buckets = 10000（限制最大数量）
  5. 使用长连接
  6. 多端口监听

1.3 TCP 重传与 RTT

Q: TCP 如何估算 RTT？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
RFC 6298 算法：

SRTT (Smoothed RTT)：
  SRTT_new = (1 - α) × SRTT + α × RTT_sample
  α = 1/8

RTTVAR (RTT Variation)：
  RTTVAR_new = (1 - β) × RTTVAR + β × |SRTT - RTT_sample|
  β = 1/4

RTO (Retransmission Timeout)：
  RTO = SRTT + max(G, K × RTTVAR)
  K = 4
  G = 时钟粒度

实际：
  RTO = SRTT + 4 * RTTVAR
  边界：200ms ≤ RTO ≤ 120s

何时采样？
  - 仅在正常 ACK 时（不重传时）
  - Karn 算法：重传时不采样（避免歧义）
  - 改进：时间戳选项（RFC 1323）

Q: TCP 重传机制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
1. 超时重传（Timeout Retransmission）
   - 等待 RTO
   - RTO 翻倍（指数退避）
   - 最多重试 tcp_retries2 次（默认 15）

2. 快速重传（Fast Retransmit）
   - 收到 3 个重复 ACK
   - 立即重传（不等 RTO）

3. SACK（Selective Acknowledgment）
   - 告诉发送方哪些段已收到
   - 减少不必要的重传

4. 拥塞控制
   - 超时时 cwnd = 1（重启慢启动）
   - 3 dup ACK 时进入快速恢复

1.4 TCP 拥塞控制

Q: 详细讲一下 Cubic 算法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Cubic（Linux 3.0+ 默认）：

关键思想：
  - 用时间而不是 RTT 计算 cwnd
  - 适合高带宽长延迟网络

三个阶段：

1. 慢启动（cwnd < ssthresh）
   - 每个 ACK cwnd += 1
   - 指数增长

2. 拥塞避免（cwnd >= ssthresh）
   - Cubic 函数：
     cwnd = C × (t - K)^3 + W_max
     - t：当前时间
     - K：从 W_max 减少到 cwnd 增长的时间
     - W_max：丢包前的 cwnd
   - 函数特性：先凹后凸，公平利用带宽

3. 快速恢复（3 dup ACK）
   - 新的 ssthresh = cwnd × 0.7
   - cwnd = ssthresh + 3
   - 进入拥塞避免

4. 超时恢复
   - 新的 ssthresh = cwnd / 2
   - cwnd = 1
   - 重新慢启动

对比 BBR：
  - Cubic：基于丢包（loss-based）
  - BBR：基于带宽和延迟（model-based）
  - BBR 在低丢包高延迟网络更优

Q: BBR 与 Cubic 的区别？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Cubic：
  - 假设丢包 = 拥塞
  - 丢包后大幅减速
  - 在 buffer 较大时易出现 bufferbloat

BBR：
  - 主动测量带宽和延迟
  - 持续探测更多带宽
  - 在低丢包网络表现更好
  - 对 bufferbloat 友好

BBR 模式：
  - Startup：指数增长寻找带宽上限
  - Drain：排空队列
  - ProbeBW：探测带宽（90%/100%/110% 循环）
  - ProbeRTT：定期降低 cwnd 测量最小 RTT

启用：
  sysctl net.ipv4.tcp_congestion_control=bbr

1.5 滑动窗口

Q: TCP 滑动窗口的工作机制？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
发送方：
  - 维护发送窗口（左边界 = 已确认，右边界 = 已发送 + 可发送）
  - 发送数据：根据对方窗口
  - 收到 ACK：左边界右移

接收方：
  - 维护接收窗口（左边界 = 已读取，右边界 = 接收的最大 + 窗口大小）
  - 通告窗口大小 = 缓冲区剩余

关键概念：
  - 窗口大小（rwnd）：TCP 头部通告
  - 拥塞窗口（cwnd）：发送方维护
  - 实际窗口 = min(rwnd, cwnd)

零窗口：
  - 接收方缓冲区满
  - 通告零窗口
  - 发送方停止发送
  - 接收方恢复后发"窗口更新"
  - 发送方持续发送"窗口探测"（1 字节）防止死锁

Nagle 算法：
  - 小包合并（避免 Nagle 延迟）
  - 关闭：TCP_NODELAY

1.6 TCP 其他问题

Q: TCP 粘包如何解决？

1
2
3
4
5
6
7
8
9
10
粘包原因：
  - TCP 是字节流协议，无消息边界
  - 多个 write() 的数据可能被合并
  - Nagle 算法加剧

解决方案：
  1. 定长消息：固定长度（简单）
  2. 分隔符：\n、\r\n 等（HTTP 风格）
  3. 长度前缀：消息头指明长度（protobuf、HTTP/2）
  4. 应用层协议：自己设计帧格式

Q: TCP keepalive 和应用层心跳的区别？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
TCP Keepalive（内核）：
  - 空闲一段时间后发送探测包
  - 默认关闭
  - 探测连接是否真的还活着
  - 触发：默认 7200s（2 小时）空闲
  - 不能由应用层数据触发

应用层心跳：
  - 业务级
  - 可在消息中携带业务数据
  - 更灵活
  - 例：WebSocket ping/pong

建议：两者结合
  - TCP keepalive 作为保底
  - 应用层心跳作为主要

2. 内核网络路径详解

2.1 收包路径完整调用链

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
包从网卡到用户态的完整路径：

  网卡（NIC）
    │
    │ 1. 网卡接收数据
    │ 2. DMA 到内存（rxd 描述符指定的地址）
    │ 3. 写入 NIC 寄存器（状态）
    │ 4. 触发硬中断（IRQ）
    │
  ▼
  ┌─────────────────────────────────────┐
  │  硬中断处理（硬中断上下文）              │
  │  1. napi_schedule()                    │
  │  2. 禁用 IRQ                          │
  │  3. 触发 NET_RX_SOFTIRQ                │
  └─────────────────────────────────────┘
    │
    │ 退出硬中断
    │
  ▼
  ┌─────────────────────────────────────┐
  │  软中断处理（softirq 上下文）           │
  │  net_rx_action()                      │
  │  1. NAPI poll                         │
  │  2. 从 ring buffer 收包               │
  │  3. napi_gro_receive()                │
  │  4. 构造 skb                          │
  │  5. enqueue_to_backlog()              │
  │  6. 重新启用 IRQ                      │
  └─────────────────────────────────────┘
    │
    │ backlog queue
    │
  ▼
  ┌─────────────────────────────────────┐
  │  netif_receive_skb()                  │
  │  1. NF_INET_PRE_ROUTING（Netfilter）  │
  │  2. ip_rcv()                          │
  │  3. ip_route_input_noref()            │
  │    - 本地：ip_local_deliver()         │
  │    - 转发：ip_forward()              │
  │  4. NF_INET_LOCAL_IN                  │
  └─────────────────────────────────────┘
    │
    │ TCP 路径
    │
  ▼
  ┌─────────────────────────────────────┐
  │  ip_local_deliver_finish()           │
  │  NF_INET_LOCAL_IN                    │
  │  ip_protocol_deliver_rcu()           │
  │    → tcp_v4_rcv()                    │
  └─────────────────────────────────────┘
    │
    │ TCP 处理
    │
  ▼
  ┌─────────────────────────────────────┐
  │  tcp_v4_rcv()                        │
  │  1. 状态检查（filter）                 │
  │  2. 查 socket（__inet_lookup）        │
  │  3. 已建立：tcp_rcv_established()    │
  │  4. 同步：tcp_v4_do_rcv()            │
  │     - 新连接：tcp_check_req()        │
  │     - 监听：tcp_v4_syn_recv_sock()  │
  └─────────────────────────────────────┘
    │
  ▼
  ┌─────────────────────────────────────┐
  │  tcp_rcv_established()               │
  │  1. tcp_ack()                         │
  │  2. tcp_data_queue()                 │
  │     - 放入 receive_queue             │
  │     - sk_data_ready()                 │
  │  3. ack 包入队                        │
  └─────────────────────────────────────┘
    │
    │ wake_up（epoll 等）
    │
  ▼
  ┌─────────────────────────────────────┐
  │  用户态：read() / recv() / epoll_wait  │
  │  - sys_read → vfs_read → sock_read  │
  │  - tcp_recvmsg                       │
  │  - 从 receive_queue 复制到用户缓冲    │
  │  - 返回给应用                         │
  └─────────────────────────────────────┘

2.2 发包路径

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
用户态 write() → 内核 → 网卡

  ┌─────────────────────────────────────┐
  │  用户态 write(fd, buf, len)         │
  │  ↓                                   │
  │  sys_write()                         │
  │  ↓                                   │
  │  sock_write() / tcp_sendmsg()        │
  └─────────────────────────────────────┘
    │
    ▼
  ┌─────────────────────────────────────┐
  │  TCP 层：tcp_sendmsg()               │
  │  1. 分配 skb                          │
  │  2. 复制用户数据到 skb               │
  │  3. tcp_transmit_skb()              │
  │  4. 校验和计算                        │
  │  5. 加入发送队列                      │
  └─────────────────────────────────────┘
    │
    ▼
  ┌─────────────────────────────────────┐
  │  IP 层：ip_queue_xmit()               │
  │  1. 查路由（skb_dst）                │
  │  2. 填充 IP 头                       │
  │  3. ip_local_out() / dev_queue_xmit()│
  └─────────────────────────────────────┘
    │
    ▼
  ┌─────────────────────────────────────┐
  │  网卡驱动：dev_queue_xmit()          │
  │  1. 队列限制                          │
  │  2. ndo_start_xmit()（驱动回调）     │
  │  3. 构造 TX descriptor                │
  │  4. 网卡 DMA 发送                    │
  │  5. 触发硬中断（发送完成）            │
  └─────────────────────────────────────┘
    │
    ▼
  网卡物理发送

2.3 关键函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
常用内核函数（面试考点）：

  tcp_v4_rcv()：
    - TCP 输入入口
    - 查找 socket
    - 状态机分发

  tcp_v4_do_rcv()：
    - 已建立连接的处理

  tcp_rcv_established()：
    - 已建立连接的数据包处理
    - 快速路径（无选项）

  tcp_ack()：
    - 处理 ACK
    - 滑动窗口更新
    - 拥塞控制回调

  tcp_sendmsg()：
    - 用户态 write 进入 TCP 层

  tcp_transmit_skb()：
    - 构造 TCP 头
    - 校验和
    - 加入发送队列

  ip_queue_xmit()：
    - 查路由
    - 填充 IP 头
    - 调用 dev_queue_xmit

  ip_rcv()：
    - 收包处理
    - 路由查找
    - 决定本地或转发

  netif_receive_skb()：
    - 软中断后
    - 分发到协议层

3. 故障排查

3.1 常见故障与定位

故障 1：连接被拒绝

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
症状：
  - "Connection refused" 错误
  - curl: connect failed
  - 客户端立即失败

排查步骤：
  1. 服务是否在监听？
     netstat -tlnp | grep <port>
     ss -tlnp
  2. 防火墙是否拦截？
     iptables -L -n | grep <port>
     firewalld 状态
  3. 服务是否在运行？
     ps -ef | grep <service>
  4. 日志是否有错误？
     journalctl -u <service> -n 50
  5. SELinux（CentOS）？
     ausearch -m avc
  6. 内核拒绝？
     dmesg | tail

故障 2：连接超时

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
症状：
  - "Connection timed out"
  - hang up

排查：
  1. 网络连通性？
     ping <ip>
     traceroute <ip>
  2. 端口是否可达？
     nc -zv <ip> <port> -w 5
  3. SYN 是否到达？
     tcpdump -i eth0 host <ip> and tcp port <port>
  4. SYN_SENT 状态的连接？
     ss -tn state syn-sent
  5. 防火墙 SYN 拦截？
     iptables -L -n | grep 'flags:'
  6. 路由问题？
     ip route get <ip>

故障 3：丢包

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
症状：
  - "Connection reset"
  - 性能下降
  - 服务端 RST 客户端

排查：
  1. 网卡丢包？
     ip -s link show eth0
     # 看 RX/TX 的 dropped
  2. 软中断丢包？
     cat /proc/net/softnet_stat
     # 第二列是 dropped
  3. conntrack 满？
     cat /proc/sys/net/netfilter/nf_conntrack_count
     cat /proc/sys/net/netfilter/nf_conntrack_max
  4. socket 缓冲区满？
     ss -tm
     # 字段：skmem:(r0,rbXXX,t0,tbXXX)
  5. TCP 丢包？
     ss -ti
     # 看 retrans 字段
  6. 防火墙拒绝？
     iptables -nvL

故障 4：延迟高

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
排查：
  1. RTT 多少？
     ping / mtr
  2. 网卡中断？
     cat /proc/interrupts | grep eth
  3. CPU 软中断？
     mpstat 1
  4. 队列统计？
     ss -ti（看 skmem）
  5. 抓包分析？
     tcpdump -tttt -i eth0
  6. 系统负载？
     top / htop
  7. NUMA 跨节点？
     numastat

3.2 性能分析工具

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# === 网络状态 ===
ss -s             # 摘要
ss -tlnp          # 监听
ss -tnp           # 已连接
ss -s | grep -E 'TCP|UDP'
ss -ti            # TCP 详细信息（含窗口、rtt）

# === 连接跟踪 ===
conntrack -L | wc -l       # 跟踪数量
conntrack -L -p tcp         # TCP 跟踪
cat /proc/net/nf_conntrack  # 原始格式

# === 网卡 ===
ip -s link show eth0
ethtool -S eth0 | grep -E "drop|miss|err"
ip -s -s -s -s link show eth0   # 详细

# === CPU 中断 ===
mpstat 1
top -d 1
cat /proc/softirqs
cat /proc/interrupts | grep eth

# === 抓包 ===
tcpdump -i eth0 -nn -c 1000 -w capture.pcap
tshark -r capture.pcap -Y 'tcp.port==80'
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0'

# === TCP 重传 / RTT ===
ss -ti | grep retrans
nstat -az
netstat -s | grep -E "retrans|out-of-order|fast"

# === bpftrace（高级） ===
bpftrace -e 'kprobe:tcp_retransmit_skb { @[comm] = count(); }'
bpftrace -e 'kprobe:tcp_connect { @[comm] = count(); }'

# === perf ===
perf record -g -p $(pidof <process>) -- sleep 5
perf report

3.3 常见连接状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
LISTEN：监听
ESTABLISHED：已建立
SYN_SENT：已发 SYN（主动连接）
SYN_RECV：收到 SYN（半开）
FIN_WAIT1：主动关闭方发了 FIN
FIN_WAIT2：收到对方 FIN ACK
CLOSE_WAIT：被动关闭方收到 FIN
LAST_ACK：发了 FIN 等对方 ACK
TIME_WAIT：等 2MSL
CLOSED：完全关闭

异常状态：
SYN_SENT 多：连接建立失败（防火墙）
CLOSE_WAIT 多：服务端未关闭（bug）
TIME_WAIT 多：短连接过多
SYN_RECV 多：SYN flood 攻击

4. 协议族对比

4.1 TCP vs UDP

特性 TCP UDP
连接 面向连接 无连接
可靠 可靠（ACK + 重传） 不可靠
顺序 保序 不保序
流控 滑动窗口 无
拥塞 拥塞控制 无（应用负责）
开销 大头（20B +） 小头（8B）
延迟 较高（握手 + ACK） 低
适用 HTTP、FTP、邮件 DNS、视频、实时

4.2 HTTP/1.1 vs HTTP/2 vs HTTP/3

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
HTTP/1.1：
  - 文本协议
  - 串行请求（队头阻塞）
  - keep-alive
  - 6 个并发连接限制

HTTP/2：
  - 二进制分帧
  - 多路复用（单连接多流）
  - 头部压缩（HPACK）
  - 服务端推送

HTTP/3：
  - 基于 QUIC（UDP）
  - 解决队头阻塞（每流独立）
  - 内置 TLS 1.3
  - 0-RTT 握手
  - 连接迁移

4.3 IPv4 vs IPv6

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
IPv4：
  - 32 位地址
  - 约 43 亿
  - NAT 缓解地址不足
  - 头部长度可变（20B+）
  - 校验和（可选）
  - 广播

IPv6：
  - 128 位地址
  - 几乎无限
  - 无需 NAT
  - 固定头 40B
  - 简化头部（更快路由）
  - 链式路由头（扩展性）
  - 组播（无广播）
  - 内置 IPsec

4.4 长连接 vs 短连接

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
短连接：
  - 每次请求建连接
  - 适合请求频率低
  - 但握手开销大
  - TIME_WAIT 多
  - 例：HTTP（早期）、SMTP

长连接：
  - 一次连接多次请求
  - 减少握手开销
  - 适合高频交互
  - 例：WebSocket、数据库连接池

连接池：
  - 预先建立 N 个连接
  - 复用这些连接
  - 性能最优
  - 例：数据库连接池

5. 性能调优实战

5.1 调优原则

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
原则 1：测量先行
  - 用工具（perf, ss, bpftrace）测量现状
  - 不要盲目调参

原则 2：先低风险
  - 调整已知的默认值
  - 避免修改未知参数

原则 3：一次一个
  - 每次只改一个参数
  - 验证效果

原则 4：记录
  - 记录每次调整
  - 方便回滚
  - 形成知识库

5.2 关键参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# === TCP 缓冲区 ===
# 高带宽下需要大窗口
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# === 队列 ===
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# === TIME_WAIT ===
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# === 端口范围 ===
net.ipv4.ip_local_port_range = 1024 65535

# === TCP 优化 ===
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_congestion_control = bbr

# === 内存 ===
net.core.rmem_default = 262144
net.core.wmem_default = 262144
vm.swappiness = 10

6. 面试中的网络问题应对

6.1 表达框架

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
网络问题回答框架（5 步）：

1. 问题理解：先复述问题
   "我理解您是说..."

2. 知识点：说出相关概念
   "这涉及 TCP 的..."

3. 详细解释：从底层说起
   "内核处理过程是..."

4. 图示：用白板或文档
   "流程图是这样的..."

5. 实际案例：举具体例子
   "我曾经遇到过..."

示例（为什么 TIME_WAIT 多）：
  1. 复述：连接关闭后主动方进入 TIME_WAIT
  2. 概念：TIME_WAIT 是 TCP 状态
  3. 详细：保证 ACK 到达 + 防止旧包干扰
  4. 图示：四次挥手
  5. 案例：HTTP 高并发场景
  6. 解决：调 fin_timeout，开 tw_reuse

6.2 常见追问

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Q: 你说 2MSL，那 2MSL 应该是 2 * 60s，TIME_WAIT 不是要等 2 分钟吗？
A: Linux 默认 tcp_fin_timeout = 60s
   但实际的 MSL 远小于 60s
   TIME_WAIT 等 2*fin_timeout

Q: TIME_WAIT 多到耗尽端口怎么办？
A: 1. 减少 fin_timeout
   2. 启用 tcp_tw_reuse
   3. 使用长连接
   4. 调整 ip_local_port_range

Q: 为什么不用 tcp_tw_recycle？
A: tcp_tw_recycle 启用后，主动关闭方
   会根据时间戳丢弃旧包
   在 NAT 场景下会误杀合法连接（多个客户端共享 IP）
   Linux 4.12+ 已移除

7. 总结与建议

1
2
3
4
5
6
7
8
准备网络面试的方法：

1. 理解每个 TCP 状态机的转换
2. 画从网卡到 socket 的完整流程
3. 了解每个内核函数的作用
4. 准备真实故障排查经验
5. 关注 RFC 文档
6. 阅读《TCP/IP 详解 卷 1：协议》
赏

谢谢你请我吃糖果

支付宝
微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

主要涉及技术：
Java后端开发、Linux开发、
公众号开发、开源爱好者、Linux

联系QQ:562054870