1. 从裸Socket到HTTP：这一篇到底在解决什么问题
接着上一篇的Linux网络编程往下聊。上一篇我们还在折腾socket、bind、listen、accept这一套，能写一个TCP回显服务，也能自己写客户端连上去收发数据。但是说句实在话，那些裸socket代码放到真实项目里，离能干活还差得远。你写个聊天程序用自定义协议没问题，但你要是想给自己的程序加一个“联网更新”“提交数据到服务端”的功能，最省力的路子绝对不是自己设计一套二进制协议，而是直接走HTTP或者HTTPS。
这个系列写到这里，题目是“http、https”，核心就一句话：把应用层最常用的两个协议讲透，让你在Linux下写的程序能真正跟互联网上的服务对话。具体来说，这篇会覆盖这么几件事：HTTP的报文结构长什么样、请求和响应的关键字段是什么意思、怎么用socket手动拼一个HTTP请求、HTTP连接复用的机制是什么、HTTPS到底比HTTP多做了哪些事、TLS握手的过程怎么抓包验证，还有最后一部分是我踩过的坑和排查思路。
适合谁看呢？如果你已经会用socket写基本的TCP客户端和服务端，但一碰到HTTP就只会调库、不知道底层发生了什么，这篇就是给你准备的。如果你在做嵌入式、做网关、做爬虫、做服务端开发，90%的场景都绕不开这两个协议。看完这篇之后，你再看curl的-v输出、看wireshark里的TLS握手、看nginx日志里的502，脑子里会有一个清晰的地图，不再是一团浆糊。
我自己当年从socket跳到HTTP时最大的困惑是：socket收发的是字节流，HTTP也是字节流，那区别到底在哪？答案其实很简单，HTTP是定义了“字节长什么样”的格式，socket是负责把字节送过去的通道。这篇就从“格式”入手，一层一层剥开。
2. HTTP协议核心拆解：请求、响应、以及最容易忽略的细节
2.1 请求报文的三段式结构
HTTP请求说到底就是一段文本，它由三个部分组成：请求行、请求头、请求体。每一部分的切换靠的是回车换行符，也就是\r\n。注意这里必须是CRLF，不是Linux下习惯的LF。我见过不少新手在手动拼HTTP包的时候用\n结尾，结果服务端解析直接出问题，这是一个非常经典的坑。
一个最基础的GET请求报文长这样：
GET /index.html HTTP/1.1\r\n Host: www.example.com\r\n User-Agent: Mozilla/5.0\r\n Accept: */*\r\n \r\n第一行是请求行，包含方法、路径、协议版本。方法常见的有GET、POST、PUT、DELETE，路径是请求的资源路径，协议版本有HTTP/1.0、HTTP/1.1、HTTP/2。中间是请求头，每一行是“键: 值”的格式，注意冒号后面有一个空格。最后空一行表示请求头结束，如果还有请求体，空行之后就跟着请求体。
我最想强调的是Host这个字段。在HTTP/1.1里它是必须的，因为一台服务器上可能跑着多个域名，服务器需要用Host字段判断你要访问哪个虚拟主机。你在浏览器地址栏输入一个网址，浏览器会自动把域名填进Host头里，但如果你自己用socket写客户端，忘记带这个头，就会得到一个400错误。
2.2 响应报文的结构与状态码语义
响应的结构和请求基本对称：状态行、响应头、空行、响应体。状态行长这样：
HTTP/1.1 200 OK\r\n Content-Type: text/html\r\n Content-Length: 1234\r\n \r\n <!DOCTYPE html>...这个200 OK就是状态码加短语。状态码的语义值得烂熟于心，因为排查问题全靠它。2xx是成功，最常见的200是一般成功、204是成功但没内容；3xx是重定向，301是永久重定向、302是临时重定向、304是命中缓存没修改；4xx是客户端错误，400是请求格式错误、401是未认证、403是禁止访问、404是不存在、429是请求太频繁；5xx是服务端错误，500是内部错误、501是未实现、502是网关拿到上游坏响应、503是服务不可用、504是上游超时。
有个细节我想多说一句：Content-Length和响应体的关系。HTTP协议在TCP之上，TCP是流式的、没有边界。服务端怎么知道响应体在哪结束？靠的就是Content-Length这个头。你读响应时读到Content-Length个字节就说明这次响应结束了。还有另一种方式是分块传输编码，响应头里有Transfer-Encoding: chunked，这时候数据是一段一段发过来的，每段前面有十六进制长度。这些机制就是为了在“没有边界的字节流”上切出“有边界的消息”。
2.3 从TCP视角理解HTTP：一次完整请求的数据流动
从socket层面看，一次HTTP请求的完整数据流是这样的：先TCP三次握手建立连接，然后客户端把请求报文作为数据发给服务端，服务端解析后把响应报文作为数据发回来，最后TCP四次挥手关闭连接。在HTTP/1.0时代，默认是请求一次关一次连接，所以每一次请求都要重新三次握手再四次挥手，效率很低。
HTTP/1.1引入了Keep-Alive机制，连接默认不关闭，可以在同一个TCP连接上串行发多个请求。这就像你同一个电话线，聊完一件事不用挂断，直接聊下一件事。从Linux编程角度看，这意味着你的TCP连接可以复用，少了反复建连的开销，对高并发场景的优化非常大。
关于连接复用，我再往下展开一下。Keep-Alive下，客户端发完一个请求、收到响应之后，连接保持在CLOSE_WAIT或者ESTABLISHED状态，下一次请求直接从这个连接发出去。服务端这边通过Keep-Alive头或者默认配置决定连接保活多久。这里有个关键点：既然连接不关闭，那服务端和客户端就都要靠Content-Length或者chunked来划分消息边界，否则双方都不知道哪是头哪是尾。所以HTTP的边界机制不只是一个解析问题，它直接决定了连接能不能复用。
3. Linux下手写HTTP客户端：从socket到完整请求
3.1 为什么非要手写一遍
现在写程序基本都有现成的库，C语言有libcurl，Python有requests，Java有OkHttp。那我还建议你手动用socket写一遍HTTP请求，原因很简单：调库的时候，你看不到背后的数据长什么样。出了问题——比如服务端返回了一个unexpected status 502、比如连接被重置、比如响应解析到一半卡死了——如果你不知道正常情况下的字节流应该是什么样，排查起来就像闭着眼修电路。
手动写一遍还有另外一层价值：当你需要做性能优化、做协议调试、做嵌入式开发（很多RTOS上没有完整的HTTP库）、或者理解代理和网关的工作原理时，你对协议的掌控力会完全不同。这不是让你在生产环境手搓HTTP，而是让你“见过猪跑”。
3.2 完整代码：socket发起GET请求
下面这段代码是我在Linux下测试过的，用最基本的socket API发起一次HTTP GET请求，然后把响应体打印出来：
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #define BUFFER_SIZE 4096 int main(int argc, char *argv[]) { if (argc < 3) { fprintf(stderr, "Usage: %s <host> <path>\n", argv[0]); return 1; } const char *host = argv[1]; const char *path = argv[2]; struct hostent *server = gethostbyname(host); if (server == NULL) { perror("gethostbyname"); return 1; } int sockfd = socket(AF_INET, SOCK_STREAM, 0); if (sockfd < 0) { perror("socket"); return 1; } struct sockaddr_in server_addr; memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; memcpy(&server_addr.sin_addr.s_addr, server->h_addr_list[0], server->h_length); server_addr.sin_port = htons(80); if (connect(sockfd, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) { perror("connect"); close(sockfd); return 1; } char request[1024]; snprintf(request, sizeof(request), "GET %s HTTP/1.1\r\n" "Host: %s\r\n" "User-Agent: my-http-client/1.0\r\n" "Connection: close\r\n" "\r\n", path, host); if (send(sockfd, request, strlen(request), 0) < 0) { perror("send"); close(sockfd); return 1; } char response[BUFFER_SIZE]; ssize_t n; while ((n = recv(sockfd, response, sizeof(response) - 1, 0)) > 0) { response[n] = '\0'; printf("%s", response); } close(sockfd); return 0; }编译运行：
gcc -o http_get http_get.c ./http_get www.example.com /index.html说几个这里的细节。gethostbyname是老的DNS解析接口，实际生产环境我更推荐用getaddrinfo，它支持IPv6并且是线程安全的。请求里我加了Connection: close，这是告诉服务端：响应完就断开，这样我的程序只要读到EOF就说明响应结束了。如果你想做Keep-Alive复用，就不能这么干，得靠Content-Length来切边界。上面这段代码只是个起点，核心是让你看到一次请求的完整链路。
3.3 解析响应的关键细节：Content-Length与chunked
我们用socket收响应的时候，recv返回的数据可能是分段的：第一次收到了响应头和一部分响应体，第二次收到剩下的响应体，这完全看网络状况。所以解析HTTP响应的标准姿势是：先收到一段数据，按\r\n\r\n切出响应头，解析里面的Content-Length，然后继续recv直到累计收到那么多字节为止。
如果是Transfer-Encoding: chunked，那就是另一种玩法。每一段数据以一行十六进制数字开头，表示这一段有多少字节，然后是数据本身，最后是一行0\r\n\r\n表示结束。我在实际解析中还得处理一种情况：某个分段的长度行和数据可能不在同一个recv包里到达，所以解析器必须是“流式”的——你把数据积累到缓冲区，一遍遍地尝试解析，而不是等所有数据到齐了一次性解析。这一步做不好，数据量稍微大一点就会出现解析不全的问题。
3.4 用系统工具对照验证
写完了代码，最好用工具验证一下。最方便的就是curl：
curl -v http://www.example.com/index.html-v会打印详细过程，包括TCP连接、发送的请求头、收到的响应头、TLS相关信息。你拿curl的请求头和我们手写的代码输出对照一下，马上能看出自己的请求少了哪些字段、格式有没有问题。
对比系统工具的输出特别重要，因为很多HTTP解析问题就是“格式不对但不报错”。比如有些服务器对Host头大小写不敏感，有些敏感；有些服务器接受LF换行，有些不接受。你手写代码时最稳妥的做法是严格按规范来：CRLF换行、Host头必须有、头名称用标准写法。
4. HTTPS与TLS握手：加密层到底加在了哪里
4.1 TCP与HTTP之间多了一层TLS
HTTPS不是另一种协议，它就是HTTP跑了TLS。这个“跑”是什么意思？从网络分层看，TLS插在TCP和HTTP之间。TCP负责把字节流可靠地送到对面，TLS负责把这层字节流加密。你在Linux下看socket层面，代码跟TCP没有本质区别——依然是connect、send、recv这一套——只是数据在发送前被TLS库加密了，接收后要先解密再交给HTTP解析器。
用一个生活化的类比来说：HTTP是写在明信片上的内容，任何人经手都能看到；HTTPS是把明信片塞进一个带锁的盒子里，只有收发双方有钥匙。TCP还是那个快递员，快递员不知道盒子里装的具体内容，他只负责把盒子从一个地址搬到另一个地址。
HTTPS要解决的核心问题有三个：内容保密、完整性验证、身份验证。内容保密靠加密算法，完整性靠MAC校验，身份验证靠数字证书。这三个问题对应了TLS握手中要完成的一系列密码学操作。很多人只记得“握手要交换密钥”，实际上握手还承载着证明“你是你”这件事。
4.2 握手流程拆解：从ClientHello到Finished
标准TLS 1.2握手大致是这么几步：
第一步，客户端发送ClientHello，里面带着客户端支持的TLS版本、加密套件列表、一个随机数。第二步，服务端收到后回复ServerHello，选定加密套件、给出自己的随机数，同时会带上自己的证书（Certificate消息）。第三步，客户端验证证书——检查证书是否由受信任的CA签发、域名是否匹配、是否过期、是否被吊销。验证通过后，客户端生成一个新的随机数作为预主密钥（pre-master secret），用服务端证书里的公钥加密后发给服务端。第四步，双方用ClientHello随机数、ServerHello随机数、预主密钥一起推导出会话密钥。第五步，双方各自发Finished消息，里面包含前面所有握手消息的摘要，用于确认双方协商的密钥是一致的。之后就开始正常的数据加密传输。
这里的关键知识点是TLS使用了“混合加密”：握手阶段用非对称加密（RSA或者ECDHE）来安全地传递对称密钥材料，数据传输阶段用对称加密（AES等）来加密实际内容。为什么这么设计？因为非对称加密慢但安全，对称加密快但密钥分发困难。两者一结合，既安全又高效。
4.3 证书验证链与SNI：两个容易忽略的细节
证书验证这块，实际踩坑最多。一个正常的证书链是这样：服务器证书（叶子证书）→ 中间CA证书 → 根CA证书。客户端必须把整条链验证完，最终找到一个在系统信任库里的根证书才算通过。很多人部署HTTPS时只往服务器上放了叶子证书，中间证书没配，结果浏览器提示不安全，但 curl 有时候又能通，因为curl做了不同的链拼接处理。在Linux下排查这类问题，可以用openssl直接看：
openssl s_client -connect example.com:443 -servername example.com-servername参数触发SNI（Server Name Indication）。SNI是TLS协议里的一个扩展，因为一台服务器可能托管多个域名的HTTPS服务，而TLS握手时服务器还没看到HTTP层的Host头，所以必须在TLS握手阶段就告诉服务器我访问的是哪个域名。这个字段就放在ClientHello里。你写代码时如果用socket直连443端口，手写TLS握手，需要正确填写SNI字段，否则服务器可能返回默认证书，验证就会失败。
4.4 Linux命令行快速验证HTTPS连通性
在Linux下调试HTTPS服务，我最常用的三个命令是curl -v、openssl s_client、openssl s_server。curl适合端到端验证，openssl s_client适合检查证书和握手细节。比如要看一个网站用的TLS版本和加密套件：
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_2输出里会有Protocol和Cipher字段，一眼就能看到协商结果。如果你要写一个自己的HTTPS客户端，流程就是先TCP连接，再初始化SSL库（比如OpenSSL的SSL_CTX、SSL_new、SSL_connect），之后用SSL_read和SSL_write代替read和write。从socket编程的角度看，你只需要把“收发字节”的入口替换成加密层提供的接口，剩下的HTTP报文逻辑完全不用变。
5. 连接复用与性能实践：Keep-Alive和连接池的底层逻辑
5.1 Keep-Alive到底省了什么
上面已经提过，HTTP/1.0默认每个请求都新建连接。新建一次TCP连接意味着一次三次握手，如果走HTTPS还要额外加一次TLS握手，其中一个RTT用于证书交换和密钥协商——实际算起来可能三四个RTT就没了。而在局域网里一次RTT也就一毫秒，跨地域公网可能要几十毫秒。所以连接复用对HTTP性能的影响非常显著。
HTTP/1.1的Keep-Alive机制，服务端和客户端都默认开启。从Linux编程的视角看，Connect之后不要因为一次请求结束就close，而是维持socket打开，在同一个socket上继续发送下一个请求。你的程序需要维护一个“连接池”，池子里放着一堆空闲的、已经建立好的TCP连接。发请求时优先从池子里取一条，用完再放回池子，而不是每次都重新connect。
5.2 连接池的取舍与坑
连接池不是越大越好。每个连接都会占用文件描述符，也占用服务端的资源。Linux下默认进程级文件描述符限制是1024，你可以用ulimit -n查看。如果你的程序需要大量并发，连接池还没有复用起来，fd先被打爆了，这是很现实的坑。我自己的经验是，连接池大小通常按照服务的QPS和单请求耗时的乘积来估算：池子里的连接数大致等于“每秒请求数 × 单请求平均耗时”，在这个值附近浮动。服务端那边限制的是最大并发连接数，如果连接数本身就打满，Keep-Alive反而会占用大量空闲连接，拖垮服务。
另外有一个很隐蔽的问题：连接池中的连接不是永远有效的。服务端可能空闲超时后主动关闭了连接，而客户端并不知道，等到用这条连接发请求时会收到Connection reset by peer。所以你的连接池必须处理“死连接”的检测。常见做法是发请求前检查这条连接的空闲时间，超过阈值（比如30秒）就主动关闭重连；或者发请求后遇到断连错误就自动重试一次，用新连接再发一遍。这个“自动重试一次”的逻辑虽然只有几行代码，但如果没有它，线上服务会不定时出现各种诡异的偶发报错。
5.3 HTTP/2的多路复用：一个连接上并行多个请求
讲到连接复用就不能不提HTTP/2。HTTP/1.1的Keep-Alive虽然复用了连接，但请求还是串行的——必须等第一个响应回来才能发第二个请求，这就是“队头阻塞”。HTTP/2在TCP连接之上引入了一个“流”的抽象，一个连接里可以同时跑多个请求，每个请求是一个流，流的标识符区分彼此。
从Linux编程视角看，HTTP/2依然跑在TCP上，但报文传输方式变了：HTTP报文被切分成一个个二进制帧，多路复用多个流，每个帧带有流ID。这就是为什么现在很多服务端/客户端库在处理HTTP/2时有完全不同的报文解析逻辑。如果你只是写普通的应用，不用关心帧格式细节，但要理解一个现象：HTTP/2之下，单个TCP连接的并发能力强很多，这也是为什么现代浏览器对同一域名通常只开少数几条连接。
6. 调试与抓包：看清HTTP和HTTPS的每一个字节
6.1 tcpdump抓HTTP流量：最直接的验证方式
手写网络程序最大的难题是“看不见数据”。很多你以为的协议细节，抓到包一看就全明白了。Linux下的tcpdump就是干这个的。比如你想看本机到某个网站的全部TCP流量：
sudo tcpdump -i any host www.example.com and port 80 -A-A参数会在输出里同时打印ASCII内容，HTTP请求和响应报文直接就能看到。我强烈建议你抓一次自己的代码发出的HTTP请求，看看报文和服务端响应到底长什么样。你会亲眼看到三次握手的SYN、SYN-ACK、ACK，看到请求行和Host头，看到响应头里的Content-Length。很多东西看过一眼比读十遍文档都清楚。
抓HTTPS时，-A输出的就是密文了，看不到明文。如果你需要分析HTTPS的应用层内容，有两个办法：一个是在客户端设置SSLKEYLOGFILE环境变量，让浏览器或curl导出TLS会话密钥，然后wireshark导入这个文件就能解密；另一个是你在自己写的程序里给SSL库设置回调，把协商出来的密钥dump出来。这两个方法的核心都是同一个：拿到会话密钥，才能解开TLS记录层的密文。所以“HTTPS明文捕获”这件事，对握着密钥的一方来说是可以做到的，对中间人则不行——这就是TLS保密性的意义。
6.2 curl -v输出逐行解读
curl -v的输出是我们日常排查中最常接触的。我拿一段典型的输出来说明它每一行代表什么：
* Connected to www.example.com (93.184.216.34) port 443 (#0) * TLSv1.3 (IN), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 * ALPN: server accepted h2 * GET /index.html HTTP/1.1 * Host: www.example.com第一段Connected告诉你TCP已经连上了，IP和端口都写出来了。中间带TLS前缀的是握手过程。SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384这句话有两层信息：TLS版本是1.3，加密套件是非对称部分是ECDHE、对称部分用AES256-GCM做认证加密。之后ALPN: server accepted h2说明双方协商用HTTP/2。再往下就是HTTP请求头本身。遇到握手失败、证书问题、协议不匹配时，这个输出就是第一现场。我每次排查HTTPS的问题，第一步绝对是curl -v而不是去翻代码。
6.3 Wireshark过滤器速查
抓包工具里Wireshark的图形界面比tcpdump更直观。几个常用的过滤器我列一下：
http 显示所有HTTP报文 tls.handshake.type == 1 显示所有ClientHello tls.handshake.certificate 显示证书消息 tcp.port == 443 只看443端口 http.response.code == 500 只看返回500的响应抓包的时候我记得取消勾选“Enable MAC name resolution”和“Enable transport name resolution”，不然各种IP被解析成奇怪的名字，过滤不好写。另外如果要分析TLS，建议开启Wireshark的TLS解密功能，导入SSLKEYLOGFILE文件，这样抓到的包能直接看到解密后的HTTP明文，方便对照请求和响应。
7. 常见问题与排查技巧实录
7.1 502 Bad Gateway：网关错误的7种可能
“unexpected status 502 bad gateway”这个报错，在代理场景、网关场景、Go的reverseproxy、Java的gateway里都非常常见。502的意思是你的程序作为网关/代理，向上游服务器发请求时收到了非法的或者无法处理的响应。我整理一下碰到过的常见原因：
- 上游服务进程崩溃或没有监听端口。最典型，连接直接被拒绝。
- 上游服务卡死或响应超时，网关等不到响应直接返回502。
- 上游返回了非HTTP格式的响应，网关解析不了。比如上游是个裸socket服务，不发HTTP报文，网关就会懵。
- 上游返回了HTTP/1.0或者HTTP/0.9格式的报文，网关不支持。
- 网关配置的Host头或者路径不对，上游返回了400/404，但网关注入的代码认为这是异常，直接转成502。
- TLS证书验证失败，网关和上游之间没有信任关系。
- 上游的Keep-Alive连接已经断开但网关不知道，复用了一个死连接导致请求发不出去。
排查这类问题的通用步骤是：先看网关日志，确认报错的时间点和涉及的上游地址；再用curl直接打上游地址，看能不能正常返回；如果curl都打不通，问题大概率在上游不在网关；如果能打通，再对比网关和curl请求的差异——Host头、路径、TLS配置、超时设置，一个一个对着查。
7.2 证书相关错误：not trusted、hostname mismatch、expired
证书类错误可能是HTTPS排错里出现频率最高的问题。certificate signed by unknown authority说明证书链顶端不在系统信任库里。解决方法是把中间证书或者根证书追加到信任库，或者用curl --cacert指定CA文件。hostname mismatch说明证书里的域名和访问地址对不上，要么是你访问的域名打错了，要么是证书签发时配的域名不对。certificate expired就是字面意思，证书过期了。
从排查效率的角度，我最常用的命令就是这个：
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates一条命令能同时看证书的签发者、所有者、有效日期，比打开浏览器点好几层菜单快得多。再配合-verify_return_error参数，openssl会直接把链验证的错误打出来。
7.3 Connection reset by peer与EOF的差别
这两个报错在网络编程里经常把新手搞晕。Connection reset by peer意味着对方收到你的数据后，直接回了RST包，这是“异常关闭”。常见原因是服务端处理不过来主动杀掉连接，或者协议不对导致服务端无法理解你的请求直接断开。EOF则是正常对端关闭写端，再读就是0字节，这通常是连接正常结束的标志。
判断这两者的实际方法很简单：你发HTTP请求，如果收到Connection reset by peer，大概率是请求格式有问题或者服务端拒绝了你；如果正常收到响应但继续读时遇到EOF，那多半是服务端按Connection: close把连接关掉了。遇到reset时，先用curl打同一个地址，如果curl也reset，再考虑是不是服务端防火墙、WAF拦截、或者协议头有问题。如果curl正常而你的代码reset，那就仔细对比你的请求报文和curl发出去的报文差异。
7.4 本地抓一个HTTPS包的完整实战
这个案例是我之前排查一个客户端程序“偶尔连接超时”时做的。步骤是完全可复现的：
第一步，在客户端环境设置密钥导出：
export SSLKEYLOGFILE=/tmp/tls_keys.log第二步，跑一次复现，让客户端程序正常访问目标HTTPS服务。第三步，抓包：
sudo tcpdump -i any host example.com and port 443 -w /tmp/https.pcap第四步，打开Wireshark加载pcap文件，进入“Edit → Preferences → Protocols → TLS”，在(Pre)-Master-Secret log filename里填入 /tmp/tls_keys.log。之后Wireshark会自动解密TLS流量，你就能在最上层看到HTTP/2的请求和响应，包括headers、body、cookie等。我那次就是通过这个方式发现流量在TCP层被中间设备截断了，而不是应用层的问题。整个过程思路简单，但能省的排查时间是以天计的。
8. 结语（个人经验）
这次把HTTP和HTTPS放在Linux网络编程系列里讲，我个人的体会是：这两个协议是“看得见摸得着”的，你完全可以用一把socket、一份文档、一个抓包工具，把从TCP连接到HTTP报文再到TLS握手的全链路亲手跑通一遍。这个底子打下来，后面看什么nginx配置、看什么网关源码、看什么微服务调优，都不会觉得虚。
最后的建议是：如果你照着这篇文章写了一个socket版的HTTP客户端，下一步可以做两件事扩展它的能力。第一件是加一个简易的响应解析器，支持Content-Length和chunked，然后把这个客户端改造成支持Keep-Alive连接复用。第二件是用OpenSSL把HTTP客户端升级成HTTPS客户端，加入证书验证和SNI。这两件事做完，你的Linux网络编程基本功就算真正过了HTTP这道关。之后不管是看libcurl源码还是自己写高性能代理，心里都会有了底气。
