Здравствуйте, AlexGin, Вы писали:

AG>Имеется вот нейкая сетевая структура, где сервер и клиент связаны по TCP.
AG>Межде сервером и клиентом поддерживается постоянное соединение (OS: Linux Ubuntu).
AG>Предполагается, что эти сервер и клиент — отдельные машинки локальной сети.

AG>Вопрос: какова максимальная длина пакета, который НЕ будет разбиваться сетью на более мелкие пакеты?
AG>Правильно ли я понимаю, что эта длина определяется параметром MTU (когда вызываем команду ifconfig или netstat -ie в Linux)?

MTU это размер пакета. Из них полезный payload для TCP будет, ессно, меньше (заголовки тоже требуют место).
MTU бывает разный. Всякие Cisco любят какие-то дикие размеры, типа 1200 с копейками

AG>Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.

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

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

AG>Вышеуказанные данные получены экспериментально.
AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.

На то он и фуфельный девайс.

AG>P.S. Конечно же, я предусмотрел на стороне приёма, накопление сегментов_пакета — восствновление исходного пакета.
AG>Оно основано на поиске 32-х битного маркера конца пакета.

Ты пытаешься сделать собственный WireShark или что?

AG>Но меня интересует вопрос — как сеть дробит пакеты TCP?
AG>Как защититься от изменения порядка следования пакетов?

Всё уже украдено придумано до вас.