首先說下網路架構
nginx和jetty都在同乙個伺服器，nginx**http流量至多個jetty應用，基本情況就是這樣
首先我們來看下，為什麼會有timewait的狀態
客戶端主動關閉連線時，會傳送最後乙個ack後，然後會進入time_wait狀態，再停留2個msl時間，進入closed狀態。
也就是說一般timewait只會出現在client中(因為主動關閉)，server端是不會關閉連線的(以為一直在監聽)
基於此，我檢視了伺服器的情況
發現nginx對外的tcp連線數狀態是正常的，問題就在對於jetty的連線數異常的多，並且不釋放
首先度娘解決方法，基本得到的結果基本就是乙個修改核心引數(不推薦此做法)
net.ipv4.tcp_tw_reuse=1
#表示開啟重用。允許將time-waitsockets重新用於新的tcp連線，預設為0，表示關閉
net.ipv4.tcp_tw_recycle=1
#表示開啟tcp連線中time-waitsockets的快速**，預設為0，表示關閉
這樣是可以快速的的**socket，但是後來查詢資料發現這樣做有隱患
1.對於net.ipv4.tcp_tw_recycle ，linux核心文件中實戰和麼描述的
tcp_tw_recycle (boolean; default: disabled; since linux 2.4)[譯者注：來自linux man tcp的描述]
enable fast recycling of time-wait sockets. enabling this option is not recommended since this causes
problems when working with nat (network address translation).
啟用time-wait狀態sockets的快速**，這個選項不推薦啟用。在nat(network address translation)網路下，會導致大量的tcp連線建立錯誤。
2.有些文件中也說了對於手機端wifi訪問的話，也會有問題，因為wifi端訪問時間戳會亂跳，導致訪問拒絕
基於以上2個隱患，所以沒有使用此方法。
後來我再觀察的時候，我發現nginx和jetty之間的連線大多都是短連線(因為預設nginx也是使用短連線)，所以有可能是nginx作為client會快速釋放，所以導致nginx的socket一直都是出於timewait狀態，所以去nginx官網檢視資料，配置nginx在負載均衡的時候使用長連線
具體配置為：
在server 的location模組裡面 新增以上資訊。
注意：需要設定nginx**請求的http協議版本號為1.1,以及清除掉connection請求header
官方文件描述：
因為http協議1.1預設就使用長連線，所以不需要connection的頭部資訊，這樣開啟nginx和jetty之間的長連線之後，timewait的狀態大量減少。
總結：我們在遇到問題的時候，百度遇到的解決方案一定要仔細分析，千萬不能隨隨便便就使用，因為別人的環境跟你的有可能不一樣，即便當時能夠解決問題，後面引發的問題，可能更加難以發現和解決。
還有我們遇到問題要多想，千萬不能自以為是什麼什麼原因，要有事實依據，才能找到更好的解決方案
最後歡迎大家一起交流和學習。
記一次伺服器事故
mysql資料庫報錯 can t create write to file tmp sql 6ccc 0.myi 在開始刪除之後，所有服務就已經恢復正常執行了，接下來就是優化那個session了，哎又是埋坑.最後附上inode擴容的方法 但是需要注意，手動擴inode，一般是新建分割槽時設定的，該操...
記一次伺服器專案遷移
今天被分配了伺服器專案遷移的任務,現在還在傳輸,閒著沒事就寫下總結,也算是一種學習 開啟虛擬機器,訪問需要遷移的伺服器 賬號密碼請向領導或運維索要 找到需要遷移的專案,一般在home 公司名 專案名,例如我所在的公司服務放置在home che tomcat epc 10100複製專案 訪問被遷移到的...
記一次伺服器被攻擊經歷
從接手公司伺服器兩個半星期經常性的無法正常ssh登陸，十次裡面有九次半都是顯示 ssh exchange identification read connection reset by peer 也谷歌很多種原因和解決方案，無非是分兩種 一是執行緒滿了，需要更改配置檔案把max session 調大...