OSI七層模型「物理層」

首先解決兩臺(tái)物理機(jī)之間的通信需求，具體就是機(jī)器A往機(jī)器B發(fā)送比特流，機(jī)器B能收到比特流。

物理層主要定義了物理設(shè)備的標(biāo)準(zhǔn)，如網(wǎng)線的類型，光纖的接口類型，各種傳輸介質(zhì)的傳輸速率。

主要作用是傳輸比特流（0101二進(jìn)制數(shù)據(jù)），將比特流轉(zhuǎn)化為電流強(qiáng)弱傳輸，到達(dá)目的后再轉(zhuǎn)化為比特流，即常說(shuō)的數(shù)模轉(zhuǎn)化和模數(shù)轉(zhuǎn)換。

這層數(shù)據(jù)叫做比特。「網(wǎng)卡工作在這層」。

物理層是OSI七層模型的物理基礎(chǔ)，沒(méi)有它就談不上數(shù)據(jù)傳輸了

物理層就是由實(shí)物所承載的，所以作比喻的話，公路、汽車和飛機(jī)等承載貨物（數(shù)據(jù)）的交通工具，就是物理層的象征

「數(shù)據(jù)鏈路層」

在傳輸比特流的過(guò)程中，會(huì)產(chǎn)生錯(cuò)傳、數(shù)據(jù)傳輸不完整的可能。

數(shù)據(jù)鏈路層定義了「如何格式化數(shù)據(jù)進(jìn)行傳輸」，以及如何控制對(duì)物理介質(zhì)的訪問(wèn)。通常提供錯(cuò)誤檢測(cè)和糾正，以確保數(shù)據(jù)傳輸?shù)臏?zhǔn)確性。

本層將比特?cái)?shù)據(jù)組成幀，交換機(jī)工作在這層，對(duì)幀解碼，并根據(jù)幀中包含的信息把數(shù)據(jù)發(fā)送到正確的接收方。

該層負(fù)責(zé)物理層面上互連的節(jié)點(diǎn)之間的通信傳輸。例如與1個(gè)以太網(wǎng)相連的兩個(gè)節(jié)點(diǎn)間的通訊。

常見(jiàn)的協(xié)議有 HDLC、PPP、SLIP等

數(shù)據(jù)鏈路層會(huì)將0、1序列劃分為具有意義的數(shù)據(jù)幀傳送給對(duì)端（「數(shù)據(jù)幀的生成與接收」）

「網(wǎng)絡(luò)層」

隨著網(wǎng)絡(luò)節(jié)點(diǎn)的不斷增加，點(diǎn)對(duì)點(diǎn)通訊需要通過(guò)多個(gè)節(jié)點(diǎn)，如何找到目標(biāo)節(jié)點(diǎn)，如何選擇最佳路徑成為首要需求。

網(wǎng)絡(luò)層主要功能是將網(wǎng)絡(luò)地址轉(zhuǎn)化為對(duì)應(yīng)的物理地址，并決定如何將數(shù)據(jù)從發(fā)送方路由到接收方。

網(wǎng)絡(luò)層通過(guò)綜合考慮發(fā)送優(yōu)先權(quán)、網(wǎng)絡(luò)擁塞程度、服務(wù)質(zhì)量以及可選路由的花費(fèi)來(lái)決定從一個(gè)網(wǎng)絡(luò)中節(jié)點(diǎn)A到另一個(gè)網(wǎng)絡(luò)中節(jié)點(diǎn)B的最佳路徑。

由于網(wǎng)絡(luò)層處理并智能指導(dǎo)數(shù)據(jù)傳送，路由器連接網(wǎng)絡(luò)隔斷，所以路由器屬于網(wǎng)絡(luò)層。

此層的數(shù)據(jù)稱之為數(shù)據(jù)包。本層需要關(guān)注的協(xié)議TCP/IP協(xié)議中的IP協(xié)議。

網(wǎng)絡(luò)層負(fù)責(zé)將數(shù)據(jù)傳輸?shù)侥繕?biāo)地址。目標(biāo)地址可以使多個(gè)網(wǎng)絡(luò)通過(guò)路由器連接而成的某一個(gè)地址。因此這一層主要負(fù)責(zé)「尋址和路由選擇」。主要由 IP、ICMP 兩個(gè)協(xié)議組成

網(wǎng)絡(luò)層將數(shù)據(jù)從發(fā)送端的主機(jī)發(fā)送到接收端的主機(jī)，兩臺(tái)主機(jī)間可能會(huì)存在很多數(shù)據(jù)鏈路，但網(wǎng)絡(luò)層就是負(fù)責(zé)找出一條相對(duì)順暢的通路將數(shù)據(jù)傳遞過(guò)去。傳輸?shù)牡刂肥褂玫氖荌P地址。IP地址通過(guò)不斷轉(zhuǎn)發(fā)到更近的IP地址，最終可以到達(dá)目標(biāo)地址

「?jìng)鬏攲印?/p>

隨著網(wǎng)絡(luò)通信需求的進(jìn)一步擴(kuò)大，通信過(guò)程中需要發(fā)送大量的數(shù)據(jù)，如海量文件傳輸，可能需要很長(zhǎng)時(shí)間，網(wǎng)絡(luò)在通信的過(guò)程中會(huì)中斷很多次，此時(shí)為了保證傳輸大量文件時(shí)的準(zhǔn)確性，需要對(duì)發(fā)送出去的數(shù)據(jù)進(jìn)行切分，切割為一個(gè)一個(gè)的段落（Segement）發(fā)送，其中一個(gè)段落丟失是否重傳，段落是否按順序到達(dá)，是傳輸層需要考慮的問(wèn)題。

傳輸層解決了主機(jī)間的數(shù)據(jù)傳輸，數(shù)據(jù)間的傳輸可以是不同網(wǎng)絡(luò)，并且傳輸層解決了「?jìng)鬏斮|(zhì)量」的問(wèn)題。

傳輸層需要關(guān)注的協(xié)議有TCP/IP協(xié)議中的TCP協(xié)議和UDP協(xié)議。

「會(huì)話層」

自動(dòng)收發(fā)包，自動(dòng)尋址。

會(huì)話層作用是「負(fù)責(zé)建立和斷開(kāi)通信連接」，何時(shí)建立，斷開(kāi)連接以及保持多久的連接。常見(jiàn)的協(xié)議有 ADSP、RPC 等

「表示層」

Linux給WIndows發(fā)包，不同系統(tǒng)語(yǔ)法不一致，如exe不能在Linux下執(zhí)行，shell不能在Windows不能直接運(yùn)行。于是需要表示層。

解決「不同系統(tǒng)之間通信語(yǔ)法問(wèn)題」，在表示層數(shù)據(jù)將按照網(wǎng)絡(luò)能理解的方案進(jìn)行格式化，格式化因所使用網(wǎng)絡(luò)的不同而不同。

它主要負(fù)責(zé)數(shù)據(jù)格式的轉(zhuǎn)換。具體來(lái)說(shuō)，就是講設(shè)備固有的數(shù)據(jù)格式轉(zhuǎn)換為網(wǎng)絡(luò)標(biāo)準(zhǔn)格式。常見(jiàn)的協(xié)議有ASCII、SSL/TLS 等

「應(yīng)用層」

規(guī)定發(fā)送方和接收方必須使用一個(gè)固定長(zhǎng)度的消息頭，消息頭必須使用某種固定的組成，消息頭中必須記錄消息體的長(zhǎng)度等信息，方便接收方正確解析發(fā)送方發(fā)送的數(shù)據(jù)。

應(yīng)用層旨在更「方便應(yīng)用從網(wǎng)絡(luò)中接收的數(shù)據(jù)」，重點(diǎn)關(guān)注TCP/IP協(xié)議中的HTTP協(xié)議

四層傳輸層數(shù)據(jù)被稱作「段」（Segments）；

三層網(wǎng)絡(luò)層數(shù)據(jù)被稱做「包」（Packages）；

二層數(shù)據(jù)鏈路層時(shí)數(shù)據(jù)被稱為「幀」（Frames）；

一層物理層時(shí)數(shù)據(jù)被稱為「比特流」（Bits）。

TCP和IP模型OSI模型注重通信協(xié)議必要的功能；TCP/IP更強(qiáng)調(diào)在計(jì)算機(jī)上實(shí)現(xiàn)協(xié)議應(yīng)該開(kāi)發(fā)哪種程序

「TCP/IP劃分了四層網(wǎng)絡(luò)模型」

第一層：應(yīng)用層，主要有負(fù)責(zé)web瀏覽器的HTTP協(xié)議， 文件傳輸?shù)腇TP協(xié)議，負(fù)責(zé)電子郵件的SMTP協(xié)議，負(fù)責(zé)域名系統(tǒng)的DNS等

第二層：傳輸層，主要是有「可靠傳輸」的TCP協(xié)議，特別「高效」的UDP協(xié)議。主要負(fù)責(zé)傳輸應(yīng)用層的數(shù)據(jù)包。

第三層：網(wǎng)絡(luò)層，主要是IP協(xié)議。主要負(fù)責(zé)尋址（找到目標(biāo)設(shè)備的位置）

第四層：數(shù)據(jù)鏈路層，主要是負(fù)責(zé)轉(zhuǎn)換數(shù)字信號(hào)和物理二進(jìn)制信號(hào)。

「四層網(wǎng)絡(luò)協(xié)議的作用」

發(fā)送端是由上至下，把上層來(lái)的數(shù)據(jù)在頭部加上各層協(xié)議的數(shù)據(jù)（部首）再下發(fā)給下層。

接受端則由下而上，把從下層接受到的數(shù)據(jù)進(jìn)行解密和去掉頭部的部首后再發(fā)送給上層。

層層加密和解密后，應(yīng)用層最終拿到了需要的數(shù)據(jù)。

「舉個(gè)例子：」

我們需要發(fā)送一個(gè)「index.html」。

兩臺(tái)電腦在應(yīng)用層都使用HTTP協(xié)議（即都使用瀏覽器）。

在傳輸層，TCP協(xié)議會(huì)將HTTP協(xié)議發(fā)送的數(shù)據(jù)看作一個(gè)數(shù)據(jù)包，并在這個(gè)數(shù)據(jù)包前面加上TCP包的一部分信息（部首）

在網(wǎng)絡(luò)層，IP協(xié)議會(huì)將TCP協(xié)議要發(fā)送的數(shù)據(jù)看作一個(gè)數(shù)據(jù)包，同樣的在這個(gè)數(shù)據(jù)包前端加上IP協(xié)議的部首

在數(shù)據(jù)鏈路層，對(duì)應(yīng)的協(xié)議也會(huì)在IP數(shù)據(jù)包前端加上以太網(wǎng)的部首。

源設(shè)備和目標(biāo)設(shè)備通過(guò)網(wǎng)線連接，就可以通過(guò)物理層的二進(jìn)制傳輸數(shù)據(jù)。

數(shù)據(jù)鏈路層，會(huì)使用對(duì)應(yīng)的協(xié)議找到物理層的二進(jìn)制數(shù)據(jù)，解碼得到以太網(wǎng)的部首信息和對(duì)應(yīng)的IP數(shù)據(jù)包，再將IP數(shù)據(jù)包傳給上層的網(wǎng)絡(luò)層。

數(shù)據(jù)鏈路層》網(wǎng)絡(luò)層》傳輸層》應(yīng)用層，一層層的解碼，最后就可以在瀏覽器中得到目標(biāo)設(shè)備傳送過(guò)來(lái)的「index.html」。

「TCP/IP協(xié)議族」

從字面意義上來(lái)講，TCP/IP是指「?jìng)鬏攲印沟腡CP協(xié)議和「網(wǎng)絡(luò)層」的IP協(xié)議。

實(shí)際上，TCP/IP只是利用 IP 進(jìn)行通信時(shí)所必須用到的協(xié)議群的統(tǒng)稱。

具體來(lái)說(shuō)，在網(wǎng)絡(luò)層是IP/ICMP協(xié)議、在傳輸層是TCP/UDP協(xié)議、在應(yīng)用層是SMTP、FTP、以及 HTTP 等。他們都屬于 TCP/IP 協(xié)議。

網(wǎng)絡(luò)設(shè)備交換機(jī)

交換機(jī)可以接入多臺(tái)電腦

每個(gè)電腦網(wǎng)卡的 「MAC 地址」都是不一樣的，電腦發(fā)送數(shù)據(jù)時(shí)，數(shù)據(jù)頭部攜帶網(wǎng)卡的 MAC 地址，用 MAC 地址標(biāo)識(shí)來(lái)不同的電腦

交換機(jī)就可以識(shí)別數(shù)據(jù)頭部的 MAC 地址來(lái)區(qū)分不同的電腦

交換機(jī)除了能識(shí)別不同的電腦，還需要找到電腦連接的「交換機(jī)端口」，才能順利的把數(shù)據(jù)從相應(yīng)端口發(fā)送出去

交換機(jī)通過(guò)「自學(xué)機(jī)制」，把學(xué)習(xí)到的設(shè)備 MAC 地址和交換機(jī)端口號(hào)添加到 「MAC 地址表」，并根據(jù) MAC 地址表進(jìn)行數(shù)據(jù)「轉(zhuǎn)發(fā)」

路由器

交換機(jī)需要記錄的 MAC 地址表也越來(lái)越多，需要的交換機(jī)也越來(lái)越多

但是交換機(jī)的「容量和性能有限」，MAC 地址表無(wú)法記錄全世界電腦的 MAC 地址和對(duì)應(yīng)的端口號(hào)，MAC 地址表太大也無(wú)法快速查找到對(duì)應(yīng)的 MAC 地址表項(xiàng)

于是就有了三層網(wǎng)絡(luò)設(shè)備「路由器」，路由器可以把全世界的網(wǎng)絡(luò)連接起來(lái)

局域網(wǎng)內(nèi)的網(wǎng)絡(luò)連接可以使用「交換機(jī)」，例如一個(gè)公司內(nèi)的網(wǎng)絡(luò)或者一個(gè)校園內(nèi)的網(wǎng)絡(luò)通過(guò)交換機(jī)連接

不同區(qū)域的局域網(wǎng)互聯(lián)使用「路由器」

?

那么如何區(qū)分不同的網(wǎng)絡(luò)區(qū)域呢？又是如何跨網(wǎng)絡(luò)區(qū)域進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)的呢？

?路由器有多個(gè)端口，分別連接不同的網(wǎng)絡(luò)區(qū)域，不同網(wǎng)絡(luò)區(qū)域的 IP 地址「網(wǎng)絡(luò)號(hào)不同」

它通過(guò)識(shí)別目的 IP 地址的「網(wǎng)絡(luò)號(hào)」，再根據(jù)「路由表」進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)

HTTP「請(qǐng)求方法」

HTTP1.0 定義了三種請(qǐng)求方法：GET， POST 和 HEAD方法。

HTTP1.1 新增了六種請(qǐng)求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

序 號(hào)方法描述

1GET請(qǐng)求指定的頁(yè)面信息，并返回實(shí)體主體。

2HEAD類似于 GET 請(qǐng)求，只不過(guò)返回的響應(yīng)中沒(méi)有具體的內(nèi)容，用于獲取報(bào)頭

3POST向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST 請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改。

4PUT從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。

5DELETE請(qǐng)求服務(wù)器刪除指定的頁(yè)面。

6CONNECTHTTP/1.1 協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。

7OPTIONS允許客戶端查看服務(wù)器的性能。

8TRACE回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。

9PATCH是對(duì) PUT 方法的補(bǔ)充，用來(lái)對(duì)已知資源進(jìn)行局部更新 。

「GET請(qǐng)求和POST請(qǐng)求的區(qū)別」

GET 請(qǐng)求的請(qǐng)求參數(shù)是添加到 head 中，可以在 url 中可以看到；POST 請(qǐng)求的請(qǐng)求參數(shù)是添加到body中，在url 中不可見(jiàn)。

請(qǐng)求的url有長(zhǎng)度限制，這個(gè)限制由瀏覽器和 web 服務(wù)器決定和設(shè)置的，例如IE瀏覽器對(duì) URL的最大限制為2083個(gè)字符，如果超過(guò)這個(gè)數(shù)字，提交按鈕沒(méi)有任何反應(yīng)，因?yàn)镚ET請(qǐng)求的參數(shù)是添加到URL中，所以GET請(qǐng)求的URL的長(zhǎng)度限制需要將請(qǐng)求參數(shù)長(zhǎng)度也考慮進(jìn)去。而POST請(qǐng)求不用考慮請(qǐng)求參數(shù)的長(zhǎng)度。

GET請(qǐng)求產(chǎn)生一個(gè)數(shù)據(jù)包; POST請(qǐng)求產(chǎn)生2個(gè)數(shù)據(jù)包，在火狐瀏覽器中，產(chǎn)生一個(gè)數(shù)據(jù)包，這個(gè)區(qū)別點(diǎn)在于瀏覽器的請(qǐng)求機(jī)制，先發(fā)送請(qǐng)求頭，再發(fā)送請(qǐng)求體，因?yàn)镚ET沒(méi)有請(qǐng)求體，所以就發(fā)送一個(gè)數(shù)據(jù)包，而POST包含請(qǐng)求體，所以發(fā)送兩次數(shù)據(jù)包，但是由于火狐機(jī)制不同，所以發(fā)送一個(gè)數(shù)據(jù)包。

GET 請(qǐng)求會(huì)被瀏覽器主動(dòng)緩存下來(lái)，留下歷史記錄，而 POST 默認(rèn)不會(huì)。

GET是冪等的，而POST不是（冪等表示執(zhí)行相同的操作，結(jié)果也是相同的）

GET是獲取數(shù)據(jù)，POST是修改數(shù)據(jù)

狀態(tài)碼

「狀態(tài)碼由3位數(shù)字組成，第一位定義響應(yīng)的類別」

1XX：指示信息，表示請(qǐng)求以接收，繼續(xù)處理

2XX：成功，表示請(qǐng)求已經(jīng)被成功接收、理解、接受

200 OK 是最常見(jiàn)的成功狀態(tài)碼，表示一切正常。如果是非 HEAD 請(qǐng)求，服務(wù)器返回的響應(yīng)頭都會(huì)有 body 數(shù)據(jù)。

204 No Content 也是常見(jiàn)的成功狀態(tài)碼，與 200 OK 基本相同，但響應(yīng)頭沒(méi)有 body 數(shù)據(jù)。

206 Partial Content 是應(yīng)用于 HTTP 分塊下載或斷電續(xù)傳，表示響應(yīng)返回的 body 數(shù)據(jù)并不是資源的全部，而是其中的一部分，也是服務(wù)器處理成功的狀態(tài)。

3XX：狀態(tài)碼表示客戶端請(qǐng)求的資源發(fā)送了變動(dòng)，需要客戶端用新的 URL 重新發(fā)送請(qǐng)求獲取資源，也就是「重定向」。

301 Moved Permanently 表示永久重定向，說(shuō)明請(qǐng)求的資源已經(jīng)不存在了，需改用新的 URL 再次訪問(wèn)，搜索引擎在抓取新內(nèi)容的同時(shí)也將舊的網(wǎng)址交換為重定向之后的網(wǎng)址。

302 Moved Permanently 表示臨時(shí)重定向，說(shuō)明請(qǐng)求的資源還在，但暫時(shí)需要用另一個(gè) URL 來(lái)訪問(wèn)，搜索引擎會(huì)抓取新的內(nèi)容而保存舊的網(wǎng)址。

301 和 302 都會(huì)在響應(yīng)頭里使用字段 Location，指明后續(xù)要跳轉(zhuǎn)的 URL，瀏覽器會(huì)自動(dòng)重定向新的 URL。

304 Not Modified不具有跳轉(zhuǎn)的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定向，用于緩存控制。

4XX：狀態(tài)碼表示客戶端發(fā)送的「報(bào)文有誤」，服務(wù)器無(wú)法處理，也就是錯(cuò)誤碼的含義。

400 Bad Request表示客戶端請(qǐng)求的報(bào)文有錯(cuò)誤。

401 Unauthorized：缺失或錯(cuò)誤的認(rèn)證，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用。

403 Forbidden表示服務(wù)器禁止訪問(wèn)資源，并不是客戶端的請(qǐng)求出錯(cuò)。

404 Not Found表示請(qǐng)求的資源在服務(wù)器上不存在或未找到，所以無(wú)法提供給客戶端。

5XX：狀態(tài)碼表示客戶端請(qǐng)求報(bào)文正確，但是「服務(wù)器處理時(shí)內(nèi)部發(fā)生了錯(cuò)誤」，屬于服務(wù)器端的錯(cuò)誤碼。

501 Not Implemented 表示客戶端請(qǐng)求的功能還不支持。

502 Bad Gateway 通常是服務(wù)器作為網(wǎng)關(guān)或代理時(shí)返回的錯(cuò)誤碼，表示服務(wù)器自身工作正常，訪問(wèn)后端服務(wù)器發(fā)生了錯(cuò)誤。

503 Service Unavailable 表示服務(wù)器當(dāng)前很忙，暫時(shí)無(wú)法響應(yīng)服務(wù)器。

504 Gateway Timeout：網(wǎng)關(guān)超時(shí)，由作為代理或網(wǎng)關(guān)的服務(wù)器使用，表示不能及時(shí)地從遠(yuǎn)程服務(wù)器獲得應(yīng)答。

「301和302的區(qū)別」

301重定向，指頁(yè)面永久性轉(zhuǎn)移，表示為資源或頁(yè)面永久性地轉(zhuǎn)移到了另一個(gè)位置。

301是HTTP協(xié)議中的一種狀態(tài)碼，當(dāng)用戶或搜索引擎向服務(wù)器發(fā)出瀏覽請(qǐng)求時(shí)，服務(wù)器返回的HTTP數(shù)據(jù)流中頭信息中包含狀態(tài)碼 301 ，表示該資源已經(jīng)永久改變了位置。

302重定向是頁(yè)面暫時(shí)性轉(zhuǎn)移，搜索引擎會(huì)抓取新的內(nèi)容而保存舊的網(wǎng)址并認(rèn)為新的網(wǎng)址只是暫時(shí)的。

HTTP1.1

「長(zhǎng)連接」

HTTP 1.1支持長(zhǎng)連接

HTTP 1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即斷開(kāi)TCP連接，服務(wù)器不跟蹤每個(gè)客戶也不記錄過(guò)去的請(qǐng)求。

HTTP 1.1則支持持久連接Persistent Connection，并且默認(rèn)使用，在同一個(gè)TCP的連接中可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)，多個(gè)請(qǐng)求和響應(yīng)可以重疊，多個(gè)請(qǐng)求和響應(yīng)可以同時(shí)進(jìn)行，更加多的請(qǐng)求頭和響應(yīng)頭

HTTP 1.1的持續(xù)連接，也需要增加新的請(qǐng)求頭來(lái)幫助實(shí)現(xiàn)，例如，Connection請(qǐng)求頭的值為Keep-Alive時(shí)，客戶端通知服務(wù)器返回本次請(qǐng)求結(jié)果后保持連接；Connection請(qǐng)求頭的值為Close時(shí)，客戶端通知服務(wù)器返回本次請(qǐng)求結(jié)果后關(guān)閉連接。

「管道網(wǎng)絡(luò)傳輸」

HTTP/1.1 采用了長(zhǎng)連接的方式，這使得管道網(wǎng)絡(luò)傳輸成為了可能。

即可在同一個(gè) TCP 連接里面，客戶端可以發(fā)起多個(gè)請(qǐng)求，只要第一個(gè)請(qǐng)求發(fā)出去了，不必等其回來(lái)，就可以發(fā)第二個(gè)請(qǐng)求出去，可以「減少整體的響應(yīng)時(shí)間?！?/p>

舉例來(lái)說(shuō)，客戶端需要請(qǐng)求兩個(gè)資源。以前的做法是，在同一個(gè)TCP連接里面，先發(fā)送 A 請(qǐng)求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出 B 請(qǐng)求，管道機(jī)制則是允許瀏覽器同時(shí)發(fā)出 A 請(qǐng)求和 B 請(qǐng)求。

但是服務(wù)器還是按照「順序」，先回應(yīng) A 請(qǐng)求，完成后再回應(yīng) B 請(qǐng)求，要是 前面的回應(yīng)特別慢，后面就會(huì)有許多請(qǐng)求排隊(duì)等著。

「Host字段」

在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址，因此，請(qǐng)求消息中的URL并沒(méi)有傳遞主機(jī)名，但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)，并且它們共享一個(gè)IP地址。

HTTP1.1的請(qǐng)求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請(qǐng)求消息中如果沒(méi)有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）。

此外，服務(wù)器應(yīng)該接受以絕對(duì)路徑標(biāo)記的資源請(qǐng)求。

「100Status」

HTTP/1.1加入了一個(gè)新的狀態(tài)碼100。

客戶端事先發(fā)送一個(gè)只帶頭域的請(qǐng)求，如果服務(wù)器因?yàn)闄?quán)限拒絕了請(qǐng)求，就回送響應(yīng)碼401（Unauthorized）；

如果服務(wù)器接收此請(qǐng)求就回送響應(yīng)碼100，客戶端就可以繼續(xù)發(fā)送帶實(shí)體的完整請(qǐng)求了。

100狀態(tài)代碼的使用，允許客戶端在發(fā)request消息body之前先用request header試探一下server，看server要不要接收request body，再?zèng)Q定要不要發(fā)request body。

「Chunked Transfer Coding」

HTTP/1.1將發(fā)送方將消息分割成若干個(gè)任意大小的數(shù)據(jù)塊，每個(gè)數(shù)據(jù)塊在發(fā)送時(shí)都會(huì)附上塊的長(zhǎng)度，最后用一個(gè)零長(zhǎng)度的塊作為消息結(jié)束的標(biāo)志。

這種方法允許發(fā)送方只緩沖消息的一個(gè)片段，避免緩沖整個(gè)消息帶來(lái)的過(guò)載。

「Cache」

HTTP/1.1在1.0的基礎(chǔ)上加入了一些Cache的新特性，當(dāng)緩存對(duì)象的Age超過(guò)Expire時(shí)變?yōu)镾table對(duì)象，Cache不需要直接拋棄Stable對(duì)象，而是與源服務(wù)器進(jìn)行重新激活。

HTTP2.0

「HTTP2.0和HTTP1.X相比的新特性」

新的二進(jìn)制格式，HTTP1.x的解析是基于文本

多路復(fù)用，即連接共享，即每一個(gè)request都是是用作連接共享機(jī)制的，一個(gè)request對(duì)應(yīng)一個(gè)id，這樣一個(gè)連接上可以有多個(gè)request，每個(gè)連接的request可以隨機(jī)的混雜在一起，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請(qǐng)求里面

header壓縮，HTTP1.x的header帶有大量信息，而且每次都要重復(fù)發(fā)送，HTTP2.0使用encoder來(lái)減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header fields表，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮?/p>

服務(wù)端推送

HTTP/2 還在一定程度上改善了傳統(tǒng)的請(qǐng)求 - 應(yīng)答工作模式，服務(wù)不再是被動(dòng)地響應(yīng)，也可以「主動(dòng)」向客戶端發(fā)送消息。

舉例來(lái)說(shuō)，在瀏覽器剛請(qǐng)求 HTML 的時(shí)候，就提前把可能會(huì)用到的 JS、CSS 文件等靜態(tài)資源主動(dòng)發(fā)給客戶端，「減少延時(shí)的等待」，也就是服務(wù)器推送。

「數(shù)據(jù)流」

HTTP/2 的數(shù)據(jù)包不是按順序發(fā)送的，同一個(gè)連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。

因此，必須要對(duì)數(shù)據(jù)包做標(biāo)記，指出它屬于哪個(gè)回應(yīng)。

每個(gè)請(qǐng)求或回應(yīng)的所有數(shù)據(jù)包，稱為一個(gè)數(shù)據(jù)流（Stream）。

每個(gè)數(shù)據(jù)流都標(biāo)記著一個(gè)獨(dú)一無(wú)二的編號(hào)，其中規(guī)定客戶端發(fā)出的數(shù)據(jù)流編號(hào)為奇數(shù)， 服務(wù)器發(fā)出的數(shù)據(jù)流編號(hào)為偶數(shù)

客戶端還可以「指定數(shù)據(jù)流的優(yōu)先級(jí)」。優(yōu)先級(jí)高的請(qǐng)求，服務(wù)器就先響應(yīng)該請(qǐng)求。

「HTTP2.0的多路復(fù)用和HTTP1.X中的長(zhǎng)連接復(fù)用有什么區(qū)別」

HTTP/1.1的Pipeling為若干個(gè)請(qǐng)求排隊(duì)串行化單線程處理，后面的請(qǐng)求等待前面請(qǐng)求的返回才能獲得執(zhí)行機(jī)會(huì)，一旦有某請(qǐng)求超時(shí)等，后續(xù)請(qǐng)求只能被阻塞，毫無(wú)辦法；

HTTP2.0多個(gè)請(qǐng)求可同時(shí)在一個(gè)連接上并行執(zhí)行，某個(gè)請(qǐng)求任務(wù)耗時(shí)嚴(yán)重，不會(huì)影響到其它連接的正常執(zhí)行

HTTP3.0

「使用UDP協(xié)議」

HTTP/2 主要的問(wèn)題在于：多個(gè) HTTP 請(qǐng)求在復(fù)用一個(gè) TCP 連接，下層的 TCP 協(xié)議是不知道有多少個(gè) HTTP 請(qǐng)求的。

所以一旦發(fā)生了丟包現(xiàn)象，就會(huì)觸發(fā) TCP 的重傳機(jī)制，這樣在一個(gè) TCP 連接中的「所有的 HTTP 請(qǐng)求都必須等待這個(gè)丟了的包被重傳回來(lái)」。

HTTP/1.1 中的管道傳輸中如果有一個(gè)請(qǐng)求阻塞了，那么隊(duì)列后請(qǐng)求也統(tǒng)統(tǒng)被阻塞住了

HTTP/2 多請(qǐng)求復(fù)用一個(gè)TCP連接，一旦發(fā)生丟包，就會(huì)阻塞住所有的 HTTP 請(qǐng)求。

這都是基于 TCP 傳輸層的問(wèn)題，所以 「HTTP/3 把 HTTP 下層的 TCP 協(xié)議改成了 UDP！」

HTTPS

「HTTP與HTTPS的區(qū)別」

HTTP 是明文傳輸協(xié)議，HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比 HTTP 協(xié)議安全

HTTPS比HTTP更加安全，對(duì)搜索引擎更友好，利于SEO，谷歌、百度優(yōu)先索引HTTPS網(wǎng)頁(yè)

HTTPS需要用到SSL證書(shū)，而HTTP不用

HTTPS標(biāo)準(zhǔn)端口443，HTTP標(biāo)準(zhǔn)端口80

HTTPS基于傳輸層，HTTP基于應(yīng)用層

HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒(méi)有顯示

「工作原理」

HTTPS 協(xié)議會(huì)對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行加密，而加密過(guò)程是使用了非對(duì)稱加密實(shí)現(xiàn)

HTTPS的整體過(guò)程分為證書(shū)驗(yàn)證和數(shù)據(jù)傳輸階段，具體的交互過(guò)程如下：

Client發(fā)起一個(gè)HTTPS的請(qǐng)求

Server把事先配置好的公鑰證書(shū)返回給客戶端。

Client驗(yàn)證公鑰證書(shū)：比如是否在有效期內(nèi)，證書(shū)的用途是不是匹配Client請(qǐng)求的站點(diǎn)，是不是在CRL吊銷列表里面，它的上一級(jí)證書(shū)是否有效，這是一個(gè)遞歸的過(guò)程，直到驗(yàn)證到根證書(shū)（操作系統(tǒng)內(nèi)置的Root證書(shū)或者Client內(nèi)置的Root證書(shū)），如果驗(yàn)證通過(guò)則繼續(xù)，不通過(guò)則顯示警告信息。

Client使用偽隨機(jī)數(shù)生成器生成加密所使用的對(duì)稱密鑰，然后用證書(shū)的公鑰加密這個(gè)對(duì)稱密鑰，發(fā)給Server。

Server使用自己的私鑰解密這個(gè)消息，得到對(duì)稱密鑰。至此，Client和Server雙方都持有了相同的對(duì)稱密鑰。

Server使用對(duì)稱密鑰加密明文內(nèi)容A，發(fā)送給Client。

Client使用對(duì)稱密鑰解密響應(yīng)的密文，得到明文內(nèi)容A。

Client再次發(fā)起HTTPS的請(qǐng)求，使用對(duì)稱密鑰加密請(qǐng)求的明文內(nèi)容B，然后Server使用對(duì)稱密鑰解密密文，得到明文內(nèi)容B。

數(shù)字證書(shū)

客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。

?

這就存在些問(wèn)題，如何保證公鑰不被篡改和信任度？

?所以這里就需要借助第三方權(quán)威機(jī)構(gòu) CA （數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)），將「服務(wù)器公鑰放在數(shù)字證書(shū)」（由數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)頒發(fā)）中，只要證書(shū)是可信的，公鑰就是可信的。

通過(guò)數(shù)字證書(shū)的方式保證服務(wù)器公鑰的身份，解決冒充的風(fēng)險(xiǎn)。

請(qǐng)求報(bào)文

「請(qǐng)求頭」

HTTP 請(qǐng)求報(bào)文由3部分組成（請(qǐng)求行+請(qǐng)求頭+請(qǐng)求體）

「常見(jiàn)的HTTP報(bào)文頭屬性」

Accpet

告訴服務(wù)端，客戶端接收什么類型的響應(yīng)

Referer

表示這是請(qǐng)求是從哪個(gè)URL進(jìn)來(lái)的，比如想在網(wǎng)上購(gòu)物，但是不知道選擇哪家電商平臺(tái)，你就去問(wèn)度娘，說(shuō)哪家電商的東西便宜啊，然后一堆東西彈出在你面前，第一給就是某寶，當(dāng)你從這里進(jìn)入某寶的時(shí)候，這個(gè)請(qǐng)求報(bào)文的Referer就是：www.baidu.com

Cache-Control

對(duì)緩存進(jìn)行控制，如一個(gè)請(qǐng)求希望響應(yīng)的內(nèi)容在客戶端緩存一年，或不被緩可以通過(guò)這個(gè)報(bào)文頭設(shè)置

Accept-Encoding

例如：Accept-Encoding:gzip， deflate（這兩種都是壓縮格式）

這個(gè)屬性是用來(lái)告訴服務(wù)器能接受什么編碼格式，包括字符編碼，壓縮形式（一般都是壓縮形式）

Host

指定要請(qǐng)求的資源所在的主機(jī)和端口

User-Agent：告訴服務(wù)器，客戶端使用的操作系統(tǒng)、瀏覽器版本和名稱

Connection

決定當(dāng)前事務(wù)（三次握手和四次揮手）完成后，是否關(guān)閉網(wǎng)絡(luò)連接。

持久連接，事務(wù)完成后不關(guān)閉網(wǎng)絡(luò)連接 ：Connection： keep-alive非持久連接，事務(wù)完成后關(guān)閉網(wǎng)絡(luò)連接：Connection： close響應(yīng)報(bào)文

響應(yīng)報(bào)文與請(qǐng)求報(bào)文一樣，由三個(gè)部分組成（響應(yīng)行，響應(yīng)頭，響應(yīng)體）

「HTTP響應(yīng)報(bào)文屬性」

Cache-Control

響應(yīng)輸出到客戶端后，服務(wù)端通過(guò)該屬性告訴客戶端該怎么控制響應(yīng)內(nèi)容的緩存

ETag

表示你請(qǐng)求資源的版本，如果該資源發(fā)生啦變化，那么這個(gè)屬性也會(huì)跟著變

Location

在重定向中或者創(chuàng)建新資源時(shí)使用

Set-Cookie

服務(wù)端可以設(shè)置客戶端的cookie

TCPTCP是一個(gè)傳輸層協(xié)議，提供可靠傳輸，支持全雙工，是一個(gè)連接導(dǎo)向的協(xié)議。

「雙工/單工」

在任何一個(gè)時(shí)刻，如果數(shù)據(jù)只能單向發(fā)送，就是單工。

如果在某個(gè)時(shí)刻數(shù)據(jù)可以向一個(gè)方向傳輸，也可以向另一個(gè)方向反方向傳輸，而且交替進(jìn)行，叫作半雙工；半雙工需要至少 1 條線路。

如果任何時(shí)刻數(shù)據(jù)都可以雙向收發(fā)，這就是全雙工，全雙工需要大于 1 條線路。

TCP 是一個(gè)雙工協(xié)議，數(shù)據(jù)任何時(shí)候都可以雙向傳輸。

這就意味著客戶端和服務(wù)端可以平等地發(fā)送、接收信息。

「TCP協(xié)議的主要特點(diǎn)」

TCP是面向連接的運(yùn)輸層協(xié)議；所謂面向連接就是雙方傳輸數(shù)據(jù)之前，必須先建立一條通道，例如三次握手就是建議通道的一個(gè)過(guò)程，而四次揮手則是結(jié)束銷毀通道的一個(gè)其中過(guò)程。

每一條TCP連接只能有兩個(gè)端點(diǎn)（即兩個(gè)套接字），只能是點(diǎn)對(duì)點(diǎn)的；

TCP提供可靠的傳輸服務(wù)。傳送的數(shù)據(jù)無(wú)差錯(cuò)、不丟失、不重復(fù)、按序到達(dá)；

TCP提供全雙工通信。允許通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都可以發(fā)送數(shù)據(jù)，因?yàn)閮啥硕荚O(shè)有發(fā)送緩存和接受緩存；

面向字節(jié)流。雖然應(yīng)用程序與TCP交互是一次一個(gè)大小不等的數(shù)據(jù)塊，但TCP把這些數(shù)據(jù)看成一連串無(wú)結(jié)構(gòu)的字節(jié)流，它不保證接收方收到的數(shù)據(jù)塊和發(fā)送方發(fā)送的數(shù)據(jù)塊具有對(duì)應(yīng)大小關(guān)系，例如，發(fā)送方應(yīng)用程序交給發(fā)送方的TCP10個(gè)數(shù)據(jù)塊，接收方的TCP可能只用收到的4個(gè)數(shù)據(jù)塊字節(jié)流交付給上層的應(yīng)用程序

「TCP的可靠性原理」

可靠傳輸有如下兩個(gè)特點(diǎn)：

傳輸信道無(wú)差錯(cuò)，保證傳輸數(shù)據(jù)正確;

不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù)，接收方總是來(lái)得及處理收到的數(shù)據(jù);

首先，采用三次握手來(lái)建立TCP連接，四次握手來(lái)釋放TCP連接，從而保證建立的傳輸信道是可靠的。

其次，TCP采用了連續(xù)ARQ協(xié)議（回退N（Go-back-N）；超時(shí)自動(dòng)重傳）來(lái)保證數(shù)據(jù)傳輸?shù)恼_性，使用滑動(dòng)窗口協(xié)議來(lái)保證接方能夠及時(shí)處理所接收到的數(shù)據(jù)，進(jìn)行流量控制。

最后，TCP使用慢開(kāi)始、擁塞避免、快重傳和快恢復(fù)來(lái)進(jìn)行擁塞控制，避免網(wǎng)絡(luò)擁塞。

報(bào)文段

TCP雖面向字節(jié)流，但傳送的數(shù)據(jù)單元為報(bào)文段

報(bào)文段 = 首部 + 數(shù)據(jù)2部分

TCP的全部功能體現(xiàn)在它首部中各字段的作用

?

首部前20個(gè)字符固定、后面有4n個(gè)字節(jié)是根據(jù)需而增加的選項(xiàng)

故 TCP首部最小長(zhǎng)度 = 20字節(jié)

?「端口」：

源端口號(hào)和目地端口各占16位兩個(gè)字節(jié)，也就是端口的范圍是2^16=65535另外1024以下是系統(tǒng)保留的，從1024-65535是用戶使用的端口范圍

「seq序號(hào)」：占4字節(jié)，TCP連接中傳送的字節(jié)流中的每個(gè)字節(jié)都按順序編號(hào)。

例如：一段報(bào)文的序號(hào)字段值是107，攜帶的數(shù)據(jù)是100個(gè)字段，下一個(gè)報(bào)文段序號(hào)從107+100=207開(kāi)始。

「ack確認(rèn)號(hào)」：4個(gè)字節(jié)，是期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)。

例如：B收到A發(fā)送的報(bào)文，其序號(hào)字段是301，數(shù)據(jù)長(zhǎng)度是200字節(jié)，表明B正確收到A發(fā)送的到序號(hào)500為止的數(shù)據(jù)（301+200-1=500），B期望收到A下一個(gè)數(shù)據(jù)序號(hào)是501，B發(fā)送給A的確認(rèn)報(bào)文段中把a(bǔ)ck確認(rèn)號(hào)置為501。

「數(shù)據(jù)偏移」：頭部有可選字段，長(zhǎng)度不固定，指出TCP報(bào)文段的數(shù)據(jù)起始處距離報(bào)文段的起始處有多遠(yuǎn)。

「保留」：保留今后使用的，被標(biāo)為1。

「控制位」：由8個(gè)標(biāo)志位組成。每個(gè)標(biāo)志位表示一個(gè)控制功能。

其中主要的6個(gè)：

「URG緊急指針標(biāo)志」，為1表示緊急指針有效，為0忽略緊急指針。

「ACK確認(rèn)序號(hào)標(biāo)志」，為1表示確認(rèn)號(hào)有效，為0表示報(bào)文不含確認(rèn)信息，忽略確認(rèn)號(hào)字段，上面的確認(rèn)號(hào)是否有效就是通過(guò)該標(biāo)識(shí)控制的。

「PSH標(biāo)志」，為1表示帶有push標(biāo)志的數(shù)據(jù)，指示接收方在接收到該報(bào)文段以后，應(yīng)盡快將該報(bào)文段交給應(yīng)用程序，而不是在緩沖區(qū)排隊(duì)。

「RST重置連接標(biāo)志」，重置因?yàn)橹鳈C(jī)崩潰或其他原因而出現(xiàn)錯(cuò)誤的連接，或用于拒絕非法的報(bào)文段或非法的連接。

「SYN同步序號(hào)」，同步序號(hào)，用于建立連接過(guò)程，在連接請(qǐng)求中，SYN=1和ACK=0表示該數(shù)據(jù)段沒(méi)有使用捎帶的確認(rèn)域，而連接應(yīng)答捎帶一個(gè)確認(rèn)，即SYN=1和ACK=1。。

「FIN終止標(biāo)志」，用于釋放連接，為1時(shí)表示發(fā)送方?jīng)]有發(fā)送了。

「窗口」：滑動(dòng)窗口大小，用來(lái)告知發(fā)送端接收端緩存大小，以此控制發(fā)送端發(fā)送數(shù)據(jù)的速率，從而達(dá)到流量控制。

「校驗(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)證。

「緊急指針」：只有控制位中的URG為1時(shí)才有效，指出本報(bào)文段中的緊急數(shù)據(jù)的字節(jié)數(shù)。

「選項(xiàng)」：其長(zhǎng)度可變，定義其他的可選參數(shù)。

粘包與拆包

TCP是面向字節(jié)流的協(xié)議，把上層應(yīng)用層的數(shù)據(jù)看成字節(jié)流，所以它發(fā)送的不是固定大小的數(shù)據(jù)包，TCP協(xié)議也沒(méi)有字段說(shuō)明發(fā)送數(shù)據(jù)包的大小。

而且TCP不保證接受方應(yīng)用程序收到的數(shù)據(jù)塊和發(fā)送應(yīng)用程序發(fā)送的數(shù)據(jù)塊具有對(duì)應(yīng)的大小關(guān)系

比如發(fā)送方應(yīng)用程序交給發(fā)送方TCP 10個(gè)數(shù)據(jù)塊，接受方TCP可能只用了4個(gè)數(shù)據(jù)塊就完整的把接受到的字節(jié)流交給了上層應(yīng)用程序。

TCP底層并不了解上層業(yè)務(wù)數(shù)據(jù)的具體含義，它會(huì)根據(jù)TCP緩沖區(qū)的實(shí)際情況進(jìn)行包的劃分，所以在業(yè)務(wù)上認(rèn)為，一個(gè)完整的包可能會(huì)被TCP拆分成多個(gè)包進(jìn)行發(fā)送，也有可能把多個(gè)小的包封裝成一個(gè)大的數(shù)據(jù)包發(fā)送，這就是所謂的TCP粘包和拆包問(wèn)題

「TCP粘包/拆包解決策略」

由于TCP無(wú)法理解上一層的業(yè)務(wù)數(shù)據(jù)特點(diǎn)，所以TCP是無(wú)法保證發(fā)送的數(shù)據(jù)包不發(fā)生粘包和拆包，這個(gè)問(wèn)題只能通過(guò)上層的協(xié)議棧設(shè)計(jì)來(lái)解決，解決思路有一下幾種：

消息定長(zhǎng)：每個(gè)發(fā)送的數(shù)據(jù)包大小固定，比如100字節(jié)，不足100字節(jié)的用空格補(bǔ)充，接受方取數(shù)據(jù)的時(shí)候根據(jù)這個(gè)長(zhǎng)度來(lái)讀取數(shù)據(jù)

消息末尾增加換行符來(lái)表示一條完整的消息：接收方讀取的時(shí)候根據(jù)換行符來(lái)判斷是否是一條完整的消息，如果消息的內(nèi)容也包含換行符，那么這種方式就不合適了。

將消息分為消息頭和消息尾兩部分，消息頭指定數(shù)據(jù)長(zhǎng)度，根據(jù)消息長(zhǎng)度來(lái)讀取完整的消息，例如UDP協(xié)議是這么設(shè)計(jì)的，用兩個(gè)字節(jié)來(lái)表示消息長(zhǎng)度，所以UDP不存在粘包和拆包問(wèn)題。

三次握手

「第一次握手」：

客戶端將TCP報(bào)文標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個(gè)序號(hào)值seq=J，保存在TCP首部的序列號(hào)字段里，指明客戶端打算連接的服務(wù)器的端口，并將該數(shù)據(jù)包發(fā)送給服務(wù)器端，發(fā)送完畢后，客戶端進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器端確認(rèn)。

「第二次握手」：

服務(wù)器端收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道客戶端請(qǐng)求建立連接，服務(wù)器端將TCP報(bào)文標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機(jī)產(chǎn)生一個(gè)序號(hào)值seq=K，并將該數(shù)據(jù)包發(fā)送給客戶端以確認(rèn)連接請(qǐng)求，服務(wù)器端進(jìn)入SYN_RCVD狀態(tài)。

「第三次握手」：

客戶端收到確認(rèn)后，檢查ack是否為J+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給服務(wù)器端，服務(wù)器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務(wù)器端進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，隨后客戶端與服務(wù)器端之間可以開(kāi)始傳輸數(shù)據(jù)了。

「上面寫(xiě)的ack和ACK，不是同一個(gè)概念：」

小寫(xiě)的ack代表的是頭部的確認(rèn)號(hào)Acknowledge number， 縮寫(xiě)ack，是對(duì)上一個(gè)包的序號(hào)進(jìn)行確認(rèn)的號(hào)，ack=seq+1。

大寫(xiě)的ACK，則是我們上面說(shuō)的TCP首部的標(biāo)志位，用于標(biāo)志的TCP包是否對(duì)上一個(gè)包進(jìn)行了確認(rèn)操作，如果確認(rèn)了，則把ACK標(biāo)志位設(shè)置成1。

「TCP為什么三次握手而不是兩次握手」

為了實(shí)現(xiàn)可靠數(shù)據(jù)傳輸， TCP 協(xié)議的通信雙方， 都必須維護(hù)一個(gè)序列號(hào)， 以標(biāo)識(shí)發(fā)送出去的數(shù)據(jù)包中， 哪些是已經(jīng)被對(duì)方收到的。三次握手的過(guò)程即是通信雙方相互告知序列號(hào)起始值， 并確認(rèn)對(duì)方已經(jīng)收到了序列號(hào)起始值的必經(jīng)步驟

如果只是兩次握手， 至多只有連接發(fā)起方的起始序列號(hào)能被確認(rèn)， 另一方選擇的序列號(hào)則得不到確認(rèn)

「《計(jì)算機(jī)網(wǎng)絡(luò)》中是這樣說(shuō)的：」

為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤。

?

在書(shū)中同時(shí)舉了一個(gè)例子，如下：

?假如client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server，本來(lái)這是一個(gè)早已失效的報(bào)文段，但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。

于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接，假設(shè)不采用「三次握手」，那么只要server發(fā)出確認(rèn)，新的連接就建立了，由于現(xiàn)在client并沒(méi)有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。

但server卻以為新的連接已經(jīng)建立，并一直等待client發(fā)來(lái)數(shù)據(jù)，這樣，server的很多資源就白白浪費(fèi)掉了。

采用「三次握手」的辦法可以防止上述現(xiàn)象發(fā)生，例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)，server由于收不到確認(rèn)，就知道client并沒(méi)有要求建立連接。

「什么是半連接隊(duì)列」

服務(wù)器第一次收到客戶端的 SYN 之后，就會(huì)處于 SYN_RCVD狀態(tài)，此時(shí)雙方還沒(méi)有完全建立其連接，服務(wù)器會(huì)把此種狀態(tài)下請(qǐng)求連接放在一個(gè)隊(duì)列里，我們把這種隊(duì)列稱之為「半連接隊(duì)列」。

當(dāng)然還有一個(gè)「全連接隊(duì)列」，就是已經(jīng)完成三次握手，建立起連接的就會(huì)放在全連接隊(duì)列中。如果隊(duì)列滿了就有可能會(huì)出現(xiàn)丟包現(xiàn)象。

補(bǔ)充一點(diǎn)關(guān)于「SYN-ACK 重傳次數(shù)」的問(wèn)題：

服務(wù)器發(fā)送完SYN－ACK包，如果未收到客戶確認(rèn)包，服務(wù)器進(jìn)行首次重傳，等待一段時(shí)間仍未收到客戶確認(rèn)包，進(jìn)行第二次重傳，如果重傳次數(shù)超過(guò)系統(tǒng)規(guī)定的最大重傳次數(shù)，系統(tǒng)將該連接信息從半連接隊(duì)列中刪除。

「三次握手過(guò)程中可以攜帶數(shù)據(jù)嗎」

其實(shí)第三次握手的時(shí)候，是可以攜帶數(shù)據(jù)的，也就是說(shuō)，第一次、第二次握手不可以攜帶數(shù)據(jù)，而第三次握手是可以攜帶數(shù)據(jù)的。

假如第一次握手可以攜帶數(shù)據(jù)的話，如果有人要惡意攻擊服務(wù)器，那他每次都在第一次握手中的 SYN 報(bào)文中放入大量的數(shù)據(jù)，因?yàn)楣粽吒揪筒焕矸?wù)器的接收、發(fā)送能力是否正常，然后瘋狂著重復(fù)發(fā) SYN 報(bào)文的話，這會(huì)讓服務(wù)器花費(fèi)很多時(shí)間、內(nèi)存空間來(lái)接收這些報(bào)文。也就是說(shuō)，第一次握手可以放數(shù)據(jù)的話，其中一個(gè)簡(jiǎn)單的原因就是會(huì)讓服務(wù)器更加容易受到攻擊了。

而對(duì)于第三次的話，此時(shí)客戶端已經(jīng)處于 established 狀態(tài)，也就是說(shuō)，對(duì)于客戶端來(lái)說(shuō)，他已經(jīng)建立起連接了，并且也已經(jīng)知道服務(wù)器的接收、發(fā)送能力是正常的了，所以能攜帶數(shù)據(jù)沒(méi)啥毛病。

四次揮手

揮手請(qǐng)求可以是Client端，也可以是Server端發(fā)起的，我們假設(shè)是Client端發(fā)起：

第一次揮手：Client端發(fā)起揮手請(qǐng)求，向Server端發(fā)送標(biāo)志位是FIN報(bào)文段，設(shè)置序列號(hào)seq，此時(shí)，Client端進(jìn)入FIN_WAIT_1狀態(tài)，這表示Client端沒(méi)有數(shù)據(jù)要發(fā)送給Server端了。

第二次揮手：Server端收到了Client端發(fā)送的FIN報(bào)文段，向Client端返回一個(gè)標(biāo)志位是ACK的報(bào)文段，ack設(shè)為seq加1，Client端進(jìn)入FIN_WAIT_2狀態(tài)，Server端告訴Client端，我確認(rèn)并同意你的關(guān)閉請(qǐng)求。

第三次揮手：Server端向Client端發(fā)送標(biāo)志位是FIN的報(bào)文段，請(qǐng)求關(guān)閉連接，同時(shí)Client端進(jìn)入LAST_ACK狀態(tài)。

第四次揮手 ：Client端收到Server端發(fā)送的FIN報(bào)文段，向Server端發(fā)送標(biāo)志位是ACK的報(bào)文段，然后Client端進(jìn)入TIME_WAIT狀態(tài)，Server端收到Client端的ACK報(bào)文段以后，就關(guān)閉連接，此時(shí)，Client端等待2MSL的時(shí)間后依然沒(méi)有收到回復(fù)，則證明Server端已正常關(guān)閉，那好，Client端也可以關(guān)閉連接了。

「為什么連接的時(shí)候是三次握手，關(guān)閉的時(shí)候卻是四次握手？」

建立連接時(shí)因?yàn)楫?dāng)Server端收到Client端的SYN連接請(qǐng)求報(bào)文后，可以直接發(fā)送SYN+ACK報(bào)文。其中ACK報(bào)文是用來(lái)應(yīng)答的，SYN報(bào)文是用來(lái)同步的。所以建立連接只需要三次握手。

由于TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運(yùn)輸層通信協(xié)議，TCP是全雙工模式。

這就意味著，關(guān)閉連接時(shí)，當(dāng)Client端發(fā)出FIN報(bào)文段時(shí)，只是表示Client端告訴Server端數(shù)據(jù)已經(jīng)發(fā)送完畢了。當(dāng)Server端收到FIN報(bào)文并返回ACK報(bào)文段，表示它已經(jīng)知道Client端沒(méi)有數(shù)據(jù)發(fā)送了，但是Server端還是可以發(fā)送數(shù)據(jù)到Client端的，所以Server很可能并不會(huì)立即關(guān)閉SOCKET，直到Server端把數(shù)據(jù)也發(fā)送完畢。

當(dāng)Server端也發(fā)送了FIN報(bào)文段時(shí)，這個(gè)時(shí)候就表示Server端也沒(méi)有數(shù)據(jù)要發(fā)送了，就會(huì)告訴Client端，我也沒(méi)有數(shù)據(jù)要發(fā)送了，之后彼此就會(huì)愉快的中斷這次TCP連接。

「為什么TIME_WAIT要等待2MSL？」

MSL：報(bào)文段最大生存時(shí)間，它是任何報(bào)文段被丟棄前在網(wǎng)絡(luò)內(nèi)的最長(zhǎng)時(shí)間。

有以下兩個(gè)原因：

第一點(diǎn)：保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉：由于IP協(xié)議的不可靠性或者是其它網(wǎng)絡(luò)原因，導(dǎo)致了Server端沒(méi)有收到Client端的ACK報(bào)文，那么Server端就會(huì)在超時(shí)之后重新發(fā)送FIN，如果此時(shí)Client端的連接已經(jīng)關(guān)閉處于CLOESD狀態(tài)，那么重發(fā)的FIN就找不到對(duì)應(yīng)的連接了，從而導(dǎo)致連接錯(cuò)亂，所以，Client端發(fā)送完最后的ACK不能直接進(jìn)入CLOSED狀態(tài)，而要保持TIME_WAIT，當(dāng)再次收到FIN的時(shí)候，能夠保證對(duì)方收到ACK，最后正確關(guān)閉連接。

第二點(diǎn)：保證這次連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失如果Client端發(fā)送最后的ACK直接進(jìn)入CLOSED狀態(tài)，然后又再向Server端發(fā)起一個(gè)新連接，這時(shí)不能保證新連接的與剛關(guān)閉的連接的端口號(hào)是不同的，也就是新連接和老連接的端口號(hào)可能一樣了，那么就可能出現(xiàn)問(wèn)題：如果前一次的連接某些數(shù)據(jù)滯留在網(wǎng)絡(luò)中，這些延遲數(shù)據(jù)在建立新連接后到達(dá)Client端，由于新老連接的端口號(hào)和IP都一樣，TCP協(xié)議就認(rèn)為延遲數(shù)據(jù)是屬于新連接的，新連接就會(huì)接收到臟數(shù)據(jù)，這樣就會(huì)導(dǎo)致數(shù)據(jù)包混亂，所以TCP連接需要在TIME_WAIT狀態(tài)等待2倍MSL，才能保證本次連接的所有數(shù)據(jù)在網(wǎng)絡(luò)中消失。

流量控制

「RTT和RTO」

RTT：發(fā)送一個(gè)數(shù)據(jù)包到收到對(duì)應(yīng)的ACK，所花費(fèi)的時(shí)間

RTO：重傳時(shí)間間隔（TCP在發(fā)送一個(gè)數(shù)據(jù)包后會(huì)啟動(dòng)一個(gè)重傳定時(shí)器，RTO即定時(shí)器的重傳時(shí)間）

開(kāi)始預(yù)先算一個(gè)定時(shí)器時(shí)間，如果回復(fù)ACK，重傳定時(shí)器就自動(dòng)失效，即不需要重傳；如果沒(méi)有回復(fù)ACK，RTO定時(shí)器時(shí)間就到了，重傳。

RTO是本次發(fā)送當(dāng)前數(shù)據(jù)包所預(yù)估的超時(shí)時(shí)間，RTO不是固定寫(xiě)死的配置，是經(jīng)過(guò)RTT計(jì)算出來(lái)的。

「滑動(dòng)窗口」

TCP的滑動(dòng)窗口主要有兩個(gè)作用：

保證TCP的可靠性

保證TCP的流控特性

TCP報(bào)文頭有個(gè)字段叫Window，用于接收方通知發(fā)送方自己還有多少緩存區(qū)可以接收數(shù)據(jù)，發(fā)送方根據(jù)接收方的處理能力來(lái)發(fā)送數(shù)據(jù)，不會(huì)導(dǎo)致接收方處理不過(guò)來(lái)，這便是流量控制。

發(fā)送方都維持了一個(gè)連續(xù)的允許發(fā)送的幀的序號(hào)，稱為發(fā)送窗口；同時(shí)，接收方也維持了一個(gè)連續(xù)的允許接收的幀的序號(hào)，稱為接收窗口。

發(fā)送窗口和接收窗口的序號(hào)的上下界不一定要一樣，甚至大小也可以不同。

不同的滑動(dòng)窗口協(xié)議窗口大小一般不同。

發(fā)送方窗口內(nèi)的序列號(hào)代表了那些已經(jīng)被發(fā)送，但是還沒(méi)有被確認(rèn)的幀，或者是那些可以被發(fā)送的幀

滑動(dòng)窗口由四部分組成每個(gè)字節(jié)的數(shù)據(jù)都有唯一順序的編碼，隨著時(shí)間發(fā)展，未確認(rèn)部分與可以發(fā)送數(shù)據(jù)包編碼部分向右移動(dòng)，形式滑動(dòng)窗口

綠色：發(fā)送成功并已經(jīng)ACK確認(rèn)的數(shù)據(jù)

黃色：發(fā)送成功等待ACK確認(rèn)的數(shù)據(jù)（占用滑動(dòng)窗口大?。?/p>

紫色：滑動(dòng)窗口剩余大小可以發(fā)送的字節(jié)數(shù)量（滑動(dòng)窗口可用大?。?/p>

灰色：后續(xù)數(shù)據(jù)編碼

接收窗口的大小就是滑動(dòng)窗口的最大值，數(shù)據(jù)傳輸過(guò)程中滑動(dòng)窗口的可用大小是動(dòng)態(tài)變化的。

但是還有這么一點(diǎn)，滑動(dòng)窗口的設(shè)計(jì)僅僅是考慮到了處理方的處理能力，但是沒(méi)有考慮到道路的通暢問(wèn)題

就好像服務(wù)端可以處理100M數(shù)據(jù)，但是傳輸?shù)臄?shù)據(jù)99M都堵在路上了，這不就是導(dǎo)致道路阻塞了么？這就需要另外一個(gè)設(shè)計(jì)「擁塞避免」

「流量控制的目的」

如果發(fā)送者發(fā)送數(shù)據(jù)過(guò)快，接收者來(lái)不及接收，那么就會(huì)有分組丟失。

為了避免分組丟失，控制發(fā)送者的發(fā)送速度，使得接收者來(lái)得及接收，這就是流量控制。

流量控制根本目的是防止分組丟失，它是構(gòu)成TCP可靠性的一方面。

「如何實(shí)現(xiàn)流量控制」

由滑動(dòng)窗口協(xié)議（連續(xù)ARQ協(xié)議）實(shí)現(xiàn)?；瑒?dòng)窗口協(xié)議既保證了分組無(wú)差錯(cuò)、有序接收，也實(shí)現(xiàn)了流量控制。

主要的方式就是接收方返回的 ACK 中會(huì)包含自己的接收窗口的大小，并且利用大小來(lái)控制發(fā)送方的數(shù)據(jù)發(fā)送。

「流量控制引發(fā)的死鎖」

當(dāng)發(fā)送者收到了一個(gè)窗口為0的應(yīng)答，發(fā)送者便停止發(fā)送，等待接收者的下一個(gè)應(yīng)答。

但是如果這個(gè)窗口不為0的應(yīng)答在傳輸過(guò)程丟失，發(fā)送者一直等待下去，而接收者以為發(fā)送者已經(jīng)收到該應(yīng)答，等待接收新數(shù)據(jù)，這樣雙方就相互等待，從而產(chǎn)生死鎖。

為了避免流量控制引發(fā)的死鎖，TCP使用了「持續(xù)計(jì)時(shí)器」。每當(dāng)發(fā)送者收到一個(gè)零窗口的應(yīng)答后就啟動(dòng)該計(jì)時(shí)器。時(shí)間一到便主動(dòng)發(fā)送報(bào)文詢問(wèn)接收者的窗口大小。若接收者仍然返回零窗口，則重置該計(jì)時(shí)器繼續(xù)等待；若窗口不為0，則表示應(yīng)答報(bào)文丟失了，此時(shí)重置發(fā)送窗口后開(kāi)始發(fā)送，這樣就避免了死鎖的產(chǎn)生。

擁塞控制

「為什么要進(jìn)行擁塞控制」

假設(shè)網(wǎng)絡(luò)已經(jīng)出現(xiàn)擁塞，如果不處理?yè)砣?，那么延時(shí)增加，出現(xiàn)更多丟包，觸發(fā)發(fā)送方重傳數(shù)據(jù)，加劇擁塞情況，繼續(xù)惡性循環(huán)直至網(wǎng)絡(luò)癱瘓。

擁塞控制與流量控制的適應(yīng)場(chǎng)景和目的均不同。

擁塞發(fā)生前，可避免流量過(guò)快增長(zhǎng)拖垮網(wǎng)絡(luò)；擁塞發(fā)生時(shí)，唯一的選擇就是降低流量。

主要使用4種算法完成擁塞控制：

慢啟動(dòng)

擁塞避免

快重傳算法

快速恢復(fù)算法

算法1、2適用于擁塞發(fā)生前，算法3適用于擁塞發(fā)生時(shí)，算法4適用于擁塞解決后（相當(dāng)于擁塞發(fā)生前）。

「rwnd與cwnd」

rwnd（Receiver Window，接收者窗口）與cwnd（Congestion Window，擁塞窗口）：

rwnd是用于流量控制的窗口大小，主要取決于接收方的處理速度，由接收方通知發(fā)送方被動(dòng)調(diào)整。

cwnd是用于擁塞處理的窗口大小，取決于網(wǎng)絡(luò)狀況，由發(fā)送方探查網(wǎng)絡(luò)主動(dòng)調(diào)整。

同時(shí)考慮流量控制與擁塞處理，則發(fā)送方窗口的大小不超過(guò)min{rwnd， cwnd}。

「慢啟動(dòng)算法」

慢開(kāi)始算法的思路就是，不要一開(kāi)始就發(fā)送大量的數(shù)據(jù)，先探測(cè)一下網(wǎng)絡(luò)的擁塞程度，也就是說(shuō)由小到大逐漸增加擁塞窗口的大小。

這里用報(bào)文段的個(gè)數(shù)作為擁塞窗口的大小舉例說(shuō)明慢開(kāi)始算法，實(shí)際的擁塞窗口大小是以字節(jié)為單位的。

一個(gè)傳輸輪次所經(jīng)歷的時(shí)間其實(shí)就是往返時(shí)間RTT，而且每經(jīng)過(guò)一個(gè)傳輸輪次，擁塞窗口cwnd就加倍。

為了防止cwnd增長(zhǎng)過(guò)大引起網(wǎng)絡(luò)擁塞，還需設(shè)置一個(gè)慢開(kāi)始門(mén)限ssthresh狀態(tài)變量。

?

ssthresh的用法如下：

?cwnd《ssthresh時(shí)，使用慢開(kāi)始算法。

當(dāng)cwnd》ssthresh時(shí)，改用擁塞避免算法。

當(dāng)cwnd=ssthresh時(shí)，慢開(kāi)始與擁塞避免算法任意

注意，這里的慢并不是指cwnd的增長(zhǎng)速率慢，而是指在TCP開(kāi)始發(fā)送報(bào)文段時(shí)先設(shè)置cwnd=1，然后逐漸增大，這當(dāng)然比按照大的cwnd一下子把許多報(bào)文段突然注入到網(wǎng)絡(luò)中要慢得多。

「擁塞避免算法」

讓擁塞窗口cwnd緩慢地增大，即每經(jīng)過(guò)一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍。

這樣擁塞窗口cwnd按線性規(guī)律緩慢增長(zhǎng)，比慢開(kāi)始算法的擁塞窗口增長(zhǎng)速率緩慢得多

無(wú)論是在慢開(kāi)始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒(méi)有按時(shí)收到確認(rèn)，雖然沒(méi)有收到確認(rèn)可能是其他原因的分組丟失，但是因?yàn)闊o(wú)法判定，所以都當(dāng)做擁塞來(lái)處理），就把慢開(kāi)始門(mén)限ssthresh設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送窗口大小的一半（但不能小于2）。

然后把擁塞窗口cwnd重新設(shè)置為1，執(zhí)行慢開(kāi)始算法。

這樣做的目的就是要迅速減少主機(jī)發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生擁塞的路由器有足夠時(shí)間把隊(duì)列中積壓的分組處理完畢。

「整個(gè)擁塞控制的流程：」

假定cwnd=24時(shí)，網(wǎng)絡(luò)出現(xiàn)超時(shí)（擁塞），則更新后的ssthresh=12，cwnd重新設(shè)置為1，并執(zhí)行慢開(kāi)始算法。

當(dāng)cwnd=12=ssthresh時(shí)，改為執(zhí)行擁塞避免算法

注意：擁塞避免并非完全能夠避免了阻塞，而是使網(wǎng)絡(luò)比較不容易出現(xiàn)擁塞。

「快重傳算法」

快重傳要求接收方在收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)（為的是使發(fā)送方及早知道有報(bào)文段沒(méi)有到達(dá)對(duì)方，可提高網(wǎng)絡(luò)吞吐量約20%）而不要等到自己發(fā)送數(shù)據(jù)時(shí)捎帶確認(rèn)。

快重傳算法規(guī)定，發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段，而不必繼續(xù)等待設(shè)置的重傳計(jì)時(shí)器時(shí)間到期

「快恢復(fù)算法」

快重傳配合使用的還有快恢復(fù)算法，有以下兩個(gè)要點(diǎn)：

當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)時(shí)，就把ssthresh門(mén)限減半（為了預(yù)防網(wǎng)絡(luò)發(fā)生擁塞）。

但是接下去并不執(zhí)行慢開(kāi)始算法

考慮到如果網(wǎng)絡(luò)出現(xiàn)擁塞的話就不會(huì)收到好幾個(gè)重復(fù)的確認(rèn)，所以發(fā)送方現(xiàn)在認(rèn)為網(wǎng)絡(luò)可能沒(méi)有出現(xiàn)擁塞。

所以此時(shí)不執(zhí)行慢開(kāi)始算法，而是將cwnd設(shè)置為ssthresh減半后的值，然后執(zhí)行擁塞避免算法，使cwnd緩慢增大。

Socket

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

Socket不是一種協(xié)議，而是一個(gè)編程調(diào)用接口（API），屬于傳輸層（主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸）

對(duì)用戶來(lái)說(shuō)，只需調(diào)用Socket去組織數(shù)據(jù)，以符合指定的協(xié)議，即可通信

UDP「UDP協(xié)議特點(diǎn)」

UDP是無(wú)連接的傳輸層協(xié)議；

UDP使用盡最大努力交付，不保證可靠交付；

UDP是面向報(bào)文的，對(duì)應(yīng)用層交下來(lái)的報(bào)文，不合并，不拆分，保留原報(bào)文的邊界；

UDP沒(méi)有擁塞控制，因此即使網(wǎng)絡(luò)出現(xiàn)擁塞也不會(huì)降低發(fā)送速率；

UDP支持一對(duì)一一對(duì)多多對(duì)多的交互通信；

UDP的首部開(kāi)銷小，只有８字節(jié)

「TCP和UDP的區(qū)別」

TCP是可靠傳輸，UDP是不可靠傳輸;

TCP面向連接，UDP無(wú)連接;

TCP傳輸數(shù)據(jù)有序，UDP不保證數(shù)據(jù)的有序性;

TCP不保存數(shù)據(jù)邊界，UDP保留數(shù)據(jù)邊界;

TCP傳輸速度相對(duì)UDP較慢;

TCP有流量控制和擁塞控制，UDP沒(méi)有;

TCP是重量級(jí)協(xié)議，UDP是輕量級(jí)協(xié)議;

TCP首部較長(zhǎng)20字節(jié)，UDP首部較短８字節(jié);

「基于TCP和UDP的常用協(xié)議」

HTTP、HTTPS、FTP、TELNET、SMTP（簡(jiǎn)單郵件傳輸協(xié)議）協(xié)議基于可靠的TCP協(xié)議。

TFTP、DNS、DHCP、TFTP、SNMP（簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議）、RIP基于不可靠的UDP協(xié)議

報(bào)文段

UDP的報(bào)文段共有2個(gè)字段：數(shù)據(jù)字段 + 首部字段

「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)寫(xiě)入該字段中，如果不寫(xiě)入端口號(hào)，則把這個(gè)字段設(shè)置為 0，這樣，接收端的應(yīng)用程序就不能發(fā)送響應(yīng)了。

目的端口：接收端計(jì)算機(jī)上 UDP 軟件使用的端口，占據(jù) 16 位。

長(zhǎng)度：該字段占據(jù) 16 位，表示 UDP 數(shù)據(jù)報(bào)長(zhǎng)度，包含 UDP 報(bào)文頭和 UDP 數(shù)據(jù)長(zhǎng)度，因?yàn)?UDP 報(bào)文頭長(zhǎng)度是 8 個(gè)字節(jié)，所以這個(gè)值最小為 8。

校驗(yàn)值：該字段占據(jù) 16 位，可以檢驗(yàn)數(shù)據(jù)在傳輸過(guò)程中是否被損壞。

網(wǎng)絡(luò)層MAC地址

MAC稱為物理地址，也叫硬件地址，用來(lái)定義網(wǎng)絡(luò)設(shè)備的位置，MAC地址是網(wǎng)卡出廠時(shí)設(shè)定的，是固定的（但可以通過(guò)在設(shè)備管理器中或注冊(cè)表等方式修改，同一網(wǎng)段內(nèi)的MAC地址必須唯一）。

MAC地址采用十六進(jìn)制數(shù)表示，長(zhǎng)度是6個(gè)字節(jié)（48位），分為前24位和后24位。

?

MAC地址對(duì)應(yīng)于OSI參考模型的第二層數(shù)據(jù)鏈路層，工作在數(shù)據(jù)鏈路層的交換機(jī)維護(hù)著計(jì)算機(jī)MAC地址和自身端口的數(shù)據(jù)庫(kù)，交換機(jī)根據(jù)收到的數(shù)據(jù)幀中的目的MAC地址字段來(lái)轉(zhuǎn)發(fā)數(shù)據(jù)幀。

?IP地址

常見(jiàn)的IP地址分為IPv4與IPv6兩大類，當(dāng)前廣泛應(yīng)用的是IPv4，目前IPv4幾乎耗盡，下一階段必然會(huì)進(jìn)行版本升級(jí)到IPv6；

IP地址是以網(wǎng)絡(luò)號(hào)和主機(jī)號(hào)來(lái)標(biāo)示網(wǎng)絡(luò)上的主機(jī)的，我們把網(wǎng)絡(luò)號(hào)相同的主機(jī)稱之為本地網(wǎng)絡(luò)，網(wǎng)絡(luò)號(hào)不相同的主機(jī)稱之為遠(yuǎn)程網(wǎng)絡(luò)主機(jī)

本地網(wǎng)絡(luò)中的主機(jī)可以直接相互通信；遠(yuǎn)程網(wǎng)絡(luò)中的主機(jī)要相互通信必須通過(guò)本地網(wǎng)關(guān)（Gateway）來(lái)傳遞轉(zhuǎn)發(fā)數(shù)據(jù)。

IP地址對(duì)應(yīng)于OSI參考模型的第三層網(wǎng)絡(luò)層，工作在網(wǎng)絡(luò)層的路由器根據(jù)目標(biāo)IP和源IP來(lái)判斷是否屬于同一網(wǎng)段，如果是不同網(wǎng)段，則轉(zhuǎn)發(fā)數(shù)據(jù)包。

「IP地址格式和表示」

IP地址（IPv4）由32位二進(jìn)制數(shù)組成，分為4段（4個(gè)字節(jié)），每一段為8位二進(jìn)制數(shù)（1個(gè)字節(jié)）

每一段8位二進(jìn)制，中間使用英文的標(biāo)點(diǎn)符號(hào)。隔開(kāi)

由于二進(jìn)制數(shù)太長(zhǎng)，為了便于記憶和識(shí)別，把每一段8位二進(jìn)制數(shù)轉(zhuǎn)成十進(jìn)制，大小為0至255。

IP地址的這種表示法叫做「點(diǎn)分十進(jìn)制表示法」。

IP地址表示為：xxx.xxx.xxx.xxx舉個(gè)栗子：210.21.196.6就是一個(gè)IP地址的表示。

計(jì)算機(jī)的IP地址由兩部分組成，一部分為網(wǎng)絡(luò)標(biāo)識(shí)，一部分為主機(jī)標(biāo)識(shí)，同一網(wǎng)段內(nèi)的計(jì)算機(jī)網(wǎng)絡(luò)部分相同，主機(jī)部分不能同時(shí)重復(fù)出現(xiàn)。

「路由器」連接不同網(wǎng)段，負(fù)責(zé)不同網(wǎng)段之間的數(shù)據(jù)轉(zhuǎn)發(fā)，「交換機(jī)」連接的是同一網(wǎng)段的計(jì)算機(jī)。

通過(guò)設(shè)置網(wǎng)絡(luò)地址和主機(jī)地址，在互相連接的整個(gè)網(wǎng)絡(luò)中保證每臺(tái)主機(jī)的IP地址不會(huì)互相重疊，即IP地址具有了唯一性。

「IP地址分類詳解」

IP地址分A、B、C、D、E五類，其中A、B、C這三類是比較常用的IP地址，D、E類為特殊地址。

子網(wǎng)掩碼

「子網(wǎng)掩碼的概念及作用」

通過(guò)子網(wǎng)掩碼，才能表明一臺(tái)主機(jī)所在的子網(wǎng)與其他子網(wǎng)的關(guān)系，使網(wǎng)絡(luò)正常工作。

子網(wǎng)掩碼和IP地址做與運(yùn)算，分離出IP地址中的網(wǎng)絡(luò)地址和主機(jī)地址，用于判斷該IP地址是在本地網(wǎng)絡(luò)上，還是在遠(yuǎn)程網(wǎng)絡(luò)網(wǎng)上。

子網(wǎng)掩碼還用于將網(wǎng)絡(luò)進(jìn)一步劃分為若干子網(wǎng)，以避免主機(jī)過(guò)多而擁堵或過(guò)少而IP浪費(fèi)。

「子網(wǎng)掩碼的組成」

同IP地址一樣，子網(wǎng)掩碼是由長(zhǎng)度為32位二進(jìn)制數(shù)組成的一個(gè)地址。

子網(wǎng)掩碼32位與IP地址32位相對(duì)應(yīng)，IP地址如果某位是網(wǎng)絡(luò)地址，則子網(wǎng)掩碼為1，否則為0。

舉個(gè)栗子：如：11111111.11111111.11111111.00000000?

左邊連續(xù)的1的個(gè)數(shù)代表網(wǎng)絡(luò)號(hào)的長(zhǎng)度，（使用時(shí)必須是連續(xù)的，理論上也可以不連續(xù)），右邊連續(xù)的0的個(gè)數(shù)代表主機(jī)號(hào)的長(zhǎng)度。

?「為什么要使用子網(wǎng)掩碼」

兩臺(tái)主機(jī)要通信，首先要判斷是否處于同一網(wǎng)段，即網(wǎng)絡(luò)地址是否相同。

如果相同，那么可以把數(shù)據(jù)包直接發(fā)送到目標(biāo)主機(jī)，否則就需要路由網(wǎng)關(guān)將數(shù)據(jù)包轉(zhuǎn)發(fā)送到目的地。

?

可以這么簡(jiǎn)單的理解：A主機(jī)要與B主機(jī)通信，A和B各自的IP地址與A主機(jī)的子網(wǎng)掩碼進(jìn)行And與運(yùn)算，看得出的結(jié)果：

1、結(jié)果如果相同，則說(shuō)明這兩臺(tái)主機(jī)是處于同一個(gè)網(wǎng)段，這樣A可以通過(guò)ARP廣播發(fā)現(xiàn)B的MAC地址，B也可以發(fā)現(xiàn)A的MAC地址來(lái)實(shí)現(xiàn)正常通信。

2、如果結(jié)果不同，ARP廣播會(huì)在本地網(wǎng)關(guān)終結(jié)，這時(shí)候A會(huì)把發(fā)給B的數(shù)據(jù)包先發(fā)給本地網(wǎng)關(guān)，網(wǎng)關(guān)再根據(jù)B主機(jī)的IP地址來(lái)查詢路由表，再將數(shù)據(jù)包繼續(xù)傳遞轉(zhuǎn)發(fā)，最終送達(dá)到目的地B。

?

?

計(jì)算機(jī)的網(wǎng)關(guān)（Gateway）就是到其他網(wǎng)段的出口，也就是路由器接口IP地址。

路由器接口使用的IP地址可以是本網(wǎng)段中任何一個(gè)地址，不過(guò)通常使用該網(wǎng)段的第一個(gè)可用的地址或最后一個(gè)可用的地址，這是為了盡可能避免和本網(wǎng)段中的主機(jī)地址沖突。

?在如下拓?fù)鋱D示例中，A與B，C與D，都可以直接相互通信（都是屬于各自同一網(wǎng)段，不用經(jīng)過(guò)路由器）

但是A與C，A與D，B與C，B與D它們之間不屬于同一網(wǎng)段，所以它們通信是要經(jīng)過(guò)本地網(wǎng)關(guān)，然后路由器根據(jù)對(duì)方IP地址，在路由表中查找恰好有匹配到對(duì)方IP地址的直連路由，于是從另一邊網(wǎng)關(guān)接口轉(zhuǎn)發(fā)出去實(shí)現(xiàn)互連

「子網(wǎng)掩碼和IP地址的關(guān)系」

子網(wǎng)掩碼是用來(lái)判斷任意兩臺(tái)主機(jī)的IP地址是否屬于同一網(wǎng)絡(luò)的依據(jù)

拿雙方主機(jī)的IP地址和自己主機(jī)的子網(wǎng)掩碼做與運(yùn)算，如結(jié)果為同一網(wǎng)絡(luò)，就可以直接通信

「如何根據(jù)IP地址和子網(wǎng)掩碼，計(jì)算網(wǎng)絡(luò)地址：」

將IP地址與子網(wǎng)掩碼轉(zhuǎn)換成二進(jìn)制數(shù)。

將二進(jìn)制形式的 IP 地址與子網(wǎng)掩碼做與運(yùn)算。

將得出的結(jié)果轉(zhuǎn)化為十進(jìn)制，便得到網(wǎng)絡(luò)地址。

網(wǎng)關(guān)

網(wǎng)關(guān)實(shí)質(zhì)上是一個(gè)網(wǎng)絡(luò)通向其他網(wǎng)絡(luò)的IP地址。

比如有網(wǎng)絡(luò)A和網(wǎng)絡(luò)B，網(wǎng)絡(luò)A的IP地址范圍為192.168.1.1~192. 168.1.254，子網(wǎng)掩碼為255.255.255.0；

網(wǎng)絡(luò)B的IP地址范圍為192.168.2.1~192.168.2.254，子網(wǎng)掩碼為255.255.255.0。

在沒(méi)有路由器的情況下，兩個(gè)網(wǎng)絡(luò)之間是不能進(jìn)行TCP/IP通信的，即使是兩個(gè)網(wǎng)絡(luò)連接在同一臺(tái)交換機(jī)（或集線器）上，TCP/IP協(xié)議也會(huì)根據(jù)子網(wǎng)掩碼（255.255.255.0）判定兩個(gè)網(wǎng)絡(luò)中的主機(jī)處在不同的網(wǎng)絡(luò)里。

而要實(shí)現(xiàn)這兩個(gè)網(wǎng)絡(luò)之間的通信，則必須通過(guò)網(wǎng)關(guān)。

如果網(wǎng)絡(luò)A中的主機(jī)發(fā)現(xiàn)數(shù)據(jù)包的目的主機(jī)不在本地網(wǎng)絡(luò)中，就把數(shù)據(jù)包轉(zhuǎn)發(fā)給它自己的網(wǎng)關(guān)，再由網(wǎng)關(guān)轉(zhuǎn)發(fā)給網(wǎng)絡(luò)B的網(wǎng)關(guān)，網(wǎng)絡(luò)B的網(wǎng)關(guān)再轉(zhuǎn)發(fā)給網(wǎng)絡(luò)B的某個(gè)主機(jī)。網(wǎng)絡(luò)B向網(wǎng)絡(luò)A轉(zhuǎn)發(fā)數(shù)據(jù)包的過(guò)程。

「所以說(shuō)，只有設(shè)置好網(wǎng)關(guān)的IP地址，TCP/IP協(xié)議才能實(shí)現(xiàn)不同網(wǎng)絡(luò)之間的相互通信?！?/p>

?

那么這個(gè)IP地址是哪臺(tái)機(jī)器的IP地址呢？

?網(wǎng)關(guān)的IP地址是具有路由功能的設(shè)備的IP地址，具有路由功能的設(shè)備有路由器、啟用了路由協(xié)議的服務(wù)器（實(shí)質(zhì)上相當(dāng)于一臺(tái)路由器）、代理服務(wù)器（也相當(dāng)于一臺(tái)路由器）。

Ping

Ping是我們測(cè)試網(wǎng)絡(luò)連接的常用指令。

它利用ICMP報(bào)文檢測(cè)網(wǎng)絡(luò)連接。

「假設(shè)A ping B」

ping通知系統(tǒng)建立一個(gè)固定格式的ICMP請(qǐng)求數(shù)據(jù)包。

ICMP協(xié)議打包這個(gè)數(shù)據(jù)包和B的IP地址轉(zhuǎn)交給IP協(xié)議層

IP層協(xié)議將機(jī)器B的IP地址為目的地址，本機(jī)的IP地址為源地址，加上一些頭部必要的控制信息，構(gòu)建一個(gè)IP數(shù)據(jù)包

獲取B的MAC地址，做這個(gè)操作首先機(jī)器A會(huì)判斷B是否在同一網(wǎng)段內(nèi)，若IP層協(xié)議通過(guò)B的IP地址和自己的子網(wǎng)掩碼，發(fā)現(xiàn)它跟自己屬于同一網(wǎng)絡(luò)，就直接在本網(wǎng)絡(luò)查找這臺(tái)機(jī)器的MAC，否則則通過(guò)路由器進(jìn)行類似查找。

?

接下來(lái)是ARP協(xié)議根據(jù)IP地址查找MAC地址的過(guò)程：

?若兩臺(tái)機(jī)器之前有過(guò)通信，在機(jī)器A的ARP緩存表里應(yīng)該存有B的IP與其MAC地址的映射關(guān)系。

若沒(méi)有，則通過(guò)發(fā)送ARP請(qǐng)求廣播，得到回應(yīng)的B機(jī)器MAC地址，并交給數(shù)據(jù)鏈路層

數(shù)據(jù)鏈路層構(gòu)建一個(gè)數(shù)據(jù)幀，目的地址是IP層傳過(guò)來(lái)的MAC地址，源地址是本機(jī)的MAC地址，再附加一些必要的控制信息，依據(jù)以太網(wǎng)的介質(zhì)訪問(wèn)規(guī)則將他們傳送出去

機(jī)器B收到這個(gè)數(shù)據(jù)幀后，先檢查目的地址，和本機(jī)MAC地址對(duì)比：

符合，接受，接收后檢查該數(shù)據(jù)幀，將IP數(shù)據(jù)包從幀中提取出來(lái)，交給本機(jī)的的IP地址協(xié)議層協(xié)議，IP協(xié)議層檢查之后，將有用的信息提取給ICMP協(xié)議，后者處理，馬上構(gòu)建一個(gè)ICMP應(yīng)答包，發(fā)送給A，其過(guò)程和主機(jī)A發(fā)送ICMP請(qǐng)求包到B的過(guò)程類似，但不用ARP廣播收取A的信息，因?yàn)檎?qǐng)求包中已經(jīng)有足夠的信息用于B回應(yīng)A。

若不符合，丟棄。

可以知道PING的過(guò)程即一段發(fā)送報(bào)文和接受確認(rèn)報(bào)文的過(guò)程，在來(lái)回直接可以計(jì)算時(shí)延。

DNS

DNS通過(guò)主機(jī)名，最終得到該主機(jī)名對(duì)應(yīng)的IP地址的過(guò)程叫做域名解析（或主機(jī)名解析）。

「通俗的講」，我們更習(xí)慣于記住一個(gè)網(wǎng)站的名字，www.baidu.com，而不是記住它的ip地址，比如：167.23.10.2

「工作原理」

將主機(jī)域名轉(zhuǎn)換為ip地址，屬于應(yīng)用層協(xié)議，使用UDP傳輸。

第一步，客戶端向本地DNS服務(wù)器發(fā)送解析請(qǐng)求

第二步，本地DNS如有相應(yīng)記錄會(huì)直接返回結(jié)果給客戶端，如沒(méi)有就向DNS根服務(wù)器發(fā)送請(qǐng)求

第三步，DSN根服務(wù)器接收到請(qǐng)求，返回給本地服務(wù)器一個(gè)所查詢域的主域名服務(wù)器的地址

第四步，本地dns服務(wù)器再向返回的主域名服務(wù)器地址發(fā)送查詢請(qǐng)求

第五步，主域名服務(wù)器如有記錄就返回結(jié)果，沒(méi)有的話返回相關(guān)的下級(jí)域名服務(wù)器地址

第六步，本地DNS服務(wù)器繼續(xù)向接收到的地址進(jìn)行查詢請(qǐng)求

第七步，下級(jí)域名服務(wù)器有相應(yīng)記錄，返回結(jié)果

第八步，本地dns服務(wù)器將收到的返回地址發(fā)給客戶端，同時(shí)寫(xiě)入自己的緩存，以便下次查詢

DNS域名查詢實(shí)際上就是個(gè)不斷遞歸查詢的過(guò)程，直到查找到相應(yīng)結(jié)果，需要注意的時(shí)，當(dāng)找不到相應(yīng)記錄，會(huì)返回空結(jié)果，而不是超時(shí)信息

DNS記錄

?

A記錄

?定義www.example.com的ip地址

www.example.com. IN A 139.18.28.5;

上面的就是一條 DNS 記錄，純文本即可。

www.example.com 是要解析的域名。

A 是記錄的類型，A 記錄代表著這是一條用于解析 IPv4 地址的記錄。

從這條記錄可知，www.example.com的 IP 地址是 139.18.28.5。

?

CNAME

?CNAME用于定義域名的別名，如下面這條 DNS 記錄：

定義www.example.com的別名

a.example.com. IN CNAME b.example.com.

這條 DNS 記錄定義了 a.example.com 是 b.example.com 的別名。

用戶在瀏覽器中輸入 a.example.com 時(shí)候，通過(guò) DNS 查詢會(huì)知道 a.example.com 是 b.example.com 的別名，因此需要實(shí)際 IP 的時(shí)候，會(huì)去拿 b.example.com 的 A 記錄。

當(dāng)你想把一個(gè)網(wǎng)站遷移到新域名，舊域名仍然保留的時(shí)候；還有當(dāng)你想將自己的靜態(tài)資源放到 CDN 上的時(shí)候，CNAME 就非常有用。

?

AAAA 記錄

?A 記錄是域名和 IPv4 地址的映射關(guān)系。和 A 記錄類似，AAAA 記錄則是域名和 IPv6 地址的映射關(guān)系。

?

MX記錄

?MX 記錄是郵件記錄，用來(lái)描述郵件服務(wù)器的域名。

在工作中，我們經(jīng)常會(huì)發(fā)郵件到某個(gè)同事的郵箱。

比如說(shuō)，發(fā)送一封郵件到 xiaoming@xiaoflyfish.com，那么如何知道哪個(gè) IP 地址是郵件服務(wù)器呢？

這個(gè)時(shí)候就可以用到下面這條 MX 記錄：

IN MX mail.xiaoflyfish.com

mail.xiaoflyfish.com 的 IP 地址可以通過(guò)查詢 mail.xiaoflyfishcom的 A 記錄和 AAAA 記錄獲得。

?

NS 記錄

?NS記錄是描述 DNS 服務(wù)器網(wǎng)址。從 DNS 的存儲(chǔ)結(jié)構(gòu)上說(shuō)，Name Server 中含有權(quán)威 DNS 服務(wù)的目錄。

也就是說(shuō)，NS 記錄指定哪臺(tái) Server 是回答 DNS 查詢的權(quán)威域名服務(wù)器。

當(dāng)一個(gè) DNS 查詢看到 NS 記錄的時(shí)候，會(huì)再去 NS 記錄配置的 DNS 服務(wù)器查詢，得到最終的記錄。如下面這個(gè)例子：

a.com. IN NS ns1.a.com.

a.com. IN NS ns2.a.com.

當(dāng)解析 a.com 地址時(shí)，我們看到 a.com 有兩個(gè) NS 記錄，所以確定最終 a.com 的記錄在 ns1.a.com 和 ns2.a.com 上。

從設(shè)計(jì)上看，ns1 和 ns2 是網(wǎng)站 a.com 提供的智能 DNS 服務(wù)器，可以提供負(fù)載均衡、分布式 Sharding 等服務(wù)。

比如當(dāng)一個(gè)北京的用戶想要訪問(wèn) a.com 的時(shí)候，ns1 看到這是一個(gè)北京的 IP 就返回一個(gè)離北京最近的機(jī)房 IP。

上面代碼中 a.com 配置了兩個(gè) NS 記錄。

通常 NS 不會(huì)只有一個(gè)，這是為了保證高可用，一個(gè)掛了另一個(gè)還能繼續(xù)服務(wù)。

通常數(shù)字小的 NS 記錄優(yōu)先級(jí)更高，也就是 ns1 會(huì)優(yōu)先于 ns2 響應(yīng)。

配置了上面的 NS 記錄后，如果還配置了 a.com 的 A 記錄，那么這個(gè) A 記錄會(huì)被 NS 記錄覆蓋。

ARP協(xié)議

ARP即地址解析協(xié)議， 用于實(shí)現(xiàn)從 IP 地址到 MAC 地址的映射，即詢問(wèn)目標(biāo)IP對(duì)應(yīng)的MAC地址。

「ARP協(xié)議的工作過(guò)程」

首先，每個(gè)主機(jī)都會(huì)有自己的ARP緩存區(qū)中建立一個(gè)ARP列表，以表示IP地址和MAC地址之間的對(duì)應(yīng)關(guān)系

當(dāng)源主機(jī)要發(fā)送數(shù)據(jù)時(shí)，首先檢測(cè)ARP列表中是否對(duì)應(yīng)IP地址的目的主機(jī)的MAC地址，如果有，則直接發(fā)送數(shù)據(jù)，如果沒(méi)有，就向本網(wǎng)段的所有主機(jī)發(fā)送ARP數(shù)據(jù)包

當(dāng)本網(wǎng)絡(luò)的所有主機(jī)收到該ARP數(shù)據(jù)包時(shí)，首先檢查數(shù)據(jù)包中的IP地址是否是自己的IP地址，如果不是，則忽略該數(shù)據(jù)包，如果是，則首先從數(shù)據(jù)包中取出源主機(jī)的IP和MAC地址寫(xiě)入到ARP列表中，如果存在，則覆蓋然后將自己的MAC地址寫(xiě)入ARP響應(yīng)包中，告訴源主機(jī)自己是它想要找的MAC地址

源主機(jī)收到ARP響應(yīng)包后，將目的主機(jī)的IP和MAC地址寫(xiě)入ARP列表，并利用此信息發(fā)送數(shù)據(jù)，如果源主機(jī)一直沒(méi)有收到ARP響應(yīng)數(shù)據(jù)包，表示ARP查詢失敗。

數(shù)字簽名網(wǎng)絡(luò)傳輸過(guò)程中需要經(jīng)過(guò)很多中間節(jié)點(diǎn)，雖然數(shù)據(jù)無(wú)法被解密，但可能被篡改

數(shù)字簽名校驗(yàn)數(shù)據(jù)的完整性

「數(shù)字簽名有兩種功效」：

能確定消息確實(shí)是由發(fā)送方簽名并發(fā)出來(lái)的，因?yàn)閯e人假冒不了發(fā)送方的簽名。

數(shù)字簽名能確定消息的完整性，證明數(shù)據(jù)是否未被篡改過(guò)。

將一段文本先用Hash函數(shù)生成消息摘要，然后用發(fā)送者的私鑰加密生成數(shù)字簽名，與原文文一起傳送給接收者

接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息，然后用HASH函數(shù)對(duì)收到的原文產(chǎn)生一個(gè)摘要信息，與上一步得到的摘要信息對(duì)比。

如果相同，則說(shuō)明收到的信息是完整的，在傳輸過(guò)程中沒(méi)有被修改，否則說(shuō)明信息被修改過(guò)，因此數(shù)字簽名能夠驗(yàn)證信息的完整性。

SQL注入SQL注入的原理是將SQL代碼偽裝到輸入?yún)?shù)中，傳遞到服務(wù)器解析并執(zhí)行的一種攻擊手法。

「SQL注入攻擊實(shí)例」

比如，在一個(gè)登錄界面，要求輸入用戶名和密碼，可以這樣輸入實(shí)現(xiàn)免帳號(hào)登錄：

用戶名： ‘or 1 = 1 --

密 碼：

用戶一旦點(diǎn)擊登錄，如若沒(méi)有做特殊處理，那么這個(gè)非法用戶就很得意的登陸進(jìn)去了。

下面我們分析一下：從理論上說(shuō)，后臺(tái)認(rèn)證程序中會(huì)有如下的SQL語(yǔ)句：

String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”;

因此，當(dāng)輸入了上面的用戶名和密碼，上面的SQL語(yǔ)句變成：

SELECT * FROM user_table WHERE username=’’or 1 = 1 –- and password=’’

分析上述SQL語(yǔ)句我們知道，username=‘ or 1=1 這個(gè)語(yǔ)句一定會(huì)成功；然后后面加兩個(gè) -，這意味著注釋，它將后面的語(yǔ)句注釋，讓他們不起作用，這樣，上述語(yǔ)句永遠(yuǎn)都能正確執(zhí)行，用戶輕易騙過(guò)系統(tǒng)，獲取合法身份。

「應(yīng)對(duì)方法」

?

預(yù)編譯

?使用預(yù)編譯手段，綁定參數(shù)是最好的防SQL注入的方法。

目前許多的ORM框架及JDBC等都實(shí)現(xiàn)了SQL預(yù)編譯和參數(shù)綁定功能，攻擊者的惡意SQL會(huì)被當(dāng)做SQL的參數(shù)而不是SQL命令被執(zhí)行。

在mybatis的mapper文件中，對(duì)于傳遞的參數(shù)我們一般是使用 # 和$來(lái)獲取參數(shù)值。

當(dāng)使用#時(shí)，變量是占位符，就是一般我們使用java的jdbc的PrepareStatement時(shí)的占位符，所有可以防止sql注入；

當(dāng)使用$時(shí)，變量就是直接追加在sql中，一般會(huì)有sql注入問(wèn)題。

?

使用正則表達(dá)式過(guò)濾傳入的參數(shù)

??

過(guò)濾參數(shù)中含有的一些數(shù)據(jù)庫(kù)關(guān)鍵詞

?加密算法加密算法分「對(duì)稱加密」 和 「非對(duì)稱加密」，其中對(duì)稱加密算法的加密與解密密鑰相同，非對(duì)稱加密算法的加密密鑰與解密密鑰不同，此外，還有一類不需要密鑰的「散列算法」。

常見(jiàn)的 「對(duì)稱加密」 算法主要有 DES、3DES、AES 等，常見(jiàn)的 「非對(duì)稱算法」 主要有 RSA、DSA 等，「散列算法」 主要有 SHA-1、MD5 等。

對(duì)稱加密

在 「對(duì)稱加密算法」 中，使用的密鑰只有一個(gè)，發(fā)送和接收雙方都使用這個(gè)密鑰對(duì)數(shù)據(jù)進(jìn)行 「加密」 和 「解密」。

數(shù)據(jù)加密過(guò)程：在對(duì)稱加密算法中，數(shù)據(jù)發(fā)送方 將 「明文」 （原始數(shù)據(jù)） 和 「加密密鑰」 一起經(jīng)過(guò)特殊 「加密處理」，生成復(fù)雜的 「加密密文」 進(jìn)行發(fā)送。

數(shù)據(jù)解密過(guò)程：「數(shù)據(jù)接收方」 收到密文后，若想讀取原數(shù)據(jù)，則需要使用 「加密使用的密鑰」 及相同算法的 「逆算法」 對(duì)加密的密文進(jìn)行解密，才能使其恢復(fù)成 「可讀明文」。

非對(duì)稱加密

「非對(duì)稱加密算法」，它需要兩個(gè)密鑰，一個(gè)稱為 「公開(kāi)密鑰」 （public key），即 「公鑰」，另一個(gè)稱為 「私有密鑰」 （private key），即 「私鑰」。

因?yàn)?「加密」 和 「解密」 使用的是兩個(gè)不同的密鑰，所以這種算法稱為 「非對(duì)稱加密算法」。

如果使用 「公鑰」 對(duì)數(shù)據(jù) 「進(jìn)行加密」，只有用對(duì)應(yīng)的 「私鑰」 才能 「進(jìn)行解密」。

如果使用 「私鑰」 對(duì)數(shù)據(jù) 「進(jìn)行加密」，只有用對(duì)應(yīng)的 「公鑰」 才能 「進(jìn)行解密」。

「例子」：甲方生成 「一對(duì)密鑰」 并將其中的一把作為 「公鑰」 向其它人公開(kāi)，得到該公鑰的 「乙方」 使用該密鑰對(duì)機(jī)密信息 「進(jìn)行加密」 后再發(fā)送給甲方，甲方再使用自己保存的另一把 「專用密鑰」 （「私鑰」），對(duì) 「加密」 后的信息 「進(jìn)行解密」。

網(wǎng)絡(luò)攻擊CSRF和XSS

「XSS：」

跨站腳本是一種網(wǎng)站應(yīng)用程序的安全漏洞攻擊，是代碼注入的一種。

它允許惡意用戶將代碼注入到網(wǎng)頁(yè)上，其他用戶在觀看網(wǎng)頁(yè)時(shí)就會(huì)受到影響，這類攻擊通常包含了HTML以及用戶端腳本語(yǔ)言。

比如通過(guò)客戶端腳本語(yǔ)言（最常見(jiàn)如：JavaScript）

在一個(gè)論壇發(fā)帖中發(fā)布一段惡意的JavaScript代碼就是腳本注入，如果這個(gè)代碼內(nèi)容有請(qǐng)求外部服務(wù)器，那么就叫做XSS

「XSS攻擊分類」

?

反射性XSS攻擊 （非持久性XSS攻擊）

?例如，正常發(fā)送消息：

http://www.test.com/message.php？send=Hello，World！

接收者將會(huì)接收信息并顯示HelloWorld；但是，非正常發(fā)送消息：

http://www.test.com/message.php？send=《script》alert（‘foolish！’）《/script》！

接收者接收消息顯示的時(shí)候?qū)?huì)彈出警告窗口！

?

持久性XSS攻擊 （留言板場(chǎng)景）

?一般指XSS攻擊代碼存儲(chǔ)在網(wǎng)站數(shù)據(jù)庫(kù)，當(dāng)一個(gè)頁(yè)面被用戶打開(kāi)的時(shí)候執(zhí)行。

也就是說(shuō)，每當(dāng)用戶使用瀏覽器打開(kāi)指定頁(yè)面時(shí)，腳本便執(zhí)行。

與非持久性XSS攻擊相比，持久性XSS攻擊危害性更大。

從名字就可以了解到，持久性XSS攻擊就是將攻擊代碼存入數(shù)據(jù)庫(kù)中，然后客戶端打開(kāi)時(shí)就執(zhí)行這些攻擊代碼。

例如，留言板表單中的表單域：

《input type=“text” name=“content” value=“這里是用戶填寫(xiě)的數(shù)據(jù)”》

正常操作流程是：用戶是提交相應(yīng)留言信息 — 將數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù) — 其他用戶訪問(wèn)留言板，應(yīng)用去數(shù)據(jù)并顯示；

而非正常操作流程是攻擊者在value填寫(xiě)：

《script》alert（‘foolish！’）；《/script》 《！--或者h(yuǎn)tml其他標(biāo)簽（破壞樣式。。。）、一段攻擊型代碼--》

并將數(shù)據(jù)提交、存儲(chǔ)到數(shù)據(jù)庫(kù)中；當(dāng)其他用戶取出數(shù)據(jù)顯示的時(shí)候，將會(huì)執(zhí)行這些攻擊性代碼

「CSRF：」

跨站請(qǐng)求偽造，是一種挾制用戶在當(dāng)前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。

比如冒充用戶發(fā)起請(qǐng)求（在用戶不知情的情況下），完成一些違背用戶意愿的請(qǐng)求（如惡意發(fā)帖，刪帖，改密碼，發(fā)郵件等）。

DOS攻擊

DOS：中文名稱是拒絕服務(wù)，該攻擊的效果是使得計(jì)算機(jī)或網(wǎng)絡(luò)無(wú)法提供正常的服務(wù)

「DOS攻擊的原理：」

首先攻擊者向被攻擊的服務(wù)器發(fā)送大量的虛假IP請(qǐng)求，被攻擊者在收到請(qǐng)求后返回確認(rèn)信息，等待攻擊者進(jìn)行確認(rèn)，該過(guò)程需要TCP的三次握手，由于攻擊者發(fā)送的請(qǐng)求信息是虛假的，所以服務(wù)器接收不到返回的確認(rèn)信息，在一段時(shí)間內(nèi)服務(wù)器會(huì)處與等待狀態(tài)，而分配給這次請(qǐng)求的資源卻被有被釋放

當(dāng)被攻擊者等待一定的時(shí)間后，會(huì)因連接超時(shí)而斷開(kāi)，這時(shí)攻擊者在次發(fā)送新的虛假信息請(qǐng)求，這樣最終服務(wù)器資源被耗盡，直到癱瘓

「DDOS：中文名稱是分布式拒絕服務(wù)攻擊」

指的是攻擊者控制多臺(tái)主機(jī)同時(shí)向同一主機(jī)或網(wǎng)絡(luò)發(fā)起DOS攻擊

DRDoS分布反射式拒絕服務(wù)攻擊這是DDoS攻擊的變形

「DDOS究竟如何攻擊」

目前最流行也是最好用的攻擊方法就是使用SYN-Flood進(jìn)行攻擊，SYN-Flood也就是SYN洪水攻擊

SYN-Flood不會(huì)完成TCP三次握手的第三步，也就是不發(fā)送確認(rèn)連接的信息給服務(wù)器，這樣，服務(wù)器無(wú)法完成第三次握手，但服務(wù)器不會(huì)立即放棄，服務(wù)器會(huì)不停的重試并等待一定的時(shí)間后放棄這個(gè)未完成的連接，這段時(shí)間叫做SYN timeout，這段時(shí)間大約30秒-2分鐘左右。

若是一個(gè)用戶在連接時(shí)出現(xiàn)問(wèn)題導(dǎo)致服務(wù)器的一個(gè)線程等待1分鐘并不是什么大不了的問(wèn)題，但是若有人用特殊的軟件大量模擬這種情況，那后果就可想而知了。一個(gè)服務(wù)器若是處理這些大量的半連接信息而消耗大量的系統(tǒng)資源和網(wǎng)絡(luò)帶寬，這樣服務(wù)器就不會(huì)再有空余去處理普通用戶的正常請(qǐng)求（因?yàn)榭蛻舻恼Ｕ?qǐng)求比率很?。@樣這個(gè)服務(wù)器就無(wú)法工作了，這種攻擊就叫做SYN-Flood攻擊

到目前為止，進(jìn)行DDoS攻擊的防御還是比較困難的

首先，這種攻擊的特點(diǎn)是它利用了TCP/IP協(xié)議的漏洞，除非你不用TCP/IP，才有可能完全抵御住DDoS攻擊

不過(guò)這不等于我們就沒(méi)有辦法阻擋DDoS攻擊，我們可以盡力來(lái)減少DDoS的攻擊

「下面就是一些防御方法：」

關(guān)閉不必要的服務(wù)

限制同時(shí)打開(kāi)的SYN半連接數(shù)目

縮短SYN半連接的time out 時(shí)間

正確設(shè)置防火墻

禁止對(duì)主機(jī)的非開(kāi)放服務(wù)的訪問(wèn)

限制特定IP地址的訪問(wèn)

啟用防火墻的防DDoS的屬性

Cookie和SessionSession 是「基于Cookie 實(shí)現(xiàn)」的另一種記錄服務(wù)端和客戶端會(huì)話狀態(tài)的機(jī)制。

Session 是存儲(chǔ)在服務(wù)端，而 SessionId 會(huì)被存儲(chǔ)在客戶端的 Cookie 中。

Session 的「認(rèn)證過(guò)程」：

客戶端第一次發(fā)送請(qǐng)求到服務(wù)端，服務(wù)端根據(jù)信息創(chuàng)建對(duì)應(yīng)的 Session，并在響應(yīng)頭返回 SessionID

客戶端接收到服務(wù)端返回的 SessionID 后，會(huì)將此信息存儲(chǔ)在 Cookie 上，同時(shí)會(huì)記錄這個(gè) SessionID 屬于哪個(gè)域名

當(dāng)客戶端再次訪問(wèn)服務(wù)端時(shí)，請(qǐng)求會(huì)自動(dòng)判斷該域名下是否存在 Cookie 信息，如果有則發(fā)送給服務(wù)端，服務(wù)端會(huì)從 Cookie 中拿到 SessionID，再根據(jù) SessionID 找到對(duì)應(yīng)的 Session，如果有對(duì)應(yīng)的 Session 則通過(guò)，繼續(xù)執(zhí)行請(qǐng)求，否則就中斷

「Cookie和Session的區(qū)別」

安全性，因?yàn)?Cookie 可以通過(guò)客戶端修改，而 Session 只能在服務(wù)端設(shè)置，所以安全性比 Cookie 高，一般會(huì)用于驗(yàn)證用戶登錄狀態(tài)

適用性，Cookie 只能存儲(chǔ)字符串?dāng)?shù)據(jù)，而 Session 可以存儲(chǔ)任意類型數(shù)據(jù)

有效期，Cookie 可以設(shè)置任意時(shí)間有效，而 Session 一般失效時(shí)間短

常見(jiàn)面試題「在瀏覽器地址欄鍵入U(xiǎn)RL」

1.DNS解析：瀏覽器會(huì)依據(jù)URL逐層查詢DNS服務(wù)器緩存，解析URL中的域名對(duì)應(yīng)的IP地址，DNS緩存從近到遠(yuǎn)依次是瀏覽器緩存、系統(tǒng)緩存、路由器緩存、IPS服務(wù)器緩存、域名服務(wù)器緩存、頂級(jí)域名服務(wù)器緩存。

從哪個(gè)緩存找到對(duì)應(yīng)的IP直接返回，不再查詢后面的緩存。

2.TCP連接：結(jié)合三次握手

3.發(fā)送HTTP請(qǐng)求：瀏覽器發(fā)出讀取文件的HTTP請(qǐng)求，該請(qǐng)求發(fā)送給服務(wù)器

4.服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文：服務(wù)器對(duì)瀏覽器請(qǐng)求做出響應(yīng)，把對(duì)應(yīng)的帶有HTML文本的HTTP響應(yīng)報(bào)文發(fā)送給瀏覽器

5.瀏覽器解析渲染頁(yè)面

6.連接結(jié)束：瀏覽器釋放TCP連接，該步驟即四次揮手。

第5步和第6步可以認(rèn)為是同時(shí)發(fā)生的，哪一步在前沒(méi)有特別的要求

責(zé)任編輯：haq