前端面試查漏補缺--(九) HTTP與HTTPS

時間 2019-11-06

標籤前端面試補缺 http https 欄目快樂工作简体版

原文原文鏈接

前言

本系列最開始是爲了本身面試準備的.後來發現整理愈來愈多,差很少有十二萬字符,最後決定仍是分享出來給你們.html

爲了分享整理出來,花費了本身大量的時間,起碼是隻本身用的三倍時間.若是喜歡的話,歡迎收藏,關注我!謝謝!前端

文章連接

合集篇:

前端面試查漏補缺--Index篇(12萬字符合集) 包含目前已寫好的系列其餘十幾篇文章.後續新增值文章不會再在每篇添加連接,強烈建議議點贊,關注合集篇!!!!,謝謝!~vue

後續更新計劃

後續還會繼續添加設計模式,前端工程化,項目流程,部署,閉環,vue常考知識點 等內容.若是以爲內容不錯的話歡迎收藏,關注我!謝謝!面試

求一分內推

目前本人也在準備跳槽,但願各位大佬和HR小姐姐能夠內推一份靠譜的武漢前端崗位!郵箱:bupabuku@foxmail.com.謝謝啦!~算法

TCP/IP協議

在講解HTTP與HTTPS以前,有個知識點必須提早講解下,那就是TCP/IP協議.segmentfault

從字面意義上講，有人可能會認爲 TCP/IP 是指 TCP 和 IP 兩種協議。實際生活當中有時也確實就是指這兩種協議。然而在不少狀況下，它只是利用 IP 進行通訊時所必須用到的協議羣的統稱。具體來講，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都屬於 TCP/IP 協議。他們與 TCP 或 IP 的關係緊密，是互聯網必不可少的組成部分。TCP/IP 一詞泛指這些協議，所以，有時也稱 TCP/IP 爲網際協議羣。設計模式

互聯網進行通訊時，須要相應的網絡協議，TCP/IP 本來就是爲使用互聯網而開發制定的協議族。所以，互聯網的協議就是 TCP/IP，TCP/IP 就是互聯網的協議。前端工程化

更詳細全面的能夠查看一篇文章帶你熟悉 TCP/IP 協議（網絡協議篇二）跨域

TCP協議（傳輸控制協議）:應用程序之間的通訊

TCP確保數據包以正確的次序到達，而且嘗試確認數據包的內容沒有改變。 TCP在IP地址之上引端口（port），它容許計算機經過網絡提供各類服務。一些端口號爲不一樣的服務保留，並且這些端口號是衆所周知。瀏覽器

服務或者守護進程：在提供服務的機器上，有程序監聽特定端口上的通訊流。例如大多數電子郵件通訊流出如今端口25上，用於wwww的HTTP通訊流出如今80端口上。

當應用程序但願經過 TCP 與另外一個應用程序通訊時，它會發送一個通訊請求。這個請求必須被送到一個確切的地址。在雙方「握手」以後，TCP 將在兩個應用程序之間創建一個全雙工 (full-duplex) 的通訊，佔用兩個計算機之間整個的通訊線路。TCP 用於從應用程序到網絡的數據傳輸控制。TCP 負責在數據傳送以前將它們分割爲 IP 包，而後在它們到達的時候將它們重組。

TCP/IP 就是TCP 和 IP 兩個協議在一塊兒協同工做，有上下層次的關係。

TCP 負責應用軟件（好比你的瀏覽器）和網絡軟件之間的通訊。IP 負責計算機之間的通訊。TCP 負責將數據分割並裝入 IP 包，IP 負責將包發送至接受者，傳輸過程要經IP路由器負責根據通訊量、網絡中的錯誤或者其餘參數來進行正確地尋址，而後在它們到達的時候從新組合它們。

IP協議（網際協議）:計算機之間的通訊

IP協議是計算機用來相互識別的通訊的一種機制，每臺計算機都有一個IP.用來在internet上標識這臺計算機。 IP 負責在因特網上發送和接收數據包。 經過 IP，消息（或者其餘數據）被分割爲小的獨立的包，並經過因特網在計算機之間傳送。IP 負責將每一個包路由至它的目的地。

IP協議僅僅是容許計算機相互發消息，但它並不檢查消息是否以發送的次序到達並且沒有損壞（只檢查關鍵的頭數據）。爲了提供消息檢驗功能，直接在IP協議上設計了傳輸控制協議TCP。

HTTP協議

概念

HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。它可使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示(如文本先於圖形)等。

HTTP是客戶端瀏覽器或其餘程序與Web服務器之間的應用層通訊協議。 在Internet上的Web服務器上存放的都是超文本信息，客戶機須要經過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不只可用於Web訪問，也能夠用於其餘因特網/內聯網應用系統之間的通訊，從而實現各種應用資源超媒體訪問的集成。

咱們在瀏覽器的地址欄裏輸入的網站地址叫作URL (Uniform Resource Locator，統一資源定位符)。就像每家每戶都有一個門牌地址同樣，每一個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級連接時，URL就肯定了要瀏覽的地址。瀏覽器經過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。

HTTP 協議基礎

永遠都是客戶端發起請求，服務器回送響應 應用 HTTP 協議時，一定是一端擔任客戶端角色，另外一端擔任服務器端角色。僅從一條通訊線路來講，服務器端和客服端的角色是肯定的。HTTP 協議規定，請求從客戶端發出，最後服務器端響應該請求並返回。換句話說，確定是先從客戶端開始創建通訊的，服務器端在沒有接收到請求以前不會發送響應。
無狀態的協議 HTTP 是一種無狀態協議。協議自身不對請求和響應之間的通訊狀態進行保存。 也就是說在 HTTP 這個級別，協議對於發送過的請求或響應都不作持久化處理。這是爲了更快地處理大量事務，確保協議的可伸縮性，而特地把 HTTP 協議設計成如此簡單的。但是隨着 Web 的不斷髮展，咱們的不少業務都須要對通訊狀態進行保存。因而咱們引入了 Cookie 技術。有了 Cookie 再用 HTTP 協議通訊，就能夠管理狀態了。
Cookie 管理狀態 Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。 Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。服務器端發現客戶端發送過來的 Cookie 後，會去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。
URI 定位資源 HTTP 協議使用 URI 定位互聯網上的資源。正是由於 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。
持久鏈接 HTTP 協議的初始版本中，每進行一個 HTTP 通訊都要斷開一次 TCP 鏈接。好比使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請求該 HTML 頁面裏包含的其餘資源。所以，每次的請求都會形成無畏的 TCP 鏈接創建和斷開，增長通訊量的開銷。爲了解決上述 TCP 鏈接的問題，HTTP/1.1 和部分 HTTP/1.0 想出了持久鏈接的方法。其特色是，只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。旨在創建一次 TCP 鏈接後進行屢次請求和響應的交互。在 HTTP/1.1 中，全部的鏈接默認都是持久鏈接。
管線化 持久鏈接使得多數請求以管線化方式發送成爲可能。之前發送請求後需等待並接收到響應，才能發送下一個請求。管線化技術出現後，不用等待亦可發送下一個請求。這樣就能作到同時並行發送多個請求，而不須要一個接一個地等待響應了。 好比，當請求一個包含多張圖片的 HTML 頁面時，與挨個鏈接相比，用持久鏈接可讓請求更快結束。而管線化技術要比持久鏈接速度更快。請求數越多，時間差就越明顯。

HTTP工做過程

1,地址解析

如用客戶端瀏覽器請求這個頁面：localhost.com:8080/index.htm 從中分解出協議名、主機名、端口、對象路徑等部分，對於咱們的這個地址，解析獲得的結果以下：

協議名：http
主機名：localhost.com
端口：8080
對象路徑：/index.htm
複製代碼
複製代碼

在這一步，須要域名系統DNS解析域名,得主機的IP地址。

2,封裝HTTP請求數據包

把以上部分結合本機本身的信息，封裝成一個HTTP請求數據包

3,封裝成TCP包，創建TCP鏈接（TCP的三次握手）

在HTTP工做開始以前，客戶機（Web瀏覽器）首先要經過網絡與服務器創建鏈接，該鏈接是經過TCP來完成的，該協議與IP協議共同構建Internet，即著名的TCP/IP協議族，所以Internet又被稱做是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議，根據規則，只有低層協議創建以後才能，才能進行更層協議的鏈接，所以，首先要創建TCP鏈接，通常TCP鏈接的端口號是80。這裏是8080端口。

4,客戶端向服務器發送請求命令

創建TCP鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可內容。

5,服務器響應

服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。

實體消息是服務器向瀏覽器發送頭信息後，它會發送一個空白行來表示頭信息的發送到此爲結束，接着，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據.

6,服務器關閉TCP鏈接

通常狀況下，一旦服務器向客戶端返回了請求數據，它就要關閉 TCP 鏈接，而後若是客戶端或者服務器在其頭信息加入了這行代碼 Connection:keep-alive ，TCP 鏈接在發送後將仍然保持打開狀態，因而，客戶端能夠繼續經過相同的鏈接發送請求。保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了網絡帶寬。

HTTP 協議報文結構與頭部

這部分涉及到的知識特別繁瑣,受限於篇幅,這裏就不贅述了.能夠參考這篇文章的四,五,六章做了超詳盡的說明.

HTTP的請求方法

GET: 獲取URL指定的資源；
POST：傳輸實體信息
PUT：上傳文件
DELETE：刪除文件
HEAD：獲取報文首部，與GET相比，不返回報文主體部分
OPTIONS：詢問支持的方法
TRACE：追蹤請求的路徑；
CONNECT：要求在與代理服務器通訊時創建隧道，使用隧道進行TCP通訊。主要使用SSL和TLS將數據加密後經過網絡隧道進行傳輸。

複製代碼

HTTP狀態碼

菜鳥教程裏有完整的說明.

HTTP缺點

通訊使用明文，容易被竊聽
不驗證通訊方的身份，可能遭遇假裝
沒法證實報文的完整性，有可能遭遇篡改

HTTPS協議

概念

超文本傳輸安全協議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，常稱爲HTTP over TLS，HTTP over SSL或HTTP Secure）是一種經過計算機網絡進行安全通訊的傳輸協議。

HTTPS經由HTTP進行通訊，但利用SSL/TLS來加密數據包。

HTTPS開發的主要目的，是提供對網站服務器的身份認證，保護交換數據的隱私與完整性。

簡而言之: HTTPS是在HTTP上創建SSL加密層，並對傳輸數據進行加密，是HTTP協議的安全版。

HTTPS比HTTP多了一層TLS/SSL協議

TLS/SSL全稱安全傳輸層協議Transport Layer Security, 是介於TCP和HTTP之間的一層安全協議，不影響原有的TCP協議和HTTP協議，因此使用HTTPS基本上不須要對HTTP頁面進行太多的改造。

HTTPS原理

這部分細提及來,真的不少.這裏我概括簡單說一下:

客戶端向服務器端索要並驗證公鑰。這一階段使用的是非對稱加密傳輸(RSA),服務端將數字證書發給客戶端.其中數字證書包括:公鑰和數字簽名.客戶端在拿到後對二者進行校驗.
在非對稱加密傳輸中,兩端協商生成"對話密鑰"。
雙方採用"對話密鑰"進行對稱加密通訊。

受限於篇幅,我就不展開了.要否則就太多太多了.這裏我推薦幾篇文章你們全面理解:

以通俗易懂的方式理解https原理: 文章
關於SSL/TLS 原理的詳細說明:文章
關於PKI體系與證書的說明:文章

HTTP 與 HTTPS 的區別

HTTP 是明文傳輸，HTTPS 經過 SSL\TLS 進行了加密
HTTP 的端口號是 80，HTTPS 是 443
HTTPS 須要到 CA 申請證書，通常免費證書不多，須要交費
HTTP 的鏈接很簡單，是無狀態的；HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，比 HTTP 協議安全。

HTTPS主要做用是：

對數據進行加密，並創建一個信息安全通道，來保證傳輸過程當中的數據安全
對網站服務器進行真實身份認證

HTTPS缺點

HTTPS協議握手階段比較費時，會使頁面的加載時間延長近50%，增長10%到20%的耗電；
https鏈接緩存不如http高效，若是是大流量網站,則會形成流量成本過高。
https鏈接服務器端資源佔用高不少，支持訪客稍多的網站須要投入更大的成本，若是所有采用https，基於大部分計算資源閒置的假設的VPS的平均成本會上去。
SSL證書須要錢，功能越強大的證書費用越高，我的網站、小網站沒有必要通常不會用。
SSL證書一般須要綁定IP，不能再同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗(SSL有擴展能夠部分解決這個問題，可是比較麻煩，並且要求瀏覽器、操做系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用)。

HTTPS接入優化

CDN接入

HTTPS 增長的延時主要是傳輸延時 RTT，RTT 的特色是節點越近延時越小，CDN 自然離用戶最近，所以選擇使用 CDN 做爲 HTTPS 接入的入口，將可以極大減小接入延時。CDN 節點經過和業務服務器維持長鏈接、會話複用和鏈路質量優化等可控方法，極大減小 HTTPS 帶來的延時。

會話緩存

雖然前文提到 HTTPS 即便採用會話緩存也要至少1*RTT的延時，可是至少延時已經減小爲原來的一半，明顯的延時優化;同時，基於會話緩存創建的 HTTPS 鏈接不須要服務器使用RSA私鑰解密獲取 Pre-master 信息，能夠省去CPU 的消耗。若是業務訪問鏈接集中，緩存命中率高，則HTTPS的接入能力講明顯提高。當前TRP平臺的緩存命中率高峯時期大於30%，10k/s的接入資源實際能夠承載13k/的接入，收效很是可觀。

硬件加速

爲接入服務器安裝專用的SSL硬件加速卡，做用相似 GPU，釋放 CPU，可以具備更高的 HTTPS 接入能力且不影響業務程序的。測試某硬件加速卡單卡能夠提供35k的解密能力，至關於175核 CPU，至少至關於7臺24核的服務器，考慮到接入服務器其它程序的開銷，一張硬件卡能夠實現接近10臺服務器的接入能力。

遠程解密

本地接入消耗過多的 CPU 資源，浪費了網卡和硬盤等資源，考慮將最消耗 CPU 資源的RSA解密計算任務轉移到其它服務器，如此則能夠充分發揮服務器的接入能力，充分利用帶寬與網卡資源。遠程解密服務器能夠選擇 CPU 負載較低的機器充當，實現機器資源複用，也能夠是專門優化的高計算性能的服務器。當前也是 CDN 用於大規模HTTPS接入的解決方案之一。

SPDY/HTTP2

前面的方法分別從減小傳輸延時和單機負載的方法提升 HTTPS 接入性能，可是方法都基於不改變 HTTP 協議的基礎上提出的優化方法，SPDY/HTTP2 利用 TLS/SSL 帶來的優點，經過修改協議的方法來提高 HTTPS 的性能，提升下載速度等。