對(duì)于網(wǎng)絡(luò)問(wèn)題的總結(jié)
對(duì)于網(wǎng)絡(luò)問(wèn)題的總結(jié)
網(wǎng)絡(luò)計(jì)劃技術(shù)是利用圖論和網(wǎng)絡(luò)分析的方法編制和優(yōu)化實(shí)施計(jì)劃的一種科學(xué)手段。今天學(xué)習(xí)啦小編給大家?guī)?lái)了對(duì)于網(wǎng)絡(luò)問(wèn)題的總結(jié)，希望對(duì)大家有所幫助。
對(duì)于網(wǎng)絡(luò)問(wèn)題的總結(jié)篇一
我的主要科研方向?yàn)橄乱淮W(wǎng)絡(luò)SDN以及云計(jì)算中網(wǎng)絡(luò)研究，但是傳統(tǒng)網(wǎng)絡(luò)發(fā)展到如此成熟的一個(gè)地步，雖然存在一些問(wèn)題，不過(guò)我們不應(yīng)該用完美來(lái)要求所有東西，傳統(tǒng)網(wǎng)絡(luò)的很多思想和技術(shù)都將長(zhǎng)遠(yuǎn)地影響以后的網(wǎng)絡(luò)發(fā)展，這篇文章欲總結(jié)一些傳統(tǒng)網(wǎng)絡(luò)中經(jīng)常會(huì)碰到的問(wèn)題。
正文
1.為什么不單獨(dú)的用MAC地址和IP地址來(lái)進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)?
如果只用MAC地址，也就是說(shuō)整個(gè)網(wǎng)絡(luò)都處于一個(gè)大二層中，都處于同一個(gè)廣播域中，當(dāng)世界上成百上千萬(wàn)的機(jī)器處于同一個(gè)廣播域的時(shí)候，結(jié)果可想而知。
如果只是用IP地址，這個(gè)問(wèn)題我只想了下面這種可能性，但是覺(jué)得解釋上仍然有些不足，希望大神可以不吝賜教。IP地址是由管理者統(tǒng)一分配的，所以在某個(gè)機(jī)器申請(qǐng)了IP地址之后，不是說(shuō)這個(gè)機(jī)器的IP地址確定了，而是這個(gè)機(jī)器現(xiàn)在所連的這根網(wǎng)線的IP地址確定了，所以只有IP地址的話，如果頻繁的更換或者移動(dòng)機(jī)器，每次都需要重新配置機(jī)器的IP地址。
2.ICMP和IGMP以及ARP和RARP屬于IP/TCP協(xié)議分層中的哪一層?
首先ICMP和IGMP都是IP的附屬協(xié)議，所以他們有理由都屬于網(wǎng)絡(luò)層，但是在數(shù)據(jù)包的具體傳輸過(guò)程中，ICMP和IGMP報(bào)文都被封裝在了IP數(shù)據(jù)報(bào)中。
對(duì)于ARP和RARP協(xié)議來(lái)說(shuō)，也是眾說(shuō)紛紜，有的教材將其劃作網(wǎng)絡(luò)層，有的認(rèn)為是數(shù)據(jù)鏈路層，從邏輯上來(lái)說(shuō)，數(shù)據(jù)在從上到下進(jìn)行封裝的過(guò)程中會(huì)加上自己的信息，當(dāng)網(wǎng)絡(luò)層的IP包進(jìn)入鏈路層時(shí)，鏈路層通過(guò)ARP協(xié)議添加鏈路信息，而這不是網(wǎng)絡(luò)層的功能，所以可以認(rèn)為是數(shù)據(jù)鏈路層，但是從整個(gè)網(wǎng)絡(luò)解析層面來(lái)說(shuō)，ARP和RARP和IP數(shù)據(jù)報(bào)一樣，都擁有自己的以太網(wǎng)數(shù)據(jù)幀類(lèi)型，所以也可以認(rèn)為是網(wǎng)絡(luò)層，所以他們?cè)谀囊粚硬⒉恢匾靼自碜钪匾?，這同時(shí)也說(shuō)明了網(wǎng)絡(luò)層的劃分并不是十分完美的。
3.為什么常見(jiàn)的網(wǎng)絡(luò)應(yīng)用端口號(hào)都是奇數(shù)?
端口號(hào)是用來(lái)區(qū)分不用應(yīng)用的，比如我們看著視頻聊著QQ，我們都需要使用網(wǎng)絡(luò)傳輸數(shù)據(jù)，所以需要客戶(hù)端端口號(hào)，同樣的，對(duì)于服務(wù)器而言，他要提供多種服務(wù)，如何區(qū)分這些服務(wù)，同樣需要的是服務(wù)器端口號(hào)。如果有注意的話發(fā)現(xiàn)常用的、時(shí)間比較久遠(yuǎn)的應(yīng)用的端口號(hào)都是奇數(shù)，比如FTP的端口號(hào)為21，SNMP為161，Telnet為23。這是為什么呢?因?yàn)檫@些端口號(hào)都是從網(wǎng)絡(luò)控制協(xié)議(即TCP前身，ARPANET的傳輸層協(xié)議)派生出來(lái)的，原來(lái)網(wǎng)絡(luò)控制協(xié)議是單工的，不是全雙工的，因此每個(gè)應(yīng)用程序需要兩個(gè)連接，一個(gè)用于接收，一個(gè)用于發(fā)送，需要預(yù)留一對(duì)奇數(shù)和偶數(shù)端口號(hào)，當(dāng)TCP和UDP稱(chēng)為了標(biāo)準(zhǔn)的傳輸層協(xié)議時(shí)，每個(gè)應(yīng)用程序只需要一個(gè)端口號(hào)，所以就使用了原來(lái)的網(wǎng)絡(luò)控制協(xié)議中的奇數(shù)。
總結(jié)
很多技術(shù)的發(fā)展都有其深刻的歷史烙印，想要精通一門(mén)技術(shù)，了解其歷史是十分重要的。
不向靜中參妙理,縱然穎悟也虛浮 立乎其大 和而不同 古之成大事者，不惟有超世之才，亦必有堅(jiān)韌不拔之志
對(duì)于網(wǎng)絡(luò)問(wèn)題的總結(jié)篇二
對(duì)于網(wǎng)絡(luò)IO，我們一般情況下都需要超時(shí)機(jī)制來(lái)避免進(jìn)行操作的線程被handle住，經(jīng)典的做法就是采用select+非阻塞IO進(jìn)行判斷，select在超時(shí)時(shí)間內(nèi)判斷是否可以讀寫(xiě)操作，然后采用非堵塞讀寫(xiě),不過(guò)一般實(shí)現(xiàn)的時(shí)候讀操作不需要設(shè)置為非堵塞，上面已經(jīng)說(shuō)過(guò)讀操作只有在沒(méi)有數(shù)據(jù)的 時(shí)候才會(huì)阻塞，select的判斷成功說(shuō)明存在數(shù)據(jù)，所以即使是阻塞讀在這種情況下也是可以做到非阻塞的效果，就沒(méi)有必要設(shè)置成非阻塞的情況了.
這部分的代碼可以參考ullib中ul_sreado_ms_ex和ul_swriteo_ms_ex. % G0 J d: g% C4采用ul_sreado_ms_ex讀數(shù)據(jù)也是不能保證返回大于0就一定讀到指定的數(shù)據(jù)長(zhǎng)度, 對(duì)于讀寫(xiě)操作, 都是需要判斷返回的讀長(zhǎng)度或者寫(xiě)長(zhǎng)度是否是需要的長(zhǎng)度, 不能簡(jiǎn)單的判斷一下返回值是否小于0. 對(duì)于ul_sreado_ms_ex的情況如果出現(xiàn)了發(fā)送端數(shù)據(jù)發(fā)送一半就被close掉的情況就有可能導(dǎo)致接收端讀不到完整的數(shù)據(jù)包. errno 只有在函數(shù)返回值為負(fù)的時(shí)候才有效,如果返回0或者大于0的數(shù), errno 的結(jié)果是無(wú)意義的. 有些時(shí)候 會(huì)出現(xiàn)read到0， 但是我們認(rèn)為是錯(cuò)誤的情況然后輸出errno造成誤解，一般建議在這種情況要同時(shí)輸出返回值和errno的結(jié)果，有些情況由于只有errno造成了對(duì)于問(wèn) 題的判斷失誤。 ; j; W& H* d6 _
長(zhǎng)連接和短連接的各種可能的問(wèn)題及相應(yīng)的處理 ' N9 C; f! {% R& ]" [
這里主要是發(fā)起連接的客戶(hù)端的問(wèn)題,這里列出的問(wèn)題主要是在采用同步模型的情況下才會(huì)存在的問(wèn)題.
短連接: J/ E. u5 V: L
采用短連接的情況一般是考慮到下面的一些問(wèn)題:
后端服務(wù)的問(wèn)題, 考慮最簡(jiǎn)單的情況下一個(gè)線程一個(gè)連接, 如果這個(gè)連接采用了長(zhǎng)連接那么就需要我們處理連接的線程和后端保持一一對(duì)應(yīng),然后按照某些原則進(jìn)行處理(n對(duì)n的關(guān)系), 但由于一方面服務(wù)器可能增加,這樣導(dǎo)致需要前后端保持一致,帶來(lái)了更多的麻煩,另一方面線程數(shù)上不去對(duì)應(yīng)處理能力也會(huì)產(chǎn)生影響,而短連接每次連接的時(shí)候只 需要關(guān)注當(dāng)前的機(jī)器,問(wèn)題相對(duì)會(huì)少一些. 其實(shí)這個(gè)問(wèn)題可以采用連接池的方式來(lái)解決,后面會(huì)提到. 不需要考慮由于異常帶來(lái)的臟數(shù)據(jù)。負(fù)載均衡方面可以簡(jiǎn)單考慮, 無(wú)論線程數(shù)是多少還是后端服務(wù)器的數(shù)量是多少都沒(méi)有關(guān)系, 每次考慮單個(gè)連接就可以了. 當(dāng)然如果負(fù)載邏輯簡(jiǎn)單,并且機(jī)器相對(duì)固定,一個(gè)線程一個(gè)長(zhǎng)連接問(wèn)題也不大. 規(guī)避一些問(wèn)題, 在過(guò)去有些情況下出現(xiàn)長(zhǎng)連接大延時(shí),數(shù)據(jù)沒(méi)響應(yīng)等問(wèn)題, 測(cè)試的時(shí)候發(fā)現(xiàn)換短連接問(wèn)題就解決了,由于時(shí)間關(guān)系就沒(méi)有再繼續(xù)追查, 事實(shí)上這些問(wèn)題現(xiàn)在基本上都已經(jīng)定位并且有相關(guān)的解決方案了.
不足:
效率不足, 由于連接操作一般會(huì)有50ns~200ns的時(shí)間消耗,導(dǎo)致短連接需要消耗更多的時(shí)間會(huì)產(chǎn)生TIME_WAIT問(wèn)題,需要做更多的守護(hù)
長(zhǎng)連接:
長(zhǎng)連接相比短連接減少了連接的時(shí)間消耗, 可以承受更高的負(fù)載. 但在使用的時(shí)候需要考慮一些問(wèn)題臟數(shù)據(jù), 在一些特殊情況(特別是邏輯錯(cuò)誤的情況下) 會(huì)存在一些我們并不需要的數(shù)據(jù). 這個(gè)時(shí)候的處理比較安全的方式是一旦檢測(cè)到就關(guān)閉連接, 檢測(cè)的方式在在發(fā)起請(qǐng)求前用前面為什么socket寫(xiě)錯(cuò)誤,但用recv檢查依然成功? 介紹的方式進(jìn)行檢查. 不過(guò)有些程序會(huì)采用繼續(xù)讀把所有不需要的數(shù)據(jù)讀完畢(讀到 EAEGIN), 不過(guò)這種方式過(guò)分依賴(lài)邏輯了,存在了一定的風(fēng)險(xiǎn). 不如直接斷開(kāi)來(lái)的簡(jiǎn)單 后端連接, 前面也提到了 在這種情況我們一般會(huì)采用連接池的方式來(lái)解決問(wèn)題比如(public/connectpool中就可以維護(hù)不同的連接,使每個(gè)線程都可以均勻的獲取到句 柄) 服務(wù)端的處理這個(gè)時(shí)候需要考慮連接的數(shù)量,簡(jiǎn)單的方式就是一個(gè)長(zhǎng)連接一個(gè)線程, 但是線程也不能無(wú)限增加( 增加了,可能造成大量的上下文切換使的性能下降). 我們一般在長(zhǎng)連接的情況采用pendingpool的模型, 通過(guò)一個(gè)異步隊(duì)列來(lái)緩沖, 這樣不需要考慮客戶(hù)端和服務(wù)端的線程數(shù)問(wèn)題,可以任意配置(可以通過(guò)線下測(cè)試選擇合適的線程數(shù))
一些特殊的問(wèn)題, 主要是長(zhǎng)連接的延時(shí) 在后面的FAQ中會(huì)有詳細(xì)的說(shuō)明. 2 A( }! ^5 ~1 O9 B+ V) /
一般來(lái)說(shuō),對(duì)于我們多數(shù)的內(nèi)部業(yè)務(wù)邏輯都是可以采用長(zhǎng)連接模式,不會(huì)產(chǎn)生太多的問(wèn)題.
對(duì)于網(wǎng)絡(luò)問(wèn)題的總結(jié)篇三
在網(wǎng)絡(luò)編程中對(duì)于一個(gè)網(wǎng)絡(luò)句柄會(huì)遇到阻塞IO和非阻塞IO的概念, 這里對(duì)于這兩種socket先做一下說(shuō)明 5 /% b8 U! i; /) `
基本概念：
socket的阻塞模式意味著必須要做完IO操作(包括錯(cuò)誤)才會(huì)返回。 非阻塞模式下無(wú)論操作是否完成都會(huì)立刻返回，需要通過(guò)其他方式來(lái)判斷具體操作是否成功。
設(shè)置：
一般對(duì)于一個(gè)socket是阻塞模式還是非阻塞模式有兩種方式 fcntl設(shè)置和recv,send系列的參數(shù). ' J% f& o: ?; S$ w2 V) p
fcntl函數(shù)可以將一個(gè)socket句柄設(shè)置成非阻塞模式:
flags = fcntl(sockfd, F_GETFL, 0); fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);
設(shè)置之后每次的對(duì)于sockfd的操作都是非阻塞的 6 B$ b8 i" _' k: U5 w$ B
recv, send函數(shù)的最后有一個(gè)flag參數(shù)可以設(shè)置成MSG_DONTWAIT臨時(shí)將sockfd設(shè)置為非阻塞模式,而無(wú)論原有是阻塞還是非阻塞。 recv(sockfd, buff, buff_size, MSG_DONTWAIT); send(scokfd, buff, buff_size, MSG_DONTWAIT); * l( V- |' G1 U
區(qū)別:
讀:
讀本質(zhì)來(lái)說(shuō)其實(shí)不能是讀,在實(shí)際中, 具體的接收數(shù)據(jù)不是由這些調(diào)用來(lái)進(jìn)行,是由于系統(tǒng)底層自動(dòng)完成的,read也好,recv也好只負(fù)責(zé)把數(shù)據(jù)從底層緩沖copy到我們指定的位置. 對(duì)于讀來(lái)說(shuō)(read, 或者 recv) ，在阻塞條件下如果沒(méi)有發(fā)現(xiàn)數(shù)據(jù)在網(wǎng)絡(luò)緩沖中會(huì)一直等待，當(dāng)發(fā)現(xiàn)有數(shù)據(jù)的時(shí)候會(huì)把數(shù)據(jù)讀到用戶(hù)指定的緩沖區(qū)，但是如果這個(gè)時(shí)候讀到的數(shù)據(jù)量比較少，比參數(shù)中指定的長(zhǎng)度要小，read并不會(huì)一直等待下去，而是立刻返回。read的原則是數(shù)據(jù)在不超過(guò)指定的長(zhǎng)度的時(shí)候有多少讀多少，沒(méi)有數(shù)據(jù)就會(huì)一直等待。所以一般情況下我們讀取數(shù)據(jù)都需要采用循環(huán)讀的方式讀取數(shù)據(jù)，一次read完畢不能保證讀到我們需要長(zhǎng)度的數(shù)據(jù)，read完一次需要判斷讀到的數(shù)據(jù)長(zhǎng)度再?zèng)Q定是否還需要再次讀取。在非阻塞的情況下，read的行為是如果發(fā)現(xiàn)沒(méi)有數(shù)據(jù)就直接返回，如果發(fā)現(xiàn)有數(shù)據(jù)那么也是采用有多少讀多少的進(jìn)行處理.對(duì)于讀而言， 阻塞和非阻塞的區(qū)別在于沒(méi)有數(shù)據(jù)到達(dá)的時(shí)候是否立刻返回.
recv中有一個(gè) MSG_WAITALL的參數(shù) recv(sockfd, buff, buff_size, MSG_WAITALL), 在正常情況下 recv是會(huì)等待直到讀取到buff_size長(zhǎng)度的數(shù)據(jù)，但是這里的WAITALL也只是盡量讀全，在有中斷的情況下recv還是可能會(huì) 被打斷，造成沒(méi)有讀完指定的buff_size的長(zhǎng)度。所以即使是采用recv + WAITALL參數(shù)還是要考慮是否需要循環(huán)讀取的問(wèn)題，在實(shí)驗(yàn)中對(duì)于多數(shù)情況下recv還是可以讀完buff_size，所以相應(yīng)的性能會(huì)比直接read 進(jìn)行循環(huán)讀要好一些。不過(guò)要注意的是這個(gè)時(shí)候的sockfd必須是處于阻塞模式下，否則WAITALL不能起作用。
寫(xiě): / E/ m& A+ B+ r
寫(xiě)的本質(zhì)也不是進(jìn)行發(fā)送操作,而是把用戶(hù)態(tài)的數(shù)據(jù)copy到系統(tǒng)底層去,然后再由系統(tǒng)進(jìn)行發(fā)送操作,返回成功只表示數(shù)據(jù)已經(jīng)copy到底層緩沖,而不表示數(shù)據(jù)以及發(fā)出,更不能表示對(duì)端已經(jīng)接收到數(shù)據(jù). 對(duì)于write(或 者send)而言，在阻塞的情況是會(huì)一直等待直到write完全部的數(shù)據(jù)再返回.這點(diǎn)行為上與讀操作有所不同，究其原因主要是讀數(shù)據(jù)的時(shí)候我們并不知道對(duì)端到底有沒(méi)有數(shù)據(jù)，數(shù)據(jù)是在什么時(shí)候結(jié)束發(fā)送的，如果一直等待就可能會(huì)造成死循環(huán)，所以并沒(méi)有去進(jìn)行這方面的處理;而對(duì)于write, 由于需要寫(xiě)的長(zhǎng)度是已知的，所以可以一直再寫(xiě)，直到寫(xiě)完.不過(guò)問(wèn)題是write是可能被打斷造成write一次只write一部分?jǐn)?shù)據(jù), 所以write的過(guò)程還是需要考慮循環(huán)write, 只不過(guò)多數(shù)情況下一次write調(diào)用就可能成功. 非阻塞寫(xiě)的情況下，是采用可以寫(xiě)多少就寫(xiě)多少的策略.與讀不一樣的地方在于，有多少讀多少是由網(wǎng)絡(luò)發(fā)送的那一端是否有數(shù)據(jù)傳輸?shù)綖闃?biāo)準(zhǔn)，但是對(duì)于可以寫(xiě)多少是由本地的網(wǎng)絡(luò)堵塞情況為標(biāo)準(zhǔn)的，在網(wǎng)絡(luò)阻塞嚴(yán)重的時(shí)候，網(wǎng)絡(luò)層沒(méi)有足夠的內(nèi)存來(lái)進(jìn)行寫(xiě)操作，這時(shí)候就會(huì)出現(xiàn)寫(xiě)不成功的情況，阻塞情況下會(huì)盡可能(有可能被中斷)等待到數(shù)據(jù)全部發(fā)送完畢，對(duì)于非阻塞的情況就是一次寫(xiě)多少算多少,沒(méi)有中斷的情況下也還是會(huì)出現(xiàn)write到一部分的情況.
看過(guò)“對(duì)于網(wǎng)絡(luò)問(wèn)題的總結(jié)”的人還看了：
1.網(wǎng)絡(luò)文明教育心得體會(huì)3篇
2.網(wǎng)絡(luò)銷(xiāo)售工作總結(jié)不足之處
3.網(wǎng)絡(luò)管理員個(gè)人工作總結(jié)與計(jì)劃
5.網(wǎng)絡(luò)安全優(yōu)秀的心得體會(huì)
6.網(wǎng)絡(luò)運(yùn)維年度工作總結(jié)報(bào)告