本地 A股量化数据库怎么设计？（方便做因子计算的表结构）
2026/9/26 12:50:32
上一篇我们把socket编程的基础过了一遍，从socket()、bind()、listen()到accept()，算是把TCP那套流程跑通了。但实际项目里，天天跟代码打交道的其实不是裸TCP，而是应用层的HTTP和HTTPS。无论是调第三方接口、写一个小服务，还是排查线上502，光会连socket还远远不够，你得懂HTTP/HTTPS的报文结构、连接管理和底层TLS握手到底做了什么。
这篇就接着上一次的话题，把Linux网络编程里的HTTP和HTTPS一次性讲透。内容包括：协议在TCP/IP里的位置、HTTP报文细节、keep-alive连接复用、用C语言手写一个HTTP客户端、TLS握手过程、openssl调试HTTPS、以及针对自己程序的抓包解密。适合刚把socket基础过完、准备深入应用层协议的读者，也适合那些写过一些接口但总在连接复用和证书问题上栽跟头的同学。
1. 先把HTTP/HTTPS放在协议栈里看清楚
很多人一上来就学"HTTP报文长什么样"，跳过了它在网络模型中到底站在哪一层，结果后面遇到"为什么这个报错"就懵了。我建议先从分层入手，理解HTTP和TCP的关系。
1.1 从printf到socket再到HTTP，数据是怎么一层层走下去的
在Linux里，你写一个printf，数据从用户态到内核态再到网卡，中间其实经过了多次封装。拿一次最简单的GET请求举例：应用层构造一段"GET / HTTP/1.1\r\n..."的字符串，交给socket去send()。send()只是把这段字符串交给TCP层，TCP会给它加一个TCP头，里面包含源端口和目标端口；再往下IP层加IP头，包含源IP和目标IP；再到链路层加帧头帧尾，最终变成一串比特流从网卡发出去。接收方反过来逐层剥离这些头部，最后在应用层拿到原始的HTTP报文。
这里的重点在于：HTTP协议本身不负责传输，它只是一套语义约定——客户端和服务器都懂这段字符串的含义。真正搬运数据的是TCP socket。所以我们学HTTP的时候，天然要结合socket API来理解发送和接收的边界。你看操作系统的头文件，socket层给的应用接口就是简单的read/write，没有任何HTTP相关函数，这就说明协议栈把HTTP完全留给了应用层去处理。
1.2 HTTP和HTTPS在协议栈中的位置，以及两者的本质差异
把上面这个过程画成一个协议栈，大概是这么个对应关系。用生活类比来说，TCP就像一家快递公司，负责把包裹从一个城市安全运到另一个城市，保证不丢件、不乱序；HTTP则是包裹上的单据格式，规定了怎么填地址、怎么写物品清单，让收发双方能读懂内容。而HTTPS呢，就是在装包裹之前，先把物品放进一个带密码锁的保险箱里再交给快递。
下表是常见区分：
| 对比项 | HTTP | HTTPS |
|---|---|---|
| 默认端口 | 80 | 443 |
| 传输层之上 | 直接基于TCP | 在TCP之上加了一层TLS/SSL |
| 数据 | 明文，任何节点都能读 | 加密，内容被TLS保护 |
| 身份认证 | 无 | 通过CA证书验证服务器身份 |
| 完整性校验 | 无 | TLS层有MAC/摘要校验 |
需要特别注意，HTTPS并不是一个新的传输协议，它依然跑在TCP之上，只是在应用层和传输层之间多插了一层TLS。你在代码里用socket连接443端口，TLS握手之后，发送出去的字节流就已经是被TLS加密后的内容，不再是明文HTTP格式。所以在抓包工具里，如果不解密，看到的是一堆不可读的字节。这个我在后面详细说。
2. 把HTTP报文和连接管理吃透
这一章是基本功。无论你用libcurl、requests还是在socket上拼报文，底层逻辑都是相同的。
2.1 HTTP报文格式：只有四个组成部分
HTTP报文分为请求报文和响应报文，结构上都是"起始行 + 头部字段 + 空行 + 可选的消息体"。
请求报文的起始行是请求行，格式为：方法 + 空格 + URI + 空格 + HTTP版本。比如：
GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Accept: */* Connection: close然后是多个头部字段，每行一个，冒号分隔。头部结束之后必须有一个空行（CRLF CRLF），再后面是消息体。GET请求一般没有消息体，POST请求才会在空行后带上要提交的数据。
响应报文的起始行是状态行，格式为：HTTP版本 + 空格 + 状态码 + 空格 + 原因短语。比如：
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close <html>...</html>这里有个特别容易踩的坑：很多人用socket接收数据时，直接判断"recv返回0就结束"。这在Connection: close时是对的，但如果是keep-alive连接，服务器读完请求后并不会关闭连接，返回0意味着连接断开，不代表完整响应已经读完。判断完整响应的正确依据是Content-Length或者分块编码，而不是连接是否关闭。这个我在2.4节详细讲。
2.2 方法、状态码、头部字段快速参考
方法常用这些：GET（获取资源）、POST（提交数据）、PUT（替换资源）、DELETE（删除）、HEAD（只要响应头）、OPTIONS（探测服务器支持的方法）、PATCH（部分更新）。实际开发中服务端路由往往只允许某几个方法，比如有的接口只放行POST，你用GET访问就会收到405。
状态码主要看分类：2xx表示成功；3xx表示重定向，典型304（Not Modified）用于缓存；4xx表示客户端错误，最常遇到400（语法错误）、401（未认证）、403（无权限）、404（找不到）、405（方法不允许）、429（请求过多）；5xx表示服务器错误，其中502（Bad Gateway）表示网关或者代理从上游收到了无效响应，504（Gateway Timeout）表示上游响应超时。
我遇到过最迷惑的一次：线上服务一直报502，但直接curl上游接口明明是好的。后来发现Nginx配的上游地址写成了服务的内网IP，而我的curl恰好从另一台机器访问，因为网络路径不同结果也不同。排查这种问题，固定思路是先用curl -v打到最后一个实际处理请求的服务上，绕过前面的网关，确认上游本身有没有问题。
头部字段里重点记几个：Host在HTTP/1.1里是必选的，虚拟主机靠它区分域名；Content-Length表示正文长度（字节数）；Transfer-Encoding: chunked表示正文是分块传输的，长度没法提前预知；Connection控制连接是否复用；Content-Type说明正文格式，比如JSON是application/json，表单是application/x-www-form-urlencoded。
2.3 用C语言的socket手写一个HTTP客户端
学习阶段我最推荐手写一次socket HTTP客户端，你会把整个请求/响应流程刻在脑子里。下面这个代码只做GET请求，依赖Connection: close来简单判断响应结束。
#include <stdio.h> #include <string.h> #include <stdlib.h> #include <unistd.h> #include <sys/socket.h> #include <netdb.h> #define BUFSZ 4096 int main(void) { const char *host = "example.com"; const char *request = "GET / HTTP/1.1\r\n" "Host: example.com\r\n" "Connection: close\r\n" "User-Agent: curl-like\r\n" "\r\n"; struct addrinfo hints, *res; memset(&hints, 0, sizeof(hints)); hints.ai_family = AF_INET; // IPv4 hints.ai_socktype = SOCK_STREAM; // TCP if (getaddrinfo(host, "80", &hints, &res) != 0) { perror("getaddrinfo"); return 1; } int fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol); if (fd < 0) { perror("socket"); return 1; } if (connect(fd, res->ai_addr, res->ai_addrlen) != 0) { perror("connect"); return 1; } freeaddrinfo(res); if (send(fd, request, strlen(request), 0) != (ssize_t)strlen(request)) { perror("send"); return 1; } shutdown(fd, SHUT_WR); // 告诉对端：我的数据发完了 char buf[BUFSZ]; ssize_t n; while ((n = recv(fd, buf, sizeof(buf) - 1, 0)) > 0) { buf[n] = '\0'; printf("%s", buf); } if (n < 0) perror("recv"); close(fd); return 0; }代码里有个关键动作：shutdown(fd, SHUT_WR)。这个调用表示"我已经没有数据要发了，你那边可以处理了，但仍可以继续给我发数据"。在HTTP请求中，GET没有消息体，请求头发送完就是结束，所以立即半关闭是合理的。服务器读到EOF就会知道请求结束了，然后开始返回响应，并在返回后主动关闭连接（因为我们带了Connection: close）。
这个版本简单粗暴，不处理粘包、不解析头部，但足够让你直观看到HTTP在socket上的样子。生产环境我建议直接用libcurl，它内部处理了重定向、超时、证书验证、连接复用一大堆问题，没必要自己造轮子。
2.4 HTTP连接复用：keep-alive带来的粘包挑战
早期的HTTP/1.0，每个请求都要新建TCP连接，请求完成后关闭。这样简单，但要反复三次握手、四次挥手，效率很低。HTTP/1.1引入持久连接，默认所有连接都是keep-alive，TCP连接可以被多个请求复用。这样同一个连接上会连续传递多个响应，于是问题来了：TCP是字节流，没有消息边界，你怎么知道一段响应到哪结束？
答案只能靠HTTP头里的长度信息。两种方式：如果响应头里有Content-Length，那么读完这个字节数就算一个完整响应；如果没有Content-Length但有Transfer-Encoding: chunked，就得按chunk格式每个块读一个长度再读数据，直到读到长度为0的块结束。实现上，你需要维护一个接收缓冲区，不断追加recv的数据，然后尝试解析：先找\r\n\r\n，拿到头部，解析长度，再判断缓冲区内是否已经有完整的正文。这套逻辑就是各种HTTP客户端的核心部分，自己实现时最容易出bug的就是缓冲区还不完整时去解析长度，结果读到一半。
我在一次压测中踩过这个坑：服务端开启了keep-alive，客户端用了一个简单的recv循环，以为每次recv返回的就是一个完整响应，结果第一个响应还差几百字节，第二个响应已经混进来了，解析全乱。从那之后我再也不敢在HTTP解析上偷懒，老老实实写缓冲区。
3. HTTPS与TLS：原理、调试和解密
3.1 HTTPS到底多做了什么，才会让你觉得它"安全"
HTTP是明文传输，任何在链路上的设备——路由器、交换机、代理——都能看到完整内容。你输入一个密码，密码就在网络上裸奔。HTTPS通过在TCP之上加TLS层，实现三个目标：机密性（内容加密，别人看不懂）、完整性（检测到数据是否被篡改）、身份认证（确认你连的确实是目标服务器，而不是冒充者）。
TLS用到了两类密码学机制：非对称加密（公钥/私钥）用来在握手阶段安全地交换密钥和验证身份；对称加密（比如AES）用来加密后续真正传输的数据，因为对称加密快得多。服务器需要先有一个证书，证书里包含服务器的公钥、域名、有效期限和CA的签名。浏览器/客户端收到证书后，会沿着证书链去验证签名是否可信、域名是否匹配、证书是否过期。只要有一环不过，连接就会失败。
3.2 TLS握手过程到底在做啥
以目前主流的TLS 1.3为例（TLS 1.2也类似），握手大致分这么几步：
- 客户端发送ClientHello：里面包含客户端支持的TLS版本、加密套件列表和一个随机数。
- 服务器返回ServerHello：选定一个加密套件和协议版本，带上自己的随机数。同时下发证书给客户端。
- 客户端验证证书（信任链、域名、有效期）。验证通过后，客户端和服务器用双方随机数再加上各自生成的临时私钥，通过某种密钥交换算法（如ECDHE）安全地算出同一个"会话密钥"。
- 双方发送ChangeCipherSpec（TLS1.2）或直接发送EncryptedExtensions、Finished等加密消息，确认后续流量都使用会话密钥加密。
这个过程你可以类比成两个人第一次见面：先互报身份（证书），然后当场约定一个只有他俩才知道的暗语（对称密钥），之后所有对话都用暗语进行。其中最关键的一点是，对话密钥并没有在网络中直接传，而是通过非对称加密的方式协商出来的，即使握手的中间过程被监听，也推导不出会话密钥。
3.3 用openssl s_client快速检查HTTPS接口
Linux下排查看HTTPS连接问题，openssl自带的s_client是神器。命令很简单：
echo | openssl s_client -connect example.com:443 -servername example.com-servername是为了支持SNI（Server Name Indication），同一台服务器上如果部署了多个HTTPS站点，需要它来指定你要访问的域名。输出里关键信息有：subject（证书归属）、issuer（签发者）、有效期、协商出的协议版本（TLSv1.3）和加密套件、最后有没有Verify return code: 0 (ok)。如果你看到Verify return code: 20 (unable to get local issuer certificate)，说明系统里没有配置该站点证书链上的根证书。
想快速看证书过期时间，可以配合处理管道：
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates这样能直接看到notBefore和notAfter。我在维护一台内网服务时就靠这个命令发现证书还差两天过期，赶紧换掉了，避免了一次线上事故。
3.4 给专门的HTTPS调试加个放大镜：SSLKEYLOGFILE解密
做开发时经常需要看自己程序发送的HTTPS请求内容，但抓包是密文。好在OpenSSL提供了一种机制导出会话密钥，配合Wireshark就能还原明文。操作步骤如下：
- 设置环境变量：
export SSLKEYLOGFILE=/tmp/keys.log - 启动你的客户端程序，正常跑一遍HTTPS请求。
- 在Wireshark里先设置一个过滤器，只捕获你访问的那台服务器的流量（比如
host example.com），保存pcap。 - 打开Wireshark，进入偏好设置，找到Protocols下的TLS，在"(Pre)-Master-Secret log filename"里填上
/tmp/keys.log。 - 重新打开pcap，你会发现被TLS加密的请求头、响应体都变成明文了。
注意，这个功能只能用来调试你自己的进程和你有权授权的服务。把SSLKEYLOGFILE放到别人的客户端环境里，或者用它对他人流量做解密，都属于越界行为，要避免。还有一点，只有支持SSLKEYLOGFILE的SSL库才有效，比如OpenSSL、libcurl编译时就默认支持；如果程序用了某个改版的TLS库，就不一定了。
4. 线上排查与踩坑实录：常见问题和技巧
这部分都是我在实际开发和运维中碰到过、也帮别人处理过的问题，整理成速查式内容，方便你遇到时直接对号入座。
4.1 服务一直报502 Bad Gateway，问题到底出在哪
502全称Bad Gateway，是网关或代理层收到的上游应答非法。常见在Nginx、Apache反代场景。现象是客户端访问Nginx时报502，但直接访问应用服务器可能正常。
排查思路按这个顺序来：
- 先看网关日志，确认它访问的上游地址和端口是什么。
- 用
nc -vz <上游IP> <端口>或telnet检查网络端口是否通。 - 直接对上游发起一次真实的HTTP请求，比如
curl -v http://上游IP:端口/health，看返回什么。 - 如果上游通了但返回异常，检查上游是不是没启动、进程崩溃、或者监听在了IPv6只听
::1而Nginx配的是IPv4。 - 如果上游进程正常但响应慢，看是不是超时，把Nginx的
proxy_read_timeout调大或排查上游慢查询。
我的经验是，大部分502其实不是网关坏了，而是上游服务进程挂了或者网络策略挡了端口。先绕过网关直连，定位速度会快很多。
4.2 405 Method Not Allowed：方法被禁止了
The specified HTTP method is not allowed for the requested resource.这个报错直译就是"你不该用这个方法来访问这个资源"。当你用POST请求一个只支持GET的资源，或者用GET请求一个只支持POST的接口，都会得到405。
用curl -X OPTIONS -i https://example.com/api/可以拿到服务器返回的Allow头部，列出它允许哪些方法。比如：
HTTP/1.1 204 No Content Allow: GET, HEAD, OPTIONS如果你的代码确实需要POST，但Allow列表里没有，就得改服务器路由配置。还有一种常见场景是跨域请求的预检OPTIONS：如果后端没有对OPTIONS放行，前端就会报405，但浏览器控制台里显示的是CORS错误，很多人绕了半天才发现是这个原因。
4.3 粘包与半包：用Content-Length正确切割HTTP响应
前面已经提到，keep-alive下TCP字节流没有边界。想写一个健壮的HTTP解析，最简单可靠的方式是维护一个动态增长的buffer。思路是：
- 每次recv到的数据先追加进buffer。
- 在buffer里搜索
\r\n\r\n，如果没有，继续recv。 - 找到头部结束后，解析头部里的
Content-Length，如果是chunked则解析chunk size。 - 判断buffer中从头部结束位置开始的长度是否大于等于Content-Length，如果不够继续recv。
- 完整的数据就取出来处理，剩余数据留在buffer里给下个响应用。
我自己写这类代码时的一个心得：先写一个"从buffer中提取一个完整HTTP消息"的函数，只依赖buffer当前内容，别依赖recv次数。这样逻辑可测、可复用。调试时加一条日志打印buffer长度和期望长度，粘包问题几乎一眼就能看出来。
4.4 证书校验失败和主机名不匹配
程序访问HTTPS时常见的报错有几种：self-signed certificate（自签名）、certificate has expired（过期）、certificate verify failed（某个环节校验失败，可能是证书链不完整）。还有一种很隐蔽的情况是证书没问题，但证书里的域名和你访问的域名不匹配，OpenSSL会报SSL: certificate subject name ... does not match host name。
正确处理方式是：如果服务器使用自签CA，就把这个CA证书加入系统的信任链（比如放到/etc/pki/ca-trust/source/anchors/然后执行update-ca-trust，或者Debian下放到/usr/local/share/ca-certificates/后update-ca-certificates）。在C代码里用libcurl时，可以设置CURLOPT_CAINFO指定CA文件。千万不要为了省事关掉CURLOPT_SSL_VERIFYPEER，除非是本地的临时调试。我还见过因为服务器没配好证书链、只发了叶子证书而导致客户端找不到中间证书，这种情况需要在服务器端把中间证书和叶子证书串成pem发下来。
5. 一些个人实际操作中的体会
这部分不算是教程，就是这些年跟HTTP/HTTPS打交道的一些真实感受。
5.1 写客户端我永远优先选libcurl
写客户端，优先用libcurl而不是自己拼socket。我手写socket HTTP客户端只是在第一次学习时写过，后来生产代码全用libcurl。不是因为socket不好，而是HTTP的边界处理、重连、超时和证书校验这些细节太容易出错了，库已经帮你踩平了路。
排查问题顺序上，我的习惯是先用curl -v和openssl s_client做黑盒测试，确定问题出在连接层、证书层还是业务层，再深入代码。这两种命令输出的信息量足够覆盖大部分情况。
5.2 抓包解密用完一定删掉密钥文件
关于抓包解密，SSLKEYLOGFILE确实好用，但它只适合调试自己的程序。我曾经在调试SDK时靠它看到了SDK内部所有请求细节，定位到一个诡异的Header拼接问题。但用完一定要删掉那个日志文件，因为里面装着可解密流量的密钥，等于你把所有HTTPS内容裸奔了。
保持连接复用和Content-Length解析，真的是每个网络程序员都该刻进DNA的东西。你可以不自己实现HTTP库，但一定得理解为什么需要它——因为线上各种妖魔鬼怪的问题，十有八九都跟"你以为你收到了完整消息，其实没有"有关。
说个我自己的习惯吧：写完一个网络请求相关模块，我都会先用黑盒命令验证一遍再写业务逻辑。遇到解析问题先怀疑字节流边界，再怀疑数据格式；遇到HTTPS报错先跑一遍openssl s_client确认证书和TLS版本正常。这套方法论救了我很多次，希望能帮你也少踩几个坑。