IT運(yùn)維 | 網(wǎng)絡(luò)基礎(chǔ)知識(shí)匯總(協(xié)議基礎(chǔ))

2020-05-18 21:34 作者：admin

 
北京IT外包服務(wù)商為您提供專業(yè)的IT外包服務(wù)
 
在上一篇網(wǎng)絡(luò)基礎(chǔ)知識(shí)匯總給大家介紹了一些網(wǎng)絡(luò)基礎(chǔ)的東西，這一篇跟大家講講網(wǎng)絡(luò)協(xié)議等內(nèi)容。供廣大網(wǎng)絡(luò)運(yùn)維，網(wǎng)絡(luò)管理員參考。
一、ARP/RARP協(xié)議       
地址解析協(xié)議，即ARP（Address Resolution Protocol），是根據(jù)IP地址獲取物理地址的一個(gè)TCP/IP協(xié)議。主機(jī)發(fā)送信息時(shí)將包含目標(biāo)IP地址的ARP請(qǐng)求廣播到網(wǎng)絡(luò)上的所有主機(jī)，并接收返回消息，以此確定目標(biāo)的物理地址；收到返回消息后將該IP地址和物理地址存入本機(jī)ARP緩存中并保留一定時(shí)間，下次請(qǐng)求時(shí)直接查詢ARP緩存以節(jié)約資源。地址解析協(xié)議是建立在網(wǎng)絡(luò)中各個(gè)主機(jī)互相信任的基礎(chǔ)上的，網(wǎng)絡(luò)上的主機(jī)可以自主發(fā)送ARP應(yīng)答消息，其他主機(jī)收到應(yīng)答報(bào)文時(shí)不會(huì)檢測(cè)該報(bào)文的真實(shí)性就會(huì)將其記入本機(jī)ARP緩存；由此攻擊者就可以向某一主機(jī)發(fā)送偽ARP應(yīng)答報(bào)文，使其發(fā)送的信息無(wú)法到達(dá)預(yù)期的主機(jī)或到達(dá)錯(cuò)誤的主機(jī)，這就構(gòu)成了一個(gè)ARP欺騙。ARP命令可用于查詢本機(jī)ARP緩存中IP地址和MAC地址的對(duì)應(yīng)關(guān)系、添加或刪除靜態(tài)對(duì)應(yīng)關(guān)系等。
 
二、路由選擇協(xié)議（IGP）       
常見的路由選擇協(xié)議有：RIP協(xié)議、OSPF協(xié)議。
　　RIP協(xié)議 ：底層是貝爾曼福特算法，它選擇路由的度量標(biāo)準(zhǔn)（metric)是跳數(shù)，最大跳數(shù)是15跳，如果大于15跳，它就會(huì)丟棄數(shù)據(jù)包。
　　OSPF協(xié)議 ：Open Shortest Path First開放式最短路徑優(yōu)先，底層是迪杰斯特拉算法，是鏈路狀態(tài)路由選擇協(xié)議，它選擇路由的度量標(biāo)準(zhǔn)是帶寬，延遲。
 
三、TCP/IP協(xié)議
TCP/IP協(xié)議是Internet最基本的協(xié)議、Internet國(guó)際互聯(lián)網(wǎng)絡(luò)的基礎(chǔ)，由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成。通俗而言：TCP負(fù)責(zé)發(fā)現(xiàn)傳輸?shù)膯?wèn)題，一有問(wèn)題就發(fā)出信號(hào)，要求重新傳輸，直到所有數(shù)據(jù)安全正確地傳輸?shù)侥康牡亍６鳬P是給因特網(wǎng)的每一臺(tái)聯(lián)網(wǎng)設(shè)備規(guī)定一個(gè)地址。IP層接收由更低層（網(wǎng)絡(luò)接口層例如以太網(wǎng)設(shè)備驅(qū)動(dòng)程序）發(fā)來(lái)的數(shù)據(jù)包，并把該數(shù)據(jù)包發(fā)送到更高層---TCP或UDP層；相反，IP層也把從TCP或UDP層接收來(lái)的數(shù)據(jù)包傳送到更低層。IP數(shù)據(jù)包是不可靠的，因?yàn)镮P并沒(méi)有做任何事情來(lái)確認(rèn)數(shù)據(jù)包是否按順序發(fā)送的或者有沒(méi)有被破壞，IP數(shù)據(jù)包中含有發(fā)送它的主機(jī)的地址（源地址）和接收它的主機(jī)的地址（目的地址）。TCP是面向連接的通信協(xié)議，通過(guò)三次握手建立連接，通訊完成時(shí)要拆除連接，由于TCP是面向連接的所以只能用于端到端的通訊。TCP提供的是一種可靠的數(shù)據(jù)流服務(wù)，采用“帶重傳的肯定確認(rèn)”技術(shù)來(lái)實(shí)現(xiàn)傳輸?shù)目煽啃浴CP還采用一種稱為“滑動(dòng)窗口”的方式進(jìn)行流量控制，所謂窗口實(shí)際表示接收能力，用以限制發(fā)送方的發(fā)送速度。
　　TCP報(bào)文首部格式： TCP協(xié)議的三次握手和四次揮手：
注：seq:"sequance"序列號(hào)；ack:"acknowledge"確認(rèn)號(hào)；SYN:"synchronize"請(qǐng)求同步標(biāo)志；；ACK:"acknowledge"確認(rèn)標(biāo)志"；FIN："Finally"結(jié)束標(biāo)志。
　　TCP連接建立過(guò)程：首先Client端發(fā)送連接請(qǐng)求報(bào)文，Server段接受連接后回復(fù)ACK報(bào)文，并為這次連接分配資源。Client端接收到ACK報(bào)文后也向Server段發(fā)生ACK報(bào)文，并分配資源，這樣TCP連接就建立了。TCP連接斷開過(guò)程：假設(shè)Client端發(fā)起中斷連接請(qǐng)求，也就是發(fā)送FIN報(bào)文。Server端接到FIN報(bào)文后，意思是說(shuō)"我Client端沒(méi)有數(shù)據(jù)要發(fā)給你了"，但是如果你還有數(shù)據(jù)沒(méi)有發(fā)送完成，則不必急著關(guān)閉Socket，可以繼續(xù)發(fā)送數(shù)據(jù)。所以你先發(fā)送ACK，"告訴Client端，你的請(qǐng)求我收到了，但是我還沒(méi)準(zhǔn)備好，請(qǐng)繼續(xù)你等我的消息"。這個(gè)時(shí)候Client端就進(jìn)入FIN_WAIT狀態(tài)，繼續(xù)等待Server端的FIN報(bào)文。當(dāng)Server端確定數(shù)據(jù)已發(fā)送完成，則向Client端發(fā)送FIN報(bào)文，"告訴Client端，好了，我這邊數(shù)據(jù)發(fā)完了，準(zhǔn)備好關(guān)閉連接了"。Client端收到FIN報(bào)文后，"就知道可以關(guān)閉連接了，但是他還是不相信網(wǎng)絡(luò)，怕Server端不知道要關(guān)閉，所以發(fā)送ACK后進(jìn)入TIME_WAIT狀態(tài)，如果Server端沒(méi)有收到ACK則可以重傳。“，Server端收到ACK后，"就知道可以斷開連接了"。Client端等待了2MSL后依然沒(méi)有收到回復(fù)，則證明Server端已正常關(guān)閉，那好，我Client端也可以關(guān)閉連接了。Ok，TCP連接就這樣關(guān)閉了！
　　為什么要三次揮手？
　　在只有兩次“握手”的情形下，假設(shè)Client想跟Server建立連接，但是卻因?yàn)橹型具B接請(qǐng)求的數(shù)據(jù)報(bào)丟失了，故Client端不得不重新發(fā)送一遍；這個(gè)時(shí)候Server端僅收到一個(gè)連接請(qǐng)求，因此可以正常的建立連接。但是，有時(shí)候Client端重新發(fā)送請(qǐng)求不是因?yàn)閿?shù)據(jù)報(bào)丟失了，而是有可能數(shù)據(jù)傳輸過(guò)程因?yàn)榫W(wǎng)絡(luò)并發(fā)量很大在某結(jié)點(diǎn)被阻塞了，這種情形下Server端將先后收到2次請(qǐng)求，并持續(xù)等待兩個(gè)Client請(qǐng)求向他發(fā)送數(shù)據(jù)...問(wèn)題就在這里，Cient端實(shí)際上只有一次請(qǐng)求，而Server端卻有2個(gè)響應(yīng)，極端的情況可能由于Client端多次重新發(fā)送請(qǐng)求數(shù)據(jù)而導(dǎo)致Server端最后建立了N多個(gè)響應(yīng)在等待，因而造成極大的資源浪費(fèi)！所以，“三次握手”很有必要！
　　為什么要四次揮手？
　　試想一下，假如現(xiàn)在你是客戶端你想斷開跟Server的所有連接該怎么做？第一步，你自己先停止向Server端發(fā)送數(shù)據(jù)，并等待Server的回復(fù)。但事情還沒(méi)有完，雖然你自身不往Server發(fā)送數(shù)據(jù)了，但是因?yàn)槟銈冎耙呀?jīng)建立好平等的連接了，所以此時(shí)他也有主動(dòng)權(quán)向你發(fā)送數(shù)據(jù)；故Server端還得終止主動(dòng)向你發(fā)送數(shù)據(jù)，并等待你的確認(rèn)。其實(shí)，說(shuō)白了就是保證雙方的一個(gè)合約的完整執(zhí)行！
　　使用TCP的協(xié)議：FTP（文件傳輸協(xié)議）、Telnet（遠(yuǎn)程登錄協(xié)議）、SMTP（簡(jiǎn)單郵件傳輸協(xié)議）、POP3（和SMTP相對(duì)，用于接收郵件）、HTTP協(xié)議等。
 
四、UDP
UDP用戶數(shù)據(jù)報(bào)協(xié)議，是面向無(wú)連接的通訊協(xié)議，UDP數(shù)據(jù)包括目的端口號(hào)和源端口號(hào)信息，由于通訊不需要連接，所以可以實(shí)現(xiàn)廣播發(fā)送。UDP通訊時(shí)不需要接收方確認(rèn)，屬于不可靠的傳輸，可能會(huì)出現(xiàn)丟包現(xiàn)象，實(shí)際應(yīng)用中要求程序員編程驗(yàn)證。　　UDP與TCP位于同一層，但它不管數(shù)據(jù)包的順序、錯(cuò)誤或重發(fā)。因此，UDP不被應(yīng)用于那些使用虛電路的面向連接的服務(wù)，UDP主要用于那些面向查詢---應(yīng)答的服務(wù)，例如NFS。相對(duì)于FTP或Telnet，這些服務(wù)需要交換的信息量較小。　　每個(gè)UDP報(bào)文分UDP報(bào)頭和UDP數(shù)據(jù)區(qū)兩部分。報(bào)頭由四個(gè)16位長(zhǎng)（2字節(jié)）字段組成，分別說(shuō)明該報(bào)文的源端口、目的端口、報(bào)文長(zhǎng)度以及校驗(yàn)值。UDP報(bào)頭由4個(gè)域組成，其中每個(gè)域各占用2個(gè)字節(jié)，具體如下：　　（1）源端口號(hào)；　　（2）目標(biāo)端口號(hào)；　　（3）數(shù)據(jù)報(bào)長(zhǎng)度；　　（4）校驗(yàn)值。　　使用UDP協(xié)議包括：TFTP（簡(jiǎn)單文件傳輸協(xié)議）、SNMP（簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議）、DNS（域名解析協(xié)議）、NFS、BOOTP。　　TCP 與 UDP 的區(qū)別：TCP是面向連接的，可靠的字節(jié)流服務(wù)；UDP是面向無(wú)連接的，不可靠的數(shù)據(jù)報(bào)服務(wù)。
 
五、DNS協(xié)議
       DNS是域名系統(tǒng)(DomainNameSystem)的縮寫，該系統(tǒng)用于命名組織到域?qū)哟谓Y(jié)構(gòu)中的計(jì)算機(jī)和網(wǎng)絡(luò)服務(wù)，可以簡(jiǎn)單地理解為將URL轉(zhuǎn)換為IP地址。域名是由圓點(diǎn)分開一串單詞或縮寫組成的，每一個(gè)域名都對(duì)應(yīng)一個(gè)惟一的IP地址，在Internet上域名與IP地址之間是一一對(duì)應(yīng)的，DNS就是進(jìn)行域名解析的服務(wù)器。DNS命名用于Internet等TCP/IP網(wǎng)絡(luò)中，通過(guò)用戶友好的名稱查找計(jì)算機(jī)和服務(wù)。

六、NAT協(xié)議
      NAT網(wǎng)絡(luò)地址轉(zhuǎn)換(Network Address Translation)屬接入廣域網(wǎng)(WAN)技術(shù)，是一種將私有（保留）地址轉(zhuǎn)化為合法IP地址的轉(zhuǎn)換技術(shù)，它被廣泛應(yīng)用于各種類型Internet接入方式和各種類型的網(wǎng)絡(luò)中。原因很簡(jiǎn)單，NAT不僅完美地解決了lP地址不足的問(wèn)題，而且還能夠有效地避免來(lái)自網(wǎng)絡(luò)外部的攻擊，隱藏并保護(hù)網(wǎng)絡(luò)內(nèi)部的計(jì)算機(jī)。
 
七、DHCP協(xié)議      DHCP動(dòng)態(tài)主機(jī)設(shè)置協(xié)議（Dynamic Host Configuration Protocol）是一個(gè)局域網(wǎng)的網(wǎng)絡(luò)協(xié)議，使用UDP協(xié)議工作，主要有兩個(gè)用途：給內(nèi)部網(wǎng)絡(luò)或網(wǎng)絡(luò)服務(wù)供應(yīng)商自動(dòng)分配IP地址，給用戶或者內(nèi)部網(wǎng)絡(luò)管理員作為對(duì)所有計(jì)算機(jī)作中央管理的手段。
 
八、HTTP協(xié)議
       超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。　　HTTP 協(xié)議包括哪些請(qǐng)求？
　　GET：請(qǐng)求讀取由URL所標(biāo)志的信息。
　　POST：給服務(wù)器添加信息（如注釋）。
　　PUT：在給定的URL下存儲(chǔ)一個(gè)文檔。
　　DELETE：刪除給定的URL所標(biāo)志的資源。
　　HTTP 中， POST 與 GET 的區(qū)別
　　1）Get是從服務(wù)器上獲取數(shù)據(jù)，Post是向服務(wù)器傳送數(shù)據(jù)。
　　2）Get是把參數(shù)數(shù)據(jù)隊(duì)列加到提交表單的Action屬性所指向的URL中，值和表單內(nèi)各個(gè)字段一一對(duì)應(yīng)，在URL中可以看到。
　　3）Get傳送的數(shù)據(jù)量小，不能大于2KB；Post傳送的數(shù)據(jù)量較大，一般被默認(rèn)為不受限制。
　　4）根據(jù)HTTP規(guī)范，GET用于信息獲取，而且應(yīng)該是安全的和冪等的。
　　I. 所謂 安全的 意味著該操作用于獲取信息而非修改信息。換句話說(shuō)，GET請(qǐng)求一般不應(yīng)產(chǎn)生副作用。就是說(shuō)，它僅僅是獲取資源信息，就像數(shù)據(jù)庫(kù)查詢一樣，不會(huì)修改，增加數(shù)據(jù)，不會(huì)影響資源的狀態(tài)。
　　II. 冪等 的意味著對(duì)同一URL的多個(gè)請(qǐng)求應(yīng)該返回同樣的結(jié)果。
 
以上內(nèi)容由北京艾銻無(wú)限科技發(fā)展有限公司整理