TCP/UDP協(xié)議和HTTP、FTP、SMTP區(qū)別及應用場景

　　1. OSI模型

　　OSI模型主要作為一個通用模型來做理論分析，而TCP/IP協(xié)議模型是互聯(lián)網(wǎng)的實際通訊協(xié)議，兩者一般做映射分析，以下不做嚴格區(qū)分和聲明：

　　1.1. OSI 模型層3個主要層面:

　　|.............主機...............| 操作系統(tǒng)和軟件等 應用、表示、會話

　　|.............網(wǎng)絡(luò)...............| 互聯(lián)網(wǎng)絡(luò)和相關(guān)協(xié)議 傳輸、網(wǎng)絡(luò) (TCP/IP)

　　|.............介質(zhì)...............| 物理介質(zhì)相關(guān) 數(shù)據(jù)鏈路、物理

　　1.2. OSI模型圖

　　1. 主機需要網(wǎng)絡(luò)傳輸數(shù)據(jù)，網(wǎng)絡(luò)本質(zhì)上是一種服務(wù)，主機和網(wǎng)絡(luò)之間靠傳輸層接口，就好比你要叫快遞送東西;

　　2. 網(wǎng)絡(luò)可以提供兩種服務(wù)：

　　a. 可靠，面向連接;(TCP) 就像靠譜的快遞，每一步都有反饋和監(jiān)控，當然價格也是呵呵...

　　b. 不可靠，盡力而為的傳輸 (UDP) 就像某些不靠譜的快遞或者聽都沒聽過的XX快遞，價格低，但是能不能到就靠運氣了。

　　3. 兩種服務(wù)無所謂好壞，TCP的可靠是需要消耗很多資源的，效率低(大塊，重要的文件等)

　　UDP不保證可靠性，但是效率高(視頻，語音，不重要的小文件等)

　　4. 而其他的“HTTP、FTP、SMTP 等所謂的“Application-layer Protocol”協(xié)議”指的是在TCP/IP通訊協(xié)議框架下具體實現(xiàn)特定功能的應用(HTTP 用來實現(xiàn)超文本傳輸，F(xiàn)TP文件傳輸，SMTP處理郵件等等)，兩者的關(guān)系，咳咳，關(guān)系通俗的說：

　　TCP和UDP以及IP協(xié)議是互聯(lián)網(wǎng)絡(luò)通訊的基礎(chǔ)，就像《憲法》，而應用協(xié)議就像具體的《刑法》、《民法》、《婚姻法》、《未成年人保護法》......等等，在某個領(lǐng)域的特定應用和具體實現(xiàn)，但是最基本的一條：違憲無效。

　　2. TCP與HTTP的區(qū)別

　　TCP/IP協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸，而HTTP是應用層協(xié)議，主要解決如何包裝數(shù)據(jù)。關(guān)于TCP/IP和HTTP協(xié)議的關(guān)系，網(wǎng)絡(luò)有一段比較容易理解的介紹：“我們在傳輸數(shù)據(jù)時，可以只使用(傳輸層)TCP/IP協(xié)議，但是那樣的話，如果沒有應用層，便無法識別數(shù)據(jù)內(nèi)容，如果想要使傳輸?shù)臄?shù)據(jù)有意義，則必須使用到應用層協(xié)議，應用層協(xié)議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用層協(xié)議。WEB使用HTTP協(xié)議作應用層協(xié)議，以封裝HTTP 文本信息，然后使用TCP/IP做傳輸層協(xié)議將它發(fā)到網(wǎng)絡(luò)上?！?/p>

　　術(shù)語TCP/IP代表傳輸控制協(xié)議/網(wǎng)際協(xié)議，指的是一系列協(xié)議?！癐P”代表網(wǎng)際協(xié)議，TCP和UDP使用該協(xié)議從一個網(wǎng)絡(luò)傳送數(shù)據(jù)包到另一個網(wǎng)絡(luò)。把IP想像成一種高速公路，它允許其它協(xié)議在上面行駛并找到到其它電腦的出口。TCP和UDP是高速公路上的“卡車”，它們攜帶的貨物就是像HTTP，文件傳輸協(xié)議FTP這樣的協(xié)議等。

　　大家應該能理解，TCP和UDP是FTP，HTTP和SMTP之類使用的傳輸層協(xié)議。雖然TCP和UDP都是用來傳輸其他協(xié)議的，它們卻有一個顯著的不同：TCP提供有保證的數(shù)據(jù)傳輸，而UDP不提供。這意味著TCP有一個特殊的機制來確保數(shù)據(jù)安全的不出錯的從一個端點傳到另一個端點，而UDP不提供任何這樣的保證。

　　HTTP(超文本傳輸協(xié)議)是利用TCP在兩臺電腦(通常是Web服務(wù)器和客戶端)之間傳輸信息的協(xié)議?？蛻舳耸褂肳eb瀏覽器發(fā)起HTTP請求給Web服務(wù)器，Web服務(wù)器發(fā)送被請求的信息給客戶端。

　　下面的圖表試圖顯示不同的TCP/IP和其他的協(xié)議在最初OSI模型中的位置：

　　7 應用層 例如HTTP、SMTP、SNMP、FTP、Telnet、SIP、SSH、NFS、RTSP、XMPP、Whois、ENRP

　　6 表示層 例如XDR、ASN.1、SMB、AFP、NCP

　　5 會話層 例如ASAP、TLS、SSH、ISO 8327 / CCITT X.225、RPC、NetBIOS、ASP、Winsock、BSD sockets

　　4 傳輸層 例如TCP、UDP、RTP、SCTP、SPX、ATP、IL

　　3 網(wǎng)絡(luò)層 例如IP、ICMP、IGMP、IPX、BGP、OSPF、RIP、IGRP、EIGRP、ARP、RARP、 X.25

　　2 數(shù)據(jù)鏈路層 例如以太網(wǎng)、令牌環(huán)、HDLC、幀中繼、ISDN、ATM、IEEE 802.11、FDDI、PPP

　　1 物理層 例如線路、無線電、光纖、信鴿

　　3. TCP,UDP,HTTP應用場景

　　3.1. Socket

　　實現(xiàn)服務(wù)器與客戶端之間的物理連接，并進行數(shù)據(jù)傳輸。主要有TCP/UDP兩個協(xié)議。Socket處于網(wǎng)絡(luò)協(xié)議的傳輸層。

　　3.2. TCP

　　傳輸控制協(xié)議，面向連接的的協(xié)議，穩(wěn)定可靠。當客戶和服務(wù)器彼此交換數(shù)據(jù)前，必須先在雙方之間建立一個TCP連接，之后才能傳輸數(shù)據(jù)。傳輸速度沒有UDP快但是建立連接有三次握手機制，斷開連接有四次揮手機制，傳輸可靠性高。

　　3.3. UDP

　　廣播式數(shù)據(jù)傳輸，UDP不提供可靠性，它只是把應用程序傳給IP層的數(shù)據(jù)報發(fā)送出去，但是并不能保證它們能到達目的地。由于UDP在傳輸數(shù)據(jù)報前不用在客戶和服務(wù)器之間建立一個連接，且沒有超時重發(fā)等機制，故而傳輸速度很快。

　　優(yōu)點：

　　1. 傳輸數(shù)據(jù)為字節(jié)級，傳輸數(shù)據(jù)可自定義，數(shù)據(jù)量小。相應的移動端開發(fā)，手機費用低

　　2. 傳輸數(shù)據(jù)時間短，性能高

　　3. 適合C/S之間信息實時交互

　　4. 可以加密，數(shù)據(jù)安全性高

　　缺點：

　　1. 需要對傳輸?shù)臄?shù)據(jù)進行解析，轉(zhuǎn)化為應用級的數(shù)據(jù)

　　2. 對開發(fā)人員的開發(fā)水平要求高

　　3. 相對于Http協(xié)議傳輸，增加了開發(fā)量

　　3.4. Http

　　http請求主要有http協(xié)議，基于http協(xié)議的soap協(xié)議，常見的http數(shù)據(jù)請求方式有g(shù)et和post，web服務(wù)

　　優(yōu)點：

　　1. 基于應用級的接口使用方便

　　2. 要求的開發(fā)水平不高，容錯性強

　　缺點：

　　1. 傳輸速度慢，數(shù)據(jù)包大。

　　2. 如實現(xiàn)實時交互，服務(wù)器性能壓力大

　　3. 數(shù)據(jù)傳輸安全性差

　　4. TCP中三次握手和四次

　　4.1. TCP三次握手

　　4.1.1. 作用:

　　三次握手用戶建立TCP連接.

　　TCP位于傳輸層，作用是提供可靠的字節(jié)流服務(wù)，為了準確無誤地將數(shù)據(jù)送達目的地，TCP協(xié)議采納三次握手策略.

　　4.1.2. 原理：

　　1)發(fā)送端首先發(fā)送一個帶有SYN(synchronize)標志地數(shù)據(jù)包給接收方。

　　2)接收方接收后，回傳一個帶有SYN/ACK標志的數(shù)據(jù)包傳遞確認信息，表示我收到了。

　　3)最后，發(fā)送方再回傳一個帶有ACK標志的數(shù)據(jù)包，代表我知道了，表示握手‘結(jié)束。

　　4.1.3. 通俗的說法

　　1)Client：嘿，李四，是我，聽到了嗎?

　　2)Server：我聽到了，你能聽到我的嗎?

　　3)Client：好的，我們互相都能聽到對方的話，我們的通信可以開始了。

　　4.2. TCP四次揮手

　　4.2.1. 作用:

　　四次揮手用于斷開TCP連接.

　　當被動方收到主動方的FIN報文通知時，它僅僅表示主動方?jīng)]有數(shù)據(jù)再發(fā)送給被動方了。但未必被動方所有的數(shù)據(jù)都完整的發(fā)送給了主動方，所以被動方不會馬上關(guān)閉SOCKET,它可能還需要發(fā)送一些數(shù)據(jù)給主動方后，再發(fā)送FIN報文給主動方，告訴主動方同意關(guān)閉連接，所以這里的ACK報文和FIN報文多數(shù)情況下都是分開發(fā)送的。

　　4.2.2. 原理：

　　1)第一次揮手：Client發(fā)送一個FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進入FIN_WAIT_1狀態(tài)。

　　2)第二次揮手：Server收到FIN后，發(fā)送一個ACK給Client，確認序號為收到序號+1(與SYN相同，一個FIN占用一個序號)，Server進入CLOSE_WAIT狀態(tài)。

　　3)第三次揮手：Server發(fā)送一個FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進入LAST_ACK狀態(tài)。

　　4)第四次揮手：Client收到FIN后，Client進入TIME_WAIT狀態(tài)，接著發(fā)送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態(tài)，完成四次揮手

　　4.2.3. 通俗的說法

　　1)Client：我所有東西都說完了

　　2)Server：我已經(jīng)全部聽到了，但是等等我，我還沒說完

　　3)Server：好了，我已經(jīng)說完了

　　4)Client：好的，那我們的通信結(jié)束l