必備網路基礎知識（持續補充）

網路基礎知識

OSI參考模型

數據發送接收過程：先自上而下，後自下而上

 每一層都工作著不同的設備

 每一層的功能以及實現的協議

 TCP/IP:先自上而下，再自下而上處理頭部

 TCP（傳輸控制協議）簡介

  • 面向連接的、可靠的、基於位元組流的傳輸層通訊協議
  • 將應用層的數據流分割成報文段並發送給目標節點的TCP層
  • 數據包都有序號，對方收到則發送ACK確認
  • 使用校驗和函數來檢驗數據在傳輸過程中是否有誤

TCP報文頭

1、埠號：用來標識同一台電腦的不同的應用進程。

1）源埠：源埠和IP地址的作用是標識報文的返回地址。

2）目的埠：埠指明接收方電腦上的應用程式介面。

TCP報頭中的源埠號和目的埠號同IP數據報中的源IP與目的IP唯一確定一條TCP連接。

2、序號和確認號：是TCP可靠傳輸的關鍵部分。序號是本報文段發送的數據組的第一個位元組的序號。在TCP傳送的流中，每一個位元組一個序號。e.g.一個報文段的序號為300，此報文段數據部分共有100位元組，則下一個報文段的序號為400。所以序號確保了TCP傳輸的有序性。確認號，即ACK，指明下一個期待收到的位元組序號，表明該序號之前的所有數據已經正確無誤的收到。確認號只有當ACK標誌為1時才有效。比如建立連接時，SYN報文的ACK標誌位為0。

3、數據偏移／首部長度：4bits。由於首部可能含有可選項內容，因此TCP報頭的長度是不確定的，報頭不包含任何任選欄位則長度為20位元組，4位首部長度欄位所能表示的最大值為1111，轉化為10進位為15，15*32/8 = 60，故報頭最大長度為60位元組。首部長度也叫數據偏移，是因為首部長度實際上指示了數據區在報文段中的起始偏移值。

4、保留：為將來定義新的用途保留，現在一般置0。

5、TCP Flags：URG  ACK  PSH  RST  SYN  FIN，共6個，每一個標誌位表示一個控制功能。

URG：緊急指針標誌，為1時表示緊急指針有效，為0則忽略緊急指針。

ACK：確認序號標誌，為1時表示確認號有效，為0表示報文中不含確認資訊，忽略確認號欄位。

PSH：push標誌，為1表示是帶有push標誌的數據，指示接收方在接收到該報文段以後，應儘快將這個報文段交給應用程式，而不是在緩衝區排隊。

RST：重置連接標誌，用於重置由於主機崩潰或其他原因而出現錯誤的連接。或者用於拒絕非法的報文段和拒絕連接請求。

SYN：同步序號，用於建立連接過程，在連接請求中，SYN=1和ACK=0表示該數據段沒有使用捎帶的確認域，而連接應答捎帶一個確認，即SYN=1和ACK=1。

FIN：finish標誌，用於釋放連接，為1時表示發送方已經沒有數據發送了，即關閉本方數據流。

6、窗口：滑動窗口大小，用來告知發送端接受端的快取大小，以此控制發送端發送數據的速率，從而達到流量控制。窗口大小時一個16bit欄位，因而窗口大小最大為65535。

7、校驗和：奇偶校驗，此校驗和是對整個的 TCP 報文段，包括 TCP 頭部和 TCP 數據，以 16 位字進行計算所得。由發送端計算和存儲，並由接收端進行驗證。

8、緊急指針：只有當 URG 標誌置 1 時緊急指針才有效。緊急指針是一個正的偏移量，和順序號欄位中的值相加表示緊急數據最後一個位元組的序號。 TCP 的緊急方式是發送端向另一端發送緊急數據的一種方式。

9、選項和填充：最常見的可選欄位是最長報文大小，又稱為MSS（Maximum Segment Size），每個連接方通常都在通訊的第一個報文段（為建立連接而設置SYN標誌為1的那個段）中指明這個選項，它表示本端所能接受的最大報文段的長度。選項長度不一定是32位的整數倍，所以要加填充位，即在這個欄位中加入額外的零，以保證TCP頭是32的整數倍。

10、數據部分： TCP 報文段中的數據部分是可選的。在一個連接建立和一個連接終止時，雙方交換的報文段僅有 TCP 首部。如果一方沒有數據要發送，也使用沒有任何數據的首部來確認收到的數據。在處理超時的許多情況中，也會發送不帶任何數據的報文段。

TCP三次握手

 

 在TCP/IP協議中,TCP協議提供可靠的連接服務,採用三次握手建立一個連接.

第一次握手：建立連接時,客戶端發送syn包(syn=j)到伺服器,並進入SYN_SEND狀態,等待伺服器確認； 
第二次握手：伺服器收到syn包,必須確認客戶的SYN（ack=j+1）,同時自己也發送一個SYN包（syn=k）,即SYN+ACK包,此時伺服器進入SYN_RECV狀態； 
第三次握手：客戶端收到伺服器的SYN＋ACK包,向伺服器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和伺服器進入ESTABLISHED狀態,完成三次握手.

SYC超時原因以及解決措施？

Client出現故障怎麼辦？

TCP四次揮手

MSL：最長報文段壽命，30s(linux)

第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。

 為什麼要有TIEM-WAIT狀態？

 為什麼需要四次揮手才斷開連接？

UDP報文結構

 UDP特點

  • 面向非連接
  • 不維護連接狀態，支援同時向多個客戶端傳輸相同的消息
  • 數據包報文只有8個位元組，額外開銷較小
  • 吞吐量只受限於數據生成速率、傳輸速率以及機器性能
  • 盡最大努力交付，不保證可靠交付，不需要維持複雜的鏈路狀態表
  • 面向報文，不對應用程式提交的報文資訊進行拆分或者合併

TCP和UDP區別

TCP：面向連接，可靠性，有序性，重量級

UDP：無連接，速度快，輕量級

TCP的滑動窗口

TCP使用滑動窗口做流量控制與亂序重排

  • 保證TCP的可靠性（源於確認重傳機制）
  • 保證TCP的流控特性

窗口數據計算過程

  • 發送端：LastByteAcked表示已發送，已收到ACK，LastByteSent表示已發送，未收到ACK，LastByteWritten指向上層應用正在寫的位置。

 

  • 接收端：LastByteRead指向上層應用讀完的最後一個位元組的位置，NextByteExpected指向的收到的連續包的最後一個位置，LastByteRcved指向的是已收到的最後一個位元組的位置，我們可以看到中間有些數據還沒有到達，所以有數據空白區。
  • 接收端在給發送端回ACK中會彙報自己的AdvertisedWindow = MaxRcvBuffer – (LastByteRcvd – LastByteRead)。
  • 而發送方會根據這個窗口來控制剩餘可發送數據的大小，以保證接收方可以處理，計算方式：EffectiveWindow = AdvertisedWindow – (LastByteSent– LastByteAcked)。

TCP會話發送方

 發送方的發送快取內的數據都可以被分為4類:

1. 已發送，已收到ACK
2. 已發送，未收到ACK
3. 未發送，但允許發送
4. 未發送，但不允許發送

其中類型2和3都屬於發送窗口。

TCP發送方滑動原理：

當收到接收方對新的ACK對於發送窗口後續位元組的確認時，窗口就會進行滑動，前提是還有未發送，但運行發送的數據以及是連續確認之後。

如果32沒有被確認，而34被確認了，窗口也不會向右滑動，只有等到32到34都被確認了之後，以及連續被確認之後，滑動窗口才會移動，那在此時沒有被移動之前，大於51的數據以及窗口外的數據是不能被發送的。

如果從32到35都被確認了，則滑動窗口，迴向又移動四位，到36這個位置，進而我們的程式就能夠發送52到55的數據了。

TCP會話接收方

接收方的快取數據分為3類：
1. 已接收
2. 未接收但準備接收
3. 未接收而且不準備接收

其中類型2屬於接收窗口。

HTTP（超文本傳輸協議）特點（補充）：

  • 支援客戶/伺服器模式
  • 簡單快速
  • 靈活
  • 無連接
  • 無狀態

HTTP請求結構

HTTP響應結構

HTTP請求/響應步驟（補充）：

  • 客戶端連接到Web伺服器
  • 發送HTTP請求
  • 伺服器接收請求並返回HTTP響應
  • 釋放TCP連接
  • 客戶端瀏覽器解析HTML內容

在瀏覽器輸入URL,按下回車之後經歷的流程（補充）：

  • DNS解析
  • TCP連接
  • 發送HTTP請求
  • 伺服器處理請求並返回HTTP報文
  • 瀏覽器解析渲染頁面
  • 連接結束

HTTP狀態碼：

狀態程式碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：

  • 1xx：指示資訊–表示請求已接收，繼續處理
  • 2xx：成功–表示請求已被成功接收、理解、接受
  • 3xx：重定向–要完成請求必須進行更進一步的操作
  • 4xx：客戶端錯誤–請求有語法錯誤或請求無法實現
  • 5xx：伺服器端錯誤–伺服器未能實現合法的請求

常見狀態碼：

  • 200 OK ：正常返回資訊
  • 400 Bad Request：客戶端請求有語法錯誤，不能被伺服器所理解
  • 401 Unauthorized ：請求未經授權，這個狀態程式碼必須和WWW-Authenticate報頭域一起使用 
  • 403 Forbidden：伺服器收到請求，但是拒絕提供服務
  • 404 Not Found：請求資源不存在，eg：輸入了錯誤的URL
  • 500 Internal Server Error：伺服器發生不可預期的錯誤
  • 503 Server Unavailable ：伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常

GET和POST請求區別：

  • HTTP報文層面：GET將請求資訊放在URL，POST在報文體中
  • 資料庫層面：GET符合冪等性和安全性，POST不符合（冪等性：對資料庫的多次操作獲得結果一致；安全性：不會改變資料庫原有數據）
  • 其他層面：GET可以被快取、被存儲，而POST不行

Cookie簡介

  • 是由伺服器發給客戶端的特殊資訊，以文本的形式存放在客戶端
  • 客戶端再次請求的時候，會把Cookie回發
  • 伺服器收到後，會解析Cookie生成與客戶端相對應的內容

Cookie的設置以及發送過程

Session簡介

  • 伺服器端的機制，在伺服器上保存的資訊
  • 解析客戶端請求並操作jsession id,按需保存狀態資訊

Session的實現方式

  • 使用Cookie來實現（Cookie頭中攜帶jessionid）
  • 使用URL回寫來實現（鏈接攜帶jessionid）

Cookie和Session區別：

  • Cookie數據存放在客戶的瀏覽器上，Session數據放在伺服器上
  • Seesion相對於Cookie更安全（可以分析存放在本地的Cookie並進行欺騙）
  • 若考慮減輕伺服器負擔，應當使用Cookie

HTTPS簡介

SSL（安全套接層協議）

  • 為網路通訊提供安全及數據完整性的一種安全協議
  • 是作業系統對外的API,SSL3.0後更名為TLS
  • 採用身份驗證和數據加密保證網路通訊的安全和數據的完整性

HTTPS數據傳輸流程（補充）：

  • 瀏覽器將支援的加密演算法資訊發給伺服器
  • 伺服器選擇一套瀏覽器支援的加密演算法，以證書的形式回發瀏覽器
  • 瀏覽器驗證證書合法性，並結合證書公鑰加密資訊發給伺服器
  • 伺服器使用私鑰解密資訊，驗證哈希，加密響應資訊回發瀏覽器
  • 瀏覽器解密響應資訊，並對消息進行驗真，之後進行加密交互數據

HTTP和HTTPS區別：

  • HTTPS需要到CA申請證書，HTTP不需要
  • HTTPS密文傳輸，HTTP明文傳輸
  • 連接方式不同，HTTPS默認使用443埠，HTTP使用80埠
  • HTTPS=HTTP+加密+認證+完整性保護，較HTTP安全

HTTPS真的很安全嗎？

  • 瀏覽器默認填充//，請求需要進行跳轉，有被劫持的風險
  • 可以使用HSTS優化

Socket簡介

Socket是對TCP/IP協議的抽象，是作業系統對外開放的介面

Socket通訊流程

Tags:

VirMach 便宜 VPS

QNews

QNews