网络通信协议

Tcp 协议

TCP 是传输层的可靠字节流通信协议，为 HTTP/HTTPS/WebSocket 等应用层协议提供底层传输支撑，核心解决「数据如何有序、无丢失、无重复地在两台设备间传输」的问题。

其连接的持续时间完全由上层应用（开发者）决定

• 核心特点

1. 面向连接：通信前需通过「三次握手」建立连接，通信结束后通过「四次挥手」关闭连接；
2. 可靠传输：通过序列号、确认应答（ACK）、重传机制保证数据不丢失、不重复、有序到达；
3. 字节流传输：无固定应用层格式，仅传输连续字节流，需上层协议自定义数据边界；
4. 拥塞控制：采用慢启动、拥塞避免、快重传、快恢复来防止网络拥塞

• 数据传输格式

TCP 本身无固定报文格式，需开发者自定义「消息头 + 消息体」区分数据边界（解决字节流粘包 / 拆包问题）：

// 自定义TCP报文结构（通用设计）
1. 消息头（固定长度）：4字节（消息总长度） + 2字节（消息类型） + 1字节（版本号）
2. 消息体（可变长度）：实际传输的业务数据（长度由消息头指定）

• 使用场景

1. 需自定义协议的高性能场景（如游戏服务器、物联网设备）
2. 作为 HTTP/HTTPS/WebSocket 的底层传输基础；

Http 协议

Http 是客户端和服务器之间通信的协议。一个完整的 Http 请求包含：

1. 请求行：方法 + URL + 协议版本
2. 请求头：元数据
3. 请求体：实际传输的数据（GET 请求通常没有）    

应用层协议，Http 1.0 默认是短连接，1.1 就变成了默认的长连接（核心改进）

Http 请求如下所示，一般来说可以用 url 来构造 http 请求（Content-Type/Content-Length 这种没在 url 里面的就手动设置）：

<!-- 请求行 -->
POST /api/orders HTTP/1.1	
<!-- 请求头 --> 
Host: api.shop.com
Content-Type: application/json
Authorization: Bearer token123
User-Agent: MyApp/1.0
Content-Length: 87

<!-- 请求体 Json 格式 --> 
{
    "productId": "12345",
    "quantity": 2,
    "customer": {
        "name": "张三",
        "address": "北京市"
    }
}

Http 响应：

<!-- 响应行 -->
HTTP/1.1 201 Created
<!-- 响应头 -->
Content-Type: application/json
Date: Mon, 23 Oct 2023 10:00:00 GMT

<!-- 响应头 -->
{
    "id": "order_67890",
    "status": "created",
    "createdAt": "2023-10-23T10:00:00Z"
}

• 请求类型

1. Get- 获取数据

GET /api/users/123 HTTP/1.1
Host: example.com

用于获取服务器的资源

2. Post - 创建数据

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{"name": "张三", "email": "zhang@example.com"}

用于在服务器当中创建新资源

3. PUT：更新完整资源
4. Delete: 删除资源

Https 协议

HTTPS 是「HTTP + TLS/SSL 加密」的组合协议，本质是加密版的 HTTP，基于 TCP 传输，核心解决 HTTP 明文传输的安全问题（防窃听、防篡改、防冒充）。

应用层协议，Http 1.0 默认是短连接，1.1 就变成了默认的长连接（核心改进）

• 核心特性

1. 加密传输：通过 TLS/SSL 对 HTTP 数据加密，传输过程中无法被破解；
2. 身份验证：通过数字证书验证服务器合法性，防止访问钓鱼网站；
3. 兼容 HTTP：请求 / 响应格式与 HTTP 一致，仅增加 TLS 加密层；
4. 基于 TCP：先完成 TCP 三次握手，再完成 TLS 握手，最后传输加密数据；
5. 默认端口：443（HTTP 默认 80）。

• TLS 握手核心流程

1. 客户端发送：TLS 版本、加密套件列表、随机数；

2. 服务器返回：数字证书、选定的加密套件、随机数；

3. 客户端验证证书，生成「预主密钥」并加密发送给服务器；

4. 双方基于随机数 + 预主密钥生成「会话密钥」；

5. 确认加密通道建立，后续 HTTP 数据均用会话密钥加密。

• Https 请求/响应示例

HTTPS 报文结构与 HTTP 一致，仅传输过程为密文，以下是「明文视角」的示例：

请求：

<!-- 请求行 -->
POST /api/pay HTTP/1.1
<!-- 请求头（明文传输，用于TLS握手和基础标识） -->
Host: pay.example.com
Content-Type: application/json
Content-Length: 78
User-Agent: MyApp/1.0
<!-- 请求体（传输时为密文，明文如下） -->
{
    "orderId": "order_67890",
    "amount": 99.00,
    "payType": "wechat"
}

响应：

HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 23 Oct 2023 10:05:00 GMT
Content-Length: 65
<!-- 响应体（传输时为密文，明文如下） -->
{
    "payId": "pay_123456",
    "status": "success",
    "payTime": "2023-10-23T10:05:00Z"
}

数据加密避免请求 / 响应被中间人窃听

WebSocket

WebSocket 是应用层的双向实时通信协议，基于 TCP 构建，通过 HTTP 握手升级为持久化长连接，核心解决 HTTP「客户端主动请求、服务端被动响应」的单向通信限制。

应用层协议，默认且唯一的使用方式是长连接

• 核心特性

1. 双向通信：连接建立后，客户端 / 服务器可主动、实时发送数据（全双工）；
2. 持久化长连接：一次握手后连接保持，直到主动关闭（无需重复建立 TCP 连接）；
3. 轻量级：数据帧格式简洁，无 HTTP 冗余头信息，传输开销远低于 HTTP；
4. 基于 HTTP 握手：首次连接兼容现有 HTTP 服务器，便于穿透防火墙；
5. 默认端口：80（WebSocket）/443（WSS，加密版 WebSocket）。

• 通信流程

1. 客户端发送 HTTP 升级请求（握手）；
2. 服务器响应升级确认，连接转为 WebSocket；
3. 双方通过 WebSocket 帧双向传输数据；
4. 任意一方发送关闭帧，结束连接。

• 报文格式示例

WebSocket 握手请求（客户端 -> 服务器）：

GET /ws/chat HTTP/1.1
Host: chat.example.com
Upgrade: websocket  <!-- 核心：请求升级为WebSocket -->
Connection: Upgrade  <!-- 确认连接升级 -->
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==  <!-- 随机密钥，用于验证 -->
Sec-WebSocket-Version: 13  <!-- 固定版本 -->
User-Agent: MyChatApp/1.0

WebSocket 握手响应

HTTP/1.1 101 Switching Protocols  <!-- 101状态码表示协议切换 -->
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  <!-- 密钥验证结果 -->

WebSocket 数据帧

// 客户端发送文本帧
{"type":"chat","content":"你好，服务器！","userId":123}

// 服务器推送文本帧
{"type":"broadcast","content":"用户123发送了新消息","time":"2023-10-23 10:10:00"}

• 使用场景

实时聊天（网页版微信、直播弹幕）

实时数据监控（股票行情、物联网设备数据推送）