1. HTTP持久连接（Keep-Alive）概述
http协议最初设计为无状态、短连接模式，即每个请求/响应对都会建立并关闭一个新的tcp连接。然而，这种模式在发送大量小请求时效率低下，因为频繁的tcp连接建立和关闭会带来显著的开销。为了解决这一问题，http/1.1引入了持久连接（persistent connections）机制，通常称为“keep-alive”。
通过持久连接，客户端可以在同一个TCP连接上发送多个HTTP请求，而无需在每个请求后重新建立连接。这显著减少了网络延迟和服务器负载，提高了通信效率。客户端通常通过在请求头中包含Connection: keep-alive来表明其希望保持连接的意图，而服务器则通过在响应头中包含相同的Connection: keep-alive来确认。
2. 客户端请求协议与连接管理
在实现HTTP持久连接时，客户端正确构建HTTP请求至关重要。原始示例代码中存在两个关键问题：
2.1 HTTP协议版本误用
示例代码中使用了GET /" + x + " HTTP/2\r\n。这是一个常见的误区。HTTP/2是一个与HTTP/1.x完全不同的二进制协议，它引入了多路复用、头部压缩等高级特性，并且通常通过ALPN（Application-Layer Protocol Negotiation）在TLS握手阶段进行协商。简单地将协议字符串从HTTP/1.1改为HTTP/2并不能使请求成为有效的HTTP/2请求，反而会导致服务器无法正确解析。
对于基于文本的请求，我们应该使用HTTP/1.0或HTTP/1.1。HTTP/1.1是当前广泛使用的版本，默认支持持久连接。
2.2 正确构建HTTP/1.1请求
为了请求持久连接，客户端应在HTTP/1.1请求头中明确包含Connection: keep-alive。
以下是一个修正后的HTTP/1.1请求示例，旨在请求服务器保持连接：
// 修正后的HTTP请求字符串示例
String requestString = String.format(
"GET /%s HTTP/1.1\r\n" // 使用HTTP/1.1协议
+ "Host: %s\r\n"
+ "Connection: keep-alive\r\n" // 明确请求保持连接
+ "\r\n",
x, hostname
);
output.write(requestString);
output.flush();注意事项：
- HTTP/1.1是默认支持持久连接的，即使不显式声明Connection: keep-alive，服务器也可能默认保持连接，但这取决于服务器的配置。显式声明有助于清晰表达客户端意图。
- \r\n是HTTP协议中标准的行结束符，用于分隔请求行、请求头和空行（表示请求头结束）。
3. 服务器响应与连接关闭机制
即使客户端发送了请求保持连接的头部，服务器仍然拥有最终决定权。原始示例中的关键问题在于服务器的响应：
HTTP/1.1 200 OK Content-Length: 2 Content-Type: text/plain Connection: close // 服务器明确表示将关闭连接 Accept-Ranges: none
服务器在响应头中明确包含了Connection: close。这意味着服务器在发送完当前响应后，将立即关闭TCP连接。一旦连接被关闭，客户端在该Socket上尝试发送后续请求将失败，或者在读取响应时遇到连接重置/EOF。这解释了为什么示例代码在打印完响应后，reader.readLine()会阻塞或返回null，导致程序停在h2和h3之间。
核心要点：
- 服务器拥有最终控制权： 客户端请求Connection: keep-alive只是一个建议，服务器可以忽略它并决定关闭连接。
- Connection: close是明确指令： 当服务器返回Connection: close时，客户端必须遵守，并在读取完当前响应后关闭Socket。
4. 嵌入式系统中的HTTP连接特性
针对ESP32这类微控制器，其HTTP服务器实现通常会考虑到资源（内存、CPU）和代码复杂度的限制。因此，它们可能不会完全支持HTTP/1.1的所有特性，包括持久连接。
- 资源限制： 维护持久连接需要服务器为每个连接分配资源（如文件描述符、内存缓冲区），这对于资源受限的嵌入式设备来说可能是一个负担。
- 代码复杂度： 实现完整的HTTP/1.1持久连接逻辑（例如，处理超时、并发请求队列）比实现简单的短连接模式要复杂得多。
- 默认行为： 许多简化的HTTP栈可能默认在每个请求后关闭连接，以简化实现并释放资源。
因此，当与ESP32等嵌入式设备通信时，即使客户端请求持久连接，也应预料到服务器可能选择关闭连接。
5. 处理多请求的策略与注意事项
基于上述分析，处理在同一Socket上发送多个HTTP请求需要灵活的策略：
5.1 策略一：每次请求建立新连接（如果服务器不支持Keep-Alive）
如果服务器明确表示不支持持久连接（例如，响应中包含Connection: close），那么最稳妥的方法是每次请求都建立一个新的Socket连接。
public HttpClient() throws UnknownHostException, IOException, InterruptedException {
// ... 初始化URL和hostname ...
for(int i=1; i<50; i++) {
String x = i%2==0 ? "on" : "off";
// 每次请求都建立新的Socket连接
Socket currentSocket = new Socket(hostname, 80);
PrintWriter output = new PrintWriter(currentSocket.getOutputStream());
InputStream input = currentSocket.getInputStream();
BufferedReader reader = new BufferedReader(new InputStreamReader(input));
String requestString = String.format(
"GET /%s HTTP/1.1\r\n"
+ "Host: %s\r\n"
+ "Connection: close\r\n" // 客户端也明确表示将关闭，与服务器保持一致
+ "\r\n",
x, hostname
);
output.write(requestString);
output.flush();
String line;
while ((line = reader.readLine()) != null) {
System.out.println(line);
// 可以在此处检查服务器的Connection头，如果为keep-alive，则可以尝试复用
// 但如果服务器一直返回close，每次都关闭是更安全的做法
}
// 每次请求后关闭当前Socket
reader.close();
output.close();
currentSocket.close();
Thread.sleep(200);
}
}5.2 策略二：正确协商Keep-Alive（如果服务器支持）
如果服务器支持持久连接，客户端应：
- 发送Connection: keep-alive的HTTP/1.1请求。
- 读取服务器响应。
- 检查服务器响应头： 如果响应中包含Connection: keep-alive，则可以复用当前Socket发送下一个请求。如果包含Connection: close，则必须关闭当前Socket并为下一个请求建立新连接。
5.3 注意事项
- 始终检查服务器响应头： 这是判断连接是否可以复用的最权威依据。
- 理解HTTP协议版本： 避免混淆HTTP/1.x和HTTP/2。对于简单的Socket编程，通常应使用HTTP/1.1。
- 考虑使用高级HTTP客户端库： 对于复杂的HTTP通信，推荐使用成熟的HTTP客户端库（如Apache HttpClient, OkHttp, Java 11+的java.net.http.HttpClient），它们能自动处理连接池、Keep-Alive协商、重试、错误处理等复杂逻辑，大大简化开发。
- 针对嵌入式设备： 在与资源受限的嵌入式设备通信时，应查阅其HTTP服务器的文档，了解其对持久连接的支持情况。如果文档不明确，通过实际测试来验证其行为。
总结
在同一Socket上发送多个HTTP请求需要客户端和服务器之间的协作。客户端应使用正确的HTTP协议版本（通常是HTTP/1.1）并明确请求持久连接（Connection: keep-alive）。然而，服务器的响应（特别是Connection: close头）是决定连接是否能被复用的最终依据。在与ESP32等嵌入式设备通信时，由于其资源和实现复杂度的限制，服务器可能更倾向于在每个请求后关闭连接。理解这些原理并根据服务器的实际行为调整客户端策略，是实现高效、健壮HTTP通信的关键。对于生产环境，强烈建议使用成熟的HTTP客户端库来处理这些底层细节。
