TCP/IP
TCP 如何保证可靠传输
TCP（传输控制协议）通过以下几个机制来保证可靠传输：
- 确认和重传机制：TCP 要求接收方在收到数据后发送确认（ACK）消息。如果发送方在特定时间内未收到确认，则会重传数据包。
- 序列号：TCP 为每个数据包分配一个序列号，接收方通过序列号来重组数据包，并可以检测出丢失的包或乱序的包。
- 窗口控制：TCP 使用滑动窗口协议来控制数据的流动，确保发送方不会淹没接收方的缓冲区。
- 流量控制：接收方会告知发送方其缓冲区的大小，发送方根据这个信息调整发送速率，防止数据溢出。
- 拥塞控制：TCP 使用多种算法（如慢启动、拥塞避免、快速重传和快速恢复）来检测和避免网络拥塞，从而提高传输效率和可靠性。
- 错误检测：TCP 数据包包含校验和字段，接收方会使用它来检查数据包是否在传输过程中损坏。如果发现错误，接收方会丢弃损坏的数据包，发送方需要重新发送这些包。
HTTP 长连接
参考 HTTP 长连接和短连接
HTTP 的常见请求头
time wait 状态过多会导致的问题？如何解决？
端口的范围是 0-65535，去掉系统和其它服务占用的部分，TCP 可用的端口其实并不多。在这种情况下，如果有大量连接停留在 TIMEWAIT 状态，会导致其它 HTTP 请求来临的时候无法使用这些端口。即：持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。
解决方法： 解决 TIME_WAIT 过多造成的问题 - 博客园 Linux TCP 状态 TIME_WAIT 过多的处理 - 知乎
RPC
RPC 的原理及过程
RPC（Remote Procedure Call，远程过程调用）是一种通过网络使得不同系统之间能够调用彼此的方法或函数的协议。它隐藏了网络通信的细节，使得远程调用看起来像本地调用一样简单。RPC 的工作原理和过程通常包括以下几个步骤：
RPC 的原理
RPC 的基本原理是让客户端可以像调用本地方法一样调用服务器端的方法，客户端调用的方法实际上会被转换成网络消息发送到服务器端执行，执行结果再通过网络消息返回给客户端。
RPC 的过程
- 客户端调用：
- 客户端调用一个本地的代理（stub），这个代理方法具有与服务器端方法相同的接口。
- 序列化请求：
- 客户端代理将方法的参数序列化成二进制数据，这个过程称为编组（marshalling）。
- 发送请求：
- 序列化后的数据通过网络发送到服务器端。
- 服务器接收请求：
- 服务器端的代理（stub）接收到请求数据后，将数据反序列化（unmarshalling）成相应的参数。
- 方法执行：
- 服务器端的代理调用实际的方法执行，并将执行结果返回给服务器端代理。
- 序列化响应：
- 服务器端代理将方法执行的结果序列化成二进制数据。
- 发送响应：
- 序列化后的结果通过网络发送回客户端。
- 客户端接收响应：
- 客户端代理接收到响应数据后，将数据反序列化成方法的返回值。
- 返回结果：
- 客户端代理将返回值传递给调用的客户端程序。
RPC 的实现细节
- 接口定义语言（IDL）：
- 使用 IDL 定义客户端和服务器端的接口，确保两端的接口一致。常见的 IDL 包括 Google 的 Protocol Buffers，Apache Thrift 等。
- 序列化和反序列化：
- 负责将方法参数和返回值在二进制数据和对象之间转换，常用的序列化框架有 JSON、XML、Protocol Buffers、Thrift 等。
- 网络传输：
- 通过 TCP/IP 或其他协议在客户端和服务器端之间传输数据。
- 错误处理：
- 处理网络故障、服务器故障、超时等各种可能的异常情况。
RPC 的优缺点
优点：
- 隐藏网络通信细节，使得分布式系统的开发更加简单。
- 可以使用多种传输协议和序列化协议，灵活性强。
缺点：
- 性能开销：网络通信和序列化反序列化带来的额外开销。
- 调试困难：由于调用过程涉及网络传输，调试和故障排查比本地调用复杂。
常见的 RPC 框架
- gRPC：基于 HTTP/2 和 Protocol Buffers 的高性能 RPC 框架，支持多种语言。
- Apache Thrift：支持多种传输协议和序列化格式，跨语言的 RPC 框架。
- Apache Dubbo：主要用于 Java，具有丰富的服务治理功能。
- Hessian：基于 HTTP 的轻量级 RPC 框架，主要用于 Java。