问题：
使用了brpc的长连接，但是为何耗时和短链接一样呢？
brpc文档里介绍，使用http协议，则默认使用pooled，只要连接数不超过max_connection_pool_size，则都可以使用长连接。
但是在实际使用中，发现整个请求耗时很长，使用curl结果如下：
curl -s -w %{time_namelookup}"
"%{time_connect}"
"%{time_pretransfer}"
"%{time_starttransfer}"
"%{time_total}"
" -d "" http://xxx.com/abc/123
time_namelookup : 0.000
time_connect : 0.033 TCP建立连接耗时.
time_pretransfer : 0.033 TCP连接建立完成后，客户端开始传递第一个字节的时间
time_starttransfer : 0.070 服务端响应开始传输第一个字节的时间 (虽然很多资料上说是服务端响应第一个字节的时间，但是根据我多次试验数据我更认为是：客户端收到服务端响应的第一个字节的时间)
time_total : 0.070 整个请求到响应完成的耗时
由此看出：
TCP建立连接，三次握手，耗时1.5RTT，耗时33ms；
数据传输：70-33=37ms，也就是客户端把数据传给服务端(0.5RTT) + 服务端处理(对方说5ms) +服务端把数据传回客户端(0.5RTT) = 37ms；也就是说1RTT = 32ms.
误区：
开始一直认为服务端内部有32ms(37-5)不知道哪去了，但是没想到的是我竟然把数据传输的1RTT给忽略了。
因为建立连接需要33ms，传输数据也需要32ms，服务端数据处理需要5ms，如果每次请求建立成功了长连接，则就可以省去TCP建联的33ms，也就是整个请求是37ms，符合预期。
结论：
从线上统计请求好时看，平均耗时70ms，所以可以确定长连接没建立成功。
解决：
既然brpc介绍用pooled连接池是长连接，那会不会是连接超过max_connection_pool_size了，所以很多都是短连接？ 于是调得更长，也不行。
netstat -ant|awk '{print $NF}'|sort|uniq -c 分析：
61 CLOSE_WAIT
1 established)
2212 ESTABLISHED
1 FIN_WAIT2
19 LISTEN
1 State
2016 TIME_WAIT
TIME_WAIT有2016个，说明有很多连接主动关闭，也就意味着请求是短链接，频繁连接关闭，那么可以确定，尽管使用了pooled，依然是端连接。
继续分析：发现有个defer_close_second参数，表示连接是立即关闭还是延迟多少秒后关闭。将该参数值从0改为120后，请求耗时从70ms降低到35ms了。
也是奇怪，既然pooled用长连接了，为何还要用defer_close_second来把问题复杂化？