计算机网络基础
什么是计算机网络?
计算机网络是指将地理位置不同的具有独立功能的多台计算机及其外部设备,通过通信线路连接起来,在网络操作系统、网络管理软件及网络通信协议的管理和协调下,实现资源共享和信息传递的计算机系统。
OSI 七层模型
OSI(Open Systems Interconnection)参考模型将计算机网络分为七层:
- 物理层(Physical Layer):传输比特流,定义电气、机械、规程等特性
- 数据链路层(Data Link Layer):帧传输,差错检测和纠正
- 网络层(Network Layer):路由选择,IP 地址,数据包传输
- 传输层(Transport Layer):端到端通信,TCP、UDP 协议
- 会话层(Session Layer):建立、管理和终止会话
- 表示层(Presentation Layer):数据加密、压缩、格式转换
- 应用层(Application Layer):用户接口,HTTP、FTP、SMTP 等协议
TCP/IP 四层模型
TCP/IP 模型将网络分为四层(或五层):
- 网络接口层(Network Interface Layer):对应 OSI 的物理层和数据链路层
- 网络层(Internet Layer):对应 OSI 的网络层,IP 协议
- 传输层(Transport Layer):对应 OSI 的传输层,TCP、UDP 协议
- 应用层(Application Layer):对应 OSI 的应用层、表示层、会话层
OSI 模型与 TCP/IP 模型的区别
| 特性 | OSI 模型 | TCP/IP 模型 |
|---|---|---|
| 层数 | 7 层 | 4 层(或 5 层) |
| 设计理念 | 理论模型,分层更细致 | 实际应用模型,更实用 |
| 应用 | 教学参考 | 实际网络协议栈 |
| 协议支持 | 多种协议 | TCP/IP 协议族 |
传输层协议
TCP(Transmission Control Protocol)
TCP 是一种面向连接的、可靠的、基于字节流的传输层通信协议。
TCP 的特点
- 面向连接:通信前需要建立连接(三次握手),通信后需要释放连接(四次挥手)
- 可靠传输:通过序列号、确认应答、重传机制等保证数据可靠传输
- 流量控制:通过滑动窗口机制控制发送方的发送速度
- 拥塞控制:通过慢开始、拥塞避免、快重传、快恢复等算法控制网络拥塞
- 全双工通信:支持双向数据传输
- 面向字节流:TCP 把应用层传下来的数据看成无结构的字节流
TCP 报文格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
主要字段:
- 源端口/目标端口:16 位,标识发送端和接收端的端口
- 序列号(Sequence Number):32 位,标识数据包的顺序
- 确认号(Acknowledgment Number):32 位,期望收到下一个数据包的序列号
- 数据偏移:4 位,TCP 报文首部长度
- 控制位:URG、ACK、PSH、RST、SYN、FIN
- 窗口大小(Window):16 位,用于流量控制
- 校验和(Checksum):16 位,用于差错检测
TCP 三次握手
TCP 建立连接需要三次握手:
客户端 服务端
| |
| SYN=1, seq=x |
|-----------------------------> |
| |
| SYN=1, ACK=1, seq=y, |
| ack=x+1 |
|<----------------------------- |
| |
| ACK=1, seq=x+1, ack=y+1 |
|-----------------------------> |
| |
| 连接已建立 |
过程说明:
- 第一次握手:客户端发送 SYN=1,seq=x 的报文,进入 SYN_SENT 状态
- 第二次握手:服务端收到 SYN 报文后,发送 SYN=1,ACK=1,seq=y,ack=x+1 的报文,进入 SYN_RECEIVED 状态
- 第三次握手:客户端收到 SYN+ACK 报文后,发送 ACK=1,seq=x+1,ack=y+1 的报文,进入 ESTABLISHED 状态;服务端收到 ACK 后也进入 ESTABLISHED 状态
为什么需要三次握手?
- 确认双方的收发能力:三次握手可以确认客户端和服务端都能正常发送和接收数据
- 防止已失效的连接请求:如果只有两次握手,可能会接收到旧的连接请求,导致连接混乱
- 同步初始序列号:三次握手可以确保双方的初始序列号(ISN)被正确同步
TCP 四次挥手
TCP 释放连接需要四次挥手:
客户端 服务端
| |
| FIN=1, seq=u |
|-----------------------------> |
| |
| ACK=1, seq=v, ack=u+1 |
|<----------------------------- |
| |
| FIN=1, ACK=1, seq=w, |
| ack=u+1 |
|<----------------------------- |
| |
| ACK=1, seq=u+1, ack=w+1 |
|-----------------------------> |
| |
| 连接已关闭 |
过程说明:
- 第一次挥手:客户端发送 FIN=1,seq=u 的报文,进入 FIN_WAIT_1 状态
- 第二次挥手:服务端收到 FIN 报文后,发送 ACK=1,seq=v,ack=u+1 的报文,进入 CLOSE_WAIT 状态;客户端收到 ACK 后进入 FIN_WAIT_2 状态
- 第三次挥手:服务端发送 FIN=1,ACK=1,seq=w,ack=u+1 的报文,进入 LAST_ACK 状态
- 第四次挥手:客户端收到 FIN 报文后,发送 ACK=1,seq=u+1,ack=w+1 的报文,进入 TIME_WAIT 状态;服务端收到 ACK 后进入 CLOSED 状态
为什么需要四次挥手?
因为 TCP 是全双工通信,需要分别关闭两个方向的数据传输:
- 客户端到服务端的方向
- 服务端到客户端的方向
每个方向都需要一个 FIN 和一个 ACK,所以需要四次挥手。
TIME_WAIT 状态的作用
客户端在发送最后一个 ACK 后会进入 TIME_WAIT 状态,等待 2MSL(Maximum Segment Lifetime)后才会关闭。作用:
- 确保最后的 ACK 能够到达:如果服务端没有收到最后的 ACK,会重传 FIN,客户端需要能够处理这个重传的 FIN
- 让旧连接的数据包在网络中消失:等待足够长的时间,确保旧连接的所有数据包都在网络中消失,避免影响新连接
TCP 流量控制
TCP 使用滑动窗口机制进行流量控制,防止发送方发送速度过快,导致接收方缓冲区溢出。
滑动窗口机制:
- 接收窗口(rwnd):接收方告诉发送方还能接收多少数据
- 发送窗口(cwnd):发送方根据接收窗口和拥塞窗口确定实际发送窗口
- 窗口大小动态调整:接收方根据缓冲区情况动态调整接收窗口大小
TCP 拥塞控制
TCP 拥塞控制算法包括:
- 慢开始(Slow Start):初始拥塞窗口较小,每收到一个 ACK,拥塞窗口指数增长
- 拥塞避免(Congestion Avoidance):到达慢开始阈值(ssthresh)后,拥塞窗口线性增长
- 快重传(Fast Retransmit):收到 3 个重复 ACK 后立即重传,而不是等待超时
- 快恢复(Fast Recovery):快重传后,进入快恢复阶段,拥塞窗口减半,然后线性增长
拥塞控制算法演变:
- TCP Tahoe:慢开始 + 拥塞避免
- TCP Reno:慢开始 + 拥塞避免 + 快重传 + 快恢复
- TCP NewReno:改进的快恢复算法
- TCP BBR:Google 提出的基于带宽和延迟的拥塞控制算法
UDP(User Datagram Protocol)
UDP 是一种无连接的、不可靠的传输层通信协议。
UDP 的特点
- 无连接:发送数据前不需要建立连接
- 不可靠:不保证数据包能到达目的地,不保证顺序
- 面向报文:应用层交给 UDP 的数据,UDP 只是添加首部后就发送,不会进行拆分或合并
- 开销小:首部只有 8 字节,比 TCP 的 20 字节小
- 传输效率高:没有连接建立、确认、重传等机制,传输效率高
UDP 报文格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
主要字段:
- 源端口/目标端口:16 位
- 长度:16 位,UDP 报文总长度(首部 + 数据)
- 校验和:16 位,用于差错检测(可选)
UDP 的适用场景
- 实时性要求高:语音、视频通话,在线游戏
- 对可靠性要求不高:DNS 查询,DHCP
- 广播和多播:UDP 支持广播和多播,TCP 不支持
- 简单应用:TFTP、SNMP
TCP 与 UDP 的区别
| 特性 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接 | 无连接 |
| 可靠性 | 可靠传输 | 不可靠传输 |
| 传输方式 | 面向字节流 | 面向报文 |
| 开销 | 首部 20 字节 | 首部 8 字节 |
| 传输效率 | 相对较低 | 相对较高 |
| 流量控制 | 支持(滑动窗口) | 不支持 |
| 拥塞控制 | 支持 | 不支持 |
| 适用场景 | 文件传输、HTTP、HTTPS | 实时通信、DNS、DHCP |
HTTP 协议
什么是 HTTP?
HTTP(HyperText Transfer Protocol)是一种用于传输超文本的协议,是互联网上应用最为广泛的一种网络协议。HTTP 基于 TCP/IP 协议,工作在应用层。
HTTP 的特点
- 无状态:HTTP 协议是无状态的,服务器不会保存客户端的任何信息
- 请求-响应模式:客户端发送请求,服务器返回响应
- 简单快速:HTTP 协议简单,通信速度快
- 灵活:可以传输任意类型的数据对象
HTTP 报文格式
HTTP 请求报文
请求行
GET /index.html HTTP/1.1
请求头
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
空行
请求体(可选)
请求行格式:
方法 请求URI HTTP版本
HTTP 方法:
- GET:获取资源,参数在 URL 中,有长度限制
- POST:提交数据,参数在请求体中,没有长度限制
- PUT:更新资源(完整更新)
- PATCH:更新资源(部分更新)
- DELETE:删除资源
- HEAD:获取响应头,不返回响应体
- OPTIONS:获取服务器支持的 HTTP 方法
HTTP 响应报文
状态行
HTTP/1.1 200 OK
响应头
Content-Type: text/html
Content-Length: 1024
空行
响应体
<html>...</html>
状态行格式:
HTTP版本 状态码 状态描述
HTTP 状态码:
-
1xx(信息性):请求已接收,继续处理
- 100 Continue
- 101 Switching Protocols
-
2xx(成功):请求已成功处理
- 200 OK:请求成功
- 201 Created:资源已创建
- 204 No Content:请求成功,无返回内容
-
3xx(重定向):需要进一步操作
- 301 Moved Permanently:永久重定向
- 302 Found:临时重定向
- 304 Not Modified:资源未修改,使用缓存
-
4xx(客户端错误):请求有错误
- 400 Bad Request:请求错误
- 401 Unauthorized:未授权
- 403 Forbidden:禁止访问
- 404 Not Found:资源不存在
- 405 Method Not Allowed:方法不允许
-
5xx(服务器错误):服务器错误
- 500 Internal Server Error:服务器内部错误
- 502 Bad Gateway:网关错误
- 503 Service Unavailable:服务不可用
- 504 Gateway Timeout:网关超时
HTTP/1.0 vs HTTP/1.1
| 特性 | HTTP/1.0 | HTTP/1.1 |
|---|---|---|
| 连接方式 | 每次请求都需要建立新连接 | 支持长连接(Keep-Alive) |
| 主机头 | 可选 | 必需(Host 头) |
| 缓存机制 | 简单的缓存控制 | 更强的缓存控制(ETag、Cache-Control) |
| 管道化 | 不支持 | 支持(Pipelining) |
| 分块传输 | 不支持 | 支持(Chunked Transfer Encoding) |
| 错误处理 | 连接关闭后无法恢复 | 可以继续使用连接 |
HTTP/2.0 特性
HTTP/2.0 的主要改进:
- 多路复用(Multiplexing):一个连接可以并发处理多个请求,解决了 HTTP/1.1 的队头阻塞问题
- 头部压缩(Header Compression):使用 HPACK 算法压缩 HTTP 头部
- 服务器推送(Server Push):服务器可以主动推送资源到客户端
- 二进制分帧(Binary Framing):将 HTTP 消息分解为帧,提高传输效率
- 请求优先级:可以为请求设置优先级
HTTP/3.0 特性
HTTP/3.0 基于 QUIC 协议(基于 UDP),主要改进:
- 基于 UDP:使用 QUIC 协议,基于 UDP 而非 TCP
- 0-RTT:减少连接建立时间
- 多路复用:解决 TCP 的队头阻塞问题
- 连接迁移:网络切换时连接不中断
- 内置加密:默认使用 TLS 1.3
HTTPS 协议
什么是 HTTPS?
HTTPS(HyperText Transfer Protocol Secure)是 HTTP 的安全版本,通过 SSL/TLS 协议对 HTTP 进行加密,保证数据传输的安全性。
HTTPS 的工作原理
HTTPS 在 HTTP 和 TCP 之间加入了 SSL/TLS 层,对数据进行加密和认证。
HTTP 明文
↓
SSL/TLS 加密
↓
TCP 传输
SSL/TLS 握手过程
HTTPS 建立连接需要 SSL/TLS 握手:
客户端 服务端
| |
| Client Hello |
| 支持的TLS版本、加密套件 |
| 随机数(Client Random) |
|-----------------------------> |
| |
| Server Hello |
| 选择的TLS版本、加密套件 |
| 随机数(Server Random) |
| 服务器证书 |
|<----------------------------- |
| |
| 验证服务器证书 |
| |
| 生成 Pre-Master Secret |
| 用服务器公钥加密后发送 |
|-----------------------------> |
| |
| 双方计算 Master Secret |
| 生成会话密钥 |
| |
| 加密通信开始 |
详细过程:
-
客户端发送 Client Hello:
- 支持的 TLS 版本
- 支持的加密套件列表
- 客户端随机数(Client Random)
-
服务端发送 Server Hello:
- 选择的 TLS 版本
- 选择的加密套件
- 服务器随机数(Server Random)
- 服务器证书(包含公钥)
-
客户端验证证书:
- 验证证书的有效性
- 验证证书的签名
- 验证域名是否匹配
-
客户端生成 Pre-Master Secret:
- 生成随机数作为 Pre-Master Secret
- 使用服务器公钥加密后发送给服务器
-
双方计算会话密钥:
- 客户端和服务端使用 Client Random、Server Random 和 Pre-Master Secret 计算 Master Secret
- 基于 Master Secret 生成会话密钥
-
开始加密通信:
- 使用会话密钥进行对称加密通信
HTTP vs HTTPS
| 特性 | HTTP | HTTPS |
|---|---|---|
| 协议 | 应用层协议 | 应用层协议 + SSL/TLS |
| 端口 | 80 | 443 |
| 加密 | 明文传输 | 加密传输 |
| 安全性 | 不安全 | 安全 |
| 证书 | 不需要 | 需要 SSL 证书 |
| 性能 | 较快 | 稍慢(握手和加密开销) |
| SEO | 无优势 | 有 SEO 优势 |
HTTPS 的优点
- 数据加密:防止数据被窃听和篡改
- 身份认证:验证服务器身份,防止中间人攻击
- 数据完整性:确保数据在传输过程中没有被修改
- SEO 优势:搜索引擎对 HTTPS 网站有排名优势
HTTPS 的缺点
- 性能开销:SSL/TLS 握手和加密解密有性能开销
- 证书成本:需要购买 SSL 证书(虽然有免费的 Let’s Encrypt)
- 服务器资源:加密解密消耗更多 CPU 资源
域名系统(DNS)
什么是 DNS?
DNS(Domain Name System)是互联网的域名系统,将域名转换为 IP 地址。
DNS 的工作原理
用户输入域名
↓
检查本地DNS缓存
↓
查询本地DNS服务器
↓
本地DNS服务器查询根域名服务器
↓
根域名服务器返回顶级域名服务器地址
↓
查询顶级域名服务器(.com)
↓
顶级域名服务器返回权威域名服务器地址
↓
查询权威域名服务器
↓
返回IP地址
DNS 查询类型
- 递归查询(Recursive Query):DNS 客户端要求 DNS 服务器必须给出最终答案
- 迭代查询(Iterative Query):DNS 服务器返回可能知道答案的其他服务器地址
DNS 记录类型
- A 记录:将域名指向 IPv4 地址
- AAAA 记录:将域名指向 IPv6 地址
- CNAME 记录:将域名指向另一个域名
- MX 记录:邮件服务器记录
- NS 记录:域名服务器记录
- TXT 记录:文本记录,用于验证、SPF 等
- PTR 记录:反向解析,IP 地址到域名
DNS 缓存
DNS 查询结果会被缓存,减少查询次数:
- 浏览器缓存:浏览器会缓存 DNS 查询结果
- 操作系统缓存:操作系统的 DNS 缓存
- 路由器缓存:路由器的 DNS 缓存
- ISP DNS 服务器缓存:ISP 的 DNS 服务器缓存
DNS 安全
- DNS 劫持:攻击者劫持 DNS 查询,返回错误的 IP 地址
- DNS 污染:返回错误的 DNS 解析结果
- DNSSEC:DNS 安全扩展,对 DNS 记录进行数字签名,防止伪造
Web Server
什么是 Web Server?
Web Server(Web 服务器)是运行在服务器上的程序,用于处理 HTTP/HTTPS 请求,返回静态或动态内容。
常见的 Web Server
Apache HTTP Server
- 特点:功能强大,模块化设计,支持多种编程语言
- 优势:历史悠久,文档丰富,模块生态完善
- 劣势:性能相对较低,占用资源较多
Nginx
- 特点:高性能、轻量级、反向代理服务器
- 优势:
- 高性能:事件驱动、异步非阻塞 I/O
- 低内存占用
- 强大的反向代理和负载均衡功能
- 支持 HTTP/2、WebSocket
- 劣势:模块生态相对 Apache 较少
- 应用场景:静态资源服务、反向代理、负载均衡、API 网关
Tomcat
- 特点:Java Servlet 容器,支持 JSP 和 Java Servlet
- 应用场景:Java Web 应用服务器
IIS
- 特点:微软的 Web 服务器,运行在 Windows 上
- 应用场景:Windows 服务器环境
Nginx 的优势
-
高性能:
- 事件驱动架构
- 异步非阻塞 I/O
- 单线程处理多个连接
- 内存占用低
-
反向代理:
- 负载均衡
- 健康检查
- 请求转发
-
静态资源服务:
- 高效处理静态文件
- 支持 Gzip 压缩
- 缓存控制
-
高并发:
- 可以处理数万个并发连接
- 性能优于 Apache
Nginx vs Apache
| 特性 | Nginx | Apache |
|---|---|---|
| 架构 | 事件驱动、异步非阻塞 | 进程/线程模型 |
| 性能 | 高并发性能优秀 | 中等 |
| 内存占用 | 低 | 较高 |
| 静态资源 | 优秀 | 良好 |
| 动态内容 | 需要反向代理到应用服务器 | 内置支持 |
| 配置 | 相对简单 | 功能丰富但复杂 |
| 模块 | 较少但高质量 | 丰富的模块生态 |
Nginx 配置文件示例
# 全局配置
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
events {
worker_connections 1024;
use epoll;
}
http {
# HTTP 配置
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Gzip 压缩
gzip on;
gzip_types text/plain text/css application/json;
# 上游服务器(负载均衡)
upstream backend {
server 127.0.0.1:8000;
server 127.0.0.1:8001;
}
# 虚拟主机
server {
listen 80;
server_name example.com;
# 反向代理
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
# 静态资源
location /static/ {
alias /var/www/static/;
expires 30d;
}
}
}
常见面试题
TCP 相关
1. 为什么 TCP 是可靠的?
- 序列号和确认应答:每个数据包都有序列号,接收方会发送确认应答
- 超时重传:如果发送方在一定时间内没有收到确认,会重传数据
- 流量控制:通过滑动窗口机制控制发送速度
- 拥塞控制:通过拥塞窗口控制网络拥塞
- 校验和:使用校验和检测数据是否损坏
2. TCP 的粘包问题如何解决?
原因:TCP 是面向字节流的,数据可能会粘在一起或被拆分。
解决方案:
- 固定长度:每个数据包固定长度,不足的用 0 填充
- 分隔符:使用特殊字符作为分隔符(如
\n、\r\n) - 长度字段:在数据包前添加长度字段,先读取长度再读取数据
- 应用层协议:使用标准的应用层协议(如 HTTP、FTP)
3. TCP 和 UDP 的选择原则?
-
选择 TCP 的场景:
- 需要可靠传输(文件传输、HTTP、HTTPS)
- 需要保证数据顺序
- 对实时性要求不高
- 需要流量控制和拥塞控制
-
选择 UDP 的场景:
- 对实时性要求高(语音、视频通话)
- 对可靠性要求不高(DNS 查询)
- 需要广播或多播
- 传输数据量小、频繁(在线游戏)
4. TCP 的流量控制和拥塞控制的区别?
-
流量控制:
- 目的:防止发送方发送速度过快,导致接收方缓冲区溢出
- 控制对象:发送方和接收方之间的数据传输
- 机制:滑动窗口,接收方通过窗口大小告知发送方还能接收多少数据
-
拥塞控制:
- 目的:防止网络拥塞,保证网络的整体稳定性
- 控制对象:整个网络
- 机制:慢开始、拥塞避免、快重传、快恢复等算法
5. TCP 的 SYN 攻击是什么?
SYN 洪水攻击:攻击者发送大量 SYN 报文,但不完成三次握手,耗尽服务器的连接资源。
防御方法:
- SYN Cookie:不分配资源,只在客户端返回 ACK 时验证并分配资源
- 减少 SYN_TIMEOUT 时间:快速释放无效连接
- 设置防火墙:限制同一 IP 的连接数
6. 为什么 TIME_WAIT 状态是 2MSL?
- 1MSL:确保最后的 ACK 能够到达服务器,如果服务器没有收到会重传 FIN
- 1MSL:确保网络中所有旧连接的数据包都消失,避免影响新连接
总共 2MSL 可以确保旧连接完全关闭,不会影响新连接。
HTTP/HTTPS 相关
1. HTTP 是无状态协议,如何实现状态管理?
Cookie:
- 服务器通过
Set-Cookie响应头设置 Cookie - 客户端自动在后续请求中携带 Cookie
- 存储在客户端,有大小限制(4KB)
Session:
- 服务器为每个客户端创建 Session,存储用户状态
- Session ID 通过 Cookie 或 URL 参数传递
- 存储在服务器,占用服务器资源
Token(JWT):
- 无状态认证方案
- 将用户信息编码到 Token 中
- 客户端每次请求携带 Token,服务器验证
2. GET 和 POST 的区别?
| 特性 | GET | POST |
|---|---|---|
| 语义 | 获取资源 | 提交数据 |
| 参数位置 | URL 中(Query String) | 请求体中(Body) |
| 参数长度 | 有长度限制(浏览器和服务器限制) | 理论上无限制 |
| 安全性 | 参数暴露在 URL 中,不适合敏感数据 | 参数在请求体中,相对安全 |
| 幂等性 | 幂等(多次请求结果相同) | 不幂等 |
| 可缓存 | 可以被缓存 | 通常不被缓存 |
| 浏览器行为 | 可以收藏、分享 | 刷新时会提示重新提交 |
3. HTTP/1.1 的性能问题?
-
队头阻塞(Head-of-Line Blocking):
- 同一连接中,前面的请求阻塞会影响后面的请求
- 虽然支持管道化,但响应必须按顺序返回
-
多个连接开销:
- 浏览器通过建立多个连接来并行请求
- 每个连接都有建立和维护的开销
-
请求头冗余:
- 每个请求都携带完整的请求头
- 很多头部信息是重复的
-
没有服务器推送:
- 客户端必须主动请求资源
- 无法主动推送资源给客户端
4. HTTP/2.0 如何解决 HTTP/1.1 的问题?
-
多路复用:
- 一个连接可以并发处理多个请求和响应
- 使用流(Stream)和帧(Frame)的概念
- 解决了队头阻塞问题
-
头部压缩:
- 使用 HPACK 算法压缩 HTTP 头部
- 维护头部字段表,减少重复传输
-
服务器推送:
- 服务器可以主动推送资源到客户端
- 减少往返次数,提高性能
-
二进制分帧:
- 将 HTTP 消息分解为帧
- 提高传输效率,便于解析
5. HTTPS 握手过程为什么需要四次交互?
HTTPS 握手过程实际上是 SSL/TLS 握手 + TCP 三次握手:
- TCP 三次握手:建立 TCP 连接(3 次交互)
- SSL/TLS 握手:建立安全连接(通常需要 2-3 次交互)
所以总共看起来像是 4-6 次交互。不过在实际实现中,TCP 三次握手和 SSL/TLS 握手可能合并进行。
6. HTTPS 为什么需要 CA 证书?
- 身份认证:CA(证书颁发机构)验证服务器身份,确保证书持有者是合法的
- 防止中间人攻击:攻击者无法伪造合法证书
- 建立信任链:客户端内置信任的 CA 根证书,验证服务器证书的合法性
7. 什么是中间人攻击?HTTPS 如何防止?
中间人攻击(MITM):攻击者拦截客户端和服务端之间的通信,冒充服务端与客户端通信。
HTTPS 如何防止:
- 加密通信:数据经过加密,即使被拦截也无法读取
- 证书验证:客户端验证服务器证书,确保连接的是真正的服务器
- 数字签名:证书由 CA 签名,无法伪造
8. 浏览器输入 URL 到页面显示的完整过程?
-
DNS 解析:
- 浏览器缓存 → 操作系统缓存 → 本地 DNS 服务器 → 根域名服务器 → 顶级域名服务器 → 权威域名服务器
- 获取域名对应的 IP 地址
-
建立 TCP 连接:
- TCP 三次握手建立连接
- 如果是 HTTPS,还需要 SSL/TLS 握手
-
发送 HTTP 请求:
- 浏览器构建 HTTP 请求报文
- 通过 TCP 连接发送到服务器
-
服务器处理请求:
- 服务器解析请求
- 处理业务逻辑
- 生成响应
-
接收 HTTP 响应:
- 浏览器接收响应报文
- 解析响应内容
-
渲染页面:
- 解析 HTML 构建 DOM 树
- 解析 CSS 构建 CSSOM 树
- 合并生成渲染树
- 布局(Layout)
- 绘制(Paint)
-
关闭连接:
- TCP 四次挥手关闭连接
9. 什么是跨域?如何解决跨域问题?
跨域:浏览器的同源策略限制了不同源之间的资源访问。
同源策略:协议、域名、端口都相同才算同源。
解决方案:
-
CORS(Cross-Origin Resource Sharing):
- 服务器设置
Access-Control-Allow-Origin响应头 - 最常用和推荐的方案
- 服务器设置
-
JSONP:
- 利用
<script>标签不受同源策略限制 - 只支持 GET 请求
- 利用
-
代理服务器:
- 前端开发时通过代理服务器转发请求
- 生产环境通过 Nginx 反向代理
-
document.domain:
- 适用于主域名相同的子域名之间
-
postMessage:
- 用于 iframe 之间的通信
DNS 相关
1. DNS 查询过程?
- 检查浏览器缓存
- 检查操作系统缓存(hosts 文件)
- 查询本地 DNS 服务器(ISP 提供的 DNS)
- 递归查询:
- 本地 DNS 服务器查询根域名服务器
- 根域名服务器返回顶级域名服务器地址
- 查询顶级域名服务器(如 .com)
- 顶级域名服务器返回权威域名服务器地址
- 查询权威域名服务器
- 返回 IP 地址
2. DNS 为什么使用 UDP 而不是 TCP?
- 查询速度快:DNS 查询通常是单个请求-响应,UDP 更快
- 开销小:DNS 查询数据量小,UDP 首部只有 8 字节
- 无需可靠传输:DNS 查询失败可以重试,不需要 TCP 的可靠性保证
但是:当 DNS 响应超过 512 字节时,会使用 TCP 传输。
3. 什么是 DNS 劫持?如何防范?
DNS 劫持:攻击者劫持 DNS 查询,返回错误的 IP 地址,将用户引导到恶意网站。
防范方法:
- 使用可信的 DNS 服务器(如 8.8.8.8、1.1.1.1)
- 使用 HTTPS,即使 DNS 被劫持,HTTPS 也能保证安全
- 使用 DNSSEC(DNS 安全扩展)
Web Server 相关
1. Nginx 为什么性能高?
-
事件驱动架构:
- 使用 epoll/kqueue 等 I/O 多路复用机制
- 单线程/少量线程处理大量连接
-
异步非阻塞 I/O:
- 不会因为某个请求阻塞而影响其他请求
- 充分利用系统资源
-
内存池:
- 减少内存分配和释放的开销
- 提高内存使用效率
-
模块化设计:
- 只加载需要的模块
- 减少资源占用
2. Nginx 的反向代理和正向代理?
正向代理(Forward Proxy):
- 客户端代理
- 客户端通过代理服务器访问目标服务器
- 代理服务器代表客户端发送请求
- 场景:VPN、翻墙、企业内部访问外网
反向代理(Reverse Proxy):
- 服务器端代理
- 客户端访问反向代理服务器,代理服务器转发请求到后端服务器
- 客户端不知道真实的后端服务器
- 场景:负载均衡、隐藏服务器信息、SSL 终止
3. Nginx 负载均衡算法?
- 轮询(Round Robin):默认算法,按顺序分配请求
- 加权轮询(Weighted Round Robin):根据服务器权重分配
- IP Hash:根据客户端 IP 的 hash 值分配,同一 IP 总是访问同一服务器
- 最少连接(Least Connections):分配连接到连接数最少的服务器
- 加权最少连接(Weighted Least Connections):结合权重和连接数
4. 为什么 Nginx 适合做静态资源服务器?
-
高效的文件处理:
- 使用
sendfile系统调用,减少数据拷贝 - 使用内存映射(mmap)提高文件读取效率
- 使用
-
缓存机制:
- 支持静态文件缓存
- 可以设置缓存过期时间
-
Gzip 压缩:
- 支持自动压缩静态文件
- 减少传输数据量
-
低资源占用:
- 处理静态文件时 CPU 和内存占用低
- 可以同时处理大量并发请求
总结
计算机网络是现代互联网的基础,掌握网络协议的原理和特性对于系统设计和开发至关重要。
核心要点总结:
- TCP/IP 模型:理解网络分层模型,各层的作用和协议
- TCP vs UDP:理解两者的区别和适用场景
- HTTP/HTTPS:掌握 HTTP 协议的特点、版本演进和安全机制
- DNS:理解域名解析的原理和过程
- Web Server:了解 Nginx 等 Web 服务器的特性和应用场景
面试重点:
- TCP 三次握手和四次挥手
- TCP 的可靠传输机制
- HTTP/1.1 的性能问题和 HTTP/2.0 的改进
- HTTPS 的工作原理和 SSL/TLS 握手
- 浏览器输入 URL 到页面显示的完整过程
- 跨域问题和解决方案
- Nginx 的高性能原理和配置
实际应用:
在实际项目中,需要根据业务场景选择合适的协议和技术:
- 高可靠性要求:选择 TCP + HTTP/HTTPS
- 高实时性要求:选择 UDP + 自定义协议
- 高并发场景:使用 Nginx 作为反向代理和负载均衡
- 安全要求高:使用 HTTPS + 证书认证
参考资料:
- 《计算机网络》(谢希仁)
- 《TCP/IP 详解 卷1:协议》
- 《HTTP 权威指南》
- 《高性能网站建设指南》
- MDN Web 文档
- Nginx 官方文档
Originally published on mlangTse's Blog. View source