计算机网络面试问题总结

GET和POST请求的区别

• 安全性：

  • GET：语义是从服务器获取指定的资源，是“只读”的，安全且幂等，所以可以对GET请求的数据做缓存，并且在浏览器中GET请求可以保存未书签。
  • POST：语义是根据请求负荷对指定的资源做处理。会修改服务器上的资源，不安全也不幂等。所以浏览器一般不会缓存POST请求，也不能把POST请求保存为书签。

• 请求长度：

  • GET的参数全部都在URL中，请求长度收到URL的限制。
  • POST理论上来说在协议层面没有限制，可能受到内存、网络传输限制

• 参数类型

  • GET：只允许ASCII字符
  • POST：ASCII字符/二进制数据/JSON等

• 编码类型：

  • GET：强制URL编码
  • POST：application/x-www-form-urlencoded（类似GET的URL编码，适合简单表单）、multipart/form-data（适合文件上传）

HTTP状态码

• 200 请求成功
• 201 请求成功，并且创建了新的资源。
• 202：请求已接受，但尚未处理完成。
• 204：请求成功，但没有返回内容。
• 206 部分内容 服务器成功执⾏部分请求 ，应⽤于 HTTP 分块下载或断点续传，响应返回的 body 数据并不是资源的全部，也是处理成功的状态
• 301 永久性重定向，请求的资源已不存在，需⽤新的 URL 访问
• 302 临时重定向，请求的资源还在，暂时需要⽤另⼀个 URL 来访问（系统维护、双十一服务降级）
• 303：请求对应的资源存在另⼀个URL，常⽤于将POST 请求重定向到 GET

• ---

• 400 请求的语法错误
• 401 未授权，一般是用户未登录
• 403 禁止访问资源，禁⽌访问资源，可能是客户端 权限不对
• 404 资源不存在
• 502 服务器作为网关或代理时，从上游服务器收到无效响应。
• 504 网关超时（ ⼀般是应⽤层服务超时，超过了⽹关配置的时间）

TCP和UDP的区别

TCP（传输控制协议）和 UDP（用户数据报协议）是传输层的核心协议，它们的核心区别如下：

1. 连接方式和数据传输

典型表现：
TCP传输文件时不会出错但可能延迟高；UDP直播时可能卡顿但延迟低。

2. 首部开销

应用场景对比

总结：如何选择？

• 用TCP当：
  需要数据完整（如银行转账）、传输大文件、容忍一定延迟。

• 用UDP当：
  追求实时性（如视频通话）、允许少量丢包（如游戏位置更新）、需要多播/广播。

从输入url到界面显示发生了什么？（浏览器怎么加载资源的）

解析URL → DNS解析 → 获取MAC地址 → 建立TCP连接 → （如果使用https）TLS握手 → 浏览器发送HTTP请求报文 → 服务器发送HTTP响应报文 → 页面渲染 → HTTP请求断开连接

渲染过程： 解析HTML → 构建DOM/CSSOM → 渲染树 → 布局 → 绘制 → 合成 → 显示

地址栏输入url地址
浏览器判断URL是否合法，如果不合法：将输入内容作为搜索条件，使用用户默认的搜索引擎进行搜索，大部分浏览器会从历史记录、、书签等地方查找输入的内容并给出智能提示
如果合法：判断是否完整，如果不完整，浏览器可能会对地址进行猜测，补全地址前缀或者后缀。

-> 进行DNS解析
浏览器不能通过域名找到TCP/IP地址，所以需要进行DNS解析，找到对应的IP地址进行访问。这个过程如下：
操作系统会检查本地缓存和hosts文件中是否有这个文件的网址记录，有的话就从记录里面找到对应的IP地址，完成域名的解析。
没有的话，使用TCP/IP种设置的DNS服务器进行查询，如果要查询的内容包含在本地配置资源中，则返回解析结果完成域名的解析。
还没有的话，检查本地DNS服务器是否缓存有该网址记录，有的话就返回解析结果，完成域名的解析。

本地DNS服务器递归地发送查询报文到根域名服务器、顶级域名服务器、权威域名服务器逐级解析，最终返回ip。

本地DNS服务器发送查询报文到根DNS服务器，根DNS服务器收到请求后，返回顶级域DNS服务器地址，然后本地DNS服务器再发送请求报文到顶级域DNS服务器，顶级域DNS服务器收到请求后，返回权威DNS服务器地址，然后本地DNS服务器再发送请求报文到权威DNS服务器，权威DNS服务器收到请求后，返回最终IP地址，完成域名的解析

-> 建立TCP连接
当浏览器获取到服务器的IP地址后，浏览器会通过一个随机的端口号向服务器80端口发起连接请求，这个连接请求到达服务器端后，通过TCP三次握手建立TCP链接

-> 发送http/https请求
建立连接后，就可以通过HTTP进行数据的传输了
若为HTTPS，还需添加一层协议作为加密及认证的服务，HTTPS协议使用SSL和TLS保障信息的安全。SSL的作用是认证客户端和服务器，确保数据发送到正确的客户端和服务器，加密数据防止数据中途被窃取。维护数据的完整性，确保数据在传输过程中不被改变。
TLS协议的作用是用在两个通信应用程序之间，提供保密性和数据完整性。TLS协议有两层，TLS记录协议和TLS握手协议

-> 服务器返回数据
当浏览器到web服务器的链接建立后，浏览器会发送一个初始的HTTP GRET请求，请求目标通常是一个HTML文件，服务器收到请求后，将发回一个HTTP响应报文，内容包括相关的响应头和HTML正文。

-> 浏览器解析并渲染页面
不同的浏览器引擎渲染过程是不太一样的，以谷歌浏览器为例，
首先处理HTML标记并构建DOM树，
第二步，处理CSS标记并构建CSSOM树，
第三步，将DOM树和CSSOM树合并为一棵渲染树，
第四步，根据渲染树来布局，计算每个节点的几何信息，
第五步，将各个节点渲染到屏幕上，这样就完成了页面的渲染。

-> 断开TCP连接

现在的浏览器为了优化请求的耗时，默认都会开启持久链接，也就是说浏览器关闭的时候，TCP链接才会关闭，也就是进行TCP四次挥手

获取MAC地址
⽹络层会将本机地址作为源地址，获取的 IP 地址作为⽬的地址。然后将下发给数据链路层，数据链路层的发送需要加⼊通信双⽅的 MAC 地址，

建立TCP链接三次握手

SYN：客户端发送SYN=1, Seq=x。
SYN-ACK：服务器回复SYN=1, ACK=x+1, Seq=y。
ACK：客户端发送ACK=y+1, Seq=x+1。

TLS握手（HTTPS）

握手协商加密参数：
Client Hello：客户端发送支持的加密算法和随机数。
Server Hello：服务器选择加密算法并返回随机数+证书（含公钥）。
验证证书：客户端验证证书合法性（CA链、有效期等）。
密钥交换：客户端生成预主密钥，用公钥加密发送给服务器。
完成握手：双方根据随机数和预主密钥生成会话密钥，后续通信加密。

关闭TCP连接（四次挥手）
默认HTTP/1.1下保持连接（Connection: keep-alive），若关闭则需四次挥手：
FIN：客户端发送FIN=1, Seq=u。
ACK：服务器回复ACK=u+1。
FIN：服务器发送FIN=1, Seq=v。
ACK：客户端回复ACK=v+1，等待2MSL后关闭。

HTTP 和 HTTPS

• HTTP是超文本传输协议，明文传输，有安全风险。HTTPS在TCP和JHTTP网络层之间加入SSL / TLS安全协议，使得报文加密传输。
• HTTP在TCP三次握手后就可以进行报文传输。HTTPS还需进行SSL / TLS握手过程。
• HTTP默认端口号80.HTTPS默认端口号443

加密方式：混合加密：
TLS握手阶段采用非对称加密。在确保密钥是安全的前提下，后面通信过程全部使用对称加密。

非对称加密用于验证身份和交换密钥

使用对称加密的原因：
对称加密只使用一个密钥，运算速度快，安全等级稍低。
非对称加密使用公钥和私钥，安全等级高但速度慢。

数字签名
发送方用摘要算法对原始数据计算哈希值，该哈希值唯一，且无法逆向推导出内容。将哈希值附加到数据中一起传输。
接收方用相同密钥计算哈希值，比较哈希值，判断内容是否被篡改。

数字证书和数字签名
数字证书验证可靠性，数字签名验证完整性。
证书在TLS握手阶段发送，签名在建立连接后和数据一起发送给客户端。

数字证书：CA私钥签名，客户端用CA公钥验证证书真实性。

跨域、同源

从一个地址请求另一个地址协议、域名、端口，只要不满足其中一个要求，就不符合同源策略，出现跨域。

跨域请求通常是由于前端应⽤程序（例如⽹站或移动应⽤程序）需要访问后端API或其他资源所导致的。为了解决跨域问题，可以使⽤以下⽅法之⼀：

如何解决跨域问题？

1. CORS：最标准的方式是后端开启 CORS ，让浏览器知道“这个跨域请求是被允许的”。CORS是浏览器和服务器之间的⼀种协议，允许跨域资源共享。通过在服务器端添加特殊的HTTP头，可以允许浏览器在跨域情况下访问服务器资源。 Springcloud有提供这方面过滤器的系列方法CorsFilter，可以添加头信息
2. 代理：
   • 由于服务端之间没有跨域，可以在前端应⽤程序的服务器中设置代理，将前端应⽤程序的请求转发到后端API。这样，前端应⽤程序就可以通过与代理服务器的同源连接来访问后端API。
   • 前端开发阶段常用 devServer/proxy 或 Vite proxy ，本质是让本地开发服务器代你转发请求
   • 生产环境常用 Nginx 反向代理，把前端和接口统一到同一域名下
3. JSONP（：利用 < script> 标签不受同源策略限制的特性，通过script标签的src属性进行跨域请求，并通过回调函数将数据返回给前端应⽤程序来实现跨域。这种⽅法通常只能⽤于GET请求。

HTTP缓存

http缓存分为强制缓存和协商缓存两种。

1. 强制缓存

缓存生效流程

• 浏览器请求资源时，先检查 Expires（http1.0）或 Cache-Control （http1.1）。
• 如果缓存未过期，直接读取本地缓存（200 OK (from disk cache)），不向服务器发送请求。
• 如果缓存过期，进入 协商缓存 阶段。
  
  适用于静态资源（JS/CSS/图片）的长期缓存。

2. 协商缓存

缓存生效流程

• 浏览器发现强制缓存过期，携带 If-Modified-Since （1.0）或 If-None-Match（1.1） 向服务器发起请求。
• 服务器比对资源是否变化：
  未变化 → 返回 304 Not Modified，浏览器使用本地缓存。
  已变化 → 浏览器使用新资源，并更新本地缓存（包括新的 Last-Modified（1.0）或 ETag（1.1）和强缓存时间）。

适用于频繁更新的资源（如 HTML 文件）。

对比：

HTTP报文组成部分

HTTP报文：请求报文、响应报文
请求报文：请求行、请求头、空行、请求体
响应报文：状态行、响应头、空行、响应体

常见的HTTP请求方法

HTTP请求头有哪些

HTTP 请求头是客户端（如浏览器）向服务器发送请求时附加的元数据，用于传递请求的上下文信息、控制缓存、身份认证等。
一、基础请求头

二、缓存控制头

三、身份认证与安全头

四、内容协商与范围请求

五、CORS（跨域）相关头

六、其他常用头

完整请求示例

GET /api/data HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0) Accept: application/json Accept-Language: en-US Authorization: Bearer xyz123 Cache-Control: no-cache Connection: keep-alive

HTTP1.0/1.1/2.0 的区别

1. HTTP1.0
HTTP 1.0浏览器与服务器只保持短暂的连接，每次请求都需要与服务器建立一个TCP连接。服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

2. HTTP1.1
在HTTP1.1中，默认支持长连接（Connection: keep-alive），即在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。建立一次连接，多次请求均由这个连接完成。

同时，HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，存在 "队头阻塞”问题。

同时，HTTP1.1在HTTP1.0的基础上，增加更多的请求头和响应头来完善的功能，如下：

• 引入了更多的缓存控制策略，如If-Unmodified-Since,If-Match,If-None-Match等缓存头来控制缓存策略
• 引入range，允许只请求资源某个部分
• 引入host，实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点

3. HTTP2.0
多路复用

HTTP/2复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了”队头堵塞”

二进制分帧

在 HTTP/2 协议中，每个数据流以消息的形式发送，而每条消息又由一个或多个二进制编码帧组成。由于帧是独立的传输单位，多个帧之间可以乱序发送，接收方只需根据帧首部的流标识就能将它们重新组装成完整的消息。
这种基于帧的传输机制正是 HTTP/2 实现多路复用的关键条件，它允许同时交错发送多个请求和响应，显著提高了传输效率。

首部压缩

在 HTTP/1.x 中，因为HTTP/1.x 协议不带状态，每次请求都必须附上所有信息，请求的很多字段都是重复的。
HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送。
首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新

推送器服务

HTTP2引入服务器推送，当服务器收到一个主资源（如HTML）请求时，可以预测客户端接下来需要的相关资源（如CSS、JS、图片），并主动推送这些资源，而不是等待客户端解析HTML后再发起请求。

限制

尽管 HTTP/2 相比 HTTP/1.x 有显著改进，但它仍然存在一些重要的限制和挑战：

1. 队头阻塞
   HTTP/2 虽然解决了应用层的队头阻塞（多个流可以并行）
   但在TCP 层仍然存在队头阻塞：如果单个 TCP 包丢失，所有流都会被阻塞，等待重传

2. 服务器推送的实际限制
   推送资源可能不被需要：服务器预测不一定准确，可能推送了用户不需要的资源，造成带宽浪费。
   缓存问题：客户端可能已经缓存了推送的资源

cookie有哪些字段

1. Name/Value：键值对（必选）

//关于cookie的使用如下：document.cookie='名字=值';

2. Expires 用于设置 Cookie 的过期时间

Expires=Wed,21Oct201507:28:00GMT

3. Max-Age 用于设置在 Cookie 失效之前需要经过的秒数（优先级比Expires高）

Max-Age=604800

4. Domain指定了 Cookie 可以送达的主机名
5. Path指定了一个 URL路径，这个路径必须出现在要请求的资源的路径中才可以发送 Cookie 首部

Path=/docs #/docs/Web/下的资源会带 Cookie 首部

重要安全字段组合：Secure+HttpOnly+SameSite

6. 标记为 Secure的 Cookie只应通过被HTTPS协议加密过的请求发送给服务端
7. HttpOnly：禁止JS访问（防XSS）
   设置后（HttpOnly=true）可阻止 JavaScript 通过document.cookie访问该 Cookie，有效防御 XSS 攻击窃取敏感信息。常用于会话 ID 或身份验证令牌，必须配合 Secure（HTTPS）使用。例如：

Set-Cookie:sessionId=abc123;HttpOnly;Secure

8. SameSite：是 Cookie 的安全属性，控制跨站请求时是否发送 Cookie，有三种值：，SameSite=Lax是现代浏览器的默认值。

Strict：完全禁止跨站发送（如银行场景）
Lax（默认）：允许安全跨站（如导航跳转）
None：允许所有跨站（需配合 Secure）

通过上述，我们可以看到cookie又开始的作用并不是为了缓存而设计出来，只是借用了cookie的特性实现缓存

关于cookie的修改，首先要确定domain和path属性都是相同的才可以，其中有一个不同得时候都会创建出一个新的cookie

Set-Cookie:name=aa;domain=aa.net;path=/# 服务端设置 document.cookie=name=bb;domain=aa.net;path=/# 客户端设置

最后cookie的删除，最常用的方法就是给cookie设置一个过期的事件，这样cookie过期后会被浏览器删除

Cookie的作用

1. 会话状态管理：它会保持用户登录状态，在无状态的HTTP协议中维持连续性。比如你登录淘宝，关掉浏览器再打开，还是保持登录状态，就是因为 cookie 存了你的身份凭证。
2. 个性化服务：存储语言或者主题等设置
3. 跟踪行为：实现用户行为追踪，跟”猜你喜欢“这些功能挂钩

localStorage

HTML5新方法

• 生命周期：持久化的本地存储，除非主动删除数据，否则数据是永远不会过期的
• 存储的信息在同一域中是共享的
• 当本页操作（新增、修改、删除）了localStorage的时候，本页面不会触发storage事件,但是别的页面会触发storage事件。
• 大小：5M（跟浏览器厂商有关系）
• localStorage本质上是对字符串的读取，如果存储内容多的话会消耗内存空间，会导致页面变卡
• 受同源策略的限制

缺点：

• 无法像Cookie一样设置过期时间
• 只能存入字符串，无法直接存对象

cookie、sessionStorage、localStorage的区别（Js本地存储的方式）

• 存储大小：cookie数据大小不能超过4k，sessionStorage和localStorage虽然也有存储大小的限制，但比cookie大得多，可以达到5M或更大

• 有效时间：localStorage存储持久数据，浏览器关闭后数据不丢失除非主动删除数据； sessionStorage数据在当前浏览器窗口关闭后自动删除；cookie设置的cookie过期时间之前一直有效，即使窗口或浏览器关闭

• 数据与服务器之间的交互方式：cookie的数据会自动的传递到服务器，服务器端也可以写cookie到客户端； sessionStorage和localStorage不会自动把数据发给服务器，仅在本地保存

应用场景：

• 标记用户与跟踪用户行为的情况，推荐使用cookie
• 适合长期保存在本地的数据（令牌），推荐使用localStorage
• 敏感账号一次性登录，推荐使用sessionStorage
• 存储大量数据的情况、在线文档（富文本编辑器）保存编辑历史的情况，推荐使用indexedDB

JWT令牌

用户账号密码认证通过后会得到一个JWT令牌，JWT令牌中已经包括了用户相关的信息，客户端携带JWT访问服务器，服务器完成令牌校验后返回资源。

JWT令牌包括三部分：头部（Header）、载荷（Payload）、签名（Signature），并以.进行拼接。其中头部和载荷都是存放JSON数据，并且用Base64Url编码。

1. **头部（Header）**包括令牌的类型（即JWT）及使用的哈希算法（如HMAC SHA256或RSA）

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

2. 载荷（Payload）存放有效信息，例如面向的用户sub，用户名name，令牌的签发时间iat，过期时间exp等

{"sub":"1234567890","name":"John Doe","iat":1516239022}

3. 签名（Signatrue）将前两部分进行编码，使用header中声明的签名算法进行签名，用于防止jwt内容被篡改

Signature=HMACSHA256(base64Url(header)+.+base64Url(payload),secretKey)

具体实现参考：

如何实现jwt鉴权机制？

注意：对文中提到的分布式系统，学成在线的老师说用对称加密性能会高一些，而用非对称加密，安全性会更好，如果确保不同的微服务安全，可以使用对称加密。