भरपर्दो डाटा ट्रान्सफरको आधारभूत कुराहरू

जो को लागी खोज्छ नेटवर्क र प्रोटोकल बुझ्न समर्पित।

संक्षिप्त

लेखले भरपर्दो डाटा ट्रान्समिशनको आधारभूत कुराहरू छलफल गर्दछ, उदाहरणहरू लागू गर्दछ Go, UDP र TCP सहित। मा आधारित पटक, два, तीन र पुस्तकहरू "कम्प्युटर नेटवर्कहरू। शीर्ष-डाउन दृष्टिकोण", अन्यथा सबैले मात्र Tannenbaum र Oliferov छलफल गरिरहेका छन्।

यातायात तह प्रोटोकल

विभिन्न होस्टहरूमा चलिरहेको अनुप्रयोग प्रक्रियाहरू बीच तार्किक जडान प्रदान गर्दछ। एप्लिकेसनको परिप्रेक्ष्यबाट, तार्किक जडान एक च्यानल जस्तो देखिन्छ जुन सीधा प्रक्रियाहरू जडान गर्दछ।

यातायात तह प्रोटोकलहरू अन्त प्रणालीहरू द्वारा समर्थित छन्, तर नेटवर्क राउटरहरू द्वारा होइन (बाहेक - डीपीआई)। प्रेषक पक्षमा, यातायात तहले पठाउने आवेदन प्रक्रियाबाट प्राप्त हुने एप्लिकेसन तह डाटालाई खण्ड भनिने यातायात तह प्याकेटहरूमा रूपान्तरण गर्दछ।

यो विभाजन गरेर (आवश्यक भएमा) एप्लिकेसन लेयर सन्देशहरूलाई टुक्राहरूमा विभाजन गरेर र ती प्रत्येकमा यातायात तह हेडर थपेर गरिन्छ।

त्यसपछि यातायात तहले खण्डलाई प्रेषकको नेटवर्क तहमा पठाउँछ, जहाँ खण्डलाई नेटवर्क तह प्याकेट (डाटाग्राम) मा इन्क्याप्सुलेटेड गरी पठाइन्छ। प्राप्त गर्ने अन्तमा, नेटवर्क तहले डाटाग्रामबाट यातायात तह खण्ड निकाल्छ र यसलाई यातायात तहमा पठाउँछ। अर्को, यातायात तहले प्राप्त खण्डलाई प्रशोधन गर्दछ ताकि यसको डाटा प्राप्त गर्ने अनुप्रयोगमा उपलब्ध हुन्छ।

विश्वसनीय डाटा प्रसारण को सिद्धान्त

एक पूर्ण सुरक्षित च्यानल मा विश्वसनीय डाटा प्रसारण

सबैभन्दा सरल मामला। पठाउने पक्षले केवल माथिल्लो तहबाट डाटा प्राप्त गर्दछ, यसलाई समावेश भएको प्याकेट सिर्जना गर्दछ, र यसलाई च्यानलमा पठाउँदछ।

सर्भर

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 अघिको अनुक्रम संख्याहरू भएका सबै प्याकेटहरू सफलतापूर्वक प्राप्त भएको जनाउने सामान्य स्वीकृति जारी गरिन्छ।
• प्रतीक्षा अन्तराल समाप्त भएको छ। घाटा र प्याकेट र रसिदहरूको ढिलाइको तथ्याङ्क निर्धारण गर्न, प्रोटोकलले टाइमर प्रयोग गर्दछ। यदि टाइमआउट अन्तराल समाप्त हुन्छ भने, पठाउने पक्षले सबै पठाइएका अपरिचित प्याकेटहरू पुन: पठाउँछ।

चयनात्मक पुनरावृत्ति

जब सञ्झ्याल आकार र थ्रुपुट-प्रसार ढिलाइ उत्पादन ठूलो हुन्छ, प्याकेटहरूको ठूलो संख्या पाइपलाइनमा हुन सक्छ। यस्तो अवस्थामा, एकल प्याकेट त्रुटिले ठूलो संख्यामा प्याकेटहरू पुन: प्रसारण हुन सक्छ, जसमध्ये धेरै जसो आवश्यक थिएन।

उदाहरण:

सबै भन्दा राम्रो सैद्धान्तिक अभ्यासहरू व्यावहारिक कार्यान्वयनमा सङ्कलन गरिन्छ टीसीपी। र यदि कसैलाई थाहा छ कसरी राम्रो - स्वागत.

सर्भर

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)
    }
}

निष्कर्षमा

भरपर्दो डाटा ट्रान्सफर र प्रयोग सुनिश्चित गर्न संयन्त्र

तंत्र
आवेदन, टिप्पणी

योगफल जाँच गर्नुहोस्
प्रसारित प्याकेटमा बिट त्रुटिहरू पत्ता लगाउन प्रयोग गरिन्छ

टाइमर
टाइमआउट अन्तराल गणना गर्दछ र यो कहिले समाप्त भएको संकेत गर्दछ। पछिल्लोको अर्थ हो कि उच्च स्तरको सम्भावनाको साथ प्याकेट वा यसको रसिद प्रसारणको क्रममा हराएको छ। यदि एक प्याकेट ढिलाइ संग डेलिभर गरिएको छ, तर हराएको छैन (टाइमआउट अन्तरालको समय भन्दा पहिले समाप्ति), वा रसिद हराएको छ, पुन: प्रसारण ले प्राप्त पक्षमा डुप्लिकेट प्याकेट निम्त्याउँछ।

क्रम संख्या
प्रेषकबाट प्राप्तकर्तामा पठाइएका डेटा प्याकेटहरूको क्रमिक संख्याको लागि प्रयोग गरिन्छ। प्राप्त प्याकेटहरूको अनुक्रम संख्यामा अन्तरले रिसीभरलाई प्याकेट हराएको पत्ता लगाउन अनुमति दिन्छ। एउटै प्याकेट अनुक्रम संख्याको अर्थ प्याकेटहरू एकअर्काको नक्कल हुन्

पुष्टिकरण
प्राप्त गर्ने अन्तद्वारा उत्पन्न गरिएको र पठाउने अन्तमा सम्बन्धित प्याकेट वा प्याकेटहरूको समूह सफलतापूर्वक प्राप्त भएको छ भनेर संकेत गर्दै। सामान्यतया स्वीकृतिले सफलतापूर्वक प्राप्त प्याकेटहरूको अनुक्रम संख्या समावेश गर्दछ। प्रोटोकलमा निर्भर गर्दै, व्यक्तिगत र समूह पुष्टिकरणहरू छुट्याइएको छ

नकारात्मक पुष्टि
प्याकेट गलत रूपमा प्राप्त भएको थियो भनेर प्रेषकलाई सूचित गर्न प्राप्तकर्ताद्वारा प्रयोग गरियो। नकारात्मक स्वीकृतिमा सामान्यतया प्याकेटको अनुक्रम संख्या समावेश हुन्छ जुन सही रूपमा प्राप्त भएको थिएन।

विन्डो, कन्वेयराइजेशन
अनुक्रम संख्याहरूको दायरा सीमित गर्नुहोस् जुन प्याकेटहरू प्रसारण गर्न प्रयोग गर्न सकिन्छ। मल्टिकास्ट र ह्यान्डशेकले स्वीकृतिहरूको प्रतीक्षाको तुलनामा प्रोटोकल थ्रुपुटलाई उल्लेखनीय रूपमा बढाउन सक्छ। हामी देख्नेछौं, विन्डोको आकार रिसेप्शन र प्राप्त गर्ने अन्तको बफरिङ क्षमताहरू, साथै नेटवर्क लोड स्तरको आधारमा गणना गर्न सकिन्छ।

नेटवर्किङका लागि गो प्रयोग गर्ने थप उदाहरणहरू

В भण्डारहरू.

स्रोत: www.habr.com