当前位置：首页 > news >正文

[re_2] rpc|http|nginx|protobuf|

news 2025/9/5 10:54:23

1.为什么做rpc这个项目

2.rpc和http应用场景有什么区别

RPC适合系统内部各模块间高效通信（如电商系统的订单和支付模块）

HTTP适合不同系统间跨网络交互（如调用第三方天气接口）

http

http1--1.1

HTTP 1.0是无状态、无连接的应用层协议，每次请求都要建立新TCP连接，用完就断

虽可通过cookie/session做身份和状态管理，但存在无法复用连接、队头阻塞等问题

不支持文件断点续传，缓存控制也较简单，带宽利用有浪费；

HTTP 1.1做了改进

支持长连接，能在一个TCP连接上传多个请求响应，引入更多缓存策略和range头域实现部分资源请求，

新增错误状态码，还要求请求带host头域，提升了性能与功能。

--http2

http2：http://www.http2demo.io/

HTTP/2 兼容 HTTP/1.1 靠 Upgrade 机制：

客户端先通过请求头里的 Connection 和 Upgrade 字段，询问服务器是否支持 HTTP/2（协议名 h2c）。

服务器若不支持，就按 HTTP/1.1 通信；
若支持，会返回 101 状态码，之后用 HTTP/2 通信。

像 OkHttp 这类工具也用类似协议协商升级的方式，先以 HTTP/1.1 发请求，再看服务器是否支持升级。

3.nginx的反向代理和正向代理 nginx的负载均衡策略

正向代理：客户端主动配置，代理客户端

反向代理：代多台服务器，做内部负载均衡

负载均衡策略

随记

- 随机：随机选集群节点处理请求，请求多了各节点负载会趋于平衡，简单高效，适合对负载均衡要求不高的场景。

- 加权随机：按服务器权重复制后随机选，比如服务器 A权重1、B权重2，复制成[A,B,B]再随机选，但依赖伪随机数，集群伸缩时精度有问题。

轮询

- 简单轮询：按顺序轮流把请求分给服务器，不考虑服务器性能差异，易造成资源浪费，应用少。
- 加权轮询：给服务器设置权重，根据性能分配请求。有经典（WRR）和交错（IWRR）两种实现，IWRR能避免节点负载尖刺，节点权重相近时效果好，权重差异大时和WRR效果趋同，实践中还会用节点权重最大公约数优化。
- 平滑加权轮询：解决加权轮询可能连续调用同一服务器的问题，让请求分配更均匀，避免服务器连续过载。

hash

- Hash 类：
- 哈希取模：对请求相关内容哈希后取模，把请求分到对应服务器。

- 一致性 Hash：解决服务器增减时大量请求重新分配的问题，更稳定。

- 最少活跃数：把请求分给当前活跃调用数最少的服务器，因为活跃数少说明服务器效率高。

- 引申出的负载均衡方式有 DNS 负载均衡、Nginx 的四层和七层负载均衡，以及 CPU 多核间的负载均衡等。

负载均衡应用

- DNS负载均衡：靠DNS服务器返回不同IP分配请求，简单易扩展，但难实时感知服务器状态，调整生效有延迟。

- Nginx四层负载均衡：基于传输层IP和端口转发请求，性能高且能做健康检查，却无法深度处理应用层数据。

- Nginx七层负载均衡：解析应用层（如HTTP）内容来分发请求，灵活能实现复杂逻辑，但更耗CPU，性能有损耗。

- CPU多核间负载均衡：系统用调度算法把任务分到空闲CPU核心，提升CPU利用率和系统性能，不过调度算法复杂，还可能有额外开销。

DNS

攻击者为放大DNS响应，常查ANY类型（请求所有记录）。常见DNS记录类型有A（解析域名到IP）、NS（指定域名服务器）、CNAME（别名解析）等。

防御可通过检测源IP的ANY查询次数，超阈值就拦截。针对伪造IP，可强制升级到TCP：按标准，DNS查询先试UDP，响应截断就用TCP重发，解析器和服务器需支持TCP作为备份。

4.为什么选择protobuf 为什么protobuf不需要带属性

代码

syntax="proto3"; package contacts; // 非嵌套 message Phone { string phone_num = 1; } message PeopleInfo { string name = 1; // 姓名 int32 age = 2; // 年龄 // 可嵌套 // message Phone // { // string PhoneNum = 1; // } repeated Phone phones = 3; // 电话 }