新聞中心

        EEPW首頁 > 嵌入式系統 > 設計應用 > TCP/IP傳輸層協議

        TCP/IP傳輸層協議

        作者: 時間:2016-11-30 來源:網絡 收藏
        當在Windows XP中同時運行多個網絡應用程序時,每個應用程序都會產生自己的
        數據流,傳輸層是用什么方法區分不同應用程序的數據流呢?
        在數據流被分段(分組)以后,傳輸層依靠什么來重新組裝這些數據流呢?
        如果某個數據段在傳輸過沖中丟失了或重復了,可靠的傳輸協議依據什么去要求
        重傳這些數據或丟棄多余的數據呢?
        帶著這些問題,下面來談論傳輸層所提供的服務。
        傳輸層的主要功能是分割并重新組裝上層提供的數據流,為數據流提供端對端的
        傳輸服務。
        在TCP/IP協議中,有兩個傳輸層協議:傳輸控制協議(TCP)和用戶數據包協議(UDP)
        TCP是一個可靠的面向連接的協議,UDP是不可靠的或非連接的協議。這種面向連接和
        非連接的通信方式的區別,就像打電話和寄明信片一樣。打電話的雙方在正式通話之
        前都會說“喂”,確定對方在線以后才開始通話,會話結束時都要說“再見”,然后
        才掛下電話。而寄明信片卻沒有這種機制,寄出去了但不管對方是否收到。
        端口號
        每個應用程序都會產生自己的數據流,這些數據流可以把目標主機上相應的服務程序
        看作自己的目的地,對于傳輸層來說,它只需要知道目標主機上的哪個服務程序來響
        應這應用程序,而不需要知道這個服務程序具體是干什么的。因此,傳輸層使用一個
        抽象的端口號來標識這些應用程序和服務程序。
        端口號的功能及應用特點
        端口號用來跟蹤網絡間同時發生的不同會話。TCP和UDP可以同時接收多個應用程序送
        來的數據流,用端口號來區分他們,然后送給適當的應用程序處理。這時多路分解技
        術的體現,它可以確保正確的用戶程序收到正確的數據。因此,每個應用程序發送數
        據前都會與操作系統進行協商,獲得響應的源端口號和目標端口號。
        在主機發送應用程序的數據之前,都必須確認端口號,如何分配這些端口號呢?一般
        有兩種情況,使用中央管理機構統一分配的端口號和使用動態綁定。
        使用中央管理機構統一分貝的端口號。應用程序的開發者們都默認在RFC1700中定義的
        特殊端口號,在進行軟件設計時,都要遵從RFC1700中定義的規則,不能隨便使用已經
        定義的端口號,那么系統將在一個特定的取值范圍隨機地為應用程序分配一個端口號。
        例如,任何Telnet應用中的會話都應用標準端口號23。
        使用動態綁定。如果一個應用程序的會話沒有涉及到特殊的端口號,那么系統將在一個
        特定的取值方位內隨機地為應用程序分配一個端口號。在應用程序進行通信以前,如果
        不知道對方的端口號,就必須發送請求以獲得對方的端口號。
        RFC(Request for Comments,征求意見資料)是一個資料系列,始創于1969年,其中描述
        了關于Internet的協議實驗,并不是所有RFC資料都是描述Internet標準的,但所有
        Internet標準都是作為RFC資料編寫的。RFC資料中提交的協議都是Internet研究人員和
        開發人員根據自己的情況建立、修改和擴充的,因此不同于CCITT(國際電報電話咨詢委
        員會)和ANSI(美國國家標準協會)等組織所倡導的并經過正式評審和標準化處理的協議
        Internet RFC有3種狀態:Proposed(提案)、Draft(草案)和Full(標準)。
        TCP/IP的設計者們采用一種混合方式實現端口號地址的管理,終端系統利用源系統端口
        號來選擇合適的應用程序,但是源系統的源端口號由源系統動態分配。
        常用的端口號介紹
        目前的端口號的分配情況大致如下:
        小于255的端口號用于公共應用
        255~1023是特定供應商應用程序的注冊端口號
        高于1023的端口號未作規定。
        常用應用層協議或應用程序端口號
        UPP
        TCP
        FTP
        -
        21
        Telnet
        -
        23
        SMTP
        -
        25
        DNS
        53
        -
        TFTP
        69
        -
        SNMP
        161
        -
        HTTP
        -
        80
        DHCP
        -
        67
        RPC(遠程調用)
        -
        135

        下面舉例說明端口號的使用過程。
        主機A要Telnet到主機B。主機A首先向TCP請求一個可用端口,假如TCP分配一個為1088
        的端口,主機A將目標端口號置為23。A和B通信以后,B看到A過來的端口號為23,就知
        道這時Telnet應用,它就會為此創建一個Telnet會話。
        假如同一系統中有多個Telnet用戶,會發生什么情況呢?當主機A上第二個用戶要Telne到
        主機B時(其實是在主機A與主機B之間建立第二個Telnet進程),主機A的第二個用戶向TCP
        TCP會選出另外一個可使用的端口號,假如為10099,給第二個用戶。主機B上便會創建
        第二個Telnet會話。
        所以在統一IP地址上具有不同端口號的兩個連接是不同的。IP地址和端口號被用來唯一地
        確定數據連接的途徑。
        UDP
        UDP是TCP/IP的另一個非常重要的協議。

        UDP數據域的頭部共占用了8個字節
        UDP數據域的頭格式描述
        名稱
        描述
        源端口
        調用的端口號
        目的端口
        被調用的端口號
        報文長度
        記錄UDP數據包中的8位組數目包括UDP數據的長度
        最小值為8(數據部分為0時)
        校驗和
        頭標和數據域計算的校驗和,這一項是可選的,為的
        是在高可靠性的網路上盡量減少開銷
        數據
        上層協議的數據

        UDP為應用程序提供的是一種不可靠的、非連接的分組交付服務,UDP報文可能出現
        丟失、重復、時延、亂序、連接失效的問題。但是正式由于它不提供這種可靠性,所
        以它的開銷很小。換句話說,UDP提供了一種在高效可靠的網絡上傳輸數據而不用消
        耗不必要的網絡資源和處理時間的通信方式。使用UDP的協議包括TFTP、SNMP、DNS
        DHCP。UDP很適合這種客戶機像服務器發送簡單服務請求的環境,因為這種服務的開
        銷本來就很小,如果在喀什或者結束時加入類似TCP三次握手的過程,網絡的實際利用
        將會變得很低。
        UDP還可以用于操作信息的登錄。例如,像日志服務器 syslog發送日志信息,采用UDP
        不會導致多臺設備向一臺服務器發送日志信息而引起過載。
        UDP依靠上層協議提供可靠性,包括處理報文的丟失、重復、時延、亂序、連接失效
        等問題。如Real流格式媒體就是使用應用程序協議來保證數據的正確傳輸。
        TCP
        在上文中已經提到UDP為應用程序提供的是一種不可靠的、非連接的分組的交付服務。當網絡硬件失效
        或者負擔太重時,數據段可能會產生丟失、重復、時延、亂序等現象,這些都會導致通信不正常。如果
        讓應用程序來負擔差錯檢測和恢復的工作,將給程序員帶來很多復雜的工作,所以使用獨立的通信協議
        來保證通信的可靠性是非常必要的。
        上一頁 1 2 下一頁

        關鍵詞: TCPIP傳輸層協

        評論


        技術專區

        關閉
        主站蜘蛛池模板: 巴林右旗| 黑龙江省| 阆中市| 启东市| 潜山县| 周至县| 南涧| 鄂温| 喀喇| 白城市| 桂平市| 大竹县| 琼海市| 元谋县| 城口县| 山阳县| 马关县| 罗平县| 汉寿县| 安远县| 张家口市| 阜平县| 若羌县| 大埔区| 汉寿县| 双鸭山市| 宜兰县| 衡阳市| 叶城县| 柳江县| 河北省| 渝北区| 长白| 垦利县| 榆林市| 辽宁省| 饶河县| 抚松县| 德兴市| 卫辉市| 沂南县|