Telnet

^{Картинка взята из телнет-видео Звёздных войн: telnet towel.blinkenlights.nl}

Недавно был пост о том, нужны ли сетевики. До тех пор, пока проверка доступности tcp/ip порта кажется чем-то сложным даже для администраторов БД и AD, сетевики несомненно нужны. Они особенно полезны в тех случаях, когда необходимо понять почему так плохо работает некое клиент-серверное приложение ценой в пароход.
Иногда мало знать ping и traceroute для того, чтобы понять и устранить проблему в сети. Необходимо понимать как работают все звенья в цепи, а сделать это может лишь сетевик. Рассмотрим несколько таких примеров.

Чем Netcat лучше telnet?

Практически всегда, если речь идет о проверке TCP/UDP порта стараются сделать это через telnet и приходится всякий раз просить поставить Netcat. Есть несколько причин, по которым telnet сильно проигрывает. Вот основные причины.

• telnet не умеет различать причины недоступности порта. Все, или ничего connect, либо fail. Netcat может подсказать, в чем проблема. В этом случае все просто, такого порта в состоянии LISTENING нет.
• Не умеет в UDP, SCTP и прочие, ничего кроме TCP.
• Не имеет опций тайм-аута соединения -w и проверки без подключения -z
  

Теперь не говорите, что вы не знали и закопайте поглубже telnet.

(1:1004)$ ncat -v -w3 -z some.server 1111Ncat: Version 7.80 ( https://nmap.org/ncat )Ncat: Connection refused.

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

(1:1005)$ ncat -v -w3 -z another.server 1521Ncat: Version 7.80 ( https://nmap.org/ncat )Ncat: No route to host.

Бытует мнение, что на Windows нет альтернативы telnet, однако это неверно. Существует штатная утилита Test-NetConnection, которую можно запустить из PowerShell.

Test-NetConnection -ComputerName "www.contoso.com" -Port 80

Linux MIB в помощь

Если ваш сервер вдруг перестал реагировать на внешние раздражители и клиентские запросы стали провисать, не всегда причина в выдернутом сетевом кабеле, или зависших сервисах JBoss/Tomcat. Прежде, чем заводить кейс в тех-поддержку проверьте Linux MIB. Есть множество программ, выдающих статистику ядра Linux по внутренним счетчикам SNMP. Самая распространенная из них все еще netstat.

(1:1008)$ netstat -s |grep prune873 packets pruned from receive queue because of socket buffer overrun(1:1009)$ nstat -s |grep PruneTcpExtPruneCalled   873 0.0

Если сервер не справляется с сетевой нагрузкой и буфер сокета перманентно переполнен, тогда ядро будет просто сбрасывать все новые пакеты и счетчик будет расти на глазах. Чтобы исправить эту ситуацию, можно добавить некоторые настраиваемые параметры в файле sysctl.conf. Текущие значения можно увидеть из файловой системы /proc.

(1:1010)$ cat /proc/sys/net/ipv4/tcp_rmem4096    16384   4194304(1:1011)$ cat /proc/sys/net/ipv4/wcp_rmem4096    16384   4194304(1:1012)$ grep -e tcp_rmem -e tcp_wmem /etc/sysctl.confnet.ipv4.tcp_rmem = 4096 87380 16777216net.ipv4.tcp_wmem = 4096 65536 16777216

Три значения параметра tcp_rmem/tcp_wmem обозначает соответственно минимальное, пороговое и максимальное значение. По умолчанию величины выставлены довольно разумно, поэтому менять их без веских оснований не стоит. Чаще всего такая ситуация может возникнуть на сети с пропускной способностью 10 GiB/s. После сохранения изменений в файле sysctl.conf следует выполнить systcl -p. Эта команда запускает системный вызов setsockopt (SO_RCVBUF).
Следует отметить, что буфер setsockopt(SO_RCVBUF), установленный в приложении, будет ограничен значениями, установленными в net.core.rmem_default и net.core.rmem_max и если приложение имеет буфер размером 1 мб, но net.core.rmem_max составляет всего 256 кб, то буфер сокета приложения будет ограничен этим значением.

Диагностика сети с помощью системных вызовов

Для любого сетевика WireShark абсолютно необходимый инструмент отладки, иногда главный. Не раз и не два только благодаря WireShark удавалось спасти проект в очень сложной ситуации. Но бывают случаи, когда только в системных вызовах ядра можно увидеть сетевую проблему.
В частности отброшенные пакеты нельзя будет увидеть в tcpdump, или WireShark. Зато можно их увидеть в режиме реального времени с помощью tcpdrop из сета bcc-tools. У команды нет никаких опций, просто выполните tcpdop. Вывод состоит из сокета, статусе соединения и флагах TCP. Далее идет трассировка стека ядра, которая привела к этому сбросу пакета.

(1:1013)$ /usr/share/bcc/tools/tcpdropTIME     PID    IP SADDR:SPORT  > DADDR:DPORT  STATE (FLAGS)16:31:07 3103   4  93.184.216.34:443       > 192.168.11.32:36222   ESTABLISHED (PSH|ACK)b'tcp_drop+0x1'b'tcp_data_queue+0x1e7'b'tcp_rcv_established+0x1df'b'tcp_v4_do_rcv+0x131'b'tcp_v4_rcv+0xad3'b'ip_protocol_deliver_rcu+0x2b'b'ip_local_deliver_finish+0x55'b'ip_local_deliver+0xe8'b'ip_rcv+0xcf'b'__netif_receive_skb_core+0x429'b'__netif_receive_skb_list_core+0x10a'b'netif_receive_skb_list_internal+0x1bf'b'netif_receive_skb_list+0x26'b'iwl_pcie_rx_handle+0x447'b'iwl_pcie_irq_handler+0x4d5'b'irq_thread_fn+0x20'b'irq_thread+0xdc'b'kthread+0x113'b'ret_from_fork+0x35'

В bcc-tools имеется еще одна очень полезная утилита tcplife, которая показывает параметры TCP соединение, в том числе, длительность сеанса. У этой команды есть некоторые опции.

(1:1014)$ /usr/share/bcc/tools/tcplife -h...examples:    ./tcplife           # trace all TCP connect()s    ./tcplife -T        # include time column (HH:MM:SS)    ./tcplife -w        # wider columns (fit IPv6)    ./tcplife -stT      # csv output, with times & timestamps    ./tcplife -p 181    # only trace PID 181    ./tcplife -L 80     # only trace local port 80    ./tcplife -L 80,81  # only trace local ports 80 and 81    ./tcplife -D 80     # only trace remote port 80

Просмотр сессий выглядит так.

# ./tcplife -D 80PID   COMM       LADDR           LPORT RADDR           RPORT TX_KB RX_KB MS27448 curl       100.66.11.247   54146 54.154.224.174  80        0     1 263.8527450 curl       100.66.11.247   20618 54.154.164.22   80        0     1 243.6227452 curl       100.66.11.247   11480 54.154.43.103   80        0     1 231.1627454 curl       100.66.11.247   31382 54.154.15.7     80        0     1 249.95

Может так случится, что между клиентом и сервером расположен межсетевой экран, либо IPS/IDS с набором правил по обрыву длительности TCP сессии по прошествии определенного времени, или достижении некоего объёма трафика. В этом случае диагностика подобного кейса может затянутся неопределенно долго, так как находится в слепой зоне, как со стороны клиентского, так и со стороны серверного приложения. Единственный способ понять в чему тут дело, это использовать инструменты bcc-tools.

Недооцененный резолвинг

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

getnameinfo(getaddrinfo(HOSTNAME)) = HOSTMANE

ункции getnameinfo и getaddrinfo являются заменой устаревших gethostbyname и gethostbyaddr соответственно.

int getnameinfo(const struct sockaddr *addr, socklen_t addrlen,    char *host, socklen_t hostlen,    char *serv, socklen_t servlen, int flags);int getaddrinfo(const char *node, const char *service,    const struct addrinfo *hints, struct addrinfo **res);

Положительный пример lib.ru

(1:1015)$ host lib.rulib.ru has address 81.176.66.163...(1:1016)$ host 81.176.66.163163.66.176.81.in-addr.arpa domain name pointer lib.ru.Отрицательный пример - example.com.(1:1017)$ host example.comexample.com has address 93.184.216.34(1:1018)$ host 93.184.216.34Host 34.216.184.93.in-addr.arpa. not found: 3(NXDOMAIN)

Если бы IP 93.184.216.34 указывал не на example.com, а на иной хост, то и это было бы ошибкой. Только тождество результат двустороннего разрешения имен гарантирует отсутствие ошибок настройки.
Вообще-то используя утилиту host следует помнить, что она так же, как dig и nslookup используют лишь DNS для разрешения имён хостов и игнорируют записи в файле /etc/hosts. По этой причине целесообразнее использовать команду getent.

(1:1019)$ strace -f -e trace=openat host my.router 2>&1 |grep -e "^openat" -e addressopenat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libuv.so.1", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libunistring.so.2", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/proc/self/task/7164/comm", O_RDWR) = 3(1:1020)$ strace -f -e trace=openat getent ahosts my.router openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libunistring.so.2", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/charset.alias", O_RDONLY|O_NOFOLLOW) = -1 ENOENT (No such file or directory)192.168.10.10    STREAM my.router192.168.10.10    DGRAM  192.168.10.10    RAW    +++ exited with 0 +++

Из вывода видно, что host не обращается к файлу /etc/hosts и по этой причине не в состоянии определить IP адрес маршрутизатора. Напротив, getent ищет в этом файле и находит соответствующую запись.

Использованные материалы

• How can I tune the TCP Socket Buffers?
• Resolve IP адресов в Linux: понятное и детальное описание
• Brendan Gregg's Blog

Возможно, протокол передачи файлов 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 лет в той или иной форме он отлично нам послужил.