Почему протокол ftp иногда вызывает ошибки передачи, если данные используют TCP, который имеет контрольную сумму?

Время от времени загрузка (особенно больших) файлов через ftp вызывает ошибки. Я предполагаю, что это также отчасти причина того, почему все основные сайты публикуют внешние контрольные суммы вместе со своими загрузками.

Как это возможно, если ftp проходит через TCP, в который встроена контрольная сумма, и повторно отправляет данные, если они передаются некорректно?

Кто-то может возразить, что это связано с короткой длиной CRC в протоколе TCP (который, я думаю, 16-битный или что-то в этом роде), а коллизии просто происходят слишком часто. но 1) для того, чтобы это было правдой, не только должна быть коллизия CRC, но и случайная сетевая ошибка должна изменить как CRC в пакете, так и сам пакет, чтобы CRC был действителен для нового пакета. Даже с 16-битным CRC, так ли это? 2) Кажется, что ошибок не так много, например, при просмотре веб-страниц, которые также проходят через TCPIP.


networking tcp checksum ftp crc
person Cray    schedule 10.01.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

FTP различает данные ASCII и BINARY и может соответствующим образом изменять поток данных, что является наиболее частой причиной, с которой я столкнулся для поврежденных загрузок FTP. (Контрольные суммы TCP будут вычисляться на основе измененных данных, поэтому на уровне TCP ничего не будет отображаться неправильно.)

Я полагаю, что следующей наиболее распространенной будет передача, которая усекается из-за тайм-аута или другой сетевой ошибки. В этом случае контрольные суммы TCP будут правильными локально, но частично загруженный файл поврежден.

Протокол FTP немного недружелюбен к брандмауэрам, так как он может вовлекать внешние узлы, подключающиеся обратно по непредсказуемым номерам портов, но это обычно проявляется как неспособность передать что-либо вообще, а не как поврежденная загрузка.

Помимо проблем с ASCII и BINARY, я не могу придумать причину, по которой FTP-соединения должны быть более восприимчивыми к поврежденной передаче. Возможно, вы просто больше их замечаете, потому что это, как правило, такие вещи, как двоичные или сжатые файлы, которые должны быть бит-в-бит полными и правильными, а если нет, вы получите большое уродливое сообщение об ошибке. Гораздо менее вероятно, что вы заметите, например, отсутствие рекламы на веб-странице, потому что время ожидания соединения с рекламной сетью истекло.

person Jim Lewis    schedule 10.01.2011

arrow_upward
1
arrow_downward

16-битная контрольная сумма не так уж и сильна, особенно если учесть размер некоторых FTP-передач, например загрузка программного обеспечения. Однако на нижних уровнях есть CRC и т. Д., Которые компенсируют.

Я не думаю, что в этом столетии у меня был испорченный FTP.

person user207421    schedule 11.01.2011