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; // 电话 }
a
用Protobuf是因为它序列化高效、数据传输快，还能跨语言、版本兼容好。Protobuf里的int类型有int32、int64、uint32、uint64、sint32、sint64等，像int32、int64常用。比如通讯录项目，用int32存年龄，还能嵌套定义电话等消息结构，方便又灵活。