为什么单独讲连接建立
前面讲网络设计时提到，Kafka 用一个 Selector 管理所有 Broker 连接。但连接不是一开始就有的------Producer 启动时不建连，第一次发消息时才触发。
很多人踩过这个坑：Producer 启动后第一条消息延迟特别高，可能要几百毫秒甚至几秒。原因就是这条消息触发了完整的连接建立流程：TCP 三次握手 + SASL 认证 + TLS 握手（如果启用）+ ApiVersions 协商。这篇把这个流程拆开讲。
01 连接建立完整流程
连接建立分 5 个阶段，从触发到就绪：
T0 触发连接： Sender 线程调用 NetworkClient.initiateConnect(nodeId) 时，ConnectionStates 里这个节点的状态是 NOT_CONNECTED，于是创建 KafkaChannel，调用 SocketChannel.connect() 发起非阻塞连接，注册 OP_CONNECT 事件。
T1 TCP 三次握手： SocketChannel.connect() 是非阻塞的，立即返回。Selector 在下一轮 select() 中检测到 OP_CONNECT 就绪，调用 finishConnect() 完成 TCP 连接。这一步在 PLAINTEXT 模式下连接就已经可用了。
T2 SASL 认证（如启用）： 如果 security.protocol 是 SASL_PLAINTEXT 或 SASL_SSL，TCP 连接建立后不会立即收发业务数据，而是先做 SASL 认证。SaslClientAuthenticator 处理多轮 challenge-response 握手，支持 PLAIN、SCRAM-SHA-256、GSSAPI 等机制。认证通过前，连接状态是 AUTHENTICATING，所有读写被拦截。
T3 TLS 握手（如启用 SSL）： 如果 security.protocol 是 SSL 或 SASL_SSL，SslTransportLayer 用 SSLEngine 做 TLS 握手：ClientHello → ServerHello + 证书 → ClientKeyExchange → Finished。证书验证、主机名验证、密钥协商都在这一步完成。
T4 连接就绪： 认证和加密都完成后，KafkaChannel 会发一个 ApiVersionsRequest 协商双方支持的 API 版本。收到响应后，ConnectionStates 标记为 READY，KafkaChannel.ready() 返回 true，开始正常收发 ProduceRequest。
一个关键细节： PLAINTEXT 模式只有 TCP 握手，连接最快；SASL_PLAINTEXT 多一轮认证；SASL_SSL 要 TCP + SASL + TLS，握手延迟最高但最安全。
02 KafkaChannel 与 TransportLayer 分层架构
Kafka 用分层设计来支持多种安全协议，上层 NetworkClient 只看到统一的 KafkaChannel 接口：
KafkaChannel 是最上层，对 NetworkClient 暴露 setSend()、write()、read()、ready() 等统一接口。它内部维护 NetworkSend 和 NetworkReceive 缓冲区，处理消息的分片读写。
Authenticator 是可选的认证层。SASL 模式下用 SaslClientAuthenticator，认证完成前拦截所有读写，认证完成后透传。PLAINTEXT 和纯 SSL 模式下没有这一层。
TransportLayer 是传输层，有三种实现：
- PlaintextTransportLayer：直接封装 SocketChannel，无加密无认证，性能最好
- SslTransportLayer：封装 SSLEngine + SocketChannel，做 TLS 加解密
- SaslTransportLayer：继承 SslTransportLayer，TLS + SASL 认证，最安全
这种分层设计的好处是：上层 KafkaChannel 不需要关心底层是明文还是加密，调用统一的 read/write 接口即可。切换 security.protocol 只需要换 TransportLayer 实现，上层代码不用改。
03 连接失败处理与重连机制
连接建立过程中可能失败，Kafka 区分了四种场景，处理策略不同：
TCP 连接超时 ：Broker 宕机或网络不通时，connect() 长时间不返回 OP_CONNECT。由 request.timeout.ms（默认30秒）检测超时，超时后触发重连。
认证失败 ：用户名密码错误或 SASL 机制不匹配，抛出 SaslAuthenticationException。这是不可重试异常------密码错了重试也没用，直接抛出，不会重连。
TLS 握手失败：证书过期、不被信任、主机名验证失败，抛出 SSLHandshakeException。也是不可重试，需要检查证书和 ssl 配置。
连接中断 ：已建立连接后 Broker 重启或网络抖动，抛出 DisconnectException。可重试，批次放回队首，触发重连。
可重试场景的重连用指数退避 + 随机抖动 ：backoff = reconnect.backoff.ms * 2^attempts + random(0, jitter)。默认初始 50ms，上限 1000ms。第1次等50ms，第2次100ms，第3次200ms......第6次起封顶1000ms。避免 Broker 宕机时客户端疯狂重连打满 CPU。
连接池管理 ：每个 Broker 节点一个 KafkaChannel（不是每个分区一个连接），由 Selector 统一管理。空闲超过 connections.max.idle.ms（默认9分钟）会被主动关闭，下次发送时重新建立。低频发送场景可以适当调大这个参数，减少重复建连开销。
写在最后
连接建立是 Kafka 网络层的"冷启动"过程。理解了 TCP 握手 → SASL 认证 → TLS 加密 → ApiVersions 协商这个顺序，就能解释很多实际问题：为什么第一条消息慢、为什么换了安全协议后延迟升高、为什么认证失败不会重试、为什么 Broker 重启后客户端能自动恢复。