信頼性の高いデータ転送の基礎

という方へ シークする ネットワークとプロトコルの理解に専念します。

簡単に

この記事では、信頼性の高いデータ送信の基本について説明し、例を実装します。 Go、UDP と TCP を含む。に基づく 時間, два, 3 それ以外の場合は、誰もがタネンバウムとオリフェロフについてのみ議論しています。

トランスポート層プロトコル

異なるホスト上で実行されているアプリケーション プロセス間に論理接続を提供します。アプリケーションの観点から見ると、論理接続はプロセスを直接接続するチャネルのように見えます。

トランスポート層プロトコル エンド システムではサポートされていますが、ネットワーク ルーターではサポートされていません (- を除く) DPI）。送信側では、トランスポート層は、送信アプリケーション プロセスから受け取ったアプリケーション層データを、セグメントと呼ばれるトランスポート層パケットに変換します。

これは、アプリケーション層メッセージを (必要に応じて) フラグメントに分割し、それぞれにトランスポート層ヘッダーを追加することによって行われます。

次に、トランスポート層はセグメントを送信者のネットワーク層に渡し、そこでセグメントはネットワーク層パケット (データグラム) にカプセル化されて送信されます。受信側では、ネットワーク層がデータグラムからトランスポート層セグメントを抽出し、それをトランスポート層に渡します。次に、トランスポート層は受信したセグメントを処理して、そのデータを受信アプリケーションが利用できるようにします。

信頼性の高いデータ送信の原則

完全に安全なチャネルを介した信頼性の高いデータ送信

最も単純なケース。送信側は上位層からデータを受け取り、それを含むパケットを作成してチャネルに送信するだけです。

Сервер

package main

import (
    "log"
    "net"
)

func main() {
    // IP-адрес сервера и порт
    serverAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:12000")
    if err != nil {
        log.Fatal(err)
    }

    // создаем сокет с портом
    serverConn, err := net.ListenUDP("udp", serverAddr)
    if err != nil {
        log.Fatal(err)
    }
    // отложенное закрытие соединения
    defer serverConn.Close()

    // создаем буфер для данных
    buf := make([]byte, 1024)

    // ждем соединение
    for {
        // читаем запрос
        n, addr, err := serverConn.ReadFromUDP(buf)
        // передаем данные в ВЕРХНИЙ уровень: в нашем случае stdout
        println(string(buf[0:n]), " form ", addr.IP.String())
        if err != nil {
            log.Fatal(err)
        }
        // ответа нет, т.к. это UDP + надежный канал
    }
}

クライアント

package main

import (
    "fmt"
    "log"
    "net"
    "time"
)

func main() {
    // IP-адрес сервера и порт
    serverAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:12000")
    if err != nil {
        log.Fatal(err)
    }
    // локальный IP-адрес и порт
    localAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:0")
    if err != nil {
        log.Fatal(err)
    }
    // установка соединения
    conn, err := net.DialUDP("udp", localAddr, serverAddr)
    if err != nil {
        log.Fatal(err)
    }
    // отложенное закрытие соединения
    defer conn.Close()

    for {
        // получение данных от ВЕРХНЕГО уровня
        fmt.Print("Введите строчное предложение > ")
        var msg string
        _, err := fmt.Scanf("%s", &msg)
        if err != nil {
            log.Fatal(err)
        }
        // передается поток байт, а не строка
        buf := []byte(msg)
        // запись (передача) в соединение
        _, err = conn.Write(buf)
        if err != nil {
            log.Fatal(err)
        }
        // 1 секундочку
        time.Sleep(time.Second * 1)
    }
}

エラーが発生する可能性のあるチャネル上での信頼性の高いデータ送信

次のステップでは、送信されたすべてのパケットが送信された順序で受信されると仮定しますが、チャネルが時々歪みのあるデータを送信するため、パケット内のビットが破損している可能性があります。

この場合、次のメカニズムが使用されます。

• エラー検出。
• フィードバック;
• 再送信。

送信を複数回繰り返すための同様のメカニズムを備えた信頼性の高いデータ転送プロトコルは、自動再送要求 (ARQ) プロトコルと呼ばれます。
さらに、受信側が最後のパケットの転送結果に関する情報をまったく受け取らない場合、受信エラーが発生する可能性を考慮する価値があります。
この問題の解決策は、TCP でも使用されており、パケットのシーケンス番号を含む新しいフィールドをデータ パケットに追加することです。

パケットの歪みや損失が発生する信頼性の低いチャネル上での信頼性の高いデータ送信

残念ながら、歪みに加えて、ネットワーク内でパケット損失も発生します。
この問題を解決するには、次のメカニズムが必要です。

• パケット損失の事実を判断する。
• 失われたパケットを受信者に再配信します。

さらに、荷物の紛失に加えて、領収書の紛失、または何も紛失していない場合でも配達が大幅に遅れる可能性にも備える必要があります。すべての場合において、同じことが行われ、パケットが再送信されます。時間を制御するために、このメカニズムではカウントダウン タイマーを使用します。これにより、待機間隔の終了を決定できます。それでパッケージには net TCPKeepAlive はデフォルトで 15 秒に設定されています。

// defaultTCPKeepAlive is a default constant value for TCPKeepAlive times
// See golang.org/issue/31510
const (
    defaultTCPKeepAlive = 15 * time.Second
)

送信側は、パケットが送信されるたびに (1 回目と 2 回目の両方で) タイマーを開始し、タイマーからの割り込みを処理し、タイマーを停止する必要があります。

これで、信頼性の高いデータ転送プロトコルの重要な概念を理解できました。

• チェックサム。
• パッケージのシーケンス番号。
• タイマー;
• ポジティブなレシートとネガティブなレシート。

しかしそれだけではありません！

パイプラインによる信頼性の高いデータ転送プロトコル

すでに検討したバリアントでは、信頼性の高い配信プロトコルは非常に非効率的です。 RTT が増加するにつれて、通信チャネルによって提供される送信が「遅く」なり始めます。効率を高め、通信チャネル容量をより有効活用するために、パイプライン処理が使用されます。

パイプラインを使用すると、次のような結果が得られます。

• 送信されたすべてのパケット (再送信を除く) を一意に識別する必要があるため、シーケンス番号の範囲を拡大します。
• 送信側と受信側のバッファを増やす必要がある。

シーケンス番号の範囲とバッファ サイズの要件は、パケットの破損、損失、遅延に応じてプロトコルが実行するアクションによって異なります。パイプラインの場合、エラーを修正するには 2 つの方法があります。

• N 個のパケットを返します。
• 選択的な繰り返し。

N パケットを遡る - スライディング ウィンドウ プロトコル

送信者は次の 3 種類のイベントをサポートする必要があります。

• 上位レベルのプロトコルによる呼び出し。データ送信関数が「上から」呼び出されると、送信側はまずウィンドウの埋まり具合（つまり、受信の受信を待っている N 個の送信メッセージの存在）をチェックします。ウィンドウが空の場合、新しいパケットが生成されて送信され、変数値が更新されます。それ以外の場合、送信側は上位層にデータを返します。これは、ウィンドウがいっぱいであることを暗黙的に示します。通常、上位層はしばらくしてから再度データの送信を試みます。実際のアプリケーションでは、送信側はデータを (すぐに送信するのではなく) バッファリングするか、ウィンドウが空の場合にのみ上位層が送信関数を呼び出せるようにする同期メカニズム (セマフォやフラグなど) を備えている可能性があります。 。
• 確認を受け取ります。このプロトコルでは、シーケンス番号 N のパケットについて、N より前のシーケンス番号を持つすべてのパケットが正常に受信されたことを示す一般確認応答が発行されます。
• 待機期間が終了しました。パケットと受信の損失と遅延の事実を判断するために、プロトコルはタイマーを使用します。タイムアウト間隔が経過すると、送信側は送信済みの未確認パケットをすべて再送信します。

選択的繰り返し

ウィンドウ サイズとスループットと伝播遅延の積が大きい場合、多数のパケットがパイプライン内に存在する可能性があります。このような場合、単一のパケット エラーにより、そのほとんどが不要な大量のパケットが再送信される可能性があります。

例

トップ 理論的 プラクティスは実際の実装で収集されます TCP。そして、誰かがその方法を最もよく知っているとしたら - 歓迎.

Сервер

package main

import (
    "bufio"
    "fmt"
    "log"
    "net"
    "strings"
)

func main() {
    // создаем сокет с портом 
    ln, err := net.Listen("tcp", ":8081")
    if err != nil {
        log.Fatalln(err)
    }
    // ожидание вызова
    conn, _ := ln.Accept()

    for {
        // считывание данных
        msg, err := bufio.NewReader(conn).ReadString('n')
        if err != nil {
            log.Fatalln(err)
        }
        // вывод сообщения в stdout
        fmt.Print("Message Received:", string(msg))
        // перевод строки в верхний регистр
        newMsg := strings.ToUpper(msg)
        // отправка данных
        conn.Write([]byte(newMsg + "n"))
    }
}

クライアント

package main

import (
    "bufio"
    "fmt"
    "log"
    "net"
    "os"
)

func main() {
    // установка соединения
    conn, err := net.Dial("tcp", "127.0.0.1:8081")
    if err != nil {
        log.Fatalln(err)
    }

    for {
        // считывание данных с stdin
        reader := bufio.NewReader(os.Stdin)
        fmt.Print("Text to send: ")
        // построчно
        text, err := reader.ReadString('n')
        if err != nil {
            log.Fatalln(err)
        }
        // отправка
        fmt.Fprintf(conn, text+"n")
        // прием
        msg, err := bufio.NewReader(conn).ReadString('n')
        if err != nil {
            log.Fatalln(err)
        }
        // вывод полученного ответа
        fmt.Print("Msg from Server: " + msg)
    }
}

出力

信頼性の高いデータ転送と使用を保証するメカニズム

Механизм
申し込み・コメント

チェックサム
送信パケット内のビットエラーを検出するために使用されます

タイマー
タイムアウト間隔をカウントダウンし、期限切れになったことを示します。後者は、高い確率でパケットまたはその受信が送信中に失われることを意味します。パケットが遅延して配信されたものの、失われていない場合（タイムアウト間隔の早期期限切れ）、または受信が失われた場合、再送信により受信側でパケットが重複します。

シリアルナンバー
送信者から受信者に送信されるデータ パケットの連続番号付けに使用されます。受信パケットのシーケンス番号のギャップにより、受信側はパケット損失を検出できます。同じパケット シーケンス番号は、パケットが互いに重複していることを意味します。

確認
受信側によって生成され、対応するパケットまたはパケットのグループが正常に受信されたことを送信側に示します。通常、確認応答には、正常に受信されたパケットのシーケンス番号が含まれます。プロトコルに応じて、個人とグループの確認が区別されます

陰性確認
パケットが正しく受信されなかったことを受信者が送信者に通知するために使用されます。否定応答には通常、正しく受信されなかったパケットのシーケンス番号が含まれます。

窓、コンベア化
パケットの送信に使用できるシーケンス番号の範囲を制限します。マルチキャストとハンドシェイクは、確認応答を待つ場合と比較して、プロトコルのスループットを大幅に向上させることができます。これから説明するように、ウィンドウ サイズは、受信側の受信能力とバッファリング能力、およびネットワーク負荷レベルに基づいて計算できます。

ネットワーキングに Go を使用するその他の例

В リポジトリ.

出所： habr.com