我想說你是對的,(time_starttransfer - time_connect)肯定是服務器用來處理請求的時間量。
但是 - 我也想知道time_connect和time_pretransfer有什麼區別? (感興趣的是@Schwartzie和@Cheeso的評論)
通過查看網絡上的幾個curl查詢,我發現有時它們是平等的,有時它們不是。
然後我想出了(至少我是這麼認爲的),他們只有HTTPS請求才會有所不同,導致服務器需要一些時間來解密SSL層,這不是目標應用程序花費的時間,而是服務器花費的時間託管應用程序/服務。
解密ssl(以及連接,也是time_connect中給出的)的時間是time_appconnect,並且只有當它爲0時(如非https請求) - time_connect和time_pretransfer是EQUAL,否則對於https請求它們不同,並且對於https time_pretransfer將等於time_appconnect(而不是time_connect)。
檢查以下兩個例子:
捲曲-kso的/ dev/null的-w 「time_connect =%{time_connect},time_appconnect:%{time_appconnect},time_pretransfer =%{time_pretransfer} \ n」 個http://www.csh.rit.edu
- time_connect = 0.128,time_appconnect:0.000,time_pretransfer = 0.128
捲曲-kso的/ dev/null的-w 「time_connect =%{time_connect},time_appconnect:%{time_appconnect},time_pretransfer =%{time_pretransfer} \ n」 個https://www.csh.rit.edu
- time_connect = 0.133,time_appconnect:0.577,time_pretransfer = 0。577
所以我說,time_pretransfer更精確比time_connect被使用,因爲它會尊重SSL連接過,也許有些其他的事情我不知道的。
與所有以前雖這麼說,我會說,對這個問題更精確的答案:
很可能是:
- time_starttransfer - time_pretransfer
爲@Schwartzie已經提到的,我只是想知道爲什麼。
我一直在試圖弄清楚這一點。我發現http://curl.haxx.se/docs/manpage.html上的時間描述更易於閱讀。我目前對遠程處理時間的最佳猜測是'time_starttransfer - time_pretransfer'。我的理解是'time_pretransfer - time_connect'還包括髮送請求所需的時間。 – Schwartzie