Web基础知识

2025-09-09

网址、域名

1. 域名（Domain Name）

作用：域名是互联网中用来代替复杂 IP 地址（如 192.168.1.1 或 2001:db8::1）的一种字符串标识，更方便记忆。
组成部分（从右到左看）：
- 顶级域名 (TLD)：如 .com, .cn, .org
- 二级域名：如 example，常常是组织或个人注册的名字
- 子域名：如 www，mail 等
- 完整示例：www.example.com
  - com → 顶级域名
  - example → 二级域名
  - www → 子域名

一个域名可以对应到一个或多个 IP 地址，这个映射由 DNS（域名系统） 负责。

2. DNS（Domain Name System）

作用：把域名翻译成 IP 地址（类似于互联网的“电话簿”）。例如：
- 你访问 www.baidu.com → DNS 会查询它的真实 IP → 浏览器才能和服务器通信。
工作流程简化：
1. 用户输入网址
2. 浏览器先查本地缓存有没有对应 IP
3. 如果没有，就请求本地 DNS 服务器
4. 本地 DNS 服务器向根域名服务器、顶级域名服务器、权威域名服务器逐级查询
5. 最终得到目标服务器的 IP 地址

3. URL（Uniform Resource Locator，统一资源定位符）

URL = 完整的网址，包括协议、域名、路径等。
基本结构：
```
协议://域名:端口/路径?参数#锚点
```
示例：
```
https://www.example.com:443/path/to/page?query=abc#section2
```
- 协议：https（常见的还有 http, ftp 等）
- 域名：www.example.com
- 端口：:443（默认端口可以省略，http 默认 80，https 默认 443）
- 路径：/path/to/page（对应服务器上的资源位置）
- 参数：?query=abc（给服务器的额外信息）
- 锚点：#section2（页面内跳转定位）

4. 网站与服务器的关系

服务器 (Server)：一台运行网站的计算机，拥有公网 IP。
网站 (Website)：存放在服务器上的一组文件（HTML、CSS、JS、图片等）。
域名解析：把域名指向服务器的 IP。
虚拟主机 / 多站点：一台服务器可以托管多个网站，通过不同的域名区分。

5. 常见的相关概念

备案：在中国大陆，使用国内服务器部署网站，需要进行 ICP 备案。
SSL证书：用来实现 HTTPS（安全加密访问）。
CDN：内容分发网络，用来加速网站访问，把资源缓存到离用户最近的节点。

协议

协议在网络里非常重要，可以理解为 计算机之间沟通的“语言和规则”

1. 协议的基本概念

协议（Protocol） = 规则 + 约定
就像我们人类说中文或英语，网络上的设备必须用相同的协议，才能互相理解。
例如：
- 如果一台电脑说“HTTP”，另一台也要懂“HTTP”才能通信。
- 如果一个只会“FTP”的服务器，浏览器用“HTTP”去访问就会失败。

2. 常见的网络协议类型

（1）应用层协议（最贴近用户）

HTTP / HTTPS
- 浏览网页的协议
- https = 在 http 基础上加密（依赖 TLS/SSL）
FTP
- 文件传输协议，用来上传、下载文件
SMTP / POP3 / IMAP
- 邮件相关协议（SMTP 负责发，POP3/IMAP 负责收）
DNS
- 域名解析协议，负责把域名翻译成 IP

👉 这些协议都是人们日常能直接感受到的。

（2）传输层协议（管“怎么传”）

TCP（Transmission Control Protocol，传输控制协议）
- 特点：可靠（有确认机制、丢了会重传）、有序、面向连接（像打电话）
- 适合网页浏览、文件下载、邮件等需要完整数据的场景
UDP（User Datagram Protocol，用户数据报协议）
- 特点：不可靠（发出去就不管了）、快、无连接（像发短信）
- 适合实时要求高的场景，比如视频通话、在线游戏

（3）网络层协议

IP（Internet Protocol）
- 网络中最核心的协议
- 规定了“数据包如何在网络中传输”和“寻址方式”
- 主要版本：IPv4（常见的 192.168.x.x）、IPv6（更长的新一代地址）

（4）链路层协议

比如 以太网协议 (Ethernet)、Wi-Fi 协议
决定了数据在局域网里“怎么从一台设备传到另一台设备”

3. 协议与 URL 的关系

你在浏览器输入网址时，开头的部分其实就是告诉浏览器 用哪个协议通信：

http://example.com → 用 HTTP 协议
https://example.com → 用 HTTPS 协议（加密）
ftp://example.com → 用 FTP 协议（文件传输）

4. 一个小比喻

应用层协议 = 交流内容的语言（中文、英文、手语）
传输层协议 = 交流的方式（电话、短信）
网络层协议 = 邮递系统（根据地址送到目标城市）
链路层协议 = 快递小哥骑电动车送到门口

端口

好问题 👍，端口是网络通信里一个非常关键但又容易被忽视的概念。我给你分层讲解一下：

1. 端口是什么？

端口 (Port)：是计算机里网络通信的“门牌号”。
一台服务器只有一个公网 IP 地址（比如 203.0.113.5），但它可能同时运行很多服务（网站、邮件、数据库……），那客户端怎么区分访问哪个服务呢？ 👉 就靠 端口号 来标记。

2. 端口号的范围

0 ~ 65535（因为端口号用 16 位整数表示）
常见划分：
- 知名端口（0 ~ 1023）：保留给常见服务
  - 80 → HTTP
  - 443 → HTTPS
  - 21 → FTP
  - 22 → SSH
  - 25 → SMTP（邮件发送）
- 注册端口（1024 ~ 49151）：分配给一些特定应用软件
- 动态/私有端口（49152 ~ 65535）：客户端临时使用

3. 端口和协议的关系

协议（HTTP、FTP、SMTP 等）规定了“通信的规则”
端口是“找到服务的号码”
举个例子：
- 你访问 https://example.com
  - 浏览器自动连到 端口 443
  - 并且按照 HTTPS 协议 交流
- 如果是 http://example.com:8080
  - 就连到 8080 端口（非标准端口），走 HTTP 协议

4. 举个生活化的比喻

IP 地址 = 小区的地址（确定是哪栋楼）
端口号 = 房间号（确定是哪户人家）
协议 = 交流的方式（用中文说话 / 用英文写信）

👉 所以，访问一个网站时，你其实是：

去某个小区的某栋楼（IP 地址），按某个房间的门铃（端口），然后用规定的语言聊天（协议）。

5. 实际应用

在浏览器里输入 http://127.0.0.1:5000
- 127.0.0.1 = 本地地址
- 5000 = 端口号（很多 Python Flask/Django 服务默认端口）
服务器可以通过 端口转发 / 防火墙规则 控制哪些端口对外开放。

请求与响应、网页加载流程

好问题 👍！这部分就是「当你在浏览器输入网址后，背后到底发生了什么」。我们可以把它分为 请求（request） 和 网页加载流程 两部分来理解。

1. 什么是请求（Request）？

请求就是客户端（比如浏览器）向服务器发出的“要资源”的消息。
请求包含：
- 请求方法（常见的有）：
  - GET：获取数据（比如打开网页）
  - POST：提交数据（比如登录表单）
  - PUT：更新数据
  - DELETE：删除数据
- 请求头 (Headers)：一些附加信息
  - 浏览器类型 (User-Agent)
  - 能接受的数据类型 (Accept)
  - Cookie 等
- 请求体 (Body)：主要在 POST/PUT 时携带数据，比如登录时提交的用户名和密码。

👉 请求就像“寄出一封信”：写明收件人（服务器 IP + 端口）、说明你要做什么（GET/POST）、带上一些附加信息（headers）、可能还附带内容（body）。

2. 什么是响应（Response）？

服务器收到请求后，会返回响应：
- 状态码 (Status Code)
  - 200 OK：成功
  - 404 Not Found：找不到资源
  - 500 Internal Server Error：服务器错误
- 响应头 (Headers)：说明返回数据的类型、缓存规则等
- 响应体 (Body)：实际的数据，比如 HTML 网页、图片、JSON 数据

👉 响应就像“服务器回信”，告诉你结果，并把你要的资源寄回来。

3. 网页加载的完整流程（从输入网址到页面显示）

步骤一：输入 URL

你在浏览器输入 https://www.example.com/。

步骤二：DNS 解析

浏览器需要把 www.example.com 转换成 IP 地址。

先查本地缓存
如果没有，就问 DNS 服务器，直到找到正确的 IP

步骤三：建立连接

浏览器和服务器通过 TCP（三次握手） 建立连接
如果是 HTTPS，还会进行 TLS 握手 来建立加密通道

步骤四：发送 HTTP 请求

浏览器构造一个 HTTP GET 请求，发给服务器，比如：

GET / HTTP/1.1
Host: www.example.com
User-Agent: Chrome/...
Accept: text/html

步骤五：服务器处理并返回响应

服务器接收到请求后，找到对应的页面，返回响应：

HTTP/1.1 200 OK
Content-Type: text/html

<html> ... </html>

步骤六：浏览器解析 HTML

浏览器开始解析 HTML 文件
遇到 CSS，发起请求获取样式
遇到 JS，发起请求获取脚本
遇到 图片/视频，发起请求获取资源

👉 这就是为什么一个网页可能需要几十甚至上百个请求。

步骤七：渲染页面

浏览器的渲染引擎会：

解析 HTML → 生成 DOM 树
解析 CSS → 生成样式规则
把 DOM 树 + CSS 规则结合 → 渲染树
根据 JS 脚本动态修改内容
把最终结果绘制到屏幕上

4. 一个小比喻

你（浏览器）去餐厅（服务器）点菜：
- 你告诉服务员：“我要一份宫保鸡丁”（请求）。
- 服务员（服务器）记下来 → 去厨房（应用程序） → 把菜做好端上来（响应）。
- 你还可能再点汤、饮料、甜点（CSS、JS、图片），直到整顿饭齐全（网页完整加载）。

TCP握手

👌 好问题！你问的“三次握手、四次挥手”其实是 TCP 协议里最经典的内容，负责建立和断开连接。我们一点点拆开来看。

一、为什么需要握手？

TCP 是面向连接的协议（不像 UDP 那样“发出去就算”），它要保证数据可靠、顺序正确。
为了确保双方都做好了收发数据的准备，需要一个建立连接的过程，这就是 三次握手。

二、三次握手（建立连接）

👉 简化理解：客户端说“我要聊”，服务器说“我可以聊”，客户端再确认“那咱开始聊”。

第一次握手（客户端 → 服务器）
- 客户端发送一个 SYN（synchronize，同步） 报文，告诉服务器：
  - 我要建立连接
  - 这是我的初始序列号（seq=x）
- 状态：客户端进入 SYN_SENT
第二次握手（服务器 → 客户端）
- 服务器收到后，回复一个 SYN + ACK（确认） 报文：
  - 同意建立连接（SYN，带自己的序列号 seq=y）
  - 确认收到了客户端的请求（ACK=x+1）
- 状态：服务器进入 SYN_RCVD
第三次握手（客户端 → 服务器）
- 客户端收到服务器的确认后，再发一个 ACK：
  - 确认收到了服务器的序列号（ACK=y+1）
- 状态：双方都进入 ESTABLISHED，连接建立成功。

✅ 这时，客户端和服务器都确认了：

自己的发送能力 OK
对方的接收能力 OK
双方的初始序列号都收到了

三、为什么是三次，不是两次？

如果只两次握手：
- 客户端发 SYN → 服务器回 SYN+ACK → 直接算建立？
- 那万一客户端的请求因为网络延迟“过期”了，服务器却以为有新连接，就会白白浪费资源（半连接攻击的隐患）。
三次握手多了一次确认，保证客户端确实收到了服务器的应答，避免“僵尸连接”。

四、四次挥手（断开连接）

建立连接要三次握手，断开要四次挥手，为什么？ 👉 因为 TCP 连接是 全双工（双方都能独立收发数据），所以关闭时要各自单独关闭。

第一次挥手（客户端 → 服务器）
- 客户端发 FIN，表示“我这边数据发完了，不再发了”。
- 状态：客户端进入 FIN_WAIT_1。
第二次挥手（服务器 → 客户端）
- 服务器回 ACK，表示“收到你的关闭请求”。
- 但服务器可能还有数据要发，所以暂时不关。
- 状态：服务器进入 CLOSE_WAIT。
第三次挥手（服务器 → 客户端）
- 服务器发 FIN，表示“我这边也发完了，可以关了”。
- 状态：服务器进入 LAST_ACK。
第四次挥手（客户端 → 服务器）
- 客户端回 ACK，确认关闭。
- 客户端进入 TIME_WAIT 等待一会儿（防止最后的 ACK 丢失），然后彻底关闭。

五、小比喻

三次握手（建立连接）
- A：喂，能听到吗？（SYN）
- B：能听到，你能听到我吗？（SYN+ACK）
- A：能听到，那开始说吧！（ACK）
四次挥手（断开连接）
- A：我说完了（FIN）
- B：好，我知道了（ACK）
- B：我也说完了（FIN）
- A：好，那挂电话了（ACK）