問題：
使用了brpc的長連接，但是為何耗時和短鏈接一樣呢？
brpc文檔里介紹，使用http協議，則默認使用pooled，只要連接數不超過max_connection_pool_size，則都可以使用長連接。
但是在實際使用中，發現整個請求耗時很長，使用curl結果如下：
curl -s -w %{time_namelookup}"\r\n"%{time_connect}"\r\n"%{time_pretransfer}"\r\n"%{time_starttransfer}"\r\n"%{time_total}"\r\n" -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來把問題復雜化？