• <sub id="h4knl"><ol id="h4knl"></ol></sub>
    <sup id="h4knl"></sup>
      <sub id="h4knl"></sub>

      <sub id="h4knl"><ol id="h4knl"><em id="h4knl"></em></ol></sub><s id="h4knl"></s>
      1. <strong id="h4knl"></strong>

      2. TCP/IP傳輸層

        時間:2024-09-23 15:30:45 TCP/IP 我要投稿
        • 相關推薦

        TCP/IP傳輸層

          TCP:傳輸控制協(xié)議,是TCP/IP參考模型的傳輸層協(xié)議。那么關于TCP/IP傳輸層,你懂多少?下面跟yjbys小編一起來學習吧!

          一、傳輸層的主要功能是什么?

          分割并重新組裝上層提供的數據流,為數據流提供端到端的傳輸服務

          二、傳輸層如何區(qū)分不同應用程序的數據流?

          因為,對應傳輸層而言,它只需要知道目標主機上的哪個服務程序來響應這個程序,而不需要知道這個服務程序是干什么的。因此,我們只需要能夠抽象的表示出來這些應用程序和服務程序即可。我們使用端口號來抽象標識每個網絡程序。

        傳輸層的TCP和UDP可以接收來自多個應用程序的數據流,用端口號標識他們,然后把他們送給Internet層處理;

        同時TCP和UDP接收來自Internet層的數據包,用端口號區(qū)分他們,然后交給不同的應用程序。

          因此:在同一IP地址(同一個目標主機)上不同的端口號是兩個不同的鏈接。IP地址和端口號用來唯一的確定網絡上數據的目的地。

          三、傳輸層有哪些協(xié)議?

          傳輸層的兩大協(xié)議:TCP(傳輸控制協(xié)議)UDP(用戶數據包協(xié)議)

          TCP是一個可靠的面向鏈接的協(xié)議,UDP是不可靠的或者說無連接的協(xié)議。

          可以用打電話和發(fā)短信來說明這種關系:

          UDP就好似發(fā)短信,只管發(fā)出去,至于對方是不是空號(網絡不可到達)能不能收到(丟包)等并不關心。

          TCP好像打電話,雙方要通話,首先,要確定對方不是開機(網絡可以到達),然后要確定是不是沒有信號(),然后還需要對方接聽(通信鏈接)。

          四、什么是UDP協(xié)議?

          UDP數據包結構如下圖所示

        源端口(16)

        目標端口(16)

        報文長度(16)

        校驗和(16)

        數據(可變)

          UDP為應用程序提供的是一種不可靠的、無連接的分組交付,因此,UDP報文可能會出現丟失、亂序、重復、延時等問題。

        因為它不提供可靠性,它的開銷很小。

          五、為什么有了UDP,還需要TCP?

          問題4中已經說到,UDP為應用程序提供的是一種無連接、不可靠的分組交付。當網絡硬件失效或者負擔太重時,數據包可能就會產生丟失、重復、延時、亂序的現象。這些都會導致我們的通信不正常。如果讓應用程序來擔負差錯控制的工作,無疑將給程序員帶來許多復雜的工作,于是,我們使用獨立的通信協(xié)議來保證通信的可靠性是非常必要的。

          六、什么是TCP協(xié)議?

          傳輸控制協(xié)議TCP是一個面向鏈接的、可靠的通信協(xié)議。

          1. 在開始傳輸前,需要進行三次握手建立鏈接

          2. 可靠性:在傳輸過程中,通信雙方的協(xié)議模塊繼續(xù)進行通信

          3. 通信結束后,通信雙方都會使用改進的三次握手來關閉鏈接

          TCP數據包結構如下圖

        源端口(16)

        目標端口(16)

        序號(32)

        應答號(32)

        頭長度(4)

        保留(6)

        編碼位(6)

        窗口(16)

        校驗和(16)

        緊急(16)

        可選項(如果有,032)

        數據(可變)

          七、怎么理解協(xié)議和程序?

          如同我們自定義的應用層協(xié)議一樣:協(xié)議只是給出了一組規(guī)范,規(guī)定我們應該怎么樣(按什么規(guī)則)保存數據。

          在計算機間傳輸的永遠都是二進制字節(jié)碼(對于傳輸層,可以理解為傳輸的始終是下層的IP數據包),是計算機中的程序通過對這些字節(jié)碼進行邏輯分析、判斷,來控制程序完成差錯控制等功能。

          至于解析這些字節(jié)碼的程序,則可以有不同的實現,只要我們按照規(guī)則來解析,并作出相應的控制,我們大可以自己寫個程序是實現相應功能。

        知道了這些后,顯然,我們也可以使用前面說的Jpcap,來自己實現一個基于Java的TCP或者UDP協(xié)議。可以參考Linux下的Tcp源碼。

        /net/ipv4/udp.c
        /net/ipv4/datagram.c
        /net/ipv4/tcp_input.c
        /net/ipv4//tcp_output.c
        /net/ipv4/tcp.c  

          八、TCP是否真的有鏈接?

          我們都知道,TCP通過完成三次握手來建立鏈接的,但是這種連接是面向虛電路的,是物理上不存在的,只是雙方的TCP程序,邏輯上的認為建立了這樣的鏈接。

          九、鏈接是如何建立的(邏輯上)?

          假設:當我們在主機A上啟動一個程序,通過TCP去鏈接主機B上的9091端口。

          整個過程是怎么樣的呢?邏輯上我們可以這么理解建立鏈接的過程:

          1.SYN:seq=X;

          1.1 A的TCP程序,為這個鏈接分配一個端口(設為9090)。

          1.2 同時邏輯上的將TCP連接的狀態(tài)設置為:正在連接。(通過在鏈接狀態(tài)表中添加一條記錄,記錄中狀態(tài)為:正在連接)

          猜想:

        TCP程序中, 應該有張表來保持鏈接的狀態(tài),其中每個狀態(tài)應該有:

        本機地址(IP加port)、對方地址、鏈接狀態(tài)

          1.3 同時,隨機生成一個初始序列號X,生成一個TCP包,將初始化序列號X設置為TCP中的序列號,發(fā)送給主機B。

          2.SYN:seq=Y ACK:ack=X+1;

          2.1 B上TCP程序收到該數據包,查詢9091端口狀態(tài),如果可以鏈接。

          2.2 同樣的,在邏輯上的將TCP連接的狀態(tài)設置為:正在連接

          2.3 同時,隨機生成一個初始化序列號Y,根據接收的序列號X,生成應答號X+1,生成一個TCP包,將序列號和應答號分別設置到TCP包頭中,將TCP數據包發(fā)給主機A。

          3.SYN:seq=X+1 ACK:ack=Y+1.

          3.1 A上的TCP程序接收到數據包,查詢9090端口狀態(tài)。

          3.2 根據收到的SYN:seq=Y;ACK:ack=X+1; 封裝一個TCP包 SYN:seq=x+1;ACK:ack=Y+1;發(fā)送給主機B。同時,TCP程序將鏈接狀態(tài)表中該條記錄狀態(tài)設置為已連接。

          3.3 主機B收到數據包,TCP程序將鏈接狀態(tài)表中該條記錄狀態(tài)設置為已連接。

          至此,一個TCP鏈接建立(三次握手)完成。

          我們可以看到:

          第一:傳送的都是IP數據包,其實只是將收到的數據包交給TCP程序處理。

          第二:鏈接狀態(tài),只是TCP程序中的一個邏輯狀態(tài)。

          十:所謂的建立TCP鏈接開銷很大,具體是指什么?

          從九中,很容易看出。要簡歷TCP鏈接,必須進行三次IP數據包的成功傳輸。

          十一:三次握手的目的是什么?

          TCP是面向鏈接的,在面向鏈接的環(huán)境中,開始傳輸數據之前,在兩個中端之間必須先建立一個鏈接。建立鏈接的過程可以確保通信雙方在發(fā)送應用程序數據包之前,都已經準備好了傳送和接收數據。并且使通信雙方統(tǒng)一了初始化序列號。

          十二:TCP如何提供可靠性?

          在傳輸過程中,通信雙方的協(xié)議模塊繼續(xù)進行通信,從而確保了傳輸的可靠性。

          針對亂序:在通過三次握手進行鏈接時,序列號被初始化。在傳輸過程中,TCP繼續(xù)使用這個序列號來標記發(fā)送的每一個數據段,沒傳送一個數據段,序列號加一。接收方依據序列號重裝收到的數據段。

          針對丟包:在傳輸過程中,接收方收到一個數據段后,會用ACK應答碼向發(fā)送端回復一個IP包進行應答,確認號ACK用來告訴發(fā)送端哪些數據包已經成功接收,發(fā)送方對未被應答的報文段提供重傳。

          針對重復:接收端收到數據段后,查看序列號,如果已經成功接收改數據包,則丟棄后面這個數據段。

          針對延時:延時造成的第一個問題,就是數據包達到接收端時亂序。

          當延時嚴重時,接收端一直未收到數據段,則不會回復ACK,發(fā)送端認為丟包,重發(fā)。

          十三:什么是預期確認?什么是肯定確認與重新傳輸?哪些情況會重傳?

          1.確認號ACK會告訴發(fā)送端哪些數據段已經成功接收,并且確認號會向發(fā)送端指出接收端希望收到的下一個序列號。即,確實號ACK為上個數據序列號+1,這種機制稱為預期確認。

          2.為了提高效率,我們在發(fā)送端,將數據段保存在緩沖區(qū)中,直道發(fā)送端收到來自接收端的確認號。這種機制被稱為“肯定確認與重新傳輸”。

          3.當發(fā)送端在給定時間間隔內收不到那個數據段的應答時,發(fā)送端就會重傳那個數據段。

          情況1:網絡延時/環(huán)路,數據段丟失

          情況2:網絡延時,數據段推遲到達

          情況3:數據段成功到達,應答因為1.2不能達到。

          十四: TCP中,序列號和應答號有哪些作用?

          從以上10,11,12中,很明顯的可以看到

          依靠序列號重組數據段

          依靠數據包消除網絡中的重復包

          依靠序列號和應答號進行差錯重傳,提高了TCP的可靠性

          十六:為什么需要窗口技術?

          前面我們已經說了,TCP的可靠性,是通過預期確認來實現的。即發(fā)送方發(fā)送一個數據段后,需要得到對方的確認后,才會發(fā)送下一個數據段。

          因此,假設一個數據段大小為64KB(IP包最大值),一次發(fā)送和確認需要的時間為500MS,則,1S內,只能傳送128KB的數據,如果帶寬為1M,顯然很浪費帶寬。為了充分利用帶寬,我們使用窗口技術。滑動窗口允許發(fā)送方在收到接收方的確認之前發(fā)送多個數據段。(窗口大小決定了在收到確認前可以發(fā)送的數據段數量)

          十七:如何實現流量控制?

          窗口數決定了當前傳輸的最大流量。當我們在傳輸過程中,通信雙方可以根據網絡條件動態(tài)協(xié)商窗口大小,調整窗口大小時,即可實現流量控制。(在TCP的每個確認中,除了ACK外,還包括一個窗口通知)

          十八:UDP的開銷很小,具體是指什么?

          1.因為UDP是無連接的。在傳輸數據之前,不需要進行復雜的三次握手來建立連接。

          2.在傳輸數據時,沒有協(xié)議間通信流量(確認信號),也不需要浪費不必要的處理時間(接收確認信號再發(fā)一下)。

          3;傳輸結束后,也不用再用改進的三次握手來端口連接。

          十九:UDP數據包、TCP數據包大小如何確認?

          無論TCP還是UDP數據包,都需要交給Internet層封裝為IP包,而一個IP包,包頭中的長度位為16位,所以IP包最大為2的16方,即65535(64KB還需要減去各種包頭長度)。

          TCP因為面向流,且可以憑借序列號對大文件進行分段和重組,因此,TCP可以用來傳輸較大的文件。而UDP,如果要傳輸大于64KB的數據,則需要自己在應用層進行差錯控制。

          為了提高傳輸效率和減少網絡通信量(協(xié)議間的通信),TCP也會一次傳輸足夠多的數據。

          因為MTU的存在,TCP包和UDP包不是越大越好。(在路由中分包,在接收端重組,加大路由與接收端負擔,增大丟包概率。分組丟失,整個數據包重傳。)

          二十:UDP適用哪些環(huán)境?TCP適用哪些環(huán)境?

          適合UDP的環(huán)境:

          1.在高效可靠的網絡環(huán)境中(不需要考慮網絡不好導致的丟包、亂序、延時、重復等問題),因為UDP是無連接的服務,不用消耗不必要的網絡資源(TCP中的協(xié)議間通信)和處理時間(預期確認需要的時間),從而效率要高的多。

          2.在輕權通信中,當需要傳輸的數據量很小(可以裝在一個IP數據包內)時。如果我們使用TCP協(xié)議,那么,先建立連接,一共需要發(fā)送3個IP數據包,然后數據傳輸,1個IP數據包,產生一個確認信號的IP包,然后關閉連接,需要傳輸5個IP數據包。使用TCP協(xié)議IP包的利用率為1/10。而使用UDP,只需要發(fā)送一個IP數據包。哪怕丟包(服務不成功),也可重新申請服務(重傳)。

        注:而且無論UDP還是TCP,傳輸的都是IP數據包。當網絡環(huán)境不好導致丟包時,無論TCP還是UDP都會丟包,這是沒有區(qū)別的。(如果考慮發(fā)送丟包,那么TCP效率更低),只是使用TCP,當連接建立成功后,TCP程序會進行可靠性控制。

          UDP很適合這種客戶機向服務器傳送簡單服務請求的環(huán)境。此類應用層協(xié)議包括TFTP , SNMP , DNS ,DHCP等。

          3.在對實時性要求很強的通信中:在諸如實時視頻直播等對實時性要求很高的環(huán)境中,從而允許一定量的丟包的情況下(直播比賽,前面丟失的包,重傳出來已經意義不大了),UDP更適合。(可以根據具體需要通過應用層協(xié)議提供可靠性,不用像TCP那么嚴格。)

          適合TCP協(xié)議的環(huán)境:

          當網絡硬件失效或者負擔太重時,數據包可能就會產生丟失、重復、延時、亂序的現象。這些都會導致我們的通信不正常的時候。如果讓應用程序來擔負差錯控制的工作,無疑將給程序員帶來許多復雜的工作,于是,我們使用獨立的通信協(xié)議來保證通信的可靠性是非常必要的。

        《&.doc》
        将本文的Word文档下载到电脑,方便收藏和打印
        推荐度:
        点击下载文档

        【TCP/IP傳輸層】相關文章:

        OSI七層與TCP/IP五層網絡架構詳解09-07

        TCP/IP協(xié)議是什么06-18

        TCP/IP三次握手四次揮手過程10-18

        對TCP/IP網絡協(xié)議的深入淺出歸納10-16

        查找本地IP/網絡IP/對方IP地址圖文教程07-17

        TCP的可靠性10-30

        三層交換機端口配置ip地址及綁定MAC地址的方法07-14

        IP雷達使用教程09-03

        TCP與UDP協(xié)議有什么不同09-16

        TCP洪水攻擊SYN Flood的診斷和處理05-26

        国产高潮无套免费视频_久久九九兔免费精品6_99精品热6080YY久久_国产91久久久久久无码
      3. <sub id="h4knl"><ol id="h4knl"></ol></sub>
        <sup id="h4knl"></sup>
          <sub id="h4knl"></sub>

          <sub id="h4knl"><ol id="h4knl"><em id="h4knl"></em></ol></sub><s id="h4knl"></s>
          1. <strong id="h4knl"></strong>

          2. 日本在线一区亚洲 | 中文字幕亚洲欧美无线码 | 中文字幕无线码一区精品 | 亚洲中文精品久久久久久 | 在线看片免费人成视频在线 | 亚洲综合另类一区二区 |

            TCP/IP傳輸層

              TCP:傳輸控制協(xié)議,是TCP/IP參考模型的傳輸層協(xié)議。那么關于TCP/IP傳輸層,你懂多少?下面跟yjbys小編一起來學習吧!

              一、傳輸層的主要功能是什么?

              分割并重新組裝上層提供的數據流,為數據流提供端到端的傳輸服務

              二、傳輸層如何區(qū)分不同應用程序的數據流?

              因為,對應傳輸層而言,它只需要知道目標主機上的哪個服務程序來響應這個程序,而不需要知道這個服務程序是干什么的。因此,我們只需要能夠抽象的表示出來這些應用程序和服務程序即可。我們使用端口號來抽象標識每個網絡程序。

            傳輸層的TCP和UDP可以接收來自多個應用程序的數據流,用端口號標識他們,然后把他們送給Internet層處理;

            同時TCP和UDP接收來自Internet層的數據包,用端口號區(qū)分他們,然后交給不同的應用程序。

              因此:在同一IP地址(同一個目標主機)上不同的端口號是兩個不同的鏈接。IP地址和端口號用來唯一的確定網絡上數據的目的地。

              三、傳輸層有哪些協(xié)議?

              傳輸層的兩大協(xié)議:TCP(傳輸控制協(xié)議)UDP(用戶數據包協(xié)議)

              TCP是一個可靠的面向鏈接的協(xié)議,UDP是不可靠的或者說無連接的協(xié)議。

              可以用打電話和發(fā)短信來說明這種關系:

              UDP就好似發(fā)短信,只管發(fā)出去,至于對方是不是空號(網絡不可到達)能不能收到(丟包)等并不關心。

              TCP好像打電話,雙方要通話,首先,要確定對方不是開機(網絡可以到達),然后要確定是不是沒有信號(),然后還需要對方接聽(通信鏈接)。

              四、什么是UDP協(xié)議?

              UDP數據包結構如下圖所示

            源端口(16)

            目標端口(16)

            報文長度(16)

            校驗和(16)

            數據(可變)

              UDP為應用程序提供的是一種不可靠的、無連接的分組交付,因此,UDP報文可能會出現丟失、亂序、重復、延時等問題。

            因為它不提供可靠性,它的開銷很小。

              五、為什么有了UDP,還需要TCP?

              問題4中已經說到,UDP為應用程序提供的是一種無連接、不可靠的分組交付。當網絡硬件失效或者負擔太重時,數據包可能就會產生丟失、重復、延時、亂序的現象。這些都會導致我們的通信不正常。如果讓應用程序來擔負差錯控制的工作,無疑將給程序員帶來許多復雜的工作,于是,我們使用獨立的通信協(xié)議來保證通信的可靠性是非常必要的。

              六、什么是TCP協(xié)議?

              傳輸控制協(xié)議TCP是一個面向鏈接的、可靠的通信協(xié)議。

              1. 在開始傳輸前,需要進行三次握手建立鏈接

              2. 可靠性:在傳輸過程中,通信雙方的協(xié)議模塊繼續(xù)進行通信

              3. 通信結束后,通信雙方都會使用改進的三次握手來關閉鏈接

              TCP數據包結構如下圖

            源端口(16)

            目標端口(16)

            序號(32)

            應答號(32)

            頭長度(4)

            保留(6)

            編碼位(6)

            窗口(16)

            校驗和(16)

            緊急(16)

            可選項(如果有,032)

            數據(可變)

              七、怎么理解協(xié)議和程序?

              如同我們自定義的應用層協(xié)議一樣:協(xié)議只是給出了一組規(guī)范,規(guī)定我們應該怎么樣(按什么規(guī)則)保存數據。

              在計算機間傳輸的永遠都是二進制字節(jié)碼(對于傳輸層,可以理解為傳輸的始終是下層的IP數據包),是計算機中的程序通過對這些字節(jié)碼進行邏輯分析、判斷,來控制程序完成差錯控制等功能。

              至于解析這些字節(jié)碼的程序,則可以有不同的實現,只要我們按照規(guī)則來解析,并作出相應的控制,我們大可以自己寫個程序是實現相應功能。

            知道了這些后,顯然,我們也可以使用前面說的Jpcap,來自己實現一個基于Java的TCP或者UDP協(xié)議。可以參考Linux下的Tcp源碼。

            /net/ipv4/udp.c
            /net/ipv4/datagram.c
            /net/ipv4/tcp_input.c
            /net/ipv4//tcp_output.c
            /net/ipv4/tcp.c  

              八、TCP是否真的有鏈接?

              我們都知道,TCP通過完成三次握手來建立鏈接的,但是這種連接是面向虛電路的,是物理上不存在的,只是雙方的TCP程序,邏輯上的認為建立了這樣的鏈接。

              九、鏈接是如何建立的(邏輯上)?

              假設:當我們在主機A上啟動一個程序,通過TCP去鏈接主機B上的9091端口。

              整個過程是怎么樣的呢?邏輯上我們可以這么理解建立鏈接的過程:

              1.SYN:seq=X;

              1.1 A的TCP程序,為這個鏈接分配一個端口(設為9090)。

              1.2 同時邏輯上的將TCP連接的狀態(tài)設置為:正在連接。(通過在鏈接狀態(tài)表中添加一條記錄,記錄中狀態(tài)為:正在連接)

              猜想:

            TCP程序中, 應該有張表來保持鏈接的狀態(tài),其中每個狀態(tài)應該有:

            本機地址(IP加port)、對方地址、鏈接狀態(tài)

              1.3 同時,隨機生成一個初始序列號X,生成一個TCP包,將初始化序列號X設置為TCP中的序列號,發(fā)送給主機B。

              2.SYN:seq=Y ACK:ack=X+1;

              2.1 B上TCP程序收到該數據包,查詢9091端口狀態(tài),如果可以鏈接。

              2.2 同樣的,在邏輯上的將TCP連接的狀態(tài)設置為:正在連接

              2.3 同時,隨機生成一個初始化序列號Y,根據接收的序列號X,生成應答號X+1,生成一個TCP包,將序列號和應答號分別設置到TCP包頭中,將TCP數據包發(fā)給主機A。

              3.SYN:seq=X+1 ACK:ack=Y+1.

              3.1 A上的TCP程序接收到數據包,查詢9090端口狀態(tài)。

              3.2 根據收到的SYN:seq=Y;ACK:ack=X+1; 封裝一個TCP包 SYN:seq=x+1;ACK:ack=Y+1;發(fā)送給主機B。同時,TCP程序將鏈接狀態(tài)表中該條記錄狀態(tài)設置為已連接。

              3.3 主機B收到數據包,TCP程序將鏈接狀態(tài)表中該條記錄狀態(tài)設置為已連接。

              至此,一個TCP鏈接建立(三次握手)完成。

              我們可以看到:

              第一:傳送的都是IP數據包,其實只是將收到的數據包交給TCP程序處理。

              第二:鏈接狀態(tài),只是TCP程序中的一個邏輯狀態(tài)。

              十:所謂的建立TCP鏈接開銷很大,具體是指什么?

              從九中,很容易看出。要簡歷TCP鏈接,必須進行三次IP數據包的成功傳輸。

              十一:三次握手的目的是什么?

              TCP是面向鏈接的,在面向鏈接的環(huán)境中,開始傳輸數據之前,在兩個中端之間必須先建立一個鏈接。建立鏈接的過程可以確保通信雙方在發(fā)送應用程序數據包之前,都已經準備好了傳送和接收數據。并且使通信雙方統(tǒng)一了初始化序列號。

              十二:TCP如何提供可靠性?

              在傳輸過程中,通信雙方的協(xié)議模塊繼續(xù)進行通信,從而確保了傳輸的可靠性。

              針對亂序:在通過三次握手進行鏈接時,序列號被初始化。在傳輸過程中,TCP繼續(xù)使用這個序列號來標記發(fā)送的每一個數據段,沒傳送一個數據段,序列號加一。接收方依據序列號重裝收到的數據段。

              針對丟包:在傳輸過程中,接收方收到一個數據段后,會用ACK應答碼向發(fā)送端回復一個IP包進行應答,確認號ACK用來告訴發(fā)送端哪些數據包已經成功接收,發(fā)送方對未被應答的報文段提供重傳。

              針對重復:接收端收到數據段后,查看序列號,如果已經成功接收改數據包,則丟棄后面這個數據段。

              針對延時:延時造成的第一個問題,就是數據包達到接收端時亂序。

              當延時嚴重時,接收端一直未收到數據段,則不會回復ACK,發(fā)送端認為丟包,重發(fā)。

              十三:什么是預期確認?什么是肯定確認與重新傳輸?哪些情況會重傳?

              1.確認號ACK會告訴發(fā)送端哪些數據段已經成功接收,并且確認號會向發(fā)送端指出接收端希望收到的下一個序列號。即,確實號ACK為上個數據序列號+1,這種機制稱為預期確認。

              2.為了提高效率,我們在發(fā)送端,將數據段保存在緩沖區(qū)中,直道發(fā)送端收到來自接收端的確認號。這種機制被稱為“肯定確認與重新傳輸”。

              3.當發(fā)送端在給定時間間隔內收不到那個數據段的應答時,發(fā)送端就會重傳那個數據段。

              情況1:網絡延時/環(huán)路,數據段丟失

              情況2:網絡延時,數據段推遲到達

              情況3:數據段成功到達,應答因為1.2不能達到。

              十四: TCP中,序列號和應答號有哪些作用?

              從以上10,11,12中,很明顯的可以看到

              依靠序列號重組數據段

              依靠數據包消除網絡中的重復包

              依靠序列號和應答號進行差錯重傳,提高了TCP的可靠性

              十六:為什么需要窗口技術?

              前面我們已經說了,TCP的可靠性,是通過預期確認來實現的。即發(fā)送方發(fā)送一個數據段后,需要得到對方的確認后,才會發(fā)送下一個數據段。

              因此,假設一個數據段大小為64KB(IP包最大值),一次發(fā)送和確認需要的時間為500MS,則,1S內,只能傳送128KB的數據,如果帶寬為1M,顯然很浪費帶寬。為了充分利用帶寬,我們使用窗口技術。滑動窗口允許發(fā)送方在收到接收方的確認之前發(fā)送多個數據段。(窗口大小決定了在收到確認前可以發(fā)送的數據段數量)

              十七:如何實現流量控制?

              窗口數決定了當前傳輸的最大流量。當我們在傳輸過程中,通信雙方可以根據網絡條件動態(tài)協(xié)商窗口大小,調整窗口大小時,即可實現流量控制。(在TCP的每個確認中,除了ACK外,還包括一個窗口通知)

              十八:UDP的開銷很小,具體是指什么?

              1.因為UDP是無連接的。在傳輸數據之前,不需要進行復雜的三次握手來建立連接。

              2.在傳輸數據時,沒有協(xié)議間通信流量(確認信號),也不需要浪費不必要的處理時間(接收確認信號再發(fā)一下)。

              3;傳輸結束后,也不用再用改進的三次握手來端口連接。

              十九:UDP數據包、TCP數據包大小如何確認?

              無論TCP還是UDP數據包,都需要交給Internet層封裝為IP包,而一個IP包,包頭中的長度位為16位,所以IP包最大為2的16方,即65535(64KB還需要減去各種包頭長度)。

              TCP因為面向流,且可以憑借序列號對大文件進行分段和重組,因此,TCP可以用來傳輸較大的文件。而UDP,如果要傳輸大于64KB的數據,則需要自己在應用層進行差錯控制。

              為了提高傳輸效率和減少網絡通信量(協(xié)議間的通信),TCP也會一次傳輸足夠多的數據。

              因為MTU的存在,TCP包和UDP包不是越大越好。(在路由中分包,在接收端重組,加大路由與接收端負擔,增大丟包概率。分組丟失,整個數據包重傳。)

              二十:UDP適用哪些環(huán)境?TCP適用哪些環(huán)境?

              適合UDP的環(huán)境:

              1.在高效可靠的網絡環(huán)境中(不需要考慮網絡不好導致的丟包、亂序、延時、重復等問題),因為UDP是無連接的服務,不用消耗不必要的網絡資源(TCP中的協(xié)議間通信)和處理時間(預期確認需要的時間),從而效率要高的多。

              2.在輕權通信中,當需要傳輸的數據量很小(可以裝在一個IP數據包內)時。如果我們使用TCP協(xié)議,那么,先建立連接,一共需要發(fā)送3個IP數據包,然后數據傳輸,1個IP數據包,產生一個確認信號的IP包,然后關閉連接,需要傳輸5個IP數據包。使用TCP協(xié)議IP包的利用率為1/10。而使用UDP,只需要發(fā)送一個IP數據包。哪怕丟包(服務不成功),也可重新申請服務(重傳)。

            注:而且無論UDP還是TCP,傳輸的都是IP數據包。當網絡環(huán)境不好導致丟包時,無論TCP還是UDP都會丟包,這是沒有區(qū)別的。(如果考慮發(fā)送丟包,那么TCP效率更低),只是使用TCP,當連接建立成功后,TCP程序會進行可靠性控制。

              UDP很適合這種客戶機向服務器傳送簡單服務請求的環(huán)境。此類應用層協(xié)議包括TFTP , SNMP , DNS ,DHCP等。

              3.在對實時性要求很強的通信中:在諸如實時視頻直播等對實時性要求很高的環(huán)境中,從而允許一定量的丟包的情況下(直播比賽,前面丟失的包,重傳出來已經意義不大了),UDP更適合。(可以根據具體需要通過應用層協(xié)議提供可靠性,不用像TCP那么嚴格。)

              適合TCP協(xié)議的環(huán)境:

              當網絡硬件失效或者負擔太重時,數據包可能就會產生丟失、重復、延時、亂序的現象。這些都會導致我們的通信不正常的時候。如果讓應用程序來擔負差錯控制的工作,無疑將給程序員帶來許多復雜的工作,于是,我們使用獨立的通信協(xié)議來保證通信的可靠性是非常必要的。