1.網路分層

• 七層OSI
• 應用層、表示層、會話層、傳輸層、網路層、資料鏈路層、物理層
• 五層協議（主要）
• 應用層、傳輸層、網路層、資料鏈路層、物理層
• 四層協議TCP/IP
• 應用層、傳輸層、網際層、網路介面層

2.各層的功能

• 應用層
• 為應用程式提供互動服務，如：HTTP、HTTPS、DNS、SMTP、FTP
• 表示層
• 主要負責資料格式的轉換，如：加密解密、壓縮解壓縮，
• 會話層
• 負責在網路中的兩節點之間建立、維持、終止通信，如：服務器驗證用戶登錄
• 運輸層/傳輸層
• 向主機行程提供通用的資料傳輸服務，如：TCP、UDP
• 網路層
• 路由選擇和轉發，如：IP
• 資料鏈路層
• 封裝成幀，
• 物理層
• 位元流透明傳輸，

3.傳輸層

3.0TCP的組成

• 源埠、目的埠、序號seq、確認號ack、視窗
• 控制位：ACK、FIN、SYN

3.1TCP和UDP的區別

• TCP
• 面向連接的，可靠的，面向位元組流的，主要是一對一連接，
• 場景：FTP檔案傳輸、SMTP郵件發送、遠程登陸、HTTP網路請求
• UDP
• 無連接的，不可靠的，盡最大努力交付的，面向報文段的，包含一對一、一對多、多對多連接，
• 場景：QQ直播、QQ語音、QQ視頻

3.2TCP的可靠性體現

• 1.確認應答機制
• 每次請求都會根據seq序列號進行“重排、丟掉重復的”，然后發送ACK報文，包含ack確認號，
• 2.重傳機制
• 超時重傳：對于發送的報文，如果在RTO(超時重傳時間)>RTT（往返時延），沒有收到ACK確認報文，則需要重新發送這個報文段，--------基于時間
• 快重傳：對于發送的報文，如果在一定時間內，連續收到對于同一個報文的確認，說明下一個報文丟失，直接重傳下一個報文，---------基于資料
• 3.流量控制
• 區域的思想，主要保證是接受方來限制發送方的發送效率，使得自己來得及接受，在TCP的報文段的視窗來設定，
• 4.滑動視窗
• 不再局限于之前的發送一個報文，應答一個報文；而是可以發送多個報文，接受多個報文；并且只需要對最后一個進行應答即可，這是累計確認，是有一個快取機制的，
• 發送方視窗組成：已經發送并收到確認的報文、已經發送未收到確認、還未發送的但可以發送的、不可以發送的；
• 發送方視窗大小 = 已經發送未收到確認 + 還未發送的但可以發送的
• 接收方視窗組成：已經接受并發送確認的報文、可以接受還未發送確認的、不可以接受的；
• 接受方視窗大小 = 可以接受還未發送確認的
• 5.擁塞控制
• 基于全域的思想，防止一段時間可能由于需求大于提供而導致的性能變差，
• 變數：擁塞視窗cwnd、慢開始門限ssthresh
• 慢開始
• cwnd = 1；每一個RTT后，cwnd = cwnd*2
• 擁塞避免
• cwnd>ssthrensh,cwnd = cwnd +1
  如果出現網路擁塞：cwnd = 1,ssthresh = cwnd/2
• 快重傳
• 對于發送的報文，如果在一定時間內，連續收到對于同一個報文的確認，說明下一個報文丟失，直接重傳下一個報文，
• cwnd = cwnd/2;ssthresh = cwnd-3;
• 快恢復
• cwnd = ssthresh + 3,重新走到擁塞避免，

3.3TCP的三次握手

• 程序：確保通信雙方都能發送和接收資料
• 1.發送方發送SYN = 1，seq = x，發送方進入SYN-SENT
  這里的初始序列號最好是隨機的，因為如果有第三方知道雙方埠和ip地址，推測出序列號就會產生一定的危害，
• 2.接收方收到請求，發送ACK = 1，SYN =1,seq = y，ack = x+1，接收方進入SYN-RECV
• 3.發送方接收到請求，建立連接；發送ACK = 1,seq= y，ack =y+1
  此時如果接收方沒有收到第三次握手，則第二次會繼續發送

補充：

1.四次握手可以嗎？

• 當然可以，但是沒有意義，因為四次握手要完成的事情，三次握手已經完成了

2.二次握手呢？

• 不可以，如果僅僅兩次握手，假設第一次握手的請求因為網路原因，沒有及時到達接收方，此時發送方重傳，接受方建立連接，但是如果之前的請求再次到達，就會再次建立一個新的請求；而三次握手，在第二次握手的時候，會適當的拋棄，

3.SYN泛洪攻擊（DOS_Denial of Service）

• 大量發送SYN=1的請求，導致服務器方，很多連接處于半連接佇列中，從而導致半連接佇列滿，而正常的請求被拋棄，
• 解決：對于攻擊的ip進行設定，拒絕訪問；及時清空半連接佇列的請求連接，

4.DDOS(Distributed Denial of Service）

• 分布式攻擊的泛洪攻擊，沒什么區別
• 解決：減少SYN的timeout時間；減少SYN的連接數量，

5.三次連接可以發送資料嗎？

• 第一次和第二次不可以：就是防止SYN攻擊的時候，有大量的資料發送，導致服務器崩潰，
• 第三次可以：此時客戶端處于建立狀態，并且知道服務器可以發送和接受資料，

6.第三次握手丟失？

• 重傳機制，RTO>RTT的時候，服務端繼續重新發送資料，時間指數倍增長，

3.4TCP的四次揮手

• 程序：通信雙方發送完資料，來斷開連接，
• 發送方斷開連接
• 1.發送方發送FIN = 1，ACK、seq、ack；發送方進入FIN_WAIT1
• 2.接收方收到請求，發送ACK 、seq、ack，接收方進入close_wait，發送方進入FIN_WAIT2
• 接收方斷開連接
• 3.接收方資料接收完，請求斷開連接；發送FIN=1，ACK ,seq，ack;進入Last_Ack
• 4.發送方接受到請求，發送ACK、seq，ack，進入TIME_WAIT階段

補充：

1.為什么需要四次？

• 不同于三次握手，因為要涉及到通信雙方的資料

2.為什么最后要等待2MSL?

• MSL:報文段最大存活時間，保證了如果最后一次揮手沒有丟失，第三次揮手的報文段重新接受；并且保證了下一次的連接中，不會有上次的存留的報文段

3.四次揮手的首次請求方一定是客戶端嗎？

• 不一定
• 讓服務端先退出，然后我們用netstat觀察埠的狀態，此時我們發現四次揮手程序中服務器和客戶端的狀態顛倒了， 也就是說，服務端和客戶端的行程那個先向對方發送FIN 欄位報文，那么哪個就先進入FIN_WAIT2狀態，
  
• 但是下一步：客戶端往服務端發送資料就不一樣？
  
• 原因：當服務器行程被終止時，會關閉其打開的所有檔案描述符，此時就會向客戶端發送一個FIN 的報文,客戶端則回應一個ACK 報文,但是這樣只完成了“四次揮手”的前兩次揮手，也就是說這樣只實作了半關閉，客戶端仍然可以向服務器寫入資料，但是當客戶端向服務器寫入資料時，由于服務器端的套接字行程已經終止，此時連接的狀態已經例外了，所以服務端行程不會向客戶端發送ACK 報文，而是發送了一個RST 報文請求將處于例外狀態的連接復位； 如果客戶端此時還要向服務端發送資料，將誘發服務端TCP向服務端發送SIGPIPE信號，因為向接收到RST的套介面寫資料都會收到此信號.
• 所以說，這就是為什么我們主動關閉服務端后，用客戶端向服務端寫資料，還必須是寫兩次后連接才會關閉的原因，
• 注：感覺有點問題，不太理解？只需要記住不同于正常關閉即可，并且傳輸資料會進行兩次寫，但不成功！

參考鏈接：
https://blog.csdn.net/bit_clearoff/article/details/60884905

4.Time-wait過多怎么辦？

• 對于服務器來說，則會嚴重損耗服務器的資源，導致部分客戶端連接不上，
• 解決：設定引數SO_REUSEADDR套接字選項來避免time-wait，進行埠重用
• 對于客戶端來說，會導致客戶端埠被占用，65536，導致無法創建新的連接
• 解決：發送RST包，直接越過Time-wait，進入closed，這就像上面的服務端主動關閉導致的一樣，

3.5TCP的心跳機制

• 很多應用層協議都有HeartBeat機制，通常是客戶端每隔一小段時間向服務器發送一個資料包，通知服務器自己仍然在線，并傳輸一些可能必要的資料，使用心跳包的典型協議是IM，比如QQ/MSN/飛信等協議，
• 心跳包之所以叫心跳包是因為：它像心跳一樣每隔固定時間發一次，以此來告訴服務器，這個客戶端還活著，事實上這是為了保持長連接，至于這個包的內容，是沒有什么特別規定的，不過一般都是很小的包，或者只包含包頭的一個空包，
• 總的來說，心跳包主要也就是用于長連接的保活和斷線處理，一般的應用下，判定時間在30-40秒比較不錯，如果實在要求高，那就在6-9秒，
• 實作步驟：TCP的KeepAlive保活機制？
• 1：客戶端每隔一個時間間隔發生一個探測包給服務器
• 2：客戶端發包時啟動一個超時定時器
• 3：服務器端接收到檢測包，應該回應一個包
• 4：如果客戶機收到服務器的應答包，則說明服務器正常，洗掉超時定時器
• 5：如果客戶端的超時定時器超時，依然沒有收到應答包，則說明服務器掛了

參考鏈接：
https://blog.csdn.net/qq_33314107/article/details/80574137

3.6TCP的粘包和拆包

• 問題： TCP報文段傳輸的時候也會出現報文段分段的現象（主要是報文段太大），類似于網路層的ip分組，
• 現象： 兩個包合在一起發送、一個包的前一部分和另一個包一起發送、一個包的后部分單獨發送
• 原因： 1.報文段太大，大于MSS(最大分段長度)、2.發送方發送的資料大于發送緩沖區剩余資料的大小、3.發送方發送的資料小于接收方緩沖區空間的大小，多次將資料發送到網路
• 解決： 1.對于報文段固定相同的長度，不足進行填充；2.對于每個報文段進行定界符的填充來進行區分；3.在報文段的首部添加表示報文段長度的標識，

3.7UDP會發生粘包和拆包嗎？

• 不會，因為其報文段發送的，而TCP是按位元組流，并且UDP的首部指示了報文段的長度，

3.8UDP怎么實作可靠的？

• 其實作不了，主要在應用層實作的，就像QQ的QICQ，其實作了TCP的各種可靠機制，

4.應用層

4.1：http常見的狀態碼

• 100：Continue
• 200：OK、206：部分請求
• 301：永久重定向、302：臨時重定向
• 永久：代表訪問某個a，會自動跳轉到b，url為b；臨時：訪問a，url不變，但是內容渲染的是b
• 400：客戶端語法錯誤、403：服務器拒絕提供服務（不為請求提供服務，或您沒有連接到此站點的權限時）、404：頁面沒有找到
• 500：服務器內部執行錯誤，無法完成請求、503：服務器正在維護

4.2：http的請求報文、回應報文

• 請求報文組成：
• 請求行、請求頭、請求體（其中請求行和請求體之間有空格來區分），如：
• Post /from/login？xxx HTTP1.1
• Host:www.baidu.com Connection:keep-alive
• name = swz & age =37
• 回應報文組成：
• 回應行、回應頭、回應體（回應行和回應體之間有空格），如：
• 200 OK HTTP1.1
• Data:xxxx Content-length:360
• < h1 > hello，world！< h1 >

4.3：Get、Post（前兩個為主）、Delete、Put

• Get：主要用于獲取資源；引數傳遞通過請求行url，所以相對不是安全，并且長度限制；但是從整體上看，其主要是有冪等性的，這個說明多次請求效果一樣，保證了對資料庫的安全；

• Post：主要用于傳輸物體內容；引數傳遞在請求體中，所以相對安全，長度足夠；主要是用于修改資料庫內容，無法保證對資料庫的安全；

  注：其實Post、Get這是兩種規定，完全可以不按照走，但是處不處理就不一定了；并且相比較而言，Post是比Get有一些好處，但是Get請求，我們的瀏覽器可以進行快取，所以多次請求的時候會加快速度，

• Delete：洗掉檔案

• Put：上傳檔案

4.4：Http1.0和Http1.1的區別

• 1.前者是短連接，后者是長連接
• 當請求一次連接的時候，如果是短連接的話，對于頁面中的其他資源，如：js、image都會建立一次新的連接，而長連接可以共用一個，
• 2.后者增加了很多新的狀態碼，如206：部分請求
• 3.后者對于網路資源的處理更加優化，如允許部分請求
• 4.后者在請求頭中增加了Host欄位，之前認為是一臺主機一個IP，而因為虛擬機等的出現，多個主機公用一個ip

4.5：Http1.1和Http2.0的區別？

• 后者維護一個頭部欄位表，這樣就不用在客戶端和服務器端來回傳輸，只需要每次有修改的東西，傳過去即可
• 后者支持自動發送，不需要必須請求，而是在一定的時候，進行自動的推動資料
• 后者利用了多路復用的基礎，實作了服務器可以回應多個請求，實作了一條連接不同請求進行復用（這一部分具體實作我也不太懂----）
• 并且2.0是基于二進制格式的，實作方便，

4.6：Http3.0和Http2.0的區別？

• 這一部分問的少，加分項吧（一般c++可能會問，之后補充吧）

4.7：Cookie和Session和Token的區別？

1.Cookie、Session的區別？

• 一般我們會問到Cookie和Session的區別，但是對于Token，可能有些面生
• Cookie：主要用于客戶端，存盤在本機上，所以相對不安全
• Session：主要用于服務器端，相比是安全的，一般兩者結合使用，是為了應對http請求的無狀態，其實作主要是：在服務器端保存一個SeeionID和Seesion，用來表示每一個會話，以及存盤相應的內容，將sessionid及對應的session分別作為key和value保存到快取中，也可以持久化到資料庫中，然后將SessionId回傳給客戶端，然后每次請求的時候在Cookie中將SessionID傳過來，進行用戶的跟蹤，
• 中途為了保證Cookie的一些資訊，我們可以在Cookie進行加密，然后在服務器端進行解密即可，
• 如果瀏覽器禁用了Cookie，那怎么辦？
• 這時候，我們可以通過在url發送的形式，將SessionID進行發送，當然為了安全，可以進行加密，

2.Session和Token的區別

• Token 出現主要是解決Session本身會占用空間來說的
• 流程：對用戶id + 資料 進行簽名操作，生成token，發送給客戶端，下次客戶端再次請求的時候，將token也傳過來，然后再次使用相同的演算法+密鑰進行簽名，比較兩者的token是否相等，如果相等，則認為是同一個用戶，
• 區別：
• Session可以說是空間換時間，而Cookie可以說是時間換空間，

3.無狀態協議

• 由于HTTP是一種沒有狀態的協議，它并不知道是誰訪問了我們的應用，
• 這里把用戶看成是客戶端，客戶端使用用戶名還有密碼通過了身份驗證，不過下次這個客戶端再發送請求時候，還得再驗證一下，所以上面的session和token是解決這個問題的（之前一直以為是為了保存資料的，我giao！）

4.分布式Session

這里在補充下分布式Session的解決方案：

• 共享Session，單獨有一個服務器存盤Session，然后每臺服務器進行回應的讀取
• 同步Session，說白了就是每臺服務器都要存盤一份，實時更新
• hash（ip），這是負載均衡的一個演算法，實作一個客戶端之后訪問對應的服務器，直接就解決了

5.負載均衡

在補充下負載均衡演算法

• 隨機
• 輪詢
• 加權輪詢
• hash（ip）

6.簽名

簡單說一下：主要是對資料通過哈希演算法進行第一步處理，然后利用私鑰進行加密生成數字簽名

• CA證書：簽名 + 服務器的公鑰

4.8:Https和Http的區別？

• 簡單來說：就是在http和tcp之間，加一層ssl/tls協議，
• 最新版本的TLS 1.0是IETF(工程任務組)制定的一種新的協議，它建立在SSL 3.0協議規范之上，是SSL 3.0的后續版本，兩者差別極小，可以理解為SSL 3.1，它是寫入了RFC的，
  注：RFC面試問過，但是不會，有興趣的可以去了解，
• 主要包含三個方面：
• 1.防竊聽
• 解決：加密（對稱加密（加密解密一個密鑰）和非對稱加密（公鑰解密，私鑰解密））
• 程序：首先服務器將公鑰傳給來，然后客戶端將對稱加密的密鑰利用公鑰加密進行傳輸，服務器獲取到利用私鑰解密，之后兩者利用客戶端的公鑰進行對稱加密傳輸，
• 分析：因為對稱加密相比于非對稱加密是更快的，而對稱加密本身無法安全的將其傳給服務器端，所以最后是兩者結合了，
• 2.防偽裝
• 解決：CA證書
• 步驟：證書機構，如下面的安信，服務器端將自己的公鑰傳給CA，然后CA進行hash+私鑰加密，生成數字簽名，然后數字簽名+服務器公鑰 = CA證書；客戶端獲取服務器的證書，并獲取CA的公鑰，進行數字簽名的解密，然后比較相等，則認證成功，獲取服務端的公鑰，下面的就一樣了，
• 分析：因為在上一步中可能會出現一些第三方中途截取的程序，它獲取服務器端的公鑰，然后把自己的公鑰傳給客戶端，客戶端將自己的公鑰加密傳給第三方，第三方私鑰獲取，然后利用服務器公鑰加密發送給服務器，這樣神不知鬼不覺就獲到了，
  
• 3.防篡改
• 前面兩個步驟很好的解決了，

4.9:Https這么好，為什么不常用？

• 1.CA證書有點貴
• 2.因為多了處理，所以比較慢
• 3.還是會有安全問題（怎么個問題？不知道）

5.一些相關協議、程序

5.1ARP請求協議

• 這是網路層的一個協議，其主要完成了從ip地址到mac地址的一個映射，
• 每個主機都會有一個ARP高速快取，就是目的ip地址的mac地址的一個映射表
• 步驟：
• 1.查詢Arp高速快取，有，獲得mac地址；沒有，則廣播發送ARP請求包
• 2.ARP回應包，單播傳回到A
• 3.將mac地址寫到Arp高速快取中

5.2DNS協議

• 這是應用層的協議，其主要功能：完成url到ip地址的映射

• 主要分為遞回查詢和迭代查詢
  

• 步驟：（遞回+迭代組合查詢）

• 1.遞回查詢
  搜索瀏覽器本身的快取、os的快取，然后向本地域名服務器進行查找
  本地域名服務器：
  

• 2.迭代查詢
  本地域名服務器向根域名服務器進行查詢，回傳頂級域名的地址
  本地域名服務器向頂級域名服務器進行查詢，回傳權限域名服務器的地址
  本地域名服務器向權限域名服務器進行查詢，回傳ip地址

• 3.快取
  將url-ip的映射保存到os、瀏覽器快取中即可，

5.3URL程序

• 1.url-ip地址的決議（DNS協議，見上面）
• 2.TCP三次握手（見上面）
• 3.ARP協議（見上面）
• 4.資料傳輸（資料發送程序）
• 5.頁面渲染：將資料從報文拿出來進行頁面的渲染，
• 6.四次揮手（見上面）

6.網路層的一些簡單了解（筆試題）

1.有類網

• 相關問題：
  • 1.下面的IP地址中A類、B類、C類地址分別有幾個?
    92.168.1.100、129.32.123.54、223.89.201.145、220.18.255.254、124.254.200.254
    191.64.220.8、66.254.1.100、92.1.100.1、202.15.200.12
    答：
    A類：第一位確定為0，范圍為：0~127，所以：92.168.1.100 124.254.200.254 66.254.1.100三個屬于A類網；B類：前兩位確定為10，范圍為：128~191，所以：129.32.123.54 191.64.220.8兩個屬于B類網；C類：前三位確定為110，范圍為:192~223，所以：223.89.201.145 220.18.255.254 192.1.100.1 202.15.200.12四個屬于C類網
  • 2.有類地址191.168.1.2的網路號和主機號分別是什么？
    答：
    因為為191開頭，所以為B類地址，前16位為網路號，后16位為主機號，所以網路號為191.168.0.0，主機號為0.0.1.2
  • 3.一個C類網可用的IP地址有多少個？
    答：
    根據問題，可知是一個確定的C類網，IP地址為可用主機個數，2^8-2=254個，

2.子網劃分

C類網192.168.1.0劃分為四個子網的子網掩碼為255.255.255.192，子網號分別為00、 01、 10、 11，

• 主機號為全1或全0的地址被保留，不能使用，
• 子網號為全0或全1的子網現在都可以使用（以前規定不可使用），
• 子網掩碼即將主機號的前n位拿出來作子網號，主機號的剩余部分作主機號，

將子網掩碼與ip地址作與運算，便可以得到網路地址，將取反后的子網掩碼與ip地址作與運算，便可以得到主機地址，

• 相關問題：假設有一個 I P 地址： 192.168.0.1，子網掩碼為： 255.255.255.0，求網路地址和主機地址？
• 步驟：
• 化為二進制為： I P 地址 11000000.10101000.00000000.00000001，子網掩碼 11111111.11111111.11111111.00000000，將兩者做 ’ 與 ’ 運算得： 11000000.10101000.00000000.00000000
  將其化為十進制得： 192.168.0.0，這便是上面 IP 的網路地址，主機地址以此類推，

參考鏈接：
https://blog.csdn.net/N1neDing/article/details/80740701