【021】JavaWeb面試題（二）：Http協議

開篇介紹

大家好，我是Java最全面試題庫的提褲姐，今天這篇是JavaWeb系列的第二篇，主要總結了JavaWeb中HTTP相關的問題，在後續，會沿著第一篇開篇的知識線路一直總結下去，做到日更！如果我能做到百日百更，希望你也可以跟著百日百刷，一百天養成一個好習慣。

HTTP流程？

1、域名解析
2、發起TCP的三次握手
3、建立TCP連線後發起http請求
4、伺服器響應http請求，瀏覽器得到HTML程式碼
5、瀏覽器解析HTML程式碼，並請求HTML程式碼中的資源
6、瀏覽器對頁面進行渲染呈現給使用者
7、連線結束

GET和POST的區別？

GET：

• get重點是從伺服器上獲取資源
• get傳輸資料是透過URL請求，以field（欄位） = value的形式，置於URL後，並用“？”連線，多個請求資料間用“&”連線
• get傳輸資料量小，因為受URL長度限制，但是效率高
• get是不安全的，因為URL是可見的，可能會洩漏私密資訊
• get方式只能支援ASCII字元，向伺服器傳的中文字元可能會亂碼

POST：

• post重點是向伺服器傳送資料。
• post傳輸資料是透過HTTP的post機制。將欄位和對應值封存在請求實體中傳送給伺服器。這個過程使用者是不可見的
• post可以傳輸大量資料，所以上傳檔案時只能用post
• post支援標準字符集，可以正確傳遞中文字元
• post 較get安全性高

HTTP常見的狀態碼有哪些？

• 1xx：指示資訊–表示請求已接收，繼續處理
• 2xx：成功–表示請求已被成功接收、理解、接受
• 3xx：重定向–要完成請求必須進行更進一步的操作
• 4xx：客戶端錯誤–請求有語法錯誤或請求無法實現
• 5xx：伺服器端錯誤–伺服器未能實現合法的請求

常見的狀態碼：

• 200：請求被正常處理
• 204：請求被受理但沒有資源可以返回
• 206：客戶端只是請求資源的一部分，伺服器只對請求的部分資源執行GET方法，相應報文中透過Content-Range指定範圍的資源。
• 301：永久性重定向
• 302：臨時重定向
• 303：與302狀態碼有相似功能，只是它希望客戶端在請求一個URI的時候，能透過GET方法重定向到另一個URI上
• 304：傳送附帶條件的請求時，條件不滿足時返回，與重定向無關
• 307：臨時重定向，與302類似，只是強制要求使用POST方法
• 400：請求報文語法有誤，伺服器無法識別
• 401：請求需要認證
• 403：請求的對應資源禁止被訪問
• 404：伺服器無法找到對應資源
• 500：伺服器內部錯誤
• 503：伺服器正忙

HTTP中重定向和請求轉發的區別？

本質區別：

• 轉發是伺服器行為
• 重定向是客戶端行為

重定向特點：兩次請求，瀏覽器地址發生變化，可以訪問自己 web 之外的資源，傳輸的資料會丟失。
請求轉發特點：一次強求，瀏覽器地址不變，訪問的是自己本身的 web 資源，傳輸的資料不會丟失。

HTTP和HTTPS的區別？

HTTPS = HTTP + SSL

• https有ca證照，http一般沒有
• http是超文字傳輸協議，資訊是明文傳輸。https則是具有安全性的ssl加密傳輸協議
• http預設80埠，https預設443埠

HTTP/2 與 HTTP/1.x 的主要區別？

• 二進位制協議代替文字協議，更加簡潔高效
• 針對每個域只使用一個多路複用的連線
• 壓縮頭部資訊減小開銷
• 允許伺服器主動推送應答到客戶端的快取中

HTTP請求報文與響應報文格式？

請求報文：
a、請求行：包含請求方法、URI、HTTP版本資訊
b、請求首部欄位
c、請求內容實體

響應報文：
a、狀態行：包含HTTP版本、狀態碼、狀態碼的原因短語
b、響應首部欄位
c、響應內容實體

什麼是HTTP協議無狀態協議？怎麼解決http協議無狀態協議？

無狀態協議對於事物處理沒有記憶能力。缺少狀態意味著後續的處理需要前面的資訊。
透過cookie和session解決

HTTPS方式與web伺服器通訊的步驟？

1、客戶使用HTTPS的URL訪問web伺服器，要求與web伺服器建立SSL連線
2、web伺服器收到客戶端請求後，將網站的證照資訊（證照中包含公鑰）傳送一份給客戶端
3、客戶端的瀏覽器與web伺服器開始協商SSL連線的安全等級，也就是資訊的加密等級
4、客戶端的瀏覽器根據雙方同意的安全等級，建立會話秘鑰，然後利用網站的公鑰將會話秘鑰加密，並傳送給網站
5、web伺服器利用自己的私鑰解密出會話秘鑰
6、web伺服器利用會話秘鑰加密與客戶端之間的通訊

說說常見的常見HTTP首部欄位？

通用首部欄位（請求報文與響應報文都會使用的首部欄位）
Date：建立報文時間
Connection：連線的管理
Cache-Control：快取的控制
Transfer-Encoding：報文主體的傳輸編碼方式

請求首部欄位（請求報文會使用的首部欄位）
Host：請求資源所在伺服器
Accept：可處理的媒體型別
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的內容編碼
Accept-Language：可接受的自然語言

響應首部欄位（響應報文會使用的首部欄位）
Accept-Ranges：可接受的位元組範圍
Location：令客戶端重新定向到的URI
Server：HTTP伺服器的安裝資訊

實體首部欄位（請求報文與響應報文的的實體部分使用的首部欄位）
Allow：資源可支援的HTTP方法
Content-Type：實體主類的型別
Content-Encoding：實體主體適用的編碼方式
Content-Language：實體主體的自然語言
Content-Length：實體主體的的位元組數
Content-Range：實體主體的位置範圍，一般用於發出部分請求時使用

說說TCP傳輸的三次握手四次揮手策略

三次握手：

為了準確無誤地把資料送達目標處，TCP協議採用了三次握手策略。
用TCP協議把資料包送出去後，TCP不會對傳送後的情況置之不理，它一定會向對方確認是否成功送達。握手過程中使用了TCP的標誌：SYN和ACK

• 傳送端首先傳送一個帶SYN標誌的資料包給對方。
• 接收端收到後，回傳一個帶有SYN/ACK標誌的資料包以示傳達確認資訊。
• 最後，傳送端再回傳一個帶ACK標誌的資料包，代表“握手”結束。

注意：若在握手過程中某個階段莫名中斷，TCP協議會再次以相同的順序傳送相同的資料包

四次揮手：

斷開一個TCP連線則需要四次揮手

• 第一次揮手：主動關閉方傳送一個FIN，用來關閉主動方到被動關閉方的資料傳送，也就是主動關閉方告訴被動關閉方：我已經不 會再給你發資料了(當然，在fin包之前傳送出去的資料，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些資料)，但是，此時主動關閉方還可 以接受資料
• 第二次揮手：被動關閉方收到FIN包後，傳送一個ACK給對方，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號）
• 第三次揮手：被動關閉方傳送一個FIN，用來關閉被動關閉方到主動關閉方的資料傳送，也就是告訴主動關閉方，我的資料也傳送完了，不會再給你發資料了
• 第四次揮手：主動關閉方收到FIN後，傳送一個ACK給被動關閉方，確認序號為收到序號+1，至此，完成四次揮手

TCP和UDP的區別？

• TCP（Transmission Control Protocol，傳輸控制協議）是基於連線的協議，也就是說，在正式收發資料前，必須和對方建立可靠的連線。一個TCP連線必須要經過三次“對話”才能建立起來
• UDP（User Data Protocol，使用者資料包協議）是與TCP相對應的協議。它是面向非連線的協議，它不與對方建立連線，而是直接就把資料包傳送過去！ UDP適用於一次只傳送少量資料、對可靠性要求不高的應用環境