網路年終工作總結 篇1
顧一下工作、反思一下不足、思考一下打算，非常必要和及時。一年多來，在上級公司和大家的共同支持幫助下，本人為有線電視網路的管理和發展作出了一點微薄的努力。現將一年多的工作總結如下：
這一年，對於我們有線網路來說，是非同尋常的一年，網路體制的改革、網路資源的產業化運作、網路業務經營方式的轉變等等，都給我們有線網路注入新的活力，給我們帶來了廣闊的發展空間和發展機遇。我作為一名有線網路人員，有幸目睹並經歷了這一年有線網路的發展進程。在上級各部門的直接領導下，我紮實工作，不計個人名利，在網路整合、強化管理、優良服務、思想工作等方面作了些創新和探索，促進了事業的發展。
一、抓安全傳輸，保信號暢通
去年以來，網路的安全傳輸形勢十分嚴峻。為確保網路傳輸的絕對安全，在上級的統一部署下，本人每天不間斷地對線路進行巡查。確保了國慶節、和黨的“xx大”召開重要播出保證期”的傳輸安全，使黨和政府的聲音安全、暢通地傳送到千家萬戶。
二、抓優質服務，誠實做人，樹行業形象，乾淨辦事。
作為一名有線網路人員，網路配備應該說是比較精簡的，具體負責日常維修的人員現增加到4人，而作為一個視窗服務的行業，且管理範圍涉及整個永康壩區，直接用戶達3000之多，各種事情可以說是應接不暇。在人手少，工作量大的情況下，本人沒有絲毫怨言，從不把困難推向公司里，而是想方設法自我消化。努力調動自己的積極性，在大家的共同努力下，使各項工作有條不紊正常運作，一年來，在上級公司領導的直接幫助、支持下，經過全體員工的共同努力，使我站的各項工作有了新的起色。全年發展(新增入網)戶185戶，改裝樓棟線路100戶，改造和改遷主支幹線8處，改遷供電電源3處；受理用戶報修860起(次)，其中維修處理因區域性停電，供電戶不正常供電故障50起(次)、受風雨雷電及氣溫變化和其它因素造成的故障460起(次)、因用戶使用不當和室內私拉亂接等造成的故障350起(次)；夜間維修線路3次，並完成了公司里安排的其它各項任務。
三、重要任務
有線電視是黨和政府的重要宣傳工具，又是民眾必不可少的文化活動。一旦出現問題，勢必回響黨委、政府的工作，影響民眾的文化生活，後果十分嚴重。為了確保線路暢通，適應民眾的文化生活需要。我鎮的有線電視光纖網線路長、光點多，覆蓋範圍廣，最長到達鴨溏來回達20多公里。所經路途地形複雜，既有以架空為主的線路，過大河的線路，受人為或自然破壞的情況較為嚴重。有線電視外線管理的另一項重要任務學習就是網路局部變更和用戶端的增減變化，隨著城市改造，街道拆遷，居民遷移，對其重新施工安裝、調試及維護應按整個系統設計要求處理，使其滿足技術指標的要求。有線電視是高科技裝備的社會系統工程，是一個龐大複雜的網路，從信號接收、處理、傳輸、分配直至用戶，環環緊密相連。它的前端部分和外線部分(包括幹線、分配網路、用戶終端)的技術指標的保證要依賴於各個環節，任何一點出了問題都可能影響用戶的正常收看。所以，我們為了要保證“安全優質播出”這一中心任務，更要加強外線的管理。存在不足：
1、入第一線不夠
對於工作，雖然本人是盡心盡責，但是聯繫民眾不夠深入。與民眾交流就比較少，使廣大民眾的建議和呼聲很難全面了解和掌握，從一定程度上影響了我的工作積極性和熱情。
2、作方式、方法比較簡單
這一年，工作可謂千頭萬緒，要求處理和解決的問題很多，在這種情況下，本人有時處理問題比較簡單，特別是遇到一些較為棘手的問題時，內心就顯得比較急躁，脾氣也就容易暴躁，得理不讓人，最終傷了不少同事的感情，得罪了不少人，使一些工作事倍功半。
網路年終工作總結 篇2
本人在領導的指導下，嚴格履行崗位職責，認真學習，努力工作，較好地完成了本職工作和領導交給的各項任務，在這個崗位上鍛鍊了能力，提高了素養，在做人和做事上都有了很大的收穫，在此，把這段時間來的工作情況和明年的規劃一個匯報。
一、工作概況：
我主要負責公司內部網路系統的維護工作，通過這段時間的工作，對公司1，2，3號院的網路狀況，拓撲結構，已經比較熟悉。面對日常網路運行中所發生的問題故障，基本可以快速判斷和解決。在維護工作上按著日常網路維護流程。每天分時段對關鍵設備運行狀況進行監控，以便及時發現解決出現的故障現象，確保設備正常運行。每天寫工作日誌，記錄每天工作內容和所出現故障，解決排除過程和故障原因。對信息管理部所負責維護的其他部門和單位所出現的故障和問題。能夠做到耐心和及時的解決，讓各部門對信息中心的工作比較滿意。遵守部門的各項制度，服從並認真完成領導安排的工作。
本崗位目前主要有三項主要工作內容：其一，網路系統設備維護方面，其二，個人辦公計算機硬體維護工作，其三，辦公計算機軟體維護工作。現對工作作如下總結計畫：
(一)、計算機硬體的更換，購置和維護情況。公司計算機硬體整個年度總體來講，出現問題頻率較多，每台機器除了日常的簡單故障維護之外，硬體方面都爭取做到物盡其用，對一些配置較低的機器進行適當的增容處理。
(二)、公司目前由於機器較多，日常出現故障的情況較為常見，主要的計算機故障有：系統故障，網路故障，軟體故障等，很多機器由於長期使用，導致系統中存在大量垃圾檔案，系統檔案也有部分受到損壞，從而導致系統崩潰，重灌系統，另外有一些屬網路故障，線路問題等。其他軟體問題主要包括大財務軟體erp的安裝使用，office,wps辦公軟體的使用等。
(三)、公司計算機病毒的維護與防範情況
目前網路計算機病毒較多，傳播途徑也較為廣泛，主要是通過USB存儲設備傳播。可以通過瀏覽網頁、下載程式、郵件傳播，為了做好防範措施，公司每台機器都安裝了防毒軟體，專殺工具,並定期的要求升級，對發現病毒的機器及時的進行處理。
二、工作中存在的不足：
1、計算機管理管理制度需要進一步完善，從而對設備方面進行有效控制。2、公司目前軟體使用方面仍存在一些不足，存在一些開通外網的計算機,私自下載盜版軟體,安裝私人軟體等情況.
三、明年工作計畫：
1、學習一門網路方面的新知識，完成自我培訓，提高自己業務水平。2、完善規章管理制度，使機器設備能發揮更大的作用，更快捷高效的為大家服務。
3、具體工作包括:新建廠區等新建項目網路建設。
雖然在工作上取得了一點成效，但是，成績只屬於過去，將來還需要繼續努力，學海無涯，工作無止境。將本著對本職工作的認真和責任心，以“服務創造價值”的部門理念為宗旨把維護工作做好做精。希望能夠為公司的整體發展做出貢獻。
網路年終工作總結 篇3
對於網路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) /
一般來說,對於我們多數的內部業務邏輯都是可以採用長連線模式,不會產生太多的問題.