2. 程式人生 > >[面試時]我是如何講清楚TCP/IP是如何實現可靠傳輸的

[面試時]我是如何講清楚TCP/IP是如何實現可靠傳輸的

阿新 • • 發佈：2019-01-03

1、概述

眾所周知，TCP/IP是面向連結的可靠傳輸協議，但是問題是如何實現可靠傳輸的呢？在我看來，TCP/IP可靠傳輸的基礎是滑動視窗協議和連續ARQ協議，配合著流量控制和擁塞控制，使得整個傳輸過程保證：

  • 傳輸通道不產生差錯
  • 不管傳送方以多快的速度傳送資料，接收方總是來得及處理收到的資料（通過累計確認、超時重傳、擁塞控制三大模組保證）

2、滑動視窗協議和連續ARQ協議

2.1、停止等待協議和自動重傳請求(ARQ)

所謂停止等待協議就是每傳送完一個分組就停止傳送，等待對方的確認。在收到確認後再發送下一個分組。但是在傳輸過程中可能出現意外，這時候就需要用到ARQ協議了，比如說：

2.1.1、B可能沒有收到A傳送的M
1

這時候A就會有個超時計時器，當超時計時器到期時沒收到B的確認報文，則A重新發送M1，因此必須保證以下幾點：

  • A傳送完一個分組後，必須暫時保留已傳送的分組副本，只有收到確認後才能清除分組副本
  • 分組和確認分組都必須進行編號
  • 超時計時器設定的重傳時間應當比資料在分組傳輸的往返時間更長一些
停止等待協議

2.1.2、A沒有收到B的確認報文或確認報文遲到

發生確認丟失時，B會再一次收到A的重傳分組M1，此時B會進行如下行動：

  • 丟棄這個重複分組M1
  • 向A傳送確認報文

發生確認遲到時，A會再一次收到B的確認報文，這時候A收下並丟棄這個確認報文，並不做什麼。

停止等待協議

2.2、滑動視窗協議和連續ARQ協議

2.2.1、累積確認方式

為了提高通道的利用率，實際上採用了流水線傳輸的方案。如圖：

停止等待協議

這時就需要使用連續ARQ協議和滑動視窗協議。傳送方和接收方各自維持著傳送視窗和接受視窗，傳送方每收到一個確認，就把傳送視窗向前滑動一個分組的位置。接收方一般採用累計確認方式，即接收方不必對收到的分組逐個傳送確認，而是可以在收到幾個分組後，對按序到達的最後一個分組傳送確認，這樣就表示：到這個分組位置的所有分組都已經正確收到了。

停止等待協議

2.2.2、累積確認方式詳細解析

由圖可見，描述一個傳送視窗的狀態需要三個指標P1、P2、P3

  • P3−P1=A 的傳送視窗(通知視窗)
  • P2−P1=已傳送但尚未收到確認的位元組數
  • P3−P2=允許傳送但尚未傳送的位元組數(可用視窗或有效視窗)

解析一：此時B沒有收到序號為31的資料，因此只能對按序收到的資料中的最高的序號給出確認，即此時Ｂ的確認號還是30(因為B沒有收到序號31的資料，只能傳送序號30的確認號)

停止等待協議

解析二：此時B收到了序號31的資料，那麼B會進行如下處理：

  • 把31~33的資料交給主機，B刪除這些資料快取
  • 接著把接收視窗向前移動3個序號，同時給A傳送確認號33

A收到B的確認號後，就可以把傳送視窗向前滑動3個序號，但P2指標不變

停止等待協議

解析三：A在繼續傳送完序號42~53的資料後，指標P2和P3重合。傳送視窗內的序號都已經用完，但還沒有收到確認。由於傳送視窗已滿，可用視窗已減小到了零，因此必須停止傳送。此時A設定了超時計時器，超時計時器到期時就重傳這部分資料，重置超時計時器，知道收到B的確認為止。如果A收到的確認號落在傳送視窗內，那麼A就可以使傳送視窗繼續向前滑動，併發送新的資料。

2.2.3、傳送快取與傳送視窗、接收快取與接收視窗

傳送快取用來暫時存放(即傳送視窗)：

  • 傳送應用程式傳送給傳送方TCP準備傳送的資料
  • TCP已經發送出但尚未收到確認的資料

接收快取用來暫時存放：

  • 按序到達的、但尚未被接收應用程式讀取的資料
  • 未按序到達的資料

2.2.4、傳送快取和接收快取小結

  • A的傳送視窗根據B的接收視窗設定，但是二者並以總是一樣大
  • 對於不按序到達的資料應如何處理，TCP彼岸準並無明確規定(一般都是臨時儲存在接收視窗中，等到位元組流完整接收後再按序提交給上層的應用程序)
  • TCP要求接收方必須有累積確認的功能，這樣子可以減少傳輸開銷
停止等待協議

2.2.5、超時重傳時間的確定

由上可知，TCP的傳送方在規定的時間內沒有收到確認就要重傳已傳送的報文段。但是由於TCP的下層網際網路環境，傳送的報文段可能只經過一個高速率的區域網，也可能經過多個低速率的網路，並且每個IP資料報所選擇的路由還可能不同，因此註定超時重傳時間要動態變化。

2.2.5.1、加權平均往返時間(平滑的往返時間，RTTs)

TCP採用的一種自適應演算法，每當第一次測量到RTT樣本時，RTTs值就取為所測量到的RTT樣本值。但以後每測量到一個新的RTT樣本，就按下式重新計算一次RTTs：

新的RTTs=(1−α)∗(舊的RTTs)+α∗(新的RTT樣本)
在上式中，0⩽α<1，若α接近零，則表示新的RTTs與舊的RTTs值相比變化不大；若α接近1，則表示新的RTTs受RTT樣本的影響較大(RTT值更新較快)。α推薦值為1/8，即0.125.
2.2.5.2、超時重傳時間(RTO)

超時計時器設定的超時重傳時間應略大於上面得出的RTTs，計算公式如下：

RTO=RTTs+4∗RTTD
2.2.5.3、RTT的偏差的加權平均值(RTTD)

RTTD與RTTs和新的RTT樣本之差有關。當第一次測量時，RTTD取值為RTT樣本的一般，在以後的測量中按下式計算，0⩽β<1，推薦取值1/4，即0.25：

新的RTTD=(1−β)∗(舊的RTTD)+β∗|RTTs−新的RTT樣本|
2.2.5.4、問題

假設傳送出一個報文段。設定的重傳時間到了，還沒有收到確認。於是重傳報文段。經過了一段時間後，收到了確認報文段。
那麼，如何判定收到的確認報文是對先發送的報文段的確認，還是對後來重傳的報文段的確認？

停止等待協議
  • 如果收到的確認是對重傳報文段的確認，但卻被源主機當成是對原來的報文段的確認，則計算出的RTTs和RTO會偏大。如此重複會導致RTO越來越長。
  • 如果收到的確認是對原來的報文段的確認，但卻被源主機當成是對重傳報文段的確認，則計算出的

    相關推薦

    [面試時]我是如何講清楚TCP/IP是如何實現可靠傳輸的

    1、概述 眾所周知，TCP/IP是面向連結的可靠傳輸協議，但是問題是如何實現可靠傳輸的呢？在我看來，TCP/IP可靠傳輸的基礎是滑動視窗協議和連續ARQ協議，配合著流量控制和擁塞控制，使得整個傳輸過程保證： 傳輸通道不產生差錯 不管傳送方以多快的速度傳送資

    我是如何講清楚TCP協議是如何保證可靠傳輸的

    1、UDP： （1）UDP，user datagram protocol，使用者資料報協議，不提供複雜的控制機制，利用IP提供面向無連線的通訊服務，並且它是將應用程式傳送過來的資料包在收到的那一刻，立即按照原樣傳送到上的一種機制。 （2）即使在網路擁堵的情況下，UDP也無法進行流量控制等避免網路

    【TCP/IP實現磁盤資源的分享-----ISCSI(互聯網最小應用程序接口)】

    pg1 left 進程 技術分享 ans 應用 mic ali 最小 Iscsi server: 首先把多塊磁盤合並為RAID5，便於後期iscis client訪問以及服務端的管理 安裝 targted服務端包，以及targtedcli創建isc

    TCP/IP實現（十二） TCP 傳輸控制協議

    一.TCP首部      TCP首部結構如下圖所示：                      TCP協議中用序號來標識每一個位元組，連線的每一端都

    TCP/IP實現（十一） UDP使用者資料報協議

    一.已連線UDP       我們可以對UDP套接字呼叫connect進行連線，但與TCP連線的差別很大。UDP進行連線並不進行三次握手，核心只是核心只是檢查一些立即可知的錯誤（如一個顯然不可達的目的地），並將對端的IP地址和埠號記錄在PCB協議控制塊中，之後立即返

    TCP/IP實現（十） 協議控制塊

    一.協議控制塊概述        網際協議控制塊（Internet協議控制塊）是傳輸層的資料結構，它被TCP,UDP以及原始IP使用，但其它協議並不適用（如：IP,ICMP,IGMP），其作用是儲存一個UDP,TCP端點的共有資訊，如：外部和本地IP,外部

    TCP/IP實現（九） 插口I/O

    一.插口快取（套接字快取） struct sockbuf { u_long sb_cc; // 快取中的資料大小 u_long sb_hiwat; /* max actual char count */ u_long sb_mbcnt; // 快取mbuf的數量 u_long sb_m

    TCP/IP實現（八） 插口層

    一.概述         插口層可以說是在使用者程式與TCP/IP協議之間的一個呈上啟下的層次，它將使用者與某協議相關的請求對映到具體的協議實現。不同型別的套接字在產生時就會關聯到相關協議實現（通過一組函式指標來實現的）。比如在一個TCP套接字上

    TCP/IP實現（七） ICMP協議

    一.概述        ICMP協議用於在網路間傳遞請求與應答以及差錯訊息。比如Ping程式便是應用了請求與應答，而Traceroute應用的卻是差錯訊息來實現的。       對於ICMP的輸入往往要經過多次處理，首先由

    TCP/IP實現（六） IP選項處理

    一.概述        IP選項是IP固定首部之後的選項部分，由於IP首部長度是用4bit來計數，以4個位元組為表示的，所以首部長度最多為60個位元組，IP選項最多為40個位元組。IP選項欄位可能包含0~多個單獨選項。選項包含兩類：單位元組與多位元組。單位

    TCP/IP實現（五） IP協議

    一.IP首部 1.概述         ip資料報的首部格式如下：                          

    【計算機網路】【TCP】如何講清楚Tcp的三次握手和四次揮手？

    每一次TCP連線都需要三個階段：連線建立、資料傳送和連線釋放。 三次握手: 三次握手就發生在連線建立階段。 目的：三次握手的目的是為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產

    面試時我不在乎候選人的經驗來自培訓班，但會關注商業專案經驗和幹活能力：再說面試時鑑別商業專案的方式 最近面試java後端開發的感受：如果就以平時專案經驗來面試，通過估計很難——再論面試前的準備

        我在部落格園裡乃至其它地方看到有不少對培訓班出身的程式設計師的評價，其實至少在我面試時，培訓班出來的程式設計師沒有原罪。     我也面試不少程式設計師，從高階開發到初級開發都有，有985和211名校出身的，也有大專學習通過培訓班積累IT經驗的。我見過有候選人

    TCP/IP實現（四） IP編址

    一.IP地址         一個IP地址是被指派給一個系統中的網路介面的而不是系統本身，就如在《TCP/IP實現（二） 介面層資料結構》中描述的那樣，每一個用於儲存IP協議地址資訊的in_ifaddr結構都和一個描述介面資訊的ifnet（或者是他的專用化）相關聯。  

    JAVA Socket 底層是怎樣基於TCP/IP 實現的

    首先必須明確：TCP/IP模型中有四層結構：       應用層（Application Layer）、傳輸層（Transport  Layer）、網路層（Internet Layer  ）、鏈路層（LinkLayer）  其中Ip協議（Internet Protocol）是位於網路層的，TCP協議時位於傳輸

    linux網路程式設計練習---聊天室（TCP/IP實現）

    為了更深刻的鍛鍊認識TCP/IP協議，加強自己對Linux系統的網路程式設計部分的編寫程式碼能力，編寫基於控制檯的聊天視窗，用本機既當伺服器又當客戶端，先開啟一個shell，執行伺服器程式，然後再開啟一個shell視窗，執行客戶端程式，顯示連線成功，開始聊天吧。不知道為什麼

    Java 基於TCP/IP 實現簡單的 socket 通訊

    Server.java package com.learn; import java.io.BufferedReader; import java.io.IOException; import

    《Linux核心TCP/IP 實現》：協議棧原始碼分析圖

    一.linux核心網路棧程式碼的準備知識 1. linux核心ipv4網路部分分層結構： BSD socket層： 這一部分處理BSD socket相關操作，每個socket在核心中以struct socket結構體現。這一部分的檔案主要有： /net/

    同學你會hello world嗎？ 給我講清楚點

    少點程式碼，多點頭髮 本文已經收錄至我的GitHub,歡迎大家踴躍star 和 issues。 https://github.com/midou-tech/articles 面試官超級喜歡問hello world問題 特別是校招，我校招碰到過3次 其實很多看起來順其自然簡單的東西，背後是一套複雜的

    TCP/UDP區別以及UDP如何實現可靠傳輸

    TCP和UDP是OSI模型中的運輸層中的協議。TCP提供可靠的通訊傳輸，而UDP則常被用於讓廣播和細節控制交給應用的通訊傳輸。   UDP(User Datagram Protocol)         UDP不提供複雜的控制機制，利用I