八股（五）计算机网络

😺计算机网络基础

[OSI 七层模型](#OSI 七层模型)

[TCP/IP 四层模型](#TCP/IP 四层模型)

为什么网络要分层？

[从输入 URL 到页面展示到底发生了什么？](#从输入 URL 到页面展示到底发生了什么？)

[HTTP 状态码](#HTTP 状态码)

[HTTP Header](#HTTP Header)

[HTTP vs HTTPS](#HTTP vs HTTPS)

[HTTP/1.1 vs HTTP/2.0](#HTTP/1.1 vs HTTP/2.0)

[HTTP 是不保存状态的协议, 如何保存用户状态?](#HTTP 是不保存状态的协议, 如何保存用户状态?)

[URI vs URL](#URI vs URL)

[Cookie vs Session](#Cookie vs Session)

[GET vs POST](#GET vs POST)

😺WebSocket

[WebSocket vs HTTP](#WebSocket vs HTTP)

[WebSocket 工作过程](#WebSocket 工作过程)

[WebSocket 与短轮询、长轮询的区别](#WebSocket 与短轮询、长轮询的区别)

[SSE vs WebSocket](#SSE vs WebSocket)

😺PING

😺DNS

[DNS 解析流程](#DNS 解析流程)

[DNS 劫持](#DNS 劫持)

[😺TCP vs UDP](#😺TCP vs UDP)

[TCP or UDP?](#TCP or UDP?)

[HTTP 基于 TCP 还是 UDP？](#HTTP 基于 TCP 还是 UDP？)

[基于 TCP/UDP 的协议](#基于 TCP/UDP 的协议)

[😺TCP 三次握手](#😺TCP 三次握手)

半连接队列和全连接队列

三次握手过程中可以携带数据吗？

[😺TCP 四次挥手](#😺TCP 四次挥手)

[为什么不能把服务端发送的 ACK 和 FIN 合并起来，变成三次挥手？](#为什么不能把服务端发送的 ACK 和 FIN 合并起来，变成三次挥手？)

[为什么 TIME_WAIT 要等 2MSL？](#为什么 TIME_WAIT 要等 2MSL？)

[TCP 如何保证传输的可靠性？](#TCP 如何保证传输的可靠性？)

😺IP

[什么是 IP 地址？](#什么是 IP 地址？)

[IPv4 vs IPv6](#IPv4 vs IPv6)

NAT

😺ARP

[Mac 地址](#Mac 地址)

[ARP 协议解决了什么问题？](#ARP 协议解决了什么问题？)

😺计算机网络基础

OSI 七层模型

Open Systems Interconnection（开放式系统互联模型）

第7层：应用层（Application）提供网络应用服务，HTTP、HTTPS、FTP、DNS

第6层：表示层（Presentation）数据格式转换、加密解密、压缩解压，UTF-8、JSON / XML

第5层：会话层（Session）建立、管理、终止会话连接，登录状态、会话保持、断点恢复

第4层：传输层（Transport）端到端通信 + 可靠传输，TCP、UDP

第3层：网络层（Network）IP寻址 + 路由转发，IP、ICMP、ARP

第2层：数据链路层（Data Link）局域网内传输，MAC地址、帧封装、差错检测

第1层：物理层（Physical）0 和 1 的物理传输，网线、光纤、电信号、无线电波

其核心思想是分层解耦，每层只负责自己的职责。

Q：HTTP 属于哪一层？

A：应用层

Q：IP 地址属于哪一层？

A：网络层。

Q：TCP 和 UDP 属于哪层？

A：传输层。

TCP/IP 四层模型

TCP/IP 四层模型是目前互联网中实际广泛使用的网络分层模型。

应用层，提供应用协议和业务服务。如 HTTP、DNS。
传输层，进程到进程通信。如 TCP、UDP。
网络层，IP寻址 + 路由转发。如 IP。
网络接口层/链路层，负责局域网通信和物理传输。

TCP/IP 不能和 OSI 完全精确一一对应，但可以大致映射。

为什么网络要分层？

各层之间相互独立 ：各层之间相互独立，各层之间不需要关心其他层是如何实现的，只需要知道自己如何调用下层提供好的功能就可以了（可以简单理解为接口调用）。这个和我们对开发时系统进行分层是一个道理。
提高了灵活性和可替换性 ：每一层都可以使用最适合的技术来实现，你只需要保证你提供的功能以及暴露的接口的规则没有改变就行了。并且，每一层都可以根据需要进行修改或替换，而不会影响到整个网络的结构。这个和我们平时开发系统的时候要求的高内聚、低耦合的原则也是可以对应上的。
大问题化小 ：分层可以将复杂的网络问题分解为许多比较小的、界线比较清晰简单的小问题来处理和解决。这样使得复杂的计算机网络系统变得易于设计，实现和标准化。这个和我们平时开发的时候，一般会将系统功能分解，然后将复杂的问题分解为容易理解的更小的问题是相对应的，这些较小的问题具有更好的边界（目标和接口）定义。

应用层常见协议

应用层是 TCP/IP 四层模型的最高层 ，也是最接近用户的一层。它主要负责定义应用程序之间如何通信。比如：浏览网页、发邮件、文件传输、域名解析、远程登录，这些都属于应用层协议。

一句话记忆：网页HTTP，域名DNS，远程SSH，邮件SMTP。

HTTP（Hypertext Transfer Protocol，超文本传输协议）：浏览器和服务器通信。
基于 TCP 协议，是一种用于传输超文本和多媒体内容的协议，主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的。⚠️HTTPS = HTTP + SSL/TLS加密。
SMTP（Simple Mail Transfer Protocol，简单邮件发送协议）：发送邮件。
基于 TCP 协议，是一种用于发送电子邮件的协议。⚠️SMTP 协议只负责邮件的发送，而不是接收。
POP3 / IMAP（邮件接收协议）：接收邮件。
基于 TCP 协议，两者都是负责邮件接收的协议。POP3偏下载式，邮件下载到本地。IMAP 协议比 POP3 在功能和性能上都更加强大，支持多设备同步，支持邮件搜索、标记、分类、归档等高级功能。几乎所有现代电子邮件客户端和服务器都支持 IMAP。
FTP（File Transfer Protocol，文件传输协议） : 文件上传 / 下载。
基于 TCP 协议，是一种用于在计算机之间传输文件的协议，可以屏蔽操作系统和文件存储方式。⚠️FTP 是一种不安全、明文传输的协议，因为它在传输过程中不会对数据进行加密。建议在传输敏感数据时使用更安全的协议，如 SFTP。
Telnet（远程登陆协议）：基于 TCP 协议，用于通过一个终端登陆到其他服务器。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用 Telnet，而是使用一种称为 SSH 的非常安全的网络传输协议的主要原因。
SSH（Secure Shell Protocol，安全的网络传输协议）：安全远程登录服务器。
基于 TCP 协议，通过加密和认证机制实现安全的访问和文件传输等业务，Linux。
RTP（Real-time Transport Protocol，实时传输协议）：通常基于 UDP 协议，但也支持 TCP 协议。它提供了端到端的实时传输数据的功能，但不包含资源预留存、不保证实时传输质量，这些功能由 WebRTC 实现。
DNS（Domain Name System，域名管理系统）: 域名 -> IP地址。
通常基于 UDP 协议（端口 53），用于解决域名和 IP 地址的映射问题。当响应数据过大或进行区域传送时会改用 TCP。

Q：DNS 为什么通常用 UDP？

A：因为请求报文小，UDP 无连接，速度快。

Q：HTTP 基于 TCP 还是 UDP？

A：基于 TCP。

Q：SMTP 和 IMAP 区别？

A：SMTP 负责发送邮件，IMAP 负责接收邮件。

传输层常见协议

传输层是 TCP/IP 四层模型中的第二层 ，它主要负责进程和进程之间的数据传输，注意不是机器和机器，机器之间是网络层的 IP。

例如：浏览器、Redis、MySQL、Tomcat这些都是不同进程。Redis -> 6379、MySQL -> 3306、Tomcat -> 8080这些端口号就是传输层核心概念。

TCP（Transmission Control Protocol，传输控制协议） ：提供 面向连接 的，可靠的数据传输服务。适合网页访问、数据库通信、文件传输、登录请求，Java 后端最常见 HTTP 基于 TCP、MySQL 基于 TCP、Redis 基于 TCP。

UDP（User Datagram Protocol，用户数据协议） ：提供 无连接 的，尽最大努力 的数据传输服务（不保证数据传输的可靠性），简单高效。适合视频直播、语音通话、游戏、DNS。

TCP优先可靠性，UDP优先性能和实时性。例如视频通话，偶尔丢一帧没关系，但卡顿很致命，所以更适合 UDP。

Q：HTTP 基于 TCP 还是 UDP？

A：基于 TCP。

Q：DNS 为什么很多时候用 UDP？

A：因为数据包小，速度要求高。

Q：为什么视频通话常用 UDP？

A：因为实时性优先，允许少量丢包。

网络层常见协议

网络层负责跨网络寻址和路由转发，即数据包应该发给哪台机器，走哪条路。

比如你访问 www.baidu.com 最终解析出 IP：110.xxx.xxx.xxx，然后数据包需要经过很多路由器才能到达目标服务器，这就是网络层在工作。

IP（Internet Protocol，网际协议）：IP地址寻址 + 路由转发。
TCP/IP 协议中最重要的协议之一，属于网络层的协议，主要作用是定义数据包的格式、对数据包进行路由和寻址，以便它们可以跨网络传播并到达正确的目的地。目前 IP 协议主要分为两种，一种是过去的 IPv4，另一种是 IPv6，目前这两种协议都在使用，但后者已被提议来取代前者。IPv6（128位地址）是为了解决 IPv4（32位，192.168.1.1）地址耗尽问题。
ARP（Address Resolution Protocol，地址解析协议）：IP地址 -> MAC地址。
ARP 协议解决的是网络层地址和链路层地址之间的转换问题。因为一个 IP 数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。
ICMP（Internet Control Message Protocol，互联网控制报文协议）：ping 网络诊断 + 错误报告，主要用来判断：网络是否通、延迟多少、是否丢包。
一种用于传输网络状态和错误消息的协议，常用于网络诊断和故障排除。例如，Ping 工具就使用了 ICMP 协议来测试网络连通性。
NAT（Network Address Translation，网络地址转换协议）：私网IP -> 公网IP。
NAT 协议的应用场景如同它的名称------网络地址转换，应用于内部网到外部网的地址转换过程中。具体地说，在一个小的子网（局域网，LAN）内，各主机使用的是同一个 LAN 下的 IP 地址，但在该 LAN 以外，在广域网（WAN）中，需要一个统一的 IP 地址来标识该 LAN 在整个 Internet 上的位置。你家 WiFi 路由器就在做这个事。
OSPF（Open Shortest Path First，开放式最短路径优先）：一种内部网关协议（Interior Gateway Protocol，IGP），也是广泛使用的一种动态路由协议，基于链路状态算法，考虑了链路的带宽、延迟等因素来选择最佳路径。
RIP(Routing Information Protocol，路由信息协议）：一种内部网关协议（Interior Gateway Protocol，IGP），也是一种动态路由协议，基于距离向量算法，使用固定的跳数作为度量标准，选择跳数最少的路径作为最佳路径。
BGP（Border Gateway Protocol，边界网关协议）：一种用来在路由选择域之间交换网络层可达性信息（Network Layer Reachability Information，NLRI）的路由选择协议，具有高度的灵活性和可扩展性。

Q：ping 用的是什么协议？

A：ICMP。

Q：ARP 的作用是什么？

A：将 IP 地址解析成 MAC 地址。

Q：NAT 为什么重要？

A：节省公网 IP 地址资源，实现内网访问公网。

😺HTTP

从输入 URL 到页面展示到底发生了什么？

⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️能一路串起 DNS、TCP、HTTP、浏览器渲染、缓存、网络分层。

URL → DNS → TCP → HTTP → 服务端处理 → 响应 → 浏览器渲染

① 用户输入 URL。比如浏览器输入 www.baidu.com。

② DNS 域名解析。浏览器不能直接识别域名，必须先把 www.baidu.com 解析成 IP 地址，例如 110.xxx.xxx.xxx。此处基于 DNS 协议，通常基于 UDP 53。

③ 建立 TCP 连接。拿到 IP 后，浏览器会向服务器发起连接。如果是 HTTP：80端口，如果是 HTTPS：443端口，底层通过 TCP 三次握手建立连接，如果是 HTTPS，还会继续进行 TLS/SSL 握手。这里就是TCP 协议。

④ 发送 HTTP 请求。连接建立后，浏览器发送请求报文。这里就是HTTP 协议。

⑤ 服务器处理请求。服务器收到请求后开始处理，然后生成响应。

⑥ 返回 HTTP 响应。

⑦ 浏览器解析和渲染页面。

HTTP 状态码

HTTP 是客户端和服务器通信协议，请求发过去后，客户端必须知道结果，状态码就是一个统一标准。200 = 面试通过，404 = 人没找到，500 = 面试官系统崩了。

1 继续，2 成功，3 跳转，4 客户端错，5 服务端错。

分类	状态码	名称	含义	高频场景
1xx 信息响应	100	Continue	继续请求	大请求体上传前确认
2xx 成功	200	OK	请求成功	查询接口成功
2xx 成功	201	Created	资源创建成功	新增用户 / 创建订单
2xx 成功	204	No Content	成功但无返回体	删除接口 DELETE
3xx 重定向	301	Moved Permanently	永久重定向	HTTP 跳 HTTPS
3xx 重定向	302	Found	临时重定向	登录跳转
3xx 重定向	304	Not Modified	资源未修改，走缓存	浏览器缓存
4xx 客户端错误	400	Bad Request	请求参数错误	参数格式 / JSON格式错误
4xx 客户端错误	401	Unauthorized	未认证 / 未登录	token 失效/不存在
4xx 客户端错误	403	Forbidden	已认证但无权限访问	普通用户访问管理员接口
4xx 客户端错误	404	Not Found	资源不存在	URL 写错 / 接口不存在
4xx 客户端错误	405	Method Not Allowed	请求方法错误	GET 调了 POST 接口
5xx 服务器错误	500	Internal Server Error	服务器内部错误	代码异常，空指针 / SQL异常
5xx 服务器错误	502	Bad Gateway	网关错误	Nginx 转发异常
5xx 服务器错误	503	Service Unavailable	服务不可用	宕机 / 限流
5xx 服务器错误	504	Gateway Timeout	网关超时	上游服务超时

HTTP 协议本身是文本协议，除了请求路径和请求体，还需要一些"元信息"，所以 Header 用来补充说明【请求上下文信息】。用来告诉服务器：我发的是什么格式？我是谁？token 是什么？是否允许缓存？浏览器是什么？

Host 请求的目标主机，Host: www.baidu.com。
【JSON传输】Content-Type 请求体数据类型，Content-Type: application/json。
Content-Length 请求体长度，Content-Length: 348。
【token认证】Authorization 认证信息，Authorization: Bearer token。
【登录Session】Cookie 客户端携带的 Cookie，Cookie: JSESSIONID=xxxx。
【浏览器识别】User-Agent 客户端身份信息，User-Agent: Chrome。

Q：Header 和 Body 的区别？

A：Header 放描述信息，Body 放真实业务数据。

Q：token 为什么通常放 Header？

A：通常放在 Authorization 字段中，符合 HTTP 认证规范，便于统一拦截和解析。

Q：JSON 请求为什么要设置 Content-Type？

A：告诉服务器按 JSON 格式解析请求体。

JWT（JSON Web Token）

JWT 是一种基于 Token 的无状态身份认证方案，通常用于用户登录和接口鉴权。

JWT 的结构：Header.Payload.Signature

Header（头部）+ Payload（载荷）+ Signature（签名）

Header 保存元信息。

Payload 保存用户信息，只是 Base64 编码，不加密，所以不能放密码、敏感隐私数据。

Signature 是最核心部分，用于 防篡改。

JWT 登录流程：

第一步：登录。

第二步：服务端校验，校验成功后生成 JWT。

第三步：返回 token 给前端。

第四步：后续请求携带 Authorization: Bearer xxx。

第五步：服务端校验，拦截器 / Filter 验证签名和过期时间。

HTTP vs HTTPS

HTTP 明文传输，HTTPS 加密传输。HTTPS = HTTP + TLS（Transport Layer Security）

复制代码

HTTPS
↓
SSL / TLS
↓
TCP
↓
IP

	HTTP	HTTPS
全称	HyperText Transfer Protocol	HTTP over TLS（Transport Layer Security）
安全性	❌ 明文传输，不安全	✅ 加密传输，安全
端口号	80	443
URL前缀	http://	https://
是否加密	❌ 否	✅ 是（TLS加密）
加密方式	无	非对称加密用于安全交换对称密钥，对称加密用于后续数据传输
性能	更快	略慢（握手+加密）
身份认证	无	有（CA证书）
是否防篡改	❌ 否	✅ 是
SEO排名	一般	更优先

Q：HTTPS 为什么安全？

A：因为使用 SSL/TLS 实现加密传输、身份认证和防篡改机制。

Q：为什么不全程使用非对称加密？

A：因为非对称加密性能较低，只适合密钥交换，不适合大数据传输。

Q：HTTPS 一定安全吗？

A：不一定，如果证书被伪造或私钥泄露仍可能被攻击。

HTTP/1.1 vs HTTP/2.0

HTTP/1.1 采用文本格式传输，通常使用多个 TCP 连接，每个连接串行处理请求，存在队头阻塞问题，并且 Header 不支持压缩。

HTTP/2.0 在 HTTP/1.1 的基础上进行了优化，引入了多路复用机制，使多个请求可以在同一个 TCP 连接中并行交错传输，同时使用二进制帧提高传输效率，并通过 HPACK 对 Header 进行压缩，还支持服务器推送机制，从而显著提升性能。

对比项	HTTP/1.1	HTTP/2.0
连接方式	多 TCP 连接（浏览器限制6~8个）	单 TCP 连接
请求处理	串行 / 队列式	多路复用（并行）
队头阻塞	应用层存在	应用层解决，但TCP仍存在
数据格式	文本格式	二进制帧
Header处理	不压缩	HPACK压缩
性能	较低	更高
Server Push（服务端推送）	❌ 不支持	✅ 支持
连接利用率	低	高

多路复用：一个 TCP 连接中，同时传输多个请求/响应，但仍然存在 TCP 层的队头阻塞问题。

复制代码

请求1 ─┐
请求2 ─┼── 同一个TCP连接交错传输
请求3 ─┘

HTTP 是不保存状态的协议, 如何保存用户状态?

HTTP 协议本身是无状态协议（服务器不会自动记住用户），必须额外设计用户状态保存机制。

方案一：Session (会话) 配合 Cookie (主流方式)

传统 Session 用户信息存在服务器，每次请求要查服务器。

用户登录 → 服务端创建 Session → 生成 SessionID（存在内存/Redis）→ 返回 Cookie → 浏览器保存 Cookie → 后续自动携带 Cookie → 服务端根据 SessionID 找 Session

方案二：Token-based 认证（现代主流，尤其适用于前后端分离的架构和微服务）

Token 信息存在客户端，比如浏览器的 localStorage，每次请求解析Token。

项目中：Redis + JWT（整体上是方案一）

Session 思想（存入redis） + Token 形式（JWT 是 Token 的一种实现方式）

登录成功 → 生成 token → 用户信息存 Redis → token 返回前端 → 拦截器校验

如果没有 Cookie 的话 Session 还能用吗？

一般是通过 Cookie 来保存 SessionID ，假如你使用了 Cookie 保存 SessionID 的方案的话，如果客户端禁用了 Cookie，那么 Session 就无法正常工作。

但是，并不是没有 Cookie 之后就不能用 Session 了，比如你可以将 SessionID 放在请求的 url 里面 https://javaguide.cn/?Session_id=xxx 。这种方案的话可行，但是安全性和用户体验感降低。当然，为了安全你也可以对 SessionID 进行一次加密之后再传入后端。

URI vs URL

URI 的全称是 统一资源标识符（Uniform Resource Identifier） ，用于唯一标识一个资源，关键在于**【标识】**。

URL 的全称是 统一资源定位符（Uniform Resource Locator） ，URL 是 URI 的一种具体实现，不仅能够标识资源，还能够提供资源的访问路径和定位信息，关键在于**【定位】**。

Cookie 本质上是存储在浏览器（客户端）的一小段数据。

Session 本质上是存储在服务器端的会话数据。

Cookie 存 sessionId，Session 存用户数据。

存储位置不同
Cookie 存储在客户端浏览器，Session 存储在服务器端。

安全性不同
Cookie 数据暴露在客户端，安全性较低；Session 数据保存在服务端，安全性更高。

容量不同
Cookie 一般大小限制在 4KB 左右，Session 容量相对更大。

作用关系
通常服务器会将 SessionId 存入 Cookie，客户端后续请求自动携带该 Cookie，服务器通过 SessionId 查找对应会话数据。

Q：分布式系统为什么少用 Session？

A：因为多台服务器之间 Session 难共享，通常使用 Redis 或 JWT。

项目中没有用本地内存Session，因为Session 无法天然跨机器共享。

实现方式：Redis + Token + 双拦截器 + ThreadLocal。

第一步：用户登录（生成一个随机 token）

第二步：将用户信息以 login:token:{token} 的形式存入 Redis，并设置过期时间。

第三步：把 token 返回前端，前端将 token 保存到 localStorage，后续请求通过 authorization 请求头携带 token。

双拦截器设计：

第一个拦截器 RefreshTokenInterceptor 拦截所有请求，从 Redis 查询用户信息，保存到 ThreadLocal，并刷新 token TTL。（负责刷新 token）

第二个拦截器 LoginInterceptor 只拦需要登录的接口，从 ThreadLocal 获取当前用户，不存在则返回 401。（负责登录校验）

传统 Session 存储在单台服务器 JVM 内存中，分布式部署时请求可能被转发到不同机器，导致 Session 无法共享。而 Redis 是独立的共享缓存服务，所有应用实例都访问同一个 Redis，因此无论请求落到哪台服务器，都能读取同一份用户登录信息。

所以说：Redis 通过共享状态存储天然支持分布式部署

GET vs POST

GET 用于获取资源，POST 用于提交数据 / 创建资源。

GET 和 POST 的核心区别在于语义。

GET 通常用于获取或查询资源，属于幂等操作，多次请求不会修改服务器状态。

POST 通常用于提交数据、创建资源或修改资源，通常不是幂等操作。

此外，GET 参数通常放在 URL 中，POST 参数通常放在请求体中。

GET 请求通常支持缓存，因为 GET 请求是幂等的，它可以被浏览器或其他中间节点缓存起来，以提高性能和效率。而 POST 请求不适合被缓存，每次执行可能需要实时的响应。

安全性上，GET 请求和 POST 请求如果使用 HTTP 协议的话，那都不安全，因为 HTTP 协议本身是明文传输的，必须使用 HTTPS 协议来加密传输数据。另外，GET 请求相比 POST 请求更容易泄露敏感数据，因为 GET 请求的参数通常放在 URL 中。

😺WebSocket

WebSocket 是一种基于 TCP 的全双工通信协议，属于应用层协议，它主要用于解决 HTTP 协议无法实现服务端主动推送的问题。

WebSocket 通过一次 HTTP 握手完成协议升级，建立持久连接后，客户端和服务器都可以主动发送和接收消息，实现双向实时通信。

常见应用场景包括实时聊天、消息推送、弹幕系统和多人协同编辑。

WebSocket vs HTTP

WebSocket 和 HTTP 两者都是基于 TCP 的应用层协议，都可以在网络中传输数据。

HTTP 是请求-响应模型，WebSocket 是双向实时通信模型。

HTTP 是请求-响应模型，只能由客户端主动发起请求，服务器被动响应。

WebSocket 是全双工双向通信协议，客户端和服务器都可以主动发送消息。

此外，WebSocket 建立的是长连接，通信开销更小，更适合实时消息推送、聊天和弹幕等场景。

	HTTP	WebSocket
通信方式	单向，请求-响应	双向，全双工
谁主动发起	只能客户端主动请求	客户端和服务端都可主动发送
连接特点	通常一次请求一次响应（逻辑短连接）	建立后保持长连接
实时性	较差，需要轮询	很强，适合实时推送
数据开销	每次都带完整请求头	帧头较小，开销低
协议前缀	`http://` `https://`	`ws://` `wss://`
典型场景	登录、查询、下单	聊天、弹幕、消息推送
服务端主动推送	不支持	支持
性能特点	高频通信性能一般	高频实时通信性能更好

Q：HTTP 能实现实时通信吗？

A：可以轮询，但效率低，不如 WebSocket。

Q：WebSocket 为什么性能更好？

A：长连接 + 头部小 + 双向通信。

Q：全双工是什么？

A：全双工指通信双方可以在同一时刻同时发送和接收数据。与半双工不同，全双工不需要一方等待另一方发送完成。

WebSocket 工作过程

WebSocket 的工作过程可以分为以下几个步骤：

客户端向服务器发送一个 HTTP 请求，请求头中包含 Upgrade: websocket 和 Sec-WebSocket-Key 等字段，表示要求升级协议为 WebSocket；
服务器收到这个请求后，会进行升级协议的操作，如果支持 WebSocket，它将回复一个 HTTP 101 状态码，响应头中包含，Connection: Upgrade和 Sec-WebSocket-Accept: xxx 等字段、表示成功升级到 WebSocket 协议。
客户端和服务器之间建立了一个 WebSocket 连接，可以进行双向的数据传输。数据以帧（frames）的形式进行传送，WebSocket 的每条消息可能会被切分成多个数据帧（最小单位）。发送端会将消息切割成多个帧发送给接收端，接收端接收消息帧，并将关联的帧重新组装成完整的消息。
客户端或服务器可以主动发送一个关闭帧，表示要断开连接。另一方收到后，也会回复一个关闭帧，然后双方关闭 TCP 连接。

WebSocket 与短轮询、长轮询的区别

这三种方式，都是为了解决"客户端如何及时获取服务器最新数据，实现实时更新"的问题。

短轮询是客户端定时发送 HTTP 请求查询服务器是否有新数据，实时性较差且存在大量无效请求，反复建立/关闭连接，且大多数请求收到的都是"无新消息"，极大增加服务器和网络压力。

长轮询是客户端发起请求后，服务器若无数据则保持连接等待，直到有数据或超时再返回，实时性较好但仍占用连接资源，需长时间维护大量连接，消耗服务器线程/连接数。

WebSocket 是客户端与服务器通过一次 HTTP Upgrade 握手后，建立一条持久的 TCP 连接。之后，双方可以随时、主动地发送数据，实现真正的全双工、低延迟通信。实现起来比短轮询和长轮询要更麻烦一些。

SSE vs WebSocket

SSE (Server-Sent Events) 和 WebSocket 都是用来实现服务器向浏览器实时推送消息的技术，让网页内容能自动更新，而不需要用户手动刷新。

SSE 是"单向 HTTP 流式推送"，WebSocket 是"双向长连接通信"。

SSE 是基于 HTTP 协议的单向通信技术，本质上是一个"长连接"的 HTTP 请求，不需要特殊的服务器或协议支持，现有的 HTTP 基础设施就能用。只支持服务器向客户端推送数据，客户端通过 EventSource 接收数据，浏览器原生支持，EventSource API 提供了自动断线重连的机制。主要设计用来传输文本 (UTF-8)，如果需要传输二进制数据，需要先进行 Base64 等编码转换成文本。

WebSocket 是基于 TCP 的双向通信协议，需要通过一个特定的 HTTP "Upgrade" 请求来建立连接，并且服务器需要明确支持 WebSocket 协议来处理连接和消息帧。通过 HTTP Upgrade 建立连接后，客户端和服务器可以互相发送数据，适合实时交互场景。开发者需要自己编写逻辑来检测断线并进行重连尝试。原生支持传输文本和二进制数据，无需额外编码。

因此，SSE 更适合单向推送场景，如日志流、AI 流式输出，而 WebSocket 更适合聊天等双向通信场景。

Q：SSE 和 WebSocket 哪个更轻量？

A：SSE 更轻量，因为基于 HTTP，无需协议升级。

Q：为什么 AI 用 SSE？

A：支持流式输出 + HTTP 兼容性好 + 自动重连。SSE 基于 HTTP 长连接，可以在同一个请求中持续分块返回数据，天然支持流式传输，同时具备良好的浏览器兼容性和基础设施支持。相比 WebSocket，AI 场景通常是单向推送，不需要双向通信，因此 SSE 在功能上已经足够。同时实现更简单、成本更低，并且支持浏览器自动断线重连，更适合长时间生成任务的稳定输出。

😺PING

PING 命令是基于 ICMP 协议（网络层）实现的网络诊断工具，用于测试主机之间的连通性和网络延迟。

底层做了什么？主要原理就是通过在网络上发送和接收 ICMP 报文实现的。

PING 命令会向目标主机发送 ICMP Echo Request 请求报文（A → B：你在吗？）
如果两个主机的连通性正常，目标主机会返回一个对应的 ICMP Echo Reply 响应报文（B → A：我在）

作用：

测试连通性：判断两台主机网络是否可达。
测试延迟（RTT）：RTT = 往返时间，请求发出去 → 响应回来的时间。
测试丢包率：如果丢包，网络不稳定 / 路由问题。

PING 输出信息怎么看？

bash 复制代码

# 发送4个PING请求数据包到 www.baidu.com
❯ ping -c 4 www.baidu.com

PING www.a.shifen.com (14.119.104.189): 56 data bytes
64 bytes from 14.119.104.189: icmp_seq=0 ttl=54 time=27.867 ms
64 bytes from 14.119.104.189: icmp_seq=1 ttl=54 time=28.732 ms
64 bytes from 14.119.104.189: icmp_seq=2 ttl=54 time=27.571 ms
64 bytes from 14.119.104.189: icmp_seq=3 ttl=54 time=27.581 ms

--- www.a.shifen.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 27.571/27.938/28.732/0.474 ms

TTL：数据包还能经过多少个路由器，TTL 越大，距离可能越近或网络路径更优。
RTT（time）：用于衡量网络延迟。常见标准< 50ms 很快，50-100ms 正常，> 200ms 慢。
丢包率：用于判断网络稳定性。0% packet loss。

😺DNS

DNS（Domain Name System）域名管理系统（应用层协议），是当用户使用浏览器访问网址之后，使用的第一个重要协议。DNS 要解决的是域名和 IP 地址的映射问题。

DNS 是应用层协议，它可以在 UDP 或 TCP 协议之上运行，端口为 53 。目前 DNS 的设计采用的是分布式、层次数据库结构。

DNS 解析流程

DNS 的作用就是把域名（www.baidu.com）转换成 IP 地址（220.181.xxx.xxx）。

DNS 的查询解析过程分为两种模式：

**递归：**从请求主机到本地 DNS 服务器的查询是递归的。
**迭代：**其余的查询是迭代的。

通常客户端先向本地 DNS 服务器发起递归查询，本地 DNS 若缓存未命中，则采用迭代查询方式依次向根 DNS、顶级域 DNS 和权威 DNS 查询目标域名的 IP 地址。

DNS 缓存主要存在于本地 DNS 服务器（递归解析器）。

DNS 劫持

DNS 劫持是一种网络攻击，它通过修改 DNS 服务器的解析结果，使用户访问的域名指向错误的 IP 地址，从而导致用户无法访问正常的网站，或者被引导到恶意的网站。DNS 劫持有时也被称为 DNS 重定向、DNS 欺骗或 DNS 污染。

😺TCP vs UDP

|----------|------------------------------------------------------------|---------------------------------------------------------------|
| | TCP | UDP |
| 连接性 | 面向连接 "三次握手"建立连接，"四次挥手"来释放连接。 | 无连接直接把数据包（数据报）扔出去。 |
| 可靠性 | 可靠序列号、确认应答（ACK）、超时重传、流量控制、拥塞控制。数据能够无差错、不丢失、不重复且按顺序地到达目的地。 | 不可靠（尽力而为）不保证顺序，不会自动重传，接收方不会发确认。 |
| 状态维护 | 有状态 TCP 需要在连接的两端维护连接状态信息 | 无状态（因此开销更小） |
| 传输效率 | 较低 | 较高 |
| 传输形式 | 面向字节流将应用程序交付的数据视为一连串无结构的字节流，可能会对数据进行拆分或合并。 | 面向数据报 (报文) 应用程序交给 UDP 多大的数据块，UDP 就照样发送，既不拆分也不合并，保留了应用程序消息的边界。 |
| 头部开销 | 20 - 60 字节（包含选项字段） | 8 字节 |
| 通信模式 | 点对点（单播通信） | 单播、多播、广播 |
| 常见应用 | HTTP/HTTPS, FTP, SMTP, SSH | DNS, DHCP, SNMP, TFTP, VoIP, 视频流 |

TCP or UDP?

主要取决于你的应用对数据传输的可靠性要求有多高，以及对实时性和效率的要求有多高。

当数据准确性和完整性至关重要，一点都不能出错时，通常选择 TCP。例如：

Web 浏览 (HTTP/HTTPS): 网页内容、图片、脚本必须完整加载才能正确显示。
文件传输 (FTP, SCP): 文件内容不允许有任何字节丢失或错序。
邮件收发 (SMTP, POP3, IMAP): 邮件内容需要完整无误地送达。
远程登录 (SSH, Telnet): 命令和响应需要准确传输。
......

当实时性、速度和效率优先，并且应用能容忍少量数据丢失或乱序时，通常选择 UDP。例如：

实时音视频通信 (VoIP, 视频会议, 直播): 偶尔丢失一两个数据包（可能导致画面或声音短暂卡顿）通常比因为等待重传（TCP 机制）导致长时间延迟更可接受。应用层可能会有自己的补偿机制。
在线游戏: 需要快速传输玩家位置、状态等信息，对实时性要求极高，旧的数据很快就没用了，丢失少量数据影响通常不大。
......

HTTP 基于 TCP 还是 UDP？

HTTP/1.x、HTTP/2 基于 TCP ；HTTP/3 基于 UDP（上层封装 QUIC 协议）。

彻底解决队头阻塞：
QUIC 实现真正独立的多路复用流。
一个流丢包，只阻塞当前流，不影响其他流。
大幅降低连接建立延迟
QUIC 将 TCP 握手 + TLS 握手合并。
支持 1-RTT 握手，甚至 0-RTT 重连。
最佳情况0 额外往返即可发数据。

基于 TCP/UDP 的协议

运行于 TCP 协议之上的协议 (强调可靠、有序传输)：

中文全称 (缩写)	英文全称	主要用途	说明与特性
超文本传输协议 (HTTP)	HyperText Transfer Protocol	传输网页、超文本、多媒体内容	HTTP/1.x 和 HTTP/2 基于 TCP。早期版本不加密，是 Web 通信的基础。
安全超文本传输协议 (HTTPS)	HyperText Transfer Protocol Secure	加密的网页传输	在 HTTP 和 TCP 之间增加了 SSL/TLS 加密层，确保数据传输的机密性和完整性。
文件传输协议 (FTP)	File Transfer Protocol	文件传输	传统的 FTP 明文传输，不安全。推荐使用其安全版本 SFTP (SSH FTP) 或 FTPS (FTP over SSL/TLS) 。
简单邮件传输协议 (SMTP)	Simple Mail Transfer Protocol	发送电子邮件	负责将邮件从客户端发送到服务器，或在邮件服务器之间传递。
邮局协议第 3 版 (POP3)	Post Office Protocol version 3	接收电子邮件	通常将邮件从服务器下载到本地设备后删除服务器副本 (可配置保留)。POP3S 是其 SSL/TLS 加密版本。

运行于 UDP 协议之上的协议 (强调快速、低开销传输)：

中文全称 (缩写)	英文全称	主要用途	说明与特性
超文本传输协议 (HTTP/3)	HyperText Transfer Protocol version 3	新一代网页传输	基于 QUIC 协议 (QUIC 基于 UDP)，旨在减少延迟、解决 TCP 队头阻塞问题。
域名系统 (DNS)	Domain Name System	域名到 IP 地址的解析	通常使用 UDP 进行快速查询。当响应数据包过大或进行区域传送时，会切换到 TCP 以保证数据完整性。
实时传输协议 (RTP)	Real-time Transport Protocol	实时音视频数据流传输	常用于 VoIP、视频会议、直播等。追求低延迟，允许少量丢包。

😺TCP 三次握手

⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️TCP 三次握手就是客户端和服务端在正式传输数据前，先确认双方都具备收发能力，并同步初始序列号（Synchronize Sequence Numbers）的过程。

-- 你：喂，能听到吗？

-- 对方：能听到，你能听到我吗？

-- 你：能听到

Synchronize 同步 Sequence Numbers 序列号，SYN（Synchronize），seq（Sequence）

第一次握手 SYN：客户端发送 SYN（seq = x），客户端状态变成 SYN_SENT（sent）。

SYN 表示我要和你建立连接，同时告诉服务端：我的初始序列号是 x。

第二次握手 SYN+ACK：服务端收到后回复 SYN + ACK（seq = y，ack = x + 1），服务端状态变成 SYN_RCVD（received）。

ACK 表示我收到你的连接请求了，确认号 ack = x + 1。

SYN 表示我也要建立连接，同时告诉客户端：我的初始序列号是 y。

第三次握手 ACK：客户端收到后再回复 ACK（ack = y + 1），客户端、服务器状态变成ESTABLISHED，连接建立完成。

ACK 表示我也收到了你的确认，确认号 ack = y + 1。

经过三次握手后，双方都确认了彼此的发送和接收能力，连接正式建立。

为什么必须三次？

第一次证明客户端发送能力正常，第二次证明服务端接收正常、服务端发送正常，第三次证明客户端接收正常。所以三次后双方发送和接收能力都被确认了。三次握手是确保 TCP 连接可靠性的最小且必需的步骤。

半连接队列和全连接队列

服务端为了管理 TCP 三次握手过程中的连接，会维护两个队列。

**半连接队列（SYN Queue）：**用于保存三次握手未完成的连接，即服务端收到 SYN 并回复 SYN+ACK 后，连接处于 SYN_RCVD 状态。
**全连接队列（Accept Queue）：**握手完成后进入全连接队列（ESTABLISHED），等待应用程序取走。

队列	作用	状态	移出条件
半连接队列（SYN Queue）	保存未完成握手连接	SYN_RCVD	收到 ACK / 超时重传失败
全连接队列（Accept Queue）	保存已完成握手连接	ESTABLISHED	被应用层 accept() 取出

三次握手过程中可以携带数据吗？

TCP 三次握手中，只有第三次握手可以携带数据。

因为客户端在发送第三次 ACK 后即进入 ESTABLISHED 状态，此时连接已经建立成功，因此允许顺便发送业务数据，以减少一次 RTT，提高传输效率。

如果第三次 ACK 丢失，但后续数据包中携带 ACK 标志位，服务端仍可将其视为有效确认并建立连接。

😺TCP 四次挥手

⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️四次挥手就是 TCP 连接断开时，双方分别关闭各自发送通道的过程。

第一次挥手（FIN）：客户端发送 FIN（seq = x），客户端状态变成 FIN_WAIT_1。

FIN 表示我这边已经没有数据要发了，只是我不发了，不代表对方不能发。

第二次挥手（ACK）：服务端收到后回复 ACK（ack = x + 1），服务端状态变成 CLOSE_WAIT，客户端状态变成 FIN_WAIT_2。

ACK 表示我知道你不发了。

第三次挥手（FIN）：服务端确认自己的数据也发完了，发送 FIN（seq = y），服务端状态变成 LAST_ACK。

FIN 表示我也发完了。

第四次挥手（ACK）：客户端回复 ACK（ack = y + 1），客户端状态变成 TIME_WAIT，服务端状态变成 CLOSED。

ACK 表示我知道你不发了。

为什么要四次挥手？

TCP 采用全双工通信，客户端和服务端的发送方向彼此独立。因此关闭连接时，需要分别关闭两个方向的发送通道。主动关闭方发送 FIN 后，被动关闭方先回复 ACK，表示确认收到关闭请求，但此时仍可能继续发送剩余数据。待数据发送完毕后，再发送 FIN，由主动关闭方回复最终 ACK。因此通常需要四次挥手。

为什么不能把服务端发送的 ACK 和 FIN 合并起来，变成三次挥手？

ACK 和 FIN 通常不能合并，核心原因是两者触发时机不同。当服务端收到客户端 FIN 时，TCP 内核会立即自动回复 ACK，用于确认关闭请求。而服务端自己的 FIN 需要等待应用层处理完剩余业务逻辑，并调用 close() 或 shutdown() 后才会发送。

因此 ACK 和 FIN 在时间上通常解耦，所以一般需要四次挥手。只有在服务端恰好也立即关闭时，才可能出现 ACK 和 FIN 合并的特殊情况。

为什么 TIME_WAIT 要等 2MSL？

第四次挥手时，客户端发送给服务端的 ACK 有可能丢失，如果服务端因为某些原因而没有收到 ACK 的话，服务端就会重发 FIN，如果客户端在 2*MSL 的时间内收到了 FIN，就会重新发送 ACK 并再次等待 2MSL，防止 Server 没有收到 ACK 而不断重发 FIN。

MSL(Maximum Segment Lifetime) : 一个片段在网络中最大的存活时间，2MSL 就是一个发送和一个回复所需的最大时间。如果直到 2MSL，Client 都没有再次收到 FIN，那么 Client 推断 ACK 已经被成功接收，则结束 TCP 连接。

TCP 如何保证传输的可靠性？

1）序列号（保证有序 + 去重）：将接收到的数据根据序列号排序，并且去掉重复序列号的数据就可以实现数据包去重。

2）确认应答 ACK（保证送达）

3）重传机制（保证不丢）：在数据包丢失或延迟的情况下，重新发送数据包，直到收到对方的确认应答（ACK）。

4）校验和（保证数据不损坏）：TCP 将保持它首部和数据的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。

5）流量控制（防止压垮接收方）：TCP 使用的流量控制协议是可变大小的滑动窗口协议。

6）拥塞控制（防止压垮网络）：网络的拥塞程度由拥塞窗口表示，它是发送方根据网络状况自己维护的一个值，表示发送方认为可以在网络中传输的数据量。

😺IP

IP（Internet Protocol，网际协议） 是 TCP/IP 协议中最重要的协议之一，属于网络层的协议，主要作用是定义数据包的格式、对数据包进行路由和寻址，以便它们可以跨网络传播并到达正确的目的地。

什么是 IP 地址？

IP 地址是互联网中用于唯一标识网络设备的逻辑地址，每台联网设备都拥有一个 IP 地址。在网络通信过程中，数据包中会携带源 IP 地址和目的 IP 地址。每个 IP 地址都是一个字符序列，如 192.168.1.1（IPv4）、2001:0db8:85a3:0000:0000:8a2e:0370:7334（IPv6）。

路由器根据目的 IP 地址查询路由表，并将数据包逐跳转发到目标网络，最终到达目标主机。其中 IP 协议主要负责寻址和路由，不保证可靠传输。

Q：IP 和 MAC 地址区别？

A：IP 是逻辑地址，用于跨网络寻址；MAC 是物理地址，用于局域网通信。

Q：为什么还需要 DNS？

A：因为人记域名比记 IP 更方便，DNS 负责域名到 IP 的映射。

Q：IP 为什么不能保证可靠？

A：IP 只负责路由转发，不负责确认、重传和排序。

IP 地址过滤是根据客户端 IP 地址对访问请求进行允许或拒绝的一种安全控制措施。

IPv4 vs IPv6

IPv4 是目前广泛使用的 IP 协议版本，采用 32 位地址，理论上最多支持约 42 亿个地址，由于互联网设备快速增长，IPv4 地址已经逐渐枯竭。

IPv6 是 IPv4 的升级版本，采用 128 位地址，地址空间极大，几乎可以为每个设备提供唯一 IP。

相比 IPv4，IPv6 具有更大的地址空间、简化的报文头结构、支持自动配置（SLAAC）、取消 NAT 依赖，并提升了网络安全性与扩展能力。

Q：为什么 IPv4 需要 NAT？

A：因为 IPv4 地址不足，需要通过 NAT 让多个内网设备共享公网 IP。

Q：IPv6 为什么不需要 NAT？

A：因为地址空间足够大，每个设备都可以分配独立公网 IP。

NAT

NAT（Network Address Translation）是网络层的一种地址转换技术，用于将内网的私有 IP 地址转换为公网 IP 地址，或者将公网 IP 转换回内网地址。

第一，解决 IPv4 地址不足的问题，使多个内网设备可以共享一个公网 IP 访问互联网。

第二，提高网络安全性，通过隐藏内部网络结构，使外部无法直接访问内网设备。

第三，维护 IP 与端口的映射关系，实现请求返回时的正确路由。

NAT 工作时会在路由设备上维护一张映射表，记录内网 IP:端口与公网 IP:端口之间的对应关系，从而保证双向通信的正确性。

Q：NAT 和防火墙有什么区别？

A：NAT 做地址转换。防火墙做访问控制（允许/拒绝）。

😺ARP

Mac 地址

MAC 地址（Media Access Control Address）是网络设备网卡的唯一标识，用于在局域网中唯一标识一个网络接口。

bash 复制代码

00:1A:2B:3C:4D:5E

MAC 地址长度为 48 位：

前 24 位：厂商编号（IEEE 分配）
后 24 位：厂商自己生成

保证全球唯一。

MAC 地址工作在数据链路层，主要用于局域网内的数据帧传输。在通信过程中，数据最终是通过 MAC 地址进行投递的，而 IP 地址主要用于跨网络的路由寻址。

在局域网通信时：

先通过 IP 找到目标网络
再通过 ARP 协议找到目标 MAC
数据帧最终是靠 MAC 地址传输的

本质：MAC 才是真正的数据链路交付地址

Q：IP 和 MAC 有什么区别？

A：IP 是网络层逻辑地址，用于跨网络路由；MAC 是数据链路层物理地址，用于局域网内通信。

Q：MAC 地址会变吗？

A：通常不会变，因为它写在网卡中，但在虚拟化环境中可以被软件修改。MAC 地址在硬件层面是唯一且固化的，但在操作系统和网络层面可以被修改或伪装，因此严格来说"改的是使用值，而不是物理地址本身"。

ARP 协议解决了什么问题？

ARP（Address Resolution Protocol，地址解析协议）用于解决网络层 IP 地址与数据链路层 MAC 地址之间的映射问题。

在局域网通信中，数据最终是通过 MAC 地址进行传输的，而应用层通常只知道目标 IP 地址，因此需要通过 ARP 协议将 IP 地址解析为对应的 MAC 地址。

ARP 的基本工作流程是：发送方通过广播 ARP 请求报文询问目标 IP 对应的 MAC 地址，目标主机收到后返回 ARP 响应报文，告知自己的 MAC 地址，并由发送方缓存该映射关系，从而完成后续通信。

Q：ARP 是广播还是单播？

A：ARP 请求是广播，ARP 响应是单播。

广播发给局域网所有人，类似：📢 "全班同学注意：谁是 192.168.1.10？"

单播只发给一个确定目标，类似：📩 "我已经知道你是谁了，只发给你一个人"