乙個兄弟問到，自個用go寫了乙個簡略的http效勞端程式，為什麼壓測的時分效勞端會呈現一段時刻的time_wait超高的狀況，致使壓測的效果不好呢？
記住老王有兩篇文章專門說這個，當時粗粗看了一遍，恰好碰上這個疑問，又翻出來細細摟了。
第乙個要弄懂的，是time_wait是怎樣發生的。
要弄懂time_wait要從tcp的四次握手的分手協議說起。
上面這個影象展示了tcp從銜接建立到銜接開釋的過程中，客戶端和效勞端的狀況變化圖。假如只看銜接開釋時期，四次握手
當然在這個例子和上面的影象中，運用客戶端和效勞端來描繪是不精確的，tcp自動斷開銜接的一方也許是客戶端，也也許是效勞端。所以運用自動斷開的一方，和被迫斷開的一方更換上面的圖也許更為恰當。
不管怎樣說，time_wait的狀況即是自動斷開的一方，傳送完最終一次ack以後進入的狀況。而且持續時刻還挺長的。
能不能傳送完ack以後不進入time_wait就直接進入close狀況呢？不可的，這個是為了tcp協議的可靠性，由於網路因素，ack也許會傳送失利，那麼這個時分，被迫一方會自動從頭傳送一次fin，這個時分假如自動方在time_wait狀況，則還會再傳送一次ack，然後確保可靠性。那麼從這個解說來說，2msl的時長設定是能夠了解的，msl是報文最大生計時刻，假如從頭傳送，乙個fin＋乙個ack，再加上不定期的延遲時刻，大致是在2msl的規模。
所以從理論上說，網上除錯引數降低time_wait的持續時刻的辦法是一種以可靠**換功能的一種方法。嗯，質量守恆定理仍是鐵律。
回到上面的疑問，go寫了乙個http效勞，壓測發現time_wait過多。
首要判別是不是壓測程式放在效勞的同一臺機器...當然不會犯這麼初級的過錯...
那麼這個感受就有點奇怪了，http效勞並沒有依靠外部mysql或許redis等效勞，即是乙個簡略的hello world，而time_wait的是自動斷開方才會呈現的，所以自動斷開方是效勞端？
答案是是的。在http1.1協議中，有個 connection 頭，connection有兩個值，close和keep-alive，這個頭就相當於客戶端通知效勞端，效勞端你履行完結懇求以後，是封閉銜接仍是堅持銜接，堅持銜接就意味著在堅持銜接時期，只能由客戶端自動斷開銜接。還有乙個keep-alive的頭，設定的值就代表了效勞端堅持銜接堅持多久。
http默許的connection值為close，那麼就意味著封閉懇求的一方簡直都會是由效勞端這邊建議的。那麼這個效勞端發生time_wait過多的狀況就很正常了。
雖然http默許connection值為close，可是如今的瀏覽器傳送懇求的時分通常都會設定connection為keep-alive了。所以，也有人說，如今沒有必要經過調整引數來使time_wait降低了。
依照http協議的頭，咱們在壓測程式宣布的http協議頭裡邊加上connection:keep-alive當然能處理這個疑問。
還有的辦法即是體系引數調優:
sysctl net.ipv4.tcp_tw_reuse=1 sysctl net.ipv4.tcp_tw_recycle=1 sysctl net.ipv4.tcp_timestamps=1
這個引數作用是當新的銜接進來的時分，能夠復用處於time_wait的socket。默許值是0。
默許time_wait的超時時刻是2倍的msl，可是msl通常會設定的十分長。假如tcp_timestamps是封閉的，敞開tcp_tw_recycle是沒用的。可是通常狀況下tcp_timestamps是默許敞開的，所以直接敞開就有用了。
也說說TIME WAIT狀態
乙個朋友問到，自己用go寫了乙個簡單的http服務端程式，為什麼壓測的時候服務端會出現一段時間的time wait超高的情況，導致壓測的效果不好呢？記得老王有兩篇文章專門說這個，當時粗粗看了一遍，正好碰上這個問題，又翻出來細細摟了。第乙個要弄懂的，是time wait是怎麼產生的。要弄懂time w...
我也來說說多核
究竟普通開發者是否需要面對多核，這個問題在很多地方都在討論。很多人都認為不需要，這樣說是基於過去幾年的經驗，認為目前的一般應用單核高速cpu已經足以應付，今後也沒有新的重要應用驅動我們使用多核cpu，多核cpu要麼是廠商狗急跳牆，要麼是僅供科研計算，謝絕參觀。看完myan的這篇，我也來說說 說多核無...
我也來說說DDD 大話目錄
回到佔佔推薦部落格索引 ddd之前沒有接觸過，但一但有了接觸就一發不可收拾，他會帶去進入乙個全新的世界！ddd不是新技術，而是新思想，新模式，是軟體開發領域的一次突破，它更接近於業務，對於業務的改動它更加運用自如，它 模式裡，你可能會涉及到ioc,aop,oop,ood等設計模組，也可能會涉及到mv...