xDS API中的每个配置资源都有一个与之相关的类型。资源类型遵循一个版本计划。资源类型是独立于下面描述的运输工具的版本。
以下v3 xDS资源类型被支持。
下面出现了类型URLs的概念，其形式为type.googleapis.com/<资源类型> - 例如，type.googleapis.com/envoy.config.cluster.v3.Cluster代表Cluster资源。在Envoy的各种请求和管理服务器的响应中，都会说明资源类型URL。
交付动态配置的最简单方法是将其放置在ConfigSource中指定的一个众所周知的路径。Envoy将使用inotify(macOS上的kqueue)来监控文件的变化，并在更新时解析文件中的DiscoveryResponseproto。二进制protobufs、JSON、YAML和proto文本是DiscoveryResponse的支持格式。
除了统计计数器和日志之外，没有任何机制可用于文件系统订阅ACK/NACK更新。如果发生配置更新拒绝，xDS API的最后有效配置将继续适用。
对于典型的HTTP路由场景，客户端配置的核心资源类型是Listener、RouteConfiguration、Cluster和ClusterLoadAssignment。每个 Listener资源可以指向一个 RouteConfiguration资源，该资源可以指向一个或多个 Cluster资源，而每个 Cluster资源可以指向一个 ClusterLoadAssignment资源。
Envoy在启动时获取所有Listener 和Cluster资源。然后，它获取 Listener和 Cluster资源所需要的任何 RouteConfiguration和 ClusterLoadAssignment资源。实际上，每一个Listener或Cluster资源都是Envoy配置树的一部分的根。
一个非代理客户端，如gRPC，可能开始时只获取它感兴趣的特定Listener资源。然后获取这些 Listener资源所需的 RouteConfiguration资源，接着是这些 RouteConfiguration资源所需的任何 Cluster资源，然后是 Cluster资源所需的 ClusterLoadAssignment资源。实际上，原始的Listener资源是客户端配置树的根。
通过流式gRPC使用的xDS传输协议有四种变体，它们涵盖了两个维度的所有组合。
第一个维度是世界状态（SotW）与增量。SotW方法是xDS最初使用的机制，客户必须在每次请求中指定其感兴趣的所有资源名称，对于LDS和CDS资源，服务器必须在每次请求中返回客户已订阅的所有资源。这意味着，如果客户已经订阅了99个资源，并想增加一个资源，它必须发送一个包含所有100个资源名称的请求，而不是只发送一个新的资源。而对于LDS和CDS资源，服务器必须通过发送所有100个资源来响应，即使已经订阅的99个资源没有变化。这种机制可能限制了可扩展性，这就是为什么后来引入了增量协议变体。增量方法允许客户端和服务器只表示相对于其先前状态的延迟--也就是说，客户端可以说它想增加或删除对某个特定资源名称的订阅，而不重新发送那些没有变化的资源，而服务器可以只为那些已经变化的资源发送更新。增量协议还提供了一种懒惰加载资源的机制。关于增量协议的细节，请看下面的增量xDS。
第二个维度是为每个资源类型使用单独的gRPC流与将所有资源类型聚合到一个gRPC流。前一种方法是xDS使用的原始机制，它提供了一个最终的一致性模型。后一种方法是为需要明确控制顺序的环境而添加的。详情请见下面的最终一致性考虑。
所以，xDS传输协议的四个变体是：