前言

今天為大家整理了一份各大佬在面試中遇到的HTTP知識點彙總，希望對大家有幫助，正文開始！

1.HTTP到底是什麼

HTTP 是一種超文字傳輸協議(Hypertext Transfer Protocol)，超文字傳輸協議該怎麼理解是本文要講的第一個問題，下面對 超文字、傳輸、協議 這三個名詞做一下解釋。

超文字

文字比較好理解就是字串嘛，在計算機剛剛發明的時代網路通訊傳輸的就只是字串，後面隨著技術的發展我們不滿足僅限字串的傳輸通訊，還涉及到 圖片、音視訊、排版（CSS）、互動行為（JS）等資源的傳輸。之前傳輸的文字逐漸豐富起來，這個時候文字的語義就擴大了，我們把語義擴大後的文字稱為超文字（Hypertext）。

傳輸

把上面提到過的超文字解析成二進位制的資料包，通過傳輸載體比如網線等從一臺裝置傳輸到另一臺裝置的過程叫做傳輸。

協議

計算機之間相互通訊需要遵守一定的規則，規則中定義了請求端如何傳遞引數，響應端如何解析資料，這個就是網路協議。

現在我們知道了 http（超文字傳輸協議）就是在多臺網路裝置之間傳輸 文字、圖片、音視訊 等超文字內容的具體規範和約定。 網路協議除了http之外，常見的還有 電子郵件傳輸協議 SMTP、檔案上傳協議 FTP、域名解析協議 DNS 。

2.一個HTTP請求是怎麼完成通訊的

常見的場景是客戶端在本地發起請求，服務端接收請求響應資料，那這個過程中具體需要哪些機制配合協作呢，HTTP是一個網路通訊協議，除了HTTP之外你肯定還聽過TCP/IP協議，TCP/IP是HTTP通訊不可或缺的一部分。

3.HTTP 和 TCP/IP 的關係

為什麼說TCP/IP是HTTP通訊不可或缺的一部分，因為HTTP協議本身並不具備資料傳輸的能力，HTTP主要負責客戶端和服務端之間請求應答的標準定義（比如報文），而資料傳輸依賴TCP/IP協議，所以理解HTTP要先從TCP/IP開始。

4.TCP/IP

TCP/IP（Transmission Control Protocol/Internet Protocol 傳輸控制協議/網際協議）主要作用是在不同網路之間實現資訊資料的傳輸，我們雖然稱之為TCP/IP協議，但它實際上是一個協議族，包含的不僅僅是 TCP協議 和 IP協議，還有 UDP、ICMP、ARP 等，TCP、IP協議是這裡面最核心的兩個協議所以稱謂用它們指代。

TCP/IP的核心思想是分層管理，分為四層分別是 應用層、傳輸層、網路層和鏈路層。分層設計的好處是每一層都只負責自己的任務，不需要考慮其他層的任務，各層互動的時候只需要相互呼叫介面即可，當然也有劣勢每次進行網路通訊的時候都需要由下至上一層一層的傳遞資訊，這對效能是有一定影響的。

• 應用層：加密、解密、資料格式化、域名解析，面向業務。HTTP、FTP、DNS
• 傳輸層：為兩臺計算機之間提供相互傳輸資料的能力。TCP、UDP
• 網路層：進行網路連線的建立和終止，以及IP地址的尋找。IP、ICMP、IPV6
• 鏈路層：用於處理網路連線的硬體部分。

4.1HTTP

HTTP是TCP/IP應用層的協議，HTTP主要負責客戶端和服務端之間請求應答的標準定義（比如報文）。

4.2 FTP

FTP是TCP/IP應用層的協議，FTP是檔案傳輸協議，主要功能用於實現使用者間檔案分發共享。

4.3 DNS

我們通過IP可以定位帶一臺裝置，當我們開啟百度的IP地址http://202.108.22.5/就打開了百度的首頁，但是這個IP地址無疑是反人類的很難記，這就有了域名，所以我們開啟http://www.baidu.com/也能開啟百度的首頁。

域名到IP的解析就是 DNS（Domain Name System）做的事情了，它作為將域名和IP地址相互對映的一個分散式資料庫，能夠使人更方便地訪問網際網路。

DNS協議是用來將域名轉換為IP地址的，也可以將IP地址轉換為相應的域名地址。目前，對於每一級域名長度的限制是63個字元，域名總長度則不能超過253個字元。

4.4 TCP

TCP（傳輸控制協議）是TCP/IP傳輸層的協議，TCP提供可靠的位元組流傳輸能力，“位元組流”是指，為了方便傳輸，將大塊資料分割成以報文段為單位的資料包進行傳輸管理。而“可靠”是指，TCP協議為保證資料可靠的傳輸採用了三次握手策略。TCP協議把資料包送出去後，不會對傳送後的情況置之不理，它一定會向對方確認是否成功送達，如有異常會啟動重發機制。HTTP就是使用TCP提供的傳輸能力進行通訊。

4.5 UDP

UDP（使用者資料報協議）是TCP/IP傳輸層的協議，UDP也提供了資料傳輸能力，UDP協議定義了埠，當資料包到達主機以後，就可以根據埠號找到對應的應用程式了，比較簡單，實現容易，但它沒有確認機制，資料包一旦發出，無法知道對方是否收到，因此可靠性較差。UDP和TCP很相似，但是更簡單，同時可靠性低於TCP，UDP的優點是快速、資源消耗少。

換句話說UDP只管發，不管對方收沒收到，像直播、視訊聊天這種就可以用UDP，因為這種需求對延時性要求很高，如果用TCP來做視訊聊天，網路不好丟包嚴重時，那TCP就會不斷重發，這樣就會導致看到的畫面可能還是對方一分鐘之前的傳送的，如果用UDP來做，網路不好時丟包就丟包了，丟包它也不會重發，而是一直髮送最新的資料，所以就能保住我看到的畫面都是實時的畫面。

UDP還有一個應用場景是DNS解析，DNS解析也使用UDP協議，因為UDP協議只要一個請求、一個應答就好了，而使用TCP協議要三次握手四次揮手更加浪費網路資源，基於資料層面考慮，DNS資料包並不是那種大資料包，所以使用UDP不需要考慮分包，如果丟包那麼就是全部丟包，如果收到了資料，那就是收到了全部資料，就算是丟包了重新請求一次就好了。

4.6 IP

IP是TCP/IP網路層的協議，IP協議規定使用IP地址來定位網際網路上每一臺唯一的裝置，再利用 ARP 協議獲取中轉裝置的 MAC 地址，以此解決定址相關問題。

4.7 IPV6

IPV4的地址長度為4個8位位元組，IPV4地址遲早會有枯竭的一天，為了解決這個問題，開始了IPV6的研發，IPv6的地址長度則是原來的4倍，一般寫成8個16位位元組，IPV6的地址是取之不盡，用之不竭的。

5.TCP與UDP

當客戶端希望與伺服器通過TCP建立連線時，首先會發送一個通訊請求，這個請求必須被送到一個明確的地址，並收到回覆，在雙方完成“握手”過程後，TCP連線建立，直到其中一端關閉再次“握手”斷開連線，這就是“三次握手和四次揮手”，而UDP則沒有握手和揮手的機制，這也是TCP更加可靠的原因。

6.TCP三次握手

握手過程中使用了TCP的標誌 SYN 和 ACK，傳送端首先發送一個帶有 SYN 標誌的資料包給對方，接收端收到後，回傳一個帶有 SYN/ACK 標誌的資料包以示傳達確認資訊，最後傳送端再回傳一個帶 ACK 標誌的確認包，代表握手結束。若在握手過程某個階段中斷，TCP 協議會再次以相同的順秀髮送相同的資料包。

• 第一次握手：客戶端傳送SYN報文到伺服器，並進入SYN已傳送狀態，伺服器接收到SYN報文。（伺服器確認了客戶端傳送正常，自己接收正常）

• 第二次握手：伺服器傳送SYN+ACK報文到客戶端，並進入ACK已傳送狀態，客戶端收到SYN+ACK報文。（客戶端確認了伺服器接收正常、傳送正常，自己接收正常傳送正常)

• 第三次握手：客戶端向伺服器傳送確認報文ACK，服務端接收到確認報文ACK，連線成功建立。(服務端確認了客戶端接收正常、傳送正常，自己接收正常傳送正常)

7.TCP四次揮手

• 第一次揮手：當客戶端的資料都傳輸完成後，客戶端向服務端發出包含FIN標誌位的連線釋放報文(當然資料沒發完時也可以傳送連線釋放報文並停止傳送資料)，需要注意的是客戶端發出FIN後就不能發資料了，但是還可以正常收資料。（客戶端告訴服務端我的資料發完了）

• 第二次揮手：服務端收到客戶端發的FIN報文後給客戶端回覆確認報文，確認報文包含ACK標誌位。此時服務端處於關閉等待狀態，而不是立馬給客戶端發FIN報文，這個狀態還要持續一段時間，因為服務端可能還有資料沒發完。（服務端告訴客戶端你的斷開請求我收到了）

• 第三次揮手：服務端將最後的資料傳送完畢後向客戶端發出連線釋放報文，報文包含FIN和ACK標誌位，用來關閉伺服器端到客戶端的資料傳送，也就是告訴客戶端，我的資料也傳送完了，此時服務端處於斷開等待狀態。（服務端告訴客戶端我的資料也發完了）

• 第四次揮手：客戶端收到服務端發的FIN報文後，向服務端發出確認報文，確認報文包含ACK標誌位，客戶端發出確認報文後不是立馬釋放TCP連線而是要經過2MSL(最長報文段壽命的2倍時長)，服務端一旦收到客戶端發出的確認報文就會立馬釋放TCP連線，所以服務端結束TCP連線的時間要比客戶端早一些。

8.為什麼握手是三次不是兩次

三次握手的作用是讓服務端和客戶端雙方明確彼此的傳送能力和接收能力都是正常的，不會造成資料丟失保證資訊傳遞的可靠性。而解決這個問題，三次通訊是理論上的最小值。 若只有兩次握手，第二次握手時伺服器給客戶端的確認報文如果丟失（客戶端接收資料能力異常），此時客戶端一直處在等待狀態，它並不清楚問題出在哪裡是自己第一次握手的報文沒有送達服務端還是服務端的響應報文丟失了，導致客戶端無法給服務端傳送資料。如果是三次握手，即便發生資料丟失也不會有問題，比如第三次握手客戶端發的確認報文丟失，服務端在一段時間內沒有收到確認報文就會重新進行第二次握手，客戶端收到重發的報文後會再次給服務端傳送確認報文。

9.為什麼揮手是四次不是三次（為什麼握手是三次揮手是四次）

因為只有在客戶端和服務端都沒有資料傳送的時候才能斷開連線，客戶端發出FIN報文時只能保證客戶端沒有資料發了，服務端還有沒有資料發給客戶端是不知道的。所以服務端收到客戶端的FIN報文後只能先回復客戶端一個確認報文來告訴客戶端服務端已經收到你的FIN報文了，但服務端還有一些資料沒發完，等這些資料發完了服務端才能給客戶端發FIN報文(所以不能一次性將確認報文和FIN報文發給客戶端)。

10.為什麼客戶端發出第四次揮手的確認報文後不會立刻釋放TCP連線

這裡同樣是要考慮丟包的問題，如果第四次揮手的報文丟失，服務端沒收到確認ACK報文就會重發第三次揮手的報文，這樣報文一去一回最長時間就是2MSL，所以客戶端需要等這麼長時間來確認服務端確實已經收到了。

11.已經建立了連線如果客戶端突然出現故障了怎麼辦

TCP有一個計時器機制，服務端每次接收到客戶端的請求都會復位這個計時器，當一定時間沒有收到客戶端的資訊服務端就會發送一個探測報文，如果依然沒有響應之後每隔75s重新發送一次，如果連著10個探測報文沒有響應伺服器就認為客戶端出現了故障，會主動關閉連線。

12.當我們在瀏覽器輸入url後發生了什麼

我們以http://www.baidu.com/index.html為例，來分析一下瀏覽器位址列輸入URL之後發生了什麼，這裡只分析和網路請求相關的內容，大量頁面渲染的東西先不涉及。

• DNS伺服器進行域名解析（先查詢快取以及本地hosts）找到www.baidu.com所射映的IP地址，然後在客戶端發起一個到伺服器的TCP連線（三次握手）。
• 客戶端通過TCP連線向伺服器傳送HTTP請求報文，該報文中包含請求資源路徑/index.html，以及其他引數。
• 伺服器接收請求報文，進行請求解析工作，完成資料庫查詢、磁碟資源讀取等，把這些內容封裝到HTTP響應報文中並向客戶端傳送。
• HTTP客戶端接收到響應報文後TCP連線關閉（四次揮手）。
• 瀏覽器渲染內容。

為了方便理解HTTP這裡只描述了一個簡單的過程，其實真實的 ‘請求->響應’ 要複雜的多，以及頁面的渲染這些後面會專門整理一篇。

13.HTTP的特點

• 支援客戶/伺服器模式
  HTTP工作於客戶端服務端的架構之上，瀏覽器作為客戶端通過url向web伺服器傳送請求，web伺服器根據接收到的請求向客戶端傳送響應資訊。

• 簡單快速
  客戶端向伺服器請求時，只需傳送請求方法和路徑。請求方法常用的有 GET、HEAD、POST，每種方法客戶端與伺服器通訊的特徵不同。由於HTTP協議的簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快，並且HTTP協議使用明文傳輸開發者不需要藉助第三方工具就可以研測。 HTTP協議主要的組成部分是header + body，頭部資訊就是簡單的語義化多行文字，在這基礎上 請求頭、狀態碼 等又支援開發者自定義，做到了足夠靈活，只要服務端和客戶端就請求頭欄位達成語義一致，新功能就可以被輕鬆加入進來。

• 靈活
  HTTP允許傳輸任意型別的資料物件，具體的傳輸型別由Content-Type值確定，可以是 圖片（image/png image/gif）、JSON（application/json）、HTML（text/html ）等。因為 HTTP 對語言以及平臺不做限制，所以有跨語言跨平臺的優越性，又因為其本身的簡單靈活幾乎所有的語言都有HTTP相關的研測方案。

• 無連線
  無連線的含義是限制每次連線只處理一個請求，伺服器處理完客戶端的請求，並收到客戶端的應答後即斷開連線，採用這種方式可以節約資源。

  早期這麼做的原因是 HTTP 協議產生於網際網路，因為伺服器需要處理同時面向全世界數十萬、百萬客戶端的網頁訪問，但每個客戶端（即瀏覽器）與伺服器之間交換資料的間歇性較大，並且網頁瀏覽的聯想性、發散性導致兩次傳送的資料關聯性很低，大部分通道實際上處於空閒狀態、導致佔用資源。因此 HTTP 的設計者有意利用這種特點將協議設計為請求時建連線、請求完釋放連線，以儘快將資源釋放出來服務其他客戶端。

  隨著時間的推移，網頁變得越來越複雜，裡面可能嵌入了很多圖片，這時候每次訪問圖片都需要建立一次 TCP 連線就顯得很低效，後來 Keep-Alive（HTTP1.1） 被提出用來解決效率低的問題。Keep-Alive 功能使客戶端到伺服器端的連線持續有效，當出現對伺服器的後繼請求時，Keep-Alive 功能避免了重新建立連線。

  我們始終都要認為HTTP請求在結束後連線就會關閉，這是HTTP的特性，因為上層實現在結束後是否關閉連線都不會改變這個特性，這和WebSocket長連線有本質的區別。

• 無狀態
  HTTP協議是無狀態協議，無狀態是指協議對於事務處理沒有記憶能力，它不會對請求和響應的狀態做持久化儲存，每個請求都是獨立的，如果後續請求需要前面的資訊，則它必須重傳，無法支援需要連續多個步驟的事務操作，這樣可能導致每次連線傳送的資料量增大。另一方面因為伺服器不需要管理狀態所以它的應答是較快的。

  這種特性有優點也有缺點，優點在於解放了伺服器，每一次請求“點到為止”不會造成不必要連線佔用，缺點在於每次請求會傳輸大量重複的內容資訊。

  客戶端與伺服器進行動態互動的Web應用程式(webapp)出現之後，HTTP無狀態的特性嚴重阻礙了這些webapp的實現，畢竟互動是需要承前啟後的，於是兩種用於保持 HTTP 連線狀態的技術就應運而生了，一個是 Cookie，而另一個則是 Session。

  Cookie可以保持登入資訊到使用者下次與伺服器的會話，換句話說，下次訪問同一網站時，使用者會發現不必輸入使用者名稱和密碼就已經登入了（當然，不排除使用者手工刪除Cookie）。而還有一些Cookie在使用者退出會話的時候就被刪除了，這樣可以有效保護個人隱私。

  Session可以理解是服務端的Cookie，當客戶端訪問伺服器時，伺服器根據需求設定 Session，將會話資訊儲存在伺服器上，同時將 Session 的 SessionId 傳遞給客戶端瀏覽器，瀏覽器將這個 SessionId 儲存在記憶體中，以後瀏覽器每次請求都會額外加上這個引數值，伺服器根據這個 SessionId，就能取得客戶端的資料資訊。瀏覽器關閉後這個 SessionId 就會被清掉，它不會存在於使用者的 Cookie 臨時檔案。如果客戶端瀏覽器意外關閉，伺服器儲存的 Session 資料不是立即釋放，此時資料還存在，只要我們知道那個 SessionId，就可以繼續通過請求獲得此 Session 的資訊，因為此時後臺的 Session 還存在，當然我們可以設定一個 Session 超時時間，一旦超過規定時間沒有客戶端請求時，伺服器就會清除對應 SessionId 的 Session 資訊。

• 明文
  HTTP協議還有一個特點是明文傳輸，明文是指在傳輸階段報文不使用二進位制資料，而是使用可直接閱讀的文字形式，相對 TCP 這樣的二進位制協議優點是可以不使用外部工具直接抓包（瀏覽器的network）除錯，缺點是不安全，可以被監聽和篡改。

14. 報文

什麼是報文

報文就是HTTP協議互動中傳遞的資訊，就是一堆引數和宣告，報文字身是多行結構的字串文字，客戶端傳送給服務端的叫請求報文，服務端下發給客戶端的叫響應報文。報文由四部分組成分別是 起始行、頭部欄位、空行、主體，在請求報文中起始行又叫請求行，在響應報文中起始行又叫狀態行。

請求報文

請求報文由四部分構成分別是 請求行、頭部欄位、空行、主體，其中 請求行、頭部欄位 合起來就是我們常說的請求頭(Req Header)，http協議規定每次請求必須傳送請求頭，請求主體(body)則可有可無，而空行就是用來分割請求頭和請求體的。

• 請求行 請求行說明了本次請求要做什麼，在請求行中定義了 請求方法、請求地址、HTTP版本。

• 頭部欄位 頭部欄位以 key-value 的形式存在，最後以換行結束。頭部欄位是可擴充套件的，可以自定義新的欄位名稱，名稱大小寫均可，通常情況下只大寫首字母。如果定義了重複的欄位名稱只會保留一個，值會被後面的覆蓋。HTTP協議並沒有對頭部欄位的整體長度做限制，但是在服務端實踐中長度超過某一個額定值4K或8K處於安全考慮會主動丟擲一個錯誤。
  頭部欄位的標頭分為四種分別是 通用標頭、請求標頭、響應標頭 和 實體標頭，這個先放在後面講。

• 空行
  分割請求頭和請求體，告訴服務端下面的內容是請求體。

• 主體

響應報文

響應報文由四部分組成分別是 狀態行、頭部欄位、空行、主體，其中 狀態行、頭部欄位 合起來就是響應頭(Res Header)。

• 狀態行
  狀態行說明本次請求的結果是什麼，在狀態行中定義了 HTTP版本、狀態碼、以及“短語訊息”，短語訊息為狀態碼提供了文字形式的解釋，狀態碼和短語訊息是一一對應的，比如狀態碼200就對應著OK。

• 頭部欄位
  參考請求報文的頭部欄位

• 空行
  分割響應頭和響應體，告訴客戶端下面的內容是響應體。

• 主體

頭部欄位

頭部欄位分為以下五類，分別是 通用頭部、請求頭部、響應頭部、實體頭部、擴充套件頭部。

• 通用頭部： 在請求頭和響應頭中都適用，比如 Content-Type 欄位。

  頭部欄位key	可選值	說明
  Connection	keep-alive、close	是否永續性連線，決定當前事務（一次三次握手和四次揮手）完成後，是否會關閉網路連線。
  Date		表示報文建立時間
  Transfer-Encoding	chunked	告知接收端為了保證報文的可靠傳輸，對報文采用了什麼編碼方式
  Cache-Control		控制快取行為
  Via		代理伺服器相關資訊

• 請求頭部： 只能出現在請求報文中，如 Origin 欄位。

  頭部欄位key	可選值	說明
  Host		接收請求的服務端的域名（或者IP）和埠
  User-Agent		客戶端資訊，web常見的是瀏覽器核心以及版本
  Accept	application/json 等	告訴服務端期望接收的資料型別
  Accept-Language	zh-CN 等	告訴服務端期望接收的語言型別
  Accept-Encoding	gzip	告訴服務端期望接收的編碼方式
  Accept-Charset		告訴服務端期望接收的字符集
  Authorization		客戶端提供給伺服器的驗證資料，客戶端token通常會寫到Authorization欄位裡。
  Cookie		攜帶Cookie
  Referer		客戶端發起請求的地址

• 響應頭部： 只能出現在響應報文中，如 Server 欄位。

  頭部欄位key	可選值	說明
  Set-Cookie		伺服器主動在客戶端設定一個標識令牌，會自動寫入Cookie。
  Access-Control-Allow-Origin	指定域名 或 *	告訴客戶端允許那些來源的域進行資源訪問
  Keep-Alive	timeout=8, max=3	timeout：保持持續連線狀態的最短時間，max：單個連線的最大請求數。
  Server		服務端資訊

• 實體頭部： 用來描述報文主體的頭部欄位，比如 Content-Length 欄位，要注意的是請求和響應報文中都有可能包含實體部分，所以這兩種型別的報文都有可能出現實體頭部。

  頭部欄位key	可選值	說明
  Content-Type	application/json	傳送的主體物件（body）型別
  Content-Encoding	gzip	傳送的編碼
  Content-Language	zh-CN	傳送的語言
  Content-Length	100{Number}	傳送實體的長度，以位元組為單位。

• 擴充套件頭部： 並非規定的標準頭部欄位，是開發者自行定義的頭部欄位。

15.Content-Type 和 Accept 的區別

application/json 表示json資料格式，同時是 Content-Type 和 Accept 欄位的值，他倆的區別在於 Content-Type 是實體頭部，會出現在請求頭和響應頭表示當前傳輸的資料體是json格式；Accept 是請求頭部，表示本次請求客戶端期望服務端返回json格式資料。

16.請求url

以 http://www.baidu.com:80/assets/public/index.html?a=1&b+2#/path/main 為例來分析一下請求url的組成：

http://： 告知瀏覽器當前使用的版本，大部分情況是HTTP協議，或者更為安全的HTTPS協議。

www.baidu.com： 域名用來定位到某一臺機器，向這臺機器發起請求，當然域名可以替換成IP地址，但是直接使用IP在生產環境並不常見。

:80： 埠也是必須的，IP用來定位到機器，而埠是用來確定向該機器上那個server發起請求。HTTP預設埠為80，HTTPS為443，80和443可以省略不寫其他埠必須要在請求地址上體現出來。

/assets/public/index.html： 資源路徑以埠後面的第一個/開始，到?號結束，中間的/代表了層級關係。

?a=1&b+2： 從 ? 到 # 之間的是引數，GET請求的引數會直接帶在URL上，POST請求引數則在請求體中。

#/path/main： #開始為前端的路由，路由改變頁面不會重新整理，以此實現前端的單頁面應用，路由是不會傳到服務端的。

17.狀態碼

響應報文的狀態行聲明瞭本次請求的狀態碼，不同狀態碼錶示的含義如下。

總的來說 1xx 是進行中，2xx 是成功，3xx 是重定向，4xx 是客戶端錯誤，5xx 是服務端錯誤。

請求方法

18.常用請求方法

• GET，從伺服器上獲取資源，無主體。
• POST，向伺服器傳送資料（常見的場景是表單提交）有主體。
• DELETE，從伺服器上刪除資源，無主體。
• PUT，更新資源，有主體。
• HEAD，獲得響應首部，HEAD 方法和 GET 方法一樣，只是不返回報文主體部分。用於確認URI有效性及資源更新時間等。
• OPTIONS，前置請求，詢問支援的方法。
• TRACE，追蹤路徑，TRACE 方法是讓 Web 伺服器端將之前的請求通訊環回給客戶端的方法。
• CONNECT，用隧道協議連線代理，CONNECT方法要求在與代理伺服器通訊時建立隧道，實現用隧道協議進行 TCP 通訊。主要用於 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網路隧道傳輸。

19.GET 和 POST 的區別

1）上面的請求方法常用的只有GET和POST，其他方法基本用不到，在工作中更新和刪除並不會特意用DELETE和PUT方法，而是統一用POST來解決。POST和GET在使用上有一些區別我們先直接給出來。

• 常規在資料獲取（查）時用GET方式，在資料提交（增刪改）時使用POST方式。
• 相對GET而言POST安全性更好，因為引數在位址列直接不可見。（HTTP本身是明文傳輸POST抓包引數也可檢視）
• GET在URL中的引數有長度限制2kb(實測了一下好像沒限制)，而POST沒有此限制可用來傳輸檔案。
• GET引數通過URL傳遞，POST放在RequestBody中。（在web中GET請求本身沒有ReqBody）
• POST方法通過RequestBody可以傳遞json資料更加語義化。（對有層級的資料用json描述體驗更好）
• GET請求效能更好速度更快
• GET請求是冪等的

2） 當直接在位址列(非ajax)訪問GET地址時還有下面這些特點：

• GET在瀏覽器回退時是無害的（被快取），而POST會再次提交請求。
• GET產生的URL地址可以被瀏覽器收藏，而POST不可以。
• GET請求會被瀏覽器主動快取，而POST不會，除非手動設定。
• GET請求只能進行URL編碼，而POST支援多種編碼方式。
• GET請求引數會被完整保留在瀏覽器歷史記錄裡，而POST中的引數不會被保留。
• 對引數的資料型別，GET只接受ASCII字元，而POST沒有限制。

這些特點其實只在web領域適用，如果說的更貼切一些就是隻在瀏覽器適用，HTTP不只是在瀏覽器端使用，拋開web上面的幾條區別就需要重新理解了。GET和POST是HTTP定義的Method，HTTP傳輸依賴TCP，在TCP這一層並沒有GET和POST相關的標準，所以GET和POST本質上只是語義和規範上的區別。

3）GET在url中傳參且長度小於2kb POST通過ReqBody傳參

GET在url中傳參且長度小於2kb(實測了一下好像沒限制)在瀏覽器中是沒問題的，因為瀏覽器廠商為了符合規範和語義對GET請求做了限制只允許通過url傳參，至於2kb的限制是因為瀏覽器為了避免url過長影響傳輸效率對位址列做了限制。上文有提到過url上除了#號之後的路由其他部分都可以傳到服務端，當然也包括?號後面的query引數，這和請求方法無關，資料既然可以抵達服務端那隻要做了解析就可以讀取，所以POST請求通過url也可以傳參。我們在討論GET和POST時不應該只侷限在瀏覽器（HTTP是跨平臺的），拋開瀏覽器GET請求其實也可以用ReqBody來傳參，下面截圖通過node+axios做了演示。結論就是GET請求雖然可以通過ReqBody傳參，但是規範上並不推薦這麼做，各個瀏覽器廠商、各種伺服器、第三方框架針對該規範可能會做不同的實現，不保證可用性與穩定性。但在技術上GET和POST都是基於TCP的傳輸實現，沒有本質區別，完全可以實現GET通過ReqBody傳參，POST通過url傳參。

4）GET獲取資料POST提交資料

既然GET和POST用URL和ReqBody都可以傳參，那麼GET獲取資料POST提交資料的設定也不是必須的，如果你願意完全可以反過來用，差別只在語義上。

5）相對GET而言POST安全性更好

這裡的安全只是因為POST請求引數在URL上不可見，但說到安全往往和攻防掛鉤，HTTP本身是明文傳輸POST請求隨便抓個包或者在network也可以看到詳細的引數。

6）GET請求效能更好速度更快

GET在請求時只發送一個數據包，會將header和data一起傳送到服務端，而POST會發送兩個資料包先發送header，伺服器返回100，然後再發送data，伺服器返回200。返回狀態碼100這個過程在瀏覽器network是不可見的，通過 (new XMLHttpRequest()).onreadystatechange = e => console.log(ajax.status) 可以看到100的過程。GET只發一個數據包以及對url長度的限制，所以效能好與POST。（GET只發一個數據包和瀏覽器實現也有關係部分瀏覽器也會和POST一樣發兩個包）

7）GET請求是冪等的

冪等是指多次請求同一個介面返回資料應該保持一致（不改變伺服器狀態），可以重複傳送請求，POST增加資料時重複傳送會帶來不可預料的後果。

20.如何優化HTTP請求

web效能優化最主要的就是要減少HTTP請求及每次響應中內容的長度：

• 域名解析：儘可能減少域名解析次數-----減少跨站、外部資源的引用
• 建立連線：減少連線建立次數-----使用Keep-Alive避免重複連線
• 傳送請求：盡力減少請求次數-----合理設定Expires時間、資源合併
• 等待響應：提高伺服器端執行速度-----提高資料運算及查詢速度
• 接收響應：儘可能減少響應資料長度-----啟用壓縮

21.什麼是CDN

CDN的全稱是Content Delivery Network，即內容分發網路，它應用了 HTTP 協議裡的快取和代理技術，代替源站響應客戶端的請求。CDN 是構建在現有網路基礎之上的網路，它依靠部署在各地的邊緣伺服器，通過中心平臺的負載均衡、內容分發、排程等功能模組，使使用者就近獲取所需內容，降低網路擁塞，提高使用者訪問響應速度和命中率。CDN的關鍵技術主要有內容儲存和分發技術。

22.什麼是HTTTPS

HTTP 是明文傳輸，很容易被攻擊者竊取重要資訊，鑑於此，HTTPS 應運而生。HTTPS 的全稱為 （Hyper Text Transfer Protocol over SecureSocket Layer），HTTPS 和 HTTP 有很大的不同在於 HTTPS 是以安全為目標的 HTTP 通道，在 HTTP 的基礎上通過傳輸加密和身份認證保證了傳輸過程的安全性。HTTPS 在 HTTP 的基礎上增加了 SSL 層，也就是說 HTTPS = HTTP + SSL。

總結

大佬就是大佬，每一個問題和答案總結的很到位，很感謝大佬的投稿分享。

當然光刷HTTP面試題肯定是不夠的，所以小編也為大家準備了其它學習資料的大禮包，戳這裡免費領取，暗號：CSDN。

獲取方式：戳這裡免費領取，暗號：CSDN