《圖解TCP/IP》之TCP與UDP

1.傳輸層的作用

TCP/IP中有兩個具有代表性的傳輸層協議愕提,它們分別是TCP和UDP试伙。TCP提供可靠的通信傳輸劈狐,而UDP則常被用于讓廣播和細節(jié)調控交給應用的通信傳輸胀葱。

1.傳輸層的定義

IP首部中有一個協議字段,用來標識網絡層的上一層所采用的是哪一種傳輸層協議唇牧。根據這個字段的協議號罕扎,就可以識別IP傳輸的數據部分究竟是TCP的內容聚唐,還是UDP的內容。
同樣腔召,傳輸層的TCP和UDP,為了識別自己所傳輸的數據部分究竟應該發(fā)給哪個應用杆查,也設定了這樣一個編號。

2.通信處理

TCP/IP的眾多應用協議大多以客戶端/服務端的形式運行臀蛛∏阻耄客戶端類似于客戶的意思,是請求的發(fā)起端浊仆。而服務端則表示提供服務的意思客峭,是請求的處理端。另外抡柿,作為服務端的程序有必要提前啟動舔琅,準備接收客戶端的請求。否則即使有客戶端的請請求發(fā)過來洲劣,也無法做到響應的處理备蚓。
這些服務端程序在UNIX系統中叫做守護進程。例如HTTP的服務端程序是httpd囱稽,而ssh的服務端程序是sshd郊尝。在UNIX中并不需要將這些守護進程逐個啟動,而是啟動一個可以代表它們接收客戶端請求的inetd服務程序即可战惊。它是一種超級守護進程流昏,該超級守護進程收到客戶端請求以后會創(chuàng)建新的進程并轉換為sshd等各個守護進程。
確認一個請求究竟是哪個服務端吞获,可以通過所收到數據包的目標端口號輕松識別况凉。

3.兩種傳輸層協議TCP和UDP
  • TCP
    TCP是面向連接的、可靠的流協議衫哥。流就是指不間斷的數據結構茎刚,你可以把它想象成排水管道中的水流。當應用程序采用TCP發(fā)送消息時撤逢,雖然可以保證發(fā)送的順序膛锭,但還是猶如沒有任何間隔的數據流發(fā)送給接收端。
    TCP為提供可靠性傳輸蚊荣,實行“順序控制”或“重發(fā)控制”機制初狰。此外還具備“流控制”、“擁塞控制”互例、提高網絡利用率等眾多功能奢入。
  • UDP
    UDP是不具有可靠性的數據報協議。細微的處理它會交給上層的應用去完成媳叨。在UDP的情況下腥光,雖然可以確保發(fā)送消息的大小关顷,卻不能保證消息一定會到達。因此武福,應用有時會根據自己的需求進行重發(fā)處理议双。
4.TCP和UDP區(qū)分

TCP用于在傳輸層有必要實現可靠傳輸的情況。由于它是面向有連接并具備順序控制捉片、重發(fā)控制等機制的平痰,所以它可以為應用提供可靠傳輸。
UDP主要用于那些對于高速傳輸和實時性有較高要求的通信或廣播通信伍纫。

2.端口號

1.端口號的定義

數據鏈路和IP中的地址宗雇,分別指的是MAC地址和IP地址。前者用來識別同一鏈路中不同的計算機莹规,后者用來識別TCP/IP網絡中互連的主機和路由器赔蒲。在傳輸層中也有這種類似于地址的概念,那就是端口號访惜。端口號用來識別同一臺計算機中進行通信的不同應用程序嘹履。因此,它也被稱為程序地址债热。

2.通過IP地址、端口號幼苛、協議號進行通信識別

TCP/IP或UDP/IP通信中通常采用5個信息來識別一個通信窒篱。它們是“源IP地址”、“目標IP地址”舶沿、“協議號”墙杯、“源端口號”、“目標端口號”括荡。只要其中某一項不同高镐,則被認為是其他通信。

3.端口號如何確定
  • 標準既定的端口號
    這種方法也叫靜態(tài)方法畸冲。它是指每個應用程序都有其指定的端口號嫉髓。但并不是說可以隨意使用任何一個端口號。每個端口號都有其對應的使用目的邑闲。
  • 時序分配法
    服務器有必要確定監(jiān)聽端口號算行,但是接收服務的客戶端沒必要確定端口號。
    在這種方法下苫耸,客戶端應用程序可以完全不用自己設置端口號州邢,而全權交給操作系統進行分配。操作系統可以為每個應用程序分配互不沖突的端口號褪子。
    根據這種動態(tài)分配端口號的機制量淌,即使是同一客戶端程序發(fā)起多個TCP連接骗村,識別這些通信連接的5部分數字也不會全部相同。
4.端口號與協議

端口號由其使用的傳輸層協議決定呀枢。因此叙身,不同的傳輸協議可以使用相同的端口號。
數據到達IP層后硫狞,會先檢查IP首部中的協議號信轿,再傳給相應協議的模塊。如果是TCP則傳給TCP模塊残吩,如果是UDP則傳給UDP模塊去做端口號的處理财忽。即使是同一端口號,由于傳輸協議是各自獨立地進行處理泣侮,因此相互之間不會收到影響即彪。

3.UDP

UDP的特點及其目的
UDP不提供復雜的控制機制,利用IP提供面向無連接的通信服務活尊。并且它是將應用程序發(fā)來的數據在收到的那一刻隶校,立刻按照原樣發(fā)送到網絡上的一種機制。
即使是出現網絡擁堵的情況蛹锰,UDP也無法進行流量控制等避免網絡擁塞的行為深胳。此外,傳輸途中即使出現丟包铜犬,UDP也不負責重發(fā)舞终。甚至當出現包的到達順序亂掉時也沒有糾正功能。如果需要這些細節(jié)控制癣猾,那么不得不交由采用UDP的應用程序去處理敛劝。
由于UDP面向無連接,它可以隨時發(fā)送數據纷宇。再加上UDP本身的處理既簡單又高效夸盟,因此經常用于以下幾個方面:

  • 包總量較少的通信
  • 視頻、音頻等多媒體通信
  • 限定與LAN等待定網絡中的應用通信
  • 廣播通信

4.TCP

TCP是對“傳輸像捶、發(fā)送上陕、通信”進行“控制”的“協議”。它充分地實現了數據傳輸時各種控制功能作岖,可以進行丟包時的重發(fā)控制唆垃,還可以對次序亂掉的分包進行順序控制。TCP作為一種面向有連接的協議痘儡,只有在確認通信對端存在時才會發(fā)送數據辕万,從而可以控制通信流量的浪費。

1.TCP的特點及其目的

為了通過IP數據報實現可靠性傳輸,需要考慮很多事情渐尿。例如數據的破壞醉途、丟包、重復以及分片順序混亂等問題砖茸。
TCP通過檢驗和隘擎、序列號、確認應答凉夯、重發(fā)控制货葬、連接管理以及窗口控制等機制實現可靠性傳輸。

2.通過序列號與確認應答提高可靠性

在TCP中劲够,當發(fā)送端的數據到達接收主機時震桶,接收端主機會返回一個已收到消息的通知。這個消息叫做確認應答征绎。

序列號是按照順序給發(fā)送數據的每一個字節(jié)都標上號碼的編號蹲姐。接收端查詢接收數據TCP首部中的序列號和數據的長度,將自己下一步應該接受的序號作為應答返送回去人柿。就這樣柴墩,通過序列號和確認應答號,TCP可以實現可靠傳輸凫岖。
屏幕快照 2019-02-13 下午5.01.22.png
3.重發(fā)超時如何判斷

重發(fā)超時是指在重發(fā)數據之前江咳,等待確認應答到來的那個特定時間間隔。如果超過了這個時間仍未收到確認應答隘截,發(fā)送端將進行數據重發(fā)扎阶。
重發(fā)超時的計算既要考慮往返時間又要考慮偏差是有其原因的。根據網絡環(huán)境的不同往返時間可能會產生大幅度的搖擺婶芭,之所以發(fā)生這種情況是因為數據包的分段是經過不同路線到達的。TCP/IP的目的是即使在這種環(huán)境下也要進行控制着饥,盡量不要浪費網絡流量犀农。
數據被重發(fā)之后若還是收不到確認應答,則進行再次發(fā)送宰掉。此時呵哨,等待確認應答的時間將會以2倍、4倍的指數函數延長轨奄。
此外孟害,數據也不會被無限、反復地重發(fā)挪拟。達到一定重發(fā)次數之后挨务,如果仍沒有任何確認應答返回,就會判斷為網絡或對端主機發(fā)生了異常,強制關閉連接谎柄。并且通知應用通信異常強行終止丁侄。

4.連接管理

TCP提供面向有連接的通信傳輸。面向有連接是指在數據通信開始之前先做好通信兩端之間的準備工作朝巫。
在數據通信之前鸿摇,通過TCP首部發(fā)送一個SYN包作為建立連接的請求等待確認應答。如果對端發(fā)來確認應答劈猿,則認為可以進行數據通信拙吉。如果對端的確認應答未能到達,就不會進行數據通信揪荣。此外筷黔,在通信結束時會進行斷開連接的處理。

可以使用TCP首部用于控制的字段來管理TCP連接变逃。一個連接的建立與斷開必逆,正常過程至少需要來回發(fā)送7個包才能完成。
屏幕快照 2019-02-13 下午5.17.03.png
5.TCP以段為單位發(fā)送數據

在建立TCP連接的同時揽乱,也可以確定發(fā)送數據包的單位名眉,我們也可以稱其為“最大消息長度”(MSS)。最理想的情況是凰棉,最大消息長度正好是IP中不會被分片處理的最大數據長度损拢。
MSS是在三次握手的時候,在兩端主機之間被計算得出撒犀。兩端的主機在發(fā)出建立連接請求時福压,會在TCP首部中寫入MSS選項,告訴對方自己的接口能夠適應的MSS的大小或舞。然后會在兩者之間選擇一個較小的投入使用荆姆。

6.利用窗口控制提高速度

TCP以1個段為單位,每發(fā)一個段進行一次確認應答的處理映凳。這樣的傳輸方式有一個缺點胆筒。那就是,包的往返時間越長通信性能就越低诈豌。
為了解決這個問題仆救,TCP引入了窗口這個概念。即使在往返時間較長的情況下矫渔,它也能控制網絡性能的下降彤蔽。


屏幕快照 2019-02-14 上午8.57.24.png

窗口大小就是指無需等待確認應答而可以繼續(xù)發(fā)送數據的最大值。

7.窗口控制與重發(fā)控制
屏幕快照 2019-02-14 上午9.01.33.png

屏幕快照 2019-02-14 上午9.01.40.png
8.流控制

TCP提供一種機制可以讓發(fā)送端根據接收端的實際接收能力控制發(fā)送的數據量庙洼。這就是所謂的流控制顿痪。它的具體操作是镊辕,接收端主機向發(fā)送端主機通知自己可以接收數據的大小,于是發(fā)送端會發(fā)送不超過這個限度的數據员魏。這大小限度被稱作窗口大小丑蛤。窗口大小的值就是由接收端主機決定的。


屏幕快照 2019-02-14 上午9.16.48.png
9.擁塞控制
屏幕快照 2019-02-14 上午9.26.25.png

5.UDP首部的格式

屏幕快照 2019-02-14 上午9.34.29.png
  • 源端口號
    表示發(fā)送端端口號撕阎,字段長16位受裹。該字段是可選項,有時可能不會設置源端口號虏束。沒有源端口號的時候該字段的值設置為0.可用于不需要返回的通信中棉饶。
  • 目標端口號
    表示接收端端口,字段長度16位镇匀。
  • 包長度
    該字段保存了UDP首部的長度跟數據的長度之和照藻。單位為字節(jié)。
  • 校驗和
    校驗和是為了提供可靠的UDP首部和數據而設計汗侵。

6.TCP首部格式

屏幕快照 2019-02-14 上午9.48.26.png

TCP中沒有表示包長度和數據長度的字段幸缕。可由IP層獲知TCP的包長由TCP的包長可知數據的長度晰韵。

  • 源端口號
    表示發(fā)送端端口號发乔,字段長16位
  • 目標端口號
    表示接收端端口號,字段長度16位
  • 序列號
    字段長32位雪猪。序列號是指發(fā)送數據的位置栏尚。每發(fā)送一次數據,就累加一次該數據字節(jié)數的大小只恨。
  • 確認應答號
    確認應答號字段長度32位译仗。是指下一次應該收到的數據的序列號。實際上官觅,它是指已收到確認應答號減一為止的數據纵菌。發(fā)送端收到這個確認應答以后可以認為在這個序號以前的數據都已經被正常接收。
  • 數據偏移
    該字段表示TCP所傳輸的數據部分應該從TCP包的哪個位開始計算休涤,當然也可以把它看作TCP首部的長度产艾。該字段長4位,單位為4字節(jié)滑绒。
  • 保留
    該字段主要是為了以后擴展時使用,其長度為4位隘膘。
  • 控制位
    字段長位8位疑故,每一位從左至右分別為CWR、ECE弯菊、URG纵势、ACK、PSH、RST钦铁、SYN软舌、FIN。這些控制標志也叫做控制位牛曹。
    1.CWR標志與后面的ECE標志都用于IP首部的ECN字段佛点。ECE標志為1時,則通知對方已將擁塞窗口縮小黎比。
    2.ECE標志表示ECN-Echo.置為1會通知通信對方超营,從對方到這邊的網絡有擁塞。在收到數據包的IP首部中ECN為1時將TCP首部中的ECE置為1阅虫。
    3.URG該位為1時演闭,表示包中有需要緊急處理的數據。對于需要緊急處理的數據颓帝,會在后面的緊急指針中再進行解釋米碰。
    4.ACK該位為1時,確認應答的字段變?yōu)橛行Ч撼恰CP規(guī)定處理最初建立連接時的SYN包之外該位必須設置為1吕座。
    5.PSH該位為1時,表示需要將收到的數據立即傳給上層應用協議工猜。PSH為0時米诉,則不需要立即傳而是先進行緩存。
    6.RST該位為1時表示TCP連接中出現異常必須強制斷開連接篷帅。
    7.SYN用于建立連接史侣。SYN為1表示希望建立連接,并在其序列號的字段進行序列號初始值的設定魏身。
    8.FIN該位為1時惊橱,表示今后不會再有數據發(fā)送,希望斷開連接箭昵。當通信結束希望斷開連接時税朴,通信雙方的主機之間就可以相互交換FIN位置為1的TCP段。
  • 窗口大小
    該字段長為16位家制。用于通知從相同TCP首部的確認應答號所指位置開始能夠接收的數據大小正林。
  • 校驗和
    TCP的校驗和與UDP相似,區(qū)別在于TCP的校驗和無法關閉颤殴。
  • 緊急指針
    該字段長為16位觅廓。只有在URG控制位為1時有效。該字段的數值表示本報文段中緊急數據的指針涵但。
  • 選項
    選項字段用于提高TCP的傳輸性能杈绸√可以根據數據偏移進行控制,所以其長度最大為40字節(jié)瞳脓。
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末塑娇,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子劫侧,更是在濱河造成了極大的恐慌埋酬,老刑警劉巖厘贼,帶你破解...
    沈念sama閱讀 212,884評論 6 492
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件漆羔,死亡現場離奇詭異,居然都是意外死亡验靡,警方通過查閱死者的電腦和手機劲弦,發(fā)現死者居然都...
    沈念sama閱讀 90,755評論 3 385
  • 文/潘曉璐 我一進店門耳标,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人邑跪,你說我怎么就攤上這事次坡。” “怎么了画畅?”我有些...
    開封第一講書人閱讀 158,369評論 0 348
  • 文/不壞的土叔 我叫張陵砸琅,是天一觀的道長。 經常有香客問我轴踱,道長症脂,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,799評論 1 285
  • 正文 為了忘掉前任淫僻,我火速辦了婚禮诱篷,結果婚禮上,老公的妹妹穿的比我還像新娘雳灵。我一直安慰自己棕所,他們只是感情好,可當我...
    茶點故事閱讀 65,910評論 6 386
  • 文/花漫 我一把揭開白布悯辙。 她就那樣靜靜地躺著琳省,像睡著了一般。 火紅的嫁衣襯著肌膚如雪躲撰。 梳的紋絲不亂的頭發(fā)上针贬,一...
    開封第一講書人閱讀 50,096評論 1 291
  • 那天,我揣著相機與錄音拢蛋,去河邊找鬼坚踩。 笑死,一個胖子當著我的面吹牛瓤狐,可吹牛的內容都是我干的瞬铸。 我是一名探鬼主播,決...
    沈念sama閱讀 39,159評論 3 411
  • 文/蒼蘭香墨 我猛地睜開眼础锐,長吁一口氣:“原來是場噩夢啊……” “哼嗓节!你這毒婦竟也來了?” 一聲冷哼從身側響起皆警,我...
    開封第一講書人閱讀 37,917評論 0 268
  • 序言:老撾萬榮一對情侶失蹤拦宣,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后信姓,有當地人在樹林里發(fā)現了一具尸體鸵隧,經...
    沈念sama閱讀 44,360評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 36,673評論 2 327
  • 正文 我和宋清朗相戀三年意推,在試婚紗的時候發(fā)現自己被綠了豆瘫。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,814評論 1 341
  • 序言:一個原本活蹦亂跳的男人離奇死亡菊值,死狀恐怖外驱,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情腻窒,我是刑警寧澤昵宇,帶...
    沈念sama閱讀 34,509評論 4 334
  • 正文 年R本政府宣布,位于F島的核電站儿子,受9級特大地震影響瓦哎,放射性物質發(fā)生泄漏。R本人自食惡果不足惜柔逼,卻給世界環(huán)境...
    茶點故事閱讀 40,156評論 3 317
  • 文/蒙蒙 一蒋譬、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧卒落,春花似錦羡铲、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,882評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至腰湾,卻和暖如春雷恃,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背费坊。 一陣腳步聲響...
    開封第一講書人閱讀 32,123評論 1 267
  • 我被黑心中介騙來泰國打工倒槐, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人附井。 一個月前我還...
    沈念sama閱讀 46,641評論 2 362
  • 正文 我出身青樓讨越,卻偏偏與公主長得像两残,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子把跨,可洞房花燭夜當晚...
    茶點故事閱讀 43,728評論 2 351

推薦閱讀更多精彩內容

  • 協議基礎 協議就是計算機之間通過網絡實現通信時實現所達成的一種“約定”人弓,這種約定使得那些由不同廠商的設備,不同的C...
    d9fc24a0c9a9閱讀 2,353評論 0 6
  • 圖解TCP_IP 第五版 第一章 網絡基礎知識 1着逐、OSI參考模型(7層): 2崔赌、七層通信: 應用層:(寫入數...
    妮妮愛布閱讀 2,218評論 0 0
  • 個人認為,Goodboy1881先生的TCP /IP 協議詳解學習博客系列博客是一部非常精彩的學習筆記耸别,這雖然只是...
    貳零壹柒_fc10閱讀 5,051評論 0 8
  • 一健芭、網絡基礎知識 1. OSI 參考模型 OSI 模型中,每個分層都接受由它下一層所提供的特定服務秀姐,并且負責為自己...
    SeanCST閱讀 1,649評論 0 6
  • 終于來到了傳輸層,這個面試問的最多了?? 傳輸層 TCP/IP中有兩個具有代表性的傳輸層協議,分別為: TCP: 提...
    洛洛愛吃肉閱讀 633評論 0 1