對於網絡問題的總結

網絡計劃技術是利用圖論和網絡分析的方法編制和優化實施計劃的一種科學手段。今天本站小編給大家帶來了對於網絡問題的總結，希望對大家有所幫助。

對於網絡問題的總結篇一

我的主要科研方向為下一代網絡SDN以及雲計算中網絡研究，但是傳統網絡發展到如此成熟的一個地步，雖然存在一些問題，不過我們不應該用完美來要求所有東西，傳統網絡的很多思想和技術都將長遠地影響以後的網絡發展，這篇文章欲總結一些傳統網絡中經常會碰到的問題。

正文

1.為什麼不單獨的用MAC地址和IP地址來進行數據轉發?

如果只用MAC地址，也就是説整個網絡都處於一個大二層中，都處於同一個廣播域中，當世界上成百上千萬的機器處於同一個廣播域的時候，結果可想而知。

如果只是用IP地址，這個問題我只想了下面這種可能性，但是覺得解釋上仍然有些不足，希望大神可以不吝賜教。IP地址是由管理者統一分配的，所以在某個機器申請了IP地址之後，不是説這個機器的IP地址確定了，而是這個機器現在所連的這根網線的IP地址確定了，所以只有IP地址的話，如果頻繁的更換或者移動機器，每次都需要重新配置機器的IP地址。

和IGMP以及ARP和RARP屬於IP/TCP協議分層中的哪一層?

首先ICMP和IGMP都是IP的附屬協議，所以他們有理由都屬於網絡層，但是在數據包的具體傳輸過程中，ICMP和IGMP報文都被封裝在了IP數據報中。

對於ARP和RARP協議來説，也是眾説紛紜，有的教材將其劃作網絡層，有的認為是數據鏈路層，從邏輯上來説，數據在從上到下進行封裝的過程中會加上自己的信息，當網絡層的IP包進入鏈路層時，鏈路層通過ARP協議添加鏈路信息，而這不是網絡層的功能，所以可以認為是數據鏈路層，但是從整個網絡解析層面來説，ARP和RARP和IP數據報一樣，都擁有自己的以太網數據幀類型，所以也可以認為是網絡層，所以他們在哪一層並不重要，明白原理最重要，這同時也説明了網絡層的劃分並不是十分完美的。

3.為什麼常見的網絡應用端口號都是奇數?

端口號是用來區分不用應用的，比如我們看着視頻聊着QQ，我們都需要使用網絡傳輸數據，所以需要客户端端口號，同樣的，對於服務器而言，他要提供多種服務，如何區分這些服務，同樣需要的是服務器端口號。如果有注意的話發現常用的、時間比較久遠的應用的端口號都是奇數，比如FTP的端口號為21，SNMP為161，Telnet為23。這是為什麼呢?因為這些端口號都是從網絡控制協議(即TCP前身，ARPANET的傳輸層協議)派生出來的，原來網絡控制協議是單工的，不是全雙工的，因此每個應用程序需要兩個連接，一個用於接收，一個用於發送，需要預留一對奇數和偶數端口號，當TCP和UDP稱為了標準的傳輸層協議時，每個應用程序只需要一個端口號，所以就使用了原來的網絡控制協議中的奇數。

總結

很多技術的發展都有其深刻的歷史烙印，想要精通一門技術，瞭解其歷史是十分重要的。

不向靜中參妙理,縱然穎悟也虛浮 立乎其大 和而不同 古之成大事者，不惟有超世之才，亦必有堅韌不拔之志

對於網絡問題的總結篇二

對於網絡IO，我們一般情況下都需要超時機制來避免進行操作的線程被handle住，經典的做法就是採用select+非阻塞IO進行判斷，select在超時時間內判斷是否可以讀寫操作，然後採用非堵塞讀寫,不過一般實現的時候讀操作不需要設置為非堵塞，上面已經説過讀操作只有在沒有數據的 時候才會阻塞，select的判斷成功説明存在數據，所以即使是阻塞讀在這種情況下也是可以做到非阻塞的效果，就沒有必要設置成非阻塞的情況了.

這部分的代碼可以參考ullib中ul_sreado_ms_ex和ul_swriteo_ms_ex. % G0 J d: g% C4採用ul_sreado_ms_ex讀數據也是不能保證返回大於0就一定讀到指定的數據長度, 對於讀寫操作, 都是需要判斷返回的讀長度或者寫長度是否是需要的長度, 不能簡單的判斷一下返回值是否小於0. 對於ul_sreado_ms_ex的情況如果出現了發送端數據發送一半就被close掉的情況就有可能導致接收端讀不到完整的數據包. errno 只有在函數返回值為負的時候才有效,如果返回0或者大於0的數, errno 的結果是無意義的. 有些時候 會出現read到0， 但是我們認為是錯誤的情況然後輸出errno造成誤解，一般建議在這種情況要同時輸出返回值和errno的結果，有些情況由於只有errno造成了對於問 題的判斷失誤。 ; j; W& H* d6 _

長連接和短連接的各種可能的問題及相應的處理 ' N9 C; f! {% R& ]" [

這裏主要是發起連接的客户端的問題,這裏列出的問題主要是在採用同步模型的情況下才會存在的問題.

短連接: J/ E. u5 V: L

採用短連接的情況一般是考慮到下面的一些問題:

後端服務的問題, 考慮最簡單的情況下一個線程一個連接, 如果這個連接採用了長連接那麼就需要我們處理連接的線程和後端保持一一對應,然後按照某些原則進行處理(n對n的關係), 但由於一方面服務器可能增加,這樣導致需要前後端保持一致,帶來了更多的麻煩,另一方面線程數上不去對應處理能力也會產生影響,而短連接每次連接的時候只 需要關注當前的機器,問題相對會少一些. 其實這個問題可以採用連接池的方式來解決,後面會提到. 不需要考慮由於異常帶來的髒數據。負載均衡方面可以簡單考慮, 無論線程數是多少還是後端服務器的數量是多少都沒有關係, 每次考慮單個連接就可以了. 當然如果負載邏輯簡單,並且機器相對固定,一個線程一個長連接問題也不大. 規避一些問題, 在過去有些情況下出現長連接大延時,數據沒響應等問題, 測試的時候發現換短連接問題就解決了,由於時間關係就沒有再繼續追查, 事實上這些問題現在基本上都已經定位並且有相關的解決方案了.

不足:

效率不足, 由於連接操作一般會有50ns~200ns的時間消耗,導致短連接需要消耗更多的時間會產生TIME_WAIT問題,需要做更多的守護

長連接:

長連接相比短連接減少了連接的時間消耗, 可以承受更高的負載. 但在使用的時候需要考慮一些問題髒數據, 在一些特殊情況(特別是邏輯錯誤的情況下) 會存在一些我們並不需要的數據. 這個時候的處理比較安全的方式是一旦檢測到就關閉連接, 檢測的方式在在發起請求前用前面為什麼socket寫錯誤,但用recv檢查依然成功? 介紹的方式進行檢查. 不過有些程序會採用繼續讀把所有不需要的數據讀完畢(讀到 EAEGIN), 不過這種方式過分依賴邏輯了,存在了一定的風險. 不如直接斷開來的簡單 後端連接, 前面也提到了 在這種情況我們一般會採用連接池的方式來解決問題比如(public/connectpool中就可以維護不同的連接,使每個線程都可以均勻的獲取到句 柄) 服務端的處理這個時候需要考慮連接的數量,簡單的方式就是一個長連接一個線程, 但是線程也不能無限增加( 增加了,可能造成大量的上下文切換使的性能下降). 我們一般在長連接的情況採用pendingpool的模型, 通過一個異步隊列來緩衝, 這樣不需要考慮客户端和服務端的線程數問題,可以任意配置(可以通過線下測試選擇合適的線程數)

一些特殊的問題, 主要是長連接的延時 在後面的FAQ中會有詳細的説明. 2 A( }! ^5 ~1 O9 B+ V) /

一般來説,對於我們多數的內部業務邏輯都是可以採用長連接模式,不會產生太多的問題.

對於網絡問題的總結篇三

在網絡編程中對於一個網絡句柄會遇到阻塞IO和非阻塞IO的概念, 這裏對於這兩種socket先做一下説明 5 /% b8 U! i; /) `

基本概念：

socket的阻塞模式意味着必須要做完IO操作(包括錯誤)才會返回。 非阻塞模式下無論操作是否完成都會立刻返回，需要通過其他方式來判斷具體操作是否成功。

設置：

一般對於一個socket是阻塞模式還是非阻塞模式有兩種方式 fcntl設置和recv,send系列的參數. ' J% f& o: ?; S$ w2 V) p

fcntl函數可以將一個socket句柄設置成非阻塞模式:

flags = fcntl(sockfd, F_GETFL, 0); fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);

設置之後每次的對於sockfd的操作都是非阻塞的 6 B$ b8 i" _' k: U5 w$ B

recv, send函數的最後有一個flag參數可以設置成MSG_DONTWAIT臨時將sockfd設置為非阻塞模式,而無論原有是阻塞還是非阻塞。 recv(sockfd, buff, buff_size, MSG_DONTWAIT); send(scokfd, buff, buff_size, MSG_DONTWAIT); * l( V- |' G1 U

區別:

讀:

讀本質來説其實不能是讀,在實際中, 具體的接收數據不是由這些調用來進行,是由於系統底層自動完成的,read也好,recv也好只負責把數據從底層緩衝copy到我們指定的位置. 對於讀來説(read, 或者 recv) ，在阻塞條件下如果沒有發現數據在網絡緩衝中會一直等待，當發現有數據的時候會把數據讀到用户指定的緩衝區，但是如果這個時候讀到的數據量比較少，比參數中指定的長度要小，read並不會一直等待下去，而是立刻返回。read的原則是數據在不超過指定的長度的時候有多少讀多少，沒有數據就會一直等待。所以一般情況下我們讀取數據都需要採用循環讀的方式讀取數據，一次read完畢不能保證讀到我們需要長度的數據，read完一次需要判斷讀到的數據長度再決定是否還需要再次讀取。在非阻塞的情況下，read的行為是如果發現沒有數據就直接返回，如果發現有數據那麼也是採用有多少讀多少的進行處理.對於讀而言， 阻塞和非阻塞的區別在於沒有數據到達的時候是否立刻返回.

recv中有一個 MSG_WAITALL的參數　recv(sockfd, buff, buff_size, MSG_WAITALL), 在正常情況下　recv是會等待直到讀取到buff_size長度的數據，但是這裏的WAITALL也只是儘量讀全，在有中斷的情況下recv還是可能會 被打斷，造成沒有讀完指定的buff_size的長度。所以即使是採用recv + WAITALL參數還是要考慮是否需要循環讀取的問題，在實驗中對於多數情況下recv還是可以讀完buff_size，所以相應的性能會比直接read 進行循環讀要好一些。不過要注意的是這個時候的sockfd必須是處於阻塞模式下，否則WAITALL不能起作用。

寫: / E/ m& A+ B+ r

寫的本質也不是進行發送操作,而是把用户態的數據copy到系統底層去,然後再由系統進行發送操作,返回成功只表示數據已經copy到底層緩衝,而不表示數據以及發出,更不能表示對端已經接收到數據. 對於write(或 者send)而言，在阻塞的情況是會一直等待直到write完全部的數據再返回.這點行為上與讀操作有所不同，究其原因主要是讀數據的時候我們並不知道對端到底有沒有數據，數據是在什麼時候結束髮送的，如果一直等待就可能會造成死循環，所以並沒有去進行這方面的處理;而對於write, 由於需要寫的長度是已知的，所以可以一直再寫，直到寫完.不過問題是write是可能被打斷造成write一次只write一部分數據, 所以write的過程還是需要考慮循環write, 只不過多數情況下一次write調用就可能成功. 非阻塞寫的情況下，是採用可以寫多少就寫多少的策略.與讀不一樣的地方在於，有多少讀多少是由網絡發送的那一端是否有數據傳輸到為標準，但是對於可以寫多少是由本地的網絡堵塞情況為標準的，在網絡阻塞嚴重的時候，網絡層沒有足夠的內存來進行寫操作，這時候就會出現寫不成功的情況，阻塞情況下會盡可能(有可能被中斷)等待到數據全部發送完畢，對於非阻塞的情況就是一次寫多少算多少,沒有中斷的情況下也還是會出現write到一部分的情況.