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

開篇介紹

你們好，我是Java最全面試題庫的提褲姐，今天這篇是JavaWeb系列的第二篇，主要總結了JavaWeb中HTTP相關的問題，在後續，會沿着第一篇開篇的知識線路一直總結下去，作到日更！若是我能作到百日百更，但願你也能夠跟着百日百刷，一百天養成一個好習慣。

HTTP流程？

一、域名解析
二、發起TCP的三次握手
三、創建TCP鏈接後發起http請求
四、服務器響應http請求，瀏覽器獲得HTML代碼
五、瀏覽器解析HTML代碼，並請求HTML代碼中的資源
六、瀏覽器對頁面進行渲染呈現給用戶
七、鏈接結束

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服務器通訊的步驟？

一、客戶使用HTTPS的URL訪問web服務器，要求與web服務器創建SSL鏈接
二、web服務器收到客戶端請求後，將網站的證書信息（證書中包含公鑰）傳送一份給客戶端
三、客戶端的瀏覽器與web服務器開始協商SSL鏈接的安全等級，也就是信息的加密等級
四、客戶端的瀏覽器根據雙方贊成的安全等級，創建會話祕鑰，而後利用網站的公鑰將會話祕鑰加密，並傳送給網站
五、web服務器利用本身的私鑰解密出會話祕鑰
六、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適用於一次只傳送少許數據、對可靠性要求不高的應用環境