前言
今天想通過抓包實驗，鞏固一下所學習的網絡協議。同時，在知識點上會加上以前遇到的一些問題。這次實驗並不是對所有的網絡協議都進行分析，而是從下面這個問題出發(面試常被問)。從這一過程中複習學過的網絡協議。使用的工具是wireshark。
問題：在瀏覽器中輸入URL後，執行的過程。會用到哪些協議？
例如：查詢www.163.com的IP地址過程如下：
(1)域名解析(DNS)
①在瀏覽器中輸入www.163.com域名，首先查看本機的緩存有無該域名記錄，如果沒有，則向本地DNS服務器請求；
②本地DNS服務器收到請求後，查看是否有該域名的解析，若有，直接返回，完成解析；若沒有，則請求根域名服務器；
③根域名服務器收到請求後，根域名返回.com的服務器ip；
④本地域名服務器接到.com服務器地址後，向該域名服務器請求www.163.com，返回163.com域的服務器ip；
⑤本地域名服務器獲得163.com域的服務器ip後，發請求到該域名服務器，返回www.163.com域的服務器ip；
⑥本地域名服務器獲取該解析後，返回給主機，解析完成，同時自己也將IP地址緩存起來。
(2)發起TCP的3次握手(TCP)
(3)爲了將消息從你的PC上傳到服務器上，需要用到IP協議、ARP協議。
(4)建立TCP連接後發起HTTP請求。(HTTP)
(5)服務器響應HTTP請求
(6)瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等）
(7)斷開TCP連接
使用wireshark搜索某一目標地址可以使用以下方法：
DNS協議
DNS報文格式如下：
DNS詢問報文如下：
Queries內的格式：
(1)查詢名：長度不固定，且不使用填充字節，一般該字段表示的就是需要查詢的域名（如果是反向查詢，則爲IP，反向查詢即由IP地址反查域名）。
(2)查詢類型：
|
類型 |
助記符 |
說明 |
|
1 |
A |
由域名獲得IPv4地址 |
|
2 |
NS |
查詢域名服務器 |
|
5 |
CNAME |
查詢規範名稱 |
|
6 |
SOA |
開始授權 |
|
11 |
WKS |
熟知服務 |
|
12 |
PTR |
把IP地址轉換成域名 |
|
13 |
HINFO |
主機信息 |
|
15 |
MX |
郵件交換 |
|
28 |
AAAA |
由域名獲得IPv6地址 |
|
252 |
AXFR |
傳送整個區的請求 |
|
255 |
ANY |
對所有記錄的請求 |
(3)查詢類：通常爲1，表明是Internet數據(實驗數據就爲0x0001)。
資源記錄(RR)區域（包括回答區域，授權區域和附加區域）格式：
(1)域名（2字節或不定長）：它的格式和Queries區域的查詢名字字段是一樣的。有一點不同就是，當報文中域名重複出現的時候，該字段使用2個字節的偏移指針來表示。比如，在資源記錄中，域名通常是查詢問題部分的域名的重複，因此用2字節的指針來表示，具體格式是最前面的兩個高位是11，用於識別指針。其餘的14位從DNS報文的開始處計數（從0開始），指出該報文中的相應字節數。一個典型的例子，C00C(1100000000001100，12正好是頭部的長度，其正好指向Queries區域的查詢名字字段)。
(2)查詢類型：表明資源紀錄的類型。
(3)查詢類：對於Internet信息，總是IN。
(4)生存時間（TTL）：以秒爲單位，表示的是資源記錄的生命週期，一般用於當地址解析程序取出資源記錄後決定保存及使用緩存數據的時間，它同時也可以表明該資源記錄的穩定程度，極爲穩定的信息會被分配一個很大的值（比如86400，這是一天的秒數）。
(5)資源數據：該字段是一個可變長字段，表示按照查詢段的要求返回的相關資源記錄的數據。可以是Address（表明查詢報文想要的迴應是一個IP地址）或者CNAME（表明查詢報文想要的迴應是一個規範主機名）等。
實驗中的查詢問題區域：
DNS應答報文：
可以看到Answer RRs和Authority RRs都置爲1了。
Answers和Authoritative nameservers詳細信息如下：
Ps：DNS佔用53號端口，同時使用TCP和UDP協議。DNS在區域傳輸的時候使用TCP協議，其他時候使用UDP協議。
DNS區域傳輸的時候使用TCP協議：
原因：輔域名服務器會定時（一般3小時）向主域名服務器進行查詢以便了解數據是否有變動。如有變動，會執行一次區域傳送，進行數據同步。區域傳送使用TCP而不是UDP，因爲數據同步傳送的數據量比一個請求應答的數據量要多得多。
域名解析時使用UDP協議：
原因：客戶端向DNS服務器查詢域名，一般返回的內容都不超過512字節，用UDP傳輸即可。不用經過三次握手，這樣DNS服務器負載更低，響應更快。理論上說，客戶端也可以指定向DNS服務器查詢時用TCP，但事實上，很多DNS服務器進行配置的時候，僅支持UDP查詢包。
HTTP協議
Connection：Keep-Alive表示採用長連接
請求行由方法字段、URL字段和HTTP協議版本字段。其中，方法字段嚴格區分大小寫，當前HTTP協議中的方法都是大寫，方法字段如下介紹如下：
①GET:請求獲取Request-URI(URI:通用資源標識符,URL是其子集，URI注重的是標識，而URL強調的是位置，可以將URL看成原始的URI),所標識的資源。
②POST：在Request-URI所標識的資源後附加新的數據；支持HTML表單提交，表單中有用戶添入的數據，這些數據會發送到服務器端，由服務器存儲至某位置（例如發送處理程序）。
③HEAD:請求Request-URI所標識的資源響應消息報頭，HEAD方法可以在響應時不返回消息體。
④PUT：與GET相反，請求服務器存儲一個資源，並用Request-URI做爲其標識；例如發佈系統。
⑤DELETE：請求刪除URL指向的資源。
⑥OPTIONS：請求查詢服務器的性能，或者查詢與資源相關的選項。
⑦TRACE：跟蹤請求要經過的防火牆、代理或網關等，主要用於測試或診斷。
⑧CONNECT：保留將來使用。
|
狀態碼 |
狀態描述 |
簡要說明 |
|
200 |
OK |
客戶端請求成功 |
|
201 |
Created |
請求已經被實現，而且有一個新的資源已經依據請求的需要而創建，且其URI已經隨Location頭信息返回。 |
|
301 |
Moved Permanently |
被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個URI之一 |
|
302 |
Found |
在響應報文中使用首部“Location: URL”指定臨時資源位置 |
|
304 |
Not Modified |
條件式請求中使用 |
|
403 |
Forbidden |
請求被服務器拒絕 |
|
404 |
Not Found |
服務器無法找到請求的URL |
|
405 |
Method Not Allowed |
不允許使用此方法請求相應的URL |
|
500 |
Internal Server Error |
服務器內部錯誤 |
|
502 |
Bad Gateway |
代理服務器從上游收到了一條僞響應 |
|
503 |
Service Unavailable |
服務器此時無法提供服務，但將來可能可用 |
|
505 |
HTTP Version Not Supported |
服務器不支持，或者拒絕支持在請求中使用的HTTP版本。這暗示着服務器不能或不願使用與客戶端相同的版本。響應中應當包含一個描述了爲何版本不被支持以及服務器支持哪些協議的實體。 |
HTTP長連接和短連接
HTTP協議與TCP/IP協議的關係
HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另一端收到發端發出的所有包，並且順序與發出順序一致。TCP有可靠，面向連接的特點。
如何理解HTTP協議是無狀態的
HTTP協議是無狀態的，指的是協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。也就是說，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯繫。HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）。
什麼是長連接、短連接？
在HTTP/1.0中，默認使用的是短連接。也就是說，瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。
但從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭有加入這行代碼：Connection:keep-alive
在使用長連接的情況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
TCP短連接
短連接的情況：client向server發起連接請求，server接到請求，然後雙方建立連接。client向server發送消息，server迴應client，然後一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起close操作。爲什麼呢，一般的server不會回覆完client後立即關閉連接的，當然不排除有特殊的情況。從上面的描述看，短連接一般只會在client/server間傳遞一次讀寫操作
短連接的優點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段。
TCP長連接
長連接的情況：client向server發起連接，server接受client連接，雙方建立連接。client與server完成一次讀寫之後，它們之間的連接並不會主動關閉，後續的讀寫操作會繼續使用這個連接。
首先說一下TCP/IP詳解上講到的TCP保活功能，保活功能主要爲服務器應用提供，服務器應用希望知道客戶主機是否崩潰，從而可以代表客戶使用資源。如果客戶已經消失，使得服務器上保留一個半開放的連接，而服務器又在等待來自客戶端的數據，則服務器將應遠等待客戶端的數據，保活功能就是試圖在服務器端檢測到這種半開放的連接。
如果一個給定的連接在兩小時內沒有任何的動作，則服務器就向客戶發一個探測報文段，客戶主機必須處於以下4個狀態之一：
(1)客戶主機依然正常運行，並從服務器可達。客戶的TCP響應正常，而服務器也知道對方是正常的，服務器在兩小時後將保活定時器復位。
(2)客戶主機已經崩潰，並且關閉或者正在重新啓動。在任何一種情況下，客戶的TCP都沒有響應。服務端將不能收到對探測的響應，並在75秒後超時。服務器總共發送10個這樣的探測，每個間隔75秒。如果服務器沒有收到一個響應，它就認爲客戶主機已經關閉並終止連接。
(3)客戶主機崩潰並已經重新啓動。服務器將收到一個對其保活探測的響應，這個響應是一個復位，使得服務器終止這個連接。
(4)客戶機正常運行，但是服務器不可達，這種情況與2類似，TCP能發現的就是沒有收到探查的響應。
短連接的操作步驟是：
建立連接——數據傳輸——關閉連接…建立連接——數據傳輸——關閉連接
長連接的操作步驟是：
建立連接——數據傳輸…(保持連接)…數據傳輸——關閉連接
長連接和短連接的優點和缺點
由上可以看出，長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對於頻繁請求資源的客戶來說，較適用長連接。不過這裏存在一個問題，存活功能的探測週期太長，還有就是它只是探測TCP連接的存活，屬於比較斯文的做法，遇到惡意的連接時，保活功能就不夠使了。在長連接的應用場景下，client端一般不會主動關閉它們之間的連接，client與server之間的連接如果一直不關閉的話，會存在一個問題，隨着客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要採取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可以避免一些惡意連接導致server端服務受損；如果條件再允許就可以以客戶端機器爲顆粒度，限制每個客戶端的最大長連接數，這樣可以完全避免某個蛋疼的客戶端連累後端服務。
短連接對於服務器來說管理較爲簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費時間和帶寬。長連接和短連接的產生在於client和server採取的關閉策略，具體的應用場景採用具體的策略，沒有十全十美的選擇，只有合適的選擇。
什麼時候用長連接、短連接？
長連接多用於操作頻繁，點對點的通訊，而且連接數不能太多情況。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket創建也是對資源的浪費。
像Web網站的http服務一般都用短鏈接，因爲長連接對於服務端來說會耗費一定的資源(具體還是要看實際情況以及用戶需求)。若Web網站的操作比較頻繁，而且有成千上萬甚至上億的客戶端，短連接會更節省資源。如果用長連接，同時有成千上萬的用戶，如果每個用戶都佔用一個連接的話，資源花費可想而知。所以在併發量大，而且每個用戶無需頻繁操作的情況下使用短連接會更好。
TCP協議
TCP報文格式：
TCP三次握手：
TCP四次揮手：
TCP報文詳細分析(第三次握手)：
TCP報文：[29 05 01 bb f4 0a 2c 77 1f a9 79 d2 50 10 01 00 b9 84 00 00]
爲了更易理解：[29 05 01 bb]
[f4 0a 2c 77]
[1f a9 79 d2]
[50 10 01 00]
[b9 84 00 00]
源端口：2905(HEX) = 10501(DEC)
目的端口：01bb(HEX) = 443(DEC)
序號：1
確認號：1
十六進制[50 10]轉化成二進制[0101 0000 0001 0000]
數據偏移(佔4位)：單位是4個字節，此字段值爲5，所以TCP首部的長度是20字節。
保留(佔6位)：保留爲今後使用，目前置爲0。
緊急位URG:0
確認位ACK:1
推送位PSH:0
復位位RST:0
同步位SYN:0
終止位FIN:0
窗口：0100(HEX) = 256(DEC)
檢驗和：0xb984
緊急指針：0
需要注意的是：四次揮手的序號和確認號。
在TCP要斷開連接時，由客戶端發送結束報文。[FIN,ACK]報文(第三次揮手)的序號等於最後一次[ACK]報文的確認號加1，而它的確認號等於最後一次[ACK]報文的序號。
UDP協議
UDP報文格式：
UDP報文：[09 06 c3 3b]
[00 57 05 01]
源端口：0906(HEX) = 2310(DEC)
目的端口：c33b(HEX) = 49979(DEC)
長度：57(HEX) = 87(DEC)
校驗和：0x0501
IP協議
IP報文格式：
IP報文：[45 00 00 28]
[1c de 40 00]
[40 06 00 00]
[0a 66 09 5a]
[27 60 84 45]
版本：4
首部長度(單位是4字節)：20
區分服務：0x00
總長度(單位是字節)：40
標識：0x1cde
十六進制[40 00]轉化成二進制[0100 0000 0000 0000]
標誌(佔3位，即010)：Reserved bit: Not set
Do not fragmaent:set
More fragments:Not set
片偏移(佔13位)：0
生存時間：64
協議：TCP
首部檢驗和：0x0000
源地址：10.102.9.90
目的地址：39.96.132.69
ARP協議
ARP協議格式：
硬件類型：Ethernet(1)
協議類型：IPv4(0x0800)
硬件地址長度：6
協議地址長度：4
OP:request(1)
發送者MAC地址：Hewlettp_14:c9:c1 (34:64:a9:14:c9:c1)
發送者IP地址：10.102.7.206
目標MAC地址：00:00:00_00:00:00 (00:00:00:00:00:00)
目標IP地址：10.102.127.254
參考：
http://www.cnblogs.com/0201zcr/p/4694945.html
https://jocent.me/2017/06/18/dns-protocol-principle.html#_label0_0