久久综合五月天,男生操女生的动漫,开心色国产,男女做爰猛烈叫床视频大全,国产肏逼,国产69精品久久久久777糖心,毛片视频免费,无码av网站

點(diǎn)擊關(guān)注公眾號，回復(fù)“2T”獲取2TB學(xué)習(xí)資源！

互聯(lián)網(wǎng)架構(gòu)師后臺回復(fù) 2T 有特別禮包

作者：數(shù)瀾科技
鏈接：https://www.jianshu.com/p/e47a766e03da

前言：作為一名開發(fā)人員我們經(jīng)常會聽到HTTP協(xié)議、TCP/IP協(xié)議、UDP協(xié)議、Socket、Socket長連接、Socket連接池等字眼，然而它們之間的關(guān)系、區(qū)別及原理并不是所有人都能理解清楚，這篇文章就從網(wǎng)絡(luò)協(xié)議基礎(chǔ)開始到Socket連接池，一步一步解釋他們之間的關(guān)系。

七層網(wǎng)絡(luò)模型

首先從網(wǎng)絡(luò)通信的分層模型講起：七層模型，亦稱OSI(Open System Interconnection)模型。自下往上分為：物理層、據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層和應(yīng)用層。所有有關(guān)通信的都離不開它，下面這張圖片介紹了各層所對應(yīng)的一些協(xié)議和硬件。

通過上圖，我知道IP協(xié)議對應(yīng)于網(wǎng)絡(luò)層，TCP、UDP協(xié)議對應(yīng)于傳輸層，而HTTP協(xié)議對應(yīng)于應(yīng)用層，OSI并沒有Socket，那什么是Socket，后面我們將結(jié)合代碼具體詳細(xì)介紹。

TCP和UDP連接

關(guān)于傳輸層TCP、UDP協(xié)議可能我們平時遇見的會比較多，有人說TCP是安全的，UDP是不安全的，UDP傳輸比TCP快，那為什么呢，我們先從TCP的連接建立的過程開始分析，然后解釋UDP和TCP的區(qū)別。

TCP的三次握手和四次分手

我們知道TCP建立連接需要經(jīng)過三次握手，而斷開連接需要經(jīng)過四次分手，那三次握手和四次分手分別做了什么和如何進(jìn)行的。

第一次握手:建立連接?？蛻舳税l(fā)送連接請求報文段，將SYN位置為1，Sequence Number為x；然后，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器的確認(rèn)；

第二次握手:服務(wù)器收到客戶端的SYN報文段，需要對這個SYN報文段進(jìn)行確認(rèn)，設(shè)置Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要發(fā)送SYN請求信息，將SYN位置為1，Sequence Number為y；服務(wù)器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一并發(fā)送給客戶端，此時服務(wù)器進(jìn)入SYN_RECV狀態(tài)；

第三次握手:客戶端收到服務(wù)器的SYN+ACK報文段。然后將Acknowledgment Number設(shè)置為y+1，向服務(wù)器發(fā)送ACK報文段，這個報文段發(fā)送完畢以后，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。

完成了三次握手，客戶端和服務(wù)器端就可以開始傳送數(shù)據(jù)。以上就是TCP三次握手的總體介紹。通信結(jié)束客戶端和服務(wù)端就斷開連接，需要經(jīng)過四次分手確認(rèn)。

第一次分手：主機(jī)1（可以使客戶端，也可以是服務(wù)器端），設(shè)置Sequence Number和Acknowledgment Number，向主機(jī)2發(fā)送一個FIN報文段；此時，主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)；這表示主機(jī)1沒有數(shù)據(jù)要發(fā)送給主機(jī)2了；

第二次分手：主機(jī)2收到了主機(jī)1發(fā)送的FIN報文段，向主機(jī)1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)；主機(jī)2告訴主機(jī)1，我“同意”你的關(guān)閉請求；

第三次分手：主機(jī)2向主機(jī)1發(fā)送FIN報文段，請求關(guān)閉連接，同時主機(jī)2進(jìn)入LAST_ACK狀態(tài)；

第四次分手：主機(jī)1收到主機(jī)2發(fā)送的FIN報文段，向主機(jī)2發(fā)送ACK報文段，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài)；主機(jī)2收到主機(jī)1的ACK報文段以后，就關(guān)閉連接；此時，主機(jī)1等待2MSL后依然沒有收到回復(fù)，則證明Server端已正常關(guān)閉，那好，主機(jī)1也可以關(guān)閉連接了。

可以看到一次tcp請求的建立及關(guān)閉至少進(jìn)行7次通信，這還不包過數(shù)據(jù)的通信，而UDP不需3次握手和4次分手。

TCP和UDP的區(qū)別

TCP是面向鏈接的，雖然說網(wǎng)絡(luò)的不安全不穩(wěn)定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上(實(shí)際上也很大程度上保證了)保證了連接的可靠性;而UDP不是面向連接的，UDP傳送數(shù)據(jù)前并不與對方建立連接，對接收到的數(shù)據(jù)也不發(fā)送確認(rèn)信號，發(fā)送端不知道數(shù)據(jù)是否會正確接收，當(dāng)然也不用重發(fā)，所以說UDP是無連接的、不可靠的一種數(shù)據(jù)傳輸協(xié)議。
也正由于1所說的特點(diǎn)，使得UDP的開銷更小數(shù)據(jù)傳輸速率更高，因?yàn)椴槐剡M(jìn)行收發(fā)數(shù)據(jù)的確認(rèn)，所以UDP的實(shí)時性更好。知道了TCP和UDP的區(qū)別，就不難理解為何采用TCP傳輸協(xié)議的MSN比采用UDP的QQ傳輸文件慢了，但并不能說QQ的通信是不安全的，因?yàn)槌绦騿T可以手動對UDP的數(shù)據(jù)收發(fā)進(jìn)行驗(yàn)證，比如發(fā)送方對每個數(shù)據(jù)包進(jìn)行編號然后由接收方進(jìn)行驗(yàn)證啊什么的，即使是這樣，UDP因?yàn)樵诘讓訁f(xié)議的封裝上沒有采用類似TCP的“三次握手”而實(shí)現(xiàn)了TCP所無法達(dá)到的傳輸效率。

問題

關(guān)于傳輸層我們會經(jīng)常聽到一些問題

1．TCP服務(wù)器最大并發(fā)連接數(shù)是多少？

關(guān)于TCP服務(wù)器最大并發(fā)連接數(shù)有一種誤解就是“因?yàn)槎丝谔柹舷逓?5535,所以TCP服務(wù)器理論上的可承載的最大并發(fā)連接數(shù)也是65535”。首先需要理解一條TCP連接的組成部分：客戶端IP、客戶端端口、服務(wù)端IP、服務(wù)端端口。所以對于TCP服務(wù)端進(jìn)程來說，他可以同時連接的客戶端數(shù)量并不受限于可用端口號，理論上一個服務(wù)器的一個端口能建立的連接數(shù)是全球的IP數(shù)*每臺機(jī)器的端口數(shù)。實(shí)際并發(fā)連接數(shù)受限于linux可打開文件數(shù)，這個數(shù)是可以配置的，可以非常大，所以實(shí)際上受限于系統(tǒng)性能。通過#ulimit -n查看服務(wù)的最大文件句柄數(shù)，通過ulimit -n xxx 修改 xxx是你想要能打開的數(shù)量。也可以通過修改系統(tǒng)參數(shù)：

2．為什么TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀態(tài)？

這是因?yàn)殡m然雙方都同意關(guān)閉連接了，而且握手的4個報文也都協(xié)調(diào)和發(fā)送完畢，按理可以直接回到CLOSED狀態(tài)（就好比從SYN_SEND狀態(tài)到ESTABLISH狀態(tài)那樣）；但是因?yàn)槲覀儽仨氁傧刖W(wǎng)絡(luò)是不可靠的，你無法保證你最后發(fā)送的ACK報文會一定被對方收到，因此對方處于LAST_ACK狀態(tài)下的Socket可能會因?yàn)槌瑫r未收到ACK報文，而重發(fā)FIN報文，所以這個TIME_WAIT狀態(tài)的作用就是用來重發(fā)可能丟失的ACK報文。

3．TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀態(tài)會產(chǎn)生什么問題

通信雙方建立TCP連接后，主動關(guān)閉連接的一方就會進(jìn)入TIME_WAIT狀態(tài)，TIME_WAIT狀態(tài)維持時間是兩個MSL時間長度，也就是在1-4分鐘，Windows操作系統(tǒng)就是4分鐘。進(jìn)入TIME_WAIT狀態(tài)的一般情況下是客戶端，一個TIME_WAIT狀態(tài)的連接就占用了一個本地端口。一臺機(jī)器上端口號數(shù)量的上限是65536個，如果在同一臺機(jī)器上進(jìn)行壓力測試模擬上萬的客戶請求，并且循環(huán)與服務(wù)端進(jìn)行短連接通信，那么這臺機(jī)器將產(chǎn)生4000個左右的TIME_WAIT Socket，后續(xù)的短連接就會產(chǎn)生address already in use : connect的異常，如果使用Nginx作為方向代理也需要考慮TIME_WAIT狀態(tài)，發(fā)現(xiàn)系統(tǒng)存在大量TIME_WAIT狀態(tài)的連接，通過調(diào)整內(nèi)核參數(shù)解決。

編輯文件，加入以下內(nèi)容：

然后執(zhí)行 /sbin/sysctl -p 讓參數(shù)生效。

net.ipv4.tcp_syncookies = 1 表示開啟SYN Cookies。當(dāng)出現(xiàn)SYN等待隊(duì)列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認(rèn)為0，表示關(guān)閉；

net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉；

net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認(rèn)為0，表示關(guān)閉。

net.ipv4.tcp_fin_timeout 修改系統(tǒng)默認(rèn)的TIMEOUT時間。

Socket長連接

所謂長連接，指在一個TCP連接上可以連續(xù)發(fā)送多個數(shù)據(jù)包，在TCP連接保持期間，如果沒有數(shù)據(jù)包發(fā)送，需要雙方發(fā)檢測包以維持此連接(心跳包)，一般需要自己做在線維持。短連接是指通信雙方有數(shù)據(jù)交互時，就建立一個TCP連接，數(shù)據(jù)發(fā)送完成后，則斷開此TCP連接。比如Http的，只是連接、請求、關(guān)閉，過程時間較短,服務(wù)器若是一段時間內(nèi)沒有收到請求即可關(guān)閉連接。其實(shí)長連接是相對于通常的短連接而說的，也就是長時間保持客戶端與服務(wù)端的連接狀態(tài)。

通常的短連接操作步驟是：

連接→數(shù)據(jù)傳輸→關(guān)閉連接；

而長連接通常就是：

連接→數(shù)據(jù)傳輸→保持連接(心跳)→數(shù)據(jù)傳輸→保持連接(心跳)→……→關(guān)閉連接；

什么時候用長連接，短連接？

長連接多用于操作頻繁，點(diǎn)對點(diǎn)的通訊，而且連接數(shù)不能太多情況，。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，次處理時直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接，如果用短連接頻繁的通信會造成Socket錯誤，而且頻繁的Socket創(chuàng)建也是對資源的浪費(fèi)。

什么是心跳包為什么需要：

心跳包就是在客戶端和服務(wù)端間定時通知對方自己狀態(tài)的一個自己定義的命令字，按照一定的時間間隔發(fā)送，類似于心跳，所以叫做心跳包。網(wǎng)絡(luò)中的接收和發(fā)送數(shù)據(jù)都是使用Socket進(jìn)行實(shí)現(xiàn)。但是如果此套接字已經(jīng)斷開（比如一方斷網(wǎng)了），那發(fā)送數(shù)據(jù)和接收數(shù)據(jù)的時候就一定會有問題?？墒侨绾闻袛噙@個套接字是否還可以使用呢？這個就需要在系統(tǒng)中創(chuàng)建心跳機(jī)制。其實(shí)TCP中已經(jīng)為我們實(shí)現(xiàn)了一個叫做心跳的機(jī)制。另外搜索公眾號互聯(lián)網(wǎng)架構(gòu)師后臺回復(fù)“2T”，獲取一份驚喜禮包。如果你設(shè)置了心跳，那TCP就會在一定的時間（比如你設(shè)置的是3秒鐘）內(nèi)發(fā)送你設(shè)置的次數(shù)的心跳（比如說2次），并且此信息不會影響你自己定義的協(xié)議。也可以自己定義，所謂“心跳”就是定時發(fā)送一個自定義的結(jié)構(gòu)體（心跳包或心跳幀），讓對方知道自己“在線”,以確保鏈接的有效性。

實(shí)現(xiàn)：

服務(wù)端：

服務(wù)端輸出結(jié)果：

客戶端代碼：

客戶端輸出結(jié)果：

定義自己的協(xié)議

如果想要使傳輸?shù)臄?shù)據(jù)有意義，則必須使用到應(yīng)用層協(xié)議比如Http、Mqtt、Dubbo等?；赥CP協(xié)議上自定義自己的應(yīng)用層的協(xié)議需要解決的幾個問題：

心跳包格式的定義及處理
報文頭的定義，就是你發(fā)送數(shù)據(jù)的時候需要先發(fā)送報文頭，報文里面能解析出你將要發(fā)送的數(shù)據(jù)長度
你發(fā)送數(shù)據(jù)包的格式，是json的還是其他序列化的方式

下面我們就一起來定義自己的協(xié)議，并編寫服務(wù)的和客戶端進(jìn)行調(diào)用：

定義報文頭格式：length:000000000xxxx; xxxx代表數(shù)據(jù)的長度，總長度20,舉例子不嚴(yán)謹(jǐn)。

數(shù)據(jù)序列化方式：JSON。

服務(wù)端:

日志打印：

客戶端

日志打?。?/span>

這里可以看到一個客戶端在同一個時間內(nèi)處理一個請求可以很好的工作，但是想象這么一個場景，如果同一時間內(nèi)讓同一個客戶端去多次調(diào)用服務(wù)端請求，發(fā)送多次頭數(shù)據(jù)和內(nèi)容數(shù)據(jù)，服務(wù)端的data事件收到的數(shù)據(jù)就很難區(qū)別哪些數(shù)據(jù)是哪次請求的，比如兩次頭數(shù)據(jù)同時到達(dá)服務(wù)端，服務(wù)端就會忽略其中一次，而后面的內(nèi)容數(shù)據(jù)也不一定就對應(yīng)于這個頭的。所以想復(fù)用長連接并能很好的高并發(fā)處理服務(wù)端請求，就需要連接池這種方式了。

Socket連接池

什么是Socket連接池,池的概念可以聯(lián)想到是一種資源的集合，所以Socket連接池，就是維護(hù)著一定數(shù)量Socket長連接的集合。它能自動檢測Socket長連接的有效性，剔除無效的連接，補(bǔ)充連接池的長連接的數(shù)量。從代碼層次上其實(shí)是人為實(shí)現(xiàn)這種功能的類，一般一個連接池包含下面幾個屬性：

空閑可使用的長連接隊(duì)列
正在運(yùn)行的通信的長連接隊(duì)列
等待去獲取一個空閑長連接的請求的隊(duì)列
無效長連接的剔除功能
長連接資源池的數(shù)量配置
長連接資源的新建功能

場景：一個請求過來，首先去資源池要求獲取一個長連接資源，如果空閑隊(duì)列里面有長連接，就獲取到這個長連接Socket,并把這個Socket移到正在運(yùn)行的長連接隊(duì)列。如果空閑隊(duì)列里面沒有，且正在運(yùn)行的隊(duì)列長度小于配置的連接池資源的數(shù)量，就新建一個長連接到正在運(yùn)行的隊(duì)列去，如果正在運(yùn)行的不下于配置的資源池長度，則這個請求進(jìn)入到等待隊(duì)列去。另外搜索公眾號互聯(lián)網(wǎng)架構(gòu)師后臺回復(fù)“2T”，獲取一份驚喜禮包。當(dāng)一個正在運(yùn)行的Socket完成了請求，就從正在運(yùn)行的隊(duì)列移到空閑的隊(duì)列，并觸發(fā)等待請求隊(duì)列去獲取空閑資源，如果有等待的情況。

下面簡單介紹Node.js的一個通用連接池模塊：generic-pool。

主要文件目錄結(jié)構(gòu)