面試 HTTP ，99% 的面試官都愛問這些問題

時間 2020-04-21

標籤面試 http 99% 愛問這些問題欄目快樂工作简体版

原文原文鏈接

HTTP 和 HTTPS 的區別

HTTP 是一種 超文本傳輸協議(Hypertext Transfer Protocol)，HTTP 是一個在計算機世界裏專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規範php

HTTP 主要內容分爲三部分，超文本（Hypertext）、傳輸（Transfer）、協議（Protocol）。html

超文本就是不僅僅只是本文，它還能夠傳輸圖片、音頻、視頻，甚至點擊文字或圖片可以進行超連接的跳轉。
上面這些概念能夠統稱爲數據，傳輸就是數據須要通過一系列的物理介質從一個端系統傳送到另一個端系統的過程。一般咱們把傳輸數據包的一方稱爲請求方，把接到二進制數據包的一方稱爲應答方。
而協議指的就是是網絡中(包括互聯網)傳遞、管理信息的一些規範。如同人與人之間相互交流是須要遵循必定的規矩同樣，計算機之間的相互通訊須要共同遵照必定的規則，這些規則就稱爲協議，只不過是網絡協議。

說到 HTTP，不得不提的就是 TCP/IP 網絡模型，通常是五層模型。以下圖所示web

可是也能夠分爲四層，就是把鏈路層和物理層都表示爲網絡接口層面試

還有一種就是 OSI 七層網絡模型，它就是在五層協議之上加了表示層和會話層算法

而 HTTPS 的全稱是 Hypertext Transfer Protocol Secure，從名稱咱們能夠看出 HTTPS 要比 HTTPS 多了 secure 安全性這個概念，實際上， HTTPS 並非一個新的應用層協議，它其實就是 HTTP + TLS/SSL 協議組合而成，而安全性的保證正是 TLS/SSL 所作的工做。chrome

也就是說，HTTPS 就是身披了一層 SSL 的 HTTP。數據庫

那麼，HTTP 和 HTTPS 的主要區別是什麼呢？跨域

最簡單的，HTTP 在地址欄上的協議是以 http:// 開頭，而 HTTPS 在地址欄上的協議是以 https:// 開頭

http://www.cxuanblog.com/
https://www.cxuanblog.com/
複製代碼

HTTP 是未經安全加密的協議，它的傳輸過程容易被攻擊者監聽、數據容易被竊取、發送方和接收方容易被僞造；而 HTTPS 是安全的協議，它經過 密鑰交換算法 - 簽名算法 - 對稱加密算法 - 摘要算法 可以解決上面這些問題。

HTTP 的默認端口是 80，而 HTTPS 的默認端口是 443。

HTTP Get 和 Post 區別

HTTP 中包括許多方法，Get 和 Post 是 HTTP 中最經常使用的兩個方法，基本上使用 HTTP 方法中有 99% 都是在使用 Get 方法和 Post 方法，因此有必要咱們對這兩個方法有更加深入的認識。瀏覽器

get 方法通常用於請求，好比你在瀏覽器地址欄輸入 www.cxuanblog.com 其實就是發送了一個 get 請求，它的主要特徵是請求服務器返回資源，而 post 方法通常用於 <form> 表單的提交，至關因而把信息提交給服務器，等待服務器做出響應，get 至關於一個是 pull/拉的操做，而 post 至關因而一個 push/推的操做。
get 方法是不安全的，由於你在發送請求的過程當中，你的請求參數會拼在 URL 後面，從而致使容易被攻擊者竊取，對你的信息形成破壞和僞造；

/test/demo_form.asp?name1=value1&name2=value2
複製代碼

而 post 方法是把參數放在請求體 body 中的，這對用戶來講不可見。緩存

POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2
複製代碼

get 請求的 URL 有長度限制，而 post 請求會把參數和值放在消息體中，對數據長度沒有要求。
get 請求會被瀏覽器主動 cache，而 post 不會，除非手動設置。
get 請求在瀏覽器反覆的 回退/前進 操做是無害的，而 post 操做會再次提交表單請求。
get 請求在發送過程當中會產生一個 TCP 數據包；post 在發送過程當中會產生兩個 TCP 數據包。對於 get 方式的請求，瀏覽器會把 http header 和 data 一併發送出去，服務器響應 200（返回數據）；而對於 post，瀏覽器先發送 header，服務器響應 100 continue，瀏覽器再發送 data，服務器響應 200 ok（返回數據）。

什麼是無狀態協議，HTTP 是無狀態協議嗎，怎麼解決

無狀態協議(Stateless Protocol) 就是指瀏覽器對於事務的處理沒有記憶能力。舉個例子來講就是好比客戶請求得到網頁以後關閉瀏覽器，而後再次啓動瀏覽器，登陸該網站，可是服務器並不知道客戶關閉了一次瀏覽器。

HTTP 就是一種無狀態的協議，他對用戶的操做沒有記憶能力。可能大多數用戶不相信，他可能以爲每次輸入用戶名和密碼登錄一個網站後，下次登錄就再也不從新輸入用戶名和密碼了。這其實不是 HTTP 作的事情，起做用的是一個叫作 小甜餅(Cookie) 的機制。它可以讓瀏覽器具備記憶能力。

若是你的瀏覽器容許 cookie 的話，查看方式 chrome://settings/content/cookies

也就說明你的記憶芯片通電了...... 當你想服務端發送請求時，服務端會給你發送一個認證信息，服務器第一次接收到請求時，開闢了一塊 Session 空間（建立了Session對象），同時生成一個 sessionId ，並經過響應頭的 **Set-Cookie：JSESSIONID=XXXXXXX **命令，向客戶端發送要求設置 Cookie 的響應；客戶端收到響應後，在本機客戶端設置了一個 **JSESSIONID=XXXXXXX **的 Cookie 信息，該 Cookie 的過時時間爲瀏覽器會話結束；

接下來客戶端每次向同一個網站發送請求時，請求頭都會帶上該 Cookie信息（包含 sessionId ），而後，服務器經過讀取請求頭中的 Cookie 信息，獲取名稱爲 JSESSIONID 的值，獲得這次請求的 sessionId。這樣，你的瀏覽器才具備了記憶能力。

還有一種方式是使用 JWT 機制，它也是可以讓你的瀏覽器具備記憶能力的一種機制。與 Cookie 不一樣，JWT 是保存在客戶端的信息，它普遍的應用於單點登陸的狀況。JWT 具備兩個特色

JWT 的 Cookie 信息存儲在客戶端，而不是服務端內存中。也就是說，JWT 直接本地進行驗證就能夠，驗證完畢後，這個 Token 就會在 Session 中隨請求一塊兒發送到服務器，經過這種方式，能夠節省服務器資源，而且 token 能夠進行屢次驗證。
JWT 支持跨域認證，Cookies 只能用在單個節點的域或者它的子域中有效。若是它們嘗試經過第三個節點訪問，就會被禁止。使用 JWT 能夠解決這個問題，使用 JWT 可以經過多個節點進行用戶認證，也就是咱們常說的跨域認證。

UDP 和 TCP 的區別

TCP 和 UDP 都位於計算機網絡模型中的運輸層，它們負責傳輸應用層產生的數據。下面咱們就來聊一聊 TCP 和 UDP 分別的特徵和他們的區別

UDP 是什麼

UDP 的全稱是 User Datagram Protocol，用戶數據報協議。它不須要所謂的握手操做，從而加快了通訊速度，容許網絡上的其餘主機在接收方贊成通訊以前進行數據傳輸。

數據報是與分組交換網絡關聯的傳輸單元。

UDP 的特色主要有

UDP 可以支持容忍數據包丟失的帶寬密集型應用程序
UDP 具備低延遲的特色
UDP 可以發送大量的數據包
UDP 可以容許 DNS 查找，DNS 是創建在 UDP 之上的應用層協議。

TCP 是什麼

TCP 的全稱是Transmission Control Protocol ，傳輸控制協議。它可以幫助你肯定計算機鏈接到 Internet 以及它們之間的數據傳輸。經過三次握手來創建 TCP 鏈接，三次握手就是用來啓動和確認 TCP 鏈接的過程。一旦鏈接創建後，就能夠發送數據了，當數據傳輸完成後，會經過關閉虛擬電路來斷開鏈接。

TCP 的主要特色有

TCP 可以確保鏈接的創建和數據包的發送
TCP 支持錯誤重傳機制
TCP 支持擁塞控制，可以在網絡擁堵的狀況下延遲發送
TCP 可以提供錯誤校驗和，甄別有害的數據包。

TCP 和 UDP 的不一樣

下面爲你羅列了一些 TCP 和 UDP 的不一樣點，方便理解，方便記憶。

TCP	UDP
TCP 是面向鏈接的協議	UDP 是無鏈接的協議
TCP 在發送數據前先須要創建鏈接，而後再發送數據	UDP 無需創建鏈接就能夠直接發送大量數據
TCP 會按照特定順序從新排列數據包	UDP 數據包沒有固定順序，全部數據包都相互獨立
TCP 傳輸的速度比較慢	UDP 的傳輸會更快
TCP 的頭部字節有 20 字節	UDP 的頭部字節只須要 8 個字節
TCP 是重量級的，在發送任何用戶數據以前，TCP須要三次握手創建鏈接。	UDP 是輕量級的。沒有跟蹤鏈接，消息排序等。
TCP 會進行錯誤校驗，並可以進行錯誤恢復	UDP 也會錯誤檢查，但會丟棄錯誤的數據包。
TCP 有發送確認	UDP 沒有發送確認
TCP 會使用握手協議，例如 SYN，SYN-ACK，ACK	無握手協議
TCP 是可靠的，由於它能夠確保將數據傳送到路由器。	在 UDP 中不能保證將數據傳送到目標。

TCP 三次握手和四次揮手

TCP 三次握手和四次揮手也是面試題的熱門考點，它們分別對應 TCP 的鏈接和釋放過程。下面就來簡單認識一下這兩個過程

TCP 三次握手

在瞭解具體的流程前，咱們須要先認識幾個概念

消息類型	描述
SYN	這個消息是用來初始化和創建鏈接的。
ACK	幫助對方確認收到的 SYN 消息
SYN-ACK	本地的 SYN 消息和較早的 ACK 數據包
FIN	用來斷開鏈接

SYN：它的全稱是 Synchronize Sequence Numbers，同步序列編號。是 TCP/IP 創建鏈接時使用的握手信號。在客戶機和服務器之間創建 TCP 鏈接時，首先會發送的一個信號。客戶端在接受到 SYN 消息時，就會在本身的段內生成一個隨機值 X。
SYN-ACK：服務器收到 SYN 後，打開客戶端鏈接，發送一個 SYN-ACK 做爲答覆。確認號設置爲比接收到的序列號多一個，即 X + 1，服務器爲數據包選擇的序列號是另外一個隨機數 Y。
ACK：Acknowledge character, 確認字符，表示發來的數據已確認接收無誤。最後，客戶端將 ACK 發送給服務器。序列號被設置爲所接收的確認值即 Y + 1。

若是用現實生活來舉例的話就是

小明 - 客戶端小紅 - 服務端

小明給小紅打電話，接通了後，小明說喂，能聽到嗎，這就至關因而鏈接創建。
小紅給小明迴應，能聽到，你能聽到我說的話嗎，這就至關因而請求響應。
小明聽到小紅的迴應後，好的，這至關因而鏈接確認。在這以後小明和小紅就能夠通話/交換信息了。

TCP 四次揮手

在鏈接終止階段使用四次揮手，鏈接的每一端都會獨立的終止。下面咱們來描述一下這個過程。

首先，客戶端應用程序決定要終止鏈接(這裏服務端也能夠選擇斷開鏈接)。這會使客戶端將 FIN 發送到服務器，並進入 FIN_WAIT_1 狀態。當客戶端處於 FIN_WAIT_1 狀態時，它會等待來自服務器的 ACK 響應。
而後第二步，當服務器收到 FIN 消息時，服務器會馬上向客戶端發送 ACK 確認消息。
當客戶端收到服務器發送的 ACK 響應後，客戶端就進入 FIN_WAIT_2 狀態，而後等待來自服務器的 FIN 消息
服務器發送 ACK 確認消息後，一段時間（能夠進行關閉後）會發送 FIN 消息給客戶端，告知客戶端能夠進行關閉。
當客戶端收到從服務端發送的 FIN 消息時，客戶端就會由 FIN_WAIT_2 狀態變爲 TIME_WAIT 狀態。處於 TIME_WAIT 狀態的客戶端容許從新發送 ACK 到服務器爲了防止信息丟失。客戶端在 TIME_WAIT 狀態下花費的時間取決於它的實現，在等待一段時間後，鏈接關閉，客戶端上全部的資源（包括端口號和緩衝區數據）都被釋放。

仍是能夠用上面那個通話的例子來進行描述

小明對小紅說，我全部的東西都說完了，我要掛電話了。
小紅說，收到，我這邊還有一些東西沒說。
通過若干秒後，小紅也說完了，小紅說，我說完了，如今能夠掛斷了
小明收到消息後，又等了若干時間後，掛斷了電話。

簡述 HTTP1.0/1.1/2.0 的區別

HTTP 1.0

HTTP 1.0 是在 1996 年引入的，從那時開始，它的普及率就達到了驚人的效果。

HTTP 1.0 僅僅提供了最基本的認證，這時候用戶名和密碼還未經加密，所以很容易收到窺探。
HTTP 1.0 被設計用來使用短連接，即每次發送數據都會通過 TCP 的三次握手和四次揮手，效率比較低。
HTTP 1.0 只使用 header 中的 If-Modified-Since 和 Expires 做爲緩存失效的標準。
HTTP 1.0 不支持斷點續傳，也就是說，每次都會傳送所有的頁面和數據。
HTTP 1.0 認爲每臺計算機只能綁定一個 IP，因此請求消息中的 URL 並無傳遞主機名（hostname）。

HTTP 1.1

HTTP 1.1 是 HTTP 1.0 開發三年後出現的，也就是 1999 年，它作出瞭如下方面的變化

HTTP 1.1 使用了摘要算法來進行身份驗證
HTTP 1.1 默認使用長鏈接，長鏈接就是隻需一次創建就能夠傳輸屢次數據，傳輸完成後，只須要一次切斷鏈接便可。長鏈接的鏈接時長能夠經過請求頭中的 keep-alive 來設置
HTTP 1.1 中新增長了 E-tag，If-Unmodified-Since, If-Match, If-None-Match 等緩存控制標頭來控制緩存失效。
HTTP 1.1 支持斷點續傳，經過使用請求頭中的 Range 來實現。
HTTP 1.1 使用了虛擬網絡，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。

HTTP 2.0

HTTP 2.0 是 2015 年開發出來的標準，它主要作的改變以下

頭部壓縮，因爲 HTTP 1.1 常常會出現 User-Agent、Cookie、Accept、Server、Range 等字段可能會佔用幾百甚至幾千字節，而 Body 卻常常只有幾十字節，因此致使頭部偏重。HTTP 2.0 使用 HPACK 算法進行壓縮。
二進制格式，HTTP 2.0 使用了更加靠近 TCP/IP 的二進制格式，而拋棄了 ASCII 碼，提高了解析效率
強化安全，因爲安全已經成爲重中之重，因此 HTTP2.0 通常都跑在 HTTPS 上。
多路複用，即每個請求都是是用做鏈接共享。一個請求對應一個id，這樣一個鏈接上能夠有多個請求。

請你說一下 HTTP 常見的請求頭

這個問題比較開放，由於 HTTP 請求頭有不少，這裏只簡單舉出幾個例子，具體的能夠參考個人另外一篇文章

mp.weixin.qq.com/s/XZZR0945I…

HTTP 標頭會分爲四種，分別是 通用標頭、實體標頭、請求標頭、響應標頭。分別介紹一下

通用標頭

通用標頭主要有三個，分別是 Date、Cache-Control 和 Connection

Date

Date 是一個通用標頭，它能夠出如今請求標頭和響應標頭中，它的基本表示以下

Date: Wed, 21 Oct 2015 07:28:00 GMT 
複製代碼

表示的是格林威治標準時間，這個時間要比北京時間慢八個小時

Cache-Control

Cache-Control 是一個通用標頭，他能夠出如今請求標頭和響應標頭中，Cache-Control 的種類比較多，雖說這是一個通用標頭，可是又一些特性是請求標頭具備的，有一些是響應標頭纔有的。主要大類有 可緩存性、閾值性、 從新驗證並從新加載 和其餘特性

Connection

Connection 決定當前事務（一次三次握手和四次揮手）完成後，是否會關閉網絡鏈接。Connection 有兩種，一種是持久性鏈接，即一次事務完成後不關閉網絡鏈接

Connection: keep-alive
複製代碼

另外一種是非持久性鏈接，即一次事務完成後關閉網絡鏈接

Connection: close
複製代碼

HTTP1.1 其餘通用標頭以下

實體標頭

實體標頭是描述消息正文內容的 HTTP 標頭。實體標頭用於 HTTP 請求和響應中。頭部Content-Length、 Content-Language、 Content-Encoding 是實體頭。

Content-Length 實體報頭指示實體主體的大小，以字節爲單位，發送到接收方。
Content-Language 實體報頭描述了客戶端或者服務端可以接受的語言。
Content-Encoding 這又是一個比較麻煩的屬性，這個實體報頭用來壓縮媒體類型。Content-Encoding 指示對實體應用了何種編碼。

常見的內容編碼有這幾種： gzip、compress、deflate、identity ，這個屬性能夠應用在請求報文和響應報文中

Accept-Encoding: gzip, deflate //請求頭
Content-Encoding: gzip  //響應頭
複製代碼

下面是一些實體標頭字段

請求標頭

Host

Host 請求頭指明瞭服務器的域名（對於虛擬主機來講），以及（可選的）服務器監聽的 TCP 端口號。若是沒有給定端口號，會自動使用被請求服務的默認端口（好比請求一個 HTTP 的 URL 會自動使用 80 做爲端口）。

Host: developer.mozilla.org
複製代碼

上面的 Accpet、 Accept-Language、Accept-Encoding 都是屬於內容協商的請求標頭。

Referer

HTTP Referer 屬性是請求標頭的一部分，當瀏覽器向 web 服務器發送請求的時候，通常會帶上 Referer，告訴服務器該網頁是從哪一個頁面連接過來的，服務器所以能夠得到一些信息用於處理。

Referer: https://developer.mozilla.org/testpage.html
複製代碼

If-Modified-Since

If-Modified-Since 一般會與 If-None-Match 搭配使用，If-Modified-Since 用於確認代理或客戶端擁有的本地資源的有效性。獲取資源的更新日期時間，可經過確認首部字段 Last-Modified 來肯定。

大白話說就是若是在 Last-Modified 以後更新了服務器資源，那麼服務器會響應 200，若是在 Last-Modified 以後沒有更新過資源，則返回 304。

If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT
複製代碼

If-None-Match

If-None-Match HTTP 請求標頭使請求成爲條件請求。對於 GET 和 HEAD 方法，僅當服務器沒有與給定資源匹配的 ETag 時，服務器纔會以 200 狀態發送回請求的資源。對於其餘方法，僅當最終現有資源的ETag與列出的任何值都不匹配時，纔會處理請求。

If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"
複製代碼

Accept

接受請求 HTTP 標頭會通告客戶端其可以理解的 MIME 類型

Accept-Charset

accept-charset 屬性規定服務器處理表單數據所接受的字符集。

經常使用的字符集有： UTF-8 - Unicode 字符編碼； ISO-8859-1 - 拉丁字母表的字符編碼

Accept-Language

首部字段 Accept-Language 用來告知服務器用戶代理可以處理的天然語言集（指中文或英文等），以及天然語言集的相對優先級。可一次指定多種天然語言集。

請求標頭咱們大概就介紹這幾種，後面會有一篇文章詳細深挖全部的響應頭的，下面是一個響應頭的彙總，基於 HTTP 1.1

響應標頭

Access-Control-Allow-Origin

一個返回的 HTTP 標頭可能會具備 Access-Control-Allow-Origin ，Access-Control-Allow-Origin 指定一個來源，它告訴瀏覽器容許該來源進行資源訪問。

Keep-Alive

Keep-Alive 表示的是 Connection 非持續鏈接的存活時間，能夠進行指定。

Server

服務器標頭包含有關原始服務器用來處理請求的軟件的信息。

應該避免使用過於冗長和詳細的 Server 值，由於它們可能會泄露內部實施細節，這可能會使攻擊者容易地發現並利用已知的安全漏洞。例以下面這種寫法

Server: Apache/2.4.1 (Unix)
複製代碼

Set-Cookie

Set-Cookie 用於服務器向客戶端發送 sessionID。

Transfer-Encoding

首部字段 Transfer-Encoding 規定了傳輸報文主體時採用的編碼方式。

HTTP /1.1 的傳輸編碼方式僅對分塊傳輸編碼有效。

X-Frame-Options

HTTP 首部字段是能夠自行擴展的。因此在 Web 服務器和瀏覽器的應用上，會出現各類非標準的首部字段。

首部字段 X-Frame-Options 屬於 HTTP 響應首部，用於控制網站內容在其餘 Web 網站的 Frame 標籤內的顯示問題。其主要目的是爲了防止點擊劫持（clickjacking）攻擊。

下面是一個響應頭的彙總，基於 HTTP 1.1

地址欄輸入 URL 發生了什麼

這道題也是一道常常會考的面試題。那麼下面咱們就來探討一下從你輸入 URL 後到響應，都經歷了哪些過程。

首先，你須要在瀏覽器中的 URL 地址上，輸入你想訪問的地址，以下

你應該訪問不到的，對不對~

而後，瀏覽器會根據你輸入的 URL 地址，去查找域名是否被本地 DNS 緩存，不一樣瀏覽器對 DNS 的設置不一樣，若是瀏覽器緩存了你想訪問的 URL 地址，那就直接返回 ip。若是沒有緩存你的 URL 地址，瀏覽器就會發起系統調用來查詢本機 hosts 文件是否有配置 ip 地址，若是找到，直接返回。若是找不到，就向網絡中發起一個 DNS 查詢。

首先來看一下 DNS 是啥，互聯網中識別主機的方式有兩種，經過主機名和 IP 地址。咱們人喜歡用名字的方式進行記憶，可是通訊鏈路中的路由卻喜歡定長、有層次結構的 IP 地址。因此就須要一種可以把主機名到 IP 地址的轉換服務，這種服務就是由 DNS 提供的。DNS 的全稱是 Domain Name System 域名系統。DNS 是一種由分層的 DNS 服務器實現的分佈式數據庫。DNS 運行在 UDP 上，使用 53 端口。

DNS 是一種分層數據庫，它的主要層次結構以下

通常域名服務器的層次結構主要是以上三種，除此以外，還有另外一類重要的 DNS 服務器，它是 本地 DNS 服務器(local DNS server)。嚴格來講，本地 DNS 服務器並不屬於上述層次結構，可是本地 DNS 服務器又是相當重要的。每一個 ISP(Internet Service Provider) 好比居民區的 ISP 或者一個機構的 ISP 都有一臺本地 DNS 服務器。當主機和 ISP 進行鏈接時，該 ISP 會提供一臺主機的 IP 地址，該主機會具備一臺或多臺其本地 DNS 服務器的 IP地址。經過訪問網絡鏈接，用戶可以容易的肯定 DNS 服務器的 IP地址。當主機發出 DNS 請求後，該請求被髮往本地 DNS 服務器，它起着代理的做用，並將該請求轉發到 DNS 服務器層次系統中。

首先，查詢請求會先找到本地 DNS 服務器來查詢是否包含 IP 地址，若是本地 DNS 沒法查詢到目標 IP 地址，就會向根域名服務器發起一個 DNS 查詢。

注意：DNS 涉及兩種查詢方式：一種是遞歸查詢(Recursive query) ，一種是迭代查詢(Iteration query)。《計算機網絡：自頂向下方法》居然沒有給出遞歸查詢和迭代查詢的區別，找了一下網上的資料大概明白了下。

若是根域名服務器沒法告知本地 DNS 服務器下一步須要訪問哪一個頂級域名服務器，就會使用遞歸查詢；

若是根域名服務器可以告知 DNS 服務器下一步須要訪問的頂級域名服務器，就會使用迭代查詢。

在由根域名服務器 -> 頂級域名服務器 -> 權威 DNS 服務器後，由權威服務器告訴本地服務器目標 IP 地址，再有本地 DNS 服務器告訴用戶須要訪問的 IP 地址。

第三步，瀏覽器須要和目標服務器創建 TCP 鏈接，須要通過三次握手的過程，具體的握手過程請參考上面的回答。
在創建鏈接後，瀏覽器會向目標服務器發起 HTTP-GET 請求，包括其中的 URL，HTTP 1.1 後默認使用長鏈接，只須要一次握手便可屢次傳輸數據。
若是目標服務器只是一個簡單的頁面，就會直接返回。可是對於某些大型網站的站點，每每不會直接返回主機名所在的頁面，而會直接重定向。返回的狀態碼就不是 200 ，而是 301,302 以 3 開頭的重定向碼，瀏覽器在獲取了重定向響應後，在響應報文中 Location 項找到重定向地址，瀏覽器從新第一步訪問便可。
而後瀏覽器從新發送請求，攜帶新的 URL，返回狀態碼 200 OK，表示服務器能夠響應請求，返回報文。

HTTPS 的工做原理

咱們上面描述了一下 HTTP 的工做原理，下面來說述一下 HTTPS 的工做原理。由於咱們知道 HTTPS 不是一種新出現的協議，而是

因此，咱們探討 HTTPS 的握手過程，其實就是 SSL/TLS 的握手過程。

TLS 旨在爲 Internet 提供通訊安全的加密協議。TLS 握手是啓動和使用 TLS 加密的通訊會話的過程。在 TLS 握手期間，Internet 中的通訊雙方會彼此交換信息，驗證密碼套件，交換會話密鑰。

每當用戶經過 HTTPS 導航到具體的網站併發送請求時，就會進行 TLS 握手。除此以外，每當其餘任何通訊使用HTTPS（包括 API 調用和在 HTTPS 上查詢 DNS）時，也會發生 TLS 握手。

TLS 具體的握手過程會根據所使用的密鑰交換算法的類型和雙方支持的密碼套件而不一樣。咱們以RSA 非對稱加密來討論這個過程。整個 TLS 通訊流程圖以下

在進行通訊前，首先會進行 HTTP 的三次握手，握手完成後，再進行 TLS 的握手過程
ClientHello：客戶端經過向服務器發送 hello 消息來發起握手過程。這個消息中會夾帶着客戶端支持的 TLS 版本號(TLS1.0 、TLS1.二、TLS1.3) 、客戶端支持的密碼套件、以及一串 客戶端隨機數。
ServerHello：在客戶端發送 hello 消息後，服務器會發送一條消息，這條消息包含了服務器的 SSL 證書、服務器選擇的密碼套件和服務器生成的隨機數。
認證(Authentication)：客戶端的證書頒發機構會認證 SSL 證書，而後發送 Certificate 報文，報文中包含公開密鑰證書。最後服務器發送 ServerHelloDone 做爲 hello 請求的響應。第一部分握手階段結束。
加密階段：在第一個階段握手完成後，客戶端會發送 ClientKeyExchange 做爲響應，這個響應中包含了一種稱爲 The premaster secret 的密鑰字符串，這個字符串就是使用上面公開密鑰證書進行加密的字符串。隨後客戶端會發送 ChangeCipherSpec，告訴服務端使用私鑰解密這個 premaster secret 的字符串，而後客戶端發送 Finished 告訴服務端本身發送完成了。