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

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

간단히

이 기사에서는 안정적인 데이터 전송의 기본 사항을 논의하고 이에 대한 예를 구현합니다. GoUDP와 TCP를 포함합니다. 기반으로 시간, два, 세 그리고 "컴퓨터 네트워크: 상향식 접근법"이라는 책이 있는데, 그 외에는 모두가 탄넨바움과 올리페로프에 대해서만 논의합니다.

전송 계층 프로토콜

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

전송 계층 프로토콜 최종 시스템에서는 지원되지만 네트워크 라우터에서는 지원되지 않음(예외 - 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(Automatic Repeat reQuest) 프로토콜이라고 합니다.
또한, 수신자가 마지막 패킷의 전송 결과에 대한 정보를 전혀 받지 못할 경우 영수증에 오류가 있을 가능성을 고려해 볼 가치가 있습니다.
이 문제를 해결하기 위한 방법은 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