《求職》第三部分 - 計算機網絡篇 - 計算機網絡總結

1.網絡總述

計算機經網絡體系結構：

各層作用及協議

分層	作用	協議
物理層	通過媒介傳輸比特，確定機械及電氣規範（比特 Bit）	RJ45、CLOCK、IEEE802.3（中繼器，集線器）
數據鏈路層	將比特組裝成幀和點到點的傳遞（幀 Frame）	PPP、FR、HDLC、VLAN、MAC（網橋，交換機）
網絡層	負責數據包從源到宿的傳遞和網際互連（包 Packet）	IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP（路由器）
運輸層	提供端到端的可靠報文傳遞和錯誤恢復（ 段Segment）	TCP、UDP、SPX
會話層	建立、管理和終止會話（會話協議數據單元 SPDU）	NFS、SQL、NETBIOS、RPC
表示層	對數據進行翻譯、加密和壓縮（表示協議數據單元 PPDU）	JPEG、MPEG、ASII
應用層	允許訪問OSI環境的手段（應用協議數據單元 APDU）	FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

OSI七層模型和TCP/IP四層模型分別是什麼？有什麼區別？

• OSI模型
  • 應用層：HTTP、SMTP、SNMP、FTP、Telnet、SSH、NFS
  • 表示層：SMB、AFP
  • 會話層：SSH、RPC、NetBIOS、ASP、Winsock、BSD sockets
  • 傳輸層：TCP、UDP、
  • 網絡層：IP、ICMP、IGMP、BGP、OSPF、RIP、ARP、RARP
  • 數據鏈路層：以太網、PPP
  • 實體層：線路、無線電、光纖
• TCP/IP協議棧模型
  • 應用層（OSI5到7層）：網絡應用程序及它們的應用層協議存留的地方
  • 傳輸層（OSI4層）：在應用程序端點之間傳送應用層報文（端對端）
  • 網絡層（OSI3層）：將數據報從一臺主機移動到另一臺主機（主機對主機）
  • 接口層（OSI1和2層）：通過源和目的地之間的一系列路由器路由數據報（設備對設備）
• 兩種模型的區別
  • OSI
    強調提供很可靠的的數據傳輸服務，每一層都要進行檢測和處理錯誤。
  • TCP/IP認爲可靠要由端對端來保證，不要把系統搞得太複雜。傳輸層利用檢驗和、確認分組、重傳、序號和定時器等手段來保證可靠性控制。

2.應用層

2.1 應用程序體系結構

1. 客戶機/服務器(C/S)體系結構
2. P2P 體系結構

2.2 因特網傳輸服務

當創建一個新的因特網應用時，首先要做出的決定是選擇 UDP 還是 TCP，它們能爲應用程序提供下列服務：

• TCP

面向連接的服務
可靠數據傳輸服務

• UDP

無連接的服務
不可靠數據傳輸服務（不保證到達，也不保證有序到達）

除此之外， TCP 具有擁塞控制機制，擁塞控制不一定能爲應用程序帶來直接好處，但能對整個網絡帶來好處。UDP 沒有擁塞控制。

2.3 應用層協議

2.3.1 HTTP

• HTTP（HyperText Transfer Protocol，超文本傳輸協議）是用於從 WWW（World Wide Web，萬維網）服務器傳輸超文本到本地瀏覽器的傳送協議。HTTP 是萬維網的數據通信的基礎。

使用 TCP 作爲運輸層協議

無狀態協議：服務器向客戶機發送被請求的文件時，並不存儲任何關於該客戶機的狀態信息。假如某個特定
的客戶機在短短的幾秒鐘內兩次請求同一個對象，服務器並不會因爲剛剛爲該用戶提供了該對象就不再做出反
應，而是重新發送該對象。

• HTTP 客戶機： web 瀏覽器
• HTTP 服務器： web 服務器，包含 web 對象（HTML 文件、 JPEG 文件、 java 小程序、視頻片段等）

連接類型：

• 非持久連接：每個請求/響應對是經一個單獨的 TCP 連接發送
• 持久連接：所有請求/響應對使用同一個 TCP 連接發送

如果使用非持久連接，將 TCP 握手第三步與一個 HTTP 請求報文結合起來發送，服務器接收請求後響應一個
對象。因此，傳輸一個對象消耗 2 個 RTT。（可以同時建立多個連接並行傳輸）但是，由於 TCP 連接會分配
緩衝區和變量，大量使用非持久連接會給服務器造成壓力

如果使用持久連接，則客戶機接收到請求對象後服務器不會發送一個 TCP 連接關閉請求。這個連接服務於所
有 web 對象的傳輸（流水線發送），如果經過一個時間間隔仍未被使用，則 HTTP 服務器關閉連接

• http1.0 使用非持久連接
• http1.1 使用持久連接

1） HTTP 報文格式(請求報文)

• 請求行
  • 請求方式
    • GET POST PUT HEAD DELETE
  • 請求資源路徑
  • HTTP協議版本
    • HTTP/1.1與HTTP/1.0的區別：
      • 長連接：HTTP/1.1默認使用長連接
      • 帶寬優化：HTTP/1.1中在請求消息中新引入了用於帶寬優化的頭域
        • range頭域與Content-Range頭域：請求消息中如果包含比較大的實體內容，但不確定服務器是否能夠接收該請求，它允許只請求資源的某個部分。在響應消息中Content-Range頭域聲明瞭返回的這部分對象的偏移值和長度。
          響應100則繼續發送整體，響應401則停止發送。
        • Accept-Encoding頭域與Content-Encoding頭域：對消息進行端到端的編碼。
      • 錯誤提示：
        • HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE,
          CONNECT這些Request方法。
        • HTTP/1.1引入了一個Warning頭域，增加對錯誤或警告信息的描述。
        • 在HTTP/1.1中新增了24個狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
• 請求頭（首部行）
  • Host：（1.1引入）請求的目標主機
  • If-Modified-Since：如果請求報文中包含此字段，則爲條件GET請求報文，用於緩存（響應報文304代碼表示緩存未修改）
  • Referer：檢測來源，防盜鏈
  • User-Agent：用戶代理，即向服務器發送請求的瀏覽器的類型（服務器可以正確地爲不同類型的用戶代理髮送相同對象的不同版本）
  • Cookie：在無狀態的HTTP之上建立一個用戶會話層
  • Cache-Control：緩存相關
  • Connection：
    • 短連接：每個TCP連接只傳輸一個請求報文和一個響應報文
      • 給web服務器帶來嚴重的負擔（高併發短連接，TIME_WAIT）
      • 安全性好
    • 長連接：所有的請求響應經相同的的TCP連接發送
      • HTTP1.1的默認模式是使用帶流水線的持續連接
      • 在一個TCP連接內，多個HTTP請求可以並行，下一個HTTP請求在上一個HTTP請求的應答完成之前就發起
      • 節約資源
  • Range：允許只獲取文件部分內容
• 實體內容
  • GET報文：
    • 通過URL參數傳遞的方式提交數據
      • 通過"？"區分資源路徑和提交的數據
      • 參數間用&分隔
    • 長度受限
    • 安全性低
  • POST報文：
    • 表單提交
    • 長度不受限制
    • 不被緩存，安全性高

“Connection:close”：瀏覽器告訴服務器不希望使用持久連接，而是要求服務器在發送完請求後關閉連接
“Accept-language”：用戶想得到該對象的語法版本計算機網絡

方法字段：
• GET：絕大部分 HTTP 請求報文使用 GET 方法
• POST：用戶提交表單時（如向搜索引擎提供關鍵字），但提交表單不一定要用 POST 方法
• HEAD：類似於 GET，區別在於服務器返回的響應報文中不包含請求對象（常用於故障跟蹤）
• PUT：用於向服務器上傳對象
• DELETE：用於刪除服務器上的對象

【注】GET 與 POST 的區別與聯繫

2） HTTP 報文格式(響應報文)

• 響應狀態行
  • 協議版本
  • 狀態碼
    • 200 OK：請求成功，信息包含在返回的響應報文中
    • 301 Moved Permanently：請求的對象已經被永久轉移了，新的 URL 定義在響應報文的 Location 首部中。客戶機軟件自動用新的 URL 獲取對象
    • 302：找到
    • 304：Not Modified：條件 GET 的響應報文中的狀態碼， web 服務器告訴 web 緩存相應對象未被修改（If-Modified-Since，Last-Modified，緩存，條件GET）
    • 400 Bad Request：請求不能被服務器理解
    • 401：未經授權
    • 403 Forbidden：服務器收到請求，但是拒絕提供服務。服務器通常會在響應報文中給出不提供服務的原因
    • 404 Not Found：被請求的文檔不在服務器上
    • 500：服務器錯誤
    • 502：無效網關
    • 504：網關超時
    • 505 HTTP Version Not Supported：服務器不支持請求報文使用的 HTTP 協議版本
  • 描述信息
• 響應頭
  • Server
  • Date：報文生成、發送時的日期
  • Expires：控制緩存過期時間
  • Location
  • Accept-Ranges
  • Content-*
  • Last-Modified： web 對象最後修改的日期
  • ETag：最後緩存時間和文件大小的哈希
  • Expires：在某時間前，直接使用，不必請求
  • Cache-Control：在某時間內，直接使用，不必請求
  • Transfer-Encoding
  • Set-Cookie
  • Connection
• 實體內容
  • MIME類型：大類別/具體類型

“Connection:close”：告訴客戶機在報文發送完後關閉了 TCP 連接
Telnet： HTTP 響應報文查看工具

3） cookie>

用於識別用戶，可能出於下列意圖：
• 服務器想限制用戶的訪問
• 服務器想把內容與用戶身份關聯起來
cookie 包含 4 個組成部分：

1. 在 HTTP 響應報文中有一個 Set-cookie 首部行

2. 在 HTTP 請求報文中有一個 Cookie 首部行

3. 在用戶端系統中保留有一個 cookie 文件，由用戶的瀏覽器管理

4. 在 web 站點有一個後端數據庫

4） web 緩存>
web 緩存器也叫代理服務器，用於緩存 web 對象。用戶可以配置其瀏覽器，使得所有 HTTP 請求首先指向web 緩存器。

如果 web 緩存器沒有請求的對象，會與初始服務器直接建立一條 TCP 連接， web 緩存器進一步發送 HTTP 請
求，獲取對象，當接收到對象後，首先在本地緩存，然後生成一個 HTTP 響應報文，發送給客戶機（因此，web 緩存器既是客戶機，又是服務器）。

web 緩存器類似於內存與處理器之間的 cache，它能從整體上大大降低因特網上的 web 流量，從而改善所有應用的性能。

條件 GET： web 緩存器使用條件 GET 向 web 服務器確認某個對象是否已經被修改（不是最新的對象）。如果

1)請求報文使用 GET 方法；

2)並且包含一個 If-modified-since:首部行，那麼這個 HTTP 請求報文就是一個條件 GET計算機網絡。如果相應對象未被修改， web 服務器返回一個實體爲空的響應報文(也就是說並沒有包含請求對象)，狀態碼爲
“304 Not Modified

請求方法

方法	意義
OPTIONS	請求一些選項信息，允許客戶端查看服務器的性能
GET	請求指定的頁面信息，並返回實體主體
HEAD	類似於 get 請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
POST	向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改
PUT	從客戶端向服務器傳送的數據取代指定的文檔的內容
DELETE	請求服務器刪除指定的頁面
TRACE	回顯服務器收到的請求，主要用於測試或診斷

狀態碼（Status-Code）

• 1xx：表示通知信息，如請求收到了或正在進行處理
  • 100 Continue：繼續，客戶端應繼續其請求
  • 101 Switching Protocols 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到 HTTP 的新版本協議
• 2xx：表示成功，如接收或知道了
  • 200 OK: 請求成功
• 3xx：表示重定向，如要完成請求還必須採取進一步的行動
  • 301 Moved Permanently: 永久移動。請求的資源已被永久的移動到新 URL，返回信息會包括新的 URL，瀏覽器會自動定向到新 URL。今後任何新的請求都應使用新的 URL 代替
• 4xx：表示客戶的差錯，如請求中有錯誤的語法或不能完成
  • 400 Bad Request: 客戶端請求的語法錯誤，服務器無法理解
  • 401 Unauthorized: 請求要求用戶的身份認證
  • 403 Forbidden: 服務器理解請求客戶端的請求，但是拒絕執行此請求（權限不夠）
  • 404 Not Found: 服務器無法根據客戶端的請求找到資源（網頁）。通過此代碼，網站設計人員可設置 “您所請求的資源無法找到” 的個性頁面
  • 408 Request Timeout: 服務器等待客戶端發送的請求時間過長，超時
• 5xx：表示服務器的差錯，如服務器失效無法完成請求
  • 500 Internal Server Error: 服務器內部錯誤，無法完成請求
  • 503 Service Unavailable: 由於超載或系統維護，服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的 Retry-After 頭信息中
  • 504 Gateway Timeout: 充當網關或代理的服務器，未及時從遠端服務器獲取請求

更多狀態碼：菜鳥教程 . HTTP狀態碼

HTTPS與HTTP協議的區別

• https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
• http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
• http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
• http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

SSL、TSL的加密方式是什麼？爲什麼https理論上時間更長，現在怎麼優化的？

• 服務器端檢查會話標識是否在自己的緩存中

4. 描述在瀏覽器的地址欄鍵入www.baidu.com後發生了哪些事情?

• DHCP
  • 獲取IP地址，網關地址，DNS服務器地址
• DNS解析
  • 從URL中抽取主機名，並將主機名傳給DNS應用的客戶端
  • DNS查詢報文被封裝到目的地址爲DNS服務器的IP數據報中，通過ARP協議獲取網關路由器的MAC地址
  • DNS客戶向DNS服務器發送包含主機名的請求
  • 經過一系列的遞歸查詢或迭代查詢，DNS客戶最終會收到一份回答報文，其中含有主機名對應的IP地址（有CDN和沒有CDN的情況不同，要分別說明，後面CDN部分會針對此做詳細說明）
• 建立連接
  • TCP三次握手
  • 用戶可以找到和打開socket文件
• 發起請求
  • 瀏覽器運用socket文件向服務器發起各種請求
  • 發送HTTP GET報文
• 應答請求
  • 運用HTTP協議把請求傳輸到服務器
  • 任務處理
  • 運用HTTP協把處理結果或請求的資源傳輸到瀏覽器（響應報文）
• 關閉連接

2.3.2 SMTP

• SMTP（Simple Mail Transfer Protocol，簡單郵件傳輸協議）是一組用於由源地址到目的地址傳送郵件的規則，由它來控制信件的中轉方式。SMTP 協議屬於 TCP/IP 協議簇，它幫助每臺計算機在發送或中轉信件時找到下一個目的地。是一個相對簡單的基於文本的協議。在其之上指定了一條消息的一個或多個接收者（在大多數情況下被確認是存在的），然後消息文本會被傳輸。可以很簡單地通過 Telnet 程序來測試一個 SMTP 服務器。SMTP 使用 TCP 端口 25。

電子郵件系統有 3 個主要組成部分： 用戶代理、郵件服務器、簡單郵件傳輸協議(SMTP)

• 每個用戶在郵件服務器上有一個郵箱，保存該用戶發送和接收的郵件
• 如果郵件未發送成功，會保存在郵件服務器上，通常 30 分鐘左右再進行嘗試，幾天後仍不成功則刪除，並以郵件形式通知發送方
• SMTP 傳輸郵件之前，需要將報文主體編碼爲 ASCII 碼，傳輸後需要解碼（HTTP 傳輸不需要）
• SMTP 一般不使用中間郵件服務器發送郵件，即使兩個郵件服務器位於地球的兩端
• SMTP 會把郵件中所有對象封裝在一個報文中，而 HTTP 則是每個報文封裝一個 web 對象

1）多用途因特網郵件擴展(MIME)

普通的郵件報文主體爲 ASCII 編碼的數據，報文首部適合於發送普通的 ASCII 文本，但是不能充分滿足多媒體
報文或攜帶非 ASCII 文本格式(非英文字符)的報文需求。需要額外的首部行提供對發送這些文件的支持
MIME 中包含 2 個支持發送上述文件的首部：

• Content-Transfer-Encoding：指出所用編碼類型，接收方可以根據這個字段還原
• Content-Type：文件類型，接收方可以根據這個首部採取一些適當動作（如解壓）

2）接收方郵件拉取>
SMTP 是一個”推協議“，不能用於接收方代理從郵件服務器上拉取郵件，拉取郵件需要使用 POP3(第三版的郵
局協議)、 IMAP(因特網郵件訪問協議)或 HTTP

POP3(第三版的郵局協議)：當用戶打開一個到郵件服務器端口 110 上的 TCP 連接後， POP3 就開始工作了，
包含 3 個階段
• 特許：用戶發送用戶名和口令鑑別身份
• 事務處理：用戶代理取回報文（還能標記報文、獲取郵件統計信息）
• 更新：客戶機發出了 quit 命令後，結束了 POP3 會話，郵件服務器會刪除被標記爲刪除的報文

使用 POP3 拉取時，可以設置爲”拉取並刪除“或”拉取並保留“

IMAP(因特網郵件訪問協議)： POP3 不能提供遠程文件夾功能， IMAP 可以， IMAP 服務器把每個報文與一個
文件夾聯繫起來， IMAP 爲用戶提供了創建文件夾以及在文件夾之間移動郵件的命令。除此之外，還提供在遠
程文件夾中查詢郵件、按指定條件查詢匹配文件的命令。與 POP3 不同， IMAP 服務器維護了 IMAP 會話的用
戶狀態信息

基於 web 的電子郵件：當使用 web 瀏覽器發送接收郵件時，推送到郵件服務器和從郵件服務器拉取郵件使用的是 HTTP 協議。

【注】SMTP和HTTP協議的區別

• SMTP是個推協議，HTTP是個拉協議，所以用戶從自己的郵件服務器上收取報文時，需要使用POP3（110）、IMAP（）以及HTTP協議

  • POP3協議沒有給用戶提供任何創建遠程文件夾併爲報文指派文件夾的方法，不維護用戶狀態信息
  • IMAP解決以上問題

• SMTP要求每個報文用7比特ASCII碼格式

• SMTP把所有報文對象放在一個報文中

2.3.3 DNS

• DNS（Domain Name System，域名系統）是互聯網的一項服務。它作爲將域名和 IP 地址相互映射的一個分佈式數據庫，能夠使人更方便地訪問互聯網。DNS 使用 TCP 和 UDP 端口 53。當前，對於每一級域名長度的限制是 63 個字符，域名總長度則不能超過 253 個字符。

域名：

• 域名 ::= {<三級域名>.<二級域名>.<頂級域名>}，如：`blog.huihut.com

DNS運行於UDP之上，使用53號端口，它提供下列服務：

1. 主機名到IP地址的轉換(主要)。
2. 主機別名 ：有着複雜主機名的主機可以擁有一個或多個別名，應用程序可以調用DNS來獲得主機別名對應的規範主機名以及主機的IP地址
3. 郵件服務器別名：qq.com與foxmail.com，DNS可以解析郵件服務器別名獲得規範名和IP地址
4. 負載分配：繁忙的站點被冗餘分佈在多臺服務器上，這些服務器有不同IP地址，IP地址集合對應於一個規範主機名，當客戶機通過主機名獲取IP地址時，DNS服務器用包含全部這些地址的報文進行回答，但在每個回答中選擇這些地址排放的順序，從而將負載分配到不同服務器

1）DNS服務器

集中設計(單一DNS服務器)具有下列問題：

• 單點故障

• 通信容量：單個DNS服務器承受所有查詢負載

• 遠距離的集中式數據庫：單個DNS服務器不可能”鄰近“所有查詢客戶機

所以DNS服務器使用分佈式設計方案：

• 根DNS服務器：因特網上有13個根DNS服務器(標號A到M)，大部分位於北美洲

• 頂級域(TLD)DNS服務器

• 權威DNS服務器

除此之外，DNS服務器還有本地DNS服務器。嚴格來說，本地DNS服務器不屬於DNS服務器的層次結構，但對DNS層次結構很重要。一臺主機具有一臺或多臺本地DNS服務器的IP地址，本地DNS服務器起着代理的作用，將請求轉發到DNS服務器層次結構中。

2）DNS查詢步驟

DNS緩存：在查詢鏈中，當一個DNS服務器接收到一個DNS回答時，DNS服務器能將回答中的信息緩存在本地存儲，以便加速後序可能的相同查詢。由於主機IP和主機名之間的映射不是永久的，DNS服務器會在一段時間後丟棄緩存（本地DNS服務器可以緩存TLD服務器的IP地址，因而允許直接繞過查詢鏈中的根DNS服務器）。

3）DNS記錄和報文

所有DNS服務器共同存儲着資源記錄，資源記錄格式如下：

(Name,Value,Type,TTL)

• Type=A：此時Name是主機名，Value是對應IP地址

• Type=NS：Name是域(如foo.com)，Value是知道如何獲取該域中主機IP地址的權威DNS服務器的主機名

• Type=CNAME：Value是別名爲Name的主機對應的規範主機名

• Type=MX：Value是別名爲Name的郵件服務器的規範主機名

如果一臺DNS服務器是某個特定主機名的權威DNS服務器，那麼會有一條包含該主機名的類型A記錄（不是權威服務器，也可能在緩存中包含A記錄）

如果DNS服務器不是某個主機名的權威DNS服務器，那麼會包含一條類型NS記錄，還將包含一條類型A記錄，提供了在NS記錄的Value字段中DNS服務器的IP地址

DNS報文(查詢和響應報文格式相同)

nslookup：從主機直接向某些DNS服務器發送DNS查詢報文

註冊域名

因特網名字和地址分配機構(ICANN)向各種註冊登記機構授權，可以向這些機構申請註冊域名：

1. 提供基本權威DNS服務器和輔助權威服務器的域名和IP
2. 註冊登記機構會將NS和A類型的記錄輸入TLD服務器
3. 確保自身在提供的權威DNS服務器中輸入了相應類型的記錄

4) DDos帶寬洪泛攻擊

如，攻擊者向每個DNS根服務器連續不斷地發送大量的分組，從而使得大多數合法的DNS請求得不到回答

DNS根服務器配置分組過濾器可以攔截這些分組，本地DNS服務器緩存了頂級域名服務器的IP地址，也能繞過DNS根服務器，防止攻擊

【QA】

1.爲什麼要DNS解析，DNS是什麼？

• 人類喜歡便於記憶的主機名標識方式，路由器定長的有層次地IP地址。
• DNS是一個由分層的DNS服務器實現的分佈式數據庫，一個使得主機能夠查詢分佈式數據庫的應用層協議。

2.DNS的解析過程，涉及到的文件以及其記錄類型

• 遞歸查詢：本地、根、二級…本地
• 迭代查詢：本地、根服務器、本地、二級、本地…本地
• 通常來說請求主機到本地DNS服務器的查詢是遞歸的，其餘的查詢是迭代的
• 記錄類型
  • CNAME：主機別名比規範主機名更容易記憶，一個IP給許多主機用，只修改CNAME對應的A記錄即可，CDN，主機別名，規範主機名，CNAME
  • A：主機名，IP，A（權威服務器有）
  • MX：郵件服務器別名，規範主機名，MX
  • NS：域，能獲取該域的主機IP地址的權威DNS服務器的主機名，NS（非權威服務器）

3.如果DNS解析出現錯誤，解決的思路是什麼？

• 本地緩存被污染
• 本地DNS服務器被污染
• 中間人攻擊
• 牆

4.Anycast 的使用場景

• 大型DNS系統中廣泛使用的多點部署、分佈式方案，對於提高可用性、提高性能、抵抗DDOS有重要作用。

=5.CDN（內容分發網絡） 技術

• CDN中涉及到的關鍵技術：
  • 緩存算法[Squid]：緩存算法決定命中率、源服務器壓力、POP節點存儲能力
  • 分發能力：分發能力取決於IDC能力和IDC策略性分佈
  • 負載均衡[Nginx]：負載均衡（智能調度）決定最佳路由、響應時間、可用性、服務質量
  • 基於DNS[BIND]：基於DNS的負載均衡以CNAME實現[to
    cluster]，智取最優節點服務
    • 爲什麼要有CNAME而不是直接返回一個CDN邊緣節點的ip？
      • 由於CDN對域名解析過程進行了調整，所以解析函數庫得到的是該域名對應的CNAME記錄（CNAME爲CDN服務商域名），爲了得到實際IP地址，瀏覽器需要再次對獲得的CNAME域名進行解析以得到實際的IP地址；
      • 在此過程中，使用的全局負載均衡DNS解析，如根據地理位置信息解析對應的IP地址，使得用戶能就近訪問。
  • 支持協議：靜動態加速（圖片加速、https帶證書加速）、下載加速、流媒體加速、企業應用加速、手機應用加速
• CDN系統的通用組成架構
  • 分發服務系統：最基本的工作單元就是Cache設備，cache（邊緣cache）負責直接響應最終用戶的訪問請求，把緩存在本地的內容快速地提供給用戶。同時cache還負責與源站點進行內容同步，把更新的內容以及本地沒有的內容從源站點獲取並保存在本地。Cache設備的數量、規模、總服務能力是衡
    量一個CDN系統服務能力的最基本的指標
  • 負載均衡系統：主要功能是負責對所有發起服務請求的用戶進行訪問調度，確定提供給用戶的最終實際訪問地址。兩級調度體系分爲全局負載均衡（GSLB）和本地負載均衡（SLB）。GSLB主要根據用戶就近性原則，通過對每個服務節點進行"最優"判斷，確定向用戶提供服務的cache的物理位置。SLB主要負責節點內部的設備負載均衡
  • 運營管理系統：分爲運營管理和網絡管理子系統，負責處理業務層面的與外界系統交互所必須的收集、整理、交付工作，包含客戶管理、產品管理、計費管理、統計分析等功能。
• 在解析過程中，企業的CDN是怎麼起作用的（在解析過程中，如何把請求打到CDN節點上）？
• 使用了CDN緩存後，針對網站的訪問過程變爲：
  • 本地DNS服務器在進行查詢的時候，將該DNS請求中繼到該域名的權威服務器。權威服務器通過分析二級域名，如video.baidu.com，不直接返回IP地址，而是返回一個對應的CNAME記錄，該記錄指向公司CDN的DNS權威服務器。
  • 用戶的本地服務器對獲得的CNAME域名進行解析，向CDN的DNS權威服務器發起請求。
  • 權威服務器通過在IP庫中查詢請求IP的地理位置（淘寶使用包裹記錄來校準），同時考慮網絡成本，流量分佈，源站負載等，返回一個最優節點緩存服務器的IP。
  • 緩存服務器根據瀏覽器提供的要訪問的域名，通過Cache內部專用DNS解析得到此域名的實際IP地址，再由緩存服務器向此實際IP地址提交訪問請求。
  • 緩存服務器從實際IP地址得得到內容以後，一方面在本地進行保存，以備以後使用，二方面把獲取的數據返回給客戶端，完成數據服務過程。

2.3.4 DHCP

DHCP（Dynamic Host Configuration Protocol，動態主機設置協議）是一個局域網的網絡協議，使用 UDP 協議工作，主要有兩個用途：

• 用於內部網絡或網絡服務供應商自動分配 IP 地址給用戶
• 用於內部網絡管理員作爲對所有電腦作中央管理的手段

獲取IP地址，掩碼，路由器IP地址，DNS服務器的IP地址

• 實現原理
  • 發現：新到主機通過DHCP發現報文，在UDP分組中向端口67發送，使用廣播目的地址255.255.255.255，源地址0.0.0.0
  • 提供：DHCP服務器通過廣播地址能提供的IP信息（地址、掩碼、租用期）
  • 請求：新到主機從提供報文中選中一個服務器，並響應一個DHCP請求報文，回顯配置參數
  • ACK：服務器用DHCP ACK報文證實所要求的參數

2.3.5 FTP

• FTP（File Transfer Protocol，文件傳輸協議）是用於在網絡上進行文件傳輸的一套標準協議，使用客戶/服務器模式，使用 TCP 數據報，提供交互式訪問，雙向傳輸。
• TFTP（Trivial File Transfer Protocol，簡單文件傳輸協議）一個小且易實現的文件傳輸協議，也使用客戶-服務器方式，使用UDP數據報，只支持文件傳輸而不支持交互，沒有列目錄，不能對用戶進行身份鑑定。

FTP 使用兩個並行的 TCP 連接來傳輸文件：

1. 控制連接(持久)：傳輸控制信息，如用戶標識、口令、改變遠程目錄命令、文件獲取上傳的命令
2. 數據連接(非持久)：傳輸實際文件

FTP 客戶機發起向 FTP 服務器的控制連接，然後在該連接上發送用戶標識和口令、改變遠程目錄命令。 FTP服務器收到命令後，發起一個到客戶機的數據連接，在該連接上準確地傳送一個文件並關閉連接。

有狀態的協議： FTP 服務器在整個會話期間保留用戶的狀態信息。服務器必須把特定的用戶賬號和控制連接聯繫起來

• 控制連接：長連接
  • 以7比特ASCII格式傳輸
• 數據連接：短連接
• 用戶身份
  • 實體用戶
  • 訪客
  • 匿名用戶
• 主動連接
  • 防火牆（NAT）問題：使用iptables的ftp模塊
  • 客戶端先發起，告知自己的端口號，連接到服務器21端口，服務器20端口主動連接客戶端
• 被動連接
  • 客戶端發送被動連接標識，服務器21端口號告訴客戶端自己使用的數據端口，客戶端隨即選用大於1024的端口主動連接服務器，
• 安全性
  • vsftpd
  • 明文傳輸不安全
  • chroot，限定用戶的訪問目錄

2.3.6 SMB

• rpc
• showmount
• 防火牆設置：/etc/sysconfig/nfs：設置端口
• 權限：網段
• NFS
  • ftp無法直接修改主機上的文件數據，需要客戶端
  • 共享打印機
  • 架構在NetBIOS協議上，適合局域網的共享
  • 每臺主機有NetBIOS Name
  • 權限
    • nmbd：管理工作組名稱的解析，使用UDP實現137 138端口
    • smbd：管理主機共享的目錄文件與打印機，利用TCP的139 445
    • /etc/samba/smb.conf
    • 賬號密碼放在TDB數據庫中user
      • 在Linux下，必須是Linux的用戶，密碼可以不同
    • 也可以使用外部服務器的密碼domain
      • NIS或LDAP來進行賬號對應
      • PDC服務器
        • 讓PDC成爲整個局域網的域管理員，win主機加入域中，win登陸時會從服務器驗證賬號密碼
    • selinux、iptables、hosts allow|deny、
  • 掛載
    • monut -t cifs

2.3.7 P2P應用

不同於C/S架構，P2P架構中，每個主機既是客戶機也是服務器，稱作對等方，由於文件分佈存儲在多個對等方中，因此文件分發速度更快

• u：上傳速率
• d：下載速率
• F：文件（比特）大小
假設服務器需要將文件發送到N個對等方：

1）如果使用C/S架構
• 服務器總共需要上傳NF比特數據，那麼至少需要NF/us的時間
• 設dmin爲下載速率最小的對等方，那麼該對等方不可能在F/dmin內獲得文件
那麼有：Dcs ≥ max{NF/us,F/dmin}，服務器調度傳輸可使下屆作爲實際分發時間，即：Dcs = max{NF/us,F/dmin}。當N足夠大時，分發時間取決於NF/us，隨對等方數量線性增加

2） 如果使用P2P架構：
• 剛開始只有服務器擁有文件，爲了將文件的所有比特傳至網絡，需要F/us
• 設dmin爲下載速率最小的對等方，那麼該對等方不可能在F/dmin內獲得文件
• 設utotal = us + u1 + … + un表示系統總上傳速率。由於最終每個對等方會有一個文件，那麼總共需要上傳NF

比特，那麼所有數據的上傳時間不可能小於NF/utotal
因此又：Dp2p ≥ max{F/us,F/dmin,NF/utotal}，如果每個對等方接收到一個比特就重新分發一個比特，可使下屆作爲實際分發時間，即：Dp2p = max{F/us,F/dmin,NF/utotal}。實際上，重新分發的是文件塊而不是一個個比特
下圖展示了在兩種架構下分發時間與對等方數量的關係，可以看出使用P2P進行文件分發速度快，具有自我擴展性：

P2P中文件的搜索方式
• 集中式索引：使用一個集中式索引服務器存儲索引，是一種P2P和C/S混合的體系結構，文件分發是P2P的，搜索是C/S的

• 查詢洪泛：建立在Gnutella協議基礎上，索引全面分佈在對等方區域中，對等方向相鄰對等方發出文件查詢請求，相鄰對等方進一步轉發查詢請求

• 層次覆蓋：結合以上兩種，與因特網高速連接並具有高可用性的對等方被指派爲超級對等方，新的對等方與超級對等方之一建立TCP連接，將其可供共享的所有文件告訴超級對等方，超級對等方維護着一個索引，超級對等方之間通過TCP連接，可以轉發查詢。

2.3.8 TELNET

• TELNET 協議是 TCP/IP 協議族中的一員，是 Internet 遠程登陸服務的標準協議和主要方式。它爲用戶提供了在本地計算機上完成遠程主機工作的能力。

2.3.9 WWW

• WWW（World Wide Web，環球信息網，萬維網）是一個由許多互相鏈接的超文本組成的系統，通過互聯網訪問。

2.3.10 SNMP

• SNMP（Simple Network Management Protocol，簡單網絡管理協議）構成了互聯網工程工作小組（IETF，Internet Engineering Task Force）定義的 Internet 協議族的一部分。該協議能夠支持網絡管理系統，用以監測連接到網絡上的設備是否有任何引起管理上關注的情況。

2.3.11 URL

• URL（Uniform Resource Locator，統一資源定位符）是因特網上標準的資源的地址（Address）

標準格式：

• 協議類型:[//服務器地址[:端口號]][/資源層級UNIX文件路徑]文件名[?查詢][#片段ID]

完整格式：

• 協議類型:[//[訪問資源需要的憑證信息@]服務器地址[:端口號]][/資源層級UNIX文件路徑]文件名[?查詢][#片段ID]

其中【訪問憑證信息@；:端口號；?查詢；#片段ID】都屬於選填項

3.傳輸層

3.1端口號與套接字

3.3.1 端口號

通常在一臺主機上能夠運行許多網絡應用程序。IP地址可以標識一臺主機，端口號則是用來標識這臺主機上的特定進程。

端口號是一個16bit的數字，大小在0 ~ 65535之間，0 ~ 1023範圍的端口號稱爲周知端口號，保留給周知的應用層協議。

應用層協議	端口號	傳輸層協議
DNS	53	UDP
FTP	21(控制連接)，20(數據連接)	TCP
TFTP	69	UDP
TELNET	23	TCP
DHCP	67(服務器)，68(客戶端)	UDP
HTTP	80	TCP
HTTPS	443	TCP
SMTP	25	TCP
POP3	110	TCP
IMAP	143	TCP

3.3.2 套接字

網絡應用由成對進程組成，進程通過一個稱爲套接字的軟件接口在網絡上發生和接收報文

套接字是同一臺主機內應用層與運輸層之間的接口，也可稱爲應用程序和網絡之間的應用程序編程接口
TCP套接字：(源IP,源端口,目的IP,目的端口)
UDP套接字：(目的IP,目的端口)

3.2多路複用與多路分解

• 多路分解：將運輸層報文段中的數據交付到正確的套接字的過程（通過報文段的端口號字段）
• 多路複用：從源主機不同套接字收集數據，併爲數據封裝上首部信息從而生成報文段，傳遞到網絡的過程

3.3可靠數據傳輸原理

• rdt：可靠數據傳輸

• udt：不可靠數據傳輸

3.3.1完全可靠信道上的可靠數據傳輸(rdt1.0)

假設底層信道是完全可靠的

3.3.2具有比特差錯信道上的可靠數據傳輸(rdt2.0、rdt2.1、rdt2.2)

更現實的底層信道模型是分組中的比特可能受損

引入了自動重傳請求(ARQ)協議，ARQ還需要另外3種協議來處理存在的比特差錯：

1. 差錯檢測

2. 接收方反饋：肯定確認(ACK)和否定確認(NAK)

3. 重傳：接收方收到有差錯的分組時，發送方重傳

對於發送方，在等待ACK或NAK狀態時，不能發送更多分組。類似於rdt2.0這種行爲的協議被稱爲停等協議rdt2.0的問題在於沒有考慮到ACK和NAK分組可能受損的情況

處理受損ACK或NAK的辦法是，如果收到受損的ACK或NAK，則重傳一次分組，但是這樣又無法確認是一次新的分組還是重傳的分組。解決辦法是在分組中添加一個序號字段，接收方只需檢查序號即可確定收到的分組是否是一次重傳。對於rdt2.0，只需1比特序號即可，從而得到rdt2.1

如果收到受損的分組，接收方也可以發送一個對上次正確接收分組的ACK，也能實現與NAK一樣的效果，也就是rdt2.2

3.3.3 具有比特差錯的丟包信道上的可靠數據傳輸(rdt3.0)

現在假定除了比特受損外，底層信道還會丟包，因此需要引入時間機制決定何時重傳分組

3.3.4 流水線可靠數據傳輸

rdt3.0功能正確，但由於是一個停等協議，所以性能很差。如果能在收到確認之前發送多個分組，可以大大提升性能

1）回退N步(GBN)

也被稱爲滑動窗口協議

• 發送方

超時重傳所有已發送但未確認的分組

• 接收方

每接收到一個有序分組交付到上層，丟棄無序分組

累積確認收到的有序分組

丟棄無序分組的優點在於接收方緩存簡單，需要維護的唯一信息就是下一個按序接收的分組的序號；缺點是對於丟棄的分組，隨後重傳也許會丟失或出錯，因此甚至需要更多的重傳

2）選擇重傳(SR)

一個單個分組的差錯就可能引起GBN重傳大量分組，許多分組根本沒有必要重傳。隨着信道差錯率的增加，流水線可能被這些沒有必要重傳的分組填滿

• 發送方

如果收到的ACK對應一個窗口內的分組，則標記爲已接收，序號等於send_base則移動窗口至具有最小序號的未確認分組處

如果窗口移動了，並且有序號落在窗口內的未發送分組，則發送這些分組

如果發生超時，只能發送1個分組

• 接收方

確認(ACK)一個正確接收到的分組（收到滑動窗口前的分組也要再次確認，因爲這種情況通常意味着這個分組的前一次確認未被髮送方收到）;

失序分組會被緩存直到所有丟失分組都被收到，此時將一批分組按序交付給上層.

一個SR運行的例子：

對於SR而言，接收方窗口長度必須小於等於序號空間大小的一半，否則可能無法確認一個分組是重傳還是初次傳送

3.4 TCP

TCP是面向連接的，提供全雙工的服務：數據流可以雙向傳輸。也是點對點的，即在單個發送方與單個接收方之間的連接。

特徵：

• 面向連接
• 只能點對點（一對一）通信
• 可靠交互
• 全雙工通信
• 面向字節流

TCP 如何保證可靠傳輸：

• 確認和超時重傳
• 數據合理分片和排序
• 流量控制
• 擁塞控制
• 數據校驗

3.4.1 TCP報文段結構

TCP 報文結構

TCP頭部

字段定義

• 源端口號（16位）

• 目的端口號（16位）

• 序號（32位）TCP的序號是數據流中的字節數，不是分組的序號。表示該報文段數據字段首字節的序號

• 確認號（32位）TCP使用累積確認，確認號是第一個未收到的字節序號，表示希望接收到的下一個字節

• 首部長度（4位）通常選項字段爲空，所以一般TCP首部的長度是20字節

• 保留（6位）

• 標誌字段（6位）

  • ACK：指示確認字段中的值是有效的
  • RST,SYN,FIN：連接建立與拆除
  • PSH：指示接收方應立即將數據交給上層
  • URG：報文段中存在着(被髮送方的上層實體置位)“緊急”的數據

• 窗口（16位）

• 校驗和（16位）

• 緊急指針（16位）

• 選項

TCP：狀態控制碼（Code，Control Flag），佔 6 比特，含義如下：

• URG：緊急比特（urgent），當 URG＝1 時，表明緊急指針字段有效，代表該封包爲緊急封包。它告訴系統此報文段中有緊急數據，應儘快傳送(相當於高優先級的數據)， 且上圖中的 Urgent Pointer 字段也會被啓用。
• ACK：確認比特（Acknowledge）。只有當 ACK＝1 時確認號字段纔有效，代表這個封包爲確認封包。當 ACK＝0 時，確認號無效。
• PSH：（Push function）若爲 1 時，代表要求對方立即傳送緩衝區內的其他對應封包，而無需等緩衝滿了才送。
• RST：復位比特(Reset)，當 RST＝1 時，表明 TCP 連接中出現嚴重差錯（如由於主機崩潰或其他原因），必須釋放連接，然後再重新建立運輸連接。
• SYN：同步比特(Synchronous)，SYN 置爲 1，就表示這是一個連接請求或連接接受報文，通常帶有 SYN 標誌的封包表示『主動』要連接到對方的意思。
• FIN：終止比特(Final)，用來釋放一個連接。當 FIN＝1 時，表明此報文段的發送端的數據已發送完畢，並要求釋放運輸連接。

3.4.2 TCP流量控制

概念

流量控制（flow control）就是讓發送方的發送速率不要太快，要讓接收方來得及接收。

方法

利用可變窗口進行流量控制

如果應用程序讀取數據相當慢，而發送方發送數據太多、太快，會很容易使接收方的接收緩存溢出，流量控制就是用來進行發送速度和接收速度的匹配。發送方維護一個“接收窗口”變量，這個變量表示接收方當前可用的緩存空間

• LastByteRead:接收方應用程序從接收緩存中讀取的最後一個字節

• LastByteRcvd:接收方接收到的最後一個字節

要防止緩存溢出，則應該滿足如下條件：

LastByteRecv - LastByteRead <= RcvBuffer

接收方可通過下列公式計算RcvWindow:

RcvWindow = RcvBuffer - [LastByteRecv - LastByteRead]

然後將RcvWindow的值記錄在TCP報文段中，發送給發送方。發送方輪流跟蹤兩個變量LastByteSent和LastByteAcked，這兩個變量之差就是發送到連接中但未被確認的數據量。通過將其控制在RcvWindow內，就能實現流量控制:

LastByteSent - LastByteAcked <= RcvWindow

這個方案存在一個問題，當接收方緩存已滿時，將RcvWindow=0通告給發送方，並且接收方沒有任何數據要發送給發送方，隨着接收方應用進程清空緩存，TCP並不向發送方發送帶有RcvWindow新值的新報文段；TCP僅在它有數據或確認要發送時纔會發送報文段。這樣，發送方不會知道接收方緩存已經有新的空間，發送方因此被阻塞而不能再發送數據。爲解決這個問題，TCP規約中要求：當接收方的接收窗口爲0時，發送方繼續發送只有1個字節數據的報文段。這些報文段將會被接收方確認。最終緩存將開始清空，並且確認報文裏將包含一個非0的RcvWindow值。

3.4.3 TCP連接管理

因爲 TCP 三次握手建立連接、四次揮手釋放連接很重要。

TCP 三次握手建立連接

【TCP 建立連接全過程解釋】

1. 客戶端發送 SYN 給服務器，說明客戶端請求建立連接；
2. 服務端收到客戶端發的 SYN，並回復 SYN+ACK 給客戶端（同意建立連接）；
3. 客戶端收到服務端的 SYN+ACK 後，回覆 ACK 給服務端（表示客戶端收到了服務端發的同意報文）；
4. 服務端收到客戶端的 ACK，連接已建立，可以數據傳輸。

TCP 爲什麼要進行三次握手？

【答案一】因爲信道不可靠，而 TCP 想在不可靠信道上建立可靠地傳輸，那麼三次通信是理論上的最小值。（而 UDP 則不需建立可靠傳輸，因此 UDP 不需要三次握手。）

Google Groups . TCP 建立連接爲什麼是三次握手？{技術}{網絡通信}

【答案二】因爲雙方都需要確認對方收到了自己發送的序列號，確認過程最少要進行三次通信。

知乎 . TCP 爲什麼是三次握手，而不是兩次或四次？

TCP 四次揮手釋放連接

【TCP 釋放連接全過程解釋】

1. 客戶端發送 FIN 給服務器，說明客戶端不必發送數據給服務器了（請求釋放從客戶端到服務器的連接）；
2. 服務器接收到客戶端發的 FIN，並回復 ACK 給客戶端（同意釋放從客戶端到服務器的連接）；
3. 客戶端收到服務端回覆的 ACK，此時從客戶端到服務器的連接已釋放（但服務端到客戶端的連接還未釋放，並且客戶端還可以接收數據）；
4. 服務端繼續發送之前沒發完的數據給客戶端；
5. 服務端發送 FIN+ACK 給客戶端，說明服務端發送完了數據（請求釋放從服務端到客戶端的連接，就算沒收到客戶端的回覆，過段時間也會自動釋放）；
6. 客戶端收到服務端的 FIN+ACK，並回復 ACK 給客戶端（同意釋放從服務端到客戶端的連接）；
7. 服務端收到客戶端的 ACK 後，釋放從服務端到客戶端的連接。

TCP 爲什麼要進行四次揮手？

【問題一】TCP 爲什麼要進行四次揮手？ / 爲什麼 TCP 建立連接需要三次，而釋放連接則需要四次？

【答案一】因爲 TCP 是全雙工模式，客戶端請求關閉連接後，客戶端向服務端的連接關閉（一二次揮手），服務端繼續傳輸之前沒傳完的數據給客戶端（數據傳輸），服務端向客戶端的連接關閉（三四次揮手）。所以 TCP 釋放連接時服務器的 ACK 和 FIN 是分開發送的（中間隔着數據傳輸），而 TCP 建立連接時服務器的 ACK 和 SYN 是一起發送的（第二次握手），所以 TCP 建立連接需要三次，而釋放連接則需要四次。

【問題二】爲什麼 TCP 連接時可以 ACK 和 SYN 一起發送，而釋放時則 ACK 和 FIN 分開發送呢？（ACK 和 FIN 分開是指第二次和第三次揮手）

【答案二】因爲客戶端請求釋放時，服務器可能還有數據需要傳輸給客戶端，因此服務端要先響應客戶端 FIN 請求（服務端發送 ACK），然後數據傳輸，傳輸完成後，服務端再提出 FIN 請求（服務端發送 FIN）；而連接時則沒有中間的數據傳輸，因此連接時可以 ACK 和 SYN 一起發送。

【問題三】爲什麼客戶端釋放最後需要 TIME-WAIT 等待 2MSL 呢？

【答案三】

1. 爲了保證客戶端發送的最後一個 ACK 報文能夠到達服務端。若未成功到達，則服務端超時重傳 FIN+ACK 報文段，客戶端再重傳 ACK，並重新計時。
2. 防止已失效的連接請求報文段出現在本連接中。TIME-WAIT 持續 2MSL 可使本連接持續的時間內所產生的所有報文段都從網絡中消失，這樣可使下次連接中不會出現舊的連接報文段。

3次握手

1.客戶端向服務器發送SYN報文段（不包含應用層數據，首部的一個標誌位(即SYN比特)被置位，客戶端隨機化選擇(避免攻擊)一個起始序號x）

2.服務器爲該TCP連接分配TCP緩存和變量，返回一個SYNACK報文段（也不包含應用層數據，SYN比特被置爲1，ACK爲x+1，服務器選擇自己的初始序列y）

3.客戶機爲該連接分配緩存和變量，返回一個對SYNACK報文段進行確認的報文段（因爲連接已經建立了，所以SYN比特被置爲0）

如果客戶端不發送ACK來完成第三次握手，最終(通常是一分鐘後)服務器將終止該半開連接並回收已分配的資源（在第三次握手前分配緩存和變量，可能會受到SYN洪泛攻擊）

如果第二次握手丟包怎麼辦？第三次呢？——知乎車小胖的回答

• 第二個包，即B發給A的SYN +ACK 中途被丟，沒有到達A：B會週期性超時重傳，直到收到A的確認

• 第三個包，即A發給B的ACK 中途被丟，沒有到達B：A發完ACK，單方面認爲TCP爲 Established狀態，而B顯然認爲TCP爲Active狀態

• 假定此時雙方都沒有數據發送：B會週期性超時重傳，直到收到A的確認，收到之後B的TCP 連接也爲Established狀態，雙向可以發包

• 假定此時A有數據發送：B收到A的 Data + ACK，自然會切換爲established 狀態，並接受A的Data

• 假定B有數據發送：數據發送不了，會一直週期性超時重傳SYN + ACK，直到收到A的確認纔可以發送數據

SYN洪泛攻擊：攻擊者發送大量的TCP SYN報文段，而不完成三次握手的第三步。通過從多個源發送SYN能夠加大攻擊力度，產生DDos(分佈式拒絕服務) SYN洪泛攻擊 預防：SYN cookies。

• 當服務器接收到一個SYN報文段時，它並不知道該報文段是來自一個合法的用戶，還是一個SYN洪泛攻擊的一部分。因此服務器不會爲該報文段生成一個半開TCP連接。相反，服務器生成一個初始TCP序列號y，該序列號是SYN報文段的源和目的IP地址、端口號以及僅被該服務器所知的祕密數的一個散列函數，這種精心製作的初始序列號被稱作“cookie”。服務器發送具有這種特殊序列號的SYNACK分組，服務器並不記憶該cookie或任何對應於SYN的其他狀態信息

SYN cookies預防SYN洪泛攻擊：

• 當服務器接收到一個SYN報文段時，它並不知道該報文段是來自一個合法的用戶，還是一個SYN洪泛攻擊的一部分。因此服務器不會爲該報文段生成一個半開TCP連接。相反，服務器生成一個初始TCP序列號y，該序列號是SYN報文段的源和目的IP地址、端口號以及僅被該服務器所知的祕密數的一個散列函數，這種精心製作的初始序列號被稱作“cookie”。服務器發送具有這種特殊序列號的SYNACK分組，服務器並不記憶該cookie或任何對應於SYN的其他狀態信息

• 如果客戶機是合法的，它將返回一個ACK報文段。服務器一旦收到該ACK，需要驗證與前面發送的某些SYN對應的ACK。對於一個合法的ACK，確認字段中的值等於SYNACK序號字段y的值加1。服務器將使用在ACK報文段中的相同字段和祕密數運行相同的函數。如果該函數的結果加1與確認號相同，服務器就認爲該ACK對應於前面發送的SYN報文段，生成一個具有套接字的全開的連接

• 如果客戶機沒有返回一個ACK報文段，則初始化的SYN也沒有對該服務器產生危害，因爲服務器沒有爲它分配任何資源

前兩次握手不包含有效載荷，第三次“握手”可以承載有效載荷

爲什麼需要3次握手而不是4次或2次？——知乎車小胖的回答

• 流程
  • 客戶端發送syn包(syn=x)到服務器，並進入SYN_SEND狀態，等待服務器確認；
  • 服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
  • 客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=y+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
  • [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-vb4ApSJP-1590982812328)(http://img.qiuye.online/18-9-19/67777489.jpg)]
• 爲什麼需要三次握手，第二次會出現什麼問題？
  • 防止已經失效的連接請求又被報文段傳輸到主機，從而產生錯誤，使得主機持續等待發來的數據，造成資源浪費。

4次揮手

TCP連接的兩個進程中任意一個都能終止該連接，連接關閉需要4步。假設客戶端發起一個關閉請求：

1.客戶端發送一個FIN報文（首部中的FIN比特被置位）

2.服務器返回一個對FIN報文的確認報文

3.服務器發送一個FIN報文（首部中的FIN比特被置位）

4.客戶端返回一個對FIN報文的確認報文

MSL(最長分節生命期)是任何IP數據報能夠在因特網中存活的最長時間（IP數據報中的TTL首部爲8位，具有最大TTL，即255的分組，在網絡中存在的時間不能超過MSL）。任何TCP實現都必須爲MSL選擇一個值。RFC 1122的建議值是2分鐘，不過源自Berkeley的實現傳統上改用30秒。意味着TIME_WAIT狀態的持續時間再1分鐘到4分鐘之間

四次揮手是因爲TCP是全雙工的，前2次揮手用於關閉一個方向的數據通道，後兩次揮手用於關閉另外一個方向的數據通道

TIME-WAIT狀態的詳細說明，主要有2個存在的理由：

• 可靠地實現TCP全雙工連接的終止

• 等待迷途分組在網絡中消逝

nmap：可以“偵察”打開的TCP接口、UDP接口；還能“偵察”防火牆及其配置；甚至能“偵察”應用程序及操作系統版本。

• 流程

  • 主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發數據了(當然，在fin包之前發送出去的數據，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些數據)，但是，此時主動關閉方還可以接受數據。
  • 被動關閉方收到FIN包後，發送一個ACK給對方，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號）。
  • 被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，我的數據也發送完了，不會再給你發數據了。
  • 主動關閉方收到FIN後，發送一個ACK給被動關閉方，確認序號爲收到序號+1，至此，完成四次揮手。
  • [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-1yNwEXJh-1590982812328)(http://img.qiuye.online/18-9-19/89768478.jpg)]

• 爲什麼需要四次揮手，爲什麼要等2msl再關閉？

  • TCP是全雙工通信，主動斷開方發送FIN並不意味着立即關閉TCP連接，而是告訴對方自己沒有更多的數據要發送了，只有當對方發完自己的數據再發送FIN後，才意味着關閉TCP連接；

• TIME_WAIT 狀態

  • TIME_WAIT的作用
    • 主動關閉的一方在發送完最後一個ACK後就會進入TIME_WAIT狀態，並停留2MSL最大報文生存時間。
    • 爲了實現 TCP 全雙工連接的可靠性關閉，用來重發可能丟失的
      ACK報文；
  • 爲什麼需要持續2個MSL(最大報文生存時間)？
    • 假設應用程序端口在進入TIME_WAIT後，2個MSL時間內並沒有收到FIN，說明應用程序最後發出的ACK已經收到了；否則會在2個MSL內再次收到ACK.。
  • TIME_WAIT 次數多了會怎麼樣？爲什麼 ？如何緩解？
    • 在高併發短連接的TCP服務器上，當服務器處理完請求後立刻主動正常關閉連接。這個場景下會出現大量socket處於TIME_WAIT狀態。如果客戶端的併發量持續很高，此時部分客戶端就會顯示連接不上。
    • 調節系統參數reuse，reclcye，負載均衡

• 回退N幀協議/滑動窗口

  • 滑動窗口怎麼實現的（原理）
    • 使用的技術包括：校驗和、積累確認、序號、超時重傳
    • 窗口裏包含已經發送但尚未收到確認的數據，和允許發送但尚未發送的數據
    • 積累確認：表明接收方已經接收到序號及之前的所有分組，只關注最近按序接收的分組
      • 不緩存失序分組
    • 你覺得這樣實現會有什麼問題->怎麼解決
      • 性能問題：單個分組的差錯就會引起重傳大量分組
      • 引入選擇重傳機制
        • 選擇重傳確認一個只能夠正確接收的分組而不管其是否按序
        • 選擇重傳會緩存失序分組
    • TCP通常會緩存失序報文，但TCP最多會重傳一個報文段，GBN會重傳n和它後繼的所有分組
  • 窗口的大小如何確定
    • 發送窗口是根據接收窗口和擁塞窗口的最小值確定的
    • 接收窗口根據接收方的緩衝區大小決定
    • 擁塞窗口根據慢啓動擁塞避免快恢復算法決定

• 擁塞避免/慢啓動/快重傳/快速恢復

  • 慢啓動：
    • TCP發送速率起始慢，但在慢啓動階段以指數增長，每過一個往返時間，擁塞窗口的報文段數目翻番。
    • 檢測到阻塞，將慢啓動門限設置爲擁塞窗口的1/2，將擁塞窗口置1，並重新開始慢啓動。
    • 當擁塞窗口的值再次達到慢啓動門限時，TCP轉移到擁塞避免模式。
  • 擁塞避免：
    • 每個往返時間只將擁塞窗口的值加一個MSS（最大報文段長度1460）
    • 當出現超時時，將慢啓動門限設置爲擁塞窗口的1/2，並將擁塞窗口的值置1，重新開始慢啓動。
  • 快速恢復：
    • 如果發送端接收到到3個冗餘ACK，則執行快速重傳，並進入快速恢復階段。
    • 將慢啓動門限設置爲擁塞窗口的一半，並將擁塞窗口設置爲此時門限加3（即原窗口/2+3）後進入擁塞避免狀態。
    • 如果出現超時事件，快速恢復在執行如同在慢啓動和擁塞避免中相同的動作後，遷移到慢啓動狀態。

• SYN攻擊

  • SYN攻擊是什麼，怎麼處理？
    • SYN攻擊屬於DOS攻擊的一種，它利用TCP協議缺陷，攻擊者通過發送大量的SYN報文端，而不完成第三次握手步驟，耗費CPU和內存資源。
    • 配合IP欺騙，SYN攻擊能達到很好的效果，通常客戶端在短時間內僞造大量不存在的IP地址，向服務器不斷地發送syn包，服務器回覆確認包，並等待客戶的確認，由於源地址是不存在的，服務器需要不斷的重發直至超時，這些僞造的SYN包將長時間佔用未連接隊列，正常的SYN請求被丟棄，目標系統運行緩慢，嚴重者引起網絡堵塞甚至系統癱瘓。
  • SYN cookie的工作原理，cookie如何計算，在哪裏傳遞
    • 服務器收到一個SYN報文段後會先生成一個初始序列號（即cookie）
    • 該序號是SYN報文段的源IP、目的IP地址與端口號以及一個祕密數的一個散列函數
    • 服務器發送具有這種特殊初始序列號的SYNACK分組
    • 如果服務器收到ACK，用同樣的祕密數和源、目的IP與端口散列驗證
    • 如果結果加1等於該ACK中確認號，生成一個具有套接字的全開連接

3.4.4 TCP擁塞控制

概念

擁塞控制就是防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載。

方法

• 慢開始( slow-start )
• 擁塞避免( congestion avoidance )
• 快重傳( fast retransmit )
• 快恢復( fast recovery )

TCP的擁塞控制圖

擁塞控制分類：

• 端到端擁塞控制：網絡層沒有爲運輸層擁塞控制提供顯示支持（TCP的擁塞控制）

• 網絡輔助的擁塞控制：網絡層組件向發送方提供關於網絡中擁塞狀態的顯式反饋信息（ATM ABR）

• 直接反饋：路由器通過阻塞分組直接通知發送方擁塞

• 路由器標記或更新從發送方流向接收方的分組中的某個字段來指示擁塞，接收方收到後通知發送方

由於IP層不向端系統提供顯示的網絡擁塞反饋，所以TCP必須使用端到端擁塞控制，而不是網絡輔助擁塞控制

TCP連接的兩方都記錄一個額外的變量：擁塞窗口(CongWin)，它對一個TCP發送方能向網絡中發送流量的速率進行了限制。特別是，在一個發送方中未被確認的數據量不會超過CongWin與RcvWindow中的最小值:

LastByteSent - LastByteAcked <= min{CongWin,RcvWindow}

後面的分析假設TCP接收緩存足夠大，因此不受RcvWindow的限制，從而可以只關注擁塞窗口

兩個擁塞指示：

• 3次冗餘ACK(第一次冗餘是第二次收到相同ACK時，所以一共4次)

• 超時

TCP擁塞控制算法包括三個主要部分：

1.加性增、乘性減

• 加性增：緩慢增加CongWin，每個RTT增加1個MSS，線性增長（擁塞避免）

• 乘性減：發生丟包時，設置CongWin = CongWin/2（不低於1個MSS），從而控制發送速度

2.慢啓動：TCP連接開始時，CongWin的初始值爲1個MSS，指數型增長

3.對擁塞指示作出反應

• 3次冗餘ACK：CongWin = CongWin/2，然後線性增加（擁塞避免）

• 超時：CongWin被設置爲1個MSS，然後指數增長，直到CongWin達到超時前的一半爲止

Threshold(閾值)：用於確定慢啓動將結束並且擁塞避免將開始的窗口長度，初始化爲一個很大的值，每當發送一個丟包時，會被設置爲丟包時CongWin的一半

3.4.5 TCP的應用場景

• web：HTTP 80
• 文件傳輸：FTP 21 20
• 電子郵件：SMTP 25 POP3 110
• 遠程終端訪問：TELNET 23 RDP 3389 遠程桌面協議

如何保證可靠傳輸？

• 差錯檢測、確認、重傳
• 序號（解決ACK受損的問題，判斷是否爲重傳的）：
  • 接收端收到冗餘分組則丟棄
  • 發送端收到冗餘ACK則重傳
• 定時器

如何檢驗丟包？

• 校驗和、確認分組、超時重傳、序號

如何保證TCP的可靠傳輸？

• 檢驗和、重傳、積累確認、序號、確認號、定時器

TCP協議有幾大計時器

1.   重傳計時器
   

在一個TCP連接中，TCP每發送一個報文段，就對此報文段設置一個超時重傳計時器。若在收到了對此特定報文段的確認之前計時器截止期到，則重傳此報文段，並將計時器復位。

2.   持續計時器
   

爲了對付零窗口大小通知，TCP需要另一個計時器。假定接收TCP宣佈了窗口大小爲零。發送TCP就停止傳送報文段，直到接收TCP發送確認並宣佈一個非零的窗口大小。但這個確認可能會丟失。我們知道在TCP中，對確認是不需要發送確認的。若確認丟失了，接收TCP並不知道，而是會認爲它已經完成任務了，並等待着發送TCP接着會發送更多的報文段。但發送TCP由於沒有收到確認，就等待對方發送確認來通知窗口的大小。雙方的TCP都在永遠地等待着對方。要打開這種死鎖，TCP爲每一個連接使用一個堅持計時器。當發送TCP收到一個窗口大小爲零的確認時，就啓動堅持計時器。當堅持計時器期限到時，發送TCP就發送一個特殊的報文段， 叫做 探測報文段 。這個報文段只有一個字節的數據。它有一個序號，但它的序號永遠不需要確認；甚至在計算對其他部分的數據的確認時該序號也被忽略。探測報文段提醒對端：確認已丟失，必須重傳。

3. 保活計時器

保活計時器使用在某些實現中，用來防止在兩個TCP之間的連接出現長時期的空閒。假定客戶打開了到服務器的連接，傳送了一些數據，然後就保持靜默了。也許這個客戶出故障了。在這種情況下，這個連接將永遠地處理打開狀態。

4. 時間等待計時器

時間等待計時器是在連接終止期間使用的。當TCP關閉一個連接時，它並不認爲這個連接馬上就真正地關閉了。在時間等待期間中，連接還處於一種中間過渡狀態。這就可以使重複的FIN報文段（如果有的話）可以到達目的站因而可將其丟棄。這個計時器的值通常設置爲一個報文段的壽命期待值的兩倍。

3.4.6 TCP 黏包問題

原因

TCP 是一個基於字節流的傳輸服務（UDP 基於報文的），“流” 意味着 TCP 所傳輸的數據是沒有邊界的。所以可能會出現兩個數據包黏在一起的情況。

解決

• 發送定長包。如果每個消息的大小都是一樣的，那麼在接收對等方只要累計接收數據，直到數據等於一個定長的數值就將它作爲一個消息。
• 包頭加上包體長度。包頭是定長的 4 個字節，說明了包體的長度。接收對等方先接收包頭長度，依據包頭長度來接收包體。
• 在數據包之間設置邊界，如添加特殊符號 \r\n 標記。FTP 協議正是這麼做的。但問題在於如果數據正文中也含有 \r\n，則會誤判爲消息的邊界。
• 使用更加複雜的應用層協議。

3.4.7 TCP 有限狀態機

TCP 有限狀態機圖片

3.5 UDP

• UDP（User Datagram Protocol，用戶數據報協議）是 OSI（Open System Interconnection 開放式系統互聯） 參考模型中一種無連接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務，其傳輸的單位是用戶數據報。

特徵：

• 無連接
• 盡最大努力交付
• 面向報文
• 沒有擁塞控制
• 支持一對一、一對多、多對一、多對多的交互通信
• 首部開銷小

UDP 報文結構

UDP 首部

TCP/UDP 圖片來源於：<https://github.com/JerryC8080/understand-tcp-udp

3.5.1 UDP實現的工作

• 複用/分解：通常應用
  程序客戶端自動分配端口號，服務器端分配一個特定的端口號
• 差錯檢測：端到端原則，在較低級別設置該功能是冗餘的，沒有差錯恢復

3.5.2 UDP的優點

• 應用層可以更精細的控制何時發送什麼數據（TCP擁塞時會遏制發送方發送）
• 無需建立連接，則沒有建立連接的時延
• 不必維護連接狀態：TCP要維護包括接收和發送緩存、擁塞控制參數、以及序號與確認號的參數
• 分組首部開銷小：UDP有8字節首部，TCP有20字節首部

可以在應用程序自身中構建可靠性機制來實現UDP應用的可靠數據傳輸。

UDP能提供運輸層最低限度的兩個服務：差錯檢測、數據交付。

3.5.3 UDP報文段結構

UDP首部只有4個字段，每個字段2個字節，一共8個字節大小的首部

校驗和：對報文段中的所有16比特字（包括數據部分，不包括校驗和本身）的和相加（如有溢出會捲回）的結果取反就是校驗和。在接收方，會將所有16比特字的和相加，如果分組無差錯，這個和會是“1111-1111-1111-1111”（爲了方便閱讀，使用’-’分隔）

許多鏈路層協議提供了差錯檢測，UDP還需提供校驗和的原因在於，不能確保所有鏈路都提供了差錯檢測。此外，即使報文段經鏈路正確地傳輸，當其存儲在某臺路由器的內存中時，也可能引入比特差錯。既未確保逐段鏈路的可靠性，也未確保內存中的差錯檢測，因此UDP必須在端到端基礎上在運輸層提供差錯檢測

校驗和方法需要相對小的分組開銷。例如，TCP和UDP中的校驗和只用了16比特。然而與常用於鏈路層的CRC(循環冗餘檢測)相比，他們提供相對弱的差錯保護。傳輸層使用校驗和而鏈路層使用CRC的原因是：運輸層通常在主機中作爲用戶操作系統的一部分並用軟件實現，因此採用簡單而快速（如校驗和）的差錯檢測方案是重要的。另一方面，鏈路層的差錯檢測在適配器中用專業硬件實現，它能快速地執行更復雜的CRC操作。

• 字段含義
  • 源端口號（16位）
  • 目的端口號（16位）
  • UDP長度（16位）：冗餘的，IP頭部已經提供數據報長度和首部長度
  • UDP檢驗和（16位）：傳送中不會被修改，除非遇到NAT，計算時加入僞頭部，包含源IP與目的IP，以驗證是否正確的到達目的地
  • 數據

3.5.4 UDP的應用場景

• 域名地址轉換：DNS
• 路由選擇表的更新：RIP
• 遠程文件服務器：NFS
• 網絡管理數據：SNMP
• TFTP 簡單文件傳輸協議 不支持身份認證
• DHCP

UDP爲什麼不可靠，怎麼解決UPD的可靠性問題？

• 不需要建立連接就可以開始傳輸，沒有確保傳遞和流量控制機制，沒有擁塞控制機制。
• 要在應用層實現類似與TCP的可靠連接的技術，比如確認與重傳機制。

2.UDP中一個包的大小最大能多大？

1. 以太網(Ethernet)數據幀的長度必須在46-1500字節之間,這是由以太網的物理特性決定的.這個1500字節被稱爲鏈路層的MTU(最大傳輸單元).但這並不是指鏈路層的長度被限制在1500字節,其實這這個MTU指的是鏈路層的數據區.

2. 並不包括鏈路層的首部和尾部的18個字節.所以,事實上,這個1500字節就是網絡層IP數據報的長度限制.因爲IP數據報的首部爲20字節,所以IP數據報的數據區長度最大爲1480字節.

3. 而這個1480字節就是用來放TCP傳來的TCP報文段或UDP傳來的UDP數據報的.又因爲UDP數據報的首部8字節,所以UDP數據報的數據區最大長度爲1472字節.這個1472字節就是我們可以使用的字節數。

爲什麼UDP有時比TCP更有優勢?

1. 網速的提升給UDP的穩定性提供可靠網絡保障，丟包率很低，如果使用應用層重傳，能夠確保傳輸的可靠性。

2. TCP爲了實現網絡通信的可靠性，使用了複雜的擁塞控制算法，建立了繁瑣的握手過程，由於TCP內置的系統協議棧中，極難對其進行改進。

3. 採用TCP，一旦發生丟包，TCP會將後續的包緩存起來，等前面的包重傳並接收到後再繼續發送，延時會越來越大，基於UDP對實時性要求較爲嚴格的情況下，採用自定義重傳機制，能夠把丟包產生的延遲降到最低，儘量減少網絡問題對遊戲性造成影響。

TCP 與 UDP 的區別

1. TCP 面向連接，UDP 是無連接的；
2. TCP 提供可靠的服務，也就是說，通過 TCP 連接傳送的數據，無差錯，不丟失，不重複，且按序到達；UDP 盡最大努力交付，即不保證可靠交付
3. TCP 的邏輯通信信道是全雙工的可靠信道；UDP 則是不可靠信道
4. 每一條 TCP 連接只能是點到點的；UDP 支持一對一，一對多，多對一和多對多的交互通信
5. TCP 面向字節流（可能出現黏包問題），實際上是 TCP 把數據看成一連串無結構的字節流；UDP 是面向報文的（不會出現黏包問題）
6. UDP 沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如 IP 電話，實時視頻會議等）
7. TCP 首部開銷20字節；UDP 的首部開銷小，只有 8 個字節

4.網絡層

• IP（Internet Protocol，網際協議）是爲計算機網絡相互連接進行通信而設計的協議。
• ARP（Address Resolution Protocol，地址解析協議）
• ICMP（Internet Control Message Protocol，網際控制報文協議）
• IGMP（Internet Group Management Protocol，網際組管理協議）

4.1網絡層功能和服務

網絡層的3個重要功能：

1.轉發：當一個分組到達某路由器的一條輸入鏈路時，路由器將分組移動到適當輸出鏈路的過程

2.選路：當分組從發送方傳至接收方時，網絡層決定這些分組所採用的路由或路徑的過程

3.連接建立：ATM等非因特網的網絡層體系結構要求從源到目的地沿着所選的路徑建立連接

虛電路和數據報網絡：

• 虛電路(VC)網絡：面向連接的，數據按需到達，分組不會丟失，路由器爲進行中的連接維持連接狀態信息

• 數據報網絡：無連接的，但在轉發表中維持了轉發狀態信息。因特網是數據報網絡（數據報網絡中，通常每1~5分鐘左右更新一次轉發表，因爲轉發表會被修改，所以從一個端系統到另一個端系統發送一系列分組可能在通過網絡時走不同的路徑，從而無序到達）

4.2轉發

使用最長前綴匹配來匹配路由表中的表項，決定轉發出口

路由器

路由器由4部分組成：

• 輸入端口

• 交換結構

• 輸出端口

• 選路處理器：維護有選路信息與轉發表，並執行路由器中的網絡管理功能

1）輸入端口

• 查找/轉發模塊：對於路由器的轉發功能是至關重要的。許多路由器中，都是在這確定一個到達的分組經交換結構轉發到哪個輸出端口。雖然轉發表是由選路處理器計算的，但通常一份轉發表的影子拷貝會被存放在每個輸入端口，而且會被更新。因此，就可以在每個輸入端口本地做出轉發決策，而無需調用中央選路處理器，從而可以避免在路由器中的某個單點產生轉發處理的瓶頸

2）交換結構

一個分組可能會在進入交換結構時暫時阻塞，這是由於來自其它輸入端口的分組正在使用該交換結構

• 經內存交換：分組到達輸入端口時，端口會通過中斷向選路處理器發出信號，於是分組被拷貝到處理器內存中。選路處理器則從分組首部中取出目的地址，在轉發表中找出適當的輸出端口，並將分組拷貝到輸出端口的緩存中

• 經一根總線交換：經一根共享總線將分組直接傳送到輸出端口，不需要選路處理器的干預。因爲總線是共享的，故一次只能有一個分組通過總線傳送

• 經一個互連網絡交換：到達某個輸入端口的分組沿着連到輸入端口的水平總線穿行，直至該水平總線與連到所希望的輸出端口的垂直總線的交叉點

3）輸出端口

輸出端口處理取出存放在輸出端口內存中的分組並將其傳輸到輸出鏈路上。當交換結構將分組交付給輸出端口的速率超過輸出鏈路速率時，就需要排隊與緩存管理功能

4）排隊

輸入端口和輸出端口都能形成分組隊列，隨着隊列的增長，路由器的緩存空間將會最終耗盡，出現丟包

輸出端口排隊：當所有輸入端口的分組發往同一個輸出端口並且交換結構速率足夠大而輸出端口的分組傳輸速率不高時，分組會在該輸出端口排隊。排隊的後果是，輸出端口上的一個分組調度程序必須在這些排隊的分組中選一個來傳送，分組調度程序在提供服務質量保證方面起着關鍵作用

輸入端口排隊：如果交換結構速率不高，不同輸入端口的隊首分組需要發往同一個輸出端口，此時交換結構需要選擇其中一個輸入端口的分組進行發送。因此，其它輸入端口中的分組會阻塞產生排隊。在隊首分組之後的分組，也會因爲隊首分組阻塞而被阻塞，即使它們需要轉發到的輸出端口此時處於空閒。這種現象叫做作線路前部阻塞(HOL)

4.3選路

• 第一跳路由器 = 默認路由器 = 源路由器

• 目的路由器：目的主機的默認路由器

源主機到目的主機選路的問題可歸結爲從源路由器到目的路由器的選路問題

4.3.1 全局選路算法(LS算法)

全局選路算法用完整的、全局性的網絡信息來計算從源到目的地之間的最低費用路徑。由於具有全局狀態信息，所以這種算法又常被稱爲鏈路狀態算法

• Dijkstra算法

4.3.2 分佈式選路算法(距離向量算法)

以迭代的、分佈式的方式計算出最低費用路徑。和全局選路算法的區別在於，沒有節點擁有關於所有網絡鏈路費用的完整信息，每個節點僅有與其直接相連鏈路的費用信息

• 距離向量算法(DV)

– 分佈式：每個節點從一個或多個直接相連的鄰居接收某些信息，執行計算，然後將計算結果發回鄰居

– 迭代：上述過程持續到鄰居之間沒有更多的信息要交換爲止

– 異步：不要求所有節點相互之間步伐一致

DV使用公式：dx(y) = minv{c(x,v)+dv(y)} 更新x到y的距離（dx(y)是從x到y的最低費用路徑的費用，minv是指取遍x的所有鄰居）

好消息傳的快，壞消息傳的慢：

• 好消息傳的快

– t0時：y檢測到距x的費用由4變爲1，更新其距離向量，並通知鄰居

– t1時：z收到來自y的更新報文並更新了其距離向量，計算出到x的新最低費用(5減爲2)

– t2時：y收到來自z的更新並更新其距離表，y的最低費用未改變，不發送報文，算法終止

• 壞消息傳的慢

– t0時：y檢測到距x的費用由4變爲60，y更新其到x的距離爲6(途經z，因爲z的距離表中記錄到x的距離爲5)，這是分佈式的角度，從全局角度看，這個距離是錯的，但分佈式中節點的狀態信息有效。開始出現選路環路，即爲到達x，y通過z選路，z又通過y選路，不停來回反覆

– t1時：y將到達x的新費用告知z

– t2時：z收到y的消息，z計算出從x到x是50，從y到x是7，所以更新到x的最低費用爲7，並通知y這個改變

– 上述過程會一直反覆，直到z最終算出它經由y的路徑費用大於50爲止（此時到x不途經y），y將經由z到x（如果費用增加到10000甚至更多，開銷可想而知）

4.3.3 因特網中的選路

隨着路由器數目變大，選路信息的計算、存儲及通信的開銷逐漸高得驚人，數億臺主機中存儲選路信息需要巨大容量的內存。在公共因特網上所有路由器上廣播LS更新的開銷將導致沒有剩餘帶寬供發送數據分組使用。距離向量算法在如此大的路由器中的迭代將肯定永遠不會收斂。可以將路由器組織成自治系統(AS)來解決

自治系統(AS)：一組處於相同的管理與技術控制下的路由器集合（ISP和AS之間是什麼關係？通常一個ISP中的路由器和互連它們的鏈路構成了單個AS，但許多ISP將它們的網絡劃分爲多個AS）

因特網中的選路協議：

• AS之間

  • 邊界網關協議(BGP/BGP4)

    • BGPv4是一種外部的路由協議。可認爲是一種高級的距離向量路由協議。

    • 路由器對使用179端口的半永久TCP連接交換選路信息

    • 每條TCP連接的兩臺路由器被稱爲BGP對等方

    • 發送BGP報文的“TCP連接”稱爲BGP會話（跨越兩個AS之間的BGP會話稱爲eBGP，同一AS中兩個路由器間的BGP會話稱爲內部BGP會話）

    • BGP中，目的地是CIDR化的前綴，表示一個子網或子網集合（假設有多個子網與一個AS相連，AS會聚合這些前綴，來向相鄰的AS通告聚合後的單一前綴，如果到達相同前綴有多個路由，BGP會使用一些規則消除直到留下一條路由）

    • 在BGP網絡中，可以將一個網絡分成多個自治系統。自治系統間使用eBGP廣播路由，自治系統內使用iBGP在自己的網絡內廣播路由。

    • BGP路由選擇方法是基於距離向量路由選擇，與傳統的距離向量（1個單獨的度量，如跳數）協議不同，BGP將AS外部路徑的度量複雜化。

    • BGP系統的主要功能是和其他BGP系統交換網絡可達信息。網絡可達信息包括列出的AS信息。這些信息有效地構造了AS互聯的拓樸圖並由此清除了路由環路，同時在AS級別上可實施策略決策。

    • BGP特點：

      • BGP是一種外部路由協議，與OSPF、RIP不同，其着眼點不在於發現和計算路由，而在於控制路由的傳播和選擇最好的路由。
      • BGP通過攜帶AS路徑信息，可以徹底的解決路由循環問題。
      • 爲了控制路由的傳播和路由的選擇，爲路由附帶屬性信息。
      • 使用TCP作爲其傳輸層協議，提高了協議的可靠性。端口號TCP
        179。
      • BGP-4支持CIDR（無類別域間選路），CIDR的引入簡化了路由聚合，減化了路由表。
      • BGP更新時只發送增量路由，減少了BGP傳播路由佔用的帶寬。
      • 提供了豐富的路由策略。

• AS內部

  • 選路信息協議(RIP)

    • 運行於UDP之上的應用層協議

    • 使用DV選路算法，使用跳數作爲費用測度，“跳”是從源路由器到目的子網的子網數，一條路徑的最大費用被限制爲15，從而限制了使用RIP的AS規模。

    • 大約每30秒通過RIP響應報文(也稱爲RIP通告)交換距離向量信息

    • 距離矢量協議

      • 距離向量：RIP發送的報文包含一個距離向量（跳數）。每個路由器都根據它接收到鄰站的這些距離向量來更新自己的路由表。

    • 工作過程

      • 初始化：在啓動一個路由守護程序時，它先判斷啓動了哪些接口，並在每個接口上發送一個請求報文，要求其他路由器發送完整路由表。在點對點鏈路中，該請求是發送給其他終點的。如果網絡支持廣播的話，這種請求是以廣播形式發送的。目的UDP端口號是520（這是其他路由器的路由守護程序端口號）

      • 接收到請求：如果這個請求是剛纔提到的特殊請求，那麼路由器就將完整的路由表發送給請求者。否則，就處理請求中的每一個表項：如果有連接到指名地址的路由，則將度量設置成我們的值，否則將度量值設爲16（度量爲16是一種稱爲"無窮大"的特殊值，它意味着沒有到達目的的路由）。然後發出響應。

      • 接收到響應：使響應生效，可能會更新路由表。可能會增加新表項，對已有表項進行修改，或者將已有表項刪除。

      • 定期選路更新：每過30秒，所有或部分路由器會將其完整路由表發送給相鄰路由器。發送路由表可以是廣播形式的（如在以太網上），或是發送給點對點鏈路的其他終點。

      • 觸發更新：每當一條路由的度量發生變化時，就對它進行更新。不需要發送完整的路由表，而只需要發送那些變化的表項。每條路由都有與之相關的定時器。如果運行RIP的系統發現一條路由在
        3分鐘內未更新,就將該路由的度量設置成無窮大( 16),並標註爲刪除。這意味着已經在 6個30秒更新時間裏沒收到通告該路由的路由器的更新了。再過 60秒,將從本地路由表中刪除該路由,以保證該路由的失效已被傳播開。

    • RIP的優缺點

      • 算法簡單，配置簡單，適合用在小型網絡之中
      • 無法區分非零部分是子網部分還是主機地址
      • 這種方法看起來很簡單,但它有一些缺陷。首先，RIP沒有子網地址的概念。例如,如果標準的B類地址中16bit的主機號不爲0,那麼RIP無法區分非零部分是一個子網號,或者是一個主機地址。有一些實現中通過接收到的RiP信息,來使用接口的網絡掩碼,而這有可能出錯。
      • 可能會發生路由環路在路由器或鏈路發生故障後,需要很長的一段時間才能穩定下來。這段時間通常需要幾分鐘。在這段建立時間裏,可能會發生路由環路。在實現RIP時,必須採用很多微妙的措施來防止路由環路的出現,並使其儘快建立。
      • 度量最大爲15，限制網絡大小
      • 採用跳數作爲路由度量忽略了其他一些應該考慮的因素。同時度量最大值爲15，則限制了可以使用RIP的網絡的大小。

  • 開放最短路徑優先(OSPF)：直接作爲IP協議的載荷

    • 直接承載在IP分組中，必須自己實現可靠報文傳輸、鏈路狀態廣播等功能

    • 使用LS選路算法，鏈路費用是由網絡管理員配置的

    • 通常用於較頂層的ISP中，而RIP通常用於較低層的ISP中

    • 至少每隔30分鐘廣播一次鏈路狀態(即使狀態未發生改變)

    • 核心是一個使用泛洪鏈路狀態信息的鏈路狀態協議和一個Dijkstra最低費用路徑算法。每個路由器主動地測試與其鄰站相連鏈路的狀態，將這些信息發送給它的其他鄰站，而鄰站將這些信息在自治系統中傳播出去。每個路由器接收這些鏈路狀態信息，並建立起完整的路由表。

    • OSPF與RIP的不同

      • 鏈路狀態協議比距離向量協議收斂的更快。收斂的意思是在路由發生變化後，例如在路由關閉或鏈路出故障後，可以穩定下來。
      • OSPF直接使用IP，對於IP首部的protocol字段，OSPF有其自己的值。

    • OSPF較RIP的優點

    • OSPF可以對每個IP服務類型計算各自的路由集。這意味着對於任何目的，可以有多個路由表表項，每個表項對應着一個IP服務類型。

    • 給每個接口指派一個無維數的費用。可以通過吞吐率、往返時間、可靠性或其他性能來進行指派。可以給每個IP服務類型指派一個單獨的費用。

    • 當對同一個目的地址存在着多個相同費用的路由時，OSPF在這些路由上平均分配流量。我們稱之爲流量平衡。

    • OSPF支持子網：子網掩碼與每個通告路由相連。這樣就允許將一個任何類型的IP地址分割成多個不同大小的子網。到一個主機的路由是通過全1子網掩碼進行通告的。默認路由是以IP地址爲0.0.0.0、網絡掩碼爲全0進行通告的。

    • 路由器之間的點對點鏈路不需要每端都有一個IP地址，我們稱之爲無編號網絡。這樣就可以節省IP地址。

    • 採用了一種簡單鑑別機制。可以採用類似RIP-2的方法指定一個明文口令。

    • OSPF採用多播，而不是廣播形式，以減少不參與OSPF的系統負載。

  • 一些常見的其他問題

    • OSPF的實現過程以及五種分組類型
    • hello報文的作用，hello報文是基於UDP還是TCP?
    • OSPF的負載均衡是怎麼做的？
    • OSPF的使用場景
    • OSPF和rip的本質區別是什麼？OSPF一定比RIP收斂快嗎？
      • ospf
        是基於鏈路狀態的路由協議，主要以帶寬作爲選路的依據
      • RIP 是基於跳數的路由協議，以跳數作爲選路的依據

4.4 IP(網際協議)

IP 地址分類：

• IP 地址 ::= {<網絡號>,<主機號>}

IP 地址類別	網絡號	網絡範圍	主機號	IP 地址範圍
A 類	8bit，第一位固定爲 0	0 —— 127	24bit	1.0.0.0 —— 127.255.255.255
B 類	16bit，前兩位固定爲 10	128.0 —— 191.255	16bit	128.0.0.0 —— 191.255.255.255
C 類	24bit，前三位固定爲 110	192.0.0 —— 223.255.255	8bit	192.0.0.0 —— 223.255.255.255
D 類	前四位固定爲 1110，後面爲多播地址
E 類	前五位固定爲 11110，後面保留爲今後所用

IP 數據報格式：

4.4.1 因特網三大組件

1.IP協議

2.選路組件

3.報告數據報中的差錯和對某些網絡層信息請求進行響應的設施

4.4.2 數據報格式

下圖爲一個IPv4數據報的格式：

• 版本號：IP協議的版本，路由器根據版本號確定如何解釋剩餘部分

• 首部長度：一個IPV4數據報可包含一些可選項，所以需要用4比特確定數據部分實際從哪開始，大多數IP數據報不包含可選項，有20字節的首部

• 服務類型：可以使不同類型(實時與非實時等)的IP數據報區分開來

• 數據報長度：IP數據報的總長（16bit，首部+數據，所以IPv4數據報的最大大小是65535字節）

• 壽命(TTL)：8位，用以確保數據報不會永遠在網絡中循環，每經過一臺路由器減1，減爲0時丟棄

• 上層協議：指明瞭數據部分應該交給哪個運輸層協議（UDP(6)、TCP(17)）

• 首部校驗和：首部中每2個字節作爲一個數，和的反碼存入校驗和字段中。路由器一般會丟棄檢測出的錯誤數據報。每臺路由器上都必須重新計算並更新校驗和，因爲TTL及選項字段可能會改變

• 選項：在IPv6中已不再使用

除此之外，首部中的以下3個字段用於IP數據報分片的標識

• 標識：識別分片的序號

• 標誌：最後一個分片的標誌爲0，其餘分片的標誌爲1（設置DF位表示不允許分片，可用於路徑MTU發現）

• 比特片偏移：該分片起始數據在原數據報中的偏移量/8

IPv4要求的最小鏈路MTU是68字節，這允許最大IPv4首部(20字節固定長度+最多40字節選項部分)拼接最小的片段（IPv4首部中片段偏移字段以8個字節爲單位）

4.4.3 IP數據報分片

一個鏈路層幀能承載的最大數據量叫做最大傳輸單元(MTU)（以太網可承載不超過1500字節的數據），因爲每個IP數據報封裝在鏈路層幀中，再從一臺路由器運輸到下一臺路由器，故鏈路層協議MTU嚴格地限制着IP數據報的長度。發送方與目的地路徑上的每段鏈路可能使用不同的鏈路層協議，每種協議可能具有不同的MTU，如果轉發表查找決定的出鏈路的MTU比該IP數據報的長度小，則需要對IP數據報進行分片。片在到達目的地運輸層以前需要被組裝，如果一個或多個片沒有到達目的地，則該不完整的數據報被丟棄

分片可以通過4.2中介紹的IP數據報中的標識、標誌、比特片偏移來識別

4.4.4 IPv4編址

主機與物理鏈路之間的邊界叫做接口，一個IP地址在技術上是與一個接口相關聯的，而不是與包括該接口的主機或路由器相關聯的

IP地址編址格式：點分十進制，一個接口的IP地址的組成部分需要由其連接的子網來決定。互連主機的接口與路由器一個接口的網絡形成一個子網：

IP編址爲子網分配一個地址：223.1.1.0/24，其中/24記法稱爲子網掩碼。其它要連到223.1.1.0/24網絡的主機都要求其地址形式爲223.1.1.xxx

除此之外，子網還包括互連路由器接口的網段

1）分類編制

在無類別域間選路之前，IP地址的分配策略採用分類編制，網絡分爲下面3類

• A類網絡：網絡部分被限制長度爲8比特

• B類網絡：網絡部分被限制長度爲16比特

• C類網絡：網絡部分被限制長度爲24比特

分類編制的問題在於：對於一個組織，分配一個B類網絡可能太大，分配一個C類網絡可能太小，這樣分配B類網絡就會造成地址空間的迅速消耗，以及大量的地址浪費。這個問題類似於操作系統內存管理中固定分區的問題

2）無類別域間選路(CIDR)

32比特的IP地址被劃分爲2部分，a.b.c.d/x，前x比特構成了IP地址的網絡部分，被稱爲該地址的網絡前綴

組織外部的路由器僅考慮前綴比特，大大減少了路由器中的轉發表的長度。剩餘32-x比特用於區分組織內部設備，當組織內部的路由器轉發分組時，纔會考慮這些比特

IP地址由因特網名字與號碼分配機構(ICANN)管理，非盈利的ICANN不僅分配IP地址，還管理DNS根服務器、解決分配域名與域名糾紛，ICANN向地區性因特網註冊機構分配地址，這些機構一起形成了ICANN地址支持組織，處理本地域內的地址分配/管理

4.4.5 DHCP(動態主機配置協議)

一個組織一旦獲得一塊地址，就可以爲該組織內的主機和路由器接口分配獨立的IP地址

DHCP可以提供以下服務：

• 爲主機分配IP地址

• 獲取子網掩碼

• 獲取第一跳路由器地址（常稱爲默認網關）

• 提供本地DNS服務器的地址（記錄在/etc/resolv.conf文件中）

由於DHCP具有能將主機連接進一個網絡的自動化網絡相關方面的能力，故它又常被稱爲即插即用協議

每個子網擁有一臺DHCP服務器，如果某個子網沒有DHCP服務器，則需要一個知道用於該網絡的一臺DHCP服務器地址的DHCP中繼代理（通常是一臺路由器）

DHCP協議的4個步驟：

1.DHCP服務器發現：新到的客戶端在68號端口使用UDP廣播(255.255.255.255)DHCP發現報文，源地址爲0.0.0.0

2.DHCP服務器提供：子網中收到DHCP請求報文的DHCP服務器使用DHCP提供報文作出響應，提供IP地址、網絡掩碼、IP地址租用期(通常設置爲幾個小時或幾天)

3. DHCP請求：客戶端從多個服務器的響應中選擇一個，並用一個DHCP請求報文對選中的服務器進行響應，回顯配置參數（這一步目的地址使用廣播地址是因爲在DHCP服務器提供時，服務器爲客戶預分配了IP地址，因此，客戶有責任通知不採用的服務器，好讓它們釋放預分配的地址）

4.DHCP ACK：服務器用DHCP ACK報文對DHCP請求報文進行響應，證實所要求的參數

DHCP有不足之處：每當一個節點連到一個新子網時，都要從DHCP得到一個新的IP地址，這樣當一個移動節點在子網直接移動時，就不能維持與遠程應用之間的連接。移動IP是一種對IP基礎設施的擴展，允許移動節點在子網之間移動時能使用其單一永久的地址

4.4.6 NAT(網絡地址轉換)

NAT適用這樣一種場景：由於每個IP使能的設備都需要一個IP地址，如果一個子網已經獲得了一塊IP地址，當連入設備增加時，IP地址可能不足

NAT主要通過NAT使能路由器來解決上述問題。同時，地址空間10.0.0.0/8是在RFC 1918中保留的3部分IP地址空間之一，可以用於專用網絡或具有專用地址的地域（具有專用地址的地域是指其地址僅對該網絡中的設備有意義的網絡），關鍵問題是：專用地址對於外部網絡無效，使用專用地址的設備如何與外部網絡通信？爲了解決這個問題，NAT使能路由器中保存有一個NAT轉換表：

NAT使能路由器對外界的行爲就像一個具有單一IP地址的單一設備，通過端口號來標識一個使用專用地址的設備

• 當專用設備與外界通信時，NAT使能路由器爲其生成一個新的源端口號，並使用連入廣域網一側接口的IP地址作爲源地址發送數據報，同時會將這個映射關係記錄在NAT轉換表中

• 當有數據報到達時，NAT使能路由器通過查找NAT轉換表中的映射關係，改寫目的IP和端口號，向專用網絡轉發數據報

私有IP網段：

• 10.0.0.0 ~ 10.255.255.255

• 172.16.0.0 ~ 172.31.255.255

• 192.168.0.0 ~ 192.168.255.255

NAT有很多爭議：1）端口號是用於編址進程的方法，不是用於編址主機的；2）路由器應該處理最多達第三層的分組；3）NAT違反了所謂的“端到端原則”；4）解決IP地址短缺的方法應該是IPv6，而不是像NAT這樣一種權宜之計；但是不管喜歡與否，NAT已成爲因特網一個重要的組件

4.4.7 ICMP(互聯網控制報文協議)

ICMP 報文格式：

應用：

• PING（Packet InterNet Groper，分組網間探測）測試兩個主機之間的連通性
  • TTL（Time To Live，生存時間）該字段指定 IP 包被路由器丟棄之前允許通過的最大網段數量

ICMP用於主機和路由器彼此交互網絡層信息。最典型的用途是差錯報告，但其用途不僅限於此(如源抑制，用於擁塞控制)

ICMP通常被認爲是IP的一部分，但從體系結構上講，它是位於IP之上，因爲ICMP報文承載在IP分組中，作爲IP有效載荷

ICMP的類型和編碼：
Traceroute：允許用戶跟蹤從一臺主機到世界上任意一臺其他主機之間的路由，使用ICMP報文實現。發送一系列不可達UDP端口號的UDP報文段，每個報文段封裝後的數據報TTL字段逐1遞增，TTL爲n的數據報到達第n跳路由器時，由於TTL過期，路由器會生成ICMP報文響應，由此可以獲得第n跳路由器的IP和名字，當一個數據報最終到達目的主機時，由於UDP端口不可達，目的主機生成一個ICMP報文，指示此錯誤信息，從而Traceroute知道不需要再發送探測分組了，因此獲得了到達目的主機的所有路由數量、標識以及RTT。

4.4.8 IPv6

1）IPv6數據報格式

IPv6引入了稱爲任播地址的新地址，這種地址可以使一個數據報能交付給一組主機中的任意一個

定長的40字節首部允許更快的處理IP數據報

• 版本號：IPv6將該字段值設置爲6

• 流量類型：與IPv4中的”服務類型“字段含義相同，區分不同類型數據報（實時/非實時）

• 有效載荷：數據部分的字節數（16bit，不包括首部，所以IPv6數據報的最大大小是65535+40=65575字節）

• 下一個首部：應該交付給運輸層的哪個協議

• 跳限制：同TTL

IPv6不允許在中間路由器上進行分片與重新組裝，這種操作只能在源與目的地上進行。如果一臺路由器收到的IPv6數據報因太大而不能轉發到出鏈路上，則只需丟掉該數據報，並返回一個”分組太大“的ICMP差錯報文。因此IPv6中沒有IPv4用於分片相關的3個字段

IPv6的關注快速處理分組，由於運輸層提供了差錯檢測，IP設計者可能覺得沒必要再在網絡層進行差錯檢測，所以去掉了首部校驗和字段

IPv4中的選項字段並沒有作爲IPv6的首部字段出現，但其並未消失，而是可能出現在可能出現在首部中由”下一個首部“指出的位置上

IPv6要求的最小鏈路MTU爲1280字節，IPv6可以運行在MTU小於此最小值的鏈路上，不過需要特定於鏈路的分片和重組功能，以使得這些鏈路看起來具有至少爲1280字節的MTU。IPv6只有主機對其產生的數據報分片，IPv6路由器不對其轉發的數據報執行分片

2）從IPv4向IPv6遷移

雖然能處理IPv6的系統可做成向後兼容的，即能發送和接收IPv4數據報，但已設置的IPv4使能的系統不能處理IPv6數據報，要解決這個問題可以使用雙棧（即IPv6節點也具有完整的IPv4實現，這樣的節點在RFC 4213中被稱爲IPv6/IPv4節點）

一種雙棧方法是建隧道：

假定2個IPv6節點要使用IPv6通信（圖中的B和E），但經由IPv4路由器而互連，將中間IPv4路由器的集合稱爲一個隧道
藉助於隧道，在該隧道發送端的IPv6節點可將整個IPv6數據報放在一個IPv4數據報的數據字段中。於是該IPv4數據報的目的地址設爲隧道接收端的IPv6節點（同時具有IPv6和IPv4地址），然後通過隧道傳輸，隧道接收端的IPv6節點E最終收到該IPv4數據報，並確定IPv4數據報含有一個IPv6數據報，提取出後再爲IPv6數據報選路，轉發

爲什麼TCP/IP在運輸層與網絡層都執行差錯檢測？
IP層只對IP首部計算檢驗和，TCP/UDP檢驗和是對整個報文段進行的

• TCP/UDP與IP不一定同屬於一個協議棧

內部網關協議

• RIP（Routing Information Protocol，路由信息協議）
• OSPF（Open Sortest Path First，開放最短路徑優先）

外部網關協議

• BGP（Border Gateway Protocol，邊界網關協議）

IP多播

• IGMP（Internet Group Management Protocol，網際組管理協議）
• 多播路由選擇協議

VPN 和 NAT

• VPN（Virtual Private Network，虛擬專用網）
• NAT（Network Address Translation，網絡地址轉換）

路由表包含什麼？

1. 網絡 ID（Network ID, Network number）：就是目標地址的網絡 ID。
2. 子網掩碼（subnet mask）：用來判斷 IP 所屬網絡
3. 下一跳地址/接口（Next hop / interface）：就是數據在發送到目標地址的旅途中下一站的地址。其中 interface 指向 next hop（即爲下一個 route）。一個自治系統（AS, Autonomous system）中的 route 應該包含區域內所有的子網絡，而默認網關（Network id: 0.0.0.0, Netmask: 0.0.0.0）指向自治系統的出口。

根據應用和執行的不同，路由表可能含有如下附加信息：

1. 花費（Cost）：就是數據發送過程中通過路徑所需要的花費。
2. 路由的服務質量
3. 路由中需要過濾的出/入連接列表

5.鏈路層

主要信道：

• 點對點信道
• 廣播信道

點對點信道

• 數據單元 ———— 幀

三個基本問題：

• 封裝成幀：把網絡層的 IP 數據報封裝成幀，SOH - 數據部分 - EOT
• 透明傳輸：不管數據部分什麼字符，都能傳輸出去；可以通過字節填充方法解決（衝突字符前加轉義字符）
• 差錯檢測：降低誤碼率（BER，Bit Error Rate），廣泛使用循環冗餘檢測（CRC，Cyclic Redundancy Check）

點對點協議（Point-to-Point Protocol）：

• 點對點協議（Point-to-Point Protocol）：用戶計算機和 ISP 通信時所使用的協議

廣播信道

廣播通信：

• 硬件地址（物理地址、MAC 地址）
• 單播（unicast）幀（一對一）：收到的幀的 MAC 地址與本站的硬件地址相同
• 廣播（broadcast）幀（一對全體）：發送給本局域網上所有站點的幀
• 多播（multicast）幀（一對多）：發送給本局域網上一部分站點的幀

5.1鏈路層提供的服務

鏈路層可能提供的服務包括：

• 成幀：將網絡數據報封裝成幀
• 鏈路接入：媒體訪問控制(MAC)協議規定了幀在鏈路上傳輸的規則
• 可靠交付：可靠交付服務通常用於易產生高差錯率的鏈路，對於低比特差錯的鏈路，可靠交付可能被認爲是一種不必要的開銷，因此不提供此服務
• 流量控制：沒有流量控制，可能會造成緩存區溢出
• 差錯檢測和糾正：奇偶校驗，檢驗和，CRC校驗
• 半雙工和全雙工：全雙工時，鏈路兩端的節點可以同時傳輸分組

5.1.1 差錯檢測和糾錯技術

在發送節點，爲了避免比特差錯，使用**差錯檢測和糾錯比特(EDC)**來增強數據的可靠性。

差錯檢測和糾正技術有時使接收方檢測到已經出現的比特差錯，但並非總是這樣。即使採用差錯檢測比特，也還是可能有未檢出比特差錯的情況
因此，主要是選擇一個差錯檢測方案，使得這種事件發生的概率很小。可以使用下列3種技術進行差錯檢測：

1.奇偶校驗：只需包含1個附加比特。

– 對於偶校驗，選擇一個值使得所有比特中1出現偶數次

– 對於奇校驗，選擇一個值使得所有比特中1出現基數次 接收方通過檢測1出現的次數判斷是否出現差錯。如果出現偶數個比特差錯，則檢驗不出。可以使用二維化的方案（詳見教材）進行優化

2.校驗和：通常更多的應用於運輸層。將數據分爲多個k比特的序列，相加(可能回滾)後取反，作爲校驗和。接收方對所有k比特（包括校驗和）的序列相加，結果的任意比特如果出現0，則檢測爲出現比特差錯

3.循環冗餘檢測**(CRC)**：發送方和接收方協商一個r+1比特的生成多項式(G)，要起其最高比特位爲1。發送方通過在d比特的數據後附加r比特，使得整個(d+r)比特的值能夠被G整除。接收方用G去除(d+r)比特，如果餘數非0，則出現差錯（附加r比特的計算詳見教材）

5.2媒體訪問控制(MAC)協議

5.2.1 點對點協議(PPP)

點對點協議(PPP)用於點對點鏈路，點對點鏈路由鏈路一端的單個發送方和鏈路另一端的單個接收方組成。通常住宅主機撥號鏈路就是用的PPP，所以它是目前部署最廣泛的鏈路層協議之一。

5.2.2 多路訪問協議

多路訪問協議用於廣播鏈路，廣播鏈路能夠讓多個發送和接收節點都連接到相同的、單一的、共享的廣播信道上。多路訪問協議用於協調多個發送和接收節點對一個共享廣播信道的訪問

1.信道劃分協議：帶寬限制：R/N

– TDM(時分多路複用)：對於N個節點的信道，傳輸速率爲R bps，TDM將時間劃分爲時間幀，並進一步劃分每個時間幀爲N個時隙，每個節點在特定的時隙內傳輸（消除了碰撞，非常公平；但節點被限制與R/N bps的平均速率，即使只有一個節點有數據要發送）

– FDM(頻分多路複用)：在R bps的信道中創建了N個較小的R/N bps信道，每個節點使用一個較小的信道傳輸（消除了碰撞，公平；但節點被限制與R/N bps的平均速率，即使只有一個節點有數據要發送）

– CDMA(碼分多址)：每個節點分配一種不同的編碼，每個節點使用其唯一的編碼來對發送的數據進行編碼（如果精心選擇編碼，不同節點能同時傳輸）

2.隨機接入協議：全部速率

– 純ALOHA：幀到達節點時，立刻傳輸。如果發生碰撞，節點將立即(在完全傳輸碰撞幀後)以概率p重傳。否則，等待一個幀傳輸時間，再以概率p重傳…（信道有效傳輸速率實際不是R bps，而是時隙ALOHA的一半，詳見教材）

– 時隙ALOHA：時間被劃分爲時隙，每個節點的時間同步，幀的傳輸只在時隙的開始時進行。如果發生碰撞，在下一個時隙開始時以概率p重傳，否則等待一個時隙再以概率p重傳…（信道有效傳輸速率實際不是R bps，而是0.37R bps，詳見教材）

– CSMA(載波偵聽多路訪問)：發送前先偵聽信道，如果沒有其它節點在使用信道，則傳輸數據。CSMA沒有碰撞檢測，即使發生碰撞，也將傳輸完碰撞幀（由於節點間數據傳輸存在時延，很可能一個傳輸正在信道中但是由於還未到達所以檢測到信道空閒，此時傳輸最終會發生碰撞）

– CSMA/CD(具有碰撞檢測的載波偵聽多路訪問)：先偵聽信道，如果沒有其它節點在使用信道，則傳輸數據。但是有碰撞檢測，如果發生碰撞，會停止傳輸剩下的數據，等待一個隨機時間(通常比傳輸一幀短)後，再進行嘗試

3.輪流協議

– 輪詢協議：指定節點之一爲主節點。主節點以循環的方式輪詢每個節點。告訴每個節點能夠傳輸的最大幀數，然後讓節點傳輸幀，主節點通過觀察信道上是否缺乏信號來決定一個節點合適完成了幀的發送（消除了困擾隨機接入協議的碰撞和空時隙，效率很高；但引入了輪詢延時，同時主節點發生故障將使信道不可用）

– 令牌傳遞協議：節點間通過令牌傳遞信道使用權，如果沒有數據發送，立即傳遞令牌給下一節點（一個節點的故障可能會使整個信道崩潰。或者如果一個節點忘記釋放令牌，必須調用某些恢復步驟使令牌返回到循環中來）

5.3鏈路層編制

5.3.1 MAC地址

長度爲6字節，共48比特，通常用十六進制表示法，地址的每個字節被表示爲一對十六進制數

• 每個適配器具有一個唯一的MAC地址，不隨位置發生變化（就像人的身份證，而IP則像人的郵政地址）

• 一臺路由器的每個接口都有一個ARP模塊和一個適配器

MAC地址分配：當一個公司要生產適配器時，它支付象徵性的費用購買一塊MAC地址空間，IEEE分配這塊地址時，固定前24比特，讓公司自己爲每個適配器生成後24比特的唯一組合

5.3.2 ARP(地址解析協議)

• 提供將IP地址轉換爲鏈路層地址的機制（ARP只爲同一子網上的節點解析IP地址，DNS爲因特網中任何地方的主機解析主機名）： 1. 每個節點的ARP模塊都在它的RAM中有一個ARP表，包含IP地址到MAC地址的映射關係，每個表項還包含TTL字段，表示表項過期時間（ARP表是自動創建的，如果某節點與子網斷開連接，它的表項最終會從留在子網中的節點的表中刪除。通常一個表項的過期時間是20分鐘） 2. 主機向其ARP模塊提供一個IP地址，ARP模塊返回IP地址對應的MAC地址。
• ARP數據報格式
  • 工作原理
    • 查詢ARP表中有沒有該目的主機的表項
    • 構造一個ARP查詢分組，用MAC廣播地址（全F）發送給全局域網，匹配的主機發送一個響應ARP分組
    • 查詢主機更新ARP表，發送IP數據報
    • 查詢ARP幀是在廣播幀中發送的，響應ARP報文在標準幀中發送
  • 以太網首部（14字節）加4字節的CRC和1500字節的MTU，最大幀長1518，最小幀長爲64，最小有效載荷46字節
    • 以太網目的地址（6字節）
    • 以太網源地址（6字節）
    • 幀類型（2）字節：即協議類型
    • CRC（4字節）在有效載荷後面
  • ARP請求/應答（28字節）
    • 硬件類型（2字節）：以太網
    • 協議類型（2字節）：IP協議
    • 硬件地址長度（1字節）
    • 協議地址長度（1字節）
    • op（1字節）：請求/應答
    • 發送端以太網地址（6字節）
    • 發送端IP地址（4字節）
    • 目的以太網地址（6字節）
    • 目的IP地址（4字節）
  • 填充位（18字節）：以太網規定最小數據長度爲46字節

如果相應表項尚未存在ARP表中？ 1. 查詢節點構造ARP查詢分組，包含有查詢節點和目的節點的IP地址，適配器在鏈路層幀中封裝這個ARP分組，廣播幀 2. 子網中的所有其他適配器接收到幀，將幀中的ARP分組向上傳遞給ARP模塊，每個節點檢查自身IP是否與ARP查詢分組中的目的IP地址相同，相同的返回一個ARP響應分組3. 查詢節點接收到ARP分組，獲得目的MAC地址，並更新自身的ARP表。

如何發送數據報到子網以外？

假設主機1要向主機2發送數據報，應該使用什麼MAC地址？如果使用49-BD-D2-C7-56-2A作爲目的MAC地址，由於子網內任何一個適配器的MAC地址都不匹配，所以這個數據報將會死亡。正確的步驟如下：

1.主機1通過ARP獲取路由器接口111.111.111.110的MAC地址，將數據報封裝成幀，轉發

2.路由器的接口111.111.111.110收到幀，由於MAC地址匹配，適配器獲取幀中的數據報上傳給網絡層

3.路由器通過查找轉發表將數據報通過交換結構轉發到輸出接口222.222.222.220

4.輸出接口222.222.222.220通過ARP獲取子網中主機2的MAC地址

5.獲得主機2的MAC地址後，將數據報傳遞給適配器，封裝成幀，最終發送到主機2

5.4以太網

雖然20世紀80年代和90年代早期，以太網面臨着其他LAN技術包括令牌環、FDDI、ATM的挑戰，但是至今，以太網仍是最流行的有線局域網技術。

所有的以太網技術都向網絡層提供無連接服務、不可靠服務。

5.4.1 以太網幀結構

• 前同步碼：8字節。以太網幀以一個8字節的前同步碼字段開始。前7個字節的值都是10101010，最後一個字節是10101011。前7個字節用於“喚醒”接收適配器，並且將其時鐘與發送方的時鐘同步，第8個字節的最後兩個1告訴接收適配器，“重要的內容”就要來了，因此接收適配器知道接下來的6個字節是目的地址

• 類型：網絡層協議類型

• 數據：46~1500字節。承載了IP數據報，以太網的最大傳輸單元(MTU)是1500字節，IP數據報最小46字節，如果不夠會填充（如果填充，在目的端填充也會上傳到網絡層，通過數據報首部的長度字段去除填充）

• 循環冗餘檢測**(CRC)**：提供差錯檢測與糾正，具體見1.1。如果校驗成果，並不會發送肯定確認。如果校驗失敗，也不會發生否定確認，只是丟棄該幀

頭信息有14字節，尾部校驗和FCS佔4字節。因此，一個標準的以太網數據幀大小是1518。

5.4.2 鏈路層交換機

現代以太網LAN使用了一種星型拓撲，每個節點與中心交換機相連

• 交換機的任務是接收入鏈路層幀並將它們轉發到出鏈路

• 交換機自身對節點透明：某節點向另一節點尋址一個幀，順利地將該幀發送進LAN，而不知道這個幀經過了某個交換機的接收與轉發

交換機具有如下性質：

• 消除碰撞：交換機緩存幀並且絕不會在網段上同時傳輸多於一個幀。交換機的最大聚合帶寬是所有接口速率之和

• 異質的鏈路：交換機將鏈路彼此隔離，LAN中的不同鏈路能夠以不同的速率運行，並且能夠在不同的媒體上運行

1）交換機轉發與過濾

• 過濾：交換機決定一個幀是應該轉發還是應該丟棄

• 轉發：決定一個幀應該被導向哪個接口

過濾和轉發都藉助於交換機表：

假設具有目的地址DD-DD-DD-DD-DD-DD的幀從交換機的x接口到達：

• 如果表中沒有針對DD-DD-DD-DD-DD-DD的表項，則向除了x的其它所有接口廣播幀

• 如果表中有針對DD-DD-DD-DD-DD-DD的表項

  • 1）接口等於x：(說明幀的目的地和幀處於同一子網，意味着該幀已經在包含目的地址的LAN網段廣播過了)該幀執行過濾功能
  • 2）接口爲y，不等於x：將幀轉發到接口y的輸出緩存區

2）自學習(即插即用)

交換機表是自動、動態、自治地建立的，沒有來自網絡管理員或配置協議的任何干預。換句話說，交換機是自學習的

1.交換機表初始爲空

2.源地址爲DD-DD-DD-DD-DD-DD的幀從接口x到達時，1）如果不存在則新建一項；2）存在則更新當前時間

3.如果一段時間後，在x接口沒有來自DD-DD-DD-DD-DD-DD的幀，則將該表項刪除

3）交換機與路由器對比

• 交換機

  • 優點

    • 即插即用
    • 相對高的分組過濾、轉發速率

  • 缺點

    • 交換網絡的活躍拓撲限制爲一棵生成樹（爲了防止廣播幀的循環）
    • 對廣播風暴不提供任何保護措施（如果某主機故障，沒完沒了傳輸廣播幀流，交換機會轉發所有這些幀，使得整個以太網崩潰）

• 路由器

  • 優點

    • 分組不會被限制在一棵生成樹上，從而能用各種拓撲結構來構建因特網
    • 對廣播風暴提供了防火牆保護

  • 缺點

    • 不是即插即用（需要人爲配置IP地址）
    • 對分組的處理時間更長（必須處理高達第3層的字段）

通常，由幾百臺主機組成的小網絡通常有幾個LAN網段，對於這些小網絡，交換機就足夠了，因爲它們不要求IP地址的任何配置就能使流量局部化並增加總吞吐量。但是在由幾千臺主機組成的更大網絡中，通常在網絡中還包括路由器。路由器提供了更健壯的流量隔離方式和對廣播風暴的控制，並在網絡的主機之間使用更“智能的”路由

【QA】

1.爲什麼運輸層使用檢驗和而鏈路層使用CRC呢？

• 運輸層差錯檢驗用軟件實現，採用簡單快速的檢驗和的方式。
• 鏈路層的差錯檢測在適配器中採用專用硬件實現。

2.爲什麼網絡層和鏈路層都需要地址？

• 保持各層的獨立，局域網是爲任意網絡層協議而設計的，不只用於IP和因特網。
• 如果適配器使用IP地址，則適配器不能方便的支持其他網絡層協議，且IP地址必須存儲在適配器的RAM中。
• 如果適配器中不適用任何地址，則主機將被局域網上發送的每個幀中斷。
• 如果網絡層使用MAC地址，無法構建高效的路由選擇方案，增加一個附加層的地址尋址，可以使得設備更易於移動和維修

6.物理層

• 傳輸數據的單位 ———— 比特
• 數據傳輸系統：源系統（源點、發送器） --> 傳輸系統 --> 目的系統（接收器、終點）

通道：

• 單向通道（單工通道）：只有一個方向通信，沒有反方向交互，如廣播
• 雙向交替通行（半雙工通信）：通信雙方都可發消息，但不能同時發送或接收
• 雙向同時通信（全雙工通信）：通信雙方可以同時發送和接收信息

通道複用技術：

• 頻分複用（FDM，Frequency Division Multiplexing）：不同用戶在不同頻帶，所用用戶在同樣時間佔用不同帶寬資源
• 時分複用（TDM，Time Division Multiplexing）：不同用戶在同一時間段的不同時間片，所有用戶在不同時間佔用同樣的頻帶寬度
• 波分複用（WDM，Wavelength Division Multiplexing）：光的頻分複用
• 碼分複用（CDM，Code Division Multiplexing）：不同用戶使用不同的碼，可以在同樣時間使用同樣頻帶通信

7.網絡錯誤排查

• 聯繫ping等檢查網絡是否通暢來考察你對問題的追溯程度，比如網絡通，但是拿不到服務器上的資源，怎麼辦，防火牆封閉了端口？如果端口也開了呢，怎麼辦，dns解析有問題？怎麼弄？
• tcpdump抓到的包如何分析？
  • 寫入到.pcap文件中，使用wireshark或packetyzer查看分析
• 在你們的運維平臺上刷新了一條資源如何檢測這條資源有沒有刷新成功？
• 網易雲音樂的評論無法加載，如何排查？說出思路，各業務模塊監控指標QPS均無抖降點，但是問題依舊存在，爲什麼？
• 如何在linux上添加路由？我添加了一條路由之後還是ping不通，可能的原因有哪些？
  • 出不去：網關不通，出去的路被防火牆檔了
  • 回不來：被丟棄，回來的報被擋了

8.Socket網絡編程

• 有哪些系統調用？
  • Server：socket、bind、listen、accept、read、write、read、…、close
  • Client： socket、connect、write、read、write、…、close
  • 建立連接的過程
    • 服務器調用socket()、bind()、listen()函數完成初始化後，調用accept()阻塞等待。
    • 客戶端調用socket()初始化後，調用connect()發出SYN段並阻塞等待服務器應答。
    • 服務器應答一個SYN-ACK段，客戶端收到後從connect()返回，同時應答一個ACK段，服務器收到後從accept()返回，TCP鏈路建立。
  • 數據傳輸的過程
    • 服務器從accept()返回後立即調用read()，讀socket就像讀管道一樣，如果沒有數據到達就阻塞等待。
    • 這時客戶端調用write()發送請求給服務器，
    • 服務器收到後從read()返回，對客戶端的請求進行處理，在此期間客戶端調用read()阻塞等待服務器的應答。
    • 服務器調用write()將處理結果發回給客戶端，再次調用read()阻塞等待下一條請求，
    • 客戶端收到後從read()返回，發送下一條請求，如此循環下去。
  • 關閉連接的過程
    • 如果客戶端沒有更多請求了，就調用close()關閉連接，就像寫端關閉的管道一樣，服務器的read()返回0。
    • 這樣服務器就知道客戶端關閉了連接，也調用close()關閉連接。
    • 注意，任何一方調用close()後，連接的兩個傳輸方向都關閉，不能再發送數據了。如果一方調用shutdown()則連接處於半關閉狀態，仍可接收對方發來的數據。
• close是一次就能直接關閉嗎？
  • 半關閉狀態shut_down

Socket 中的 read()、write() 函數

ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);

read()

• read 函數是負責從 fd 中讀取內容。
• 當讀成功時，read 返回實際所讀的字節數。
• 如果返回的值是 0 表示已經讀到文件的結束了，小於 0 表示出現了錯誤。
• 如果錯誤爲 EINTR 說明讀是由中斷引起的；如果是 ECONNREST 表示網絡連接出了問題。

write()

• write 函數將 buf 中的 nbytes 字節內容寫入文件描述符 fd。
• 成功時返回寫的字節數。失敗時返回 -1，並設置 errno 變量。
• 在網絡程序中，當我們向套接字文件描述符寫時有倆種可能。
• （1）write 的返回值大於 0，表示寫了部分或者是全部的數據。
• （2）返回的值小於 0，此時出現了錯誤。
• 如果錯誤爲 EINTR 表示在寫的時候出現了中斷錯誤；如果爲 EPIPE 表示網絡連接出現了問題（對方已經關閉了連接）。

Socket 中 TCP 的三次握手建立連接

我們知道 TCP 建立連接要進行 “三次握手”，即交換三個分組。大致流程如下：

1. 客戶端向服務器發送一個 SYN J
2. 服務器向客戶端響應一個 SYN K，並對 SYN J 進行確認 ACK J+1
3. 客戶端再想服務器發一個確認 ACK K+1

只有就完了三次握手，但是這個三次握手發生在 Socket 的那幾個函數中呢？請看下圖：

從圖中可以看出：

1. 當客戶端調用 connect 時，觸發了連接請求，向服務器發送了 SYN J 包，這時 connect 進入阻塞狀態；
2. 服務器監聽到連接請求，即收到 SYN J 包，調用 accept 函數接收請求向客戶端發送 SYN K ，ACK J+1，這時 accept 進入阻塞狀態；
3. 客戶端收到服務器的 SYN K ，ACK J+1 之後，這時 connect 返回，並對 SYN K 進行確認；
4. 服務器收到 ACK K+1 時，accept 返回，至此三次握手完畢，連接建立。

Socket 中 TCP 的四次握手釋放連接

上面介紹了 socket 中 TCP 的三次握手建立過程，及其涉及的 socket 函數。現在我們介紹 socket 中的四次握手釋放連接的過程，請看下圖：

圖示過程如下：

1. 某個應用進程首先調用 close 主動關閉連接，這時 TCP 發送一個 FIN M；
2. 另一端接收到 FIN M 之後，執行被動關閉，對這個 FIN 進行確認。它的接收也作爲文件結束符傳遞給應用進程，因爲 FIN 的接收意味着應用進程在相應的連接上再也接收不到額外數據；
3. 一段時間之後，接收到文件結束符的應用進程調用 close 關閉它的 socket。這導致它的 TCP 也發送一個 FIN N；
4. 接收到這個 FIN 的源發送端 TCP 對它進行確認。

這樣每個方向上都有一個 FIN 和 ACK。