TCP/UDP/HTTP的區別和聯絡
一、TPC/IP協議是傳輸層協議，主要解決資料如何在網路中傳輸，而HTTP是應用層協議，主要解決如何包裝資料。
關於TCP/IP和HTTP協議的關係，網路有一段比較容易理解的介紹：“我們在傳輸資料時，可以只使用（傳輸層）TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別資料內容，如果想要使傳輸的資料有意義，則必須使用到應用層協議，應用層協議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用層協議。WEB使用HTTP協議作應用層協議，以封裝HTTP 文字資訊，然後使用TCP/IP做傳輸層協議將它發到網路上。”
術語TCP/IP代表傳輸控制協議/網際協議，指的是一系列協議。
“IP”代表網際協議，TCP和UDP使用該協議從一個網路傳送資料包到另一個網路。把IP想像成一種高速公路，它允許其它協議在上面行駛並找到到其它電腦的出口。TCP和UDP是高速公路上的“卡車”，它們攜帶的貨物就是像HTTP，檔案傳輸協議FTP這樣的協議等。
你應該能理解，TCP和UDP是FTP，HTTP和SMTP之類使用的傳輸層協議。雖然TCP和UDP都是用來傳輸其他協議的，它們卻有一個顯著的不同：TCP提供有保證的資料傳輸，而UDP不提供。這意味著TCP有一個特殊的機制來確保資料安全的不出錯的從一個端點傳到另一個端點，而UDP不提供任何這樣的保證。
HTTP(超文字傳輸協議)是利用TCP在兩臺電腦(通常是Web伺服器和客戶端)之間傳輸資訊的協議。客戶端使用Web瀏覽器發起HTTP請求給Web伺服器，Web伺服器傳送被請求的資訊給客戶端。
下面的圖表試圖顯示不同的TCP/IP和其他的協議在最初OSI模型中的位置：
1、HTTP協議的幾個重要概念
1、HTTP協議的幾個重要概念
1.連線(Connection)：一個傳輸層的實際環流，它是建立在兩個相互通訊的應用程式之間。
2.訊息(Message)：HTTP通訊的基本單位，包括一個結構化的八元組序列並通過連線傳輸。
3.請求(Request)：一個從客戶端到伺服器的請求資訊包括應用於資源的方法、資源的識別符號和協議的版本號
4.響應(Response)：一個從伺服器返回的資訊包括HTTP協議的版本號、請求的狀態(例如“成功”或“沒找到”)和文件的MIME型別。
5.資源(Resource)：由URI標識的網路資料物件或服務。
6.實體(Entity)：資料資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應資訊中。一個實體包括實體頭資訊和實體的本身內容。
7.客戶機(Client)：一個為傳送請求目的而建立連線的應用程式。
8.使用者代理(Useragent)：初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它使用者工具。
9.伺服器(Server)：一個接受連線並對請求返回資訊的應用程式。
10.源伺服器(Originserver)：是一個給定資源可以在其上駐留或被建立的伺服器。
11.
代理經常作為通過防火牆的客戶機端的門戶，代理還可以作為一個幫助應用來通過協議處理沒有被使用者代理完成的請求。
12.閘道器(Gateway)：一個作為其它伺服器中間媒介的伺服器。與代理不同的是，閘道器接受請求就好象對被請求的資源來說它就是源伺服器；發出請求的客戶機並沒有意識到它在同閘道器打交道。
閘道器經常作為通過防火牆的伺服器端的門戶，閘道器還可以作為一個協議翻譯器以便存取那些儲存在非HTTP系統中的資源。
13.通道(Tunnel)：是作為兩個連線中繼的中介程式。一旦啟用，通道便被認為不屬於HTTP通訊，儘管通道可能是被一個HTTP請求初始化的。當被中繼的連線兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。
14.快取(Cache)：反應資訊的局域儲存。
2.傳送請求
開啟一個連線後，客戶機把請求訊息送到伺服器的停留埠上，完成提出請求動作。
HTTP/1.0 請求訊息的格式為：
請求訊息=請求行(通用資訊|請求頭|實體頭)CRLF[實體內容]
請求 行=方法 請求URL HTTP版本號 CRLF
方 法=GET|HEAD|POST|擴充套件方法
U R L=協議名稱+宿主名+目錄與檔名
請求行中的方法描述指定資源中應該執行的動作，常用的方法有GET、HEAD和POST。不同的請求物件對應GET的結果是不同的，對應關係如下：
物件 GET的結果
檔案 檔案的內容
程式 該程式的執行結果
資料庫查詢 查詢結果
HEAD??要求伺服器查詢某物件的元資訊，而不是物件本身。
POST??從客戶機向伺服器傳送資料，在要求伺服器和CGI做進一步處理時會用到POST方法。POST主要用於傳送HTML文字中FORM的內容，讓CGI程式處理。
一個請求的例子為：
GEThttp://networking.zju.edu.cn/zju/index.htmHTTP/1.0 networking.zju.edu.cn/zju/index.htmHTTP/1.0 頭資訊又稱為元資訊，即資訊的資訊，利用元資訊可以實現有條件的請求或應答。
請求頭??告訴伺服器怎樣解釋本次請求，主要包括使用者可以接受的資料型別、壓縮方法和語言等。
實體頭??實體資訊型別、長度、壓縮方法、最後一次修改時間、資料有效期等。
實體??請求或應答物件本身。
3.傳送響應
伺服器在處理完客戶的請求之後，要向客戶機發送響應訊息。
HTTP/1.0的響應訊息格式如下：
響應訊息=狀態行(通用資訊頭|響應頭|實體頭) CRLF 〔實體內容〕
狀態行=HTTP版本號 狀態碼 原因敘述
狀態碼錶示響應型別
1×× 保留
2×× 表示請求成功地接收
3×× 為完成請求客戶需進一步細化請求
4×× 客戶錯誤
5×× 伺服器錯誤
響應頭的資訊包括：服務程式名，通知客戶請求的URL需要認證，請求的資源何時能使用。
4.關閉連線
客戶和伺服器雙方都可以通過關閉套接字來結束TCP/IP對話二、TCP（傳輸控制協議）： 一、TCP是一種面向連線的、可靠的傳輸層協議；
TCP協議建立在不可靠的網路層 IP 協議之上，IP協議並不能提供任何可靠性機制，TCP的可靠性完全由自己實現；
TCP採用的最基本的可靠性技術是：確認與超時重傳機制、流量控制機制；
1.超時重傳是TCP協議保證資料可靠性的一個重要機制，其原理是在傳送某一個數據以後就開啟一個計時器，在一定時間內如果沒有得到傳送的資料報的ACK報文，那麼就重新發送資料，直到傳送成功為止。
2.流量控制就是讓傳送速率不要過快，讓接收方來得及接收。利用滑動視窗機制就可以實施流量控制。
1.源埠和目的埠欄位—— socket（IP+埠號）。TCP的包是沒有IP地址的，那是IP層上的事。但是有源埠和目標埠。
2. 序列號 SEQ ——當前報文段的序號。
3. 確認應答號 AN ——期望收到對方的下一個報文段的資料的第一個位元組的序號；
4. 緊急 URG ——當 URG = 1 時，表明緊急指標欄位有效。它告訴系統此報文段中有緊急資料，應儘快傳送(相當於高優先順序的資料)；
5. 確認 ACK ——當 ACK = 1 時。表示確認應答號 AN 有效。
6. 推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的報文段，就儘快地交付接收應用程序，而不再等到整個快取都填滿了後再向上交付；
7. 復位 RST (ReSeT) —— 當 RST = 1 時，表明 TCP 連線中出現嚴重差錯（如由於主機崩潰或其他原因），必須釋放連線，然後再重新建立傳輸連線；
8. 同步 SYN —— 同步 SYN = 1 表示這是一個連線請求報文。
9. 終止 FIN (Finish) —— 用來釋放一個連線。FIN= 1 表明傳送端的資料已傳送完畢，並要求釋放傳輸連線；
10. 視窗欄位 —— 佔 2 位元組，用來讓對方設定傳送視窗的依據，單位為位元組。視窗值是[ 0, 216-1 ]之間的整數；
11. 檢驗和 —— 佔 2 位元組。檢驗和欄位檢驗的範圍包括首部和資料這兩部分。在計算檢驗和時，要在TCP 報文段的前面加上 12 位元組的偽部(協議欄位為6，表示TCP)；
12. 緊急指標欄位 —— 佔 16 位，指出在本報文段中緊急資料共有多少個位元組(緊急資料放在本報文段資料的最前面)；
13. 選項欄位 —— 長度可變。① 最大報文段長度 MSS：MSS是指在TCP連線建立時，收發雙發協商的通訊時每一個報文段所能承載的資料欄位的最大長度（並不是TCP報文段的最大長度，而是：MSS=TCP報文段長度-TCP首部長度），單位為位元組（雙方提供的MSS中的最小值，為本次連線的最大MSS值）；② 視窗擴大選項；③ 時間戳選項； ④ 選擇確認選項； 二、TCP三次握手（非常重要）
* 第一次握手：客戶端向伺服器傳送請求報文段，其中同步位SYN=1，序號SEQ=x（表明傳送資料時的第一個資料位元組的序號是x），等待伺服器確認；
* 第二次握手：伺服器收到客戶端發來的請求，如果同意建立連線，就發回一個確認報文段，該報文段中同步位SYN=1，確認號ACK=x+1，序號SEQ=y；
* 第三次握手：客戶端收到伺服器的確認報文段後，還需要向伺服器給出確認，向其傳送確認包ACK(ack=y+1)，進而完成三次握手。
通過這樣的三次握手，客戶端與服務端建立起可靠的雙工的連線，開始傳送資料。
為了保證服務端能收接受到客戶端的資訊並能做出正確的應答而進行前兩次(第一次和第二次)握手，為了保證客戶端能夠接收到服務端的資訊並能做出正確的應答而進行後兩次(第二次和第三次)握手。
三、使用者資料報協議（使用者報文協議）UDP
UDP是一種無連線的、不可靠的傳輸層協議；
提供了有限的差錯檢驗功能；
目的是希望以最小的開銷來達到網路環境中的程序通訊目的；
隨著網路技術飛速發展，網速已不再是傳輸的瓶頸，UDP協議以其簡單、傳輸快的優勢，在越來越多場景下取代了TCP，如網頁瀏覽、流媒體、實時遊戲、物聯網。
1.網速的提升給UDP穩定性提供可靠網路保障
CDN服務商Akamai（NASDAQ: AKAM）報告從2008年到2015年7年時間，各個國家網路平均速率由1.5Mbps提升為5.1Mbps，網速提升近4倍。網路環境變好，網路傳輸的延遲、穩定性也隨之改善，UDP的丟包率低於5%，如果再使用應用層重傳，能夠完全確保傳輸的可靠性。
2.對比測試結果UDP效能優於TCP
為了提升瀏覽速度，Google基於TCP提出了SPDY協議以及HTTP/2。Google在Chrome上實驗基於UDP的QUIC協議，傳輸速率減少到100ms以內。
Google採用QUIC後連線速率能有效提升75%。
Google搜尋採用QUIC後頁面載入效能提升3%。
YouTube採用QUIC後重新緩衝次數減少了30%。
3.TCP設計過於冗餘，速度難以進一步提升
TCP為了實現網路通訊的可靠性，使用了複雜的擁塞控制演算法，建立了繁瑣的握手過程以及重傳策略。由於TCP內建在系統協議棧中，極難對其進行改進。
4.UDP協議以其簡單、傳輸快的優勢，在越來越多場景下取代了TCP
4.1 網頁瀏覽
使用UDP協議有三個優點 ：
能夠對握手過程進行精簡，減少網路通訊往返次數；
能夠對TLS加解密過程進行優化；
收發快速，無阻塞。
4.2 流媒體
採用TCP，一旦發生丟包，TCP會將後續包快取起來，等前面的包重傳並接收到後再繼續傳送，延遲會越來越大。基於UDP的協議如WebRTC是極佳的選擇。
2010年google 通過收購 Global IP Solutions，獲得了WebRTC（網頁實時通訊，Web Real-Time Communication）技術，用於提升網頁視訊速率。
4.3 實時遊戲
對實時要求較為嚴格的情況下，採用自定義的可靠UDP協議，比如Enet、RakNet（使用者有sony online game、minecraft）等，自定義重傳策略，能夠把丟包產生的延遲降到最低，儘量減少網路問題對遊戲性造成的影響。
採用UDP的經典遊戲如FPS遊戲Quake、CS，著名的遊戲引擎Unity3D採用的也是RakNet
四、TCP與UDP的不同
1. 是否需要建立連線。
UDP在傳送資料之前不需要先建立連線；TCP則提供面向連線的服務；
2. 是否需要給出確認
對方的傳輸層在收到UDP報文後，不需要給出任何確認，而 TCP需要給出確認報文，要提供可靠的、面向連線的傳輸服務。
3.雖然UDP不提供可靠交付，但在某些情況下UDP是一種最有效的工作方式；【UDP取代TCP】
2. UDP主要用於那些對高速傳輸和實時性有較高要求的通訊或廣播通訊。
舉一個通過 IP 電話進行通話的例子。如果使用 TCP，資料在傳送途中如果丟失就會被重發，這樣就會導致無法流暢地傳輸通話人的聲音。而採用UDP，它不會進行重發處理，從而也就不會有聲音大幅度延遲到達的問題，即使有部分資料丟失，也只是會影響某一小部分的通話。