🔄Update: 计算机网络
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
# 分层模型
|
||||
|
||||
## `OSI` 七层模型
|
||||
|
||||
- 应用层
|
||||
- 为计算机用户提供服务
|
||||
- 表示层
|
||||
- 数据处理（编解码、加密解密、压缩解压缩）
|
||||
- 会话层
|
||||
- 管理应用程序之间的会话
|
||||
- 传输层
|
||||
- 为两台主机进程之间的通信提供通用的数据传输服务
|
||||
- 网络层
|
||||
- 路由和寻址
|
||||
- 数据链路层
|
||||
- 帧编码和误差纠正控制
|
||||
- 物理层
|
||||
- 传送比特流数据
|
||||
|
||||
|
||||
|
||||
## `TCP/IP` 协议
|
||||
|
||||
- 应用层
|
||||
- 传输层
|
||||
- 网络层
|
||||
- 网络接口层
|
||||
@@ -0,0 +1,20 @@
|
||||
# 应用层协议
|
||||
|
||||
- HTTP 超文本传输协议
|
||||
- 基于 TCP
|
||||
- 无状态
|
||||
- WebSocket 全双工通信协议
|
||||
- 基于 TCP
|
||||
- 允许双方同时收发数据
|
||||
- SMTP 简单邮件传输协议
|
||||
- 基于 TCP
|
||||
- POP3/IMAP 邮件接收协议
|
||||
- IMAP 比 POP3 强大
|
||||
- FTP 文件传输协议
|
||||
- 基于 TCP
|
||||
- 将命令与数据分开传输
|
||||
- 注意不会对数据加密，可以使用 SFTP(基于 SSH)
|
||||
- Telnet 远程登陆协议
|
||||
- 用户名密码明文发送
|
||||
- SSH 安全的网络传输协议
|
||||
- DNS 域名系统
|
||||
@@ -0,0 +1,44 @@
|
||||
# 三次握手
|
||||
|
||||
**过程**
|
||||
|
||||
- 第一次握手
|
||||
- 客户端发送 `SYN`
|
||||
- 第二次握手
|
||||
- 服务端响应 `ACK`
|
||||
- 服务端发送 `SYN`
|
||||
- 第三次握手
|
||||
- 客户端响应 `ACK`
|
||||
|
||||
**作用**
|
||||
|
||||
- 第一次握手
|
||||
- 第二次握手
|
||||
- `Client`
|
||||
- 自己：发送、接收
|
||||
- 对方：发送、接收
|
||||
- `Server`
|
||||
- 自己：接收
|
||||
- 对方：发送
|
||||
- 第三次握手
|
||||
- 确认双方收发的功能正常
|
||||
|
||||
**术语**
|
||||
|
||||
- `SYN`
|
||||
- 同步序列编号
|
||||
|
||||
**约定**
|
||||
|
||||
- 第三次握手是可以携带数据的
|
||||
|
||||
**断开握手**
|
||||
|
||||
- 第一次挥手
|
||||
- 客户端发送 `FIN`
|
||||
- 第二次挥手
|
||||
- 服务端响应 `ACK`
|
||||
- 第三次挥手
|
||||
- 服务端发送 `FIN`
|
||||
- 第四次挥手
|
||||
- 服务端发送 `ACK`
|
||||
@@ -0,0 +1,34 @@
|
||||
# HTTPS
|
||||
|
||||
- HTTPS = HTTP + SSL/TLS
|
||||
- SSL
|
||||
- 安全套接字协议
|
||||
- TLS
|
||||
- SSL 升级版
|
||||
|
||||
|
||||
**加密**
|
||||
|
||||
- 非对称加密
|
||||
- 客户端 -> 移动端
|
||||
- 客户端
|
||||
- 公钥加密
|
||||
- 服务端
|
||||
- 私钥解密
|
||||
- 优点
|
||||
- 密钥生成以及加解密需要耗费较多的系统资源
|
||||
- 对称加密
|
||||
- HTTPS 消息加密方法
|
||||
- 核心
|
||||
- 双方共享唯一密钥 `k`
|
||||
- 通过 `k` 进行加密解密
|
||||
|
||||
*实际操作*
|
||||
|
||||
- 先通过一次非对称加密协商对称加密密钥
|
||||
- 双方使用对称密钥进行后续通信
|
||||
|
||||
**问题**
|
||||
|
||||
- 非对称加密可能会有 *中间人攻击* （伪造私钥） -> 引入 CA 认证，客户端从 CA 证书中获取公钥
|
||||
- CA 可能会被冒充 ? -> 根证书预置在操作系统中，无法伪造
|
||||
@@ -0,0 +1,9 @@
|
||||
# 访问网页的过程
|
||||
|
||||
1. 输入 `URL`
|
||||
`协议`://`域名`:`端口`/`资源路径`?`参数`#`锚点`
|
||||
2. 获取 `IP`
|
||||
`DNS` 解析
|
||||
3. TCP 连接
|
||||
4. HTTP/HTTPS 请求
|
||||
5. 返回数据
|
||||
@@ -0,0 +1,15 @@
|
||||
# 轮询 vs 长轮询
|
||||
|
||||
- 轮询
|
||||
- `Polling`
|
||||
- 客户端定期向服务器发送请求，查询是否有新数据
|
||||
- 弊端
|
||||
- 增加冗余网络请求
|
||||
- 长轮询
|
||||
- `Long Pollong`
|
||||
- 客户端请求后，服务端保持连接
|
||||
- 有新数据后返回响应
|
||||
- 客户端继续发起新请求
|
||||
- 好处
|
||||
- 高效
|
||||
- 接近实时通讯
|
||||
@@ -0,0 +1,18 @@
|
||||
# 用户状态
|
||||
|
||||
> HTTP 与 HTTPS 是无状态的，那么客户端与服务端之间如何维护状态信息？
|
||||
|
||||
**`Session`**
|
||||
|
||||
1. 用户发送账号密码登录
|
||||
2. 服务端生成 `Session` 对象
|
||||
3. `Session ID` 回传给客户端 并 `Set-Cookie`
|
||||
4. 浏览器将 `Session ID` 存放在 `Cookie` 中
|
||||
5. 后续请求使用该 `Cookie`
|
||||
|
||||
*前提：浏览器开启 Cookie(备选：URL重写)*
|
||||
|
||||
**`Token`**
|
||||
|
||||
- 无状态的认证方式——服务端无需存储状态
|
||||
|
||||
Reference in New Issue
Block a user