前言:
看完了計網的五層結構，就實際操作一下來捉下不同層下的協議包來康康。加深一下印象=。=
實驗準備
Wireshark軟件
隨意獲取一個網站的ip地址，用於過濾
TCP三次握手
TCP三次握手用於建立TCP連接。
三次握手的連接：
第一次握手：
客戶端主動打開，發送連接請求報文段（SYN報文），SYN標識位置爲1，Sequence Number會被設置爲一個隨機值，然後客戶端進入SYN_SEND狀態，同步已發送狀態
第二次握手：
服務器收到SYN報文段進行確認，將SYN標識位置爲1，ACK置爲1，Sequence Number置爲y，這裏是Acknowledgment Number置爲x+1，然後服務器進入SYN_RECV狀態，並且爲這個狀態被稱爲半連接狀態，會在第三次握手之前爲該TCP連接分配TCP緩存和變量，並將該TCP連接放入半連接隊列。此處服務器容易收到SYN攻擊。
第三次握手：
客戶端再進行一次確認，將ACK置爲1，Sequence Number置爲x+1，Acknowledgment Number置爲y+1，最後客戶端與服務器都進入ESTABLISHED狀態,已建立連接狀態，第三次連接可以在報文段負載中攜帶數據了。
常見問題：
ack與ACK的區別：
ack代表着期待發送的下一個包的序號 ，ACK代表的是TCP標識位中的ACK標識爲1，表示這是一個確認報文。
第二次握手中服務器容易收到什麼攻擊？
服務器端的資源分配是在二次握手時分配的，而客戶端的資源是在完成三次握手時分配的，所以服務器容易受到SYN洪泛攻擊，SYN攻擊就是Client在短時間內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server則回覆確認包，並等待Client確認，由於源地址不存在，因此Server需要不斷重發第二次握手報文直至超時，這些僞造的SYN包將長時間佔用未連接隊列，導致正常的SYN請求因爲隊列滿而被丟棄
爲什麼需要第三次握手？
歸根到底就是要讓客戶端和服務端都清楚雙方的初始序號，TCP 需要 seq 序列號來做可靠重傳或接收，因此需要三次握手來約定確定。第二次握手讓客戶端清楚服務端以獲取自身序號，第三次握手讓服務端知道客戶端以獲取自身序號。
TCP四次握手
tcp四次握手主要是用來關閉TCP連接的
四次連接
這種是服務器主動提出斷開連接。試了蠻多次都是服務器先主動斷開連接的，也沒差啦，不過就是跟書上描述的客戶端先提出的斷開連接調轉了而已，過程差不多。
書上的過程：
第一次握手：
客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀
態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
第二次握手：
-
服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間,關閉等待狀態。
-
客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最後的數據）。
第三次握手：
服務器將最後的數據發送完畢後，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
第四次握手：
- 客戶端收到服務器的連接釋放報文後，必鬚髮出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
- 服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
常見問題：
爲什麼連接的時候是三次握手，關閉的時候卻是四次握手？
答：關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉TCP連接，所以只能先回復一個ACK報文，告訴Client端，“你發的FIN報文我收到了”。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送，多出了這一步。故需要四步握手。
爲什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？
答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。在Client發送出最後的ACK回覆，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重複發送FIN片段。所以Client不能立即關閉，它必須確認Server接收到了該ACK。Client會在發送出ACK之後進入到TIME_WAIT狀態。Client會設置一個計時器，等待2MSL的時間。如果在該時間內再次收到FIN，那麼Client會重發ACK並再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網絡中最大的存活時間，2MSL就是一個發送和一個回覆所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP連接。
DNS連接
dns連接主要分爲兩次：
dns查詢報文：
通過udp報文攜帶dns報文，可以看出是根據把域名攜帶到dnf服務器中
dns響應報文：dns服務器返回域名對應的ip地址
DHCP協議
由於是筆記本=。=，這裏就斷開了wifi然後走到二樓連新的wifi。這時筆記本就會啓動DHCP協議來獲取ip地址
Discover：
u此時廣播DHCP發現報文，通過發送udp分組，使用廣播地址255.255.255.255 源地址0.0.0.0，等待DHCP服務器的響應
offer：某個DHCP分配好ip地址，並返回DHCP提供報文（攜帶這ip地址、網絡掩碼、ip地址租用期）。此時仍然通過廣播的形式返回。因爲此時主機還不知道自身的ip地址
request：從多個DHCP服務器中選擇一個並且向選擇的DHCP服務器返回一個響應報文，此時仍然是廣播，未收到DHCP的ack報文還不能使用所分配的地址
ACK：服務器用DHCP ACK報文對DHCP請求報文就行響應。
至此主機可以使用所分配的地址。