ພື້ນຖານຂອງການໂອນຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້

ແກ່ຜູ້ທີ່ ສະແຫວງຫາ ອຸທິດຕົນເພື່ອຄວາມເຂົ້າໃຈເຄືອຂ່າຍແລະໂປໂຕຄອນ.

ໄລຍະສັ້ນໆ

ບົດຄວາມສົນທະນາພື້ນຖານຂອງການສົ່ງຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້, ປະຕິບັດຕົວຢ່າງກ່ຽວກັບ Go, ລວມທັງ UDP ແລະ TCP. ອີງໃສ່ ເວລາ, два, ສາມ ແລະປຶ້ມ "ເຄືອຂ່າຍຄອມພິວເຕີ. ວິທີການເທິງລົງລຸ່ມ", ຖ້າບໍ່ດັ່ງນັ້ນທຸກຄົນແມ່ນສົນທະນາພຽງແຕ່ Tannenbaum ແລະ Oliferov.

ໂປຣໂຕຄໍຊັ້ນການຂົນສົ່ງ

ສະຫນອງການເຊື່ອມຕໍ່ຢ່າງມີເຫດຜົນລະຫວ່າງຂະບວນການແອັບພລິເຄຊັນທີ່ເຮັດວຽກຢູ່ໃນໂຮດທີ່ແຕກຕ່າງກັນ. ຈາກທັດສະນະຂອງແອັບພລິເຄຊັນ, ການເຊື່ອມຕໍ່ທີ່ມີເຫດຜົນເບິ່ງຄືວ່າເປັນຊ່ອງທາງທີ່ເຊື່ອມຕໍ່ໂດຍກົງກັບຂະບວນການຕ່າງໆ.

ໂປຣໂຕຄໍຊັ້ນການຂົນສົ່ງ ໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍລະບົບ end, ແຕ່ບໍ່ແມ່ນ routers ເຄືອຂ່າຍ (ຍົກເວັ້ນ - DPI). ໃນດ້ານຜູ້ສົ່ງ, ຊັ້ນການຂົນສົ່ງຈະປ່ຽນຂໍ້ມູນຊັ້ນຄໍາຮ້ອງສະຫມັກທີ່ມັນໄດ້ຮັບຈາກຂະບວນການສົ່ງຄໍາຮ້ອງສະຫມັກເຂົ້າໄປໃນຊຸດຊັ້ນການຂົນສົ່ງທີ່ເອີ້ນວ່າ segments.

ນີ້ແມ່ນເຮັດໄດ້ໂດຍການແຍກ (ຖ້າຈໍາເປັນ) ຂໍ້ຄວາມຊັ້ນຄໍາຮ້ອງສະຫມັກເຂົ້າໄປໃນ fragments ແລະເພີ່ມ header ຊັ້ນການຂົນສົ່ງກັບແຕ່ລະຄົນຂອງເຂົາເຈົ້າ.

ຫຼັງຈາກນັ້ນ, ຊັ້ນການຂົນສົ່ງຈະຜ່ານ segment ໄປຫາຊັ້ນເຄືອຂ່າຍຂອງຜູ້ສົ່ງ, ບ່ອນທີ່ segment ໄດ້ຖືກ encapsulated ໃນ packet ຊັ້ນເຄືອຂ່າຍ (datagram) ແລະສົ່ງ. ໃນຕອນທ້າຍຂອງການຮັບ, ຊັ້ນເຄືອຂ່າຍສະກັດສ່ວນຊັ້ນການຂົນສົ່ງຈາກ datagram ແລະສົ່ງມັນເຖິງຊັ້ນການຂົນສົ່ງ. ຕໍ່ໄປ, ຊັ້ນການຂົນສົ່ງຈະປະມວນຜົນສ່ວນທີ່ໄດ້ຮັບເພື່ອໃຫ້ຂໍ້ມູນຂອງມັນສາມາດໃຊ້ໄດ້ກັບແອັບພລິເຄຊັນທີ່ໄດ້ຮັບ.

ຫຼັກການຂອງການສົ່ງຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້

ການສົ່ງຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ຜ່ານຊ່ອງທາງທີ່ປອດໄພຢ່າງສົມບູນ

ກໍລະນີທີ່ງ່າຍດາຍທີ່ສຸດ. ດ້ານການສົ່ງພຽງແຕ່ໄດ້ຮັບຂໍ້ມູນຈາກຊັ້ນເທິງ, ສ້າງຊຸດທີ່ມີມັນ, ແລະສົ່ງມັນໄປຫາຊ່ອງທາງ.

Server

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

ການສົ່ງຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ຜ່ານຊ່ອງທີ່ມີຄວາມຜິດພາດທີ່ເປັນໄປໄດ້

ຂັ້ນຕອນຕໍ່ໄປແມ່ນການສົມມຸດວ່າແພັກເກັດທີ່ຖືກສົ່ງທັງຫມົດແມ່ນໄດ້ຮັບໃນຄໍາສັ່ງທີ່ພວກມັນຖືກສົ່ງ, ແຕ່ບິດໃນພວກມັນອາດຈະຖືກທໍາລາຍຍ້ອນຄວາມຈິງທີ່ວ່າບາງຄັ້ງຊ່ອງທາງການສົ່ງຂໍ້ມູນທີ່ມີການບິດເບືອນ.

ໃນກໍລະນີດັ່ງກ່າວນີ້, ກົນໄກດັ່ງຕໍ່ໄປນີ້ຖືກນໍາໃຊ້:

• ການ​ກວດ​ສອບ​ຄວາມ​ຜິດ​ພາດ​;
• ຄໍາຄຶດຄໍາເຫັນ;
• retransmission.

ໂປໂຕຄອນການໂອນຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ທີ່ມີກົນໄກທີ່ຄ້າຍຄືກັນສໍາລັບການສົ່ງຄືນໃຫມ່ຫຼາຍຄັ້ງແມ່ນເອີ້ນວ່າໂປໂຕຄອນ repeat reQuest (ARQ) ອັດຕະໂນມັດ.
ນອກຈາກນັ້ນ, ມັນເປັນມູນຄ່າທີ່ຈະພິຈາລະນາຄວາມເປັນໄປໄດ້ຂອງຄວາມຜິດພາດໃນໃບຮັບເງິນ, ໃນເວລາທີ່ຝ່າຍຮັບຈະບໍ່ໄດ້ຮັບຂໍ້ມູນໃດໆກ່ຽວກັບຜົນໄດ້ຮັບຂອງການໂອນຊອງສຸດທ້າຍ.
ການແກ້ໄຂບັນຫານີ້, ຍັງໃຊ້ໃນ TCP, ແມ່ນການເພີ່ມພາກສະຫນາມໃຫມ່ໃສ່ຊຸດຂໍ້ມູນທີ່ມີຈໍານວນລໍາດັບຂອງແພັກເກັດ.

ການສົ່ງຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ຜ່ານຊ່ອງທີ່ບໍ່ຫນ້າເຊື່ອຖືໄດ້ຂຶ້ນກັບການບິດເບືອນຂອງແພັກເກັດແລະການສູນເສຍ

ຄຽງຄູ່ກັບການບິດເບືອນ, ແຕ່ຫນ້າເສຍດາຍ, ມີການສູນເສຍແພັກເກັດໃນເຄືອຂ່າຍ.
ແລະເພື່ອແກ້ໄຂບັນຫານີ້, ກົນໄກແມ່ນຕ້ອງການ:

• ການກໍານົດຄວາມເປັນຈິງຂອງການສູນເສຍແພັກເກັດ;
• ການຈັດສົ່ງຊຸດທີ່ສູນເສຍໄປໃຫ້ຜູ້ຮັບ.

ນອກຈາກນັ້ນ, ນອກເຫນືອຈາກການສູນເສຍຊຸດ, ມັນຈໍາເປັນຕ້ອງສະຫນອງຄວາມເປັນໄປໄດ້ຂອງການສູນເສຍໃບຮັບເງິນຫຼື, ຖ້າບໍ່ມີຫຍັງສູນເສຍ, ການຈັດສົ່ງຂອງມັນມີຄວາມຊັກຊ້າຢ່າງຫຼວງຫຼາຍ. ໃນທຸກກໍລະນີ, ສິ່ງດຽວກັນແມ່ນເຮັດ: ຊຸດໄດ້ຖືກສົ່ງຄືນ. ເພື່ອຄວບຄຸມເວລາ, ກົນໄກນີ້ໃຊ້ເຄື່ອງຈັບເວລານັບຖອຍຫຼັງ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດຈຸດສິ້ນສຸດຂອງໄລຍະລໍຖ້າ. ດັ່ງນັ້ນໃນຊຸດ ສຸດທິ TCPKeepAlive ຖືກຕັ້ງເປັນ 15 ວິນາທີຕາມຄ່າເລີ່ມຕົ້ນ:

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

ດ້ານການສົ່ງຕ້ອງເລີ່ມຈັບເວລາທຸກຄັ້ງທີ່ແພັກເກັດຖືກສົ່ງ (ທັງຄັ້ງທຳອິດ ແລະຄັ້ງທີສອງ), ຈັດການການລົບກວນຈາກເຄື່ອງຈັບເວລາ ແລະຢຸດມັນ.

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຄຸ້ນເຄີຍກັບແນວຄວາມຄິດທີ່ສໍາຄັນຂອງໂປໂຕຄອນການໂອນຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້:

• checksums;
• ເລກລໍາດັບຂອງຊຸດ;
• ເຄື່ອງຈັບເວລາ;
• ໃບຮັບເງິນໃນທາງບວກແລະທາງລົບ.

ແຕ່ນັ້ນບໍ່ແມ່ນທັງຫມົດ!

ອະນຸສັນຍາການໂອນຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ດ້ວຍການວາງທໍ່

ໃນຕົວແປທີ່ພວກເຮົາໄດ້ພິຈາລະນາແລ້ວ, ໂປໂຕຄອນການຈັດສົ່ງທີ່ເຊື່ອຖືໄດ້ແມ່ນບໍ່ມີປະສິດທິພາບຫຼາຍ. ມັນເລີ່ມຕົ້ນທີ່ຈະ "ຊ້າລົງ" ການຖ່າຍທອດທີ່ສະຫນອງໂດຍຊ່ອງທາງການສື່ສານຍ້ອນວ່າ RTT ເພີ່ມຂຶ້ນ. ເພື່ອເພີ່ມປະສິດຕິພາບຂອງມັນແລະນໍາໃຊ້ຄວາມສາມາດຂອງຊ່ອງທາງການສື່ສານທີ່ດີກວ່າ, ທໍ່ແມ່ນຖືກນໍາໃຊ້.

ການ​ນໍາ​ໃຊ້​ທໍ່​ນໍາ​ໄປ​ສູ່​ການ​:

• ການເພີ່ມລະດັບຂອງຕົວເລກລໍາດັບ, ນັບຕັ້ງແຕ່ແພັກເກັດທີ່ສົ່ງທັງຫມົດ (ຍົກເວັ້ນການສົ່ງຄືນ) ຕ້ອງໄດ້ຮັບການກໍານົດເປັນເອກະລັກ;
• ຄວາມຕ້ອງການທີ່ຈະເພີ່ມທະວີການ buffers ໃນດ້ານສົ່ງແລະຮັບ.

ຊ່ວງເລກລຳດັບ ແລະຄວາມຕ້ອງການຂະໜາດຂອງບັຟເຟີແມ່ນຂຶ້ນກັບການກະທຳທີ່ໂປຣໂຕຄໍເຮັດເພື່ອຕອບສະໜອງຕໍ່ການສໍ້ລາດບັງຫຼວງຂອງແພັກເກັດ, ການສູນເສຍ, ແລະຄວາມລ່າຊ້າ. ໃນກໍລະນີຂອງທໍ່, ມີສອງວິທີການແກ້ໄຂຂໍ້ຜິດພາດ:

• return N ແພັກເກັດຄືນ;
• ການຄ້າງຫ້ອງທີ່ເລືອກ.

ການກັບຄືນ N packets - sliding window protocol

ຜູ້ສົ່ງຕ້ອງສະຫນັບສະຫນູນສາມປະເພດຂອງເຫດການ:

• ໂທຫາໂດຍໂປໂຕຄອນລະດັບສູງກວ່າ. ເມື່ອຟັງຊັນການສົ່ງຂໍ້ມູນເອີ້ນວ່າ "ຈາກຂ້າງເທິງ", ຝ່າຍສົ່ງຈະກວດເບິ່ງລະດັບຂອງການຕື່ມຂໍ້ມູນຂອງປ່ອງຢ້ຽມ (ນັ້ນແມ່ນ, ການປະກົດຕົວຂອງ N ຂໍ້ຄວາມທີ່ສົ່ງມາລໍຖ້າການໄດ້ຮັບໃບຮັບເງິນ). ຖ້າປ່ອງຢ້ຽມຫວ່າງເປົ່າ, ແພັກເກັດໃຫມ່ຖືກສ້າງຂື້ນແລະສົ່ງຕໍ່, ແລະຄ່າຕົວແປຈະຖືກປັບປຸງ. ຖ້າບໍ່ດັ່ງນັ້ນ, ດ້ານການສົ່ງຄືນຂໍ້ມູນໄປຫາຊັ້ນເທິງ, ແລະນີ້ແມ່ນຕົວຊີ້ບອກວ່າປ່ອງຢ້ຽມເຕັມ. ໂດຍປົກກະຕິຊັ້ນເທິງຈະພະຍາຍາມສົ່ງຂໍ້ມູນອີກເທື່ອຫນຶ່ງຫຼັງຈາກເວລາໃດຫນຶ່ງ. ໃນຄໍາຮ້ອງສະຫມັກທີ່ແທ້ຈິງ, ຜູ້ສົ່ງອາດຈະຂັດຂວາງຂໍ້ມູນ (ແທນທີ່ຈະສົ່ງທັນທີ) ຫຼືມີກົນໄກການ synchronization (ເຊັ່ນ Semalt ຫຼືທຸງ) ທີ່ຈະຊ່ວຍໃຫ້ຊັ້ນເທິງໂທຫາຫນ້າທີ່ສົ່ງພຽງແຕ່ເມື່ອປ່ອງຢ້ຽມຫວ່າງເປົ່າ. .
• ໄດ້​ຮັບ​ການ​ຢືນ​ຢັນ​. ໃນໂປຣໂຕຄໍ, ສຳລັບແພັກເກັດທີ່ມີເລກລຳດັບ N, ການຮັບຮູ້ທົ່ວໄປແມ່ນອອກໂດຍຊີ້ບອກວ່າແພັກເກັດທັງໝົດທີ່ມີເລກລຳດັບກ່ອນໜ້າ N ແມ່ນໄດ້ຮັບສຳເລັດແລ້ວ.
• ໄລຍະລໍຖ້າໄດ້ໝົດອາຍຸແລ້ວ. ເພື່ອກໍານົດຄວາມເປັນຈິງຂອງການສູນເສຍແລະການຊັກຊ້າຂອງຊອງແລະໃບຮັບເງິນ, ໂປໂຕຄອນໃຊ້ເຄື່ອງຈັບເວລາ. ຖ້າຊ່ວງເວລາໝົດເວລາໝົດເວລາ, ຝ່າຍສົ່ງຈະສົ່ງແພັກເກັດທີ່ບໍ່ໄດ້ຮັບຮູ້ທັງໝົດທີ່ຖືກສົ່ງຄືນ.

ການຄ້າງຫ້ອງທີ່ເລືອກ

ເມື່ອຂະຫນາດຂອງປ່ອງຢ້ຽມແລະຜະລິດຕະພັນການຊັກຊ້າການຂະຫຍາຍພັນດ້ວຍຂະຫນາດໃຫຍ່, ຈໍານວນແພັກເກັດຈໍານວນຫລາຍອາດຈະຢູ່ໃນທໍ່. ໃນກໍລະນີດັ່ງກ່າວ, ຂໍ້ຜິດພາດຂອງແພັກເກັດດຽວອາດຈະເຮັດໃຫ້ຈໍານວນແພັກເກັດຖືກສົ່ງຄືນໃຫມ່, ເຊິ່ງສ່ວນໃຫຍ່ແມ່ນບໍ່ຈໍາເປັນຕ້ອງ.

ຕົວຢ່າງ:

ດີ​ທີ່​ສຸດ ທິດສະດີ ການປະຕິບັດໄດ້ຖືກເກັບກໍາໃນການປະຕິບັດຕົວຈິງ TCP. ແລະ​ຖ້າ​ຫາກ​ວ່າ​ຜູ້​ໃດ​ຜູ້​ຫນຶ່ງ​ຮູ້​ຈັກ​ດີ​ທີ່​ສຸດ - ຍິນດີຕ້ອນຮັບ.

Server

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

ສະຫລຸບ

ກົນໄກເພື່ອຮັບປະກັນການໂອນຂໍ້ມູນແລະການນໍາໃຊ້ທີ່ເຊື່ອຖືໄດ້

ກົນໄກ
ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​, ຄໍາ​ເຫັນ​

ກວດສອບລວມ
ໃຊ້ເພື່ອກວດຫາຂໍ້ຜິດພາດເລັກນ້ອຍໃນແພັກເກັດທີ່ສົ່ງຜ່ານ

ຈັບເວລາ
ນັບລົງໄລຍະໝົດເວລາ ແລະຊີ້ບອກເວລາທີ່ມັນໝົດອາຍຸ. ອັນສຸດທ້າຍຫມາຍຄວາມວ່າມີຄວາມເປັນໄປໄດ້ສູງ, ແພັກເກັດຫຼືໃບຮັບເງິນຂອງມັນສູນເສຍໃນລະຫວ່າງການສົ່ງ. ຖ້າແພັກເກັດຖືກຈັດສົ່ງດ້ວຍຄວາມລ່າຊ້າ, ແຕ່ບໍ່ໄດ້ເສຍ (ໝົດເວລາກ່ອນໄວອັນຄວນຂອງຊ່ວງເວລາໝົດເວລາ), ຫຼືໃບຮັບເງິນຫາຍໄປ, ການສົ່ງຕໍ່ຈະພາໃຫ້ແພັກເກັດຊໍ້າກັນຢູ່ດ້ານການຮັບ.

ialາຍເລກຊີຣຽວ
ໃຊ້ສໍາລັບການຈັດລຽງຕາມລໍາດັບຂອງຊຸດຂໍ້ມູນທີ່ຖືກສົ່ງຈາກຜູ້ສົ່ງໄປຫາຜູ້ຮັບ. ຊ່ອງຫວ່າງໃນຕົວເລກລໍາດັບຂອງແພັກເກັດທີ່ໄດ້ຮັບອະນຸຍາດໃຫ້ຜູ້ຮັບສາມາດກວດພົບການສູນເສຍແພັກເກັດ. ເລກລຳດັບແພັກເກັດດຽວກັນໝາຍຄວາມວ່າແພັກເກັດນັ້ນຊໍ້າກັນ

ການຢືນຢັນ
ສ້າງຂຶ້ນໂດຍຈຸດຮັບ ແລະຊີ້ໃຫ້ເຫັນເຖິງຈຸດສົ່ງທີ່ແພັກເກັດທີ່ສອດຄ້ອງກັນ ຫຼືກຸ່ມຂອງແພັກເກັດໄດ້ຮັບສຳເລັດແລ້ວ. ໂດຍປົກກະຕິການຮັບຮູ້ປະກອບມີຕົວເລກລໍາດັບຂອງຊຸດທີ່ໄດ້ຮັບຜົນສໍາເລັດ. ອີງຕາມພິທີການ, ການຢືນຢັນຂອງບຸກຄົນ ແລະກຸ່ມແມ່ນຈໍາແນກໄດ້

ການຢືນຢັນທາງລົບ
ໃຊ້ໂດຍຜູ້ຮັບເພື່ອແຈ້ງໃຫ້ຜູ້ສົ່ງຮູ້ວ່າແພັກເກັດໄດ້ຮັບບໍ່ຖືກຕ້ອງ. ໂດຍທົ່ວໄປແລ້ວການຮັບຮູ້ທາງລົບປະກອບມີຈໍານວນຊຸດຂອງຊຸດທີ່ບໍ່ໄດ້ຮັບຢ່າງຖືກຕ້ອງ

ປ່ອງຢ້ຽມ, conveyorization
ຈໍາ​ກັດ​ລະ​ດັບ​ຂອງ​ຕົວ​ເລກ​ລໍາ​ດັບ​ທີ່​ສາ​ມາດ​ນໍາ​ໃຊ້​ເພື່ອ​ສົ່ງ​ຊອງ​ໄດ້​. Multicast ແລະ handshake ສາມາດເພີ່ມການສົ່ງຜ່ານໂປໂຕຄອນຢ່າງຫຼວງຫຼາຍເມື່ອທຽບກັບການລໍຖ້າການຮັບຮູ້. ດັ່ງທີ່ພວກເຮົາຈະເຫັນ, ຂະຫນາດປ່ອງຢ້ຽມສາມາດຖືກຄິດໄລ່ໂດຍອີງໃສ່ຄວາມສາມາດຮັບແລະ buffering ຂອງຈຸດຮັບ, ເຊັ່ນດຽວກັນກັບລະດັບການໂຫຼດເຄືອຂ່າຍ.

ຕົວຢ່າງເພີ່ມເຕີມຂອງການໃຊ້ Go ສໍາລັບເຄືອຂ່າຍ

В ຄັງເກັບມ້ຽນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com