經(jīng)常聽到一些網(wǎng)絡協(xié)議相關(guān)的名詞瑟曲，像什么TCP士鸥、UDP闲孤、HTTP、SOCKET烤礁，它們到底有什么樣的區(qū)別呢讼积，今天我們就來好好梳理一遍。
先看一幅圖
如圖所示：
- IP協(xié)議屬于網(wǎng)絡層
- TCP和UDP屬于運輸層協(xié)議
- HTTP應用層協(xié)議
我們來假想一個典型的網(wǎng)絡通訊過程
如果現(xiàn)在有客戶端A要想服務器B發(fā)送一個http網(wǎng)絡請求脚仔，整個流程是怎樣的呢勤众？
首先A與B要建立網(wǎng)絡連接，這里就需要用到網(wǎng)絡層的IP協(xié)議鲤脏，根據(jù)IP地址和端口去發(fā)現(xiàn)對方们颜。
成功找到對方后將會建立一條TCP連接（HTTP基于TCP），當TCP的三次握手建立之后,進入HTTP通訊流程——正式發(fā)送一個請求到服務器猎醇，請求中包含請求方法窥突、URI、協(xié)議版本以及相關(guān)的MIME樣式的消息硫嘶。
服務器響應一個狀態(tài)行阻问，包含消息的協(xié)議版本、一個成功和失敗碼以及相關(guān)的MIME式樣的消息音半。
HTTP/1.0為每一次HTTP的請求/響應建立一條新的TCP鏈接则拷，因此一個包含HTML內(nèi)容和圖片的頁面將需要建立多次的短期的TCP鏈接。每一次鏈接的建立需要這種經(jīng)常性的開銷曹鸠，而其并不帶有實際有用的數(shù)據(jù)煌茬，只是保證鏈接的可靠性，因此HTTP/1.1提出了可持續(xù)鏈接的實現(xiàn)方法彻桃。
HTTP/1.1將只建立一次TCP的鏈接而重復地使用它傳輸一系列的請求/響應消息坛善，因此減少了鏈接建立的次數(shù)和經(jīng)常性的鏈接開銷。
把以上過程抽象一下：
把IP想像成一種高速公路邻眷，它允許其它協(xié)議在上面行駛并找到到其它電腦的出口眠屎。
TCP和UDP是高速公路上的“卡車”，它們攜帶的貨物就是像HTTP肆饶，文件傳輸協(xié)議FTP這樣的協(xié)議等改衩。
在文章的最后，我們再來簡單回顧下三次握手的細節(jié)：
TCP連接的三次握手：
第一次握手：客戶端發(fā)送syn包(syn=j)到服務器驯镊，并進入SYN_SEND狀態(tài)葫督，等待服務器確認竭鞍；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1）橄镜，同時自己也發(fā)送一個SYN包（syn=k）偎快，即SYN+ACK包，此時服務器進入SYN_RECV狀態(tài)洽胶；
第三次握手：客戶端收到服務器的SYN＋ACK包晒夹，向服務器發(fā)送確認包ACK(ack=k+1)，此包發(fā)送完畢姊氓，客戶端和服務器進入ESTABLISHED狀態(tài)丐怯，完成三次握手。
握手過程中傳送的包里不包含數(shù)據(jù)他膳，三次握手完畢后响逢，客戶端與服務器才正式開始傳送數(shù)據(jù)
斷開連接時服務器和客戶端均可以主動發(fā)起斷開TCP連接的請求，斷開過程需要經(jīng)過“四次握手”
總結(jié)：
HTTP協(xié)議是基于傳輸層的TCP協(xié)議棕孙，而TCP協(xié)議又基于網(wǎng)絡層的IP協(xié)議。
SOCKET是針對網(wǎng)絡編程設計的接口些膨，它有很多不同的具體實現(xiàn)蟀俊，例如以TCP為基礎的TCPSOCKET和以UDP為基礎的UDPSOCKET，貌似我們常用的基于TCP/IP的SOCKET編程更多一些订雾。
