網絡知識面面觀

HTTP響應常見狀態碼

博文連接： 網絡知識面面觀

狀態碼	描述
100-199	成功接收請求, 要求客戶端繼續提交下一次請求才能完成整個處理過程
200-299	成功接收請求並已完成整個處理過程，經常使用200
300-399	爲完成請求, 需進一步細化需求: 例如: 請求的資源已經移動一個新地址，經常使用302(重定向)，307 和304(拿緩存)
400-499	客戶端的請求有錯誤, 包含語法錯誤或者不能正確執行。 經常使用404(請求的資源在web服務器中沒有)，403(服務器拒絕訪問, 權限不夠)
500-599	服務器端出現錯誤
200	表示一切正常, 返回的是正常請求結果
302/307	臨時重定向，指出請求的文檔已被臨時移動到別處, 此文檔的新的url在location響應頭中給出
304	未修改，表示客戶端緩存的版本是最新的, 客戶端應該繼續使用它
403	禁止，服務器理解客戶端請求，但拒絕處理它，一般用於服務器上文件或目錄的權限設置所致
404	找不到，服務器上不存在客戶端所請求的資源
500	服務器內部錯誤，服務器端的cgi，asp，jsp等程序發生錯誤

TCP三次握手和四次揮手

• 創建TCP鏈接須要三次握手：首先Client端發送鏈接請求報文，Server端接收鏈接後回覆ACK報文，併爲此次鏈接分配資源。Client端接收到 ACK報文後也向Server端發發送ACK報文，並分配資源，這樣TCP鏈接就創建了。

  • 第一步：客戶端的TCP先向服務器的TCP發送一個鏈接請求報文。這個特殊的報文中不含應用層數據，其首部中的SYN標誌位被置1。另外， 客戶端會隨機選擇一個起始序號seq=x(鏈接請求報文不攜帶數據，但要消耗掉一個序號)。
  • 第二步：服務器端的TCP收到鏈接請求報文後，若贊成創建鏈接，就向客戶端發送請求，併爲該TCP鏈接分配TCP緩存和變量。在確認報文中，SYN和ACK位都被置爲1, 確認好字段的值爲x+1，而且服務器隨機產生起始序號seq=y(確認報文不攜帶數據, 但也要消耗掉一個序號)。確認報文一樣不包含應用層數據。
  • 第三步：當客戶端收到確認報文後，還要向服務器給出確認，而且也要給該鏈接分配緩存和變量。這個報文的ACK標誌位被置爲1，序號字段爲x+1，確認號字段爲y+1。

• 四次揮手

  • 第一步：客戶端打算關閉鏈接，就向其TCP發送一個鏈接釋放報文，並中止再發送數據，主動關閉TCP鏈接，該報文的FIN標誌位被置1，seq=u，它等於前面已經傳送過的數據的最後一個字節的序號加1(FIN報文即便不攜帶數據，也要消耗掉一個序號)。
  • 第二步：服務器接收鏈接釋放報文後即發出確認，確認號是ack=u+1，這個報文本身的序號是v，等於它前面已傳送過的數據的最後一個本身的序號加1。此時，從客戶端到服務器這個方向的鏈接就釋放了，TCP鏈接處於半關閉狀態。但服務器若發送數據，客戶端仍要接收，即從服務器到客戶機的鏈接仍未關閉。
  • 第三步：若服務器已經沒有了要向客戶端發送的數據，就通知TCP釋放鏈接，此時其發出FIN=1的鏈接釋放報文。
  • 第四步: 客戶端收到鏈接釋放報文後，必須發出確認。在確認報文中，ACK字段被置爲1，確認號ack=w+1，序號seq=u+1。此時，TCP鏈接尚未釋放掉，必須通過等待計時器設置的時間2MSL後, A才進入到鏈接關閉狀態。

計算機網絡體系結構

應用層

應用層( application-layer）的任務是經過應用進程間的交互來完成特定網絡應用。應用層協議定義的是應用進程（進程：主機中正在運行的程序）間的通訊和交互的規則。對於不一樣的網絡應用須要不一樣的應用層協議。在互聯網中應用層協議不少，如域名系統 DNS，支持萬維網應用的 HTTP 協議，支持電子郵件的 SMTP 協議等等。咱們把應用層交互的數據單元稱爲報文。

域名系統

域名系統( Domain Name System 縮寫 DNS， Domain Name被譯爲域名)是因特網的一項核心服務，它做爲能夠將域名和 IP地址相互映射的一個分佈式數據庫，可以令人更方便的訪問互聯網，而不用去記住可以被機器直接讀取的 IP數串。

http協議

超文本傳輸協議（ HTTP， HyperText Transfer Protocol)是互聯網上應用最爲普遍的一種網絡協議。全部的 WWW（萬維網） 文件都必須遵照這個標準。

運輸層

運輸層( transport layer)的主要任務就是負責向兩臺主機進程之間的通訊提供通用的數據傳輸服務。應用進程利用該服務傳送應用層報文。「通用的」是指並不針對某一個特定的網絡應用，而是多種應用可使用同一個運輸層服務。因爲一臺主機可同時運行多個線程，所以運輸層有複用和分用的功能。所謂複用就是指多個應用層進程可同時使用下面運輸層的服務，分用和複用相反，是運輸層把收到的信息分別交付上面應用層中的相應進程。

運輸層經常使用的兩種協議TCP UDP

• 傳輸控制協議TCP（Transmisson Control Protocol）--提供面向鏈接的，可靠的數據傳輸服務。
• 用戶數據協議UDP（User Datagram Protocol）--提供無鏈接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）。

TCP的主要特色

• TCP是面向鏈接的。（就好像打電話同樣，通話前須要先撥號創建鏈接，通話結束後要掛機釋放鏈接）；
• 每一條TCP鏈接只能有兩個端點，每一條TCP鏈接只能是點對點的（一對一）；
• TCP提供可靠交付的服務。經過TCP鏈接傳送的數據，無差錯、不丟失、不重複、而且按序到達；
• TCP提供全雙工通訊。TCP容許通訊雙方的應用進程在任什麼時候候都能發送數據。TCP鏈接的兩端都設有發送緩存和接收緩存，用來臨時存放雙方通訊的數據；
• 面向字節流。TCP中的「流」（Stream）指的是流入進程或從進程流出的字節序列。「面向字節流」的含義是：雖然應用程序和TCP的交互是一次一個數據塊（大小不等），但TCP把應用程序接下來的數據僅僅當作是一連串的無結構的字節流。

UDP的主要特色

• UDP是無鏈接的；
• UDP使用盡最大努力交付，即不保證可靠交付，所以主機不須要維持複雜的連接狀態（這裏面有許多參數）；
• UDP是面向報文的；
• UDP沒有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用，如直播，實時視頻會議等）；
• UDP支持一對1、一對多、多對一和多對多的交互通訊；
• UDP的首部開銷小，只有8個字節，比TCP的20個字節的首部要短。

網絡層

• 在計算機網絡中進行通訊的兩個計算機之間可能會通過不少個數據鏈路，也可能還要通過不少通訊子網。網絡層的任務就是選擇合適的網間路由和交換結點， 確保數據及時傳送。在發送數據時，網絡層把運輸層產生的報文段或用戶數據報封裝成分組和包進行傳送。在TCP/IP體系結構中，因爲網絡層使用IP協議，所以分組也叫IP數據報 ，簡稱數據報。
• 互聯網是由大量的異構（heterogeneous）網絡經過路由器（router）相互鏈接起來的。互聯網使用的網絡層協議是無鏈接的網際協議（Intert Prococol）和許多路由選擇協議，所以互聯網的網絡層也叫作網際層或IP層。

數據鏈路層

• 數據鏈路層(data link layer)一般簡稱爲鏈路層。兩臺主機之間的數據傳輸，老是在一段一段的鏈路上傳送的，這就須要使用專門的鏈路層的協議。 在兩個相鄰節點之間傳送數據時，數據鏈路層將網絡層接下來的IP數據報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。每一幀包括數據和必要的控制信息（如同步信息，地址信息，差錯控制等）。
• 在接收數據時，控制信息使接收端可以知道一個幀從哪一個比特開始和到哪一個比特結束。這樣，數據鏈路層在收到一個幀後，就可從中提取數據部分，上交給網絡層。控制信息還使接收端可以檢測到所收到的幀中有無差錯。若是發現差錯，數據鏈路層就簡單地丟棄這個出了差錯的幀，以免繼續在網絡中傳送下去，浪費網絡資源。若是須要改正數據在鏈路層傳輸時出現差錯（這就是說，數據鏈路層不只要檢錯，並且還要糾錯），那麼就要採用可靠性傳輸協議來糾正出現的差錯。這種方法會使鏈路層的協議複雜些。

物理層

• 在物理層上所傳送的數據單位是比特。 物理層(physical layer)的做用是實現相鄰計算機節點之間比特流的透明傳送，儘量屏蔽掉具體傳輸介質和物理設備的差別。使其上面的數據鏈路層沒必要考慮網絡的具體傳輸介質是什麼。「透明傳送比特流」表示經實際電路傳送後的比特流沒有發生變化，對傳送的比特流來講，這個電路好像是看不見的。
• 在互聯網使用的各類協中最重要和最著名的就是TCP/IP兩個協議。

計算機網絡的七層體系結構圖

HTTP與HTTPS的區別

HTTP協議運行在TCP之上，明文傳輸，客戶端與服務器端都沒法驗證對方的身份；HTTPS是身披SSL(Secure Socket Layer)外殼的HTTP，運行於SSL上，SSL運行於TCP之上，是添加了加密和認證機制的HTTP。兩者之間存在以下不一樣：

• 端口不一樣：HTTPS與HTTP使用不一樣的鏈接方式，用的端口也不同，前者是80，後者是443；
• 資源消耗：和HTTP通訊相比，HTTPS通訊會因爲加減密處理消耗更多的CPU和內存資源；
• 開銷：HTTPS通訊須要證書，而證書通常須要向認證機構購買；
• HTTPS的加密機制是一種共享密鑰加密和公開密鑰加密並用的混合加密機制。

對稱加密與非對稱加密

• 對稱密鑰加密是指加密和解密使用同一個密鑰的方式，這種方式存在的最大問題就是密鑰發送問題，即如何安全地將密鑰發給對方；而非對稱加密是指使用一對非對稱密鑰，即公鑰和私鑰，公鑰能夠隨意發佈，但私鑰只有本身知道。發送密文的一方使用對方的公鑰進行加密處理，對方接收到加密信息後，使用本身的私鑰進行解密。
• 因爲非對稱加密的方式不須要發送用來解密的私鑰，因此能夠保證安全性；可是和對稱加密比起來，它很是的慢，因此咱們仍是要用對稱加密來傳送消息，但對稱加密所使用的密鑰咱們能夠經過非對稱加密的方式發送出去。

TCP協議如何保持傳輸的可靠性

TCP提供一種面向鏈接的、可靠的字節流服務。其中，面向鏈接意味着兩個使用 TCP的應用（一般是一個客戶和一個服務器）在彼此交換數據以前必須先創建一個 TCP鏈接。在一個 TCP鏈接中，僅有兩方進行彼此通訊；而字節流服務意味着兩個應用程序經過 TCP連接交換 8bit字節構成的字節流， TCP不在字節流中插入記錄標識符。

對於可靠性，TCP經過如下方式進行保證：

• 數據包校驗：目的是檢測數據在傳輸過程當中的任何變化，若校驗出包有錯，則丟棄報文段而且不給出響應，這時TCP發送數據端超時後會重發數據；
• 對失序數據包重排序：既然TCP報文段做爲IP數據報來傳輸，而IP數據報的到達可能會失序，所以TCP報文段的到達也可能會失序。TCP將對失序數據進行從新排序，而後才交給應用層；
• 丟棄重複數據：對於重複數據，可以丟棄重複數據；
• 應答機制：當TCP收到發自TCP鏈接另外一端的數據，它將發送一個確認。這個確認不是當即發送，一般將推遲幾分之一秒；
• 超時重發：當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。若是不能及時收到一個確認，將重發這個報文段；
• 流量控制：TCP鏈接的每一方都有固定大小的緩衝空間。TCP的接收端只容許另外一端發送接收端緩衝區所能接納的數據，這能夠防止較快主機導致較慢主機的緩衝區溢出，這就是流量控制。TCP使用的流量控制協議是可變大小的滑動窗口協議。

查找域名對應的IP地址

這一步包括 DNS具體的查找過程，包括：瀏覽器緩存->系統緩存->路由器緩存...

• 瀏覽器搜索本身的DNS緩存（維護一張域名與IP地址的對應表）；
• 搜索操做系統中的DNS緩存（維護一張域名與IP地址的對應表）；
• 搜索操做系統的hosts文件（ Windows環境下，維護一張域名與IP地址的對應表）；

• 操做系統將域名發送至LDNS（本地區域名服務器），LDNS查詢本身的DNS緩存（通常查找成功率在80%左右），查找成功則返回結果，失敗則發起一個迭代DNS解析請求：

  • LDNS向 Root Name Server（根域名服務器，如com、net、org等的解析的頂級域名服務器的地址）發起請求，此處，Root Name Server返回com域的頂級域名服務器的地址；
  • LDNS向com域的頂級域名服務器發起請求，返回baidu.com域名服務器地址；
  • LDNS向baidu.com域名服務器發起請求，獲得www.baidu.com的IP地址；
• LDNS將獲得的IP地址返回給操做系統，同時本身也將IP地址緩存起來；
• 操做系統將IP地址返回給瀏覽器，同時本身也將IP地址緩存起來。

從輸入URL到頁面加載發生了什麼

整體來講分爲如下幾個過程:

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

HTTP的幾種請求方法的用途

• GET方法：發送一個請求來取得服務器上的某一資源
• POST方法：向URL指定的資源提交數據或附加新的數據
• PUT方法：跟POST方法很像，也是向服務器提交數據。可是，它們之間有不一樣。PUT指定了資源在服務器上的位置，而POST沒有
• HEAD方法：只請求頁面的首部
• DELETE方法：刪除服務器上的某資源
• OPTIONS方法：它用於獲取當前URL所支持的方法。若是請求成功，會有一個Allow的頭包含相似「GET,POST」這樣的信息
• TRACE方法：TRACE方法被用於激發一個遠程的，應用層的請求消息迴路
• CONNECT方法：把請求鏈接轉換到透明的TCP/IP通道

五類IP地址的範圍

IP地址分爲A,B,C,D,E五類。

• 網絡號：用於識別主機所在的網絡；
• 主機號：用於識別該網絡中的主機。

其中A類分配給政府機關使用，B類地址給大中型企業使用，C類地址給我的使用。這三種是主要的。

IP地址分爲五類，A類保留給政府機構，B類分配給中等規模的公司，C類分配給任何須要的人，D類用於組播，E類用於實驗，各種可容納的地址數目不一樣。

其中A類、B類、和C類這三類地址用於TCP/IP節點，其它兩類D類和E類被用於特殊用途。A、B、C三類IP地址的特徵：當把IP地址寫成二進制形式時，A類地址的第一位老是0，B類地址的前兩位老是10，C類地址的前三位老是110。

A類地址

1. A類地址第1字節爲網絡地址，其它3個字節爲主機地址。
2. A類地址範圍：1.0.0.1—126.155.255.254

3. A類地址中的私有地址和保留地址：

   • 10.X.X.X是私有地址（所謂的私有地址就是在互聯網上不使用，而被用在局域網絡中的地址）
   • 127.X.X.X是保留地址，用作循環測試用的

B類地址

1. B類地址第1字節和第2字節爲網絡地址，其它2個字節爲主機地址。
2. B類地址範圍：128.0.0.1—191.255.255.254。

3. B類地址的私有地址和保留地址：

   • 172.16.0.0—172.31.255.255是私有地址
   • 169.254.X.X是保留地址。若是你的IP地址是自動獲取IP地址，而你在網絡上又沒有找到可用的DHCP服務器。就會獲得其中一個IP

C類地址

1. C類地址第1字節、第2字節和第3個字節爲網絡地址，第4個個字節爲主機地址。另外第1個字節的前三位固定爲110。
2. C類地址範圍：192.0.0.1—223.255.255.254。

3. C類地址中的私有地址：

   • 192.168.X.X 是私有地址。

D類地址

1. D類地址不分網絡地址和主機地址，它的第1個字節的前四位固定爲1110。
2. D類地址範圍：224.0.0.1—239.255.255.254

E類地址

1. E類地址也不分網絡地址和主機地址，它的第1個字節的前五位固定爲11110。
2. E類地址範圍：240.0.0.1—255.255.255.254

HTTP長鏈接、短鏈接

• 在HTTP/1.0中默認使用短鏈接。也就是說，客戶端和服務器每進行一次HTTP操做，就創建一次鏈接，任務結束就中斷鏈接。當客戶端瀏覽器訪問的某個HTML或其餘類型的Web頁中包含有其餘的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會從新創建一個HTTP會話。
• 而從HTTP/1.1起，默認使用長鏈接，用以保持鏈接特性。使用長鏈接的HTTP協議，會在響應頭加入這行代碼：Connection:keep-alive
• 在使用長鏈接的狀況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經創建的鏈接。Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間。實現長鏈接須要客戶端和服務端都支持長鏈接。
• HTTP協議的長鏈接和短鏈接，實質上是TCP協議的長鏈接和短鏈接。

如何理解HTTP協議是無狀態的

HTTP協議是無狀態的，指的是協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。也就是說，打開一個服務器上的網頁和上一次打開這個服務器上的網頁之間沒有任何聯繫。 HTTP是一個無狀態的面向鏈接的協議，無狀態不表明 HTTP不能保持 TCP鏈接，更不能表明 HTTP使用的是 UDP協議（無鏈接）。

各類協議與HTTP協議之間的關係

Socket鏈接與HTTP鏈接的聯繫與區別

• 一般狀況下Socket鏈接就是TCP鏈接，所以Socket鏈接一旦創建，通訊雙方便可開始相互發送數據內容，直到雙方鏈接斷開。但在實際網絡應用中，客戶端到服務器之間的通訊每每須要穿越多箇中間節點，例如路由器、網關、防火牆等，大部分防火牆默認會關閉長時間處於非活躍狀態的鏈接而致使Socket鏈接斷連，所以須要經過輪詢告訴網絡，該鏈接處於活躍狀態。
• 而HTTP鏈接使用的是「請求—響應」的方式，不只在請求時須要先創建鏈接，並且須要客戶端向服務器發出請求後，服務器端才能回覆數據。
• 不少狀況下，須要服務器端主動向客戶端推送數據，保持客戶端與服務器數據的實時與同步。此時若雙方創建的是Socket鏈接，服務器就能夠直接將數據傳送給客戶端；若雙方創建的是HTTP鏈接，則服務器須要等到客戶端發送一次請求後才能將數據傳回給客戶端，所以，客戶端定時向服務器端發送鏈接請求，不只能夠保持在線，同時也是在「詢問」服務器是否有新的數據，若是有就將數據傳給客戶端。

HTTP(TCP) 報文結構

例如一個 100kb的 HTML文檔須要傳送到另一臺計算機，並不會整個文檔直接傳送過去，可能會切割成幾個部分，好比四個分別爲 25kb的數據段。而每一個數據段再加上一個 TCP首部，就組成了 TCP報文。 TCP報文 ( Segment)，包括首部和數據部分。

首部：

• 源端口 source port
• 目的端口 destination port
• 序號 sequence number
• 確認號 acknowledgment number
• 數據偏移 offset
• 保留 reserved
• 標誌位 tcp flags
• 窗口大小 window size
• 檢驗和 checksum
• 緊急指針 urgent pointer
• 選項 tcp options

HTTP的緩存機制

HTTP的緩存主要利用header裏的兩個字段來控制：

• Cache-control主要包含以及幾個字段：

  • private：則只有客戶端能夠緩存
  • public：客戶端和代理服務器均可以緩存
  • max-age：緩存的過時時間
  • no-cache：須要使用對比緩存來驗證緩存數據
  • no-store：全部內存都不會進行緩存

• ETag：即用來進行對比緩存，Etag是服務端資源的一個標識碼

  • 當客戶端發送第一次請求時服務端會下發當前請求資源的標識碼Etag，下次再請求時，客戶端則會經過header裏的If-None-Match將這個標識碼Etag帶上，服務端將客戶端傳來的Etag與最新的資源Etag作對比，若是同樣，則表示資源沒有更新，返回304。

經過Cache-control和Etag的配合來實現HTTP的緩存機制。

Cookie

Cookie就是用來在本地緩存記住一些狀態的，一個 Cookie通常都包含 domain(所屬域)、 path、 Expires(過時時間)等幾個屬性。服務端能夠經過在響應頭 set-cookies將狀態寫入客戶端的 Cookie中。

HTTP 2.0與HTTP 1.x相比有什麼優勢

• 二進制格式：HTTP 1.x是文本協議，而HTTP 2.0是二進制以幀爲基本單位，是一個二進制協議，一幀中除了包含數據外同時還包含該幀的標識：Stream Identifier，即標識了該幀屬於哪一個request，使得網絡傳輸變得十分靈活。

• 多路複用: 一個很大的改進，原先HTTP 1.x一個鏈接一個請求的狀況有比較大的侷限性，也引起了不少問題，如創建多個鏈接的消耗以及效率問題。

  • HTTP 1.x爲了解決效率問題，可能會盡可能多的發起併發的請求去加載資源，然而瀏覽器對於同一域名下的併發請求有限制，而優化的手段通常是將請求的資源放到不一樣的域名下來突破這種限制。
  • 而HTTP 2.0支持的多路複用能夠很好的解決這個問題，多個請求共用一個TCP鏈接，多個請求能夠同時在這個TCP鏈接上併發，一個是解決了創建多個TCP鏈接的消耗問題，一個也解決了效率的問題。那麼是什麼原理支撐多個請求能夠在一個TCP鏈接上併發呢？基本原理就是上面的二進制分幀，由於每一幀都有一個身份標識，因此多個請求的不一樣幀能夠併發的無序發送出去，在服務端會根據每一幀的身份標識，將其整理到對應的request中。
• header 頭部壓縮：主要是經過壓縮header來減小請求的大小，減小流量消耗，提升效率。由於以前存在一個問題是，每次請求都要帶上 header，而這個header中的數據一般是一成不變的。
• 支持服務端推送

流量控制

流量控制是對一條通訊路徑上的流量進行控制，就是發送方經過獲取接收方的回饋來動態調整發送的速率，來達到控制流量的效果，其目的是保證發送者的發送速度不超過接收者的接收速度。

擁塞控制

擁塞控制是對整個通訊子網的流量進行控制，屬於全局控制。

1. 慢開始+擁塞避免

2. 快重傳+快恢復

   • 快重傳：重傳機制都是等到超時還未收到接收方的回覆，纔開始進行重傳。而快重傳的設計思路是：若是發送方收到3個重複的接收方的ACK，就能夠判斷有報文段丟失，此時就能夠當即重傳丟失的報文段，而不用等到設置的超時時間到了纔開始重傳，提升了重傳的效率。
   • 快恢復：擁塞控制會在網絡擁塞時將擁塞窗口降爲1，從新慢開始，這樣存在的一個問題就是網絡沒法很快恢復到正常狀態。快恢復就是來優化這個問題的，使用快恢復，則出現擁塞時，擁塞窗口只會下降到新的慢開始門閥值（即12），而不會降爲1，而後直接開始進入擁塞避免加法增加。

原文連接： 先後端均適用的網絡知識點大全