謹(jǐn)以此文總結(jié)我站在iOS開發(fā)者角度對于以上關(guān)鍵詞的形象理解，至于底層抽象的概念，別人用啥TCP/IP詳解：卷一、卷二、卷三都講不清楚，我也懶得浪費時間。前人栽樹，后人乘涼，一個道理。
有名字就有定義，理解的前提從來都是對定義有所了解。就好比現(xiàn)在讓你形容一下梯形的定義，如果你不知道定義，你就可能把平行四邊形當(dāng)做特殊的梯形處理，也就有可能把TCP和Socket搞混，更加會糾結(jié)TCP連接與Socket連接以及HTTP的長/短連接之間到底有啥區(qū)別。
其實有了區(qū)別才好理解。但在這之前首先得理清一個概念，那就是OSI七層模型，以及所謂的五層模型，四層模型到底是什么鬼？
OSI七層模型是萬能的國際標(biāo)準(zhǔn)化組織(ISO)提出的一個試圖使各種計算機在世界范圍內(nèi)互連的理想標(biāo)準(zhǔn)，說白了理想和現(xiàn)實的差距就是七層模型和五層模型的差距。具體分類如下表：
| 七層模型 | 五層模型 | 四層模型 |
|---|---|---|
| 應(yīng)用層 | ||
| 表示層 | 應(yīng)用層 | 應(yīng)用層 |
| 會話層 | ||
| 傳輸層 | 傳輸層 | 傳輸層 |
| 網(wǎng)絡(luò)層 | 網(wǎng)絡(luò)層 | 網(wǎng)絡(luò)層 |
| 數(shù)據(jù)鏈路層 | 數(shù)據(jù)鏈路層 | 鏈接層/實體層 |
| 物理層 | 物理層 |
七層模型的上三層歸為應(yīng)用層即為TCP/IP五層模型，五層模型的下兩層歸為鏈接層或者說實體層即為四層模型。
也就是說，所謂的五層或者四層，其實可以認(rèn)為是方便理解而形成的潛規(guī)則，而具體的實施肯定還是得根據(jù)七層的標(biāo)準(zhǔn)來。畢竟每一層都有每一層各自的功能，而為了完成每一層的功能，就需要大家遵守相關(guān)的規(guī)則，也就是協(xié)議。所以，對模型分層沒必要太在意，五層也好，四層也罷，對于這些看不見摸不著的東西，你只要知道，互聯(lián)網(wǎng)是分層的，來來去去加起來也就這么幾層就夠了。
那么，回到第一個問題，這一大堆關(guān)鍵詞之間到底有啥區(qū)別？
從本質(zhì)上來區(qū)分，HTTP，WebSocket，TCP，UDP，IP都是協(xié)議，而TCP/IP是不同協(xié)議的組合，你也可以稱之為協(xié)議棧，協(xié)議族，TCP/IP模型等等都可以，你開心就行，反正都是虛無的不能吃的東西，都是為了完成對應(yīng)功能而制定的統(tǒng)一規(guī)則。
而Socket（套接字）才是真正能操作的東西。Socket的本質(zhì)是API，是先人對TCP/IP協(xié)議族的抽象或者說封裝，它就像一個門面，給你一個操作TCP/IP協(xié)議的入口，來建立Socket連接。值得一提的是，此Socket是指網(wǎng)絡(luò)編程下的Socket，而不是Unix中的Socket。雖然概念相似，但是Unix中的Socket不是基于這些亂七八糟的協(xié)議，而是基于操作系統(tǒng)本身的文件系統(tǒng)。
從分層上來區(qū)分，HTTP，WebSocket是應(yīng)用層協(xié)議，TCP，UDP是傳輸層協(xié)議，IP是網(wǎng)絡(luò)層協(xié)議。
TCP是面向連接的一種傳輸控制協(xié)議。TCP連接之后，客戶端和服務(wù)器可以互相發(fā)送和接收消息，在客戶端或者服務(wù)器沒有主動斷開之前，連接一直存在，故稱為長連接。特點：連接有耗時，傳輸數(shù)據(jù)無大小限制，準(zhǔn)確可靠，先發(fā)先至。
UDP是無連接的用戶數(shù)據(jù)報協(xié)議，所謂的無連接就是在傳輸數(shù)據(jù)之前不需要交換信息，沒有握手建立連接的過程，只需要直接將對應(yīng)的數(shù)據(jù)發(fā)送到指定的地址和端口就行。故UDP的特點是不穩(wěn)定，速度快，可廣播，一般數(shù)據(jù)包限定64KB之內(nèi)，先發(fā)未必先至。
HTTP是基于TCP協(xié)議的應(yīng)用，請求時需建立TCP連接，而且請求包中需要包含請求方法，URI，協(xié)議版本等信息，請求結(jié)束后斷開連接，完成一次請求/響應(yīng)操作。故稱為短連接。
而HTTP/1.1中的keep-alive所保持的長連接則是為了優(yōu)化每次HTTP請求中TCP連接三次握手的麻煩和資源開銷，只建立一次TCP連接，多次的在這個通道上完成請求/響應(yīng)操作。
值得一提的是，服務(wù)器無法主動給客戶端推送消息。
WebSocket也是一種協(xié)議，并且也是基于TCP協(xié)議的。具體流程是WebSocket通過HTTP先發(fā)送一個標(biāo)記了 Upgrade 的請求，服務(wù)端解析后開始建立TCP連接，省去了HTTP長連接每次請求都要上傳header的冗余，可以理解為WebSocket是HTTP的優(yōu)化，但WebSocket不僅僅在Web應(yīng)用程序上得到支持。
其實這就是一個文字游戲而已，建立Socket連接需要至少一對Socket（套接字），而創(chuàng)建Socket連接可以指定不同的傳輸層協(xié)議，即TCP或UDP，所以當(dāng)采用TCP建立連接時，該Socket連接就視為一個TCP連接。而采用UDP則是無連接的。
這兩個雖然名字差不多，但卻是兩個完全不同的概念，就好比Java和JavaScript一樣毫無關(guān)系。Socket是一套協(xié)議封裝后的接口，用于建立Socket連接，而WebSocket雖然是Html5的產(chǎn)物，但也不僅僅局限于瀏覽器的應(yīng)用程序，許多語言都提供了WebSocket的支持，比如C，C++，Python等。
HTTP通信過程屬于“你推一下，我走一下”的方式，客戶端不發(fā)請求則服務(wù)器永遠(yuǎn)無法發(fā)送數(shù)據(jù)給客戶端，而WebSocket則在進行第一次HTTP請求之后，其他全部采用TCP通道進行雙向通訊。所以，HTTP和WebSocket雖都是基于TCP協(xié)議，但是兩者屬于完全不同的兩種通訊方式。
能比較的都比較了，附上一張關(guān)系圖強化理解。其實，如果不是專攻網(wǎng)絡(luò)方面，作為一個程序猿，了解了不同的通訊方式及其對應(yīng)的優(yōu)缺點，就可以確定其應(yīng)用的場景。而這些，就已經(jīng)基本夠用了。
如有理解紕漏的地方還請批評斧正。
聯(lián)系客服
