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

???????低三層為通信子網(wǎng)杯缺，負責(zé)數(shù)據(jù)傳輸
???????高三層為資源子網(wǎng)，相當(dāng)于計算機系統(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連接的建立，這個連接必須是一方主動打開洒宝，另一方被動打開的购公。建立過程如下：

1.png

???????握手之前主動打開連接的客戶端結(jié)束CLOSED階段，被動打開的服務(wù)器端也結(jié)束CLOSED階段雁歌，并進入LISTEN階段宏浩。隨后開始“三次握手”：
???????①.首先客戶端向服務(wù)器端發(fā)送一段TCP報文，其中：
??????????????標(biāo)記位為SYN靠瞎，表示“請求建立新連接”比庄；
??????????????序號為seq=x（x一般為1）；
??????????????隨后客戶端進入SYN-SENT階段乏盐；
???????②.服務(wù)器端接收到來自客戶端的TCP報文之后佳窑，結(jié)束LISTEN階段。并返回一段TCP報文父能，其中：
??????????????標(biāo)志位為SYN和ACK神凑，表示“確認客戶端的報文seq序號有效，服務(wù)器能正常接收客戶端發(fā)送的數(shù)據(jù)何吝，并同意創(chuàng)建新連接”（即告訴客戶端耙厚，服務(wù)器收到了你的數(shù)據(jù)）；
??????????????序號為seq=y岔霸；
??????????????確認號為ack=x+1薛躬，表示收到客戶端的序號seq并將其值加1作為自己確認號ack的值；隨后服務(wù)器端進入SYN-RCVD階段呆细。
???????③.客戶端接收到來自服務(wù)器端的確認收到數(shù)據(jù)的TCP報文之后型宝，明確了從客戶端到服務(wù)器的數(shù)據(jù)傳輸是正常的，結(jié)束SYN-SENT階段絮爷。并返回最后一段TCP報文趴酣。其中：
??????????????標(biāo)志位為ACK，表示“確認收到服務(wù)器端同意連接的信號”（即告訴服務(wù)器坑夯，我知道你收到我發(fā)的數(shù)據(jù)了）岖寞；
??????????????序號為seq=x+1，表示收到服務(wù)器端的確認號ack柜蜈，并將其值作為自己的序號值仗谆；
??????????????確認號為ack=y+1指巡，表示收到服務(wù)器端序號seq，并將其值加1作為自己的確認號ack的值隶垮；
??????????????隨后客戶端進入ESTABLISHED階段藻雪。
???????服務(wù)器收到來自客戶端的“確認收到服務(wù)器數(shù)據(jù)”的TCP報文之后，明確了從服務(wù)器到客戶端的數(shù)據(jù)傳輸是正常的狸吞。結(jié)束SYN-SENT階段勉耀，進入ESTABLISHED階段。
???????在客戶端與服務(wù)器端傳輸?shù)腡CP報文中蹋偏，雙方的確認號ack和序號seq的值便斥，都是在彼此ack和seq值的基礎(chǔ)上進行計算的，這樣做保證了TCP報文傳輸?shù)倪B貫性威始。一旦出現(xiàn)某一方發(fā)出的TCP報文丟失枢纠，便無法繼續(xù)"握手"，以此確保了"三次握手"的順利完成字逗。
???????此后客戶端和服務(wù)器端進行正常的數(shù)據(jù)傳輸京郑。這就是“三次握手”的過程宅广。

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

???????防止服務(wù)器端因接收了早已失效的連接請求報文，從而一直等待客戶端請求跟狱，最終導(dǎo)致形成死鎖俭厚、浪費資源。
???????可以這樣理解：“第三次握手”是客戶端向服務(wù)器端發(fā)送數(shù)據(jù)驶臊，這個數(shù)據(jù)就是要告訴服務(wù)器挪挤，客戶端有沒有收到服務(wù)器“第二次握手”時傳過去的數(shù)據(jù)。若發(fā)送的這個數(shù)據(jù)是“收到了”的信息关翎，接收后服務(wù)器就正常建立TCP連接扛门，否則建立TCP連接失敗，服務(wù)器關(guān)閉連接端口纵寝。由此減少服務(wù)器開銷和接收到失效請求發(fā)生的錯誤论寨。

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

???????假定A向B發(fā)送一個連接請求爽茴，由于一些原因葬凳，導(dǎo)致A發(fā)出的連接請求在一個網(wǎng)絡(luò)節(jié)點逗留了比較多的時間。此時A會將此連接請求作為無效處理室奏，又重新向B發(fā)起了一次新的連接請求火焰，B正常收到此連接請求后建立了連接，數(shù)據(jù)傳輸完成后釋放了連接胧沫。如果此時A發(fā)出的第一次請求又到達了B昌简，B會以為A又發(fā)起了一次連接請求占业，如果是兩次握手：此時連接就建立了，B會一直等待A發(fā)送數(shù)據(jù)江场，從而白白浪費B的資源纺酸。 如果是三次握手：由于A沒有發(fā)起連接請求，也就不會理會B的連接響應(yīng)址否，B沒有收到A的確認連接餐蔬，就會關(guān)閉掉本次連接。

b.四次揮手

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

2.png

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

???????TCP建立連接時之所以只需要"三次握手"诊杆，是因為在第二次"握手"過程中，服務(wù)器端發(fā)送給客戶端的TCP報文是以SYN與ACK作為標(biāo)志位的何陆。SYN是請求連接標(biāo)志晨汹，表示服務(wù)器端同意建立連接；ACK是確認報文贷盲，表示告訴客戶端淘这，服務(wù)器端收到了它的請求報文。
???????即SYN建立連接報文與ACK確認接收報文是在同一次"握手"當(dāng)中傳輸?shù)墓剩?三次握手"不多也不少铝穷，正好讓雙方明確彼此信息互通。
???????TCP釋放連接時之所以需要“四次揮手”佳魔，是因為FIN釋放連接報文與ACK確認接收報文是分別由第二次和第三次"握手"傳輸?shù)氖锬簟楹谓⑦B接時一起傳輸，釋放連接時卻要分開傳輸鞠鲜？
???????建立連接時宁脊，被動方服務(wù)器端結(jié)束CLOSED階段進入“握手”階段并不需要任何準(zhǔn)備，可以直接返回SYN和ACK報文贤姆，開始建立連接榆苞。
???????釋放連接時，被動方服務(wù)器突然收到主動方客戶端釋放連接的請求時并不能立即釋放連接霞捡，因為還有必要的數(shù)據(jù)需要處理坐漏，所以服務(wù)器先返回ACK確認收到報文，經(jīng)過CLOSE-WAIT階段準(zhǔn)備好釋放連接之后，才能返回FIN釋放連接報文仙畦。
???????所以是“三次握手”输涕，“四次揮手”。

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

???????為了確認服務(wù)器端是否收到客戶端發(fā)出的ACK確認報文慨畸。
???????當(dāng)客戶端發(fā)出最后的ACK確認報文時莱坎，并不能確定服務(wù)器端能夠收到該段報文。所以客戶端在發(fā)送完ACK確認報文之后寸士，會設(shè)置一個時長為2MSL的計時器檐什。
???????MSL指的是Maximum Segment Lifetime：一段TCP報文在傳輸過程中的最大生命周期。2MSL即是服務(wù)器端發(fā)出為FIN報文和客戶端發(fā)出的ACK確認報文所能保持有效的最大時長弱卡。
???????服務(wù)器端在1MSL內(nèi)沒有收到客戶端發(fā)出的ACK確認報文乃正，就會再次向客戶端發(fā)出FIN報文；
???????如果客戶端在2MSL內(nèi)婶博，再次收到了來自服務(wù)器端的FIN報文瓮具，說明服務(wù)器端由于各種原因沒有接收到客戶端發(fā)出的ACK確認報文》踩耍客戶端再次向服務(wù)器端發(fā)出ACK確認報文名党，計時器重置，重新開始2MSL的計時挠轴；
???????如果客戶端在2MSL內(nèi)沒有再次收到來自服務(wù)器端的FIN報文传睹，說明服務(wù)器端正常接收了ACK確認報文，客戶端可以進入CLOSED階段岸晦，完成“四次揮手”欧啤。
???????所以，客戶端要經(jīng)歷時長為2SML的TIME-WAIT階段启上；這也是為什么客戶端比服務(wù)器端晚進入CLOSED階段的原因邢隧。

三.HTTP協(xié)議

???????HTTP協(xié)議屬于應(yīng)用層，采用請求->響應(yīng)的工作方式碧绞，半雙工工作模式(可以發(fā)府框，可以收吱窝，不能同時)讥邻，長/短連接(http1.1默認是長連接，http1.0是短連接)工作方式如下：

3.png

???????請求的報文結(jié)構(gòu)如下：

4.png

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

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

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

Https通信流程

image.png

Http與Https的區(qū)別

5.png

四.Socket

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

6.png

???????1.Socket不是一種協(xié)議笨农，而是一個編程調(diào)用接口（API），屬于傳輸層（主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸）吁脱；
???????2.通過Socket，我們才能在Andorid平臺上通過 TCP/IP協(xié)議進行開發(fā)彬向；
???????3.對用戶來說兼贡，只需調(diào)用Socket去組織數(shù)據(jù)，以符合指定的協(xié)議娃胆，即可通信遍希；

建立socket通信過程

7.png

Socket 與 Http 對比

???????Socket屬于傳輸層，因為 TCP / IP協(xié)議屬于傳輸層里烦，解決的是數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸?shù)膯栴}凿蒜；
???????HTTP協(xié)議 屬于 應(yīng)用層，解決的是如何包裝數(shù)據(jù)胁黑；
???????由于二者不屬于同一層面废封，所以本來是沒有可比性的。但隨著發(fā)展丧蘸，默認的Http里封裝了下面幾層的使用漂洋，所以才會出現(xiàn)Socket & HTTP協(xié)議的對比：（主要是工作方式的不同）：
???????Http：采用請求->響應(yīng)方式。
???????即建立網(wǎng)絡(luò)連接后力喷，當(dāng)客戶端向服務(wù)器發(fā)送請求后刽漂，服務(wù)器端才能向客戶端返回數(shù)據(jù)∪吲常可理解為：是客戶端有需要才進行通信
???????Socket：采用服務(wù)器主動發(fā)送數(shù)據(jù)的方式
???????即建立網(wǎng)絡(luò)連接后爽冕，服務(wù)器可主動發(fā)送消息給客戶端，而不需要由客戶端向服務(wù)器發(fā)送請求披蕉，可理解為：是服務(wù)器端有需要才進行通信
???????很多情況下，需要服務(wù)器端主動向客戶端推送數(shù)據(jù)，保持客戶端與服務(wù)器數(shù)據(jù)的實時與同步没讲。此時若雙方建立的是Socket連接眯娱，服務(wù)器就可以直接將數(shù)據(jù)傳送給客戶端；若雙方建立的是HTTP連接爬凑，則服務(wù)器需要等到客戶端發(fā)送一次請求后才能將數(shù)據(jù)傳回給客戶端徙缴，因此，客戶端定時向服務(wù)器端發(fā)送連接請求嘁信， 不僅可以保持在線于样，同時也是在“詢問”服務(wù)器是否有新的數(shù)據(jù)，如果有就將數(shù)據(jù)傳給客戶端潘靖。

心跳機制

???????正常連接斷開客戶端會給服務(wù)端發(fā)送一個fin包穿剖，服務(wù)端收到fin包后才會知道連接斷開。 而斷網(wǎng)斷電時客戶端無法發(fā)送fin包給服務(wù)端卦溢，所以服務(wù)端沒辦法檢測到客戶端已經(jīng)斷線糊余。
???????為了緩解這個問題，服務(wù)端需要有個心跳邏輯单寂，就是服務(wù)端檢測到某個客戶端多久沒發(fā)送任何數(shù)據(jù)過來就認為客戶端已經(jīng)斷開贬芥， 這需要客戶端定時向服務(wù)端發(fā)送心跳數(shù)據(jù)維持連接。
???????心跳機制實現(xiàn)
???????長連接的實現(xiàn)：心跳機制宣决，應(yīng)用層協(xié)議大多都有HeartBeat機制蘸劈，通常是客戶端每隔一小段時間向服務(wù)器發(fā)送一個數(shù)據(jù)包，通知服務(wù)器自己仍然在線尊沸。并傳輸一些可能必要的數(shù)據(jù)昵时。使用心跳包的典型協(xié)議是IM，比如QQ/MSN/飛信等協(xié)議
???????1椒丧、在TCP的機制里面壹甥，本身是存在有心跳包的機制的，也就是TCP的選項：SO_KEEPALIVE壶熏。 系統(tǒng)默認是設(shè)置的2小時的心跳頻率句柠。但是它檢查不到機器斷電、網(wǎng)線拔出棒假、防火墻這些斷線溯职。 而且邏輯層處理斷線可能也不是那么好處理。一般帽哑，如果只是用于泵站疲活還是可以的。通過使用TCP的KeepAlive機制（修改那個time參數(shù)）妻枕，可以讓連接每隔一小段時間就產(chǎn)生一些ack包僻族，以降低被踢掉的風(fēng)險粘驰，當(dāng)然，這樣的代價是額外的網(wǎng)絡(luò)和CPU負擔(dān)述么。
???????2蝌数、應(yīng)用層心跳機制實現(xiàn)。

Cookie與Session的作用和原理

???????Session是在服務(wù)端保存的一個數(shù)據(jù)結(jié)構(gòu)度秘，用來跟蹤用戶的狀態(tài)顶伞，這個數(shù)據(jù)可以保存在集群、數(shù)據(jù)庫剑梳、文件中唆貌。
???????Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息垢乙，也是實現(xiàn)Session的一種方式锨咙。
???????Session：
???????由于HTTP協(xié)議是無狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶的狀態(tài)時就需要用某種機制來識具體的用戶侨赡，這個機制就是Session蓖租。典型的場景比如購物車，當(dāng)你點擊下單按鈕時羊壹，由于HTTP協(xié)議無狀態(tài)蓖宦，所以并不知道是哪個用戶操作的，所以服務(wù)端要為特定的用戶創(chuàng)建了特定的Session油猫，用于標(biāo)識這個用戶稠茂，并且跟蹤用戶，這樣才知道購物車里面有幾本書情妖。
???????Session是保存在服務(wù)端的睬关，有一個唯一標(biāo)識。在服務(wù)端保存Session的方法很多毡证，內(nèi)存电爹、數(shù)據(jù)庫、文件都有料睛。集群的時候也要考慮Session的轉(zhuǎn)移丐箩，在大型的網(wǎng)站，一般會有專門的Session服務(wù)器集群恤煞，用來保存用戶會話屎勘，這個時候 Session 信息都是放在內(nèi)存的。
???????具體到Web中的Session指的就是用戶在瀏覽某個網(wǎng)站時居扒，從進入網(wǎng)站到瀏覽器關(guān)閉所經(jīng)過的這段時間概漱，也就是用戶瀏覽這個網(wǎng)站所花費的時間。因此從上述的定義中我們可以看到喜喂，Session實際上是一個特定的時間概念瓤摧。
???????當(dāng)客戶端訪問服務(wù)器時竿裂，服務(wù)器根據(jù)需求設(shè)置Session，將會話信息保存在服務(wù)器上姻灶，同時將標(biāo)示Session的SessionId傳遞給客戶端瀏覽器铛绰，瀏覽器將這個SessionId保存在內(nèi)存中诈茧，我們稱之為無過期時間的Cookie产喉。瀏覽器關(guān)閉后，這個Cookie就會被清掉敢会，它不會存在于用戶的Cookie臨時文件曾沈。以后瀏覽器每次請求都會額外加上這個參數(shù)值，服務(wù)器會根據(jù)這個SessionId鸥昏，就能取得客戶端的數(shù)據(jù)信息塞俱。
???????如果客戶端瀏覽器意外關(guān)閉，服務(wù)器保存的Session數(shù)據(jù)不是立即釋放吏垮，此時數(shù)據(jù)還會存在障涯，只要我們知道那個SessionId，就可以繼續(xù)通過請求獲得此Session的信息膳汪，因為此時后臺的Session還存在唯蝶，當(dāng)然我們可以設(shè)置一個Session超時時間，一旦超過規(guī)定時間沒有客戶端請求時遗嗽，服務(wù)器就會清除對應(yīng)SessionId的Session信息粘我。
???????Cookie
???????Cookie是由服務(wù)器端生成，發(fā)送給User-Agent（一般是web瀏覽器）痹换，瀏覽器會將Cookie的key/value保存到某個目錄下的文本文件內(nèi)征字，下次請求同一網(wǎng)站時就發(fā)送該Cookie給服務(wù)器（前提是瀏覽器設(shè)置為啟用Cookie）。Cookie名稱和值可以由服務(wù)器端開發(fā)自己定義娇豫，對于JSP而言也可以直接寫入Sessionid匙姜，這樣服務(wù)器可以知道該用戶是否合法用戶以及是否需要重新登錄等。

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

???????在前面講到冯痢，Https在通信過程中用到了非對稱加密及服務(wù)端會發(fā)送ssl證書給客戶端氮昧，客戶端需要驗證證書的合法性，然后進行下一次通信系羞。

1.非對稱加密

???????即公鑰公開給任何人郭计，私鑰自己保留，用公鑰加密椒振，用私鑰解密昭伸，用一張圖來形象的表示非對稱加密：

非對稱加密.png

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

???????Https在通信過程中客戶端收到服務(wù)端的SSL證書后，會驗證其合法性澎迎，關(guān)于數(shù)字證書生成及驗證流程庐杨，用一張圖來表示一下工作過程：

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

3.中間人攻擊

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

中間人攻擊.png