> В каком формате передаются данные по сети (Go)

Короткий ответ

По сети данные передаются в виде последовательности байтов, организованных в соответствии с протоколами стека TCP/IP. На прикладном уровне - это структурированные форматы: JSON, Protobuf, gRPC, HTTP-сообщения. На транспортном уровне - сегменты TCP или дейтаграммы UDP. На сетевом - IP-пакеты. Формат определяет сериализация и протокол, а не сам канал передачи.

Подробное объяснение

Стек протоколов - это уровни абстракции, каждый добавляет свой заголовок к данным:

• Прикладной уровень - формат данных, понятный приложению: JSON, XML, Protobuf, MessagePack, а также семантика HTTP/2, gRPC, WebSocket.
• Транспортный уровень - TCP добавляет sequence number, port, flags; UDP - только port и length. Здесь данные - это поток байтов (TCP) или дейтаграммы (UDP).
• Сетевой уровень - IP-пакет: source/destination IP, TTL, protocol type.
• Канальный уровень - Ethernet-кадр: MAC-адреса, CRC.

В Go на практике чаще всего работают с:

• JSON - стандартный encoding/json, удобен для REST, но медленный и неэффективный по размеру.
• Protobuf - google.golang.org/protobuf, бинарный, компактный, требует .proto-контрактов, используется в gRPC.
• gRPC - поверх HTTP/2, потоковая передача, multiplexing, бинарные сообщения.
• MessagePack - бинарный JSON-подобный, быстрее JSON, но менее распространён.

Важно понимать: "формат передачи" - это не только сериализация, но и framing (как понять, где заканчивается одно сообщение и начинается другое). Для TCP-стрима нужен delimiter (например, \n), length-prefix или использование HTTP/gRPC, которые решают framing на уровне протокола.

На практике

В Go-сервисах выбор формата зависит от контекста:

• Внутренние микросервисы - gRPC + Protobuf: строгая типизация, schema evolution, низкая задержка.
• Внешние API - JSON: совместимость, читаемость, простота отладки.
• Высоконагруженные системы - бинарные форматы, часто с сжатием (gzip, snappy) поверх.
• Streaming - chunked transfer encoding, WebSocket, gRPC streams.

Для TCP-соединений в Go важно помнить про bufio.Reader, io.ReadFull для length-prefixed сообщений, и про то, что TCP не сохраняет границы сообщений - это задача приложения.

Пример кода

GO
// length-prefixed framing поверх TCP
type Message struct {
    Type string `json:"type"`
    Data []byte `json:"data"`
}

func writeMessage(w io.Writer, msg Message) error {
    payload, err := json.Marshal(msg)
    if err != nil {
        return err
    }
    // 4 байта длины + payload
    if err := binary.Write(w, binary.BigEndian, uint32(len(payload))); err != nil {
        return err
    }
    _, err = w.Write(payload)
    return err
}

func readMessage(r io.Reader) (Message, error) {
    var msg Message
    var length uint32
    if err := binary.Read(r, binary.BigEndian, &length); err != nil {
        return msg, err
    }
    buf := make([]byte, length)
    if _, err := io.ReadFull(r, buf); err != nil {
        return msg, err
    }
    err := json.Unmarshal(buf, &msg)
    return msg, err
}

Как отвечать на собеседовании

Начни с уровней стека, затем переходи к прикладным форматам. Упомяни framing - это показывает понимание проблем TCP. Сравни JSON и Protobuf по критериям: скорость сериализации, размер, совместимость версий, читаемость. Если спросят про gRPC - объясни, что это не формат, а RPC-фреймворк поверх HTTP/2, который использует Protobuf по умолчанию.

Покажи осведомлённость о trade-off: JSON - простой, но медленный; Protobuf - быстрый, но требует генерации кода и контрактов. Для senior важно упомянуть про schema evolution (как добавлять поля без breaking changes) и про сжатие на уровне транспорта.

Что проверяет интервьюер

• Понимание сетевого стека, а не только "JSON по HTTP".
• Знание framing и проблем TCP-стрима.
• Умение выбирать формат под задачу, а не "всегда JSON".
• Практический опыт с Go-инструментарием: encoding/json, protobuf, bufio.
• Понимание trade-off между бинарными и текстовыми форматами.

Типичные ошибки

• Ответ "данные передаются в JSON" - слишком узко, не показывает понимание уровней.
• Игнорирование framing - "просто пишем в сокет" без объяснения, как читатель поймёт границы сообщения.
• Путаница между HTTP и форматом данных - HTTP это протокол, JSON это формат.
• Утверждение, что TCP сохраняет границы сообщений - это не так, TCP - поток байтов.
• Незнание разницы между сериализацией и кодированием - например, UTF-8 это кодировка, JSON это формат сериализации.