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