第一章、計算機網路體系結構
協議：為進行網路中的資料交換而建立的規則，標準或約定
介面：同一結點內相領兩層間交換資訊的連線點，是乙個系統內部的規定
服務：下尾為上層提供的功能呼叫
osi模型：應表會傳網數物
tcp/ip模型：應用層ftp dns smtp http/傳輸層/網際層/網路介面層
第二章、物理層
位元率：單位時間內數字通訊系統傳輸的位元數
波特率：單位時間內數字通訊系統所傳輸的碼元個數（脈衝個數），乙個碼元可以有多個位元
奈奎斯特定理無雜訊通道中極限碼元傳輸率為2wbaud,w是理想低通訊道的頻寬，單位是赫茲，若用v表示每個碼元離散電平的數目
夏農定理：極限資料傳輸速率=wlog2(1+s/n)
第三章、資料鏈路層
零位元填充：五個連續的1後面就補0
流量控制與可靠傳輸：滑動視窗機制
隨機訪問介質訪問控制
csma協議：1-堅持：通道忙則繼續偵聽至空閒，非堅持：通道忙則放棄偵聽，等待隨機時間後再偵聽，p-堅持：通道忙則下一時隙再偵聽，空閒以概率p傳送資料，1-p推遲下一時隙
csma/cd協議：傳送前先偵聽，空閒則立即傳送資料並進行衝突檢測，如果通道忙則繼續偵聽通道，直到通道變為空閒，半雙工，爭用期是兩倍單程傳播時延。為了檢測到可能存在的衝突，幀的傳輸時延至少要兩倍於訊號在匯流排中的傳播時延
csma/ca協議：碰撞避免：預約通道，ack幀，rts/cts幀
解決衝突皆採用二進位制指數退避演算法
第四章、網路層
nat網路位址轉換，將私有網路位址轉換為公用位址，對外隱藏內部管理的ip
icmp網際控制報文協議：允許主機或路由器報告差錯和異常情況
路由協議rip ：優先跳距離短的路徑，最多允許15跳，每30秒廣播一次rip路由更新資訊
路由協議ospf：鏈路變化時才用洪氾法向所有路由器傳送資訊
第五章、傳輸層
tcp：可靠有連線，三握四揮，流量控制與擁塞控制
udp：不可靠無連線，無連線，首部僅8位元組
第六章、應用層
網域名稱系統dns：遞迴查詢/遞迴與迭代相結合
檔案傳輸協議ftp：採用c/s工作方式，使用兩個並行的tcp連線
cookie與session：cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在伺服器端保持狀態的方案。
滑動視窗協議
雙方都有傳送視窗和接收視窗，傳送方每收到乙個確認，就把傳送視窗向前移動乙個分組的位置，接收方一般採用累計確認方式（即累計重傳協議），連續接收到的分組只傳送最後乙個分組的確認。另外還有1位元協議（送一幀等一幀）與後退n協議（可以發多個幀，但若前面某個幀
幀同步（rst即時戰略）和狀態同步（mmo大型多人遊戲）
幀同步：伺服器轉化客戶端操作，每個客戶端在固定邏輯幀執行該幀所有客戶端的操作命令，在嚴格一致的時間軸上執行同樣的命令序列得到同樣的結果
優點開發方便，打擊反饋好，網路流量小
缺點斷線要追幀，難反外掛程式，客戶端計算壓力大，一致性要求高，伺服器等全部的第n幀到了再發下一幀操作，需要平滑插值過渡處理
狀態同步：伺服器承載所有計算，客戶端只做表現
優點斷線易重連，防外掛程式
缺點打擊反饋不夠精準，所有表現由伺服器推送，各表現難契合，
三次握手：
客戶端傳送syn包到伺服器，並進入syn_send狀態，等待伺服器確認
伺服器收到syn包，需要發出ack包確認，同時自己也傳送乙個syn包，此時伺服器從 listen狀態進入syn_recv狀態
客戶端收到伺服器的syn+ack包，向伺服器傳送確認ack，此包傳送完畢，客戶端和 伺服器進入established狀態，完成三次握手
握手過程中傳送的包不包含資料，三次握手完畢後，客戶端與伺服器才正式開始傳送資料， 理想狀態下，一旦tcp建立，在通訊雙方中任何一方主動關閉連線之前，tcp連線都將被一 直保持下去
四次揮手：
主動關閉方傳送乙個fin包，用來關閉主動方到被關閉方的資料傳輸，此時進入 fin_wait1狀態，也就是主動方告訴被動方：我已經不會再給你傳送資料了（當然，在fin 包之前傳送出去的資料，如果主動方沒收到對應的ack確認報文，主動方依然會重發這些 資料），但是此時主動關閉方還可以接受資料
被動關閉方收到fin包後，傳送乙個ack給對方，進入close_wait狀態，主動關閉方 收到ack確認後進入fin_wait2狀態
被動關閉方傳送乙個fin包，用來關閉被動關閉方到主動關閉方的資料傳輸，此時進入 last_ack狀態。也就是告訴主動關閉方，我的資料也傳完了，不會再給你傳送資料了
主動關閉方收到fin後傳送乙個ack確認給被動關閉方，進入time_wait狀態，被動關 閉方接受到ack後進入close狀態，至此，完成四次揮手斷開連線
主動關閉方進入time_wait之後，會等待2msl（最長報文存活時間）時間，如果這個時 間過去以後沒有收到對方任何響應，就關閉連線，銷毀資源，進入close狀態。之所以要 等待2msl時間，是因為這樣可以防止最後傳送的這個ack丟失。在time_wait狀態下等待2msl時間，是為了能夠正確處理第乙個ack丟失的情況 下，能夠收到對端重傳的fin，然後重傳ack。
使用者資料+應用首部構成應用資料； 應用資料在傳輸層+tcp首部，形成tcp段； tcp段在網路層+ip首部，形成ip資料報； ip資料報在網路介面層+乙太網幀頭幀尾，形成乙太網幀，然後傳送到網路上；
關於連續arq協議內容： arq即自動重傳請求，當傳送方傳送資料後，超時計時器開始計時，當超時計時器到期時 沒收到對端的確認報文，則傳送方重新傳送資料。
關於tcp/ip實現流量控制： 流量控制的意義：使得接收方來得及處理傳送方傳送的資料。 流量控制主要通過滑動視窗實現：滑動視窗
擁塞控制，就是防止過多的資料注入到網路中，從而使網路中的路由器或鏈路避免過 載。 tcp/ip實現擁塞控制有四個演算法：慢開始、擁塞避免、快重傳、快恢復。
慢開始和擁塞避免演算法： 慢開始演算法的核心是從小到大逐漸增大擁塞視窗的數值。通常在剛開始傳送報文時，先把擁 塞視窗設定為乙個最大報文段mss的數值，而在每收到對上一輪報文段的確認後，就把擁 塞視窗的數值加倍。 為了防止擁塞視窗增長過大引起網路阻塞，還需要維護乙個慢開始門限的狀態變數，當擁塞 視窗的值小於慢開始門限時，使用慢開始演算法，一旦擁塞視窗的值大於慢開始的門限值，就 改用擁塞避免演算法。 擁塞避免演算法的思路時讓擁塞視窗緩慢增大，收到每一輪的確認後，將擁塞視窗的值加1， 而不是加倍，這樣擁塞視窗的值按照線性規律緩慢增長。 無論是在慢開始階段還是在擁塞避免階段，只要傳送方判斷網路出現擁塞（沒有按時接收到 確認），就把慢開始門限設定為出現擁塞時傳送視窗的一半，但最小不能小於2個mss值， 而後把擁塞視窗的值重新設定為1個mss，執行慢開始。
快重傳和快恢復演算法： 快重傳演算法首先要求接收方每收到乙個失序的報文段後就立即傳送重複確認（重**送對前 面有序部分的確認），而不是等待自己傳送資料時才進行確認，也不是累積收到的報文傳送 積累確認，如果傳送方連續收到三個確認重複，就應該立即重傳對方未收到的報文段（有收 到重複確認，說明後面的報文段都送達了，只有中間丟失的報文段沒送達）。
快恢復演算法是當傳送方連續收到三個重複確認時，就把慢開始門限減半，這是為了預防發生 網路擁塞。注意接下來不執行慢開始演算法。由於傳送方現在認為網路很可能沒有發生很嚴重 的阻塞（如果發生了嚴重阻塞的話，就不會一連有好幾個報文到達接收方，就不會導致接收 方連續傳送重複確認），因此與慢開始不同之處是現在不執行慢開始演算法（即擁塞視窗的值
不設為1個mss），而是把擁塞視窗的值設為慢開始門限減半後的值，而後開始執行擁塞避 免演算法，線性地增大擁塞視窗。
繁忙的三月
好久沒更新了，本來上週寫了很長一篇澳門遊記，可惜被ie 或者說這個 吞了，再也沒有力氣重寫一遍。想想也挺佩服那些文人學者的，寫本數十萬字的書，結果由於戰亂或各種狀況給丟了，居然還能重寫起來，一寫又是好幾年，沒有那種執著的學術追求恐怕是不行的。最近一直忙，還要學車，23日就要考樁了，從去年的8月拖到現...
三月二十號
今天周四，今天沒上課，今天把loadrunner錄製對discuz的實戰一部分東西做好了，感覺挺好的，錄製註冊指令碼，登入指令碼。錄製成功了，在場景裡面也執行成功了。感覺挺好，現在回想起來，兩周之前，或許連loadrunner是啥還不知道呢，然後剛開始看著教程一點一點費勁的安裝軟體，安裝好幾次都失敗...
三月英語 丘陵
這個月比較突出的事情，就是轉變狀態了。開學之後能夠堅持學習英語是一件簡單又困難的事情。對於我來講，這個月尤為困難的一點是我對aj失去了興趣，就像平地起了乙個小丘陵，逃不脫，跨不過。具體的情況大概是這樣，雖然aj的故事聽起來是挺有意思，但是aj的腔調忽然不是很喜歡。總覺得aj的那個感覺並不是我想要的，...