go語言TCP連接池rocket049/connpool使用

安裝：

成都創新互聯專注網站設計,以設計驅動企業價值的持續增長,網站，看似簡單卻每一個企業都需要——設計，看似簡潔卻是每一位設計師的心血 十載來，我們只專注做網站。認真對待每一個客戶，我們不用口頭的語言來吹擂我們的優秀，數千家的成功案例見證著我們的成長。

go get -v -u github.com/rocket049/connpool

go get -v -u gitee.com/rocket049/connpool

rocket049/connpool 包是本人用go語言開發的，提供一個通用的TCP連接池，初始化參數包括最高連接數、超時秒數、連接函數，放回連接池的連接被重新取出時，如果已經超時，將會自動重新連接；如果沒有超時，連接將被復用。

可調用的函數：

調用示例：

Go 語言自我提升 (三次握手 - 四次揮手 - TCP狀態圖 - udp - 網絡文件傳輸)

三次握手：

1. 主動發起連接請求端（客戶端），發送 SYN 標志位，攜帶數據包、包號

2. 被動接收連接請求端（服務器），接收 SYN，回復 ACK，攜帶應答序列號。同時，發送SYN標志位，攜帶數據包、包號

3. 主動發起連接請求端（客戶端），接收SYN 標志位，回復 ACK。

被動端（服務器）接收 ACK —— 標志著 三次握手建立完成（ Accept()/Dial() 返回 ）

四次揮手：

1. 主動請求斷開連接端（客戶端）， 發送 FIN標志，攜帶數據包

2. 被動接受斷開連接端（服務器）， 發送 ACK標志，攜帶應答序列號。 —— 半關閉完成。

3. 被動接受斷開連接端（服務器）， 發送 FIN標志，攜帶數據包

4. 主動請求斷開連接端（客戶端）， 發送 最后一個 ACK標志，攜帶應答序列號。—— 發送完成，客戶端不會直接退出，等 2MSL時長。

等 2MSL待目的：確保服務器 收到最后一個ACK

滑動窗口：

通知對端本地存儲數據的 緩沖區容量。—— write 函數在對端 緩沖區滿時，有可能阻塞。

TCP狀態轉換：

1. 主動發起連接請求端：

CLOSED —— 發送SYN —— SYN_SENT(了解) —— 接收ACK、SYN，回發 ACK —— ESTABLISHED (數據通信)

2. 主動關閉連接請求端：

ESTABLISHED —— 發送FIN —— FIN_WAIT_1 —— 接收ACK —— FIN_WAIT_2 (半關閉、主動端)

—— 接收FIN、回復ACK —— TIME_WAIT (主動端) —— 等 2MSL 時長 —— CLOSED

3. 被動建立連接請求端：

CLOSED —— LISTEN —— 接收SYN、發送ACK、SYN —— SYN_RCVD —— 接收 ACK —— ESTABLISHED (數據通信)

4. 被動斷開連接請求端：

ESTABLISHED —— 接收 FIN、發送 ACK —— CLOSE_WAIT —— 發送 FIN —— LAST_ACK —— 接收ACK —— CLOSED

windows下查看TCP狀態轉換：

netstat -an | findstr? 端口號

Linux下查看TCP狀態轉換：

netstat -an | grep? 端口號

TCP和UDP對比:?

TCP: 面向連接的可靠的數據包傳遞。 針對不穩定的 網絡層，完全彌補。ACK

UDP：無連接不可靠的報文傳輸。 針對不穩定的 網絡層，完全不彌補。還原網絡真實狀態。

優點???????????????????????????????????????????????????????????? 缺點

TCP： 可靠、順序、穩定 ???????????????????????????????????? 系統資源消耗大，程序實現繁復、速度慢

UDP：系統資源消耗小，程序實現簡單、速度快 ???????????????????????? 不可靠、無序、不穩定

使用場景：

TCP：大文件、可靠數據傳輸。 對數據的 穩定性、準確性、一致性要求較高的場合。

UDP：應用于對數據時效性要求較高的場合。 網絡直播、電話會議、視頻直播、網絡游戲。

UDP-CS-Server實現流程：

1.? 創建 udp地址結構 ResolveUDPAddr(“協議”， “IP：port”) —— udpAddr 本質 struct{IP、port}

2.? 創建用于 數據通信的 socket ListenUDP(“協議”, udpAddr ) —— udpConn (socket)

3.? 從客戶端讀取數據，獲取對端的地址 udpConn.ReadFromUDP() —— 返回：n，clientAddr， err

4.? 發送數據包給 客戶端 udpConn.WriteToUDP("數據"， clientAddr)

UDP-CS-Client實現流程：

1.? 創建用于通信的 socket。 net.Dial("udp", "服務器IP：port") —— udpConn (socket)

2.? 以后流程參見 TCP客戶端實現源碼。

UDPserver默認就支持并發！

------------------------------------

命令行參數： 在main函數啟動時，向整個程序傳參。 【重點】

語法： go run xxx.go ? argv1 argv2? argv3? argv4 。。。

xxx.exe:? 第 0 個參數。

argv1 ：第 1 個參數。

argv2 ：第 2 個參數。

argv3 ：第 3 個參數。

argv4 ：第 4 個參數。

使用： list := os.Args? 提取所有命令行參數。

獲取文件屬性函數：

os.stat(文件訪問絕對路徑) —— fileInfo 接口

fileInfo 包含 兩個接口。

Name() 獲取文件名。 不帶訪問路徑

Size() 獲取文件大小。

網絡文件傳輸 —— 發送端（客戶端）

1.? 獲取命令行參數，得到文件名（帶路徑）filePath list := os.Args

2.? 使用 os.stat() 獲取 文件名（不帶路徑）fileName

3.? 創建 用于數據傳輸的 socket? net.Dial("tcp"， “服務器IP+port”) —— conn

4.? 發送文件名(不帶路徑)? 給接收端， conn.write()

5.? 讀取 接收端回發“ok”，判斷無誤。封裝函數 sendFile(filePath, conn) 發送文件內容

6.? 實現 sendFile(filePath,? conn)

1) 只讀打開文件 os.Open(filePath)

for {

2) 從文件中讀數據? f.Read(buf)

3) 將讀到的數據寫到socket中? conn.write(buf[:n])

4）判斷讀取文件的 結尾。 io.EOF. 跳出循環

}

網絡文件傳輸 —— 接收端（服務器）

1. 創建用于監聽的 socket net.Listen() —— listener

2. 借助listener 創建用于 通信的 socket listener.Accpet()? —— conn

3. 讀取 conn.read() 發送端的 文件名， 保存至本地。

4. 回發 “ok”應答 發送端。

5. 封裝函數，接收文件內容 recvFile(文件路徑)

1) f = os.Create(帶有路徑的文件名)

for {

2）從 socket中讀取發送端發送的 文件內容 。 conn.read(buf)

3)? 將讀到的數據 保存至本地文件 f.Write(buf[:n])

4)? 判斷 讀取conn 結束， 代表文件傳輸完成。 n == 0? break

}

go語言tcp客戶端怎么和服務端鏈接

網絡連接需要用socket,易語言用查易語言socket用或者看看否TCP協議相關組件

TCP那些事兒

目錄：

以前我也認為TCP是相當底層的東西，我永遠不需要去了解它。雖然差不多是這樣，但是實際生活中，你依然可能遇見和TCP算法相關的bug，這時候懂一些TCP的知識就至關重要了。（ 本文也可以引申為，系統調用，操作系統這些都很重要，這個道理適用于很多東西 ）

這里推薦一篇小短文， 人人都應該懂點TCP

使用TCP協議通信的雙方必須先建立TCP連接，并在內核中為該連接維持一些必要的數據結構，比如連接的狀態、讀寫緩沖區、定時器等。當通信結束時，雙方必須關閉連接以釋放這些內核數據。TCP服務基于流，源源不斷從一端流向另一端，發送端可以逐字節寫入，接收端可以逐字節讀出，無需分段。

需要注意的幾點：

TCP狀態（11種）：

eg.

以上為TCP三次握手的狀態變遷

以下為TCP四次揮手的狀態變遷

服務器通過 listen 系統調用進入 LISTEN 狀態，被動等待客戶端連接，也就是所謂的被動打開。一旦監聽到SYN（同步報文段）請求，就將該連接放入內核的等待隊列，并向客戶端發送帶SYN的ACK（確認報文段），此時該連接處于 SYN_RECVD 狀態。如果服務器收到客戶端返回的ACK，則轉到 ESTABLISHED 狀態。這個狀態就是連接雙方能進行全雙工數據傳輸的狀態。

而當客戶端主動關閉連接時，服務器收到FIN報文，通過返回ACK使連接進入 CLOSE_WAIT 狀態。此狀態表示——等待服務器應用程序關閉連接。通常，服務器檢測到客戶端關閉連接之后，也會立即給客戶端發送一個FIN來關閉連接，使連接轉移到 LAST_ACK 狀態，等待客戶端對最后一個FIN結束報文段的最后一次確認，一旦確認完成，連接就徹底關閉了。

客戶端通過 connect 系統調用主動與服務器建立連接。此系統調用會首先給服務器發一個SYN，使連接進入 SYN_SENT 狀態。

connect 調用可能因為兩種原因失敗：1. 目標端口不存在（未被任何進程監聽）護著該端口被 TIME_WAIT 狀態的連接占用（ 詳見后文 ）。2. 連接超時，在超時時間內未收到服務器的ACK。

如果 connect 調用失敗，則連接返回初始的 CLOSED 狀態，如果調用成功，則轉到 ESTABLISHED 狀態。

客戶端執行主動關閉時，它會向服務器發送一個FIN，連接進入 TIME_WAIT_1 狀態，如果收到服務器的ACK，進入 TIME_WAIT_2 狀態。此時服務器處于 CLOSE_WAIT 狀態，這一對狀態是可能發生辦關閉的狀態（詳見后文）。此時如果服務器發送FIN關閉連接，則客戶端會發送ACK進行確認并進入 TIME_WAIT 狀態。

流量控制是為了控制發送方發送速率，保證接收方來得及接收。

接收方發送的確認報文中的窗口字段可以用來控制發送方窗口大小，從而影響發送方的發送速率。將窗口字段設置為 0，則發送方不能發送數據。

如果網絡出現擁塞，分組將會丟失，此時發送方會繼續重傳，從而導致網絡擁塞程度更高。因此當出現擁塞時，應當控制發送方的速率。這一點和流量控制很像，但是出發點不同。 流量控制是為了讓接收方能來得及接收，而擁塞控制是為了降低整個網絡的擁塞程度。

TCP 主要通過四種算法來進行擁塞控制： 慢開始、擁塞避免、快重傳、快恢復。

在Linux下有多種實現，比如reno算法，vegas算法和cubic算法等。

發送方需要維護一個叫做擁塞窗口（cwnd）的狀態變量，注意擁塞窗口與發送方窗口的區別：擁塞窗口只是一個狀態變量，實際決定發送方能發送多少數據的是發送方窗口。

為了便于討論，做如下假設：

發送的最初執行慢開始，令 cwnd=1，發送方只能發送 1 個報文段；當收到確認后，將 cwnd 加倍，因此之后發送方能夠發送的報文段數量為：2、4、8 ...

注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非常快，從而使得發送方發送的速度增長速度過快，網絡擁塞的可能也就更高。設置一個慢開始門限 ssthresh，當 cwnd = ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。

如果出現了超時，則令 ssthresh = cwnd/2，然后重新執行慢開始。

在接收方，要求每次接收到報文段都應該對最后一個已收到的有序報文段進行確認。例如已經接收到 M1 和 M2，此時收到 M4，應當發送對 M2 的確認。

在發送方，如果收到三個重復確認，那么可以知道下一個報文段丟失，此時執行快重傳，立即重傳下一個報文段。例如收到三個 M2，則 M3 丟失，立即重傳 M3。

在這種情況下，只是丟失個別報文段，而不是網絡擁塞。因此執行快恢復，令 ssthresh = cwnd/2 ，cwnd = ssthresh，注意到此時直接進入擁塞避免。

慢開始和快恢復的快慢指的是 cwnd 的設定值，而不是 cwnd 的增長速率。慢開始 cwnd 設定為 1，而快恢復 cwnd 設定為 ssthresh。

??發送端的每個TCP報文都必須得到接收方的應答，才算傳輸成功。

??TCP為每個TCP報文段都維護一個重傳定時器。

??發送端在發出一個TCP報文段之后就啟動定時器，如果在定時時間類未收到應答，它就將重發該報文段并重置定時器。

??因為TCP報文段最終在網絡層是以IP數據報的形式發送，而IP數據報到達接收端可能是亂序或者重復的。TCP協議會對收到的TCP報文進行重排、整理，確保順序正確。

TCP報文段所攜帶的應用程序數據按照長度分為兩種： 交互數據 和 成塊數據

對于什么是粘包、拆包問題，我想先舉兩個簡單的應用場景：

對于第一種情況，服務端的處理流程可以是這樣的：當客戶端與服務端的連接建立成功之后，服務端不斷讀取客戶端發送過來的數據，當客戶端與服務端連接斷開之后，服務端知道已經讀完了一條消息，然后進行解碼和后續處理...。對于第二種情況，如果按照上面相同的處理邏輯來處理，那就有問題了，我們來看看 第二種情況 下客戶端發送的兩條消息遞交到服務端有可能出現的情況：

第一種情況：

服務端一共讀到兩個數據包，第一個包包含客戶端發出的第一條消息的完整信息，第二個包包含客戶端發出的第二條消息，那這種情況比較好處理，服務器只需要簡單的從網絡緩沖區去讀就好了，第一次讀到第一條消息的完整信息，消費完再從網絡緩沖區將第二條完整消息讀出來消費。

第二種情況：

服務端一共就讀到一個數據包，這個數據包包含客戶端發出的兩條消息的完整信息，這個時候基于之前邏輯實現的服務端就蒙了，因為服務端不知道第一條消息從哪兒結束和第二條消息從哪兒開始，這種情況其實是發生了TCP粘包。

第三種情況：

服務端一共收到了兩個數據包，第一個數據包只包含了第一條消息的一部分，第一條消息的后半部分和第二條消息都在第二個數據包中，或者是第一個數據包包含了第一條消息的完整信息和第二條消息的一部分信息，第二個數據包包含了第二條消息的剩下部分，這種情況其實是發送了TCP拆，因為發生了一條消息被拆分在兩個包里面發送了，同樣上面的服務器邏輯對于這種情況是不好處理的。

我們知道tcp是以流動的方式傳輸數據，傳輸的最小單位為一個報文段（segment）。tcp Header中有個Options標識位，常見的標識為mss(Maximum Segment Size)指的是，連接層每次傳輸的數據有個最大限制MTU(Maximum Transmission Unit)，一般是1500比特，超過這個量要分成多個報文段，mss則是這個最大限制減去TCP的header，光是要傳輸的數據的大小，一般為1460比特。換算成字節，也就是180多字節。

tcp為提高性能，發送端會將需要發送的數據發送到緩沖區，等待緩沖區滿了之后，再將緩沖中的數據發送到接收方。同理，接收方也有緩沖區這樣的機制，來接收數據。

發生TCP粘包、拆包主要是由于下面一些原因：

既然知道了tcp是無界的數據流，且協議本身無法避免粘包，拆包的發生，那我們只能在應用層數據協議上，加以控制。通常在制定傳輸數據時，可以使用如下方法：

寫了一個簡單的 golang 版的tcp服務器實例，僅供參考：

例子

參考和推薦閱讀書目：

注釋：

eg.

go語言中的tcpconn是阻塞還是非阻塞的

阻塞socket和非阻塞socket的區別： 1、讀操作 對于阻塞的socket,當socket的接收緩沖區中沒有數據時，read調用會一直阻塞住，直到有數據到來才返回。當socket緩沖區中的數據量小于期望讀取的數據量時，返回實際讀取的字節數。

網站欄目：go語言tcpsyn go語言tcp發送圖片
當前鏈接：http://vcdvsql.cn/article26/dooojcg.html

成都網站建設公司_創新互聯，為您提供微信小程序、手機網站建設、網站內鏈、網站策劃、網站排名、做網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯