OSI七层模型
- 应用层
- 表示层
- 会话层
- 传输层
- 网络层
- 数据链路层
- 物理层
TCP/IP 四层模型
- 应用层（HTTP，DNS，SSH）
- 传输层（TCP，UDP）
- 网络层（IP，NAT，ARP）
- 网络接口层（MAC，以太网）
OSI七层模型和TCP/IP四层模型对比
HTTP协议（应用层）
- 位于应用层，基于传输层的TCP协议，主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。
- 无状态的协议，使用Cookie，Session等记住用户的状态。
HTTP1.0
- 最早出现于1996年
HTTP1.1
- 缓存处理， 提供了更多的缓存头用来控制缓存策略；
- 引入range头域，允许只请求资源的一部分，支持了断点续传；
- 引入更多错误状态码
- 引入Host头域，可以访问同一IP地址的不同域名
- 支持长连接，不用每次都要三次握手
HTTP2.0
- 二进制分帧，所有的帧都采用二进制编码
- 多路复用，每个数据流都可以拆分成很多互不依赖的帧，这些帧可以独立发送，接收端再组合起来。HTTP2.0的连接都是持久化的，每个域名一个连接。
- 请求优先级，帧可以设置优先级
- header压缩，HTTP1.1的header带有大量信息，且每次都要重复发送，HTTP2.0对此进行了压缩
- 服务端推送，服务端可以对一个请求发送多个响应
TCP协议（传输层）
面向连接，可靠，基于字节流
基于字节流是指，TCP只处理二进制数据，是无法区分数据之间的关系的，为此，HTTP协议在每个数据头标记了数据的长度，以此区分不同的数据。
三次握手
为了确认两件事情，一是客户端的发送与接受功能是否正常；二是服务端的发送与接受能力是否正常。
- 第一次握手，客户端发出消息，服务端接受到消息后，服务端确认了客户端的发送功能和服务端的接受功能正常；
- 第二次握手，服务端发送消息，客户端接受到消息后，客户端确认了客户端的发送接受功能和服务端的发送接受功能正常；
- 第三次握手，客户端发送消息，服务端接受消息后，服务端确认了客户端的接受功能和服务端的发送功能正常。
四次挥手
TCP是全双工通信，可以双向传输数据。
- 第一次挥手，客户端发出FIN消息，服务端接受到消息后，确认客户端没有消息发出了；
- 第二次挥手，服务端发出ACK消息，客户端接收到消息后，确认服务端知道了客户端不再发送消息的事实；
- 第三次挥手，服务端发出FIN消息，客户端接收到消息后，确认服务端没有消息发出了；
- 第四次挥手，客户端发出ACK消息，服务端接受到消息后，确认客户端知道了服务端不再发送消息的事实。
如何保证数据传输的可靠性
- 基于数据块传输 ：应用数据被分割成 TCP 认为最适合发送的数据块，再传输给网络层，数据块被称为报文段或段。
- 对失序数据包重新排序以及去重：TCP 为了保证不发生丢包，就给每个包一个序列号，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据就可以实现数据包去重。
- 校验和 : TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
- 超时重传 : 当发送方发送数据之后，它启动一个定时器，等待目的端确认收到这个报文段。接收端实体对已成功收到的包发回一个相应的确认信息（ACK）。如果发送端实体在合理的往返时延（RTT）内未收到确认消息，那么对应的数据包就被假设为已丢失并进行重传。
- 流量控制 : TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议（TCP 利用滑动窗口实现流量控制）。
- 拥塞控制 : 当网络拥塞时，减少数据的发送。
流量控制
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。
TCP协议会将待发送的数据拆分成数据包一个一个发送，并通过一个滑动窗口来控制发送的速率。这个窗口保证同一时刻内只有特定数量的数据包处于待发送状态，包含已经发送但未收到确认消息的数据包和即将发送的数据包。
发送窗口
接受窗口
拥塞控制
- 流量控制是端到端的，而拥塞控制是全局性的，涉及到所有的路由器和网络。
- TCP发送方会让自己的发送窗口取拥塞窗口和接收方接受窗口中较小的一个。
- TCP的拥塞控制采取了四种算法，慢开始、拥塞避免、快重传和快恢复。
RPC（应用层）
RPC(Remote Procedure Call）又叫做 远程过程调用，它本身并不是一个具体的协议，而是一种调用方式 。
不同的RPC实现要么直接基于TCP，要么基于HTTP协议，总之，都是应用层的协议。核心功能有：
- 客户端：调用远程方法的一端
- 客户端Stub（桩）：代理类，将你调用方法，类，参数等信息传递到服务端
- 网络传输：将信息传输到服务端
- 服务端Stub（桩）：接受到请求后，指定对应的方法然后返回结果的类
- 服务端：提供远程方法的一端
Dubbo框架
Dubbo3提供了从服务定义、服务发现、服务通信到流量管控等几乎所有的服务治理能力，支持Triple协议（基于HTTP/2之上定义的下一代RPC通信协议）。
gRPC框架
Google开源的一个高性能、通用的开源RPC框架，基于HTTP/2协议设计，基于ProtoBuf序列化协议开发。
HTTP协议和RPC的区别
- RPC是C/S架构，HTTP是B/S架构。RPC协议可能每家都不一样，而HTTP协议是一个通用的协议，是个浏览器就支持。
- 服务发现，HTTP通过DNS服务查找服务器的IP地址和端口，RPC协议使用专门的中间服务来获取IP地址和端口。
- 底层连接方式，HTTP协议再建立了底层TCP连接后一般会复用该连接，RPC协议会维护一个TCP连接池，用完再放回去，无太大区别。
- 传输内容，一般包含消息头和消息体。HTTP协议传输的内容以字符串或json格式为主，RPC可以使用Protobuf序列化格式保存二进制数据，信息密度更高。
Protobuf序列化协议
采用Tag-Length-Value将每个字段编码成二进制数据，然后拼接成一个二进制字节流，信息密度十分紧凑。
