一. 引言
網絡協議是每個程序員都要掌握的基礎知識,干啥都離不開網絡,就算在家里新買了個路由器不是嗎,同事連不上網,你的女朋友手機沒有網看劇了正看到高潮部分,到那時候你打開百度......那嫌棄的你的眼神仿佛在說,就這?程序員連個網都不會修?以上都是臆想,以實際為准.雖然看完本文章,你還是需要去百度怎么修復網絡問題,但是你已經知道為什么會出現這種問題了!
二. UDP
UDP協議全稱是用戶數據報協議,在網絡中它與TCP協議一樣用於處理數據包,是一種無連接的協議.在OSI中,第四層傳輸層,處於IP協議的上一層UDP有不提供數據包分組,組裝和不能對數據包進行排序的缺點,也就是說,當報文發送后,無法監控其是否完整安全到達的,就想一個壞掉了的水龍頭,你不論怎么讓他停止他都只會輸出,也不管你的桶滿沒滿,就像愛一樣
特點
1. 面向無連接:
首先UDP是不需要和TCP一樣在發送數據前進行三次握手建立連接的,想發數據就可以開始發送了.並且也只是主句報文的搬運工,不會對數據報文進行任何拆分和拼接操作
具體來說:
- 在發送端,應用層將數據傳遞給UDP協議,UDP只會給數據增加一個UDP頭標識下UDP,然后就傳遞給網絡層了
- 在接收端,網絡層將數據傳遞給傳輸層,UDP只去除IP報頭就傳遞給應用層,不會任何拼接操作
2. 有單播,多播,廣播的功能
UDP不止支持一對一的傳輸方式,同樣支持一對多,多對多,多對一的方式,也就是說UDP提供了單播,多播和廣播的功能.
3. UDP是面向報文的
發送方的UDP讀應用程序交下來的報文,在添加首部后就向下交付IP層.UDP對應用層交下來的報文,既不合並,也不拆分,而是保留這些報文的邊界.因此,應用程序必須選擇合適大小的報文
4. 不可靠性
首先不可靠性體現在無連接上,通信不需要建立連接,想發就發,這樣的情況肯定不可靠
並且受到什么數據就傳遞什么數據,並且也不會備份數據,發送數據也不會關心對方是否已經正確接收到數據了
再者網絡環境時好時壞,但是UDP因為沒有擁塞控制,一直會以恆定的速度發送數據,即使網絡條件不好,也不會對發送數據進行調整.這樣實現的弊端就是在網絡條件不好的情況下會導致丟包,但是有點也很明顯,比如電話會議等等最好就是UDP
5. 頭部開銷小,傳輸數據報文是很高效的.
因此UDP的頭部開銷小,只有八字節,相比TCP的至少二十字節要少得多,在傳輸數據報文時是很高效的
三. TCP/IP網絡模型
計算機網絡設備相互通信,雙方必須基於相同的方法.比如如何探測到通信目標,由那一邊先發起通信,使用哪種語言進行通信,怎樣結束通信等規則都需要實現確定.不同硬件,操作系統之間的通信,所有的這一切都需要一種規則,而我們吧這種規則成為協議.
TCP/IP是互聯網相關的各類協議的總稱,比如:**TCP，UDP，IP，FTP，HTTP，ICMP，SMTP **等都屬於 TCP/IP 族內的協議
大家一定知道OSI七層模型,TCP/IP概念模型是這樣的
- 應用層:負責向用戶提供應用程序.比如HTTP,FTP,Telnet,DNS,SMTP等
- 傳輸層:負責對報文進行分組和重組,並以TCP或UDP協議格式封裝報文
- 網絡層:負責路由以及把分組報文發送給目標網絡或主機
- 鏈路層:負責封裝和接縫IP報文,發送和接收ARP/RARP報文等
TCP
當一台計算機想要與另一台計算機通訊時,兩台計算機之間的通信需要暢通且可靠,這樣才能保證正確收發數據.例如當你收文件時候不希望收到的是一個損壞的文件,發過來的小電影是無法放映的,或者直接變成馬賽克,當然也可能本來就有馬賽克,這不是我們希望得到的,於是就用到了TCP
TCP協議全稱是傳輸控制協議,,這是一種面向連接的,可靠的,基於字節流的傳輸層通信協議
TCP的連接過程
TCP報文也分為首部和數據兩部分,首部默認情況下一般是20字節長度,但在20字節長度,但在一些請求情況下,會使用"可選字段",這時,首部長度會有所增加,但最長不超過60字節
源端口 - 16bit
來源處的端口號；端口號有65536個，即$2^{16}$。
目的端口 - 16bit
目的處的端口號
序號 - 32bit
TCP在對數據進行分段的時候，會給每一個TCP報文段添加一個序號，序號字段的值其實是該文段所發送的數據的第一個字節的序號。這么做的原因是，TCP是面向連接的可靠服務，這個序號可以保證數據在傳輸過程中保持有序性，接受端可以通過這個序號確認收到的數據的完整性和先后順序；
確認號 - 32bit
確認號，是期望收到對方的下一個報文段的數據的第一個字節的序號；
數據偏移 - 4bit
其實它本質上就是“首部長度”，因為“數據偏移”是指TCP報文段的數據部分的起始處距離TCP報文段的起始處的距離。（仍然很拗口，但相信你能明白）。
數據偏移總共占4bit，因此最大能表示的數值為15。但TCP的報文頭部至少為20字節。因此數據偏移的單位是“4字節”，此處的設計和IP數據報的設計是完全相同的，所以說TCP報文段首部的長度最長為15×4=60字節，且首部長度必須為4字節的整數倍。
保留字段 - 6bit
IETF文檔指出，這6bit在標准中是保留字段，留待以后使用，必須為0。我猜測，有兩個目的，第一個是預留除URG/ACK/PSH/RST/SYN/FIN/之外的冗余功能位；第二個是為了對齊字節位。
控制位 - 6bit
又稱為TCP flag，該字段從左到右分為以下六個字段，指明包的類型。同時用於控制TCP的狀態機，同時ACK和SYN與三次握手協議有關，FIN與四次揮手協議有關。
① 緊急字段URG - 1bit
當URG=1時，此字段告訴系統此報文段中有緊急數據，應盡快傳送。
② 確認字段ACK - 1bit
當ACK=1時，表示確認，且確認號有效；當ACK=0時，確認號字段無效。
③ 推送字段PSH - 1bit
當PSH=1時，則報文段會被盡快地交付給目的方，不會對這樣的報文段使用緩存策略。
④ 復位字段RST - 1bit
當RST為1時，表明TCP連接中出現了嚴重的差錯，必須釋放連接，然后再重新建立連接。
⑤ 同步字段SYN - 1bit
當SYN=1時，表示發起一個連接請求。
⑥ 終止字段FIN - 1bit
用來釋放連接。當FIN=1時，表明此報文段的發送端的數據已發送完成，並要求釋放連接。
窗口字段 - 16bit
此字段用來控制對方發送的數據量，單位為字節。
一般TCP連接的其中一端會根據自身的緩存空間大小來確定自己的接收窗口大小，然后告知另一端以確定另一端的發送窗口大小。該字段與TCP的流量控制服務有關。
校驗和字段 - 16bit
與IP協議的檢驗和不同，TCP的這個校驗和是針對首部和數據兩部分的。
緊急指針字段 - 16bit
緊急指針指出在本報文段中的緊急數據的最后一個字節的序號。
三次握手四次揮手(這詞都聽吐了,換個叫法:一鍵三連,取消三連加取關/滑稽))
還有一點其實人家是Three-way handshake,三步握手四步揮手的,誰握手握三次,揮手揮四次的,/吃瓜
TIP:注意箭頭的指向,結合文字進行理解,箭頭沒有問題
1. 一鍵三連
在三連之前服務器和客戶端都為CLOSED狀態.通信開始前,雙方都得創建各自的傳輸控制塊(TCB)
服務器創建完TCB后便進入LISTEN狀態此時准備接受客戶端發來的連接請求
點贊(第一次握手)
客戶端向服務端發送連接請求報文段.該保溫段的頭部中SYN=1,ACK=0,seq=X.請求發送后客戶端便進入SYN-SENT狀態
- SYN = 1,ACK = 0表示該報文段位連接請求報文
- x為本次TCP通信的字節流的初始序號
TIP:TCP規定SYN = 1的報文段不能有數據部分,但要消耗一個序號
投幣(第二次握手)
服務端收到連接請求報文段后,如果同意連接,則會發送一個應答:SYN = 1,ACK = 1,seq = y,ack = x + 1
該應答發送完成后便進入SYN-RCVD狀態.
- SYN=1，ACK=1表示該報文段為連接同意的應答報文
- seq=y表示服務端作為發送者時，發送字節流的初始序號
- ack=x+1表示服務端希望下一個數據報發送序號從x+1開始的字節
收藏(第三次握手)
當客戶端收到連接同意的應答后,還要向服務端發送一個確認報文段,表示服務端發來的連接同意應答已經收到
該報文頭部為:ACK = 1, seq = x + 1, ack = y + 1.
客戶端發完這個報文后便進入ESTABLSHED狀態,服務端收到這個應答后也進入ESTABLISHED狀態,此時連接的建立完成
2. 取消三連加取關
TCP連接的釋放一共需要四部,因為TCP連接時雙向的,因此在四次揮手中,前兩次揮手用於斷開一個方向的連接,后兩次揮手用於斷開另一方向連接
取消點贊(第一次揮手)
若客戶端認為數據發送完成,則它需要向服務端發送連接釋放請求.該請求只有報文頭,頭中攜帶的主要參數為:
FIN = 1,seq = u此時,客戶端將進入FIN-WAIT-1狀態
- FIN = 1表示該保溫是一個連接釋放請求
- seq = u,u - 1是A向B發送的最后一個字節的序號
取消投幣(第二次揮手)
服務端收到連接釋放請求后,會通知相應的應用程序,告訴它客戶端向服務端這個方向的連接已經釋放.此時服務端進入CLOSE-WAIT狀態,並向客戶端發送連接釋放的回答,其報文頭包含:
ACK = 1,seq = v, ack = u + 1
- ACK=1：除TCP連接請求報文段以外，TCP通信過程中所有數據報的ACK都為1，表示應答。
- seq=v，v-1是B向A發送的最后一個字節的序號。
- ack=u+1表示希望收到從第u+1個字節開始的報文段，並且已經成功接收了前u個字節
客戶端收到應答進入FIN-WAIT-2狀態,等待服務端發送連接釋放請求
第二次揮手完成后,客戶端到服務端方向的連接已經釋放,服務端不會接受數據,客戶端也不會發送數據,但服務端到客戶端的連接仍然存在,服務端可以繼續向客戶端發送數據
取消收藏(第三次揮手)
當服務端發送完所有數據后,向客戶端發送連接釋放請求,請求頭:FIN = 1,ACK, seq = w,ack = u+1.服務端便進入LAST-ACK狀態.
取消關注(第四次揮手)
當客戶端收到釋放請求后向B發送確認應答,此時客戶端進入TiME-WAIT狀態,該狀態會持續2MSL(2分鍾)時間,若該時間沒有服務端重發請求的話,就進入CLOSED狀態,撤銷TCB.當服務端收到確認應答后,也進入CLOSED狀態撤銷TCB