OSI七層模型

OSI模型（Open System Interconnection Model）是一個由ISO提出得到概念模型，試圖提供一個使各種不同的的計算機和網路在世界範圍內實現互聯的標準框架。

分層結構

OSI參考模型採用分層結構，如圖所示。 不得不說，這張圖真的超經典呀。一張圖搞定你你不懂的一切。

主要分為以下七層（從下至上）：物理層、資料鏈路層、網路層、傳輸層、會話層、表示層、應用層。

各層功能

• 物理層
  簡單的說，物理層（Physical Layer）確保原始的資料可在各種物理媒體上傳輸。在這一層上面規定了啟用、維持、關閉通訊端點之間的機械特性、電氣特性、功能特性以及過程特性，為上層協議提供了一個傳輸資料的物理媒體。這一層傳輸的是bit流。
• 資料鏈路層
  資料鏈路層（Data Link Layer）在不可靠的物理介質上提供可靠的傳輸。該層的作用包括：實體地址定址、資料的成幀、流量控制、資料的檢錯、重發等。這一層中將bit流封裝成frame幀。
• 網路層
  網路層（Network Layer）負責對子網間的資料包進行路由選擇。此外，網路層還可以實現擁塞控制、網際互連等功能。在這一層，資料的單位稱為資料包（packet）。
• 傳輸層
  傳輸層是第一個端到端，即主機到主機的層次。傳輸層負責將上層資料分段並提供端到端的、可靠的或不可靠的傳輸。此外，傳輸層還要處理端到端的差錯控制和流量控制問題。在這一層，資料的單位稱為資料段（segment）。
• 會話層
  這一層管理主機之間的會話程序，即負責建立、管理、終止程序之間的會話。會話層還利用在資料中插入校驗點來實現資料的同步，訪問驗證和會話管理在內的建立和維護應用之間通訊的機制。如伺服器驗證使用者登入便是由會話層完成的。使通訊會話在通訊失效時從校驗點繼續恢復通訊。
• 表示層
  這一層主要解決使用者資訊的語法表示問題。它將欲交換的資料從適合於某一使用者的抽象語法，轉換為適合於OSI系統內部使用的傳送語法。即提供格式化的表示和轉換資料服務。資料的壓縮和解壓縮， 加密和解密等工作都由表示層負責。
• 應用層
  這一層為作業系統或網路應用程式提供訪問網路服務的介面。

各層傳輸協議、傳輸單元、主要功能性裝置比較

關於協議你應該知道這些

以上通過圖表、文字向大家闡述了七層模型每一層的具體功能及其相關協議，但知道了這些還不夠，你還要知道以下這些。

TCP/UDP

• TCP/UDP是什麼？
  TCP — Transmission Control Protocol，傳輸控制協議。
  UDP — User Data Protocol，使用者資料報協議。
• TCP/UDP的區別（優缺點）？
  (1)、TCP是面向連線的，UDP是面向無連線的。TCP在通訊之前必須通過三次握手機制與對方建立連線，而UDP通訊不必與對方建立連線，不管對方的狀態就直接把資料傳送給對方
  (2)、TCP連線過程耗時，UDP不耗時
  (3)、TCP連線過程中出現的延時增加了被攻擊的可能，安全性不高，而UDP不需要連線，安全性較高
  (4)、TCP是可靠的，保證資料傳輸的正確性，不易丟包;UDP是不可靠的，易丟包
  (5)、tcp傳輸速率較慢，實時性差，udp傳輸速率較快。tcp建立連線需要耗時，並且tcp首部資訊太多，每次傳輸的有用資訊較少，實時性差。
  (6)、tcp是流模式，udp是資料包模式。tcp只要不超過緩衝區的大小就可以連續傳送資料到緩衝區上，接收端只要緩衝區上有資料就可以讀取，可以一次讀取多個數據包，而udp一次只能讀取一個數據包，資料包之間獨立
• TCP三次握手過程

STEP 1：主機A通過向主機B傳送一個含有同步序列號的標誌位的資料段給主機B，向主機B請求建立連線,通過這個資料段，主機A告訴主機B兩件事:我想要和你通訊；你可以用哪個序列號作為起始資料段來回應我。
STEP 2：主機B收到主機A的請求後,用一個帶有確認應答(ACK)和同步序列號(SYN)標誌位的資料段響應主機A，也告訴主機A兩件事：我已經收到你的請求了，你可以傳輸資料了；你要用哪佧序列號作為起始資料段來回應我。
STEP 3：主機A收到這個資料段後，再發送一個確認應答，確認已收到主機B的資料段：”我已收到回覆，我現在要開始傳輸實際資料了。這樣3次握手就完成了，主機A和主機B就可以傳輸資料了。

• 注意
  此時需要注意的是，TCP建立連線要進行3次握手，而斷開連線要進行4次。
• 名詞解釋

ACK：TCP報頭的控制位之一，對資料進行確認，確認由目的端發出，用它來告訴傳送端這個序列號之前的資料段都收到了。比如，確認號為X，則表示前X-1個數據段都收到了，只有當ACK=1時，確認號才有效，當ACK=0時，確認號無效，這時會要求重傳資料，保證資料的完整性。
SYN：同步序列號，TCP建立連線時將這個位置1。
FIN ：傳送端完成傳送任務位，當TCP完成資料傳輸需要斷開時，提出斷開連線的一方將這位置1。

• TCP可靠性的四大手段
  (1)、順序編號： tcp在傳輸檔案的時候，會將檔案拆分為多個tcp資料包，每個裝滿的資料包大小大約在1k左右，tcp協議為保證可靠傳輸，會將這些資料包順序編號
  (2)、確認機制： 當資料包成功的被髮送方傳送給接收方，接收方會根據tcp協議反饋給傳送方一個成功接收的ACK訊號，訊號中包含了當前包的序號
  (3)、超時重傳： 當傳送方傳送資料包給接收方時，會為每一個數據包設定一個定時器，當在設定的時間內，傳送方仍沒有收到接收方的ACK訊號，會再次傳送該資料包，直到收到接收方的ACK訊號或者連線已斷開
  (4)、校驗資訊： tcp首部校驗資訊較多，udp首部校驗資訊較少。

  上文部分協議簡單講

• IEEE 802.1A、IEEE 802.2
  IEEE是英文Institute of Electrical and Electronics Engineers的簡稱，其中文譯名是電氣和電子工程師協會。IEEE 802規範定義了網絡卡如何訪問傳輸介質（如光纜、雙絞線、無線等），以及如何在傳輸介質上傳輸資料的方法，還定義了傳輸資訊的網路裝置之間連線建立、維護和拆除的途徑。遵循IEEE 802標準的產品包括網絡卡、橋接器、路由器以及其他一些用來建立區域網絡的元件。
  IEEE802.1A —— 區域網體系結構
  IEEE802.2 ——- 邏輯鏈路控制(LLC)
• FDDI
  光纖分散式資料介面（Fiber Distributed Data Interface）
• PPP
  點對點協議（Point to Point Protocol），為在點對點連線上傳輸多協議資料包提供了一個標準方法。
• IP
  網際網路協議（Internet Protocol），為計算機網路相互連線進行通訊而設計的協議。任何廠家生產的計算機系統，只要遵守IP協議就可以與因特網互連互通。IP地址具有唯一性，根據使用者性質的不同，可以分為5類。
• ICMP
  控制報文協議（Internet Control Message Protocol）。TCP/IP設計了ICMP協議，當某個閘道器發現傳輸錯誤時，立即向信源主機發送ICMP報文，報告出錯資訊，讓信源主機採取相應處理措施，它是一種差錯和控制報文協議，不僅用於傳輸差錯報文，還傳輸控制報文。
• ARP/RARP
  ARP (Address Resolution Protocol) 地址解析協議
  RARP (Reverse Address Resolution Protocol) 反向地址解析協議
• SMTP
  簡單郵件傳輸協議（Simple Mail Transfer Protocol），它是一組用於由源地址到目的地址傳送郵件的規則，由它來控制信件的中轉方式。SMTP協議屬於TCP/IP協議簇，它幫助每臺計算機在傳送或中轉信件時找到下一個目的地。通過SMTP協議所指定的伺服器,就可以把E-mail寄到收信人的伺服器上了。
• SNMP
  簡單網路管理協議（Simple Network Management Protocol ），該協議能夠支援網路管理系統，用以監測連線到網路上的裝置是否有任何引起管理上關注的情況。
• DNS
  域名系統（Domain Name System），因特網上作為域名和IP地址相互對映的一個分散式資料庫，能夠使使用者更方便的訪問網際網路，而不用去記住能夠被機器直接讀取的IP數串。通過主機名，最終得到該主機名對應的IP地址的過程叫做域名解析(或主機名解析)。DNS協議執行在UDP協議之上，使用埠號53。
• FTP
  文字傳輸協議（File Transfer Protocol），用於Internet上的控制檔案的雙向傳輸。同時，它也是一個應用程式Application）。基於不同的作業系統有不同的FTP應用程式，而所有這些應用程式都遵守該協議以傳輸檔案。在FTP的使用當中，使用者經常“下載”（Download）和“上載”（Upload）。“下載”檔案就是從遠端主機拷貝檔案至自己的計算機上；“上載”檔案就是將檔案從自己的計算機中拷貝至遠端主機上。
• HTTP
  超文字傳輸協議（HyperText Transfer Protocol），是網際網路上應用最為廣泛的一種網路協議。所有的WWW檔案都必須遵守這個標準。它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文字文件，還確定傳輸文件中的哪一部分，以及哪部分內容首先顯示(如文字先於圖形)等。HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端伺服器模型，是一個無狀態的協議。

原文地址：https://blog.stanley.wang/