企业官网建设流程全解析

简介：面向C++网络开发者的OpenSSL HTTPS访问实现参考示例。资源基于MFC完成原生Socket对HTTP站点的POST登录，集成OpenSSL后进一步实现对HTTPS站点（以小米官网为例）的POST访问，覆盖HTTP与HTTPS两种协议下的实际请求链路，并给出可运行工程的完整组织方式。包体共148个文件，以81个h头文件、9个cpp源文件为主体，附带编译好的lib静态库、dll动态库、obj中间文件、vcxproj工程文件等，整包约40.15MB，可直接引入现有项目使用，免去OpenSSL自行编译配置的繁琐环节。已有711人学习下载。通过示例可掌握OpenSSL初始化、证书管理与HTTPS POST请求封装方法，理解Socket客户端在两种协议中的差异，适合需要在MFC或C++工程中快速接入HTTPS通信的开发者作为参考。

1. 没有HTTP库的时候，怎么用OpenSSL直接访问HTTPS

项目里有个服务端只开放HTTPS接口，而代码这边因为历史原因没接任何HTTP客户端库，还必须在C++的SOCKET层把请求原样发出去。我最初试过用命令行工具转发，调试一次超时一次，后来发现最直接的方式，是在原生SOCKET之上挂OpenSSL：TCP包照常走，数据在发送前经过SSL_write，在接收后经过SSL_read，HTTP报文自己拼。这篇文章就围着这条链路展开，从SSL_CTX初始化、TLS握手，到手工构造HTTP POST报文，再到读响应和最常见的炸点，最后落成一个能复用TLS连接连续POST的写法。适合两类人：一类是在C++里要对接REST API、又不方便引第三方库的开发者，另一类是刚接触OpenSSL、想弄清楚握手和数据收发到底各自负责什么的熟手。

2. 从TCP到TLS：SSL_CTX初始化与握手细节

2.1 为什么选OpenSSL而不是先引一个HTTP库

很多人拿到HTTPS接口的第一反应，是找一处开箱即用的HTTP客户端库。但真要在既有工程里塞一个新依赖，往往会撞上三件事：编译链对不上、库版本和项目里其他模块冲突，或者机房里压根不允许新增外部包。与其在依赖上耗时间，不如在SOCKET层直接控制一切。

OpenSSL只负责TLS这一层，HTTP报文由自己拼。这样栈上少一层依赖，也方便控制底层socket的超时、非阻塞和连接复用。代价是HTTP协议细节都得自己管，但POST这种简单场景，报文也就几十行字符串拼接，可控性反而更高。

选型时有几个习惯我会先固定下来。工程里通常只需要一个全局的SSL_CTX，多个连接共享它，SSL对象才是每连接一个。之前看到有人每次请求都新建SSL_CTX，纯属浪费，而且SSL_CTX销毁时还有线程安全问题。初始化代码一般放在进程启动阶段，只执行一次。

#include <openssl/ssl.h> #include <openssl/err.h> #include <openssl/x509v3.h> SSL_CTX* g_ctx = nullptr; bool init_ssl_ctx() { if (g_ctx) { return true; } SSL_library_init(); OpenSSL_add_all_algorithms(); SSL_load_error_strings(); g_ctx = SSL_CTX_new(TLS_client_method()); if (!g_ctx) { return false; } SSL_CTX_set_default_verify_paths(g_ctx); SSL_CTX_set_verify(g_ctx, SSL_VERIFY_PEER, nullptr); return true; }

这段代码的逻辑分四步：初始化全局算法表，创建客户端TLS上下文，加载系统CA路径，打开对端证书校验。重点是SSL_CTX_set_verify(g_ctx, SSL_VERIFY_PEER, nullptr)这行，第三个参数传nullptr表示校验失败时由SSL_connect直接返回错误，而不是在回调里兜底。

参数改动就两句：如果项目要求吊销列表检查，加SSL_CTX_set0_verify_cert_store；如果只想用在内部测试环境，可以把SSL_VERIFY_PEER换成SSL_VERIFY_NONE，但那只建议在明确不会暴露到公网的场合用，上线前必须改回来。

2.2 把已连接的SOCKET升级成SSL通道

TCP和TLS是两个阶段，TCP先connect，TLS后握手，这个顺序别搞反。常见错误是先把socket交给SSL，再去做connect，结果握手时内核根本没连上对端。正确做法是用原生socket完成三次握手，然后通过SSL_set_fd把文件描述符挂到SSL对象上。

握手所需的hostname在这里要提前设置。OpenSSL 1.1.0之后，SSL_set_tlsext_host_name不仅用于SNI扩展，证书主机名校验也需要它。后续SSL_get_verify_result的返回值，会结合这个hostname一起判断。

bool connect_and_handshake(int sockfd, const std::string& hostname) { SSL* ssl = SSL_new(g_ctx); if (!ssl) { return false; } SSL_set_fd(ssl, sockfd); SSL_set_tlsext_host_name(ssl, hostname.c_str()); int ret = SSL_connect(ssl); if (ret != 1) { unsigned long err = ERR_get_error(); ERR_print_errors_fp(stderr); SSL_free(ssl); return false; } X509* cert = SSL_get1_peer_certificate(ssl); if (!cert) { SSL_free(ssl); return false; } long verify = SSL_get_verify_result(ssl); X509_free(cert); if (verify != X509_V_OK) { SSL_free(ssl); return false; } return true; }

SSL_new从全局上下文里派生一个会话对象，每个连接独立持有。SSL_set_fd只是绑定文件描述符，不触发网络动作。握手真正发生在SSL_connect返回之后，返回1才是成功；其他值都要立刻用SSL_get_error(ssl, ret)去看错误类型，而不是简单打印errno，因为TLS层的错误码和socket层的errno是两套东西，混着看容易脑补出错误结论。

证书这块，SSL_get1_peer_certificate取得对端证书后需要手动X509_free。SSL_get_verify_result返回X509_V_OK表示证书链和主机名都通过，否则常用错误是X509_V_ERR_CERT_NOT_YET_VALID和X509_V_ERR_HOSTNAME_MISMATCH，前者多半是服务器时钟问题，后者就是hostname设置不对。

2.3 证书链校验失败时，先分清root和intermediate

自签证书导致的握手失败是我见过最多的一类。现象很统一：SSL_connect返回-1，错误栈里出现certificate verify failed。第一次遇到时我以为是代码写错，查了半天才发现是测试服务器拿着自签证书，而本地CA库里根本没有对应的根证书。

解法分两层。一是用SSL_CTX_load_verify_locations加载私有CA证书，指定路径时注意是PEM文件路径而不是目录路径，目录需要额外调用SSL_CTX_load_verify_dir。二是在测试环境临时降低校验强度，但要在代码里留下明确的开关，别把SSL_VERIFY_NONE写死在正式路径里。

还要注意intermediate证书链不完整的情况。服务器返回的证书只有叶子证书，没有中间CA，本地即使有根证书也拼不出完整链。可以用openssl s_client -connect host:port -showcerts预先验证对端证书链是否完整，这一步能省掉大量排错时间。

3. 构造HTTP POST报文：从请求行到Content-Length的精确计算

3.1 报文三部分：起始行、头部、空行与body

HTTP POST报文结构很固定，起始行、头部、空行、body四段。最容易出事的不是头部内容，而是空行后的body字节长度计算。

服务端判断body长度全靠Content-Length，算错一位，对方要么一直等请求体读完，要么把下一条请求的头部当成body处理，整个会话就乱了。

#include <sstream> #include <string> std::string build_post_request(const std::string& host, const std::string& path, const std::string& content_type, const std::string& body) { std::ostringstream req; req << "POST " << path << " HTTP/1.1\r\n" << "Host: " << host << "\r\n" << "Content-Type: " << content_type << "\r\n" << "Content-Length: " << body.size() << "\r\n" << "Connection: keep-alive\r\n" << "\r\n" << body; return req.str(); }

这段代码里body.size()是字节数，C++的std::string存的是原始字节，不是字符个数。如果body是JSON，里面带中文，UTF-8编码下一个汉字占3字节，size()返回的就是这个字节数，服务端按字节流读取，正好对上。

Content-Type必须和body实际格式一致。JSON接口用application/json，表单用application/x-www-form-urlencoded，混用会导致服务端反序列化失败。Connection: keep-alive先写上，后面做连接复用要用到。

3.2 一个能直接跑的POST封装

把前面几步串起来，就是一个完整请求。这里复用g_ctx，内部新建socket、握手、拼报文、发送、循环读响应，最后统一释放。

#include <cstring> #include <netdb.h> #include <unistd.h> #include <arpa/inet.h> bool http_post(const std::string& host, int port, const std::string& path, const std::string& body, std::string& response) { int sockfd = socket(AF_INET, SOCK_STREAM, 0); if (sockfd < 0) { return false; } struct hostent* hp = gethostbyname(host.c_str()); if (!hp) { close(sockfd); return false; } struct sockaddr_in addr{}; addr.sin_family = AF_INET; addr.sin_port = htons(port); memcpy(&addr.sin_addr, hp->h_addr, hp->h_length); if (connect(sockfd, (struct sockaddr*)&addr, sizeof(addr)) < 0) { close(sockfd); return false; } SSL* ssl = SSL_new(g_ctx); SSL_set_fd(ssl, sockfd); SSL_set_tlsext_host_name(ssl, host.c_str()); if (SSL_connect(ssl) != 1) { ERR_print_errors_fp(stderr); SSL_free(ssl); close(sockfd); return false; } std::string request = build_post_request( host, path, "application/json", body); int sent = SSL_write(ssl, request.data(), (int)request.size()); if (sent <= 0) { SSL_free(ssl); close(sockfd); return false; } char buf[8192]; std::string raw; int received = 0; while ((received = SSL_read(ssl, buf, sizeof(buf))) > 0) { raw.append(buf, received); if (raw.find("\r\n\r\n") != std::string::npos && raw.find("\r\n0\r\n") != std::string::npos) { break; } } response = raw; SSL_free(ssl); close(sockfd); return true; }

这段代码有几个取舍要说明。gethostbyname只做域名解析，如果有IPv6需求，换getaddrinfo更顺，但对应的socket创建分支也要调整。SSL_write的返回值是成功发送的字节数，这里没有做半包处理，因为一个POST请求一般不会超过TCP发送缓冲区。

响应读取用循环，目的是处理TCP粘包。SSL_read一次不一定返回完整响应，必须把数据累加后判断结束条件。这里的1465字节读的是chunked响应，判断\r\n0\r\n表示读到最后一个chunk。如果是Content-Length型响应，这个判断就不可靠。

3.3 读响应：先判断编码格式再定终止条件

响应体有两种常见格式：Content-Length和Transfer-Encoding: chunked。前者按头部里的长度读，读到字节数等于Content-Length就结束；后者按分块规则读，块大小用十六进制写在每块开头，读到0\r\n\r\n才算完。

bool is_response_complete(const std::string& raw, const std::string& content_length) { if (!content_length.empty()) { size_t body_len = (size_t)std::stoul(content_length); size_t header_end = raw.find("\r\n\r\n"); if (header_end == std::string::npos) { return false; } return raw.size() >= header_end + 4 + body_len; } return raw.find("\r\n0\r\n") != std::string::npos; }

这段逻辑的关键是，先找到头部和body的分隔空行\r\n\r\n，再用总长度减掉头部长度得出body字节数。很多人在Content-Length解析上翻车，是因为没有考虑头部也有可能分多次到达，find找不到空行时就要继续读。

还有一类服务端会同时返回Connection: close，意思是读完响应就断开。这种情况下读到SSL_read返回0即可结束，说明对端已经正常关闭TLS会话，不要当成错误。

4. HTTPS POST避坑记录：TLS握手与HTTP报文最容易翻车的五个位置

4.1 现象：socket连接成功，SSL_connect一直返回-1

第一次排查时，我拿着ERR_print_errors_fp打出来的栈看半天，错误码是SSL routines:ssl3_read_bytes:sslv3 alert handshake failure。明明端口通的，为什么握手会失败。

原因是对端根本不是HTTPS服务，而是HTTP明文服务。浏览器会自动升级，但OpenSSL不会，它默认走TLS，对面收到的是乱码，直接回一个握手失败的alert。更隐蔽的情况是中间有代理服务器拦了443端口，代理不理解TLS报文。

解决：先在命令行验证对端协议，openssl s_client -connect host:port -servername hostname，如果输出里没有BEGIN CERTIFICATE，说明那一端不是标准TLS服务。再把SSL_set_fd之前的socket设置超时，避免对端不响应时整个进程挂死。

4.2 现象：POST发出后服务端迟迟不返回，直到超时

请求看起来发送成功，SSL_write也返回了完整字节数，但服务端就是不动。

原因是Content-Length算多了或者算少了。算多了，服务端会一直等剩下的body；算少了，服务端把body后半截当成下一段请求解析。这个坑在body含中文时尤其容易踩，因为有人会数“字符个数”而不是“字节个数”。C++里std::string::size()无法犯这个错，但如果你把body转成std::wstring再转回，字节就变了。

解决：不用手数，直接body.size()，并在服务端日志里确认收到的Content-Length和实际字段一致。调试时可以在本地用Python起一个临时HTTP服务，打印收到的原始字节，对比发送内容，一眼就能看出问题。

4.3 现象：SOCKET改成非阻塞后，SSL_read返回-1

项目要求高并发，我把socket设成非阻塞，结果SSL_read负值满天飞，程序直接认为连接断了。

原因是非阻塞socket下，SSL_read返回-1不一定代表连接关闭，要用SSL_get_error(ssl, ret)区分。返回SSL_ERROR_WANT_READ表示底层socket暂时没有数据，应该等epoll可读事件后重试；返回SSL_ERROR_WANT_WRITE表示socket写缓冲区满，应该等可写事件后重试。直接当成失败杀掉连接，长连接就废了。

解决：同步场景下就用阻塞socket加超时，省去状态机。异步场景下封装一个handle_ssl_retry函数，遇到WANT_READ/WANT_WRITE时返回“稍后再试”，而不是立刻关闭SSL对象。

4.4 现象：证书校验通过，但主机名完全不匹配

内网测试环境里，给服务器配的证书CN是localhost，代码里填入的hostname是内网IP。SSL_get_verify_result返回X509_V_OK，说明证书链本身没问题，但业务里还是握手失败。

原因：OpenSSL在更高版本把主机名校验从SSL_set_verify回调挪到了内部逻辑，需要显式设置SNI和hostname。如果只设了SSL_set_fd，没设SSL_set_tlsext_host_name，主机名校验就会跳过，证书校验只验证链，不验证域名。

解决：每个连接初始化时，务必调用SSL_set_tlsext_host_name(ssl, hostname.c_str())。如果hostname是IP地址，还要确认证书的SAN（Subject Alternative Name）里包含这个IP，光有CN已经不够了，现代浏览器和OpenSSL都要求SAN有对应项。

4.5 现象：响应读回一半，程序就认为读完了

服务端返回大JSON，SSL_read一次没读完，代码判断到\r\n\r\n就退出，导致body截断。

原因：\r\n\r\n只表示头部结束，不代表body结束。body长度由Content-Length或chunked终止符决定，和头部空行没有直接关系。

解决：上文is_response_complete判断法就够用。注意Content-Length也可能在头部还没完整到达时就出现在raw里，这时要保证先解析完头部，再按长度比较。更稳妥的做法是封装一个响应累积器，收到数据后先尝试解析Content-Length，解析不到就继续读，收到并解析到了就严格等满字节数。

5. 复用同一TLS连接连续POST：把握手成本降到一次

每次请求都重新socket、握手、挥手，慢不只是网络延迟，TLS握手本身要2个RTT，再加上证书校验，一次请求多出几十毫秒很正常。高频调用场景下，复用TLS连接能把这部分开销彻底去掉。

这里先明确一个边界：TLS连接复用和HTTP keep-alive是两回事。前者指同一个SSL*对象上多次调用SSL_write/SSL_read；后者指HTTP头部的Connection字段。代码要两个都做，才能在一个TCP连接上连发多个POST。

class PostSession { public: bool connect_to(const std::string& host, int port, const std::string& path); bool post(const std::string& path, const std::string& body, std::string& response); void disconnect(); private: SSL* ssl_ = nullptr; int fd_ = -1; }; bool PostSession::post(const std::string& path, const std::string& body, std::string& response) { std::string request = build_post_request( "example-host", path, "application/json", body); if (SSL_write(ssl_, request.data(), (int)request.size()) <= 0) { return false; } std::string raw; char buf[8192]; int received = 0; while ((received = SSL_read(ssl_, buf, sizeof(buf))) > 0) { raw.append(buf, received); if (is_response_complete(raw, content_length_of(raw))) { break; } } if (received < 0) { return false; } response = raw; return true; }

注意一个细节：SSL_read在上一次响应读完之后，socket缓冲区里可能残留了下一个响应的数据，必须先按Content-Length精确截断本次响应的边界，多余的数据留给下一次SSL_read读。如果把缓冲区一次全塞进response，下一次请求的响应就少了开头。

另外，服务端可能主动断开空闲连接。如果SSL_read返回0，说明对端发了close_notify，这时不能再复用这个SSL*，应该重连后重发请求。我的做法是在封装里记录一个healthy_标志位，任何一次读写失败就把标志置为false，下次调用前检查。

从那以后我每次做TLS长连接，都会强制走一遍这个流程：先确认响应边界判断函数覆盖了Content-Length和chunked两种格式，再验证SSL_read返回0时能触发重连，最后才把会话对象放进连接池。前面四次翻车的经验，其实都集中在“没有精确控制字节边界”和“没有区分SSL错误与socket错误”两件事上，希望帮到你。

本文还有配套的精品资源，点击获取