SOME/IP 协议详解——远程过程调用（RPC）

1. 传输协议绑定

• 协议支持： SOME/IP 目前支持 UDP（用户数据报协议）和 TCP（传输控制协议）。
• 具体规则
  • 如果一个服务器运行同一服务的多个实例，属于不同服务实例的消息应通过服务器端的传输协议端口映射到服务实例。
    • 示例：一辆车有四个轮胎压力传感器，每个传感器作为一个服务实例。当这些传感器发送轮胎压力数据（即消息）时，服务器（如车辆的中央控制单元）需要根据传输协议端口准确地知道每个消息来自哪个轮胎的传感器。
  • 所有传输协议绑定应支持在一个传输层协议数据单元（PDU，即 UDP 数据包或 TCP 段）中传输多个 SOME/IP 消息。
    • 示例：在一个车辆系统中，多个电子控制单元需要同时向中央控制单元发送状态消息。使用 UDP 时，一个 UDP 数据包可以包含多个 SOME/IP 消息，这些消息可能来自不同的 ECU，如发动机控制单元、刹车控制单元等；使用 TCP 时，一个 TCP 段也可以携带多个这样的消息。
  • 接收 SOME/IP 实现应能够接收通过 UDP 或 TCP 传输的未对齐的 SOME/IP 消息。理由是：当在 UDP 或 TCP 中传输多个 SOME/IP 有效载荷时，只有当每个有效载荷的长度是对齐大小（例如 32 位）的倍数时，才能保证有效载荷的对齐。

1.1 UDP 绑定

• 传输方式：SOME/IP 协议利用 UDP 传输消息时，直接将 SOME/IP 消息封装在 UDP 数据包内。这意味着 SOME/IP 消息作为 UDP 数据包的有效载荷进行传输，UDP 为其提供基本的传输服务。
• 分片限制：SOME/IP 协议本身不限制 UDP 的分片功能。UDP 分片是将一个较大的 UDP 数据包分割成多个较小的片段进行传输，在网络层可能会因为链路层的最大传输单元（MTU）限制而发生。例如，当一个 SOME/IP 消息较大，超过了网络链路层的 MTU 时，UDP 会自动将其分片，而 SOME/IP 协议允许这种分片操作。
• 消息识别与头部独立性：在单个 UDP 数据包中可能包含多个 SOME/IP 消息。接收方通过 SOME/IP 消息头部中的长度字段来确定每个消息的边界。每个 SOME/IP 有效载荷都有自己独立的 SOME/IP 头部，这使得每个消息在 UDP 数据包内能够被独立识别和处理，即便它们在同一个 UDP 数据包中传输。

1.2 TCP 绑定

• 与 UDP 绑定的关系及特性增强：TCP 绑定基于 UDP 绑定构建，在其基础上提供了更强大的功能。TCP 本身具有可靠性特性，能够处理如数据丢失、重复、乱序以及网络拥塞等问题，SOME/IP 利用 TCP 的这些特性来确保更可靠的消息传输，尤其适用于对数据完整性和准确性要求较高的场景。
• Nagle 算法设置：为了降低延迟并提高反应速度，在使用 TCP 绑定进行 SOME/IP 通信时，应关闭 Nagle 算法（即设置 TCP_NODELAY 选项）。Nagle 算法的目的是减少网络中微小数据包的数量，但在某些实时性要求较高的场景下，关闭它可以使消息能够更快地发送出去，减少不必要的等待时间。
• 连接管理责任与行为
  • 连接建立与关闭时机：TCP 连接由客户端负责管理。当客户端需要发送第一个方法调用或者尝试接收第一个通知时，它会主动打开 TCP 连接；当 TCP 连接不再需要时（例如，相关服务已停止或超时），客户端负责关闭连接。这确保了连接的有效性和资源的合理利用，避免不必要的连接占用网络资源和系统开销。
  • 连接丢失处理：如果 TCP 连接丢失，客户端未完成的请求将被视为超时。这意味着客户端需要在应用层处理这种超时情况，可能需要采取相应的措施，如重新发送请求或者进行错误处理，以保证业务逻辑的正确性。
  • 多服务实例与连接关系：对于一个服务实例的所有方法、事件和通知，都使用单个 TCP 连接进行传输，以保证数据的有序性和连贯性。当存在多个服务实例时，每个服务实例需要单独的 TCP 连接，这样可以避免不同服务实例之间的通信干扰，确保每个服务实例的通信独立、稳定。
• 魔数饼干（Magic Cookies）的作用：为了便于测试工具识别通过 TCP 传输的 SOME/IP 消息边界，可在 TCP 消息流中定期插入 SOME/IP 魔数饼干消息。这些魔数饼干消息具有特定的格式和内容，就像在消息流中设置的特殊标记，测试工具可以通过检测这些标记来准确地确定 SOME/IP 消息的起始和结束位置，从而更好地进行测试和分析工作。
  

1.3 多服务实例（重要）

• 实例区分方式：同一服务的不同实例通过唯一的实例 ID 进行区分。这个实例 ID 在服务发现和通信过程中起到关键作用，使得系统能够准确识别和定位不同的服务实例，就像每个人都有唯一的身份证号码一样，用于在众多服务实例中准确找到目标实例。
• 部署情况与端口分配：这些服务实例可以分布在不同的电子控制单元（ECU）上，也可以多个实例同时存在于一个 ECU 中。在端口分配方面，不同的服务可以共享传输层协议（如 UDP 或 TCP）的相同端口号，但同一服务的不同实例在单个 ECU 上必须监听不同的端口。这样的设计确保了在复杂的汽车电子系统中，不同服务实例之间的通信不会发生冲突，并且能够被准确地路由和处理。例如，多个不同的服务可以共同使用 UDP 的 5000 端口进行通信，但如果一个服务有多个实例在同一 ECU 上运行，每个实例将使用不同的端口，如 5001、5002 等，通过服务 ID、实例 ID 以及端口号的组合，系统能够精确地找到目标服务实例进行通信。

1.4 通过 UDP 传输大型 SOME/IP 消息（SOME/IP - TP）

• SOME/IP - TP 的引入

  • SOME/IP 的 UDP 绑定只能传输能直接放入 IP 数据包的 SOME/IP 消息。
  • 对于大于一定尺寸（例如 32KB）的 SOME/IP 消息，需要使用 SOME/IP 传输协议（SOME/IP - TP）。
  • 大尺寸的 SOME/IP 消息被称为 “original” SOME/IP 消息，这些消息在 SOME/IP - TP 中被拆分成多个 “segments”（段）进行传输。
  • 只有在需要传输非常大的数据块（> 1400 字节）且在出现错误时对延迟没有严格要求的情况下才使用 TCP。

• SOME/IP - TP 的相关规则

  • 使用 SOME/IP - TP 传输 SOME/IP 消息时需要激活会话处理（Session Handling），且每个原始消息的会话 ID 必须唯一。
  • 所有 SOME/IP - TP 段都应携带原始消息的会话 I