摘要：很多人都知道協(xié)議是基于協(xié)議創(chuàng)造出來(lái)的采用文本方式傳輸非二進(jìn)制傳輸?shù)膽?yīng)用層協(xié)議，協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸，而應(yīng)用層協(xié)議，主要解決如何包裝和規(guī)范數(shù)據(jù)。你也可以自己定義應(yīng)用層協(xié)議，只不過(guò)所有配套的東西都要自己重新造輪子。

從問(wèn)題切入能幫我們更好地理解晦澀難懂的概念。很多人都知道http協(xié)議是基于Tcp協(xié)議創(chuàng)造出來(lái)的采用文本方式傳輸（非二進(jìn)制傳輸）的應(yīng)用層協(xié)議，TPC/IP協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸，而應(yīng)用層協(xié)議，主要解決如何包裝和規(guī)范數(shù)據(jù)。那不經(jīng)過(guò)應(yīng)用層協(xié)議就不能傳遞數(shù)據(jù)了嗎，當(dāng)然可以只使用（傳輸層）TCP/IP協(xié)議，但那就像你寫(xiě)了一堆字，卻不按語(yǔ)法來(lái)寫(xiě)，別人即使看到你的文章，卻完全不知道你想表達(dá)什么，應(yīng)用層協(xié)議就相當(dāng)于語(yǔ)言中的語(yǔ)法。

應(yīng)用層協(xié)議有很多，比如HTTP（超文本傳輸協(xié)議）、FTP（文件傳輸協(xié)議）、TELNET（遠(yuǎn)程登錄協(xié)議）、SMTP（郵件傳輸協(xié)議）等?，F(xiàn)代瀏覽器默認(rèn)都支持http協(xié)議，也有專門(mén)為http協(xié)議定制的http服務(wù)器。你也可以自己定義應(yīng)用層協(xié)議，只不過(guò)所有配套的東西都要自己重新造輪子。

在TCP/IP協(xié)議中,要提供可靠的連接服務(wù),需要采用三次握手建立一個(gè)可靠連接，為什么建立可靠連接需要三次握手？客戶端發(fā)起，服務(wù)端響應(yīng)，不是兩次握手就可以建立連接了嗎？假設(shè)沒(méi)有第三次握手，客戶端發(fā)出連接請(qǐng)求A，由于網(wǎng)絡(luò)原因，服務(wù)端并沒(méi)有收到A，于是客戶端又發(fā)送了連接請(qǐng)求B，并建立了連接，完成通信，斷開(kāi)連接。這時(shí)候，服務(wù)端突然又收到了A，于是看作是一次新的連接請(qǐng)求，進(jìn)行第二次握手，由于不存在第三次握手，所以這時(shí)已經(jīng)建立了TCP連接。但實(shí)際上客戶端并沒(méi)有發(fā)起連接，所以不會(huì)傳遞數(shù)據(jù)，服務(wù)端卻一直在等待客戶端發(fā)數(shù)據(jù)過(guò)來(lái)，那么這條連接就會(huì)變成一條死連接，造成很大的資源浪費(fèi)。所以第三次握手的必要性：防止已失效的請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端而造成連接的誤判。

斷開(kāi)一個(gè)TCP連接時(shí)，需要客戶端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開(kāi)，即四次揮手確認(rèn)斷開(kāi)一個(gè)連接。為什么是四次揮手呢，客戶端發(fā)起，服務(wù)端響應(yīng)，再加一次前面說(shuō)到的確認(rèn)，三次就可以完成了呀。

TCP協(xié)議是全雙工協(xié)議，就是說(shuō)雙方都可以同時(shí)向?qū)Ψ桨l(fā)送或接收數(shù)據(jù)。當(dāng)有一方要關(guān)閉連接時(shí)，會(huì)發(fā)送指令告知對(duì)方，我要關(guān)閉連接了。這時(shí)對(duì)方會(huì)回一個(gè)ACK，此時(shí)一個(gè)方向的連接關(guān)閉（此時(shí)2次揮手了）。但是另一個(gè)方向仍然可以繼續(xù)傳輸數(shù)據(jù)，等到發(fā)送完了所有的數(shù)據(jù)后，會(huì)發(fā)送一個(gè)FIN段來(lái)關(guān)閉此方向上的連接，接收方發(fā)送ACK確認(rèn)關(guān)閉連接（此時(shí)4次揮手了）。

最后看一下通信領(lǐng)域常見(jiàn)的全雙工、半雙工、單工概念：

TCP協(xié)議可以提供全雙工的數(shù)據(jù)流傳輸服務(wù)，亦即接收的時(shí)候可以發(fā)送，發(fā)送的時(shí)候也可以接收，每個(gè)連接都相當(dāng)于兩根并行且雙向傳輸?shù)男盘?hào)線。

http 1.0是半雙工協(xié)議，遵循請(qǐng)求-響應(yīng)模式，就是數(shù)據(jù)可以在客戶端和服務(wù)端兩個(gè)方向上傳輸，但是不能同時(shí)傳輸。它意味著在同一時(shí)刻，只有一個(gè)方向上的數(shù)據(jù)傳送，每個(gè)連接都相當(dāng)于只有一根可以雙向傳輸?shù)男盘?hào)線。

http1.1也是半雙工協(xié)議，依然遵循請(qǐng)求-響應(yīng)模式，但引入了管道機(jī)制，建立了長(zhǎng)連接和多路復(fù)用,可先后發(fā)送多個(gè)http請(qǐng)求,不用等待回復(fù),回復(fù)按順序一個(gè)一個(gè)回復(fù)。但是客戶端在未收到之前所發(fā)出所有請(qǐng)求的響應(yīng)之前，將會(huì)阻塞后面的請(qǐng)求(排隊(duì)等待)，比如谷歌瀏覽器最多同時(shí)允許同域名下6個(gè)并發(fā)請(qǐng)求，如果該6個(gè)請(qǐng)求一直沒(méi)有響應(yīng)，將會(huì)引起后續(xù)所有請(qǐng)求的阻塞。

http2.0（未普及）是全雙工協(xié)議，依然遵循請(qǐng)求-響應(yīng)模式，但客戶端發(fā)送多個(gè)請(qǐng)求和服務(wù)端給出多個(gè)響應(yīng)的順序不受限制，這樣既避免了堵塞，又能更快獲取響應(yīng)。在復(fù)用同一個(gè)TCP連接時(shí)，服務(wù)器同時(shí)(或先后)收到了A、B兩個(gè)請(qǐng)求，先回應(yīng)A請(qǐng)求，但由于處理過(guò)程非常耗時(shí)，于是就發(fā)送A請(qǐng)求已經(jīng)處理好的部分， 接著回應(yīng)B請(qǐng)求，完成后，再發(fā)送A請(qǐng)求剩下的部分。

長(zhǎng)連接，指建立一個(gè)TCP連接后，可以連續(xù)發(fā)送多個(gè)數(shù)據(jù)包，在TCP連接保持期間，如果沒(méi)有數(shù)據(jù)包發(fā)送，需要雙方發(fā)檢測(cè)包以維持此連接，一般需要自己做在線維持。 建立連接后，在斷開(kāi)之前，后續(xù)每次交互數(shù)據(jù)包不需要再經(jīng)過(guò)三次握手四次揮手過(guò)程。常見(jiàn)頭信息中Connection：keep-alive

短連接，是指通信雙方有數(shù)據(jù)交互時(shí)，就建立一個(gè)TCP連接，數(shù)據(jù)發(fā)送完成后，則斷開(kāi)此TCP連接，每次交互數(shù)據(jù)都需要經(jīng)過(guò)握手和揮手的繁瑣過(guò)程，一般銀行都使用短連接。常見(jiàn)頭信息中Connection：close

<完>