MQTTS本质是MQTT over TLS，无独立握手格式；其TLS握手发生在TCP连接后、MQTT帧前，属下层协议，应用层不可见原始握手字节；推荐用Wireshark/tshark分析，C++应通过OpenSSL等库获取解析后的握手信息而非自行解析二进制。
MQTTS 不是独立协议，本质是 MQTT + TLS
MQTTS 没有自己独有的“握手数据包格式”。所谓“MQTTS 的 TLS 握手”，就是标准 TLS 1.2 或 TLS 1.3 在 TCP 连接建立后、MQTT 协议帧传输前发生的加密协商过程。你无法也不应该用 C++ 直接“解析 MQTTS 的 TLS 握手数据包”——因为那根本不是 MQTT 层面的数据，而是下层 TLS Record Layer 和 Handshake Protocol 的原始字节流。
真正能做的，是在 TLS 握手完成前捕获并分析这些裸字节（例如通过抓包或中间人代理），或在 TLS 库内部钩住握手回调。但注意：一旦 TLS 连接建立成功，应用层（如 mosquitto、paho-cpp）看到的只有已解密的 MQTT 报文，再也看不到原始握手内容。
用 Wireshark / tshark 解析 TLS 握手最实际
如果你的目标是“看懂 TLS 握手发生了什么”，C++ 编程不是首选路径。直接用网络分析工具更可靠、可复现、无需实现密码学逻辑：
- 启动 MQTT 客户端连接
test.mosquitto.org:8883（MQTTS 默认端口） - 用
tshark -i any -d tcp.port==8883,ssl -Y "ssl.handshake" -V抓取并解码握手字段 - 重点关注
ClientHello中的supported_versions、signature_algorithms、key_share（TLS 1.3）或cipher_suites（TLS 1.2） - Wireshark 可加载服务器证书（若未启用 SNI 或证书公开），验证
Certificate消息结构是否符合 X.509 v3
硬用 C++ 解析 raw TLS handshake bytes 需要手动实现 SSL3_RT_HANDSHAKE 记录头解析、握手消息长度字段提取、枚举类型判别（handshake_type == 1 是 ClientHello），极易因版本差异或扩展字段错位导致解析失败。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
在 C++ TLS 库中获取握手元信息（非原始包）
若必须在 C++ 程序中感知握手结果，应依赖 TLS 库提供的安全接口，而非自行解析字节流。以 OpenSSL 为例：
<pre class="brush:php;toolbar:false;">SSL_CTX* ctx = SSL_CTX_new(TLS_client_method());
SSL* ssl = SSL_new(ctx);
// 设置 verify callback，可在 SSL_do_handshake() 期间获取证书链
SSL_set_verify(ssl, SSL_VERIFY_PEER, verify_callback);
SSL_set_fd(ssl, sockfd);
int ret = SSL_connect(ssl); // 阻塞完成 TLS 握手
<p>// 握手完成后，读取协商结果：
const SSL_CIPHER* cipher = SSL_get_current_cipher(ssl);
printf("Negotiated cipher: %s\n", SSL_CIPHER_get_name(cipher)); // e.g. "TLS_AES_256_GCM_SHA384"</p><p>X509<em> peer_cert = SSL_get_peer_certificate(ssl);
if (peer_cert) {
char</em> subj = X509_NAME_oneline(X509_get_subject_name(peer_cert), nullptr, 0);
printf("Server cert subject: %s\n", subj); // 不是原始 ASN.1，是解析后字符串
OPENSSL_free(subj);
}</p>这里的关键是：SSL_get_current_cipher() 和 <code>SSL_get_peer_certificate() 返回的是库内部已解析、验证过的结构体，不是原始 packet buffer。强行从 SSL_read() 前的 socket 缓冲区里扣 handshake 数据，会破坏 TLS 状态机，且 OpenSSL 不暴露底层 record 解析 API。
为什么不要自己解析 TLS 握手二进制？
即使你拿到完整的 TLS 握手流量（比如从 pcap 文件读出），手动解析仍面临不可控复杂度：
- TLS 1.2 和 1.3 的
ClientHello结构完全不同：1.3 移除了cipher_suites中的 RSA/SHA1 组合，并把密钥交换移到key_share扩展里 - 扩展字段（
extension_type）需逐个解析长度+内容，常见扩展如server_name（SNI）、supported_groups、application_layer_protocol_negotiation（ALPN，MQTT 通常设为"mqtt"） - 没有完整证书链时，
Certificate消息可能只含根证书指纹，或触发 OCSP stapling —— 这些都得调用 OpenSSL/BoringSSL 的 ASN.1 解析器，不是靠memcpy能搞定的 - 现代 TLS 常启用 0-RTT（TLS 1.3），首次握手后的 early data 包和 handshake 包混在同一 TCP segment，边界模糊
真正需要深度定制的场景（如 IoT 设备证书预置策略分析），应基于 openssl s_client -connect host:8883 -debug -tlsextdebug 输出做文本解析，而不是从零写 C++ 二进制 parser。
