Пакеты, конечно, могут придти в разном порядке. Но вот ядро отдаст данные вашему приложению всегда в правильном порядке.
Т.е. даже если пришли пакеты с SEQ=1, и длиной 1000, а также SEQ = 2501 и длиной 500, то ядро понимая, что чего-то не хватает (пропущено 1500 байтов в середине — второй SEQ, т.е. номер байта, 2501, а мы пока что имели байты вплоть до 1000 включительно), не отдаст на прикладной уровень второй пакет. А по сети ядро будет отправлять ACK 1000, что он получил первый пакет, намекая, что там больше нету.
Как только придёт пакет с SEQ 1001 и какой-нибудь длиной, он будет отдан ядру. Пакет с SEQ=2501, хотя он у ядра давно уже есть, вашему приложению не будет отдан до тех пор, пока все 1500 байтов с номерами 1001 до 2500 включительно не дойдут, по скольким пакетом бы они ни были раскиданы (хоть 1500 пакетов по одному байту). Если в процессе передачи этих промежуточных пакетов произойдёт таймаут, то пакет с SEQ=2501 ваше приложение и не увидит никогда, хотя ядро системы-получателя его имело.
(Хочу обратить внимание на то, что пакеты не пронумерованы. Пронумерованы байты. Поле SEQ в пакете — последовательный номер первого байта данного пакета. Одна тонкость: нумерация начинается не с 0 и не с 1, а со случайного числа, которое определяется отправителем при установке соединения — в пакете с флагом SYN. Пример выше нужно понимать так, что SYN был с SEQ=1).
То есть, о том, что до вас не дойдут промежуточные пакеты, вы можете в случае с TCP не беспокоиться. Если вы на одном конце записали байты в сокет в определённом порядке, вы на другом конце или получите их в точно таком же порядке, или не получите вообще.
Средний
