上一篇我们把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呢就是在装包裹之前先把物品放进一个带密码锁的保险箱里再交给快递。下表是常见区分对比项HTTPHTTPS默认端口80443传输层之上直接基于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; charsetutf-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表示重定向典型304Not Modified用于缓存4xx表示客户端错误最常遇到400语法错误、401未认证、403无权限、404找不到、405方法不允许、429请求过多5xx表示服务器错误其中502Bad Gateway表示网关或者代理从上游收到了无效响应504Gateway 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-aliveTCP连接可以被多个请求复用。这样同一个连接上会连续传递多个响应于是问题来了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安全地算出同一个会话密钥。双方发送ChangeCipherSpecTLS1.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是为了支持SNIServer 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版本正常。这套方法论救了我很多次希望能帮你也少踩几个坑。
