五層模型

首先是經(jīng)典的五層模型：應(yīng)用層--傳輸層--網(wǎng)絡(luò)層--數(shù)據(jù)鏈路層--物理層

物理層：主要作用是定義物理設(shè)備如何傳輸數(shù)據(jù)（電腦的硬件設(shè)備相關(guān)，網(wǎng)卡端口，網(wǎng)線連出去之后要有一條光纜，為我們傳輸幾千公里以外的數(shù)據(jù)等）
數(shù)據(jù)鏈路層：在通信的實(shí)體間建立數(shù)據(jù)鏈路連接（物理設(shè)備可以把兩臺(tái)設(shè)備連接在一起，而這層就相當(dāng)于是軟件讓兩臺(tái)設(shè)備創(chuàng)建了電路連接）
網(wǎng)絡(luò)層：為數(shù)據(jù)在節(jié)點(diǎn)之間傳輸創(chuàng)建邏輯鏈路（假設(shè)我的電腦要去訪問百度的服務(wù)器，如何去尋找百度服務(wù)器就是網(wǎng)絡(luò)層做的事情）
傳輸層：向用戶提供了可靠的端到端（end-end）服務(wù)，主要有兩個(gè)協(xié)議TCP協(xié)議和UDP協(xié)議，網(wǎng)絡(luò)層建立客戶端與服務(wù)器端的連接之后要傳輸數(shù)據(jù)，那么如何傳輸，是在這一層定義的。傳輸層向高層屏蔽了下層數(shù)據(jù)通信的細(xì)節(jié)。
應(yīng)用層：為應(yīng)用軟件提供了很多服務(wù)，主要有HTTP協(xié)議和FTP協(xié)議，構(gòu)建于TCP協(xié)議之上，屏蔽了網(wǎng)絡(luò)傳輸?shù)南嚓P(guān)細(xì)節(jié)
（OSI七層）將五層中的應(yīng)用層又分為會(huì)話層，表示層以及應(yīng)用層。
會(huì)話層：負(fù)責(zé)網(wǎng)絡(luò)中兩節(jié)點(diǎn)的建立，在數(shù)據(jù)傳輸中維護(hù)計(jì)算機(jī)網(wǎng)絡(luò)中兩臺(tái)計(jì)算機(jī)的通信連接，并決定何時(shí)終止通信。
表示層：負(fù)責(zé)數(shù)據(jù)格式的轉(zhuǎn)換，數(shù)據(jù)解析等。同時(shí)也對(duì)應(yīng)用層的協(xié)議進(jìn)行翻譯。

HTTP協(xié)議的發(fā)展之路

HTTP/0.9：
內(nèi)容十分簡(jiǎn)單，只有一個(gè)命令GET，對(duì)應(yīng)get、post等請(qǐng)求方法；
沒有HEADER等描述數(shù)據(jù)的信息
服務(wù)器發(fā)送完內(nèi)容，就關(guān)閉TCP連接（在一個(gè)TCP連接上可以建立多個(gè)HTTP連接）
HTTP/1.0：
增加了很多命令，如post、put等
增加status code狀態(tài)碼和header數(shù)據(jù)描述以及操作的方法描述
多字符集支持、多部分發(fā)送、權(quán)限、緩存等
HTTP/1.1：
數(shù)據(jù)大部分都是字符串形式的，所以數(shù)據(jù)的分別片方式不太一樣
持久連接keep-alive。使連接持續(xù)有效
pipeline管線化，可以在同一個(gè)連接里發(fā)送多個(gè)請(qǐng)求，但是服務(wù)器端是按請(qǐng)求順序處理的（串行）
增加host和一些其他命令，有了host就可以在一臺(tái)設(shè)備上同時(shí)啟動(dòng)多個(gè)服務(wù)，通過host可以定位到請(qǐng)求的是哪個(gè)軟件服務(wù)（比如node，Java等）
HTTP/2：主要是為了解決HTTP1.1里面的一些性能低下的問題
所有數(shù)據(jù)都是以二進(jìn)制傳輸?shù)?，（按幀傳輸?br> 所以同一個(gè)連接里面發(fā)送多個(gè)請(qǐng)求不再按照順序來處理
頭信息壓縮以及推送等高效率的功能
HTTP1.1里面 header里面有很多字段都是字符串形式的，占用很多帶寬，頭信息壓縮之后，有效地減少了帶寬使用
HTTP1.1里面主動(dòng)方永遠(yuǎn)是客戶端，服務(wù)器端一直是被動(dòng)方，舉個(gè)栗子：當(dāng)請(qǐng)求一個(gè)html頁面的時(shí)候，服務(wù)器端先把html源代碼發(fā)送給客戶端，客戶端解析到需要引用css和js的部分時(shí)再去向服務(wù)器端請(qǐng)求css和js文件
而HTTP2里面加入了推送的功能，就可以在客戶端請(qǐng)求完html頁面之后主動(dòng)把它需要引用的css和js文件等推送過去，實(shí)現(xiàn)了三者的并行傳輸。

TCP三次握手

第一次握手：client給server發(fā)送一個(gè)創(chuàng)建連接的請(qǐng)求，帶有標(biāo)志位SYN=1，序列Seq=X，進(jìn)入SYN_SEND狀態(tài)，等待server確認(rèn)。
第二次握手：server收到連接請(qǐng)求，就會(huì)開啟一個(gè)socket接口，確認(rèn)client的SYN（ACK=X+1），向client返回一個(gè)標(biāo)志位SYN=1，再發(fā)一個(gè)自己的序列Seq=Y，進(jìn)入SYN_RECV狀態(tài)
第三次握手：client收到應(yīng)答再發(fā)送給server一個(gè)應(yīng)答ACK=Y+1，序列Seq=Z，雙方進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。
三次握手的原因：為了防止服務(wù)器端開啟一些無用的連接，網(wǎng)絡(luò)傳輸是有延時(shí)的，如果傳輸?shù)倪^程當(dāng)中客戶端的請(qǐng)求被阻塞或者延遲，過一定的時(shí)間他沒有收到服務(wù)器端的應(yīng)答就會(huì)默認(rèn)本次發(fā)送失效，重新再發(fā)一次請(qǐng)求，而隔了一段時(shí)間之后服務(wù)器端接收到了之前的請(qǐng)求，就回去給客戶端響應(yīng)，并且等待他的回應(yīng)，但此時(shí)客戶端認(rèn)為自己沒有發(fā)送這個(gè)請(qǐng)求，是不會(huì)響應(yīng)的。
四次揮手關(guān)閉連接
第一次揮手：Clien發(fā)送一個(gè)FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進(jìn)入FIN_WAIT_1狀態(tài)。
第二次揮手：Server收到FIN后，發(fā)送一個(gè)ACK給Client,Server進(jìn)入CLOSE_WAIT狀態(tài)。
第三次揮手：Server發(fā)送一個(gè)FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入LAST_ACK狀態(tài)。
第四次揮手：Client收到FIN后，Client進(jìn)入TIME_WAIT狀態(tài)，發(fā)送ACK給Server，Server進(jìn)入CLOSED狀態(tài)，完成四次握手.
四次揮手的原因：
當(dāng)收到對(duì)方的FIN報(bào)文時(shí)，僅表示對(duì)方不再發(fā)送數(shù)據(jù)但還能接收收據(jù)，我們也未必把全部數(shù)據(jù)都發(fā)給了對(duì)方，所以我們可以立即close，也可以發(fā)送一些數(shù)據(jù)給對(duì)方后，再發(fā)送FIN報(bào)文給對(duì)方表示同意關(guān)閉連接。因此我們的ACK和FIN一般會(huì)分開發(fā)送。

URI

Uniform Resource Identifier/統(tǒng)一資源標(biāo)識(shí)符
用來唯一標(biāo)識(shí)互聯(lián)網(wǎng)上的信息資源
包括URL和URN
URL：Uniform Resource Locator/統(tǒng)一資源定位符
http://user:pass@host.com:80/path?query=string#hash
http：協(xié)議
user:pass：用戶密碼，一般不用
host.com：資源定位，找到這臺(tái)服務(wù)器所在互聯(lián)網(wǎng)的位置。可以是IP，就可以直接找到目標(biāo)服務(wù)器，也可以是域名，需要DNS解析才能找到目標(biāo)服務(wù)器
80：端口，每一臺(tái)服務(wù)器都有很多的端口，存放了很多的web服務(wù)，端口可以定位是具體的哪一個(gè)，HTTP協(xié)議默認(rèn)是80，F(xiàn)TP是21，HTTPS是443
path：請(qǐng)求路徑
query=string#hash：參數(shù)
URN：永久統(tǒng)一資源定位符，在資源移動(dòng)之后還能被找到，但目前還沒有成熟的使用方案

HTTP報(bào)文

請(qǐng)求報(bào)文
起始行：包含請(qǐng)求方式，請(qǐng)求地址，協(xié)議版本
首部：key-value值，告訴服務(wù)器端都要什么值，值要什么類型
空行：表示header部分結(jié)束了，到了數(shù)據(jù)部分
主體：數(shù)據(jù)部分
響應(yīng)報(bào)文
起始行：協(xié)議版本，狀態(tài)碼，狀態(tài)碼的含義
首部：key-value值
空行：表示header部分結(jié)束了，到了數(shù)據(jù)部分
主體：響應(yīng)的數(shù)據(jù)部分

HTTPS

HTTP是明文協(xié)議
1、傳遞的數(shù)據(jù)容易被偷窺和篡改（對(duì)稱加密）
在每次發(fā)送真實(shí)數(shù)據(jù)之前，服務(wù)器先生成一把密鑰，然后先把密鑰傳輸給客戶端。之后服務(wù)器給客戶端發(fā)送真實(shí)數(shù)據(jù)的時(shí)候，會(huì)用這把密鑰對(duì)數(shù)據(jù)進(jìn)行加密，客戶端收到加密數(shù)據(jù)之后，用剛才收到的密鑰進(jìn)行解密。如果客戶端要給服務(wù)器發(fā)送數(shù)據(jù)，也是采用這把密鑰來加密。

這種加密的密鑰傳輸也是采用明文的方式，因此這種加密對(duì)于中間人來說跟明文其實(shí)沒啥區(qū)別，反倒還多了一個(gè)加密解密的步驟。
2、密鑰的傳遞問題（非對(duì)稱加密，密鑰是一對(duì)，公鑰和私鑰）
數(shù)學(xué)基礎(chǔ)：兩個(gè)超大的素?cái)?shù)求乘積非常容易（私鑰），但分解因子很麻煩（公鑰）rsa算法
接收端和發(fā)送端分別擁有一對(duì)公鑰和私鑰，公鑰是可以發(fā)送給對(duì)方的私鑰不可以，加密的時(shí)候就先用對(duì)方的公鑰和己方的私鑰加密，再發(fā)送給對(duì)方，對(duì)方用自己的私鑰解密。即用公鑰加密的數(shù)據(jù)，只有對(duì)應(yīng)的私鑰才能解密；用私鑰加密的數(shù)據(jù)，只有對(duì)應(yīng)的公鑰才能解密。