1.簡述HTTP協議

HTTP，全名超文本傳輸協議，是一個用于客戶端與服務器之間進行數據傳輸的應用層協議，可以傳輸文本、圖片、音視頻等超文本內容。

1.HTTP使用TCP作為傳輸層協議，因此具有可靠性，

2.除此之外，HTTP簡單靈活，應用廣泛。

3.同時HTTP是一個無狀態的協議，也就是說各個請求相互獨立，不受干擾；

4.HTTP使用明文傳輸，不經過加密，因此有一定的安全隱患，可能有不法分子通過竊聽盜取我們的私人信息。因此產生了HTTPS，是在HTTP基礎上，在HTTP和TCP之間加入了一個SSL/TLS協議，保證了安全性。

5.HTTP還具有無連接性，每次請求和響應都需要建立新的連接，因此HTTP效率不高，但是可以通過長連接的機制來提高效率。

2.HTTP有哪些特點？

HTTP 超文本傳輸協議，用于實現服務器端和客戶端的數據傳輸。它的特點是簡單快速、無連接、無狀態、可傳遞任意數據類型和一對一通訊。

簡單快速：客戶端向服務器端發送請求時，只需傳遞請求方法、路徑和請求參數，因為協議簡單，所以使得 HTTP 服務器的程序規模小，因而通信速度很快。

無連接：所謂的無連接指的是，每次連接只處理一個請求。服務器處理完客戶的請求后，會立即斷開連接。

無狀態：HTTP 不會記錄每次請求的身份信息，因此前一次請求和后一次請求相互“不認識”。

可傳遞任意數據類型：HTTP 允許傳輸任意數據類型，只需要在請求頭中標識數據類型 Content-Type 即可。

一對一通訊：每次 HTTP 請求，都是一個客戶端對應一個服務器端。

3.HTTP常見狀態碼

1xx 類狀態碼屬于提示信息，是協議處理中的一種中間狀態，實際用到的比較少。

2xx 類狀態碼表示服務器成功處理了客戶端的請求，也是我們最愿意看到的狀態。

• 「200 OK」是最常見的成功狀態碼，表示一切正常。如果是非 HEAD 請求，服務器返回的響應頭都會有 body 數據。

• 「204 No Content」也是常見的成功狀態碼，與 200 OK 基本相同，但響應頭沒有 body 數據。

• 「206 Partial Content」是應用于 HTTP 分塊下載或斷點續傳，表示響應返回的 body 數據并不是資源的全部，而是其中的一部分，也是服務器處理成功的狀態。

3xx 類狀態碼表示客戶端請求的資源發生了變動，需要客戶端用新的 URL 重新發送請求獲取資源，也就是重定向。

• 「301 Moved Permanently」表示永久重定向，說明請求的資源已經不存在了，需改用新的 URL 再次訪問。

• 「302 Found」表示臨時重定向，說明請求的資源還在，但暫時需要用另一個 URL 來訪問。

301 和 302 都會在響應頭里使用字段 Location，指明后續要跳轉的 URL，瀏覽器會自動重定向新的 URL。

• 「304 Not Modified」不具有跳轉的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定向，也就是告訴客戶端可以繼續使用緩存資源，用于緩存控制。

4xx 類狀態碼表示客戶端發送的報文有誤，服務器無法處理，也就是錯誤碼的含義。

• 「400 Bad Request」表示客戶端請求的報文有錯誤，但只是個籠統的錯誤。

• 「403 Forbidden」表示服務器禁止訪問資源，并不是客戶端的請求出錯。

• 「404 Not Found」表示請求的資源在服務器上不存在或未找到，所以無法提供給客戶端。

5xx 類狀態碼表示客戶端請求報文正確，但是服務器處理時內部發生了錯誤，屬于服務器端的錯誤碼。

• 「500 Internal Server Error」與 400 類型，是個籠統通用的錯誤碼，服務器發生了什么錯誤，我們并不知道。

• 「501 Not Implemented」表示客戶端請求的功能還不支持，類似“即將開業，敬請期待”的意思。

• 「502 Bad Gateway」通常是服務器作為網關或代理時返回的錯誤碼，表示服務器自身工作正常，訪問后端服務器發生了錯誤。

• 「503 Service Unavailable」表示服務器當前很忙，暫時無法響應客戶端，類似“網絡服務正忙，請稍后重試”的意思。

4.HTTP請求的幾種方式

1. GET：GET方法用于從服務器獲取指定資源。它是一種冪等的、安全的和可緩存的方法，不會對服務器端數據產生副作用。GET方法將請求參數附加在URL的查詢字符串中，適用于獲取數據的操作。

2. POST：POST方法用于向服務器提交數據，通常用于創建新資源或提交表單數據。POST方法不是冪等的，可能對服務器端數據產生副作用。POST方法將請求參數放在請求體中，適用于修改數據或執行特定操作的操作。

3. PUT：PUT方法用于向服務器更新指定資源。它是冪等的，即多次執行相同的PUT操作不會產生副作用。PUT方法要求客戶端發送完整的資源表示，用于替換服務器上的指定資源。

4. DELETE：DELETE方法用于刪除服務器上的指定資源。它是冪等的，即多次執行相同的DELETE操作不會產生副作用。DELETE方法用于刪除資源，但是要謹慎使用，因為刪除后無法恢復數據。

5. PATCH：PATCH方法用于局部更新服務器上的指定資源。它類似于PUT方法，但只需要發送需要更新的部分數據。PATCH方法用于更新資源的一部分，而不是整個資源。

6. HEAD：HEAD方法與GET方法類似，但只返回資源的頭部信息，不返回實際的資源內容。HEAD方法可用于獲取資源的元數據或檢查資源是否存在。

7. OPTIONS：OPTIONS方法用于獲取服務器支持的請求方法和資源的通信選項。客戶端可以通過發送OPTIONS請求來了解服務器的能力和約束。

8. TRACE：TRACE方法用于回顯服務器收到的請求，用于測試和調試。服務器將接收到的請求內容原樣返回給客戶端，用于驗證請求是否在傳輸中被修改。

5.GET和POST區別

GET?和?POST?是 HTTP 協議中的兩種主要方法（或稱為“請求方法”），用于發送數據到服務器或從服務器獲取數據。這兩種方法在 Web 開發中特別常見，并且在使用 HTML 表單、API 調用等場景中被廣泛使用。以下是它們之間的主要區別：

GET

• 目的：從指定的資源請求數據。
• 安全性：由于數據在 URL 中以查詢字符串的形式傳遞，所以 GET 請求不適合傳輸敏感數據，因為它可能會被保存在瀏覽器歷史、服務器日志等地方。
• 冪等性：GET 請求是冪等的，即多次執行相同的 GET 請求不會導致服務器上的數據發生變化。
• 緩存：GET 請求可以被緩存，這有助于減少網絡流量并提高性能。
• 數據長度：由于 URL 的長度限制，GET 請求可以攜帶的數據量有限（盡管現代瀏覽器和服務器對 URL 長度有更大的限制）。
• 使用場景：常用于從服務器檢索信息，如查詢數據庫記錄、讀取靜態資源等。

POST

• 目的：向指定的資源提交數據，請求服務器進行處理（例如，提交表單或上傳文件）。
• 安全性：POST 請求將數據放在請求體中，而不是 URL 中，因此比 GET 請求更適合傳輸敏感數據。但是，為了確保安全性，仍需要使用 HTTPS 協議來加密傳輸的數據。
• 冪等性：POST 請求通常不是冪等的，因為每次提交數據都可能導致服務器上的數據發生變化。但是，某些實現可能會使 POST 請求具有冪等性，這取決于服務器的處理方式。
• 緩存：POST 請求通常不會被緩存，因為它們包含的數據可能隨時發生變化。
• 數據長度：POST 請求可以攜帶的數據量比 GET 請求大得多，因為請求體的大小通常沒有限制（盡管實際上可能會受到服務器配置的限制）。
• 使用場景：常用于向服務器提交數據，如提交表單、上傳文件、創建新資源等。

總結

• 當需要從服務器檢索信息時，使用 GET 請求。
• 當需要向服務器提交數據或執行其他非冪等操作時，使用 POST 請求。
• 在傳輸敏感數據時，務必使用 HTTPS 協議來加密數據。
• 根據需要傳輸的數據量選擇適當的請求方法。如果數據量較大，則使用 POST 請求；如果數據量較小且主要是檢索信息，則使用 GET 請求。

6.HTTP的緩存技術

對于一些重復性的請求，可以把請求到的數據緩存到本地，這樣下次請求時直接讀取本地數據，不用再去訪問網絡服務器了，這樣會讓性能得到提升。緩存技術兩種實現方式：強制緩存，協商緩存

• 強制緩存

只要瀏覽器的緩存沒有過期，就直接使用瀏覽器的本地緩存。

強制緩存通過Cache-control和Expires兩個響應頭字段控制的（cache-control優先級高）。過程如下：

當瀏覽器第一次請求訪問服務器資源時，服務器會在返回這個資源的同時，在 響應 頭部加上 Cache-Control，Cache-Control 中設置了過期時間大小；

瀏覽器再次請求訪問服務器中的該資源時，會先通過請求資源的時間與 Cache-Control 中設置的過期時間大小，來計算出該資源是否過期，如果沒有，則使用該緩存，否則重新請求服務器；

服務器再次收到請求后，會再次更新 響應 頭部的 Cache-Control。

• 協商緩存

通過和服務器協商之后，判斷是否使用本地緩存。

兩種實現方式：

1.基于時間：請求頭的If-Modified-Since字段與響應頭的 Last-Modified 字段 Last-Modified：資源最后修改時間。

當資源過期了，發現響應頭中具有 Last-Modified 聲明，則再次發起請求的時候帶上 Last-Modified 的時間，服務器收到請求后發現有 If-Modified-Since 則與被請求資源的最后修改時間進行對比（Last-Modified），如果二者不同，說明資源又被改過，則返回最新資源，HTTP 200 OK；如果相同，說明資源無新修改，響應 HTTP 304 走緩存。

2.基于唯一標識：請求頭的 If-None-Match 字段與響應頭的 ETag 字段

當資源過期時，瀏覽器發現響應頭里有 Etag，則再次向服務器發起請求時，會將請求頭 If-None-Match 值設置為 Etag 的值。服務器收到請求后進行比對，如果資源沒有變化返回 304，如果資源變化了返回 200。

兩種方式第二種更為可靠，時間可能會被篡改。因此，響應頭中如果同時出現Last-modified和etag，優先使用etag。

協商緩存必須是在未命中強制緩存的情況下才會發生的，因為協商緩存需要基于強制緩存的cache-control字段判斷資源是否過期。

7.HTTP為什么不安全

1. 明文傳輸：HTTP協議是明文傳輸的，所有的請求和響應內容都是以明文的形式傳輸的，這使得攻擊者可以輕易地截取、竊聽和篡改通信內容。

2. 缺乏數據完整性驗證：由于HTTP協議缺乏數據完整性驗證機制，攻擊者可以修改傳輸的數據包，從而篡改數據內容，比如在響應中插入惡意代碼。

3. 缺乏身份驗證：HTTP協議沒有內置的身份驗證機制，因此無法保證通信雙方的身份真實性。這意味著攻擊者可以冒充其他用戶或服務器進行攻擊。

4. 缺乏加密保護：HTTP協議沒有加密機制，因此無法對通信內容進行加密保護。這使得敏感信息（如用戶名、密碼等）在傳輸過程中容易被竊取。

8.HTTPS加密過程（TLS握手）

1. 握手階段：客戶端向服務器發送一個請求連接的請求，并提供自己的加密能力和支持的加密算法列表。服務器選擇一個與客戶端能力匹配的加密算法，并返回自己的身份認證信息（證書）。

2. 證書驗證：客戶端驗證服務器提供的證書的有效性和合法性。這包括檢查證書的頒發機構和過期時間等。如果驗證通過，則建立信任關系。

3. 密鑰協商：客戶端和服務器使用非對稱加密算法進行密鑰交換，以協商一個對稱密鑰，該對稱密鑰將用于后續的數據加密和解密。

4. 數據傳輸：在握手階段完成后，客戶端和服務器使用協商好的對稱密鑰進行數據的加密和解密，確保數據的機密性和完整性。

首先它是先建立了一個TCP連接，也就是說經過一個三次握手，三次握手完了之后還要經歷一次TLS/SSL握手。

1.Client Hello（發送客戶端生成的隨機數，當前的TLS版本和支持的加密套件）

比如說我們現在有一個客戶端和一個服務端，然后我們這個客戶端要先發起一個ClientHello，這個的話意思就是說我要發起一個HTTPS連接了，然后的話它會攜帶幾個信息，首先第一個是一個客戶端攜帶一個隨機數,還有我要使用的密碼套件，比如說他要使用的是 RSA 這樣的技術，還是說DES這樣的技術，還有一個是我當前要執行的一個TLS/SSL協議的一個版本號,比如說1.2這樣的版本,然后他就把這個打包成一個包，然后發給這個服務端。

2.Server Hello（返回服務端生成的隨機數，確認支持TLS版本號和加密套件）

服務端收到之后就會回復一個server hello，server hello主要是對于這個我們的客戶端做一個就是做一個回應，就是說比如說我確認你的協議了，你的TLS/SSL協議是1.2,然后我服務端這邊支持就把然后我就可以確認版本號,然后的話密碼套件我這也有，所以話我們可以達成這個協議，否則的話就會終止本次的連接，之后還會加上一個這個服務端產生的隨機數，然后接著的話就會把這個包返還給客戶端。

接下來，在繼續之后的握手步驟之前，客戶端需要先驗證一下證書，拿到證書中的公鑰，也即服務端使用的公鑰

Certificate（客戶端驗證證書）

服務端將證書發給客戶端，客戶端對證書進行驗證，驗證成功后客戶端后續就可以使用服務端（證書中）提供的RSA公鑰了

Server Key Exchange

服務端把公鑰發送給客戶端

Server Hello Done

表示服務器已經接受了客戶端的hello消息，并且已經從中選擇了一個密碼套件（Cipher Suite），同時也向客戶端發送了自己的hello消息，以及服務器使用的密碼套件和其他的相關信息。這意味著服務器和客戶端已經就雙方協商使用的加密算法、密鑰長度、認證方式等相關信息達成了一致，并且接下來的通信將在雙方協商確定的密碼套件的保護下進行。

3.Client Key Exchange

客戶端會生成第三個隨機數，也叫預主密鑰，用收到的公鑰進行加密，發送給服務器。服務端收到后，會用自己的私鑰進行解密，得到預主密鑰。只有客戶端和服務端知道這個。客戶端用預主密鑰和第一第二隨機數計算出會話密鑰，服務器也是同樣。二者得到的會話密鑰是相同的。

4.Change Cipher Spec

告訴對方使用新的加密規范

5.Encrypted Handshake Message

雙方同步之前協商的信息。

至此，TLS握手結束，握手階段采用的是非對稱加密，之后的數通信采用對稱加密。

9.HTTP各個版本的特點

HTTP/1.0:

優點：

簡單、兼容性好。

缺點：

1. 不支持持久連接：客戶端每次請求都需要和服務器建立新的TCP連接，完成之后斷開連接。

2. 隊頭阻塞：下個請求必須在上個請求響應到達后發送。如果上個請求響應丟失，則后面請求被阻塞。

3. 安全性差，沒有加密措施。

HTTP/1.1:

優點：

1. 引入了緩存機制，通過Cache-Control等響應頭控制緩存策略（強制緩存和協商緩存）。

2. 支持持久連接（keep-alive），即在一個TCP連接上處理多個請求和響應。

3. 支持管道化請求，可以同時發送多個請求。但是響應的順序必須和請求的順序相同。（可以解決請求部分的隊頭阻塞）

缺點：

仍然無法解決隊頭阻塞問題

HTTP/2.0:

優點：

1. 采用二進制格式傳輸，而非HTTP/1.x的文本協議，減少了數據傳輸的大小和延遲。

2. 多路復用。在同一個TCP連接上可以有多個請求和響應，解決了HTTP的隊頭阻塞的問題。

3. 支持請求的優先級控制：可以更好地管理多個請求。

4. 頭部壓縮。HTTP/2使用HPACK算法來壓縮頭部信息，減少了數據傳輸的大小。

5. 服務端推送。服務器可以在客戶端請求一段資源時，主動推送其他相關資源，提高頁面加載速度。

6. 基于TLS（Transport Layer Security）加密傳輸，提高了數據傳輸的安全性。

缺點：

1.在TCP層面存在隊頭阻塞問題：TCP保證數據的完整性，當前面的某個數據沒到達時，后續收到的所有數據只能存放在內核的緩沖區中，只有當數據全部到達才會發送給HTTP。當 TCP 丟包時，整個 TCP 都要等待重傳，那么就會阻塞該 TCP 連接中的所有請求。

2.TCP握手和TLS握手

TLS和TCP是分層的，需要分批次進行握手，先TCP握手再TLS握手。時間較長。

3.網絡遷移會導致重新連接

如果IP或者端口號發生了變化，會導致TCP與TLS重新握手，如果網絡變化比較頻繁，會導致效率很低。

HTTP/3.0:

1. 基于UDP協議。與HTTP/1.x和HTTP/2使用TCP不同，HTTP/3使用UDP協議，同時在應用層使用了QUIC協議提高了連接的可靠性。QUIC連接上的多個流之間沒有依賴，當某個流發生丟包時，只阻塞這個流，其他流不會受到影響，不存在隊頭阻塞問題。

2. 更快的連接建立。QUIC協議內部包含了TLS1.3，握手只需要1個RTT就能完成建立連接與TLS密鑰協商；如果之前有連接過，那么在第二次連接的時候，數據可以和QUIC的握手信息一起發送，達到0-RTT的效果。

3. 連接遷移：通過連接ID來標識通信的雙方，即使網絡IP發生變化，可以根據連接ID和TLS密鑰等來找到原來的連接，避免重連。

10.HTTP首部常見字段

1.請求頭：

• Host：指定目標服務器的主機名或IP地址。

• User-Agent：標識發起請求的用戶代理（通常是瀏覽器）的信息。

• Accept：指定客戶端能夠接受的內容類型。

• Content-Type：指定請求中的實體正文的媒體類型。

• Content-Length：指定請求中的實體正文的長度。

• Cookie：包含由服務器發送的Cookie信息，用于跟蹤用戶狀態。

• Authorization：用于進行身份驗證的憑證，常用于發送用戶憑證給服務器。

• Referer：指定當前請求的來源頁面 URL

2.響應頭：

• Content-Type：指定響應中的實體正文的媒體類型。

• Content-Length：指定響應中的實體正文的長度。

• Set-Cookie：在響應中設置新的 Cookie。

• Location：用于重定向，指定新的請求目標位置。

• Cache-Control：控制緩存行為，指定是否可以緩存響應以及緩存有效期等。

• Server：指示服務器的軟件信息。

11.cookie和session作用

Cookie和Session是用于在Web應用中跟蹤用戶狀態和存儲用戶信息的機制。

1.cookie是服務器通過HTTP在客戶端存儲的小型文本文件，由服務器發送給瀏覽器，然后瀏覽器保存在本地，每次瀏覽器向服務器發送請求時，都會自動將響應的cookie添加到請求頭中發送給服務器。

特點：

• 存儲在客戶端，能長期保存在瀏覽器本地硬盤中，也可以設置過期時間，使其在一定時間后失效。

• 可以存儲少量數據，通常用來標識用戶、記錄用戶偏好設置等。

• 可以跨頁面和域名

• 可以被客戶端篡改或禁用

2.session是服務器端用于存儲用戶信息的一種機制，當用戶第一次訪問服務器時，服務器會為改用戶創建一個唯一的會話ID，并將該ID返回給客戶端進行保存。之后，客戶端每次請求都會帶上這個會話ID，服務器根據會話ID來識別并獲取用戶的相關信息。

特點：

• session信息存儲在服務端

• 可以存儲大量數據，靈活性高

• 存儲時間依賴于會話超時設置或手動刪除

• 需要服務器對session進行管理

12.cookie和session區別

• 存儲位置：Cookie存儲在客戶端，而Session存儲在服務器端。

• 存儲內容和大小：Cookie通常用于存儲少量數據，而Session可以存儲大量數據。

• 安全性：由于Cookie存儲在客戶端，因此存在被篡改的風險；而Session存儲在服務器端，相對更安全。

• 跨頁面/跨域：Cookie可以跨頁面和跨域使用，而Session在同一域名下可以跨頁面使用，但無法跨域。

• 可見性：Cookie可以設置為可見或不可見，可以通過瀏覽器開發者工具查看；而Session對客戶端是不可見的。

通常，Cookie用于存儲輕量級的用戶狀態和偏好設置，而Session用于存儲較重量級的用戶信息和會話狀態。它們經常一起使用，通過會話ID和Cookie進行數據傳遞和用戶身份驗證。

13.鍵入網址到網頁顯示，期間發生了什么？

1. 首先是域名解析，由DNS協議完成。

• 瀏覽器提取URL中的域名部分

• 瀏覽器向本地DNS緩存中進行查詢，如果有該域名對應的IP，則直接使用。

• 如果沒有，瀏覽器會向操作系統發起DNS查詢請求，向操作系統中的hosts文件中查找。如果找到，則使用；

• 如果沒有，則向DNS服務器發起查詢請求。DNS服務器按照遞歸查詢的過程向根域名服務器、頂級域名服務器和權威域名服務器依次查詢，最終返回對應的IP地址。

• 操作系統將IP地址返回給瀏覽器，并將其緩存到本地的DNS緩存中，以便下次使用。

1. 然后瀏覽器建立TCP連接，客戶端與服務器通過三次握手建立TCP連接；

2. 瀏覽器請求某個資源之前，先檢查本地是否有緩存，如果緩存命中且可用，則直接從緩存中獲取響應，無需向服務器發送請求；如果未命中，則向服務器發送http請求。這個請求可以攜帶緩存控制字段，比如If-None-Match、If-Modified-Since兩個協商緩存的字段。

3. 服務器對客戶端發來的http請求進行處理，并返回響應。響應頭中可能包括Cache-Control和ETag等緩存控制字段。

4. 瀏覽器接收到http響應，根據響應頭中的字段決定是否緩存，并把響應內容解析，渲染頁面，顯示在瀏覽器窗口中。