『壹』 golang連接池管理tcp
Golang網路編程絲綢之路-TCP/UDP地址解析TL;DR在使用Golang編寫TCP/UDPsocket的時候，第一步做的就是地址解析。
該函數返回的地址包含的信息如下：
TCPAddr里，IP既可以是IPv4地址，也可以是IPv6地址。Port就是埠了。Zone是IPv6本地地址所在的區域。
從返回結果看該函數的參數，network指address的網路類型；address指要解析的地址，會從中解析出我們想要的IP,Port和Zone。
從源碼中可以看出，參數network只能是如下四個值，否則會得到一個錯誤。
解析過程跟ResolveTCPAddr的一樣，不過得到的是*UDPAddr。
UDPAddr包含的信息如下：
【golang】高並發下TCP常見問題解決方案首先，看一下TCP握手簡單描繪過程：
其握手過程原理，就不必說了，有很多詳細文章進行敘述，本文只關注研究重點。
在第三次握手過程中，如果伺服器收到ACK，就會與客戶端建立連接，此時內核會把連接從半連接隊列移除，然後創建新的連接，並將其添加到全連接隊列，等待進程調用。
如果伺服器繁忙，來不及調用連接導致全連接隊列溢出，伺服器就會放棄當前握手連接，發送RST給客戶端，即connectionresetbypeer。
在linux平台上，客戶端在進行高並發TCP連接處理時，最高並發數量都要受系統對用戶單一進程同時打開文件數量的限制（這是因為系統每個TCP都是SOCKET句柄，每個soker句柄都是一個文件），當打開連接超過限制，就會出現toomanyopenfiles。
使用下指令查看最大句柄數量：
增加句柄解決方案
一篇搞懂tcp，http，socket，socket連接池之間的關系
作為一名開發人員我們經常會聽到HTTP協議、TCP/IP協議、UDP協議、Socket、Socket長連接、Socket連接池等字眼，然而它們之間的關系、區別及原理並不是所有人都能理解清楚，這篇文章就從網路協議基礎開始到Socket連接池，一步一步解釋他們之間的關系。
首先從網路通信的分層模型講起：七層模型，亦稱OSI(OpenSystemInterconnection)模型。自下往上分為：物理層、數據鏈路層、網路層、傳輸層、會話層、表示層和應用層。所有有關通信的都離不開它，下面這張圖片介紹了各層所對應的一些協議和硬體
通過上圖，我知道IP協議對應於網路層，TCP、UDP協議對應於傳輸層，而HTTP協議對應於應用層，OSI並沒有Socket，那什麼是Socket，後面我們將結合代碼具體詳細介紹。
關於傳輸層TCP、UDP協議可能我們平時遇見的會比較多，有人說TCP是安全的，UDP是不安全的，UDP傳輸比TCP快，那為什麼呢，我們先從TCP的連接建立的過程開始分析，然後解釋UDP和TCP的區別。
TCP的三次握手和四次分手
我們知道TCP建立連接需要經過三次握手，而斷開連接需要經過四次分手，那三次握手和四次分手分別做了什麼和如何進行的。
第一次握手：建立連接。客戶端發送連接請求報文段，將SYN位置為1，SequenceNumber為x；然後，客戶端進入SYN_SEND狀態，等待伺服器的確認；
第二次握手：伺服器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設置AcknowledgmentNumber為x+1(SequenceNumber+1)；同時，自己自己還要發送SYN請求信息，將SYN位置為1，SequenceNumber為y；伺服器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一並發送給客戶端，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN+ACK報文段。然後將AcknowledgmentNumber設置為y+1，向伺服器發送ACK報文段，這個報文段發送完畢以後，客戶端和伺服器端都進入ESTABLISHED狀態，完成TCP三次握手。
完成了三次握手，客戶端和伺服器端就可以開始傳送數據。以上就是TCP三次握手的總體介紹。通信結束客戶端和服務端就斷開連接，需要經過四次分手確認。
第一次分手：主機1（可以使客戶端，也可以是伺服器端），設置SequenceNumber和AcknowledgmentNumber，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；
第二次分手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，AcknowledgmentNumber為SequenceNumber加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我「同意」你的關閉請求；
第三次分手：主機2向主機1發送FIN報文段，請求關閉連接，同時主機2進入LAST_ACK狀態；
第四次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連接；此時，主機1等待2MSL後依然沒有收到回復，則證明Server端已正常關閉，那好，主機1也可以關閉連接了。
可以看到一次tcp請求的建立及關閉至少進行7次通信，這還不包過數據的通信，而UDP不需3次握手和4次分手。
TCP和UDP的區別
1、TCP是面向鏈接的，雖然說網路的不安全不穩定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上(實際上也很大程度上保證了)保證了連接的可靠性;而UDP不是面向連接的，UDP傳送數據前並不與對方建立連接，對接收到的數據也不發送確認信號，發送端不知道數據是否會正確接收，當然也不用重發，所以說UDP是無連接的、不可靠的一種數據傳輸協議。
2、也正由於1所說的特點，使得UDP的開銷更小數據傳輸速率更高，因為不必進行收發數據的確認，所以UDP的實時性更好。知道了TCP和UDP的區別，就不難理解為何採用TCP傳輸協議的MSN比採用UDP的QQ傳輸文件慢了，但並不能說QQ的通信是不安全的，因為程序員可以手動對UDP的數據收發進行驗證，比如發送方對每個數據包進行編號然後由接收方進行驗證啊什麼的，即使是這樣，UDP因為在底層協議的封裝上沒有採用類似TCP的「三次握手」而實現了TCP所無法達到的傳輸效率。
關於傳輸層我們會經常聽到一些問題
1．TCP伺服器最大並發連接數是多少？
關於TCP伺服器最大並發連接數有一種誤解就是「因為埠號上限為65535,所以TCP伺服器理論上的可承載的最大並發連接數也是65535」。首先需要理解一條TCP連接的組成部分：客戶端IP、客戶端埠、服務端IP、服務端埠。所以對於TCP服務端進程來說，他可以同時連接的客戶端數量並不受限於可用埠號，理論上一個伺服器的一個埠能建立的連接數是全球的IP數*每台機器的埠數。實際並發連接數受限於linux可打開文件數，這個數是可以配置的，可以非常大，所以實際上受限於系統性能。通過#ulimit-n查看服務的最大文件句柄數，通過ulimit-nxxx修改xxx是你想要能打開的數量。也可以通過修改系統參數：
2．為什麼TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態？
這是因為雖然雙方都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網路是不可靠的，你無法保證你最後發送的ACK報文會一定被對方收到，因此對方處於LAST_ACK狀態下的Socket可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。
3．TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態會產生什麼問題
通信雙方建立TCP連接後，主動關閉連接的一方就會進入TIME_WAIT狀態，TIME_WAIT狀態維持時間是兩個MSL時間長度，也就是在1-4分鍾，Windows操作系統就是4分鍾。進入TIME_WAIT狀態的一般情況下是客戶端，一個TIME_WAIT狀態的連接就佔用了一個本地埠。一台機器上埠號數量的上限是65536個，如果在同一台機器上進行壓力測試模擬上萬的客戶請求，並且循環與服務端進行短連接通信，那麼這台機器將產生4000個左右的TIME_WAITSocket，後續的短連接就會產生addressalreadyinuse:connect的異常，如果使用Nginx作為方向代理也需要考慮TIME_WAIT狀態，發現系統存在大量TIME_WAIT狀態的連接，通過調整內核參數解決。
編輯文件，加入以下內容：
然後執行/sbin/sysctl-p讓參數生效。
net.ipv4.tcp_syncookies=1表示開啟SYNCookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防範少量SYN攻擊，默認為0，表示關閉；
net.ipv4.tcp_tw_reuse=1表示開啟重用。允許將TIME-WAITsockets重新用於新的TCP連接，默認為0，表示關閉；
net.ipv4.tcp_tw_recycle=1表示開啟TCP連接中TIME-WAITsockets的快速回收，默認為0，表示關閉。
net.ipv4.tcp_fin_timeout修改系統默認的TIMEOUT時間
相關視頻推薦
10道網路八股文，每道都很經典，讓你在面試中逼格滿滿
徒手實現網路協議棧，請准備好環境，一起來寫代碼
學習地址：C/C++Linux伺服器開發/後台架構師【零聲教育】-學習視頻教程-騰訊課堂
需要C/C++Linux伺服器架構師學習資料加qun812855908獲取（資料包括C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg等），免費分享
關於TCP/IP和HTTP協議的關系，網路有一段比較容易理解的介紹：「我們在傳輸數據時，可以只使用(傳輸層)TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別數據內容。如果想要使傳輸的數據有意義，則必須使用到應用層協議。應用層協議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用層協議。
HTTP協議即超文本傳送協議(HypertextTransferProtocol)，是Web聯網的基礎，也是手機聯網常用的協議之一，WEB使用HTTP協議作應用層協議，以封裝HTTP文本信息，然後使用TCP/IP做傳輸層協議將它發到網路上。
由於HTTP在每次請求結束後都會主動釋放連接，因此HTTP連接是一種「短連接」，要保持客戶端程序的在線狀態，需要不斷地向伺服器發起連接請求。通常的做法是即時不需要獲得任何數據，客戶端也保持每隔一段固定的時間向伺服器發送一次「保持連接」的請求，伺服器在收到該請求後對客戶端進行回復，表明知道客戶端「在線」。若伺服器長時間無法收到客戶端的請求，則認為客戶端「下線」，若客戶端長時間無法收到伺服器的回復，則認為網路已經斷開。
下面是一個簡單的HTTPPostapplication/json數據內容的請求：
現在我們了解到TCP/IP只是一個協議棧，就像操作系統的運行機制一樣，必須要具體實現，同時還要提供對外的操作介面。就像操作系統會提供標準的編程介面，比如Win32編程介面一樣，TCP/IP也必須對外提供編程介面，這就是Socket。現在我們知道，Socket跟TCP/IP並沒有必然的聯系。Socket編程介面在設計的時候，就希望也能適應其他的網路協議。所以，Socket的出現只是可以更方便的使用TCP/IP協議棧而已，其對TCP/IP進行了抽象，形成了幾個最基本的函數介面。比如create，listen，accept，connect，read和write等等。
不同語言都有對應的建立Socket服務端和客戶端的庫，下面舉例Nodejs如何創建服務端和客戶端：
服務端：
服務監聽9000埠
下面使用命令行發送http請求和telnet
注意到curl只處理了一次報文。
客戶端
Socket長連接
所謂長連接，指在一個TCP連接上可以連續發送多個數據包，在TCP連接保持期間，如果沒有數據包發送，需要雙方發檢測包以維持此連接(心跳包)，一般需要自己做在線維持。短連接是指通信雙方有數據交互時，就建立一個TCP連接，數據發送完成後，則斷開此TCP連接。比如Http的，只是連接、請求、關閉，過程時間較短,伺服器若是一段時間內沒有收到請求即可關閉連接。其實長連接是相對於通常的短連接而說的，也就是長時間保持客戶端與服務端的連接狀態。
通常的短連接操作步驟是：
連接數據傳輸關閉連接；
而長連接通常就是：
連接數據傳輸保持連接(心跳)數據傳輸保持連接(心跳)……關閉連接；
什麼時候用長連接，短連接？
長連接多用於操作頻繁，點對點的通訊，而且連接數不能太多情況，。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。例如：資料庫的連接用長連接，如果用短連接頻繁的通信會造成Socket錯誤，而且頻繁的Socket創建也是對資源的浪費。
什麼是心跳包為什麼需要：
心跳包就是在客戶端和服務端間定時通知對方自己狀態的一個自己定義的命令字，按照一定的時間間隔發送，類似於心跳，所以叫做心跳包。網路中的接收和發送數據都是使用Socket進行實現。但是如果此套接字已經斷開（比如一方斷網了），那發送數據和接收數據的時候就一定會有問題。可是如何判斷這個套接字是否還可以使用呢？這個就需要在系統中創建心跳機制。其實TCP中已經為我們實現了一個叫做心跳的機制。如果你設置了心跳，那TCP就會在一定的時間（比如你設置的是3秒鍾）內發送你設置的次數的心跳（比如說2次），並且此信息不會影響你自己定義的協議。也可以自己定義，所謂「心跳」就是定時發送一個自定義的結構體（心跳包或心跳幀），讓對方知道自己「在線」,以確保鏈接的有效性。
實現：
服務端：
服務端輸出結果：
客戶端代碼：
客戶端輸出結果：
如果想要使傳輸的數據有意義，則必須使用到應用層協議比如Http、Mqtt、Dubbo等。基於TCP協議上自定義自己的應用層的協議需要解決的幾個問題：
下面我們就一起來定義自己的協議，並編寫服務的和客戶端進行調用：
定義報文頭格式：length:000000000xxxx;xxxx代表數據的長度，總長度20,舉例子不嚴謹。
數據表的格式:Json
服務端:
日誌列印：
客戶端
日誌列印：
客戶端定時發送自定義協議數據到服務端，先發送頭數據，在發送內容數據，另外一個定時器發送心跳數據，服務端判斷是心跳數據，再判斷是不是頭數據，再是內容數據，然後解析後再發送數據給客戶端。從日誌的列印可以看出客戶端先後writeheader和data數據，服務端可能在一個data事件裡面接收到。
這里可以看到一個客戶端在同一個時間內處理一個請求可以很好的工作，但是想像這么一個場景，如果同一時間內讓同一個客戶端去多次調用服務端請求，發送多次頭數據和內容數據，服務端的data事件收到的數據就很難區別哪些數據是哪次請求的，比如兩次頭數據同時到達服務端，服務端就會忽略其中一次，而後面的內容數據也不一定就對應於這個頭的。所以想復用長連接並能很好的高並發處理服務端請求，就需要連接池這種方式了。
什麼是Socket連接池,池的概念可以聯想到是一種資源的集合，所以Socket連接池，就是維護著一定數量Socket長連接的集合。它能自動檢測Socket長連接的有效性，剔除無效的連接，補充連接池的長連接的數量。從代碼層次上其實是人為實現這種功能的類，一般一個連接池包含下面幾個屬性：
場景：一個請求過來，首先去資源池要求獲取一個長連接資源，如果空閑隊列裡面有長連接，就獲取到這個長連接Socket,並把這個Socket移到正在運行的長連接隊列。如果空閑隊列裡面沒有，且正在運行的隊列長度小於配置的連接池資源的數量，就新建一個長連接到正在運行的隊列去，如果正在運行的不下於配置的資源池長度，則這個請求進入到等待隊列去。當一個正在運行的Socket完成了請求，就從正在運行的隊列移到空閑的隊列，並觸發等待請求隊列去獲取空閑資源，如果有等待的情況。
這里簡單介紹Nodejs的Socket連接池generic-pool模塊的源碼。
主要文件目錄結構
下面介紹庫的使用：
初始化連接池
使用連接池
下面連接池的使用，使用的協議是我們之前自定義的協議。
日誌列印：
這里看到前面兩個請求都建立了新的Socket連接socket_pool127.0.0.19000connect，定時器結束後重新發起兩個請求就沒有建立新的Socket連接了，直接從連接池裡面獲取Socket連接資源。
源碼分析
發現主要的代碼就位於lib文件夾中的Pool.js
構造函數：
lib/Pool.js
可以看到包含之前說的空閑的資源隊列，正在請求的資源隊列，正在等待的請求隊列等。
下面查看Pool.acquire方法
lib/Pool.js
上面的代碼就按種情況一直走下到最終獲取到長連接的資源，其他更多代碼大家可以自己去深入了解。
Golang建立TCP時使用連接池程序輸出如下，相比不用連接池，單次操作時間少了一個數量級。
Golang需要自己實現資料庫連接池嗎使用完後必須con.close()掉，
使用連接池的話，執行con.close並不會關閉與資料庫的TCP連接，而是將連接還回到池中去，如果不close掉的話，這個連接將會一直被佔用，直接連接池中的連接耗盡為止。
golang獲取tcp連接的文件描述符fd有個通過代理進來的tcp連接，通過Conn.RemoteAddr獲取到的是代理點的ip地址，為了獲取實際客戶端的ip，找到了syscall.Getpeername的方法，而這個方法需要的是連接的fd。