TCP協(xié)議/UDP協(xié)議

TCP傳輸控制協(xié)議面向連接網(wǎng)絡(luò)協(xié)議 安全可靠
UDP用戶報(bào)文協(xié)議 無連接網(wǎng)絡(luò)協(xié)議 傳輸效率高 但不安全
TCP協(xié)議傳輸會先判斷是否在一個(gè)局域網(wǎng)內(nèi) 沒有發(fā)現(xiàn)便會經(jīng)過互聯(lián)網(wǎng)
TCP協(xié)議報(bào)文結(jié)構(gòu)
源端口 目標(biāo)端口 每個(gè)占用16個(gè)BIt tcp協(xié)議端口范圍是0-65535 計(jì)算方法是2的N次方
序列號 對每一個(gè)數(shù)據(jù)包進(jìn)行編號方便資源管理確定數(shù)據(jù)完整性
確認(rèn)號 告知下一次傳輸包編號
控制位 數(shù)據(jù)傳輸控制管理

報(bào)文結(jié)構(gòu).jpg

報(bào)文結(jié)構(gòu).png

傳輸中最小默認(rèn)值為1500字節(jié) 比1500字節(jié)大的都會被分割
名詞:
ACK 確認(rèn)控制字符 0=無效 1=生效
FIN 斷開連接字符 0=無效 1=有效
SYN 請求建立連接 0=無效 1=有效

三次握手

三次握手.jpg

• 首先兩個(gè)人約定協(xié)議

1. 感覺網(wǎng)絡(luò)情況不對的時(shí)候，任何一方都可以發(fā)起詢問
2. 任何情況下，若發(fā)起詢問后5秒還沒收到回復(fù)，則認(rèn)為網(wǎng)絡(luò)不通
3. 網(wǎng)絡(luò)不通的情況下等1min路由器之后再發(fā)起詢問

• 對于我而言，發(fā)起 “1+1等于幾”的詢問后

1. 若5s內(nèi)沒有收到回復(fù)，則認(rèn)為網(wǎng)絡(luò)不通
2. 若收到回復(fù)，則我確認(rèn)①我能聽到她的消息 ②她能聽到我的消息，然后回復(fù)她的問題的答案

• 對于她而言，當(dāng)感覺網(wǎng)絡(luò)情況不對的時(shí)候

1. 若沒有收到我的詢問，則她發(fā)起詢問
2. 若收到“1+1等于幾”，則她確認(rèn) ①她可以聽到我的消息，然后回復(fù)我的問題的答案和她的問題“2，2+2等于幾”
3. 若5s內(nèi)沒有收到我的回復(fù)“4”，則她確認(rèn) ②我聽不見她的消息
4. 若5s內(nèi)收到了我的回復(fù)“4”，則她確認(rèn) ②我可以聽見她的消息
   這樣，如果上面的對話得以完成，就證明雙方都可以確認(rèn)自己可以聽到對方的聲音，對方也可以聽到自己的聲音！

四次揮手

所謂四次揮手（Four-Way Wavehand）即終止TCP連接，就是指斷開一個(gè)TCP連接時(shí)，需要客戶端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開。在socket編程中，這一過程由客戶端或服務(wù)端任一方執(zhí)行close來觸發(fā)

四次揮手.jpg

第二次握手
服務(wù)端收到這個(gè)FIN，他發(fā)回一個(gè)ACK(確認(rèn))，確認(rèn)收到序號為收到序號+1，和SYN一樣，一個(gè)FIN將占用一個(gè)序號。
服務(wù)器收到連接釋放報(bào)文，發(fā)出確認(rèn)報(bào)文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v，此時(shí)，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器
通知高層的應(yīng)用進(jìn)程，客戶端向服務(wù)器的方向就釋放了，這時(shí)候處于半關(guān)閉狀態(tài)，即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個(gè)
狀態(tài)還要持續(xù)一段時(shí)間，也就是整個(gè)CLOSE-WAIT狀態(tài)持續(xù)的時(shí)間。
客戶端收到服務(wù)器的確認(rèn)請求后，此時(shí)，客戶端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報(bào)文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。

第三次握手
服務(wù)端發(fā)送一個(gè)FIN(結(jié)束)到客戶端，服務(wù)端關(guān)閉客戶端的連接。
服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報(bào)文，F(xiàn)IN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時(shí)的序列號為seq=w，
此時(shí)，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)。

第四次握手
客戶端發(fā)送ACK(確認(rèn))報(bào)文確認(rèn)，并將確認(rèn)的序號+1，這樣關(guān)閉完成。
客戶端收到服務(wù)器的連接釋放報(bào)文后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時(shí)，客戶端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)。注意此時(shí)
TCP連接還沒有釋放，必須經(jīng)過2??MSL（最長報(bào)文段壽命）的時(shí)間后，當(dāng)客戶端撤銷相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。
服務(wù)器只要收到了客戶端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。同樣，撤銷TCB后，就結(jié)束了這次的TCP連接?？梢钥吹?，服務(wù)器結(jié)束TCP連接的時(shí)間要比客戶端早一些。

什么是2MSL

MSL是Maximum Segment Lifetime英文的縮寫，中文可以譯為“報(bào)文最大生存時(shí)間”，他是任何報(bào)文在網(wǎng)絡(luò)上存在的最長時(shí)間，超過這個(gè)時(shí)間報(bào)文將被丟棄。因?yàn)閠cp報(bào)文（segment）是ip數(shù)據(jù)報(bào)（datagram）的數(shù)據(jù)部分，具體稱謂請參見《數(shù)據(jù)在網(wǎng)絡(luò)各層中的稱呼》一文，而ip頭中有一個(gè)TTL域，TTL是time to live的縮寫，中文可以譯為“生存時(shí)間”，這個(gè)生存時(shí)間是由源主機(jī)設(shè)置初始值但不是存的具體時(shí)間，而是存儲了一個(gè)ip數(shù)據(jù)報(bào)可以經(jīng)過的最大路由數(shù)，每經(jīng)過一個(gè)處理他的路由器此值就減1，當(dāng)此值為0則數(shù)據(jù)報(bào)將被丟棄，同時(shí)發(fā)送ICMP報(bào)文通知源主機(jī)。RFC 793中規(guī)定MSL為2分鐘，實(shí)際應(yīng)用中常用的是30秒，1分鐘和2分鐘等。

2MSL即兩倍的MSL，TCP的TIME_WAIT狀態(tài)也稱為2MSL等待狀態(tài)，當(dāng)TCP的一端發(fā)起主動關(guān)閉，在發(fā)出最后一個(gè)ACK包后，即第3次握手完成后發(fā)送了第四次握手的ACK包后就進(jìn)入了TIME_WAIT狀態(tài)，必須在此狀態(tài)上停留兩倍的MSL時(shí)間，等待2MSL時(shí)間主要目的是怕最后一個(gè)ACK包對方?jīng)]收到，那么對方在超時(shí)后將重發(fā)第三次握手的FIN包，主動關(guān)閉端接到重發(fā)的FIN包后可以再發(fā)一個(gè)ACK應(yīng)答包。在TIME_WAIT狀態(tài)時(shí)兩端的端口不能使用，要等到2MSL時(shí)間結(jié)束才可繼續(xù)使用。當(dāng)連接處于2MSL等待階段時(shí)任何遲到的報(bào)文段都將被丟棄。不過在實(shí)際應(yīng)用中可以通過設(shè)置SO_REUSEADDR選項(xiàng)達(dá)到不必等待2MSL時(shí)間結(jié)束再使用此端口。

TTL與MSL是有關(guān)系的但不是簡單的相等的關(guān)系，MSL要大于等于TTL。

• 思考：那么為什么是4次揮手呢?
  為了確保數(shù)據(jù)能夠完成傳輸。
  關(guān)閉連接時(shí)，當(dāng)收到對方的FIN報(bào)文通知時(shí)，它僅僅表示對方?jīng)]有數(shù)據(jù)發(fā)送給你了；但未必你所有的數(shù)據(jù)都全部發(fā)送給對方了，所以你可以未必會馬上會關(guān)閉SOCKET,也
  即你可能還需要發(fā)送一些數(shù)據(jù)給對方之后，再發(fā)送FIN報(bào)文給對方來表示你同意現(xiàn)在可以關(guān)閉連接了，所以它這里的ACK報(bào)文和FIN報(bào)文多數(shù)情況下都是分開發(fā)送的。
  可能有人會有疑問，tcp我握手的時(shí)候?yàn)楹蜛CK(確認(rèn))和SYN(建立連接)是一起發(fā)送。揮手的時(shí)候?yàn)槭裁词欠珠_的時(shí)候發(fā)送呢.
  因?yàn)楫?dāng)Server端收到Client端的SYN連接請求報(bào)文后，可以直接發(fā)送SYN+ACK報(bào)文。其中ACK報(bào)文是用來應(yīng)答的，SYN報(bào)文是用來同步的。但是關(guān)閉連接時(shí)，當(dāng)Server端收到
  FIN報(bào)文時(shí)，很可能并不會立即關(guān)閉 SOCKET，所以只能先回復(fù)一個(gè)ACK報(bào)文，告訴Client端，"你發(fā)的FIN報(bào)文我收到了"。只有等到我Server端所有的報(bào)文都發(fā)送完了，我才能
  發(fā)送FIN報(bào)文，因此不能一起發(fā)送。故需要四步握手

關(guān)于三次握手與四次揮手通常都會有典型的面試題
（1）三次握手是什么或者流程？四次握手呢？
（2）為什么建立連接是三次握手，而關(guān)閉連接卻是四次揮手呢？

TCP 11種狀態(tài)

1350996969_2313.jpg

LISTEN ：表示服務(wù)器端的某個(gè)SOCKET處于監(jiān)聽狀態(tài)，可以接受客戶端的連接。

SYN_RCVD ：表示服務(wù)器接收到了來自客戶端請求連接的SYN報(bào)文。在正常情況下，這個(gè)狀態(tài)是服務(wù)器端的SOCKET在建立TCP連接時(shí)的三次握手會話過程中的一個(gè)中間狀態(tài)，很短暫，基本上用netstat很難看到這種狀態(tài)，除非故意寫一個(gè)監(jiān)測程序，將三次TCP握手過程中最后一個(gè)ACK報(bào)文不予發(fā)送。當(dāng)TCP連接處于此狀態(tài)時(shí)，再收到客戶端的ACK報(bào)文，它就會進(jìn)入到ESTABLISHED 狀態(tài)。

SYN_SENT ：這個(gè)狀態(tài)與SYN_RCVD 狀態(tài)相呼應(yīng)，當(dāng)客戶端SOCKET執(zhí)行connect()進(jìn)行連接時(shí)，它首先發(fā)送SYN報(bào)文，然后隨即進(jìn)入到SYN_SENT 狀態(tài)，并等待服務(wù)端的發(fā)送三次握手中的第2個(gè)報(bào)文。SYN_SENT 狀態(tài)表示客戶端已發(fā)送SYN報(bào)文。

ESTABLISHED ：表示TCP連接已經(jīng)成功建立。

FIN_WAIT_1：這個(gè)狀態(tài)得好好解釋一下，其實(shí)FIN_WAIT_1 和FIN_WAIT_2 兩種狀態(tài)的真正含義都是表示等待對方的FIN報(bào)文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實(shí)際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時(shí)，它想主動關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報(bào)文，此時(shí)該SOCKET進(jìn)入到FIN_WAIT_1 狀態(tài)。而當(dāng)對方回應(yīng)ACK報(bào)文后，則進(jìn)入到FIN_WAIT_2 狀態(tài)。當(dāng)然在實(shí)際的正常情況下，無論對方處于任何種情況下，都應(yīng)該馬上回應(yīng)ACK報(bào)文，所以FIN_WAIT_1 狀態(tài)一般是比較難見到的，而FIN_WAIT_2 狀態(tài)有時(shí)仍可以用netstat看到。

FIN_WAIT_2 ：上面已經(jīng)解釋了這種狀態(tài)的由來，實(shí)際上FIN_WAIT_2狀態(tài)下的SOCKET表示半連接，即有一方調(diào)用close()主動要求關(guān)閉連接。注意：FIN_WAIT_2 是沒有超時(shí)的（不像TIME_WAIT 狀態(tài)），這種狀態(tài)下如果對方不關(guān)閉（不配合完成4次揮手過程），那這個(gè) FIN_WAIT_2 狀態(tài)將一直保持到系統(tǒng)重啟，越來越多的FIN_WAIT_2 狀態(tài)會導(dǎo)致內(nèi)核crash。

TIME_WAIT ：表示收到了對方的FIN報(bào)文，并發(fā)送出了ACK報(bào)文。 TIME_WAIT狀態(tài)下的TCP連接會等待2MSL（Max Segment Lifetime，最大分段生存期，指一個(gè)TCP報(bào)文在Internet上的最長生存時(shí)間。每個(gè)具體的TCP協(xié)議實(shí)現(xiàn)都必須選擇一個(gè)確定的MSL值，RFC 1122建議是2分鐘，但BSD傳統(tǒng)實(shí)現(xiàn)采用了30秒，Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本機(jī)的這個(gè)值），然后即可回到CLOSED* 可用狀態(tài)了。如果FIN_WAIT_1狀態(tài)下，收到了對方同時(shí)帶FIN標(biāo)志和ACK標(biāo)志的報(bào)文時(shí)，可以直接進(jìn)入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)。（這種情況應(yīng)該就是四次揮手變成三次揮手的那種情況）

CLOSING ：這種狀態(tài)在實(shí)際情況中應(yīng)該很少見，屬于一種比較罕見的例外狀態(tài)。正常情況下，當(dāng)一方發(fā)送FIN報(bào)文后，按理來說是應(yīng)該先收到（或同時(shí)收到）對方的ACK報(bào)文，再收到對方的FIN報(bào)文。但是CLOSING 狀態(tài)表示一方發(fā)送FIN報(bào)文后，并沒有收到對方的ACK報(bào)文，反而卻也收到了對方的FIN報(bào)文。什么情況下會出現(xiàn)此種情況呢？那就是當(dāng)雙方幾乎在同時(shí)close()一個(gè)SOCKET的話，就出現(xiàn)了雙方同時(shí)發(fā)送FIN報(bào)文的情況，這是就會出現(xiàn)CLOSING 狀態(tài)，表示雙方都正在關(guān)閉SOCKET連接。

CLOSE_WAIT ：表示正在等待關(guān)閉。怎么理解呢？當(dāng)對方close()一個(gè)SOCKET后發(fā)送FIN報(bào)文給自己，你的系統(tǒng)毫無疑問地將會回應(yīng)一個(gè)ACK報(bào)文給對方，此時(shí)TCP連接則進(jìn)入到CLOSE_WAIT狀態(tài)。接下來呢，你需要檢查自己是否還有數(shù)據(jù)要發(fā)送給對方，如果沒有的話，那你也就可以close()這個(gè)SOCKET并發(fā)送FIN報(bào)文給對方，即關(guān)閉自己到對方這個(gè)方向的連接。有數(shù)據(jù)的話則看程序的策略，繼續(xù)發(fā)送或丟棄。簡單地說，當(dāng)你處于CLOSE_WAIT 狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接。

LAST_ACK ：當(dāng)被動關(guān)閉的一方在發(fā)送FIN報(bào)文后，等待對方的ACK報(bào)文的時(shí)候，就處于LAST_ACK 狀態(tài)。當(dāng)收到對方的ACK報(bào)文后，也就可以進(jìn)入到CLOSED 可用狀態(tài)了。

• 客戶端獨(dú)有:

1. SYN_SENT (等待接收連接申請回復(fù)狀態(tài))
2. FIN_WAIT 1 (等待遠(yuǎn)程連接中斷請求狀態(tài)1)
3. FIN_WAIT 2 (等待遠(yuǎn)程連接中斷請求狀態(tài) 2)
4. CLOSING (等待遠(yuǎn)程TCP對連接中斷的確認(rèn)狀態(tài))
5. TIME_WAIT(等待足夠的時(shí)間以確保遠(yuǎn)程TCP接收到連接中斷確認(rèn)信息)

• 服務(wù)端獨(dú)有

1. LISTEN (偵聽來自遠(yuǎn)方TCP端口的連接申請)
2. SYN_RCVD (等待客戶端回復(fù)連接申請狀態(tài))
3. CLOSE_WAIT (等待TCP遠(yuǎn)程連接中斷的確認(rèn))
4. LAST_ACK(等待原來發(fā)向遠(yuǎn)程TCP的中斷連接確認(rèn))

• 共有

1. CLOSED (關(guān)閉 沒有任何連接狀態(tài))
2. ESTABLISHED (通訊 連接成功狀態(tài))

網(wǎng)絡(luò)重要協(xié)議

• DNS協(xié)議原理 , 建立IP地址和域名對應(yīng)關(guān)系
  作用 將域名信息轉(zhuǎn)換為IP地址
  DNS解析過程

1. 本地查詢解析記錄
   (1) 查看本地DNS緩存,可以利用ipconfig 如果本地有記錄便會直接訪問
   (2) 本機(jī)手動配置DNS解析 電腦配置文件存放地點(diǎn)C:\Windows\System32\drivers\etc\hosts
   當(dāng)本地查找不到時(shí)會到網(wǎng)上LDNS服務(wù)器上進(jìn)行查找
2. 遞歸查詢
   當(dāng)本地查找不到 會在網(wǎng)上LDNS服務(wù)器(域名服務(wù)器)上進(jìn)行查找DNS解析 找到對應(yīng)的DNS解析發(fā)送到主機(jī)上以獲取地址
   常見DNS服務(wù)器有223.5.5.5 / 2223.6.6.6
3. 迭代查詢
   LDNS也沒找到對應(yīng)地址時(shí)便會向根域名發(fā)送請求
   根域名服務(wù)器會提供頂級服務(wù)器的信息,頂級服務(wù)器會發(fā)送二級服務(wù)器信息直到對應(yīng)的域名服務(wù)器 然后返回信息
   一個(gè)網(wǎng)址的全稱寫法www.baidu.con.
.代表根域名服務(wù)器 用于提供頂級域名服務(wù)器信息
   .com代表頂級服務(wù)器 提供二級域名服務(wù)器信息
   .baidu代表二級服務(wù)器 提供IP和域名對應(yīng)關(guān)系
   www代表不同的網(wǎng)站
   得到信息后就會建立TCP三次握手 開始訪問網(wǎng)址傳輸數(shù)據(jù)
   dig 網(wǎng)址 +trace 查看DNS解析過程

• ARP協(xié)議
  ARP協(xié)議 用于建立IP和MAC地址對應(yīng)關(guān)系(一般局域網(wǎng)常用)

1. 一臺主機(jī)向另一臺主機(jī)發(fā)送信息時(shí), 會發(fā)送一個(gè)Request請求MAC地址
   另一臺主機(jī)收到后會回復(fù)Reply MAC地址 兩臺主機(jī)的ARP協(xié)議會記錄MAC地址 接著開始會話

2. 在交換機(jī)環(huán)境中(多臺機(jī)器) 一臺向另一臺服務(wù)器發(fā)送信息時(shí) 會發(fā)送一個(gè)Request包 這時(shí)Request內(nèi)信息為目標(biāo)IP 源IP 源MAC FF 因?yàn)椴恢滥繕?biāo)MAC 所有會廣播給所有用戶 進(jìn)行解析
   當(dāng)目標(biāo)IP地址主機(jī)收到后回復(fù)Reply 自己的MAC地址這個(gè)過程就是ARP詢問 / 回復(fù)

3. ARP會在主機(jī)中生成一個(gè)ARP表 (IP地址對應(yīng)的MAC地址表)
   每次通訊都會記錄IP對應(yīng)的MAC地址 在多次廣播后ARP中就存儲了完整的對應(yīng)表 之后發(fā)送信息就不用再廣播 節(jié)省資源

ARP原理說明:

1. 構(gòu)建ARP請求和回復(fù)信息 從而獲得MAC地址
2. 構(gòu)建ARP表 表內(nèi)有IP和MAC對應(yīng)關(guān)系信息
3. 構(gòu)建完成后減少廣播發(fā)送次數(shù) 減少資源浪費(fèi)

• ARP緩存表有狀態(tài)

1. 動態(tài) 動態(tài)更新或添加ARP表信息 會定期更新
   主機(jī)插入網(wǎng)線后交換機(jī)會立刻獲取MAC地址組成 交換機(jī)的MAC表,主機(jī)會隨時(shí)更新自己的ARP表
   應(yīng)用場景 : 辦公室常用
2. 靜態(tài) 手工配置ARP表信息 永久保留
   主機(jī)配置靜態(tài)表 局域網(wǎng)內(nèi)所有的主機(jī)都有配置靜態(tài)表 否則不生效
   應(yīng)用場景: 數(shù)據(jù)中心 / IDC機(jī)房

• 查看路由表信息

1. route -n
2. netstat -rn
3. ip route show
   三個(gè)命令都是查看路由表規(guī)則信息