计算机网络面试
计算机网络面试
如果你不是从事于通信领域,面试时问及计算机网络的知识,一般也就限定在:HTTP(含 HTTPS、Cookie、Session)、TCP、UDP、Socket 这些
综合
【中等】计算机网络如何分层?🌟🌟🌟
❓ 问题:计算机网络如何分层?各层的作用是什么?各层的主要协议、设备分别是什么?
这是学习计算机网络知识宏观层面必须要了解的核心点。知道了这些,对于网络的体系结构就基本上了解了。

计算机网络分层一般有三种划分体系:OSI 分层;五层协议分层;TCP/IP 协议分层。
- OSI 的七层体系结构概念清楚,理论完整,但是比较复杂且不实用,所以并不流行。
- 五层协议分层是一种折中方案,在现实中更为流行。
物理层
物理层(Physical Layer)负责在物理介质上传输原始比特流(0 和 1)。它定义了设备的电气、机械、功能和规程特性,如电压、线速、线缆、接口、光缆等。
- 要点:调制、解调、数字信号、模拟信号、通信媒介、信道复用
- 数据单元:比特流
- 关键协议/标准:
- RS-232、V.35:古老的串行通信标准。
- IEEE 802.3:以太网的相关物理层标准(如 100BASE-TX)。
- T1/E1、SONET/SDH:电信级传输标准。
- 主要设备:光纤、同轴电缆、双绞线、中继器和集线器。
- 集线器 (Hub):傻瓜式设备,单纯地放大和转发电信号到所有端口。
- 中继器 (Repeater):用于放大信号,延长网络传输距离。
- 调制解调器 (Modem):在数字信号和模拟信号之间进行转换。
- 光纤、同轴电缆
数据链路层
数据链路层(Data Link Layer)负责在同一局域网内的节点之间可靠地传输数据帧。
- 要点:点对点信道、广播信道、局域网、以太网、MAC、适配器
- 帧同步:将比特流组装成帧,标明帧的开始和结束。
- 差错控制:通过 CRC(循环冗余校验)检测物理层产生的比特错误。
- 寻址:使用** MAC 地址**(物理地址)来唯一标识网络设备。
- 流量控制:控制发送速率,防止高速发送方淹没低速接收方。
- 数据单元:帧(frame)
- 关键协议
- 以太网 (Ethernet):目前最主流的局域网技术。
- PPP:点对点协议,常用于拨号上网。
- VLAN (虚拟局域网):在二层交换机上划分逻辑网络。
- CSMA/CD
- 主要设备
- 交换机 (Switch):智能设备,根据目标 MAC 地址将帧转发到特定的端口。
- 网桥 (Bridge):连接两个相似的局域网,现已基本被交换机取代。
网络层
网络层(network layer)负责在不同网络之间(网际互连)进行逻辑寻址和分组路由。
- 要点
- 逻辑寻址:使用** IP 地址**来标识设备和网络。
- 路由选择:根据网络状况,为数据包选择最佳路径。
- 分组与重组:将传输层的数据段封装成数据包。
- 数据单元:IP 数据报(packet)
- 关键协议:
- IP (Internet Protocol):核心协议,负责寻址和路由。
- ICMP:用于网络连通性测试和错误报告,如
ping
、tracert
。 - ARP:将 IP 地址解析为 MAC 地址。
- RIP, OSPF, BGP:动态路由协议。
- 主要设备
- 路由器 (Router):连接不同网络,根据 IP 地址为数据包选择路由。
传输层
传输层(transport layer)负责端到端的通信,为运行在不同主机上的应用进程提供逻辑通信。
- 要点:滑动窗口、拥塞控制、三次握手
- 服务:提供可靠的(TCP)或不可靠的(UDP)数据传输服务。
- 复用与分用:多个应用进程可以同时使用同一传输层服务。
- 差错控制与流量控制:确保数据完整、有序、不丢失地到达。
- 数据单元:报文段(segment)或用户数据报
- 关键协议
- TCP (传输控制协议):面向连接的、可靠的、基于字节流的协议。
- UDP (用户数据报协议):无连接的、尽最大努力交付的协议,效率高。
- 主要设备:
- 防火墙 (Firewall):工作在三、四层(甚至更高),可以根据 IP 和端口进行访问控制。
- 多层交换机:除了二层交换功能,还具备基于 IP 地址的三层路由功能。
会话层
会话层(Session Layer)不参与具体的传输,它提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制。
表示层
表示层(Presentation Layer)是为在应用过程之间传送的信息提供表示方法的服务,它关心的只是发出信息的语法与语义。表示层要完成某些特定的功能,主要有不同数据编码格式的转换,提供数据压缩、解压缩服务,对数据进行加密、解密。
应用层
应用层(application layer)为应用程序提供网络服务接口,是用户与网络的交互界面。
- 数据单元:报文(message)
- 关键协议
- HTTP/HTTPS:万维网数据传送协议。
- FTP:文件传输协议。
- SMTP/POP3/IMAP:电子邮件相关协议。
- DNS:域名系统,将域名解析为 IP 地址。
- DHCP:动态主机配置协议,自动分配 IP 地址。
- WebSocket:全双工通信协议。
- 主要设备:
- 应用网关/代理服务器:工作在应用层,可以对特定应用协议的数据进行解析和控制。
【困难】从输入网址到网页显示,期间发生了什么?🌟🌟
先通过 DNS 找到 IP,再通过 TCP 建立连接,接着通过 TLS 保证安全,最后通过 HTTP 传输页面数据,浏览器最终解析渲染呈现给用户。 整个过程完美体现了网络分层模型的协同工作。
核心流程
- DNS 解析:浏览器查询域名对应的 IP 地址(问路)。
- TCP 握手:与目标 IP 的服务器进行 三次握手,建立可靠连接(拨号接通)。
- TLS 握手(如为 HTTPS):协商加密密钥,建立安全通道(切换加密线路)。
- 发送 HTTP 请求:发出
GET /index.html
等请求报文(说出需求)。 - 接收 HTTP 响应:服务器返回
200 OK
和网页数据(收到包裹)。 - 解析渲染:浏览器解析 HTML/CSS/JS,渲染显示页面(拆包组装货物)。
- 加载资源:对页面中的图片、样式等资源重复步骤 2-5(获取所有零件)。
- TCP 挥手:页面加载完成后,四次挥手释放连接(挂断电话)。
涉及的核心协议与角色
步骤 | 核心协议 | 核心角色 |
---|---|---|
问地址 | DNS ( over UDP ) | DNS 服务器 |
建连接 | TCP | 浏览器、服务器 |
保安全 | TLS ( over TCP ) | 证书颁发机构 (CA) |
传内容 | HTTP/HTTPS ( over TCP ) | Web 服务器 (Nginx/Apache) |
HTTP
【中等】HTTP 1.0 和 2.0 有什么区别?🌟
HTTP/2 通过二进制帧、多路复用和头部压缩三大技术,从根本上解决了 HTTP/1.x 的性能瓶颈,大幅降低了延迟并节省了带宽,是 Web 性能的一次重大飞跃。
核心改进
对比维度 | HTTP/1.0 | HTTP/2.0 | 带来的好处 |
---|---|---|---|
协议格式 | 纯文本 | 二进制帧 | 解析高效、错误少、紧凑 |
连接方式 | 短连接 (每次请求新建 TCP 连接) | 多路复用 (单连接并行处理无数请求) | 极大降低延迟,减少连接开销,解决应用层队头阻塞 |
头部传输 | 无压缩 (每次发送冗余头部) | HPACK 压缩 (静态表+动态表+哈夫曼编码) | 节省大量带宽 (减少 50%-90%头部大小) |
资源推送 | 被动响应 (需客户端先请求) | 服务器主动推送 (预测并推送相关资源) | 减少往返次数,提升页面加载速度 |
资源调度 | 优先级支持弱 | 原生流优先级 (设置权重和依赖) | 优化加载顺序,提升用户体验 |
对开发者的影响
- 语法不变:所有 HTTP 方法 (GET/POST)、状态码 (200/404)、URL 等概念完全保留。
- 无需改代码:性能提升在底层协议栈自动完成,应用层无感知。
- 必须 HTTPS:主流浏览器只支持在加密连接上使用 HTTP/2,推动了全网安全化。
【中等】HTTP 2.0 和 3.0 有什么区别?🌟
HTTP/3 通过将底层协议从 TCP 替换为 QUIC,彻底解决了延迟和连接稳定性的瓶颈,尤其在高丢包和移动网络环境下,性能提升显著。对于开发者而言,HTTP 的语法和 API 保持不变,所有优化都在底层自动完成。
核心改进
对比维度 | HTTP/2 | HTTP/3 | 带来的好处 |
---|---|---|---|
协议 | TCP + TLS (TCP 层丢失包会阻塞所有流) | QUIC (运行在 UDP 之上,丢包只影响单个流) | 高丢包网络下更稳定、更快速 |
连接速度 | 1-3 次往返 (首次握手) | 1 次往返 (首次),支持 0-RTT (重连) | 连接建立更快,重复访问速度极快 |
网络切换 | 连接会中断 (IP 变化导致 TCP 连接断裂) | 无缝连接 (通过连接 ID 标识,与 IP 无关) | Wi-Fi/5G 切换无感知,体验更流畅 |
安全与纠错 | 需 TLS 加密 | 默认加密,支持前向纠错 | 安全性更高,抗丢包能力更强 |
【中等】HTTP 和 HTTPS 有什么区别?🌟
HTTPS = HTTP + 加密 + 身份认证 + 数据完整性保护,是 HTTP 的安全升级版,已成为现代网站的必备标准。
核心差异
特性对比 | HTTP | HTTPS |
---|---|---|
数据传输 | 明文,不安全 | 加密,防窃听、防篡改 |
身份认证 | 无,可能遇到假网站 | 有,通过 SSL 证书验证真身 |
默认端口 | 80 | 443 |
浏览器显示 | 网址前显示 “不安全” | 网址前显示 “锁”图标🔒 |
【中等】HTTPS 的加密过程是怎样的?
HTTPS 先通过非对称加密“安全地约定”一个密码本(会话密钥),之后双方就一直用这个密码本进行对称加密的“秘密通话”。
核心思想:混合加密
- 非对称加密(RSA/ECC):用于安全握手,交换密钥。安全但慢。
- 对称加密(AES/ChaCha20):用于传输数据。快但需解决密钥分发问题。
- HTTPS 的智慧:用非对称加密的安全性来解决对称加密的密钥分发问题。
加密四步曲
打招呼与挑战:
- 客户端和服务器互相交换支持的技术参数和随机数,为生成密钥准备材料。
证书验证:
- 服务器出示由权威机构(CA)颁发的数字证书。
- 客户端验证证书真伪和有效性,并从中提取服务器公钥。
密钥协商
- 客户端生成一个预备主密钥,并用服务器公钥加密后发送。
- 服务器用自己唯一的私钥解密,得到该密钥。
- 此时,双方拥有了相同的三个随机数(Client Random, Server Random, Premaster Secret),据此独立计算出相同的会话主密钥。
加密通信:握手完成,后续所有数据传输都使用刚生成的会话密钥进行高效的对称加密/解密。
为什么这么做?
- 安全:非对称加密保证了密钥交换过程无法被窃听。
- 高效:对称加密保证了海量数据传输的速度。
- 身份认证:数字证书确保了你在和真正的目标服务器通信,而非中间人。
【中等】HTTP 与 RPC 之间的区别?🌟
- HTTP:一种具体的通信协议(如邮寄的“标准信封格式”)。
- RPC:一种通信概念/范式(“像调用本地函数一样调用远程服务”的理念),可以用 HTTP 或其他协议来实现。
核心对比
特性维度 | HTTP (常指 RESTful API) | RPC (如 gRPC, Dubbo) |
---|---|---|
设计目标 | 通用资源操作(GET/POST/PUT/DELETE) | 远程方法调用 |
性能 | 文本传输(JSON/XML),性能相对较低 | 二进制编码(Protobuf 等),性能高 |
协议 | 标准 HTTP 协议 | 可基于 TCP 自定义协议,也可基于 HTTP/2 |
适用场景 | 对外开放 API,跨语言跨平台 | 内部微服务调用,追求高性能治理 |
服务治理 | 需依赖网关、Mesh 等外部组件 | 内置服务发现、熔断等治理能力 |
一句话总结
- 对外(开放 API)用 HTTP:通用、标准、兼容性无敌。
- 对内(微服务)用 RPC:高效、治理能力强、性能极致。
现代趋势:两者边界模糊,gRPC 等现代 RPC 框架直接基于** HTTP/2 **传输,兼顾了性能与通用性。
TCP
【中等】什么是 TCP 协议?
TCP(Transmission Control Protocol),即传输控制协议,它是一种面向连接的、可靠的、基于字节流的传输层通信协议。
核心机制
机制 | 作用 | 简单比喻 |
---|---|---|
连接管理 | 通过三次握手建立连接,四次挥手断开连接。 | 打电话前先拨通,说完再见再挂断。 |
确认重传 | 接收方收到包必须回复确认,发送方没收到确认就重发。 | 寄挂号信,必须签收回执,没回执就再寄。 |
排序机制 | 给每个数据包标序号,接收方按序号重组,保证数据有序。 | 拼图游戏,每块都有编号,按顺序拼好。 |
流量控制 | 接收方告知自身处理能力,防止发送方发得太快导致数据溢出。 | 根据食堂阿姨打饭快慢,调整递盘子的速度。 |
【困难】TCP 三次握手的过程是怎样的?
❓ 问题:三次握手有什么用?什么是三次握手?为什么需要三次握手?
(1)三次握手有什么用?
- 三次握手负责建立 TCP 双向连接。
(2)什么是三次握手?
如上图所示,三次握手流程如下:
- 第一次握手 - 客户端向服务端发送带有 SYN 标志的数据包。
- 第二次握手 - 服务端向客户端发送带有 SYN/ACK 标志的数据包。
- 第三次握手 - 客户端向服务端发送带有带有 ACK 标志的数据包。
至此,TCP 三次握手完成,客户端与服务端已建立双向连接。
💡 说明:SYN 为 synchronize 的缩写,ACK 为 acknowledgment 的缩写。
(3)为什么需要三次握手?
为了便于说明,假设客户端为 A, 服务端为 B。
- 第一次握手,A 向 B 发同步消息。B 收到消息后,B 认为:A 发消息没问题;B 收消息没问题。
- 第二次握手,B 向 A 发同步消息和确认消息。A 收到消息后,A 认为:A 发消息、收消息都没问题;B 发消息、收消息都没问题。但是,此时 B 不确定自己发消息是否没问题,所以就需要第三次握手。
- 第三次握手,A 向 B 发确认消息。B 收到消息后。B 认为:B 发消息没问题。
【困难】TCP 四次挥手的过程是怎样的?
❓ 问题:四次挥手有什么用?什么是四次挥手?为什么建立连接是三次握手,关闭连接确是四次挥手呢?
(1)四次挥手有什么用?
- 四次挥手负责断开 TCP 连接。
(2)什么是四次挥手?
如上图所示,四次挥手流程如下:
- 第一次挥手 - 客户端向服务端发送一个 FIN 包,用来关闭客户端到服务端的数据传送。
- 第二次挥手 - 服务端收到这个 FIN 包,向客户端发送一个 ACK 包,确认序号为收到的序号加 1。和 SYN 一样,一个 FIN 将占用一个序号。
- 第三次挥手 - 服务端关闭与客户端的连接,向客户端发送一个 FIN 包。
- 第四次挥手 - 客户端向服务端发送 ACK 包,并将确认序号设置为收到序号加 1。
(3)为什么建立连接是三次握手,关闭连接确是四次挥手呢?
- 建立连接的时候, 服务器在 LISTEN 状态下,收到建立连接请求的 SYN 报文后,把 ACK 和 SYN 放在一个报文里发送给客户端。
- 而关闭连接时,服务器收到对方的 FIN 报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送 FIN 报文给对方来表示同意现在关闭连接,因此,己方 ACK 和 FIN 一般都会分开发送,从而导致多了一次。
【困难】TCP 滑动窗口原理是什么?
❓ 问题:什么是滑动窗口?滑动窗口原理是什么?
什么是滑动窗口?
滑动窗口是 TCP 的一种控制网络流量的技术。
TCP 必需要解决的可靠传输以及包乱序(reordering)的问题,所以,TCP 必需要知道网络实际的数据处理带宽或是数据处理速度,这样才不会引起网络拥塞,导致丢包。
TCP 头里有一个字段叫 Window,又叫 Advertised-Window,这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。
滑动窗口原理是什么?

- 已发送已确认 - 数据流中最早的字节已经发送并得到确认。这些数据是站在发送端的角度来看的。上图中的 31 个字节已经发送并确认。
- 已发送但尚未确认 - 已发送但尚未得到确认的字节。发送方在确认之前,不认为这些数据已经被处理。上图中的 32 ~ 45 字节为第 2 类。
- 未发送而接收方已 Ready - 设备尚未将数据发出 ,但接收方根据最近一次关于发送方一次要发送多少字节确认自己有足够空间。发送方会立即尝试发送。上图中的 46 ~ 51 字节为第 3 类。
- 未发送而接收方 Not Ready - 由于接收方 not ready,还不允许将这部分数据发出。上图中的 52 以后的字节为第 4 类。

这张图片相对于上一张图片,滑动窗口偏移了 5 个字节,意味着有 5 个已发送的字节得到了确认。
【困难】TCP 重传机制是什么?
❓ 问题:为什么需要重传机制?TCP 有哪些重传机制,原理是什么?
TCP 重传机制确保数据可靠传输,应对网络丢包。
四大触发原因
- 数据包丢失(真丢了)
- 确认 ACK 丢失(对方回了,回执丢了)
- 确认 ACK 延迟(回执来太慢,等不及了)
- 接收方处理慢(对方收到了但没来得及回)
两大核心机制
机制 | 工作原理 | 特点 |
---|---|---|
超时重传 | 为一个包启动定时器,时间到了(**RTO **超时)就重传。 | 最后保险,效率低,性能差。 |
快速重传 | 收到** 3 个重复 ACK**(意味着后序包到了但前面缺包),不等超时立刻重传缺包。 | 效率高,大幅减少等待时间。 |
优化补丁:SACK
- 作用:在快速重传基础上,接收方告诉发送方具体丢了哪些包。
- 好处:实现精确重传,只重传真正丢失的包,避免浪费带宽。
【困难】TCP 的粘包和拆包能说说吗?
TCP 是字节流协议,它只保证数据顺序,不维护应用层消息的边界。像用消防水管喝水,发送方是一杯杯倒(消息),接收方是一桶桶接(字节流),一桶里可能有多杯或半杯。
TCP 粘包拆包是因其字节流特性导致的必然现象,必须在应用层自行定义消息边界,而在消息头中携带长度字段是最通用、最有效的解决方案。
现象 | 描述 | 简单比喻 |
---|---|---|
粘包 | 接收方一次收到多个应用消息包。 | 收到[AB] 而不是[A][B] |
拆包/半包 | 接收方一次只收到一个应用消息包的部分。 | 收到[A-] 和[-B] 而不是完整的[A] |
最主流解决方案:长度字段法
在应用层协议中,给每个消息添加一个固定长度的消息头,头里写明后面消息体的长度。
- 发送端:先发 4 字节头(长度),再发实际数据。
- 接收端:先读取
4
字节头,解析出长度 N;再读取 N 字节,即为一个完整应用消息。
这是绝大多数 RPC 框架(如 gRPC、Dubbo)和自定义二进制协议的首选方案。
其他解决方案
方法 | 做法 | 优点 | 缺点 | 应用场景 |
---|---|---|---|---|
定长法 | 每个消息固定长度 | 简单 | 浪费带宽 | 极少使用 |
分隔符法 | 用特殊字符(如\n )标记消息结束 | 灵活 | 需处理内容转义 | 文本协议(如 Redis) |
用现成协议 | 使用 HTTP 等高级协议 | 省心 | 开销可能较大 | Web 应用 |
【中等】TCP 和 UDP 有什么区别?
最根本区别
- TCP:可靠优先,像打电话,需要连接和确认。
- UDP:速度优先,像发短信/喊话,无连接直接发。
核心对比
特性 | TCP (传输控制协议) | UDP (用户数据报协议) |
---|---|---|
连接 | 面向连接 (需三次握手) | 无连接 (直接发送) |
可靠性 | 可靠,不丢包,不乱序 | 不可靠,尽最大努力交付 |
传输模式 | 字节流 (需处理粘包) | 数据报文 (有消息边界) |
速度 | 慢 | 快 |
控制机制 | 有流量控制、拥塞控制 | 无任何控制 |
如何选择
- 要准确:选 TCP。用于网页、邮件、文件传输。
- 要速度:选 UDP。用于视频、语音、直播、游戏。
本质是权衡:用 TCP 的延迟换取可靠,或用 UDP 的不可靠换取低延迟。