NetWork
本文鑑於個人蒐集資料文章總結所得，若有錯誤請儘快聯繫我！
文章目錄
計算機網絡體系結構, 可以分爲四層也可以是7層：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-7ClwAUQh-1590151948375)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/1005dc9d-9049-4b06-9524-6171e56ebd8c.png)]
-
應用層
爲特定應用程序提供數據傳輸服務，例如 HTTP、DNS 等。數據單位爲報文。
-
運輸層
提供的是進程間的通用數據傳輸服務。由於應用層協議很多，定義通用的運輸層協議就可以支持不斷增多的應用層協議。運輸層包括兩種協議：傳輸控制協議 TCP，提供面向連接、可靠的數據傳輸服務，數據單位爲報文段；用戶數據報協議 UDP，提供無連接、盡最大努力的數據傳輸服務，數據單位爲用戶數據報。TCP 主要提供完整性服務，UDP 主要提供及時性服務。
-
網絡層
爲主機之間提供服務，而不是像運輸層協議那樣是爲主機中的進程提供服務。網絡層把運輸層傳遞下來的報文段或者用戶數據報封裝成分組來進行傳輸。
-
數據鏈路層
網絡層針對的還是主機之間，而主機之間可以有很多鏈路，鏈路層協議就是爲相鄰結點之間提供服務。數據鏈路層把網絡層傳來的分組封裝成幀。
-
物理層
考慮的是怎樣在傳輸媒體上傳輸數據比特流，而不是指具體的傳輸媒體。物理層的作用是儘可能屏蔽傳輸媒體和通信手段的差異，使物理層上的數據鏈路層感覺不到這些差異。
IP（網絡層）
用於報文交換網絡的一種面向數據的協議，是TCP/IP協議中網絡層的主要協議；
主要根據源主機和目的主機的地址傳送數據；有IPv4和IPv6；
-
網絡層的結構
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-q9NBZQEe-1590151948377)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/163cf8b4-5f30-46c9-af00-316a71b3c890.jpg)]
- 地址解析協議 ARP（Address Resolution Protocol）
- 網際控制報文協議 ICMP（Internet Control Message Protocol）
- 網際組管理協議 IGMP（Internet Group Management Protocol）
-
IP數據報格式
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-LVlVfU0u-1590151948379)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/8681db55-0873-434b-aa98-83d07e8392ae.jpg)]
-
版本 : 有 4（IPv4）和 6（IPv6）兩個值；
-
首部長度 : 佔 4 位，因此最大值爲 15。值爲 1 表示的是 1 個 32 位字的長度，也就是 4 字節。因爲首部固定長度爲 20 字節，因此該值最小爲 5。如果可選部分的長度不是 4 字節的整數倍，就用尾部的填充部分來填充。
-
區分服務 : 用來獲得更好的服務，一般情況下不使用。
-
總長度 : 包括首部長度和數據部分長度。
-
標識 : 在數據報長度過長從而發生分片的情況下，相同數據報的不同分片具有相同的標識符。
-
片偏移 : 和標識符一起，用於發生分片的情況。片偏移的單位爲 8 字節。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-VbalX1am-1590151948380)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/45c86855-9b18-4cf4-a9a7-f8b6eb78d133.png)] -
生存時間 ：TTL，它的存在是爲了防止無法交付的數據報在互聯網中不斷兜圈子。以路由器跳數爲單位，當 TTL 爲 0 時就丟棄數據報。
-
協議 ：指出攜帶的數據應該上交給哪個協議進行處理，例如 ICMP、TCP、UDP 等。
-
首部檢驗和 ：因爲數據報每經過一個路由器，都要重新計算檢驗和，因此檢驗和不包含數據部分可以減少計算的工作量。
-
-
IP地址
- A：前8位網絡號，後24位主機號，以0開頭
- B：前16位網絡號，後16位主機號，以10開頭
- C：前24位網絡號，後8位主機號，以110開頭
- D：多播地址，1110開頭
- E：保留地址，1111開頭
- 全是0的主機號代表網絡本身
- 全是1的主機號代表廣播，用於向該網絡中所有主機發送消息；
- 以十進制127開頭的地址是環回地址，目的地址是環回地址的
-
ARP
把IP地址映射位物理地址；反之爲RARP；
-
子網掩碼
32位地址，1表示網絡位，0表示主機位；指明一個IP地址的哪些位標識的是主機所在的子網以及哪些位標識是主機的位掩碼，必須和IP地址結合使用；
作用：將某個Ip地址分成網絡地址和主機地址；
TCP/IP（運輸層）
-
什麼是TCP/IP
TCP/IP是一類協議系統，用於網絡通信的一套協議集合;
現在的 TCP/IP 體系結構不嚴格遵循 OSI 分層概念，應用層可能會直接使用 IP 層或者網絡接口層。
-
TCP
運輸層: 運輸層提供了應用進程間的邏輯通信。運輸層向高層用戶屏蔽了下面網絡層的核心細節，使應用程序看見的好像在兩個運輸層實體之間有一條端到端的邏輯通信信道。
TCP: 是面向連接的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通信，面向字節流（把應用層傳下來的報文看成字節流，把字節流組織成大小不等的數據塊）
意義：應用層之間需要可靠的像管道一樣的連接，網絡層不提供，只提供不可靠的包交換，因此需要運輸層的協調；
-
首部格式:
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-KPVfiipE-1590151948381)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/21a00b02-c0a6-4bcd-9af0-5ec6bb66e34c.jpg)]
-
seq序號 ：用於對字節流進行編號，例如序號爲 301，表示第一個字節的編號爲 301，如果攜帶的數據長度爲 100 字節，那麼下一個報文段的序號應爲 401。
-
ack確認號 ：期望收到的下一個報文段的序號。例如 B 正確收到 A 發送來的一個報文段，序號爲 501，攜帶的數據長度爲 200 字節，因此 B 期望下一個報文段的序號爲 701，B 發送給 A 的確認報文段中確認號就爲 701。
-
數據偏移 ：指的是數據部分距離報文段起始處的偏移量，實際上指的是首部的長度。
-
確認 ACK ：當 ACK=1 時確認號字段有效，否則無效。TCP 規定，在連接建立後所有傳送的報文段都必須把 ACK 置 1。
-
同步 SYN ：在連接建立時用來同步序號。當 SYN=1，ACK=0 時表示這是一個連接請求報文段。若對方同意建立連接，則響應報文中 SYN=1，ACK=1。
-
終止 FIN ：用來釋放一個連接，當 FIN=1 時，表示此報文段的發送方的數據已發送完畢，並要求釋放運輸連接。
-
窗口 ：窗口值作爲接收方讓發送方設置其發送窗口的依據。之所以要有這個限制，是因爲接收方的數據緩存空間是有限的。
-
-
作用：
- 將應用層向傳輸層發送網間傳輸的、8位字節表示的數據流分成適當長度的報文段，收鏈路層最大傳輸單元MTU限制；
- 傳包給網絡層，TCP爲了不丟包，每個包一個序號，保證了傳送到接收端實體的包能按序接受，然後接受實體收到包後返回相應的ACK確認
- 如果發送端實體再合理的RTT（往返時延)沒收到確認，那麼對應的數據包就被認爲丟失，將重傳
- TCP用一個校驗和（Checksum）函數來檢驗數據是否錯誤，發送和接受都需要計算這個
-
三次握手
seq數據包本身序列號；ack期望繼續發送數據包序列號
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-d62KyWVK-1590151948382)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/086871db-5871-460f-97b7-126cd738bb0e.jpg)]
-
TIME_WAIT
客戶端接收到服務器端的 FIN 報文後進入此狀態，此時並不是直接進入 CLOSED 狀態，還需要等待一個時間計時器設置的時間。這麼做有兩個理由：
確保最後一個確認報文段能夠到達。如果 B 沒收到 A 發送來的確認報文段，那麼就會重新發送連接釋放請求報文段，A 等待一段時間就是爲了處理這種情況的發生。
可能存在“已失效的連接請求報文段”，爲了防止這種報文段出現在本次連接之外，需要等待一段時間。
-
-
TCP滑動窗口
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-6sfykgQ7-1590151948383)(https://github.com/CyC2018/Interview-Notebook/raw/66d63de8b875ff9be79763fb9bbed93f183403cb/pics/223fc26e-2fd6-484c-bcb7-443cac134f15.jpg)]
窗口是緩存的一部分，用來暫時存放字節流。發送方和接收方各有一個窗口，接收方通過 TCP 報文段中的窗口字段告訴發送方自己的窗口大小，發送方根據這個值和其它信息設置自己的窗口大小。 -
慢啓動和擁塞避免
所以需要設置一個慢開始門限ssthresh狀態變量:
-
當cwnd < ssthresh, 使用慢啓動算法
-
當cwnd > ssthresh, 使用擁塞避免算法, 停用慢啓動算法
-
慢啓動思路
開始發送方先設置cwnd(擁塞窗口)=1, 發送第一個報文段M1, 接收到接收方的確認後, 把cwnd 加倍(2), 接着一直重複下去
-
擁塞避免
爲了防止cwnd增加過快而導致網絡擁塞, 每經過一個RTT事件就把發送方的cwnd+1, 這裏不是加倍;
-
擁塞控制
當發送方判斷網絡出現擁塞(沒收到確認), 就把門限ssthresh設置爲出現擁塞時的擁塞窗口值的一半(除以2), 再把cwnd設爲1, 重新開始慢啓動算法(目的是較少發送到網絡種的分組數, 使得積壓的分組被處理完畢)
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-uDtCnlzQ-1590151948384)(http://p2e1umi3v.bkt.clouddn.com/18-3-9/81168366.jpg)]
-
-
快重傳 和 快恢復
-
接收方每次接受到報文段都會對已收到的有序報文段確認, 例如已經接收到M1,M2,此時收到M4, 應當發送對M2的確認
-
發送方如果收到三個重複的確認, 那麼可以確認下一個報文段丟失, 例如收到三個M2, 那麼M3丟失, 此時啓動快重傳
只是丟失個別報文段的這種情況下, 一般不會網絡擁塞, 所以執行快恢復, 設ssthresh = cwnd/2 ,cwnd =ssthresh, 並且啓動擁塞避免;
-
-
-
UDP
是無連接的，盡最大可能交付，沒有擁塞控制，面向報文（對於應用程序傳下來的報文不合並也不拆分，只是添加 UDP 首部）。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-RNf9VgBr-1590151948384)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/bd6c05f3-02ee-4c8a-b374-40c87154a898.jpg)]
-
TCP和UDP的應用
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-8QUGhrBf-1590151948385)(http://p2e1umi3v.bkt.clouddn.com/18-3-9/50470979.jpg)]
HTTP和HTTPS（引用層）
-
HTTP
Hyper Text Transfer Protocal超文本傳輸協議；用於萬維網服務器傳輸超文本到本地瀏覽器的傳輸協議；基於TCP/IP的應用層協議
-
特點
- 簡單快速：請求方法有GET，POST,PUT等；
- 靈活：允許傳輸任意類型的數據對象，傳輸類型有content-type標記
- 無連接：限制每次連接只處理一個請求，服務器處理完用戶請求並受到客戶端的應答後，即斷開連接.但是在Http1.1的時候默認爲長連接
- 無狀態：服務器不會爲下一次連接而維護這次連接所傳輸的信息，沒有記憶性；
-
請求方式
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-SZo0mHLi-1590151948385)(http://p2e1umi3v.bkt.clouddn.com/18-3-9/67661190.jpg)]來源: 菜鳥教程 -
get和post的區別
- get能被緩存
- get請求回保存在瀏覽器的記錄中，也能保存爲書籤
- get有長度限制而post沒有
- get不安全，post安全
- get只當用於取回數據
- get不應再處理敏感數據時使用
- post參數不會保存再瀏覽器歷史或服務器日誌中
-
狀態碼（這個很少問）
- 1xx: 信息相應，接受到請求
- 2xx: 處理成功響應，被成功接受
- 3xx: 重定向響應，完成制定的動作，必須接受進一步
- 4xx: 客戶端錯誤，請求語法錯誤
- 5xx: 服務端錯誤，不能執行一個正確的請求
-
-
HTTPS
HTTPS以安全爲目標的HTTP通道，在HTTP加入SSL層，HTTPS的安全基礎就是SSL（Secure Sockets Layer），加密的詳細內容需要SSL；
兩種方式確保安全：建立信息安全通道；確認網站的真實性；
- 加密流程
- 客戶端使用https訪問URL, 與服務器建立SSL連接
- 服務器收到請求, 返回網站的證書信息(包含公鑰)
- 客戶端和服務端開始ssl連接的安全等級
- 根據雙方同意的安全等級, 建立會話密鑰, 利用網站的公鑰將會話密鑰加密, 傳送到服務器
- 服務器利用自己的私鑰解密出會話密鑰
- 服務器利用會話密鑰加密與客戶端的通信
-
客戶端的瀏覽器向服務器傳送客戶端SSL 協議的版本號，加密算法的種類，產生的隨機數，以及其他服務器和客戶端之間通訊所需要的各種信息。
-
服務器向客戶端傳送SSL 協議的版本號，加密算法的種類，隨機數以及其他相關信息，同時服務器還將向客戶端傳送自己的證書。
-
客戶利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過期，發行服務器證書的CA 是否可靠，發行者證書的公鑰能否正確解開服務器證書的“發行者的數字簽名”，服務器證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續進行第四步。
-
用戶端隨機產生一個用於後面通訊的“對稱密碼”，然後用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中獲得）對其加密，然後傳給服務器。
-
服務器用私鑰解密“對稱密碼”(此處的公鑰和私鑰是相互關聯的，公鑰加密的數據只能用私鑰解密，私鑰只在服務器端保留。然後用其作爲服務器和客戶端的“通話密碼”加解密通訊。同時在SSL 通訊過程中還要完成數據通訊的完整性，防止數據通訊中的任何變化。
-
客戶端向服務器端發出信息，指明後面的數據通訊將使用的步驟⑤中的主密碼爲對稱密鑰，同時通知服務器客戶端的握手過程結束。
-
服務器向客戶端發出信息，指明後面的數據通訊將使用的步驟⑤中的主密碼爲對稱密鑰，同時通知客戶端服務器端的握手過程結束。
-
SSL 的握手部分結束，SSL 安全通道的數據通訊開始，客戶和服務器開始使用相同的對稱密鑰進行數據通訊，同時進行通訊完整性的檢驗。
- 缺點
- 握手階段比較費時. 網頁加載時間延長
- 緩存不如http高效, 會增加數據開銷
- SSL證書需要錢
- SSL證書需要綁定IP, 不能在同一IP綁定多個域名
- 並非絕對安全, 有CA根證書和長我加密算法依舊可以進行中間人攻擊
-
HTTP和HTTPS的區別
- HTTP傳輸的數據是未加密的，HTTPS是加密的
- HTTP使用80端口，HTTPS使用443端口
- HTTPS需要CA，證書授權中心的授權證書
- HTTPs 並不是新協議，而是 HTTP 先和 SSL（Secure Socket Layer）通信，再由 SSL 和 TCP 通信。通過使用 SSL，HTTPs 提供了加密、認證和完整性保護。
-
Cookie
Http協議是無狀態的, 而Http/1.1引入了Cookie來保存狀態信息;
- Set-Cookie字段有以下屬性:
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-9Y2Qr8E4-1590151948386)(http://p2e1umi3v.bkt.clouddn.com/18-3-9/69897260.jpg)] - Session和Cookie的區別
Session 是服務器用來跟蹤用戶的一種手段，每個 Session 都有一個唯一標識：Session ID。當服務器創建了一個 Session 時，給客戶端發送的響應報文就包含了 Set-Cookie 字段，其中有一個名爲 sid 的鍵值對，這個鍵值對就是 Session ID。客戶端收到後就把 Cookie 保存在瀏覽器中，並且之後發送的請求報文都包含 Session ID。HTTP 就是通過 Session 和 Cookie 這兩種方式一起合作來實現跟蹤用戶狀態的，Session 用於服務器端，Cookie 用於客戶端。
- Set-Cookie字段有以下屬性:
-
緩存
有兩種緩存方法：讓代理服務器進行緩存和讓客戶端瀏覽器進行緩存。
Cache-Control 用於控制緩存的行爲。Cache-Control: no-cache 有兩種含義，如果是客戶端向緩存服務器發送的請求報文中含有該指令，表示客戶端不想要緩存的資源；如果是源服務器向緩存服務器發送的響應報文中含有該指令，表示緩存服務器不能對資源進行緩存。
Expires 字段可以用於告知緩存服務器該資源什麼時候會過期。當首部字段 Cache-Control 有指定 max-age 指令時，比起首部字段 Expires，會優先處理 max-age 指令。
-
持久鏈接
- Http/1.0 之前默認是非持久化連接的, 如果要維持持續鏈接, 需要使用Keep-Alive
- Http/1.1 默認持久化連接, 通過Connection首字段進行管理.
-
Http各版本區別
-
HTTP/0.9
HTTP 0.9是第一個版本的HTTP協議，已過時。它的組成極其簡單，只允許客戶端發送GET這一種請求，且不支持請求頭。由於沒有協議頭，造成了HTTP 0.9協議只支持一種內容，即純文本。不過網頁仍然支持用HTML語言格式化，同時無法插入圖片。
HTTP 0.9具有典型的無狀態性，每個事務獨立進行處理，事務結束時就釋放這個連接。由此可見，HTTP協議的無狀態特點在其第一個版本0.9中已經成型。一次HTTP 0.9的傳輸首先要建立一個由客戶端到Web服務器的TCP連接，由客戶端發起一個請求，然後由Web服務器返回頁面內容，然後連接會關閉。如果請求的頁面不存在，也不會返回任何錯誤碼。
-
HTTP/1.0
- 請求與響應支持頭域
- 響應對象以一個響應狀態行開始
- 響應對象不只限於超文本
- 開始支持客戶端通過POST方法向Web服務器提交數據，支持GET、HEAD、POST5. 方法
- 支持長連接（但默認還是使用短連接），緩存機制，以及身份認證
-
HTTP/1.1
關鍵的性能優化: keepalive連接，chunked編碼傳輸，字節範圍請求，請求流水線等
- 請求消息和響應消息都應支持Host頭域在HTTP1.0中認爲每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。因此，Host頭的引入就很有必要了。
- 新增了一批Request method
HTTP1.1增加了OPTIONS,PUT, DELETE, TRACE, CONNECT方法
緩存處理 - HTTP/1.1在1.0的基礎上加入了一些cache的新特性，引入了實體標籤，一般被稱爲e-tags，新增更爲強大的Cache-Control頭。
-
HTTP/2.0
HTTP 2.0是下一代HTTP協議，目前應用還非常少。主要特點有：
-
多路複用（二進制分幀）
不會改動HTTP 的語義，HTTP 方法、狀態碼、URI 及首部字段，等等這些核心概念上一如往常，卻能致力於突破上一代標準的性能限制，改進傳輸性能，實現低延遲和高吞吐量。而之所以叫2.0，是在於新增的二進制分幀層。在二進制分幀層上， HTTP 2.0 會將所有傳輸的信息分割爲更小的消息和幀,並對它們採用二進制格式的編碼 ，其中HTTP1.x的首部信息會被封裝到Headers幀，而我們的request body則封裝到Data幀裏面。
-
頭部壓縮[ 像來自同一個網頁的圖像，將會有大量的請求看上去幾乎同樣的，這就需要壓縮技術對付這種幾乎相同的信息。]
-
隨時復位
-
服務器端推流: Server Push
-
優先權和依賴
-
-
參考文獻
- 面試時，你被問到過 TCP/IP 協議嗎? - CSDN博客 http://blog.csdn.net/yulyu/article/details/69062288
- preparation/Network.md https://github.com/lisongting/preparation/blob/26f7302dcc243aecfd363e1a31769946efc852f9/Network.md
- https://github.com/CyC2018/Interview-Notebook/blob/master/notes/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md
- TCP擁塞控制-慢啓動、擁塞避免、快重傳、快啓動 - CSDN博客 http://blog.csdn.net/jtracydy/article/details/52366461
- https://github.com/CyC2018/Interview-Notebook/blob/66d63de8b875ff9be79763fb9bbed93f183403cb/notes/HTTP.md
- https加密流程和原理 - CSDN博客 http://blog.csdn.net/xincai/article/details/51954468