golang udp編程

用戶數(shù)據(jù)報(bào)協(xié)議（User Datagram Protocol，縮寫為UDP），又稱用戶數(shù)據(jù)報(bào)文協(xié)議，是一個(gè)簡(jiǎn)單的面向數(shù)據(jù)報(bào)(package-oriented)的傳輸層協(xié)議，正式規(guī)范為RFC 768。

創(chuàng)新互聯(lián)主營(yíng)雅安網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,手機(jī)APP定制開發(fā),雅安h5小程序開發(fā)搭建,雅安網(wǎng)站營(yíng)銷推廣歡迎雅安等地區(qū)企業(yè)咨詢

UDP只提供數(shù)據(jù)的不可靠傳遞，它一旦把應(yīng)用程序發(fā)給網(wǎng)絡(luò)層的數(shù)據(jù)發(fā)送出去，就不保留數(shù)據(jù)備份（所以UDP有時(shí)候也被認(rèn)為是不可靠的數(shù)據(jù)報(bào)協(xié)議）。

UDP在IP數(shù)據(jù)報(bào)的頭部?jī)H僅加入了復(fù)用和數(shù)據(jù)校驗(yàn)。

由于缺乏可靠性且屬于非連接導(dǎo)向協(xié)議，UDP應(yīng)用一般必須允許一定量的丟包、出錯(cuò)和復(fù)制粘貼。

1 在接收udp包時(shí)，如果接收包時(shí)給定的buffer太小的話，就要自己解決粘包問題。

2 udp包的發(fā)送和接收不保證一定成功，不保證按正確順序抵達(dá)。

3 如果不允許丟包的情況出現(xiàn)的話，要有重發(fā)機(jī)制來保證，如：反饋機(jī)制確認(rèn)。

服務(wù)端

客戶端

同步socket, 異步socket, 多線程socket， 多進(jìn)程socket

socket常用，本文立足同步和異步socket，以及現(xiàn)有的socketserver庫。

同步socket一般有利用socket庫直接，就可以寫出tcp或udp的套接字

socketserver提供的線程或進(jìn)程方式的socket

利用python 3.5+的asyncio協(xié)議，封裝一個(gè)協(xié)程的socket server ，普通的socket客戶也可以連接。

服務(wù)器端

客戶端

為字節(jié)流加上自定義固定長(zhǎng)度報(bào)頭，報(bào)頭中包含字節(jié)流長(zhǎng)度，然后一次send到對(duì)端，對(duì)端在接收時(shí)，先從緩存中取出定長(zhǎng)的報(bào)頭，然后再取真實(shí)數(shù)據(jù)

構(gòu)造報(bào)頭信息

服務(wù)端

客戶端

粘包，分包都tcp

tcp為什么會(huì)有粘包分包這些情況：

1.服務(wù)端處理不過來

2.客戶端采用優(yōu)化納格爾算法，達(dá)到一定字節(jié)才發(fā)

怎么處理：

1. 客，服雙方確定包頭規(guī)范，根據(jù)包頭的信息取包長(zhǎng)度

2. 客戶端發(fā)送帶上標(biāo)記位，如\n, 服務(wù)端根據(jù)標(biāo)記取包

服務(wù)器端

客戶端

服務(wù)器端

客戶端

服務(wù)器端

客戶端

封裝了socket，而且解決了Io阻塞問題

服務(wù)端

客戶端

客戶端

參考：

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

阻塞socket和非阻塞socket的區(qū)別： 1、讀操作 對(duì)于阻塞的socket,當(dāng)socket的接收緩沖區(qū)中沒有數(shù)據(jù)時(shí)，read調(diào)用會(huì)一直阻塞住，直到有數(shù)據(jù)到來才返回。當(dāng)socket緩沖區(qū)中的數(shù)據(jù)量小于期望讀取的數(shù)據(jù)量時(shí)，返回實(shí)際讀取的字節(jié)數(shù)。

網(wǎng)絡(luò)編程（五）TCP詳解

考慮最簡(jiǎn)單的情況：兩臺(tái)主機(jī)之間的通信。這個(gè)時(shí)候只需要一條網(wǎng)線把兩者連起來，規(guī)定好彼此的硬件接口，如都用 USB、電壓 10v、頻率 2.4GHz 等， 這一層就是物理層，這些規(guī)定就是物理層協(xié)議 。

我們當(dāng)然不滿足于只有兩臺(tái)電腦連接，因此我們可以使用交換機(jī)把多個(gè)電腦連接起來，如下圖：

這樣連接起來的網(wǎng)絡(luò)，稱為局域網(wǎng)，也可以稱為以太網(wǎng)（以太網(wǎng)是局域網(wǎng)的一種）。在這個(gè)網(wǎng)絡(luò)中，我們需要標(biāo)識(shí)每個(gè)機(jī)器，這樣才可以指定要和哪個(gè)機(jī)器通信。這個(gè)標(biāo)識(shí)就是硬件地址 MAC。

硬件地址隨機(jī)器的生產(chǎn)就被確定，永久性唯一。在局域網(wǎng)中，我們需要和另外的機(jī)器通信時(shí)，只需要知道他的硬件地址，交換機(jī)就會(huì)把我們的消息發(fā)送到對(duì)應(yīng)的機(jī)器。

這里我們可以不管底層的網(wǎng)線接口如何發(fā)送，把物理層抽離，在他之上創(chuàng)建一個(gè)新的層次，這就是 數(shù)據(jù)鏈路層 。

我們依然不滿足于局域網(wǎng)的規(guī)模，需要把所有的局域網(wǎng)聯(lián)系起來，這個(gè)時(shí)候就需要用到路由器來連接兩個(gè)局域網(wǎng)：

但是如果我們還是使用硬件地址來作為通信對(duì)象的唯一標(biāo)識(shí)，那么當(dāng)網(wǎng)絡(luò)規(guī)模越來越大，需要記住所有機(jī)器的硬件地址是不現(xiàn)實(shí)的；

同時(shí)，一個(gè)網(wǎng)絡(luò)對(duì)象可能會(huì)頻繁更換設(shè)備，這個(gè)時(shí)候硬件地址表維護(hù)起來更加復(fù)雜。這里使用了一個(gè)新的地址來標(biāo)記一個(gè)網(wǎng)絡(luò)對(duì)象： IP 地址 。

通過一個(gè)簡(jiǎn)單的寄信例子來理解 IP 地址。

我住在北京市，我朋友 A 住在上海市，我要給朋友 A 寫信：

因此，這里 IP 地址就是一個(gè)網(wǎng)絡(luò)接入地址（朋友 A 的住址），我只需要知道目標(biāo) IP 地址，路由器就可以把消息給我?guī)У健?在局域網(wǎng)中，就可以動(dòng)態(tài)維護(hù)一個(gè) MAC 地址與 IP 地址的映射關(guān)系，根據(jù)目的 IP 地址就可以尋找到機(jī)器的 MAC 地址進(jìn)行發(fā)送 。

這樣我們不需管理底層如何去選擇機(jī)器，我們只需要知道 IP 地址，就可以和我們的目標(biāo)進(jìn)行通信。這一層就是 網(wǎng)絡(luò)層 。網(wǎng)絡(luò)層的核心作用就是 提供主機(jī)之間的邏輯通信 。

這樣，在網(wǎng)絡(luò)中的所有主機(jī)，在邏輯上都連接起來了，上層只需要提供目標(biāo) IP 地址和數(shù)據(jù)，網(wǎng)絡(luò)層就可以把消息發(fā)送到對(duì)應(yīng)的主機(jī)。

一個(gè)主機(jī)有多個(gè)進(jìn)程，進(jìn)程之間進(jìn)行不同的網(wǎng)絡(luò)通信，如邊和朋友開黑邊和女朋友聊微信。我的手機(jī)同時(shí)和兩個(gè)不同機(jī)器進(jìn)行通信。

那么當(dāng)我的手機(jī)收到數(shù)據(jù)時(shí)，如何區(qū)分是微信的數(shù)據(jù)，還是王者的數(shù)據(jù)？那么就必須在網(wǎng)絡(luò)層之上再添加一層： 運(yùn)輸層 ：

運(yùn)輸層通過 socket（套接字），將網(wǎng)絡(luò)信息進(jìn)行進(jìn)一步的拆分，不同的應(yīng)用進(jìn)程可以獨(dú)立進(jìn)行網(wǎng)絡(luò)請(qǐng)求，互不干擾。

這就是運(yùn)輸層的最本質(zhì)特點(diǎn)： 提供進(jìn)程之間的邏輯通信 。這里的進(jìn)程可以是主機(jī)之間，也可以是同個(gè)主機(jī)，所以在 android 中，socket 通信也是進(jìn)程通信的一種方式。

現(xiàn)在不同的機(jī)器上的應(yīng)用進(jìn)程之間可以獨(dú)立通信了，那么我們就可以在計(jì)算機(jī)網(wǎng)絡(luò)上開發(fā)出形形式式的應(yīng)用：如 web 網(wǎng)頁的 http，文件傳輸 ftp 等等。這一層稱為 應(yīng)用層 。

應(yīng)用層還可以進(jìn)一步拆分出表示層、會(huì)話層，但他們的本質(zhì)特點(diǎn)都沒有改變： 完成具體的業(yè)務(wù)需求 。和下面的四層相比，他們并不是必須的，可以歸屬到應(yīng)用層中。

最后對(duì)計(jì)網(wǎng)分層進(jìn)行小結(jié)：

這里需要注意的是，分層并不是在物理上的分層，而是邏輯上的分層。通過對(duì)底層邏輯的封裝，使得上層的開發(fā)可以直接依賴底層的功能而無需理會(huì)具體的實(shí)現(xiàn)，簡(jiǎn)便了開發(fā)。

這種分層的思路，也就是責(zé)任鏈設(shè)計(jì)模式，通過層層封裝，把不同的職責(zé)獨(dú)立起來，更加方便開發(fā)、維護(hù)等等。

TCP 并不是把應(yīng)用層傳輸過來的數(shù)據(jù)直接加上首部然后發(fā)送給目標(biāo)，而是把數(shù)據(jù)看成一個(gè)字節(jié) 流，給他們標(biāo)上序號(hào)之后分部分發(fā)送。這就是 TCP 的 面向字節(jié)流 特性：

面向字節(jié)流的好處是無需一次存儲(chǔ)過大的數(shù)據(jù)占用太多內(nèi)存，壞處是無法知道這些字節(jié)代表的意義，例如應(yīng)用層發(fā)送一個(gè)音頻文件和一個(gè)文本文件，對(duì)于 TCP 來說就是一串字節(jié)流，沒有意義可言，這會(huì)導(dǎo)致粘包以及拆包問題，后面講。

前面講到，TCP 是可靠傳輸協(xié)議，也就是，一個(gè)數(shù)據(jù)交給他，他肯定可以完整無誤地發(fā)送到目標(biāo)地址，除非網(wǎng)絡(luò)炸了。他實(shí)現(xiàn)的網(wǎng)絡(luò)模型如下：

對(duì)于應(yīng)用層來說，他就是一個(gè)可靠傳輸?shù)牡讓又С址?wù)；而運(yùn)輸層底層采用了網(wǎng)絡(luò)層的不可靠傳輸。雖然在網(wǎng)絡(luò)層甚至數(shù)據(jù)鏈路層就可以使用協(xié)議來保證數(shù)據(jù)傳輸?shù)目煽啃裕@樣網(wǎng)絡(luò)的設(shè)計(jì)會(huì)更加復(fù)雜、效率會(huì)隨之降低。把數(shù)據(jù)傳輸?shù)目煽啃员ＷC放在運(yùn)輸層，會(huì)更加合適。

可靠傳輸原理的重點(diǎn)總結(jié)一下有： 滑動(dòng)窗口、超時(shí)重傳、累積確認(rèn)、選擇確認(rèn)、連續(xù) ARQ 。

停止等待協(xié)議

要實(shí)現(xiàn)可靠傳輸，最簡(jiǎn)便的方法就是：我發(fā)送一個(gè)數(shù)據(jù)包給你，然后你跟我回復(fù)收到，我繼續(xù)發(fā)送下一個(gè)數(shù)據(jù)包。傳輸模型如下：

這種“一來一去”的方法來保證傳輸可靠就是 停止等待協(xié)議 （stop-and-wait）。不知道還記不記得前面 TCP 首部有一個(gè) ack 字段，當(dāng)他設(shè)置為 1 的時(shí)候，表示這個(gè)報(bào)文是一個(gè)確認(rèn)收到報(bào)文。

然后再來考慮另一種情況：丟包。網(wǎng)絡(luò)環(huán)境不可靠，導(dǎo)致每一次發(fā)送的數(shù)據(jù)包可能會(huì)丟失，如果機(jī)器 A 發(fā)送了數(shù)據(jù)包丟失了，那么機(jī)器 B 永遠(yuǎn)接收不到數(shù)據(jù)，機(jī)器 A 永遠(yuǎn)在等待。

解決這個(gè)問題的方法是： 超時(shí)重傳 。當(dāng)機(jī)器 A 發(fā)出一個(gè)數(shù)據(jù)包時(shí)便開始計(jì)時(shí)，時(shí)間到還沒收到確認(rèn)回復(fù)，就可以認(rèn)為是發(fā)生了丟包，便再次發(fā)送，也就是重傳。

但重傳會(huì)導(dǎo)致另一種問題：如果原先的數(shù)據(jù)包并沒有丟失，只是在網(wǎng)絡(luò)中待的時(shí)間比較久，這個(gè)時(shí)候機(jī)器 B 會(huì)受到兩個(gè)數(shù)據(jù)包，那么機(jī)器 B 是如何辨別這兩個(gè)數(shù)據(jù)包是屬于同一份數(shù)據(jù)還是不同的數(shù)據(jù)？

這就需要前面講過的方法： 給數(shù)據(jù)字節(jié)進(jìn)行編號(hào) 。這樣接收方就可以根據(jù)數(shù)據(jù)的字節(jié)編號(hào)，得出這些數(shù)據(jù)是接下來的數(shù)據(jù)，還是重傳的數(shù)據(jù)。

在 TCP 首部有兩個(gè)字段：序號(hào)和確認(rèn)號(hào)，他們表示發(fā)送方數(shù)據(jù)第一個(gè)字節(jié)的編號(hào)，和接收方期待的下一份數(shù)據(jù)的第一個(gè)字節(jié)的編號(hào)。

停止等待協(xié)議的優(yōu)點(diǎn)是簡(jiǎn)單，但缺點(diǎn)是 信道利用率 太低。

假定AB之間有一條直通的信道來傳送分組

這里的TD是A發(fā)送分組所需要的時(shí)間（顯然TD = 分組長(zhǎng)度 / 數(shù)據(jù)速率）再假定TA是B發(fā)送確認(rèn)分組所需要的時(shí)間（A和B處理分組的時(shí)間都忽略不計(jì)）那么A在經(jīng)過TD+RTT+TA時(shí)間后才能發(fā)送下一個(gè)分組，這里的RTT是往返時(shí)間，因?yàn)橹挥蠺D是采用來傳輸有用的數(shù)據(jù)（這個(gè)數(shù)據(jù)包括了分組首部，如果可以知道傳輸更精確的數(shù)據(jù)的時(shí)間，可以計(jì)算的更精確），所有信道利用率為

為了提高傳輸效率，發(fā)送方可以不使用低效率的停止等待協(xié)議，而是采用 流水線傳輸 ：就是發(fā)送方可以 連續(xù)的發(fā)送多個(gè)分組 ，不必每發(fā)完一個(gè)分組就停下來等待對(duì)方的確認(rèn)。這樣可使信道上一直有數(shù)據(jù)不間斷地在傳送。顯然這種傳輸方式可以獲得很高的信道利用率

停止等待協(xié)議已經(jīng)可以滿足可靠傳輸了，但有一個(gè)致命缺點(diǎn)： 效率太低 。發(fā)送方發(fā)送一個(gè)數(shù)據(jù)包之后便進(jìn)入等待，這個(gè)期間并沒有干任何事，浪費(fèi)了資源。解決的方法是： 連續(xù)發(fā)送數(shù)據(jù)包 。

也就是下面介紹的 連續(xù)ARQ協(xié)議 和 滑動(dòng)窗口協(xié)議

連續(xù) ARQ 協(xié)議

模型如下：

和停止等待最大的不同就是，他會(huì)源源不斷地發(fā)送，接收方源源不斷收到數(shù)據(jù)之后，逐一進(jìn)行確認(rèn)回復(fù)。這樣便極大地提高了效率。但同樣，帶來了一些額外的問題:

發(fā)送是否可以無限發(fā)送直到把緩沖區(qū)所有數(shù)據(jù)發(fā)送完？不可以。因?yàn)樾枰紤]接收方緩沖區(qū)以及讀取數(shù)據(jù)的能力。如果發(fā)送太快導(dǎo)致接收方無法接受，那么只是會(huì)頻繁進(jìn)行重傳，浪費(fèi)了網(wǎng)絡(luò)資源。所以發(fā)送方發(fā)送數(shù)據(jù)的范圍，需要考慮到接收方緩沖區(qū)的情況。這就是 TCP 的 流量控制 。

解決方法是： 滑動(dòng)窗口 。基本模型如下：

在 TCP 的首部有一個(gè)窗口大小字段，他表示接收方的剩余緩沖區(qū)大小，讓發(fā)送方可以調(diào)整自己的發(fā)送窗口大小。通過滑動(dòng)窗口，就可以實(shí)現(xiàn) TCP 的流量控制，不至于發(fā)送太快，導(dǎo)致太多的數(shù)據(jù)丟失。

連續(xù) ARQ 帶來的第二個(gè)問題是：網(wǎng)絡(luò)中充斥著和發(fā)送數(shù)據(jù)包一樣數(shù)據(jù)量的確認(rèn)回復(fù)報(bào)文，因?yàn)槊恳粋€(gè)發(fā)送數(shù)據(jù)包，必須得有一個(gè)確認(rèn)回復(fù)。提高網(wǎng)絡(luò)效率的方法是： 累積確認(rèn) 。

接收方不需要逐個(gè)進(jìn)行回復(fù)，而是累積到一定量的數(shù)據(jù)包之后，告訴發(fā)送方，在此數(shù)據(jù)包之前的數(shù)據(jù)全都收到。例如，收到 1234，接收方只需要告訴發(fā)送方我收到 4 了，那么發(fā)送方就知道 1234 都收到了。

第三個(gè)問題是：如何處理丟包情況。在停止等待協(xié)議中很簡(jiǎn)單，直接一個(gè)超時(shí)重傳就解決了。但，連續(xù) ARQ 中不太一樣。

例如：接收方收到了 123 567，六個(gè)字節(jié)，編號(hào)為 4 的字節(jié)丟失了。按照累積確認(rèn)的思路，只能發(fā)送 3 的確認(rèn)回復(fù)，567 都必須丟掉，因?yàn)榘l(fā)送方會(huì)進(jìn)行重傳。這就是 GBN（go-back-n) 思路。

但是我們會(huì)發(fā)現(xiàn)，只需要重傳 4 即可，這樣不是很浪費(fèi)資源，所以就有了： 選擇確認(rèn) SACK 。在 TCP 報(bào)文的選項(xiàng)字段，可以設(shè)置已經(jīng)收到的報(bào)文段，每一個(gè)報(bào)文段需要兩個(gè)邊界來進(jìn)行確定。這樣發(fā)送方，就可以根據(jù)這個(gè)選項(xiàng)字段只重傳丟失的數(shù)據(jù)了。

第四個(gè)問題是：擁塞控制的問題

也是通過窗口的大小來控制的，但是檢測(cè)網(wǎng)絡(luò)滿不滿是個(gè)挺難的事情，所以 TCP 發(fā)送包經(jīng)常被比喻成往誰管理灌水，所以擁塞控制就是在不堵塞，不丟包的情況下盡可能的發(fā)揮帶寬。

水管有粗細(xì)，網(wǎng)絡(luò)有帶寬，即每秒鐘能發(fā)送多少數(shù)據(jù)；水管有長(zhǎng)度，端到端有時(shí)延。理想狀態(tài)下，水管里面的水 = 水管粗細(xì) * 水管長(zhǎng)度。對(duì)于網(wǎng)絡(luò)上，通道的容量 = 帶寬 * 往返時(shí)延。

如果我們?cè)O(shè)置發(fā)送窗口，使得發(fā)送但未確認(rèn)的包為通道的容量，就能撐滿整個(gè)管道。

如圖所示，假設(shè)往返時(shí)間為 8 秒，去 4 秒，回 4 秒，每秒發(fā)送一個(gè)包，已經(jīng)過去了 8 秒，則 8 個(gè)包都發(fā)出去了，其中前四個(gè)已經(jīng)到達(dá)接收端，但是 ACK 還沒返回，不能算發(fā)送成功，5-8 后四個(gè)包還在路上，還沒被接收，這個(gè)時(shí)候，管道正好撐滿，在發(fā)送端，已發(fā)送未確認(rèn)的 8 個(gè)包，正好等于帶寬，也即每秒發(fā)送一個(gè)包，也即每秒發(fā)送一個(gè)包，乘以來回時(shí)間 8 秒。

如果在這個(gè)基礎(chǔ)上調(diào)大窗口，使得單位時(shí)間可以發(fā)送更多的包，那么會(huì)出現(xiàn)接收端處理不過來，多出來的包會(huì)被丟棄，這個(gè)時(shí)候，我們可以增加一個(gè)緩存，但是緩存里面的包 4 秒內(nèi)肯定達(dá)不到接收端課，它的缺點(diǎn)會(huì)增加時(shí)延，如果時(shí)延達(dá)到一定程度就會(huì)超時(shí)重傳

TCP 擁塞控制主要來避免兩種現(xiàn)象，包丟失和超時(shí)重傳，一旦出現(xiàn)了這些現(xiàn)象說明發(fā)送的太快了，要慢一點(diǎn)。

具體的方法就是發(fā)送端慢啟動(dòng)，比如倒水，剛開始倒的很慢，漸漸變快。然后設(shè)置一個(gè)閾值，當(dāng)超過這個(gè)值的時(shí)候就要慢下來

慢下來還是在增長(zhǎng)，這時(shí)候就可能水滿則溢，出現(xiàn)擁塞，需要降低倒水的速度，等水慢慢滲下去。

擁塞的一種表現(xiàn)是丟包，需要超時(shí)重傳，這個(gè)時(shí)候，采用快速重傳算法，將當(dāng)前速度變?yōu)橐话搿Ｋ运俣冗€是在比較高的值，也沒有一夜回到解放前。

到這里關(guān)于 TCP 的可靠傳輸原理就已經(jīng)介紹得差不多。最后進(jìn)行一個(gè)小結(jié)：

當(dāng)然，這只是可靠傳輸?shù)谋揭唤牵信d趣可以再深入去研究

一文梳理HTTP、TCP、Socket和WebSocket的區(qū)別和聯(lián)系

第一層：應(yīng)用層，定義了用于在網(wǎng)絡(luò)中進(jìn)行通信和傳輸數(shù)據(jù)的接口；（Http協(xié)議位于該層）

第二層：表示層，定義不同系統(tǒng)中數(shù)據(jù)的傳輸格式，編碼和解碼規(guī)范等；

第三層：會(huì)話層，管理用戶的會(huì)話，控制用戶間邏輯連接的建立和中斷；

第四層：傳輸層，管理著網(wǎng)絡(luò)中端到端的數(shù)據(jù)傳輸；（Tcp協(xié)議位于該層）

第五層：網(wǎng)絡(luò)層，定義網(wǎng)絡(luò)設(shè)備間如何傳輸數(shù)據(jù)；（IP位于該層）

第六層：鏈路層，將上面的網(wǎng)絡(luò)層的數(shù)據(jù)包封裝成數(shù)據(jù)幀，便于物理層傳輸；

第七層：物理層，這一層主要就是傳輸這些二進(jìn)制數(shù)據(jù)。

建立起一個(gè) TCP 連接需要經(jīng)過“ 三次握手 ”：

握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前，TCP 連接都將被一直保持下去。斷開連接時(shí)服務(wù)器和客戶端均可以主動(dòng)發(fā)起斷開TCP連接的請(qǐng)求。

SYN攻擊就是利用三次握手的第二次握手時(shí)進(jìn)行的，這時(shí)候服務(wù)器處于SYN_RECV狀態(tài)，等待客戶端進(jìn)行確認(rèn)ACK，SYN會(huì)偽造不存在的源IP，就會(huì)有大量的鏈接處于等待或重試發(fā)送SYN+ACK包，導(dǎo)致該階段隊(duì)列持續(xù)增長(zhǎng)，進(jìn)而導(dǎo)致后續(xù)正常請(qǐng)求被丟棄。

HTTP協(xié)議即超文本傳送協(xié)議(Hypertext Transfer Protocol )，是Web聯(lián)網(wǎng)的基礎(chǔ)，也是手機(jī)聯(lián)網(wǎng)常用的協(xié)議之一，HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。

HTTP連接最顯著的特點(diǎn)是客戶端發(fā)送的每次請(qǐng)求都需要服務(wù)器回送響應(yīng)，在請(qǐng)求結(jié)束后，會(huì)主動(dòng)釋放連接。從建立連接到關(guān)閉連接的過程稱為“一次連接”。

由于HTTP在每次請(qǐng)求結(jié)束后都會(huì)主動(dòng)釋放連接，因此HTTP連接是一種“短連接”。

要保持客戶端程序的在線狀態(tài)，需要不斷地向服務(wù)器發(fā)起連接請(qǐng)求，通常情況下即使不需要獲得任何數(shù)據(jù)，客戶端也保持每隔一段固定的時(shí)間向服務(wù)器發(fā)送一次“保持連接”的請(qǐng)求，服務(wù)器在收到該請(qǐng)求后對(duì)客戶端進(jìn)行回復(fù)，表明知道客戶端“在線”。若服務(wù)器長(zhǎng)時(shí)間無法收到客戶端的請(qǐng)求，則認(rèn)為客戶端“下線”，若客戶端長(zhǎng)時(shí)間無法收到服務(wù)器的回復(fù)，則認(rèn)為網(wǎng)絡(luò)已經(jīng)斷開。

通常情況下Socket連接就是TCP連接，因此Socket連接一旦建立，通信雙方即可開始相互發(fā)送數(shù)據(jù)內(nèi)容，直到雙方連接斷開。但在實(shí)際網(wǎng)絡(luò)應(yīng)用中，客戶端到服務(wù)器之間的通信往往需要穿越多個(gè)中間節(jié)點(diǎn)，例如路由器、網(wǎng)關(guān)、防火墻等，大部分防火墻默認(rèn)會(huì)關(guān)閉長(zhǎng)時(shí)間處于非活躍狀態(tài)的連接而導(dǎo)致 Socket 連接斷連，因此需要通過輪詢告訴網(wǎng)絡(luò)，該連接處于活躍狀態(tài)。

而HTTP連接使用的是“請(qǐng)求—響應(yīng)”的方式，不僅在請(qǐng)求時(shí)需要先建立連接，而且需要客戶端向服務(wù)器發(fā)出請(qǐng)求后，服務(wù)器端才能回復(fù)數(shù)據(jù)。

很多情況下，需要服務(wù)器端主動(dòng)向客戶端推送數(shù)據(jù)，保持客戶端與服務(wù)器數(shù)據(jù)的實(shí)時(shí)與同步。此時(shí)若雙方建立的是Socket連接，服務(wù)器就可以直接將數(shù)據(jù)傳送給客戶端；若雙方建立的是HTTP連接，則服務(wù)器需要等到客戶端發(fā)送一次請(qǐng)求后才能將數(shù)據(jù)傳回給客戶端，因此，客戶端定時(shí)向服務(wù)器端發(fā)送連接請(qǐng)求，不僅可以保持在線，同時(shí)也是在“詢問”服務(wù)器是否有新的數(shù)據(jù)，如果有就將數(shù)據(jù)傳給客戶端。

相關(guān)視頻推薦

看完《tcp/ip詳解》不能coding的，一次課開啟設(shè)計(jì)tcp/ip協(xié)議棧

深入聊聊websocket協(xié)議，tcp分包與粘包解決方案

學(xué)習(xí)地址：C/C++Linux服務(wù)器開發(fā)/后臺(tái)架構(gòu)師【零聲教育】-學(xué)習(xí)視頻教程-騰訊課堂

需要C/C++ Linux服務(wù)器架構(gòu)師學(xué)習(xí)資料加qun 812855908 獲取（資料包括 C/C++，Linux，golang技術(shù)，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協(xié)程，DPDK，ffmpeg 等），免費(fèi)分享

創(chuàng)建Socket連接時(shí)，可以指定使用的傳輸層協(xié)議，Socket可以支持不同的傳輸層協(xié)議（TCP或UDP），當(dāng)使用TCP協(xié)議進(jìn)行連接時(shí)，該Socket連接就是一個(gè)TCP連接。

socket則是對(duì)TCP/IP協(xié)議的封裝和應(yīng)用（程序員層面上）。也可以說，TPC/IP協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸，而HTTP是應(yīng)用層協(xié)議，主要解決如何包裝數(shù)據(jù)。

關(guān)于TCP/IP和HTTP協(xié)議的關(guān)系，網(wǎng)絡(luò)有一段比較容易理解的介紹：

平時(shí)說的最多的socket是什么呢，實(shí)際上socket是對(duì)TCP/IP協(xié)議的封裝，Socket本身并不是協(xié)議，而是一個(gè)調(diào)用接口（API），通過Socket，才能使用TCP/IP協(xié)議。

實(shí)際上，Socket跟TCP/IP協(xié)議沒有必然的聯(lián)系。Socket編程接口在設(shè)計(jì)的時(shí)候，就希望也能適應(yīng)其他的網(wǎng)絡(luò)協(xié)議。所以說，Socket的出現(xiàn) 只是使得程序員更方便地使用TCP/IP協(xié)議棧而已，是對(duì)TCP/IP協(xié)議的抽象，從而形成了一些最基本的函數(shù)接口，比如create、 listen、connect、accept、send、read和write等等。

實(shí)際上，傳輸層 TCP 是基于網(wǎng)絡(luò)層 IP 協(xié)議的，而應(yīng)用層 HTTP 協(xié)議又是基于傳輸層 TCP 協(xié)議的，而 Socket 本身不算是協(xié)議，就像上面所說，它只是提供了一個(gè)針對(duì) TCP 或者 UDP 編程的接口。

總結(jié)：

Socket 其實(shí)并不是一個(gè)協(xié)議，而是為了方便使用 TCP/UDP 而抽象出來的一層，是位于應(yīng)用層和傳輸控制層之間的一組接口。

當(dāng)兩臺(tái)主機(jī)通信時(shí)，必須通過Socket連接，Socket則利用TCP/IP協(xié)議建立TCP連接。TCP連接則更依靠于底層的IP協(xié)議，IP協(xié)議的連接則依賴于鏈路層等更低層次。

WebSocket就像HTTP一樣，是一個(gè)典型的應(yīng)用層協(xié)議。

總結(jié)：

WebSocket是HTML5規(guī)范提出的一種協(xié)議。HTML5 Web Sockets規(guī)范定義了Web Sockets API，支持頁面使用Web Socket協(xié)議與遠(yuǎn)程主機(jī)進(jìn)行全雙工的通信。它引入了WebSocket接口并且定義了一個(gè)全雙工的通信通道，通過一個(gè)單一的套接字在Web上進(jìn)行操作。

HTML5 Web Sockets以最小的開銷高效地提供了Web連接。相較于經(jīng)常需要使用推送實(shí)時(shí)數(shù)據(jù)到客戶端甚至通過維護(hù)兩個(gè)HTTP連接來模擬全雙工連接的舊的輪詢或長(zhǎng)輪詢（Comet）來說，這就極大的減少了不必要的網(wǎng)絡(luò)流量與延遲。

相同點(diǎn)：

不同點(diǎn)：

聯(lián)系：

WebSocket連接的過程：

總結(jié)：

分享題目：go語言socket粘包,go socket粘包
分享URL：http://chinadenli.net/article36/dsgdhsg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、動(dòng)態(tài)網(wǎng)站、企業(yè)建站、企業(yè)網(wǎng)站制作、響應(yīng)式網(wǎng)站、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)