Русский
Русский
English
Статистика
Реклама

Ftp

Перевод Умрёт ли FTP? Расцвет и упадок протокола

05.10.2020 12:23:18 | Автор: admin


Вот небольшое известие, которое вы могли пропустить, восстанавливая свою жизнь после начала кризиса COVID: из-за того, что вирус перемешал всем карты, Google пропустила выпуск Chrome версии 82. Да кого это волнует?, спросите вы. Ну, хотя бы пользователей FTP, или File Transfer Protocol. Во время пандемии Google отложила свои планы по убийству FTP, и теперь, когда буря немного успокоилась, Google недавно объявила о том, что возвращается к мысли об убийстве в Chrome версии 86, которая снова сократит поддержку протокола, и окончательно убьёт его в Chrome 88. (Mozilla объявила о похожих планах на Firefox, утверждая, что дело в безопасности и возрасте поддерживающего протокол кода.) Это один из старейших протоколов, который поддерживает мейнстримный Интернет (в следующем году ему исполнится 50 лет), но эти популярные приложения хотят оставить его в прошлом. Сегодня мы поговорим об истории FTP, сетевого протокола, который продержался дольше, чем почти все остальные.

1971


Именно в этом году родившийся в Индии студент магистратуры MIT Абхай Бхушнан впервые разработал File Transfer Protocol. FTP, появившийся спустя два года после telnet, стал одним из первых примеров работающего пакета приложений для системы, которая в дальнейшем стала известна как ARPANET. Он обогнал электронную почту, Usenet и даже стек TCP/IP. Как и telnet, FTP по-прежнему используется, хоть и ограниченно. Однако в современном Интернете он потерял значимость, в основном из-за проблем с безопасностью, а его место занимают альтернативные протоколы с шифрованием в случае FTP это SFTP, протокол передачи файлов, работающий поверх протокола Secure Shell (SSH), по большей мере заменившего telnet.


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

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

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


Телетайпный терминал эпохи ARPANET.

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

В своём RFC Бхушан пишет:

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

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

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

Мы спросили: Почему бы не добавить в FTP две команды под названием mail и mail file? Команда mail будет использоваться для обычных текстовых сообщений, а mail file для вложений писем, которые существуют и сегодня, говорит он в интервью.

Разумеется, Бхушан был не единственным, кто принял участие в разработке этого фундаментального раннего протокола, ведь после выпуска из вуза он получил должность в Xerox. Созданный им протокол продолжил своё развитие без него, получив в 1970-х и 1980-х серию обновлений в виде RFC; в том числе примерно в 1980 году появилась его реализация, позволявшая обеспечивать поддержку спецификации TCP/IP.

Хотя со временем появлялись незначительные обновления, чтобы протокол успевал за временем и мог поддерживать новые технологии, версия, которую мы используем сегодня, была выпущена в 1985 году, когда Джон Постел и Джойс К. Рейнольдс разработали RFC 959 обновление предыдущих протоколов, лежащих в основе современного ПО для работы с FTP. (Постел и Рейнольдс, среди прочего, примерно в то же время работали над системой доменных имён (DNS).) Хотя в документе эта версия описывается как предназначенная для исправления незначительных ошибок документации, улучшения объяснения некоторых функций протокола и добавления новых вспомогательных команд, стандартной стала именно она.

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

Во многих смыслах, из-за столь раннего появления в истории Интернета FTP повлиял на структуру множества последующих протоколов. Можно сравнить его с чем-то, что часто менялось и совершенствовалось в течение нескольких десятков лет, допустим, с баскетбольными кроссовками. Да, Converse All-Stars это хорошая обувь, и в нужных условиях с честью она послужит и сегодня, но с гораздо большей вероятностью успеха добьётся какая-нибудь модель от Nike, вероятно, под брендом Air Jordan.

File Transfer Protocol это Converse All-Star Интернета. Он передавал файлы ещё до того, как это стало круто, и по-прежнему сохраняет часть своей притягательности.

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

Так Алан Эмтедж, создатель Archie, считающегося первым поисковым движком Интернета, рассказывал Internet Hall of Fame почему его изобретение, позволявшее пользователям искать на анонимных FTP-серверах файлы, не сделало его богатым. Если вкратце, то Интернет тогда был некоммерческим, а аспирант и работник техподдержки монреальского Университета Макгилла Эмтедж без разрешения использовал сеть вуза для работы Archie. Но именно так и лучше всего было поступить. Как гласит старая пословица, лучше просить прощения, чем разрешения. (Как и Бхушан, Эмтедж был иммигрантом, он родился и вырос на Барбадосе и приехал в Канаду, став студентом благодаря своим достижениям.)


Скриншот WS_FTP FTP-клиента для Windows, который был довольно популярен в 90-х.

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


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

Крупные технологические компании наподобие Hewlett-Packard, Mozilla, Intel и Logitech десятками лет использовали эти сайты для распространения среди конечных пользователей документации и драйверов. И по большей части эти сайты по-прежнему находятся онлайн, храня контент, который находился там долгие годы.

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


Пример того, как выглядит FTP в современном веб-браузере (ftp.logitech.com).

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

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

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

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

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

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

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

Цитата из статьи 1997 года в Network World; в ней говорится, что FTP, несмотря на свою неуклюжесть, по-прежнему остаётся хорошим вариантом для надомных работников и корпоративных пользователей Интернета. Хотя автор статьи был заинтересованным лицом (Роджер Грин являлся президентом компании Ipswitch, крупного изготовителя программ для FTP), его аргументы, тем не менее, соответствовали духу эпохи. Протокол был отличным способом передачи больших файлов через сети и сохранения их на сервере. Проблема в том, что FTP, несмотря на своё постепенное совершенствование, будет вытеснен гораздо более изощрёнными альтернативами, как протоколами (BitTorrent, SFTP, rsync, git, даже современными вариантами HTTP), так и облачными системами наподобие Dropbox или Amazon Web Services.

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

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


Panics Transmit современный пример FTP-клиента. Множество современных клиентов поддерживает широкий набор протоколов, а не только старый добрый FTP.

Позже я выпустился и FTP-сервер отключился навсегда; к тому же всё равно возникли более эффективные варианты его замены, например, BitTorrent, и более законные, типа Spotify и Tidal.

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

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

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

Самые распространённые способы его использования, например, для организации публично доступных анонимных FTP-серверов, по сути, потеряли свою популярность. А в своей основной нише он в конечном итоге был заменён более защищёнными и современными версиями, например SFTP.

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

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



На правах рекламы


VDS с посуточной оплатой для любых целей это про наши эпичные серверы. Максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.

Подробнее..

Перевод FTP исполнилось 50 лет

18.04.2021 00:07:30 | Автор: admin
image


16 апреля 1971 года-это не только день, когда The Rolling Stone впервые выпустила Brown Sugar, но и день публикации RFC 114, знаменующий день рождения FTP.

В те дни вьетнамская война была в центре внимания, TCP/IP еще не существовал, Джими Хендрикс умер 6 месяцев назад, telnet был новым крутым парнем, а некоторые из самых влиятельных рок-н-ролльных артистов собирались выпустить свои шедевры, в то время как FTP использовал сетевой протокол под названием NCP.

За прошедшие годы протокол FTP был усовершенствован 16 раз, добавивилась поддержка TCP/IP, безопасного расширения, также известного как FTPS, которое использует ту же технологию, что и HTTPS, и более поздние дополнение, такое как поддержка IPv6.



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

В 2021 году то, что кажется признанным прогрессом, принимает форму проприетарных протоколов, сделанных за закрытыми дверями и без каких-либо RFC. Вместо этого поставщикам, желающим создать конкурирующие серверы, остается реверс-инжиниринг SDK, как это сделал Minio с S3.

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

Развитие FTP


RFC 114 (апрель 1971 г.)
RFC 697 (июль 1975 г.): CWD Command
RFC 765 (июнь 1980 г.): TCP/IP
RFC 959 (октябрь 1985 г.): Первоначальная спецификация FTP
RFC 1579 (февраль 1994 г.): FTP с поддержкой firewall
RFC 1635 (май 1994 г.): Как использовать анонимный FTP
RFC 1639 (июнь 1994 г.): операция по большим адресным записям
RFC 1738 (декабрь 1994 г.): унифицированные указатели ресурсов
RFC 2228 (октябрь 1997 г.): Расширения безопасности FTP.
RFC 2389 (август 1998 г.): механизм согласования функций для протокола передачи файлов.
RFC 2428 (сентябрь 1998 г.): расширения для IPv6, NAT и расширенного пассивного режима.
RFC 2577 (май 1999 г.): соображения безопасности FTP
RFC 2640 (июль 1999 г.): интернационализация FTP
RFC 3659 (март 2007 г.): Расширение команд FTP
RFC 5797 (март 2010 г.): Реестр команд и расширений FTP.
RFC 7151 (март 2014 г.): Команда HOST для виртуальных хостов
Подробнее..

Менеджер приложений для Windows Mobile

28.01.2021 18:09:16 | Автор: admin

Предисловие

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

Меня всегда волновало удобство установки программ на старые устройства. Я уже давно держу свой FTP сервер для этих целей, а клиенты есть практически подо все операционные системы, но это всё равно не слишком удобно, особенно для людей, не сталкивавшихся раньше с FTP. Поэтому около года назад мне пришла в голову мысль сделать что-то вроде магазина приложений, но у меня всё как-то не было времени и желания и достаточных знаний, возможно. И на самом деле проект включает в себя не только WinMobile, но кучу разных мобильных и десктопных систем, таких как Symbian, Mac OS (classic), старые версии Windows, DOS, Palm... словом все, к которым у меня есть доступ для отладки и которые можно вывести в сеть. Почему же я начал именно с WM? Всё очень просто. Так вышло, что моим любимым языком программирования является C#, а на WM есть свой собственный .Net, который, хоть и с большим числом ограничений, позволяет писать приложения.

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

Как вообще сейчас писать под Windows Mobile?

Способов на самом деле много, но в любом случае понадобится Windows Mobile SDK. Я использую версию для WM 5.0, но она позволяет собирать приложения и для WM2003 и для WM6. В качестве IDE я использую Visual Studio 2008, но видел мануалы по подключению SDK к студиям вплоть до 2017. С VS2008 этот SDK работает из коробки, поэтому я просто создал виртуальную машину с Windows 7 (потому что на Windows 10 такая старая студия уже не устанавливается), поставил студию и всё заработало.

Окно проекта VS2008Окно проекта VS2008

Писать можно как на Visual C++, так и на C# с .Net Compact Framework 3.5. Для КПК существует отдельный Smart Device Project. Отладка производится либо на встроенном в SDK эмуляторе, либо на подключенном через ActiveSync физическом устройстве.

Эмулятор с WM2003Эмулятор с WM2003Но я предпочитаю использовать HTC CruiseНо я предпочитаю использовать HTC Cruise

Обзор возможностей клиента

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

Список приложений на сервереСписок приложений на сервере

Страница приложения содержит некоторое количество информации о нём и позволяет загрузить и установить программу.

Страница приложенияСтраница приложения

На вкладке "Установленные" находится список уже загруженных на устройство приложений. Здесь же можно удалить их или узнать некоторые свойства, такие как место установки, дата установки и т.д.

Список установленных приложенийСписок установленных приложений

Для доступа к настройкам приложения требуется выбрать меню "Действия" -> "Параметры". Выбор вкладки "Обновить" того же меню приведет к загрузке списков доступных и установленных программ заново.

Параметры менеджераПараметры менеджера

С помощью меню "Справка" можно узнать информацию о приложении, авторе и получить помощь в работе.

О ПрограммеО Программе

Немного о внутреннем устройстве

Как я уже говорил выше, я уже давно использую FTP-сервер с хранилищем приложений для разных устройств, поэтому он же и лёг в основу всей системы. Причем мне нужно по сути всего 3 команды: листинг, скачивание файла и считывание размера файла. В Net CF почему-то нет поддержки FTP, так что мне пришлось искать стороннюю библиотеку. Сначала я использовал OpenNetCF.Net.FTP, но потом просто взял оттуда нужные функции. Я всё равно к этому времени уже переписал часть библиотеки для своего удобства, поэтому "ванильную" версию всё равно использовать было бы нельзя.

Так как все файлы на сервере лежат в виде zip-архивов, мне понадобилась библиотека распаковщика. В качестве оной я взял ICSharpCode.SharpZipLib. К сожалению та версия, что сейчас лежит на гитхабе уже давно не поддерживает WinMobile, но я нашел старую DLL-библиотеку, собранную ещё в 2008 году и она заработала без проблем.

Далее - установка. Я использую вызов стандартной утилиты wceload для установки Cab-файлов. Сейчас она запускается со своим интерфейсом, но в будущем я хочу сделать установку тихой, не прерывая работу менеджера. Если же программа представляет из себя одиночный exe или папку, то я копирую её в установочную директорию и "руками" создаю ярлык и инсталляционные записи в реестре.

И наконец список установленных приложений вместе со свойствами просто считывается из реестра из ключа HKLM\Software\Apps.

Кроме этого мне пришлось написать свой собственный диалог выбора папки, окно "О Программе" и некоторые методы (например, определение свободного места в памяти), потому что их тоже нет среди стандартных функций Net CF.

Итог

Я написал эту статью по большей части для того, чтобы оценить интерес людей к подобному проекту. Ну и привлечь к нему внимание, конечно. Учитывая, что это, по сути, только начало пути, я думаю, будут ещё статьи о работе над менеджером и сопутствующих вещах.

Этот проект, как и другие мои поделия можно найти на моём гитхабе.

Пожалуй и всё, что мне хотелось сказать сегодня.

Подробнее..

Многопоточное скачивание файлов с ftp python-скриптом

18.01.2021 00:17:12 | Автор: admin

Зачем это нужно?

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

Ситуация

Нужно было забирать периодически пару сотен файлов с ftp-сервера под Windows. Много мелочи и несколько очень крупных по размеру файлов. Суммарно примерно на 500 Гб. Сервер представляет собой vps, расположенный довольно далеко за рубежом. Днем машина высоко нагружена, рано ночью выполняются регламентные работы, итого на скачивание часов 5 максимум.

Ни одна из рассмотренных мной утилит не смогла справиться качественно и за отведенное время. Ну что ж, деваться некуда, нормальную систему резервного копирования ещё не купили, а значит ноги в руки вооружаемся редактором или IDE Python и вперёд! За приключениями!

Конфиг

Все параметры для скрипта вынесем в отдельный файл для удобства.

Шаблон конфига:

host = 'ip.ip.ip.ip'user = 'ftpusername'passwd = 'ftppassword'basepath = '/path/to/backup/folder'  # Папка, в которой будут созданы подпапки со скачанными файламиmax_threads = 20 # максимальное количество одновременных процессов загрузкиlog_path = '\path\to\logfile'statusfilepath = '\path\to\statusfile'

Конфиг сохраняем с расширением .py и импортируем в начале нашего скрипта. Импортировать можно непосредственно в пространство имён скрипта, но я сделал конструкцию слегка напоминающую костыль в основной части моего скрипта:

if __name__ == "__main__":    host = config.host    user = config.user    passwd = config.passwd    basepath = config.basepath  # Папка, в которой будут созданы подпапки со скачанными файлами    max_threads = config.max_threads    log_path = config.log_path    statusfilepath = config.statusfilepath    main()

В начале был список

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

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

Удобства ради и чтобы не таскать параметры по всему коду - переопределим параметры стандартного класса ftp:

class MyFtp (ftplib.FTP):    """Класс переопределяет стандартный, чтобы задать все параметры соединение в одном месте"""    def __init__(self):        self.host = host        self.user = user        self.passwd = passwd        self.timeout = 1800        super(MyFtp, self).__init__()    def connect(self):        super(MyFtp, self).connect(self.host, timeout=self.timeout)    def login(self):        super(MyFtp, self).login(user=self.user, passwd=self.passwd)    def quit(self):        super(MyFtp,self).quit()

Параметры берутся из конфига. Конечно же в нужно не забыть импортировать библиотеку ftplib, чтобы этот кусок заработал.

Список файлов с сервера мы получим с помощью следующего класса:

class FileList:    """Класс для работы со списком загружаемых файлов"""    def __init__(self):        self.ftp = None        self.file_list = []    def connect_ftp(self):        import sys        self.ftp = MyFtp()        self.ftp.connect()        self.ftp.login()        self.ftp.__class__.encoding = sys.getfilesystemencoding()    def get_list(self, name):        """Метод для получения списка всех файлов с ftp-сервера."""        import os        for dirname in self.ftp.mlsd(str(name), facts=["type"]):            if dirname[1]["type"] == "file":                entry_file_list = {}                entry_file_list['remote_path'] = name  #путь до файла                entry_file_list['filename'] = dirname[0]  #имя файла                self.file_list.append(entry_file_list)            else:                path = os.path.join(name, dirname[0])                self.get_list(path)    def get_next_file(self):        return self.file_list.pop()    def len(self):        return len(self.file_list)

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

Логирование

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

class MyLogger:    """Класс для логирования событий"""    def __init__(self):        self.logger = None    def start_file_logging(self, logger_name, log_path):        """Обычное логирование в файл"""        import logging        self.logger = logging.getLogger(logger_name)        self.logger.setLevel(logging.INFO)        try:            fh = logging.FileHandler(log_path)        except FileNotFoundError:            log_path = "downloader.log"            fh = logging.FileHandler(log_path)        formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')        fh.setFormatter(formatter)        self.logger.addHandler(fh)    def start_rotate_logging(self, logger_name, log_path, max_bytes=104857600, story_backup=5):        """Логирование в файл с ротацией логов"""        import logging        from logging.handlers import RotatingFileHandler        self.logger = logging.getLogger(logger_name)        self.logger.setLevel(logging.INFO)        try:            fh = RotatingFileHandler(log_path, maxBytes=max_bytes, backupCount=story_backup)        except FileNotFoundError:            log_path = "downloader.log"            fh = RotatingFileHandler(log_path, maxBytes=max_bytes, backupCount=story_backup)        formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')        fh.setFormatter(formatter)        self.logger.addHandler(fh)    def add(self, msg):        self.logger.info(str(msg))    def add_error(self, msg):        self.logger.error(str(msg))

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

Скачивание файла

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

class BaseFileDownload(threading.Thread):    """ Объект для копируемого файла """    count = 0    def __init__(self, rpath, filename, log):        threading.Thread.__init__(self)        self.remote_path = rpath        self.filename = filename        self.ftp = None        self.command = None        self.currentpath = None        self.log = log        self.__class__.count += 1 # для подсчета одновременно запущенных закачек    def __del__(self):        self.__class__.count -= 1    def connect(self):        """Метод для соединения с ftp"""        import sys        self.ftp = MyFtp()        self.ftp.connect()        self.ftp.login()        self.ftp.__class__.encoding = sys.getfilesystemencoding()    def run(self):        """Запуск потока скачивания"""        import os        self.connect()        self.command = str(bytes('RETR ', encoding='latin-1'), encoding='utf-8')        self.currentpath = os.path.join(basepath, self.remote_path[3:])        self.ftp.cwd(self.remote_path)        if not os.path.exists(self.currentpath):            os.makedirs(self.currentpath, exist_ok=True)        self.host_file = os.path.join(self.currentpath, self.filename)        try:            with open(self.host_file, 'wb') as local_file:                self.log.add("Start downloading " + self.filename)                self.ftp.retrbinary(self.command + self.filename, local_file.write)                self.log.add("Downloading " + self.filename + " complete")        except ftplib.error_perm:            self.log.add_error('Perm error')        self.ftp.quit()

Для подсчета количества одновременно скачиваемых файлов мы будет использовать свойство класса count. В нём у нас будет количество существующих экземпляров класса: в конструкторе счетчик наращивается, в деструкторе, соответственно, уменьшается.

Метод для запуска скачивания должен обязательно называться run - это требование библиотеки threading (не забываем её импортировать!), которую мы будем использовать для параллельного запуска нескольких процессов скачивания.

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

Статус-файл

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

Класс для работы с этим файлов выглядит так:

class StatusFile:    """По окончанию задачи скрипт пишет в файл уведомление о корректном выполнении."""    def __init__(self):        self.msg = ''    def setstatus(self, msg):        global statusfilepath        with open(statusfilepath, 'w') as status_file:            status_file.write(msg)

Многопоточность

Ну и, наконец, сама основная функция скрипта, которая осуществляет работу с потоками скачивания:

def main():    import os    import datetime    import time    log = MyLogger()    log.start_rotate_logging("DownloaderLog", os.path.join(log_path, "download_backup.log")) # запускаем логирование    now = datetime.datetime.today().strftime("%Y%m%d")    global basepath    basepath = os.path.join(basepath, now)  # модифицируем путь, добавляя текущую дату    list_file = FileList()    list_file.connect_ftp()    list_file.get_list("..")    for i in range(list_file.len()):        flag = True        while flag:   # цикл внутри которого поддерживается нужное количество одновременно запущенных загрузок            if BaseFileDownload.count < max_threads:                curfile = list_file.get_next_file()                threadid = BaseFileDownload(curfile["remote_path"], curfile["filename"], log)                threadid.start()                flag = False            else:                time.sleep(20)    log.add("Downloading files complete")    statusfile = StatusFile()    statusfile.setstatus("Downloading at " + str(datetime.datetime.now()) + " finishing successful")

Здесь мы запускаем логирование, получаем список файлов ( он хранится в памяти).

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

Исходный код целиком можно найти здесь.

Подробнее..
Категории: Python , Multithreading , Ftp

Работа с FTP протоколом в Android. Пример

21.02.2021 00:06:08 | Автор: admin
Всем привет! Это будет очень маленькая статья. Наша задача тут: подключиться к локальному серверу FTP (я выбрала FileZilla) и отправить туда чего-нибудь используя (очевидно) FTP протокол.
Итак, капелька теории:
FTP (File Transfer Protocol) протокол передачи файлов по сети.
Для работы по FTP нужны двое: FTP-сервер и FTP-клиент.
Сервер обеспечивает доступ по логину и паролю к нужным файлам и, соответственно, показывает пользователю только те файлы и папки, к которым он имеет доступ.
Клиент программа для FTP-соединения. Основная идея в том, чтобы пользователь мог оперировать файловыми данными на стороне сервера: просматривать, редактировать, копировать, загружать и удалять.
Все логично.
В отличие, скажем, от того же HTTP FTP использует в качестве модели соединения двойное подключение. При этом один канал является управляющим, через который поступают команды серверу и возвращаются его ответы (обычно через TCP-порт 21), а через остальные происходит собственно передача данных, по одному каналу на каждую передачу. Поэтому в рамках одной сессии по протоколу FTP можно передавать одновременно несколько файлов, причём в обоих направлениях.

Если расписать процесс установки соединения и дальнейшей передачи данных по пунктам, то получится примерно следующее:

  1. Пользователь активирует клиентское приложение и соединяется с сервером, введя логин и пароль.
  2. Устанавливается управляющее соединение между соответствующими модулями интерпретаторами протокола со стороны клиента и сервера.
  3. Пользователь посредством клиента посылает команды серверу, определяющие различные параметры FTP-соединения (активный или пассивный режим, FTP порт, вид передачи данных, их тип), а также директивы для действий, которые юзер намерен осуществить (например, удалить, переименовать, закачать файл и т.д.).
  4. Далее один из участников (к примеру, клиент), являющийся пассивным, становится в режим ожидания открытия соединения на FPT порт, который задан для передачи информации.
    Затем активный участник открывает соединение и начинает передавать данные по предназначенному для этого каналу.
  5. По завершении передачи, это соединение закрывается, но управляющий канал между интерпретаторами остается открытым, вследствие чего пользователь в рамках той же сессии может вновь открыть передачу данных.

FTP соединение по умолчанию происходит через порт 21, если не установлен другой порт.

image

Реализация
В данном случае будем использовать класс FTPClient из библиотеки Apache (org.apache.commons.net.ftp.FTPClient). Создаем объект класса, устанавливаем таймаут. Затем мы должны сначала подключиться к серверу с помощью connect, прежде чем что-либо делать (и не забыть отключиться после того, как все сделаем). В connect в качестве первого параметра пишем локальный адрес хоста, вторым аргументом порт для подключения. Также необходимо проверить код ответа FTP (слишком очевидно, но все же), чтобы убедиться, что соединение было успешным.

import org.apache.commons.net.ftp.FTPimport org.apache.commons.net.ftp.FTPClientimport org.apache.commons.net.ftp.FTPReply...val con = FTPClient()        con.connectTimeout = ххх        con.connect("192.168.0.105", 21)        if (FTPReply.isPositiveCompletion(con.replyCode)) {                //все круто        }

Хорошо, мы подключились к серверу. Что дальше? Теперь необходимо пройти авторизацию под именем пользователя, которого мы, собственно, создали для этого. Но перед этим нужно установить для текущего режима подключения к данным значение PASSIVE_LOCAL_DATA_CONNECTION_MODE с помощью команды enterLocalPassiveMode(). Это значит, что все передачи будут происходить между клиентом и сервером, и что сервер находится в пассивном режиме, ожидая подключения клиента для инициализации передачи данных. (например, ACTIVE_LOCAL_DATA_CONNECTION_MODE подразумевает, что инициатором подключения будет выступать сервер).
После в login пишем логин и пароль пользователя. storeFile() сохраняет файл на сервере, используя заданное имя и принимая входные данные из заданного InputStream. У меня была задача периодически писать в определенный файл на сервере, поэтому это выглядит так:

con.enterLocalPassiveMode()                if (con.login("nad", "nad")) { //вводим логин и пароль (да, вот так в открытом виде)                    con.setFileType(FTP.BINARY_FILE_TYPE)                    val msg = "your_msg"                    val msg_bytes: InputStream = ByteArrayInputStream(msg.toByteArray())                    val result: Boolean = con.storeFile("/sms.txt", msg_bytes)                    msg_bytes.close()                    if (result) Log.v("upload result", "succeeded")                    con.logout()                    con.disconnect()                }            }             catch (ex: IOException) {                ex.printStackTrace()                return Result.failure()            }

Если же вы хотите скопировать свой файл на сервер целиком, можно сделать так (суть не особо меняется, но вдруг кому-то нужно):

val file = File("путь до файла")val msg_bytes = FileInputStream(file)


В целом это все, что вам может понадобиться. И, конечно, немного о настройке локального FTP сервера. У меня это, как и писала ранее, FileZilla. Все оставляем по дефолту. Создаем пользователя и присваиваем ему папку на хосте, из которой он может читать/писать/удалять и т.д.

image

Вот и все. Запускаем и смотрим логи на сервере. И вот чего должны получить:

image

Удачи!
Подробнее..

Перевод FTP исполнилось почти 50 лет и ему пора на пенсию

20.10.2020 16:06:30 | Автор: admin

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




Пока вы пытались перестроить всю свою жизнь так, чтобы уместить её в своей крохотной квартирке в начале коронавирусного кризиса, вы могли пропустить эту небольшую новость: из-за того, что вирус повлиял практически на все сферы жизни, компания Google решила пропустить выпуск 82-й версии Chrome.

Кому какое дело, спросите вы? До этого есть дело пользователям FTP протокола передачи файлов.

Во время пандемии Google отложила планы убийства FTP, и недавно, когда всё более-менее успокоилось, компания объявила о возврате к намерению убрать поддержку протокола в 86-й версии Chrome, и полностью убить его в 88-й версии.

Mozilla рассказала о похожих планах для браузера Firefox, ссылаясь на соображения безопасности и возраст кода.

Это один из самых старых протоколов, всё ещё поддерживаемых популярными приложениями в интернете в следующем году ему стукнет 50 но эти приложения уже готовятся отказаться от него.

Давайте углубимся в историю FTP, сетевого протокола, продержавшегося дольше любого другого.

1971


Именно в этом году Абхай Бушан, студент магистратуры из MIT, родившийся в Индии, впервые разработал FTP. FTP появился через два года после telnet, и был одним из первых примеров рабочего набора приложений для сети, известной тогда под названием ARPANET ещё до появления электронной почты, Usenet и даже стека TCP/IP. FTP, как и telnet, до сих пор можно кое-где использовать, однако в современном интернете он потерял популярность в основном из-за проблем с безопасностью. Его место занимает зашифрованная альтернатива SFTP протокол передачи файлов, работающий на базе протокола SSH, по большей части заменившего telnet.

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

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

Различия в характеристиках терминалов обрабатываются системными программами хостов в соответствии со стандартными протоколами, пояснял он, цитируя как telnet, так и протокол удалённого запуска задач того времени. Однако вам, чтобы пользоваться удалёнными системами, необходимо разбираться в их особенностях.


Терминал телетайпа из эпохи ARPANET

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

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


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

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

Поэтому мы подумали почему бы не добавить в FTP пару команд, mail и mail file? Mail это обычные текстовые сообщения, mail file это вложение файла в сообщение, это то, что у нас есть сегодня, сказал он в интервью.

Естественно, Бушан был не единственным человеком, оставившим свой след в этом раннем фундаментальном протоколе. Бушан в итоге ушёл от работы учёного, получив место в компании Xerox. Созданный им протокол продолжал расти и развиваться уже без него, претерпел несколько обновлений в 1970-х и 1980-х годах через последовательность RFC, включая и реализацию с поддержкой TCP/IP.

С тех пор он претерпел несколько небольших изменений, призванных поддерживать его в актуальном состоянии и добавлявших поддержку более новых технологий, современная версия FTP появилась в 1985 году, когда Джон Постел и Джойс Рейнолдс разработали RFC 959, обновление предыдущих протоколов, являющихся основой современных программ, поддерживающих FTP. Примерно в то же время Постел и Рейнолдс также принимали участие в разработке системы доменных имён. В документе новая версия описывалась, как попытка исправить некоторые небольшие ошибки в документации, улучшить объяснение некоторых особенностей протокола, и добавить несколько необязательных команд. Но при этом именно эта версия задержалась надолго.

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

Поскольку протокол появился так давно, он во многом определил многие последующие протоколы. Его можно сравнить с чем-то, что часто скачкообразно обновляется в течение десятилетий допустим, с баскетбольной обувью. Конечно, кеды Converse All-Stars до сих пор можно считать хорошей обувью, и они могут хорошо показать себя в определённых условиях и сегодня, однако для профессиональных баскетболистов, скорее всего, лучше подойдёт что-нибудь от Nike с брендом Air Jordan.

FTP это кеды Converse All-Star интернета. Он передавал файлы ещё до того, как это стало круто, и до сих пор сохранил часть тех эмоций.

Никто не зарабатывал с интернета никаких денег это была, скорее, денежная дыра. Мы сражались в праведной борьбе. Мы видели его потенциал. Но если кто-то говорит вам, что мог предсказать будущее, он врёт. Я лично был там.

Алан Эмтейж, создатель первого поискового сервиса Archie, рассуждает в интервью блогу Internet Hall of Fame на тему того, почему его изобретение, позволившее пользователям искать файлы на анонимных FTP-серверах, не сделало его богатым. Если кратко, в то время интернет был некоммерческим, и Эмтейж, аспирант и сотрудник техподдержки монреальского университета Макгилла, использовал школьную сеть для работы Archie, причём без разрешения. Но так поступать было круто, рассказал он. Как говорится, легче просить прощения, чем разрешения. Эмтейж, как и Бушан, эмигрант он родился и рос на Барбадосе, а в Канаду приехал благодаря выдающейся успеваемости.



Почему FTP возможно, последняя связь с остатками прошлого, всё ещё существующего в онлайне


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

Крупные технологические компании типа Hewlett-Packard, Mozilla, Intel и Logitech, десятилетиями использовали подобные сайты для распространения документации и драйверов среди конечных пользователей. По большей части эти сайты до сих пор работают, раздавая годами хранящийся там контент.

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


Как сегодня выглядит FTP в браузере: ftp.logitech.com

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

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

В той статье было интервью с Джейсоном Скоттом из организации Internet Archive; они пытаются сохранять эти винтажные FTP-сайты, ведь любой из них может отключиться в любой момент.

Скотт тогда отметил, что долговременное существование этих FTP уже считается исключением из правила.

Очень странно, что у этих FTP-сайтов бывает инерция по 15-20 лет, и что они могли всё это время работать в неприкосновенности, сказал он.

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

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

так говорится в статье журнала Network World за 1997 год, где доказывается, что несмотря на все недостатки FTP, это всё равно был нормальный вариант для многих удалённых работников и корпоративных пользователей. Конечно, статья была написана заинтересованным лицом Роджер Грин был президентом компании Ipswitch, крупного производителя программ для работы с FTP однако его аргументы в то время были справедливы. Это был отличный способ передавать крупные файлы по сетям и хранить их где-то на сервере. Проблема в том, что протокол FTP, пусть он и улучшался со временем, в итоге обогнали более сложные альтернативы как протоколы (BitTorrent, SFTP, rsync, git, даже современные варианты HTTP), так и облачные решения типа Dropbox или Amazon Web Services.

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

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


Panic Transmit, современный пример FTP-клииента. Многие современные клиенты поддерживают множество протоколов кроме старого доброго FTP.

В итоге я съехал, и FTP-сервер закрылся навсегда в любом случае, появились более эффективные альтернативы, типа BitTorrent, и более легальные, типа Spotify и Tidal. Сожалению ли я сегодня о моём сервере? Конечно. Но в то время я чувствовал, что реализую некий протест, иду против системы. Конечно, ничего такого на самом деле не было.

Как обмен файлами претерпел изменения по сравнению с теми безрассудными временами 15-летней давности, так и мы выросли из использования былых FTP-серверов. Мы обучились более эффективным и безопасным техникам удалённой работы с файлами. В 2004 году было общепринятой практикой работать с веб-сервером через FTP. Сегодня, когда инструменты типа Git позволяют эффективно контролировать версии, такой подход считается рискованным и неэффективным.

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

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

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

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

Если удаление поддержки FTP из браузера ускорит уход протокола, то так тому и быть. Однако за эти 50 лет в той или иной форме он отлично нам послужил.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru