從計(jì)算機(jī)說(shuō)起

計(jì)算機(jī)最開(kāi)始其實(shí)是用于高速計(jì)算的機(jī)器，慢慢的后來(lái)才出現(xiàn)了多媒體功能。

互聯(lián)網(wǎng)

一臺(tái)計(jì)算機(jī)能做的事情其實(shí)很有限，互聯(lián)網(wǎng)是將不同功能的計(jì)算機(jī)連接起來(lái)實(shí)現(xiàn)資源共享的系統(tǒng)。

服務(wù)器&終端：服務(wù)器、手機(jī)、PC其實(shí)都屬于計(jì)算機(jī)的一種，而一般來(lái)說(shuō)，個(gè)人PC和手機(jī)的處理能力遠(yuǎn)遠(yuǎn)不如一個(gè)服務(wù)器集群的，所以說(shuō)服務(wù)器和這些終端存在大量數(shù)據(jù)交互，這個(gè)數(shù)據(jù)交互就是依靠互聯(lián)網(wǎng)。

TCP

互聯(lián)網(wǎng)好啊，互聯(lián)網(wǎng)能把所有的“計(jì)算機(jī)”都連接在一起，那么，在如此大量的信息交互中，傳輸數(shù)據(jù)的目標(biāo)性、完整性和安全性怎么保證呢？
Transmission Control Protocol，簡(jiǎn)稱TCP，中文譯名：傳輸控制協(xié)議。TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。
TCP傳輸是由專門的TCP傳輸實(shí)體負(fù)責(zé)的，這個(gè)實(shí)體，可能是一個(gè)類，也可能是一個(gè)工具庫(kù)，實(shí)體主要管理TCP和IP層之間的接口。

TCP/IP：

TCP將需要傳輸?shù)臄?shù)據(jù)分段，然后通過(guò)IP層（發(fā)送方）發(fā)送和（接收方）接收，IP層是不會(huì)在乎數(shù)據(jù)傳輸?shù)捻樞蚝屯暾缘?，所以TCP還需要保證接收數(shù)據(jù)的完整性和順序。
那么，TCP是如何工作的呢？

建立連接——三次握手

1. 客戶端發(fā)送SYN（SEQ=x）報(bào)文給服務(wù)器端，進(jìn)入SYN_SEND狀態(tài)。
2. 服務(wù)器端收到SYN報(bào)文，回應(yīng)一個(gè)SYN （SEQ=y）ACK（ACK=x+1）報(bào)文，進(jìn)入SYN_RECV狀態(tài)。
3. 客戶端收到服務(wù)器端的SYN報(bào)文，回應(yīng)一個(gè)ACK（ACK=y+1）報(bào)文，進(jìn)入Established狀態(tài)。

三次握手完成，TCP客戶端和服務(wù)器端成功地建立連接，可以開(kāi)始傳輸數(shù)據(jù)了。

斷開(kāi)連接——四次揮手

1. 某個(gè)應(yīng)用進(jìn)程首先調(diào)用close，稱該端執(zhí)行“主動(dòng)關(guān)閉”（active close）。該端的TCP于是發(fā)送一個(gè)FIN分節(jié)，表示數(shù)據(jù)發(fā)送完畢。
2. 接收到這個(gè)FIN的對(duì)端執(zhí)行 “被動(dòng)關(guān)閉”（passive close），這個(gè)FIN由TCP確認(rèn)。
   注意：FIN的接收也作為一個(gè)文件結(jié)束符（end-of-file）傳遞給接收端應(yīng)用進(jìn)程，放在已排隊(duì)等候該應(yīng)用進(jìn)程接收的任何其他數(shù)據(jù)之后，因?yàn)?，F(xiàn)IN的接收意味著接收端應(yīng)用進(jìn)程在相應(yīng)連接上再無(wú)額外數(shù)據(jù)可接收。
3. 一段時(shí)間后，接收到這個(gè)文件結(jié)束符的應(yīng)用進(jìn)程將調(diào)用close關(guān)閉它的套接字。這導(dǎo)致它的TCP也發(fā)送一個(gè)FIN。
4. 接收這個(gè)最終FIN的原發(fā)送端TCP（即執(zhí)行主動(dòng)關(guān)閉的那一端）確認(rèn)這個(gè)FIN。

HTTP

HTTP，是Hyper Text Transfer Protocol的縮寫，翻譯過(guò)來(lái)是超文本傳輸協(xié)議，它建立在TCP協(xié)議之上，最初出現(xiàn)的時(shí)候就是解決網(wǎng)頁(yè)內(nèi)容傳輸問(wèn)題的，HTTP在連接成功的TCP通道中傳輸數(shù)據(jù)包。

特點(diǎn)

1. 一次性：每次HTTP請(qǐng)求是即時(shí)連接并且在單次請(qǐng)求、響應(yīng)完成之后就關(guān)閉的
2. 單向性：只能是請(qǐng)求方主動(dòng)向接收方發(fā)出請(qǐng)求并連接的（這個(gè)也是TCP的特點(diǎn)）

請(qǐng)求方式

HTTP規(guī)定了一些請(qǐng)求方式，使用不同請(qǐng)求做不同的事。

1. GET，請(qǐng)求指定的頁(yè)面信息，并返回實(shí)體主體。
2. HEAD，類似于 GET 請(qǐng)求，只不過(guò)返回的響應(yīng)中沒(méi)有具體的內(nèi)容，用于獲取報(bào)頭
3. POST，向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST 請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改。
4. PUT，從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
5. DELETE，請(qǐng)求服務(wù)器刪除指定的頁(yè)面。
   6.CONNECT，HTTP/1.1 協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。
6. OPTIONS，允許客戶端查看服務(wù)器的性能。
7. TRACE，回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。
8. PATCH，是對(duì) PUT 方法的補(bǔ)充，用來(lái)對(duì)已知資源進(jìn)行局部更新 。

請(qǐng)求狀態(tài)

HTTP規(guī)定了一系列code，表示每次HTTP請(qǐng)求的響應(yīng)狀態(tài)。

1xx 信息，服務(wù)器收到請(qǐng)求，需要請(qǐng)求者繼續(xù)執(zhí)行操作
2xx 成功，操作被成功接收并處理
3xx 重定向，需要進(jìn)一步的操作以完成請(qǐng)求
4xx 客戶端錯(cuò)誤，請(qǐng)求包含語(yǔ)法錯(cuò)誤或無(wú)法完成請(qǐng)求
5xx 服務(wù)器錯(cuò)誤，服務(wù)器在處理請(qǐng)求的過(guò)程中發(fā)生了錯(cuò)誤

更詳細(xì)的狀態(tài)碼在這里

HTTPS

終于進(jìn)入重點(diǎn)了...
HTTP請(qǐng)求基于TCP，內(nèi)容都是明文傳輸，信息沒(méi)有加密，如果使用HTTP傳輸敏感數(shù)據(jù)，那這些敏感數(shù)據(jù)很容易被截獲盜取。所以Netscape 公司制定了HTTPS協(xié)議，將內(nèi)容進(jìn)行加密傳輸。
HTTPS(Hypertext Transfer Protocol Secure) = HTTP+SSL/TLS，在HTTP和TCP之間加入一層安全協(xié)議層，就是HTTPS

SSL/TLS
SSL：Secure Sockets Layer，安全套接字層
TLS：Transport Layer Security，傳輸層安全

HTTP 原理

① 客戶端的瀏覽器首先要通過(guò)網(wǎng)絡(luò)與服務(wù)器建立連接，該連接是通過(guò)TCP 來(lái)完成的，一般 TCP 連接的端口號(hào)是80。 建立連接后，客戶機(jī)發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為：統(tǒng)一資源標(biāo)識(shí)符（URL）、協(xié)議版本號(hào)，后邊是 MIME 信息包括請(qǐng)求修飾符、客戶機(jī)信息和許可內(nèi)容。

② 服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行，包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤的代碼，后邊是 MIME 信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容。

HTTPS 原理

① 客戶端將它所支持的算法列表和一個(gè)用作產(chǎn)生密鑰的隨機(jī)數(shù)發(fā)送給服務(wù)器；

② 服務(wù)器從算法列表中選擇一種加密算法，并將它和一份包含服務(wù)器公用密鑰的證書發(fā)送給客戶端；該證書還包含了用于認(rèn)證目的的服務(wù)器標(biāo)識(shí)，服務(wù)器同時(shí)還提供了一個(gè)用作產(chǎn)生密鑰的隨機(jī)數(shù)；

③ 客戶端對(duì)服務(wù)器的證書進(jìn)行驗(yàn)證，并抽取服務(wù)器的公用密鑰；然后，再產(chǎn)生一個(gè)稱作 pre_master_secret 的隨機(jī)密碼串，并使用服務(wù)器的公用密鑰對(duì)其進(jìn)行加密（參考非對(duì)稱加 / 解密），并將加密后的信息發(fā)送給服務(wù)器；

④ 客戶端與服務(wù)器端根據(jù) pre_master_secret 以及客戶端與服務(wù)器的隨機(jī)數(shù)值獨(dú)立計(jì)算出加密和 MAC密鑰；

⑤ 客戶端將所有握手消息的 MAC 值發(fā)送給服務(wù)器；

⑥ 服務(wù)器將所有握手消息的 MAC 值發(fā)送給客戶端。

優(yōu)點(diǎn)

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

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

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

缺點(diǎn)

1. 相同網(wǎng)絡(luò)環(huán)境下，HTTPS 協(xié)議會(huì)使頁(yè)面的加載時(shí)間延長(zhǎng)近 50%，增加 10%到 20%的耗電。此外，HTTPS 協(xié)議還會(huì)影響緩存，增加數(shù)據(jù)開(kāi)銷和功耗。

2. HTTPS 協(xié)議的安全是有范圍的，在黑客攻擊、拒絕服務(wù)攻擊和服務(wù)器劫持等方面幾乎起不到什么作用。

3. 最關(guān)鍵的是，SSL 證書的信用鏈體系并不安全。特別是在某些國(guó)家可以控制 CA根證書的情況下，中間人攻擊一樣可行。

4. 成本增加。部署 HTTPS 后，因?yàn)?HTTPS 協(xié)議的工作要增加額外的計(jì)算資源消耗，例如 SSL 協(xié)議加密算法和 SSL 交互次數(shù)將占用一定的計(jì)算資源和服務(wù)器成本。在大規(guī)模用戶訪問(wèn)應(yīng)用的場(chǎng)景下，服務(wù)器需要頻繁地做加密和解密操作，幾乎每一個(gè)字節(jié)都需要做加解密，這就產(chǎn)生了服務(wù)器成本。隨著云計(jì)算技術(shù)的發(fā)展，數(shù)據(jù)中心部署的服務(wù)器使用成本在規(guī)模增加后逐步下降，相對(duì)于用戶訪問(wèn)的安全提升，其投入成本已經(jīng)下降到可接受程度。

注：以上內(nèi)容基本來(lái)自百度百科，只是做了綜述