一.計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)

???????低三層為通信子網(wǎng)，負(fù)責(zé)數(shù)據(jù)傳輸
???????高三層為資源子網(wǎng)，相當(dāng)于計(jì)算機(jī)系統(tǒng)，完成數(shù)據(jù)處理；
???????傳輸層承上啟下
???????TCP/IP各層的功能如下：

TCP-IP.png

二.TCP協(xié)議

???????Transmission Control Protocol，即：傳輸控制協(xié)議
???????屬于傳輸層通信協(xié)議
???????基于TCP的應(yīng)用層協(xié)議有HTTP、SMTP、FTP、Telnet 和 POP3；

a.三次握手

???????所謂的三次握手即TCP連接的建立，這個(gè)連接必須是一方主動(dòng)打開(kāi)，另一方被動(dòng)打開(kāi)的。建立過(guò)程如下：

1.png

???????握手之前主動(dòng)打開(kāi)連接的客戶(hù)端結(jié)束CLOSED階段，被動(dòng)打開(kāi)的服務(wù)器端也結(jié)束CLOSED階段，并進(jìn)入LISTEN階段。隨后開(kāi)始“三次握手”：
???????①.首先客戶(hù)端向服務(wù)器端發(fā)送一段TCP報(bào)文，其中：
??????????????標(biāo)記位為SYN，表示“請(qǐng)求建立新連接”；
??????????????序號(hào)為seq=x（x一般為1）；
??????????????隨后客戶(hù)端進(jìn)入SYN-SENT階段；
???????②.服務(wù)器端接收到來(lái)自客戶(hù)端的TCP報(bào)文之后，結(jié)束LISTEN階段。并返回一段TCP報(bào)文，其中：
??????????????標(biāo)志位為SYN和ACK，表示“確認(rèn)客戶(hù)端的報(bào)文seq序號(hào)有效，服務(wù)器能正常接收客戶(hù)端發(fā)送的數(shù)據(jù)，并同意創(chuàng)建新連接”（即告訴客戶(hù)端，服務(wù)器收到了你的數(shù)據(jù)）；
??????????????序號(hào)為seq=y；
??????????????確認(rèn)號(hào)為ack=x+1，表示收到客戶(hù)端的序號(hào)seq并將其值加1作為自己確認(rèn)號(hào)ack的值；隨后服務(wù)器端進(jìn)入SYN-RCVD階段。
???????③.客戶(hù)端接收到來(lái)自服務(wù)器端的確認(rèn)收到數(shù)據(jù)的TCP報(bào)文之后，明確了從客戶(hù)端到服務(wù)器的數(shù)據(jù)傳輸是正常的，結(jié)束SYN-SENT階段。并返回最后一段TCP報(bào)文。其中：
??????????????標(biāo)志位為ACK，表示“確認(rèn)收到服務(wù)器端同意連接的信號(hào)”（即告訴服務(wù)器，我知道你收到我發(fā)的數(shù)據(jù)了）；
??????????????序號(hào)為seq=x+1，表示收到服務(wù)器端的確認(rèn)號(hào)ack，并將其值作為自己的序號(hào)值；
??????????????確認(rèn)號(hào)為ack=y+1，表示收到服務(wù)器端序號(hào)seq，并將其值加1作為自己的確認(rèn)號(hào)ack的值；
??????????????隨后客戶(hù)端進(jìn)入ESTABLISHED階段。
???????服務(wù)器收到來(lái)自客戶(hù)端的“確認(rèn)收到服務(wù)器數(shù)據(jù)”的TCP報(bào)文之后，明確了從服務(wù)器到客戶(hù)端的數(shù)據(jù)傳輸是正常的。結(jié)束SYN-SENT階段，進(jìn)入ESTABLISHED階段。
???????在客戶(hù)端與服務(wù)器端傳輸?shù)腡CP報(bào)文中，雙方的確認(rèn)號(hào)ack和序號(hào)seq的值，都是在彼此ack和seq值的基礎(chǔ)上進(jìn)行計(jì)算的，這樣做保證了TCP報(bào)文傳輸?shù)倪B貫性。一旦出現(xiàn)某一方發(fā)出的TCP報(bào)文丟失，便無(wú)法繼續(xù)"握手"，以此確保了"三次握手"的順利完成。
???????此后客戶(hù)端和服務(wù)器端進(jìn)行正常的數(shù)據(jù)傳輸。這就是“三次握手”的過(guò)程。

a.1.為什么要三次握手？

???????防止服務(wù)器端因接收了早已失效的連接請(qǐng)求報(bào)文，從而一直等待客戶(hù)端請(qǐng)求，最終導(dǎo)致形成死鎖、浪費(fèi)資源。
???????可以這樣理解：“第三次握手”是客戶(hù)端向服務(wù)器端發(fā)送數(shù)據(jù)，這個(gè)數(shù)據(jù)就是要告訴服務(wù)器，客戶(hù)端有沒(méi)有收到服務(wù)器“第二次握手”時(shí)傳過(guò)去的數(shù)據(jù)。若發(fā)送的這個(gè)數(shù)據(jù)是“收到了”的信息，接收后服務(wù)器就正常建立TCP連接，否則建立TCP連接失敗，服務(wù)器關(guān)閉連接端口。由此減少服務(wù)器開(kāi)銷(xiāo)和接收到失效請(qǐng)求發(fā)生的錯(cuò)誤。

a.2.通俗理解為什么不是二次握手？

???????假定A向B發(fā)送一個(gè)連接請(qǐng)求，由于一些原因，導(dǎo)致A發(fā)出的連接請(qǐng)求在一個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)逗留了比較多的時(shí)間。此時(shí)A會(huì)將此連接請(qǐng)求作為無(wú)效處理，又重新向B發(fā)起了一次新的連接請(qǐng)求，B正常收到此連接請(qǐng)求后建立了連接，數(shù)據(jù)傳輸完成后釋放了連接。如果此時(shí)A發(fā)出的第一次請(qǐng)求又到達(dá)了B，B會(huì)以為A又發(fā)起了一次連接請(qǐng)求，如果是兩次握手：此時(shí)連接就建立了，B會(huì)一直等待A發(fā)送數(shù)據(jù)，從而白白浪費(fèi)B的資源。 如果是三次握手：由于A沒(méi)有發(fā)起連接請(qǐng)求，也就不會(huì)理會(huì)B的連接響應(yīng)，B沒(méi)有收到A的確認(rèn)連接，就會(huì)關(guān)閉掉本次連接。

b.四次揮手

???????所謂四次揮手即TCP連接的釋放(解除)。連接的釋放必須是一方主動(dòng)釋放，另一方被動(dòng)釋放。釋放過(guò)程如下：

2.png

c.為什么“握手”是三次，“揮手”卻要四次

???????TCP建立連接時(shí)之所以只需要"三次握手"，是因?yàn)樵诘诙?握手"過(guò)程中，服務(wù)器端發(fā)送給客戶(hù)端的TCP報(bào)文是以SYN與ACK作為標(biāo)志位的。SYN是請(qǐng)求連接標(biāo)志，表示服務(wù)器端同意建立連接；ACK是確認(rèn)報(bào)文，表示告訴客戶(hù)端，服務(wù)器端收到了它的請(qǐng)求報(bào)文。
???????即SYN建立連接報(bào)文與ACK確認(rèn)接收?qǐng)?bào)文是在同一次"握手"當(dāng)中傳輸?shù)?，所?三次握手"不多也不少，正好讓雙方明確彼此信息互通。
???????TCP釋放連接時(shí)之所以需要“四次揮手”，是因?yàn)镕IN釋放連接報(bào)文與ACK確認(rèn)接收?qǐng)?bào)文是分別由第二次和第三次"握手"傳輸?shù)?。為何建立連接時(shí)一起傳輸，釋放連接時(shí)卻要分開(kāi)傳輸？
???????建立連接時(shí)，被動(dòng)方服務(wù)器端結(jié)束CLOSED階段進(jìn)入“握手”階段并不需要任何準(zhǔn)備，可以直接返回SYN和ACK報(bào)文，開(kāi)始建立連接。
???????釋放連接時(shí)，被動(dòng)方服務(wù)器突然收到主動(dòng)方客戶(hù)端釋放連接的請(qǐng)求時(shí)并不能立即釋放連接，因?yàn)檫€有必要的數(shù)據(jù)需要處理，所以服務(wù)器先返回ACK確認(rèn)收到報(bào)文，經(jīng)過(guò)CLOSE-WAIT階段準(zhǔn)備好釋放連接之后，才能返回FIN釋放連接報(bào)文。
???????所以是“三次握手”，“四次揮手”。

d.為什么客戶(hù)端在TIME-WAIT階段要等2MSL

???????為了確認(rèn)服務(wù)器端是否收到客戶(hù)端發(fā)出的ACK確認(rèn)報(bào)文。
???????當(dāng)客戶(hù)端發(fā)出最后的ACK確認(rèn)報(bào)文時(shí)，并不能確定服務(wù)器端能夠收到該段報(bào)文。所以客戶(hù)端在發(fā)送完ACK確認(rèn)報(bào)文之后，會(huì)設(shè)置一個(gè)時(shí)長(zhǎng)為2MSL的計(jì)時(shí)器。
???????MSL指的是Maximum Segment Lifetime：一段TCP報(bào)文在傳輸過(guò)程中的最大生命周期。2MSL即是服務(wù)器端發(fā)出為FIN報(bào)文和客戶(hù)端發(fā)出的ACK確認(rèn)報(bào)文所能保持有效的最大時(shí)長(zhǎng)。
???????服務(wù)器端在1MSL內(nèi)沒(méi)有收到客戶(hù)端發(fā)出的ACK確認(rèn)報(bào)文，就會(huì)再次向客戶(hù)端發(fā)出FIN報(bào)文；
???????如果客戶(hù)端在2MSL內(nèi)，再次收到了來(lái)自服務(wù)器端的FIN報(bào)文，說(shuō)明服務(wù)器端由于各種原因沒(méi)有接收到客戶(hù)端發(fā)出的ACK確認(rèn)報(bào)文?？蛻?hù)端再次向服務(wù)器端發(fā)出ACK確認(rèn)報(bào)文，計(jì)時(shí)器重置，重新開(kāi)始2MSL的計(jì)時(shí)；
???????如果客戶(hù)端在2MSL內(nèi)沒(méi)有再次收到來(lái)自服務(wù)器端的FIN報(bào)文，說(shuō)明服務(wù)器端正常接收了ACK確認(rèn)報(bào)文，客戶(hù)端可以進(jìn)入CLOSED階段，完成“四次揮手”。
???????所以，客戶(hù)端要經(jīng)歷時(shí)長(zhǎng)為2SML的TIME-WAIT階段；這也是為什么客戶(hù)端比服務(wù)器端晚進(jìn)入CLOSED階段的原因。

三.HTTP協(xié)議

???????HTTP協(xié)議屬于應(yīng)用層，采用請(qǐng)求->響應(yīng)的工作方式，半雙工工作模式(可以發(fā)，可以收，不能同時(shí))，長(zhǎng)/短連接(http1.1默認(rèn)是長(zhǎng)連接，http1.0是短連接)工作方式如下：

3.png

???????請(qǐng)求的報(bào)文結(jié)構(gòu)如下：

4.png

HTTP1.1 與 HTTP1.0的區(qū)別

???????Http1.1 比 Http1.0 多了以下優(yōu)點(diǎn)：
???????1.引入持久連接，即在同一個(gè)TCP的連接中可傳送多個(gè)HTTP請(qǐng)求 & 響應(yīng)，即在http頭加入了Connection:Keep-Alive，加入Connection:close才關(guān)閉；
???????2.多個(gè)請(qǐng)求 & 響應(yīng)可同時(shí)進(jìn)行、可重疊
???????3.引入更加多的請(qǐng)求頭 & 響應(yīng)頭，如 與身份認(rèn)證、狀態(tài)管理 & Cache緩存等機(jī)制相關(guān)的、HTTP1.0無(wú)host字段

網(wǎng)絡(luò)連接類(lèi)型

Https通信流程

image.png

Http與Https的區(qū)別

5.png

四.Socket

???????套接字，是應(yīng)用層 與 TCP/IP 協(xié)議族通信的中間軟件抽象層，表現(xiàn)為一個(gè)封裝了 TCP / IP協(xié)議族 的編程接口（API）

6.png

???????1.Socket不是一種協(xié)議，而是一個(gè)編程調(diào)用接口（API），屬于傳輸層（主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸）；
???????2.通過(guò)Socket，我們才能在Andorid平臺(tái)上通過(guò) TCP/IP協(xié)議進(jìn)行開(kāi)發(fā)；
???????3.對(duì)用戶(hù)來(lái)說(shuō)，只需調(diào)用Socket去組織數(shù)據(jù)，以符合指定的協(xié)議，即可通信；

建立socket通信過(guò)程

7.png

Socket 與 Http 對(duì)比

???????Socket屬于傳輸層，因?yàn)?TCP / IP協(xié)議屬于傳輸層，解決的是數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸?shù)膯?wèn)題；
???????HTTP協(xié)議 屬于 應(yīng)用層，解決的是如何包裝數(shù)據(jù)；
???????由于二者不屬于同一層面，所以本來(lái)是沒(méi)有可比性的。但隨著發(fā)展，默認(rèn)的Http里封裝了下面幾層的使用，所以才會(huì)出現(xiàn)Socket & HTTP協(xié)議的對(duì)比：（主要是工作方式的不同）：
???????Http：采用請(qǐng)求->響應(yīng)方式。
???????即建立網(wǎng)絡(luò)連接后，當(dāng)客戶(hù)端向服務(wù)器發(fā)送請(qǐng)求后，服務(wù)器端才能向客戶(hù)端返回?cái)?shù)據(jù)。可理解為：是客戶(hù)端有需要才進(jìn)行通信
???????Socket：采用服務(wù)器主動(dòng)發(fā)送數(shù)據(jù)的方式
???????即建立網(wǎng)絡(luò)連接后，服務(wù)器可主動(dòng)發(fā)送消息給客戶(hù)端，而不需要由客戶(hù)端向服務(wù)器發(fā)送請(qǐng)求，可理解為：是服務(wù)器端有需要才進(jìn)行通信
???????很多情況下，需要服務(wù)器端主動(dòng)向客戶(hù)端推送數(shù)據(jù)，保持客戶(hù)端與服務(wù)器數(shù)據(jù)的實(shí)時(shí)與同步。此時(shí)若雙方建立的是Socket連接，服務(wù)器就可以直接將數(shù)據(jù)傳送給客戶(hù)端；若雙方建立的是HTTP連接，則服務(wù)器需要等到客戶(hù)端發(fā)送一次請(qǐng)求后才能將數(shù)據(jù)傳回給客戶(hù)端，因此，客戶(hù)端定時(shí)向服務(wù)器端發(fā)送連接請(qǐng)求， 不僅可以保持在線(xiàn)，同時(shí)也是在“詢(xún)問(wèn)”服務(wù)器是否有新的數(shù)據(jù)，如果有就將數(shù)據(jù)傳給客戶(hù)端。

心跳機(jī)制

???????正常連接斷開(kāi)客戶(hù)端會(huì)給服務(wù)端發(fā)送一個(gè)fin包，服務(wù)端收到fin包后才會(huì)知道連接斷開(kāi)。 而斷網(wǎng)斷電時(shí)客戶(hù)端無(wú)法發(fā)送fin包給服務(wù)端，所以服務(wù)端沒(méi)辦法檢測(cè)到客戶(hù)端已經(jīng)斷線(xiàn)。
???????為了緩解這個(gè)問(wèn)題，服務(wù)端需要有個(gè)心跳邏輯，就是服務(wù)端檢測(cè)到某個(gè)客戶(hù)端多久沒(méi)發(fā)送任何數(shù)據(jù)過(guò)來(lái)就認(rèn)為客戶(hù)端已經(jīng)斷開(kāi)， 這需要客戶(hù)端定時(shí)向服務(wù)端發(fā)送心跳數(shù)據(jù)維持連接。
???????心跳機(jī)制實(shí)現(xiàn)
???????長(zhǎng)連接的實(shí)現(xiàn)：心跳機(jī)制，應(yīng)用層協(xié)議大多都有HeartBeat機(jī)制，通常是客戶(hù)端每隔一小段時(shí)間向服務(wù)器發(fā)送一個(gè)數(shù)據(jù)包，通知服務(wù)器自己仍然在線(xiàn)。并傳輸一些可能必要的數(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)線(xiàn)拔出、防火墻這些斷線(xiàn)。 而且邏輯層處理斷線(xiàn)可能也不是那么好處理。一般，如果只是用于?；钸€是可以的。通過(guò)使用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)。

Cookie與Session的作用和原理

???????Session是在服務(wù)端保存的一個(gè)數(shù)據(jù)結(jié)構(gòu)，用來(lái)跟蹤用戶(hù)的狀態(tài)，這個(gè)數(shù)據(jù)可以保存在集群、數(shù)據(jù)庫(kù)、文件中。
???????Cookie是客戶(hù)端保存用戶(hù)信息的一種機(jī)制，用來(lái)記錄用戶(hù)的一些信息，也是實(shí)現(xiàn)Session的一種方式。
???????Session：
???????由于HTTP協(xié)議是無(wú)狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶(hù)的狀態(tài)時(shí)就需要用某種機(jī)制來(lái)識(shí)具體的用戶(hù)，這個(gè)機(jī)制就是Session。典型的場(chǎng)景比如購(gòu)物車(chē)，當(dāng)你點(diǎn)擊下單按鈕時(shí)，由于HTTP協(xié)議無(wú)狀態(tài)，所以并不知道是哪個(gè)用戶(hù)操作的，所以服務(wù)端要為特定的用戶(hù)創(chuàng)建了特定的Session，用于標(biāo)識(shí)這個(gè)用戶(hù)，并且跟蹤用戶(hù)，這樣才知道購(gòu)物車(chē)?yán)锩嬗袔妆緯?shū)。
???????Session是保存在服務(wù)端的，有一個(gè)唯一標(biāo)識(shí)。在服務(wù)端保存Session的方法很多，內(nèi)存、數(shù)據(jù)庫(kù)、文件都有。集群的時(shí)候也要考慮Session的轉(zhuǎn)移，在大型的網(wǎng)站，一般會(huì)有專(zhuān)門(mén)的Session服務(wù)器集群，用來(lái)保存用戶(hù)會(huì)話(huà)，這個(gè)時(shí)候 Session 信息都是放在內(nèi)存的。
???????具體到Web中的Session指的就是用戶(hù)在瀏覽某個(gè)網(wǎng)站時(shí)，從進(jìn)入網(wǎng)站到瀏覽器關(guān)閉所經(jīng)過(guò)的這段時(shí)間，也就是用戶(hù)瀏覽這個(gè)網(wǎng)站所花費(fèi)的時(shí)間。因此從上述的定義中我們可以看到，Session實(shí)際上是一個(gè)特定的時(shí)間概念。
???????當(dāng)客戶(hù)端訪問(wèn)服務(wù)器時(shí)，服務(wù)器根據(jù)需求設(shè)置Session，將會(huì)話(huà)信息保存在服務(wù)器上，同時(shí)將標(biāo)示Session的SessionId傳遞給客戶(hù)端瀏覽器，瀏覽器將這個(gè)SessionId保存在內(nèi)存中，我們稱(chēng)之為無(wú)過(guò)期時(shí)間的Cookie。瀏覽器關(guān)閉后，這個(gè)Cookie就會(huì)被清掉，它不會(huì)存在于用戶(hù)的Cookie臨時(shí)文件。以后瀏覽器每次請(qǐng)求都會(huì)額外加上這個(gè)參數(shù)值，服務(wù)器會(huì)根據(jù)這個(gè)SessionId，就能取得客戶(hù)端的數(shù)據(jù)信息。
???????如果客戶(hù)端瀏覽器意外關(guān)閉，服務(wù)器保存的Session數(shù)據(jù)不是立即釋放，此時(shí)數(shù)據(jù)還會(huì)存在，只要我們知道那個(gè)SessionId，就可以繼續(xù)通過(guò)請(qǐng)求獲得此Session的信息，因?yàn)榇藭r(shí)后臺(tái)的Session還存在，當(dāng)然我們可以設(shè)置一個(gè)Session超時(shí)時(shí)間，一旦超過(guò)規(guī)定時(shí)間沒(méi)有客戶(hù)端請(qǐng)求時(shí)，服務(wù)器就會(huì)清除對(duì)應(yīng)SessionId的Session信息。
???????Cookie
???????Cookie是由服務(wù)器端生成，發(fā)送給User-Agent（一般是web瀏覽器），瀏覽器會(huì)將Cookie的key/value保存到某個(gè)目錄下的文本文件內(nèi)，下次請(qǐng)求同一網(wǎng)站時(shí)就發(fā)送該Cookie給服務(wù)器（前提是瀏覽器設(shè)置為啟用Cookie）。Cookie名稱(chēng)和值可以由服務(wù)器端開(kāi)發(fā)自己定義，對(duì)于JSP而言也可以直接寫(xiě)入Sessionid，這樣服務(wù)器可以知道該用戶(hù)是否合法用戶(hù)以及是否需要重新登錄等。

五.網(wǎng)絡(luò)安全

???????在前面講到，Https在通信過(guò)程中用到了非對(duì)稱(chēng)加密及服務(wù)端會(huì)發(fā)送ssl證書(shū)給客戶(hù)端，客戶(hù)端需要驗(yàn)證證書(shū)的合法性，然后進(jìn)行下一次通信。

1.非對(duì)稱(chēng)加密

???????即公鑰公開(kāi)給任何人，私鑰自己保留，用公鑰加密，用私鑰解密，用一張圖來(lái)形象的表示非對(duì)稱(chēng)加密：

非對(duì)稱(chēng)加密.png

2.消息摘要/數(shù)字證書(shū)/CA

???????Https在通信過(guò)程中客戶(hù)端收到服務(wù)端的SSL證書(shū)后，會(huì)驗(yàn)證其合法性，關(guān)于數(shù)字證書(shū)生成及驗(yàn)證流程，用一張圖來(lái)表示一下工作過(guò)程：

消息摘要/數(shù)字證書(shū)/CA.png

3.中間人攻擊

???????中間人攻擊(Man-in-the-Middle attack:MITM)是指攻擊者與通訊的兩端分別創(chuàng)建獨(dú)立的聯(lián)系，并交換其所收到的數(shù)據(jù)，使通訊的兩端認(rèn)為他們正在通過(guò)一個(gè)私密的連接與對(duì)方直接對(duì)話(huà)，實(shí)際上整個(gè)會(huì)話(huà)都被攻擊者完全控制。

中間人攻擊.png