协议 tcp rpc http websocket

传输层：tcp，udp

应用层：http，grpc，websocket

浏览器服务器太多了，互相沟通需要统一的协议，http主要用于B/S

如果是公司内部，轻量小巧定制化，用rpc

http是半双工，同一时间，只能一方发送消息，客户发送请求，

建立http连接后，通过header可以申请升级到 websocket 协议

 

待补充wireshark的抓包分析：

--------------------------

TCP、RPC、HTTP、WebSocket 是不同层级、不同定位的网络通信相关概念，覆盖从底层传输到上层应用调用的范围。下面从定义、核心特点、使用场景等维度逐一拆解，帮你理清它们的区别与关联：

1. TCP（Transmission Control Protocol，传输控制协议）

定义

TCP 是传输层（OSI 七层模型的第四层）的面向连接的可靠传输协议，位于 IP 协议之上、应用层协议（如 HTTP、WebSocket）之下，负责在两台主机之间建立可靠的字节流传输通道。

核心特点

• 面向连接：通信前必须通过 “三次握手” 建立连接，通信结束后通过 “四次挥手” 释放连接。
• 可靠传输：通过序列号、确认应答（ACK）、重传机制、流量控制（滑动窗口）、拥塞控制等，保证数据按序、无丢失、无重复到达。
• 字节流传输：将数据视为连续的字节序列，不保留消息边界（需应用层自行处理拆包 / 粘包）。
• 全双工通信：连接建立后，双方可同时收发数据。

适用场景

需要可靠数据传输的场景，如文件传输（FTP）、邮件发送（SMTP）、网页访问（HTTP 基于 TCP）、数据库连接（MySQL 基于 TCP）等。

局限性

• 建立连接耗时（三次握手），开销略高；
• 对丢包敏感，重传机制可能导致延迟增加（不适合对实时性要求极高的场景，如语音通话）。

2. HTTP（HyperText Transfer Protocol，超文本传输协议）

定义

HTTP 是应用层（OSI 七层模型的第七层）的无状态协议，基于 TCP 传输，最初用于浏览器与服务器之间传输超文本（HTML），现在成为通用的 RESTful API 通信协议。

核心特点

• 基于 TCP：默认使用 80 端口（HTTPS 用 443 端口），通信前需建立 TCP 连接（HTTP/1.1 支持长连接，可复用连接）。
• 无状态：服务器不保留客户端的会话状态（每次请求独立，需通过 Cookie、Session 等额外机制维持状态）。
• 请求 - 响应模型：客户端发起请求（如 GET/POST/PUT/DELETE），服务器返回响应，一问一答，默认单向（客户端主动，服务器被动）。
• 版本演进：
  • HTTP/1.0：短连接，每次请求需新建 TCP 连接，效率低；
  • HTTP/1.1：支持长连接（Connection: keep-alive），管线化请求，减少连接开销；
  • HTTP/2：多路复用（一个 TCP 连接并发处理多个请求）、二进制帧、头部压缩，性能大幅提升；
  • HTTP/3：基于 UDP（QUIC 协议），解决 TCP 队头阻塞问题，更低延迟。

适用场景

• 网页浏览、RESTful API 接口（前后端交互、微服务间简单通信）；
• 一次性数据获取 / 提交（如查询数据、上传文件）。

局限性

• 被动响应：服务器无法主动向客户端推送数据（需轮询、长轮询等折中方案）；
• 无状态：需额外机制维护会话，增加开发复杂度。

3. WebSocket

定义

WebSocket 是应用层的全双工通信协议，同样基于 TCP 传输，专为解决 HTTP 单向通信的痛点设计，实现客户端与服务器的实时双向通信。

核心特点

• 基于 TCP：默认使用 80 端口（wss:// 用 443 端口），通过 “握手” 升级为 WebSocket 连接（HTTP 101 状态码确认升级）。
• 全双工通信：连接建立后，客户端和服务器可随时主动发送数据，无需等待请求。
• 长连接：连接持续存在，直到某一方主动关闭，减少反复建立连接的开销。
• 轻量级帧：数据以帧的形式传输，头部开销小，比 HTTP 更高效。
• 支持二进制 / 文本数据：可传输 JSON、二进制文件（如图片、视频片段）等。

适用场景

• 实时通信场景：聊天应用、弹幕、实时数据监控（如股票行情、物联网设备数据推送）；
• 协作工具：在线文档协作、多人游戏。

与 HTTP 的关系

WebSocket 握手阶段依赖 HTTP，握手完成后脱离 HTTP 协议，直接基于 TCP 传输数据；与 HTTP 长轮询相比，WebSocket 无需反复发起请求，资源消耗更低，实时性更强。

4. RPC（Remote Procedure Call，远程过程调用）

定义

RPC 是一种通信范式 / 框架（非单一协议），本质是 “让远程服务器上的函数调用像本地函数调用一样简单”，底层可基于 TCP 或 HTTP 传输，属于应用层的概念。

核心特点

• 透明性：调用远程服务时，开发者无需关注网络通信细节（如数据打包、传输、解包），语法与本地函数调用一致。
• 序列化 / 反序列化：将调用参数（如对象、基本类型）序列化为二进制 / JSON/Protobuf 等格式传输，服务端反序列化后执行函数，再将结果序列化返回。
• 多种传输方式：可基于 TCP（如 gRPC 基于 HTTP/2 本质也是 TCP）、HTTP（如 RESTful 可视为一种轻量 RPC），也可自定义协议。
• 服务治理：成熟的 RPC 框架（如 Dubbo、gRPC、Thrift）内置负载均衡、服务发现、熔断降级、超时重试等能力。

典型架构

plaintext

 

 

客户端（Stub）→ 序列化 → 网络传输（TCP/HTTP）→ 服务端（Skeleton）→ 反序列化 → 执行函数 → 结果返回

 

（Stub：客户端代理，模拟远程函数；Skeleton：服务端代理，处理请求并调用实际函数）

适用场景

• 微服务间通信（如 Dubbo 用于 Java 微服务、gRPC 用于跨语言微服务）；
• 分布式系统中节点间的高效调用（如大数据框架内部通信）。

常见 RPC 框架

• gRPC：Google 开发，基于 HTTP/2，使用 Protobuf 序列化，支持多语言；
• Dubbo：阿里开源，基于 TCP，主打 Java 微服务；
• Thrift：Facebook 开源，支持多传输协议（TCP/HTTP）和序列化格式，跨语言；
• RESTful API：可视为轻量 RPC，基于 HTTP，用 JSON 序列化，无强框架依赖。

核心区别与关联总结

概念	层级 / 定位	核心特征	底层传输	典型场景
TCP	传输层协议	可靠、面向连接、字节流	IP	所有需要可靠传输的场景
HTTP	应用层协议	请求 - 响应、无状态、单向（默认）	TCP	网页访问、RESTful API
WebSocket	应用层协议	全双工、长连接、实时双向通信	TCP	实时聊天、数据推送
RPC	应用层通信范式 / 框架	透明远程调用、服务治理	TCP/HTTP	微服务通信、分布式调用

关键关联

• TCP 是 HTTP、WebSocket、多数 RPC 的底层传输基础；
• WebSocket 是 HTTP 的补充，解决实时双向通信问题；
• RPC 是更高层的封装，可基于 HTTP 或 TCP 实现，目标是简化远程调用；
• HTTP 可视为一种 “松散的 RPC”，而 gRPC 等框架是 “更高效、更严谨的 RPC”。

如果你的场景是 “前后端实时聊天”，选 WebSocket；如果是 “微服务间高效调用”，选 gRPC/Dubbo；如果是 “简单的前后端数据交互”，用 HTTP RESTful；TCP 则是所有这些场景的底层保障。