OSI模型，即開(kāi)放式通信系統(tǒng)互聯(lián)參考模型(Open System Interconnection,OSI/RM,Open Systems InterconnectionReference Model)，是國(guó)際標(biāo)準(zhǔn)化組織(ISO)提出的一個(gè)試圖使各種計(jì)算機(jī)在世界范圍內(nèi)互連為網(wǎng)絡(luò)的標(biāo)準(zhǔn)框架，簡(jiǎn)稱(chēng)OSI。
0SI／RM協(xié)議是由IS0(國(guó)際標(biāo)準(zhǔn)化組織)制定的，它有三個(gè)基本的功能：提供給開(kāi)發(fā)者一個(gè)必須的、通用的概念以便開(kāi)發(fā)完善、可以用來(lái)解釋連接不同系統(tǒng)的框架。
95【中國(guó)自動(dòng)化網(wǎng)社區(qū)】c2bd23【http://sns.ca800.com】9d2
8825668【中國(guó)自動(dòng)化網(wǎng)社區(qū)】6c850d【http://sns.ca800.com】a2eb3
OSI的層次劃分：OSI將計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)(architecture)劃分為以下七層：
1、物理層 ?Physical Layer
物理接口規(guī)范，傳輸比特流,網(wǎng)卡是工作在物理層的。
2、數(shù)據(jù)鏈路層 ?Data Link Layer
成幀，保證幀的無(wú)誤傳輸，MAC地址，形成EHTHERNET幀
3、網(wǎng)絡(luò)層 ?Network Layer
路由選擇，流量控制，IP地址，形成IP包
4、傳輸層 ?Transport Layer
端口地址，如HTTP對(duì)應(yīng)80端口。TCP和UDP工作于該層,還有就是差錯(cuò)校驗(yàn)和流量控制。
5、會(huì)話層 ?Session Layer
組織兩個(gè)會(huì)話進(jìn)程之間的通信,并管理數(shù)據(jù)的交換使用NETBIOS和WINSOCK協(xié)議。QQ等軟件進(jìn)行 ? ? ? ?通訊因該是工作在會(huì)話層的。
6、表示層 ?Presentation Layer
使得不同操作系統(tǒng)之間通信成為可能。
7、應(yīng)用層 Application Layer
對(duì)應(yīng)于各個(gè)應(yīng)用軟件
它和我們常用的TCP/IP的協(xié)議層有些相似，TCP/IP把1和2封裝為一層，3和4還是獨(dú)立的層，5和6和7封裝成為一層，也就是說(shuō)TCP/IP只有四層，但是在此我講述的7層的具體意義。
在這里我將假設(shè)一個(gè)場(chǎng)景，那就是把要傳輸數(shù)據(jù)的一方視為某個(gè)公司的經(jīng)理，網(wǎng)絡(luò)傳輸被視為這個(gè)經(jīng)理要把一件事情告訴另一個(gè)公司的經(jīng)理。
網(wǎng)絡(luò)的A端：
1、應(yīng)用層：A公司經(jīng)理把他想要告訴B公司經(jīng)理的事情用嘴講了出來(lái)。
用戶(hù)的應(yīng)用程序懷網(wǎng)絡(luò)之間的接口 老板
2、表示層：秘書(shū)就把A公司經(jīng)理說(shuō)的事情翻譯成為英文然后寫(xiě)在了紙上。
協(xié)商數(shù)據(jù)交換格式 相當(dāng)公司中簡(jiǎn)報(bào)老板、替老板寫(xiě)信的助理
3、會(huì)話層：行政的職員把秘書(shū)寫(xiě)的這封信，裝到了信封封裝好了，寫(xiě)上了信封的信息。
允許用戶(hù)使用簡(jiǎn)單易記的名稱(chēng)建立連接 相當(dāng)于公司中收寄信、寫(xiě)信封與拆信封的秘書(shū)
4、傳輸層：A郵局的職工把這封信取走。
提供終端到終端的可靠連接 相當(dāng)于公司中跑郵局的送信職員
5、網(wǎng)絡(luò)層：A郵局的分派的職工，把這封信分派到指定送信區(qū)域。
使用權(quán)數(shù)據(jù)路由經(jīng)過(guò)大型網(wǎng)絡(luò) 相當(dāng)于郵局中的排序工人
6、數(shù)據(jù)鏈路層：A郵局的裝箱的職工，就把一同送往這個(gè)區(qū)域的信封裝到一個(gè)木箱子里，然后送到A郵局物流站。
決定訪問(wèn)網(wǎng)絡(luò)介質(zhì)的方式 相當(dāng)于郵局中的裝拆箱工人
7、物理層：A郵局的物流職工把木箱運(yùn)到鐵路
將數(shù)據(jù)轉(zhuǎn)換為可通過(guò)物理介質(zhì)傳送的電子信號(hào) 相當(dāng)于郵局中的搬運(yùn)工人
這里的鐵路就是網(wǎng)絡(luò)連接物理介質(zhì)
網(wǎng)絡(luò)的B端：
7、物理層：B郵局的物流職工把木箱從鐵路運(yùn)到郵局的物流站。
6、數(shù)據(jù)鏈路層：B郵局的拆箱的職工把物流站的木箱拆箱然后把所有的信件取出來(lái)。
5、網(wǎng)絡(luò)層：B郵局的分派的職工，把這封信分派到指定送信區(qū)域。
4、傳輸層：B郵局的職工把這封信送到B公司。
3、會(huì)話層：B公司行政的職員把公司的信件整理并且拆封信件（假設(shè)這是公司允許的情況下）并送到各自部門(mén)的秘書(shū)手里。
2、表示層：B公司秘書(shū)把信上的英文翻譯成為中文。
1、應(yīng)用層：B公司經(jīng)理聽(tīng)秘書(shū)轉(zhuǎn)述給他這封信的內(nèi)容。
到此為止一個(gè)完整的通過(guò)這7層的網(wǎng)絡(luò)通訊順利完成。接下來(lái)我將用技術(shù)術(shù)語(yǔ)并結(jié)合TCP/IP中的應(yīng)用再描述一遍這7層協(xié)議。
（1）應(yīng)用層：與其他計(jì)算機(jī)進(jìn)行通訊的一個(gè)應(yīng)用，它是對(duì)應(yīng)應(yīng)用程序的通信服務(wù)的。例如，一個(gè)沒(méi)有通信功能的字處理程序就不能執(zhí)行通信的代碼，從事字處理工作的程序員也不關(guān)心OSI的第7層。但是，如果添加了一個(gè)傳輸文件的選項(xiàng)，那么字處理器的程序員就需要實(shí)現(xiàn)OSI的第7層。
應(yīng)用層為操作系統(tǒng)或網(wǎng)絡(luò)應(yīng)用程序提供訪問(wèn)網(wǎng)絡(luò)服務(wù)的接口。
應(yīng)用層是模型中的最頂層，是用戶(hù)與網(wǎng)絡(luò)的接口，該層通過(guò)應(yīng)用程序來(lái)完成網(wǎng)絡(luò)用戶(hù)的應(yīng)用需求。該層的數(shù)據(jù)放在TCP數(shù)據(jù)包的數(shù)據(jù)部分，該層定義了一個(gè)很重要的協(xié)議——Http協(xié)議，我們一般的Web開(kāi)發(fā)都是基于應(yīng)用層的開(kāi)發(fā)， 所以后面專(zhuān)題將會(huì)和大家介紹下Http協(xié)議。
既然知道http是大家在應(yīng)用層的一個(gè)協(xié)議比如我們?yōu)g覽網(wǎng)頁(yè)什么的就是http應(yīng)用IOS上層也是基于http的協(xié)議比較簡(jiǎn)單些，效率高靈活的比較難。
示例：Telnet(遠(yuǎn)程登錄協(xié)議)、FTP(File Transfer Protocol)、HTTP(Hyperrext Transfer Protocol)、SNMP(simple Mail Transfer Protocol)BOOTP(Boot trap．Protocol)AFP（Apple Talk文件協(xié)議--Apple公司的網(wǎng)絡(luò)協(xié)議族，用于交換文件）SNMP(Simple Network Management Protoco1)
NCP(NetWare Core Protoco1)NFS(Network File System)
8825668【中國(guó)自動(dòng)化網(wǎng)社區(qū)】6c850d【http://sns.ca800.com】a2eb3
（2）表示層：這一層的主要功能是定義數(shù)據(jù)格式及加密。例如，F(xiàn)TP允許你選擇以二進(jìn)制或ASII格式傳輸。如果選擇二進(jìn)制，那么發(fā)送方和接收方不改變文件的內(nèi)容。如果選擇ASII格式，發(fā)送方將把文本從發(fā)送方的字符集轉(zhuǎn)換成標(biāo)準(zhǔn)的ASII后發(fā)送數(shù)據(jù)。在接收方將標(biāo)準(zhǔn)的ASII轉(zhuǎn)換成接收方計(jì)算機(jī)的字符集。示例：加密，ASII等。
表示層對(duì)上層數(shù)據(jù)或信息進(jìn)行變換以保證一個(gè)主機(jī)應(yīng)用層信息可以被另一個(gè)主機(jī)的應(yīng)用程序理解。表示層的數(shù)據(jù)轉(zhuǎn)換包括數(shù)據(jù)的加密、壓縮、格式轉(zhuǎn)換等。
示例：
EBCDIC（extended binary coded decimal interchange code）、ASCII（Amercia Standard Code for Information Interchange）；
圖像標(biāo)準(zhǔn)：JPEG（Joint Photographic Experts Group）、TIFF（Tagged Image File Format）、GIF；
視頻標(biāo)準(zhǔn)：MIDI（Musical Instrument Digital Interface）、MPEG（Motion Picture Experts Group）、QuickTime等。
ad【中國(guó)自動(dòng)化網(wǎng)社區(qū)】2c4082【http://sns.ca800.com】48
（3）會(huì)話層：他定義了如何開(kāi)始、控制和結(jié)束一個(gè)會(huì)話，包括對(duì)多個(gè)雙向小時(shí)的控制和管理，以便在只完成連續(xù)消息的一部分時(shí)可以通知應(yīng)用，從而使表示層看到的數(shù)據(jù)是連續(xù)的，在某些情況下，如果表示層收到了所有的數(shù)據(jù)，則用數(shù)據(jù)代表表示層。示例：RPC，SQL等。
會(huì)話層管理主機(jī)之間的會(huì)話進(jìn)程，即負(fù)責(zé)建立、管理、終止進(jìn)程之間的會(huì)話。會(huì)話層還利用在數(shù)據(jù)中插入校驗(yàn)點(diǎn)來(lái)實(shí)現(xiàn)數(shù)據(jù)的同步。
示例：
SSH,Secure Shell
ZIP,Zone Information Protocol
SDP,Sockets Direct Protocol
ADSP：AppleTalk的數(shù)據(jù)流協(xié)議
ASP：AppleTalk的動(dòng)態(tài)會(huì)話協(xié)議
H.245,Call Control Protocol for Multimedia Communication
ISO-SP,OSI Session Layer Protocol（X.225, ISO 8327）
iSNS,Internet Storage Name Service
NetBIOS,Network Basic Input Output System
PAP,Password Authentication Protocol
PPTP,Point-to-Point Tunneling Protocol
RPC,遠(yuǎn)程過(guò)程調(diào)用
RTCP,實(shí)時(shí)傳輸控制協(xié)議
SMPP,Short Message Peer-to-Peer
SCP,Secure Copy Protocol
ad【中國(guó)自動(dòng)化網(wǎng)社區(qū)】2c4082【http://sns.ca800.com】48
（4）傳輸層：這層的功能包括是否選擇差錯(cuò)恢復(fù)協(xié)議還是無(wú)差錯(cuò)恢復(fù)協(xié)議，及在同一主機(jī)上對(duì)不同應(yīng)用的數(shù)據(jù)流的輸入進(jìn)行復(fù)用，還包括對(duì)收到的順序不對(duì)的數(shù)據(jù)包的重新排序功能。
通過(guò)MAC和IP地址，我們可以找到互聯(lián)網(wǎng)上任意兩臺(tái)主機(jī)來(lái)建立通信。然而這里有一個(gè)問(wèn)題，找到主機(jī)后，主機(jī)上有很多程序都需要用到網(wǎng)絡(luò)，比如說(shuō)你在一邊聽(tīng)歌和好用QQ聊天， 當(dāng)網(wǎng)絡(luò)上發(fā)送來(lái)一個(gè)數(shù)據(jù)包時(shí)， 是怎么知道它是表示聊天的內(nèi)容還是歌曲的內(nèi)容的， 這時(shí)候就需要一個(gè)參數(shù)來(lái)表示這個(gè)數(shù)據(jù)包是發(fā)送給那個(gè)程序（進(jìn)程）來(lái)使用的，這個(gè)參數(shù)我們就叫做端口號(hào)，主機(jī)上用端口號(hào)來(lái)標(biāo)識(shí)不同的程序（進(jìn)程），端口是0到65535之間的一個(gè)整數(shù)，0到1023的端口被系統(tǒng)占用，用戶(hù)只能選擇大于1023的端口。
傳輸層的功能就是建立端口到端口的通信，網(wǎng)絡(luò)層就是建立主機(jī)與主機(jī)的通信，這樣如果我們確定了主機(jī)和端口，這樣就可以實(shí)現(xiàn)程序之間的通信了。我們所說(shuō)的Socket編程就是通過(guò)代碼來(lái)實(shí)現(xiàn)傳輸層之間的通信。因?yàn)槌跏蓟疭ocket類(lèi)對(duì)象要指定IP地址和端口號(hào)。
在傳輸層有兩個(gè)非常重要的協(xié)議：UDP 協(xié)議和TCP協(xié)議
采用UDP協(xié)議話傳輸?shù)木褪荱DP數(shù)據(jù)包，同樣UDP數(shù)據(jù)包也由頭和數(shù)據(jù)兩部分組成，頭部分主要標(biāo)識(shí)了發(fā)送端口和接受端口，數(shù)據(jù)部分就是具體的內(nèi)容信息。同樣UDP數(shù)據(jù)包是放入IP數(shù)據(jù)包中的"數(shù)據(jù)"部分，IP數(shù)據(jù)包再放入數(shù)據(jù)幀中在網(wǎng)絡(luò)上傳輸。
由于UDP協(xié)議的可靠性差（數(shù)據(jù)發(fā)送后無(wú)法確定對(duì)方是否收到），所以又定義了一個(gè)可靠性高的協(xié)議——TCP協(xié)議，TCP協(xié)議采取了握手的方式要確保對(duì)方收到了數(shù)據(jù)。
示例：TCP(Transmission Control Protocol)、UDP(User Datagram Protocol）、SPX(SequenCed Packet ExChange Protocol)等。ATP(AppleTalk Transaction Protocol)，NBP(名字綁定協(xié)議)NetBEUI(NetBIOS Extended User Internet)
ad【中國(guó)自動(dòng)化網(wǎng)社區(qū)】2c4082【http://sns.ca800.com】48
（5）網(wǎng)絡(luò)層：這層對(duì)端到端的包傳輸進(jìn)行定義，他定義了能夠標(biāo)識(shí)所有結(jié)點(diǎn)的邏輯地址，還定義了路由實(shí)現(xiàn)的方式和學(xué)習(xí)的方式。為了適應(yīng)最大傳輸單元長(zhǎng)度小于包長(zhǎng)度的傳輸介質(zhì)，網(wǎng)絡(luò)層還定義了如何將一個(gè)包分解成更小的包的分段方法。
網(wǎng)絡(luò)層負(fù)責(zé)對(duì)子網(wǎng)間的數(shù)據(jù)包進(jìn)行路由選擇。網(wǎng)絡(luò)層還可以實(shí)現(xiàn)擁塞控制、網(wǎng)際互連等功能。
在這一層，數(shù)據(jù)的單位稱(chēng)為數(shù)據(jù)包（packet）。
該層通過(guò)尋址（尋址地址）來(lái)建立兩個(gè)節(jié)點(diǎn)之間的連接，大家都知道我們的電腦連接上網(wǎng)絡(luò)后都一個(gè)IP地址，我們可以通過(guò)IP地址來(lái)確定不同的計(jì)算機(jī)是否在同一個(gè)子網(wǎng)路。如果我們的電腦連接上網(wǎng)絡(luò)后就有兩種地址：物理地址和網(wǎng)絡(luò)地址（IP地址），網(wǎng)絡(luò)上的計(jì)算機(jī)要通信，必須要知道通信的計(jì)算機(jī)“在哪里”， 首先通過(guò)網(wǎng)絡(luò)地址來(lái)判斷是否處于同一個(gè)子網(wǎng)絡(luò)，然后再對(duì)物理地址（MAC）地址進(jìn)行處理，從而準(zhǔn)確確定要通信計(jì)算機(jī)的位置。
在網(wǎng)絡(luò)層中有我們熟悉的IP協(xié)議（即規(guī)定網(wǎng)絡(luò)地址的協(xié)議），目前廣泛采用的是IP協(xié)議第四版（IPv4）,這個(gè)版本規(guī)定，網(wǎng)絡(luò)地址由32位二進(jìn)制位組成。我們可以自己配置IP地址也可以自動(dòng)獲得的方式得到IP地址，Ip地址分成兩部分，前24位代表網(wǎng)絡(luò)，后8位代表主機(jī)號(hào)， 如192.168.254.1和192.168.254.2就處于同一個(gè)子網(wǎng)絡(luò)里，因?yàn)檫@兩個(gè)IP地址的前24位相同。
網(wǎng)絡(luò)層中以IP數(shù)據(jù)包的形式來(lái)傳遞數(shù)據(jù)，IP數(shù)據(jù)包也包括兩部分：頭（Head）和數(shù)據(jù)(Data)，IP數(shù)據(jù)包放進(jìn)數(shù)據(jù)幀中的數(shù)據(jù)部分進(jìn)行傳輸。
示例：IP(Internet Protocol)、IPX(Internet work Packet Exchange)、DDP(Datagram Delivery Protoco1)ICMP（Internet Control Message Protocol）APPLETALK、
6b3365【中國(guó)自動(dòng)化網(wǎng)社區(qū)】652ace【http://sns.ca800.com】ba9338
（6）數(shù)據(jù)鏈路層：他定義了在單個(gè)鏈路上如何傳輸數(shù)據(jù)。這些協(xié)議與被討論的各種介質(zhì)有關(guān)。
數(shù)據(jù)鏈路層在不可靠的物理介質(zhì)上提供可靠的傳輸。該層的作用包括：物理地址尋址、數(shù)據(jù)的成幀、流量控制、數(shù)據(jù)的檢錯(cuò)、重發(fā)等。
在這一層，數(shù)據(jù)的單位稱(chēng)為幀（frame）。
該層對(duì)接受到物理層傳輸過(guò)來(lái)的比特流進(jìn)行分組，一組電信號(hào)構(gòu)成的數(shù)據(jù)包，就叫做"幀"，數(shù)據(jù)鏈鏈路層就是來(lái)傳輸以"幀"為單位的數(shù)據(jù)包，把數(shù)據(jù)傳遞給上一層（網(wǎng)絡(luò)層），幀數(shù)據(jù)由兩部分組成：幀頭和幀數(shù)據(jù)，幀頭包括接受方物理地址（就是網(wǎng)卡的地址）和其他的網(wǎng)絡(luò)信息，幀數(shù)據(jù)就是要傳輸?shù)臄?shù)據(jù)體。數(shù)據(jù)幀的最長(zhǎng)為1500字節(jié)，如果數(shù)據(jù)很長(zhǎng)，就必須分割成多個(gè)幀進(jìn)行發(fā)送。
示例：?ARP、RARP、SDLC、HDLC、PPP、STP、幀中繼等。
（7）物理層：OSI的物理層規(guī)范是有關(guān)傳輸介質(zhì)的特性標(biāo)準(zhǔn)，這些規(guī)范通常也參考了其他組織制定的標(biāo)準(zhǔn)。連接頭、針、針的使用、電流、電流、編碼及光調(diào)制等都屬于各種物理層規(guī)范中的內(nèi)容。物理層常用多個(gè)規(guī)范完成對(duì)所有細(xì)節(jié)的定義。
物理層規(guī)定了激活、維持、關(guān)閉通信端點(diǎn)之間的機(jī)械特性、電氣特性、功能特性以及過(guò)程特性。該層為上層協(xié)議提供了一個(gè)傳輸數(shù)據(jù)的物理媒體。只是說(shuō)明標(biāo)準(zhǔn)
在這一層，數(shù)據(jù)的單位稱(chēng)為比特（bit）。
示例：802.3EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45、fddi令牌環(huán)網(wǎng)等。。
OSI是一個(gè)定義良好的協(xié)議規(guī)范集，并有許多可選部分完成類(lèi)似的任務(wù)。
它定義了開(kāi)放系統(tǒng)的層次結(jié)構(gòu)、層次之間的相互關(guān)系以及各層所包括的可能的任務(wù)。是作為一個(gè)框架來(lái)協(xié)調(diào)和組織各層所提供的服務(wù)。
但是OSI參考模型并沒(méi)有提供一個(gè)可以實(shí)現(xiàn)的方法，而是描述了一些概念，用來(lái)協(xié)調(diào)進(jìn)程間通信標(biāo)準(zhǔn)的制定。即OSI參考模型并不是一個(gè)標(biāo)準(zhǔn)，而是一個(gè)在制定標(biāo)準(zhǔn)時(shí)所使用的概念性框架。
事實(shí)上的標(biāo)準(zhǔn)是TCP/IP參考模型
PPPOE機(jī)制
另外，還有一個(gè)最廣泛的例子就是PPPoE，在以太網(wǎng)上走PPP業(yè)務(wù)，也沒(méi)有用到ARP。它的實(shí)現(xiàn)機(jī)理是這樣的：我要跟外界通信，首先我發(fā)一個(gè)PADI廣播包；如果在這個(gè)以太網(wǎng)上有PPPoE服務(wù)器（即BRAS），那么回復(fù)一個(gè)PADO單播給我；然后我再發(fā)一個(gè)PADR給PPPoE服務(wù)器請(qǐng)求建立連接，服務(wù)器收到后，則回復(fù)一個(gè)PADS單播包，分配一個(gè)SessionID，PPPoE連接建立。
ARP、RARP
1)當(dāng)ADSL撥號(hào)成功時(shí)沒(méi)有建立IP和MAC的映射。撥號(hào)鏈接是一種點(diǎn)到點(diǎn)鏈路，這種鏈路的特點(diǎn)是一端發(fā)送的數(shù)據(jù)總被另一端原順序的接受到。（即使兩端的IP不在同一段上也能夠收到）里面有一個(gè)確定性：一定別對(duì)端收到；唯一性：一定被唯一的對(duì)端收到；順序性：包不會(huì)亂續(xù)；這樣的鏈路是不需要什么MAC的。
2)你說(shuō)的撥號(hào)可能說(shuō)的是PPPOE撥號(hào)，這個(gè)是有IP和MAC的關(guān)系的，但使用的而不是ARP協(xié)議，而是PPPOE自身的保證機(jī)制。這也就是PPPOE能夠防止ARP病毒的根本所在。
如果說(shuō)道信元的話那是ATM的東西。映射的不是IP和MAC，應(yīng)該說(shuō)的IP和VPI VCI對(duì)。
任何三層地址都需要映射到二層地址，以太網(wǎng)是IP和MAC，F(xiàn)R是IP和DLCI，ATM是IP和vpi/vci，當(dāng)沒(méi)有映射時(shí)，在路由器上debug會(huì)看到“encapsulation failed”
有點(diǎn)看不下去了,對(duì)于你
3)得出以下結(jié)論：
1，如果計(jì)算機(jī)在訪問(wèn)internet的時(shí)候,不論是客戶(hù)機(jī)基于以太網(wǎng)，還是服務(wù)器基于以太網(wǎng)技術(shù)，都必修使用ARP和RARP協(xié)議。
2，如果計(jì)算機(jī)在訪問(wèn)internet的時(shí)候，客戶(hù)計(jì)算機(jī)或服務(wù)器都使用FDDI或其他非以太網(wǎng)技術(shù)，可以不使用ARP和RARP協(xié)議。
最大感覺(jué)就是你總結(jié)的東西都不對(duì)味
簡(jiǎn)單的說(shuō)兩句吧
1.arp和rarp 和以太網(wǎng)之間就是地址解析和反向地址解析協(xié)議,是基于以太網(wǎng)的技術(shù),這沒(méi)什么好說(shuō)的
2.如果你非要把 arp和rarp 和internet聯(lián)系上的話 這里面的 的關(guān)系就沒(méi)你說(shuō)的那么簡(jiǎn)單,絕對(duì)和狹隘了,internet包含的東西很多,但是和 arp和rarp 有關(guān)系的幾乎沒(méi)有,這個(gè)是你對(duì)概念的含糊和理解的不清楚的原因
3.fddi 是光纖類(lèi)東西,不論是技術(shù)還是概念都與arp和rarp 沒(méi)關(guān)系 那就更不要在說(shuō)信員是什么了
那么,在最深層次上說(shuō), 數(shù)據(jù)在 以太網(wǎng) 里面?zhèn)鬏數(shù)臅r(shí)候,用到的是模擬信號(hào)轉(zhuǎn)為數(shù)字信號(hào) 也就是用 0和1來(lái)處理數(shù)據(jù)的電平的
一般說(shuō)來(lái) arp和rarp 用在內(nèi)網(wǎng)中就是起到解析地址的作用(以前就是這么定義的,而且這也是最主要的作用) 基本是在設(shè)備(pc or sever)端上做處理的 廣義上說(shuō)可以更本就不用關(guān)心他們之間是怎么連的,那就更不需要關(guān)心又是什么網(wǎng)絡(luò)~
fddi 是光纖傳輸,是將模擬信號(hào)轉(zhuǎn)為光信號(hào)來(lái)處理傳送的，在兩個(gè)局端之間有轉(zhuǎn)換設(shè)備來(lái)處理,然后同理也是在另一端復(fù)員信號(hào)送到局端通過(guò)arp和rarp協(xié)議來(lái)處理數(shù)據(jù)具體走向的
那么 arp和rarp 和internet的聯(lián)系 無(wú)論是基于ATM 還是 FR 還是ADSL撥號(hào)的 PPP/MP 等等網(wǎng)絡(luò)"中間"技術(shù) 和arp和rarp的關(guān)系簡(jiǎn)單來(lái)說(shuō)就一句話,那就是沒(méi)聯(lián)系,8桿子都打不著
最后 必須這兩個(gè)字 在做下結(jié)論的時(shí)候,在不是很清楚的情況下 最好別用 否則就是在吾人子弟的
多看看書(shū)吧
4)ADSL只是種接入方式
5)首先說(shuō)，我不是什么高手，但是對(duì)于你所講的這些東西，自信還有一點(diǎn)了解。
ARP（地址解析協(xié)議）和RARP（逆地址解析協(xié)議）是某些網(wǎng)絡(luò)接口（如以太網(wǎng)和令牌環(huán)網(wǎng)）使用的特殊協(xié)議，用來(lái)轉(zhuǎn)換IP層和網(wǎng)絡(luò)接口層使用的地址。這里已經(jīng)說(shuō)的很清楚，arp不是每種網(wǎng)絡(luò)都需要的實(shí)現(xiàn)。實(shí)質(zhì)上你是可以實(shí)現(xiàn)一個(gè)二層鏈路完全由非以太網(wǎng)跟令牌環(huán)網(wǎng)構(gòu)成的網(wǎng)絡(luò)，這里根本不牽涉arp什么事情。
對(duì)于TCP/IP來(lái)講，它是可選的，可有可無(wú)的。它既不是TCP/IP協(xié)議族最初額實(shí)現(xiàn)，也不是必須或者必要的實(shí)現(xiàn)，如果你不怕麻煩，完全可以不要它的存在（對(duì)于RARP協(xié)議來(lái)講，情況稍微有些特殊）。從這個(gè)意義上來(lái)講，ARP/RARP根本就沒(méi)有追究存在必要不必要的問(wèn)題。
舉個(gè)例子，我們的農(nóng)業(yè)生產(chǎn)什么是根本？種子、土地，人，陽(yáng)光，環(huán)境。除了這些之外，其它的東西就是可有可無(wú)的，農(nóng)業(yè)社會(huì)，大家是刀耕火種，現(xiàn)在是機(jī)械化。ARP/RARP的有無(wú)就跟機(jī)械化的有無(wú)是一樣的。不是必要的，但是現(xiàn)在如果你說(shuō)不要耕種設(shè)備了行不行啊，答案是行，也不行。行是因?yàn)闆](méi)有一樣可以做，不行是因?yàn)楝F(xiàn)在沒(méi)有人再想去面朝黃土背朝天的勞作了，沒(méi)有了大家可能真的就不習(xí)慣了。
總之來(lái)講，討論arp跟rarp存在的必要與否本身，根本就沒(méi)有什么意義。
至于什么P2P根本就跟這個(gè)帖子的內(nèi)容沒(méi)有什么關(guān)系了。說(shuō)是什么技術(shù)，有些牽強(qiáng)。算是一個(gè)思想吧，一種軟件組織的架構(gòu)。至于什么改變互聯(lián)網(wǎng)基礎(chǔ)的潛能，讓人聽(tīng)了卻是摸不著頭腦的感覺(jué)。跟之前提的什么C/S,B/S本是一類(lèi)東西，至于是采用哪種組織軟件，要看應(yīng)用的特點(diǎn)，并不是萬(wàn)能良藥，什么東西拿P2P來(lái)就萬(wàn)事大吉，選其它的就不行，反之也一樣。
你的主要問(wèn)題在于，對(duì)網(wǎng)絡(luò)實(shí)質(zhì)內(nèi)容理解本身就膚淺，卻又自以為是。個(gè)人認(rèn)為你需要做的是，靜下心來(lái)，認(rèn)真的理解網(wǎng)絡(luò)的實(shí)質(zhì)，不要搞些似是而非的東西出來(lái)，這樣真的很誤人的。
6)目前的網(wǎng)絡(luò)都有二層的地址，不過(guò)不一定叫MAC地址。譬如FR的DLCI,ATM的VPI VCI等等。
下面我們講一個(gè)實(shí)例化 兩臺(tái)電腦的一個(gè)通信過(guò)程，比如常見(jiàn)的：
HTTP
HTTP協(xié)議如何工作？
大家都知道一般的通信流程：首先客戶(hù)端發(fā)送一個(gè)請(qǐng)求(request)給服務(wù)器，服務(wù)器在接收到這個(gè)請(qǐng)求后將生成一個(gè)響應(yīng)(response)返回給客戶(hù)端。
1.Request和Response的格式
Request格式：
HTTP請(qǐng)求行
（請(qǐng)求）頭
空行
可選的消息體
注：請(qǐng)求行和標(biāo)題必須以作為結(jié)尾（也就是，回車(chē)然后換行）?？招袃?nèi)必須只有而無(wú)其他空格。在HTTP/1.1 ? ? ? ?協(xié)議中，所有的請(qǐng)求頭，除Host外，都是可選的。
實(shí)例：
2.建立連接的方式
HTTP支持2中建立連接的方式：非持久連接和持久連接(HTTP1.1默認(rèn)的連接方式為持久連接)。
1) 非持久連接
讓我們查看一下非持久連接情況下從服務(wù)器到客戶(hù)傳送一個(gè)Web頁(yè)面的步驟。假設(shè)該貝面由1個(gè)基本HTML文件和10個(gè)JPEG圖像構(gòu)成，而且所有這些對(duì)象都存放在同一臺(tái)服務(wù)器主機(jī)中。再假設(shè)該基本HTML文件的URL為：gpcuster.cnblogs.com/index.html。
下面是具體步騾:
1.HTTP客戶(hù)初始化一個(gè)與服務(wù)器主機(jī)gpcuster.cnblogs.com中的HTTP服務(wù)器的TCP連接。HTTP服務(wù)器使用默認(rèn)端口號(hào)80監(jiān)聽(tīng)來(lái)自HTTP客戶(hù)的連接建立請(qǐng)求。
2.HTTP客戶(hù)經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字發(fā)出—個(gè)HTTP請(qǐng)求消息。這個(gè)消息中包含路徑名/somepath/index.html。
3.HTTP服務(wù)器經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字接收這個(gè)請(qǐng)求消息，再?gòu)姆?wù)器主機(jī)的內(nèi)存或硬盤(pán)中取出對(duì)象/somepath/index.html，經(jīng)由同一個(gè)套接字發(fā)出包含該對(duì)象的響應(yīng)消息。
4.HTTP服務(wù)器告知TCP關(guān)閉這個(gè)TCP連接(不過(guò)TCP要到客戶(hù)收到剛才這個(gè)響應(yīng)消息之后才會(huì)真正終止這個(gè)連接)。
5.HTTP客戶(hù)經(jīng)由同一個(gè)套接字接收這個(gè)響應(yīng)消息。TCP連接隨后終止。該消息標(biāo)明所封裝的對(duì)象是一個(gè)HTML文件?？蛻?hù)從中取出這個(gè)文件，加以分析后發(fā)現(xiàn)其中有10個(gè)JPEG對(duì)象的引用。
6.給每一個(gè)引用到的JPEG對(duì)象重復(fù)步騾1-4。
上述步驟之所以稱(chēng)為使用非持久連接，原因是每次服務(wù)器發(fā)出一個(gè)對(duì)象后，相應(yīng)的TCP連接就被關(guān)閉，也就是說(shuō)每個(gè)連接都沒(méi)有持續(xù)到可用于傳送其他對(duì)象。每個(gè)TCP連接只用于傳輸一個(gè)請(qǐng)求消息和一個(gè)響應(yīng)消息。就上述例子而言，用戶(hù)每請(qǐng)求一次那個(gè)web頁(yè)面，就產(chǎn)生11個(gè)TCP連接。
2) 持久連接
非持久連接有些缺點(diǎn)。首先，客戶(hù)得為每個(gè)待請(qǐng)求的對(duì)象建立并維護(hù)一個(gè)新的連接。對(duì)于每個(gè)這樣的連接，TCP得在客戶(hù)端和服務(wù)器端分配TCP緩沖區(qū)，并維持TCP變量。對(duì)于有可能同時(shí)為來(lái)自數(shù)百個(gè)不同客戶(hù)的請(qǐng)求提供服務(wù)的web服務(wù)器來(lái)說(shuō)，這會(huì)嚴(yán)重增加其負(fù)擔(dān)。其次，如前所述，每個(gè)對(duì)象都有2個(gè)RTT的響應(yīng)延長(zhǎng)——一個(gè)RTT用于建立TCP連接，另—個(gè)RTT用于請(qǐng)求和接收對(duì)象。最后，每個(gè)對(duì)象都遭受TCP緩啟動(dòng)，因?yàn)槊總€(gè)TCP連接都起始于緩啟動(dòng)階段。不過(guò)并行TCP連接的使用能夠部分減輕RTT延遲和緩啟動(dòng)延遲的影響。
在持久連接情況下，服務(wù)器在發(fā)出響應(yīng)后讓TCP連接繼續(xù)打開(kāi)著。同一對(duì)客戶(hù)/服務(wù)器之間的后續(xù)請(qǐng)求和響應(yīng)可以通過(guò)這個(gè)連接發(fā)送。整個(gè)Web頁(yè)面(上例中為包含一個(gè)基本HTMLL文件和10個(gè)圖像的頁(yè)面)自不用說(shuō)可以通過(guò)單個(gè)持久TCP連接發(fā)送:甚至存放在同一個(gè)服務(wù)器中的多個(gè)web頁(yè)面也可以通過(guò)單個(gè)持久TCP連接發(fā)送。通常，HTTP服務(wù)器在某個(gè)連接閑置一段特定時(shí)間后關(guān)閉它，而這段時(shí)間通常是可以配置的。持久連接分為不帶流水線(without ? ? ? ?pipelining)和帶流水線(with ? ? ? ?pipelining)兩個(gè)版本。如果是不帶流水線的版本，那么客戶(hù)只在收到前一個(gè)請(qǐng)求的響應(yīng)后才發(fā)出新的請(qǐng)求。這種情況下，web頁(yè)面所引用的每個(gè)對(duì)象(上例中的10個(gè)圖像)都經(jīng)歷1個(gè)RTT的延遲，用于請(qǐng)求和接收該對(duì)象。與非持久連接2個(gè)RTT的延遲相比，不帶流水線的持久連接已有所改善，不過(guò)帶流水線的持久連接還能進(jìn)一步降低響應(yīng)延遲。不帶流水線版本的另一個(gè)缺點(diǎn)是，服務(wù)器送出一個(gè)對(duì)象后開(kāi)始等待下一個(gè)請(qǐng)求，而這個(gè)新請(qǐng)求卻不能馬上到達(dá)。這段時(shí)間服務(wù)器資源便閑置了。
HTTP/1.1的默認(rèn)模式使用帶流水線的持久連接。這種情況下，HTTP客戶(hù)每碰到一個(gè)引用就立即發(fā)出一個(gè)請(qǐng)求，因而HTTP客戶(hù)可以一個(gè)接一個(gè)緊挨著發(fā)出各個(gè)引用對(duì)象的請(qǐng)求。服務(wù)器收到這些請(qǐng)求后，也可以一個(gè)接一個(gè)緊挨著發(fā)出各個(gè)對(duì)象。如果所有的請(qǐng)求和響應(yīng)都是緊挨著發(fā)送的，那么所有引用到的對(duì)象一共只經(jīng)歷1個(gè)RTT的延遲(而不是像不帶流水線的版本那樣，每個(gè)引用到的對(duì)象都各有1個(gè)RTT的延遲)。另外，帶流水線的持久連接中服務(wù)器空等請(qǐng)求的時(shí)間比較少。與非持久連接相比，持久連接(不論是否帶流水線)除降低了1個(gè)RTT的響應(yīng)延遲外，緩啟動(dòng)延遲也比較小。其原因在于既然各個(gè)對(duì)象使用同一個(gè)TCP連接，服務(wù)器發(fā)出第一個(gè)對(duì)象后就不必再以一開(kāi)始的緩慢速率發(fā)送后續(xù)對(duì)象。相反，服務(wù)器可以按照第一個(gè)對(duì)象發(fā)送完畢時(shí)的速率開(kāi)始發(fā)送下一個(gè)對(duì)象。
3.緩存的機(jī)制
HTTP/1.1中緩存的目的是為了在很多情況下減少發(fā)送請(qǐng)求，同時(shí)在許多情況下可以不需要發(fā)送完整響應(yīng)。前者減少了網(wǎng)絡(luò)回路的數(shù)量；HTTP利用一個(gè)“過(guò)期（expiration）”機(jī)制來(lái)為此目的。后者減少了網(wǎng)絡(luò)應(yīng)用的帶寬；HTTP用“驗(yàn)證（validation）”機(jī)制來(lái)為此目的。
HTTP定義了3種緩存機(jī)制：
lFreshnessallows a response to be used without re-checking it on the origin server, and can be ? ? ? ?controlled by both the server and the client. For example, the Expires response header gives a date when the ? ? ? ?document becomes stale, and the Cache-Control: max-age directive tells the cache how many seconds the response ? ? ? ?is fresh for.
lValidationcan be used to check whether a cached response is still good after it becomes stale. For ? ? ? ?example, if the response has a Last-Modified header, a cache can make aconditional requestusing ? ? ? ?the If-Modified-Since header to see if it has changed.
lInvalidationis usually a side effect of another request that passes through the cache. For example, if ? ? ? ?URL associated with a cached response subsequently gets a POST, PUT or DELETE request, the cached response will ? ? ? ?be invalidated.
4.響應(yīng)授權(quán)激發(fā)機(jī)制
這些機(jī)制能被用于服務(wù)器激發(fā)客戶(hù)端請(qǐng)求并且使客戶(hù)端授權(quán)。
詳細(xì)的信息請(qǐng)參考：RFC 2617: HTTP Authentication: Basic and Digest Access
5.基于HTTP的應(yīng)用
多線程下載
下載工具開(kāi)啟多個(gè)發(fā)出HTTP請(qǐng)求的線程
每個(gè)http請(qǐng)求只請(qǐng)求資源文件的一部分：Content-Range: bytes 20000-40000/47000
HTTPS傳輸協(xié)議原理
兩種基本的加解密算法類(lèi)型
通信過(guò)程：
優(yōu)點(diǎn)：
客戶(hù)端產(chǎn)生的密鑰只有客戶(hù)端和服務(wù)器端能得到
加密的數(shù)據(jù)只有客戶(hù)端和服務(wù)器端才能得到明文
服務(wù)器和客戶(hù)端交互：
參考文章：http://blog.csdn.net/lisa890608/article/details/8231666
http://www.cnblogs.com/qiqibo/p/3143964.html
http://www.cnblogs.com/skyofbitbit/p/3713125.html
http://www.cnblogs.com/lavenderone/archive/2011/10/14/2212523.html
TPC/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ò)有一段比較容易理解的介紹：
“我們?cè)趥鬏敂?shù)據(jù)時(shí)，可以只使用（傳輸層）TCP/IP協(xié)議，但是那樣的話，如 ? ? ? ? ? ?果沒(méi)有應(yīng)用層，便無(wú)法識(shí)別數(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ò)上?！?/p>
我們平時(shí)說(shuō)的最多的socket是什么呢，實(shí)際上socket是對(duì)TCP/IP協(xié)議的封裝，Socket本身并不是協(xié)議，而是一個(gè)調(diào)用接口（API），通過(guò)Socket，我們才能使用TCP/IP協(xié)議。 ? ? ? ?實(shí)際上，Socket跟TCP/IP協(xié)議沒(méi)有必然的聯(lián)系。Socket編程接口在設(shè)計(jì)的時(shí)候，就希望也能適應(yīng)其他的網(wǎng)絡(luò)協(xié)議。所以說(shuō)，Socket的出現(xiàn) ? ? ? ?只是使得程序員更方便地使用TCP/IP協(xié)議棧而已，是對(duì)TCP/IP協(xié)議的抽象，從而形成了我們知道的一些最基本的函數(shù)接口，比如create、 ? ? ? ?listen、connect、accept、send、read和write等等。網(wǎng)絡(luò)有一段關(guān)于socket和TCP/IP協(xié)議關(guān)系的說(shuō)法比較容易理 解：
“TCP/IP只是一個(gè)協(xié)議棧，就像操作系統(tǒng)的運(yùn)行機(jī)制一樣，必須要具體實(shí)現(xiàn)，同時(shí)還要提供對(duì)外的操作接口。這個(gè)就像操作系統(tǒng)會(huì)提供標(biāo)準(zhǔn)的編程接口，比如win32編程接口一樣，TCP/IP也要提供可供程序員做網(wǎng)絡(luò)開(kāi)發(fā)所用的接口，這就是Socket編程接口?！?/p>
總結(jié)一些基于基于TCP/IP協(xié)議的應(yīng)用和編程接口的知識(shí)，也就是剛才說(shuō)了很多的 HTTP和Socket。
CSDN上有個(gè)比較形象的描述：HTTP是轎車(chē)，提供了封裝或者顯示數(shù)據(jù)的具體形式；Socket是發(fā)動(dòng)機(jī)，提供了網(wǎng)絡(luò)通信的能力。
實(shí)際上，傳輸層的TCP是基于網(wǎng)絡(luò)層的IP協(xié)議的，而應(yīng)用層的HTTP協(xié)議又是基于傳輸層的TCP協(xié)議的，而Socket本身不算是協(xié)議，就像上面所說(shuō)，它只是提供了一個(gè)針對(duì)TCP或者UDP編程的接口。
下面是一些經(jīng)常在筆試或者面試中碰到的重要的概念，特在此做摘抄和總結(jié)。
一。什么是TCP連接的三次握手
第一次握手：客戶(hù)端發(fā)送syn包(syn=j)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；
第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶(hù)的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；
第三次握手：客戶(hù)端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶(hù)端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。
握手過(guò)程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶(hù)端與服務(wù)器才正式開(kāi)始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉 連接之前，TCP ? ? ? ?連接都將被一直保持下去。斷開(kāi)連接時(shí)服務(wù)器和客戶(hù)端均可以主動(dòng)發(fā)起斷開(kāi)TCP連接的請(qǐng)求，斷開(kāi)過(guò)程需要經(jīng)過(guò)“四次握手”（過(guò)程就不細(xì)寫(xiě)了，就是服務(wù)器和客 戶(hù)端交互，最終確定斷開(kāi)）
二。利用Socket建立網(wǎng)絡(luò)連接的步驟
建立Socket連接至少需要一對(duì)套接字，其中一個(gè)運(yùn)行于客戶(hù)端，稱(chēng)為ClientSocket ，另一個(gè)運(yùn)行于服務(wù)器端，稱(chēng)為ServerSocket 。
套接字之間的連接過(guò)程分為三個(gè)步驟：服務(wù)器監(jiān)聽(tīng)，客戶(hù)端請(qǐng)求，連接確認(rèn)。
1。服務(wù)器監(jiān)聽(tīng)：服務(wù)器端套接字并不定位具體的客戶(hù)端套接字，而是處于等待連接的狀態(tài)，實(shí)時(shí)監(jiān)控網(wǎng)絡(luò)狀態(tài)，等待客戶(hù)端的連接請(qǐng)求。
2?？蛻?hù)端請(qǐng)求：指客戶(hù)端的套接字提出連接請(qǐng)求，要連接的目標(biāo)是服務(wù)器端的套接字。為此，客戶(hù)端的套接字必須首先描述它要連接的服務(wù)器的套接字，指出服務(wù)器端套接字的地址和端口號(hào)，然后就向服務(wù)器端套接字提出連接請(qǐng)求。
3。連接確認(rèn)：當(dāng)服 務(wù)器端套接字監(jiān)聽(tīng)到或者說(shuō)接收到客戶(hù)端套接字的連接請(qǐng)求時(shí)，就響應(yīng)客戶(hù)端套接字的請(qǐng)求，建立一個(gè)新的線程，把服務(wù)器端套接字的描述發(fā)給客戶(hù)端，一旦客戶(hù)端 ? ? ? ?確認(rèn)了此描述，雙方就正式建立連接。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽(tīng)狀態(tài)，繼續(xù)接收其他客戶(hù)端套接字的連接請(qǐng)求。
三。HTTP鏈接的特點(diǎn)
HTTP協(xié)議即超文本傳送協(xié)議(Hypertext Transfer Protocol )，是Web聯(lián)網(wǎng)的基礎(chǔ)，也是手機(jī)聯(lián)網(wǎng)常用的協(xié)議之一，HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。
HTTP連接最顯著的特點(diǎn)是客戶(hù)端發(fā)送的每次請(qǐng)求都需要服務(wù)器回送響應(yīng)，在請(qǐng)求結(jié)束后，會(huì)主動(dòng)釋放連接。從建立連接到關(guān)閉連接的過(guò)程稱(chēng)為“一次連接”。
四。TCP和UDP的區(qū)別
1。TCP是面向鏈 接的，雖然說(shuō)網(wǎng)絡(luò)的不安全不穩(wěn)定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上（實(shí)際上也很大程度上保證了）保證了連接的 ? ? ? ?可靠性；而UDP不是面向連接的，UDP傳送數(shù)據(jù)前并不與對(duì)方建立連接，對(duì)接收到的數(shù)據(jù)也不發(fā)送確認(rèn)信號(hào)，發(fā)送端不知道數(shù)據(jù)是否會(huì)正確接收，當(dāng)然也不用重 發(fā)，所以說(shuō)UDP是無(wú)連接的、不可靠的一種數(shù)據(jù)傳輸協(xié)議。
2。也正由于1所說(shuō)的特點(diǎn)，使得UDP的開(kāi)銷(xiāo)更小數(shù)據(jù)傳輸速率更高，因?yàn)椴槐剡M(jìn)行收發(fā)數(shù)據(jù)的確認(rèn)，所以UDP的實(shí)時(shí)性更好。
知道了TCP和 UDP的區(qū)別，就不難理解為何采用TCP傳輸協(xié)議的MSN比采用UDP的QQ傳輸文件慢了，但并不能說(shuō)QQ的通信是不安全的，因?yàn)槌绦騿T可以手動(dòng)對(duì)UDP ? ? ? ?的數(shù)據(jù)收發(fā)進(jìn)行驗(yàn)證，比如發(fā)送方對(duì)每個(gè)數(shù)據(jù)包進(jìn)行編號(hào)然后由接收方進(jìn)行驗(yàn)證啊什么的，即使是這樣，UDP因?yàn)樵诘讓訁f(xié)議的封裝上沒(méi)有采用類(lèi)似TCP的“三次握手”而實(shí)現(xiàn)了TCP所無(wú)法達(dá)到的傳輸效率。
轉(zhuǎn)載注明來(lái)源：細(xì)說(shuō)OSI七層協(xié)議模型及OSI參考模型中的數(shù)據(jù)封裝過(guò)程？ - 網(wǎng)絡(luò)工程 - 周陸軍的個(gè)人網(wǎng)站
