计算机网络基础与HTTP协议本文从网络分层模型、TCP可靠传输机制、HTTP协议演进、HTTPS/TLS握手流程、缓存策

概述

计算机网络是互联网应用的基石,HTTP协议是Web服务的核心协议。作为后端工程师,深入理解网络分层模型、TCP/IP协议栈、HTTP协议演进(HTTP/1.x → HTTP/2 → HTTP/3)、HTTPS加密原理、缓存机制、身份认证等核心知识,不仅是面试高频考点,更是解决生产环境网络问题、优化系统性能的必备技能。本文从网络分层模型、TCP可靠传输机制、HTTP协议演进、HTTPS/TLS握手流程、缓存策略、身份认证方案等多个维度,结合电商系统实战案例,深入剖析计算机网络的核心原理与最佳实践,帮助读者构建完整的网络知识体系,在面试和实际工作中游刃有余。

一、理论知识与核心概念

1.1 为什么后端工程师必须懂网络?

在微服务架构、分布式系统、云原生应用大行其道的今天,网络通信无处不在。后端工程师每天都在与网络打交道:

典型场景:

服务间调用: 微服务之间通过HTTP/gRPC/Dubbo通信,跨机房RPC调用延迟优化
数据库连接: MySQL连接池、Redis连接超时、连接泄漏问题排查
缓存设计: HTTP缓存(浏览器缓存、CDN缓存)、分布式缓存(Redis)
负载均衡: Nginx反向代理、四层LB vs 七层LB选型
API设计: RESTful API最佳实践、幂等性设计、超时重试策略
安全防护: HTTPS配置、CSRF防御、XSS防御、SQL注入防御
性能优化: TCP连接池复用、HTTP/2多路复用、HTTPS握手优化
故障排查: 网络抖动、丢包、超时、TIME_WAIT过多、连接池耗尽

不懂网络的代价:

线上故障无从下手: 接口超时、连接失败、响应慢,无法定位问题根因
性能优化没有思路: 盲目加机器、加缓存,治标不治本
面试频繁被问倒: TCP三次握手、HTTPS握手、HTTP/2多路复用是高频面试题

懂网络的价值:

快速定位线上问题: 通过tcpdump、Wireshark抓包分析,精准定位网络层问题
系统设计更合理: 合理使用连接池、超时配置、重试策略,提升系统稳定性
性能优化有抓手: HTTP/2升级、HTTPS优化、CDN加速,显著提升用户体验
面试脱颖而出: 网络原理 + 生产实战经验,是高级工程师的硬通货

1.2 核心概念

OSI七层模型 vs TCP/IP四层模型:

OSI七层: 理论参考模型(物理层、数据链路层、网络层、传输层、会话层、表示层、应用层)
TCP/IP四层: 实际应用模型(网络接口层、网络层、传输层、应用层)
后端开发重点: 应用层(HTTP/HTTPS/DNS)、传输层(TCP/UDP)、网络层(IP路由)

TCP vs UDP:

TCP: 面向连接、可靠传输、流量控制、拥塞控制,适合HTTP、MySQL、Redis
UDP: 无连接、不可靠、低延迟,适合DNS、视频直播、游戏

HTTP vs HTTPS:

HTTP: 明文传输,端口80,易被窃听和篡改
HTTPS: HTTP + TLS/SSL加密,端口443,保证数据机密性、完整性、身份认证

Cookie vs Session vs Token:

Cookie: 浏览器存储,每次请求自动携带,容量4KB,易被篡改
Session: 服务器存储,通过Cookie传递SessionID,占用服务器内存
Token (JWT): 无状态认证,服务器不存储,适合分布式系统、微服务架构

二、OSI七层模型与TCP/IP四层模型

2.1 OSI七层模型详解

OSI(Open System Interconnection)七层模型是国际标准化组织(ISO)提出的网络通信理论模型,将网络通信划分为7个层次,自底向上依次为:

第1层: 物理层 (Physical Layer)

作用: 传输比特流(0和1),定义物理接口、电压、传输速率
设备: 网卡、光纤、双绞线、集线器(Hub)
数据单元: 比特(Bit)
典型协议: IEEE 802.3 (以太网物理层标准)

第2层: 数据链路层 (Data Link Layer)

作用: 帧传输,MAC地址寻址,差错检测(CRC校验),流量控制
设备: 交换机(Switch)、网桥(Bridge)
数据单元: 帧(Frame)
典型协议: Ethernet(以太网)、PPP、HDLC
MAC地址: 48位物理地址,全球唯一,如00:1A:2B:3C:4D:5E

第3层: 网络层 (Network Layer)

作用: IP寻址,路由选择,分组转发,跨网络通信
设备: 路由器(Router)、三层交换机
数据单元: 包(Packet) / 数据报(Datagram)
典型协议:
- IP: Internet Protocol,核心协议,负责寻址和路由
- ICMP: 控制报文协议,ping命令使用的协议
- ARP: 地址解析协议,IP地址 → MAC地址映射
- IGMP: 组播协议

第4层: 传输层 (Transport Layer)

作用: 端到端连接,可靠传输,流量控制,拥塞控制,端口号寻址
协议:
- TCP: 面向连接,可靠传输,流量控制,拥塞控制
- UDP: 无连接,不可靠,低延迟,无流量控制
数据单元: 段(Segment, TCP) / 数据报(Datagram, UDP)
端口号: 0-65535,标识应用程序(如HTTP 80, HTTPS 443, MySQL 3306)

第5层: 会话层 (Session Layer)

作用: 建立、管理、终止会话,会话同步,断点续传
典型协议: RPC、SQL、NFS

第6层: 表示层 (Presentation Layer)

作用: 数据格式转换、加密解密、压缩解压
典型协议: SSL/TLS、JPEG、MPEG、ASCII、Unicode

第7层: 应用层 (Application Layer)

作用: 为应用程序提供网络服务,直接与用户交互
典型协议: HTTP/HTTPS、FTP、SMTP、DNS、Telnet、SSH

2.2 TCP/IP四层模型详解

TCP/IP四层模型是实际互联网使用的协议模型,自底向上依次为:

第1层: 网络接口层 (Network Access Layer)

对应OSI: 物理层 + 数据链路层
作用: 物理层比特流传输 + 数据链路层帧传输、MAC寻址
设备: 网卡、交换机
协议: Ethernet(以太网)、Wi-Fi、PPP
数据单元: 帧(Frame) + 比特(Bit)

第2层: 网络层 / 互联网层 (Internet Layer)

对应OSI: 网络层
作用: IP寻址,路由选择,分组转发,跨网络通信
设备: 路由器
协议: IP (IPv4/IPv6)、ICMP、ARP、IGMP
数据单元: 包(Packet) / IP数据报

第3层: 传输层 (Transport Layer)

对应OSI: 传输层
作用: 端到端连接,可靠传输,端口号寻址
协议: TCP、UDP
数据单元: 段(Segment, TCP) / 数据报(Datagram, UDP)

第4层: 应用层 (Application Layer)

对应OSI: 会话层 + 表示层 + 应用层
作用: 为应用程序提供网络服务,数据格式定义,加密,会话管理
协议: HTTP/HTTPS、FTP、SMTP、DNS、SSH、Telnet
数据单元: 消息(Message) / 数据(Data)

2.3 数据封装与解封装流程

发送端 - 数据封装 (Encapsulation):

应用层数据自顶向下,每层添加自己的头部信息(Header):

应用层: HTTP请求 (如GET /api/users HTTP/1.1)
传输层: +TCP头部(20字节) → TCP段 (包含源端口、目标端口、序列号、确认号)
网络层: +IP头部(20字节) → IP包 (包含源IP、目标IP)
数据链路层: +以太网头部(14字节) + FCS尾部(4字节) → 以太网帧 (包含源MAC、目标MAC)
物理层: 帧 → 比特流 → 电信号/光信号 → 物理介质传输

接收端 - 数据解封装 (Decapsulation):

数据自底向上,每层移除自己的头部信息:

物理层: 电信号/光信号 → 比特流 → 帧
数据链路层: 移除以太网头部和FCS,验证MAC地址 → IP包
网络层: 移除IP头部,验证目标IP地址 → TCP段
传输层: 移除TCP头部,根据端口号交给应用程序 → 应用层数据
应用层: 应用程序接收HTTP响应数据

关键要点:

每层只关心自己的头部,下层看到的是上层数据+头部的整体,实现了层次解耦
头部开销: 以太网头部14B + IP头部20B + TCP头部20B + FCS尾部4B = 58字节
MTU (Maximum Transmission Unit): 以太网默认1500字节,IP包超过MTU会分片
MSS (Maximum Segment Size): TCP数据段最大长度 = MTU - IP头部 - TCP头部 = 1500 - 20 - 20 = 1460字节

三、TCP协议深度剖析

3.1 TCP vs UDP对比

维度	TCP	UDP
连接性	面向连接(三次握手建立连接)	无连接(直接发送数据)
可靠性	可靠传输(确认、重传、排序)	不可靠(不保证到达、顺序、不重复)
流量控制	支持(滑动窗口)	不支持
拥塞控制	支持(慢启动、拥塞避免、快重传、快恢复)	不支持
传输速度	慢(头部20字节,需确认)	快(头部8字节,无需确认)
应用场景	HTTP、HTTPS、FTP、MySQL、Redis、SSH	DNS、视频直播、游戏、物联网
适用需求	数据完整性要求高	实时性要求高,容忍少量丢包

为什么HTTP使用TCP而不是UDP?

HTTP需要保证数据完整性和顺序性(HTML、CSS、JS必须完整下载)
TCP提供可靠传输,自动重传丢失的数据包
TCP流量控制和拥塞控制,避免网络拥堵

为什么视频直播使用UDP而不是TCP?

实时性要求高,丢几帧画面可接受,但延迟不可接受
UDP无需等待确认,延迟低
TCP重传机制会增加延迟,导致画面卡顿

3.2 TCP三次握手 (Three-Way Handshake)

握手流程:

第一次握手: 客户端 → 服务端: SYN=1, seq=x
- 客户端发送SYN(同步)报文,请求建立连接
- 客户端状态: CLOSED → SYN_SENT
第二次握手: 服务端 → 客户端: SYN=1, ACK=1, seq=y, ack=x+1
- 服务端收到SYN,发送SYN+ACK报文,确认客户端的SYN,并请求建立连接
- 服务端状态: LISTEN → SYN_RCVD
第三次握手: 客户端 → 服务端: ACK=1, ack=y+1
- 客户端收到SYN+ACK,发送ACK报文,确认服务端的SYN
- 客户端状态: SYN_SENT → ESTABLISHED
- 服务端状态: SYN_RCVD → ESTABLISHED

连接建立成功,双方进入ESTABLISHED状态,开始数据传输。

为什么需要三次握手?

防止失效的连接请求:
- 客户端发送的第一个SYN请求可能在网络中滞留,延迟到达服务端
- 如果只有两次握手,服务端收到失效的SYN后会建立连接,但客户端已经关闭,造成资源浪费
- 三次握手: 客户端可以通过第三次ACK确认是否真的需要这个连接
同步双方序列号 (seq):
- TCP是可靠传输,需要序列号保证数据顺序
- 三次握手同步双方的初始序列号(ISN, Initial Sequence Number)
确认双方收发能力正常:
- 第一次握手: 服务端确认客户端发送能力、服务端接收能力正常
- 第二次握手: 客户端确认服务端发送能力、客户端接收能力正常
- 第三次握手: 服务端确认客户端接收能力正常 → 双方收发能力都确认OK

两次握手为什么不行?

服务端无法确认客户端接收能力,可能建立失效连接
无法同步客户端的初始序列号

四次握手没必要吗?

三次握手已经足够确认双方收发能力和同步序列号

3.3 TCP四次挥手 (Four-Way Teardown)

挥手流程:

第一次挥手: 客户端 → 服务端: FIN=1, seq=u
- 客户端发送FIN(结束)报文,请求关闭连接
- 客户端状态: ESTABLISHED → FIN_WAIT_1
第二次挥手: 服务端 → 客户端: ACK=1, ack=u+1
- 服务端收到FIN,发送ACK报文,确认关闭请求
- 服务端状态: ESTABLISHED → CLOSE_WAIT
- 客户端状态: FIN_WAIT_1 → FIN_WAIT_2
第三次挥手: 服务端 → 客户端: FIN=1, ACK=1, seq=w, ack=u+1
- 服务端处理完剩余数据,发送FIN报文,请求关闭连接
- 服务端状态: CLOSE_WAIT → LAST_ACK
第四次挥手: 客户端 → 服务端: ACK=1, ack=w+1
- 客户端收到FIN,发送ACK报文,确认关闭
- 客户端状态: FIN_WAIT_2 → TIME_WAIT → (等待2MSL) → CLOSED
- 服务端状态: LAST_ACK → CLOSED

连接完全关闭。

为什么需要四次挥手?

TCP是全双工通信:
- 客户端和服务端都可以独立发送和接收数据
- 关闭连接需要分别关闭发送方向和接收方向,不能同时关闭
- 第一、二次挥手: 客户端→服务端方向关闭(客户端不再发送数据,但可接收)
- 第三、四次挥手: 服务端→客户端方向关闭(服务端不再发送数据,但可接收)
第二次和第三次不能合并:
- 服务端收到FIN后,可能还有数据未发送完,需要先ACK确认,等数据发完再发FIN

TIME_WAIT状态的作用 (2MSL):

MSL (Maximum Segment Lifetime): 报文最大生存时间,通常1分钟
2MSL = 2分钟,确保最后一个ACK能够到达服务端
若ACK丢失,服务端会重发FIN,客户端重新发送ACK
避免旧连接的数据包干扰新连接

TIME_WAIT过多的问题:

TIME_WAIT状态出现在主动关闭方(通常是客户端或HTTP短连接的服务端)
大量TIME_WAIT占用端口(0-65535),可能导致端口耗尽,无法建立新连接
解决方案: 使用长连接(HTTP/1.1 keep-alive)、连接池复用、调整系统参数

# Linux系统参数优化
net.ipv4.tcp_tw_reuse=1          # 允许TIME_WAIT socket重用于新连接
net.ipv4.tcp_tw_recycle=1        # 快速回收TIME_WAIT socket (NAT环境慎用)
net.ipv4.tcp_fin_timeout=30      # FIN_WAIT_2超时时间30秒 (默认60秒)

3.4 TCP流量控制 (Flow Control) - 滑动窗口

问题: 发送方发送速度太快,接收方处理不过来,导致数据丢失。

解决方案: 滑动窗口 (Sliding Window) 机制,接收方告诉发送方自己的接收窗口大小,发送方控制发送速度。

核心字段: TCP头部的窗口大小(Window Size) 字段(16位,最大65535字节)

工作原理:

接收方在ACK报文中告知发送方接收窗口大小(剩余缓冲区空间)
发送方根据接收窗口调整发送速度,不能超过接收窗口大小
接收方处理数据后,窗口变大,通知发送方可以继续发送

示例:

接收方接收窗口: 10KB
发送方已发送未确认数据: 6KB
发送方还能发送: 10KB - 6KB = 4KB

接收方处理了3KB数据,发送ACK,窗口变为: 10KB - 3KB + 3KB = 10KB
发送方收到ACK后,可继续发送

零窗口问题:

接收方缓冲区满,接收窗口为0,发送方停止发送
发送方定期发送零窗口探测报文(ZWP),询问接收方窗口是否恢复

3.5 TCP拥塞控制 (Congestion Control)

问题: 网络拥堵,大量数据包丢失,重传导致网络更加拥堵。

解决方案: 拥塞控制算法,发送方根据网络状况动态调整发送速度。

核心概念:

拥塞窗口 (cwnd, Congestion Window): 发送方维护的窗口,表示网络能承受的数据量
慢启动阈值 (ssthresh): 拥塞窗口的阈值,超过后进入拥塞避免阶段

四大算法:

1. 慢启动 (Slow Start):

初始状态: cwnd = 1 MSS (Maximum Segment Size,通常1460字节)
指数增长: 每收到一个ACK,cwnd翻倍 (1 → 2 → 4 → 8 → 16 ...)
目的: 快速探测网络容量

2. 拥塞避免 (Congestion Avoidance):

触发条件: cwnd >= ssthresh (慢启动阈值)
线性增长: 每个RTT(往返时延),cwnd + 1 MSS
目的: 避免网络拥堵

3. 快重传 (Fast Retransmit):

触发条件: 收到3个重复ACK (说明后续数据包丢失)
立即重传: 不等超时,立即重传丢失的数据包
目的: 快速恢复丢包

4. 快恢复 (Fast Recovery):

触发条件: 快重传后
调整窗口: ssthresh = cwnd / 2, cwnd = ssthresh + 3 MSS
目的: 避免慢启动,快速恢复传输速度

拥塞控制流程:

1. 慢启动: cwnd指数增长 (1 → 2 → 4 → 8 → 16 → 32 → 64)
2. cwnd达到ssthresh (假设64): 进入拥塞避免,线性增长 (64 → 65 → 66 → 67)
3. 发生丢包 (收到3个重复ACK): 快重传 + 快恢复
   - ssthresh = cwnd / 2 = 67 / 2 = 33
   - cwnd = ssthresh + 3 = 33 + 3 = 36
   - 继续拥塞避免,线性增长 (36 → 37 → 38)
4. 发生超时: 慢启动重新开始
   - ssthresh = cwnd / 2
   - cwnd = 1

四、HTTP协议深度剖析

4.1 HTTP协议演进历程

HTTP/0.9 (1991):

仅支持GET方法,只能传输HTML文本
无HTTP头,无状态码
请求完成后立即断开连接

HTTP/1.0 (1996):

支持POST、HEAD方法
引入HTTP头(Header),支持Content-Type、Content-Length
引入状态码(200、404、500等)
支持缓存(Expires、Last-Modified)
缺点: 短连接,每次请求都需要建立TCP连接,性能差

HTTP/1.1 (1997, 至今主流):

默认长连接 (keep-alive): 一个TCP连接可发送多个HTTP请求,避免频繁握手
管道化 (Pipelining): 允许一次发送多个请求,无需等待响应(浏览器默认未启用,存在队头阻塞问题)
Host头部: 支持虚拟主机,一个IP多个域名
分块传输 (Chunked Transfer Encoding): 支持流式传输,无需提前知道Content-Length
缓存优化: 引入ETag、Cache-Control
缺点: 队头阻塞 (Head-of-Line Blocking): 前一个请求未完成,后续请求被阻塞

HTTP/2 (2015):

二进制分帧 (Binary Framing): 数据以二进制帧传输,替代HTTP/1.x的文本协议
多路复用 (Multiplexing): 一个TCP连接可并行传输多个请求和响应,彻底解决队头阻塞
头部压缩 (HPACK): 压缩HTTP头部,减少传输开销
服务器推送 (Server Push): 服务器主动推送资源(如CSS、JS),无需客户端请求
流优先级 (Stream Priority): 客户端可指定资源加载优先级
缺点: 基于TCP,仍存在TCP队头阻塞(丢包时整个TCP连接阻塞)

HTTP/3 (2022, 基于QUIC):

基于UDP: 使用QUIC协议(Quick UDP Internet Connections),替代TCP
彻底解决TCP队头阻塞: QUIC在UDP基础上实现可靠传输,单个流丢包不影响其他流
0-RTT连接建立: 复用之前的连接信息,握手时间为0
连接迁移: 切换网络(Wi-Fi → 4G)时,连接不中断
内置TLS 1.3加密: 安全性和性能兼顾
应用: Google、Cloudflare、Facebook已大规模使用

4.2 HTTP/1.1 vs HTTP/2 vs HTTP/3对比

维度	HTTP/1.1	HTTP/2	HTTP/3
传输协议	TCP	TCP	UDP (QUIC)
数据格式	文本	二进制帧	二进制帧
连接复用	长连接(keep-alive)	多路复用(一个TCP连接)	多路复用(一个QUIC连接)
队头阻塞	应用层队头阻塞	解决应用层队头阻塞,但仍有TCP队头阻塞	彻底解决队头阻塞
头部压缩	无	HPACK压缩	QPACK压缩
服务器推送	不支持	支持	支持
握手时延	TCP 3次握手 + TLS 2-RTT	TCP 3次握手 + TLS 2-RTT	QUIC 1-RTT / 0-RTT
连接迁移	不支持(切换网络需重新建立连接)	不支持	支持(连接ID不变)
适用场景	传统Web应用	高并发Web应用、移动端H5	弱网环境、移动端App

4.3 HTTP/2多路复用原理

HTTP/1.1的问题:

浏览器对同一域名最多并发6-8个TCP连接
一个TCP连接同时只能处理一个请求,后续请求被阻塞(队头阻塞)
为了并发,需要域名分片(多个子域名)、雪碧图(合并图片)、文件合并(合并CSS/JS)

HTTP/2多路复用:

一个TCP连接并行传输多个请求和响应
每个请求/响应对应一个流(Stream),流ID唯一标识
每个流拆分成多个帧(Frame),帧在TCP连接中乱序传输,接收端根据流ID重组
彻底解决应用层队头阻塞,无需域名分片、文件合并

示例:

HTTP/1.1:
请求1 → 响应1 → 请求2 → 响应2 → 请求3 → 响应3 (串行)

HTTP/2:
请求1、请求2、请求3 → (帧乱序传输) → 响应1、响应2、响应3 (并行)

性能提升:

首屏加载时间减少30-50%
无需域名分片,减少DNS查询时间
无需文件合并,提高缓存命中率

五、HTTPS加密原理

5.1 为什么需要HTTPS?

HTTP的三大安全问题:

窃听 (Eavesdropping): 明文传输,中间人可截获数据
篡改 (Tampering): 数据可被中间人修改,如注入广告、恶意脚本
冒充 (Impersonation): 无法验证服务器身份,可能访问假冒网站

HTTPS = HTTP + TLS/SSL 加密:

机密性 (Confidentiality): 数据加密传输,中间人无法窃听
完整性 (Integrity): 数据摘要校验,防止篡改
身份认证 (Authentication): 数字证书验证服务器身份,防止冒充

5.2 对称加密 vs 非对称加密

对称加密 (Symmetric Encryption):

加密和解密使用相同密钥
典型算法: AES-128、AES-256、DES、3DES
优点: 速度快,加密效率高,适合大量数据加密
缺点: 密钥分发困难,如何安全地传输密钥?

非对称加密 (Asymmetric Encryption):

公钥加密,私钥解密 (或私钥签名,公钥验证)
典型算法: RSA、ECC(椭圆曲线加密)
优点: 无需预先共享密钥,公钥公开,私钥保密
缺点: 速度慢,计算开销大(比对称加密慢1000倍以上)

HTTPS混合加密方案:

握手阶段: 使用RSA非对称加密,安全地交换Pre-Master Secret,生成会话密钥
数据传输阶段: 使用AES对称加密,快速加密大量HTTP数据
完美结合: 既保证了密钥交换的安全性,又保证了数据传输的高效性

5.3 HTTPS/TLS握手流程 (TLS 1.2)

握手流程 (2-RTT):

Step 1: Client Hello (客户端):

TLS版本: TLS 1.2
客户端随机数 (Client Random)
支持的加密套件列表 (如TLS_RSA_WITH_AES_128_GCM_SHA256)

Step 2: Server Hello + Certificate (服务端):

确认TLS版本: TLS 1.2
服务器随机数 (Server Random)
选择的加密套件 (如TLS_RSA_WITH_AES_128_GCM_SHA256)
服务器证书 (包含服务器公钥 + CA签名)
Server Hello Done

Step 3: 客户端验证证书:

证书是否过期?
CA签名是否有效? (使用浏览器内置的根证书验证)
域名是否匹配? (证书中的域名与访问的域名是否一致)
✅ 验证通过,提取服务器公钥

Step 4: 生成Pre-Master Secret (客户端):

随机生成48字节Pre-Master Secret
使用服务器公钥(RSA)加密Pre-Master Secret

Step 5: Client Key Exchange (客户端 → 服务端):

发送加密的Pre-Master Secret (只有服务器私钥能解密)
Change Cipher Spec (切换加密规格)
Encrypted Handshake Message (Finished) - 用会话密钥加密的握手摘要,验证握手过程完整性

Step 6: 服务端解密Pre-Master Secret:

使用服务器私钥(RSA)解密,得到Pre-Master Secret

Step 7: 双方生成Session Key (会话密钥):

Session Key = PRF(Pre-Master Secret + Client Random + Server Random)

PRF (Pseudo-Random Function): 伪随机函数,基于HMAC-SHA256
生成的会话密钥用于对称加密(AES-128),后续所有数据都用此密钥加密

Step 8: Server Finished (服务端 → 客户端):

Change Cipher Spec
Encrypted Handshake Message (用会话密钥加密)

握手完成,使用会话密钥(AES-128)进行对称加密通信。

关键要点:

Pre-Master Secret只有客户端和服务器知道,中间人无法解密
Session Key由三个随机数生成,每次握手都不同,保证前向安全 (Forward Secrecy)
即使服务器私钥泄露,之前的会话密钥也无法破解

5.4 数字证书与CA认证

数字证书 (Digital Certificate):

证书内容: 域名、公钥、证书有效期、证书颁发机构(CA)、CA签名
证书作用: 证明服务器身份,防止中间人冒充

CA (Certificate Authority) 证书颁发机构:

根CA: 浏览器内置的受信任CA (如DigiCert、Let's Encrypt、GlobalSign)
证书链: 服务器证书 → 中间CA证书 → 根CA证书

证书验证流程:

浏览器收到服务器证书
验证证书有效期是否过期
验证域名是否匹配
使用CA公钥验证CA签名 (签名 = CA私钥加密的证书摘要)
若CA是中间CA,继续验证中间CA的证书,直到根CA
✅ 验证通过,信任服务器公钥

证书申请流程:

生成服务器私钥和公钥
提交CSR (Certificate Signing Request) 给CA,包含域名、公钥、组织信息
CA验证域名所有权 (DNS验证、文件验证、邮件验证)
CA签发证书 (CA私钥签名)
部署证书到服务器

免费证书: Let's Encrypt,支持自动化申请和续期 (certbot工具)

六、HTTP缓存机制

HTTP缓存是Web性能优化的核心手段,合理使用缓存可减少服务器负载、降低带宽消耗、提升用户体验。

6.1 缓存分类

按存储位置分:

浏览器缓存: 浏览器本地缓存(Memory Cache、Disk Cache)
代理缓存: CDN、Nginx反向代理缓存
服务端缓存: Redis、Memcached

按缓存策略分:

强缓存: 命中后直接使用缓存,不发送请求到服务器
协商缓存: 发送请求到服务器,验证资源是否更新,未更新返回304 Not Modified

6.2 强缓存 (Strong Cache)

核心字段: Cache-Control (HTTP/1.1) 和 Expires (HTTP/1.0)

Cache-Control指令:

Cache-Control: max-age=3600              # 缓存3600秒(1小时)
Cache-Control: public                    # 可被任何缓存(浏览器、CDN)缓存
Cache-Control: private                   # 只能被浏览器缓存,不能被CDN缓存
Cache-Control: no-cache                  # 不使用强缓存,必须协商缓存
Cache-Control: no-store                  # 不缓存,每次都请求服务器
Cache-Control: must-revalidate           # 缓存过期后必须重新验证

Expires (HTTP/1.0):

Expires: Wed, 21 Oct 2025 07:28:00 GMT  # 绝对过期时间

优先级: Cache-Control > Expires

示例:

# 静态资源(CSS、JS、图片)强缓存1年
Cache-Control: public, max-age=31536000

工作流程:

浏览器请求资源
检查本地缓存是否存在且未过期
命中强缓存: 直接使用本地缓存,状态码200 (from cache)
未命中: 发送请求到服务器

6.3 协商缓存 (Negotiated Cache)

核心字段: ETag / If-None-Match 和 Last-Modified / If-Modified-Since

ETag (Entity Tag) - 资源指纹:

服务器生成的资源唯一标识(如MD5哈希值)
资源内容变化,ETag变化

# 首次响应
HTTP/1.1 200 OK
ETag: "5d8c72a5edda8d6a:3239"
Cache-Control: no-cache

# 后续请求
GET /api/users HTTP/1.1
If-None-Match: "5d8c72a5edda8d6a:3239"

# 服务器响应 (资源未变化)
HTTP/1.1 304 Not Modified
ETag: "5d8c72a5edda8d6a:3239"

Last-Modified / If-Modified-Since - 最后修改时间:

# 首次响应
HTTP/1.1 200 OK
Last-Modified: Wed, 21 Oct 2024 07:28:00 GMT
Cache-Control: no-cache

# 后续请求
GET /api/users HTTP/1.1
If-Modified-Since: Wed, 21 Oct 2024 07:28:00 GMT

# 服务器响应 (资源未变化)
HTTP/1.1 304 Not Modified
Last-Modified: Wed, 21 Oct 2024 07:28:00 GMT

ETag vs Last-Modified:

维度	ETag	Last-Modified
精度	高(内容变化即变化)	低(秒级,1秒内多次修改检测不到)
优先级	高	低
性能	需计算哈希,开销大	读取文件时间,开销小
适用场景	内容频繁变化、精度要求高	内容变化不频繁、静态文件

优先级: ETag > Last-Modified

6.4 缓存最佳实践

1. 静态资源强缓存 + 文件指纹:

<!-- HTML文件: 不缓存,每次请求 -->
<meta http-equiv="Cache-Control" content="no-cache">

<!-- CSS/JS文件: 强缓存1年 + 文件指纹(版本号/哈希值) -->
<link rel="stylesheet" href="/css/main.abc123.css">
<script src="/js/app.def456.js"></script>

静态资源通过Webpack打包,文件名包含哈希值
文件内容变化 → 哈希变化 → 浏览器请求新文件
未变化的文件使用强缓存,减少请求

2. API接口协商缓存:

# 用户列表接口,数据可能变化,使用ETag协商缓存
HTTP/1.1 200 OK
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Cache-Control: no-cache

3. CDN缓存策略:

# Nginx配置
location ~* .(jpg|jpeg|png|gif|css|js)$ {
    expires 1y;                        # 静态资源强缓存1年
    add_header Cache-Control "public";
}

location /api/ {
    expires -1;                        # API接口不缓存
    add_header Cache-Control "no-cache, no-store, must-revalidate";
}

4. 缓存失效策略:

版本号: /api/v1/users, /api/v2/users
时间戳: /css/main.css?v=202410210728
文件哈希: /js/app.abc123.js

七、Cookie vs Session vs Token

7.1 Cookie

定义: 浏览器存储的键值对,每次请求自动携带到服务器。

特点:

存储位置: 浏览器本地
容量限制: 单个Cookie最大4KB,单个域名最多约50个Cookie
生命周期:
- 会话Cookie: 关闭浏览器即失效
- 持久Cookie: 设置Expires或Max-Age
作用域: Domain和Path限制
自动携带: 浏览器自动在每次请求中携带同域名Cookie

安全属性:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Max-Age=3600; Path=/; Domain=.example.com

HttpOnly: 禁止JavaScript访问Cookie,防止XSS攻击窃取Cookie
Secure: 仅HTTPS传输,防止中间人窃听
SameSite: 防止CSRF攻击
- Strict: 完全禁止第三方Cookie
- Lax: 部分禁止(GET跳转允许,POST禁止)
- None: 不限制(需配合Secure使用)

示例:

// 设置Cookie
Cookie cookie = new Cookie("username", "alice");
cookie.setHttpOnly(true);
cookie.setSecure(true);
cookie.setMaxAge(3600);  // 1小时
cookie.setPath("/");
response.addCookie(cookie);

// 读取Cookie
Cookie[] cookies = request.getCookies();
for (Cookie cookie : cookies) {
    if ("username".equals(cookie.getName())) {
        String username = cookie.getValue();
    }
}

7.2 Session

定义: 服务器存储的用户会话数据,通过Cookie传递SessionID。

工作流程:

用户登录成功,服务器创建Session,生成SessionID
服务器将SessionID通过Cookie返回给浏览器
浏览器后续请求自动携带Cookie (SessionID)
服务器根据SessionID查找Session,获取用户信息

存储方式:

内存存储: 服务器内存(默认),重启丢失,不支持集群
Redis存储: 分布式缓存,支持集群、持久化、高可用

示例:

// 创建Session
HttpSession session = request.getSession();
session.setAttribute("userId", 123);
session.setAttribute("username", "alice");

// 读取Session
Long userId = (Long) session.getAttribute("userId");
String username = (String) session.getAttribute("username");

// 销毁Session (登出)
session.invalidate();

Session配置 (Spring Boot):

# Session超时时间30分钟
server.servlet.session.timeout=30m

# Session存储到Redis
spring.session.store-type=redis
spring.redis.host=localhost
spring.redis.port=6379

缺点:

占用服务器内存: 大量用户Session占用内存
集群session共享问题: 需要Session复制或集中存储(Redis)
CSRF攻击风险: Cookie自动携带,容易被CSRF攻击

7.3 Token (JWT)

定义: 无状态认证令牌,服务器不存储,客户端每次请求携带Token。

JWT (JSON Web Token) 结构:

Header.Payload.Signature

示例:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywidXNlcm5hbWUiOiJhbGljZSIsImV4cCI6MTYzNDU2Nzg5MH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

三部分:

Header (头部): 算法和令牌类型

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload (载荷): 用户信息、过期时间

{
  "userId": 123,
  "username": "alice",
  "exp": 1634567890
}

Signature (签名): 防篡改

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

工作流程:

用户登录成功,服务器生成JWT,返回给客户端
客户端存储JWT (localStorage / sessionStorage)
客户端每次请求携带JWT (放在HTTP Header: Authorization: Bearer <token>)
服务器验证JWT签名,解析Payload,获取用户信息

示例:

// 生成JWT
String token = Jwts.builder()
    .setSubject("alice")
    .claim("userId", 123)
    .setExpiration(new Date(System.currentTimeMillis() + 3600000))  // 1小时
    .signWith(SignatureAlgorithm.HS256, "secret-key")
    .compact();

// 验证JWT
Claims claims = Jwts.parser()
    .setSigningKey("secret-key")
    .parseClaimsJws(token)
    .getBody();
Long userId = claims.get("userId", Long.class);
String username = claims.getSubject();

优点:

无状态: 服务器不存储Token,水平扩展容易
跨域: Token可放在HTTP Header,支持跨域请求
适合微服务: 各服务共享secret-key,无需Session复制
防CSRF: Token不会自动携带,需手动放在Header

缺点:

无法主动失效: Token签发后无法撤销,只能等待过期
Token泄露风险: 存储在localStorage,易被XSS攻击窃取
Token体积大: Payload包含用户信息,比SessionID大

Token安全最佳实践:

短有效期: Access Token有效期15分钟-1小时
Refresh Token: Access Token过期后,使用Refresh Token刷新
HTTPS传输: 防止Token被中间人窃听
敏感信息加密: Payload中不要放敏感信息(如密码)

7.4 Cookie vs Session vs Token对比

维度	Cookie	Session	Token (JWT)
存储位置	浏览器	服务器(内存/Redis)	客户端(localStorage)
容量限制	4KB	无限制	无限制(但不宜过大)
服务器压力	无	高(占用内存)	无(无状态)
集群支持	天然支持	需Session共享(Redis)	天然支持
安全性	易被CSRF攻击	易被CSRF攻击	防CSRF,但易被XSS窃取
跨域	受同源策略限制	受同源策略限制	支持跨域
适用场景	简单状态存储(如主题、语言)	传统Web应用	微服务、移动端、SPA

八、实战场景应用

8.1 电商系统网络优化实战

场景: 电商首页加载慢,用户体验差,跳出率高。

问题分析:

HTTP/1.1队头阻塞: 浏览器对同一域名最多6个并发连接,大量图片串行加载
无缓存策略: 每次刷新页面,所有CSS/JS/图片都重新下载
未启用HTTPS: CDN缓存命中率低,用户数据不安全

优化方案:

1. 升级HTTP/2:

Nginx配置HTTP/2,一个TCP连接并行加载所有资源
性能提升: 首屏加载时间从3秒降至1.5秒 (提升50%)

server {
    listen 443 ssl http2;  # 启用HTTP/2
    server_name www.example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
}

2. 静态资源强缓存 + CDN:

静态资源(CSS/JS/图片)强缓存1年,文件名包含哈希值
CDN缓存配置,减少源站请求

location ~* .(jpg|jpeg|png|gif|webp|css|js)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

3. 启用HTTPS + TLS 1.3:

Let's Encrypt免费证书,certbot自动续期
TLS 1.3握手1-RTT,比TLS 1.2快1-RTT

certbot --nginx -d www.example.com -d example.com

4. 图片懒加载 + WebP格式:

图片懒加载,只加载可视区域图片
图片格式转WebP,体积减少30-50%

<img src="placeholder.jpg" data-src="product.webp" loading="lazy">

效果:

首屏加载时间: 3秒 → 1秒 (提升67%)
页面跳出率: 40% → 15% (降低62.5%)
CDN缓存命中率: 50% → 90% (提升80%)

8.2 RESTful API设计最佳实践

1. 资源命名:

# ✅ 正确: 使用名词复数,表示资源集合
GET    /api/v1/products           # 获取商品列表
GET    /api/v1/products/{id}      # 获取单个商品
POST   /api/v1/products           # 创建商品
PUT    /api/v1/products/{id}      # 更新商品
DELETE /api/v1/products/{id}      # 删除商品

# ❌ 错误: 使用动词
GET /api/v1/getProducts
POST /api/v1/createProduct

2. HTTP方法语义:

方法	语义	幂等性	安全性
GET	查询	✅ 是	✅ 是
POST	创建	❌ 否	❌ 否
PUT	完整更新	✅ 是	❌ 否
PATCH	部分更新	❌ 否	❌ 否
DELETE	删除	✅ 是	❌ 否

3. 状态码使用:

# 成功响应
200 OK                # 成功
201 Created           # 创建成功
204 No Content        # 成功,无返回内容(如DELETE)

# 客户端错误
400 Bad Request       # 参数错误
401 Unauthorized      # 未认证
403 Forbidden         # 无权限
404 Not Found         # 资源不存在
409 Conflict          # 资源冲突(如重复创建)
422 Unprocessable Entity  # 参数验证失败

# 服务端错误
500 Internal Server Error   # 服务器内部错误
502 Bad Gateway             # 网关错误
503 Service Unavailable     # 服务不可用
504 Gateway Timeout         # 网关超时

4. 统一响应格式:

{
  "code": 200,
  "message": "success",
  "data": {
    "id": 123,
    "name": "iPhone 15",
    "price": 5999
  },
  "timestamp": 1700000000000
}

5. 分页、排序、过滤:

# 分页
GET /api/v1/products?page=1&size=20

# 排序
GET /api/v1/products?sort=price,desc&sort=createdAt,asc

# 过滤
GET /api/v1/products?category=phone&minPrice=1000&maxPrice=5000

九、生产案例与故障排查

9.1 案例1: TCP连接池耗尽导致接口超时

故障现象:

订单服务调用支付服务接口频繁超时
错误日志: java.net.SocketTimeoutException: connect timed out
监控显示: 订单服务TIME_WAIT连接数飙升至30000+

问题分析:

订单服务使用RestTemplate调用支付服务,每次请求创建新连接(短连接)
订单服务是主动关闭方,产生大量TIME_WAIT状态连接(2MSL = 2分钟)
Linux默认端口范围28232个(32768-61000),TIME_WAIT占满端口,无法建立新连接

排查步骤:

# 1. 查看TIME_WAIT连接数
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

# 输出:
ESTABLISHED 100
TIME_WAIT 30000

# 2. 查看端口范围
cat /proc/sys/net/ipv4/ip_local_port_range
# 输出: 32768 61000

# 3. 查看连接池配置
# RestTemplate未配置连接池,每次请求创建新连接

解决方案:

1. 配置连接池 (Apache HttpClient):

@Bean
public RestTemplate restTemplate() {
    PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
    connectionManager.setMaxTotal(200);           // 最大连接数200
    connectionManager.setDefaultMaxPerRoute(50);  // 每个路由最大50个连接

    RequestConfig requestConfig = RequestConfig.custom()
        .setConnectTimeout(5000)                 // 连接超时5秒
        .setSocketTimeout(10000)                 // 读取超时10秒
        .setConnectionRequestTimeout(3000)       // 从连接池获取连接超时3秒
        .build();

    CloseableHttpClient httpClient = HttpClients.custom()
        .setConnectionManager(connectionManager)
        .setDefaultRequestConfig(requestConfig)
        .setKeepAliveStrategy((response, context) -> 60 * 1000)  // keep-alive 60秒
        .build();

    return new RestTemplate(new HttpComponentsClientHttpRequestFactory(httpClient));
}

2. 优化系统参数:

# /etc/sysctl.conf
net.ipv4.tcp_tw_reuse=1           # 允许TIME_WAIT socket重用
net.ipv4.ip_local_port_range=10000 65000  # 扩大端口范围
net.ipv4.tcp_fin_timeout=30       # FIN_WAIT_2超时时间30秒

效果:

TIME_WAIT连接数: 30000 → 200
接口超时率: 15% → 0.1%
接口响应时间: 500ms → 50ms (连接复用)

9.2 案例2: HTTPS证书过期导致服务不可用

故障现象:

用户访问网站报错: NET::ERR_CERT_DATE_INVALID
浏览器显示: 证书已过期
支付、登录功能全部不可用

问题分析:

HTTPS证书有效期3个月(Let's Encrypt),未配置自动续期
证书过期后,浏览器拒绝访问,服务不可用

解决方案:

1. 手动续期证书:

# 停止Nginx
systemctl stop nginx

# 续期证书
certbot renew

# 启动Nginx
systemctl start nginx

2. 配置自动续期 (推荐):

# crontab定时任务,每天凌晨2点检查证书并续期
0 2 * * * certbot renew --quiet && systemctl reload nginx

3. 监控证书有效期:

# 查看证书有效期
echo | openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null | openssl x509 -noout -dates

4. 告警配置:

证书有效期 < 7天,发送告警邮件/短信
使用监控工具(Zabbix、Prometheus)监控证书过期时间

十、常见问题与避坑指南

10.1 浏览器输入URL到页面展示的完整流程

完整流程:

DNS解析: 域名 → IP地址
- 浏览器缓存 → OS缓存 → 路由器缓存 → ISP DNS服务器 → 根DNS → 顶级域DNS → 权威DNS
TCP三次握手: 建立TCP连接
- Client → Server: SYN
- Server → Client: SYN+ACK
- Client → Server: ACK
TLS握手 (HTTPS):
- Client Hello → Server Hello + Certificate → Client Key Exchange → Server Finished
发送HTTP请求:
- GET / HTTP/1.1
- Host: www.example.com
服务器处理请求:
- Nginx反向代理 → 应用服务器 → 数据库查询 → 渲染HTML
返回HTTP响应:
- HTTP/1.1 200 OK
- Content-Type: text/html
浏览器渲染页面:
- 解析HTML → 构建DOM树
- 解析CSS → 构建CSSOM树
- 合并DOM + CSSOM → 渲染树
- 布局 (Layout) → 绘制 (Paint) → 合成 (Composite)
加载资源:
- 并发下载CSS、JS、图片
- 执行JavaScript
TCP四次挥手: 关闭TCP连接 (HTTP/1.0) 或保持连接 (HTTP/1.1 keep-alive)

10.2 常见面试题

Q: TCP为什么可靠?

确认应答 (ACK): 接收方收到数据后发送ACK,发送方未收到ACK会重传
序列号: 保证数据顺序,防止乱序
校验和: 检测数据是否损坏
超时重传: 超时未收到ACK,重传数据
流量控制: 滑动窗口,防止接收方缓冲区溢出
拥塞控制: 慢启动、拥塞避免、快重传、快恢复,防止网络拥堵

Q: HTTP/1.1如何优化性能?

长连接 (keep-alive): 复用TCP连接
管道化 (Pipelining): 一次发送多个请求 (浏览器默认未启用)
域名分片: 多个子域名并发下载 (HTTP/2后不需要)
资源合并: 合并CSS/JS,减少请求数
CDN加速: 就近访问,减少延迟
缓存: 强缓存 + 协商缓存

Q: HTTPS如何保证安全?

机密性: 对称加密(AES)加密数据,中间人无法窃听
完整性: 消息摘要(SHA-256)校验,防止篡改
身份认证: 数字证书(CA签名)验证服务器身份,防止冒充

Q: Cookie如何防止XSS和CSRF攻击?

防XSS: HttpOnly属性,禁止JavaScript访问Cookie
防CSRF: SameSite属性,限制第三方Cookie携带

10.3 避坑指南

1. RestTemplate未配置连接池,导致TIME_WAIT过多:

❌ 默认每次请求创建新连接
✅ 配置连接池,复用连接

2. HTTPS证书过期,未配置自动续期:

❌ 手动续期,容易忘记
✅ certbot自动续期,crontab定时任务

3. HTTP缓存配置不当,导致用户看到旧数据:

❌ API接口设置强缓存,数据更新后用户看不到
✅ API接口使用协商缓存或不缓存

4. Cookie未设置HttpOnly、Secure,导致安全风险:

❌ Cookie可被JavaScript读取,易被XSS窃取
✅ 设置HttpOnly、Secure、SameSite

5. TCP连接超时时间设置过长,导致请求堆积:

❌ 超时时间30秒,故障服务拖垮整个系统
✅ 超时时间3-5秒,快速失败,熔断降级

十一、最佳实践与总结

11.1 网络优化最佳实践

1. 协议选择:

HTTP/2: 提升Web性能,减少延迟
HTTPS: 保证数据安全,SEO排名优先
HTTP/3 + QUIC: 弱网环境、移动端优先

2. 连接管理:

长连接: HTTP/1.1 keep-alive,复用TCP连接
连接池: RestTemplate、HttpClient、数据库连接池,复用连接
超时配置: 连接超时3-5秒,读取超时10-30秒,快速失败

3. 缓存策略:

静态资源: 强缓存1年,文件名包含哈希值
API接口: 协商缓存(ETag)或不缓存
CDN: 静态资源就近访问,减少延迟

4. 安全防护:

HTTPS: 所有生产环境强制HTTPS
Cookie安全: HttpOnly + Secure + SameSite
Token认证: JWT短有效期 + Refresh Token

11.2 核心要点总结

网络分层模型:

OSI七层: 理论模型,从下到上: 物理层、数据链路层、网络层、传输层、会话层、表示层、应用层
TCP/IP四层: 实际模型,从下到上: 网络接口层、网络层、传输层、应用层
数据封装: 发送端自顶向下添加头部,接收端自底向上移除头部

TCP协议:

三次握手: SYN → SYN+ACK → ACK,确认双方收发能力,同步序列号
四次挥手: FIN → ACK → FIN → ACK → TIME_WAIT(2MSL) → CLOSED,全双工连接分别关闭
流量控制: 滑动窗口,接收方告知发送方接收窗口大小
拥塞控制: 慢启动、拥塞避免、快重传、快恢复,防止网络拥堵

HTTP协议:

HTTP/1.1: 长连接、管道化、缓存,队头阻塞问题
HTTP/2: 二进制分帧、多路复用、头部压缩、服务器推送,解决应用层队头阻塞
HTTP/3: 基于QUIC(UDP),彻底解决队头阻塞,0-RTT握手,连接迁移

HTTPS加密:

混合加密: 握手阶段RSA非对称加密,数据传输阶段AES对称加密
TLS握手: Client Hello → Server Hello + Certificate → Client Key Exchange → Session Key生成 → 加密通信
数字证书: CA签名验证服务器身份,防止中间人冒充

HTTP缓存:

强缓存: Cache-Control max-age,命中后直接使用缓存,不请求服务器
协商缓存: ETag / Last-Modified,发送请求验证资源是否更新,未更新返回304

身份认证:

Cookie: 浏览器存储,自动携带,HttpOnly + Secure + SameSite防止XSS和CSRF
Session: 服务器存储,通过Cookie传递SessionID,集群需Session共享
Token (JWT): 无状态认证,客户端存储,适合微服务、移动端

掌握计算机网络基础与HTTP协议,是每位后端工程师的必备技能。通过深入理解网络分层模型、TCP可靠传输机制、HTTP协议演进、HTTPS加密原理、缓存策略、身份认证方案,结合生产环境实战经验,能够在面试和实际工作中游刃有余,构建高性能、高安全的Web应用系统。

参考资料:

《图解HTTP》 - 上野宣
《图解TCP/IP》 - 竹下隆史
《HTTP权威指南》 - David Gourley
《Web性能权威指南》 - Ilya Grigorik
MDN Web文档: developer.mozilla.org/
RFC 7540 (HTTP/2): tools.ietf.org/html/rfc754…
RFC 9114 (HTTP/3): www.rfc-editor.org/rfc/rfc9114…