網絡原理

OSI模型的七層結構

一、物理層：
二進傳輸
爲啓動、維護以及關閉物理鏈路定義了電氣規範、機械規範、過程規範、和功能規範。
二、數據鏈路層：
訪問介質：
定義如何格式化數據以便進行傳輸以及如何控制對網絡的訪問。
支持錯誤檢測
三、網絡層：
路由數據包
選擇傳遞數據的最佳路徑
支持邏輯尋址和路徑選擇
四、傳輸層：
確保數據傳輸的可靠性
創建、維護和終止虛擬電路
信息留空制來保障可靠性
五、會話層：
主機間通訊
創建、管理和終止在應用程序之間的會話
六、表示層：
數據表示：
確保接受系統能夠讀出該數據
格式化數據
構建數據
協商用於應用層的數據傳輸語法
提供加密
七、應用層：
網絡進程訪問應用層：
爲應用程序進程（例如，電子郵件、文件傳輸和終端仿真）提供網絡服務
提供用戶身份驗證
PDU:

PDU:Prtocol Data Unit,協議數據單元是指對等層次之間的數據單位
物理層的PDU是數據位bit
數據鏈路層的PDU是數據幀frame
網絡層的PDU是數據包packet
傳輸層的PDU是數據段segment
其餘更高層次的PDU是消息message
三種通信方式：

單播：unicast
廣播：broadcast
主播：multicast
UTP交叉線T568A和T568B的線序

T568A：
綠白、綠、橙白、藍、藍白、橙、棕白、棕

T568B：
橙白、橙、綠白、 藍、藍白、綠、棕白、棕
Hub集線器

Hub:多端口中繼器
Hub並不記憶該信息包是由哪一個MAC地址發出，哪一個MAC地址在Hub的哪一個端口
Hub的特色：
共享帶寬
半雙工
以太網橋

交換式以太網的優點
擴展了網絡帶寬
分割了網絡衝突域，使網絡衝突被限制在最小的範圍內
交換機做爲更加智能的交換設備，可以提供更多用戶所要求的功能：優先級、虛擬網7遠程檢測......
Hub和交換機

集線器屬於OSI的第一層物理層設備，而網橋屬於OSI的第二層數據鏈路層設備
從工做方式來看，集線器是一種廣播模式，全部端口在一個衝突域裏面。網橋的能夠經過端口隔離衝突
Hub是全部共享總線和共享帶寬。網橋每一個端口占一個帶寬
路由器

爲了實現路由，路由器須要作下列事情：
分隔廣播域
選擇路由表中到達目標最好的路徑
維護和檢查路由信息
鏈接廣域網
路由

路由：把一個數據包從一個設備發送到不一樣網路里的另外一個設備上去。這些工做依靠路由器來玩成。路由器只關心網絡的狀態和決定網絡中的最佳路徑。路由的實現依靠路由器中的路由表來完成。
VLAN

分隔廣播域
安全
靈活管理
VLAN=廣播域=邏輯網絡（Subnet)
分層的網絡架構

核心層Core Layer
企業級應用快速轉發
分佈層Distribution Layer
廣播域，路由，安全，遠程接入，訪問層匯聚
訪問層AccessLayer
終端輸入
TCP/IP協議棧

TCP/IP 協議棧是一系列網絡協議的總和，是構成網絡通訊的核心骨架，它定義了電子設備如何連入因特網，以及數據如何在它們之間進行傳輸。TCP/IP 協議採用4層結構，分別是應用層、傳輸層、網絡層和鏈路層，每一層都呼叫它的下一層所提供的協議來完成本身的需求。因爲咱們大部分時間都工做在應用層，下層的事情不用咱們操心；其次網絡協議體系自己就很複雜龐大，入門門檻高，所以很難搞清楚TCP/IP的工做原理，通俗一點講就是，一個主機的數據要通過哪些過程才能發送到對方的主機上。
應用層常見的網絡協議及端口號

http80 https 443 ftp21 dnstcp53 udp53 tftp69 smtp25 pop3 110 imap143 telnet23 ssh22 mysql 3306
oracle 1521
sql server 1433
redis 6379
TCP特性

工做在傳輸層
面向鏈接協議
全雙工協議
半關閉
錯誤檢查
將數據打包成段，排序
確認機制
數據恢復，重傳
流量控制，滑動窗口
擁塞控制，慢啓動和擁塞避免算法
有限狀態機FSM：Finite State Machine

CLOSED 沒有任何鏈接狀態
LISTEN偵聽狀態，等待來自遠方TCP端口的鏈接請求
SYN-SENT 在發送連接請求後，等待對方確認
SYN-RECEIVED在收到和發送一個鏈接請求後，等待對方確認
ESTABLISHED表明傳輸鏈接創建，雙方進入數據傳送狀態
FIN-WAIT-1主動關閉，主機已發送關閉鏈接請求，等待對方確認
FIN-WAIT-2主動關閉，主機已收到對方關閉傳輸鏈接確認，等待對方發送關閉鏈接請求
TIME-WAIT完成雙向傳輸鏈接關閉，等待全部分組消失
CLOSE-WAIT被動關閉，收到對方發來的關閉鏈接請求，並以確認
LAST-ACK被動關閉，等待最後一個關閉傳輸鏈接確認，並等待全部分組消失
CLOSING雙方同時嘗試關閉傳輸鏈接，等待對方確認
有限狀態機

客戶端先發送一個FIN給服務端，本身進入了FIN_WAIT_1狀態，這時等待接受服務端的報文，該報文會有三種可能：
只有服務端的ACK
只有度無故的FIN
基於服務端的ACK，又有FIN
一、只收到服務器的ACK，客戶端對進入FIN_WAIT_2狀態，後續當收到服務端的FIN時，迴應發送一個ACK，會進入到TIME_WAIT狀態，這個狀態會持續2MSL（TCP報文段在網絡中的最大生存時間，RFC 1122標準的建議值是2min）。客戶端等待2MSL，是爲了當最後一個ACK丟失時，能夠再發送一次。由於服務端在等待超時後會再發送一個FIN給客戶端，進入客戶端知道ACK已丟失
二、只有服務端的FIN時，迴應一個ACK給服務端，進入CLOSING狀態，而後接受到服務端的ACK時，進入TIME_WAIT狀態
三、同時收到服務端的ACK和FIN，直接進入TIME_WAIT狀態
客戶端的典型狀態轉移

客戶端經過connect系統調用主動與服務器創建鏈接connect系統調用首先給服務器發送一個同步報文段，使鏈接轉移到SYN_SENT狀態
此後connect系統調用可能由於以下兩個緣由失敗返回：
一、若是connect鏈接的目標端口不存在（未被任何進程監聽），或者該端口仍被處於TIME_WAIT狀態的鏈接所佔用（見後文），則服務器將給客戶端發送一個復位報文段，connect調用失敗。
二、若是目標端口存在，但connect在超時時間內未收到服務器的確認報文段，則connect調用失敗。
connect調用失敗將使鏈接馬上返回初始的CLOSED狀態。若是客戶端成功收到服務器的同步報文段和確認，則connect調用成功返回，鏈接轉移至ESTABLISHED狀態。
處於FIN_WAIT_2狀態的客戶端須要等待服務器發送結束報文段，才能轉移至TIME_WAIT狀態，不然它將一直停留在這個狀態。若是不是爲了在半關閉狀態下繼續接收數據，鏈接長時間地停留在FIN_WAIT_2狀態並沒有益處。鏈接停留在FIN_WAIT_2狀態的狀況可能發生在：客戶端執行半關閉後未等服務器關閉鏈接就強行退出了。此時客戶端鏈接由內核來接管，可稱之爲孤兒鏈接（和孤兒進程相似）
Linux爲了防止孤兒鏈接長時間存留在內核中，定義了兩個內核參數：
/proc/sys/net/ipv4/tcp_max_orphans指定內核能接管的孤兒鏈接數目
/proc/sys/net/ipv4/tcp_fin_timeout指定孤兒鏈接在內核中生存的時間
TCP超時重傳

異常網絡情況下（開始出現超時或丟包），TCP控制數據傳輸以保證其承諾的可靠服務
TCP服務必須可以重傳超時時間內未收到確認的TCP報文段。爲此，TCP模塊爲每一個TCP報文段都維護一個重傳定時器，該定時器在TCP報文段第一次被髮送時啓動。若是超時時間內未收到接受方的應答，TCP模塊將重傳TCP報文段並重置定時器。至於下次重傳的超時時間如何選擇，以及最多執行多少次重傳，就是TCP的重傳策略
與TCP超時重傳相關的兩個內核參數：
/proc/sys/net/ipv4/tcp_retries1,指定在底層IP接管以前TCP最少執行的重傳次數，默認值是3
/proc/sys/net/ipv4/tcp_retries2,指定鏈接放棄前TCP最多能夠執行的重傳次數，默認值15（通常對應13~30Min)
擁塞控制

網絡中的帶寬、交換節點中的緩存和處理機等，都是網絡的資源。在，某個時間，若對網絡中某一資源的需求超過了該資源所能提供的可承受的能力，網絡的性能就會變壞。這種狀況就叫作擁塞
TCP爲了提供=高網絡利用率，下降丟包率啊，並保證網絡資源對每條數據流的公平性。即所謂的擁塞控制
TCP擁塞控制的標準文檔是RFC 5681，其中詳細介紹了擁塞控制的四個部分：
慢啓動（slow start)、擁塞避免（congestin avoidance)、快速重傳（fastretransmit)和快速恢復（fast recovery).擁塞控制算法在linux下有多種實現，好比reno算法、vegas算法和cubic算法等。它們或者部分或者所有實現了上述四個部分
當前所使用的擁塞控制算法
/proc/sys/net/ipv4/tcp_congestion_control
UDP特性

工做在傳輸層提供不可靠的網絡訪問非面向鏈接協議有限的錯誤檢查傳輸性能高無數據恢復特性