操作系统

死锁

是什么？

死锁：两个或两个以上的进程、线程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们将无法推进下去

满足条件

  1. 互斥条件
    资源同一时间只能被一个线程占有（比如锁）。
  2. 请求与保持
    线程已经持有一个资源，又去请求别的资源，且不释放已有的。
  3. 不可剥夺
    资源只能由持有者主动释放，别人不能强行抢走。
  4. 循环等待
    线程 A 等 B，B 等 C，C 等 A，形成一个环形等待链。

解决方法
破坏 4 个条件中的任意一个即可

  • 破坏循环等待（最常用、最实用）
    所有线程统一按固定顺序获取锁
    比如：永远先锁 A 再锁 B，不反过来。
  • 破坏请求与保持
    要么一次性申请所有需要的锁，要么一个都不申请。
  • 破坏不可剥夺
    允许抢占资源，超时放弃锁。
  • 破坏互斥
    用无锁编程、CAS、乐观锁等（不太常用）

进程与线程

是什么？

进程 = 正在运行的程序实例，是资源分配的基本单位。

  • 一个运行中的程序，比如打开一个浏览器、一个微信
  • 拥有独立的资源：内存空间、文件句柄、网络连接等
  • 进程之间相互独立，不能直接访问对方内存
  • 一个进程至少有一个线程（主线程）
  • 创建 / 销毁开销大

线程 = 进程内部的执行路径，是 CPU 调度的基本单位。

  • 进程内部的执行单元
  • 同一个进程内的线程共享进程资源（内存、文件等）
  • 线程之间切换快、创建销毁开销小
  • 线程自己几乎不占资源，只占栈、程序计数器等少量执行上下文

虚拟内存

是什么？

  • 每个进程都有一套独立的虚拟地址空间（比如 4GB）
  • 程序访问的都是虚拟地址，不是真实物理内存地址
  • 操作系统通过页表把虚拟地址 → 翻译成物理地址

作用

  • 扩大内存空间
  • 进程隔离，更安全
  • 内存使用更高效
  • 方便程序加载运行

关键机制

  • 把虚拟内存和物理内存都切成固定大小的页（Page），通常 4KB
  • 每个进程有一张页表，记录：虚拟页号 → 物理页号 / 是否在内存 / 是否在硬盘
  • CPU 访问地址时，硬件（MMU）自动查页表翻译

缺页中断

  • 要访问的页不在物理内存，在硬盘上
  • CPU 触发缺页中断
  • 操作系统把页从 swap 读回物理内存
  • 更新页表，继续执行程序

虚拟内存是计算机中用于临时存储数据的一种技术，操作系统给每个进程提供的独立虚拟地址空间，通过页表映射到物理内存或硬盘交换区。
它可以扩大可用内存、实现进程地址隔离、提高内存利用率，并通过分页和缺页中断完成地址翻译和数据换入换出。

计算机网络

网络分层

OSI 七层模型

  1. 应用层：给应用用的协议（HTTP、FTP、DNS）
  2. 表示层：数据加密、压缩、格式转换
  3. 会话层：建立、管理、断开会话
  4. 传输层：端到端传输（TCP、UDP）
  5. 网络层：寻址路由（IP、ARP）
  6. 数据链路层：帧传输、MAC 地址（以太网）
  7. 物理层：光电信号、网线、接口
    应 表 会 传 网 链 物

TCP/IP 模型

  1. 应用层
    对应 OSI 上三层：HTTP、HTTPS、DNS、FTP
  2. 传输层
    TCP、UDP
  3. 网络层
    IP、ARP、ICMP
  4. 网络接口层（链路层）
    设备驱动、网卡、MAC、以太网

协议

定义

描述网络通信协议，定义网络通信的规则，两者交流的的规则

分类

TCP 协议
规定了：

  • 怎么建立连接（三次握手）
  • 怎么断开连接（四次挥手）
  • 数据怎么编号
  • 丢了怎么重传
  • 怎么保证不乱序
    可靠、有序、慢 → 网页、文件、接口
    特点：面向连接、可靠、基于字节流，全双工通信，有流量控制和拥塞控制，适用于对数据准确性要求高的场景。

UDP 协议
规定了：

  • 怎么打包数据
  • 怎么加上目标端口
  • 发出去就行，不保证到达
    不可靠、快、实时 → 直播、游戏、DNS
    特点：无连接、不可靠、面向数据报、开销小、速度极快，适用于对数据实时性要求高的场景。

HTTP 协议
规定了：

  • 客户端怎么发请求（GET / POST）
  • 服务端怎么回响应
  • 头怎么写、内容怎么放
  • 状态码代表什么
    应用层协议，底层用 TCP → 网页、接口

访问网站过程

  1. 先做 DNS 解析，域名转 IP
  2. 进行 TCP 三次握手 建立连接
  3. HTTPS 则进行 TLS 握手 加密
  4. 浏览器发送 HTTP 请求报文
  5. 服务器返回 HTTP 响应（HTML 等资源）
  6. 浏览器解析渲染，并加载图片、JS、CSS 等额外资源请求
  7. 最后 TCP 四次挥手 断开连接

域名解析过程

浏览器先查自身缓存，再查系统缓存和 hosts，没有就请求本地 DNS。
本地 DNS 依次问根 DNS、顶级域 DNS、权威 DNS，拿到 IP 后缓存并返回。

tcp三次握手

  1. 客户端向服务器发送SYN包，请求建立连接。c 发生带着syn标志和随机序列号seq的报文到s，C 进入状态：SYN_SENT，等待服务器返回ACK包。
  2. 服务器收到c的SYN包，回复ACK包和SYN包，序列号seq也随机生成，确认号是收到的序列号+1，s进入状态：SYN_RCVD，等待客户端返回ACK包。
  3. 客户端收到s的ACK包，回复ACK包和SYN包，序列号seq是第一次的+1，确认号是收到的序列号+1，进入状态：ESTABLISHED，完成三次握手，开始通信。

丢失其中的一次会怎么样？

  • 第一次握手 SYN 丢失：
    S 完全收不到任何包，无感知
    C 在 SYN_SENT 等待 ACK
    超时后，内核自动重传 SYN（指数退避重发）
    重传多次仍失败 → 连接超时，建立失败

  • 第2次握手 ACK 丢失：
    C：还在 SYN_SENT，收不到 ACK → 超时重传 SYN
    S：已经进入 SYN_RCVD，但收不到第三次握手
    S 会超时重传 SYN+ACK
    结果：
    重传多次失败 → 两端都认为连接失败
    服务端 SYN_RCVD 队列会占用一个位置，极端情况可能导致 SYN 洪水

  • 第3次握手 ACK 丢失：
    C 已经认为连接建立成功，进入 ESTABLISHED
    S 还在 SYN_RCVD，没收到 ACK，认为连接没建好

S 超时后重传 SYN+ACK
C 收到重复的 SYN+ACK，会重新发送 ACK
若 S 最终收到 ACK → 连接正常建立
若一直收不到 → S 放弃连接，C 还以为连着，c发包会触发 RST重置连接。

http详解

基础概念

HTTP（超文本传输协议，Hypertext Transfer Protocol）是一种用于从网络传输超文本到本地浏览器的传输协议。它定义了客户端与服务器之间请求和响应的格式。HTTP 工作在 TCP/IP 模型之上，通常使用端口 80，基于 TCP/IP 通信协议来传递数据。

HTTP 本身是不安全的，因为传输的数据未经加密，可能会被窃听或篡改，为了解决这个问题，引入了 HTTPS，即在 HTTP 上加入 SSL/TLS 协议，为数据传输提供了加密和身份验证。

HTTPS（超文本传输安全协议，Hypertext Transfer Protocol Secure）是 HTTP 的安全版本，它在 HTTP 下增加了 SSL/TLS 协议，提供了数据加密、完整性校验和身份验证。HTTPS 通常使用端口 443。

工作原理

HTTP 协议工作于客户端-服务端架构上。

工作过程：
  1. 客户端发起请求：用户通过客户端（如浏览器）输入 URL，客户端向服务器发起一个 HTTP 请求。
  2. 服务器处理请求：服务器接收到请求后，根据请求的类型（如GET、POST等）和请求的资源，进行相应的处理。
  3. 服务器返回响应：服务器将处理结果包装成HTTP响应消息，发送回客户端。
  4. 客户端渲染页面：客户端接收到响应后，根据响应内容（如HTML、图片等）渲染页面，展示给用户。
特性：
  • 无连接：HTTP 协议是一种无连接的协议。HTTP/1.0 中一次请求完成后立刻断开 TCP 连接；HTTP/1.1 通过 Keep‑Alive 实现长连接复用，一条 TCP 连接可传输多次请求，但HTTP 本身依然是无连接的应用层协议，连接状态不由 HTTP 协议维护。
  • 无状态（状态无保持）：HTTP 协议是一种无状态的协议，服务器不会记忆客户端上一次请求产生的任何状态信息，每一条请求都是相互独立、互不感知的。如需保存登录、浏览记录等会话状态，需要借助 Cookie、Session、Token (JWT) 等额外技术实现。
  • 支持缓存：HTTP 协议内置完整的缓存机制。客户端可对静态资源进行缓存；通过 Cache‑Control、Expires（强缓存）、Last‑Modified、ETag（协商缓存）控制缓存策略，减少重复请求、降低服务器压力、节省带宽并提升访问速度。
  • 请求‑响应模式，服务器无法主动推送：通信采用一问一答模式，只能由客户端主动发起请求，服务器被动返回响应。原生 HTTP 无法由服务器主动向客户端推送消息；实时双向通信场景可采用 WebSocket、SSE 等技术方案扩展实现。
  • 明文传输：默认 HTTP 为明文传输，请求与响应数据直接裸奔，存在被窃听、篡改、身份冒充的风险；安全传输可使用 HTTPS（HTTP+TLS/SSL）进行加密。
  • 灵活可扩展：通过请求头、响应头可自由扩展功能；依靠 Content‑Type 可以传输 HTML、JSON、图片、视频、文件等任意类型的数据资源。

HTTP 与 HTTPS的区别

  • 加密：
    • HTTP：明文传输，数据未经加密，可能会被窃听或篡改。
    • HTTPS：在 HTTP 上增加了 SSL/TLS 协议，提供了数据加密、完整性校验和身份验证。
  • 端口：
    • HTTP：默认端口为 80。
    • HTTPS：默认端口为 443。
  • 安全性：
    • HTTP：不安全，数据未经加密，可能会被窃听或篡改。
    • HTTPS：安全，数据通过 SSL/TLS 加密传输，提供了数据加密、完整性校验和身份验证。
  • 证书：
    • HTTP：由于不加密数据，性能略高于HTTPS。
    • HTTPS：由于需要进行加密和解密，可能会有一定的性能开销。
  • 性能：
    • HTTP：由于不加密数据，性能略高于HTTPS。
    • HTTPS：由于需要进行加密和解密，可能会有一定的性能开销。
  • 搜索引擎：
    • HTTP：搜索引擎可能会对没有使用HTTPS的网站进行降权。
    • HTTPS：搜索引擎会优先考虑 HTTPS 协议，因为 HTTPS 协议更安全、更符合搜索引擎的安全要求。
  • 成本：
    • HTTP：通常免费。
    • HTTPS：需要购买SSL证书，可能会有一定的成本。
  • 应用场景：
    • HTTP：适用于静态资源传输，如图片、视频等。
    • HTTPS：适用于需要加密传输的场景，如登录、支付等。

请求方法

  1. http/1.0

    1996 年发布，短连接为默认模式，每一次 HTTP 请求都会新建一条 TCP 连接，请求完成立即断开。
    支持的请求方法：

  • get 获取资源
  • post 提交数据
  • head 请求资源的响应头信息。
    缺点：
  • 每次请求都需要新建一条 TCP 连接，导致传输效率低。
  • 服务器无法主动推送消息，只能由客户端主动发起请求。
  • 缺少缓存机制，导致重复请求。
  1. http/1.1

    1999 年发布，在 1.0 基础上扩展方法；默认开启长连接 keep‑alive；强制要求Host请求头；支持管道化请求。
    支持的请求方法：

  • GET - 请求指定的资源。
  • POST - 提交数据以处理请求。
  • HEAD - 请求资源的响应头信息。
  • PUT - 上传文件或者更新资源。
  • DELETE - 删除指定的资源。
  • OPTIONS - 请求获取服务器支持的请求方法。
  • TRACE - 回显服务器收到的请求，主要用于诊断。
  • CONNECT - 建立一个隧道用于代理服务器的通信，通常用于 HTTPS。
  1. http/2.0
    请求方法语义完全继承 HTTP/1.1，没有新增请求方法；底层传输依然基于 TCP
    但对协议进行了优化，提高了传输效率和速度。HTTP/2 也引入了新的特性，如多路复用、头部压缩和服务器推送等。
  2. http/3.0
    HTTP/3 基于 QUIC 协议实现，继续使用 HTTP/2 的方法。HTTP/3 主要改进了传输层，使用 UDP 代替 TCP 以提高传输速度和可靠性。

消息结构

客户端请求消息

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。

  1. 请求行（Request Line）

    告诉服务器本次请求要做什么、访问哪个资源、使用哪个 HTTP 协议版本
    格式：请求方法 请求URL HTTP版本

  • 请求方法：GET、POST、PUT、DELETE 等。
  • 请求URL ：如 /index.html、api/data 等。
  • HTTP版本号：HTTP/1.0 或 HTTP/1.1。

    请求行的格式示例：GET /index.html HTTP/1.1

  1. 请求头（Request Headers）

    携带客户端附加信息，给服务器传递请求的附加条件
    常见字段

  • Host：目标服务器域名 / IP（HTTP1.1 必须带此字段）
  • User‑Agent：客户端浏览器、操作系统标识
  • Accept：客户端可接收的数据类型
  • Accept‑Encoding：客户端支持的压缩格式 (gzip/deflate)
  • Content‑Type：请求体的数据类型（POST 提交 JSON、表单时使用）
  1. 空行：隔开请求行和请求头部。

必不可少！ 代表请求头部结束，后面如果有内容就是请求体。

  1. 请求数据：根据请求方法，可能是表单数据、JSON 数据等。
  • GET 请求：不包含请求体，所有数据都在 URL 中。
  • POST 请求：包含请求体，用于提交表单数据、JSON 数据等。
实例

客户端（get）请求示例：
GET /index.html HTTP/1.1 # 请求行
Host: www.example.com # 请求头
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
Accept-Encoding: gzip, deflate
Connection: keep-alive

客户端（post）请求示例：
POST /api/user/login HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: application/json,text/html,/;q=0.8
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/json; charset=UTF-8
Content-Length: 52
#空行
{“username”:”zhangsan”,”password”:”123456”} #请求体数据

服务器响应消息

HTTP 响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

  1. 状态行（Status Line）：包含HTTP版本号、状态码、状态描述。
  • http版本号：HTTP/1.0 或 HTTP/1.1。
  • 状态码：200、404、500 等。
  • 状态描述：OK、Not Found、Internal Server Error 等。

    状态行的格式示例：HTTP/1.1 200 OK

  1. 响应头（Response Headers）：作用：服务器返回的附加说明信息，描述响应体、服务器信息等。
  • Content‑Type：响应体的数据类型与编码，如 text/html; charset=UTF‑8、application/json
  • Content‑Length：响应体字节大小
  • Date：服务器生成响应的时间
  • Server：服务器软件信息
  • Connection：连接方式 keep‑alive（长连接） / close（短连接）

  1. 空行：隔开状态行和消息报头。

  2. 响应正文（Response Body）：包含实际的响应数据，如HTML、图片、视频等。
    服务器返回给客户端的真实数据；可以是 HTML、JSON、图片、文件、视频等资源。

实例

服务器响应示例：
HTTP/1.1 200 OK
Date: Wed, 18 Apr 2024 12:00:00 GMT
Server: Apache/2.4.1 (Unix)
Last-Modified: Wed, 18 Apr 2024 11:00:00 GMT
Content-Length: 12345
Content-Type: text/html; charset=UTF-8

1
2
3
4
5
6
7
8
9
10
<!DOCTYPE html>
<html>
<head>
    <title>Example Page</title>
</head>
<body>
    <h1>Hello, World!</h1>
    <!-- The rest of the HTML content -->
</body>
</html>