因?yàn)榻M內(nèi)的錯(cuò)誤日志被重定向另外一個(gè)日志里今天查看的時(shí)候發(fā)現(xiàn)一個(gè)進(jìn)程有這樣的輸出
報(bào)一個(gè)IO WAIT? 然后我查了一下一開始我搞錯(cuò)方向了以為是http 客戶端的問題 查看了代碼使用原生的http.Post() 函數(shù)很容易忽略一個(gè)問題 就是http.Post()? http.Get()使用的DefaultClient 這個(gè)對(duì)象而這個(gè)對(duì)象如果你沒有顯式的對(duì)DefaultClient 的成員Timeout 賦值那么這個(gè)請(qǐng)求是沒有設(shè)置超時(shí)時(shí)間的畔濒，將不會(huì)超時(shí)侵状，使協(xié)程掛掉
解決這個(gè)問題簡(jiǎn)單一點(diǎn)的就是直接設(shè)置http.Clinet.Timeout,如果想更小粒度的控制
net.Dialer.Timeout：限制建立TCP連接所花費(fèi)的時(shí)間
http.Transport.TLSHandshakeTimeout ：限制了執(zhí)行TLS握手的時(shí)間
http.Transport.ResponseHeaderTimeout：限制了讀取頭部的時(shí)間
http.Transport.ExpectContinueTimeout ：這個(gè)設(shè)置在1.6被去掉
http.Transport.IdleConnTimeout：在連接池中限制一個(gè)空閑連接的保持時(shí)間
對(duì)于發(fā)送request的時(shí)間并沒有任何方法可以限制但是可以取消這個(gè)quest??
*****************************************************************************************************************************************************************
回到IO WAIT 的問題 可以看到 棧是從底層的http.server 函數(shù)打上來的不是客戶端未超時(shí)造成的 為什么會(huì)有這個(gè)問題我查了下 http server 是有一個(gè)ReadTimeout 和 WriteTimeout 的參數(shù)嗤攻，這兩個(gè)參數(shù)是做什么的呢诽俯？
如果不設(shè)置Timeout,那么很慢的客戶端或者消失的客戶端就會(huì)影響到服務(wù)端，將會(huì)看到如下的表示?
從圖上看ReadTimeout 就是從建立連接到獲取請(qǐng)求頭部和body(如果有body的話)的時(shí)間闯团，WriteTimeout 就是覆蓋從讀取頭部結(jié)束到寫回response的時(shí)間房交，如果你使用了https的話那么 他從結(jié)束accept就開始調(diào)用SetWriteDeadline伐割，那么在這種情況下也包括了header read and the first byte wait這部分內(nèi)容刃唤，就是上圖虛線那部分時(shí)間
http.TimeoutHandler?并不是一個(gè)服務(wù)端參數(shù)白群，只是handler的一個(gè)封裝，可以限制http處理請(qǐng)求的最長時(shí)間笼裳，他通過超過時(shí)間將返回504粱玲，如果不設(shè)置超時(shí)時(shí)間可以使用這個(gè)來處理請(qǐng)求
?使用默認(rèn)的http.Server 以及函數(shù) http.ListenAndServe,?http.ListenAndServeTLS 這些函數(shù)的timeout 默認(rèn)值都是關(guān)閉了timeout抽减，有鏈接泄露和文件描述符用光的危險(xiǎn)
參考
The complete guide to Go net/http timeouts
基本上是翻譯這篇文章
