前言

今天為大家整理了一份各大佬在面試中遇到的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.1 HTTP

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