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

來自公眾號：Java建設者
作者cxuan

HTTP 和 HTTPS 的區(qū)別

HTTP 是一種 超文本傳輸協(xié)議(Hypertext Transfer Protocol)昏滴，HTTP 是一個在計算機世界里專門在兩點之間傳輸文字、圖片累颂、音頻滞详、視頻等超文本數(shù)據(jù)的約定和規(guī)范

image

HTTP 主要內容分為三部分，超文本（Hypertext）紊馏、傳輸（Transfer）料饥、協(xié)議（Protocol）。

  • 超文本就是不單單只是本文朱监，它還可以傳輸圖片稀火、音頻、視頻赌朋，甚至點擊文字或圖片能夠進行超鏈接的跳轉。

  • 上面這些概念可以統(tǒng)稱為數(shù)據(jù)篇裁，傳輸就是數(shù)據(jù)需要經(jīng)過一系列的物理介質從一個端系統(tǒng)傳送到另外一個端系統(tǒng)的過程沛慢。通常我們把傳輸數(shù)據(jù)包的一方稱為請求方，把接到二進制數(shù)據(jù)包的一方稱為應答方达布。

  • 而協(xié)議指的就是是網(wǎng)絡中(包括互聯(lián)網(wǎng))傳遞团甲、管理信息的一些規(guī)范。如同人與人之間相互交流是需要遵循一定的規(guī)矩一樣黍聂，計算機之間的相互通信需要共同遵守一定的規(guī)則躺苦，這些規(guī)則就稱為協(xié)議，只不過是網(wǎng)絡協(xié)議产还。

說到 HTTP匹厘，不得不提的就是 TCP/IP 網(wǎng)絡模型，一般是五層模型脐区。如下圖所示

image

但是也可以分為四層愈诚，就是把鏈路層和物理層都表示為網(wǎng)絡接口層

image

還有一種就是 OSI 七層網(wǎng)絡模型，它就是在五層協(xié)議之上加了表示層和會話層

image

而 HTTPS 的全稱是 Hypertext Transfer Protocol Secure，從名稱我們可以看出 HTTPS 要比 HTTPS 多了 secure 安全性這個概念炕柔，實際上酌泰， HTTPS 并不是一個新的應用層協(xié)議，它其實就是 HTTP + TLS/SSL 協(xié)議組合而成匕累，而安全性的保證正是 TLS/SSL 所做的工作陵刹。

也就是說，HTTPS 就是身披了一層 SSL 的 HTTP欢嘿。

image

那么衰琐，HTTP 和 HTTPS 的主要區(qū)別是什么呢？

  • 最簡單的际插，HTTP 在地址欄上的協(xié)議是以 http:// 開頭碘耳，而 HTTPS 在地址欄上的協(xié)議是以 https:// 開頭
http://www.cxuanblog.com/
https://www.cxuanblog.com/
  • HTTP 是未經(jīng)安全加密的協(xié)議，它的傳輸過程容易被攻擊者監(jiān)聽框弛、數(shù)據(jù)容易被竊取辛辨、發(fā)送方和接收方容易被偽造；而 HTTPS 是安全的協(xié)議瑟枫，它通過 密鑰交換算法 - 簽名算法 - 對稱加密算法 - 摘要算法 能夠解決上面這些問題斗搞。
image
  • HTTP 的默認端口是 80，而 HTTPS 的默認端口是 443慷妙。

HTTP Get 和 Post 區(qū)別

HTTP 中包括許多方法僻焚，Get 和 Post 是 HTTP 中最常用的兩個方法，基本上使用 HTTP 方法中有 99% 都是在使用 Get 方法和 Post 方法膝擂，所以有必要我們對這兩個方法有更加深刻的認識虑啤。

  • get 方法一般用于請求，比如你在瀏覽器地址欄輸入 www.cxuanblog.com 其實就是發(fā)送了一個 get 請求架馋，它的主要特征是請求服務器返回資源狞山，而 post 方法一般用于

    表單的提交，相當于是把信息提交給服務器叉寂，等待服務器作出響應萍启，get 相當于一個是 pull/拉的操作，而 post 相當于是一個 push/推的操作屏鳍。

  • get 方法是不安全的勘纯，因為你在發(fā)送請求的過程中，你的請求參數(shù)會拼在 URL 后面钓瞭，從而導致容易被攻擊者竊取驳遵，對你的信息造成破壞和偽造；

/test/demo_form.asp?name1=value1&name2=value2

而 post 方法是把參數(shù)放在請求體 body 中的山涡，這對用戶來說不可見超埋。

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

  • get 請求的 URL 有長度限制搏讶，而 post 請求會把參數(shù)和值放在消息體中，對數(shù)據(jù)長度沒有要求霍殴。

  • get 請求會被瀏覽器主動 cache媒惕，而 post 不會，除非手動設置来庭。

  • get 請求在瀏覽器反復的 回退/前進 操作是無害的妒蔚，而 post 操作會再次提交表單請求。

  • get 請求在發(fā)送過程中會產(chǎn)生一個 TCP 數(shù)據(jù)包月弛；post 在發(fā)送過程中會產(chǎn)生兩個 TCP 數(shù)據(jù)包肴盏。對于 get 方式的請求，瀏覽器會把 http header 和 data 一并發(fā)送出去帽衙，服務器響應 200（返回數(shù)據(jù)）菜皂；而對于 post，瀏覽器先發(fā)送 header厉萝，服務器響應 100 continue恍飘，瀏覽器再發(fā)送 data，服務器響應 200 ok（返回數(shù)據(jù)）谴垫。

什么是無狀態(tài)協(xié)議章母，HTTP 是無狀態(tài)協(xié)議嗎，怎么解決

無狀態(tài)協(xié)議(Stateless Protocol) 就是指瀏覽器對于事務的處理沒有記憶能力翩剪。舉個例子來說就是比如客戶請求獲得網(wǎng)頁之后關閉瀏覽器乳怎，然后再次啟動瀏覽器，登錄該網(wǎng)站前弯，但是服務器并不知道客戶關閉了一次瀏覽器蚪缀。

HTTP 就是一種無狀態(tài)的協(xié)議，他對用戶的操作沒有記憶能力恕出⊙叮可能大多數(shù)用戶不相信，他可能覺得每次輸入用戶名和密碼登陸一個網(wǎng)站后剃根，下次登陸就不再重新輸入用戶名和密碼了。這其實不是 HTTP 做的事情前方，起作用的是一個叫做 小甜餅(Cookie) 的機制狈醉。它能夠讓瀏覽器具有記憶能力。

如果你的瀏覽器允許 cookie 的話惠险，查看方式 chrome://settings/content/cookies

image

也就說明你的記憶芯片通電了…… 當你向服務端發(fā)送請求時苗傅，服務端會給你發(fā)送一個認證信息，服務器第一次接收到請求時班巩，開辟了一塊 Session 空間（創(chuàng)建了Session對象）渣慕，同時生成一個 sessionId 嘶炭，并通過響應頭的 Set-Cookie：JSESSIONID=XXXXXXX 命令，向客戶端發(fā)送要求設置 Cookie 的響應逊桦；客戶端收到響應后眨猎，在本機客戶端設置了一個 JSESSIONID=XXXXXXX 的 Cookie 信息，該 Cookie 的過期時間為瀏覽器會話結束强经；

image

接下來客戶端每次向同一個網(wǎng)站發(fā)送請求時睡陪，請求頭都會帶上該 Cookie信息（包含 sessionId ）， 然后匿情，服務器通過讀取請求頭中的 Cookie 信息兰迫，獲取名稱為 JSESSIONID 的值，得到此次請求的 sessionId炬称。這樣汁果，你的瀏覽器才具有了記憶能力。

image

還有一種方式是使用 JWT 機制玲躯，它也是能夠讓你的瀏覽器具有記憶能力的一種機制据德。與 Cookie 不同，JWT 是保存在客戶端的信息府蔗，它廣泛的應用于單點登錄的情況晋控。JWT 具有兩個特點

  • JWT 的 Cookie 信息存儲在客戶端，而不是服務端內存中姓赤。也就是說赡译，JWT 直接本地進行驗證就可以，驗證完畢后不铆，這個 Token 就會在 Session 中隨請求一起發(fā)送到服務器蝌焚，通過這種方式，可以節(jié)省服務器資源誓斥，并且 token 可以進行多次驗證只洒。

  • JWT 支持跨域認證，Cookies 只能用在單個節(jié)點的域或者它的子域中有效劳坑。如果它們嘗試通過第三個節(jié)點訪問毕谴，就會被禁止。使用 JWT 可以解決這個問題距芬，使用 JWT 能夠通過多個節(jié)點進行用戶認證涝开，也就是我們常說的跨域認證。

UDP 和 TCP 的區(qū)別

TCP 和 UDP 都位于計算機網(wǎng)絡模型中的運輸層框仔，它們負責傳輸應用層產(chǎn)生的數(shù)據(jù)舀武。下面我們就來聊一聊 TCP 和 UDP 分別的特征和他們的區(qū)別

UDP 是什么

UDP 的全稱是 User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議离斩。它不需要所謂的握手操作银舱，從而加快了通信速度瘪匿，允許網(wǎng)絡上的其他主機在接收方同意通信之前進行數(shù)據(jù)傳輸。

數(shù)據(jù)報是與分組交換網(wǎng)絡關聯(lián)的傳輸單元寻馏。

UDP 的特點主要有

  • UDP 能夠支持容忍數(shù)據(jù)包丟失的帶寬密集型應用程序

  • UDP 具有低延遲的特點

  • UDP 能夠發(fā)送大量的數(shù)據(jù)包

  • UDP 能夠允許 DNS 查找棋弥，DNS 是建立在 UDP 之上的應用層協(xié)議。

TCP 是什么

TCP 的全稱是Transmission Control Protocol 操软，傳輸控制協(xié)議嘁锯。它能夠幫助你確定計算機連接到 Internet 以及它們之間的數(shù)據(jù)傳輸。通過三次握手來建立 TCP 連接聂薪，三次握手就是用來啟動和確認 TCP 連接的過程家乘。一旦連接建立后，就可以發(fā)送數(shù)據(jù)了藏澳，當數(shù)據(jù)傳輸完成后仁锯，會通過關閉虛擬電路來斷開連接。

TCP 的主要特點有

  • TCP 能夠確保連接的建立和數(shù)據(jù)包的發(fā)送

  • TCP 支持錯誤重傳機制

  • TCP 支持擁塞控制翔悠，能夠在網(wǎng)絡擁堵的情況下延遲發(fā)送

  • TCP 能夠提供錯誤校驗和业崖，甄別有害的數(shù)據(jù)包。

TCP 和 UDP 的不同

image

下面為你羅列了一些 TCP 和 UDP 的不同點蓄愁，方便理解双炕，方便記憶。

image

TCP 三次握手和四次揮手

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

TCP 三次握手

在了解具體的流程前，我們需要先認識幾個概念

image

  • SYN：它的全稱是 Synchronize Sequence Numbers丹拯，同步序列編號站超。是 TCP/IP 建立連接時使用的握手信號。在客戶機和服務器之間建立 TCP 連接時乖酬，首先會發(fā)送的一個信號死相。客戶端在接受到 SYN 消息時咬像，就會在自己的段內生成一個隨機值 X算撮。

  • SYN-ACK：服務器收到 SYN 后，打開客戶端連接县昂，發(fā)送一個 SYN-ACK 作為答復肮柜。確認號設置為比接收到的序列號多一個，即 X + 1七芭，服務器為數(shù)據(jù)包選擇的序列號是另一個隨機數(shù) Y素挽。

  • ACK：Acknowledge character, 確認字符蔑赘，表示發(fā)來的數(shù)據(jù)已確認接收無誤狸驳。最后预明，客戶端將 ACK 發(fā)送給服務器。序列號被設置為所接收的確認值即 Y + 1耙箍。

image

如果用現(xiàn)實生活來舉例的話就是

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

  • 小明給小紅打電話撰糠，接通了后，小明說喂辩昆，能聽到嗎阅酪，這就相當于是連接建立。

  • 小紅給小明回應汁针，能聽到术辐，你能聽到我說的話嗎，這就相當于是請求響應施无。

  • 小明聽到小紅的回應后辉词，好的，這相當于是連接確認猾骡。在這之后小明和小紅就可以通話/交換信息了瑞躺。

TCP 四次揮手

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

image

  • 首先，客戶端應用程序決定要終止連接(這里服務端也可以選擇斷開連接)嫂便。這會使客戶端將 FIN 發(fā)送到服務器捞镰，并進入 FIN_WAIT_1 狀態(tài)。當客戶端處于 FIN_WAIT_1 狀態(tài)時顽悼，它會等待來自服務器的 ACK 響應曼振。

  • 然后第二步，當服務器收到 FIN 消息時蔚龙，服務器會立刻向客戶端發(fā)送 ACK 確認消息冰评。

  • 當客戶端收到服務器發(fā)送的 ACK 響應后，客戶端就進入 FIN_WAIT_2 狀態(tài)木羹，然后等待來自服務器的 FIN 消息

  • 服務器發(fā)送 ACK 確認消息后甲雅，一段時間（可以進行關閉后）會發(fā)送 FIN 消息給客戶端，告知客戶端可以進行關閉坑填。

  • 當客戶端收到從服務端發(fā)送的 FIN 消息時抛人，客戶端就會由 FIN_WAIT_2 狀態(tài)變?yōu)?TIME_WAIT 狀態(tài)。處于 TIME_WAIT 狀態(tài)的客戶端允許重新發(fā)送 ACK 到服務器為了防止信息丟失脐瑰⊙叮客戶端在 TIME_WAIT 狀態(tài)下花費的時間取決于它的實現(xiàn)，在等待一段時間后苍在，連接關閉绝页，客戶端上所有的資源（包括端口號和緩沖區(qū)數(shù)據(jù)）都被釋放荠商。

還是可以用上面那個通話的例子來進行描述

  • 小明對小紅說，我所有的東西都說完了续誉，我要掛電話了莱没。

  • 小紅說，收到酷鸦，我這邊還有一些東西沒說饰躲。

  • 經(jīng)過若干秒后，小紅也說完了臼隔，小紅說嘹裂，我說完了，現(xiàn)在可以掛斷了

  • 小明收到消息后摔握，又等了若干時間后焦蘑，掛斷了電話。

簡述 HTTP1.0/1.1/2.0 的區(qū)別

HTTP 1.0

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

  • HTTP 1.0 僅僅提供了最基本的認證宁舰，這時候用戶名和密碼還未經(jīng)加密拼卵，因此很容易收到窺探。

  • HTTP 1.0 被設計用來使用短鏈接蛮艰，即每次發(fā)送數(shù)據(jù)都會經(jīng)過 TCP 的三次握手和四次揮手腋腮，效率比較低。

  • HTTP 1.0 只使用 header 中的 If-Modified-Since 和 Expires 作為緩存失效的標準壤蚜。

  • HTTP 1.0 不支持斷點續(xù)傳即寡，也就是說，每次都會傳送全部的頁面和數(shù)據(jù)袜刷。

  • HTTP 1.0 認為每臺計算機只能綁定一個 IP聪富，所以請求消息中的 URL 并沒有傳遞主機名（hostname）。

HTTP 1.1

HTTP 1.1 是 HTTP 1.0 開發(fā)三年后出現(xiàn)的著蟹，也就是 1999 年墩蔓，它做出了以下方面的變化

  • HTTP 1.1 使用了摘要算法來進行身份驗證

  • HTTP 1.1 默認使用長連接，長連接就是只需一次建立就可以傳輸多次數(shù)據(jù)萧豆，傳輸完成后奸披，只需要一次切斷連接即可。長連接的連接時長可以通過請求頭中的 keep-alive 來設置

  • HTTP 1.1 中新增加了 E-tag涮雷，If-Unmodified-Since, If-Match, If-None-Match 等緩存控制標頭來控制緩存失效阵面。

  • HTTP 1.1 支持斷點續(xù)傳，通過使用請求頭中的 Range 來實現(xiàn)。

  • HTTP 1.1 使用了虛擬網(wǎng)絡样刷，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers）嗽交，并且它們共享一個IP地址。

HTTP 2.0

HTTP 2.0 是 2015 年開發(fā)出來的標準颂斜，它主要做的改變如下

  • 頭部壓縮，由于 HTTP 1.1 經(jīng)常會出現(xiàn) User-Agent拾枣、Cookie沃疮、Accept、Server梅肤、Range 等字段可能會占用幾百甚至幾千字節(jié)司蔬，而 Body 卻經(jīng)常只有幾十字節(jié)，所以導致頭部偏重姨蝴。HTTP 2.0 使用 HPACK 算法進行壓縮俊啼。

  • 二進制格式，HTTP 2.0 使用了更加靠近 TCP/IP 的二進制格式左医，而拋棄了 ASCII 碼授帕，提升了解析效率

  • 強化安全，由于安全已經(jīng)成為重中之重浮梢，所以 HTTP2.0 一般都跑在 HTTPS 上跛十。

  • 多路復用，即每一個請求都是是用作連接共享秕硝。一個請求對應一個id芥映，這樣一個連接上可以有多個請求。

image

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

這個問題比較開放远豺，因為 HTTP 請求頭有很多奈偏，這里只簡單舉出幾個例子。

HTTP 標頭會分為四種躯护，分別是 通用標頭惊来、實體標頭、請求標頭棺滞、響應標頭唁盏。分別介紹一下

通用標頭

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

Date

Date 是一個通用標頭厘擂，它可以出現(xiàn)在請求標頭和響應標頭中，它的基本表示如下

Date: Wed, 21 Oct 2015 07:28:00 GMT

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

image

Cache-Control

Cache-Control 是一個通用標頭刽严，他可以出現(xiàn)在請求標頭和響應標頭中，Cache-Control 的種類比較多，雖然說這是一個通用標頭舞萄，但是有一些特性是請求標頭具有的眨补，有一些是響應標頭才有的。主要大類有 可緩存性倒脓、閾值性撑螺、 重新驗證并重新加載 和其他特性

Connection

Connection 決定當前事務（一次三次握手和四次揮手）完成后，是否會關閉網(wǎng)絡連接崎弃。Connection 有兩種甘晤，一種是持久性連接，即一次事務完成后不關閉網(wǎng)絡連接

Connection: keep-alive

另一種是非持久性連接饲做，即一次事務完成后關閉網(wǎng)絡連接

Connection: close

HTTP1.1 其他通用標頭如下

image

實體標頭

實體標頭是描述消息正文內容的 HTTP 標頭线婚。實體標頭用于 HTTP 請求和響應中。頭部Content-Length盆均、 Content-Language塞弊、 Content-Encoding 是實體頭。

  • Content-Length 實體報頭指示實體主體的大小泪姨，以字節(jié)為單位游沿，發(fā)送到接收方。

  • Content-Language 實體報頭描述了客戶端或者服務端能夠接受的語言肮砾。

  • Content-Encoding 這又是一個比較麻煩的屬性奏候，這個實體報頭用來壓縮媒體類型。Content-Encoding 指示對實體應用了何種編碼唇敞。

    常見的內容編碼有這幾種： gzip蔗草、compress、deflate疆柔、identity 咒精，這個屬性可以應用在請求報文和響應報文中

Accept-Encoding: gzip, deflate //請求頭
Content-Encoding: gzip  //響應頭

下面是一些實體標頭字段

image

請求標頭

Host

Host 請求頭指明了服務器的域名（對于虛擬主機來說）厢破，以及（可選的）服務器監(jiān)聽的 TCP 端口號鸽心。如果沒有給定端口號序愚，會自動使用被請求服務的默認端口（比如請求一個 HTTP 的 URL 會自動使用 80 作為端口）吨岭。

Host: developer.mozilla.org

上面的 Accpet、 Accept-Language旺韭、Accept-Encoding 都是屬于內容協(xié)商的請求標頭逾条。

Referer

HTTP Referer 屬性是請求標頭的一部分燥撞，當瀏覽器向 web 服務器發(fā)送請求的時候厂庇，一般會帶上 Referer渠啊，告訴服務器該網(wǎng)頁是從哪個頁面鏈接過來的，服務器因此可以獲得一些信息用于處理权旷。

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 狀態(tài)發(fā)送回請求的資源。對于其他方法蚓聘，僅當最終現(xiàn)有資源的ETag與列出的任何值都不匹配時，才會處理請求盟劫。

If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"

Accept

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

Accept-Charset

accept-charset 屬性規(guī)定服務器處理表單數(shù)據(jù)所接受的字符集夜牡。

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

Accept-Language

首部字段 Accept-Language 用來告知服務器用戶代理能夠處理的自然語言集（指中文或英文等）侣签，以及自然語言集的相對優(yōu)先級塘装。可一次指定多種自然語言集影所。

請求標頭我們大概就介紹這幾種蹦肴，后面會有一篇文章詳細深挖所有的響應頭的，下面是一個響應頭的匯總猴娩，基于 HTTP 1.1

image

響應標頭

Access-Control-Allow-Origin

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

Keep-Alive

Keep-Alive 表示的是 Connection 非持續(xù)連接的存活時間矛双，可以進行指定。

Server

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

應該避免使用過于冗長和詳細的 Server 值议忽，因為它們可能會泄露內部實施細節(jié)，這可能會使攻擊者容易地發(fā)現(xiàn)并利用已知的安全漏洞十减。例如下面這種寫法

Server: Apache/2.4.1 (Unix)

Set-Cookie

Set-Cookie 用于服務器向客戶端發(fā)送 sessionID栈幸。

Transfer-Encoding

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

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

X-Frame-Options

HTTP 首部字段是可以自行擴展的速址。所以在 Web 服務器和瀏覽器的應用上，會出現(xiàn)各種非標準的首部字段由驹。

首部字段 X-Frame-Options 屬于 HTTP 響應首部壳繁，用于控制網(wǎng)站內容在其他 Web 網(wǎng)站的 Frame 標簽內的顯示問題。其主要目的是為了防止點擊劫持（clickjacking）攻擊。

下面是一個響應頭的匯總闹炉，基于 HTTP 1.1

image

地址欄輸入 URL 發(fā)生了什么

這道題也是一道經(jīng)常會考的面試題蒿赢。那么下面我們就來探討一下從你輸入 URL 后到響應，都經(jīng)歷了哪些過程渣触。

  • 首先羡棵，你需要在瀏覽器中的 URL 地址上，輸入你想訪問的地址嗅钻，如下
image

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

  • 然后，瀏覽器會根據(jù)你輸入的 URL 地址养篓，去查找域名是否被本地 DNS 緩存秃流，不同瀏覽器對 DNS 的設置不同，如果瀏覽器緩存了你想訪問的 URL 地址柳弄，那就直接返回 ip。如果沒有緩存你的 URL 地址碧注，瀏覽器就會發(fā)起系統(tǒng)調用來查詢本機 hosts 文件是否有配置 ip 地址嚣伐，如果找到，直接返回逝变。如果找不到基茵，就向網(wǎng)絡中發(fā)起一個 DNS 查詢。

首先來看一下 DNS 是啥壳影，互聯(lián)網(wǎng)中識別主機的方式有兩種耿导，通過主機名和 IP 地址。我們人喜歡用名字的方式進行記憶态贤，但是通信鏈路中的路由卻喜歡定長舱呻、有層次結構的 IP 地址。所以就需要一種能夠把主機名到 IP 地址的轉換服務悠汽，這種服務就是由 DNS 提供的箱吕。DNS 的全稱是 Domain Name System 域名系統(tǒng)。DNS 是一種由分層的 DNS 服務器實現(xiàn)的分布式數(shù)據(jù)庫柿冲。DNS 運行在 UDP 上茬高，使用 53 端口。

image

DNS 是一種分層數(shù)據(jù)庫假抄，它的主要層次結構如下

image

一般域名服務器的層次結構主要是以上三種怎栽，除此之外丽猬，還有另一類重要的 DNS 服務器，它是 本地 DNS 服務器(local DNS server)熏瞄。嚴格來說脚祟，本地 DNS 服務器并不屬于上述層次結構，但是本地 DNS 服務器又是至關重要的强饮。每個 ISP(Internet Service Provider) 比如居民區(qū)的 ISP 或者一個機構的 ISP 都有一臺本地 DNS 服務器由桌。當主機和 ISP 進行連接時，該 ISP 會提供一臺主機的 IP 地址邮丰，該主機會具有一臺或多臺其本地 DNS 服務器的 IP地址行您。通過訪問網(wǎng)絡連接，用戶能夠容易的確定 DNS 服務器的 IP地址剪廉。當主機發(fā)出 DNS 請求后娃循，該請求被發(fā)往本地 DNS 服務器，它起著代理的作用斗蒋，并將該請求轉發(fā)到 DNS 服務器層次系統(tǒng)中捌斧。

首先，查詢請求會先找到本地 DNS 服務器來查詢是否包含 IP 地址吹泡，如果本地 DNS 無法查詢到目標 IP 地址骤星，就會向根域名服務器發(fā)起一個 DNS 查詢经瓷。

注意：DNS 涉及兩種查詢方式：一種是遞歸查詢(Recursive query) 爆哑，一種是迭代查詢(Iteration query)∮咚保《計算機網(wǎng)絡：自頂向下方法》竟然沒有給出遞歸查詢和迭代查詢的區(qū)別揭朝，找了一下網(wǎng)上的資料大概明白了下。

如果根域名服務器無法告知本地 DNS 服務器下一步需要訪問哪個頂級域名服務器色冀，就會使用遞歸查詢潭袱；

如果根域名服務器能夠告知 DNS 服務器下一步需要訪問的頂級域名服務器，就會使用迭代查詢锋恬。

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

  • 第三步彤悔，瀏覽器需要和目標服務器建立 TCP 連接，需要經(jīng)過三次握手的過程索守，具體的握手過程請參考上面的回答晕窑。

  • 在建立連接后，瀏覽器會向目標服務器發(fā)起 HTTP-GET 請求卵佛，包括其中的 URL杨赤，HTTP 1.1 后默認使用長連接敞斋，只需要一次握手即可多次傳輸數(shù)據(jù)。

  • 如果目標服務器只是一個簡單的頁面疾牲，就會直接返回植捎。但是對于某些大型網(wǎng)站的站點，往往不會直接返回主機名所在的頁面说敏，而會直接重定向鸥跟。返回的狀態(tài)碼就不是 200 ，而是 301,302 以 3 開頭的重定向碼盔沫，瀏覽器在獲取了重定向響應后医咨，在響應報文中 Location 項找到重定向地址，瀏覽器重新第一步訪問即可架诞。

  • 然后瀏覽器重新發(fā)送請求拟淮，攜帶新的 URL，返回狀態(tài)碼 200 OK谴忧，表示服務器可以響應請求很泊，返回報文。

HTTPS 的工作原理

我們上面描述了一下 HTTP 的工作原理沾谓，下面來講述一下 HTTPS 的工作原理委造。因為我們知道 HTTPS 不是一種新出現(xiàn)的協(xié)議，而是

image

所以均驶，我們探討 HTTPS 的握手過程昏兆，其實就是 SSL/TLS 的握手過程。

TLS 旨在為 Internet 提供通信安全的加密協(xié)議妇穴。TLS 握手是啟動和使用 TLS 加密的通信會話的過程爬虱。在 TLS 握手期間，Internet 中的通信雙方會彼此交換信息腾它，驗證密碼套件跑筝，交換會話密鑰。

每當用戶通過 HTTPS 導航到具體的網(wǎng)站并發(fā)送請求時瞒滴，就會進行 TLS 握手曲梗。除此之外，每當其他任何通信使用HTTPS（包括 API 調用和在 HTTPS 上查詢 DNS）時妓忍，也會發(fā)生 TLS 握手虏两。

TLS 具體的握手過程會根據(jù)所使用的密鑰交換算法的類型和雙方支持的密碼套件而不同。我們以RSA 非對稱加密來討論這個過程单默。整個 TLS 通信流程圖如下

image

  • 在進行通信前碘举，首先會進行 HTTP 的三次握手，握手完成后搁廓，再進行 TLS 的握手過程

  • ClientHello：客戶端通過向服務器發(fā)送 hello 消息來發(fā)起握手過程引颈。這個消息中會夾帶著客戶端支持的 TLS 版本號(TLS1.0 耕皮、TLS1.2、TLS1.3) 蝙场、客戶端支持的密碼套件凌停、以及一串 客戶端隨機數(shù)。

  • ServerHello：在客戶端發(fā)送 hello 消息后售滤，服務器會發(fā)送一條消息罚拟，這條消息包含了服務器的 SSL 證書、服務器選擇的密碼套件和服務器生成的隨機數(shù)完箩。

  • 認證(Authentication)：客戶端的證書頒發(fā)機構會認證 SSL 證書赐俗，然后發(fā)送 Certificate 報文，報文中包含公開密鑰證書弊知。最后服務器發(fā)送 ServerHelloDone 作為 hello 請求的響應阻逮。第一部分握手階段結束。

  • 加密階段：在第一個階段握手完成后秩彤，客戶端會發(fā)送 ClientKeyExchange 作為響應叔扼，這個響應中包含了一種稱為 The premaster secret 的密鑰字符串，這個字符串就是使用上面公開密鑰證書進行加密的字符串漫雷。隨后客戶端會發(fā)送 ChangeCipherSpec瓜富，告訴服務端使用私鑰解密這個 premaster secret 的字符串，然后客戶端發(fā)送 Finished 告訴服務端自己發(fā)送完成了降盹。

Session key 其實就是用公鑰證書加密的公鑰与柑。

  • 實現(xiàn)了安全的非對稱加密：然后，服務器再發(fā)送 ChangeCipherSpec 和 Finished 告訴客戶端解密完成澎现，至此實現(xiàn)了 RSA 的非對稱加密仅胞。

文章參考：

What is a TLS handshake?

Recursive and Iterative DNS Queries

DNS遞歸查詢與迭代查詢

TCP三次握手和四次揮手過程

HTTP/1.0 AND 1.1, WHAT ARE THE DIFFERENCES?

TCP Connection Termination

Transmission_Control_Protocol

SYN

TCP 3-Way Handshake (SYN, SYN-ACK,ACK)

HTTP/2 相比 1.0 有哪些重大改進每辟？

TCP vs UDP: What's the Difference?

計算機網(wǎng)絡7層模型

HTTP常見面試題

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末剑辫，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子渠欺，更是在濱河造成了極大的恐慌妹蔽，老刑警劉巖，帶你破解...
    沈念sama閱讀 211,817評論 6贊 492
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件挠将，死亡現(xiàn)場離奇詭異胳岂，居然都是意外死亡，警方通過查閱死者的電腦和手機舔稀，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,329評論 3贊 385
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門乳丰，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人内贮，你說我怎么就攤上這事产园」” “怎么了？”我有些...
    開封第一講書人閱讀 157,354評論 0贊 348
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵什燕，是天一觀的道長粘勒。 經(jīng)常有香客問我，道長屎即，這世上最難降的妖魔是什么庙睡？ 我笑而不...
    開封第一講書人閱讀 56,498評論 1贊 284
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮技俐，結果婚禮上乘陪，老公的妹妹穿的比我還像新娘。我一直安慰自己雕擂，他們只是感情好暂刘，可當我...
    茶點故事閱讀 65,600評論 6贊 386
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著捂刺，像睡著了一般谣拣。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上族展，一...
    開封第一講書人閱讀 49,829評論 1贊 290
  • 城市分裂傳說
    那天森缠，我揣著相機與錄音，去河邊找鬼仪缸。 笑死贵涵，一個胖子當著我的面吹牛，可吹牛的內容都是我干的恰画。 我是一名探鬼主播宾茂，決...
    沈念sama閱讀 38,979評論 3贊 408
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼拴还！你這毒婦竟也來了跨晴？” 一聲冷哼從身側響起，我...
    開封第一講書人閱讀 37,722評論 0贊 266
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤片林，失蹤者是張志新（化名）和其女友劉穎端盆，沒想到半個月后，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體费封，經(jīng)...
    沈念sama閱讀 44,189評論 1贊 303
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡焕妙，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 36,519評論 2贊 327
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了弓摘。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片焚鹊。...
    茶點故事閱讀 38,654評論 1贊 340
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖韧献，靈堂內的尸體忽然破棺而出末患，到底是詐尸還是另有隱情爷抓，我是刑警寧澤，帶...
    沈念sama閱讀 34,329評論 4贊 330
  • ?日本核電站爆炸內幕
    正文 年R本政府宣布阻塑，位于F島的核電站蓝撇，受9級特大地震影響，放射性物質發(fā)生泄漏陈莽。R本人自食惡果不足惜渤昌，卻給世界環(huán)境...
    茶點故事閱讀 39,940評論 3贊 313
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望走搁。 院中可真熱鬧独柑，春花似錦、人聲如沸私植。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,762評論 0贊 21
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽曲稼。三九已至索绪，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間贫悄，已是汗流浹背瑞驱。 一陣腳步聲響...
    開封第一講書人閱讀 31,993評論 1贊 266
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留窄坦，地道東北人唤反。 一個月前我還...
    沈念sama閱讀 46,382評論 2贊 360
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像鸭津，于是被迫代替她去往敵國和親彤侍。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
    茶點故事閱讀 43,543評論 2贊 349