TCP本機客戶端連接本機服務器引起的相關問題

2015-10-09 09:16 作者：admin 瀏覽量：

　　我們的服務器上啟了一個redis服務端，偵聽0.0.0.0的1234端口，同處在本機的另外一個進程會頻繁發起到該服務端的短連接，結果導致了兩個問題：

　　1.大量的TIME_WAIT狀態的連接;（電腦維護外包）

　　2.發起連接的進程的CPU占用率接近100%。

　　這兩個結果嚴重影響了我們網關的性能，在分析具體原因之前，首先做一個提倡，那就是：本機連接本機，首選UNIX域套接字而不是TCP!

　　首先我們來看看問題1。TIME_WAIT就不多說了，只要任何一端主動斷開連接，那么它最終可能將會進入TIME_WAIT狀態，具體是否會進入在Linux上取決于幾個因素，第一，有沒有兩端開啟timestamps，如果開啟了，有沒有在服務端開啟recycle，如果開啟了，那么TIME_WAIT套接字就會迅速消失，也就是說，想讓recycle起作用，一定要開啟timestamps。如果沒有timestamps，那么就會有大量的TIME_WAIT狀態的套接字。

　　在Linux內核協議棧的實現中，所有連接本機的數據流，其路由選擇最終都會到定向到loopback，如果沒有綁定源IP地址，那么源/目標IP地址均為127.0.0.1!如果服務端口是固定的，那么最終會接受65535-1個連接，減1的原因在于服務端已經bind了服務端口，因此客戶端不能再次bind。這是合理的，因為按照四元組唯一性考慮，一個服務只能接受一個特定IP地址的65535個連接或者65534個連接，但是問題是，如果需求巨大，這顯然不能滿足要求，你要知道，作為服務器而言，它要考慮的是總的最大并發連接數，一臺機器上同時發起6萬多個連接的可能性并不大，因此TCP在大多數情況下是合理，采用16bit的端口號剛剛好，因為協議頭不能太大，否則載荷率就會變小，這顯然是網絡傳輸所要求的，然而本機連本機時，并不需要網絡傳輸，你想當然會認為有多少需求就要都要滿足，不過TCP并不適合這種場合。（it外包服務公司）

　　本機連本機，沒有網絡傳輸帶來的延遲，吞吐限制也僅限于本機資源利用，因此并發10萬甚至更多的需求都是合理的，可是TCP并不能滿足，原因就在于它只有16bit的端口號，目標端口固定，同時只能有65534個連接。如何解決呢?我們知道127.0.0.0/8都是屬于loopback的，我們可以采用不同的源IP地址，如果想這么做，有兩個選擇，那就是要么客戶端bind源IP為127.x.y.z，要么SNAT成127.x.y.z，這樣就可以接受海量的連接需求了。但是這并不是最終的解決方案，為什么非要用TCP呢?TCP本來就是為網絡傳輸設計的，它的流控應對不同的主機，擁控應對反復無常的網絡，在本機，這些都不是問題，所以本機連本機，最好使用本機套接字，比如UNIX域套接字。

　　再來看問題2，一個連接本機的TCP數據包最終到達了loopback的xmit發送函數，其中簡單的調度了本CPU上的一個軟中斷處理，然后會在下一次中斷結束后調度其執行，這有很大幾率是在當前發送進程的上下文中進行的，也就是說，發送進程在其上下文中進行了發送操作，而此時軟中斷借用了其上下文觸發了接收操作，再然后，LOCK的開銷就很明顯，由于大量的TW套接字的insert和delete，需要頻繁LOCK哈希表，這種開銷完全記帳到了發送進程的名下，也是不公平的。

　　注意，Linux內核中，softirq會在兩種上下文中執行，一種是硬件中斷后的任意上下文中，一種是每CPU一個內核線程的上下文中，后者會記帳給top命令的si百分比，前者則會記帳給任意被中斷的進程。（網絡外包公司）

　　艾銻無限是中國領先IT外包服務商，專業為企業提供IT運維外包、電腦維護、網絡維護、網絡布線、辦公設備維護、服務器維護、數據備份恢復、門禁監控、網站建設等多項IT服務外包,服務熱線：400-650-7820 聯系電話：010-62684652 咨詢QQ1548853602 地址：北京市海淀區北京科技會展2號樓16D,用心服務每一天，為企業的發展提升更高的效率，創造更大的價值。

　　更多的IT外包信息盡在艾銻無限http://m.richjn.cn