又是紛繁絮繞的一個秋，我很遺憾有些事情我做的處置的確實欠妥亦或是缺乏了些許于年齡不相關的東西吧。天天2B一樣的活著，突然一個耳光打來，確實有些冷靜了！冷笑道：也許確實是有些什么吧！
迷茫和夢想充斥著腦海中。我應該慢下來，慢慢的審視自己，聽取別人的意見，規規矩矩的！可是誰又理解其中的甘苦呢？猶如一顆長在巖石夾縫中小樹，必定要委屈求全的，夢想很遠很遠，我很慶幸我一直在走，雖然有時候走的很難很慢，卻一直沒有停下腳步，可能夢想永遠都不會實現，即使實現不了，也無什么可悲哀的--命！
最近又重寫TCP部分APP程序，其中發現幾處問題第一處是網卡的吞吐量和應用程序所能達到的最高效率處理率的沖突問題，這個問題毫無疑問在網絡空閑時數據輸入進來，中斷繁忙的進出，BUF頻繁的分配釋放，由于使用了堆內存，所以效率比構建的結構內存要快，然后輸入協議棧，那么這樣下來協議棧要處理的包就遠遠的超過了CPU時間片給他的時間導致了數據的擠壓，以至于有些響應出問題，重發和轉發包的問題。這里應該加一層過濾，不屬于自己的統統丟掉。有的硬件有數據過濾，有的沒有需要軟件構成。這樣可以大大的屏蔽不需要的報文處理上，減少CPU負擔。這是提速A+第二處是網卡驅動問題，首先你應該有一個很穩定的網卡驅動，也就是要在拋去協議棧的時候測試那段DEV代碼，看中斷收發，收發可以構建一些簡單的包，比如ARP，和廣播包等！這是B+。再者就是TCP的SYN信號處理，這信號對程序員來說陌生！那是因為沒看TCPIP協議，SYN發送始于socket 的connect host ip ,然后由于TCP的控制塊控制狀態變為SYNSEND，此時可能鏈接不成功，不在線或者故障阻塞等，不要試圖關閉，等待TCP SEND SYN ==MAXSYN，這個間隔在1左右，或者更短一些，發送完畢之后host還是不在，則關閉鏈接，這時候上層關閉端口才是正確的！！！這里處理不好也是要命的！現象時bind端口不成功，表面上看是綁定的不成功其實深層的原因是過早的關閉了控制塊，殊不知協議棧并不會按照你的意愿去做，因為你違背了他的意愿，他還有任務沒有完成呢，所以他會掛起這個繼續等待，這個等待就長了，于是乎你在建立一個則增加一堆內存，在一次往復，最終內存爆掉或者協議棧用完他的堆。再也不能工作為止！GAME OVER!
彼采葛兮，一日不見，如三月兮！
彼采蕭兮，一日不見，如三秋兮！
彼采艾兮！一日不見，如三歲兮！
比特
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
