Http和Https的區別？
- Http是明文傳輸；
- Https在Http基礎之上加了一層ssl/tls加密，保證數據傳輸過程的安全性；
- Http和Https使用的是不一致的連接方式，默認使用的端口也不一致，Http是80，Https是433端口。
Https是如何保證安全傳輸的？
通過祕鑰的方式對數據進行加解密，祕鑰主要爲：對稱祕鑰和非對稱祕鑰。
對稱祕鑰：在每次發送真實數據之前，服務器先生成一把密鑰，然後先把密鑰傳輸給客戶端。之後服務器給客戶端發送真實數據的時候，會用這把密鑰對數據進行加密，客戶端收到加密數據之後，用剛纔收到的密鑰進行解密。
假如服務器用明文的方式傳輸密鑰給客戶端，然後密鑰被中間人給捕獲了，那麼在之後服務器和客戶端的加密傳輸過程中，中間人也可以用他捕獲的密鑰進行解密。這樣的話，加密的數據在中間人看來和明文沒啥兩樣，加密也變得毫無意義。
非對稱祕鑰：讓客戶端和服務器都擁有兩把鑰匙，一把鑰匙是公開的(全世界知道都沒關係)，我們稱之爲公鑰；另一把鑰匙則是保密的(只有自己本人才知道)，我們稱之爲私鑰。這且，用公鑰加密的數據，只有對應的私鑰才能解密；用私鑰加密的數據，只有對應的公鑰才能解密。
Http無狀態協議，怎麼理解無狀態協議，如何實現有狀態的請求？
無狀態協議就是服務器不會記錄客戶端是誰，Java可以通過session/cookie實現無狀態請求。
由服務器生成session，並返回sessionId給客戶端的cookie中，cookie訪問會通過sessionId去對應的session值。
Http中的302狀態碼的作用？
302是用來實現重定向的。
304緩存的原理
如果客戶端（瀏覽器）發送的是一個條件驗證請求,則web服務器可能會返回304響應,這就表明了客戶端中所請求資源的緩存仍然是有效的,也就是說該資源從上次緩存到現在沒有被修改過，瀏覽器會自動識別並讀取緩存中的文件來顯示。
在進行條件請求時，一般請求頭會帶上 If-Modified-Since、 If-None-Match，這兩個值分別對應響應頭 Last-Modified、 ETag 返回的值
服務器會讀取到這兩個請求頭中的值,判斷出客戶端緩存的資源是否是最新的,如果是的話,服務器就會返回304 Not Modified響應,客戶端收到304響應後,就會從緩存中讀取對應的資源.
另一種情況是,如果服務器認爲客戶端緩存的資源已經過期了,那麼服務器就會返回200 OK響應,響應體就是該資源當前最新的內容.客戶端收到200響應後,就會用新的資源覆蓋掉舊的緩存資源.
只有在客戶端緩存了對應資源且該資源的響應頭中包含了Last-Modified或ETag的情況下,纔可能發送條件請求.如果這兩個頭都不存在,則必須無條件請求該資源,服務器也就必須返回完整的資源數據.
Http協議 1.0和Http協議1.1的區別
- HTTP 協議1.1支持長連接, HTTP1.1 中有一個 Transport 段。會攜帶一個 Connection:Keep-Alive，表示希望將此條連接作爲持久連接。可以通過將Connection屬性設置close關閉持久連接。
-
HTTP 1.0規定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求處理後立即斷開TCP連接，服務器不跟蹤每個客戶也不記錄過去的請求。
-
在HTTP1.0中認爲每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。
-
HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。此外，服務器應該接受以絕對路徑。
-
HTTP/1.1在1.0的基礎上加入了一些cache的新特性，當緩存對象的Age超過Expire時變爲stale對象，cache不需要直接拋棄stale對象，而是與源服務器進行重新激活（revalidation）。
-
HTTP/1.1中引入了Chunked transfer-coding來解決大內存數據傳輸，發送方將消息分割成若干個任意大小的數據塊，每個數據塊在發送時都會附上塊的長度，最後用一個零長度的塊作爲消息結束的標誌。這種方法允許發送方只緩衝消息的一個片段，避免緩衝整個消息帶來的過載。
如何保證基於Hppt協議的接口安全性
- 選擇攔截器過濾：在請求的時候對請求方法進行一次攔截處理。比如非正常訪問的方法已經注入插入可執行語句參數驗證等在攔截中進行一次安全校驗保證請求不是非法請求。
-
數據加密：我們知道目前大部分APP接口都是通過Http協議進行調用的容易被抓包攔截。我們可以對客戶端和服務端都對數據傳輸的時候進行一個加密處理。常用的MD5 AES等。
-
簽名：根據用戶名或者用戶id，結合用戶的ip或者設備號，生成一個token。在請求後臺，後臺獲取http的head中的token，校驗是否合法。在使用Base64方式的編碼後，Token字符串還是有20多位，有的時候還是嫌它長了。由於GUID本身就有128bit，在要求有良好的可讀性的前提下，很難進一步改進了。那我們如何產生更短的字符串呢？還有一種方式就是較少Token的長度，不用GUID，而採用一定長度的隨機數，例如64bit，再用Base64 由於這裏只用了64bit，此時得到的字符串爲Onh0h95n7nw的形式，長度要短一半。這樣就方便攜帶多了。但是這種方式是沒有唯一性保證的。不過用來作爲身份認證的方式還是可以的（如網盤的提取碼）。
Http協議上傳文件，數據如何傳輸
- 通過對數據進行壓縮的方式進行傳輸。
- 首先服務端需要能支持文件的壓縮功能，其次瀏覽器能夠針對被壓縮的文件進行解壓縮。瀏覽器可以指定 Accept-Encoding 來高速服務器我當前支持的編碼類型Accept-Encoding:gzip,deflate。
- 進行分割傳輸
- 在傳輸大容量數據時，通過把數據分割成多塊，能夠讓瀏覽器逐步顯示頁面。這種把實體主體分塊的功能稱爲分塊傳輸編碼（Chunked Transfer Coding）。
Http的優點
- 支持客戶/服務器模式。
- 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
- 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type（Content-Type是HTTP包中用來表示內容類型的標識）加以標記。
- 無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
- 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
Http缺點
它是明文傳輸，明文傳輸就意味着報文中的所有信息都是暴露的，就可以通過監聽報文，就可以獲取到所有數據，進行竊取和修改，存在不安全性。
http是應用層協議，它是基於傳出層協議tcp來實現的，也就意味它的性能雖然不算太差，但不能完全適用於現在的互聯網。
一次Http請求的完整交互流程
客戶端先發送請求報文（包括：請求方式，請求地址，請求協議版本，請求頭信息以及主體內容）
服務器處理完會發送響應報文給客戶端（包括：協議版本，狀態碼，狀態碼短語，響應頭，主體）