На уровне TCP не известно ни длины передаваемого файла, ни даже понятия файла - это всего лишь поток байтов, который, вероятно, будет закрыт в будущем. Возможно даже, что через этот байтовый поток передается несколько реальных файлов, но на уровне TCP ничего из этого не известно.
Знания, которые могут быть использованы для некоторого индикатора выполнения, приходят с уровня приложения. При загрузке файла с HTTP (т. Е. Обычно используемый сегодня протокол) сервер в большинстве случаев отправляет в заголовке HTTP поле Content-length, в котором указывается максимальная длина ответа. Поскольку клиент знает, сколько байтов уже получено, он может показать процент полученных данных.
Это также похоже на загрузку, когда клиент знает длину данных для загрузки и знает, сколько данных он уже отправил. Обратите внимание, что клиент не знает наверняка, сколько данных фактически получено. Но механизм TCP гарантирует, что существует также ограниченное окно байтов «в полете» и что клиент сможет отправлять больше данных только после того, как сервер подтвердит достаточно предыдущих данных.
Но учтите, что такой индикатор прогресса возможен не во всех случаях. Даже с HTTP серверу не требуется отправлять данные заранее. Он может просто пропустить эту информацию и закрыть TCP-соединение после передачи всех данных. Или он может использовать кодирование передачи по частям, где он отправляет данные небольшими частями с префиксом длины, но конечная длина ответа заранее не известна. В этом случае браузер не может отобразить надлежащий индикатор выполнения, поскольку окончательная длина не известна, поэтому обычно показывается только то, что все еще выполняется некоторая передача, но не указывается объем выполненной передачи.
И это только с протоколом HTTP. Но другие прикладные протоколы похожи в том, что их длина может быть известна заранее, а может и не быть, и в этом случае некоторые индикаторы прогресса могут показывать перенесенный процент или нет.