Чтение поврежденных данных из сокета TCP в Ubuntu Linux

У меня такое же поведение (если клиент запускается с ключом -f [--fragments]) с реализацией сервера python3 и исходным клиентом в C. И только начало последовательности (1-й фрагмент?) всегда теряется.

#!/usr/bin/env python3

import threading
import socketserver

assert "__main__" == __name__

_mutex = threading.Lock()
_expected = "55aa55aa785634127856341278563412"

class _Handler(socketserver.BaseRequestHandler):
    def handle(self):
        _data = list()
        while True:
            _chunk = self.request.recv(1024)
            if not _chunk: break
            _data.append(_chunk)
        _data = bytes().join(_data).hex()
        if _expected == _data: return
        if _expected.endswith(_data): _case = "head case"
        else: _case = "other case"
        with _mutex: print(f"{_case}: {_data}", flush = True)

class _Server(socketserver.ThreadingMixIn, socketserver.TCPServer): pass

with _Server(("localhost", 5050), _Handler) as _server:
    _server.allow_reuse_address = True
    _server.serve_forever()

Короче говоря: я думаю, что SYN-cookies являются корнем проблемы.

Я не знаю, является ли полученное поведение («сломанный» первый вызов recv после accept) ошибкой ядра. Насколько я понимаю, функция SYN-cookies позволяет «принять» клиента так, чтобы он ничего не заметил, но это может создать проблемы для серверного приложения. Однако у меня нет однозначного ответа на вопрос, почему такое поведение включено в политику по умолчанию. Ваш клиент похож на сетевого злоумышленника =).

Возможно полезные ссылки:

• https://access.redhat.com/solutions/30453
• https://man7.org/linux/man-pages/man7/tcp.7.html (там ctrl+f tcp_syncookies)

Мне показалось довольно странным, что исчезает только начало последовательности... Далее я проверил dmesg и увидел это:

TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:5050. Sending cookies.

Далее отключаю его (насколько я знаю, в продакшене это не рекомендуется):

sudo sysctl net.ipv4.tcp_syncookies=0

После этого «повреждение данных» исчезло.

Следующее изменение в server.c:114 также исправляет это:

--- a/server.c
+++ b/server.c
-    res = listen(listenfd, 5);
+    res = listen(listenfd, 8192);

https://man7.org/linux/man-pages/man2/listen.2.html

Кроме того, обновление логики client с использованием функции MSG_MORE (только для Linux, https://man7.org/linux/man-pages/man2/sendto.2.html) решает проблему, поскольку снижает нагрузку, позволяя серверу «перехватывать» начало данных. Что наводит на странные мысли о том, что в этом механизме защиты операционной системы есть ошибка. Я не понимаю, почему в случае перегрузки сервера поведение по умолчанию не «отклонять запросы на подключение до тех пор, пока они не будут готовы».

на первый взгляд здесь аналогичная проблема: https://wpbolt.com/syn-cookies-ate-my-dog-breaking-tcp-on-linux/

но в нашем случае в Wireshark см. подтверждение всех пакетов данных. это все еще похоже на ошибку ядра.

Чтобы воспроизвести эту ошибку, не обязательно открывать большое количество TCP-соединений. 10 достаточно.
Схематически это можно воспроизвести следующим образом:

запустить сервер

...
listenfd = socket(...  
res = bind(listenfd, ...  
res = listen(listenfd, 1); !!! backlog set 1  
wait user key press (need wait add socket to backlog queue)

запустить клиент
запустите 10 потоков с:

fd = socket(... 
z = setsockopt(fd, SOL_TCP, TCP_NODELAY, &one, sizeof(one)); 
connect(fd ...  
for(int i=0;i<28;i++)  
    send(fd, &buff[i], 1, 0);  
recv()  

9 TCP-потоков попадают в очередь на стороне сервера и начинают повторную отправку SYN с увеличивающимися интервалами.

на стороне сервера нажмите Enter, чтобы разблокировать и

while(1)
  select([listenfd, socketN])
  listenfd: new connection
     accept(...) 
     add to socketN
  socketN: new data
     recv()

В результате первые байты данных в нескольких TCP-соединениях будут потеряны. Такое поведение наблюдается в Ubuntu 24.04 с ядром 6.10.2.

Воспроизводится с небольшим количеством TCP-соединений на debian trixie amd64 с python3.

#!/usr/bin/env python3

import sys
import time
import socket
import threading
import traceback
import concurrent.futures

assert "__main__" == __name__

_delay = +5.0e+0  # instead press any key
_streams = 16  # or `10` like in @Drepin7 answer
_host, _port = "localhost", 5050

_expected = bytes().join((
    bytes.fromhex("55aa") * 2,
    bytes.fromhex("785634127856341278563412") * 32
))


def _request(key):
    try:
        _data = _expected
        with socket.socket(
            socket.AF_INET, socket.SOCK_STREAM
        ) as _socket:
            # `TCP_NODELAY` not required for reproduce
            # _socket.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
            _socket.connect((_host, _port))
            _address = _socket.getsockname()
            _address = _address[1]  # bound port
            key = f"{key}#{_address}"
            print(f"{key} connected", file = sys.stderr, flush = True)
            while _data:
                _socket.sendall(_data[:2])
                _data = _data[2:]

    except BaseException:
        print(
            traceback.format_exc().strip(),
            file = sys.stderr, flush = True
        )
        raise

    finally: return key


def _server():
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as _socket:
        _socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        _socket.bind((_host, _port))
        _socket.listen(1)  # backlog = 1
        time.sleep(_delay)

        print(
            f"server started after delay = {_delay}",
            file = sys.stderr, flush = True
        )

        while True:
            _data = bytes()

            _connection, _address = _socket.accept()
            _address = _address[1]  # remote port
            print(f"{_address} accepted", file = sys.stderr, flush = True)

            try:
                with _connection:
                    while len(_expected) > len(_data):
                        _chunk = _connection.recv(len(_expected) - len(_data))
                        if not _chunk: break
                        _data += _chunk
                if _expected == _data: return
                if _expected.endswith(_data): _case = "head case"
                else: _case = "other case"
                print(
                    f"{_case} [{_address}]: {_data.hex()}",
                    file = sys.stdout, flush = True
                )

            except BaseException:
                print(
                    traceback.format_exc().strip(),
                    file = sys.stderr, flush = True
                )
                raise

            finally: continue


threading.Thread(target = _server, daemon = True).start()

with concurrent.futures.ProcessPoolExecutor(max_workers = _streams) as _pool:
    for _client in _pool.map(_request, range(_streams)): print(
        f"request finished: {_client}", flush = True, file = sys.stderr
    )

Те же проблемы с потерей головы запроса на стороне сервера и

TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:5050. Sending cookies.

Конечно, после sudo sysctl net.ipv4.tcp_syncookies=0 оно исчезло.

На данный момент это все больше похоже на ошибку ядра.