轉(zhuǎn)載聲明：
作者：jsonchao
鏈接：https://juejin.im/post/5e5b50eb6fb9a07cae136773
來源：掘金
著作權(quán)歸作者所有剔桨。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。

一郭变、HTTP/HTTPS （???）

1、HTTP與HTTPS有什么區(qū)別铜邮？

HTPPS和HTTP的概念：
HTTPS是一種通過計算機(jī)網(wǎng)絡(luò)進(jìn)行安全通信的傳輸協(xié)議萨蚕。HTTPS經(jīng)由HTTP進(jìn)行通信，但利用SSL/TLS來加密數(shù)據(jù)包担猛。HTTPS開發(fā)的主要目的，是提供對網(wǎng)站服務(wù)器的身份 認(rèn)證，保護(hù)交換數(shù)據(jù)的隱私與完整性聊记。

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer）浩蓉，是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版蒸走。即HTTP下加入SSL層仇奶，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL比驻。 它是一個URI scheme（抽象標(biāo)識符體系）该溯，句法類同http:體系。用于安全的HTTP數(shù)據(jù)傳輸别惦。https:URL表明它使用了HTTP狈茉，但HTTPS存在不同于HTTP的默認(rèn)端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統(tǒng)的最初研發(fā)由網(wǎng)景公司進(jìn)行掸掸，提供了身份驗證與加密通訊方法氯庆，現(xiàn)在它被廣泛用于萬維網(wǎng)上安全敏感的通訊，例如交易支付方面扰付。

超文本傳輸協(xié)議 (HTTP-Hypertext transfer protocol) 是一種詳細(xì)規(guī)定了瀏覽器和萬維網(wǎng)服務(wù)器之間互相通信的規(guī)則堤撵，通過因特網(wǎng)傳送萬維網(wǎng)文檔的數(shù)據(jù)傳送協(xié)議。

常見不同點：

• https協(xié)議需要到ca申請證書悯周，一般免費證書很少粒督，需要交費。
• http是超文本傳輸協(xié)議禽翼，信息是明文傳輸屠橄，https 則是具有安全性的ssl加密傳輸協(xié)議
• http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。
• http的連接很簡單,是無狀態(tài)的HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸闰挡、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議 要比http協(xié)議安全

HTTPS解決的問題：

    1 . 信任主機(jī)的問題. 采用https 的server 必須從CA 申請一個用于證明
        服務(wù)器用途類型的證書. 改證書只有用于對應(yīng)的server 的時候,客戶度才信任次主機(jī)
    2 . 防止通訊過程中的數(shù)據(jù)的泄密和被竄改

如下圖所示锐墙，可以很明顯的看出兩個的區(qū)別：

image.png

注：TLS是SSL的升級替代版，具體發(fā)展歷史可以參考傳輸層安全性協(xié)議长酗。

HTTP與HTTPS在寫法上的區(qū)別也是前綴的不同溪北，客戶端處理的方式也不同，具體說來：

如果URL的協(xié)議是HTTP，則客戶端會打開一條到服務(wù)端端口80（默認(rèn)）的連接之拨，并向其發(fā)送老的HTTP請求茉继。 
如果URL的協(xié)議是HTTPS，則客戶端會打開一條到服務(wù)端端口443（默認(rèn)）的連接蚀乔，然后與服務(wù)器握手烁竭，
  以二進(jìn)制格式與服務(wù)器交換一些SSL的安全參數(shù)，附上加密的 HTTP請求吉挣。 所以你可以看到派撕，HTTPS比
  HTTP多了一層與SSL的連接，這也就是客戶端與服務(wù)端SSL握手的過程睬魂，整個過程主要完成以下工作：

      交換協(xié)議版本號 
      選擇一個兩端都了解的密碼,對兩端的身份進(jìn)行認(rèn)證 生成臨時的會話密鑰终吼，以便加密信道。 
      SSL握手是一個相對比較復(fù)雜的過程氯哮，更多關(guān)于SSL握手的過程細(xì)節(jié)可以參考TLS/SSL握手過程

SSL/TSL的常見開源實現(xiàn)是OpenSSL际跪，OpenSSL是一個開放源代碼的軟件庫包，應(yīng)用程序可以使用這個包來進(jìn)行安全通信蛙粘，避免竊聽垫卤，同時確認(rèn)另一端連接者的身份。這個包廣泛被應(yīng)用在互聯(lián)網(wǎng)的網(wǎng)頁服務(wù)器上出牧。 更多源于OpenSSL的技術(shù)細(xì)節(jié)可以參考OpenSSL穴肘。

2、Http1.1和Http1.0及2.0的區(qū)別舔痕？

HTTP1.0和HTTP1.1的一些區(qū)別

HTTP1.0最早在網(wǎng)頁中使用是在1996年评抚，那個時候只是使用一些較為簡單的網(wǎng)頁上和網(wǎng)絡(luò)請求上，而HTTP1.1則在1999年才開始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)絡(luò)請求中伯复，同時HTTP1.1也是當(dāng)前使用最為廣泛的HTTP協(xié)議慨代。 主要區(qū)別主要體現(xiàn)在：

• 1、緩存處理啸如，在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標(biāo)準(zhǔn)侍匙，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略叮雳。

• 2想暗、帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用，HTTP1.0中帘不，存在一些浪費帶寬的現(xiàn)象说莫，例如客戶端只是需要某個對象的一部分，而服務(wù)器卻將整個對象送過來了寞焙，并且不支持?jǐn)帱c續(xù)傳功能储狭，HTTP1.1則在請求頭引入了range頭域互婿，它允許只請求資源的某個部分，即返回碼是206（Partial Content）辽狈，這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接慈参。

• 3、錯誤通知的管理稻艰，在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼懂牧，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個資源被永久性的刪除尊勿。

• 4、Host頭處理畜侦，在HTTP1.0中認(rèn)為每臺服務(wù)器都綁定一個唯一的IP地址元扔，因此，請求消息中的URL并沒有傳遞主機(jī)名（hostname）旋膳。但隨著虛擬主機(jī)技術(shù)的發(fā)展澎语，在一臺物理服務(wù)器上可以存在多個虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個IP地址验懊。HTTP1.1的請求消息和響應(yīng)消息都應(yīng)支持Host頭域擅羞，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）

• 5、長連接义图，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理减俏，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲碱工，在HTTP1.1中默認(rèn)開啟Connection： keep-alive娃承，一定程度上彌補了HTTP1.0每次請求都要創(chuàng)建連接的缺點。

SPDY

在講Http1.1和Http2.0的區(qū)別之前怕篷，還需要說下SPDY历筝，它是HTTP1.x的優(yōu)化方案：

2012年google如一聲驚雷提出了SPDY的方案，優(yōu)化了HTTP1.X的請求延遲廊谓，解決了HTTP1.X的安全性梳猪，具體如下：

• 1、降低延遲蒸痹，針對HTTP高延遲的問題春弥，SPDY優(yōu)雅的采取了多路復(fù)用（multiplexing）。多路復(fù)用通過多個請求stream共享一個tcp連接的方式电抚，解決了HOL blocking的問題惕稻，降低了延遲同時提高了帶寬的利用率。

• 2蝙叛、請求優(yōu)先級（request prioritization）俺祠。多路復(fù)用帶來一個新的問題是，在連接共享的基礎(chǔ)之上有可能會導(dǎo)致關(guān)鍵請求被阻塞。SPDY允許給每個request設(shè)置優(yōu)先級蜘渣，這樣重要的請求就會優(yōu)先得到響應(yīng)淌铐。比如瀏覽器加載首頁，首頁的html內(nèi)容應(yīng)該優(yōu)先展示蔫缸，之后才是各種靜態(tài)資源文件腿准，腳本文件等加載，這樣可以保證用戶能第一時間看到網(wǎng)頁內(nèi)容拾碌。

• 3吐葱、header壓縮。前面提到HTTP1.x的header很多時候都是重復(fù)多余的校翔。選擇合適的壓縮算法可以減小包的大小和數(shù)量弟跑。

• 4、基于HTTPS的加密協(xié)議傳輸防症，大大提高了傳輸數(shù)據(jù)的可靠性孟辑。

• 5、服務(wù)端推送（server push）蔫敲，采用了SPDY的網(wǎng)頁饲嗽，例如我的網(wǎng)頁有一個sytle.css的請求，在客戶端收到sytle.css數(shù)據(jù)的同時奈嘿，服務(wù)端會將sytle.js的文件推送給客戶端貌虾，當(dāng)客戶端再次嘗試獲取sytle.js時就可以直接從緩存中獲取到，不用再發(fā)請求了指么。SPDY構(gòu)成圖：

image.png

SPDY位于HTTP之下酝惧，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協(xié)議(將HTTP1.x的內(nèi)容封裝成一種新的frame格式)伯诬，同時可以使用已有的SSL功能晚唇。

HTTP2.0和HTTP1.X相比的新特性

• 新的二進(jìn)制格式（Binary Format），HTTP1.x的解析是基于文本盗似×ㄉ拢基于文本協(xié)議的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性赫舒，要做到健壯性考慮的場景必然很多悍及，二進(jìn)制則不同，只認(rèn)0和1的組合接癌⌒母希基于這種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制格式，實現(xiàn)方便且健壯缺猛。

• 多路復(fù)用（MultiPlexing）缨叫，即連接共享椭符，即每一個request都是是用作連接共享機(jī)制的。一個request對應(yīng)一個id耻姥，這樣一個連接上可以有多個request销钝，每個連接的request可以隨機(jī)的混雜在一起，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請求里面琐簇。

• header壓縮蒸健，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息婉商，而且每次都要重復(fù)發(fā)送似忧，HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header fields表丈秩，既避免了重復(fù)header的傳輸橡娄，又減小了需要傳輸?shù)拇笮　?/p>

• 服務(wù)端推送（server push），同SPDY一樣癣籽，HTTP2.0也具有server push功能。

需要更深的理解請點擊這里

3滤祖、Https 請求慢的解決辦法

1筷狼、不通過DNS解析，直接訪問IP

2匠童、解決連接無法復(fù)用

http/1.0協(xié)議頭里可以設(shè)置Connection:Keep-Alive或者Connection:Close埂材，選擇是否允許在一定時間內(nèi)復(fù)用連接（時間可由服務(wù)器控制）。但是這對App端的請求成效不大汤求，因為App端的請求比較分散且時間跨度相對較大俏险。

• 方案1.基于tcp的長連接 (主要） 移動端建立一條自己的長鏈接通道，通道的實現(xiàn)是基于tcp協(xié)議扬绪∈溃基于tcp的socket編程技術(shù)難度相對復(fù)雜很多，而且需要自己定制協(xié)議挤牛。但信息的上報和推送變得更及時莹痢，請求量爆發(fā)的時間點還能減輕服務(wù)器壓力（避免頻繁創(chuàng)建和銷毀連接）

• 方案2.http long-polling 客戶端在初始狀態(tài)發(fā)送一個polling請求到服務(wù)器，服務(wù)器并不會馬上返回業(yè)務(wù)數(shù)據(jù)墓赴，而是等待有新的業(yè)務(wù)數(shù)據(jù)產(chǎn)生的時候再返回竞膳，所以鏈接會一直被保持。一但結(jié)束當(dāng)前連接诫硕，馬上又會發(fā)送一個新的polling請求坦辟，如此反復(fù)，保證一個連接被保持章办。 存在問題： 1）增加了服務(wù)器的壓力 2）網(wǎng)絡(luò)環(huán)境復(fù)雜場景下锉走，需要考慮怎么重建健康的連接通道 3）polling的方式穩(wěn)定性不好 4）polling的response可能被中間代理cache住 ……

• 方案3.http streaming 和long-polling不同的是滨彻，streaming方式通過再server response的頭部增加“Transfer Encoding:chuncked”來告訴客戶端后續(xù)還有新的數(shù)據(jù)到來 存在問題： 1）有些代理服務(wù)器會等待服務(wù)器的response結(jié)束之后才將結(jié)果推送給請求客戶端。streaming不會結(jié)束response 2）業(yè)務(wù)數(shù)據(jù)無法按照請求分割 ……

• 方案4.web socket 和傳統(tǒng)的tcp socket相似挠日，基于tcp協(xié)議疮绷，提供雙向的數(shù)據(jù)通道。它的優(yōu)勢是提供了message的概念嚣潜，比基于字節(jié)流的tcp socket使用更簡單冬骚。技術(shù)較新，不是所有瀏覽器都提供了支持懂算。

3只冻、解決head of line blocking

它的原因是隊列的第一個數(shù)據(jù)包（隊頭）受阻而導(dǎo)致整列數(shù)據(jù)包受阻

使用http pipelining，確保幾乎在同一時間把request發(fā)向了服務(wù)器

4计技、Http的request和response的協(xié)議組成

1喜德、Request組成

客戶端發(fā)送一個HTTP請求到服務(wù)器的請求消息包括以下格式：

請求行（request line）、請求頭部（header）垮媒、空行和請求數(shù)據(jù)四個部分組成舍悯。

image.png

請求行以一個方法符號開頭，以空格分開睡雇，后面跟著請求的URI和協(xié)議的版本萌衬。

Get請求例子

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent  Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept  image/webp,image/*,*/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflate, sdch
Accept-Language zh-CN,zh;q=0.8

第一部分：請求行，用來說明請求類型,要訪問的資源以及所使用的HTTP版本. GET說明請求類型為GET,[/562f25980001b1b106000338.jpg]為要訪問的資源它抱，該行的最后一部分說明使用的是HTTP1.1版本秕豫。
第二部分：請求頭部，緊接著請求行（即第一行）之后的部分观蓄，用來說明服務(wù)器要使用的附加信息 從第二行起為請求頭部混移，HOST將指出請求的目的地.User-Agent,服務(wù)器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎(chǔ).該信息由你的瀏覽器來定義,并且在每個請求中自動發(fā)送等等
第三部分：空行，請求頭部后面的空行是必須的 即使第四部分的請求數(shù)據(jù)為空侮穿，也必須有空行歌径。
第四部分：請求數(shù)據(jù)也叫主體，可以添加任意的其他數(shù)據(jù)撮珠。 這個例子的請求數(shù)據(jù)為空沮脖。

POST請求例子

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive

name=Professional%20Ajax&publisher=Wiley

第一部分：請求行，第一行明了是post請求芯急，以及http1.1版本勺届。

第二部分：請求頭部，第二行至第六行娶耍。

第三部分：空行免姿，第七行的空行。

第四部分：請求數(shù)據(jù)榕酒，第八行胚膊。

2故俐、Response組成

一般情況下，服務(wù)器接收并處理客戶端發(fā)過來的請求后會返回一個HTTP的響應(yīng)消息紊婉。

HTTP響應(yīng)也由四個部分組成药版，分別是：狀態(tài)行、消息報頭喻犁、空行和響應(yīng)正文

image.png

• 第一部分：狀態(tài)行槽片，由HTTP協(xié)議版本號， 狀態(tài)碼肢础， 狀態(tài)消息 三部分組成还栓。

  第一行為狀態(tài)行，（HTTP/1.1）表明HTTP版本為1.1版本传轰，狀態(tài)碼為200剩盒，狀態(tài)消息為（ok）

• 第二部分：消息報頭，用來說明客戶端要使用的一些附加信息

  第二行和第三行為消息報頭慨蛙， Date:生成響應(yīng)的日期和時間辽聊；Content-Type:指定了MIME類型的HTML(text/html),編碼類型是UTF-8

• 第三部分：空行，消息報頭后面的空行是必須的

• 第四部分：響應(yīng)正文期贫，服務(wù)器返回給客戶端的文本信息身隐。

  空行后面的html部分為響應(yīng)正文。

5唯灵、談?wù)剬ttp緩存的了解。

HTTP的緩存機(jī)制也是依賴于請求和響應(yīng)header里的參數(shù)類實現(xiàn)的隙轻，最終響應(yīng)式從緩存中去埠帕，還是從服務(wù)端重新拉取，HTTP的緩存機(jī)制的流程如下所示：

image.png

HTTP的緩存可以分為兩種：

強制緩存：需要服務(wù)端參與判斷是否繼續(xù)使用緩存玖绿，當(dāng)客戶端第一次請求數(shù)據(jù)是敛瓷，服務(wù)端返回了緩存的過期時間（Expires與Cache-Control），沒有過期就可以繼續(xù)使用緩存斑匪，否則則不適用呐籽，無需再向服務(wù)端詢問。
對比緩存：需要服務(wù)端參與判斷是否繼續(xù)使用緩存蚀瘸，當(dāng)客戶端第一次請求數(shù)據(jù)時狡蝶，服務(wù)端會將緩存標(biāo)識（Last-Modified/If-Modified-Since與Etag/If-None-Match）與數(shù)據(jù)一起返回給客戶端，客戶端將兩者都備份到緩存中 贮勃，再次請求數(shù)據(jù)時贪惹，客戶端將上次備份的緩存 標(biāo)識發(fā)送給服務(wù)端，服務(wù)端根據(jù)緩存標(biāo)識進(jìn)行判斷寂嘉，如果返回304奏瞬，則表示通知客戶端可以繼續(xù)使用緩存枫绅。 強制緩存優(yōu)先于對比緩存。

上面提到強制緩存使用的的兩個標(biāo)識：

Expires：Expires的值為服務(wù)端返回的到期時間硼端，即下一次請求時并淋，請求時間小于服務(wù)端返回的到期時間，直接使用緩存數(shù)據(jù)珍昨。到期時間是服務(wù)端生成的县耽，客戶端和服務(wù)端的時間可能有誤差。 Cache-Control：Expires有個時間校驗的問題曼尊，所有HTTP1.1采用Cache-Control替代Expires酬诀。 Cache-Control的取值有以下幾種：

private: 客戶端可以緩存。
public: 客戶端和代理服務(wù)器都可緩存骆撇。
max-age=xxx: 緩存的內(nèi)容將在 xxx 秒后失效
no-cache: 需要使用對比緩存來驗證緩存數(shù)據(jù)瞒御。
no-store: 所有內(nèi)容都不會緩存，強制緩存神郊，對比緩存都不會觸發(fā)肴裙。 我們再來看看對比緩存的兩個標(biāo)識：

Last-Modified/If-Modified-Since

Last-Modified 表示資源上次修改的時間。

當(dāng)客戶端發(fā)送第一次請求時涌乳，服務(wù)端返回資源上次修改的時間：

Last-Modified: Tue, 12 Jan 2016 09:31:27 GMT

客戶端再次發(fā)送蜻懦，會在header里攜帶If-Modified-Since。將上次服務(wù)端返回的資源時間上傳給服務(wù)端夕晓。

If-Modified-Since: Tue, 12 Jan 2016 09:31:27 GMT 

服務(wù)端接收到客戶端發(fā)來的資源修改時間宛乃，與自己當(dāng)前的資源修改時間進(jìn)行對比，如果自己的資源修改時間大于客戶端發(fā)來的資源修改時間蒸辆，則說明資源做過修改征炼， 則返回200表示需要重新請求資源，否則返回304表示資源沒有被修改躬贡，可以繼續(xù)使用緩存谆奥。

上面是一種時間戳標(biāo)記資源是否修改的方法，還有一種資源標(biāo)識碼ETag的方式來標(biāo)記是否修改拂玻，如果標(biāo)識碼發(fā)生改變酸些，則說明資源已經(jīng)被修改，ETag優(yōu)先級高于Last-Modified檐蚜。

Etag/If-None-Match

ETag是資源文件的一種標(biāo)識碼魄懂，當(dāng)客戶端發(fā)送第一次請求時，服務(wù)端會返回當(dāng)前資源的標(biāo)識碼：

ETag: "5694c7ef-24dc"

客戶端再次發(fā)送闯第，會在header里攜帶上次服務(wù)端返回的資源標(biāo)識碼：

If-None-Match:"5694c7ef-24dc" 服務(wù)端接收到客戶端發(fā)來的資源標(biāo)識碼逢渔，則會與自己當(dāng)前的資源嗎進(jìn)行比較，如果不同乡括，則說明資源已經(jīng)被修改肃廓，則返回200智厌，如果相同則說明資源沒有被修改，返回 304盲赊，客戶端可以繼續(xù)使用緩存铣鹏。

6、Http長連接哀蘑。

Http1.0是短連接诚卸，HTTP1.1默認(rèn)是長連接，也就是默認(rèn)Connection的值就是keep-alive绘迁。但是長連接實質(zhì)是指的TCP連接合溺，而不是HTTP連接。TCP連接是一個雙向的通道缀台，它是可以保持一段時間不關(guān)閉的棠赛，因此TCP連接才有真正的長連接和短連接這一說。

Http1.1為什么要用使用tcp長連接膛腐？

長連接是指的TCP連接睛约，也就是說復(fù)用的是TCP連接。即長連接情況下哲身，多個HTTP請求可以復(fù)用同一個TCP連接辩涝，這就節(jié)省了很多TCP連接建立和斷開的消耗。

此外勘天，長連接并不是永久連接的怔揩。如果一段時間內(nèi)（具體的時間長短，是可以在header當(dāng)中進(jìn)行設(shè)置的脯丝，也就是所謂的超時時間）沧踏，這個連接沒有HTTP請求發(fā)出的話，那么這個長連接就會被斷掉巾钉。

需要更深的理解請點擊這里

7、Https加密原理秘案。

加密算法的類型基本上分為了兩種：

• 對稱加密砰苍，加密用的密鑰和解密用的密鑰是同一個，比較有代表性的就是 AES 加密算法阱高；
• 非對稱加密赚导，加密用的密鑰稱為公鑰，解密用的密鑰稱為私鑰赤惊，經(jīng)常使用到的 RSA 加密算法就是非對稱加密的吼旧；

此外，還有Hash加密算法

HASH算法：MD5, SHA1, SHA256

相比較對稱加密而言未舟，非對稱加密安全性更高圈暗，但是加解密耗費的時間更長掂为，速度慢。

想了解更多加密算法請點擊這里

HTTPS = HTTP + SSL员串，HTTPS 的加密就是在 SSL 中完成的勇哗。

這就要從 CA 證書講起了。CA 證書其實就是數(shù)字證書寸齐，是由 CA 機(jī)構(gòu)頒發(fā)的欲诺。至于 CA 機(jī)構(gòu)的權(quán)威性，那么是毋庸置疑的渺鹦，所有人都是信任它的扰法。CA 證書內(nèi)一般會包含以下內(nèi)容：

• 證書的頒發(fā)機(jī)構(gòu)、版本
• 證書的使用者
• 證書的公鑰
• 證書的有效時間
• 證書的數(shù)字簽名 Hash 值和簽名 Hash 算法
• ...

客戶端如何校驗 CA 證書毅厚？

CA 證書中的 Hash 值塞颁，其實是用證書的私鑰進(jìn)行加密后的值（證書的私鑰不在 CA 證書中）。然后客戶端得到證書后卧斟，利用證書中的公鑰去解密該 Hash 值殴边，得到 Hash-a ；然后再利用證書內(nèi)的簽名 Hash 算法去生成一個 Hash-b 珍语。最后比較 Hash-a 和 Hash-b 這兩個的值锤岸。如果相等，那么證明了該證書是對的板乙，服務(wù)端是可以被信任的是偷；如果不相等，那么就說明該證書是錯誤的募逞，可能被篡改了蛋铆，瀏覽器會給出相關(guān)提示，無法建立起 HTTPS 連接放接。除此之外刺啦，還會校驗 CA 證書的有效時間和域名匹配等。

HTTPS 中的 SSL 握手建立過程

假設(shè)現(xiàn)在有客戶端 A 和服務(wù)器 B ：

• 1纠脾、首先玛瘸，客戶端 A 訪問服務(wù)器 B ，比如我們用瀏覽器打開一個網(wǎng)頁 www.baidu.com 苟蹈，這時糊渊，瀏覽器就是客戶端 A ，百度的服務(wù)器就是服務(wù)器 B 了慧脱。這時候客戶端 A 會生成一個隨機(jī)數(shù)1渺绒，把隨機(jī)數(shù)1 、自己支持的 SSL 版本號以及加密算法等這些信息告訴服務(wù)器 B 。
• 2宗兼、服務(wù)器 B 知道這些信息后躏鱼，然后確認(rèn)一下雙方的加密算法，然后服務(wù)端也生成一個隨機(jī)數(shù) B 针炉，并將隨機(jī)數(shù) B 和 CA 頒發(fā)給自己的證書一同返回給客戶端 A 挠他。
• 3、客戶端 A 得到 CA 證書后篡帕，會去校驗該 CA 證書的有效性殖侵，校驗方法在上面已經(jīng)說過了案狠。校驗通過后兔乞，客戶端生成一個隨機(jī)數(shù)3 狂魔，然后用證書中的公鑰加密隨機(jī)數(shù)3 并傳輸給服務(wù)端 B 澳迫。
• 4擂找、服務(wù)端 B 得到加密后的隨機(jī)數(shù)3手报，然后利用私鑰進(jìn)行解密黄锤，得到真正的隨機(jī)數(shù)3骗爆。
• 5结执、最后度陆，客戶端 A 和服務(wù)端 B 都有隨機(jī)數(shù)1、隨機(jī)數(shù)2献幔、隨機(jī)數(shù)3懂傀，然后雙方利用這三個隨機(jī)數(shù)生成一個對話密鑰。之后傳輸內(nèi)容就是利用對話密鑰來進(jìn)行加解密了蜡感。這時就是利用了對稱加密蹬蚁，一般用的都是 AES 算法。
• 6郑兴、客戶端 A 通知服務(wù)端 B 犀斋，指明后面的通訊用對話密鑰來完成，同時通知服務(wù)器 B 客戶端 A 的握手過程結(jié)束情连。
• 7叽粹、服務(wù)端 B 通知客戶端 A，指明后面的通訊用對話密鑰來完成却舀，同時通知客戶端 A 服務(wù)器 B 的握手過程結(jié)束虫几。
• 8、SSL 的握手部分結(jié)束禁筏，SSL 安全通道的數(shù)據(jù)通訊開始，客戶端 A 和服務(wù)器 B 開始使用相同的對話密鑰進(jìn)行數(shù)據(jù)通訊衡招。

簡化如下：

• 1篱昔、客戶端和服務(wù)端建立 SSL 握手，客戶端通過 CA 證書來確認(rèn)服務(wù)端的身份；
• 2州刽、互相傳遞三個隨機(jī)數(shù)空执，之后通過這隨機(jī)數(shù)來生成一個密鑰；
• 3穗椅、互相確認(rèn)密鑰辨绊，然后握手結(jié)束；
• 4匹表、數(shù)據(jù)通訊開始门坷，都使用同一個對話密鑰來加解密；

可以發(fā)現(xiàn)袍镀，在 HTTPS 加密原理的過程中把對稱加密和非對稱加密都利用了起來默蚌。即利用了非對稱加密安全性高的特點，又利用了對稱加密速度快苇羡，效率高的好處绸吸。

需要更深的理解請點擊這里

8、HTTPS 如何防范中間人攻擊设江？

什么是中間人攻擊锦茁？

當(dāng)數(shù)據(jù)傳輸發(fā)生在一個設(shè)備（PC/手機(jī)）和網(wǎng)絡(luò)服務(wù)器之間時，攻擊者使用其技能和工具將自己置于兩個端點之間并截獲數(shù)據(jù)叉存；盡管交談的兩方認(rèn)為他們是在與對方交談码俩，但是實際上他們是在與干壞事的人交流，這便是中間人攻擊鹉胖。

有幾種攻擊方式握玛？

• 1、嗅探： 嗅探或數(shù)據(jù)包嗅探是一種用于捕獲流進(jìn)和流出系統(tǒng)/網(wǎng)絡(luò)的數(shù)據(jù)包的技術(shù)甫菠。網(wǎng)絡(luò)中的數(shù)據(jù)包嗅探就好像電話中的監(jiān)聽挠铲。

• 2、數(shù)據(jù)包注入： 在這種技術(shù)中寂诱，攻擊者會將惡意數(shù)據(jù)包注入常規(guī)數(shù)據(jù)中拂苹。這樣用戶便不會注意到文件/惡意軟件，因為它們是合法通訊流的一部分痰洒。

• 3瓢棒、會話劫持： 在你登錄進(jìn)你的銀行賬戶和退出登錄這一段期間便稱為一個會話。這些會話通常都是黑客的攻擊目標(biāo)丘喻，因為它們包含潛在的重要信息脯宿。在大多數(shù)案例中，黑客會潛伏在會話中泉粉，并最終控制它连霉。

• 4榴芳、SSL剝離： 在SSL剝離攻擊中，攻擊者使SSL/TLS連接剝落跺撼，隨之協(xié)議便從安全的HTTPS變成了不安全的HTTP窟感。

HTTPS 如何防范中間人攻擊：

請見https加密原理。

9歉井、有哪些響應(yīng)碼柿祈，分別都代表什么意思？

1** 信息哩至，服務(wù)器收到請求躏嚎，需要請求者繼續(xù)執(zhí)行操作

2** 成功，操作被成功接收并處理

3** 重定向憨募，需要進(jìn)一步的操作以完成請求

4** 客戶端錯誤紧索，請求包含語法錯誤或無法完成請求

5** 服務(wù)器錯誤，服務(wù)器在處理請求的過程中發(fā)生了錯誤

二菜谣、TCP/UDP （???）

1珠漂、為什么tcp要經(jīng)過三次握手，四次揮手尾膊？

重要標(biāo)志位

ACK ： TCP協(xié)議規(guī)定媳危，只有ACK=1時有效，也規(guī)定連接建立后所有發(fā)送的報文的ACK必須為1

SYN(SYNchronization) ： 在連接建立時用來同步序號冈敛。當(dāng)SYN=1而ACK=0時待笑，表明這是一個連接請求報文。對方若同意建立連接抓谴，則應(yīng)在響應(yīng)報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連接請求或連接接受報文暮蹂。

FIN （finis）即完，終結(jié)的意思癌压， 用來釋放一個連接仰泻。當(dāng) FIN = 1 時，表明此報文段的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢滩届，并要求釋放連接集侯。

三次握手、四次揮手過程

三次握手：

第一次握手：建立連接帜消√耐鳎客戶端發(fā)送連接請求報文段，將SYN位置為1泡挺，Sequence Number為x辈讶；然后，客戶端進(jìn)入SYN_SEND狀態(tài)娄猫，等待服務(wù)器的確認(rèn)贱除；

第二次握手：服務(wù)器收到SYN報文段咳促。服務(wù)器收到客戶端的SYN報文段，需要對這個SYN報文段進(jìn)行確認(rèn)勘伺，設(shè)置Acknowledgment Number為x+1(Sequence Number+1)；同時褂删，自己自己還要發(fā)送SYN請求信息飞醉，將SYN位置為1，Sequence Number為y屯阀；服務(wù)器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中缅帘，一并發(fā)送給客戶端，此時服務(wù)器進(jìn)入SYN_RECV狀態(tài)难衰；

第三次握手：客戶端收到服務(wù)器的SYN+ACK報文段。然后將Acknowledgment Number設(shè)置為y+1盖袭，向服務(wù)器發(fā)送ACK報文段鳄虱，這個報文段發(fā)送完畢以后弟塞，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)拙已，完成TCP三次握手。

四次揮手：

第一次分手：主機(jī)1（可以使客戶端倍踪，也可以是服務(wù)器端）系宫，設(shè)置Sequence Number和Acknowledgment Number扩借，向主機(jī)2發(fā)送一個FIN報文段往枷；此時错洁，主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)屯碴；這表示主機(jī)1沒有數(shù)據(jù)要發(fā)送給主機(jī)2了导而；

第二次分手：主機(jī)2收到了主機(jī)1發(fā)送的FIN報文段今艺，向主機(jī)1回一個ACK報文段虚缎，Acknowledgment Number為Sequence Number加1实牡；主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)创坞；主機(jī)2告訴主機(jī)1题涨，我“同意”你的關(guān)閉請求纲堵；

第三次分手：主機(jī)2向主機(jī)1發(fā)送FIN報文段婉支，請求關(guān)閉連接向挖，同時主機(jī)2進(jìn)入LAST_ACK狀態(tài)何之；

第四次分手：主機(jī)1收到主機(jī)2發(fā)送的FIN報文段溶推，向主機(jī)2發(fā)送ACK報文段蒜危，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài)部翘；主機(jī)2收到主機(jī)1的ACK報文段以后窖梁，就關(guān)閉連接荸哟；此時敲茄，主機(jī)1等待2MSL后依然沒有收到回復(fù)堰燎，則證明Server端已正常關(guān)閉秆剪，那好仅讽，主機(jī)1也可以關(guān)閉連接了洁灵。

“三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端汤锨，因而產(chǎn)生錯誤”。主要目的防止server端一直等待慎菲，浪費資源。換句話說有决，即是為了保證服務(wù)端能收接受到客戶端的信息并能做出正確的應(yīng)答而進(jìn)行前兩次(第一次和第二次)握手书幕，為了保證客戶端能夠接收到服務(wù)端的信息并能做出正確的應(yīng)答而進(jìn)行后兩次(第二次和第三次)握手苛骨。

“四次揮手”原因是因為tcp是全雙工模式牵素，接收到FIN時意味將沒有數(shù)據(jù)再發(fā)來，但是還是可以繼續(xù)發(fā)送數(shù)據(jù)测蘑。

2、TCP可靠傳輸原理實現(xiàn)（滑動窗口）怨绣。

確認(rèn)和重傳：接收方收到報文后就會進(jìn)行確認(rèn)，發(fā)送方一段時間沒有收到確認(rèn)就會重傳萧吠。

數(shù)據(jù)校驗纸型。

數(shù)據(jù)合理分片與排序，TCP會對數(shù)據(jù)進(jìn)行分片铸鹰，接收方會緩存為按序到達(dá)的數(shù)據(jù)，重新排序后再提交給應(yīng)用層剖毯。

流程控制：當(dāng)接收方來不及接收發(fā)送的數(shù)據(jù)時逊谋，則會提示發(fā)送方降低發(fā)送的速度胶滋，防止包丟失究恤。

擁塞控制：當(dāng)網(wǎng)絡(luò)發(fā)生擁塞時，減少數(shù)據(jù)的發(fā)送理张。

關(guān)于滑動窗口涯穷、流量控制拷况、擁塞控制實現(xiàn)原理請點擊這里

3粟誓、Tcp和Udp的區(qū)別鹰服？

1悲酷、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接
2顿肺、TCP提供可靠的服務(wù)屠尊。也就是說讼昆，通過TCP連接傳送的數(shù)據(jù)，無差錯掺炭，不丟失涧狮，不重復(fù)者冤，且按序到達(dá);UDP盡最大努力交付涉枫，即不保 證可靠交付
3愿汰、TCP面向字節(jié)流摇予，實際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;UDP是面向報文的
UDP沒有擁塞控制侧戴，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機(jī)的發(fā)送速率降低（對實時應(yīng)用很有用酗宋，如IP電話，實時視頻會議等）
4丹锹、每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
5颊糜、TCP首部開銷20字節(jié);UDP的首部開銷小衬鱼，只有8個字節(jié)
6、TCP的邏輯通信信道是全雙工的可靠信道抛蚤，UDP則是不可靠信道
詳細(xì)了解岁经，點擊這里

4樊拓、如何設(shè)計在 UDP 上層保證 UDP 的可靠性傳輸骑脱？

傳輸層無法保證數(shù)據(jù)的可靠傳輸，只能通過應(yīng)用層來實現(xiàn)了拥娄。實現(xiàn)的方式可以參照tcp可靠性傳輸?shù)姆绞健Ｈ绮豢紤]擁塞處理摊欠，可靠UDP的簡單設(shè)計如下：

• 1些椒、添加seq/ack機(jī)制，確保數(shù)據(jù)發(fā)送到對端
• 2石窑、添加發(fā)送和接收緩沖區(qū)，主要是用戶超時重傳经宏。
• 3烛恤、添加超時重傳機(jī)制苹熏。

具體過程即是：送端發(fā)送數(shù)據(jù)時，生成一個隨機(jī)seq=x干发，然后每一片按照數(shù)據(jù)大小分配seq。數(shù)據(jù)到達(dá)接收端后接收端放入緩存必峰，并發(fā)送一個ack=x的包吼蚁，表示對方已經(jīng)收到了數(shù)據(jù)。發(fā)送端收到了ack包后旗国，刪除緩沖區(qū)對應(yīng)的數(shù)據(jù)嫁怀。時間到后萝招，定時任務(wù)檢查是否需要重傳數(shù)據(jù)槐沼。

目前有如下開源程序利用udp實現(xiàn)了可靠的數(shù)據(jù)傳輸纽窟。分別為RUDP、RTP审孽、UDT:

1、RUDP（Reliable User Datagram Protocol）

RUDP 提供一組數(shù)據(jù)服務(wù)質(zhì)量增強機(jī)制打颤，如擁塞控制的改進(jìn)、重發(fā)機(jī)制及淡化服務(wù)器算法等反肋。

2、RTP（Real Time Protocol）

RTP為數(shù)據(jù)提供了具有實時特征的端對端傳送服務(wù)，如在組播或單播網(wǎng)絡(luò)服務(wù)下的交互式視頻音頻或模擬數(shù)據(jù)棍厌。

3、UDT（UDP-based Data Transfer Protocol）

UDT的主要目的是支持高速廣域網(wǎng)上的海量數(shù)據(jù)傳輸束析。

關(guān)于RUDP弄慰、RTP、UDT的更多介紹請查看此處

三墓陈、其它重要網(wǎng)絡(luò)概念 （??）

1、socket斷線重連怎么實現(xiàn)仔拟，心跳機(jī)制又是怎樣實現(xiàn)？

socket概念

套接字（socket）是通信的基石载佳，是支持TCP/IP協(xié)議的網(wǎng)絡(luò)通信的基本操作單元炒事。它是網(wǎng)絡(luò)通信過程中端點的抽象表示，包含進(jìn)行網(wǎng)絡(luò)通信必須的五種信息：連接使用的協(xié)議蔫慧，本地主機(jī)的IP地址挠乳，本地進(jìn)程的協(xié)議端口，遠(yuǎn)地主機(jī)的IP地址姑躲，遠(yuǎn)地進(jìn)程的協(xié)議端口。

為了區(qū)別不同的應(yīng)用程序進(jìn)程和連接黍析，許多計算機(jī)操作系統(tǒng)為應(yīng)用程序與TCP／IP協(xié)議交互提供了套接字(Socket)接口卖怜。應(yīng) 用層可以和傳輸層通過Socket接口，區(qū)分來自不同應(yīng)用程序進(jìn)程或網(wǎng)絡(luò)連接的通信阐枣，實現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù)马靠。

建立socket連接

建立Socket連接至少需要一對套接字，其中一個運行于客戶端蔼两，稱為ClientSocket 甩鳄，另一個運行于服務(wù)器端，稱為ServerSocket 宪哩。

套接字之間的連接過程分為三個步驟：服務(wù)器監(jiān)聽娩贷，客戶端請求第晰，連接確認(rèn)锁孟。

• 服務(wù)器監(jiān)聽：服務(wù)器端套接字并不定位具體的客戶端套接字彬祖，而是處于等待連接的狀態(tài)，實時監(jiān)控網(wǎng)絡(luò)狀態(tài)品抽，等待客戶端的連接請求储笑。
• 客戶端請求：指客戶端的套接字提出連接請求，要連接的目標(biāo)是服務(wù)器端的套接字圆恤。為此突倍，客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字，指出服務(wù)器端- - 套接字的地址和端口號盆昙，然后就向服務(wù)器端套接字提出連接請求羽历。
• 連接確認(rèn)：當(dāng)服務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時，就響應(yīng)客戶端套接字的請求淡喜，建立一個新的線程秕磷，把服務(wù)器端套接字的描述發(fā) 給客戶端，一旦客戶端確認(rèn)了此描述炼团，雙方就正式建立連接澎嚣。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽狀態(tài)，繼續(xù)接收其他客戶端套接字的連接請求瘟芝。

SOCKET連接與TCP連接

創(chuàng)建Socket連接時易桃，可以指定使用的傳輸層協(xié)議，Socket可以支持不同的傳輸層協(xié)議（TCP或UDP）锌俱，當(dāng)使用TCP協(xié)議進(jìn)行連接時晤郑，該Socket連接就是一個TCP連接。

Socket連接與HTTP連接

由于通常情況下Socket連接就是TCP連接贸宏，因此Socket連接一旦建立贩汉，通信雙方即可開始相互發(fā)送數(shù)據(jù)內(nèi)容，直到雙方連接斷開锚赤。但在實際網(wǎng) 絡(luò)應(yīng)用中匹舞，客戶端到服務(wù)器之間的通信往往需要穿越多個中間節(jié)點，例如路由器线脚、網(wǎng)關(guān)赐稽、防火墻等，大部分防火墻默認(rèn)會關(guān)閉長時間處于非活躍狀態(tài)的連接而導(dǎo)致 Socket 連接斷連浑侥，因此需要通過輪詢告訴網(wǎng)絡(luò)姊舵，該連接處于活躍狀態(tài)。

而HTTP連接使用的是“請求—響應(yīng)”的方式寓落，不僅在請求時需要先建立連接括丁，而且需要客戶端向服務(wù)器發(fā)出請求后，服務(wù)器端才能回復(fù)數(shù)據(jù)伶选。

很多情況下史飞，需要服務(wù)器端主動向客戶端推送數(shù)據(jù)尖昏，保持客戶端與服務(wù)器數(shù)據(jù)的實時與同步。此時若雙方建立的是Socket連接构资，服務(wù)器就可以直接將數(shù) 據(jù)傳送給客戶端抽诉；若雙方建立的是HTTP連接，則服務(wù)器需要等到客戶端發(fā)送一次請求后才能將數(shù)據(jù)傳回給客戶端吐绵，因此迹淌，客戶端定時向服務(wù)器端發(fā)送連接請求， 不僅可以保持在線己单，同時也是在“詢問”服務(wù)器是否有新的數(shù)據(jù)唉窃，如果有就將數(shù)據(jù)傳給客戶端。TCP(Transmission Control Protocol)?傳輸控制協(xié)議

socket斷線重連實現(xiàn)

正常連接斷開客戶端會給服務(wù)端發(fā)送一個fin包纹笼，服務(wù)端收到fin包后才會知道連接斷開句携。 而斷網(wǎng)斷電時客戶端無法發(fā)送fin包給服務(wù)端，所以服務(wù)端沒辦法檢測到客戶端已經(jīng)短線允乐。 為了緩解這個問題矮嫉，服務(wù)端需要有個心跳邏輯，就是服務(wù)端檢測到某個客戶端多久沒發(fā)送任何數(shù)據(jù)過來就認(rèn)為客戶端已經(jīng)斷開牍疏， 這需要客戶端定時向服務(wù)端發(fā)送心跳數(shù)據(jù)維持連接蠢笋。

心跳機(jī)制實現(xiàn)

長連接的實現(xiàn)：心跳機(jī)制，應(yīng)用層協(xié)議大多都有HeartBeat機(jī)制鳞陨，通常是客戶端每隔一小段時間向服務(wù)器發(fā)送一個數(shù)據(jù)包昨寞，通知服務(wù)器自己仍然在線。并傳輸一些可能必要的數(shù)據(jù)厦滤。使用心跳包的典型協(xié)議是IM援岩，比如QQ/MSN/飛信等協(xié)議

1、在TCP的機(jī)制里面掏导，本身是存在有心跳包的機(jī)制的享怀，也就是TCP的選項：SO_KEEPALIVE。 系統(tǒng)默認(rèn)是設(shè)置的2小時的心跳頻率趟咆。但是它檢查不到機(jī)器斷電添瓷、網(wǎng)線拔出、防火墻這些斷線值纱。 而且邏輯層處理斷線可能也不是那么好處理鳞贷。一般，如果只是用于迸斑耄活還是可以的搀愧。通過使用TCP的KeepAlive機(jī)制（修改那個time參數(shù)），可以讓連接每隔一小段時間就產(chǎn)生一些ack包，以降低被踢掉的風(fēng)險咱筛，當(dāng)然搓幌，這樣的代價是額外的網(wǎng)絡(luò)和CPU負(fù)擔(dān)。

2眷蚓、應(yīng)用層心跳機(jī)制實現(xiàn)鼻种。

2反番、Cookie與Session的作用和原理沙热。

• Session是在服務(wù)端保存的一個數(shù)據(jù)結(jié)構(gòu)，用來跟蹤用戶的狀態(tài)罢缸，這個數(shù)據(jù)可以保存在集群篙贸、數(shù)據(jù)庫、文件中枫疆。
• Cookie是客戶端保存用戶信息的一種機(jī)制爵川，用來記錄用戶的一些信息，也是實現(xiàn)Session的一種方式息楔。

Session：

由于HTTP協(xié)議是無狀態(tài)的協(xié)議寝贡，所以服務(wù)端需要記錄用戶的狀態(tài)時，就需要用某種機(jī)制來識具體的用戶值依，這個機(jī)制就是Session.典型的場景比如購物車圃泡，當(dāng)你點擊下單按鈕時，由于HTTP協(xié)議無狀態(tài)愿险，所以并不知道是哪個用戶操作的颇蜡，所以服務(wù)端要為特定的用戶創(chuàng)建了特定的Session，用用于標(biāo)識這個用戶辆亏，并且跟蹤用戶风秤，這樣才知道購物車?yán)锩嬗袔妆緯?code>這個Session是保存在服務(wù)端的，有一個唯一標(biāo)識扮叨。在服務(wù)端保存Session的方法很多缤弦，內(nèi)存、數(shù)據(jù)庫彻磁、文件都有甸鸟。集群的時候也要考慮Session的轉(zhuǎn)移，在大型的網(wǎng)站兵迅，一般會有專門的Session服務(wù)器集群抢韭，用來保存用戶會話，這個時候 Session 信息都是放在內(nèi)存的恍箭。

具體到Web中的Session指的就是用戶在瀏覽某個網(wǎng)站時刻恭，從進(jìn)入網(wǎng)站到瀏覽器關(guān)閉所經(jīng)過的這段時間，也就是用戶瀏覽這個網(wǎng)站所花費的時間。因此從上述的定義中我們可以看到鳍贾，Session實際上是一個特定的時間概念鞍匾。

當(dāng)客戶端訪問服務(wù)器時，服務(wù)器根據(jù)需求設(shè)置Session骑科，將會話信息保存在服務(wù)器上橡淑，同時將標(biāo)示Session的SessionId傳遞給客戶端瀏覽器，

瀏覽器將這個SessionId保存在內(nèi)存中咆爽，我們稱之為無過期時間的Cookie梁棠。瀏覽器關(guān)閉后，這個Cookie就會被清掉斗埂，它不會存在于用戶的Cookie臨時文件符糊。

以后瀏覽器每次請求都會額外加上這個參數(shù)值，服務(wù)器會根據(jù)這個SessionId呛凶，就能取得客戶端的數(shù)據(jù)信息男娄。

如果客戶端瀏覽器意外關(guān)閉，服務(wù)器保存的Session數(shù)據(jù)不是立即釋放漾稀，此時數(shù)據(jù)還會存在模闲，只要我們知道那個SessionId,就可以繼續(xù)通過請求獲得此Session的信息，因為此時后臺的Session還存在崭捍，當(dāng)然我們可以設(shè)置一個Session超時時間尸折，一旦超過規(guī)定時間沒有客戶端請求時，服務(wù)器就會清除對應(yīng)SessionId的Session信息缕贡。

Cookie

Cookie是由服務(wù)器端生成翁授，發(fā)送給User-Agent（一般是web瀏覽器），瀏覽器會將Cookie的key/value保存到某個目錄下的文本文件內(nèi)晾咪，下次請求同一網(wǎng)站時就發(fā)送該Cookie給服務(wù)器（前提是瀏覽器設(shè)置為啟用Cookie）收擦。Cookie名稱和值可以由服務(wù)器端開發(fā)自己定義，對于JSP而言也可以直接寫入Sessionid谍倦，這樣服務(wù)器可以知道該用戶是否合法用戶以及是否需要重新登錄等塞赂。

3、IP報文中的內(nèi)容昼蛀。

image.png

版本：IP協(xié)議的版本宴猾，目前的IP協(xié)議版本號為4，下一代IP協(xié)議版本號為6叼旋。

首部長度：IP報頭的長度仇哆。固定部分的長度（20字節(jié)）和可變部分的長度之和。共占4位夫植。最大為1111讹剔，即10進(jìn)制的15油讯，代表IP報頭的最大長度可以為15個32bits（4字節(jié)），也就是最長可為15*4=60字節(jié)延欠，除去固定部分的長度20字節(jié)陌兑，可變部分的長度最大為40字節(jié)。

服務(wù)類型：Type Of Service由捎。

總長度：IP報文的總長度兔综。報頭的長度和數(shù)據(jù)部分的長度之和。

標(biāo)識：唯一的標(biāo)識主機(jī)發(fā)送的每一分?jǐn)?shù)據(jù)報狞玛。通常每發(fā)送一個報文软驰，它的值加一。當(dāng)IP報文長度超過傳輸網(wǎng)絡(luò)的MTU（最大傳輸單元）時必須分片为居，這個標(biāo)識字段的值被復(fù)制到所有數(shù)據(jù)分片的標(biāo)識字段中碌宴，使得這些分片在達(dá)到最終目的地時可以依照標(biāo)識字段的內(nèi)容重新組成原先的數(shù)據(jù)杀狡。

標(biāo)志：共3位蒙畴。R、DF呜象、MF三位。目前只有后兩位有效，DF位：為1表示不分片看尼，為0表示分片坦报。MF：為1表示“更多的片”，為0表示這是最后一片休玩。

片位移：本分片在原先數(shù)據(jù)報文中相對首位的偏移位著淆。（需要再乘以8）

生存時間：IP報文所允許通過的路由器的最大數(shù)量。每經(jīng)過一個路由器拴疤，TTL減1永部，當(dāng)為0時，路由器將該數(shù)據(jù)報丟棄呐矾。TTL 字段是由發(fā)送端初始設(shè)置一個 8 bit字段.推薦的初始值由分配數(shù)字 RFC 指定苔埋，當(dāng)前值為 64。發(fā)送 ICMP 回顯應(yīng)答時經(jīng)常把 TTL 設(shè)為最大值 255蜒犯。

協(xié)議：指出IP報文攜帶的數(shù)據(jù)使用的是那種協(xié)議组橄，以便目的主機(jī)的IP層能知道要將數(shù)據(jù)報上交到哪個進(jìn)程（不同的協(xié)議有專門不同的進(jìn)程處理）。和端口號類似罚随，此處采用協(xié)議號玉工，TCP的協(xié)議號為6，UDP的協(xié)議號為17淘菩。ICMP的協(xié)議號為1遵班，IGMP的協(xié)議號為2.

首部校驗和：計算IP頭部的校驗和，檢查IP報頭的完整性。

源IP地址：標(biāo)識IP數(shù)據(jù)報的源端設(shè)備费奸。

目的IP地址：標(biāo)識IP數(shù)據(jù)報的目的地址弥激。

最后就是可變部分和數(shù)據(jù)部分。

四愿阐、常見網(wǎng)絡(luò)流程機(jī)制 （??）

1微服、瀏覽器輸入地址到返回結(jié)果發(fā)生了什么？

總體來說分為以下幾個過程:

1缨历、DNS解析以蕴，此外還有DNSy優(yōu)化（DNS緩存、DNS負(fù)載均衡）

2辛孵、TCP連接

3丛肮、發(fā)送HTTP請求

4、服務(wù)器處理請求并返回HTTP報文

5魄缚、瀏覽器解析渲染頁面

6宝与、連接結(jié)束

Web前端的本質(zhì)

將信息快速并友好的展示給用戶并能夠與用戶進(jìn)行交互。

如何盡快的加載資源（網(wǎng)絡(luò)優(yōu)化）冶匹？

答案就是能不從網(wǎng)絡(luò)中加載的資源就不從網(wǎng)絡(luò)中加載习劫，當(dāng)我們合理使用緩存，將資源放在瀏覽器端嚼隘，這是最快的方式诽里。如果資源必須從網(wǎng)絡(luò)中加載，則要考慮縮短連接時間飞蛹，即DNS優(yōu)化部分;減少響應(yīng)內(nèi)容大小谤狡，即對內(nèi)容進(jìn)行壓縮。另一方面卧檐，如果加載的資源數(shù)比較少的話墓懂，也可以快速的響應(yīng)用戶。

操作系統(tǒng)（???）

1泄隔、操作系統(tǒng)如何管理內(nèi)存的拒贱？

2、進(jìn)程調(diào)度佛嬉。

3逻澳、說下Linux進(jìn)程和線程的區(qū)別。

進(jìn)程和線程的主要差別在于它們是不同的操作系統(tǒng)資源管理方式暖呕。進(jìn)程有獨立的地址空間斜做，一個進(jìn)程崩潰后，在保護(hù)模式下不會對其它進(jìn)程產(chǎn)生影響湾揽，而線程只是一個進(jìn)程中的不同執(zhí)行路徑瓤逼。線程有自己的堆棧和局部變量笼吟，但線程之間沒有單獨的地址空間，一個線程死掉就等于整個進(jìn)程死掉霸旗，所以多進(jìn)程的程序要比多線程的程序健壯贷帮，但在進(jìn)程切換時，耗費資源較大诱告，效率要差一些撵枢。但對于一些要求同時進(jìn)行并且又要共享某些變量的并發(fā)操作，只能用線程精居，不能用進(jìn)程锄禽。

1. 簡而言之,一個程序至少有一個進(jìn)程,一個進(jìn)程至少有一個線程。

2. 線程的劃分尺度小于進(jìn)程靴姿，使得多線程程序的并發(fā)性高沃但。

3. 另外，進(jìn)程在執(zhí)行過程中擁有獨立的內(nèi)存單元佛吓，而多個線程共享內(nèi)存宵晚，從而極大地提高了程序的運行效率。

4. 線程在執(zhí)行過程中與進(jìn)程還是有區(qū)別的辈毯。每個獨立的線程有一個程序運行的入口坝疼、順序執(zhí)行序列和程序的出口搜贤。但是線程不能夠獨立執(zhí)行谆沃，必須依存在應(yīng)用程序中，由應(yīng)用程序提供多個線程執(zhí)行控制仪芒。

5. 從邏輯角度來看唁影，多線程的意義在于一個應(yīng)用程序中，有多個執(zhí)行部分可以同時執(zhí)行掂名。但操作系統(tǒng)并沒有將多個線程看做多個獨立的應(yīng)用据沈，來實現(xiàn)進(jìn)程的調(diào)度和管理以及資源分配。這就是進(jìn)程和線程的重要區(qū)別饺蔑。

4锌介、你能解釋一下Linux的軟鏈接和硬鏈接嗎？

Linux鏈接分兩種猾警，一種被稱為硬鏈接（Hard Link）孔祸，另一種被稱為符號鏈接（Symbolic Link）。默認(rèn)情況下发皿，ln命令產(chǎn)生硬鏈接崔慧。

硬連接

硬連接指通過索引節(jié)點來進(jìn)行連接。在Linux的文件系統(tǒng)中穴墅，保存在磁盤分區(qū)中的文件不管是什么類型都給它分配一個編號惶室，稱為索引節(jié)點號(Inode Index)温自。在Linux中，多個文件名指向同一索引節(jié)點是存在的皇钞。一般這種連接就是硬連接悼泌。硬連接的作用是允許一個文件擁有多個有效路徑名，這樣用戶就可以建立硬連接到重要文件夹界，以防止“誤刪”的功能券躁。其原因如上所述，因為對應(yīng)該目錄的索引節(jié)點有一個以上的連接掉盅。只刪除一個連接并不影響索引節(jié)點本身和其它的連接也拜，只有當(dāng)最后一個連接被刪除后，文件的數(shù)據(jù)塊及目錄的連接才會被釋放趾痘。也就是說慢哈，文件真正刪除的條件是與之相關(guān)的所有硬連接文件均被刪除。

軟連接

另外一種連接稱之為符號連接（Symbolic Link）永票，也叫軟連接卵贱。軟鏈接文件有類似于Windows的快捷方式。它實際上是一個特殊的文件侣集。在符號連接中键俱，文件實際上是一個文本文件，其中包含的有另一文件的位置信息世分。

5编振、安卓權(quán)限管理，為何在清單中注冊權(quán)限臭埋，安卓APP就可以使用踪央，反之不可以？

此題考查Android的權(quán)限管理在Android的安全架構(gòu)中的作用瓢阴。

Android 是一個權(quán)限分隔的操作系統(tǒng)畅蹂，其中每個應(yīng)用都有其獨特的系統(tǒng)標(biāo)識（Linux 用戶 ID 和組 ID）。系統(tǒng)各部分也分隔為不同的標(biāo)識荣恐。Linux 據(jù)此將不同的應(yīng)用以及應(yīng)用與系統(tǒng)分隔開來液斜。

其他更詳細(xì)的安全功能通過“權(quán)限”機(jī)制提供，此機(jī)制會限制特定進(jìn)程可以執(zhí)行的具體操作叠穆，并且根據(jù) URI 權(quán)限授權(quán)臨時訪問特定的數(shù)據(jù)段少漆。

Android 安全架構(gòu)的中心設(shè)計點是：在默認(rèn)情況下任何應(yīng)用都沒有權(quán)限執(zhí)行對其他應(yīng)用、操作系統(tǒng)或用戶有不利影響的任何操作痹束。這包括讀取或?qū)懭胗脩舻乃接袛?shù)據(jù)（例如聯(lián)系人或電子郵件）检疫、讀取或?qū)懭肫渌麘?yīng)用程序的文件、執(zhí)行網(wǎng)絡(luò)訪問祷嘶、使設(shè)備保持喚醒狀態(tài)等屎媳。

由于每個 Android 應(yīng)用都是在進(jìn)程沙盒中運行夺溢，因此應(yīng)用必須顯式共享資源和數(shù)據(jù)。它們的方法是聲明需要哪些權(quán)限來獲取基本沙盒未提供的額外功能烛谊。應(yīng)用以靜態(tài)方式聲明它們需要的權(quán)限风响，然后 Android 系統(tǒng)提示用戶同意。

數(shù)據(jù)庫 （?）

1丹禀、數(shù)據(jù)庫的四大特征状勤，數(shù)據(jù)庫的隔離級別？

事務(wù)（Transaction）是并發(fā)控制的基本單位双泪。所謂的事務(wù)持搜，它是一個操作序列，這些操作要么都執(zhí)行焙矛，要么都不執(zhí)行葫盼，它是一個不可分割的工作單位。例如村斟，銀行轉(zhuǎn)賬工作：從一個賬號扣款并使另一個賬號增款贫导，這兩個操作要么都執(zhí)行，要么都不執(zhí)行蟆盹。所以孩灯，應(yīng)該把它們看成一個事務(wù)。事務(wù)是數(shù)據(jù)庫維護(hù)數(shù)據(jù)一致性的單位逾滥，在每個事務(wù)結(jié)束時峰档，都能保持?jǐn)?shù)據(jù)一致性。事務(wù)具有以下4個基本特征：

數(shù)據(jù)庫的四大特征：

（1）原子性（Atomicity）

原子性是指事務(wù)包含的所有操作要么全部成功匣距，要么全部失敗回滾面哥。

（2）一致性（Consistency）

一個事務(wù)執(zhí)行之前和執(zhí)行之后都必須處于一致性狀態(tài)。

（3）隔離性（Isolation）

隔離性是當(dāng)多個用戶并發(fā)訪問數(shù)據(jù)庫時毅待，比如操作同一張表時，數(shù)據(jù)庫為每一個用戶開啟的事務(wù)归榕，不能被其他事務(wù)的操作所干擾尸红，多個并發(fā)事務(wù)之間要相互隔離。

（4）持久性（Durability）

持久性是指一個事務(wù)一旦被提交了刹泄，那么對數(shù)據(jù)庫中的數(shù)據(jù)的改變就是永久性的外里。

數(shù)據(jù)庫的隔離級別：

1）Serializable(串行化)：可避免臟讀、不可重復(fù)讀特石、幻讀的發(fā)生盅蝗。

2）Repeatable read (可重復(fù)讀)：可避免臟讀、不可重復(fù)讀的發(fā)生姆蘸。

3）Read committed (讀已提交)：可避免臟讀的發(fā)生墩莫。

4）Read uncommitted (讀未提交)：最低級別芙委，任何情況都無法保證。

2狂秦、數(shù)據(jù)庫設(shè)計中常講的三范式是指什么灌侣？

1）第一范式1NF(域的原子性)

如果數(shù)據(jù)庫表中的所有字段值都是不可分解的原子值，就說明該數(shù)據(jù)庫表滿足了第一范式

2）第二范式2NF(表中除主鍵外的字段都完全依賴主鍵)

第二范式是在第一范式基礎(chǔ)上建立的裂问。第二范式有兩個重點:(1)表中必須有主鍵侧啼；(2)其他非主屬性必須完全依賴主鍵，不能只依賴主鍵的一部分（主要針對聯(lián)合主鍵而言）堪簿。

3）第三范式3NF（表中除主鍵外的字段都完全直接依賴痊乾，不能是傳遞依賴）

不能是傳遞依賴，即不能存在：非主鍵列 A 依賴于非主鍵列 B椭更，非主鍵列 B 依賴于主鍵的情況符喝。第二范式和第三范式區(qū)分的關(guān)鍵點：2NF：非主鍵列是否完全依賴于主鍵，還是依賴于主鍵的一部分甜孤；3NF：非主鍵列是直接依賴于主鍵协饲，還是直接依賴于非主鍵列。

數(shù)據(jù)結(jié)構(gòu)和算法（???）

對于算法面試準(zhǔn)備缴川，無疑就是刷《劍指Offer》+ LeetCode 效果最佳茉稠。刷《劍指Offer》是為了建立全面的算法面試思維，打下堅實的基礎(chǔ)把夸，刷LeetCode則是為了不斷強化與開闊我們自己的算法思想而线。這兩塊 CS-Notes 中已經(jīng)實現(xiàn)地很完美了，建議大家將《劍指Offer》刷完恋日，然后再至少刷100道LeetCode題目以上膀篮。

1、劍指 Offer 題解

2岂膳、Leetcode 題解