Java面試知識總結（一）-- 網路基礎

根據慕課網視訊和一些其他社群別的博主的總結進行的二次總結。這個過程為的是加深印象。

OSI 七層協議

1. 物理層

定義了機器之間通訊標準：網線型別，介面型別，各種介質的傳輸數率。這一層傳輸位元流（二進位制資料），進行數模轉換和模數轉換。

2. 資料鏈路層

定義如何格式化資料進行傳輸，如何控制對物理介質的訪問。採用差錯控制與流量控制方法，確保資料傳輸的可靠性。在這一層的資料是幀，工作的裝置是網路卡、網橋、交換機。

3. 網路層

將網路地址翻譯成對應實體地址（封裝和解析），通過路由選擇演算法為通訊子網選擇最適當的傳輸路徑（傳送方->接受方），以及實現擁塞控制、網路互連等功能。這一層的資料是資料包，工作的裝置有路由器、交換機、防火牆。IP協議。

4. 傳輸層*

保證海量檔案傳輸資料的準確性，傳輸層定義了傳輸資料的協議和埠號，用來對資料進行分割，傳輸，重組。傳輸層向高層遮蔽了下層資料通訊的細節。在這一層工作的協議有TCP和UDP等。

5. 會話層

建立和保證應用程式之間的通訊。使應用程式自動收發包和定址。

6. 表示層

對接收的資料進行解釋、加密、解密、壓縮、解壓縮等，即把計算機能夠識別的內容轉換成人能夠識別的內容（圖片、聲音、文字等）。

7. 應用層

基於網路構建具體應用，使用者可以自己規定各個應用間訊息傳輸的形式，例如FTP上傳檔案下載服務、Telnet服務、HTTP服務、DNS服務、SNMP郵件服務等。

TCP/IP

是OSI的實現。四層模型。不僅僅是TCP和IP協議，是一系列網路協議的總稱（協議簇），如：HTTP, FTP, SMTP, DNS, UDP等等。
？注重實現協議應該開發哪種程式。
TCP/IP協議從應用層到物理層至上而下再至下而上處理資料頭部。

應用層

對應七層協議的會話，表示，應用

傳輸層

對應七層協議的傳輸

網路層

對應七層協議的網路

鏈路層

對應七層協議的物理，資料鏈路

TCP報文頭部結構

由圖可知，TCP報文頭部至少需要20位元組長度。

源埠，目標埠

標識出目標埠，目標IP，源埠，源IP，就可以確定一個連線的唯一性。IP層處理兩個IP元組，而TCP層處理其餘兩個元組。這兩個埠長度分別為兩位元組。

序列號

報文段第一個位元組的序列號。佔用四個位元組。一次通訊過程中，第一次序號值被初始化為一個隨機值ISN，後續的序號值將在此基礎上加上該報文段所攜帶資料的第一個位元組在整個位元組流中的偏移X，即ISN+X。

確認號

ACK，四個位元組。作為收到另一方傳送的報文後的響應。值是收到對方的序號值+1。告知對方下一個期望接收的序列號，小於ACK的所有位元組已經全部收到。

頭部長度

4bits，表示tcp頭部有多少個32bits字。4bits最多表示15個數，所以頭部最大可以表示1532bits，即154bytes，四位元組。

八位標誌位

常見的標記位有SYN,ACK,FIN,RST,PSH。
含義？

視窗大小

兩位元組。是TCP流量控制的一個手段，這裡說的視窗是指接收通告視窗，它告訴對方本端的tcp接收緩衝區還能容納多少位元組的資料，這樣對方就可以控制傳送資料的速度。

校驗和

佔用兩個位元組，防止傳輸過程中資料包有損壞，如果遇到校驗和有差錯的報文，TCP 直接丟棄之，等待重傳。

緊急指標

它和序號欄位的值相加表示最後一個緊急資料的下一位元組的序號。傳送緊急資料時會用到。

可選項

最後一個選項欄位是可變長的可選資訊，最多包含40位元組的資料。典型的tcp頭部選項結構：

常用的可選項有以下幾個:

• TimeStamp: TCP 時間戳，後面詳細介紹。
• MSS: 指的是 TCP 允許的從對方接收的最大報文段。
• SACK: 選擇確認選項。
• Window Scale： 視窗縮放選項。

TCP 三次握手

IP無連線通訊協議，不會佔用兩個正在通訊計算機的通訊線路。通過IP協議，資料被分割為小的獨立的包，進行傳輸，但是無法保證資料包傳輸的可靠性，所以需要TCP保證傳輸的準確性。

TCP是面向連線的、可靠的、基於位元組流的傳輸層通訊協議。

三次握手過程：

• 服務端開啟某個埠，進入LISTEN狀態，開始監聽。
• 客戶端主動發起連線，傳送連線請求報文SYN，完成後進入SYN-SENT狀態
• 服務端接收到資訊，傳送回SYN和確認報文ACK，進入SYN-RCVD狀態；如果服務端未傳送確認資訊，則客戶端重傳包。
• 客戶端接收到返回的資訊，將ACK傳送給服務端，進入ESTABLISHED狀態，建立連線。

為什麼不是兩次？

如果第一次握手時客戶端傳送的報文滯留在網路沒有到達客戶端，那麼客戶端將重傳報文從而建立連線。過程結束後，滯留的包到達服務端，此時服務端只需回傳接收到的包就可以預設建立連線，但是之前客戶端已經通過重傳建立過連線了，從而造成了資源的浪費。

為什麼不是四次

三次握手已經可以確定建立連線了，四次雖然可以，但是沒有必要。如果是將服務端的SYN和ACK報文拆分成兩次傳送，這和一次的效果是相同的，也沒有必要。

SYN Flood 攻擊

首先我們需要明白什麼是半連線佇列和全連線佇列。
服務端建立監聽之後，收到客戶端傳送的SYN包，進入SYN-RCVD狀態，並向客戶端傳送ACK。此時這個連線被推入SYN佇列，就是半連線佇列。
當第三次握手時客戶端發返回給服務端ACK，兩端建立連線，等待被具體應用取走前，進入TCP維護佇列，就是全連線佇列。

• 問題產生：
  SYN Flood 攻擊就是客戶端偽造大量不存在的IP地址，向服務端不斷髮送SYN報文。隨後服務端返回ACK，大量連線處於半連線佇列，造成服務端無法正常處理連線請求。
  又由於偽造的IP地址不存在，服務端長時間收不到客戶端的ACK，使其不斷重發資料，會耗盡服務端資源。

• 解決辦法：

  • 增加SYN，即增加半連線佇列的容量
  • 減少SYN+ACK重試次數，避免大量超時重發
  • 利用 SYN Cookie 技術，在服務端接收到SYN後不立即分配連線資源，而是根據這個SYN計算出一個Cookie，連同第二次握手回覆給客戶端，在客戶端回覆ACK的時候帶上這個Cookie值，服務端驗證 Cookie 合法之後才分配連線資源。

TCP 四次揮手

斷開一個TCP連線時的整個流程。

• 假設客戶端主動關閉，客戶端向服務端發出FIN報文，進入FIN-WAIT-1狀態。此時客戶端半關閉狀態，只能接收報文。
• 服務端收到FIN報文，向客戶端傳送ACK確認，進入CLOSED-WAIT狀態。客戶端收到報文，進入FIN-WAIT-2狀態。
• 服務端傳送FIN報文，進入LAST-ACK狀態
• 客戶端收到服務端發來的FIN後，自己變成了TIME-WAIT狀態，然後傳送 ACK 給服務端。收到ACK後，服務端關閉。
• 此後客戶端需要等待2個MSL(Maximum Segment Lifetime，報文最大生存時間)，在這段時間內如果客戶端沒有收到服務端的重發請求，那麼表示 ACK 成功到達，揮手結束，否則客戶端重發 ACK。

為什麼最後有TIME-WAIT狀態

• 保證有足夠時間讓被動關閉端收到ACK
  • 1 MSL 確保傳送的ACK有足夠時間到被關閉端
  • 1 MSL 確保如果規定時間內對端未收到ACK，有足夠時間重傳FIN
• 避免新舊連線混在一起

為什麼四次揮手斷開連線

因為服務端在接收到FIN, 往往不會立即返回FIN, 必須等到服務端所有的報文都傳送完畢了，才能發FIN。因此先發一個ACK表示已經收到客戶端的FIN，延遲一段時間才發FIN。這就造成了四次揮手。

如果是三次揮手會有什麼問題？

出現大量CLOSED-WAIT狀態的原因？

UDP

• 一個面向無連線的傳輸協議。
• 不維護連線狀態，支援同時向多個客戶端傳輸相同訊息
• 資料包包頭8位元組，較小
• 吞吐量只受限於資料生成速率，傳輸速率和機器效能
• 不保證可靠交付，無需維持複雜的連結狀態表
• 面向報文，不對應用程式提供的報文資訊進行拆分或合併

TCP 和 UDP 區別

• 面向連線 vs 無連線
• 可靠性：TCP可靠，丟包重傳；UDP不可靠。
• 有序性：TCP利用序列號保證了資料的有序性（資料到達會排序）
• 速度：TCP建立連線，速率較慢；UDP較快
• TCP 流模式，UDP報文模式

TCP 的流量控制

簡單說就是通過接收端快取區大小，控制傳送端的傳送。如果接收端快取區已滿，傳送端就無法進行傳送。

TCP 的滑動視窗

• 保證TCP可靠性
• 保證TCP流控特性
• 分為兩個視窗，接受視窗和傳送視窗

傳送視窗

已傳送未確認視窗和未傳送可傳送的視窗決定了傳送視窗的大小。而接收視窗的大小取決於傳送端已傳送未確認視窗的大小。

接收視窗

待傳送端已傳送但未確認的資料被確認後，接收視窗會進行移動，形成滑動視窗。只有收到ACK確認後，視窗才會滑動，一定時間內未確認的資料將會重傳，從而保證了TCP連線的可靠性。

流量控制的過程

• 通過三次揮手後，傳送端和接收端建立連線，並初始化視窗大小為200個位元組。

• 此時傳送端給接收端傳送100個位元組的資料，那麼SND.NXT指標會右移100位元組，使可用視窗減少100位元組。

• 接收端接收了100位元組，由於處理能力有限，一次最多隻能處理40位元組，剩餘的60位元組留在了緩衝區。這樣，接收端接收視窗需要縮小60位元組變成140位元組，保證未來能處理這60位元組的緩衝區資料。

• 接收端收到傳送端資料給傳送端返回的ACK報文首部會帶上視窗大小的資料，於是傳送端也相應調整視窗大小為140位元組。傳送端此時已傳送已確認的資料為40位元組，所以SND.UNA右移40位元組。

報文結構

HTTP報文結構：起始行 + 頭部 + 空行 + 實體

起始行

• 請求報文起始行：方法 + 路徑 + HTTP版本
• 相應報文起始行：HTTP版本 + 狀態碼 + 原因
• 每個部分用空格間隔，最後一個部分換行符

請求頭/響應頭

在起始行後，是請求頭和響應頭。
格式要求：

• 欄位名不區分大小寫
• 欄位名不允許出現空格，不可以出現下劃線_
• 欄位名後面必須緊接著:

空行

• 用來區分頭部和實體

實體

• 具體資料

請求方法

• GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE

GET, POST 區別

• 快取角度：GET會被瀏覽器主動快取下來，POST不會
• 編碼角度：GET進行URL編碼，只接受ASCII碼，POST沒有限制
• 引數角度：GET放在URL中，不安全；POST放在請求體中，適合傳輸敏感資訊
• 冪等性角度：GET冪等，POST不是（執行相同操作，結果也相同）
• TCP傳輸時，GET直接將報文傳送完成，POST分兩次傳送，第一次傳送頭部資訊，如果TCP響應100，那麼繼續傳送實體部分

URI 統一資源識別符號碼

使用ASCII，所有非ASCII碼通過轉化為16進位制位元組值加%的編碼形式進行識別。

在瀏覽器位址列鍵入URL，按下回車後經歷的流程

• DNS解析
  -
• TCP連線，三次握手
• 傳送HTTP請求
• 伺服器處理請求返回HTTP響應報文
• 瀏覽器渲染介面
• 結束連線，四次揮手

HTTP狀態碼

• 1xx: 協議處理的中間狀態，需要繼續處理
  • 100 Switching Protocols：在HTTP升級為WebSocket的時候，如果伺服器同意變更，就會傳送狀態碼 101。
• 2xx: 請求成功
  • 200 OK：在響應體中放有資料
  • 204 NO CONTENT
  • 206 PARTIAL
• 3xx: 重定向，資源位置發生變動，需要重新請求
  • 301 Moved Permanently即永久重定向，對應著302 Found，即臨時重定向
  • 304 Not Modified: 當協商快取命中時會返回這個狀態碼。
• 4xx: 客戶端錯誤，請求報文有誤
  • 400 Bad Request: 客戶端請求語法錯誤
  • 403 Forbidden：伺服器收到請求，但拒絕服務
  • 404 Not Found: 請求的伺服器資源不存在
• 5xx: 服務端錯誤
  • 500 Internal Server Error：伺服器傳送不可預知的錯誤
  • 503 Server Unavailable：伺服器無法響應服務

Cookie 和 Session 的區別

Cookie

• 客戶端傳送第一次請求時，由服務端傳送給客戶端的特殊資訊，以文字形式存在客戶端
• 客戶端再次請求時，會攜帶Cookie資訊回傳到伺服器
• 伺服器通過解析，獲取客戶端的狀態。

Session

• 伺服器的機制，在伺服器上儲存的資訊
• 客戶端傳送請求時，伺服器解析客戶端資料是否包含session id，若沒有則為其生成

實現方式

• 通過Cookie：在Cookie資訊中攜帶Session id
• 通過URL回寫：？？？

區別

• Cookie存放在客戶端瀏覽器上，Session資料存放在客戶端上
• Session更安全
• 使用Cookie可以減輕瀏覽器負擔

HTTP 和 HTTPS 的區別

• HTTPS需要申請CA證照
• HTTPS有SSL加密傳輸；HTTP明文
• 埠號不同：443；80
• HTTPS = HTTP + 加密 + 認證 + 完整性保護，更安全

Socket

• 是對TCP/IP協議的抽象，是作業系統對外開放的抽象。
• 通訊流程：

本作品採用《CC 協議》，轉載必須註明作者和本文連結