HTTP相關(guān)知識(shí)

http全稱(chēng)，超文本傳輸協(xié)議，屬于應(yīng)用層協(xié)議 ，屬于無(wú)狀態(tài)協(xié)議，面向?qū)ο蟮膮f(xié)議;

HTTP工作原理：

HTTP是基于客戶/服務(wù)器模式，且面向連接的。典型的HTTP事務(wù)處理有如下的過(guò)程：^ [7]^

（1）客戶與服務(wù)器建立連接；

（2）客戶向服務(wù)器提出請(qǐng)求；

（3）服務(wù)器接受請(qǐng)求，并根據(jù)請(qǐng)求返回相應(yīng)的文件作為應(yīng)答；

（4）客戶與服務(wù)器關(guān)閉連接。

發(fā)展階段，

HTTP1.0和HTTP2.0的區(qū)別

總的區(qū)別就是：

1. HTTP/2采用二進(jìn)制格式而非文本格式

2. HTTP/2是完全多路復(fù)用的，而非有序并阻塞的——只需一個(gè)連接即可實(shí)現(xiàn)并行

3. 使用報(bào)頭壓縮，HTTP/2降低了開(kāi)銷(xiāo)

4. HTTP/2讓服務(wù)器可以將響應(yīng)主動(dòng)“推送”到客戶端緩存中

1.多路復(fù)用和二進(jìn)制幀

HTTP/1.x 有個(gè)問(wèn)題叫線端阻塞(head-of-line blocking), 它是指一個(gè)連接(connection)一次只提交一個(gè)請(qǐng)求的效率比較高, 多了就會(huì)變慢。 HTTP/1.1 試過(guò)用流水線(pipelining)來(lái)解決這個(gè)問(wèn)題, 但是效果并不理想(數(shù)據(jù)量較大或者速度較慢的響應(yīng), 會(huì)阻礙排在他后面的請(qǐng)求). 此外, 由于網(wǎng)絡(luò)媒介(intermediary )和服務(wù)器不能很好的支持流水線, 導(dǎo)致部署起來(lái)困難重重。而多路傳輸(Multiplexing)能很好的解決這些問(wèn)題, 因?yàn)樗芡瑫r(shí)處理多個(gè)消息的請(qǐng)求和響應(yīng); 甚至可以在傳輸過(guò)程中將一個(gè)消息跟另外一個(gè)摻雜在一起。所以客戶端只需要一個(gè)連接就能加載一個(gè)頁(yè)面。

多路復(fù)用允許單一的 HTTP/2 連接同時(shí)發(fā)起多重的請(qǐng)求-響應(yīng)消息。如下圖：

從這張圖可以看出，請(qǐng)求index.html頁(yè)面的時(shí)候，瀏覽器會(huì)去請(qǐng)求style.css和scripts.js的文件。左邊的圖是順序加載兩個(gè)個(gè)文件的，右邊則是并行加載兩個(gè)文件。

我們知道，TCP連接相當(dāng)于兩根管道（雙工，一個(gè)用于服務(wù)器到客戶端，一個(gè)用于客戶端到服務(wù)器），管道里面數(shù)據(jù)傳輸是通過(guò)字節(jié)碼傳輸，傳輸是有序的，每個(gè)字節(jié)都是一個(gè)一個(gè)來(lái)傳輸。

例如客戶端要向服務(wù)器發(fā)送Hello、World兩個(gè)單詞，只能是先發(fā)送Hello再發(fā)送World，沒(méi)辦法同時(shí)發(fā)送這兩個(gè)單詞。不然服務(wù)器收到的可能就是HWeolrllod（注意是穿插著發(fā)過(guò)去了，但是順序還是不會(huì)亂）。這樣服務(wù)器就懵b了。

接上面的問(wèn)題，能否同時(shí)發(fā)送Hello和World兩個(gè)單詞能，當(dāng)然也是可以的，可以將數(shù)據(jù)拆成包，給每個(gè)包打上標(biāo)簽。發(fā)的時(shí)候是這樣的①H ②W ①e ②o ①l ②r ①l ②l ①o ②d。這樣到了服務(wù)器，服務(wù)器根據(jù)標(biāo)簽把兩個(gè)單詞區(qū)分開(kāi)來(lái)。實(shí)際的發(fā)送效果如下圖：

二進(jìn)制分幀可以實(shí)現(xiàn)上面的效果，二進(jìn)制分幀層在 應(yīng)用層(HTTP/2)和傳輸層(TCP or UDP)之間。HTTP/2并沒(méi)有去修改TCP協(xié)議而是盡可能的利用TCP的特性。

在二進(jìn)制分幀層中， HTTP/2 會(huì)將所有傳輸?shù)男畔⒎指顬閹╢rame）,并對(duì)它們采用二進(jìn)制格式的編碼 ，其中 首部信息會(huì)被封裝到 HEADER frame，而相應(yīng)的 Request Body 則封裝到 DATA frame 里面。

HTTP 性能優(yōu)化的關(guān)鍵并不在于高帶寬，而是低延遲。TCP 連接會(huì)隨著時(shí)間進(jìn)行自我「調(diào)諧」，起初會(huì)限制連接的最大速度，如果數(shù)據(jù)成功傳輸，會(huì)隨著時(shí)間的推移提高傳輸?shù)乃俣?。這種調(diào)諧則被稱(chēng)為 TCP 慢啟動(dòng)。由于這種原因，讓原本就具有突發(fā)性和短時(shí)性的 HTTP 連接變的十分低效。

HTTP/2 通過(guò)讓所有數(shù)據(jù)流共用同一個(gè)連接，可以更有效地使用 TCP 連接，讓高帶寬也能真正的服務(wù)于 HTTP 的性能提升。

2.首部壓縮

在 HTTP/1 中，HTTP 請(qǐng)求和響應(yīng)都是由「狀態(tài)行、請(qǐng)求 / 響應(yīng)頭部、消息主體」三部分組成。一般而言，消息主體都會(huì)經(jīng)過(guò) gzip 壓縮，或者本身傳輸?shù)木褪菈嚎s過(guò)后的二進(jìn)制文件（例如圖片、音頻），但狀態(tài)行和頭部卻沒(méi)有經(jīng)過(guò)任何壓縮，直接以純文本傳輸。

隨著 Web 功能越來(lái)越復(fù)雜，每個(gè)頁(yè)面產(chǎn)生的請(qǐng)求數(shù)也越來(lái)越多，導(dǎo)致消耗在頭部的流量越來(lái)越多，尤其是每次都要傳輸 UserAgent、Cookie 這類(lèi)不會(huì)頻繁變動(dòng)的內(nèi)容，完全是一種浪費(fèi)。

我們?cè)儆猛ㄋ椎恼Z(yǔ)言解釋下，壓縮的原理。頭部壓縮需要在支持 HTTP/2 的瀏覽器和服務(wù)端之間：

• 維護(hù)一份相同的靜態(tài)字典（Static Table），包含常見(jiàn)的頭部名稱(chēng)，以及特別常見(jiàn)的頭部名稱(chēng)與值的組合；

• 維護(hù)一份相同的動(dòng)態(tài)字典（Dynamic Table），可以動(dòng)態(tài)的添加內(nèi)容；

• 支持基于靜態(tài)哈夫曼碼表的哈夫曼編碼（Huffman Coding）；

靜態(tài)字典的作用有兩個(gè)：

1）對(duì)于完全匹配的頭部鍵值對(duì)，例如 “:method :GET”，可以直接使用一個(gè)字符表示；

2）對(duì)于頭部名稱(chēng)可以匹配的鍵值對(duì)，例如 “cookie :xxxxxxx”，可以將名稱(chēng)使用一個(gè)字符表示。

HTTP/2 中的靜態(tài)字典如下（以下只截取了部分，完整表格在這里）：

同時(shí)，瀏覽器和服務(wù)端都可以向動(dòng)態(tài)字典中添加鍵值對(duì)，之后這個(gè)鍵值對(duì)就可以使用一個(gè)字符表示了。需要注意的是，動(dòng)態(tài)字典上下文有關(guān)，需要為每個(gè) HTTP/2 連接維護(hù)不同的字典。在傳輸過(guò)程中使用，使用字符代替鍵值對(duì)大大減少傳輸?shù)臄?shù)據(jù)量。

3.HTTP2支持服務(wù)器推送

服務(wù)端推送是一種在客戶端請(qǐng)求之前發(fā)送數(shù)據(jù)的機(jī)制。當(dāng)代網(wǎng)頁(yè)使用了許多資源:HTML、樣式表、腳本、圖片等等。在HTTP/1.x中這些資源每一個(gè)都必須明確地請(qǐng)求。這可能是一個(gè)很慢的過(guò)程。瀏覽器從獲取HTML開(kāi)始，然后在它解析和評(píng)估頁(yè)面的時(shí)候，增量地獲取更多的資源。因?yàn)榉?wù)器必須等待瀏覽器做每一個(gè)請(qǐng)求，網(wǎng)絡(luò)經(jīng)常是空閑的和未充分使用的。

為了改善延遲，HTTP/2引入了server push，它允許服務(wù)端推送資源給瀏覽器，在瀏覽器明確地請(qǐng)求之前。一個(gè)服務(wù)器經(jīng)常知道一個(gè)頁(yè)面需要很多附加資源，在它響應(yīng)瀏覽器第一個(gè)請(qǐng)求的時(shí)候，可以開(kāi)始推送這些資源。這允許服務(wù)端去完全充分地利用一個(gè)可能空閑的網(wǎng)絡(luò)，改善頁(yè)面加載時(shí)間

其實(shí)說(shuō)白了，就是HTTP2.0中，瀏覽器在請(qǐng)求HTML頁(yè)面的時(shí)候，服務(wù)端會(huì)推送css、js等其他資源給瀏覽器，減少網(wǎng)絡(luò)空閑浪費(fèi)。

二、HTTP和HTTPS的區(qū)別

HTTPS：是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。

SSL：是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。TLS與SSL在傳輸層對(duì)網(wǎng)絡(luò)連接進(jìn)行加密。HTTPS就是在HTTP的基礎(chǔ)上加入了SSL協(xié)議，SSL依靠證書(shū)來(lái)驗(yàn)證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的通信加密。

HTTPS協(xié)議的主要作用可以分為兩種：一種是建立一個(gè)信息安全通道，來(lái)保證數(shù)據(jù)傳輸?shù)陌踩?；另一種就是確認(rèn)網(wǎng)站的真實(shí)性。

兩者主要區(qū)別如下：

???1、https協(xié)議需要到ca申請(qǐng)證書(shū)，一般免費(fèi)證書(shū)較少，因而需要一定費(fèi)用。


　　2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。

　　3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

　　4、http的連接很簡(jiǎn)單，是無(wú)狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

HTTPS的工作原理：

客戶端在使用HTTPS方式與Web服務(wù)器通信時(shí)有以下幾個(gè)步驟，如圖所示。

　?。?）客戶使用https的URL訪問(wèn)Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。

　?。?）Web服務(wù)器收到客戶端請(qǐng)求后，會(huì)將網(wǎng)站的證書(shū)信息（證書(shū)中包含公鑰）傳送一份給客戶端。

　?。?）客戶端的瀏覽器與Web服務(wù)器開(kāi)始協(xié)商SSL連接的安全等級(jí)，也就是信息加密的等級(jí)。

　?。?）客戶端的瀏覽器根據(jù)雙方同意的安全等級(jí)，建立會(huì)話密鑰，然后利用網(wǎng)站的公鑰將會(huì)話密鑰加密，并傳送給網(wǎng)站。

　?。?）Web服務(wù)器利用自己的私鑰解密出會(huì)話密鑰。

　?。?）Web服務(wù)器利用會(huì)話密鑰加密與客戶端之間的通信。

https://www.cnblogs.com/frankyou/p/6145485.html

https://www.cnblogs.com/wqhwe/p/5407468.html

DNS基本概念

根域

就是所謂的 “.”，其實(shí)我們的網(wǎng)址 www.baidu.com 在配置當(dāng)中應(yīng)該是 www.baidu.com.（最后有一點(diǎn)），一般我們?cè)跒g覽器里輸入時(shí)會(huì)省略后面的點(diǎn)，而這也已經(jīng)成為了習(xí)慣。根域服務(wù)器我們知道有 13 臺(tái)，但是這是錯(cuò)誤的觀點(diǎn)。

根域服務(wù)器只是具有 13 個(gè) IP 地址，但機(jī)器數(shù)量卻不是 13 臺(tái)，因?yàn)檫@些 IP 地址借助了任播的技術(shù)，所以我們可以在全球設(shè)立這些 IP 的鏡像站點(diǎn)，你訪問(wèn)到的這個(gè) IP 并不是唯一的那臺(tái)主機(jī)。

域的劃分

根域下來(lái)就是頂級(jí)域或者叫一級(jí)域，有兩種劃分方式，一種互聯(lián)網(wǎng)剛興起時(shí)的按照行業(yè)性質(zhì)劃分的 com.，net. 等，一種是按國(guó)家劃分的如 cn.，jp.，等。具體多少你可以自己去查，我們這里不關(guān)心。

每個(gè)域都會(huì)有域名服務(wù)器，也叫權(quán)威域名服務(wù)器。Baidu.com 就是一個(gè)頂級(jí)域名，而 www.baidu.com 卻不是頂級(jí)域名，他是在 baidu.com 這個(gè)域里的一叫做 www 的主機(jī)。

一級(jí)域之后還有二級(jí)域，三級(jí)域，只要我買(mǎi)了一個(gè)頂級(jí)域，并且我搭建了自己 BIND 服務(wù)器（或者其他軟件搭建的）注冊(cè)到互聯(lián)網(wǎng)中，那么我就可以隨意在前面多加幾個(gè)域了（當(dāng)然長(zhǎng)度是有限制的）。

比如 a.www.baidu.com，在這個(gè)網(wǎng)址中，www.baidu.com 變成了一個(gè)二級(jí)域而不是一臺(tái)主機(jī)，主機(jī)名是 a。

域名服務(wù)器

能提供域名解析的服務(wù)器，上面的記錄類(lèi)型可以是 A(address)記錄，NS 記錄（name server），MX（mail），CNAME 等。

A 記錄是什么意思呢，就是記錄一個(gè) IP 地址和一個(gè)主機(jī)名字，比如我這個(gè)域名服務(wù)器所在的域 test.baidu.com，我們知道這是一個(gè)二級(jí)的域名，然后我在里面有一條 A 記錄,記錄了主機(jī)為 a 的 IP，查到了就返回給你了。

如果我現(xiàn)在要想 baidu.com 這個(gè)域名服務(wù)器查詢(xún) a.test.baidu.com，那么這個(gè)頂級(jí)域名服務(wù)器就會(huì)發(fā)現(xiàn)你請(qǐng)求的這個(gè)網(wǎng)址在 test.baidu.com 這個(gè)域中，我這里記錄了這個(gè)二級(jí)域的域名服務(wù)器 test.baidu.com 的 NS 的 IP。我返回給你這個(gè)地址你再去查主機(jī)為 a 的主機(jī)把。

這些域內(nèi)的域名服務(wù)器都稱(chēng)為權(quán)威服務(wù)器，直接提供 DNS 查詢(xún)服務(wù)。（這些服務(wù)器可不會(huì)做遞歸哦）

DNS解析過(guò)程

那么我們的 DNS 是怎么解析一個(gè)域名的呢？

1. 現(xiàn)在我有一臺(tái)計(jì)算機(jī)，通過(guò) ISP 接入了互聯(lián)網(wǎng)，那么 ISP 就會(huì)給我分配一個(gè) DNS 服務(wù)器，這個(gè) DNS 服務(wù)器不是權(quán)威服務(wù)器，而是相當(dāng)于一個(gè)代理的 dns 解析服務(wù)器，他會(huì)幫你迭代權(quán)威服務(wù)器返回的應(yīng)答，然后把最終查到 IP 返回給你。

2. 現(xiàn)在的我計(jì)算機(jī)要向這臺(tái) ISPDNS 發(fā)起請(qǐng)求查詢(xún) www.baidu.com 這個(gè)域名了，(這里其實(shí)準(zhǔn)確來(lái)說(shuō)不是 ISPDNS，而應(yīng)該是用戶自己電腦網(wǎng)絡(luò)設(shè)置里的 DNS，并不一定是 ISPDNS。比如也有可能你手工設(shè)置了 8.8.8.8)。

3. ISPDNS 拿到請(qǐng)求后，先檢查一下自己的緩存中有沒(méi)有這個(gè)地址，有的話就直接返回。這個(gè)時(shí)候拿到的 ip 地址，會(huì)被標(biāo)記為非權(quán)威服務(wù)器的應(yīng)答。

4. 如果緩存中沒(méi)有的話，ISPDNS 會(huì)從配置文件里面讀取 13 個(gè)根域名服務(wù)器的地址（這些地址是不變的，直接在 BIND 的配置文件中）。

5. 然后像其中一臺(tái)發(fā)起請(qǐng)求。

6. 根服務(wù)器拿到這個(gè)請(qǐng)求后，知道他是 com. 這個(gè)頂級(jí)域名下的，所以就會(huì)返回 com 域中的 NS 記錄，一般來(lái)說(shuō)是 13 臺(tái)主機(jī)名和 IP。

7. 然后 ISPDNS 向其中一臺(tái)再次發(fā)起請(qǐng)求，com 域的服務(wù)器發(fā)現(xiàn)你這請(qǐng)求是 baidu.com 這個(gè)域的，我一查發(fā)現(xiàn)了這個(gè)域的 NS，那我就返回給你，你再去查。（目前百度有 4 臺(tái) baidu.com 的頂級(jí)域名服務(wù)器）。

8. ISPDNS 不厭其煩的再次向 baidu.com 這個(gè)域的權(quán)威服務(wù)器發(fā)起請(qǐng)求，baidu.com 收到之后，查了下有 www 的這臺(tái)主機(jī)，就把這個(gè) IP 返回給你了，

9. 然后 ISPDNS 拿到了之后，將其返回給了客戶端，并且把這個(gè)保存在高速緩存中。

下面我們來(lái)用 nslookup 這個(gè)工具詳細(xì)來(lái)說(shuō)一下解析步驟：

從上圖我們可以看到:

1. 第一行 Server 是：DNS 服務(wù)器的主機(jī)名 – 192.168.110.10

2. 第二行A ddress 是： 它的 IP 地址 – 192.168.110.10#53

3. 下面的 Name 是：解析的 URL – www.jsjzx.com

4. Address 是：解析出來(lái)的 IP – 192.168.110

但是也有像百度這樣的 DNS 比較復(fù)雜的解析:

你會(huì)發(fā)現(xiàn)百度有一個(gè) cname = www.a.shifen.com 的別名。這是怎么一個(gè)過(guò)程呢？我們用 dig 工具來(lái)跟蹤一下，Dig 工具會(huì)在本地計(jì)算機(jī)做迭代，然后記錄查詢(xún)的過(guò)程。

第一步是向我這臺(tái)機(jī)器的 ISPDNS 獲取到根域服務(wù)區(qū)的 13 個(gè) IP 和主機(jī)名 [b-j].root-servers.net.。

第二步是向其中的一臺(tái)根域服務(wù)器（Servername 就是末行小括號(hào)里面的）發(fā)送 www.baidu.com 的查詢(xún)請(qǐng)求，他返回了 com. 頂級(jí)域的服務(wù)器 IP（未顯示）和名稱(chēng)，

第三步，便向 com. 域的一臺(tái)服務(wù)器 192.33.4.12 請(qǐng)求 www.baidu.com，他返回了 baidu.com 域的服務(wù)器 IP（未顯示）和名稱(chēng)，百度有四臺(tái)頂級(jí)域的服務(wù)器

第四步呢，向百度的頂級(jí)域服務(wù)器（202.108.22.220）請(qǐng)求 www.baidu.com，他發(fā)現(xiàn)這個(gè) www 有個(gè)別名，而不是一臺(tái)主機(jī)，別名是 www.a.shifen.com。

按照一般的邏輯，當(dāng) dns 請(qǐng)求到別名的時(shí)候，查詢(xún)會(huì)終止，而是重新發(fā)起查詢(xún)別名的請(qǐng)求，所以此處應(yīng)該返回的是 www.a.shifen.com 而已。但是為什么返回 a.shifen.com 的這個(gè)域的 NS 呢？

我們可以嘗試下面的這個(gè)命令：dig +trace shifen.com 看看有什么結(jié)果：

你會(huì)發(fā)現(xiàn)第三步時(shí) shifen.com 這個(gè)頂級(jí)域的域名服務(wù)器和 baidu.com 這個(gè)域的域名服務(wù)器是同一臺(tái)主機(jī)（即：dns.baidu.com）！當(dāng)我拿到 www.baidu.com 的別名 www.a.shifen.com 的時(shí)候，我本來(lái)需要重新到 com 域查找 shifen.com 域的 NS，但是因?yàn)檫@兩個(gè)域在同一臺(tái) NS 上，所以直接向本機(jī)發(fā)起了，

shifen.com 域發(fā)現(xiàn)請(qǐng)求的 www.a.shifen.com 是屬于 a.shifen.com 這個(gè)域的，于是就把 a.shifen.com 的這個(gè) NS 和 IP 返回，讓我到 a.shifen.com 這個(gè)域的域名服務(wù)器上查詢(xún) www.a.shifen.com。

于是我便從 ns X .a.shifen.com 中一臺(tái)拿到了一條 A 記錄，最終的最終也便是 www.baidu.com 的 IP 地址了?！敬颂幰部梢杂?dig +trace www.a.shifen.com】跟蹤一下，用一個(gè)圖來(lái)說(shuō)明一下(圖中第三步的全世界只有 13 臺(tái)是錯(cuò)誤的)

以下內(nèi)容為在虛擬機(jī)中搭建 local dns 服務(wù)器得到的實(shí)驗(yàn)數(shù)據(jù)，糾正上述結(jié)論。在上面的分析中，我們用 dig 工具進(jìn)行了追蹤，但是 dig 沒(méi)有繼續(xù)追蹤當(dāng)我們從 baidu.com 拿到 cname 和 ns2.a.shifen.com 的 IP 之后的事情。

我們就所以然的下結(jié)論認(rèn)為 local dns 會(huì)向 ns2.a.shifen.com 請(qǐng)求 www.a.shifen.com。其實(shí)這個(gè)想法是錯(cuò)誤，在自己的本地搭建一個(gè) local dns，抓取整個(gè)解析過(guò)程中是所有包，看看就明白拉。

實(shí)際的結(jié)果是雖然 dns.baidu.com 返回了 a.shifen.com 域的服務(wù)器地址和 IP，但是 local dns 并不是直接向上述返回的 IP 請(qǐng)求 www.a.shifen.com，而是再一次去請(qǐng)求 com 域，得到 shifen.com 域的服務(wù)器（也就是 baidu.com 的那四臺(tái)），然后又請(qǐng)求 www.a.shifen.com，返回 a.shifen.com 的域的服務(wù)器，最后才是去請(qǐng)求 www.a.shifen.com，

雖然上面已經(jīng)返回了 IP，但是實(shí)驗(yàn)的結(jié)果就是再走一遍 shifen.com 域的查詢(xún)。

上圖就是 localdns 在解析 www.baidu.com 的抓包全過(guò)程。藍(lán)色那條就是在收到 cname 和響應(yīng)的 a.shifen.com 的域名服務(wù)器 IP 地址之后，繼續(xù)向 com 域請(qǐng)求 shifen.com。

這個(gè)圖充分說(shuō)明了返回 cname 的同時(shí)也返回了 ns2.a.shifen.com 的 IP。

相關(guān)術(shù)語(yǔ)

類(lèi)型編碼內(nèi)容A1將 DNS 域名映射到 IPv4 地址，基本作用是說(shuō)明一個(gè)域名對(duì)應(yīng)了哪些 IPv4 地址NS2權(quán)威名稱(chēng)服務(wù)器記錄，用于說(shuō)明這個(gè)區(qū)域有哪些 DNS 服務(wù)器負(fù)責(zé)解析CNAME5別名記錄，主機(jī)別名對(duì)應(yīng)的規(guī)范名稱(chēng)SOA6起始授權(quán)機(jī)構(gòu)記錄，NS 記錄說(shuō)明了有多臺(tái)服務(wù)器在進(jìn)行解析，但哪一個(gè)才是主服務(wù)器，NS 并沒(méi)有說(shuō)明，SOA 記錄了說(shuō)明在眾多 NS 記錄里哪一臺(tái)才是主要的服務(wù)器PTR12IP 地址反向解析，是 A 記錄的逆向記錄，作用是把 IP 地址解析為域名MX15郵件交換記錄，指定負(fù)責(zé)接收和發(fā)送到域中的電子郵件的主機(jī)TXT16文本資源記錄，用來(lái)為某個(gè)主機(jī)名或域名設(shè)置的說(shuō)明AAAA28將 DNS 域名映射到 IPv6 地址，基本作用是說(shuō)明一個(gè)域名對(duì)應(yīng)了哪些 IPv6 地址

總結(jié)

因此總結(jié)一下便是：

1. 本機(jī)向 local dns 請(qǐng)求 www.baidu.com

2. local dns 向根域請(qǐng)求 www.baidu.com，根域返回 com. 域的服務(wù)器 IP

3. 向 com. 域請(qǐng)求 www.baidu.com，com. 域返回 baidu.com 域的服務(wù)器 IP

4. 向 baidu.com 請(qǐng)求 www.baidu.com，返回 cname www.a.shifen.com 和 a.shifen.com 域的服務(wù)器 IP

5. 向 root 域請(qǐng)求 www.a.shifen.com

6. 向 com. 域請(qǐng)求 www.a.shifenc.om

7. 向 shifen.com 請(qǐng)求

8. 向 a.shifen.com 域請(qǐng)求

9. 拿到 www.a.shifen.com 的 IP

10. local dns 返回本機(jī) www.baidu.com cname www.a.shifen.com 以及 www.a.shifen.com 的 IP、

TCP相關(guān)知識(shí)

tcp簡(jiǎn)介 ：面向字節(jié)流 可靠的 面相連接的協(xié)議

面向連接：意味著交換數(shù)據(jù)之前，需要建立完整的TCP連接，

基于字節(jié)流：交換的數(shù)據(jù)格式是字節(jié)（byte）構(gòu)成有序，但是無(wú)結(jié)構(gòu)的 字節(jié)流，連接正常建立完成，客戶端發(fā)送無(wú)特殊格式的字節(jié)流，存在緩沖結(jié)構(gòu)用于接收數(shù)據(jù)。

TCP報(bào)文結(jié)構(gòu)：

1. 端口號(hào)：

2. 序號(hào)

3. 確認(rèn)序號(hào)

4. 首部長(zhǎng)度

5. 保留字段

6. 控制位

7. 窗口大小

8. 校驗(yàn)和

9. 緊急指針

10. 選項(xiàng)

11. 有效數(shù)據(jù)部分

可靠性：確?？煽啃砸揽咳缦率侄?/p>

1. 合理的數(shù)據(jù)大小：

2. 校驗(yàn)和

3. 序號(hào)和確認(rèn)序號(hào)

4. 超時(shí)重傳

5. 連接管理：三次握手，四次揮手

6. 流量控制

7. 擁塞控制

TCP 和 UDP 的區(qū)別

具體區(qū)別：

UDPTCP是否連接無(wú)連接面向連接是否可靠不可靠，沒(méi)有確認(rèn)機(jī)制、流量控制和擁塞控制可靠，有確認(rèn)機(jī)制、流量控制和擁塞控制連接對(duì)象個(gè)數(shù)支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多交互通信只支持一對(duì)一通信傳輸方式面向報(bào)文面向字節(jié)流首部開(kāi)銷(xiāo)首部開(kāi)銷(xiāo)小，固定8字節(jié)首部開(kāi)銷(xiāo)較大，最小20字節(jié)，最大60字節(jié)適用場(chǎng)景適用于實(shí)時(shí)應(yīng)用(IP電話、視頻會(huì)議、直播等)適用于要求可靠傳輸?shù)膽?yīng)用，如文件傳輸?shù)?/p>

TCP的連接控制：

建立連接

三次握手：

1. 第一次握手：客戶端發(fā)送SYN=1 標(biāo)識(shí)建立連接，并初始化seq，發(fā)送完成客戶端進(jìn)入 SYN-SENT狀態(tài)，等待服務(wù)端確認(rèn)

2. 第二次握手：序號(hào) seq 設(shè)置為服務(wù)器初始序號(hào)y。發(fā)送完報(bào)文段2后，服務(wù)器進(jìn)入 SYN-RECEIVED 狀態(tài)

3. 第三次握手：客戶端在收到報(bào)文段2后，向服務(wù)器發(fā)送報(bào)文段3，其 ACK 標(biāo)志位為1，代表對(duì)服務(wù)器做出應(yīng)答，確認(rèn)序號(hào)字段 ack 為 y + 1，序號(hào)字段 seq 為 x + 1。此報(bào)文段發(fā)送完畢后，雙方都進(jìn)入 ESTABLISHED 狀態(tài)，表示連接已建立。

常見(jiàn)面試題 1： TCP 建立連接為什么要三次握手而不是兩次？

A1：

1. TCP 實(shí)現(xiàn)了可靠的數(shù)據(jù)傳輸，原因之一就是 TCP 報(bào)文段中維護(hù)了序號(hào)字段和確認(rèn)序號(hào)字段，如果是兩次握手，只有發(fā)起方的初始序號(hào)可以得到確認(rèn)，而另一方的初始序號(hào)則得不到確認(rèn)。

2. 三次握手才能讓雙方均確認(rèn)自己和對(duì)方的發(fā)送和接收能力都正常

3. 防止已過(guò)期的連接請(qǐng)求報(bào)文突然又傳送到服務(wù)器，因而產(chǎn)生錯(cuò)誤

常見(jiàn)面試題2： TCP 建立連接為什么要三次握手而不是四次？

A2：相比上個(gè)問(wèn)題而言，這個(gè)問(wèn)題就簡(jiǎn)單多了。因?yàn)槿挝帐忠呀?jīng)可以確認(rèn)雙方的發(fā)送接收能力正常，雙方都知道彼此已經(jīng)準(zhǔn)備好，而且也可以完成對(duì)雙方初始序號(hào)值得確認(rèn)，也就無(wú)需再第四次握手了。

常見(jiàn)面試題3： 有一種網(wǎng)絡(luò)攻擊是利用了 TCP 建立連接機(jī)制的漏洞，你了解嗎？這個(gè)問(wèn)題怎么解決？

A3：在三次握手過(guò)程中，服務(wù)器在收到了客戶端的 SYN 報(bào)文段后，會(huì)分配并初始化連接變量和緩存，并向客戶端發(fā)送 SYN + ACK 報(bào)文段，攻擊者發(fā)送大量的 SYN 報(bào)文段到服務(wù)器請(qǐng)求建立連接，但是卻不進(jìn)行第三次握手，這會(huì)導(dǎo)致服務(wù)器打開(kāi)大量的半開(kāi)連接，消耗大量的資源，最終無(wú)法進(jìn)行正常的服務(wù)。

四次揮手：

1. 客戶端發(fā)送關(guān)閉連接的報(bào)文段，F(xiàn)IN 標(biāo)志位1，請(qǐng)求關(guān)閉連接，并停止發(fā)送數(shù)據(jù)。序號(hào)字段 seq = x (等于之前發(fā)送的所有數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加一)，然后客戶端會(huì)進(jìn)入 FIN-WAIT-1 狀態(tài)，等待來(lái)自服務(wù)器的確認(rèn)報(bào)文。

2. 服務(wù)器收到 FIN 報(bào)文后，發(fā)回確認(rèn)報(bào)文，ACK = 1， ack = x + 1，并帶上自己的序號(hào) seq = y，然后服務(wù)器就進(jìn)入 CLOSE-WAIT 狀態(tài)。服務(wù)器還會(huì)通知上層的應(yīng)用程序?qū)Ψ揭呀?jīng)釋放連接，此時(shí) TCP 處于半關(guān)閉狀態(tài)，也就是說(shuō)客戶端已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，但是服務(wù)器還可以發(fā)送數(shù)據(jù)，客戶端也還能夠接收。

3. 客戶端收到服務(wù)器的 ACK 報(bào)文段后隨即進(jìn)入 FIN-WAIT-2 狀態(tài)，此時(shí)還能收到來(lái)自服務(wù)器的數(shù)據(jù)，直到收到 FIN 報(bào)文段。

4. 服務(wù)器發(fā)送完所有數(shù)據(jù)后，會(huì)向客戶端發(fā)送 FIN 報(bào)文段，各字段值如圖所示，隨后服務(wù)器進(jìn)入 LAST-ACK 狀態(tài)，等待來(lái)自客戶端的確認(rèn)報(bào)文段。

5. 客戶端收到來(lái)自服務(wù)器的 FIN 報(bào)文段后，向服務(wù)器發(fā)送 ACK 報(bào)文，隨后進(jìn)入 TIME-WAIT 狀態(tài)，等待 2MSL(2 * Maximum Segment Lifetime，兩倍的報(bào)文段最大存活時(shí)間) ，這是任何報(bào)文段在被丟棄前能在網(wǎng)絡(luò)中存在的最長(zhǎng)時(shí)間，常用值有30秒、1分鐘和2分鐘。如無(wú)特殊情況，客戶端會(huì)進(jìn)入 CLOSED 狀態(tài)。

6. 服務(wù)器在接收到客戶端的 ACK 報(bào)文后會(huì)隨即進(jìn)入 CLOSED 狀態(tài)，由于沒(méi)有等待時(shí)間，一般而言，服務(wù)器比客戶端更早進(jìn)入 CLOSED 狀態(tài)。

常見(jiàn)面試題1： 為什么 TCP 關(guān)閉連接為什么要四次而不是三次？

A1：在數(shù)據(jù)發(fā)送完后，服務(wù)器會(huì)向客戶單發(fā)送 FIN 報(bào)文，表示數(shù)據(jù)已經(jīng)發(fā)送完畢，請(qǐng)求關(guān)閉連接，然后客戶端再做出應(yīng)答，因此一共需要四次揮手。

常見(jiàn)面試題2： 客戶端為什么需要在 TIME-WAIT 狀態(tài)等待 2MSL 時(shí)間才能進(jìn)入 CLOSED 狀態(tài)？

A2：客戶端為了確保服務(wù)器收到了 ACK，會(huì)設(shè)置一個(gè)定時(shí)器，并在 TIME-WAIT 狀態(tài)等待 2MSL 的時(shí)間，如果在此期間又收到了來(lái)自服務(wù)器的 FIN 報(bào)文段，那么客戶端會(huì)重新設(shè)置計(jì)時(shí)器并再次等待 2MSL 的時(shí)間，如果在這段時(shí)間內(nèi)沒(méi)有收到來(lái)自服務(wù)器的 FIN 報(bào)文，那就說(shuō)明服務(wù)器已經(jīng)成功收到了 ACK 報(bào)文，此時(shí)客戶端就可以進(jìn)入 CLOSED 狀態(tài)了。

TCP 的流量控制與滑動(dòng)窗口

什么是 流量控制 ？

TCP 連接雙方的主機(jī)都為該連接設(shè)置了發(fā)送緩存和接收緩存，這些緩存起到了蓄水池的作用

滑動(dòng)窗口

發(fā)送緩存中的字節(jié)分類(lèi)

1. 第一類(lèi)：已發(fā)送且已確認(rèn)，這些數(shù)據(jù)已經(jīng)發(fā)送成功并已經(jīng)被確認(rèn)的數(shù)據(jù)，比如圖中的前31個(gè)bytes，這些數(shù)據(jù)其實(shí)的位置是在窗口之外了，下一步將被移出發(fā)送緩存。窗口內(nèi)順序最低的字節(jié)被確認(rèn)之后，窗口左邊界會(huì)向右移動(dòng)，稱(chēng)為窗口合攏。

2. 第二類(lèi)：已發(fā)送但未收到確認(rèn)，這部分?jǐn)?shù)據(jù)已經(jīng)被發(fā)送出去，但是還沒(méi)有收到接收端的 ACK，認(rèn)為并沒(méi)有完成發(fā)送，這部分?jǐn)?shù)據(jù)屬于窗口內(nèi)的數(shù)據(jù)。

3. 第三類(lèi)：未發(fā)送但是接收方已經(jīng)準(zhǔn)備好接收，這部分是盡快發(fā)送的數(shù)據(jù)，這部分?jǐn)?shù)據(jù)已經(jīng)被加載到緩存中，也在發(fā)送窗口中，正在等待發(fā)送，其實(shí)這個(gè)窗口是完全有接收方告知的，接收方告知當(dāng)前可以接受這些數(shù)據(jù)，所以發(fā)送方需要盡快的發(fā)送。

4. 第四類(lèi)：未發(fā)送且接收方未準(zhǔn)備好接收，這些數(shù)據(jù)屬于未發(fā)送，同時(shí)接收端也不允許發(fā)送的，因?yàn)檫@些數(shù)據(jù)已經(jīng)超出了發(fā)送端所接收的范圍。