一、TCP/IP協(xié)議

作為一個(gè)小萌新，當(dāng)然我無法將tcp/ip協(xié)議的大部分江山和盤托出，但是其中很多面試可能問到的知識(shí)，我覺得有必要總結(jié)一下！
首先，在學(xué)習(xí)tcp/ip協(xié)議之前，我們必須搞明白什么是tcp/ip協(xié)議。

1、什么是tcp/ip協(xié)議

書本上的定義：網(wǎng)絡(luò)協(xié)議是為計(jì)算機(jī)網(wǎng)絡(luò)中進(jìn)行數(shù)據(jù)交換而建立的規(guī)則、標(biāo)準(zhǔn)或約定的集合。

比如：中國(guó)人之間交流使用漢語，要遵循漢語的語法結(jié)構(gòu)和發(fā)音；那如果我們跟英國(guó)人交流的話，就要使用英語的語法結(jié)構(gòu)和發(fā)音；人與人之間交流所用的語言就是一種協(xié)議。對(duì)于計(jì)算機(jī)來說，兩臺(tái)機(jī)器之間的通信就要制定各種各樣的協(xié)議，例如：文件傳輸使用TCP協(xié)議，域名系統(tǒng)使用DNS協(xié)議。數(shù)據(jù)根據(jù)協(xié)議規(guī)定的內(nèi)容進(jìn)行傳輸，這樣就實(shí)現(xiàn)了兩臺(tái)機(jī)器之間的通信。

總的來說：網(wǎng)絡(luò)協(xié)議就是人為規(guī)定的一套通信規(guī)范，只要雙方都遵循這個(gè)規(guī)范，就能實(shí)現(xiàn)交流。
TCP/IP具體含義：從字面意義上講，可能會(huì)認(rèn)為 TCP/IP 是指 TCP 和 IP 兩種協(xié)議。然而多數(shù)情況下，它只是利用ip進(jìn)行通信時(shí)所必須用到的協(xié)議群的統(tǒng)稱。具體來說，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都屬于 TCP/IP 協(xié)議。他們與 TCP 或 IP 的關(guān)系緊密，是互聯(lián)網(wǎng)必不可少的組成部分。TCP/IP 一詞泛指這些協(xié)議，因此，有時(shí)也稱 TCP/IP 為網(wǎng)際協(xié)議群。

2、tcp/ip協(xié)議的分層

TCP/IP協(xié)議族中有一個(gè)重要的概念是分層，提到協(xié)議分層，通常會(huì)聯(lián)想到OSI的七層協(xié)議經(jīng)典架構(gòu)，但是TCP/IP協(xié)議族的結(jié)構(gòu)則稍有不同，但是二者之間有一定聯(lián)系，如圖所示：

tcp/ip協(xié)議分為“應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層”。

2.1、應(yīng)用層

顧名思義，應(yīng)用層就是我們應(yīng)用和接觸最多的層，我們最常寫的Java程序，甚至QQ微信都是應(yīng)用層的產(chǎn)物。
應(yīng)用層決定這次通信的應(yīng)用類型，比如說FTP、DNS、SMTP等等，同時(shí)HTTP協(xié)議也屬于應(yīng)用層的范圍。通俗來講，應(yīng)用層決定這一次通信要干嘛。

2.2、傳輸層

應(yīng)用層把數(shù)據(jù)丟給傳輸層后，傳輸層把數(shù)據(jù)進(jìn)行一下包裝，包裝紙上面寫著“源端口、目的端口、序號(hào)、確認(rèn)序號(hào)、檢驗(yàn)和等TCP自身的數(shù)據(jù)，
傳輸層提供兩臺(tái)計(jì)算機(jī)之間的數(shù)據(jù)傳輸，傳輸層中包含著兩個(gè)很吊的協(xié)議，分別是TCP和UDP協(xié)議，而且沒有第三種協(xié)議可走。
TCP和UDP協(xié)議的區(qū)別

1、基于連接（TCP）與無連接(UDP)。 2、TCP要求系統(tǒng)資源較多，UDP較少。 3、UDP程序結(jié)構(gòu)較簡(jiǎn)單。
4、流模式（TCP）與數(shù)據(jù)報(bào)模式(UDP)。 5、TCP保證數(shù)據(jù)正確性，UDP可能丟包。 6、TCP保證數(shù)據(jù)順序，UDP不保證。
7、TCP面向連接（如打電話要先撥號(hào)建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
8、TCP提供可靠的服務(wù)。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯(cuò)，不丟失，不重復(fù)，且按序到達(dá);UDP盡最大努力交付，即不保證可靠交付。
9、TCP面向字節(jié)流，實(shí)際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;UDP是面向報(bào)文的，沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低（對(duì)實(shí)時(shí)應(yīng)用很有用，如IP電話，實(shí)時(shí)視頻會(huì)議等）。
10、每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信。
11、TCP首部開銷20字節(jié);UDP的首部開銷小，只有8個(gè)字節(jié)。 12、TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道。

此外，面試中經(jīng)常提及的三次握手，四次揮手就是TCP協(xié)議的部分內(nèi)容 。

三次握手，四次揮手
TCP有6種標(biāo)志符

	1、SYN(synchronous),建立聯(lián)機(jī)2、ACK(acknowledgement),確認(rèn)3、PSH(push),傳輸4、FIN(finish),結(jié)束5、RST(reset),重置6、URG(urgent),緊急

1、三次握手：

概念：指在發(fā)送數(shù)據(jù)的準(zhǔn)備階段，服務(wù)器和客戶端之間需要三次交互

第一次握手：建立連接時(shí)，客戶端向服務(wù)器發(fā)送一個(gè)SYN包，并進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器確認(rèn)

第二次握手：當(dāng)服務(wù)器收到客戶端的請(qǐng)求后，此時(shí)要給客戶端給一個(gè)確認(rèn)信息ACK,同時(shí)發(fā)送SYN包，此時(shí)服務(wù)器進(jìn)入 SYN_RECV狀態(tài)

第三次握手：客戶端收到服務(wù)器發(fā)的ACK+SYN包后，向服務(wù)器發(fā)送ACK,發(fā)送完畢之后，客戶端和服務(wù)器進(jìn)入
ESTABLISHED(TCP連接成功)狀態(tài)，完成三次握手

2、四次揮手
概念：所謂四次揮手就是說關(guān)閉TCP連接的過程，當(dāng)斷開一個(gè)TCP連接時(shí)，需要客戶端和服務(wù)器共發(fā)送四個(gè)包確認(rèn)

第一次揮手：客戶端發(fā)送一個(gè)FIN,用來關(guān)閉客戶端到服務(wù)器的數(shù)據(jù)傳輸，客戶端進(jìn)入FIN_WAIT_1狀態(tài)

第二次揮手：服務(wù)器收到FIN后，發(fā)送一個(gè)ACK給客戶端，確認(rèn)序號(hào)為收到序號(hào)+1（與SYN相同，一個(gè)FIN占用一個(gè)序號(hào)），服務(wù)器進(jìn)入CLOSE_WAIT狀態(tài)

第三次揮手：服務(wù)器發(fā)送一個(gè)FIN,用來關(guān)閉服務(wù)器到客戶端的數(shù)據(jù)傳輸，服務(wù)器進(jìn)入LAST_ACK狀態(tài)

第四次揮手：客戶端收到FIN后，客戶端進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個(gè)AKC給服務(wù)器，確認(rèn)序號(hào)為收到序號(hào)+1，服務(wù)器進(jìn)入CLOSED狀態(tài)，完成四次揮手

TCP四次揮手過程中通信雙方狀態(tài)解析：

FIN_WAIT_1:?其實(shí)FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對(duì)方的FIN報(bào)文。而這兩種狀態(tài)的區(qū)別是：

1. FIN_WAIT_1狀態(tài)：實(shí)際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時(shí)，它想主動(dòng)關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報(bào)文，此時(shí)該SOCKET即進(jìn)入到FIN_WAIT_1狀態(tài)。而當(dāng)對(duì)方回應(yīng)ACK報(bào)文后，則進(jìn)入到FIN_WAIT_2狀態(tài)，當(dāng)然在實(shí)際的正常情況下，無論對(duì)方何種情況下，都應(yīng)該馬上回應(yīng)ACK報(bào)文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的，而FIN_WAIT_2狀態(tài)還有時(shí)常?？梢杂胣etstat看到。（主動(dòng)方）
2. FIN_WAIT_2：實(shí)際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對(duì)方，我暫時(shí)還有點(diǎn)數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關(guān)閉連接。（主動(dòng)方）

CLOSE_WAIT:表示在等待關(guān)閉。當(dāng)對(duì)方close一個(gè)SOCKET后發(fā)送FIN報(bào)文給自己，你系統(tǒng)毫無疑問地會(huì)回應(yīng)一個(gè)ACK報(bào)文給對(duì)方，此時(shí)則進(jìn)入到CLOSE_WAIT狀態(tài)。接下來呢，實(shí)際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對(duì)方，如果沒有的話，那么你也就可以 close這個(gè)SOCKET，發(fā)送FIN報(bào)文給對(duì)方，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接。（被動(dòng)方）

LAST_ACK:?被動(dòng)關(guān)閉一方在發(fā)送FIN報(bào)文后，最后等待對(duì)方的ACK報(bào)文。當(dāng)收到ACK報(bào)文后，也即可以進(jìn)入到CLOSED可用狀態(tài)了。（被動(dòng)方）

TIME_WAIT:?表示收到了對(duì)方的FIN報(bào)文，并發(fā)送出了ACK報(bào)文，就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FIN WAIT1狀態(tài)下，收到了對(duì)方同時(shí)帶FIN標(biāo)志和ACK標(biāo)志的報(bào)文時(shí)，可以直接進(jìn)入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)。（主動(dòng)方）

CLOSED:?表示連接中斷。

為什么要有TIME_WAIT這個(gè)狀態(tài)？

假設(shè)最終的ACK丟失，主機(jī)2將重發(fā)FIN，主機(jī)1必須維護(hù)TCP狀態(tài)信息以便可以重發(fā)最終的ACK，否則會(huì)發(fā)送RST，結(jié)果主機(jī)2認(rèn)為發(fā)生錯(cuò)誤。TCP實(shí)現(xiàn)必須可靠地終止連接的兩個(gè)方向(全雙工關(guān)閉)，主機(jī)1必須進(jìn)入 TIME_WAIT 狀態(tài)，因?yàn)橹鳈C(jī)1可能面 臨重發(fā)最終ACK的情形。

出現(xiàn)太多TIME_WAIT可能導(dǎo)致的后果：

在高并發(fā)短連接的TCP服務(wù)器上，當(dāng)服務(wù)器處理完請(qǐng)求后立刻按照主動(dòng)正常關(guān)閉連接。這個(gè)場(chǎng)景下，會(huì)出現(xiàn)大量socket處于TIMEWAIT狀態(tài)。如果客戶端的并發(fā)量持續(xù)很高，此時(shí)部分客戶端就會(huì)顯示連接不上。 我來解釋下這個(gè)場(chǎng)景。主動(dòng)正常關(guān)閉TCP連接，都會(huì)出現(xiàn)TIMEWAIT。為什么我們要關(guān)注這個(gè)高并發(fā)短連接呢？有兩個(gè)方面需要注意：

① 高并發(fā)可以讓服務(wù)器在短時(shí)間范圍內(nèi)同時(shí)占用大量端口，而端口有個(gè)0~65535的范圍，并不是很多，刨除系統(tǒng)和其他服務(wù)要用的，剩下的就更少了。

②在這個(gè)場(chǎng)景中，短連接表示“業(yè)務(wù)處理+傳輸數(shù)據(jù)的時(shí)間 遠(yuǎn)遠(yuǎn)小于 TIMEWAIT超時(shí)的時(shí)間”的連接。這里有個(gè)相對(duì)長(zhǎng)短的概念，比如，取一個(gè)web頁(yè)面，1秒鐘的http短連接處理完業(yè)務(wù)，在關(guān)閉連接之后，這個(gè)業(yè)務(wù)用過的端口會(huì)停留在TIMEWAIT狀態(tài)幾分鐘，而這幾分鐘，其他HTTP請(qǐng)求來臨的時(shí)候是無法占用此端口的。單用這個(gè)業(yè)務(wù)計(jì)算服務(wù)器的利用率會(huì)發(fā)現(xiàn)，服務(wù)器干正經(jīng)事的時(shí)間和端口（資源）被掛著無法被使用的時(shí)間的比例是 1：幾百，服務(wù)器資源嚴(yán)重浪費(fèi)。

說個(gè)題外話，從這個(gè)意義出發(fā)來考慮服務(wù)器性能調(diào)優(yōu)的話，長(zhǎng)連接業(yè)務(wù)的服務(wù)就不需要考慮TIMEWAIT狀態(tài)。同時(shí)，假如你對(duì)服務(wù)器業(yè)務(wù)場(chǎng)景非常熟悉，你會(huì)發(fā)現(xiàn)，在實(shí)際業(yè)務(wù)場(chǎng)景中，一般長(zhǎng)連接對(duì)應(yīng)的業(yè)務(wù)的并發(fā)量并不會(huì)很高

綜合這兩個(gè)方面，持續(xù)的到達(dá)一定量的高并發(fā)短連接，會(huì)使服務(wù)器因端口資源不足而拒絕為一部分客戶服務(wù)。

time_wait狀態(tài)如何避免

首先服務(wù)器可以設(shè)置SO_REUSEADDR套接字選項(xiàng)來通知內(nèi)核，如果端口忙，但TCP連接位于TIME_WAIT狀態(tài)時(shí)可以重用端口。在一個(gè)非常有用的場(chǎng)景就是，如果你的服務(wù)器程序停止后想立即重啟，而新的套接字依舊希望使用同一端口，此時(shí)SO_REUSEADDR選項(xiàng)就可以避免TIME_WAIT狀態(tài)。

2.3、網(wǎng)絡(luò)層

應(yīng)用層將數(shù)據(jù)丟給傳輸層進(jìn)行包裝，網(wǎng)絡(luò)層則是用來處理這些流動(dòng)的數(shù)據(jù)包，也就是如果把相應(yīng)的數(shù)據(jù)包路由到指定的地點(diǎn)，為通信時(shí)的網(wǎng)絡(luò)傳輸選擇傳輸路線。
就像送快遞一樣，需要選擇正確路線，才能送到你家。

2.4、數(shù)據(jù)鏈路層

數(shù)據(jù)鏈路層包含了軟件與硬件的接口部分，以及各種網(wǎng)絡(luò)設(shè)備的硬件，也就是整個(gè)網(wǎng)絡(luò)通信過程中最底層的基礎(chǔ)設(shè)施。

一個(gè)HTTP請(qǐng)求的響應(yīng)過程：

簡(jiǎn)單了解了每一層的作用之后，我們?cè)囍饋?#xff0c;摸索一下一次整體的http請(qǐng)求到響應(yīng)的過程。
拿訪問google做個(gè)例子：

0.訪問google.com，按下回車。

1.應(yīng)用層準(zhǔn)備好請(qǐng)求報(bào)文，通過DNS服務(wù)進(jìn)行域名解析，得到google的ip地址，并將報(bào)文發(fā)到傳輸層。

2.傳輸層收到報(bào)文后，會(huì)將請(qǐng)求的數(shù)據(jù)包進(jìn)行拆分，打包，并對(duì)每個(gè)包裹打上tag。在請(qǐng)求報(bào)文的基礎(chǔ)上，加上一層TCP的首部信息，然后發(fā)往網(wǎng)絡(luò)層。

3.到了網(wǎng)絡(luò)層以后，IP協(xié)議就發(fā)揮了巨大的作用，IP協(xié)議中需要兩個(gè)比較重要的信息，那就是ip地址和mac地址。ip已經(jīng)在應(yīng)用層通過dns解析出來了，那mac怎么辦。。。真尷尬，然而這時(shí)ARP協(xié)議又冒了出來，它可以根據(jù)ip地址反向查詢到目標(biāo)主機(jī)的mac地址。好了，現(xiàn)在啥都有了，打包帶走，把數(shù)據(jù)發(fā)到數(shù)據(jù)鏈路層。

4.終于走到基礎(chǔ)設(shè)施這里了，此時(shí)數(shù)據(jù)包就在一根根光纖中旋轉(zhuǎn)跳躍的奔向目的地，當(dāng)然，整個(gè)過程不一定是直達(dá)的，可能需要經(jīng)過各種中轉(zhuǎn)站，就跟坐火車轉(zhuǎn)車一樣的。

5.請(qǐng)求到達(dá)服務(wù)器后，先從數(shù)據(jù)鏈路層往上走，并驗(yàn)證消去以太網(wǎng)首部信息，在網(wǎng)絡(luò)層消去IP首部，在傳輸層消去TCP首部，就像剝洋蔥一樣一層一層去皮，最后剩下的就請(qǐng)求報(bào)文。在應(yīng)用層對(duì)請(qǐng)求做出處理之后，需要對(duì)請(qǐng)求返回一個(gè)響應(yīng)。而整個(gè)響應(yīng)的傳輸過程就和請(qǐng)求一樣，一層一層的封裝，響應(yīng)到達(dá)客戶端時(shí)再一層一層的消去首部，最后呈現(xiàn)響應(yīng)的結(jié)果。

簡(jiǎn)而言之，他們可以概括為一張這樣的圖：

二、HTTP/HTTPS協(xié)議

?在了解這兩個(gè)之前，我們先來看兩張圖：


從這兩張圖片來看，http協(xié)議和https協(xié)議有一個(gè)最顯而易見的區(qū)別：https比http要安全。

1、基本概念

1.1、http

HTTP：是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，是一個(gè)客戶端和服務(wù)器端請(qǐng)求和應(yīng)答的標(biāo)準(zhǔn)（基于TCP/IP協(xié)議），用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。

HTTP 是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，HTTP 協(xié)議一共有五大特點(diǎn)：
1、支持客戶/服務(wù)器模式；
2、簡(jiǎn)單快速；
3、靈活；
4、無連接；
5、無狀態(tài)。

其中我們主要了解一下無連接和無狀態(tài)這兩個(gè)特點(diǎn)：

1、無連接
無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。

早期這么做的原因是 HTTP 協(xié)議產(chǎn)生于互聯(lián)網(wǎng)，因此服務(wù)器需要處理同時(shí)面向全世界數(shù)十萬、上百萬客戶端的網(wǎng)頁(yè)訪問，但每個(gè)客戶端（即瀏覽器）與服務(wù)器之間交換數(shù)據(jù)的間歇性較大（即傳輸具有突發(fā)性、瞬時(shí)性），并且網(wǎng)頁(yè)瀏覽的聯(lián)想性、發(fā)散性導(dǎo)致兩次傳送的數(shù)據(jù)關(guān)聯(lián)性很低，大部分通道實(shí)際上會(huì)很空閑、無端占用資源。

因此 HTTP 的設(shè)計(jì)者有意利用這種特點(diǎn)將協(xié)議設(shè)計(jì)為請(qǐng)求時(shí)建連接、請(qǐng)求完釋放連接，以盡快將資源釋放出來服務(wù)其他客戶端。

但是，隨著時(shí)間的推移，網(wǎng)頁(yè)變得越來越復(fù)雜，里面可能嵌入了很多圖片，這時(shí)候每次訪問圖片都需要建立一次 TCP 連接就顯得很低效。后來，Keep-Alive 被提出用來解決這效率低的問題。

Keep-Alive 功能使客戶端到服務(wù)器端的連接持續(xù)有效，當(dāng)出現(xiàn)對(duì)服務(wù)器的后繼請(qǐng)求時(shí)，Keep-Alive
功能避免了建立或者重新建立連接。市場(chǎng)上的大部分 Web 服務(wù)器，包括 iPlanet、IIS 和 Apache，都支持 HTTP
Keep-Alive。對(duì)于提供靜態(tài)內(nèi)容的網(wǎng)站來說，這個(gè)功能通常很有用。但是，對(duì)于負(fù)擔(dān)較重的網(wǎng)站來說，這里存在另外一個(gè)問題：雖然為客戶保留打開的連接有一定的好處，但它同樣影響了性能，因?yàn)樵谔幚頃和Ｆ陂g，本來可以釋放的資源仍舊被占用。當(dāng)Web服務(wù)器和應(yīng)用服務(wù)器在同一臺(tái)機(jī)器上運(yùn)行時(shí)，Keep-Alive
功能對(duì)資源利用的影響尤其突出。

這樣一來，客戶端和服務(wù)器之間的 HTTP 連接就會(huì)被保持，不會(huì)斷開（超過 Keep-Alive
規(guī)定的時(shí)間，意外斷電等情況除外），當(dāng)客戶端發(fā)送另外一個(gè)請(qǐng)求時(shí)，就使用這條已經(jīng)建立的連接。

2、無狀態(tài)
無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。

即我們給服務(wù)器發(fā)送 HTTP 請(qǐng)求之后，服務(wù)器根據(jù)請(qǐng)求，會(huì)給我們發(fā)送數(shù)據(jù)過來，但是，發(fā)送完，不會(huì)記錄任何信息。

HTTP 是一個(gè)無狀態(tài)協(xié)議，這意味著每個(gè)請(qǐng)求都是獨(dú)立的，Keep-Alive 沒能改變這個(gè)結(jié)果。

缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

HTTP 協(xié)議這種特性有優(yōu)點(diǎn)也有缺點(diǎn)：

1、優(yōu)點(diǎn)在于解放了服務(wù)器，每一次請(qǐng)求“點(diǎn)到為止”不會(huì)造成不必要連接占用
2、缺點(diǎn)在于每次請(qǐng)求會(huì)傳輸大量重復(fù)的內(nèi)容信息。

客戶端與服務(wù)器進(jìn)行動(dòng)態(tài)交互的 Web 應(yīng)用程序出現(xiàn)之后，HTTP 無狀態(tài)的特性嚴(yán)重阻礙了這些應(yīng)用程序的實(shí)現(xiàn)，畢竟交互是需要承前啟后的，簡(jiǎn)單的購(gòu)物車程序也要知道用戶到底在之前選擇了什么商品。

于是，兩種用于保持 HTTP 連接狀態(tài)的技術(shù)就應(yīng)運(yùn)而生了，一個(gè)是 Cookie，而另一個(gè)則是 Session。

3、Cookie和 Session：

1、Cookie：
Cookie可以保持登錄信息到用戶下次與服務(wù)器的會(huì)話，換句話說，下次訪問同一網(wǎng)站時(shí)，用戶會(huì)發(fā)現(xiàn)不必輸入用戶名和密碼就已經(jīng)登錄了（當(dāng)然，不排除用戶手工刪除Cookie）。而還有一些Cookie在用戶退出會(huì)話的時(shí)候就被刪除了，這樣可以有效保護(hù)個(gè)人隱私。

Cookies 最典型的應(yīng)用是判定注冊(cè)用戶是否已經(jīng)登錄網(wǎng)站，用戶可能會(huì)得到提示，是否在下一次進(jìn)入此網(wǎng)站時(shí)保留用戶信息以便簡(jiǎn)化登錄手續(xù)，這些都是 Cookies 的功用。
另一個(gè)重要應(yīng)用場(chǎng)合是“購(gòu)物車”之類處理。用戶可能會(huì)在一段時(shí)間內(nèi)在同一家網(wǎng)站的不同頁(yè)面中選擇不同的商品，這些信息都會(huì)寫入 Cookies，以便在最后付款時(shí)提取信息。

2、 Session：

它是通過服務(wù)器來保持狀態(tài)的。

當(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í)文件。

以后瀏覽器每次請(qǐng)求都會(huì)額外加上這個(gè)參數(shù)值，服務(wù)器會(huì)根據(jù)這個(gè) SessionId，就能取得客戶端的數(shù)據(jù)信息。

如果客戶端瀏覽器意外關(guān)閉，服務(wù)器保存的 Session 數(shù)據(jù)不是立即釋放，此時(shí)數(shù)據(jù)還會(huì)存在，只要我們知道那個(gè) SessionId，就可以繼續(xù)通過請(qǐng)求獲得此 Session 的信息，因?yàn)榇藭r(shí)后臺(tái)的 Session 還存在，當(dāng)然我們可以設(shè)置一個(gè) Session 超時(shí)時(shí)間，一旦超過規(guī)定時(shí)間沒有客戶端請(qǐng)求時(shí)，服務(wù)器就會(huì)清除對(duì)應(yīng) SessionId 的 Session 信息。

1.2、https

HTTPS：是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。

那么https協(xié)議是怎么用SSL加密的呢？
其實(shí)SSL也是一種協(xié)議，SSL/TLS 在 TCP 之上加了一層加密等處理，不影響原有的 TCP 和 HTTP，上下都是透明的，用來實(shí)現(xiàn)安全傳輸。
其過程如圖所示：

SSL/TLS 概述

1、主要功能：

• 防冒充(pretending): 驗(yàn)證交互雙方（通常只是對(duì)服務(wù)端）身份的真實(shí)性； 防竊聽(eavesdropping):
• 對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行加密，即使被截獲也無法被識(shí)別； 防篡改(tampering):
• 確保接收方收到的數(shù)據(jù)是原始未篡改過的，若被篡改能識(shí)別出來并丟棄；

2、SSL/TLS 交互過程（加密過程）：
這里有個(gè)重要依據(jù)是RSA公鑰加密算法：

• 對(duì)于數(shù)據(jù)交換雙方，都擁有自身的公鑰和私鑰，私鑰都為自己私藏，公鑰都向?qū)Ψ焦_；
• 同樣一個(gè)數(shù)據(jù)，發(fā)送方使用自身的私鑰加密，接收方收到后可以用發(fā)送方的公鑰解密。

在連接的時(shí)候，會(huì)有以下操作：

1. 服務(wù)端：向客戶端發(fā)送服務(wù)端證書(證書中包含服務(wù)端公鑰)，并向客戶端索要客戶端證書；
2. 客戶端：收到服務(wù)端證書后，驗(yàn)證其身份有效性(可信機(jī)構(gòu)頒發(fā)、域名一致、未過期等)，如驗(yàn)證失敗則握手失敗，如成功則從中取出服務(wù)端公鑰；
3. 客戶端：向服務(wù)端發(fā)送客戶端證書(證書中包含客戶端公鑰)；
4. 服務(wù)端：收到客戶端證書后，驗(yàn)證其身份真實(shí)性，如驗(yàn)證失敗則握手失敗。

2、http和https的區(qū)別

由上圖我們可以知道，http和https最顯而易見的區(qū)別，就是一個(gè)安全一個(gè)不安全。

那么為什么他們會(huì)有這樣的區(qū)別呢？
答：HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私
信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網(wǎng)景公司設(shè)計(jì)SSL（Secure 
Sockets Layer）協(xié)議用于對(duì)HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密，從而就誕生了HTTPS。簡(jiǎn)
單來說，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)
議，要比http協(xié)議安全。

HTTPS和HTTP的區(qū)別主要如下：

1、https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。

2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。

3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

4、http的連接很簡(jiǎn)單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

3、https的優(yōu)缺點(diǎn)

3.1、https協(xié)議的優(yōu)點(diǎn)

其實(shí)，HTTPS也并非絕對(duì)安全。掌握根證書的機(jī)構(gòu)、掌握加密算法的組織同樣可以進(jìn)行中間人形式的攻擊，但HTTPS仍是現(xiàn)行架構(gòu)下最安全的解決方案，主要有以下幾個(gè)好處：

（1）使用HTTPS協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；

（2）HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。

（3）HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對(duì)安全，但它大幅增加了中間人攻擊的成本。

（4）谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS加密的網(wǎng)站在搜索結(jié)果中的排名將會(huì)更高”。

3.2、https的缺點(diǎn)

雖然說HTTPS有很大的優(yōu)勢(shì)，但其相對(duì)來說，還是存在不足之處的：

（1）HTTPS協(xié)議握手階段比較費(fèi)時(shí)，會(huì)使頁(yè)面的加載時(shí)間延長(zhǎng)近50%，增加10%到20%的耗電；

（2）HTTPS連接緩存不如HTTP高效，會(huì)增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會(huì)因此而受到影響；

（3）SSL證書需要錢，功能越強(qiáng)大的證書費(fèi)用越高，個(gè)人網(wǎng)站、小網(wǎng)站沒有必要一般不會(huì)用。

（4）SSL證書通常需要綁定IP，不能在同一IP上綁定多個(gè)域名，IPv4資源不可能支撐這個(gè)消耗。

（5）HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。最關(guān)鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國(guó)家可以控制CA根證書的情況下，中間人攻擊一樣可行。