一萌抵、傳輸層的功能

1.1 OSI和DoD模型

1

• TCP（Transmission Control Protocol）舔稀，傳輸控制協(xié)議乳丰，這是一種可靠安全的傳輸協(xié)議。一般如果一個文件在傳輸時需要分段内贮，在需要使用此協(xié)議产园。此協(xié)議會建立一個會話，實現(xiàn)可靠傳輸贺归。而且還有流量控制功能淆两。可以使用命令netstat -nb查看會話拂酣。
• UDP（User Data Protocol）秋冰，用戶數(shù)據(jù)報協(xié)議。此協(xié)議一般用在文件只需要一個數(shù)據(jù)報就可以傳輸完的情況婶熬，不需要分段剑勾，不需要建立會話埃撵，也不需要流量控制，是一種不可靠的傳輸虽另≡萘酰可用于多播和廣播。

1.2 傳輸層協(xié)議和應用層協(xié)議之間的關系

2

• 查看服務偵聽的端口netstat -anb
• 產(chǎn)看建立的會話netstat -n
• 查看建立會話的進程netstat -nb
• 測試連接遠程計算機某個端口是否打開telnet 192.168.80.100 3389

1.3 傳輸層功能

為相互通信的應用進程提供了邏輯通信

3

1.4 傳輸層的端口

4

• TCP的端口：使用一個16位端口號進行標志，具有本地意義孝偎，即端口號只是為了標志本計算機應用層中的各進程访敌。在Internet中不同計算機的相同端口號是沒有聯(lián)系的。

分類：

• 熟知的端口衣盾，數(shù)值一般為0-1023

FTP:21
telnet:23
SMTP:25
PoP3:110
DNS:53
HTTP:80
https:443
RDP:3389

• 登記端口號寺旺，數(shù)值為1024-49151
• 客戶端口號，數(shù)值為49152-65535势决，使用命令netstat -n | find "ESTABLISHED"

二阻塑、傳輸層協(xié)議UDP和TCP

2.1 UDP協(xié)議

2.1.1 主要特點

此協(xié)議是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接果复；使用盡最大努力交付陈莽，即不保證可靠交付，同時也不使用擁塞控制；是面向報文的走搁，沒有擁塞控制独柑，很適合多媒體通信的要求；支持一對一私植、一對多忌栅、多對一和多對多的交互通信；首部開銷小曲稼，只有八個字節(jié)。域名解析就是使用此協(xié)議者春。

2.1.2 UDP協(xié)議

5

6

2.2 TCP協(xié)議

2.2.1 概述

此協(xié)議是面向連接的傳輸層協(xié)議，每一條TCP連接只能有兩個端點（endpoint）读第，每一條TCP連接只能是點對點的（一對一）曙博，此協(xié)議提供可靠交付的服務，提供全雙工通信怜瞒，面向字節(jié)流父泳。

2.2.2 TCP的連接

此協(xié)議把連接作為最基本的抽象，每一條TCP連接有兩個端點吴汪，連接的端點不是主機惠窄，不是主機的IP地址，不是應用程序漾橙，也不是傳輸層的協(xié)議端口杆融。TCP連接的端點叫做套接字（socket）。端口號拼接到IP地址即構成了套接字霜运。socket=(IP：port)脾歇，每一條TCP連接唯一的被通信兩端的兩個端口（即兩個套接字）所確定。

2.2.3 可靠傳輸原理

7

• 確認丟失和確認遲到
  

  8
  
  說明：當發(fā)送端發(fā)送一個數(shù)據(jù)后，接收端接收到了光绕，但是反饋的數(shù)據(jù)報丟了诞帐，那么發(fā)送端則重新發(fā)送前面的數(shù)據(jù)（認為沒有收到），此時發(fā)送端收到之后將其丟棄慧起，再次發(fā)送反饋的數(shù)據(jù)完慧。這種情況即確認丟失屈尼。而確認遲到是指在上面的情況中，反饋的消息不是丟失了演熟，而是發(fā)送太慢，導致發(fā)送端以為丟失了大溜，然后重傳，于是接收端繼續(xù)丟棄重復數(shù)據(jù)報付材，并發(fā)送一個反饋消息厌衔。

• 使用上述的確認和重傳機制富寿，我們就可以在不可靠的傳輸網(wǎng)絡上實現(xiàn)可靠的通信。這種可靠傳輸協(xié)議通常稱為自動重傳請求ARQ（Automatic Repeate reQuest）。ARQ標明重傳的請求是自動進行的窖贤。接收方不需要請求發(fā)送方重傳某個出錯的分組。

• 信道利用率
  停止等待協(xié)議的優(yōu)點是簡單滤蝠，但缺點是信道利用率太低。
  

  8
  
  說明：從圖中我們可以看到發(fā)送的時間為Td览闰，而一個往返的總時間為（Td+RTT+Ta）压鉴。所以信道利用率U=Td/(Td+RTT+Ta)太低击蹲。那如果要向提高信道利用率歌豺，可選的辦法有提高Td类咧，即流水線傳輸：
  
  9
  
  這種情況下，就是讓發(fā)送端一直發(fā)送數(shù)據(jù)血巍，不要等待述寡。那么這種情況下如何實現(xiàn)可靠傳輸呢？

• 連續(xù)ARQ協(xié)議
  

  10
  
  說明：如上有12個數(shù)據(jù)報螟炫，而發(fā)送窗口為5標明每次可以連續(xù)發(fā)送5個數(shù)據(jù)報。發(fā)送5個數(shù)據(jù)報之后等待然评，此時如果收到第一個數(shù)據(jù)報的反饋信息碗淌，那么發(fā)送窗口向后移動亿眠，發(fā)送第六個數(shù)據(jù)報缕探，依次類推爹耗。同時每接受到一個數(shù)據(jù)報的反饋消息倦始，則此數(shù)據(jù)報就可以從緩存中刪除了鞋邑。當然這種方式在確認反饋消息的時候效率不高枚碗，可以使用累積確認肮雨。

• 累積確認
  接收方一般采用累計確認怨规。優(yōu)點是容易實現(xiàn)波丰，信道利用率高；缺點是不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息媚赖。累積確認就是在發(fā)送時，首先發(fā)送多個數(shù)據(jù)報捻撑，比如此時發(fā)送的五個數(shù)據(jù)報中顾患，第三個數(shù)據(jù)報沒有收到江解，此此時就會反饋給接收端已經(jīng)收到第二個數(shù)據(jù)報的信息鳖枕，而接收端則會從第三個數(shù)據(jù)報開始宾符，進行重發(fā)（當然也包括第四個和第五個數(shù)據(jù)報魏烫，雖然它們是發(fā)送成功的）。

2.2.4 TCP報文段的首部格式

11

• 標記位URG=1表示在傳輸數(shù)據(jù)報時不需要排隊双絮，不管緩存中有多少數(shù)據(jù)。
• 標記位ACK=0表示確認號是無效的（在接收數(shù)據(jù)后其值為1焚挠，但是如果還沒有發(fā)送數(shù)據(jù)宣蔚，那當然就是0）挟鸠。
• 標記位SYN=1表示同步艘希，也就是這個數(shù)據(jù)報的發(fā)送需要建立一個會話。
• 標志位PSH=1表示接收端在將接收到的數(shù)據(jù)組裝的時候不排序营袜。
• 標志位RST=1表示TCP會話出現(xiàn)了嚴重的問題，需要重新建立連接跪另。比如我們對某個打開但是會沒有完全打開時，點擊關閉嘲驾，則會出現(xiàn)這種情況。
• 標志位FIN=1表示數(shù)據(jù)傳輸已經(jīng)完畢了榕暇，需要釋放連接。

窗口占兩個字節(jié)筒饰，比如此時有兩個主機A业栅、B谬晕。A在發(fā)送數(shù)據(jù)時可以緩存的字節(jié)為65530個字節(jié)碘裕，于是需要將這個窗口發(fā)送給B，看B的接收緩存是不是能夠滿足最大的窗口字節(jié)攒钳，需要統(tǒng)一帮孔。同樣，當B向A發(fā)送數(shù)據(jù)時也需要統(tǒng)一窗口。
緊急指針只有在標志位URG=1的情況下才有作用文兢，這表示TCP報文中數(shù)據(jù)部分中前面的多少個字節(jié)需要緊急處理晤斩。
選項中有很多信息，比如最大TCP報文的長度為多少個字節(jié)，是不是支持選擇性確認SACK茫负。如果不夠四個字節(jié)則會進行填充勉失，以達到四個字節(jié)徒蟆。

2.2.5 TCP如何實現(xiàn)可靠傳輸

• 以字節(jié)為單位的滑動窗口技術
  
  12
  
  說明：首先注意發(fā)送窗口和接收窗口必須一致绷落，這里使用前面講到的停止等待協(xié)議。如果A向B發(fā)送數(shù)據(jù)撇寞，在不出錯的情況下鸟缕，比如將最前面的20個字節(jié)分成了三段番甩，1~3、4~7、8~10追迟、11~20進行發(fā)送厢绝，當B還沒有收到相關數(shù)據(jù)時口予，A是不能發(fā)送第21個字節(jié)及之后的數(shù)據(jù)的，此時如果A沒有收到B的反饋浮声，則A緩存中的數(shù)據(jù)是不能刪除的，窗口也是不能移動的嫌变，當B反饋確認號為8時，則A緩存中，之前的數(shù)據(jù)就可以刪除了公黑，發(fā)送第八個字節(jié)后的數(shù)據(jù)，同時A的窗口可以向后移動了，可以發(fā)送21~27的數(shù)據(jù)了，而B中就可以將1~7個字節(jié)提取出去了闷沥，緩存中就可以刪除苹祟，同時B的窗口也會向后移動体谒，依次類推贮聂。但是如果在傳輸過程中8~10這一段數(shù)據(jù)丟失了甘穿，其他段都接收到了妨托，于是會通過前面講的選擇性確認SACK來告訴A哪一段缺失了，要求重發(fā)判族。注意君躺，不是一收到數(shù)據(jù)就發(fā)送確認侮邀，而是發(fā)現(xiàn)接收的數(shù)據(jù)不是連續(xù)的才發(fā)送確認號。

2.2.6 超時重傳時間的選擇

TCP每發(fā)送一個報文段贝润，就對這個報文段設置一次計時器绊茧。只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段打掘。

13

2.2.7 TCP的流量控制

用于解決發(fā)送端和接收端處理數(shù)據(jù)能力不同的問題尊蚁。比如A發(fā)送數(shù)據(jù)很快亡笑，但是B的處理能力有限，很快A發(fā)送的數(shù)據(jù)就將B的緩存占滿了横朋，不能再接收數(shù)據(jù)了仑乌，比如先進行一部分處理才能再次接收，于是B需要向A告知這一點琴锭，這就是流量控制晰甚。在傳輸數(shù)據(jù)的過程中會根據(jù)自己的處理能力實時反饋相應的窗口，如果不能處理數(shù)據(jù)决帖，則將窗口設置為零厕九，先處理一部分數(shù)據(jù)之后再反饋相關信息，當接收端表示能夠繼續(xù)接收數(shù)據(jù)了地回，于是向發(fā)送端發(fā)送新的窗口和確認號止剖，但是這個反饋信息如果丟失了怎么辦？這里發(fā)送端會定時的發(fā)送窗口測定的數(shù)據(jù)報來檢查接收端的窗口落君。

2.2.8 TCP擁塞控制

• 出現(xiàn)資源擁塞的條件：對資源需求的綜合大于可用資源穿香。

• 擁塞控制是一個全局性的過程，涉及到所有的主機绎速、所有的路由器皮获，以及與降低網(wǎng)絡傳輸性能有關的所有因素。

• 流量控制往往指在給定的發(fā)送端和接收端之間的點對點通信量的控制纹冤，它所要做的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率洒宝，以便使接收端來得急接收购公。

• 擁塞控制所起的作用
  

  14
  
  說明：比如此時網(wǎng)路中最大的處理能力為100M，但是現(xiàn)在各個主機不管雁歌，都向其發(fā)送數(shù)據(jù)宏浩，使得發(fā)送的數(shù)據(jù)達到500M，此時可能路由器忙不過來了靠瞎，可能只能處理了10M的數(shù)據(jù)比庄，或者還可能死機，導致吞吐量極大的降低乏盐，這就是擁塞佳窑。而TCP都會有一個擁塞控制的作用，一般如果發(fā)現(xiàn)網(wǎng)絡較忙時父能，就會協(xié)調傳輸速度神凑，可能此時發(fā)送了90M的數(shù)據(jù)，但是網(wǎng)絡正確處理了85個何吝，此時網(wǎng)絡的吞吐量卻是很高的溉委。

• 慢開始和擁塞避免
  發(fā)送方維持擁塞窗口cwnd（congestion window）。發(fā)送放控制擁塞窗口的原則是：
  1爱榕、只要網(wǎng)絡沒有出現(xiàn)擁塞瓣喊，擁塞窗口就再增大一些，以便把更多的分組發(fā)送出去
  2呆细、只要網(wǎng)絡出現(xiàn)擁塞，擁塞窗口就減小一些八匠，以減少注入到網(wǎng)絡中的分組數(shù)絮爷。
  慢開始算法的原理：
  

  15
  
  說明:可以看到開始的時候只是發(fā)送了一個數(shù)據(jù)報坑夯，之后慢慢的增加發(fā)送速度，當然每次都會檢查網(wǎng)路傳輸?shù)那闆r，在網(wǎng)絡暢通的情況下才會增加發(fā)送速度蹋偏，反之則降低發(fā)送速度黎棠。
  
  16
  
  說明：剛開始的時候速度增長是以2的倍數(shù)增加，當達到慢開始門限后关翎，則是每次增加1的速度增加葬凳。當速度達到24時發(fā)現(xiàn)出現(xiàn)了擁塞昌简，于是則要計算一個新的慢開始門限，即此時速度的一般12樊诺，如果還是擁塞，則繼續(xù)計算新的慢開始門限音同，之后則又開始慢慢增長词爬，同時注意，此時的慢開始門限就是12了权均，而不是最開始的16顿膨。
  注意：擁塞避免并非指完全能夠避免擁塞。而是在說在擁塞避免階段把擁塞窗口控制為按線性規(guī)律增長叽赊，使網(wǎng)絡比較不容易出現(xiàn)擁塞恋沃。這是最開始的擁塞控制方法，之后又出現(xiàn)了新的方法必指，即快重傳和快恢復囊咏。

• 快重傳和快恢復
  快重傳：比如此時發(fā)送端向接收端發(fā)送了1、2塔橡、3梅割、4、5這樣一個數(shù)據(jù)段葛家，但是在發(fā)送的過程中第三個數(shù)據(jù)丟失了户辞，根據(jù)之前講的累積確認，此時還是必須等到第4癞谒、5個數(shù)據(jù)接收到之后才發(fā)送確認號底燎，但是要知道只要收到的數(shù)據(jù)為1、2弹砚、4双仍，發(fā)送端就已經(jīng)知道丟包了，于是此時會向發(fā)送端連續(xù)發(fā)送三個相同的確認號迅栅，讓其發(fā)送第三個數(shù)據(jù)報殊校，這就是快重傳晴玖。
  快恢復：如上读存，丟失第三個數(shù)據(jù)報可能是因為擁塞，于是發(fā)送端會降低擁塞窗口呕屎，比如此時減小到了1让簿，但是對于接收端發(fā)送的三個相同的確認號，此時卻都收到了秀睛，這標明此時網(wǎng)絡又是很好的尔当，不再擁塞了，此時就不會向之前那樣先指數(shù)再線性這樣增長了，而是讓擁塞窗口快速恢復到12椭迎，然后線性增長锐帜，這是相對慢開始來說的。
  

  17

• 發(fā)送窗口的實際上限值
  發(fā)送方的發(fā)送窗口的上限值應當取為接收方窗口和擁塞窗口這兩個變量中較小的一個畜号，即應按一下公式確定：
  發(fā)送窗口的上限值= Min{rwnd, cwnd}

2.2.9 TCP的運輸連接管理

傳輸連接有三個階段缴阎，即：連接建立、數(shù)據(jù)傳送和連接釋放简软。TCP連接的建立都是采用客戶服務器方式蛮拔。主動發(fā)起連接建立的應用進程叫客戶（client），被動等待連接建立的應用進程叫做服務器（server）痹升。

• 三次握手建立TCP連接
  

  18
  
  說明：建立連接個過程中首先客戶端發(fā)送一個同步數(shù)據(jù)報建炫，此時同步標記SYN=1，標志位ACK=0疼蛾，序號seq=x肛跌。服務器接受到這樣一個數(shù)據(jù)報之后就知道這是一個主動發(fā)起連接的數(shù)據(jù)報，此時服務器發(fā)送一個數(shù)據(jù)報据过，其中SYN=1惋砂，標志位ACK=1，序號seq=y绳锅，由服務器指定西饵，確認號ack=x+1，讓客戶端發(fā)送第x+1個字節(jié)鳞芙，接下來眷柔，客戶端就再次發(fā)送確認數(shù)據(jù)報，此時就沒有同步標記了原朝。在前兩次數(shù)據(jù)傳輸中已經(jīng)足夠確定網(wǎng)絡是否暢通驯嘱，那么為什么還要發(fā)第三次確認數(shù)據(jù)？這是因為當客戶端發(fā)起請求喳坠，而這個請求可能在網(wǎng)路傳輸中傳輸較慢鞠评，一直沒有到達服務器，于是客戶端再次發(fā)出請求壕鹉，而此時請求很快便到達剃幌，而此次會話在傳輸任務完成之后會話就斷開了，然而晾浴，第一次發(fā)起的請求數(shù)據(jù)報在之后又被服務器接受到了负乡，服務器以為這是客戶端又發(fā)起的請求，于是就向客戶端發(fā)出確認脊凰，然而可能此時客戶端不需要建立連接抖棘，于是便不理睬這個確認，于是服務器就一直等待客戶端的確認且發(fā)出數(shù)據(jù)，這樣資源便被浪費了切省，這種情況多的時候服務器就可能宕機最岗。而在三次握手方式中，服務器如果接受到第三次確認后朝捆，那么就人為自己發(fā)出的確認信息有用仑性，于是就開始進行數(shù)據(jù)傳輸了，如果等了一段時間右蹦，沒有等到第三次確認诊杆，那么就釋放這個連接了。

• 三次握手建立TCP連接的各狀態(tài)
  

  19
  
  說明：客戶端發(fā)出第一次請求之后就變成了SYN-SENT狀態(tài)何陆，而服務器收到之前是LISTEN狀態(tài)晨汹，收到之后變?yōu)?code>SYN-RCVD狀態(tài)，客戶端收到反饋后贷盲，發(fā)出請求淘这，狀態(tài)變?yōu)?code>ESTABLISHED，而服務器收到之后變?yōu)?code>ESTABLISHED巩剖。

• TCP的連接釋放
  

  20
  
  
  21
  
  
  22
  
  
  23
  
  說明：連接過程如上铝穷。

• 連接釋放過程中的狀態(tài)
  

  24
  
  說明：連接必須經(jīng)過2MSL的時間才真正釋放，因為最后一次客戶端向服務器確認的數(shù)據(jù)可能會丟失佳魔，所以需要等待曙聂。