傳輸層與應(yīng)用層

1、傳輸層與應(yīng)用層 第1頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日1、理解TCP/IP傳輸層傳輸層提供從源主機(jī)到目的主機(jī)的傳輸服務(wù)。功能：分段和重組上層應(yīng)用程序發(fā)送的數(shù)據(jù)，并在端點(diǎn)（源主機(jī)&目的主機(jī)）之間進(jìn)行傳輸。主要協(xié)議：TCP：面向連接UDP：無連接第2頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日服務(wù)質(zhì)量（QOS）通常用來描述傳輸層。工作在本層的主要協(xié)議是面向連接的TCP。TCP的主要功能是：可靠而又準(zhǔn)確地傳輸并控制源主機(jī)和目的主機(jī)之間的信息流?？煽啃裕和ㄟ^序號和確認(rèn)機(jī)制來保證流控制：通過滑動窗口機(jī)制來保證第3頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日流

2、控制TCP傳輸控制協(xié)議發(fā)送數(shù)據(jù)分段時，可以保證數(shù)據(jù)的完整性。確保數(shù)據(jù)完整性的一種方法就是流控制。流控制可以避免發(fā)送數(shù)據(jù)的主機(jī)使接收主機(jī)緩存溢出的問題。第4頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日可靠性為了獲得可靠的數(shù)據(jù)傳輸，正在通信的終端系統(tǒng)之間必須維護(hù)一個面向連接的關(guān)系?？煽康膫鬏斖ㄟ^下列方法實(shí)現(xiàn):確保傳送的數(shù)據(jù)分段要向發(fā)送方確認(rèn)。重傳所有未確認(rèn)的數(shù)據(jù)分段。在目的端將數(shù)據(jù)分段按正確的順序重組。提供避免和控制擁塞的機(jī)制。第5頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日會話的建立、維持和終止傳輸層的其中一個功能就是與其對等系統(tǒng)建立面向連接的會話。第6頁，共27頁，20

3、22年，5月20日，22點(diǎn)1分，星期日會話建立過程發(fā)送方請求同步接受方接收請求，并同步反方向上的連接參數(shù)發(fā)送方發(fā)送確認(rèn)信息雙方建立連接，數(shù)據(jù)開始傳輸?shù)?頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日會話維持-數(shù)據(jù)傳輸過程在傳輸過程中，兩臺主機(jī)還需要繼續(xù)通過協(xié)議軟件的通信來驗(yàn)證數(shù)據(jù)是否被正確接收。數(shù)據(jù)傳輸過程中，可能有擁塞發(fā)生，導(dǎo)致數(shù)據(jù)的丟失。右圖為擁塞發(fā)生時的處理辦法。第8頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日會話終止數(shù)據(jù)傳輸完成后，發(fā)送端主機(jī)發(fā)送一個標(biāo)識數(shù)據(jù)傳輸結(jié)束的指示器。接收端主機(jī)在數(shù)據(jù)傳輸完成后確認(rèn)數(shù)據(jù)傳輸結(jié)束，連接終止。第9頁，共27頁，2022年，5月2

4、0日，22點(diǎn)1分，星期日TCP的三次握手過程第10頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日2、滑動窗口在大多數(shù)可靠的、面向連接的數(shù)據(jù)傳輸?shù)幕拘问街?，?shù)據(jù)分組必須以與發(fā)送時相同的順序傳輸?shù)浇邮斩?。任何的?shù)據(jù)分段丟失、損壞或者接收時重復(fù)、亂序都會導(dǎo)致協(xié)議出錯?；镜慕鉀Q方法：讓接收方在接收每一個數(shù)據(jù)分段后都進(jìn)行確認(rèn)。第11頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日如下圖所示，發(fā)送方在發(fā)送每一個數(shù)據(jù)分段后都要等候確認(rèn)信息，然后再發(fā)送，這樣吞吐量很低。在沒有收到確認(rèn)的情況下，窗口是允許發(fā)送方發(fā)送的數(shù)據(jù)分組的個數(shù)。能否發(fā)送更多的數(shù)據(jù)分組呢？第12頁，共27頁，2022年，

5、5月20日，22點(diǎn)1分，星期日發(fā)送方接收方發(fā)送1接收1發(fā)送ACK2接收ACK2發(fā)送2接收3發(fā)送ACK3接收ACK3發(fā)送3接收2發(fā)送ACK4第13頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日TCP使用期待確認(rèn)，確認(rèn)號就是所期待接收的下一個字節(jié)?；瑒哟翱谥冈赥CP會話過程中窗口大小是動態(tài)協(xié)商的。滑動窗口是一個流控機(jī)制，要求源設(shè)備在向目的設(shè)備發(fā)送一定數(shù)量的數(shù)據(jù)之后接收一個確認(rèn)。第14頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日發(fā)送方接收方發(fā)送1接收2發(fā)送ACK4接收ACK4發(fā)送ACK7接收ACK7發(fā)送2發(fā)送3接收1接收3發(fā)送4發(fā)送5發(fā)送6接收5接收4接收6第15頁，共27頁，

6、2022年，5月20日，22點(diǎn)1分，星期日窗口大小為3，表示源設(shè)備可以發(fā)送3個字節(jié)到目的設(shè)備，然后等待一個確認(rèn)。目的設(shè)備接收到這3個字節(jié)后，向源設(shè)備發(fā)送一個確認(rèn)，然后，源設(shè)備就可以繼續(xù)傳輸下面的3個字節(jié)了。如果在傳輸過程中，目的設(shè)備沒有接收到這3個字節(jié)，則不會返回確認(rèn)。由于源設(shè)備沒有收到確認(rèn)，它知道這些字節(jié)需要重傳，且傳輸?shù)乃俾蕰档汀５?6頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日TCP窗口的大小是可變的。每一個確認(rèn)都包含著一個表示接收方能夠接收多少字節(jié)的窗口信息。通常，發(fā)送方和接收方的窗口大小是一樣的。第17頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日確認(rèn)可靠的傳

7、輸保證數(shù)據(jù)流能從一臺主機(jī)通過數(shù)據(jù)鏈路傳遞到另一臺主機(jī)而沒有數(shù)據(jù)重復(fù)或丟失。主動確認(rèn)及重傳是一種保證數(shù)據(jù)可靠傳輸?shù)募夹g(shù)。發(fā)送方保持所發(fā)送的每一個數(shù)據(jù)分組的記錄并等待確認(rèn)。發(fā)送方還會在發(fā)送一個數(shù)據(jù)分段時啟動一個定時器，如果定時器到期時確認(rèn)還沒有收到，就會重傳該數(shù)據(jù)分段。第18頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日TCP數(shù)據(jù)分段格式TCP是一種面向連接的傳輸層協(xié)議，能提供可靠的數(shù)據(jù)傳輸。在綿亙向連接的環(huán)境中，開始傳輸數(shù)據(jù)之前，端點(diǎn)之間先要建立連接。TCP負(fù)責(zé)將消息拆分成數(shù)據(jù)分段，重傳丟失的數(shù)據(jù)分段并將數(shù)據(jù)分段在目的主機(jī)重組成消息。TCP在端用戶之間建立了一條虛電路，提供端到端的服務(wù)

8、。第19頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日以下協(xié)議使用TCP：文件傳輸協(xié)議FTP超文本傳輸協(xié)議HTTP簡單郵件傳輸協(xié)議SMTP第20頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日TCP數(shù)據(jù)分段格式：第21頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日UDPUDP是無連接的傳輸協(xié)議UDP是一種簡單協(xié)議，它交換數(shù)據(jù)報而沒有確認(rèn)機(jī)制或傳輸保證。對于錯誤處理和重傳機(jī)制必須由上層協(xié)議來完成。以下協(xié)議使用UDP簡單文件傳輸協(xié)議TFTP簡單網(wǎng)絡(luò)管理協(xié)議SNMP動態(tài)主機(jī)配置協(xié)議DHCP第22頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日UDP數(shù)據(jù)分段格式：第23頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日TCP與UDP端口號端口號用來跟蹤網(wǎng)絡(luò)上同一時間的不同會話。TCP和UDP都使用端口號向上層傳遞信息。一個IP地址和一個端口號組合在一起稱為套接字。知名服務(wù)的端口號由Internet地址授權(quán)委員會控制管理。范圍：1024以下為知名端口號，1024以上為動態(tài)分配端口號第24頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日第25頁，共27頁，2022年，5月20日，22點(diǎn)1分，星期日3、TCP/IP應(yīng)用層第26頁，