學(xué)習(xí)資料(網(wǎng)絡(luò))：
1、HTTP 與 HTTPS 有什么區(qū)別？
HTTPS 是一種通過計(jì)算機(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ù)的隱私與完整性。
HTPPS 和 HTTP 的概念：
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)
的 HTTP 通道，簡單講是 HTTP 的安全版。即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，
因此加密的詳細(xì)內(nèi)容就需要 SSL。它是一個(gè) URI scheme（抽象標(biāo)識符體系），句法類同 http:
體系。用于安全的 HTTP 數(shù)據(jù)傳輸。https:URL 表明它使用了 HTTP，但 HTTPS 存在不同于
HTTP 的默認(rèn)端口及一個(gè)加密/身份驗(yàn)證層（在 HTTP 與 TCP 之間）。這個(gè)系統(tǒng)的最初研發(fā)由
網(wǎng)景公司進(jìn)行，提供了身份驗(yà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 申請證書，一般免費(fèi)證書很少，需要交費(fèi)。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 申請一個(gè)
用于證明服務(wù)器用途類型的證書. 改證書只有用于對應(yīng)的 server 的時(shí)候,客戶度才信任次主
機(jī) 2 . 防止通訊過程中的數(shù)據(jù)的泄密和被竄改
如下圖所示，可以很明顯的看出兩個(gè)的區(qū)別：
注：TLS 是 SSL 的升級替代版，具體發(fā)展歷史可以參考傳輸層安全性協(xié)議。
HTTP 與 HTTPS 在寫法上的區(qū)別也是前綴的不同，客戶端處理的方式也不同，具體說來：
如果 URL 的協(xié)議是 HTTP，則客戶端會(huì)打開一條到服務(wù)端端口 80（默認(rèn)）的連接，并向其
發(fā)送老的 HTTP 請求。 如果 URL 的協(xié)議是 HTTPS，則客戶端會(huì)打開一條到服務(wù)端端口 443
（默認(rèn)）的連接，然后與服務(wù)器握手，以二進(jìn)制格式與服務(wù)器交換一些 SSL 的安全參數(shù)，附
上加密的 HTTP 請求。 所以你可以看到，HTTPS 比 HTTP 多了一層與 SSL 的連接，這也就
是客戶端與服務(wù)端 SSL 握手的過程，整個(gè)過程主要完成以下工作：
交換協(xié)議版本號 選擇一個(gè)兩端都了解的密碼 對兩端的身份進(jìn)行認(rèn)證 生成臨時(shí)的會(huì)話密
鑰，以便加密信道。 SSL 握手是一個(gè)相對比較復(fù)雜的過程，更多關(guān)于 SSL 握手的過程細(xì)節(jié)
可以參考 TLS/SSL 握手過程
SSL/TSL 的常見開源實(shí)現(xiàn)是 OpenSSL，OpenSSL 是一個(gè)開放源代碼的軟件庫包，應(yīng)用程序
可以使用這個(gè)包來進(jìn)行安全通信，避免竊聽，同時(shí)確認(rèn)另一端連接者的身份。這個(gè)包廣泛被
應(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 年，那個(gè)時(shí)候只是使用一些較為簡單的網(wǎng)頁上和網(wǎng)絡(luò)
請求上，而 HTTP1.1 則在 1999 年才開始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)絡(luò)請求中，同時(shí)
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 中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶
端只是需要某個(gè)對象的一部分，而服務(wù)器卻將整個(gè)對象送過來了，并且不支持?jǐn)帱c(diǎn)
續(xù)傳功能，HTTP1.1 則在請求頭引入了 range 頭域，它允許只請求資源的某個(gè)部分，
即返回碼是 206（Partial Content），這樣就方便了開發(fā)者自由的選擇以便于充分利
用帶寬和連接。
3、錯(cuò)誤通知的管理，在 HTTP1.1 中新增了 24 個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如 409（Conflict）
表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個(gè)資
源被永久性的刪除。
4、Host 頭處理，在 HTTP1.0 中認(rèn)為每臺服務(wù)器都綁定一個(gè)唯一的 IP 地址，因此，
請求消息中的 URL 并沒有傳遞主機(jī)名（hostname）。但隨著虛擬主機(jī)技術(shù)的發(fā)展，
在一臺物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)（Multi-homed Web Servers），并且它
們共享一個(gè) IP 地址。HTTP1.1 的請求消息和響應(yīng)消息都應(yīng)支持 Host 頭域，且請求
消息中如果沒有 Host 頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）。
5、長連接，HTTP 1.1 支持長連接（PersistentConnection）和請求的流水線
（Pipelining）處理，在一個(gè) TCP 連接上可以傳送多個(gè) HTTP 請求和響應(yīng)，減少了建
立和關(guān)閉連接的消耗和延遲，在 HTTP1.1 中默認(rèn)開啟 Connection： keep-alive，一
定程度上彌補(bǔ)了 HTTP1.0 每次請求都要?jiǎng)?chuàng)建連接的缺點(diǎn)。
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ù)用通過多個(gè)請求 stream 共享一個(gè) tcp 連接的方式，解決了 HOL blocking 的
問題，降低了延遲同時(shí)提高了帶寬的利用率。
2、請求優(yōu)先級（request prioritization）。多路復(fù)用帶來一個(gè)新的問題是，在連接
共享的基礎(chǔ)之上有可能會(huì)導(dǎo)致關(guān)鍵請求被阻塞。SPDY 允許給每個(gè) request 設(shè)置優(yōu)先
級，這樣重要的請求就會(huì)優(yōu)先得到響應(yīng)。比如瀏覽器加載首頁，首頁的 html 內(nèi)容應(yīng)
該優(yōu)先展示，之后才是各種靜態(tài)資源文件，腳本文件等加載，這樣可以保證用戶能
第一時(shí)間看到網(wǎng)頁內(nèi)容。
3、header 壓縮。前面提到 HTTP1.x 的 header 很多時(shí)候都是重復(fù)多余的。選擇合適
的壓縮算法可以減小包的大小和數(shù)量。
4、基于 HTTPS 的加密協(xié)議傳輸，大大提高了傳輸數(shù)據(jù)的可靠性。
5、服務(wù)端推送（server push），采用了 SPDY 的網(wǎng)頁，例如我的網(wǎng)頁有一個(gè) sytle.css
的請求，在客戶端收到 sytle.css 數(shù)據(jù)的同時(shí)，服務(wù)端會(huì)將 sytle.js 的文件推送給客戶
端，當(dāng)客戶端再次嘗試獲取 sytle.js 時(shí)就可以直接從緩存中獲取到，不用再發(fā)請求了。
SPDY 構(gòu)成圖：
SPDY 位于 HTTP 之下，TCP 和 SSL 之上，這樣可以輕松兼容老版本的 HTTP 協(xié)議(將 HTTP1.x
的內(nèi)容封裝成一種新的 frame 格式)，同時(shí)可以使用已有的 SSL 功能。
HTTP2.0 和 HTTP1.X 相比的新特性
新的二進(jìn)制格式（Binary Format），HTTP1.x 的解析是基于文本?；谖谋緟f(xié)議的
格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性，要做到健壯性考慮的場景必然
很多，二進(jìn)制則不同，只認(rèn) 0 和 1 的組合。基于這種考慮 HTTP2.0 的協(xié)議解析決定
采用二進(jìn)制格式，實(shí)現(xiàn)方便且健壯。
多路復(fù)用（MultiPlexing），即連接共享，即每一個(gè) request 都是是用作連接共享機(jī)
制的。一個(gè) request 對應(yīng)一個(gè) id，這樣一個(gè)連接上可以有多個(gè) request，每個(gè)連接的
request 可以隨機(jī)的混雜在一起，接收方可以根據(jù) request 的 id 將 request 再歸屬
到各自不同的服務(wù)端請求里面。
header 壓縮，如上文中所言，對前面提到過 HTTP1.x 的 header 帶有大量信息，而
且每次都要重復(fù)發(fā)送，HTTP2.0 使用 encoder 來減少需要傳輸?shù)?header 大小，通訊
雙方各自 cache 一份 header fields 表，既避免了重復(fù) header 的傳輸，又減小了需
要傳輸?shù)拇笮　?br> 服務(wù)端推送（server push），同 SPDY 一樣，HTTP2.0 也具有 server push 功能。
需要更深的理解請點(diǎn)擊這里
3、Https 請求慢的解決辦法
1、不通過 DNS 解析，直接訪問 IP
2、解決連接無法復(fù)用
http/1.0 協(xié)議頭里可以設(shè)置 Connection:Keep-Alive 或者 Connection:Close，選擇是否允許
在一定時(shí)間內(nèi)復(fù)用連接（時(shí)間可由服務(wù)器控制）。但是這對 App 端的請求成效不大，因?yàn)?br> App 端的請求比較分散且時(shí)間跨度相對較大。
方案 1.基于 tcp 的長連接 (主要） 移動(dòng)端建立一條自己的長鏈接通道，通道的實(shí)現(xiàn)是基于
tcp 協(xié)議?；?tcp 的 socket 編程技術(shù)難度相對復(fù)雜很多，而且需要自己定制協(xié)議。但信息
的上報(bào)和推送變得更及時(shí)，請求量爆發(fā)的時(shí)間點(diǎn)還能減輕服務(wù)器壓力（避免頻繁創(chuàng)建和銷毀
連接）
方案 2.http long-polling 客戶端在初始狀態(tài)發(fā)送一個(gè) polling 請求到服務(wù)器，服務(wù)器并不會(huì)
馬上返回業(yè)務(wù)數(shù)據(jù)，而是等待有新的業(yè)務(wù)數(shù)據(jù)產(chǎn)生的時(shí)候再返回，所以鏈接會(huì)一直被保持。
一但結(jié)束當(dāng)前連接，馬上又會(huì)發(fā)送一個(gè)新的 polling 請求，如此反復(fù)，保證一個(gè)連接被保持。
存在問題： 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ù)器會(huì)等待服務(wù)器的 response 結(jié)束之后才將結(jié)果推送給請求客戶端。
streaming 不會(huì)結(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
它的原因是隊(duì)列的第一個(gè)數(shù)據(jù)包（隊(duì)頭）受阻而導(dǎo)致整列數(shù)據(jù)包受阻
使用 http pipelining，確保幾乎在同一時(shí)間把 request 發(fā)向了服務(wù)器
4、Http 的 request 和 response 的協(xié)議組成
1、Request 組成
客戶端發(fā)送一個(gè) HTTP 請求到服務(wù)器的請求消息包括以下格式：
請求行（request line）、請求頭部（header）、空行和請求數(shù)據(jù)四個(gè)部分組成。
請求行以一個(gè)方法符號開頭，以空格分開，后面跟著請求的 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ǔ).該
信息由你的瀏覽器來定義,并且在每個(gè)請求中自動(dòng)發(fā)送等等 第三部分：空行，請求頭部后面
的空行是必須的 即使第四部分的請求數(shù)據(jù)為空，也必須有空行。 第四部分：請求數(shù)據(jù)也叫
主體，可以添加任意的其他數(shù)據(jù)。 這個(gè)例子的請求數(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ā)過來的請求后會(huì)返回一個(gè) HTTP 的響應(yīng)消息。
HTTP 響應(yīng)也由四個(gè)部分組成，分別是：狀態(tài)行、消息報(bào)頭、空行和響應(yīng)正文。
第一部分：狀態(tài)行，由 HTTP 協(xié)議版本號， 狀態(tài)碼， 狀態(tài)消息 三部分組成。
第一行為狀態(tài)行，（HTTP/1.1）表明 HTTP 版本為 1.1 版本，狀態(tài)碼為 200，狀態(tài)消息為（ok）
第二部分：消息報(bào)頭，用來說明客戶端要使用的一些附加信息
第二行和第三行為消息報(bào)頭， Date:生成響應(yīng)的日期和時(shí)間；Content-Type:指定了 MIME
類型的 HTML(text/html),編碼類型是 UTF-8
第三部分：空行，消息報(bào)頭后面的空行是必須的
第四部分：響應(yīng)正文，服務(wù)器返回給客戶端的文本信息。
空行后面的 html 部分為響應(yīng)正文。
5、談?wù)剬?http 緩存的了解。
HTTP 的緩存機(jī)制也是依賴于請求和響應(yīng) header 里的參數(shù)類實(shí)現(xiàn)的，最終響應(yīng)式從緩存中
去，還是從服務(wù)端重新拉取，HTTP 的緩存機(jī)制的流程如下所示：
HTTP 的緩存可以分為兩種：
強(qiáng)制緩存：需要服務(wù)端參與判斷是否繼續(xù)使用緩存，當(dāng)客戶端第一次請求數(shù)據(jù)是，服務(wù)端返
回了緩存的過期時(shí)間（Expires 與 Cache-Control），沒有過期就可以繼續(xù)使用緩存，否則則
不適用，無需再向服務(wù)端詢問。 對比緩存：需要服務(wù)端參與判斷是否繼續(xù)使用緩存，當(dāng)客
戶端第一次請求數(shù)據(jù)時(shí)，服務(wù)端會(huì)將緩存標(biāo)識（Last-Modified/If-Modified-Since 與
Etag/If-None-Match）與數(shù)據(jù)一起返回給客戶端，客戶端將兩者都備份到緩存中 ，再次請
求數(shù)據(jù)時(shí)，客戶端將上次備份的緩存 標(biāo)識發(fā)送給服務(wù)端，服務(wù)端根據(jù)緩存標(biāo)識進(jìn)行判斷，
如果返回 304，則表示通知客戶端可以繼續(xù)使用緩存。 強(qiáng)制緩存優(yōu)先于對比緩存。
上面提到強(qiáng)制緩存使用的的兩個(gè)標(biāo)識：
Expires：Expires 的值為服務(wù)端返回的到期時(shí)間，即下一次請求時(shí)，請求時(shí)間小于服務(wù)端返
回的到期時(shí)間，直接使用緩存數(shù)據(jù)。到期時(shí)間是服務(wù)端生成的，客戶端和服務(wù)端的時(shí)間可能
有誤差。 Cache-Control：Expires 有個(gè)時(shí)間校驗(yàn)的問題，所有 HTTP1.1 采用 Cache-Control
替代 Expires。 Cache-Control 的取值有以下幾種：
private: 客戶端可以緩存。 public: 客戶端和代理服務(wù)器都可緩存。 max-age=xxx: 緩存的
內(nèi)容將在 xxx 秒后失效 no-cache: 需要使用對比緩存來驗(yàn)證緩存數(shù)據(jù)。 no-store: 所有內(nèi)
容都不會(huì)緩存，強(qiáng)制緩存，對比緩存都不會(huì)觸發(fā)。 我們再來看看對比緩存的兩個(gè)標(biāo)識：
Last-Modified/If-Modified-Since
Last-Modified 表示資源上次修改的時(shí)間。
當(dāng)客戶端發(fā)送第一次請求時(shí)，服務(wù)端返回資源上次修改的時(shí)間：
Last-Modified: Tue, 12 Jan 2016 09:31:27 GMT
客戶端再次發(fā)送，會(huì)在 header 里攜帶 If-Modified-Since。將上次服務(wù)端返回的資源時(shí)間上
傳給服務(wù)端。
If-Modified-Since: Tue, 12 Jan 2016 09:31:27 GMT
服務(wù)端接收到客戶端發(fā)來的資源修改時(shí)間，與自己當(dāng)前的資源修改時(shí)間進(jìn)行對比，如果自己
的資源修改時(shí)間大于客戶端發(fā)來的資源修改時(shí)間，則說明資源做過修改， 則返回 200 表示
需要重新請求資源，否則返回 304 表示資源沒有被修改，可以繼續(xù)使用緩存。
上面是一種時(shí)間戳標(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ā)送第一次請求時(shí)，服務(wù)端會(huì)返回當(dāng)前資源的標(biāo)
識碼：
ETag: "5694c7ef-24dc" 客戶端再次發(fā)送，會(huì)在 header 里攜帶上次服務(wù)端返回的資源標(biāo)識碼：
If-None-Match:"5694c7ef-24dc" 服務(wù)端接收到客戶端發(fā)來的資源標(biāo)識碼，則會(huì)與自己當(dāng)前
的資源嗎進(jìn)行比較，如果不同，則說明資源已經(jīng)被修改，則返回 200，如果相同則說明資源
沒有被修改，返回 304，客戶端可以繼續(xù)使用緩存。
6、Http 長連接。
Http1.0 是短連接，HTTP1.1 默認(rèn)是長連接，也就是默認(rèn) Connection 的值就是 keep-alive。
但是長連接實(shí)質(zhì)是指的 TCP 連接，而不是 HTTP 連接。TCP 連接是一個(gè)雙向的通道，它是可
以保持一段時(shí)間不關(guān)閉的，因此 TCP 連接才有真正的長連接和短連接這一說。
Http1.1 為什么要用使用 tcp 長連接？
長連接是指的 TCP 連接，也就是說復(fù)用的是 TCP 連接。即長連接情況下，多個(gè) HTTP 請求
可以復(fù)用同一個(gè) TCP 連接，這就節(jié)省了很多 TCP 連接建立和斷開的消耗。
此外，長連接并不是永久連接的。如果一段時(shí)間內(nèi)（具體的時(shí)間長短，是可以在 header 當(dāng)
中進(jìn)行設(shè)置的，也就是所謂的超時(shí)時(shí)間），這個(gè)連接沒有 HTTP 請求發(fā)出的話，那么這個(gè)長
連接就會(huì)被斷掉。
需要更深的理解請點(diǎn)擊這里
7、Https 加密原理。 加密算法的類型基本上分為了兩種：
? 對稱加密，加密用的密鑰和解密用的密鑰是同一個(gè)，比較有代表性的就是 AES 加
密算法；
? 非對稱加密，加密用的密鑰稱為公鑰，解密用的密鑰稱為私鑰，經(jīng)常使用到的 RSA
加密算法就是非對稱加密的；
此外，還有 Hash 加密算法
HASH 算法：MD5, SHA1, SHA256
相比較對稱加密而言，非對稱加密安全性更高，但是加解密耗費(fèi)的時(shí)間更長，速度慢。
想了解更多加密算法請點(diǎn)擊這里
HTTPS = HTTP + SSL，HTTPS 的加密就是在 SSL 中完成的。
這就要從 CA 證書講起了。CA 證書其實(shí)就是數(shù)字證書，是由 CA 機(jī)構(gòu)頒發(fā)的。至于 CA 機(jī)
構(gòu)的權(quán)威性，那么是毋庸置疑的，所有人都是信任它的。CA 證書內(nèi)一般會(huì)包含以下內(nèi)容：
? 證書的頒發(fā)機(jī)構(gòu)、版本
? 證書的使用者
? 證書的公鑰
? 證書的有效時(shí)間
? 證書的數(shù)字簽名 Hash 值和簽名 Hash 算法
? ... 客戶端如何校驗(yàn) CA 證書？
CA 證書中的 Hash 值，其實(shí)是用證書的私鑰進(jìn)行加密后的值（證書的私鑰不在 CA 證書
中）。然后客戶端得到證書后，利用證書中的公鑰去解密該 Hash 值，得到 Hash-a ；然
后再利用證書內(nèi)的簽名 Hash 算法去生成一個(gè) Hash-b 。最后比較 Hash-a 和 Hash-b 這
兩個(gè)的值。如果相等，那么證明了該證書是對的，服務(wù)端是可以被信任的；如果不相等，那
么就說明該證書是錯(cuò)誤的，可能被篡改了，瀏覽器會(huì)給出相關(guān)提示，無法建立起 HTTPS 連
接。除此之外，還會(huì)校驗(yàn) CA 證書的有效時(shí)間和域名匹配等。
HTTPS 中的 SSL 握手建立過程
假設(shè)現(xiàn)在有客戶端 A 和服務(wù)器 B ：
? 1 、 首 先 ， 客 戶 端 A 訪 問 服 務(wù) 器 B ， 比 如 我 們 用 瀏 覽 器 打 開 一 個(gè) 網(wǎng)
頁 www.baidu.com ，這時(shí)，瀏覽器就是客戶端 A ，百度的服務(wù)器就是服務(wù)器 B 了。
這時(shí)候客戶端 A 會(huì)生成一個(gè)隨機(jī)數(shù) 1，把隨機(jī)數(shù) 1 、自己支持的 SSL 版本號以及
加密算法等這些信息告訴服務(wù)器 B 。
? 2、服務(wù)器 B 知道這些信息后，然后確認(rèn)一下雙方的加密算法，然后服務(wù)端也生成
一個(gè)隨機(jī)數(shù) B ，并將隨機(jī)數(shù) B 和 CA 頒發(fā)給自己的證書一同返回給客戶端 A 。
? 3、客戶端 A 得到 CA 證書后，會(huì)去校驗(yàn)該 CA 證書的有效性，校驗(yàn)方法在上面
已經(jīng)說過了。校驗(yàn)通過后，客戶端生成一個(gè)隨機(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，然后雙方利
用這三個(gè)隨機(jī)數(shù)生成一個(gè)對話密鑰。之后傳輸內(nèi)容就是利用對話密鑰來進(jìn)行加解密
了。這時(shí)就是利用了對稱加密，一般用的都是 AES 算法。
? 6、客戶端 A 通知服務(wù)端 B ，指明后面的通訊用對話密鑰來完成，同時(shí)通知服務(wù)
器 B 客戶端 A 的握手過程結(jié)束。
? 7、服務(wù)端 B 通知客戶端 A，指明后面的通訊用對話密鑰來完成，同時(shí)通知客戶端
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、互相傳遞三個(gè)隨機(jī)數(shù)，之后通過這隨機(jī)數(shù)來生成一個(gè)密鑰；
? 3、互相確認(rèn)密鑰，然后握手結(jié)束；
? 4、數(shù)據(jù)通訊開始，都使用同一個(gè)對話密鑰來加解密；
可以發(fā)現(xiàn)，在 HTTPS 加密原理的過程中把對稱加密和非對稱加密都利用了起來。即利用了
非對稱加密安全性高的特點(diǎn)，又利用了對稱加密速度快，效率高的好處。
需要更深的理解請點(diǎn)擊這里
8、HTTPS 如何防范中間人攻擊？
什么是中間人攻擊？
當(dāng)數(shù)據(jù)傳輸發(fā)生在一個(gè)設(shè)備（PC/手機(jī)）和網(wǎng)絡(luò)服務(wù)器之間時(shí)，攻擊者使用其技能和工具將
自己置于兩個(gè)端點(diǎn)之間并截獲數(shù)據(jù)；盡管交談的兩方認(rèn)為他們是在與對方交談，但是實(shí)際上
他們是在與干壞事的人交流，這便是中間人攻擊。
有幾種攻擊方式？
1、嗅探：嗅探或數(shù)據(jù)包嗅探是一種用于捕獲流進(jìn)和流出系統(tǒng)/網(wǎng)絡(luò)的數(shù)據(jù)包的技術(shù)。
網(wǎng)絡(luò)中的數(shù)據(jù)包嗅探就好像電話中的監(jiān)聽。
2、數(shù)據(jù)包注入： 在這種技術(shù)中，攻擊者會(huì)將惡意數(shù)據(jù)包注入常規(guī)數(shù)據(jù)中。這樣用
戶便不會(huì)注意到文件/惡意軟件，因?yàn)樗鼈兪呛戏ㄍㄓ嵙鞯囊徊糠帧?br> 3、會(huì)話劫持： 在你登錄進(jìn)你的銀行賬戶和退出登錄這一段期間便稱為一個(gè)會(huì)話。
這些會(huì)話通常都是黑客的攻擊目標(biāo)，因?yàn)樗鼈儼瑵撛诘闹匾畔?。在大多?shù)案例
中，黑客會(huì)潛伏在會(huì)話中，并最終控制它。
4、SSL 剝離： 在 SSL 剝離攻擊中，攻擊者使 SSL/TLS 連接剝落，隨之協(xié)議便從安
全的 HTTPS 變成了不安全的 HTTP。
HTTPS 如何防范中間人攻擊：
請見 https 加密原理。
9、有哪些響應(yīng)碼，分別都代表什么意思？
1* 信息，服務(wù)器收到請求，需要請求者繼續(xù)執(zhí)行操作
2** 成功，操作被成功接收并處理
3** 重定向，需要進(jìn)一步的操作以完成請求
4** 客戶端錯(cuò)誤，請求包含語法錯(cuò)誤或無法完成請求
5** 服務(wù)器錯(cuò)誤，服務(wù)器在處理請求的過程中發(fā)生了錯(cuò)誤
二、TCP/UDP （???）
1、為什么 tcp 要經(jīng)過三次握手，四次揮手？
重要標(biāo)志位
ACK ： TCP 協(xié)議規(guī)定，只有 ACK=1 時(shí)有效，也規(guī)定連接建立后所有發(fā)送的報(bào)文的 ACK 必
須為 1
SYN(SYNchronization) ： 在連接建立時(shí)用來同步序號。當(dāng) SYN=1 而 ACK=0 時(shí)，表明這是
一個(gè)連接請求報(bào)文。對方若同意建立連接，則應(yīng)在響應(yīng)報(bào)文中使SYN=1和ACK=1. 因此, SYN
置 1 就表示這是一個(gè)連接請求或連接接受報(bào)文。
FIN （finis）即完，終結(jié)的意思， 用來釋放一個(gè)連接。當(dāng) FIN = 1 時(shí)，表明此報(bào)文段的發(fā)
送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并要求釋放連接。
三次握手、四次揮手過程
三次握手：
第一次握手：建立連接。客戶端發(fā)送連接請求報(bào)文段，將 SYN 位置為 1，Sequence Number
為 x；然后，客戶端進(jìn)入 SYN_SEND 狀態(tài)，等待服務(wù)器的確認(rèn)；
第二次握手：服務(wù)器收到 SYN 報(bào)文段。服務(wù)器收到客戶端的 SYN 報(bào)文段，需要對這個(gè) SYN
報(bào)文段進(jìn)行確認(rèn)，設(shè)置 Acknowledgment Number 為 x+1(Sequence Number+1)；同時(shí)，
自己自己還要發(fā)送 SYN 請求信息，將 SYN 位置為 1，Sequence Number 為 y；服務(wù)器端將
上述所有信息放到一個(gè)報(bào)文段（即 SYN+ACK 報(bào)文段）中，一并發(fā)送給客戶端，此時(shí)服務(wù)器
進(jìn)入 SYN_RECV 狀態(tài)；
第三次握手：客戶端收到服務(wù)器的 SYN+ACK 報(bào)文段。然后將 Acknowledgment Number
設(shè)置為 y+1，向服務(wù)器發(fā)送 ACK 報(bào)文段，這個(gè)報(bào)文段發(fā)送完畢以后，客戶端和服務(wù)器端都
進(jìn)入 ESTABLISHED 狀態(tài)，完成 TCP 三次握手。
四次揮手：
第一次分手：主機(jī) 1（可以使客戶端，也可以是服務(wù)器端），設(shè)置 Sequence Number 和
Acknowledgment Number，向主機(jī) 2 發(fā)送一個(gè) FIN 報(bào)文段；此時(shí)，主機(jī) 1 進(jìn)入 FIN_WAIT_1
狀態(tài)；這表示主機(jī) 1 沒有數(shù)據(jù)要發(fā)送給主機(jī) 2 了；
第二次分手：主機(jī) 2 收到了主機(jī) 1 發(fā)送的 FIN 報(bào)文段，向主機(jī) 1 回一個(gè) ACK 報(bào)文段，
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 報(bào)文段，請求關(guān)閉連接，同時(shí)主機(jī) 2 進(jìn)入 LAST_ACK
狀態(tài)；
第四次分手：主機(jī) 1 收到主機(jī) 2 發(fā)送的 FIN 報(bào)文段，向主機(jī) 2 發(fā)送 ACK 報(bào)文段，然后主機(jī)
1 進(jìn)入 TIME_WAIT 狀態(tài)；主機(jī) 2 收到主機(jī) 1 的 ACK 報(bào)文段以后，就關(guān)閉連接；此時(shí)，主機(jī)
1 等待 2MSL 后依然沒有收到回復(fù)，則證明 Server 端已正常關(guān)閉，那好，主機(jī) 1 也可以關(guān)閉
連接了。
“三次握手”的目的是“為了防止已失效的連接請求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生
錯(cuò)誤”。主要目的防止 server 端一直等待，浪費(fèi)資源。換句話說，即是為了保證服務(wù)端能收
接受到客戶端的信息并能做出正確的應(yīng)答而進(jìn)行前兩次(第一次和第二次)握手，為了保證客
戶端能夠接收到服務(wù)端的信息并能做出正確的應(yīng)答而進(jìn)行后兩次(第二次和第三次)握手。
“四次揮手”原因是因?yàn)?tcp 是全雙工模式，接收到 FIN 時(shí)意味將沒有數(shù)據(jù)再發(fā)來，但是還是
可以繼續(xù)發(fā)送數(shù)據(jù)。
2、TCP 可靠傳輸原理實(shí)現(xiàn)（滑動(dòng)窗口）。
確認(rèn)和重傳：接收方收到報(bào)文后就會(huì)進(jìn)行確認(rèn)，發(fā)送方一段時(shí)間沒有收到確認(rèn)就會(huì)重傳。
數(shù)據(jù)校驗(yàn)。
數(shù)據(jù)合理分片與排序，TCP 會(huì)對數(shù)據(jù)進(jìn)行分片，接收方會(huì)緩存為按序到達(dá)的數(shù)據(jù)，重新排序
后再提交給應(yīng)用層。
流程控制：當(dāng)接收方來不及接收發(fā)送的數(shù)據(jù)時(shí)，則會(huì)提示發(fā)送方降低發(fā)送的速度，防止包丟
失。
擁塞控制：當(dāng)網(wǎng)絡(luò)發(fā)生擁塞時(shí)，減少數(shù)據(jù)的發(fā)送。
關(guān)于滑動(dòng)窗口、流量控制、擁塞控制實(shí)現(xiàn)原理請點(diǎn)擊這里
3、Tcp 和 Udp 的區(qū)別？
1、基于連接與無連接；
2、對系統(tǒng)資源的要求（TCP 較多，UDP 少）；
3、UDP 程序結(jié)構(gòu)較簡單；
4、流模式與數(shù)據(jù)報(bào)模式 ；
5、TCP 保證數(shù)據(jù)正確性，UDP 可能丟包；
6、TCP 保證數(shù)據(jù)順序，UDP 不保證。
4、如何設(shè)計(jì)在 UDP 上層保證 UDP 的可靠性傳輸？
傳輸層無法保證數(shù)據(jù)的可靠傳輸，只能通過應(yīng)用層來實(shí)現(xiàn)了。實(shí)現(xiàn)的方式可以參照 tcp 可靠
性傳輸?shù)姆绞?。如不考慮擁塞處理，可靠 UDP 的簡單設(shè)計(jì)如下：
? 1、添加 seq/ack 機(jī)制，確保數(shù)據(jù)發(fā)送到對端
? 2、添加發(fā)送和接收緩沖區(qū)，主要是用戶超時(shí)重傳。
? 3、添加超時(shí)重傳機(jī)制。
具體過程即是：送端發(fā)送數(shù)據(jù)時(shí)，生成一個(gè)隨機(jī) seq=x，然后每一片按照數(shù)據(jù)大小分配 seq。
數(shù)據(jù)到達(dá)接收端后接收端放入緩存，并發(fā)送一個(gè) ack=x 的包，表示對方已經(jīng)收到了數(shù)據(jù)。
發(fā)送端收到了 ack 包后，刪除緩沖區(qū)對應(yīng)的數(shù)據(jù)。時(shí)間到后，定時(shí)任務(wù)檢查是否需要重傳數(shù)
據(jù)。
目前有如下開源程序利用 udp 實(shí)現(xiàn)了可靠的數(shù)據(jù)傳輸。分別為 RUDP、RTP、UDT:
1、RUDP（Reliable User Datagram Protocol）
RUDP 提供一組數(shù)據(jù)服務(wù)質(zhì)量增強(qiáng)機(jī)制，如擁塞控制的改進(jìn)、重發(fā)機(jī)制及淡化服務(wù)器算法等。
2、RTP（Real Time Protocol）
RTP 為數(shù)據(jù)提供了具有實(shí)時(shí)特征的端對端傳送服務(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 斷線重連怎么實(shí)現(xiàn)，心跳機(jī)制又是怎樣實(shí)現(xiàn)？
socket 概念
套接字（socket）是通信的基石，是支持 TCP/IP 協(xié)議的網(wǎng)絡(luò)通信的基本操作單元。它是網(wǎng)
絡(luò)通信過程中端點(diǎn)的抽象表示，包含進(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ì)算機(jī)操作系統(tǒng)為應(yīng)用程序與 TCP／IP 協(xié)議交互
提供了套接字(Socket)接口。應(yīng) 用層可以和傳輸層通過 Socket 接口，區(qū)分來自不同應(yīng)用程
序進(jìn)程或網(wǎng)絡(luò)連接的通信，實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù)。
建立 socket 連接
建立 Socket 連接至少需要一對套接字，其中一個(gè)運(yùn)行于客戶端，稱為 ClientSocket ，另一
個(gè)運(yùn)行于服務(wù)器端，稱為 ServerSocket 。
套接字之間的連接過程分為三個(gè)步驟：服務(wù)器監(jiān)聽，客戶端請求，連接確認(rèn)。
? 服務(wù)器監(jiān)聽：服務(wù)器端套接字并不定位具體的客戶端套接字，而是處于等待連接的
狀態(tài)，實(shí)時(shí)監(jiān)控網(wǎng)絡(luò)狀態(tài)，等待客戶端的連接請求。
? 客戶端請求：指客戶端的套接字提出連接請求，要連接的目標(biāo)是服務(wù)器端的套接字。
為此，客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字，指出服務(wù)器端- - 套接字的地址和端口號，然后就向服務(wù)器端套接字提出連接請求。 連接確認(rèn)：當(dāng)服
務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時(shí)，就響應(yīng)客戶端套接
字的請求，建立一個(gè)新的線程，把服務(wù)器端套接字的描述發(fā) 給客戶端，一旦客戶端
確認(rèn)了此描述，雙方就正式建立連接。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽狀態(tài)，繼續(xù)
接收其他客戶端套接字的連接請求。
SOCKET 連接與 TCP 連接
創(chuàng)建 Socket 連接時(shí)，可以指定使用的傳輸層協(xié)議，Socket 可以支持不同的傳輸層協(xié)議（TCP
或 UDP），當(dāng)使用 TCP 協(xié)議進(jìn)行連接時(shí)，該 Socket 連接就是一個(gè) TCP 連接。
Socket 連接與 HTTP 連接
由于通常情況下 Socket 連接就是 TCP 連接，因此 Socket 連接一旦建立，通信雙方即可開
始相互發(fā)送數(shù)據(jù)內(nèi)容，直到雙方連接斷開。但在實(shí)際網(wǎng) 絡(luò)應(yīng)用中，客戶端到服務(wù)器之間的
通信往往需要穿越多個(gè)中間節(jié)點(diǎn)，例如路由器、網(wǎng)關(guān)、防火墻等，大部分防火墻默認(rèn)會(huì)關(guān)閉
長時(shí)間處于非活躍狀態(tài)的連接而導(dǎo)致 Socket 連接斷連，因此需要通過輪詢告訴網(wǎng)絡(luò)，該連
接處于活躍狀態(tài)。
而 HTTP 連接使用的是“請求—響應(yīng)”的方式，不僅在請求時(shí)需要先建立連接，而且需要客戶
端向服務(wù)器發(fā)出請求后，服務(wù)器端才能回復(fù)數(shù)據(jù)。
很多情況下，需要服務(wù)器端主動(dòng)向客戶端推送數(shù)據(jù)，保持客戶端與服務(wù)器數(shù)據(jù)的實(shí)時(shí)與同步。
此時(shí)若雙方建立的是 Socket 連接，服務(wù)器就可以直接將數(shù) 據(jù)傳送給客戶端；若雙方建立的
是 HTTP 連接，則服務(wù)器需要等到客戶端發(fā)送一次請求后才能將數(shù)據(jù)傳回給客戶端，因此，
客戶端定時(shí)向服務(wù)器端發(fā)送連接請求， 不僅可以保持在線，同時(shí)也是在“詢問”服務(wù)器是否
有新的數(shù)據(jù)，如果有就將數(shù)據(jù)傳給客戶端。TCP(Transmission Control Protocol) 傳輸控制
協(xié)議
socket 斷線重連實(shí)現(xiàn)
正常連接斷開客戶端會(huì)給服務(wù)端發(fā)送一個(gè) fin 包，服務(wù)端收到 fin 包后才會(huì)知道連接斷開。而
斷網(wǎng)斷電時(shí)客戶端無法發(fā)送 fin 包給服務(wù)端，所以服務(wù)端沒辦法檢測到客戶端已經(jīng)短線。 為
了緩解這個(gè)問題，服務(wù)端需要有個(gè)心跳邏輯，就是服務(wù)端檢測到某個(gè)客戶端多久沒發(fā)送任何
數(shù)據(jù)過來就認(rèn)為客戶端已經(jīng)斷開， 這需要客戶端定時(shí)向服務(wù)端發(fā)送心跳數(shù)據(jù)維持連接。
心跳機(jī)制實(shí)現(xiàn)
長連接的實(shí)現(xiàn)：心跳機(jī)制，應(yīng)用層協(xié)議大多都有 HeartBeat 機(jī)制，通常是客戶端每隔一小段
時(shí)間向服務(wù)器發(fā)送一個(gè)數(shù)據(jù)包，通知服務(wù)器自己仍然在線。并傳輸一些可能必要的數(shù)據(jù)。使
用心跳包的典型協(xié)議是 IM，比如 QQ/MSN/飛信等協(xié)議
1、在 TCP 的機(jī)制里面，本身是存在有心跳包的機(jī)制的，也就是 TCP 的選項(xiàng)：SO_KEEPALIVE。
系統(tǒng)默認(rèn)是設(shè)置的 2 小時(shí)的心跳頻率。但是它檢查不到機(jī)器斷電、網(wǎng)線拔出、防火墻這些斷
線。 而且邏輯層處理斷線可能也不是那么好處理。一般，如果只是用于?；钸€是可以的。
通過使用 TCP 的 KeepAlive 機(jī)制（修改那個(gè) time 參數(shù)），可以讓連接每隔一小段時(shí)間就產(chǎn)
生一些 ack 包，以降低被踢掉的風(fēng)險(xiǎn)，當(dāng)然，這樣的代價(jià)是額外的網(wǎng)絡(luò)和 CPU 負(fù)擔(dān)。
2、應(yīng)用層心跳機(jī)制實(shí)現(xiàn)。
2、Cookie 與 Session 的作用和原理。
? Session 是在服務(wù)端保存的一個(gè)數(shù)據(jù)結(jié)構(gòu)，用來跟蹤用戶的狀態(tài)，這個(gè)數(shù)據(jù)可以保存
在集群、數(shù)據(jù)庫、文件中。
? Cookie 是客戶端保存用戶信息的一種機(jī)制，用來記錄用戶的一些信息，也是實(shí)現(xiàn)
Session 的一種方式。
Session： 由于 HTTP 協(xié)議是無狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶的狀態(tài)時(shí)，就需要用某種機(jī)制來
識具體的用戶，這個(gè)機(jī)制就是 Session.典型的場景比如購物車，當(dāng)你點(diǎn)擊下單按鈕時(shí)，由于
HTTP 協(xié)議無狀態(tài)，所以并不知道是哪個(gè)用戶操作的，所以服務(wù)端要為特定的用戶創(chuàng)建了特
定的 Session，用用于標(biāo)識這個(gè)用戶，并且跟蹤用戶，這樣才知道購物車?yán)锩嬗袔妆緯?。這
個(gè) Session 是保存在服務(wù)端的，有一個(gè)唯一標(biāo)識。在服務(wù)端保存 Session 的方法很多，內(nèi)存、
數(shù)據(jù)庫、文件都有。集群的時(shí)候也要考慮 Session 的轉(zhuǎn)移，在大型的網(wǎng)站，一般會(huì)有專門的
Session 服務(wù)器集群，用來保存用戶會(huì)話，這個(gè)時(shí)候 Session 信息都是放在內(nèi)存的。
具體到 Web 中的 Session 指的就是用戶在瀏覽某個(gè)網(wǎng)站時(shí)，從進(jìn)入網(wǎng)站到瀏覽器關(guān)閉所經(jīng)
過的這段時(shí)間，也就是用戶瀏覽這個(gè)網(wǎng)站所花費(fèi)的時(shí)間。因此從上述的定義中我們可以看到，
Session 實(shí)際上是一個(gè)特定的時(shí)間概念。
當(dāng)客戶端訪問服務(wù)器時(shí)，服務(wù)器根據(jù)需求設(shè)置 Session，將會(huì)話信息保存在服務(wù)器上，同時(shí)
將標(biāo)示 Session 的 SessionId 傳遞給客戶端瀏覽器，
瀏覽器將這個(gè) SessionId 保存在內(nèi)存中，我們稱之為無過期時(shí)間的 Cookie。瀏覽器關(guān)閉后，
這個(gè) Cookie 就會(huì)被清掉，它不會(huì)存在于用戶的 Cookie 臨時(shí)文件。
以后瀏覽器每次請求都會(huì)額外加上這個(gè)參數(shù)值，服務(wù)器會(huì)根據(jù)這個(gè) SessionId，就能取得客
戶端的數(shù)據(jù)信息。
如果客戶端瀏覽器意外關(guān)閉，服務(wù)器保存的 Session 數(shù)據(jù)不是立即釋放，此時(shí)數(shù)據(jù)還會(huì)存在，
只要我們知道那個(gè) SessionId,就可以繼續(xù)通過請求獲得此 Session 的信息，因?yàn)榇藭r(shí)后臺的
Session 還存在，當(dāng)然我們可以設(shè)置一個(gè) Session 超時(shí)時(shí)間，一旦超過規(guī)定時(shí)間沒有客戶端
請求時(shí)，服務(wù)器就會(huì)清除對應(yīng) SessionId 的 Session 信息。
Cookie Cookie 是由服務(wù)器端生成，發(fā)送給 User-Agent（一般是 web 瀏覽器），瀏覽器會(huì)將 Cookie
的 key/value 保存到某個(gè)目錄下的文本文件內(nèi)，下次請求同一網(wǎng)站時(shí)就發(fā)送該 Cookie 給服
務(wù)器（前提是瀏覽器設(shè)置為啟用 Cookie）。Cookie 名稱和值可以由服務(wù)器端開發(fā)自己定義，
對于 JSP 而言也可以直接寫入 Sessionid，這樣服務(wù)器可以知道該用戶是否合法用戶以及是
否需要重新登錄等。
3、IP 報(bào)文中的內(nèi)容。
版本：IP 協(xié)議的版本，目前的 IP 協(xié)議版本號為 4，下一代 IP 協(xié)議版本號為 6。
首部長度：IP 報(bào)頭的長度。固定部分的長度（20 字節(jié)）和可變部分的長度之和。共占 4 位。
最大為 1111，即 10 進(jìn)制的 15，代表 IP 報(bào)頭的最大長度可以為 15 個(gè) 32bits（4 字節(jié)），也
就是最長可為 15*4=60 字節(jié)，除去固定部分的長度 20 字節(jié)，可變部分的長度最大為 40 字
節(jié)。
服務(wù)類型：Type Of Service。
總長度：IP 報(bào)文的總長度。報(bào)頭的長度和數(shù)據(jù)部分的長度之和。
標(biāo)識：唯一的標(biāo)識主機(jī)發(fā)送的每一分?jǐn)?shù)據(jù)報(bào)。通常每發(fā)送一個(gè)報(bào)文，它的值加一。當(dāng) IP 報(bào)
文長度超過傳輸網(wǎng)絡(luò)的 MTU（最大傳輸單元）時(shí)必須分片，這個(gè)標(biāo)識字段的值被復(fù)制到所
有數(shù)據(jù)分片的標(biāo)識字段中，使得這些分片在達(dá)到最終目的地時(shí)可以依照標(biāo)識字段的內(nèi)容重新
組成原先的數(shù)據(jù)。
標(biāo)志：共 3 位。R、DF、MF 三位。目前只有后兩位有效，DF 位：為 1 表示不分片，為 0
表示分片。MF：為 1 表示“更多的片”，為 0 表示這是最后一片。
片位移：本分片在原先數(shù)據(jù)報(bào)文中相對首位的偏移位。（需要再乘以 8）
生存時(shí)間：IP 報(bào)文所允許通過的路由器的最大數(shù)量。每經(jīng)過一個(gè)路由器，TTL 減 1，當(dāng)為 0
時(shí)，路由器將該數(shù)據(jù)報(bào)丟棄。TTL 字段是由發(fā)送端初始設(shè)置一個(gè) 8 bit 字段.推薦的初始值由
分配數(shù)字 RFC 指定，當(dāng)前值為 64。發(fā)送 ICMP 回顯應(yīng)答時(shí)經(jīng)常把 TTL 設(shè)為最大值 255。
協(xié)議：指出 IP 報(bào)文攜帶的數(shù)據(jù)使用的是那種協(xié)議，以便目的主機(jī)的 IP 層能知道要將數(shù)據(jù)報(bào)
上交到哪個(gè)進(jìn)程（不同的協(xié)議有專門不同的進(jìn)程處理）。和端口號類似，此處采用協(xié)議號，
TCP 的協(xié)議號為 6，UDP 的協(xié)議號為 17。ICMP 的協(xié)議號為 1，IGMP 的協(xié)議號為 2. 首部校驗(yàn)和：計(jì)算 IP 頭部的校驗(yàn)和，檢查 IP 報(bào)頭的完整性。
源 IP 地址：標(biāo)識 IP 數(shù)據(jù)報(bào)的源端設(shè)備。
目的 IP 地址：標(biāo)識 IP 數(shù)據(jù)報(bào)的目的地址。
最后就是可變部分和數(shù)據(jù)部分。 四、常見網(wǎng)絡(luò)流程機(jī)制 （??）
1、瀏覽器輸入地址到返回結(jié)果發(fā)生了什么？
總體來說分為以下幾個(gè)過程:
1、DNS 解析，此外還有 DNSy 優(yōu)化（DNS 緩存、DNS 負(fù)載均衡）
2、TCP 連接
3、發(fā)送 HTTP 請求
4、服務(wù)器處理請求并返回 HTTP 報(bào)文
5、瀏覽器解析渲染頁面
6、連接結(jié)束
Web 前端的本質(zhì)
將信息快速并友好的展示給用戶并能夠與用戶進(jìn)行交互。
如何盡快的加載資源（網(wǎng)絡(luò)優(yōu)化）？
答案就是能不從網(wǎng)絡(luò)中加載的資源就不從網(wǎng)絡(luò)中加載，當(dāng)我們合理使用緩存，將資源放在瀏
覽器端，這是最快的方式。如果資源必須從網(wǎng)絡(luò)中加載，則要考慮縮短連接時(shí)間，即 DNS
優(yōu)化部分;減少響應(yīng)內(nèi)容大小，即對內(nèi)容進(jìn)行壓縮。另一方面，如果加載的資源數(shù)比較少的
話，也可以快速的響應(yīng)用戶。