HTTP和HTTPS的區別和常見的面試題

本篇會着重介紹http和https的區別和常見的面試題

常見的http和https面試題:

• Http與Https的基本概念和他們的區別
• HTTPS工做原理
• 經常使用的HTTP方法有哪些
• GET方法與POST方法的區別,何時應該使用GET何時應該使用POST
• HTTP請求報文與響應報文格式
• 常見的HTTP的狀態碼
• HTTP1.0,1.1,2.0之間的區別和特性
• 常見HTTP首部字段
• HTTP的缺點與HTTPS有哪些改進
• HTTP優化
• 一個頁面從輸入 URL 到頁面加載顯示完成，這個過程當中都發生了什麼？
• 爲何HTTPS安全

以上就是我進行總結的http和https的面試問題,接下來我會對每一個問題予以解答分析,相信帶着問題看答案會印象更深入

 Http與Https的基本概念和他們的區別

http的中文叫作超文本傳輸協議,它負責完成客戶端到服務端的一系列操做,是專門用來傳輸注入HTML的超媒體文檔等web內容的協議,它是基於傳輸層的TCP協議的應用層協議

https:https是基於安全套接字的http協議,也能夠理解爲是http+ssl/tls(數字證書)的組合

http和https的區別:

• HTTP 的 URL 以 http:// 開頭，而 HTTPS 的 URL 以 https:// 開頭
• HTTP 是不安全的，而 HTTPS 是安全的
• HTTP 標準端口是 80 ，而 HTTPS 的標準端口是 443
• 在 OSI 網絡模型中，HTTPS的加密是在傳輸層完成的,由於SSL是位於傳輸層的,TLS的前身是SSL,因此同理
• HTTP無需認證證書,而https須要認證證書 

小結：簡單來講http是用來進行html等超媒體傳輸的,可是http不安全,爲了安全,使用證書SSL和HTTP的方式進行數據傳輸,也就是HTTPS 

HTTPS工做原理

• 首先服務端給客戶端傳輸證書,這個證書就是公鑰,只是包含了不少的信息,好比說證書的辦法機構,證書的過時時間
• 客戶端進行證書的解析,好比說驗證辦法機構,過時時間,若是發現沒有任何問題,就生成一個隨機值(私鑰),而後用證書對這個私鑰進行加密,併發送給服務端
• 服務端使用私鑰將這個信息進行解密,獲得客戶端的私鑰,而後客戶端和服務端就能夠經過這個私鑰進行通訊了
• 服務端將消息進行對稱加密(簡單來講就是講消息和私鑰進行混合,除非知道私鑰不然服務進行解密),私鑰正好只有客戶端和服務端知道,因此信息就比較安全了
• 服務端將進行對稱加密後的消息進行傳送
• 客戶端使用私鑰進行信息的解密

小結：https就是使用了非對稱加密(一對公私鑰進行加密解密)進行公鑰傳輸,而後客戶端經過公鑰加密將本身的私鑰發給服務端,之後就可使用這個私鑰進行消息的收發了(圖文方式的https的加密原理,能夠點擊連接:到個人另外一篇博客進行學習)

經常使用的HTTP方法有哪些

• GET 從服務器得到資源

• POST 客戶端向服務器提交資源

• PUT 修改服務器相關資源  (已經不多用)

• DELETE 刪除服務器相關資源   (已經不多用)

小結：我基本用的是get和post,其他的兩個基本沒用過(被本身菜醒)

GET方法與POST方法的區別,何時應該使用GET何時應該使用POST

• GET：通常用於信息獲取，使用URL傳遞參數，對所發送信息的數量也有限制，通常在2000個字符
• POST：通常用於修改服務器上的資源，對所發送的信息數量沒有限制
• GET方式須要使用Request.QueryString來取得變量的值，而POST方式經過Request.Form來獲取變量的值，也就是說Get是經過地址欄來傳值，而Post是經過提交表單來傳值。

小結：對於信息的獲取通常使用get,在如下狀況下最好使用post請求:

1. 向服務器發送大量數據（由於post沒有發送數據的數量限制） 
2. 沒法使用緩存文件（會更新服務器上的文件）
3. 發送包含未知字符的用戶輸入時(親身經歷過GET的坑,淚目) 

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

這裏我推薦一位大神寫的很出色的博客,在這裏就不詳細寫了,博客地址:https://blog.csdn.net/a19881029/article/details/14002273

小結：主要的區別就是請求報文有url和請求方法,響應報文沒有這兩個,可是有狀態碼和狀態碼描述,還要注意一些常見的請求頭和響應頭表明的意思,好比說Connection:Keep-Alive

常見的HTTP的狀態碼

我在上面推薦的博客已經進行了一些經常使用狀態嗎的說明,個人一片文章裏面也有詳細說明

博客地址: https://blog.csdn.net/zhttly/article/details/82829854

HTTP1.0,1.1,2.0之間的區別和特性

http1.0:

• 是一種無狀態、無鏈接的應用層協議,每一個請求都會新建立一個tcp鏈接,完成後關閉服務端不跟蹤也不記錄過去的請求(無狀態),但正因頻繁建立鏈接,因爲tcp的慢啓動(爲了避免給網絡形成擁堵,在首次進行tcp請求的時候,會限制服務端和客戶端之間交互數據量的上限,大概爲14kb,以後以指數級增加),服務端接受請求,處理完,發送完響應以後就會將tcp鏈接關閉,這形成了很大的資源浪費,並且http1.0在一個請求接收到響應以後纔會接着發送下一個,這也形成了head of line blocking(隊頭阻塞),如今的瀏覽器爲了解決這個問題,採用了一個頁面能夠創建多個tcp鏈接的方式來進行

http1.1:

• 繼承了http1.0的特色,同時改善了http的一些問題,首先是長鏈接,http1.1新增長了connecion字段,裏面能夠設置keey-Alive(保持鏈接)或者close(關閉長鏈接),避免了每次請求都會新建鏈接,提升了網絡的利用率
• http1.1還增長了Host字段,用來明確表示瀏覽器要服務器上的哪個WEB站點,這才實現了在一臺WEB服務器上能夠在同一個IP地址和端口號上使用不一樣的主機名來建立多個虛擬WEB站點,同時還支持了斷點續傳
• http1.1的管道:能夠發送不少請求到服務端,可是服務端必需要按順序返回響應,由此能夠看出http1.1的管道只是把客戶端的請求序列變成了服務端的響應序列,仍是有問題,不少瀏覽器並非很支持
• http1.1還增長了緩存,斷點續傳

http2.0 : 

• 採用了二進制分幀(frame),在應用層和傳輸層之間增長了一個二進制分幀層,也就是把http1.x的header和body使用幀(frame)進行了封裝
  • 這裏明確幾個概念:流(stream) : 已經創建上鍊接的雙向字節流(也就是一個請求和其對應的響應) 消息:與邏輯消息對應的完整的一系列數據幀 幀(frame):http2.0進行通訊的最小單位,每一個幀都會包含一個頭部,這個頭部會包含當前幀所處的流
• 多路複用:全部的HTTP2.0通訊都在一個TCP鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流,每一個數據流都以消息的方式進行發送,這個發送可使亂序的,而後在經過每一個幀頭部的流標識符進行組裝,同時每一個數據流均可以設置優先級,可見http2.0真正實現了並行發送數據,這個是給予二進制分幀來實現的,接下來上一張圖片,展現一下一個在一個流中分幀傳輸的實例

                                                                               注:此圖片來源於百度圖片

• 頭部壓縮:就是和服務端約定頭部的數據的編碼,來將頭部進行壓縮後發送,這樣就能夠增長請求頭的容量

小結：這裏講的稍微有一點多,這裏給一個總結

1. http1.0:無鏈接,無狀態,一次請求一個tcp鏈接
2. http1.1:持久鏈接,請求管道化(有一些缺陷) ,增長了host字段,緩存,斷點續傳
3. http2.0 : 二進制分幀(多路複用的實現基礎), 多路複用,頭部壓縮

常見HTTP首部字段

這裏我仍是給你們推薦兩篇博客,寫的很詳細就不在這裏獻醜了

 地址1 : http://www.javashuo.com/article/p-minfzymc-u.html

 地址2 : https://blog.csdn.net/chenyuanyong110/article/details/52781462

 

HTTP的缺點與HTTPS有哪些改進

http的傳輸是不安全的,https是http+ssl證書進行加密的,因此比http安全(這裏的詳細過程上面有寫)

HTTP優化

• 資源內斂 : 資源內聯 : 既然每一個資源的首次訪問都會存在握手等rtt損耗,那麼越少數量的資源請求就越好,例如咋一個html中src訪問css,不如直接將其這個css集成到html中
• 圖片懶加載 ; 用到的時候在加載,這個已經很廣泛了,就不細說了
• 服務器渲染 : 讓服務端先將頁面渲染好,在發送給客戶端,也能夠減小rtt的次數

一個頁面從輸入 URL 到頁面加載顯示完成，這個過程當中都發生了什麼？

這裏個人另外一篇博客有詳細的說明 地址鏈接 ; https://blog.csdn.net/zhttly/article/details/82832582  (喜歡的話贊一下啊)

 爲何HTTPS安全

HTTPS是HTTP和SSL組合而成的,在傳輸層使用了SSL進行加密,保證了只有擁有私鑰的才能看到信

 

原博：https://blog.csdn.net/zhttly/article/details/82895713