????????小猿的某同事不甘于現(xiàn)狀凸克，近期到處投簡歷面試议蟆。某天，小猿只見某灰頭土臉萎战、唉聲嘆氣咐容，于是小猿本著看熱鬧不嫌事兒大的心態(tài)，一臉壞笑湊上去問：“大佬蚂维，最近面試咋樣戳粒，是不是都拿好幾個(gè)offer了~^_^”，某答道：“什么呀虫啥，面?zhèn)€試咋就這么難蔚约，一道面試題硬是讓面試官扯出了整個(gè)計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)圖譜，也是沒誰了~”涂籽，小猿好奇問：“啥題炊琉，啥題~”，某答：“爛大街的一道題又活，面試前也準(zhǔn)備了，唉锰悼，你說為啥面試官就能從這道題目扯出一堆題目...”(此處省略一萬字)
????????接下來小猿就給大家說說某遇到的這道題柳骄，還有它牽扯出的整個(gè)計(jì)算機(jī)網(wǎng)絡(luò)的知識(shí)圖譜。廢話不多說箕般，直接上題目
????????題目描述一：請(qǐng)說說HTTP請(qǐng)求的整個(gè)過程
????????題目描述二：當(dāng)你在瀏覽器中輸出某個(gè)URL耐薯，按下回車后都經(jīng)歷了什么樣的流程
????????題目描述三：請(qǐng)簡單介紹一下HTTP是怎么工作的
????????相信各位猿對(duì)這道題應(yīng)該并不陌生，而且網(wǎng)上一搜一堆的講解與答案，但是某遇到的這個(gè)大牛面試官曲初，卻可以從某的回答中延伸出更多的問題体谒，如果想要過關(guān)，還是要對(duì)整個(gè)計(jì)算機(jī)網(wǎng)絡(luò)的知識(shí)體系有比較深刻的理解才行臼婆。下面先貼出小猿對(duì)這個(gè)題目的理解和可能從這道題目引出的計(jì)算機(jī)網(wǎng)絡(luò)的知識(shí)點(diǎn)抒痒，然后小猿對(duì)這些知識(shí)點(diǎn)慢慢的給大家分析。
小猿對(duì)題 目的理解：
DNS解析：如果URL中是網(wǎng)址颁褂，需要向?qū)@個(gè)網(wǎng)址進(jìn)行域名解析故响，得到相應(yīng)的IP地址，請(qǐng)求會(huì)逐層查詢DNS緩存得到目的IP地址（DNS緩存由近到遠(yuǎn)依次是：瀏覽器緩存颁独、系統(tǒng)緩存彩届、路由器緩存、IPS服務(wù)器緩存誓酒、根域名服務(wù)器緩存樟蠕、頂級(jí)域名服務(wù)器緩存）
TCP連接：根據(jù)IP地址和斷開，找到對(duì)應(yīng)的服務(wù)器靠柑，通過TCP的三次握手建立連接
發(fā)送HTTP請(qǐng)求：建立TCP連接后發(fā)起HTTP請(qǐng)求
服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文：服務(wù)器根據(jù)請(qǐng)求參數(shù)得到返回結(jié)果寨辩，并返回HTTP報(bào)文
瀏覽器解析渲染頁面：瀏覽器得到報(bào)文，解析HTML代碼病往，并請(qǐng)求HTML代碼中的資源（例如js捣染、css等）茸塞，然后渲染頁面
連接結(jié)束：TCP4次揮手芝加，HTTP斷開連接
知識(shí)圖譜
OSI七層架構(gòu)
七層結(jié)構(gòu)簡介：
7層結(jié)構(gòu)數(shù)據(jù)傳輸流程：
詳細(xì)介紹每層的功能和
應(yīng)用層（Application Layer）
是計(jì)算機(jī)用戶，以及各種應(yīng)用程序和網(wǎng)絡(luò)之間的接口：
是用戶與網(wǎng)絡(luò)堪滨，以及應(yīng)用程序與網(wǎng)絡(luò)間的直接接口畔勤，使得用戶能夠與網(wǎng)絡(luò)進(jìn)行交互式聯(lián)系蕾各。
實(shí)現(xiàn)各種服務(wù)：該層具有的各種應(yīng)用程序可以完成和實(shí)現(xiàn)用戶請(qǐng)求的各種服務(wù)。
該層還負(fù)責(zé)協(xié)調(diào)各個(gè)應(yīng)用程序間的工作庆揪。
應(yīng)用層為用戶提供的服務(wù)和協(xié)議有：文件服務(wù)式曲、目錄服務(wù)、文件傳輸服務(wù)（FTP）缸榛、遠(yuǎn)程登錄服務(wù)（Telnet）吝羞、電子郵件服務(wù)（E-mail）、打印服務(wù)内颗、安全服務(wù)钧排、網(wǎng)絡(luò)管理服務(wù)、數(shù)據(jù)庫服務(wù)等均澳。
表示層（Presentation Layer）
對(duì)來自應(yīng)用層的命令和數(shù)據(jù)進(jìn)行解釋恨溜，對(duì)各種語法賦予相應(yīng)的含義符衔，并按照一定的格式傳送給會(huì)話層。
主要功能：數(shù)據(jù)格式處理糟袁、編碼判族、壓縮解壓、加密解密等项戴，具體說明如下：
數(shù)據(jù)格式處理：協(xié)商和建立數(shù)據(jù)交換的格式形帮，解決各應(yīng)用程序之間在數(shù)據(jù)格式表示上的差異。
數(shù)據(jù)的編碼：處理字符集和數(shù)字的轉(zhuǎn)換肯尺。例如由于用戶程序中的數(shù)據(jù)類型（整型或?qū)嵭臀衷怠⒂蟹?hào)或無符號(hào)等）、用戶標(biāo)識(shí)等都可以有不同的表示方式则吟，因此槐臀，在設(shè)備之間需要具有在不同字符集或格式之間轉(zhuǎn)換的功能。
壓縮和解壓縮：為了減少數(shù)據(jù)的傳輸量氓仲，這一層還負(fù)責(zé)數(shù)據(jù)的壓縮與恢復(fù)水慨。
數(shù)據(jù)的加密和解密：可以提高網(wǎng)絡(luò)的安全性。
-
會(huì)話層（Session Layer）
其任務(wù)就是組織和協(xié)調(diào)兩個(gè)會(huì)話進(jìn)程之間的通信敬扛，并對(duì)數(shù)據(jù)交換進(jìn)行管理晰洒，具體如下：
會(huì)話管理：允許用戶在兩個(gè)實(shí)體設(shè)備之間建立、維持和終止會(huì)話啥箭，并支持它們之間的數(shù)據(jù)交換谍珊。例如提供單方向會(huì)話或雙向同時(shí)會(huì)話，并管理會(huì)話中的發(fā)送順序急侥，以及會(huì)話所占用時(shí)間的長短砌滞。
會(huì)話流量控制：提供會(huì)話流量控制和交叉會(huì)話功能。
尋址：使用遠(yuǎn)程地址建立會(huì)話連接坏怪。
出錯(cuò)控制：從邏輯上講會(huì)話層主要負(fù)責(zé)數(shù)據(jù)交換的建立贝润、保持和終止，但實(shí)際的工作卻是接收來自傳輸層的數(shù)據(jù)铝宵，并負(fù)責(zé)糾正錯(cuò)誤打掘。會(huì)話控制和遠(yuǎn)程過程調(diào)用均屬于這一層的功能。但應(yīng)注意鹏秋，此層檢查的錯(cuò)誤不是通信介質(zhì)的錯(cuò)誤尊蚁，而是磁盤空間、打印機(jī)缺紙等類型的高級(jí)錯(cuò)誤侣夷。
傳輸層（Transport Layer）
向用戶提供可靠的端到端的差錯(cuò)和流量控制横朋，保證報(bào)文的正確傳輸。傳輸層的作用是向高層屏蔽下層數(shù)據(jù)通信的細(xì)節(jié)惜纸，即向用戶透明地傳送報(bào)文叶撒。
傳輸連接管理：提供建立、維護(hù)和拆除傳輸連接的功能耐版。傳輸層在網(wǎng)絡(luò)層的基礎(chǔ)上為高層提供“面向連接”和“面向無接連”的兩種服務(wù)祠够。
處理傳輸差錯(cuò)：提供可靠的“面向連接”和不太可靠的“面向無連接”的數(shù)據(jù)傳輸服務(wù)、差錯(cuò)控制和流量控制粪牲。在提供“面向連接”服務(wù)時(shí)古瓤，通過這一層傳輸?shù)臄?shù)據(jù)將由目標(biāo)設(shè)備確認(rèn)，如果在指定的時(shí)間內(nèi)未收到確認(rèn)信息腺阳，數(shù)據(jù)將被重發(fā)落君。
監(jiān)控服務(wù)質(zhì)量。
該層常見的協(xié)議：TCP/IP中的TCP協(xié)議亭引、Novell網(wǎng)絡(luò)中的SPX協(xié)議和微軟的NetBIOS/NetBEUI協(xié)議绎速。
網(wǎng)絡(luò)層（Network Layer）
通過路由選擇算法，為報(bào)文或分組通過通信子網(wǎng)選擇最適當(dāng)?shù)穆窂?/p>
數(shù)據(jù)鏈路層的數(shù)據(jù)在這一層被轉(zhuǎn)換為數(shù)據(jù)包焙蚓，然后通過路徑選擇纹冤、分段組合、順序购公、進(jìn)/出路由等控制萌京，將信息從一個(gè)網(wǎng)絡(luò)設(shè)備傳送到另一個(gè)網(wǎng)絡(luò)設(shè)備。
尋址：數(shù)據(jù)鏈路層中使用的物理地址（如MAC地址）僅解決網(wǎng)絡(luò)內(nèi)部的尋址問題宏浩。在不同子網(wǎng)之間通信時(shí)知残，為了識(shí)別和找到網(wǎng)絡(luò)中的設(shè)備，每一子網(wǎng)中的設(shè)備都會(huì)被分配一個(gè)唯一的地址比庄。由于各子網(wǎng)使用的物理技術(shù)可能不同求妹，因此這個(gè)地址應(yīng)當(dāng)是邏輯地址（如IP地址）。
交換：規(guī)定不同的信息交換方式印蔗。常見的交換技術(shù)有：線路交換技術(shù)和存儲(chǔ)轉(zhuǎn)發(fā)技術(shù)扒最，后者又包括報(bào)文交換技術(shù)和分組交換技術(shù)。
路由算法：當(dāng)源節(jié)點(diǎn)和目的節(jié)點(diǎn)之間存在多條路徑時(shí)华嘹，本層可以根據(jù)路由算法吧趣，通過網(wǎng)絡(luò)為數(shù)據(jù)分組選擇最佳路徑，并將信息從最合適的路徑由發(fā)送端傳送到接收端耙厚。
連接服務(wù)：與數(shù)據(jù)鏈路層流量控制不同的是强挫，前者控制的是網(wǎng)絡(luò)相鄰節(jié)點(diǎn)間的流量，后者控制的是從源節(jié)點(diǎn)到目的節(jié)點(diǎn)間的流量薛躬。其目的在于防止阻塞俯渤，并進(jìn)行差錯(cuò)檢測(cè)。
數(shù)據(jù)鏈路層是解決同一網(wǎng)絡(luò)內(nèi)節(jié)點(diǎn)之間的通信型宝，而網(wǎng)絡(luò)層主要解決不同子網(wǎng)間的通信八匠。例如在廣域網(wǎng)之間通信時(shí)絮爷，必然會(huì)遇到路由（即兩節(jié)點(diǎn)間可能有多條路徑）選擇問題。?
數(shù)據(jù)鏈路層（Data Link Layer）
物理層提供的比特流的基礎(chǔ)上梨树，通過差錯(cuò)控制坑夯、流量控制方法，使有差錯(cuò)的物理線路變?yōu)闊o差錯(cuò)的數(shù)據(jù)鏈路抡四，即提供可靠的通過物理介質(zhì)傳輸數(shù)據(jù)的方法柜蜈。
該層通常又被分為介質(zhì)訪問控制（MAC）和邏輯鏈路控制（LLC）兩個(gè)子層
MAC子層的主要任務(wù)是解決共享型網(wǎng)絡(luò)中多用戶對(duì)信道競爭的問題，完成網(wǎng)絡(luò)介質(zhì)的訪問控制指巡；
LLC子層的主要任務(wù)是建立和維護(hù)網(wǎng)絡(luò)連接淑履，執(zhí)行差錯(cuò)校驗(yàn)、流量控制和鏈路控制藻雪。數(shù)據(jù)鏈路層的具體工作是接收來自物理層的位流形式的數(shù)據(jù)秘噪，并封裝成幀，傳送到上一層阔涉；同樣缆娃，也將來自上層的數(shù)據(jù)幀，拆裝為位流形式的數(shù)據(jù)轉(zhuǎn)發(fā)到物理層瑰排；并且贯要，還負(fù)責(zé)處理接收端發(fā)回的確認(rèn)幀的信息，以便提供可靠的數(shù)據(jù)傳輸椭住。
物理層（Physical Layer）
利用傳輸介質(zhì)為數(shù)據(jù)鏈路層提供物理連接崇渗，實(shí)現(xiàn)比特流的透明傳輸。
物理層的作用是實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送京郑，盡可能屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異宅广。使其上面的數(shù)據(jù)鏈路層不必考慮網(wǎng)絡(luò)的具體傳輸介質(zhì)是什么。
分享一張大而全的七層協(xié)議框架圖
TCP/IP協(xié)議-OSI的一種“實(shí)現(xiàn)”
傳輸控制協(xié)議TCP簡介
面向連接的些举、可靠的跟狱、基于字節(jié)流的傳輸層通信協(xié)議
將應(yīng)用的數(shù)據(jù)流分割成報(bào)文段并發(fā)送個(gè)給目標(biāo)節(jié)點(diǎn)的TCP層，
分段的長度受數(shù)據(jù)鏈路層MTU(最大傳輸單元户魏，Maximum Transmission Unit)的限制
TCP單個(gè)數(shù)據(jù)報(bào)的最大長度稱為最大段尺寸MSS驶臊；
在TCP三次握手建立連接的時(shí)候，雙方會(huì)商量傳輸中MSS的大械鸪蟆关翎；
數(shù)據(jù)包都有序號(hào)以保證消息接收的順序，對(duì)方收到則發(fā)送ACK確認(rèn)鸠信，未收到則重傳
使用奇偶校驗(yàn)和來校驗(yàn)數(shù)據(jù)在傳輸過程中是否有誤
TCP報(bào)文頭
-
SourcePort：源端口纵寝，占用2個(gè)字節(jié)。源端口和IP地址的作用是標(biāo)識(shí)報(bào)文的返回地址星立。
p.s. IP可以唯一表示一臺(tái)主機(jī)爽茴，TCP協(xié)議和端口號(hào)可以唯一表示主機(jī)中的一個(gè)進(jìn)程葬凳；所以我們可以根據(jù)IP地址+協(xié)議+端口號(hào)唯一表示網(wǎng)絡(luò)中的一個(gè)進(jìn)程（即Socket的工作原理）。
DestinationPort：目的端口室奏，占用2個(gè)字節(jié)沮明；指明接收方計(jì)算機(jī)上的應(yīng)用程序的端口。
SequenceNumber（序號(hào)seq）：本報(bào)文段發(fā)送的數(shù)據(jù)組的第一個(gè)字節(jié)的序號(hào)窍奋。e.g.一個(gè)報(bào)文段的序號(hào)為300，此報(bào)文段數(shù)據(jù)部分共有100字節(jié)酱畅，則下一個(gè)報(bào)文段的序號(hào)為400琳袄。所以序號(hào)確保了TCP傳輸?shù)挠行蛐浴?/p>
AcknowledgmentNumber（確認(rèn)號(hào)ack）：指明下一個(gè)期待收到的字節(jié)序號(hào)，表明該序號(hào)之前的所有數(shù)據(jù)已經(jīng)正確無誤的收到纺酸。確認(rèn)號(hào)只有當(dāng)ACK標(biāo)志為1時(shí)才有效窖逗。
offset（數(shù)據(jù)偏移）：占用4bits。由于首部可能含有可選項(xiàng)內(nèi)容餐蔬，因此TCP報(bào)頭的長度是不確定的碎紊，報(bào)頭不包含任何任選字段則長度為20字節(jié)，4位首部長度字段所能表示的最大值為1111樊诺，轉(zhuǎn)化為10進(jìn)制為15仗考，15*32/8 = 60，故報(bào)頭最大長度為60字節(jié)词爬。首部長度也叫數(shù)據(jù)偏移秃嗜，是因?yàn)槭撞块L度實(shí)際上指示了數(shù)據(jù)區(qū)在報(bào)文段中的起始偏移值。
Reserved（保留字節(jié)）：為將來定義新的用途保留顿膨，現(xiàn)在一般置0锅锨。
TCP Flags（TCP控制位）
SYN：同步序號(hào)，用于建立連接過程恋沃，在連接請(qǐng)求中必搞，SYN=1和ACK=0表示該數(shù)據(jù)段沒有使用捎帶的確認(rèn)域，而連接應(yīng)答捎帶一個(gè)確認(rèn)囊咏，即SYN=1和ACK=1恕洲。?
ACK：確認(rèn)序號(hào)標(biāo)志，為1時(shí)表示確認(rèn)號(hào)有效匆笤，為0表示報(bào)文中不含確認(rèn)信息研侣，忽略確認(rèn)號(hào)字段。?
FIN：finish標(biāo)志炮捧，用于釋放連接庶诡，為1時(shí)表示發(fā)送方已經(jīng)沒有數(shù)據(jù)發(fā)送了，即關(guān)閉本方數(shù)據(jù)流咆课。
URG：緊急指針標(biāo)志末誓，為1時(shí)表示緊急指針有效扯俱，為0則忽略緊急指針。?
PSH：push標(biāo)志喇澡，為1表示是帶有push標(biāo)志的數(shù)據(jù)迅栅，指示接收方在接收到該報(bào)文段以后，應(yīng)盡快將這個(gè)報(bào)文段交給應(yīng)用程序晴玖，而不是在緩沖區(qū)排隊(duì)读存。?
RST：重置連接標(biāo)志，用于重置由于主機(jī)崩潰或其他原因而出現(xiàn)錯(cuò)誤的連接呕屎∪貌荆或者用于拒絕非法的報(bào)文段和拒絕連接請(qǐng)求。?
CWR：Congestion Window Reduced
ECE：ECN echo
Window（窗口）：滑動(dòng)窗口大小秀睛，用來告知發(fā)送端接受端的緩存大小尔当，以此控制發(fā)送端發(fā)送數(shù)據(jù)的速率，從而達(dá)到流量控制蹂安。窗口大小時(shí)一個(gè)16bit字段椭迎，因而窗口大小最大為65535。
Checksum（校驗(yàn)和）：奇偶校驗(yàn)田盈，此校驗(yàn)和是對(duì)整個(gè)的?TCP?報(bào)文段畜号，包括?TCP?頭部和?TCP?數(shù)據(jù)，以 16位進(jìn)行計(jì)算所得允瞧。由發(fā)送端計(jì)算和存儲(chǔ)弄兜，并由接收端進(jìn)行驗(yàn)證。
UrgentPointer（緊急指針）：只有當(dāng)?URG?標(biāo)志置?1?時(shí)緊急指針才有效瓷式。緊急指針是一個(gè)正的偏移量替饿，和順序號(hào)字段中的值相加表示緊急數(shù)據(jù)最后一個(gè)字節(jié)的序號(hào)。?TCP?的緊急方式是發(fā)送端向另一端發(fā)送緊急數(shù)據(jù)的一種方式贸典。
TCP Options（選項(xiàng)與填充）如果沒有選項(xiàng)视卢，則TCP頭長度是20字節(jié)，TCP選項(xiàng)最大是40個(gè)字節(jié)。最常見的可選字段是最長報(bào)文大小，又稱為MSS（Maximum Segment Size）穷当，每個(gè)連接方通常都在通信的第一個(gè)報(bào)文段（為建立連接而設(shè)置SYN標(biāo)志為1的那個(gè)段）中指明這個(gè)選項(xiàng)持偏，它表示本端所能接受的最大報(bào)文段的長度劝堪。選項(xiàng)長度不一定是32位的整數(shù)倍，所以要加填充位，即在這個(gè)字段中加入額外的零，以保證TCP頭是32的整數(shù)倍鳞芙。
Data（數(shù)據(jù)部分）TCP?報(bào)文段中的數(shù)據(jù)部分是可選的。在一個(gè)連接建立和一個(gè)連接終止時(shí)，雙方交換的報(bào)文段僅有?TCP?首部原朝。如果一方?jīng)]有數(shù)據(jù)要發(fā)送驯嘱，也使用沒有任何數(shù)據(jù)的首部來確認(rèn)收到的數(shù)據(jù)。在處理超時(shí)的許多情況中喳坠，也會(huì)發(fā)送不帶任何數(shù)據(jù)的報(bào)文段鞠评。
說說TCP的三次握手
在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)壕鹉，采用三次握手建立一個(gè)連接
第一次握手：建立連接時(shí)剃幌，客戶端發(fā)送SYN包到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)晾浴，等待服務(wù)器確認(rèn)锥忿。這里發(fā)送的SYN包，SYN標(biāo)志位為1怠肋，seq序號(hào)初始為x
第二次握手：服務(wù)器收到SYN包，必須確認(rèn)客戶的SYN淹朋，同時(shí)自己也發(fā)送一個(gè)SYN包給客戶端笙各，此時(shí)服務(wù)端進(jìn)入SYN_RECV狀態(tài)。這里服務(wù)端發(fā)送的SYN包中SYN標(biāo)志位和ACK標(biāo)志位都是1础芍，seq序號(hào)初始為y杈抢，ack為x+1（表示客戶端下次再發(fā)送包seq從x+1開始）
第三次握手：客戶端收到服務(wù)器的SYN+ACK的包，向服務(wù)器發(fā)送確認(rèn)包仑性，此包ACK標(biāo)志位1惶楼，seq序號(hào)為x+1，ack為y+1（表示服務(wù)端下一次發(fā)送數(shù)據(jù)seq從y+1開始）诊杆。此包發(fā)送完畢歼捐，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成三次握手晨汹，開始數(shù)據(jù)傳送豹储。
為什么需要三次握手才能建立連接
為了初始化SequenceNumber
為了防止服務(wù)器端開啟一些無用的連接增加服務(wù)器開銷以及防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤淘这。
三次握手的隱患-SYN Flood
問題描述
Server收到Client的SYN剥扣，回復(fù)SYN-ACK的時(shí)候未收到ACK確認(rèn)
Server不斷重試直至超時(shí)，Linux默認(rèn)等待63秒才斷開連接（Linux默認(rèn)重試5次铝穷，每次等待時(shí)間翻倍钠怯，第一次重試前等待時(shí)間為1秒，第五次重試后等待時(shí)間是32秒曙聂，然后才斷開連接）
惡意攻擊者晦炊，不斷向服務(wù)端發(fā)送SYN請(qǐng)求后立刻下線，服務(wù)器端會(huì)等待63秒后才斷開連接，進(jìn)而導(dǎo)致服務(wù)端資源耗盡刽锤，讓正常的連接請(qǐng)求不能處理
針對(duì)SYN Flood的防護(hù)措施
針對(duì)上述問題的解決辦法
SYN隊(duì)列滿后镊尺，通過tcp_syncookies參數(shù)回發(fā)SYN Cookie
如果是正常連接，Client會(huì)回發(fā)SYN Cookie給服務(wù)端并思；如果是惡意攻擊庐氮，因?yàn)镃lient已經(jīng)下線，則不會(huì)返回宋彼。
正常連接返回SYN Cookie后弄砍，可以直接建立連接
建立連接后，Client出現(xiàn)故障怎么辦
笔涮椋活機(jī)制
向?qū)Ψ桨l(fā)送币羯簦活探測(cè)報(bào)文，如果未收到響應(yīng)則繼續(xù)發(fā)送
嘗試次數(shù)達(dá)到崩晨玻活探測(cè)數(shù)仍未收到響應(yīng)衣式，則中斷連接
TCP四次揮手
揮手是為了終止連接，TCP采用四次揮手來釋放連接
第一次揮手：Client發(fā)送一個(gè)FIN檐什，用來關(guān)閉Client到Server的數(shù)據(jù)傳送碴卧，Client進(jìn)入FIN-WAIT_1狀態(tài)；
第二次揮手：Server收到FIN后乃正，發(fā)送一個(gè)ACK給client住册，確認(rèn)序號(hào)為收到序號(hào)+1（與SYN相同，一個(gè)FIN占用一個(gè)序號(hào)）瓮具，Server進(jìn)入CLOSE_WAIT狀態(tài)荧飞；Client接收到Server的FIN之后，進(jìn)入FIN_WAIT_2狀態(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ā)送一個(gè)ACK給Server蒋歌，確認(rèn)序號(hào)為收到序號(hào)+1帅掘，Server進(jìn)入CLOSED狀態(tài)，完成四次握手
為什么要有TIME_WAIT狀態(tài)
防止上一次連接中的包堂油，迷路后重新出現(xiàn)修档，影響新連接（經(jīng)過2MSL，上一次連接中所有的重復(fù)包都會(huì)消失）
可靠的關(guān)閉TCP連接府框。為的是確認(rèn)服務(wù)器端是否收到客戶端發(fā)出的ACK確認(rèn)報(bào)文吱窝。當(dāng)客戶端發(fā)出最后的ACK確認(rèn)報(bào)文時(shí)，并不能確定服務(wù)器端能夠收到該段報(bào)文。所以客戶端在發(fā)送完ACK確認(rèn)報(bào)文之后院峡，會(huì)設(shè)置一個(gè)時(shí)長為2MSL的計(jì)時(shí)器兴使。MSL指的是Maximum Segment Lifetime：一段TCP報(bào)文在傳輸過程中的最大生命周期。2MSL即是服務(wù)器端發(fā)出為FIN報(bào)文和客戶端發(fā)出的ACK確認(rèn)報(bào)文所能保持有效的最大時(shí)長照激。
服務(wù)器端在1MSL內(nèi)沒有收到客戶端發(fā)出的ACK確認(rèn)報(bào)文发魄，就會(huì)再次向客戶端發(fā)出FIN報(bào)文；
如果客戶端在2MSL內(nèi)俩垃，再次收到了來自服務(wù)器端的FIN報(bào)文励幼，說明服務(wù)器端由于各種原因沒有接收到客戶端發(fā)出的ACK確認(rèn)報(bào)文】诹客戶端再次向服務(wù)器端發(fā)出ACK確認(rèn)報(bào)文苹粟，計(jì)時(shí)器重置，重新開始2MSL的計(jì)時(shí)跃闹；
否則客戶端在2MSL內(nèi)沒有再次收到來自服務(wù)器端的FIN報(bào)文嵌削，說明服務(wù)器端正常接收了ACK確認(rèn)報(bào)文，客戶端可以進(jìn)入CLOSED階段望艺，完成“四次揮手”苛秕。
為什么需要四次握手
因?yàn)槿p工，發(fā)送方和接收方都需要FIN報(bào)文和ACK保報(bào)文
建立連接時(shí)荣茫，被動(dòng)方服務(wù)器端結(jié)束CLOSED階段進(jìn)入“握手”階段并不需要任何準(zhǔn)備，可以直接返回SYN和ACK報(bào)文场靴，開始建立連接啡莉。釋放連接時(shí)，被動(dòng)方服務(wù)器旨剥，突然收到主動(dòng)方客戶端釋放連接的請(qǐng)求時(shí)并不能立即釋放連接咧欣，因?yàn)檫€有必要的數(shù)據(jù)需要處理，所以服務(wù)器先返回ACK確認(rèn)收到報(bào)文轨帜，經(jīng)過CLOSE-WAIT階段準(zhǔn)備好釋放連接之后魄咕，才能返回FIN釋放連接報(bào)文。
服務(wù)器出現(xiàn)大量CLOSE_WAIT狀態(tài)的原因
如果一直保持在CLOSE_WAIT狀態(tài)蚌父，那么只有一種情況哮兰，就是在對(duì)方關(guān)閉連接之后服務(wù)器程序自己沒有進(jìn)一步發(fā)出ack信號(hào)。換句話說苟弛，就是在對(duì)方連接關(guān)閉之后喝滞，程序里沒有檢測(cè)到，或者程序壓根就忘記了這個(gè)時(shí)候需要關(guān)閉連接膏秫，于是這個(gè)資源就一直被程序占著右遭。
檢查代碼，特別是釋放資源的代碼
檢查配置，特別是處理請(qǐng)求的線程配置 ? ?
UDP報(bào)文結(jié)構(gòu)
UDP 報(bào)文中每個(gè)字段的含義如下：
源端口：這個(gè)字段占據(jù) UDP 報(bào)文頭的前 16 位窘哈，通常包含發(fā)送數(shù)據(jù)報(bào)的應(yīng)用程序所使用的 UDP 端口吹榴。接收端的應(yīng)用程序利用這個(gè)字段的值作為發(fā)送響應(yīng)的目的地址。這個(gè)字段是可選的滚婉，所以發(fā)送端的應(yīng)用程序不一定會(huì)把自己的端口號(hào)寫入該字段中图筹。如果不寫入端口號(hào)，則把這個(gè)字段設(shè)置為 0满哪。這樣婿斥，接收端的應(yīng)用程序就不能發(fā)送響應(yīng)了。
目的端口：接收端計(jì)算機(jī)上 UDP 軟件使用的端口哨鸭，占據(jù) 16 位民宿。
長度：該字段占據(jù) 16 位，表示 UDP 數(shù)據(jù)報(bào)長度像鸡，包含 UDP 報(bào)文頭和 UDP 數(shù)據(jù)長度活鹰。因?yàn)?UDP 報(bào)文頭長度是 8 個(gè)字節(jié)，所以這個(gè)值最小為 8只估。
校驗(yàn)值：該字段占據(jù) 16 位志群，可以檢驗(yàn)數(shù)據(jù)在傳輸過程中是否被損壞。
UDP特點(diǎn)
面向非連接
不維護(hù)連接狀態(tài)蛔钙，支持同時(shí)向多個(gè)客戶端傳輸相同的消息
數(shù)據(jù)包報(bào)頭只有8個(gè)字節(jié)锌云，額外開銷較小
吞吐量只受限于數(shù)據(jù)生成速率、傳輸速率以及機(jī)器性能
盡最大努力交付吁脱，不保證可靠交付桑涎，不需要維護(hù)復(fù)雜的連接狀態(tài)表
面向報(bào)文，不對(duì)應(yīng)用程序提交的報(bào)文信息進(jìn)行拆分或者合并
TCP和UDP的區(qū)別
可以從以下幾個(gè)方面總結(jié)區(qū)別
TCP的滑動(dòng)窗口
窗口數(shù)據(jù)的計(jì)算過程
左邊是TCP發(fā)送端緩沖區(qū)兼贡，右邊是接收端緩沖區(qū)攻冷，左邊向右邊發(fā)送數(shù)據(jù)；從發(fā)送端看遍希，下面的長條代表發(fā)送的字節(jié)流等曼，從左向右依次發(fā)送；從接收端看凿蒜，下面的長條代表接收字節(jié)流禁谦，從左向右一次接收。
LastByteAcked：指向已經(jīng)接收到ack反饋的連續(xù)內(nèi)存的最大位置废封，LastByteAcked之前字節(jié)都已經(jīng)接收到接收端的ack回執(zhí)
LastByteSent：指向已經(jīng)發(fā)送的最后一個(gè)字節(jié)的位置
LastByteWrittten：指向上層應(yīng)用已寫完的最大內(nèi)存位置
LastByteRead：指向上層已經(jīng)讀完的最后一個(gè)字節(jié)的位置
NextByteExpected：指向已經(jīng)收到的連續(xù)內(nèi)存的最大位置枷畏，已經(jīng)收到了但是還沒有返回ack回執(zhí)
LastByteRcvd：指向已經(jīng)接收到的最大內(nèi)存的位置，NextByteExpected與LastByteRcvd之間存在沒有接收到的seq
接收端可接收窗口 AdvertisedWindow 大惺觥：
AdvertisedWindow = MaxRevBuffer - （LastByteRcvd - LastByteRead）
發(fā)送端窗口內(nèi)剩余可發(fā)送的窗口 EffectiveWindow 大杏倒睢：
EffectiveWindow =?AdvertisedWindow - （LastByteSent -?LastByteAcked）
這樣計(jì)算是做最壞的打算触趴，就是認(rèn)為發(fā)送端已經(jīng)接收到回執(zhí)的連續(xù)最大內(nèi)存到已經(jīng)發(fā)送的最大內(nèi)存位置的數(shù)據(jù)，還在路上沒有被接收端接收渴肉；接收端的最大接收位置的都已經(jīng)發(fā)送了ack冗懦，但是還沒有被上層應(yīng)用處理〕鸺溃【這里AdvertisedWindow是接收端反饋給接收端的報(bào)文頭里window的值，告訴發(fā)送端接收端還可以接收多少數(shù)據(jù)乌奇；發(fā)送端根據(jù)window大小計(jì)算自己還可以發(fā)送多少數(shù)據(jù)】
TCP會(huì)話的發(fā)送方
TCP發(fā)送方没讲，任何時(shí)候在其緩存內(nèi)的數(shù)據(jù)都可以分為四類
Category #1：已經(jīng)發(fā)送并且已經(jīng)收到ack回執(zhí)的部分
Category #2：已經(jīng)發(fā)送但是沒有收到ack回執(zhí)的部分；這部分大小是LastByteSent 與LastByteAcked的差
Category #3：已經(jīng)準(zhǔn)備好并且允許發(fā)送礁苗，但是還沒有發(fā)送的部分爬凑；這部分就是EffectiveWindow 的大小
Category #4：不允許發(fā)送的部分；已經(jīng)準(zhǔn)備好的數(shù)據(jù)试伙，但是由于接收端緩存限制暫時(shí)不能發(fā)送的部分
其中Category #2 和 Category #3 組成了滑動(dòng)窗口嘁信，當(dāng)LastByteAcked向前移動(dòng)的時(shí)候，滑動(dòng)窗口才能向前移動(dòng)疏叨。
TCP會(huì)話的接收方
TCP接收方潘靖，任何時(shí)候在其接收緩存內(nèi)的數(shù)據(jù)都可以分為三類或叫三種狀態(tài)
Category #1+#2：已經(jīng)接收并且已經(jīng)回執(zhí)ack
Category #3：未接收但是可以接收，準(zhǔn)備接收的
Category #4：不能接收蚤蔓，達(dá)到了窗口的閾值了卦溢，不能接收了
因?yàn)榻邮盏降臄?shù)據(jù)TCP機(jī)制會(huì)立刻ack回執(zhí)，認(rèn)為沒有延遲秀又，所以不存在已接收但沒有回執(zhí)ack的狀態(tài)单寂；
未接收但是準(zhǔn)備接收的 Category #3 就是叫做接收窗口；接收窗口的滑動(dòng)機(jī)制與發(fā)送發(fā)一致
TCP的滑動(dòng)窗口總結(jié)
TCP最基本的傳輸可靠性來源于確認(rèn)重傳機(jī)制涮坐，TCP的滑動(dòng)窗口的可靠性也是建立在確認(rèn)重傳機(jī)制的基礎(chǔ)上的凄贩；發(fā)送窗口只有接收到接收端對(duì)本段發(fā)送窗口內(nèi)字節(jié)的ack確認(rèn)誓军，才會(huì)滑動(dòng)發(fā)送窗口的左邊界袱讹；接收窗口只有在前面的端都確認(rèn)的情況下，才移動(dòng)左邊界昵时，當(dāng)前面字節(jié)沒有接收但是接收到后面的字節(jié)的情況下捷雕，窗口是不會(huì)移動(dòng)的，并且不會(huì)對(duì)接收到的后邊的字節(jié)確認(rèn)壹甥，以此讓對(duì)端確認(rèn)這些字段是否需要重傳救巷。
滑動(dòng)窗口可以按照一定的策略動(dòng)態(tài)的挑戰(zhàn)，應(yīng)用程序可以根據(jù)自身的處理能力設(shè)置調(diào)整策略
HTTP簡介
HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫,是用于從萬維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議句柠。HTTP是一個(gè)基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結(jié)果等）
HTTP工作原理
HTTP協(xié)議工作于客戶端-服務(wù)端架構(gòu)上浦译。瀏覽器作為HTTP客戶端通過URL向HTTP服務(wù)端即WEB服務(wù)器發(fā)送所有請(qǐng)求棒假。
Web服務(wù)器有：Apache服務(wù)器，IIS服務(wù)器（Internet Information Services）等精盅。
Web服務(wù)器根據(jù)接收到的請(qǐng)求后帽哑，向客戶端發(fā)送響應(yīng)信息。HTTP默認(rèn)端口號(hào)為80叹俏，但是你也可以改為8080或者其他端口妻枕。
HTTP三點(diǎn)注意事項(xiàng)：
HTTP是無連接：無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求粘驰，并收到客戶的應(yīng)答后屡谐，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間蝌数。
HTTP是媒體獨(dú)立的：這意味著愕掏，只要客戶端和服務(wù)器知道如何處理的數(shù)據(jù)內(nèi)容，任何類型的數(shù)據(jù)都可以通過HTTP發(fā)送籽前⊥ふ洌客戶端以及服務(wù)器指定使用適合的MIME-type內(nèi)容類型。
HTTP是無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議枝哄。無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力肄梨。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳挠锥，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大众羡。另一方面寻定，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快淡诗。
HTTP請(qǐng)求結(jié)構(gòu)
客戶端發(fā)送一個(gè)HTTP請(qǐng)求到服務(wù)器的請(qǐng)求消息包括以下格式：請(qǐng)求行（request line）、請(qǐng)求頭部（header）侥祭、空行和請(qǐng)求數(shù)據(jù)四個(gè)部分組成蓖宦，下圖給出了請(qǐng)求報(bào)文的一般格式齐婴。
HTTP響應(yīng)報(bào)文
實(shí)例
下面實(shí)例是一點(diǎn)典型的使用GET來傳遞數(shù)據(jù)的實(shí)例：
客戶端請(qǐng)求：
GET?/hello.txt?HTTP/1.1 User-Agent:?curl/7.16.3?libcurl/7.16.3?OpenSSL/0.9.7l?zlib/1.2.3 Host:?www.example.com? Accept-Language:?en,?mi
服務(wù)端響應(yīng):
HTTP/1.1?200?OK Date:?Mon,?27?Jul?2009?12:28:53?GMT Server:?Apache Last-Modified:?Wed,?22?Jul?2009?19:15:56?GMT ETag:?"34aa387-d-1568eb00" Accept-Ranges:?bytes Content-Length:?51 Vary:?Accept-Encoding Content-Type:?text/plain
面試題：在瀏覽器地址欄鍵入U(xiǎn)RL，按下回車之后經(jīng)歷的流程
DNS解析：如果URL中是網(wǎng)址稠茂，需要向?qū)@個(gè)網(wǎng)址進(jìn)行域名解析柠偶，得到相應(yīng)的IP地址，請(qǐng)求會(huì)逐層查詢DNS緩存得到目的IP地址（DNS緩存由近到遠(yuǎn)依次是：瀏覽器緩存睬关、系統(tǒng)緩存诱担、路由器緩存、IPS服務(wù)器緩存电爹、根域名服務(wù)器緩存蔫仙、頂級(jí)域名服務(wù)器緩存）
TCP連接：根據(jù)IP地址和斷開，找到對(duì)應(yīng)的服務(wù)器丐箩，通過TCP的三次握手建立連接
發(fā)送HTTP請(qǐng)求：建立TCP連接后發(fā)起HTTP請(qǐng)求
服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文：服務(wù)器根據(jù)請(qǐng)求參數(shù)得到返回結(jié)果摇邦，并返回HTTP報(bào)文
瀏覽器解析渲染頁面：瀏覽器得到報(bào)文恤煞，解析HTML代碼，并請(qǐng)求HTML代碼中的資源（例如js施籍、css等）阱州，然后渲染頁面
連接結(jié)束：TCP4次揮手，HTTP斷開連接
HTTP狀態(tài)碼
狀態(tài)碼分類
HTTP狀態(tài)碼由三個(gè)十進(jìn)制數(shù)字組成法梯，第一個(gè)十進(jìn)制數(shù)字定義了狀態(tài)碼的類型苔货，后兩個(gè)數(shù)字沒有分類的作用。HTTP狀態(tài)碼共分為5種類型：
1xx：指示信息--表示請(qǐng)求已接收立哑，繼續(xù)處理
2xx：請(qǐng)求成功-表示請(qǐng)求已經(jīng)成功接收夜惭、理解、接受
3xx：重定向--要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作
4xx：客戶端錯(cuò)誤--請(qǐng)求有語法錯(cuò)誤或請(qǐng)求無法實(shí)現(xiàn)
5xx：服務(wù)器端錯(cuò)誤-服務(wù)器未實(shí)現(xiàn)合法的請(qǐng)求
常見的狀態(tài)碼：
HTTP 請(qǐng)求方法
GET與POST請(qǐng)求的區(qū)別
HTTP報(bào)文層面：一般情況铛绰，GET將請(qǐng)求信息放在URL诈茧，POST放在請(qǐng)求體里面
數(shù)據(jù)層面：GET符合冪等性和安全性，POST不符合
GET請(qǐng)求可以被緩存捂掰，被存儲(chǔ)敢会，POST不行
Cookie、Session这嚣、token
https://www.cnblogs.com/moyand/p/9047978.html
https://segmentfault.com/a/1190000017831088
Cookie
Cookie指的是瀏覽器里面能永久存儲(chǔ)的一種數(shù)據(jù)鸥昏，僅僅是瀏覽器實(shí)現(xiàn)的一種數(shù)據(jù)存儲(chǔ)功能
cookie由服務(wù)器生成，發(fā)送給瀏覽器姐帚，瀏覽器把cookie以kv的形式保存到某個(gè)目錄的文本文件內(nèi)吏垮，下一次請(qǐng)求同一網(wǎng)址時(shí)會(huì)把該cookie發(fā)送給服務(wù)端。由于cookie是存在客戶端上的罐旗，所以瀏覽器加入了一些限制確保cookie不會(huì)被惡意使用膳汪，同時(shí)不會(huì)占據(jù)太多磁盤空間，所以每個(gè)域的cookie數(shù)量有限
cookie的設(shè)置和發(fā)送過程：
Session
session從字面上講九秀，就是會(huì)話遗嗽，就是服務(wù)器要知道當(dāng)前發(fā)請(qǐng)求給自己的是誰。為了做這種區(qū)分鼓蜒，服務(wù)器就要給每個(gè)客戶端分配不同的“身份標(biāo)識(shí)”痹换，然后客戶端每次向服務(wù)器發(fā)送請(qǐng)求，都帶上這個(gè)標(biāo)識(shí)友酱，服務(wù)器就知道這個(gè)請(qǐng)求來源于誰晴音。瀏覽器默認(rèn)采用cookie來保存這個(gè)標(biāo)識(shí)柔纵。
服務(wù)器使用session把用戶信息臨時(shí)保存在服務(wù)器上缔杉，用戶離開網(wǎng)站后session會(huì)被銷毀。
????注意
cookie只是實(shí)現(xiàn)session的其中一種方案搁料。雖然是最常用的或详，但并不是唯一的方法系羞。禁用cookie后還有其他方法存儲(chǔ)，比如放在url中
現(xiàn)在大多都是Session + Cookie霸琴，但是只用session不用cookie椒振，或是只用cookie，不用session在理論上都可以保持會(huì)話狀態(tài)梧乘∨煊可是實(shí)際中因?yàn)槎喾N原因，一般不會(huì)單獨(dú)使用
用session只需要在客戶端保存一個(gè)id选调，實(shí)際上大量數(shù)據(jù)都是保存在服務(wù)端夹供。如果全部用cookie，數(shù)據(jù)量大的時(shí)候客戶端是沒有那么多空間的仁堪。
如果只用cookie不用session哮洽，那么賬戶信息全部保存在客戶端，一旦被劫持弦聂，全部信息都會(huì)泄露鸟辅。并且客戶端數(shù)據(jù)量變大，網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量也會(huì)變大
Token
token 也稱作令牌莺葫，由uid+time+sign[+固定參數(shù)]
token 的認(rèn)證方式類似于臨時(shí)的證書簽名, 并且是一種服務(wù)端無狀態(tài)的認(rèn)證方式, 非常適合于 REST API 的場(chǎng)景. 所謂無狀態(tài)就是服務(wù)端并不會(huì)保存身份認(rèn)證相關(guān)的數(shù)據(jù)匪凉。
token 的認(rèn)證流程與cookie很相似
用戶登錄，成功后服務(wù)器返回Token給客戶端捺檬。
客戶端收到數(shù)據(jù)后保存在客戶端
客戶端再次訪問服務(wù)器洒缀，將token放入headers中
服務(wù)器端采用filter過濾器校驗(yàn)。校驗(yàn)成功則返回請(qǐng)求數(shù)據(jù)欺冀，校驗(yàn)失敗則返回錯(cuò)誤碼
分布式情況下的session和token
我們已經(jīng)知道session時(shí)有狀態(tài)的树绩，一般存于服務(wù)器內(nèi)存或硬盤中，當(dāng)服務(wù)器采用分布式或集群時(shí)隐轩，session就會(huì)面對(duì)負(fù)載均衡問題饺饭。
負(fù)載均衡多服務(wù)器的情況，不好確認(rèn)當(dāng)前用戶是否登錄职车，因?yàn)槎喾?wù)器不共享session瘫俊。這個(gè)問題也可以將session存在一個(gè)服務(wù)器中來解決，但是就不能完全達(dá)到負(fù)載均衡的效果悴灵。
而token是無狀態(tài)的扛芽，token字符串里就保存了所有的用戶信息
客戶端登陸傳遞信息給服務(wù)端，服務(wù)端收到后把用戶信息加密（token）傳給客戶端积瞒，客戶端將token存放于localStroage等容器中川尖。客戶端每次訪問都傳遞token茫孔，服務(wù)端解密token叮喳，就知道這個(gè)用戶是誰了被芳。通過cpu加解密，服務(wù)端就不需要存儲(chǔ)session占用存儲(chǔ)空間馍悟，就很好的解決負(fù)載均衡多服務(wù)器的問題了畔濒。這個(gè)方法叫做JWT(Json Web Token)
總結(jié)
session存儲(chǔ)于服務(wù)器，可以理解為一個(gè)狀態(tài)列表锣咒，擁有一個(gè)唯一識(shí)別符號(hào)sessionId侵状，通常存放于cookie中。服務(wù)器收到cookie后解析出sessionId毅整，再去session列表中查找壹将，才能找到相應(yīng)session。依賴cookie
cookie類似一個(gè)令牌毛嫉，裝有sessionId诽俯，存儲(chǔ)在客戶端，瀏覽器通常會(huì)自動(dòng)添加承粤。
token也類似一個(gè)令牌暴区，無狀態(tài)，用戶信息都被加密到token中辛臊，服務(wù)器收到token后解密就可知道是哪個(gè)用戶仙粱。需要開發(fā)者手動(dòng)添加。
jwt只是一個(gè)跨域認(rèn)證的方案
HTTPS
https://zhuanlan.zhihu.com/p/27395037
http://www.reibang.com/p/14cd2c9d2cd2
HTTPS 協(xié)議（HyperText Transfer Protocol over Secure Socket Layer）：可以理解為HTTP+SSL/TLS彻舰， 即 HTTP 下加入 SSL 層伐割，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細(xì)內(nèi)容就需要 SSL刃唤，用于安全的 HTTP 數(shù)據(jù)傳輸隔心。
如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS
SSL（Secure Socket Layer，安全套接字層）：SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應(yīng)用層協(xié)議之間尚胞，為數(shù)據(jù)通訊提供安全支持硬霍。
TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL笼裳，目前使用最廣泛的是TLS 1.1唯卖、TLS 1.2。
SSL/TLS 為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議
SSL/TLS 是操作系統(tǒng)對(duì)外的API躬柬，SSL3.0后更新為TLS
SSL/TLS?采用身份驗(yàn)證和數(shù)據(jù)加密保證網(wǎng)絡(luò)通信的安全和數(shù)據(jù)的完整性
加密算法：
對(duì)稱加密：加密和解密都是使用的同一個(gè)密鑰
有流式拜轨、分組兩種
例如：DES、AES-GCM允青、ChaCha20-Poly1305等
非對(duì)稱加密：加密使用的密鑰和解密使用的密鑰是不相同的
加密解密的秘鑰分別稱為：公鑰橄碾、私鑰
公鑰和算法都是公開的，私鑰是保密的。非對(duì)稱加密算法性能較低堪嫂，但是安全性超強(qiáng)，由于其加密特性木柬，非對(duì)稱加密算法能加密的數(shù)據(jù)長度也是有限的皆串。
例如：RSA、DSA眉枕、ECDSA恶复、 DH、ECDHE
哈希算法
將任意長度的信息轉(zhuǎn)換為較短的固定長度的值速挑，通常其長度要比信息小得多谤牡，且算法不可逆。
例如：MD5姥宝、SHA-1翅萤、SHA-2、SHA-256 等
數(shù)字簽名
簽名就是在信息的后面再加上一段內(nèi)容（信息經(jīng)過hash后的值）腊满，可以證明信息沒有被修改過套么。hash值一般都會(huì)加密后（也就是簽名）再和信息一起發(fā)送，以保證這個(gè)hash值不被修改碳蛋。
HTTPS數(shù)據(jù)傳輸流程
HTTPS在傳輸?shù)倪^程中會(huì)涉及到三個(gè)密鑰：
服務(wù)器端的公鑰和私鑰胚泌，用來進(jìn)行非對(duì)稱加密
客戶端生成的隨機(jī)密鑰，用來進(jìn)行對(duì)稱加密
一個(gè)HTTPS請(qǐng)求實(shí)際上包含了兩次HTTP傳輸肃弟，可以細(xì)分為8步玷室。
客戶端向服務(wù)器發(fā)起HTTPS請(qǐng)求，將瀏覽器支持的加密算法發(fā)送給服務(wù)器
服務(wù)器端有一個(gè)密鑰對(duì)笤受，即公鑰和私鑰穷缤，是用來進(jìn)行非對(duì)稱加密使用的，服務(wù)器端保存著私鑰箩兽，不能將其泄露绅项，公鑰可以發(fā)送給任何人。
服務(wù)器選擇一套瀏覽器支持的加密算法比肄，以證書的形式發(fā)送給客戶端快耿，其中包含服務(wù)端的公鑰。
客戶端收到服務(wù)器端的證書之后芳绩，會(huì)對(duì)證書進(jìn)行檢查掀亥，驗(yàn)證其合法性，如果發(fā)現(xiàn)發(fā)現(xiàn)證書有問題妥色，那么HTTPS傳輸就無法繼續(xù)搪花。如果公鑰合格，那么客戶端會(huì)生成一個(gè)隨機(jī)值，這個(gè)隨機(jī)值就是用于進(jìn)行對(duì)稱加密的密鑰撮竿，我們將該密鑰稱之為client key吮便，即客戶端密鑰，這樣在概念上和服務(wù)器端的密鑰容易進(jìn)行區(qū)分幢踏。然后用服務(wù)器的公鑰對(duì)客戶端密鑰進(jìn)行非對(duì)稱加密髓需，這樣客戶端密鑰就變成密文了，至此房蝉，HTTPS中的第一次HTTP請(qǐng)求結(jié)束僚匆。
客戶端會(huì)發(fā)起HTTPS中的第二個(gè)HTTP請(qǐng)求，將加密之后的客戶端密鑰發(fā)送給服務(wù)器搭幻。
服務(wù)器接收到客戶端發(fā)來的密文之后咧擂，會(huì)用自己的私鑰對(duì)其進(jìn)行非對(duì)稱解密、驗(yàn)證哈希檀蹋，解密之后的明文就是客戶端密鑰松申，然后用客戶端密鑰對(duì)數(shù)據(jù)進(jìn)行對(duì)稱加密，這樣數(shù)據(jù)就變成了密文俯逾。
然后服務(wù)器將加密后的密文發(fā)送給客戶端攻臀。
客戶端收到服務(wù)器發(fā)送來的密文，用客戶端密鑰對(duì)其進(jìn)行對(duì)稱解密纱昧，得到服務(wù)器發(fā)送的數(shù)據(jù)刨啸。這樣HTTPS中的第二個(gè)HTTP請(qǐng)求結(jié)束，整個(gè)HTTPS傳輸完成识脆。
問題：
1.怎么保證保證服務(wù)器給客戶端下發(fā)的公鑰是真正的公鑰设联，而不是中間人偽造的公鑰呢？
SSL 證書灼捂，權(quán)威證書機(jī)構(gòu)發(fā)布CA證書
2.證書如何安全傳輸离例，被掉包了怎么辦？
首先悉稠，數(shù)字證書內(nèi)容是加密的
包括了加密后服務(wù)器的公鑰宫蛆、權(quán)威機(jī)構(gòu)的信息、服務(wù)器域名的猛，還有經(jīng)過CA私鑰簽名之后的證書內(nèi)容（經(jīng)過先通過Hash函數(shù)計(jì)算得到證書數(shù)字摘要耀盗，然后用權(quán)威機(jī)構(gòu)私鑰加密數(shù)字摘要得到數(shù)字簽名)，簽名計(jì)算方法以及證書對(duì)應(yīng)的域名卦尊。
驗(yàn)證證書過程是安全的
當(dāng)客戶端收到這個(gè)證書之后叛拷，使用本地配置的權(quán)威機(jī)構(gòu)的公鑰對(duì)證書進(jìn)行解密得到服務(wù)端的公鑰和證書的數(shù)字簽名，數(shù)字簽名經(jīng)過CA公鑰解密得到證書信息摘要岂却。
然后證書簽名的方法計(jì)算一下當(dāng)前證書的信息摘要忿薇，與收到的信息摘要作對(duì)比裙椭，如果一樣，表示證書一定是服務(wù)器下發(fā)的署浩，沒有被中間人篡改過揉燃。因?yàn)橹虚g人雖然有權(quán)威機(jī)構(gòu)的公鑰，能夠解析證書內(nèi)容并篡改筋栋，但是篡改完成之后中間人需要將證書重新加密炊汤，但是中間人沒有權(quán)威機(jī)構(gòu)的私鑰，無法加密二汛，強(qiáng)行加密只會(huì)導(dǎo)致客戶端無法解密婿崭，如果中間人強(qiáng)行亂修改證書拨拓，就會(huì)導(dǎo)致證書內(nèi)容和證書簽名不匹配肴颊。
HTTPS和HTTP的區(qū)別
HTTPS需要到CA申請(qǐng)證書，HTTP不需要
HTTPS密文傳輸渣磷，HTTP明文傳輸
連接方式不同婿着，HTTPS默認(rèn)使用443端口，HTTP默認(rèn)80
HTTPS=HTTP+加密+認(rèn)證+完整性保護(hù)醋界，較HTTP安全
Socket簡介
socket是對(duì)TCP/IP協(xié)議的抽象竟宋，是操作系統(tǒng)對(duì)外開放的接口
Socket通信流程
客戶端：
4.用戶創(chuàng)建socket
5.用戶打開socket，并通過IP地址+端口號(hào)試圖connect服務(wù)器的socket
7.客戶端連接成功形纺，開始向服務(wù)器輸入狀態(tài)信息
9.客戶端寫入信息
11.客戶端關(guān)閉
服務(wù)器：
1.服務(wù)器根據(jù)地址類型（ipv4丘侠、ipv6）、socket類型逐样、協(xié)議創(chuàng)建socket
2.服務(wù)器為socket綁定對(duì)應(yīng)的IP地址和端口號(hào)
3.服務(wù)器監(jiān)聽端口號(hào)請(qǐng)求蜗字，接收用戶發(fā)來的連接請(qǐng)求，此時(shí)服務(wù)器沒有打開socket
6.服務(wù)器接收到了用戶發(fā)來的socket連接請(qǐng)求脂新，被動(dòng)打開socket挪捕，開始接收客戶端請(qǐng)求，直到用戶返回連接信息争便。這時(shí)候服務(wù)器的socket進(jìn)入堵塞狀態(tài)级零，所謂堵塞，即accept();方法一直接收到客戶端返回連接信息后才返回滞乙，然后開始接收下一個(gè)用戶端請(qǐng)求
8.服務(wù)器accept();方法返回奏纪，連接成功
10.服務(wù)器讀取信息
12.服務(wù)端關(guān)閉
完成~
小猿同事面試過程中，計(jì)算機(jī)網(wǎng)絡(luò)相關(guān)的基礎(chǔ)知識(shí)也就問了這么多亥贸，肯定還是有很多知識(shí)點(diǎn)和細(xì)節(jié)沒有介紹到荣挨，小猿和同事們還需要繼續(xù)努力深究，爭取再整理更詳細(xì)的知識(shí)點(diǎn)分析給大家~
