TCP UDP常見問題合集

2021-10-05 07:02:02 字數 2615 閱讀 8209

沒有圖,都是口述,簡答或面試時使用。

1.源埠號一般是大於1024的隨機埠;

埠號範圍:0~65535;

2.常用的tcp/udp埠號:

tcp 20,21 ftp(20為資料埠,21為命令埠);

udp 67/68 dhcp(68源埠,67目的埠)

udp 161/162 snmp(161收發請求,162接收trap)

1.tcp面向連線,提供可靠交付,通過流量控制,擁塞控制等一些列機制保證可靠傳輸;udp是無連線的,盡最大可能交付。

2.tcp面向位元組流,將應用層報文看成位元組流組成大小不等的資料塊;udp面向報文,應用層報文並不拆分,只是新增udp首部。

3.tcp連線只能是一對一,而udp支援一對一,一對多,多對多的互動通訊。

1.tcp除頭部可選項之外長度為20。

2.報文結構:

源埠,目的埠,序列號,ack號,頭部長度,6個控制位:psh(盡快交付應用層,不要快取),urg(代表緊急指標是否可用),fin,syn,ack,rst(tcp異常,斷開連線),視窗值(主要用於流量控制),校驗和,緊急指標(指出本報文段最後乙個位元組的序號,使接收方知道緊急資料長度),可選長度。

三次握手:

1.客戶端a隨機生成乙個序列號x,syn置位為1,向伺服器b傳送,請求連線,同時a進入syn-sent態;

2.b響應a的請求,隨機生成序列號y,ack為x+1,syn置為1,ack置為1,向a響應並確認,b進入syn-rcvd態;

3.a收到響應後進入established態,並返回ack確認,ack位置1,序列號為x+1,ack為y+1,值得一提ack不占用序列號,下乙個正常資料序列號依然是x+1,b收到ack後進入established狀態,建立完成。

四次揮手:

1.首先a先發出釋放報文段,fin置為1,序列號假定為u,發出後a進入fin-wait-1階段,主動關閉tcp連線,等待b進行確認;

2.b收到後進入close-wait狀態,發出確認報文,序列號假定為v,ack為u+1,ack位置為1,a到b的連線已經釋放;

3.a收到ack後進入fin-wait-2階段;

4.b沒有資料向a發出之後,發出釋放連線報文,fin位置1,ack位置1,如果之前有資料傳送,序列號不確定,如果沒有,序列號為v,ack為u+1,b進入last-ack階段;

5.a收到釋放報文後,傳送ack最後確認,序列號為u+1,ack為v+1,b收到後進入closed狀態,a等待兩倍最大報文存活時間msl後進入closed狀態。

1.保證客戶端傳送的最後乙個ack能夠到達b,如果b沒有收到ack,超時後b會重傳ack+fin報文段,a能夠在兩倍的msl時間內重新收到ack+fin,否則b將不能正常進入closed狀態;

2.是為了確保等待兩倍的msl後,使得本次連線所產生的報文從網路中消失,下個新的連線不會出現舊的請求報文段。

三次握手:

1.為了使得客戶端得知自己收發資料沒有問題,讓伺服器端得知自己的收發沒有問題,如果說是兩次握手,服務端無法得知自己傳送資料是否成功;

2.為了防止已經失效的連線請求重新到伺服器端,如果某些失效請求在網路中駐留了很久才到伺服器,服務端如果不收到ack就開啟tcp連線,就會使得服務端白白等待客戶端傳送資料,造成資源浪費。

四次揮手:

由於tcp是雙向連線,伺服器與客戶端都可以收發資料,在客戶端想要主動斷開服務時,伺服器端可能還有未傳送完成的資料,所以收到客戶端fin報文段後,先傳送ack確認此報文段,等待伺服器端報文傳送完成後,再進行fin釋放連線請求。

tcp流量控制主要是針對接收端處理速度不如傳送端速度快的問題,消除傳送方使接受方快取溢位的可能性,接收端通過滑動視窗機制,告知傳送端傳送資料的大小,達到流量控制的目的;

視窗指的是一次可以傳送多少資料;

tcp擁塞控制主要針對傳送方傳送資料過快導致網路擁塞的問題,傳送方維持乙個擁塞視窗,擁塞視窗大小取決於網路擁塞程度,傳送方自己的傳送視窗=min(傳送方擁塞視窗,流量控制中接收方告知傳送方的視窗值)。

擁塞控制四種方法:

1.慢啟動

首先把擁塞視窗cwnd設定為乙個mss的數值,每次收到對最後乙個位元組的確認報文後(相當於往返時間rtt)就就將cwnd加倍,當大於慢開始門限ssthresh後,cwnd開始使用擁塞避免演算法;

2.擁塞避免

每經過乙個rtt,不再將cwnd加倍,而是將cwnd加1。

無論是在慢啟動還是在擁塞避免,只要在超時計時器超時後沒收確認報文,就將ssthresh減小到出現擁塞時cwnd的一半,然後cwnd改為1,重新開始慢啟動。

3.快速重傳

普通超時重傳中,在超時計時器超時才認為資料報丟失,在快速重傳機制中,傳送方連續收到三個對同一資料報的確認,即認為資料丟失,不等超時計時器到時就開始重傳。

4.快速恢復

配合快速重傳,當發現資料報丟失後,就將ssthresh減小到出現擁塞時cwnd的一半,但cwnd直接改為新的ssthresh,隨後執行擁塞避免演算法,不再經歷慢啟動。

重傳計時器,堅持計時器(零視窗),保活計時器(客戶端傳了一些資料或者建立連線時突然靜默了),時間等待計時器(關閉連線時等待兩倍的msl);

TCP UDP常見問題小結

1,udp丟包 困擾幾天的udp內網傳輸部分終於做通了,解決的關鍵就在於setsockopt的呼叫,設定接收緩衝。遇到的問題是這樣的,主機端傳送udp資料報 應用層的包大小為1452byte大小,這樣拆包是根據乙太網的mtu為1500位元組而考慮的 當然外網狀態下並不一定就是乙太網網路,路由mtu可...

Python常見問題合集

字典新增元素的方法 pass語句的作用 斷言assert 結構 assert可以設定第二個引數,用於作為觸發異常後的提示語句,並顯示在最後 assert 1 2,1 不等於 2 traceback most recent call last file line 1,in assertionerror...

redis集群常見問題合集

1,ruby版本太低導致的報錯問題 1 2 from redis trib.rb 25 in 1 from usr local ruby lib ruby 2.6.0 rubygems core ext kernel require.rb 54 in require usr local ruby l...