摘要：無法形容，直接對產(chǎn)生了滿分好感于是直接打開源碼目錄全局搜，找到，如下一段注釋掉了上面這些，跑起來沒有問題，這樣的問題就解決了。那么查一下，有說設(shè)置注冊表的感覺并不是解決辦法實(shí)測也不能解決問題。

我司的軟件在一個(gè)客戶處測試功能和性能，這個(gè)客戶比較特殊：

他們客戶端是很舊的java代碼，且要求不能改動，客戶端的主要業(yè)務(wù)簡單說就是上傳下載文件

他們提供了客戶端demo，http請求是用裸socket手動加http頭，寫死了http1.1，但又不帶host這個(gè)http頭

客戶要求中間必須經(jīng)過一臺windows server服務(wù)器代理

后端的實(shí)際服務(wù)器是linux系統(tǒng)，用的是nginx

最開始是請求直接返400，nginx access log可以看到400但是沒有更多信息，error log則沒有任何信息打印，一開始另一位同事負(fù)責(zé)定位，我跟著一起用wireshark抓包看了很久，沒得出結(jié)論。后來我又看了一下，nginx error log默認(rèn)的日志級別是crit，那么直接改到debug，看到這個(gè)信息：

那么問題就一目了然了，查了一下，這個(gè)header是http1.1要求必須帶的

且nginx嚴(yán)格遵守該協(xié)議，沒有提供可配置的方式忽略這個(gè)頭，如上圖按理說服務(wù)端不應(yīng)該強(qiáng)行處理這種問題，但客戶要求最高，沒辦法

這時(shí)候好在，正好我們需要一層反向代理，那么，看看能不能找一個(gè)允許不帶該header的反向代理服務(wù)器實(shí)現(xiàn)，接下來可以暫時(shí)忽略這個(gè)問題，我們使用壓測工具測性能，壓測工具在這個(gè)header上是沒有問題的

windows server系統(tǒng)的服務(wù)器，一開始我們直接用Nginx，但簡單測后就知道性能很差，搜了一下基本是說nginx和apache在windows上性能都沒啥希望，首推的基本還是微軟自家的IIS，于是我們配起了IIS，果然性能與直連后端相比基本沒有損耗，但是經(jīng)過很長時(shí)間查資料，找不到配置忽略host header的方法，而且IIS的確不好用，配置比較難看懂，大家都不熟悉windows平臺，接下來只能另辟蹊徑

python：老本行，用twisted寫了個(gè)4行的反向代理，性能不如nginx，大概只有直連的1/6，時(shí)間緊迫，沒來得及分析，繼續(xù)嘗試其他語言
nodejs：在github找到個(gè)redbird庫，代碼也是只需要兩行，但性能跟python半斤八兩
java：撿了個(gè)undertow的框架，折騰挺久終于搞起來，倒是基本沒有性能損耗，于是就要解決header問題，但是這個(gè)版本的400返回沒帶提示信息，java框架源碼要反編譯看，倒也還好，但是沒有錯誤信息，不好直接搜代碼，只能看流程，比較難看，java接觸的也少
go：代碼倒是長一些，有三十來行，但是只用到了go的標(biāo)準(zhǔn)庫，性能不出意外也是等于直連，驚喜的來了，它的400帶了個(gè)錯誤信息提示：missing required Host header，當(dāng)時(shí)那個(gè)幸福感。。。無法形容，直接對go產(chǎn)生了滿分好感
于是直接打開源碼目錄全局搜，找到src/net/http/server.go，如下一段
`

// hosts, haveHost := req.Header["Host"]
isH2Upgrade := req.isH2Upgrade()
// if req.ProtoAtLeast(1, 1) && (!haveHost || len(hosts) == 0) && !isH2Upgrade && req.Method != "CONNECT" {
//     return nil, badRequestError("missing required Host header")
// }
// if len(hosts) > 1 {
//     return nil, badRequestError("too many Host headers")
// }
// if len(hosts) == 1 && !httpguts.ValidHostHeader(hosts[0]) {
//     return nil, badRequestError("malformed Host header")
// }

`
注釋掉了上面這些，跑起來沒有問題，這樣host header的問題就解決了。

但是到這還沒結(jié)束，壓測跑了一會兒發(fā)現(xiàn)請求全部失敗，看了一下報(bào)錯，socket爆了，在cmd里netstat查了一下，果然go進(jìn)程接近2w的socket消耗，全部是TIME_WAIT狀態(tài)

本端主動關(guān)閉的socket，就會進(jìn)入TIME_WAIT狀態(tài)，被對方關(guān)閉是CLOSE_WAIT。那么查一下windows socket time_wait，有說設(shè)置注冊表的
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesTcpipParameters]
"TcpTimedWaitDelay"=dword:0000001e

感覺并不是解決辦法？實(shí)測也不能解決問題。想想也知道關(guān)鍵應(yīng)該是找到為什么go會頻繁關(guān)閉socket，那么google的關(guān)鍵字就應(yīng)該是這樣了：go socket time_wait

搜索結(jié)果第一條stackoverflow的就是答案：https://stackoverflow.com/que...
在main函數(shù)里加上配置：
http.DefaultTransport.(*http.Transport).MaxIdleConns = 8192
http.DefaultTransport.(*http.Transport).MaxIdleConnsPerHost = 8192
這個(gè)值的含義見鏈接，簡單說就是允許保持的最大tcp連接數(shù)，默認(rèn)值是2（待研究為什么要這樣默認(rèn)），超過后會一直關(guān)socket再重開，我們壓測工具跑的是100并發(fā)，實(shí)際只需要這個(gè)值是200就夠了（因?yàn)橥鵵eal server的那個(gè)方向還需要同樣的連接數(shù) 所以*2）

想想python應(yīng)該也能做到無損耗的，暫時(shí)沒有再去研究，但從簡單使用來看，腳本語言畢竟是腳本語言，你大爺還是你大爺。