HTTP POST中的延迟来自哪里？ 我在C++中使用CPP NETLIB在异步模式下开发了Ubuntu 14.04的Web服务。服务需要响应消息体中通过HTTP POST发送的数据。当接收到大于1K的输入时，我发现性能很差，我想解决这个问题

如果数据相对较小，小于1K，服务器几乎会立即接收数据。如果数据超过1K，则在第一次调用异步读取回调函数之后，在第一块实际数据呈现给回调函数之前，会有大约1秒的延迟。在最初的延迟之后，随后的块几乎立即到达

我怎样才能消除这种延误？这是使用curl后测试数据的产物吗？如何轻松测试curl的性能以发布数据

您可以在github上找到解决问题的方法。以下是我用于将数据发布到服务器的命令：

rcook$ curl -d @AsyncDaemon.h http://localhost:8787/foo

以下是其输出的示例（带注释）：

如您所见，在第一次调用异步读取回调（并接收零字节数据，顺便说一句）后，它请求另一个输入块。此时，在输入到达之前有一个超过1秒的暂停，在本例中为1431387371.536394到1431387372.537203。那段时间发生了什么？我怎样才能消除这种延误

我在网上做了一些研究，并进行了一些实验（使用cpp netlib的同步模式与异步模式（无效果），curl与libcurl（无效果）），但没有找到答案

更新：TCP转储 根据jxh的建议，我在一个示例事务期间运行了一个tcp转储：

00:28:01.304446 IP6 localhost.52265 > localhost.8787: Flags [S], seq 3956487146, win 43690, options [mss 65476,sackOK,TS val 395479802 ecr 0,nop,wscale 7], length 0
00:28:01.304461 IP6 localhost.8787 > localhost.52265: Flags [R.], seq 0, ack 3956487147, win 0, length 0
00:28:01.305014 IP localhost.49421 > localhost.8787: Flags [S], seq 1668603425, win 43690, options [mss 65495,sackOK,TS val 395479803 ecr 0,nop,wscale 7], length 0
00:28:01.305039 IP localhost.8787 > localhost.49421: Flags [S.], seq 4010788604, ack 1668603426, win 43690, options [mss 65495,sackOK,TS val 395479803 ecr 395479803,nop,wscale 7], length 0
00:28:01.305079 IP localhost.49421 > localhost.8787: Flags [.], ack 1, win 342, options [nop,nop,TS val 395479803 ecr 395479803], length 0
00:28:01.305185 IP localhost.49421 > localhost.8787: Flags [P.], seq 1:176, ack 1, win 342, options [nop,nop,TS val 395479803 ecr 395479803], length 175
00:28:01.305210 IP localhost.8787 > localhost.49421: Flags [.], ack 176, win 350, options [nop,nop,TS val 395479803 ecr 395479803], length 0
00:28:02.306555 IP localhost.49421 > localhost.8787: Flags [P.], seq 176:1382, ack 1, win 342, options [nop,nop,TS val 395480053 ecr 395479803], length 1206
00:28:02.306620 IP localhost.8787 > localhost.49421: Flags [.], ack 1382, win 1373, options [nop,nop,TS val 395480053 ecr 395480053], length 0
00:28:02.307223 IP localhost.8787 > localhost.49421: Flags [P.], seq 1:52, ack 1382, win 1373, options [nop,nop,TS val 395480053 ecr 395480053], length 51
00:28:02.307270 IP localhost.49421 > localhost.8787: Flags [.], ack 52, win 342, options [nop,nop,TS val 395480053 ecr 395480053], length 0
00:28:02.307494 IP localhost.8787 > localhost.49421: Flags [P.], seq 52:66, ack 1382, win 1373, options [nop,nop,TS val 395480053 ecr 395480053], length 14
00:28:02.307522 IP localhost.49421 > localhost.8787: Flags [.], ack 66, win 342, options [nop,nop,TS val 395480053 ecr 395480053], length 0
00:28:02.307765 IP localhost.8787 > localhost.49421: Flags [F.], seq 66, ack 1382, win 1373, options [nop,nop,TS val 395480053 ecr 395480053], length 0
00:28:02.307867 IP localhost.49421 > localhost.8787: Flags [F.], seq 1382, ack 67, win 342, options [nop,nop,TS val 395480053 ecr 395480053], length 0
00:28:02.307917 IP localhost.8787 > localhost.49421: Flags [.], ack 1383, win 1373, options [nop,nop,TS val 395480053 ecr 395480053], length 0

我对tcpdump不是很有经验，但它看起来像是175个字节流到服务器（HTTP头？），然后在一秒钟多一点的延迟后，1206个字节流到服务器，然后是51个字节的块，延迟最小，然后是服务器响应

---

这告诉我延迟是在客户端引入的，很可能是在curl中。有人知道原因吗？

由于@jxh建议的调试和诊断技术，问题得以解决

向curl命令添加

--trace---trace time

，显示curl在发送其余请求之前，花了那神秘的一秒钟等待服务器返回100 Continue响应：

01:31:44.043611 == Info: Connected to localhost (127.0.0.1) port 8787 (#0)
01:31:44.043726 => Send header, 175 bytes (0xaf)
0000: 50 4f 53 54 20 2f 66 6f 6f 20 48 54 54 50 2f 31 POST /foo HTTP/1
0010: 2e 31 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 .1..User-Agent: 
0020: 63 75 72 6c 2f 37 2e 33 35 2e 30 0d 0a 48 6f 73 curl/7.35.0..Hos
0030: 74 3a 20 6c 6f 63 61 6c 68 6f 73 74 3a 38 37 38 t: localhost:878
0040: 37 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d 0a 7..Accept: */*..
0050: 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 Content-Length: 
0060: 31 32 30 36 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 1206..Content-Ty
0070: 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f pe: application/
0080: 78 2d 77 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e x-www-form-urlen
0090: 63 6f 64 65 64 0d 0a 45 78 70 65 63 74 3a 20 31 coded..Expect: 1
00a0: 30 30 2d 63 6f 6e 74 69 6e 75 65 0d 0a 0d 0a    00-continue....
01:31:45.045626 == Info: Done waiting for 100-continue
01:31:45.045831 => Send data, 1206 bytes (0x4b6)

cpp netlib（至少从版本0.11.0开始）中的一个错误是，它不支持发送curl期望的100 Continue响应

然后，解决方案变得令人信服，不再等待100个连续响应。正如我所说，将

-H'Expect:'

添加到curl命令行可以实现这一目的。这样，整个事务大约需要一毫秒

---

由于我回答了自己的问题，我在几周内不会接受我的回答，以给其他人一个更好的机会。

读取0字节不是意味着连接已被对等方关闭吗？@MartinJames，“读取0字节”行只报告传递给异步读取回调的长度参数是多少。第一次调用它时，它是零。之后，它是非零的。是的，我也很惊讶。但这一联系绝对不是封闭的。后续读取将引入整个请求。获取TCP转储。您是否看到服务器端拥有所有数据，但您的服务器代码没有读取这些数据？同步I/O是否也显示相同的症状？如果这不能给您带来牵引力，请尝试使用

--trace---trace time

@jxh，您的建议使我发现了延迟的来源（curl正在等待100次继续）解析（将

-H'Expect:'

添加到命令）。非常感谢！请说明哪个版本的cpp netlib存在此问题，如果问题得到解决，请记住更新您的答案。

01:31:44.043611 == Info: Connected to localhost (127.0.0.1) port 8787 (#0)
01:31:44.043726 => Send header, 175 bytes (0xaf)
0000: 50 4f 53 54 20 2f 66 6f 6f 20 48 54 54 50 2f 31 POST /foo HTTP/1
0010: 2e 31 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 .1..User-Agent: 
0020: 63 75 72 6c 2f 37 2e 33 35 2e 30 0d 0a 48 6f 73 curl/7.35.0..Hos
0030: 74 3a 20 6c 6f 63 61 6c 68 6f 73 74 3a 38 37 38 t: localhost:878
0040: 37 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d 0a 7..Accept: */*..
0050: 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 Content-Length: 
0060: 31 32 30 36 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 1206..Content-Ty
0070: 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f pe: application/
0080: 78 2d 77 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e x-www-form-urlen
0090: 63 6f 64 65 64 0d 0a 45 78 70 65 63 74 3a 20 31 coded..Expect: 1
00a0: 30 30 2d 63 6f 6e 74 69 6e 75 65 0d 0a 0d 0a    00-continue....
01:31:45.045626 == Info: Done waiting for 100-continue
01:31:45.045831 => Send data, 1206 bytes (0x4b6)