안정적인 데이터 전송의 기본

하는 분들에게 추구하다 네트워크와 프로토콜을 이해하는 데 전념합니다.

간단히

이 기사에서는 안정적인 데이터 전송의 기본 사항을 논의하고 이에 대한 예제를 구현합니다. Go, UDP 및 TCP를 포함합니다. 기반 시간, два, 세 그리고 "Computer Networks. Top-Down Approach"라는 책이 있습니다. 그렇지 않으면 모든 사람들이 Tannenbaum과 Oliferov에 대해서만 논의하고 있습니다.

전송 계층 프로토콜

서로 다른 호스트에서 실행되는 애플리케이션 프로세스 간의 논리적 연결을 제공합니다. 애플리케이션 관점에서 보면 논리적 연결은 프로세스를 직접 연결하는 채널처럼 보입니다.

전송 계층 프로토콜 최종 시스템에서는 지원되지만 네트워크 라우터에서는 지원되지 않습니다(예외: 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에서도 사용되는 이 문제에 대한 해결책은 패킷의 시퀀스 번호를 포함하는 데이터 패킷에 새 필드를 추가하는 것입니다.

패킷 왜곡 및 손실이 발생할 수 있는 신뢰할 수 없는 채널을 통한 안정적인 데이터 전송

불행하게도 왜곡과 함께 네트워크에 패킷 손실이 발생합니다.
그리고 이 문제를 해결하려면 다음과 같은 메커니즘이 필요합니다.

• 패킷 손실 사실을 결정하고;
• 손실된 패킷을 수신자에게 다시 전달합니다.

또한, 패키지 분실 외에도 영수증 분실 가능성에 대비해야 하며, 분실된 것이 없는 경우 배송이 상당히 지연될 수 있습니다. 모든 경우에 동일한 작업이 수행됩니다. 즉, 패킷이 재전송됩니다. 시간을 제어하기 위해 이 메커니즘은 대기 간격의 끝을 결정할 수 있는 카운트다운 타이머를 사용합니다. 그래서 패키지에 그물 TCPKeepAlive는 기본적으로 15초로 설정됩니다.

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

송신 측은 패킷이 전송될 때마다(첫 번째와 두 번째 모두) 타이머를 시작하고 타이머의 중단을 처리하고 중지해야 합니다.

따라서 우리는 신뢰할 수 있는 데이터 전송 프로토콜의 주요 개념에 익숙해졌습니다.

• 체크섬;
• 패키지의 순서 번호;
• 타이머;
• 긍정적이고 부정적인 영수증.

하지만 그게 전부가 아닙니다!

파이프라이닝을 통한 안정적인 데이터 전송 프로토콜

우리가 이미 고려한 변형에서는 신뢰할 수 있는 전달 프로토콜이 매우 비효율적입니다. RTT가 증가함에 따라 통신 채널에서 제공하는 전송 속도가 "느려지기" 시작합니다. 효율성을 높이고 통신 채널 용량을 더 잘 활용하기 위해 파이프라이닝이 사용됩니다.

파이프라이닝을 사용하면 다음과 같은 이점이 있습니다.

• 전송된 모든 패킷(재전송 제외)을 고유하게 식별해야 하므로 시퀀스 번호의 범위를 늘립니다.
• 송신측과 수신측의 버퍼를 늘려야 할 필요성.

시퀀스 번호 범위와 버퍼 크기 요구 사항은 패킷 손상, 손실 및 지연에 대한 응답으로 프로토콜이 수행하는 작업에 따라 달라집니다. 파이프라이닝의 경우 오류를 수정하는 방법에는 두 가지가 있습니다.

• N 패킷을 다시 반환합니다.
• 선택적 반복.

N 패킷으로 돌아가기 - 슬라이딩 윈도우 프로토콜

발신자는 세 가지 유형의 이벤트를 지원해야 합니다.

• 더 높은 수준의 프로토콜로 호출합니다. 데이터 전송 기능이 "위에서" 호출되면 송신측에서는 먼저 윈도우가 채워지는 정도(즉, 수신 대기 중인 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