Corda节点与Notary通信机制及首次流执行耗时问题咨询

问题1：Corda节点与Notary的通信是否与和其他peer节点的通信方式相同？ #

TLS connections
Corda使用TLS对节点间的点对点连接进行加密。实践表明，JVM TLS层可达到的最大吞吐量会限制需要在peer间传输大量数据的流的节点吞吐量，例如性能测试CorDapp中的CashIssueAndPayment流。

参考Corda 4.9企业版官方文档中关于TLS连接的优化章节可知：Corda节点与Notary的通信和与其他peer节点的通信采用相同的TLS加密机制，文档明确说明所有节点间的点对点连接均通过TLS加密，Notary作为网络内的节点之一，遵循统一的通信加密规则。

问题2：若节点与Notary的通信同样采用上述TLS机制，那么连接（如握手）是仅在首次流执行时建立，还是随节点重启时就建立？ #

节点与Notary的TLS连接握手仅在首次执行涉及Notary的流时建立，节点重启后不会自动预建立该连接。只有当节点发起需要与Notary交互的流操作（如公证交易）时，才会触发完整的TLS握手流程，建立加密连接；后续涉及Notary的流调用可复用已建立的连接，无需重复握手。

补充问题：节点启动后首次调用流比后续调用耗时显著更长的原因分析 #

对应原问题：Corda JMeter性能测试中，线程组内首个采样器（均为Java请求采样器）耗时远高于后续采样器

导致首次流调用耗时更长的核心原因包括：

• TLS握手开销：首次与peer或Notary通信时，需完成证书验证、密钥协商等完整TLS握手步骤，产生额外耗时；后续调用复用已建立的连接，避免重复握手。
• JVM类加载与初始化：节点启动后首次执行流，JVM需加载并初始化CorDapp类、流逻辑类及依赖库，该初始化操作仅在首次执行时发生，后续调用直接复用已加载的类实例。
• 缓存未命中：首次执行流时，节点的身份信息、网络地址等缓存尚未建立，需从数据库或网络获取数据；后续调用直接读取缓存，提升效率。
• 数据库连接初始化：首次流执行可能需要建立新的数据库连接或初始化会话，该过程增加首次调用耗时；后续调用复用连接池中的已有连接。

内容的提问来源于stack exchange，提问作者Benjamin