TCP and MTU

Человек врёт, учитывать не стоит.

А можно обосновать?

при вызове userspace функций read write, ведро всё сфрагментирует за тебя. Единственное с чем могут быть проблемы - передача джамб-датаграм в условиях интернета.

Максимальная длина IP-сообщения (с учетом заголовка) равна 65535 октетов

Фрагментацией по MTU занимается IP.

Можешь попробовать сделать send по TCP на 2Мб.

По UDP соответственно больше 64К-20 не пройдет

Пруфлинки - в википедии

Фрагментацией по MTU занимается IP.

а фрагментацией твоего send-а по max IP - ядро, т.к. TCP - это поток.

Щас доформулирую.

Например нужно передать 4kb. MTU 1500. Что будет работать быстрее, 3 write по 1024+1024+1024+1024 или 1 на 4kb или абсолютно перпендикулярно?

Оптимально, если размер порции полезных данных тютелька в тютельку влезает в MTU Ethernet без свободного места (к данным добавляются заголовки TCP, IP и Ethernet). Тогда принимающей стороне не придется буферизовать куски отдельных пакетов. Но это из области нереального.

То есть выгоднее всё таки 1024+1024+1024+1024?

>Например нужно передать 4kb. MTU 1500. Что будет работать быстрее, 3 write по 1024+1024+1024+1024 или 1 на 4kb или абсолютно перпендикулярно?

Считаю, 1 на 4kb

> Максимальная длина IP-сообщения (с учетом заголовка) равна 65535 октетов ...

это всё понятно, и IP и TCP и UDP.

>То есть выгоднее всё таки 1024+1024+1024+1024?

Чем 4x1024 выгоднее (1500-m) + (1500-m) + (1096+2m), где m - сумма заголовков всей этой луковицы

Например нужно передать 4kb. MTU 1500. Что будет работать быстрее, 3 write по 1024+1024+1024+1024 или 1 на 4kb или абсолютно перпендикулярно?

В реальной жизни «перпендикулярно», т.к. не ты один шлешь данные в сеть.

Потому что на один системный вызов меньше

Потому что на один системный вызов меньше

А можно послать 4 по 1К за один вызов writev)

Вообще - это всё бессмысленные загоны. Ничего хорошего от таких оптимизаций не получится.

>А можно послать 4 по 1К за один вызов writev)

writev отправляет сообщения, а не поток символов? До чего дошел прогресс!!! Тогда да.. Но если это 4 отдельных TCP сообщения одного логического куска данных, то лучше, чтоб их было 3

Короче, предлагаю TC эксперимент. Создать маленькую программку, которая будет измерять эффективность посылки по loopback. Сделать её реалтаймной с наивысшим приоритетом по FIFO, чтоб другие не мешали.

Не, loopback - плохо. Это волшебный адаптер. В ядре даже есть спец флажок для него.

writev отправляет массив из буферов - специально вместо write в цикле сделали.

Cпасибо всем кто поучаствовал утро вечера мудренее пойду лучше спать :)

>Не, loopback - плохо. Это волшебный адаптер. В ядре даже есть спец флажок для него.

Разве это влияет на разбиение пакетов?

Это влияет на скорость. Он использует разделяемую память, в стеке есть проверки, а не loopback ли это.

Да и например wifi драйвера перетряхивают очереди пакетов уже внутри драйвера.

Это я к тому, что даже смена сетевой карты может всё в корне изменить. Так что если хочется поизвращаться - делать это надо на том, что будет в дальнейшем использоваться.

TCP - это поточный протокол, там пакетов на уровне программы не видно.

> То есть выгоднее всё таки 1024+1024+1024+1024?

Так Вы напоретесь на алгоритм Нейгла, потом еще на на какой-нибудь клинч с внутренней оптимизацией стека. В Вашем конкретном случае, выгоднее отправить сразу 4К. Конечно, если мегабайты отправляете, то можно и поразмыслить, а с 4К думать нечего. Если Вы протокола не понимаете, то лучше стеку не помогать, он сам лучше Вас разберется.

Вообще, Стивенса читайте, там все написано. Есть книжки и покороче, с более сжатым изложением, например очень хороша «Эффективное программирование TCP/IP». Достаточно хотя бы по диагонали пролистать книжку, чтобы подобные вопросы отпали сами собой.

Короче, tcp работает с потоками и сам разруливает и различия в mtu, и потери и задержки на каналах итп. Поэтому тот некий человек сильно неправ.

человек не врет, не стоит лишний раз фрагментировать пакеты сетевого уровня

>человек не врет, не стоит лишний раз фрагментировать пакеты сетевого уровня

TCP потоковый, 10 раз уже сказали.

> TCP потоковый, 10 раз уже сказали.

А если Nagle отключить, станет уже не совсем потоковый?

>А если Nagle отключить, станет уже не совсем потоковый?

Не станет. Неизвестно, на какие куски порубит пакет маршрутизатор, неизвестно, с какой задержкой каждый из пакетов придет получателю. Если на принимающей стороне от recv() ожидают «пакеты» определенного размера, то работать это будет нормально при тестировании в локалке, а в «большой» сети очень хреново.

Если не считать L2, то на каждый пакет придётся 40 байт оверхеда.
Это примерно на 1% больше трафика ушедшего в гудок при сравнении отправки максимальными кусками при MTU 1500 и кусками по 1к.