淺談計算機網絡（HTTP/HTTPS/TCP/UDP/IP）

前言

計算機網絡是計算機專業很重要的一門課，課程中詳細闡述了兩臺計算機之間是如何進行通訊、如何保證通訊的可靠性、如何保證通訊的高效性等等內容，在平常coding中可能比較少關注到這方面，可是在真正遇到網絡方面的問題沒法解決時，瞭解計算機網絡的原理倒是十分必要的。

OSI七層網絡模型

• OSI七層網絡模型縮略圖

• 自底向上理解七層網絡模型

  工程學科是不斷迭代的過程，所以七層協議大概是這麼進化來的。

  • 物理層

    物理層解決了兩臺機器之間相互通訊的問題，首先機器A發送了一些比特流，機器B須要收到這些比特流，這就是物理層所作的事情。物理層主要定義了網絡設備的標準，例如接口的類型、機器的類型、網絡的類型等。其傳輸的數據主要是bit流，也就是010101....這類數據，以電流強弱定義，也就是D/A or A/D轉換。物理層的分組稱爲bit。

  • 數據鏈路層

    在傳輸bit流的過程當中，會產生錯傳、數據傳輸不完整的狀況，數據鏈路層就應運而生。數據鏈路層主要定義數據格式化傳輸、以及如何控制對物理介質的訪問，一般還有錯誤控制和糾正，處理錯誤數據。這一層將分組稱爲幀。

  • 網絡層

    在數據傳輸的過程當中，須要有數據發送方和數據接收方，並且在網絡愈來愈複雜的變化中，如何在多個節點中找到最佳路徑精準地找到接收方，這就是網絡層須要作的事。網絡層會將網絡地址翻譯爲對應的物理地址，而後經過計算，得出從節點A到節點B的最佳路徑，本層的協議是IP協議，在本層中將分組稱爲數據報。

  • 傳輸層

    在網絡層傳輸的過程當中，會中斷好屢次，因此須要把發送的信息切割爲一個一個的Segment，分段傳輸，那麼其中一段發送失敗了或出現錯誤了，要怎麼辦，是否須要重傳，這就是傳輸層須要乾的事。傳輸層保證了傳輸的質量，這層也被稱爲OSI七層模型中最重要的一層，本層須要關注的協議爲TCP/UDP協議。另外傳輸層會將數據報進行進一步切割，例如：以太坊沒法接收大於1500Byte的數據報，因而傳輸層就將報文分割爲多個報文段，並按順序發送，而且傳輸層是負責端到端的傳輸。

  • 會話層

    會話層的做用就是創建和管理應用程序之間的通訊，無需用戶過多地參與到TCP/IP協議中。

  • 表示層

    表示層能夠幫助咱們翻譯在不一樣類型網絡上的數據，例如加密解密、轉換翻譯、壓縮解壓縮等。

  • 應用層

    應用層規定發送方和接收方必須使用固定長度的消息頭，而且封裝了各類的報文信息，旨在使用戶更方便地應用網絡中接收到的數據，該層須要關注的協議爲HTTP協議，該層的分組稱爲報文。

  網絡數據處理流程爲，發送方先自上而下封裝，接收方自下而上解封數據。而事實上OSI並無真正實現網絡，而TCP/IP五層模型其實是對OSI參考模型的實現。

TCP/IP協議族

• 傳輸控制協議（Transmission Control Protocol）簡介

  • 面向鏈接的、可靠的、基於字節流的傳輸層通訊協議
  • 將應用層的數據流分割成報文段併發送給目標節點的TCP層
  • 報文段都有序號，對方收到則發送ACK確認，未收到則重傳

• TCP的報文頭

• 源端口：發送方的端口號

• 目的端口：接收方的端口號

• 序號：TCP報文段的序號

• 確認序號：接收方接收到了序號爲x的報文段，期待收到序號爲x+1爲起始的報文段。

• 數據偏移：報文段在整個報文中偏移的字節量

• 保留域：備用區

• 標誌位：URG(緊急信息)、ACK(確認標誌位)、PSH(爲1則收到信息收當即交給進程，無需再隊列中等待)、RST(重置標鏈接)、SYN(請求鏈接)、FIN(結束鏈接)

• 檢驗和：檢驗數據是否正確

• TCP的三次握手

TCP是面向鏈接的協議，在進行三次握手的過程後，TCP將創建一條 全雙工的鏈接。爲何要進行三次握手呢？
其一，主要是爲了確認 客戶機和 服務器同時具有發送和接收的能力， 第一次握手， 服務器確認了 客戶機的 發送能力，第二次握手， 客戶機確認了 服務器的 接收能力和 發送能力，第三次握手， 服務器確認了 客戶機的 接收能力。
其二，是須要初始化seq的序號，以避免在正式傳輸中出現亂序。

三次握手過程以下：

1.客戶機首先向服務器發送鏈接請求，此時 SYN標誌位爲 1，且 seq=x， x爲一個大於等於1的正整數，此時服務器爲 Listen狀態，客戶端處於 SYN-SENT狀態。

2.服務器收到了來自客戶機的請求，返回應答，此時 SYN標誌位爲 1， ACK標誌位爲 1， ack=x+1（表明指望收到起始爲seq=x+1的報文段），seq=y，此時服務器處於 SYN-RCVD狀態，客戶端處於 ESTABLISHED狀態。

3.客戶機收到了服務器返回的應答報文，因而發送本身的應答報文，響應服務器的應答，此時 ACK標誌位爲 1， seq爲 x+1（響應ack需求）， ack= y+1（表示指望從服務器獲取y+1爲起始的報文段），此時服務器處於 ESTABLISHED狀態。完成三次握手。

• TCP的四次揮手

四次揮手由客戶端或服務端任意一端close。

過程（假設由客戶端主動關閉）

1. 客戶端發送關閉鏈接請求，此時 FIN標誌位爲 1， seq=u。

2. 服務端返回應答報文，此時 ACK標誌位爲 1， seq= v， ack= u+1（表示指望獲得u+1爲起始的報文段），等待一段時間，而且傳送剩餘數據（若是有的話）。

3. 服務端發送關閉鏈接請求，此時 FIN標誌位爲 1， ACK標誌位爲 1， seq=w， ack= u+1。

4. 客戶端返回應答請求，此時 ACK標誌位爲 1， seq= u+1， ack= w+1。發送事後 服務端當即關閉鏈接， 客戶端等待一段時間（2MSL，一分鐘左右），肯定後續無數據傳送，則自行關閉鏈接。

>爲何須要有2MSL的等待時間？
>1.確保對方收到本身的ACK，若是對方未收到ACK則會重發FIN請求，一來一回正好爲2ML。
>2.避免新舊鏈接混淆。

>爲何須要四次揮手？
>由於確保服務器端和客戶端都有FIN和ACK。
複製代碼

• SYN Flood洪泛攻擊
  

  其原理是：例用三次握手的規則，在客戶機向服務器發送請求後，在服務器發送SYN-ACK後下線，服務器則沒法收到ACK確認，服務器段則會不斷重試，重試間隔爲1s,2s,4s,8s,16s,32s，在linux默認情況下會等待63s，若是有大量的鏈接重複此過程，則會形成服務器鏈接隊列耗盡，這就是洪泛攻擊的原理。
  防禦措施：linux下設置了TCP_SYN_Cookies參數，若爲正常鏈接，客戶機發回SYN Cookie，若是爲異常鏈接，就不發回，但也不會影響到鏈接隊列。
  
  創建鏈接後客戶機忽然出現故障：服務器默認「保活機制」，會在必定時間內發送請求，若幾回請求無應答，則將該客戶機標識爲不可達客戶機。

• TCP與UDP區別

  首先先看UDP報文頭：

UDP報文頭由源端口號、目的端口號、報文段長度、檢驗和組成。長度爲8個字節。而TCP爲20個字節。

• UDP的特色

  1.面向非鏈接，傳輸速度快。
  2.支持同時向多個客戶端傳輸信息。
  3.報文段報文頭只有8個字節，額外開銷小。
  4.吞吐量只受限於數據生成速率、傳輸速率以及機器性能。
  5.盡最大努力交付，不保證可靠交付，不須要維持複雜的鏈接狀態表。
  6.面向報文，不對應用程序提交的信息進行拆分或合併。
  

結論：

1.TCP面向鏈接，UDP面向無鏈接
2.TCP可靠，UDP不可靠
3.TCP有序，UDP可能無序
4.TCP速度慢，UDP速度快
5.TCP重量級，UDP輕量級
複製代碼

• TCP中的滑動窗口

  滑動窗口是避免發送方發送過量數據致使接收方緩存沒法接收以致於數據丟失的問題，主要在報文頭的window字段中，接收方會告訴發送方本身的緩存還能夠接收多少數據，而發送方能夠根據這一信息，調整本身將要發送的數據。
  

如上圖所示，發送方窗口分爲三段：
1. LastByteAcked：最後被確認到的數據位置
2. LastByteSent：已發送的數據的最後一個字節位置
3. LastByteWritten：程序向滑動窗口寫入的數據位置
接收方窗口分爲三段：
1. LastByteRead：最後被應用程序讀取到的數據（已經發送ACK）位置
2. NextByteExpected：收到的但還未發送ACK的數據位置
3. LastByteRcvd：已收到的最後一個字節的位置。


計算方式
接收方還可處理量：AdvertisedWindow = MaxRcvBuffer（最大緩存） - (LastByteRcvd-LastByteRead)
發送方可發送量：EffectiveWindow = AdvertiseWindow-(LastByteSent - LastByteAcked)
解讀：
接收方可處理量爲 = 最大緩存 - 已收到的報文段（已收到的最後一個字節的位置-程序讀取到的數據的位置）
發送方可發送量 = 接收方可處理量 - 待確認量（發送方最後發送的字節位置 - 發送了而且已獲取確認的位置）

發送方滑動窗口的四類數據：

1.已發送而且被確認的數據
2.已發送但未獲得確認的數據
3.未發送但接收方贊成發送的數據
4.未發送且接收方拒絕的數據

接收方滑動窗口三類數據

1.接收且已確認的數據

2.未接收但能夠接收的數據

3.未接收且沒法接收的數據

當接收方滑動窗口不足時，發送方是不會移動本身的滑動窗口的，只有當發送方的滑動窗口以前的全部數據都被確認，發送方的滑動窗口才會向後移動，這也是TCP保證數據完整性的重要手段。

HTTP協議

• HTTP簡介

  HTTP：超文本傳輸協議
  1.支持客戶/服務器模式
  2.簡單高效
  3.靈活
  4.無鏈接：限制每次鏈接只處理一個請求，但從HTTP1.1起，默認使用長鏈接。
  5.無狀態
  HTTP版本如今有經常使用的1.0和1.1，還有2.0，1.1在1.0的基礎上作了keep-alive長鏈接技術，而2.0雖然在各類思想上都顯得更加合理，可是1.1基本能知足平常需求且更換2.0消耗大，因此2.0目前並無推廣開。
• HTTP請求報文

請求行：

>請求方式  url   協議版本
  >頭部字段名:值
  >......
  >頭部字段名:值
  >請求正文
複製代碼

例如：

>POST /user HTTP/1.1      //請求行
  >Host: www.baidu.com
  >Content-Type: application/x-www-form-urlencoded
  >Connection: Keep-Alive
  >User-agent: Mozilla/5.0.      //以上是首部行
  >（此處必須有一空行）  //空行分割header和請求內容 
  >name=world   請求體
複製代碼

• HTTP報文頭

• 請求/響應的步驟 1.客戶端鏈接到Web服務器
  2.發送HTTP請求
  3.服務器接受請求並返回HTTP響應
  4.釋放TCP鏈接（若是是keep-alive則保持一段時間）
  5.客戶端解析HTML內容
  

• 關於HTTP的面試題

  1.在瀏覽器地址欄鍵入URL，按下回車後經歷的流程。
  答：首先要進行DNS解析，將訪問的域名解析爲IP地址，解析是由近到遠的，首先在瀏覽器緩存中尋找是否有對應的IP，若是沒有則進入系統緩存，若是沒有則按照路由器緩存->IPS服務器緩存->根域名緩存->頂級域名服務器緩存，這樣一路查找，直到找到了則中止查找，直接返回。而後進行TCP鏈接，默認端口80，進行三次握手（能夠簡單描述三次握手的流程），創建鏈接後發送HTTP請求，服務器處理請求並返回HTTP報文，瀏覽器解析並渲染頁面，最後鏈接結束。

  2.常見的HTTP狀態碼。 答：先分類。
  1xx提示信息--表示請求已接受，繼續處理
  2xx表示成功鏈接
  3xx重定向--要完成請求必須進行更進一步操做
  4xx表示瀏覽器（客戶端）出現錯誤
  5xx表示服務器端出現錯誤
  常見的HTTP狀態碼：
  200 ok，成功鏈接
  400 bad request(客戶端請求語法錯誤，服務器沒法理解)
  401:未經受權
  403:拒絕服務
  404:Not Found
  500內部服務器錯誤
  503：當前不能處理，一段時間後可能能夠恢復正常。
  

  3.GET和POST請求的區別。
  答：1.HTTP報文層面：GET請求信息放在URL後（?XXX=XXX&XX=XXX），POST放在報文體，安全一些（但其實沒什麼區別，抓包能夠直接抓到報文）
  2.數據庫層面：GET符合冪等性（對數據庫一次或屢次操做，結果是一致的）和安全性（對數據庫一次或屢次操做，沒有改變數據庫中的數據），GET是作查詢操做的，不會改變數據庫中的數據。
  3.POST插入，每次請求都有可能不同。
  其餘層面，GET能夠被CDN緩存，被存儲，在服務量巨大的環境下，又有大部分的數據是隻讀的，因此咱們並不想讓服務器徹底處理，就可使用GET請求，但POST不行,POST必須交由服務器處理。

  4.Cookie和Session的區別
  Cookie是客戶端解決方案，由服務器發給客戶端的特殊信息，以文本的形式存放在客戶端。
  Cookie使用過程：
  1.用戶向服務器發送我的識別信息，服務器也向客戶端發送Cookie文件。
  2.客戶端再次發送請求時，也會把cookie發送回去。
  3.服務端會獲取cookie從而生成與客戶端相對應的內容。
  Session 服務端解決方案,Session是在服務器上保存的信息。服務器解析客戶端請求並操做SessionId，按需保存狀態信息。若是客戶端包含SessionId則直接使用，若是不包含則建立一個。
  Session實現方式：
  1.使用Cookie實現
  客戶端向服務端發送請求，服務端返回響應報文並SetCookie，Cookie中含有JSESSIONID-XXXXX，客戶端以後的每次請求都會攜帶這個Cookie，服務端根據這個Cookie中的Session提供響應的內容。
  2.使用URL回寫實現
  使用URL回寫即在URL地址中攜帶JSESSIONID這個參數。
  
  Tomcat同時支持Cookie和URL回寫，默認使用Cookie，當瀏覽器拒絕Cookie時，則使用URL回寫的方式實現Session
  區別：
  Cookie是以文件的形式存儲在客戶端，而Session是在服務器端進行處理的，Session相對Cookie來講比較安全，由於Cookie存儲在客戶端，容易被修改，而Session存在於服務器端，沒法被修改，但Session會佔用服務器資源，影響服務器性能，若是考慮服務器性能優先，則能夠考慮多使用Cookie。

• HTTP和HTTPS區別

  HTTPS：超文本傳輸安全協議
  HTTP:HTTP+TCP+IP
  HTTPS:HTTP+(SSL OR TLS)+TCP+IP
  要說HTTP和HTTPS的區別首先要提到SSL和加密方式。
  

• SSL:Security-Sockets-Layer,安全套接層

  SSL是爲網絡通訊提升安全及數據完整性的一種安全協議，是操做系統對外的API，SSL3.0後改名爲TLS，採用身份驗證和數據加密保證網絡通訊安全和數據的完整性。

• 加密的幾種形式

  • 1.對稱加密 對稱加密是一種能夠進行解密的加密方式，其特色就是，將一個數據按照必定過程加密，那麼按照這個過程的反過程必定能夠將這個數據進行解密。其特色是效率高，但安全性低。
  • 2.非對稱加密 非對稱加密的特色是加密使用的密鑰和解密使用的密鑰是不相同的，即，將一條數據按照必定的過程進行加密，按照這個過程的反過程並不能逆推回加密數據的源數據，而只能經過另外一種特定的方式進行解密，這就是非對稱加密。非對稱加密的安全性高，但效率不如對稱加密。
  • 3.Hash加密 Hash加密，將任意長度的信息轉換爲固定長度的值，其加密的數據是不可逆的，通常平常所用的加密方式是MD5方式。
  • 4.數字簽名 在信息後加一段Hash值，證實某個消息或文件時某人發出的，且能夠證實信息沒有被修改。

• HTTPS使用的加密方式

  HTTPS使用證書+各類加密方式共同加密
  加密的三次握手過程：
  1.瀏覽器將支持的加密算法信息發送給服務器
  2.服務器選擇一套瀏覽器支持的加密方式，以證書的形式回發給瀏覽器。包含CA機構，公鑰，有效期，全部者等。
  3.瀏覽器驗證證書的合法性，並結合證書公鑰，加密信息發送給服務器。
  4.服務器使用私鑰解密，驗證hash，加密響應消息回發瀏覽器
  5.瀏覽器對響應消息進行解密，並對消息進行驗證，以後進行密文交互數據。
  

• 區別
  

  HTTPS須要到CA申請證書，而HTTP不須要。
  HTTPS的證書是須要收費的，HTTP不收費。
  HTTPS默認端口爲443，HTTP默認端口爲80。
  HTTPS爲有狀態協議，HTTP爲無狀態協議。
  

雖然說HTTPS是安全協議，可是HTTPS也未必安全，在瀏覽器默認填充http:// 的狀況下訪問https的網站，請求須要進行跳轉，這個過程當中就有被劫持的風險。但可使用HSTS優化（自行了解）。

Socket

• Socket概念

  Socket是對TCP/IP協議的抽象，是操做系統對外開放的接口，若是必定要按層次來理解Socket的話，Socket位於傳輸層之上，應用層之下。能夠把它理解爲一扇門，各類請求能夠經過這扇門和和系統進行通訊。

• Socket 通訊流程

• Socket 通訊原理

  咱們知道，在進程間通訊咱們能夠經過管道、共享內存等等等等方式，可是不管使用哪種方式，通訊的本質都是須要被通訊的對象有一個能夠惟一標識的標識符。在進程間通訊時，進程的標識符爲PID，而在網絡通訊中，咱們首先要使用IP標識主機，TCP+端口號標識進程。而端口號就至關於門牌號，Socket能夠監聽某個端口來使該進程與某個請求進行交互。而Socket是基於Unix而生的，Unix奉行的宗旨就是，一切皆文件，因此Socket的本質就是在讀寫特定的Socket文件，以達到通訊的目的。

結語

經過上文的敘述，能夠大概瞭解OSI七層網絡模型的「各司其職」、瞭解TCP/IP協議族、還有三次握手四次揮手的整個過程、瞭解洪泛攻擊的原理、TCP/UDP的區別以及TCP中擁塞控制之滑動窗口，還了解了HTTP協議以及HTTP安全協議——HTTPS，還稍微談到了點Socket。 計算機網絡是一門大的學科，上面所說的也不過百分之二三，寥寥而已。可是基本能夠知足平常開發所需。

本文圖片來自網絡，侵刪。

歡迎你們訪問個人我的博客：Object's Blog