文章目錄
- Question1：介紹一下 OSI七層網絡體系結構（或TCP/IP四層網路體系結構或現代五層網絡體系結構）？
- Answer1：
- Question2：簡要闡述一下 TCP/IP 原理？
- Answer2：
- Question3：簡要闡述TCP 首部格式？
- Answer3：
- Question4：談一談 TCP三次握手和四次揮手？
- Answer4：
- Question5：談一談 HTTP 協議及其原理/傳輸過程？
- Answer5：
- Question6：談一談 HTTP 常用狀態及其含義？
- Answer6：
- Question7：談一談對 HTTPS 的認識？
- Answer7：
- Question8：談一談 CDN 原理？
- Answer8：
面向面試的博客，以問答式Q/A方式呈現。
Question1：介紹一下 OSI七層網絡體系結構（或TCP/IP四層網路體系結構或現代五層網絡體系結構）？
Answer1：
三種劃分方式都是可以的，如下圖所示：
以OSI 七層模型爲例，如圖：
- 物理層：主要定義物理設備標準，如網線的接口類型、光纖的接口類型、各種傳輸介質的傳輸速率等。它的主要作用是傳輸比特流（就是由 1、0 轉化爲電流強弱來進行傳輸,到達目的地後在轉化爲1、0，也就是我們常說的模數轉換與數模轉換）。這一層的數據叫做比特。
- 數據鏈路層：主要將從物理層接收的數據進行 MAC 地址（網卡的地址）的封裝與解封裝。常把這一層的數據叫做幀。在這一層工作的設備是交換機，數據通過交換機來傳輸。
- 網絡層：主要將從下層接收到的數據進行 IP 地址（例 192.168.0.1)的封裝與解封裝。在這一層工作的設備是路由器，常把這一層的數據叫做數據包。
- 傳輸層：定義了一些傳輸數據的協議和端口號（WWW 端口 80 等），如：TCP（傳輸控制協議，傳輸效率低，可靠性強，用於傳輸可靠性要求高，數據量大的數據），UDP（用戶數據報協議，與 TCP 特性恰恰相反，用於傳輸可靠性要求不高，數據量小的數據，如 QQ 聊天數據就是通過這種方式傳輸的）。 主要是將從下層接收的數據進行分段進行傳輸，到達目的地址後在進行重組。常常把這一層數據叫做段。
- 會話層：通過傳輸層（端口號：傳輸端口與接收端口）建立數據傳輸的通路。主要你的系統之間發起會話或或者接受會話請求（設備之間需要互相認識可以是 IP 也可以是 MAC 或者是主機名）。
- 表示層：主要是進行對接收的數據進行解釋、加密與解密、壓縮與解壓縮等（也就是把計算機能夠識別的東西轉換成人能夠能識別的東西（如圖片、聲音等））。
- 應用層 主要是一些終端的應用，比如說FTP（各種文件下載），WEB（IE瀏覽），QQ之類的（你就把它理解成我們在電腦屏幕上可以看到的東西．就 是終端應用）。
Question2：簡要闡述一下 TCP/IP 原理？
Answer2：
TCP/IP 協議不是 TCP 和 IP 這兩個協議的合稱，而是指因特網整個 TCP/IP 協議族。從協議分層:模型方面來講，TCP/IP 由四個層次組成：網絡接口層、網絡層、傳輸層、應用層。
網絡訪問層(Network Access Layer)
網絡訪問層(Network Access Layer)在 TCP/IP 參考模型中並沒有詳細描述，只是指出主機必須使用某種協議與網絡相連。
網絡層(Internet Layer)
網絡層(Internet Layer)是整個體系結構的關鍵部分，其功能是使主機可以把分組發往任何網絡，並使分組獨立地傳向目標。這些分組可能經由不同的網絡，到達的順序和發送的順序也可能不同。高層如果需要順序收發，那麼就必須自行處理對分組的排序。互聯網層使用因特網協議(IP，Internet Protocol)。
傳輸層(Tramsport Layer-TCP/UDP)
傳輸層(Tramsport Layer)使源端和目的端機器上的對等實體可以進行會話。在這一層定義了兩個端到端的協議：傳輸控制協議(TCP，Transmission Control Protocol)和用戶數據報協議(UDP，User Datagram Protocol)。TCP 是面向連接的協議，它提供可靠的報文傳輸和對上層應用的連接服務。爲此，除了基本的數據傳輸外，它還有可靠性保證、流量控制、多路複用、優先權和安全性控制等功能。UDP 是面向無連接的不可靠傳輸的協議，主要用於不需要 TCP 的排序和流量控制等功能的應用程序。
應用層(Application Layer)
應用層(Application Layer)包含所有的高層協議，包括：虛擬終端協議(TELNET，TELecommunications NETwork)、文件傳輸協議(FTP，File Transfer Protocol)、電子郵件傳輸協議(SMTP，Simple Mail Transfer Protocol)、域名服務(DNS，Domain Name Service)、網上新聞傳輸協議(NNTP，Net News Transfer Protocol)和超文本傳送協議(HTTP，HyperText Transfer Protocol)等。
Question3：簡要闡述TCP 首部格式？
Answer3：
TCP首部格式如下圖所示：
- 源端口號（ 16 位）：它（連同源主機 IP 地址）標識源主機的一個應用進程。
- 目的端口號（ 16 位）：它（連同目的主機 IP 地址）標識目的主機的一個應用進程。這兩個值加上 IP 報頭中的源主機 IP 地址和目的主機 IP 地址唯一確定一個 TCP 連接。
- 順序號 seq（ 32 位）：用來標識從 TCP 源端向 TCP 目的端發送的數據字節流，它表示在這個報文段中的第一個數據字節的順序號。如果將字節流看作在兩個應用程序間的單向流動，則TCP 用順序號對每個字節進行計數。序號是 32bit 的無符號數，序號到達 2 的 32 次方 － 1 後又從 0 開始。當建立一個新的連接時， SYN 標誌變 1 ，順序號字段包含由這個主機選擇的該連接的初始順序號 ISN （ Initial Sequence Number ）。
- 確認號 ack（ 32 位）：包含發送確認的一端所期望收到的下一個順序號。因此，確認序號應當是上次已成功收到數據字節順序號加 1 。只有 ACK 標誌爲 1 時確認序號字段纔有效。 TCP 爲應用層提供全雙工服務，這意味數據能在兩個方向上獨立地進行傳輸。因此，連接的每一端必須保持每個方向上的傳輸數據順序號。
- TCP 報頭長度（ 4 位）：給出報頭中 32bit 字的數目，它實際上指明數據從哪裏開始。需要這個值是因爲任選字段的長度是可變的。這個字段佔 4bit ，因此 TCP 最多有 60 字節的首部。然而，沒有任選字段，正常的長度是 20 字節。
- 保留位（ 6 位）：保留給將來使用，目前必須置爲 0 。
- 控制位（ control flags ， 6 位）：在 TCP 報頭中有 6 個標誌比特，它們中的多個可同時被設置爲 1 。依次爲：
（1）URG ：爲 1 表示緊急指針有效，爲 0 則忽略緊急指針值。
（2）ACK ：爲 1 表示確認號有效，爲 0 表示報文中不包含確認信息，忽略確認號字段。
（3） PSH ：爲 1 表示是帶有 PUSH 標誌的數據，指示接收方應該儘快將這個報文段交給應用層而不用等待緩衝區裝滿。
（4）RST ：用於復位由於主機崩潰或其他原因而出現錯誤的連接。它還可以用於拒絕非法的報文段和拒絕連接請求。一般情況下，如果收到一個 RST 爲 1 的報文，那麼一定發生了某些問題。
（5）SYN ：同步序號，爲 1 表示連接請求，用於建立連接和使順序號同步（synchronize ）。
（6）FIN ：用於釋放連接，爲 1 表示發送方已經沒有數據發送了，即關閉本方數據流。 - 窗口大小（ 16 位）：數據字節數，表示從確認號開始，本報文的源方可以接收的字節數，即源方接收窗口大小。窗口大小是一個 16bit 字段，因而窗口大小最大爲 65535 字節。
- 校驗和（ 16 位）：此校驗和是對整個的 TCP 報文段，包括 TCP 頭部和 TCP 數據，以 16 位字進行計算所得。這是一個強制性的字段，一定是由發送端計算和存儲，並由接收端進行驗證。
- 緊急指針（ 16 位）：只有當 URG 標誌置 1 時緊急指針纔有效。TCP 的緊急方式是發送端向另一端發送緊急數據的一種方式。
- 選項：最常見的可選字段是最長報文大小，又稱爲 MSS(Maximum Segment Size) 。每個連接方通常都在通信的第一個報文段（爲建立連接而設置 SYN 標誌的那個段）中指明這個選項，它指明本端所能接收的最大長度的報文段。選項長度不一定是 32 位字的整數倍，所以要加填充位，使得報頭長度成爲整字數。
- 數據： TCP 報文段中的數據部分是可選的。在一個連接建立和一個連接終止時，雙方交換的報文段僅有 TCP 首部。如果一方沒有數據要發送，也使用沒有任何數據的首部來確認收到的數據。在處理超時的許多情況中，也會發送不帶任何數據的報文段。
Question4：談一談 TCP三次握手和四次揮手？
Answer4：
TCP 在傳輸之前會進行三次溝通，一般稱爲“三次握手”，傳完數據斷開的時候要進行四次溝通，一般稱爲“四次揮手”。
三次握手
三次握手過程如下所示：
第一次握手：主機 A 發送位碼爲 syn＝1,隨機產生 seq number=1234567 的數據包到服務器，主機 B由 SYN=1 知道，A 要求建立聯機；
第二次握手：主機 B 收到請求後要確認聯機 信息，向 A 發 送 ack number=( 主機 A 的
seq+1),syn=1,ack=1,隨機產生 seq=7654321 的包
第三次握手：主機 A 收到後檢查 ack number 是否正確，即第一次發送的 seq number+1,以及位碼ack 是否爲 1，若正確，主機 A 會再發送 ack number=(主機 B 的 seq+1),ack=1，主機 B 收到後確認seq 值與 ack=1 則連接建立成功。
四次揮手
TCP 建立連接要進行三次握手，而斷開連接要進行四次。這是由於 TCP 的半關閉造成的。因爲 TCP 連接是全雙工的(即數據可在兩個方向上同時傳遞)所以進行關閉時每個方向上都要單獨進行關閉。這個單方向的關閉就叫半關閉。當一方完成它的數據發送任務，就發送一個 FIN 來向另一方通告將要終止這個方向的連接。
四次揮手過程如下所示：
1） 關閉客戶端到服務器的連接：首先客戶端 A 發送一個 FIN，用來關閉客戶到服務器的數據傳送，然後等待服務器的確認。其中終止標誌位 FIN=1，序列號 seq=u。
2） 服務器收到這個 FIN，它發回一個 ACK，確認號 ack 爲收到的序號加 1。
3） 關閉服務器到客戶端的連接：也是發送一個 FIN 給客戶端。
4） 客戶段收到 FIN 後，併發回一個 ACK 報文確認，並將確認序號 seq 設置爲收到序號加 1。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
注意：主機 A 發送 FIN 後，進入終止等待狀態， 服務器 B 收到主機 A 連接釋放報文段後，就立即給主機 A 發送確認，然後服務器 B 就進入 close-wait 狀態，此時 TCP 服務器進程就通知高層應用進程，因而從 A 到 B 的連接就釋放了。此時是“半關閉”狀態。即 A 不可以發送給B，但是 B 可以發送給 A。此時，若 B 沒有數據報要發送給 A 了，其應用進程就通知 TCP 釋放連接，然後發送給 A 連接釋放報文段，並等待確認。A 發送確認後，進入 time-wait，注意，此時 TCP 連接還沒有釋放掉，然後經過時間等待計時器設置的 2MSL 後，A 才進入到close 狀態。
Question5：談一談 HTTP 協議及其原理/傳輸過程？
Answer5：
HTTP是一個無狀態的協議。無狀態是指客戶機（Web瀏覽器）和服務器之間不需要建立持久的連接，:這意味着當一個客戶端向服務器端發出請求，然後服務器返回響應(response)，連接就被關閉了，在服務器端不保留連接的有關信息.HTTP 遵循請求(Request)/應答(Response)模型。客戶機（瀏覽器）向服務器發送請求，服務器處理請求並返回適當的應答。所有 HTTP 連接都被構造成一套請求和應答。
1 ：地址解析
如用客戶端瀏覽器請求這個頁面：http://localhost.com:8080/index.htm 從中分解出協議名、主機名、端口、對象路徑等部分，對於我們的這個地址，解析得到的結果如下：
協議名：http
主機名：localhost.com
端口：8080
對象路徑：/index.htm
在這一步，需要域名系統 DNS 解析域名 localhost.com,得主機的 IP 地址。
2 ： 封裝 HTTP 請求數據包
把以上部分結合本機自己的信息，封裝成一個 HTTP 請求數據包。
3 ： 封裝成 TCP 包並建立連接
封裝成 TCP 包，建立 TCP 連接（TCP 的三次握手）。
4 ： 客戶機發送請求命
客戶機發送請求命令：建立連接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是 MIME 信息包括請求修飾符、客戶機信息和可內容。
5 ： 服務器響應
服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是 MIME 信息包括服務器信息、實體信息和可能的內容。
6 ： 服務器關閉 TCP 連接
服務器關閉 TCP 連接：一般情況下，一旦 Web 服務器向瀏覽器發送了請求數據，它就要關閉 TCP 連接，然後如果瀏覽器或者服務器在其頭信息加入了這行代碼Connection:keep-alive，TCP 連接在發送後將仍然保持打開狀態，於是，瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了爲每個請求建立新連接所需的時間，還節約了網絡帶寬。
Question6：談一談 HTTP 常用狀態及其含義？
Answer6：
消息響應類型
| 狀態碼 | 明細 |
|---|---|
| 100 | Continue(繼續) |
| 101 | Switching Protocol(切換協議) |
成功響應類型
| 狀態碼 | 明細 |
|---|---|
| 200 OK(成功) | |
| 201 | Created(已創建) |
| 202 | Accepted(已創建) |
| 203 | Non-Authoritative Information(未授權信息) |
| 204 | No Content(無內容) |
| 205 | Reset Content(重置內容) |
| 206 | Partial Content(部分內容) |
重定向類型
| 狀態碼 | 明細 |
|---|---|
| 300 | Multiple Choice(多種選擇) |
| 301 | Moved Permanently(永久移動) |
| 302 | Found(臨時移動) |
| 303 | See Other(查看其他位置) |
| 304 | Not Modified(未修改) |
| 305 | Use Proxy(使用代理) |
| 306 | unused (未使用) |
| 307 | Temporary Redirect(臨時重定向) |
| 308 | Permanent Redirect(永久重定向) |
客戶端錯誤類型
| 狀態碼 | 明細 |
|---|---|
| 400 | Bad Request(錯誤請求) |
| 401 | Unauthorized(未授權) |
| 402 | Payment Required(需要付款) |
| 403 | Forbidden(禁止訪問) |
| 404 | Not Found(未找到) |
| 405 | Method Not Allowed(不允許使用該方法) |
| 406 | Not Acceptable(無法接受) |
| 407 | Proxy Authentication Required(要求代理身份驗證) |
| 408 | Request Timeout(請求超時) |
| 409 | Conflict(衝突) |
| 410 | Gone(已失效) |
| 411 | Length Required(需要內容長度頭) |
| 412 | Precondition Failed(預處理失敗) |
| 413 | Request Entity Too Large(請求實體過長) |
| 414 | Request-URI Too Long(請求網址過長) |
| 415 | Unsupported Media Type(媒體類型不支持) |
| 416 | Requested Range Not Satisfiable(請求範圍不合要求) |
| 417 | Expectation Failed(預期結果失敗) |
服務器端錯誤類型
| 狀態碼 | 明細 |
|---|---|
| 500 | Internal Server Error(內部服務器錯誤) |
| 501 | Implemented(未實現) |
| 502 | Bad Gateway(網關錯誤) |
| 503 | Service Unavailable(服務不可用) |
| 504 | Gateway Timeout (網關超時) |
| 505 | HTTP Version Not Supported(HTTP 版本不受支持) |
Question7：談一談對 HTTPS 的認識？
Answer7：
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全爲目標的:HTTP 通道，簡單講是 HTTP 的安全版。即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL。其所用的端口號是 443。 過程大致如下：
步驟一：建立連接獲取證書
SSL 客戶端通過 TCP 和服務器建立連接之後（443 端口），並且在一般的 tcp 連接協商（握手）過程中請求證書。即客戶端發出一個消息給服務器，這個消息裏面包含了自己可實現的算法列表和其它一些需要的消息，SSL 的服務器端會迴應一個數據包，這裏面確定了這次通信所需要的算法，然後服務器向客戶端返回證書。（證書裏面包含了服務器信息：域名。申請證書的公司，公共祕鑰）。
步驟二：證書驗證
Client 在收到服務器返回的證書後，判斷簽發這個證書的公共簽發機構，並使用這個機構的公共祕鑰確認簽名是否有效，客戶端還會確保證書中列出的域名就是它正在連接的域名。
步驟三：數據加密和傳輸
如果確認證書有效，那麼生成對稱祕鑰並使用服務器的公共祕鑰進行加密。然後發送給服務器，服務器使用它的私鑰對它進行解密，這樣兩臺計算機可以開始進行對稱加密進行通信。
Question8：談一談 CDN 原理？
Answer8：
CND 一般包含分發服務系統、負載均衡系統和管理系統。
1、分發服務系統
其基本的工作單元就是各個 Cache 服務器。負責直接響應用戶請求，將內容快速分發到用戶；同時還負責內容更新，保證和源站內容的同步。
根據內容類型和服務種類的不同，分發服務系統分爲多個子服務系統，如：網頁加速服務、流媒體加速服務、應用加速服務等。每個子服務系統都是一個分佈式的服務集羣，由功能類似、地域接近的分佈部署的 Cache 集羣組成。
在承擔內容同步、更新和響應用戶請求之外，分發服務系統還需要向上層的管理調度系統反饋各個Cache 設備的健康狀況、響應情況、內容緩存狀況等，以便管理調度系統能夠根據設定的策略決定由哪個 Cache 設備來響應用戶的請求。
2、負載均衡系統
負載均衡系統是整個 CDN 系統的中樞。負責對所有的用戶請求進行調度，確定提供給用戶的最終訪問地址。
使用分級實現。最基本的兩極調度體系包括全局負載均衡（GSLB）和本地負載均衡（SLB）。
GSLB 根據用戶地址和用戶請求的內容，主要根據就近性原則，確定向用戶服務的節點。一般通過 DNS解析或者應用層重定向（Http 3XX 重定向）的方式實現。
SLB 主要負責節點內部的負載均衡。當用戶請求從 GSLB 調度到 SLB 時，SLB 會根據節點內各個Cache 設備的工作狀況和內容分佈情況等對用戶請求重定向。SLB 的實現有四層調度（LVS）、七層調度（Nginx）和鏈路負載調度等。
3、管理系統
分爲運營管理和網絡管理子系統。
網絡管理系統實現對 CDN 系統的設備管理、拓撲管理、鏈路監控和故障管理，爲管理員提供對全網資源的可視化的集中管理，通常用 web 方式實現。
運營管理是對 CDN 系統的業務管理，負責處理業務層面的與外界系統交互所必須的一些收集、整理、交付工作。包括用戶管理、產品管理、計費管理、統計分析等。
