Чем http отличается от ftp: HTTP против FTP

HTTP против FTP

Эта статья — попытка описать основные различия между известными протоколами обмена данными FTP и HTTP.

Мы активно используем оба протокола в нашем основном продукте — корпоративном мессенджере MyChat уже много лет, и за это время столкнулись со многими заблуждениями и непониманием работы этих двух фундаментальных протоколов обмена файлами в Интернете.

Если вы увидите какие-то ошибки или неточности, напишите об этом на форуме.

Дисклэймер: в английском языке есть два термина: “upload” и “download”. В русском нет хороших аналогов, поэтому для файлов, которые мы отдаём с клиента на сервер, применяем слово “заливать” (upload), а для файлов, которые забираем на клиент с сервера — используем слово “скачивать” (“download”).

Оба протокола используются для скачивания и заливки файлов в Интернете и локальных сетях. Для текста и бинарных данных. Оба протокола работают поверх TCP/IP. Но между ними есть несколько серьёзных различий.

Скорость передачи

Наверное, самый распространённый вопрос: что быстрее для передачи файлов, FTP или HTTP?

Что делает FTP быстрым?

• в передаваемом потоке нет мета описаний, только чистые бинарные данные. Справочные данные идут в отдельном соединении;
• нет накладных расходов по перекодировке передаваемых данных.

Что делает HTTP быстрым?

• повторное использование существующих постоянных соединений повышает производительность TCP, не тратится время на создание новых соединений;
• конвейерная обработка позволяет быстрее запрашивать несколько файлов с одного и того же сервера;
• (автоматическое) сжатие трафика уменьшает объём передаваемых данных, это может увеличить скорость передачи при условии быстрых клиента и сервера и медленного канала связи;
• нет управляющих команд в потоке передачи данных, это экономит время обработки.

В конечном итоге чистый результат, конечно, зависит от конкретных деталей, но я бы сказал, что для одиночных статических файлов вы не сможете увидеть ощутимую разницу.

Для одиночного файла небольшого размера и медленного соединения FTP покажет себя лучше. При получении нескольких файлов подряд (особенно небольших размеров) HTTP обычно показывает лучший результат.

Возраст

FTP (RFC959) появился за десять лет до того, как был придуман HTTP. В то время FTP был единственным протоколом в Интернете. Первые зачатки того, что впоследствии стало документом RFC959, можно найти в далёком 1971 году.

Заливка

Оба протокола умеют это делать. У FTP есть команда «append», HTTP исповедует подход «вот вам данные, а вы сами разбирайтесь, что с ними делать», то есть, никаких команд по управлению заливаемыми файлами нет.

Следует сказать, что существует протокол WebDAV, построенный поверх HTTP, который позволяет работать с файлами в традиционной манере, будто они находятся на вашем локальном устройстве.

Форматы ASCII, EBCDIC или бинарный

FTP имеет представление о формате файла, поэтому может передавать данные как в ASCII, так и в двоичном виде (raw bytes). HTTP же всегда отправляет файлы в двоичном виде. Таким образом, FTP умеет преобразовывать данные «на лету», если они передаются между системами с разными архитектурами (Windows/Linux/мэйнфрэймы).

Например, если отправитель использует одну схему для кодирования конца строки («EOL» — End-Of-Line), а получатель — другую, то FTP сделает так, что они друг друга поймут. Unix использует только символ NL (newLine x0A), а MS Windows два символа подряд, CR и LF (CarriageReturn и LineFeed — x0D0A). EBCDIC перекодировки используются на старых мэйнфреймах.

HTTP, в противовес FTP, предоставляет метаданные для файлов, «Content-Type». Таким образом, метаданные могут использоваться клиентами для интерпретации содержимого.

Заголовки

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

Пайплайны или конвейеры

HTTP поддерживает конвейерную обработку данных. Это означает, что клиент может запросить новую передачу файлов до того, как закончится предыдущая, что даёт возможность убрать задержки при закачке нескольких документов подряд. TCP пакеты, таким образом, будут оптимизированы для максимальной скорости передачи.

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

FTP команды/ответы

FTP клиент может отправлять на сервер множество команд и получать на них ответы от сервера. Даже передача одного файла включает в себя целую серию таких простых команд. Это, конечно, негативно сказывается на скорости, потому что каждая команда требует обработки на двух сторонах: клиенте и сервере. Из-за этого возникают задержки. HTTP передачи данных – это преимущественно, только один запрос и один ответ (для каждого файла). Получение одного файла через FTP иногда может занимать до десятка команд и ответов между клиентом и сервером.

Два соединения

Одна из самых больших проблем для FTP в реальной работе — это использование двух соединений. Первое — для отправки управляющих команд, а второе — для передачи содержимого файла. Для этой цели он каждый раз открывает отдельный поток TCP. Если вы передаёте 100 файлов, по очереди будут открыты и закрыты 100 TCP соединений.

Файрволы и NAT

FTP использует два соединения: управляющее и для передачи данных. Соединение для данных может идти в двух направлениях, и использовать динамические номера портов. Это добавляет головной боли администраторам и зачастую требует от файрволов понимания специфики функционирования FTP на уровне сетевого протокола, чтобы обеспечить нормальную работу.

Это также означает, что если обе стороны соединения находятся за NAT, вы, скорее всего, не сможете пользоваться FTP.

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

Чтобы такого не происходило, приходится время от времени отправлять фиктивные пустые команды, чтобы соединение поддерживалось в «живом» состоянии. Результат — небольшой, но лишний трафик.

Активный и пассивный режимы

FTP открывает второе соединение в активном или пассивном режиме. Если работает активный режим (соединение инициирует сервер) — будут проблемы с соединением в сложных сетях, потому что такое соединение невозможно через NAT. Поэтому, в большинстве случаев используется пассивный режим (passive mode), когда соединение происходит только со стороны клиента.

Зашифрованные управляющие соединения

Поскольку брандмауэры должны уметь «разбирать по косточкам» управляющее соединение FTP, чтобы дать возможность корректно открывать второе соединение для передачи бинарных данных, существует огромная проблема с зашифрованными соединениями (FTP-SSL или FTPS). Как только управляющее соединение становится зашифрованным, файрвол уже не в состоянии интерпретировать его команды, чтобы понимать, когда и как следует разрешить второе соединение между клиентом и сервером для передачи бинарных данных.

К тому же, разработка самого стандарта FTPS заняла слишком много времени, что привело к одновременному существованию нескольких гибридных версий, плохо совместимых между собой.

Схемы авторизации

У FTP и HTTP есть несколько документированных методов аутентификации. Оба протокола предлагают базовую аутентификацию обычным текстом (логин/пароль). Однако, для HTTP существуют несколько часто используемых методов проверки, которые не отправляют пароль в виде обычного текста, в отличие от FTP.

Скачивание

Оба протокола умеют это делать. У обоих протоколов были проблемы при скачивании файлов с размером, больше чем 2 гигабайта, но это уже в прошлом. В современных клиентах и серверах, на современных операционных системах этой проблемы больше нет.

Диапазоны/возобновление скачивания

FTP поддерживает скачивание и закачку, а также восстановление разорванных соединений и продолжение передачи в обеих направлениях. HTTP может похвастаться только восстановлением при скачивании, а при заливке файлов на сервер восстановление оборванного соединения и продолжение заливки часто оказываются невозможными.

В противовес FTP, HTTP поддерживает более продвинутые диапазоны для скачивания.

Также у FTP есть проблемы при возобновлении соединений при заливке или скачивании файлов, начиная с сегмента, большего, чем 2 GB.

Постоянные соединения

HTTP клиент может держать одно постоянное соединение с сервером для любого количества передач файлов.

FTP должен создавать новое соединение для каждой новой передачи. Многократные выполнения новых подключений плохо сказываются на производительности из-за необходимости «рукопожатий» (handshakes) для TCP соединений.

Кодирование HTTP-чанков

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

Во время передачи отправляющая сторона отдаёт поток данных блоками (размер блока + сами данные) до тех пор, пока они не закончатся, а потом передаёт блок с нулевой длиной, чтобы просигнализировать о конце файла.

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

Сжатие

HTTP предоставляет серверу и клиенту возможность договориться и выбрать один из алгоритмов сжатия. Алгоритм gzip является, пожалуй, наиболее широко используемым. Есть более современный brotli, но он ещё не полностью поддерживается разными серверами и клиентами, хотя даёт лучшее сжатие (до +20%), особенно на текстовых html, javascript и css файлах.

FTP предоставляет официальное встроенное RLE сжатие, однако оно обычно неэффективно для большинства бинарных и текстовых данных. Есть много дополнительных «хакерских» реализаций для сжатия FTP трафика, но ни одна из них не стала официальной и широко используемой.

FXP

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

IPv6

И HTTP, и FTP отлично работают с IPv6, однако изначально в оригинальной спецификации протокола FTP не было поддержки IPv6, и из-за этого множество серверов до сих пор не имеют нужных команд для его включения. Это также касается межсетевых экранов между клиентами и серверами, которые должны понимать FTP.

Виртуальный хостинг на основе имени

Используя HTTP 1.1, вы легко можете разместить множество сайтов на одном сервере, и все они будут различаться по их именам.

В FTP вы вообще не можете использовать виртуальный хостинг на основе имён, пока команда HOST не будет реализована на сервере, с которым вы соединены. Это свежая спецификация, и она ещё мало распространена.

Просмотр каталогов

В FTP можно получить список файлов из папки на удалённом сервере, не скачивая их, в то время как в HTTP нет такой возможности.

Однако, в силу того, что авторы спецификации FTP жили в разное время, команды для получения списка файлов в каталоге (LIST и NLST) не имеют чётко описанного формата вывода. Поэтому авторам FTP клиентов приходится заниматься написание синтаксических анализаторов текста, чтобы попытаться правильно угадать, что за данные им передаёт сервер. Более поздние спецификации (RFC3659) предусматривают новые команды типа MLSD, но они ещё не получили широкого распространения и плохо поддерживаются разными серверами и клиентами.

Списки файлов в каталогах через HTTP обычно передаются текстом в HTML формате, либо с помощью WebDAV, который работает поверх HTTP.

Поддержка прокси

Одно из серьёзных преимуществ HTTP перед FTP — это поддержка прокси, встроенная в него с самого начала. Технология отлажена и очень хорошо работает. Многие протоколы могут быть инкапсулированы внутрь HTTP, как в своеобразный «конверт» для прохождения прокси-серверов.

FTP всегда использовался с прокси серверами, но это никогда не было стандартизировано, и всегда требовало специальных подходов в каждом конкретном случае.

Как отправлять документы в конференции чата или почему HTTP(S) лучше FTP?

Несмотря на лето, сезон отпусков и тотальное нежелание работать жару, мы снова обновили MyChat. Основная «фича» новой версии 6.2 — вставка файлов в конференциях.

Обо всём уже написано в официальной новости, я же остановлюсь на технологии, как оно всё устроено «под капотом».
Как вы знаете, в сервер MyChat встроен высокопроизводительный WEB-сервер Node.js. Мы постепенно переводим работу с файлами в MyChat с FTP на HTTP(s) протокол из-за удобства последнего.

1. Как было раньше?
2. Как вставляются файлы в конференциях MyChat сейчас?
3. Что будет дальше? Откажемся от FTP?
4. Плюсы передачи файлов напрямую, через FTP (клиент-клиент)
5. Минусы передачи файлов напрямую через FTP (клиент-клиент)
6. Плюсы передачи файлов через сервер
7. Минусы передачи файлов через сервер
8. Итоги подведём (с)

Как было раньше?

Раньше в MyChat можно было передавать файлы только в приватах, один-на-один. Эта технология работает и сейчас, она особенно хороша, если отправитель и получатель находятся в локальной сети и видят друг друга «напрямую». Скорость передачи будет близка к физической скорости сети, хоть фильмы передавай 🙂

Однако, как только пользователи начинают подключаться к серверу через Интернет, из разных подсетей, из-за NAT, файрволов, прокси и прочих антивирусов — начинаются всевозможные проблемы. Не каждый администратор – гуру в сетевых технологиях и знает, как работает FTP в пассивном режиме, как пробрасывать порты на роутерах и настраивать диапазоны.

Мы же стремимся сделать MyChat как можно проще и ближе к пользователям. В идеале — чтобы он всё сделал за админа сам 🙂

Получается, по умолчанию лучше хранить файлы на сервере, а не передавать их напрямую между клиентами.

Как вставляются файлы в конференциях MyChat сейчас?

Общая схема работы такая:

1. Берём файл, рассчитываем для него контрольную сумму SHA-1.
2. Отправляем запрос на сервер, есть ли такой файл на сервере, возможно, он уже заливался на сервер до нас кем-то.
3. Получаем ответ от сервера. Если файл там уже был, то сразу отправляем сообщение в конференцию, если файла на сервере нет — заливаем его по HTTP/HTTPS и после этого отправляем сообщение в конференцию.
4. После того, как пользователи конференции получают сообщение, они могут кликнуть по нему и файл автоматически скачается по HTTP/HTTPS на локальный компьютер в папку «Мои документы» (либо в другую, согласно настроек).

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

Что будет дальше? Откажемся от FTP?

Полностью отказываться от FTP мы не будем. FTP сервер останется в MyChat Server, как и раньше. Будет публичная папка, будут личные аккаунты пользователей.

Отдельная технология передачи файлов «точка-точка» тоже останется, слишком быстро она работает 🙂 Кто понимает, будет пользоваться, а кому не нужно – уберут правами.

Кстати говоря, систему обновлений и вставку картинок в чат мы уже перенесли с FTP на рельсы HTTP/HTTPS. Судя по отзывам наших пользователей, ход был правильный.

Передачу файлов мы со временем перенесём целиком и полностью на плечи WEB-сервера, и вот почему:

Плюсы передачи файлов напрямую, через FTP (клиент-клиент)

1. Скорость
   Максимальная, которую может предоставить ваша сеть, FTP в MyChat «выжмет» из неё все возможное.

Минусы передачи файлов напрямую через FTP (клиент-клиент)

1. Интернет, разные подсети, NAT, файрволы, антивирусы, прокси
   Если на пути есть эти препятствия, передача напрямую работать не будет. На практике это означает, что в 90% случаев по умолчанию будет включаться медленный режим передачи «клиент-сервер-клиент». MyChat файлы передаст, но скорость уже будет совсем не та.
2. На сервере нет копий файлов
   Передали файлы и потеряли копию — просите файл снова у отправителя. Перезаписали поверху — ищите оригинал. Про сохранение файлов для внутренней СБ компании или для аудита уже не говорим.
3. Получатель должен быть онлайн
   В противном случае файлы придётся заливать на сервер.
4. Нет синхронизации
   Передали файл с компьютера на компьютер, подключились Android-приложением в свою учётку — файлов нет. Они остались локально у получателя и отправителя.
5. Нет шифрования
   По умолчанию FTP не использует шифрование трафика.

Плюсы передачи файлов через сервер

1. Проще настройка
   http/https работает по одному TCP порту. В большинстве случаев настройка даже не потребуется.
2. Синхронизация
   Клиент всегда может запросить историю в конференции или привате, если там передавались файлы — их можно скачать, даже если у пользователя их уже нет на локальном устройстве.
3. Нет копий одинаковых файлов
   Для каждого файла вычисляются контрольные суммы, поэтому на сервере не будет дубликатов, даже если у файлов разные названия. Дополнительный бонус в следующем: если файл уже кто-то заливал на сервер до вас, то будущие отправки таких файлов будут происходить мгновенно.
4. История изменения файлов
   Даже если название файла оставалось одним и тем же, а содержимое менялось, то для сервера — это разные файлы. И все копии будут храниться в целости и сохранности.
5. Минимальная нагрузка на сервер
   Файл будут скачивать не тогда, когда его залили, а только при необходимости. Даже если вы его отправили в конференцию, где сидит сотня людей.
6. Ограничения по типу и размеру файлов
   Клиент-сервер, админ всё может настроить максимально гибко.
7. Шифрование
   Включаете HTTPS в админке сервера, добавляете свои сертификаты и работаете.

Минусы передачи файлов через сервер

1. Расход свободного места на сервере
   Объективно, на сериалы никакого места не хватит. Но это регулируется либо административно, либо технически. Да и место на HDD дешевеет с каждым годом.
2. Большие файлы в локальной сети будут передаваться медленнее
   Файлы идут не напрямую, а сначала заливаются на сервер, а потом уже скачиваются по запросу.

Итоги подведём (с)

Сложим плюсы и минусы:

1. Передача напрямую: -5 баллов
2. Передача через сервер: 7 против 2. Но мы не убираем технологию передачи напрямую, так что 2 балла можно записать в плюсы.

Итого, счёт +14 баллов в пользу новой технологии.

Выводы очевидны: HTTP/HTTPS и хранение файлов на сервере — побеждают.

ftp или http

← →
anton773 ©
 
(2006-08-11 22:12)
[0]

Еще один вопрос. По какому протоколу лучше скачивать файлы если есть возможность выбора.В чем преимущества и недостатки ftp и http. Заранее спасибо.

← →
Alvin ©
 
(2006-08-12 13:30)
[1]

Вообще FTP это протокол специально для передачи файлов — File Transfer Protocol

← →
mr. Eof
 
(2006-08-12 18:30)
[2]

На самом деле, http — универсальный протокол, и передавать данные по нему можно не хуже. Посмотри любой сайт, там тебе везде предложат выбрать http или ftp.
Разницы — нет.

Но я бы качал по FTP.

← →
Ketmar ©
 
(2006-08-12 19:52)
[3]

однофигственно. я — по http. %-))

← →
anton773 ©
 
(2006-08-12 21:13)
[4]

А если смотреть по объему переданных(полученных ) байт. Какой протокол экономичнее? (в смысле служебной информации)

← →
Ketmar ©
 
(2006-08-12 21:14)
[5]

пофигу.

← →
anton773 ©
 
(2006-08-12 21:35)
[6]

Всем спасибо!

← →
SergP ©
 
(2006-08-12 23:51)
[7]

> [2] mr. Eof   (12.08.06 18:30)
> На самом деле, http — универсальный протокол, и передавать
> данные по нему можно не хуже. Посмотри любой сайт, там тебе
> везде предложат выбрать http или ftp.
> Разницы — нет.
>
> Но я бы качал по FTP.


> [5] Ketmar ©   (12.08.06 21:14)
> пофигу.

По http все-таки лучше и быстрее. У меня инет дерьмовый, поэтому разницу сильно заметно. По хттп отправляется запрос, а далее закачивается контент, а по фтп перед самой закачкой клиент должен долго (сравнительно) «общаться с сервером».

← →
Ketmar ©
 
(2006-08-13 00:03)
[8]

> [7] SergP ©   (12.08.06 23:51)
да, в общем, не столь уж и долго. в принципе, общение по ftp даже на несколько десятков байт короче иногда (если тупой сервер не присылает километровые приветы %-). а «долгота» — это от того, что несколько соединений устанавливается.

← →
Интересующийся
 
(2006-08-15 10:10)
[9]

Если много файлов загрудаются или каталог то однозначно FTP
А по одному действительно пофин.

P.S.
Если файлы загружаются по одному и редко лучше выбрать HTTP, его проще реализовать 🙂

← →
Ketmar ©
 
(2006-08-15 15:00)
[10]

> [9] Интересующийся   (15. 08.06 10:10)
и если много — тоже пофигу. %-)

← →
DVM ©
 
(2006-08-15 15:07)
[11]

HTTP проще в реализации и в использовании. Меньше (теоретически) грузит сервер.

← →
anton773 ©
 
(2006-08-15 21:24)
[12]

А вообще в идеале сколько должно быть служебной информации в закачиваемом файле.У меня вот процентов 8-10.Шото многовато.

← →
Dmitrij_K
 
(2006-08-15 22:13)
[13]

Служебной информации при скачивании файлов по ftp и http меньше 1 кб

← →
Slym ©
 
(2006-08-16 06:40)
[14]

http можно подружить с gzip/deflate тогда экономичность поднимется

← →
Ketmar ©
 
(2006-08-16 09:59)
[15]

> [12] anton773 ©   (15. 08.06 21:24)
смотря какого размера файл. если байт, например, то в процентном отношении будет очень много. %-)

← →
Ketmar ©
 
(2006-08-16 09:59)
[16]

ой. в закачиваемом файле вообще нет никакой «служебной информации». она идёт до. %-)

← →
anton773 ©
 
(2006-08-16 21:46)
[17]

> ой. в закачиваемом файле вообще нет никакой «служебной информации».
>  она идёт до. %-)

Да но ведь при скачивании файла по http он нарезается на пакетики размером обычно меннее килобайта и в каждый пакетик добавляется служебная информация если верить умным книгам то 40 байт + балласт(если пакет менее стандартного).Поправьте меня если я не прав.

← →
Ketmar ©
 
(2006-08-16 21:55)
[18]

> [17] anton773 ©   (16. 08.06 21:46)
это вам кто-то жестоко наврал.

← →
Dmitrij_K
 
(2006-08-16 21:57)
[19]

> Да но ведь при скачивании файла по http он нарезается на
> пакетики размером обычно меннее килобайта

Неа
Клиент посылает заголовок потом данные, и сервер отвечает также
\\

← →
Dmitrij_K
 
(2006-08-16 21:58)
[20]

Ты перепутал с более низким уровнем, tcp или ip

← →
anton773 ©
 
(2006-08-16 22:26)
[21]

> это вам кто-то жестоко наврал.

http://win-da.by.ru/internet/speed.shtml (раздел оптимизация размера TCP пакета)

← →
Ketmar ©
 
(2006-08-16 22:28)
[22]

> [21] anton773 ©   (16. 08.06 22:26)
хм. а при чёи тут протокол TCP? мы же о протоколах более высокого уровня говорим. а TCP — он и под ftp тоже лежит. %-)

← →
anton773 ©
 
(2006-08-17 03:47)
[23]

> мы же о протоколах более высокого уровня говорим

Я не совсем правильно вопрос сформулировал 🙂 А еще есть способы уменьшить объем служебной информации?  [21] частично помогло,но хочется еще оптимизировать траффик.

← →
Slym ©
 
(2006-08-17 08:42)
[24]

anton773 ©   (17.08.06 3:47) [23]
оптимизировать траффик
САЖМИ ЕГО!

← →
Ketmar ©
 
(2006-08-17 10:09)
[25]

> [23] anton773 ©   (17.08.06 03:47)
в общем случае задача решаема фиговато. только под конкретные условия. например, для локалки можно научить сокеты не аккумулировать байты, а слать их почти сразу на сетевуху. и отдавать файлы большими кусками. сеть забьётся мгновенно, но может и будет шустрее. %-)

← →
Belorus ©
 
(2006-08-17 14:42)
[26]

И FTP и ХТТП качают одинаково. Служебная инфа идёт до передачи и всё. До конца закачки, они молчат, льётся только инфа. Если Передача идёт по TCP, то приходят подтверждения. По UDP — не приходят(если не модифицировано для подтверждения). Никак оптимизировать не удастся.

← →
Ketmar ©
 
(2006-08-17 14:55)
[27]

> [26] Belorus ©   (17.08.06 14:42)
удастся. см. [25].

← →
Slym ©
 
(2006-08-17 15:05)
[28]

Ketmar ©   (17. 08.06 10:09) [25]
не аккумулировать байты, а слать их почти сразу на сетевуху
называется Nagle режим
Трафик вырастит адназначна!
если отсылать 1000б без Nagle режима он уйдет одним пакетом размером
1000 + размер IP заголовка (не помню но около 20 байт) + размер TCP заголовка (прим 15байт) итого около 1035 байт (при условии что MTU больше)
при отсылке 1000б с Nagle режимом допустим в 5 заходов толучим 5 IP пакетов общим размером (1000/5+20+15)*5 т.е. на (20+15)*4=80 байт больше

← →
Ketmar ©
 
(2006-08-17 15:11)
[29]

> [28] Slym ©   (17.08.06 15:05)
нет, не naggle. » если буфер для исходящих имеет нулевой размер, то функции Send и SendTo независимо от режима работы сокета отправляют данные непосредственно в сеть» (ц)
я имел в виду именно это.

← →
anton773 ©
 
(2006-08-17 21:40)
[30]

Всем спасибо. Получается что все возможное для оптимизации траффика я уже сделал. и больше чем рекомендуют в [21] не сделать

← →
SergP ©
 
(2006-08-18 00:34)
[31]

> [17] anton773 ©   (16.08.06 21:46)
>
> > ой. в закачиваемом файле вообще нет никакой «служебной
> информации».
> >  она идёт до. %-)
>
> Да но ведь при скачивании файла по http он нарезается на
> пакетики размером обычно меннее килобайта и в каждый пакетик
> добавляется служебная информация если верить умным книгам
> то 40 байт + балласт(если пакет менее стандартного).Поправьте
> меня если я не прав.

Это ты уже на уровень TCP перепрыгнул. Здесь разницы нежду http и ftp нет никакой, так как они оба базируются на TCP.

> А еще есть способы уменьшить объем служебной информации?
>

Увеличить MTU и MSS. Хотя если это не в локалке, а в инете, то может даже ухудшить ситуацию. Ну можно подобрать наиболее оптимальные значения…

ну можно разработать свой (более экономичный) протокол транспортного уровня… Но это по видимому страшно геморойно, да и заметной экономии не добъешься…

← →
brother ©
 
(2006-08-20 11:12)
[32]

Раз пошла речь о закачке фалов, подскажите пример закачки файла с http. А то искал, а все примеры тока для index.html страниц! (во всяком случае только они и скачиваются). Я бы хотел и рисунки итд скачать.

← →
Alex Konshin ©
 
(2006-08-20 12:03)
[33]

Для закачки гораздо предпочтительнее использовать HTTP, т.к. не будет проблем с proxy и firewall.
FTP лучше не использовать, т.к. он исполльзует два порта (два соединения) и потому проблемы с firewall. Единственный случай, когда FTP предпочтительней  —  это если нужно дать возможность клиенту получить список файлов в неком фолдере на сервере.

Все остальные доводы — ерунда.

← →
Ketmar ©
 
(2006-08-20 13:01)
[34]

> [32] brother ©   (20.08.06 11:12)
«прикалываются» в другом месте.

← →
Anatoly Podgoretsky ©
 
(2006-08-20 13:38)
[35]

FTP  — File Transfer Protocol
HTTP — HyperText Transfer Protocol

← →
Alex Konshin ©
 
(2006-08-20 22:02)
[36]

> Anatoly Podgoretsky ©   (20.08.06 13:38) [35]
> FTP  — File Transfer Protocol
> HTTP — HyperText Transfer Protocol

И что из этого? На заборе тоже много чего написано.
Факт то, что HTTP проще использовать, если есть файерволы на пути.
А файлы они передают одинаково.

← →
atruhin ©
 
(2006-08-21 16:53)
[37]

> [29] Ketmar ©   (17.08.06 15:11)
> > [28] Slym ©   (17.08.06 15:05)
> нет, не naggle. » если буфер для исходящих имеет нулевой
> размер

Ты не прав. naggle делает именно то, что ты так пространно описал.

← →
Ketmar ©
 
(2006-08-21 21:00)
[38]

> [37] atruhin ©   (21.08.06 16:53)
афаир, naggle — это собирание мелких пакетов в один, а потом отправка. это очень похоже на то, что я описал, но не то же самое. %-)

← →
n0name
 
(2006-08-22 14:35)
[39]

> Alex Konshin ©   (20.08.06 12:03) [33]

Можно перевести сервер в пассивный режим, указав номер порта, который можно предварительно разрешить в фаерволе.

← →
Alex Konshin ©
 
(2006-08-23 14:26)
[40]

> n0name   (22.08.06 14:35) [39]
> > Alex Konshin ©   (20.08.06 12:03) [33]
> Можно перевести сервер в пассивный режим, указав номер порта,
>  который можно предварительно разрешить в фаерволе.

Да знаю я. Только это лишние сложности. Например, у меня дома файервол железный и не шибко умный.
Особенно весело получается, когда файерволы с обоих сторон.
Так что HTTP всяко проще будет.

Протоколы Интернета и электронной почты

149

C# и .NET — Сетевое программирование — Протоколы Интернета и электронной почты

После обсуждения базовых протоколов мы можем подняться на более высокий уровень. Протоколы HTTP и FTP охватывают уровни 5—7 модели OSI.

FTP — File Transfer Protocol

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

Модель приложения с FTP-сервером и клиентом проиллюстрирована на следующем рисунке. Приложение-клиент представляет пользовательский интерфейс и создает FTP-запрос в соответствии с запросом пользователя и спецификацией FTP. FTP-команда посылается приложению-серверу через TCP/IP, и интерпретатор на сервере соответственно интерпретирует FTP-команду. В зависимости от FTP-команды в FTP-ответе клиенту возвращается с сервера список файлов или конкретный файл:

Протокол FTP имеет следующие характеристики:

• Надежная передача данных через TCP

• Анонимный доступ или аутентификация пользователя по имени и паролю

• Файлы отправляются в ASCII-коде в форме, поддерживаемой целевой платформой, или как неизмененные двоичные данные.

FTP-команды можно сгруппировать в следующие категории:

Команды контроля доступа

В FTP-командах контроля доступа указывается имя пользователя (USER) и пароль (PASS), установки могут изменяться (REIN), и соединение может быть закончено (QUIT).

Команды параметров передачи

FTP-передачу можно конфигурировать с помощью команд параметров передачи. Эти команды поддерживают изменение ASCII-кода на двоичный код, сжатие данных, изменение портов для отправки.

Команды FTP-сервиса

Копирование файлов с сервера (RETR), копирование файлов на сервер (STOR), удаление файлов (DELE), переименование файлов (RNTO), создание каталогов (MKD) и запрос списка файлов (LIST) — вот некоторые команды FTP-сервиса.

Протокол FTP определен в RFC 959.

FTP-клиенты

Чтобы понять суть протокола FTP, лучше всего поработать из командной строки с утилитой ftp, как показано на следующем рисунке. Программа ftp работает через приглашение ftp, позволяющее вводить команды. Эти команды отличаются от команд протокола FTP — вы можете увидеть их все, если введете команду ?. При введении команды open ftp.microsoft.com создается соединение с хостом ftp.microsoft.com.

Уст

Что такое FTP простыми словами ~ Блоги ~ Beesona.Ru

FTP (File Transfer Protocol) представляет собой протокол передачи данных , активно применяемый пользователями во всем мире для обмена файлами между двумя компьютерами, объединенными TCP/IP сетью. Зная, что такое ftp, можно понять какие преимущества имеет этот способ обмена данными и чем он отличается от других протоколов.
Так, в отличие от HTTP протокола, отлично справляющегося с передачей web-содержимого (по сути текстовых файлов, заполненных кодом), FTP предпочтительнее использовать для работы с большими объемами данных.

Преимущества протокола FTP

• Если соединение неожиданно прервется, файл можно докачать, а не загружать каждый раз заново.
• Скачивание происходит одновременно в несколько потоков (особенно важно для больших файлов). Один из каналов всегда является управляющим (служит для отправки команд на сервер и получения ответов), остальные — собственно для передачи информации.
• Поддержка текстового и двоичного режима передачи данных.
• Встроенная аутентификация пользователей.

Что такое FTP доступ?

Доступом можно считать саму процедуру установления соединения между клиентской машиной и сервером. Уровень доступа настраивается на сервере и может разрешать различные действия с файлами и папками: переименование, создание, перемещение, удаление и т.п.
Пользоваться протоколом ФТП предельно просто. В зависимости от способа подключения, мы увидим либо стандартное отображение файлов и папок, хранящихся на удаленном сервере, либо их представление в том или ином файловом менеджере. Например Total Comander, FAR Manager или фтп-клиент типа FileZilla,WinSCP и другие.

Подробнее

Количество просмотров: 36
Количество комментариев: 0
Метки: FTP, ФТП,
Рубрика: Блоги ~ Личные блоги
Опубликовано: 11.09.2019

FTP — Википедия. Что такое FTP

FTP (англ. File Transfer Protocol) — протокол передачи файлов по сети. В отличие от TFTP, гарантирует передачу (либо выдачу ошибки) за счёт применения квитируемого протокола TCP. Стандартный порт управления FTP-соединением — 21. Типичное применение FTP-протокола — загрузка сайтов и других документов с частного устройства разработки на общедоступные сервера хостинга.

Протокол построен на архитектуре «клиент-сервер» и использует разные сетевые соединения для передачи команд и данных между клиентом и сервером. Пользователи FTP могут пройти аутентификацию, передавая логин и пароль открытым текстом, или же, если это разрешено на сервере, они могут подключиться анонимно. Можно использовать протокол SSH для безопасной передачи, скрывающей (шифрующей) логин и пароль, а также шифрующей содержимое.

Первые клиентские FTP-приложения были интерактивными инструментами командной строки, реализующими стандартные команды и синтаксис. Графические пользовательские интерфейсы с тех пор были разработаны для многих используемых по сей день операционных систем. Среди этих интерфейсов как программы общего веб-дизайна вроде Microsoft Expression Web, так и специализированные FTP-клиенты (например, FileZilla).

FTP является одним из старейших прикладных протоколов, появившимся задолго до HTTP, и даже до TCP/IP, в 1971 году. В первое время он работал поверх протокола NCP^[1]. Он и сегодня широко используется для распространения ПО и доступа к удалённым хостам.

Описание протокола

Отличие от HTTP

Достаточно яркая особенность протокола FTP в том, что он использует множественное (как минимум — двойное) подключение. При этом один канал является управляющим, через который поступают команды серверу и возвращаются его ответы (обычно через TCP-порт 21), а через остальные происходит собственно передача данных, по одному каналу на каждую передачу. Поэтому в рамках одной сессии по протоколу FTP можно передавать одновременно несколько файлов, причём в обоих направлениях. Для каждого канала данных открывается свой TCP порт, номер которого выбирается либо сервером, либо клиентом, в зависимости от режима передачи^[2].

Протокол FTP (как и HTTP) имеет двоичный режим передачи, что сокращает накладные расходы трафика и уменьшает время обмена данными при передаче больших файлов.

Начиная работу через протокол FTP, клиент входит в сессию, и все операции проводятся в рамках этой сессии (проще говоря, сервер помнит текущее состояние). Протокол HTTP ничего не «помнит» — его задача — отдать данные и забыть, поэтому запоминание состояния при использовании HTTP осуществляется внешними по отношению к протоколу методами^[2].

FTP работает на прикладном уровне модели OSI и используется для передачи файлов с помощью TCP/IP. Для этого должен быть запущен FTP-сервер, ожидающий входящих запросов. Компьютер-клиент может связаться с сервером по порту 21. Это соединение (поток управления) остаётся открытым на время сессии. Второе соединение (поток данных), может быть открыт как сервером из порта 20 к порту соответствующего клиента (активный режим), или же клиентом из любого порта к порту соответствующего сервера (пассивный режим), что необходимо для передачи файла данных. Поток управления используется для работы с сессией — например, обмен между клиентом и сервером командами и паролями с помощью telnet-подобного протокола. Например, «RETR имя файла» передаст указанный файл от сервера клиенту. Вследствие этой двухпортовой структуры, FTP считается внешнеполосным протоколом, в отличие от внутриполосного HTTP.

Соединение и передача данных

Протокол определён в RFC 959.
Сервер отвечает по потоку управления трёхзначными ASCII-кодами состояния с необязательным текстовым сообщением. Например, «200» (или «200 ОК») означает, что последняя команда была успешно выполнена. Цифры представляют код ответа, а текст — разъяснение или запрос. Текущая передача по потоку данных может быть прервана с помощью прерывающего сообщения, посылаемого по потоку управления.

FTP может работать в активном или пассивном режиме, от выбора которого зависит способ установки соединения. В активном режиме клиент создаёт управляющее TCP-соединение с сервером и отправляет серверу свой IP-адрес и произвольный номер клиентского порта, после чего ждёт, пока сервер запустит TCP-соединение с этим адресом и номером порта. В случае, если клиент находится за брандмауэром и не может принять входящее TCP-соединение, может быть использован пассивный режим. В этом режиме клиент использует поток управления, чтобы послать серверу команду PASV, и затем получает от сервера его IP-адрес и номер порта, которые затем используются клиентом для открытия потока данных с произвольного клиентского порта к полученному адресу и порту. Оба режима были обновлены в сентябре 1998 г. для поддержки IPv6. В это время были проведены дальнейшие изменения пассивного режима, обновившие его до расширенного пассивного режима.

При передаче данных по сети могут быть использованы четыре представления данных:

• ASCII — используется для текста. Данные, если необходимо, до передачи конвертируются из символьного представления на хосте-отправителе в «восьмибитный ASCII», и (опять же, если необходимо) в символьное представление принимающего хоста. В частности, изменяются символы перевода строки (CR /chr(13)/, LF /chr(10)/ в Windows на LF /chr(10)/ в Unix/Linux. Как следствие, этот режим не подходит для файлов, содержащих не только обычный текст.
• Режим изображения (обычно именуемый бинарным) — устройство-отправитель посылает каждый файл байт за байтом, а получатель сохраняет поток байтов при получении. Поддержка данного режима была рекомендована для всех реализаций FTP.
• EBCDIC — используется для передачи обычного текста между хостами в кодировке EBCDIC. В остальном, этот режим аналогичен ASCII-режиму.
• Локальный режим — позволяет двум компьютерам с идентичными установками посылать данные в собственном формате без конвертации в ASCII.

Для текстовых файлов предоставлены различные форматы управления и настройки структуры записи. Эти особенности были разработаны для работы с файлами, содержащими Telnet или ASA-форматирование.

Передача данных может осуществляться в любом из трёх режимов:

• Поточный режим — данные посылаются в виде непрерывного потока, освобождая FTP от выполнения какой бы то ни было обработки. Вместо этого, вся обработка выполняется TCP. Индикатор конца файла не нужен, за исключением разделения данных на записи.
• Блочный режим — FTP разбивает данные на несколько блоков (блок заголовка, количество байт, поле данных) и затем передаёт их TCP.
• Режим сжатия — данные сжимаются единым алгоритмом (обычно, кодированием длин серий).

Аутентификация

FTP-аутентификация использует схему имя пользователя/пароль для предоставления доступа. Имя пользователя посылается серверу командой USER, а пароль — командой PASS. Если предоставленная клиентом информация принята сервером, то сервер отправит клиенту приглашение и начинается сессия. Пользователи могут, если сервер поддерживает эту особенность, войти в систему без предоставления учётных данных, но сервер может предоставить только ограниченный доступ для таких сессий.

Анонимный FTP

Хост, обеспечивающий FTP-сервис, может предоставить анонимный доступ к FTP. Пользователи обычно входят в систему как «anonymous» (может быть регистрозависимым на некоторых FTP-серверах) в качестве имени пользователя. Хотя обычно пользователей просят прислать адрес их электронной почты вместо пароля, никакой проверки фактически не производится. Многие FTP-хосты, предоставляющие обновления программного обеспечения, поддерживают анонимный доступ.

FTP-ALG

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

NAT и обход брандмауэров

FTP обычно передает данные при наличии соединения сервера с клиентом, после того как клиент отправил команду PORT. Это создает проблему как для NAT, так и для брандмауэров, которые не разрешают соединения из интернета к внутренним хостам. Для NAT дополнительной проблемой является то, что представление IP-адресов и номера порта в команде PORT относится к IP-адресу и порту внутреннего хоста, вместо публичного IP-адреса и NAT-порта. Существует два подхода к этой проблеме. Первый заключается в том, что FTP-клиент и FTP-сервер используют команду PASV, которая вызывает соединение для передачи данных, установленное от клиента к серверу. Второй подход — изменение для NAT значений команды PORT с помощью шлюза на прикладном уровне.

Поддержка веб-браузерами

Большая часть обычных веб-браузеров может извлекать файлы, расположенные на FTP-серверах, хотя они могут не поддерживать расширения протоколов вроде FTPS. Когда указан FTP-адрес, а не HTTP-адрес, доступный контент на удалённом сервере представляется аналогично остальному веб-контенту. Полностью функциональный FTP-клиент может быть запущен в Firefox как расширение FireFTP.

Синтаксис

Синтаксис FTP URL описан в RFC1738, в форме: ftp://[<пользователь>[:<пароль>]@]<хост>[:<порт>]/<путь> (параметры в квадратных скобках необязательны). Например:

ftp://public.ftp-servers.example.com/mydirectory/myfile.txt (недоступная ссылка)

или:

ftp://user001:[email protected]/mydirectory/myfile.txt (недоступная ссылка)

Более детально об указании имени пользователя и пароля написано в документации браузеров. По умолчанию, большинство веб-браузеров используют пассивный (PASV) режим, который лучше обходит брандмауэры конечного пользователя.

Безопасность

FTP не разрабатывался как защищённый (особенно по нынешним меркам) протокол и имеет многочисленные уязвимости в защите. В мае 1999 авторы RFC 2577 свели уязвимости в следующий список проблем:

• Скрытые атаки (bounce attacks)
• Спуф-атаки (spoof attacks)
• Атаки методом грубой силы (brute force attacks)
• Перехват пакетов, сниффинг (packet capture, sniffing)
• Защита имени пользователя
• Захват портов (port stealing)

FTP не может зашифровать свой трафик, все передачи — открытый текст, поэтому имена пользователей, пароли, команды и данные могут быть прочитаны кем угодно, способным перехватить пакет по сети. Эта проблема характерна для многих спецификаций Интернет-протокола (в их числе SMTP, Telnet, POP, IMAP), разработанных до создания таких механизмов шифрования, как TLS и SSL. Обычное решение этой проблемы — использовать «безопасные», TLS-защищённые версии уязвимых протоколов (FTPS для FTP, TelnetS для Telnet и т. д.) или же другой, более защищённый протокол, вроде SFTP/SCP, предоставляемого с большинством реализаций протокола Secure Shell.

Безопасный FTP

Существует несколько методов безопасной передачи файлов, в одно или другое время называемых «Безопасным FTP».

FTPS

Явный FTPS — расширение стандарта FTP, позволяющее клиентам требовать того, чтобы FTP-сессия была зашифрована. Это реализуется отправкой команды «AUTH TLS». Сервер обладает возможностью позволить или отклонить соединения, которые не запрашивают TLS. Это расширение протокола определено в спецификации RFC 4217. Неявный FTPS — устаревший стандарт для FTP, требующий использования SSL- или TLS-соединения. Этот стандарт должен был испо

Что такое FTP и чем он отличается от HTTP?

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

Что такое протокол передачи файлов (FTP)?

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

FTP — это старый протокол, использующий простой интерфейс командной строки. Он существовал до появления TCP / IP (протокол управления передачей / Интернет-протокол). Это означает, что FTP предоставил средства для передачи файлов с одного компьютера на другой еще до появления Интернета.

FTP используется более 40 лет и с тех пор претерпел значительные улучшения. Первоначально он был написан Абхаем Бхушаном и опубликован как RFC 114 16 ^{апреля 1971 года.}

В 1980 году был создан TCP / IP, и версия FTP для TCP / IP была зарегистрирована как RFC 765. Текущая спецификация FTP была зарегистрирована в октябре 1985 года как RFC 959. Позднее были внесены поправки, которые добавили расширения безопасности, пассивные режимы и поддержка IPv6.

Примечание. RFC (Запрос на комментарии) является официальным документом IETF (Инженерной группы Интернета).

До того, как в операционных системах появился графический интерфейс пользователя (GUI), клиенты FTP были просто программами командной строки.Но теперь для серверов, мобильных устройств и настольных компьютеров существуют клиенты с графическим интерфейсом пользователя и утилиты автоматизации. Теперь FTP можно оценить через современный графический интерфейс или интерфейс командной строки.

Вы можете использовать FTP для передачи любых типов файлов, включая документы, видео и музыкальные файлы. Он работает в приложениях, таких как веб-браузеры. Возможно, вы даже использовали его для загрузки из Интернета, например для загрузки обновления приложения.

FTP может служить для установки системы управления контентом (CMS), такой как WordPress, на вашем веб-хостинге.Вы можете создать резервную копию своего веб-сайта и сохранить ее копию на своем компьютере.

Использует ли FTP HTTP?

FTP и HTTP — два независимых протокола. HTTP использует модель клиент-сервер, как и FTP.

В чем разница между HTTP и FTP?

FTP передает файлы с помощью двух параллельных TCP-соединений. Первое соединение отправляет команды управления, а другое отправляет и получает данные. Это означает, что FTP открывает второй порт TCP каждый раз, когда отправляет или получает данные.

HTTP, с другой стороны, отправляет управляющую информацию внутри полосы. Это означает, что строки заголовка запроса и ответа отправляются по тому же TCP-соединению, которое передает переданные файлы.

Хотя FTP можно использовать только для передачи файлов, HTTP также можно использовать для просмотра веб-сайтов.

FTP против HTTP: что быстрее?

Говоря о скоростях передачи, какой протокол быстрее зависит от того, как они используются.

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

С другой стороны, HTTP работает быстрее при получении нескольких файлов подряд, особенно если файлы имеют небольшой размер.

Многие считают, что при работе с большими файлами FTP более эффективен. Для файлов меньшего размера используйте HTTP.

Нет заметной разницы между ними при работе с одиночными статическими файлами.

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

Как быстро FTP для передачи файлов:

• Перекодирование переданных данных не требует дополнительных затрат.
• Отправленные файлы не содержат метаданных. В передаваемом потоке есть только двоичные данные.

Как HTTP работает быстро для передачи файлов:

• Конвейерная обработка позволяет быстро обрабатывать несколько файловых запросов с одного сервера.
• Вы получите лучшую производительность TCP, поскольку существующие постоянные соединения используются повторно.HTTP не создает новых подключений и тем самым экономит время.
• Время обработки меньше, так как канал передачи данных не имеет управляющих команд.
• Сжатие трафика (автоматическое) уменьшает объем отправляемых данных. Таким образом, скорость передачи может быть увеличена, когда клиент и сервер работают быстро, но канал соединения медленный.

Заключение

FTP используется уже давно и, похоже, в ближайшее время не устареет.Он по-прежнему служит своей цели, хотя не используется так часто, как HTTP. Может показаться, что это не очень удобно, но программы с графическим пользовательским интерфейсом (GUI) делают его более удобным. Если вы ищете быстрый и безопасный сервис, который поможет вам без проблем переносить большие файлы и папки, тогда не ищите дальше. FileWhopper — это удобный, чрезвычайно безопасный и доступный инструмент, который позволяет вам передавать файлы и папки ЛЮБОГО размера без ежемесячной подписки или других регулярных платежей.Вы платите только за объем отправленных данных и получаете возможность одновременной загрузки и выгрузки, шифрования военного уровня и до 90 дней в облачном хранилище данных, которые вы хотите передать. На момент написания этой статьи вы можете бесплатно протестировать услугу, выполнив свой первый перевод до 5 ГБ, не платя никаких денег.

Вам понравилась эта статья?

Загружается …

Как вы загружаете файлы на веб-сервер? — Изучите веб-разработку

В этой статье показано, как опубликовать свой сайт в Интернете с помощью инструментов передачи файлов.

Сводка

Если вы создали простую веб-страницу (см. Пример в разделе «Основы HTML»), вы, вероятно, захотите разместить ее в Интернете на веб-сервере. В этой статье мы обсудим, как это сделать, используя различные доступные параметры, такие как клиенты SFTP, RSync и GitHub.

SFTP

Существует несколько клиентов SFTP. Наша демонстрация охватывает FileZilla, поскольку она бесплатна и доступна для Windows, macOS и Linux. Чтобы установить FileZilla, перейдите на страницу загрузок FileZilla, нажмите большую кнопку «Загрузить», затем выполните установку из установочного файла обычным способом.

Примечание : Конечно, есть много других вариантов. См. Дополнительные сведения в разделе «Инструменты публикации».

Откройте приложение FileZilla; вы должны увидеть что-то вроде этого:

Вход

В этом примере мы предположим, что наш хостинг-провайдер (служба, которая будет размещать наш HTTP-сервер) — это фиктивная компания «Example Hosting Provider», чьи URL-адреса выглядят так: mypersonalwebsite.examplehostingprovider.net .

Мы только что открыли счет и получили от них следующую информацию:

Поздравляем с открытием учетной записи на Example Hosting Provider.

Ваш аккаунт: demozilla

Ваш сайт будет доступен по адресу demozilla.examplehostingprovider.net

Для публикации в этой учетной записи подключитесь через SFTP со следующими учетными данными:

• SFTP-сервер: sftp: //demozilla.examplehostingprovider.нетто
• Имя пользователя: demozilla
• Пароль: quickbrownfox
• Порт: 5548
• Для публикации в сети поместите свои файлы в каталог Public / htdocs .

Давайте сначала посмотрим на http://demozilla.examplehostingprovider.net/ — как видите, пока там ничего нет:

Примечание : В зависимости от вашего хостинг-провайдера большую часть времени вы будете видеть страницу, на которой написано что-то вроде «Этот веб-сайт размещен на [Hosting Service]».»При первом переходе на свой веб-адрес.

Чтобы подключить SFTP-клиент к удаленному серверу, выполните следующие действия:

1. Выберите Файл> Менеджер сайта … в главном меню.
2. В окне Site Manager нажмите кнопку New Site , затем введите имя сайта как demozilla в отведенное место.
3. Укажите SFTP-сервер, указанный вашим хостом, в поле Host: .
4. В раскрывающемся списке Тип входа: выберите Обычный , затем введите предоставленное имя пользователя и пароль в соответствующие поля.
5. Введите правильный порт и другую информацию.

Ваше окно должно выглядеть примерно так:

Теперь нажмите Подключите для подключения к серверу SFTP.

Примечание. Убедитесь, что ваш хостинг-провайдер предлагает SFTP (безопасный FTP) подключение к вашему хостинговому пространству. FTP по своей сути небезопасен, и вам не следует его использовать.

Здесь и там: локальный и удаленный просмотр

После подключения ваш экран должен выглядеть примерно так (мы подключились к нашему собственному примеру, чтобы дать вам представление):

Давайте посмотрим, что вы видите:

• На центральной левой панели вы видите свои локальные файлы.Перейдите в каталог, в котором вы храните свой веб-сайт (например, mdn ).
• На центральной правой панели вы видите удаленные файлы. Мы вошли в наш удаленный корень FTP (в данном случае пользователей / demozilla )
• На данный момент вы можете игнорировать нижнюю и верхнюю панели. Соответственно, это журнал сообщений, показывающий состояние соединения между вашим компьютером и сервером SFTP, и журнал в реальном времени каждого взаимодействия между вашим клиентом SFTP и сервером.

Загрузка на сервер

В наших примерах инструкций хоста говорилось: «Чтобы опубликовать в Интернете, поместите свои файлы в каталог Public / htdocs .»Вам нужно перейти в указанный каталог на правой панели. Этот каталог фактически является корнем вашего веб-сайта, где будет находиться ваш файл index.html и другие ресурсы.

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

Они действительно в сети?

Пока все хорошо, но действительно ли файлы в сети? Вы можете проверить еще раз, вернувшись на свой сайт (например,грамм. http://demozilla.examplehostingprovider.net/ ) в вашем браузере:

И — вуаля ! Наш сайт работает!

Rsync

Rsync — это инструмент для синхронизации файлов локально и удаленно, который обычно доступен в большинстве систем на базе Unix (например, macOS и Linux), но существуют и версии для Windows.

Он рассматривается как более продвинутый инструмент, чем SFTP, поскольку по умолчанию он используется в командной строке. Базовая команда выглядит так:

 rsync [-options] SOURCE user @ x.x.x.x: DESTINATION 

• -options — это тире, за которым следует одна или несколько букв, например -v для подробных сообщений об ошибках и -b для создания резервных копий. Вы можете увидеть полный список на странице руководства rsync (ищите «Сводка параметров»).
• ИСТОЧНИК — это путь к локальному файлу или каталогу, из которого вы хотите скопировать файлы.
• user @ — это учетные данные пользователя на удаленном сервере, на который вы хотите скопировать файлы.
• x.x.x.x — IP-адрес удаленного сервера.
• НАЗНАЧЕНИЕ — это путь к месту, куда вы хотите скопировать свой каталог или файлы на удаленном сервере.

Вам необходимо получить такие данные у вашего хостинг-провайдера.

Для получения дополнительной информации и дополнительных примеров см. Как использовать Rsync для копирования / синхронизации файлов между серверами.

Конечно, рекомендуется использовать безопасное соединение, например FTP. В случае Rsync вы указываете детали SSH, чтобы установить соединение через SSH, используя опцию -e .Например:

 rsync [-options] -e "ssh [ПОДРОБНОСТИ SSH ЗДЕСЬ]" ИСТОЧНИК [email protected]: DESTINATION 

Более подробную информацию о том, что необходимо, можно найти в разделе «Как копировать файлы с помощью Rsync через SSH».

Инструменты графического интерфейса Rsync

Для Rsync доступны инструменты с графическим интерфейсом

(для тех, кому неудобно пользоваться командной строкой). Acrosync — один из таких инструментов, доступный для Windows и macOS.

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

GitHub

GitHub позволяет публиковать веб-сайты через страницы GitHub (gh-страницы).

Мы рассмотрели основы использования этого в статье «Публикация вашего веб-сайта» из нашего руководства «Начало работы с Интернетом», поэтому мы не собираемся повторять все это здесь.

Однако стоит знать, что вы также можете разместить веб-сайт на GitHub, но использовать с ним собственный домен. См. Подробное руководство в разделе Использование личного домена со страницами GitHub.

Другие способы загрузки файлов

Протокол FTP — один из хорошо известных методов публикации веб-сайтов, но не единственный.Вот еще несколько возможностей:

• Веб-интерфейсы . HTML-интерфейс, действующий как интерфейс для службы удаленной загрузки файлов. Предоставляется вашим хостингом.
• WebDAV . Расширение протокола HTTP для расширенного управления файлами.

Как загрузить файл на свой веб-сайт с помощью FTP-клиента FileZilla (thesitewizard.com)

Учебное пособие по публикации файла на веб-сервере вашего веб-сайта с использованием FTP

Кристофера Хенга, мастера сайта.com

Процесс передачи файла с вашего компьютера на ваш веб-сайт часто называют «загрузкой» этого файла или «публикацией» его.
Для веб-хостов, поддерживающих
FTP (сокращение от «Протокол передачи файлов») или SFTP (безопасная форма протокола передачи файлов), вам нужна программа
вызывал «FTP-клиент» для передачи файла.

В этом руководстве рассказывается, как передать файл на веб-сервер с помощью
бесплатный FTP-клиент, известный как FileZilla.
Доступны версии для Windows, Linux и Mac OS X.Я опишу версию этой программы для Windows, но если вы используете
другая операционная система, есть вероятность, что она работает очень похоже.

Загрузите и установите FileZilla

Сначала перейдите на страницу загрузки FileZilla и получите соответствующий
версия для вашей системы. Для Windows получите установочную версию; в то время, когда я писал это, это было помечено «(рекомендуется)» в разделе Windows.

После того, как вы скачали программу, вам нужно будет ее установить.Перейдите на рабочий стол и дважды щелкните файл, который у вас только что
скачал. Следуйте инструкциям, чтобы установить его на жесткий диск.

Предварительные шаги

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

• Имя FTP-сервера вашего веб-сайта. Например, ваш хост может сказать вам, что ваше имя хоста FTP — «ftp.example.com».
• Ваш идентификатор пользователя или логин для вашей учетной записи FTP.
• Ваш пароль для вашей учетной записи FTP.
• Каталог, в который необходимо поместить файлы, чтобы их можно было увидеть в веб-браузере, посещающем ваш сайт. Например, ваш хост может
  скажет вам разместить файлы в подкаталоге с именем «www» или «public_html» или даже в каталоге по умолчанию, который вы видите при входе в систему
  ваш FTP-сайт.

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

Шаги по загрузке или публикации файла на вашем веб-сервере

В рамках этого руководства я предполагаю, что вы хотите загрузить файл с именем «feedback.php». Каждый раз, когда вы видите «feedback.php»
упомянуто, вы можете заменить это имя именем файла, который вы действительно хотите загрузить. FileZilla не ограничивает вас
на загрузку только файлов с таким именем. Вы можете загружать изображения (например, GIF, JPG, PNG и т. Д.), Файлы HTML, видеоклипы, музыкальные файлы.
(например, файлы MP3, файлы WAV, файлы MIDI), сценарии Perl, сценарии PHP, целые каталоги (т.е. папки), содержащие файлы,
и так далее.Для любопытных: я использую «feedback.php» в качестве файла примера, потому что это руководство изначально было написано, чтобы помочь
тем, кто пользуется моим бесплатным мастером обратной связи
чтобы загрузить созданную форму на свой сайт.

1. Если вы видите диалоговое окно с заголовком «Менеджер сайта» при запуске FileZilla, переходите к следующему шагу.
   Если нет, щелкните меню «Файл», а затем пункт «Менеджер сайта» в этом меню. Появится диалоговое окно.

2. Щелкните кнопку «Новый сайт». Это создает новый элемент в разделе «Мои сайты» (или «Мои FTP-сайты» в зависимости от
   в какой версии FileZilla вы используете) под названием «Новый сайт» (или «Новый FTP-сайт» в более старых версиях)

3. Переименуйте «Новый сайт» (или как там было изначально) на имя вашего сайта.По умолчанию
   курсор клавиатуры был бы помещен в часть имени «Новый сайт», позволяя вам изменить i

Как настроить собственный FTP-сервер с помощью Core FTP

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

Для чего-то вроде этого многие люди сразу же рассматривают длинный список решений для обмена файлами, таких как 5 браузерных инструментов для обмена файлами P2P, упомянутых Тимом, или 4 приложения для обмена файлами, о которых он написал, которые общаются через Интернет.Мы рассмотрели множество FTP-клиентов, и Варун показал, как включить службу Windows FTP для обслуживания файлов с вашего собственного FTP-сайта.

Служба Windows FTP полезна для быстрого обмена файлами без необходимости установки какого-либо нового программного обеспечения, но она также имеет ограниченные функциональные возможности.Для таких вещей, как безопасность, обширное управление пользователями или простое управление несколькими доменами, программное обеспечение за пределами бесплатного FTP-сервера может предложить некоторые довольно интересные преимущества. Один из моих любимых инструментов — бесплатный Core FTP Server.

Настройка FTP-домена

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

При первом запуске Core FTP Server вы увидите пустой список доменов, где вы можете начать настройку трех бесплатных FTP-доменов.Для этого просто нажмите кнопку « Setup ».

Настройка домена — это то место, где происходит 90 процентов конфигурации.На этой странице вы увидите не только возможность настройки своего FTP-домена, но и возможность включить подписанные сертификаты для доступа к FTP-серверу, виртуальные пути, по которым пользователи могут перемещаться при подключении к вашему серверу, а также большую безопасность. такие параметры, как SSH, SSL и т. д.

Если вы приобрели сертификаты, нажмите кнопку « Сертификат », чтобы настроить их.Если у вас его нет, вы можете настроить свой собственный «Самоподписанный сертификат » на экране ниже.

Самый быстрый и простой способ настроить сервер (хотя, очевидно, не самый безопасный) — просто настроить « localhost » со стандартным портом FTP и настроить корневой путь FTP, по которому любой, кто подключается к вашему FTP-серверу, может получать файлы. .Вы также можете создавать подкаталоги для отдельных пользователей и настраивать их при настройке защищенных учетных записей пользователей. Вы делаете это после настройки своего домена, нажав кнопку « New » рядом со списком Users .

Здесь я создал пользователя с именем « ryanfriend1 », который будет иметь доступ к подкаталогу « ryanfriend1 » при входе на FTP-сервер.Как видите, Core FTP Server предлагает целый список параметров для каждого пользователя, которые вы можете настроить, например скорость загрузки и выгрузки, тайм-ауты и даже ограничить количество килобайт, которое может загрузить пользователь.

На левой панели навигации в окне настроек пользователя вы также можете щелкнуть ссылку « Permissions », чтобы заблокировать или разрешить доступ к файлам и каталогам для этого пользователя.

Вернувшись на главный экран Core FTP Server, если вы нажмете кнопку « Access Rules », вы можете заблокировать IP-адрес, домен или диапазон IP-адресов, если вам когда-нибудь понадобится.

После того, как вы настроили хотя бы один FTP-домен и пользователя, нажмите « Start », и вы увидите запуск сервера в поле активности внизу главной страницы.Когда вы видите, что сервер «активен …», ваши пользователи почти могут получить доступ к вашему FTP-серверу. Вам все равно придется пересылать входящие FTP-запросы на новый FTP-сервер.

Сначала откройте командную строку на компьютере, где работает сервер, и введите « ipconfig », чтобы проверить свой IP-адрес.После того, как у вас есть адрес ПК, вы готовы к настройке маршрутизатора. Войдите на страницу администратора маршрутизатора и (на веб-хостинге

— с использованием FTP

с использованием FTP

Приложение File Manager Центра управления — это удобный способ управления файлами HTML, изображения и CGI, составляющими ваш веб-сайт. Вы также можете использовать программу FTP (протокол передачи файлов ) на своем компьютере для загрузки, скачивания и переименования файлов на вашем веб-сайте и изменения настроек доступа.

FTP может загружать и загружать несколько файлов, тогда как File Manager позволяет загружать или загружать только один файл за раз.

Существует множество программ FTP, доступных для каждого типа компьютера, в этой статье рассказывается, как использовать File Manager через Центр управления, настроить FTP с помощью программ Dreamweaver и FileZilla.

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

Информация для входа на FTP

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

Имя хоста (или Хост ): ftp-dom.earthlink.net или ftp.yourdomain.com

Имя пользователя (или ID пользователя ): vashdomen.com

Пароль : пароль вашего веб-хостинга

В начало

Использование диспетчера файлов через Центр управления

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