TCP со стороны приложения основывается на потоке, что означает отсутствие пакетов, только последовательность байтов.Ядро может собирать несколько записей в соединение перед отправкой, и принимающая сторона может сделать доступным любое количество полученных данных для каждого вызова "чтения".
TCP, по IPсторона, это пакеты.Поскольку стандартный Ethernet имеет MTU (максимальная единица передачи) 1500 байтов, а TCP и IP имеют 20-байтовые заголовки, каждый пакет, передаваемый по Ethernet, будет передавать 1460 байтов (или меньше) потока TCP на другую сторону.Запись из приложения 40 КБ или 80 МБ здесь не будет иметь значения.
Сколько времени потребуется для передачи данных, будет зависеть от того, как и где вы их измеряете.Запись 40 КБ, скорее всего, вернется немедленно, так как этот объем данных просто будет сброшен в «окне отправки» TCP внутри ядра.Запись 80 МБ заблокирует ожидание передачи всего этого (ну, все, кроме последних 64 КБ, которые будут помещаться в ожидании в окне).
Скорость передачи TCP также зависит от получателя.У него есть «окно получения», которое содержит все, что получено от партнера, но не выбрано приложением.Объем пространства, доступного в этом окне, передается отправителю при каждом возврате ACK, поэтому, если принимающее приложение не освобождает его достаточно быстро, отправитель в конечном итоге приостанавливается.WireShark может дать некоторую информацию здесь.
В конце концов, оба метода должны передавать в одно и то же время, поскольку приложение может легко заполнить исходящее окно быстрее, чем TCP может передать его, независимо от того, как эти данные разбиты на фрагменты.
Однако я не могу говорить о работе QT.