计算机网络八股第二期

计算机网络八股第二期

1.讲一讲从输入网址到网页显示之间发生了什么（从网络的角度）

想想一下你从网店买一本书，从输入网址到网页显示其实和你从网店买一本书差不多，网店发给你的是实体而网络传输的是文字，图片等等资源的数据。

1. 查看仓库地址，DNS解析
   你输入的网址是为了方便人们记忆而特意规定的一种网址，网络设备不会直接识别，他们只认识像192.16.10.0.0这样的IP地址。此时就需要我们的好朋友DNS服务器登场了，DNS服务器的作用就是将我们平常看到的类似于www.baidu.com这样的网址经过查询返回真正的IP地址供用户使用。

2. 打电话联系仓库，TCP连接
   你的设备知道了服务的地址后就要和服务器建立一个可靠的连接像打电话一样，此时就是我们众所周知的TCP三次握手
   第一次：我们打电话过去，喂，你好服务器，我想和你聊聊（发送SYN包过去，表示请求连接）
   第二次：服务器接收到请求同义连接，并询问你是否准备好了（发送SYN和ACK包，表示同意连接并确认客户端请求）
   第三次：你说收到，我准备好了，开始聊吧（发送ACK包）
   在三次握手之后一个安全的连接通道就建立好了，如果在此期间我们访问的是https://开头的网址，就相当于给问我们的通话加上了保险（TLS,SSL握手），对传输内容加密防止偷看。

3. 下订单”：发送 HTTP(S) 请求

   • 连接建立好了（电话通了），你的设备（通常是浏览器）就要向服务器（仓库）正式提出请求了。

   • 它使用 HTTP(S) 协议（就是网购时填的订单单子）说：“你好，我是浏览器，我想要 / 这个页面（通常是首页）的内容，请发给我！” 这个请求里还会包含一些额外信息，比如你的浏览器类型、能接受的语言等。

4. “仓库处理订单”：服务器处理请求

   • 服务器（仓库管理员）收到你的“订单”（HTTP 请求）。

   • 它理解了你想要什么（/ 这个页面）。

   • 它开始“打包”你需要的东西：

     • 可能需要从数据库里查找信息（比如最新的商品列表）。

     • 可能需要运行一些程序（后端代码）生成动态内容。

     • 把最终的网页内容（主要是 HTML 文件，网页的骨架和文字）准备好。

5. “快递发货”：服务器发送 HTTP(S) 响应

   • 服务器把“打包”好的 HTML 文件（主包裹）放进“快递车”（网络连接）。

   • 它发送一个 HTTP(S) 响应 回来。这个响应包含：

     • 状态码：比如 200 OK（发货成功），404 Not Found（你要的东西仓库没有）。

     • 响应头：包裹信息，比如包裹类型（是网页）、大小、日期等。

     • 响应体：最重要的部分——HTML 文件的内容（你的书）。

6. “拆包裹 & 发现还要买零件”：浏览器解析 HTML

   • 你的浏览器收到“主包裹”（HTML 文件）。

   • 它开始“拆包裹”（解析 HTML 代码）。

   • 解析过程中，它发现：“咦，这个网页还需要一些图片 (<img> 标签) 和样式表 (<link rel="stylesheet">) 才能完整显示啊！可能还需要 JavaScript 文件 (<script>) 来让页面动起来！”

   • 这些额外的资源（图片、CSS、JS）可能存储在同一台服务器上，也可能在完全不同的服务器（CDN）上。

7. “再下订单买零件”：获取额外资源

   • 对于 HTML 里发现的每一个额外资源（图片、CSS、JS 等），浏览器会重复步骤 1-6：

     • 如果资源在另一个域名下，需要再次进行 DNS 解析（查那个新域名的地址）。

     • 可能需要建立新的 TCP 连接（给新仓库打电话）。

     • 发送新的 HTTP(S) 请求（下新的订单要图片、CSS 等）。

     • 接收服务器发回的 HTTP(S) 响应（收到图片、CSS 等包裹）。

8. “组装成品”：浏览器渲染页面

   • 当所有“零件”（HTML、CSS、JavaScript、图片、字体等）都到齐后：

     • 浏览器根据 HTML 构建页面的基本结构（骨架）。

     • 根据 CSS 给页面“穿衣服”（布局、颜色、字体等样式）。

     • 执行 JavaScript 让页面“活起来”（交互、动态效果）。

   • 最终，一个完整的、你可以看到和操作的网页就显示在你的屏幕上了！

总结一下这个“网购”之旅（网络之旅）：

1. 查地址 (DNS解析) -> 找到网站服务器的IP。

2. 打电话联系 (TCP握手) -> 建立可靠连接（安全网站还要加保险箱）。

3. 下订单 (HTTP请求) -> 告诉服务器你要什么页面。

4. 仓库处理 (服务器处理) -> 服务器准备好页面内容（HTML）。

5. 发货 (HTTP响应) -> 服务器把HTML发回给你。

6. 拆主包裹 (解析HTML) -> 浏览器发现还需要图片/CSS/JS等零件。

7. 再下单买零件 (重复1-5) -> 获取所有额外资源。

8. 组装成品 (渲染) -> 浏览器把所有零件组合成你看到的漂亮网页

2.能说一下SpringMVC的执行流程吗？

1. 快递送达总站： 前端请求到达 DispatcherServlet (总调度员)。

2. 查送货地址： DispatcherServlet 问 HandlerMapping (地址簿)：“这快递（请求URL）送哪个车间（Controller）？”

3. 找合适快递员： DispatcherServlet 找到能对接那个车间（Controller）的 HandlerAdapter (万能适配器)。

4. 车间加工： HandlerAdapter 把请求（快递）交给 Controller (车间) 处理。

   • 车间拆包（取参数）、干活（执行业务逻辑）、写回执单（准备 Model 数据和 View 信息或直接返回数据）。

5. 决定包装方式：

   • 如果回执单说要包装（返回视图名）：

     • 找包装车间： DispatcherServlet 问 ViewResolver (包装调度员)：“xxx.html 这个包装盒在哪？”

     • 包装成品： 找到的 View (包装车间/模板引擎) 把数据（Model）塞进模板，生成 HTML 包裹。

   • 如果回执单说直接发数据（返回数据 + @ResponseBody）：跳过找包装车间和包装步骤，直接把数据（通常是转成JSON）当作包裹。

6. 发回快递： DispatcherServlet (总调度员) 把最终包裹（HTML页面 或 JSON数据）通过 HTTP 响应“快递”回前端浏览器。

3.HTTP各版本的变化

1. HTTP/0.9 (1991年) - “原始版”

• 核心特点：

  • 只有 GET 一种请求方法。

  • 响应只能是纯文本（HTML），没有响应头（Header）、状态码、错误处理。

• 比喻：
  就像你打电话给朋友只说一句：“把书给我”，对方直接扔过来一本书，没有包装盒、快递单、退货选项。

2. HTTP/1.0 (1996年) - “基础版”

• 核心改进：

  • 引入 Header（头部信息）：
    请求和响应都支持头部字段（如 Content-Type、User-Agent），可以传递元数据（比如文件类型、编码方式）。

  • 支持多种请求方法：
    新增 POST、HEAD 等方法（比如提交表单）。

  • 状态码和错误处理：
    响应中明确返回状态码（如 200 OK、404 Not Found）。

  • 支持非文本内容：
    可传输图片、文件等二进制数据（通过 Content-Type 标识）。

• 痛点：

  • 每个请求必须新建一个 TCP 连接，用完就关（短连接）。加载一个网页（含多个图片/CSS）时，反复建立/断开连接效率极低！

• 比喻：
  快递每次只送一件商品，送完就拆掉运输通道。买10件商品要建10次通道，效率低下。

3. HTTP/1.1 (1997年) - “实用版”

至今仍是主流版本

• 核心改进：

  • 持久连接（Keep-Alive）：
    一个 TCP 连接可发送多个请求（默认开启），减少反复建连的开销。

  • 管道化（Pipelining）：
    允许一次性发送多个请求（无需等上一个响应返回），但响应必须按顺序返回（队头阻塞问题）。

  • 更多方法：
    新增 PUT、DELETE、OPTIONS 等方法（为 RESTful API 铺路）。

  • Host 头支持：
    允许一台服务器托管多个网站（虚拟主机）。

  • 缓存控制：
    通过 Cache-Control、ETag 等头部实现更精细的缓存策略。

• 遗留问题：

  • 队头阻塞（Head-of-Line Blocking）：
    如果第一个请求响应慢，会阻塞后续所有请求（即使它们已准备好）。

  • 头部冗余：
    每次请求都重复发送大量相同的头部（如 Cookie、User-Agent），浪费带宽。

• 比喻：
  建一条高速路（TCP连接）可连续发多辆货车（请求），但货车必须按顺序排队过关卡（服务器响应），前车卡住，后车全堵。

4. HTTP/2 (2015年) - “性能飞跃版”

基于 Google 的 SPDY 协议

• 核心改进：

  • 二进制协议：
    不再用文本格式（如 GET /index.html），改用二进制帧（Frame）传输，解析更快、更紧凑。

  • 多路复用（Multiplexing）：
    彻底解决队头阻塞！多个请求/响应可在同一个连接上并行交错传输，互不阻塞。

  • 头部压缩（HPACK）：
    用字典编码压缩头部（尤其是重复字段），体积减少 50%~90%。

  • 服务器推送（Server Push）：
    服务器可主动推送资源（如 CSS/JS）给客户端，无需等浏览器解析 HTML 后再请求。

  • 流优先级（Stream Priority）：
    客户端可指定资源加载优先级（如优先加载 HTML 而非图片）。

• 未解决问题：

  • TCP 层的队头阻塞：
    若 TCP 包丢失，需等待重传，仍会阻塞该连接上的所有流（HTTP/3 解决）。

• 比喻：
  高速路升级为立体交通（二进制帧），所有货车（请求/响应）可同时跑在不同车道（流），且货车自带压缩包装（头部压缩）。

5. HTTP/3 (2022年正式标准化) - “未来版”

基于 QUIC 协议（UDP + TLS）

• 核心改进：

  • 弃用 TCP，改用 UDP 之上的 QUIC 协议：
    UDP 无连接特性避免 TCP 握手延迟（尤其弱网环境）。

  • 解决 TCP 队头阻塞：
    每个请求流独立传输，丢包只影响当前流，其他流不受阻！

  • 零 RTT 建连：
    首次连接 1-RTT，后续连接可 0-RTT（极速恢复会话）。

  • 内置加密（TLS 1.3）：
    安全性成为默认要求，无明文传输。

• 挑战：

  • 需要操作系统和网络设备支持 QUIC（逐步普及中）。

• 比喻：
  把高速路（TCP）换成无人机物流网（UDP+QUIC），每个包裹（流）独立飞行，丢包不影响其他包裹，且自带武装押运（加密）。

总结对比表