计算机网络

IT枫斗者大约 25 分钟Java八股文Java八股文计算机网络

阅读提示

建议先看题目目录，再按“概念 -> 原理 -> 场景 -> 优化”顺序复习。
每题先讲结论，再补关键机制和项目实践，回答会更稳。

适用范围：ARP 示例以 IPv4 以太网为例；TCP 连接状态以 RFC 9293（2022）为准；拥塞控制先讲 RFC 5681 的经典算法；HTTP 方法语义依据 RFC 9110（2022），并区分 HTTP/1.1、HTTP/2 与 HTTP/3。协议机制不等于某个操作系统或框架的默认配置。

1、网络7层架构是什么？

应用层（数据）：确定进程之间通信的性质以满足用户需要以及提供网络与用户应用
表示层（数据）：主要解决用户信息的语法表示问题，如加密解密
会话层（数据）：提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制，这是参考模型的职责划分，实际 Web 登录验证通常由应用层实现
运输层（段）：实现网络不同主机上用户进程之间的数据通信，可靠与不可靠的传输，传输层的错误检测，流量控制等
网络层（包）：提供逻辑地址（IP）、选路，数据从源端到目的端的传输
数据链路层（帧）：包含 MAC 等子层，将上层数据封装成帧，用MAC地址访问媒介，错误检测；是否纠错或重传取决于具体链路协议
物理层（比特流）：设备之间比特流的传输，物理接口，电气特性等

2、TCP/IP 四层模型？

应用层：对应于OSI参考模型的（应用层、表示层、会话层）。
传输层: 对应OSI的传输层，为应用进程提供端到端通信；TCP 提供可靠、有序的字节流，UDP 不保证交付或顺序。
网际层：对应于OSI参考模型的网络层，主要解决主机到主机的通信问题。
网络接口层：与OSI参考模型的数据链路层、物理层对应。

3、请简单说下ARP协议的工作过程？

主机先查路由表确定出口与下一跳：同链路通信通常解析目的主机的 MAC；跨网段通信解析网关的 MAC，而不是远端主机的 MAC。
若 ARP 缓存已有下一跳 IPv4 地址对应的有效 MAC，直接封装以太网帧；否则在本地链路广播 ARP Request，询问谁拥有这个下一跳地址。
拥有该地址的主机通常单播回复 ARP Reply；发送方更新缓存后发送数据。请求重试仍无响应时，本次邻居解析失败，不等于能断定远端主机已关机。

4、请简单说下ARP协议的工作过程？

这一题可结合跨网段示意理解：IP 目的地址与以太网帧的目的 MAC 不一定属于同一台设备。

A: 192.168.1.10/24  →  网关: 192.168.1.1  →  B: 192.168.2.20/24
A 查路由后 ARP 查询 192.168.1.1
A 发出的帧：目的 MAC = 网关 MAC；内部 IP 包：目的 IP = B

ARP 广播不会由路由器转发到远端子网。接收方会根据已有缓存和是否为请求目标更新映射，不能简单理解为“非目标设备一律忽略所有信息”。ARP 不提供身份认证；IPv6 使用 ICMPv6 邻居发现而不是 ARP。参见 RFC 826 的生成与接收算法、RFC 4861。

5、TCP和UDP什么区别？

TCP 面向连接，提供可靠、有序的字节流，不保留应用消息边界；应用需用长度字段或分隔符等方式划分消息。UDP 无连接并保留数据报边界，自身不提供重传、排序、流量控制或拥塞控制；应用或上层协议可补充这些能力（如 QUIC）。TCP 的可靠性也不意味着网络中断后仍保证成功交付，应用仍须处理连接错误。

6、详细说下 TCP 三次握手的过程？

三次握手
TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 报文段。

最初客户端和服务端都处于 CLOSED(关闭) 状态。本例中 A（Client）主动打开连接，B（Server）被动打开连接。
一开始，B 的 TCP 服务器进程首先创建传输控制块TCB，准备接受客户端进程的连接请求。然后服务端进程就处于 LISTEN(监听) 状态，等待客户端的连接请求。如有，立即作出响应。
第一次握手：A 的 TCP 客户端进程也是首先创建传输控制块 TCB。然后，在打算建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN=1，同时选择一个初始序号 seq = x。本例 SYN 不携带数据；协议允许 SYN 携带数据，但在连接确认前不能将数据交付应用。SYN 标志本身消耗一个序号。这时，TCP 客户进程进入 SYN-SENT（同步已发送）状态。
第二次握手：B 收到连接请求报文后，如果同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。本例 SYN+ACK 不携带数据，SYN 本身同样消耗一个序号。这时 TCP 服务端进程进入 SYN-RCVD（同步收到）状态。
第三次握手：TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。这时 ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态；B 在收到有效的第三次握手 ACK 后才进入 ESTABLISHED。

7、为什么两次握手不可以呢？

为了防止已经失效的连接请求报文段突然又传送到了 B，因而产生错误。比如下面这种情况：A 发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达 B。本来这是一个早已失效的报文段。但是 B 收到此失效的链接请求报文段后，就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。
对于上面这种情况，如果不进行第三次握手，B 发出确认后就认为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。
如果采用了三次握手，由于 A 实际上并没有发出建立连接请求，对于已无对应连接的旧 SYN+ACK，A 通常回复 RST，使 B 清理半连接；若无有效回应，B 也会在重试超时后清理。第三次握手让 B 确认 A 收到了自己的初始序号。

8、为什么不需要四次握手？

有人可能会说 A 发出第三次握手的信息后在没有接收到 B 的请求就已经进入了连接状态，那如果 A 的这个确认包丢失或者滞留了怎么办？
第三次握手已经确认了双方的初始序号，不需要再为纯 ACK 增加一次握手。若最后的 ACK 丢失，B 仍处于 SYN-RCVD，可重传 SYN+ACK，A 再回复 ACK；后续带有效确认号的数据也可能完成确认。若持续丢包，则重试最终超时，建立连接仍可能失败。参见 RFC 9293 §3.5。

9、详细说下 TCP 四次挥手的过程？

数据传输结束后，通信的双方都可以释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。

第一次挥手：A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u（等于前面已传送过的数据的最后一个字节的序号加 1），这时 A 进入 FIN-WAIT-1（终止等待1）状态，等待 B 的确认。请注意：TCP 规定，FIN 报文段即使不携带数据，也将消耗掉一个序号。
第二次挥手：B 收到连接释放报文段后立即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v（等于 B 前面已经传送过的数据的最后一个字节的序号加1），然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务端进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。A 收到来自 B 的确认后，就进入 FIN-WAIT-2(终止等待2)状态，等待 B 发出的连接释放报文段。
第三次挥手：若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。假定 B 的序号为 w（在半关闭状态，B 可能又发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态，等待 A 的确认。
第四次挥手：A 在收到 B 的连接释放报文后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号 seq = u + 1（前面发送的 FIN 报文段要消耗一个序号）。然后进入 TIME-WAIT(时间等待) 状态。请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，A 才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果 B 一收到 A 的确认就进入 CLOSED 状态，然后撤销传输控制块。在本例的正常关闭路径中，B 先于 A 关闭；TIME-WAIT 用于应对最后 ACK 丢失后的 FIN 重传，并让旧报文过期。ACK 与 FIN 可以合并，因此关闭不一定恰好四个报文段；同时关闭和 RST 中止也不遵循这一示例路径。

10、TCP 协议是如何保证可靠传输的？

数据包校验：通过校验和检测传输差错，但无法检出所有可能的变化，也不提供抗篡改认证，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；
丢弃重复数据：对于重复数据，能够丢弃重复数据；
应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。可以采用延迟确认，但并非所有 ACK 都延迟，失序报文等场景通常需及时反馈；
超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制：TCP 连接的接收端缓冲空间有限，大小可以由实现动态调整。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

11、谈下你对 TCP 拥塞控制的理解？使用了哪些算法？

拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。
拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致于过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
RFC 5681 描述的经典 TCP 拥塞控制包含四种相互配合的算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。
慢开始：
慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的负荷情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 以字节计；在持续有数据、ACK 正常返回且未受其他限制时，慢开始阶段每 RTT 近似翻倍。初始窗口并非固定为 1 MSS；RFC 6928 的实验性方案允许最多 10 MSS（还受字节上限约束），实际取值依实现而定。
拥塞避免：
拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即经典拥塞避免阶段每 RTT 大约增加 1 MSS，而不是增加 1 字节；这不是所有拥塞控制算法的统一增长规则。
快重传与快恢复：
在 TCP/IP 中，快速重传和快恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。
经典快重传在收到三个重复 ACK 时推断报文段丢失并重传，无须等到重传超时。重复 ACK 也可能由重排序产生，因此这是一种丢包推断；没有快重传并不意味着定时器会让整个连接立即暂停。
经典 Reno 快恢复在调整 ssthresh 和 cwnd 后继续利用 ACK 反馈发送，避免每次丢包都退回慢开始；多包丢失时恢复效率可能降低。现代实现还可结合 SACK、RACK-TLP 等机制，不能把“收到三个重复 ACK”当成唯一丢包检测条件。

参考：RFC 5681 §3、RFC 6928 §2、RFC 8985。

11、说下 GET 和 POST 的区别？

GET 请求目标资源的表示；POST 请求目标资源按其自身语义处理提交的内容，例如创建订单、提交表单，并不限于更新资源。两者都各自是一次 HTTP 请求。即使用 Expect: 100-continue 先等临时响应再发送内容，也仍是同一次请求；TCP 分包次数不等于 HTTP 请求次数。
GET 是安全且幂等的方法：安全指客户端不请求改变资源状态，幂等指多次相同请求的预期服务器效果与一次相同，并非每次响应内容必须相同。访问日志等副作用不违背安全语义。POST 不保证幂等，业务可用幂等键等机制防止重复下单。
查询参数位于 URI 的 query 部分，不是请求头字段；在 HTTP/1.1 中通常出现在请求行。POST 同样可以带查询参数，请求体也不限于表单。GET 请求内容没有普遍定义的语义，可能被中间件拒绝，不宜依赖 GET body 传参。
%E4%BD%A0%E5%A5%BD 是“你好”的 UTF-8 字节的百分号编码，不是 Base64，也不是加密。表单编码 application/x-www-form-urlencoded 将空格编码为 +；这一规则不能泛化到所有 URI 部分。
POST 不自带加密，传输机密性依赖 HTTPS。URL 参数更容易出现在历史记录和访问日志中，但请求体也可能被记录，敏感数据的保护不能只靠更换方法。
HTTP 没有规定 GET/POST 的统一大小上限；URI、请求头、请求体均受客户端、代理和服务器配置限制。POST 并非无限大。

方法语义适用于 HTTP/1.1、HTTP/2、HTTP/3；报文在线路上的表示不同。参见 RFC 9110 §9.2–9.3、RFC 3986 §2.1。

什么是 Cookie？
HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，浏览器会根据 Domain、Path、Secure 等属性及浏览器的 Cookie 策略决定是否随请求发送它。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。
Cookie 主要用于以下三个方面：
会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等）
什么是 Session？
Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。服务端 Session 通常在超时或显式失效时结束，关闭浏览器不等于服务端立即销毁 Session。常见机制是浏览器携带会话 ID，服务端据此查找状态；多实例部署需考虑共享存储或会话路由。

作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
存取方式的不同，Cookie 值须符合协议字符约束，非 ASCII 数据需先编码；Session 可保存的数据类型取决于框架与存储，分布式存储通常还要求可序列化，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 的有效期由服务端管理；关闭浏览器可能丢失会话 Cookie，但不会直接通知服务端销毁 Session，浏览器恢复功能也可能保留它。
隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，但客户端持有的会话 ID 被窃取后仍可能遭到会话劫持，需结合 HTTPS、Secure、HttpOnly 等保护。
存储大小不同， RFC 6265 建议通用客户端至少支持每个 Cookie 4096 字节（名称、值与属性合计），实际限制依浏览器而定；这不是业务可依赖的无限配额。Session 容量受服务端内存、存储与框架限制。

Cookie 的存储、发送规则与容量建议参见 RFC 6265 §5–6。

14、对称加密与非对称加密有什么区别？

对称加密：指加密和解密使用同一密钥，优点是运算速度较快，缺点是如何安全将密钥传输给另一方。常见的对称加密算法有：AES 等。

非对称加密：指的是加密和解密使用不同的密钥（即公钥和私钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。常见的非对称加密算法有RSA。

15、Http请求的过程与原理?

HTTP 是应用层协议，可以传递 HTML、图片、JSON 等表示。下面以新建连接的 HTTP/1.1 为例；HTTPS 还需 TLS 握手，HTTP/2 通常复用 TCP 连接，而 HTTP/3 使用基于 UDP 的 QUIC，不能套用 TCP 三次握手。

Http请求过程
客户端进行DNS域名解析，得到对应的IP地址
根据这个IP，找到对应的服务器建立连接（三次握手）
建立TCP连接后发起HTTP请求（一个完整的http请求报文）
服务器响应HTTP请求，客户端得到html代码
客户端解析html代码，用html代码中的资源(如js,css,图片等等)渲染页面。
HTTP/1.1 默认使用持久连接，可复用以继续请求资源；仅在需要关闭时才释放 TCP 连接，不是每个响应后都四次挥手。DNS、连接和资源也可能命中缓存或复用。

版本依据：RFC 9112 §9、RFC 9114。

16、说说ARP与RARP 的区别？

ARP（Address Resolution Protocol）和RARP（Reverse Address Resolution Protocol）都是用于在网络通信中进行地址转换的协议，但它们在功能、工作方式和用途上有一些区别。
功能不同：
ARP协议用于将IP地址转换为MAC地址。在通信过程中，当一台主机需要知道另一台主机的MAC地址时，它可以使用ARP协议查询目标主机的MAC地址。
RARP协议则用于将MAC地址转换为IP地址。在启动过程中，当一台主机需要知道自己的IP地址时，可以向网络中发送RARP请求，以获取自己的IP地址。
工作方式不同：
ARP协议是一种广播协议。当主机需要知道另一台主机的MAC地址时，它在本地局域网上广播一个ARP请求包，只有目标主机会响应并将自己的MAC地址发送回来。
RARP 客户端在本地链路广播请求，由维护 MAC 到 IP 映射的 RARP 服务器应答，不要求客户端事先知道服务器地址。
用途不同：
由于现代操作系统和网络设备能够自动分配IP地址，RARP协议的使用已经相对较少。
ARP协议在现代网络通信中仍然扮演着重要的角色，用于解析目标主机的MAC地址。
总体而言，ARP和RARP在网络中的地址解析过程中有各自的功能和应用场景，不能把二者当成可互换的地址配置方案；RARP 的广播请求机制见 RFC 903。

17、TCP/IP原理？

TCP/IP 协议不是 TCP 和 IP 这两个协议的合称，而是指因特网整个 TCP/IP 协议族。从协议分层模型方面来讲，TCP/IP 由四个层次组成：网络接口层、网络层、传输层、应用层。

网络访问层(Network Access Layer)
网络访问层(Network Access Layer)在 TCP/IP 参考模型中并没有详细描述，只是指出主机必须使用某种协议与网络相连。
网络层(Internet Layer)
网络层(Internet Layer)是整个体系结构的关键部分，其功能是使主机可以把分组发往任何网络，并使分组独立地传向目标。这些分组可能经由不同的网络，到达的顺序和发送的顺序也可能不同。高层如果需要顺序收发，那么就必须自行处理对分组的排序。互联网层使用因特网协议(IP，Internet Protocol)。
传输层(Transport Layer-TCP/UDP)
传输层(Transport Layer)使源端和目的端机器上的对等实体可以进行会话。在这一层定义了两个端到端的协议：传输控制协议(TCP，Transmission Control Protocol)和用户数据报协议(UDP，User Datagram Protocol)。TCP 是面向连接的协议，它提供可靠的字节流传输和对上层应用的连接服务。为此，除了基本的数据传输外，它还有可靠性保证、流量控制、多路复用等功能；TCP 本身不提供加密和应用身份认证。UDP 是面向无连接的不可靠传输的协议，主要用于不需要 TCP 的排序和流量控制等功能的应用程序。
应用层(Application Layer)
应用层(Application Layer)包含所有的高层协议，包括：虚拟终端协议(TELNET，TELecommunicationsNETwork)、文件传输协议(FTP，File Transfer Protocol)、电子邮件传输协议(SMTP，Simple Mail Transfer Protocol)、域名服务(DNS，Domain Name Service)、网上新闻传输协议(NNTP，Net News Transfer Protocol)和超文本传送协议(HTTP，HyperText Transfer Protocol)等。

18、说下CDN 原理？

CDN 一般包含分发服务系统、负载均衡系统和管理系统
分发服务系统
其基本的工作单元就是各个 Cache 服务器。负责直接响应用户请求，将内容快速分发到用户；同时还负责内容更新，保证和源站内容的同步。根据内容类型和服务种类的不同，分发服务系统分为多个子服务系统，如：网页加速服务、流媒体加速服务、应用加速服务等。每个子服务系统都是一个分布式的服务集群，由功能类似、地域接近的分布部署的Cache 集群组成。在承担内容同步、更新和响应用户请求之外，分发服务系统还需要向上层的管理调度系统反馈各个Cache 设备的健康状况、响应情况、内容缓存状况等，以便管理调度系统能够根据设定的策略决定由哪个 Cache 设备来响应用户的请求。
负载均衡系统：
负载均衡系统是整个 CDN 系统的中枢。负责对所有的用户请求进行调度，确定提供给用户的最终访问地址。
使用分级实现。最基本的两极调度体系包括全局负载均衡（GSLB）和本地负载均衡（SLB）。
GSLB 根据用户地址和用户请求的内容，主要根据就近性原则，确定向用户服务的节点。一般通过 DNS 解析或者应用层重定向（Http 3XX 重定向）的方式实现。
SLB 主要负责节点内部的负载均衡。当用户请求从 GSLB 调度到 SLB 时，SLB 会根据节点内各个Cache 设备的工作状况和内容分布情况等对用户请求重定向。SLB 的实现有四层调度（LVS）、七层调度（Nginx）和链路负载调度等。
管理系统：分为运营管理和网络管理子系统。
网络管理系统实现对 CDN 系统的设备管理、拓扑管理、链路监控和故障管理，为管理员提供对全网资源的可视化的集中管理，通常用 web 方式实现。
运营管理是对 CDN 系统的业务管理，负责处理业务层面的与外界系统交互所必须的一些收集、整理、交付工作。包括用户管理、产品管理、计费管理、统计分析等。