前端基礎

【一】什麼是前端

【1】什麼是前端

• 任何與使用者直接打交道的操作介面都可以稱之為前端
  • 比如電腦介面、手機介面、平板介面

【2】什麼是後端

• 不直接與使用者打交道的用於執行真正業務邏輯的程式碼
  • 比如C程式碼，Java程式碼，Python程式碼

【3】前端基礎

【二】Web伺服器

【1】在瀏覽器中輸入網址（URL）

• 使用者在瀏覽器的位址列中輸入目標網址（例如：https://www.example.com），並按下Enter鍵。,-gi1h704ckkoewj6z5ifkn./)

【2】DNS解析

• 瀏覽器會先檢查是否有快取過該域名的IP地址，如果有快取則直接使用，否則瀏覽器會向本機的DNS快取查詢域名對應的IP地址。
• 如果找不到，則瀏覽器會向遞迴解析伺服器傳送DNS查詢請求。
• 這個過程中可能包括本地Hosts檔案的解析、本地DNS快取的查詢以及頂級域名伺服器（Root DNS Server），依次透過多級的DNS伺服器逐步解析出目標域名的IP地址。

• 例如：
  • 使用者輸入的URL為https://www.example.com，經過DNS解析後得到IP地址為192.0.2.123。

【3】建立TCP連線

• 瀏覽器使用獲取到的IP地址和預設的埠號（通常是80）與目標伺服器建立TCP連線。
• 這個過程涉及到TCP/IP的三次握手，確保客戶端和伺服器之間建立穩定可靠的連線。

【4】傳送HTTP請求

• 一旦TCP連線建立成功，瀏覽器會傳送一個HTTP請求給目標伺服器。
• 該請求會包含一些重要資訊，例如請求方法（GET、POST等）、請求頭（User-Agent、Cookies等）和請求體（如果有資料需要上傳）。

• 例如：
  • 瀏覽器傳送一個GET請求給伺服器，請求的資源路徑為/。

【5】伺服器處理請求

• 目標伺服器接收到瀏覽器傳送的HTTP請求後，會根據請求的內容進行相應的處理。
• 這個過程會涉及到後端服務的執行，例如使用Nginx作為反向代理伺服器將請求轉發給後端Web框架（如Django、Flask等）。

【6】伺服器傳送HTTP響應

• 伺服器處理完請求後，會生成一個HTTP響應，該響應包括狀態碼、響應頭和響應體。
• 狀態碼錶示伺服器對請求的處理結果，響應頭包含了一些元資訊，而響應體包含了請求的實際內容。伺服器將該HTTP響應傳送回客戶端瀏覽器。

【7】接收並渲染頁面

• 瀏覽器接收到伺服器傳送的HTTP響應後，會根據響應的內容進行解析和渲染。
• 瀏覽器會根據Content-Type等響應頭資訊確定如何展示內容，如果內容是HTML頁面，則瀏覽器會解析HTML標記、載入外部樣式表和指令碼檔案，並將頁面渲染出來。

【8】斷開TCP連線

• 頁面渲染完成後，如果沒有keep-alive機制或者WebSocket等長連線技術，瀏覽器會傳送一個關閉TCP連線的請求給伺服器，進而兩者斷開連線。

• 需要注意的是，上述過程中還涉及到重定向、HTTPS安全連線以及其他一些特殊情況的處理，但基本的流程如上所述。
• 此外，還有一些細節可以進一步擴充套件和討論，例如HTTP/2、HTTP/3等協議的特點及最佳化。

【三】從瀏覽器輸入一個地址到看到頁面資訊的詳細過程

【1】總覽

• 瀏覽器先分析超連結中的URL:分析域名是否規範
• 瀏覽器向DNS請求解析請求解析 https://www.example.com/index.html 中的ip地址
• DNS將解析出的ip地址返回瀏覽器
• 瀏覽器與伺服器建立TCP連線（80埠，三次握手）
• 伺服器接收到瀏覽器請求文件（GET/index.html）進行處理
• 伺服器給出響應，將文件index.html傳送給瀏覽器，瀏覽器進行解封裝。
• 瀏覽器渲染 index.html 中的內容（渲染頁面）
• 釋放TCP連線（四次揮手）

【2】瀏覽器先分析超連結中的URL

（1）輸入的瀏覽器網址分析

• 首先，URL是由協議、主機和埠（預設為80）以及檔名三部門構成。
• 如：https://www.example.com:80/index.html
  • 協議(https://www.example.com):埠(80)/詳細地址
• 我們可以理解為 URL 就是我們在瀏覽器中輸入的地址，而輸入的URL中就攜帶者域名
  • 比如 https://www.baidu.com 訪問百度官網
  • 其中 www.baidu.com 就是百度伺服器的域名

（2）簡析URL的組成

• URL 的元素組成也和上述大致相似
  • 其中 訪問協議 和 域名是必須的，目錄名和檔名可以忽略

• 相應的 URL 請求對應在伺服器上的檔案路徑如下

（3）分析域名是否規範

• 首先，瀏覽器做的第一步就是會解析URL得到裡面的引數，分析域名是否規範，並將域名和需要的請求的資源分離開來，從而瞭解需要請求的是哪個伺服器，請求的是伺服器上的什麼資源等等。
• 瀏覽器對URL進行解析之後，瀏覽器確定了目標伺服器和檔名，接下來就是需要根據這些訊息封裝成一個HTTP請求報文傳送出去。
• HTTP請求報文的例子為：

• 對於這個封裝，其中涉及到計算機網路中的知識。
  • 就是說傳送端在層與層之間傳輸資料的時候，每經過一層必定會被打上一個該層所屬的首部資訊。
  • 反之，接收端在層與層之間傳輸資料的時候，沒經過一層就會把該層對應的首部訊息消除。

【2】DNS解析

（1）DNS 解析簡解

• 封裝好HTTP請求報文之後，就需要獲取目標伺服器的ip地址（ip包裡面有ip地址），雖然解析得到了域名，按理瀏覽器應該已經知道了目標伺服器是誰了。
• 但是實際上，域名並不是目標伺服器真正意義上的地址，網際網路上每一臺計算機都被全世界唯一IP地址標識著，但是IP地址並不方便記憶，所以才設計出了域名。
• 但是雖然域名容易被使用者所接受和使用，但是計算機只能識別純數字構成的IP地址，不能直接讀取域名。
• 所以如果只是知道域名也不知道這個請求會被髮送到哪裡去。
• 那麼就需要解析域名獲取目標伺服器的IP地址。
• 此時的瀏覽器就會向DNS請求解析請求解析 https://www.example.com:80/index.html 中的 IP地址

• 舉個形象的例子

  • 我們經常透過 ping www.baidu.com 來檢驗我們的伺服器是否能連通外網
  • 其實在 ping www.baidu.com 過程中，就發生了 DNS 解析操作

  C:\Users\Administrator>ping www.baidu.com
      
  正在 Ping www.a.shifen.com [180.101.50.188] 具有 32 位元組的資料:
  來自 180.101.50.188 的回覆: 位元組=32 時間=10ms TTL=52
      
  180.101.50.188 的 Ping 統計資訊:
      資料包: 已傳送 = 1，已接收 = 1，丟失 = 0 (0% 丟失)，
  往返行程的估計時間(以毫秒為單位):
      最短 = 10ms，最長 = 10ms，平均 = 10ms
  

  • 我們可以看到，百度的 IP 地址就是

    180.101.50.188
    

    • 我們透過 在瀏覽器位址列輸入 http://180.101.50.188/
    • 等價於，我們在瀏覽器位址列輸入 https://www.baidu.com/

（2）DNS域名解析IP地址的過程

• 1.客戶端首先檢視瀏覽器快取，看有沒有該域名對應的IP地址
• 2.如果沒有的話，檢視本地host檔案，看有沒有該域名對應的IP地址
• 3.如果沒有的話，客戶端向本地域名伺服器進行遞迴查詢，查詢該域名對應的IP地址
• 4.如果還是沒有的話，本地域名伺服器向根域名伺服器進行迭代查詢，根域名伺服器通常是把自己知道的頂級域名伺服器的IP地址告訴本地域名伺服器
• 5.本地域名伺服器再向頂級域名伺服器查詢，頂級域名伺服器要麼給出所要查詢的IP地址，要麼告訴本地伺服器下一步應該向哪一個許可權域名伺服器進行查詢
• 6.本地域名伺服器向許可權域名伺服器進行查詢，然後得到了所要解析的IP地址
• 7.本地域名伺服器將該域名和對應的IP地址寫入自身快取，然後將解析的IP地址返回給客戶端。

1、首先本地電腦會檢查瀏覽器DNS快取中有沒有這個域名對應的解析過的IP地址。

• 如果快取的中有，這個解析過程就結束。
  • 快取中維護著一張域名與 IP 地址的對應表。瀏覽器快取域名也是有限制的，不僅瀏覽器快取大小有限制，而且快取的時間也有限制，通常情況下，快取時間為幾分鐘到幾個小時或者更長。
  • 域名被快取的時間限制可以透過TTL屬性來設定，這個快取時間太長、太短都不太好。
    • 如果時間太長，一旦域名被解析到的ip發生變化，就會導致客戶端快取的域名無法解析到變化後的ip地址，導致該域名不能正常解析，這段時間內會有一部分使用者無法訪問網站。
    • 如果設定時間太短，會導致使用者每次訪問網站都需要重新解析一次域名，都會影響到使用者的使用。

2、如果瀏覽器快取中沒有資料，瀏覽器會查詢hosts檔案（作業系統快取中：hosts檔案）看有沒有該域名對應的IP地址。

• 我們的作業系統也有一個域名解析的過程
  • 在Linux中可以透過/etc/hosts檔案中來設定
  • Windows中可以透過配置C:\Windows\System32\drivers\etc\hosts檔案來設定，使用者可以將任何域名解析到任何能夠訪問到的ip地址。
• 我們可以在測試的時候將一個域名解析到一臺測試伺服器上，這樣不用修改任何程式碼就能測試到單獨伺服器上的程式碼的業務邏輯是否正確。
• 正是因為有這種本地DNS解析的規程，所以就可能有駭客透過修改使用者的域名來把特定的域名解析到他指定的ip地址上，導致域名被劫持。

3、如果本地快取檔案中也沒有的話，就需要使用到網路配置中的“DNS伺服器地址”。

• 作業系統會把這個域名傳送給本地DNS伺服器。
  • 每個完整的內網通常都會配置本地DNS伺服器
    • 例如使用者是在學校或者單位接入網際網路，那麼使用者的本地DNS伺服器肯定是在學校或者工作單位裡面。
    • 它們一般都會快取域名解析結果，當然快取時間是受到域名的失效時間控制的。
    • 後面的DNS迭代和遞迴也是由本地DNS伺服器負責的。
• Windows的配置在：
  • 控制皮膚
  • 網路共享中心
  • 更改介面卡
  • 選擇目標介面卡右鍵選擇屬性
  • Internet協議版本4(TCP/IPv4)
  • 配置DNS地址。

• Linux中的配置在：/etc/resolv.conf

[root@VM-8-11-opencloudos ~]# cat /etc/resolv.conf

# Generated by NetworkManager
nameserver 183.60.83.19
nameserver 183.60.82.98

• 本地域名伺服器記錄的解析如果有就會直接返回，如果沒有解析，就會去根域名伺服器（www頂級域.baidu：二級域.com）找全球13臺，依次迭代查詢得到最後的ip解析地址 ，透過迭代去查詢的。
• （注意：主機和本地域名伺服器之間的查詢方式是遞迴查詢）

4、如果DNS伺服器中還是沒有，本地域名伺服器向根域名伺服器進行迭代查詢

（注意：本地域名伺服器和其他域名伺服器之間的查詢方式是迭代查詢，防止根域名伺服器壓力過大）

• 透過以下方式進行迭代查詢：
  • 首先本地域名伺服器向根域名伺服器發起請求，根域名伺服器是最高層次的，它並不會直接指明這個域名對應的 IP 地址，而是返回頂級域名伺服器的地址，也就是說給本地域名伺服器指明一條道路，讓他去這裡尋找答案。
  • 本地域名伺服器拿到這個頂級域名伺服器的地址後，就向其發起請求，獲取許可權域名伺服器的地址
  • 本地域名伺服器根據許可權域名伺服器的地址向其發起請求，最終得到該域名對應的IP地址

5、本地域名伺服器將得到的IP地址返回給作業系統，同時自己將IP地址快取起來

6、作業系統將 IP 地址返回給瀏覽器，同時自己也將IP地址快取起來

7、至此，瀏覽器就得到了域名對應的 IP地址，並將IP地址快取起來

（補充）遞迴查詢和迭代查詢的區別

• DNS客戶端和本地名稱伺服器是遞迴查詢，而本地名稱伺服器和其他名稱伺服器之間是迭代查詢。

（補充）DNS遞迴名稱解析

• 在DNS遞迴解析中
  • 當所配置的本地名稱伺服器解析不了時，後面的查詢工作是由本地名稱伺服器替代DNS客戶端進行的（以“本地名稱伺服器”為中心），只需要本地名稱伺服器向DNS客戶端返回最終的查詢結果即可。

（補充）DNS迭代名稱解析（查詢）：

• 迭代查詢的所有查詢工作全部是DNS客戶端自己進行（以“DNS客戶端”自己為中心），在其中一條件滿足之後就會採用迭代名稱解析方式。

（補充）小結

• 在查詢本地名稱伺服器時，如果客戶端的請求報文中沒有申請使用遞迴查詢，即在DNS請求報頭部的RD欄位沒有置1。
  • 相當於說“你都沒有主動要求我為你進行遞迴查詢，我當然不會為你工作了”。
• 客戶端在DNS請求報文中申請使用的是遞迴查詢（也就是RD欄位置1了），但在所配置的本地名稱伺服器上是禁用遞迴查詢（DNS伺服器一般預設支援遞迴查詢的），即在應答DNS報文頭部的RA欄位置0。
• 其中，DNS 使用的是 UDP 協議，也就是說上面各種請求的轉發，都是基於 UDP 這個無連線協議的。

【3】DNS將解析出的ip地址返回瀏覽器

【4】瀏覽器與伺服器建立TCP連線（80埠，三次握手）

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

【5】瀏覽器請求文件（GET/index.html）

• TCP三次握手完成之後，瀏覽器與伺服器之間就會建立起一個可靠的虛擬通道，於是瀏覽器就可以傳送自己的HTTP請求了。
• HTTP 請求報文或者響應報文在 TCP 連線通道上進行傳輸的時候，由於這些報文比較大，為了更容易和準確可靠的傳輸，TCP 會將 HTTP 報文按序號分割成若干報文段並加上 TCP 首部，分別進行傳輸。
• 接收方在收到這些報文段後，按照序號以原來的順序重組 HTTP 報文。
• HTTP中的請求報文：
  • 請求報文：客戶端（瀏覽器）向web伺服器傳送的請求報文。報文的所有欄位都是ASCII碼。
  • 請求報文中可以攜帶資料，也可以不攜帶資料。
  • 請求報文由請求行、請求頭部、空行和請求包體 4 個部分組成。

• 首部行：用來說明瀏覽器、伺服器或報文主體是一些資訊。
• 首部欄位：請求報文裡。請求的時候需要攜帶資料告訴伺服器自己需要訪問的東西。攜帶的資料是透過頭部欄位(header)去訪問。
• 請求報文裡的欄位
  • Host:表示訪問的主機。表示訪問的那個網址---》URL（透過域名dns或者ip地址）
  • connection：close或者keepalive 表示當前是連線還是斷開的狀態。
  • user-agent ：表示使用的是什麼使用者代理---》瀏覽器（本質上使用的是什麼瀏覽器）：請求欄位，用來描述發起請求的客戶端，比如是Chrome、Mozilla、Safari，或者是spider。
  • Accept-language.cn ：客戶端可接受的自然語言。
  • Accept-encode.cn：客戶端可接受的編碼壓縮格式;接收的編碼、接收的型別的檔案（表示的是壓縮）
  • cookie：儲存於客戶端擴充套件欄位，向同一域名的服務端傳送屬於該域的cookie;
• 請求行：方法、URL、版本
  • 常見的方法為：GET、POST、PUT、DELETE等
  • 常見的版本為：HTTP1.0、HTTP1.1、HTTP2.0等

【6】伺服器給出響應，將文件index.html傳送給瀏覽器，瀏覽器進行解封裝。

• 瀏覽器的 HTTP 請求報文透過 TCP 三次握手建立的連線通道被切分成若干報文段分別傳送給伺服器，伺服器在收到這些報文段後，按照序號以原來的順序重組 HTTP 請求報文。
• 然後處理並返回一個 HTTP 響應。
  • 當然，HTTP 響應報文也要經過和 HTTP 請求報文一樣的過程。
• HTTP的響應報文：response響應報文，即從Web伺服器到客戶機(瀏覽器)的應答。報文的所有欄位都是ASCII碼。

• HTTP 響應報文由狀態行、響應頭部、空行 和 響應包體 4 個部分組成
• reposes裡面的狀態碼：重要
• 狀態行：狀態碼（列舉常見的）
  • 200 : 響應成功 301：永久重定向,請求資源的url已永久更改，在響應中給出了新的url。
  • 302：臨時重定向。
  • 304：not modify（未改變，和快取裡面的是一樣的）
  • 404：not found ，網頁不存在。
  • 502：bad gateway （閘道器故障），但是後端的real server掛了。
  • 500：內部伺服器錯誤。（伺服器崩潰了）
• 響應頭部：響應欄位：
• Date：日期，通用欄位，但通常出現在響應頭裡，表示 HTTP 報文建立的時間，客戶端可以使用這個時間再搭配其他欄位決定快取策略
• Server：Server 響應報頭域包含了伺服器用來處理請求的軟體資訊及其版本。它和 User-Agent 請求報頭域是相對應的，前者傳送伺服器端軟體的資訊，後者傳送客戶端軟體(瀏覽器)和作業系統的資訊。
• cache-control: max-age=30
• content-type：傳遞過來的型別。

【7】瀏覽器顯示index.html中的內容（渲染頁面）

• 瀏覽器接收到伺服器返回的資料包，根據瀏覽器的渲染機制對相應的資料進行渲染。
• 渲染就是將響應報文裡的html檔案+圖片+影片等展示出來，看到效果。
• 瀏覽器支援HTML語言，支援http，播放器等功能。

【8】釋放TCP連線（四次揮手）

• 瀏覽器和伺服器都不再需要傳送資料後，四次揮手斷開 TCP 連線。

四次握手指斷開TCP協議連線時客戶端和伺服器之間的互動過程

• 客戶端向伺服器傳送一個FIN（結束）報文
  • 表示要關閉連線。
• 伺服器收到FIN報文後向客戶端回送一個ACK報文
  • 表示已經收到客戶端的請求。
• 如果伺服器還有資料需要傳送給客戶端
  • 則繼續傳送直到資料全部傳送完畢。
• 伺服器傳送一個FIN報文，表示資料已經全部傳送完畢
  • 可以關閉連線。

• 客戶端收到FIN報文後向伺服器傳送一個ACK報文，表示確認收到關閉請求。
• 此時客戶端需要進入TIME-WAIT狀態，等待兩倍的報文最大生存時間，以保證資料已經被全部傳輸完畢。
• 如果伺服器沒有收到來自客戶端的ACK報文，則會重傳FIN報文。

【四】HTTP

【1】什麼是http協議

• HTTP協議（HyperText Transfer Protocol，超文字傳輸協議）

  • 由蒂姆·伯納斯-李於1989年為了推廣網際網路技術而推出的一種無狀態網路應用協議

• HTTP協議構建於TCP/IP協議族之上

  • 屬於應用層協議。

• 主要

  用於傳輸與超文字相關的資原始檔

  • 如HTML網頁，css，js，圖片，影片，音訊等。

【2】HTTP協議的特點

• http協議具有無狀態、無事務、所有請求必有所回應的特點。

（1）基於請求、響應

• 服務端永遠不會主動給客戶端發訊息 必須是客戶端先請求服務端被動響應
• http協議是基於客戶端請求，服務端響應模型來實現的。
• 所以一般而言對於http協議通訊的雙方來說，發起請求的一方只能是客戶端，而響應資料的一方只能是服務端。

（2）基於TCP/IP作用於應用層之上的協議

• 應用層協議:HTTP HTTPS FTP ...

（3）無狀態

• 服務端不儲存客戶端狀態(縱使見她千百遍 我都當她如初見)
• 所謂的無狀態是指http協議預設情況下，服務端不識別客戶端的。
• 在客戶端多次發起請求到同一個伺服器，服務端接收到客戶端的請求在處理完成以後就會主動斷開。
• 所以對於客戶端的每一次請求，對於服務端來說，都是一次新的客戶端請求。
• 也就是說，服務端無法區分多次請求的客戶端是否同一個客戶端。

（4）短連線

• 不保持客戶端與服務端之間的連結導通

補充:websocket(長連線) 主要用於加好友聊天等業務

【3】請求格式和 響應格式

（1）請求格式

• 客戶端給服務端傳送訊息應該遵循的資料格式
  • 1.請求首行(請求方法 協議版本)
  • 2.請求頭(一大堆k:v鍵值對)
  • 3.(換行不能省略)
  • 4.請求體(攜帶敏感資料:密碼 身份照號...) 不是一直都有

（2） 響應格式

• 服務端給客戶端傳送訊息應該遵循的資料格式
  • 1.響應首行(響應狀態碼 協議版本)
  • 2.響應頭(一大堆k:v鍵值對)
  • 3.(換行不能省略)
  • 4.響應體(給瀏覽器展示給使用者看的頁面內容)

【4】請求響應模型

• HTTP協議永遠都是客戶端發起請求，伺服器回送響應。

【1】請求報文格式

• 對於客戶端的

  http請求格式

  一般分三部分組成

  • 分別是請求行、請求頭、請求體（部分請求方法不具有請求體）。

• 一般如下：

• 一般如下：

請求方法  請求路徑  http協議版本                   <---- http響應的一行內容，也叫請求行
請求頭選項1: 選項值
請求頭選項2: 選項值
....
請求頭選項n: 選項值

請求體(可以有多行，前後必有空行)

• 我們可以藉助telnet工具對遠端的web伺服器發起http或https請求。
• telnet預設是關閉的。所以需要手動開啟。

• 例如，發起http請求訪問，基本的http請求格式如下：

GET  /get  HTTP/1.1
Host: httpbin.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36

【2】傳送GET請求

telnet httpbin.org 80

GET  /get  HTTP/1.1
Host: httpbin.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36

• 請求效果如下：

【3】傳送POST請求

• 傳送POST請求，併傳送json資料格式。

POST /post HTTP/1.1
Host: httpbin.org
Content-Type: application/json
Content-Length: 44

{"name": "xiaoming", "age": 16,"pwd": "123"}

• 也可以透過安裝測試工具，如postman或Apifox，來檢視並學習http協議的請求與響應格式。

【4】響應報文格式

• 上面看到的內容實際上就是遠端http伺服器透過http通訊返回的響應報文。格式如下：

協議版本 響應狀態碼 響應文字提示                               <-----  http響應的第一行內容，響應行
響應頭選項1: 選項值
響應頭選項2: 選項值
....
響應頭選項n: 選項值

響應體（服務端返回的正文資訊，前後必有空行）

【五】協議報文詳解

• 前面我們提到，http協議是應用層協議，是基於tcp協議。
• 在前面的網路程式設計曾經學習過tcp協議的通訊是可靠安全的
  • 所以實際上來說，因為http協議是基於TCP協議來傳輸資料的，所以http協議就具有了有所請求必有所回應的特點，也因此我們可以說，http協議一次通訊的最基本的流程都是具有請求報文與響應報文的。
• 請求報文與響應報文就組成http協議的通訊內容（HTTP報文）。
  • 不管是請求報文還是響應報文在上面的傳送請求與檢視伺服器響應報文
  • 我們都可以看到，實際上HTTP報文就是一段連續的多行的文字。

【1】HTTP請求流程

【2】請求報文

• 請求報文（HTTP Rquest）主要透過客戶端傳送用於表達對伺服器資源的操作。
• 基本格式：

請求方法  請求路徑  http協議版本                   <---- http響應的一行內容，也叫請求行
請求頭選項1: 選項值
請求頭選項:2 選項值
....
請求頭選項n: 選項值

請求體(可以有多行，前後必有空行)

（1）請求行

• 請求行（HTTP Request Line）
  • 表示請求報文的首行
• 主要三部分組成，使用單個空格隔開，分別是：
  • 請求方法
  • 請求路徑
  • HTTP協議版本。

（2）請求方法

• HTTP請求方法（HTTP Request Method）
• 表示客戶端希望對伺服器指定資源進行哪一種型別的操作
• 存在多種HTTP請求方法表達增刪查改。
• 常見請求方法如下：

請求方法	描述	報文中是否包含請求體
GET	表示客戶端希望從伺服器中獲取或下載資源資訊	Flase
POST	表示客戶端希望上傳檔案或透過請求在伺服器建立資源資訊。	True
PUT	表示客戶端希望修改或更新伺服器資源（表示修改全部資源資訊，例如資料表的一整個記錄）	True
PATCH	表示客戶端希望修改或更新伺服器資源（表示修改部分資源資訊，例如資料表的一個記錄裡面某個屬性值）	True
DELETE	表示客戶端希望刪除或廢棄伺服器資源	Flase
OPTION	表示客戶端希望獲取伺服器所支援的請求方法列表	Flase
HEAD	表示客戶端希望獲取伺服器支援的跨域地址列表	Flase

（3）請求路徑

• 表示遠端web伺服器的一個可訪問資源。
• 一般就是代表的就是一個伺服器的具體檔案或資料表中的記錄資訊，或一個服務端裡面的函式或方法。

/     表示根路徑
/1.html   表示web伺服器中web根目錄下的1.html檔案
/login    表示web伺服器中的一個login方法或者login函式

（4）http協議版本

• 表示客戶端目前使用的HTTP協議版本，並期望服務端也採用同樣版本的協議與客戶端進行通訊。
• http協議傳送至今已經到了HTTP2.0版本，目前主流的使用版本有：HTTP/1.0 、HTTP/1.1。

（5）請求頭

• HTTP請求頭（Request Head）
  • 主要對客戶端請求操作進行限制條件與補充說明。
• 常見的標準HTTP請求頭如下：

選項	描述	值
Host	指定客戶端請求的伺服器的域名和埠號。	www.baidu.com
Content-Type	告訴伺服器，客戶端請求攜帶的請求體資料的媒體型別資訊（MIME型別）
User-Agent	告知伺服器HTTP 客戶端網路代理程式的版本資訊，一般就是瀏覽器的版本資訊。
Authorization	告知伺服器客戶端的Web認證資訊。
Content-Length	HTTP報文中請求體的大小，以位元組為單位。
Referer	告訴伺服器該網頁是從哪個頁面連結過來。也就是上一頁頁面的地址。
Accept	指定客戶端能夠接收並理解的媒體型別型別（MIME型別），用於表達希望服務端的返回資源格式。
Accept-Encoding	指定瀏覽器可以支援的web伺服器返回內容壓縮編碼型別。	gzip, deflate, br
Pragma	指定服務端控制快取行為。http/1.0以前的欄位。	Pragme: no-cache
Cache-Control	指定服務端控制快取行為。http/1.1以後的欄位。	Cache-Control: no-cache
Upgrade	向伺服器請求在當前http協議的基礎上升級採用新的某種傳輸協議以便伺服器進行轉換	常用於http協議升級到ws協議。
Connection	指定本次http通訊結束以後，是否關閉TCP網路連線。如果設定持久連線，則可以在一次會話中，可以使用同一個TCP連線，進行多次的HTTP通訊，提高效率。	持久連線，Connection: keep-alive 非持久連線，Connection: close

注意：在http通訊過程中，請求頭也是可以自定義的，但是不能出現多位元組編碼字元，例如中文等。

（6）常見的MIME格式

型別	描述	別名
text/html	HTML網頁
application/json	json文字	text/json
text/plain	純文字，普通文字
text/xml	xml文件
application/javascript	js指令碼	text/javascript
text/css	css樣式
image/png	png格式圖片
image/jpeg	jpg格式圖片
image/gif	gif格式圖片
application/x-gzip	gzip格式壓縮包
application/msword	doc文件
application/vnd.openxmlformats-officedocument.wordprocessingml.document	docx文件
application/vnd.ms-excel	xls文件
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet	xlsx文件
application/pdf	pdf文件
audio/mpeg	mp3音訊
video/mp4	mp4影片

【3】響應報文

• HTTP響應報文（HTTP Response）
  • 是服務端在接收理解、處理並返回客戶端操作的結果。
  • 主要有三部分組成：
    • 響應行，響應頭與響應體。
• 注意：針對部分請求方法（delete、OPTION、HEAD）的返回結果有時候是沒有響應體的。

協議版本 響應狀態碼 響應文字提示                               <-----  http響應的第一行內容，響應行
響應頭選項1: 選項值
響應頭選項2: 選項值
....
響應頭選項n: 選項值

響應體（服務端返回的正文資訊，前後必有空行）

（1）響應行

• HTTP響應行（HTTP Request Line），是HTTP響應報文的首行
• 由三部分組成，使用單個空格隔開：
  • HTTP協議版本
  • 響應狀態碼
  • 響應資訊。

（2）HTTP協議版本

• 響應報文的HTTP協議版本，與客戶端的協議版本保持一致。
• 例如：HTTP/1.0，HTTP/1.1。

（3）響應狀態碼

• 狀態碼（Status Code）
  • 用於表達本次服務端在接收客戶端請求之後的操作結果的成功或失敗結果，由三位整陣列成。

狀態碼型別	描述
1xx	告訴客戶端，本次請求，服務端還在持續處理中，並沒有結束。
2xx	告訴客戶端，本次請求，服務端已經接收並成功受理了。
3xx	告訴客戶端，服務端位置發生改變，希望客戶端重定向訪問跳轉新的伺服器地址進行請求
4xx	告訴客戶端，本次請求有誤，伺服器無法處理。
5xx	告訴客戶端，本次請求服務端在處理過程中服務端出錯了。

（4）常見的HTTP狀態碼

狀態碼	響應資訊	描述
101	Switching Protocols	伺服器已經理解了客戶端的請求，並將透過Upgrade訊息頭通知客戶端採用升級協議來完成請求。
200	OK	請求已成功，請求所希望的響應頭或資料體將隨此響應返回。出現此狀態碼是表示正常狀態。常用於GET，PUT或PATCH
201	Created	請求已成功，請求的資源已經建立成功或更新完成，常用於POST，PUT或PATCH
204	No Content	請求已成功，但是沒有任何內容返回。常用於DEELTE
301	Moved Permanently	永久重定向，表示當前客戶端請求的資源地址已經永久發生改變。
302	Move Temporarily	臨時重定向，表示當前客戶端請求的資源地址還存在，但是訪問客戶端達不到訪問資源的條件，所以暫時無法訪問。
304	Not Modified	表示本次客戶端請求的資源，並非來自服務端，而是本地快取。如果web專案有做了客戶端快取，一般靜態檔案都會出現304
305	Use Proxy	被請求的資源必須透過指定的代理才能被訪問。
307	Temporary Redirect	請求的資源臨時從不同的URI 響應請求。
400	Bad Request	本次請求，報文語義有誤或請求引數有誤，當前請求無法被伺服器理解。
401	Unauthorized	本次請求，需要需要使用者驗證，但使用者並沒有提供認證。
403	Forbidden	伺服器已經理解請求，但是拒絕執行它。一般是因為沒有許可權導致的。
404	Not Found	請求失敗，請求所希望得到的資源未被在伺服器上發現，請求路徑不存在。
405	Method Not Allowed	請求行中指定的請求方法不能被用於請求相應的資源。使用了錯誤的請求方法。
500	Internal Server Error	伺服器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。就是服務端的程式碼報錯了。
502	Bad Gateway	閘道器當機，作為閘道器或者代理工作的伺服器嘗試執行請求時，從上游伺服器接收到無效的響應。一般就是大量訪問請求導致伺服器癱瘓或當機了。
503	Service Unavailable	閘道器過載，由於臨時的伺服器維護或者過載，伺服器當前無法處理請求。
504	Gateway Timeout	閘道器超時，作為閘道器或者代理工作的伺服器嘗試執行請求時，未能及時從上游伺服器或者輔助伺服器（例如DNS）收到響應。
507	Insufficient Storage	伺服器無法儲存完成請求所必須的內容。

（5）響應頭

• HTTP響應頭（Response Head），主要是伺服器返回的內容進行補充說明，並提供下一次請求的一些輔助資訊。

選項	描述
Content-Type	告知客戶端，響應資料的MIME型別
Content-Length	告知客戶端，響應資料的位元組大小
Content-Encoding	告知客戶端，響應資料採用的壓縮格式
Server	告知客戶端，響應伺服器的名字或型別
Date	告知客戶端，響應請求的時間
Location	告知客戶端，實際要請求的資源地址（用於301或302進行頁面跳轉）
Cache-Control	告知客戶端，響應資料的快取機制
Refresh	告知客戶端，要定時重新整理的時間間隔
Connection	告知客戶端，本次HTTP通訊完成以後是否要保持TCP連線。
Transfer-Encoding	告知客戶端，資料是以分塊方式響應回來的。
Content-Disposition	告知客戶端，以下載方式打資料的，格式：Content-Disposition: attachment;filename=檔名
Expires	告知客戶端，響應資料的過期事件，-1表示馬上過期，客戶端不要快取當前響應資料。
Retry-After	告知客戶端，應該在多久之後再次傳送請求。常見於服務端限流，或503中。
Access-Control-Allow-Origin	指定客戶端透過哪些域名下的指令碼可以訪問伺服器資源。
Access-Control-Allow-Methods	指定客戶端透過哪些HTTP請求方法訪問服務端資源。
Access-Control-Allow-Headers	指定客戶端請求伺服器的報文中，允許包含哪些請求頭。

【總結】

【1】什麼是HTTP協議

• 超文字傳輸協議，用來規定伺服器和瀏覽器之間資料互動的格式
• 該協議可以不遵循，但是自己寫的服務端不能被瀏覽器正常識別，只能單機使用

【2】HTTP協議的四大特性

（1）基於請求響應

（2）基於TCP/IP之上，作用域應用層之上的協議

（3）無狀態

• 不儲存使用者的資訊
  • 早期的網站不需要使用者註冊 所有人訪問的網頁資料都是一樣的
• 由於HTTP協議是無狀態的，所以後來出現了一些專門用來記錄使用者狀態的技術
  • cookie/session/token

（4）無/短連結

• HTTP協議預設是HTTP 1.0 短連結
  • 即兩者請求響應後立刻斷絕關係，絕大多數網站都用的短連結
• HTTP 1.1 長連結
  • 長連結：雙方建立連線之後預設不會斷開連結(websocket)

【3】HTTP協議的格式

（1）請求資料格式

• 請求首行（標識HTTP協議，當前請求方式）
• 請求頭（多組K:V鍵值對）
• \r\n\r\n
• 請求體（並不是所有的請求都有，get沒有post有，存放的是post請求提交的敏感資料）

（2）響應資料格式

• 響應首行（標識HTTP協議，當前請求方式，響應狀態碼）
• 響應頭（多組K:V鍵值對）
• \r\n\r\n
• 響應體（返回給瀏覽器，展示給使用者看的資料）

（3）請求方式

• get請求
  • 朝服務端要資料
    • 輸入網址獲取對應的內容
• post請求
  • 朝服務端提交資料
    • 使用者登入 輸入使用者名稱密碼之後 提交到服務端後端做身份校驗

（4）響應狀態碼

• 用一堆簡單的數字來表示一些複雜的狀態或描述性資訊

（5）URL

• 統一資源定位符(網址)