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

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

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

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

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

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

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

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

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

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

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

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

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

<完>