首頁常見問題正文

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

更新時間:2023-09-21 來源:黑馬程序員 瀏覽量:

  1. OSI模型

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

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

  |.............主機...............| 操作系統(tǒng)和軟件等 應(yī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模型圖

1695279522683_OSI模型圖.jpg

  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)特定功能的應(yīng)用(HTTP 用來實現(xiàn)超文本傳輸,F(xiàn)TP文件傳輸,SMTP處理郵件等等),兩者的關(guān)系,咳咳,關(guān)系通俗的說:

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

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

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

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

  大家應(yīng)該能理解,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模型中的位置:

1695279565524_不同的TCP和IP和其他的協(xié)議在最初OSI模型中的位置.jpg

  7 應(yīng)用層 例如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應(yīng)用場景

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

  優(yōu)點:

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

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

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

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

  缺點:

  1. 需要對傳輸?shù)臄?shù)據(jù)進行解析,轉(zhuǎn)化為應(yīng)用級的數(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. 基于應(yīng)用級的接口使用方便

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

  缺點:

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

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

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

  4. TCP中三次握手和四次

  4.1. TCP三次握手

1695279603686_三次握手.jpg

  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四次揮手

1695279662149_TCP四次握手.jpg

  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

分享到:
在線咨詢 我要報名
和我們在線交談!