Есть ли разница в скорости передачи файлов по FTP и Samba?
У меня есть настройка домашней сети с настольным ПК, двумя ноутбуками и рабочим столом сервера Ubuntu, подключенных к маршрутизатору (DD-WRT). Я хочу настроить сервер Ubuntu на отдельном поддомене (по соображениям безопасности: у меня есть веб-сайты, входящие на сервер), но я также хочу иметь доступ к резервным дискам, которые я установил на сервере. Я знаю, что могу настроить FTP-сервер в Ubuntu, но мне интересно, не потеряю ли я скорость при передаче таким способом. Кто-нибудь знает решение, которое я могу использовать?
2 ответа 2
FTP должен быть быстрее, чем SMB/CIFS (протокол, который реализует Samba), если вы просто передаете полные файлы. SMB/CIFS реализует полную файловую систему, и это всегда будет иметь больше издержек, чем просто отправка пакета байтов на другую сторону.
По моему опыту, это действительно зависит от сборки и конфигурации сервера Linux.
Я видел реализации / сборки Samba, которые имеют ужасную производительность, и другие сборки, где он работает быстрее, чем Windows для Windows.
FTP, вероятно, является наиболее простым решением для установки, однако Samba гораздо более функциональна.
Что касается других моментов, маршрутизатор не имеет значения, я не совсем уверен, что это как-то связано с этой настройкой, и нет необходимости в других поддоменах, так как вы всегда можете использовать IP или другие параметры безопасности.
Это было немного сложно, если я что-то пропустил или вы хотите, чтобы я уточнить какие-либо вопросы, пожалуйста, скажите!
Какой сетевой протокол обмена файлами имеет лучшую производительность и надежность? [закрыто]
У нас есть настройка с несколькими веб-серверами с балансировкой нагрузки. Мы хотим иметь какое-то сетевое общее хранилище, к которому могут обращаться все веб-серверы. Он будет использоваться как место для хранения файлов, загруженных пользователями. Все работает под управлением Linux.
Должны ли мы использовать NFS, CIFS, SMB, fuse + sftp, fuse + ftp? Есть так много вариантов для сетевых протоколов обмена файлами, что очень трудно выбрать один. Мы просто хотим постоянно смонтировать этот общий ресурс на нескольких машинах. Функции безопасности не так важны, потому что сеть не будет доступна из других источников, кроме серверов, на которых она установлена. Мы просто хотим, чтобы он работал надежно и быстро.
Какой из них мы должны использовать?
В NFSv4.1 добавлена возможность Parallel NFS pNFS, которая делает возможным параллельный доступ к данным. Мне интересно, какие клиенты используют хранилище, если только в стиле Unix, тогда я бы остановился на NFS, основываясь на показателях производительности.
Редхат хорошо справляется со списком плюсов и минусов кластера FS против NFS. В основном, если вы хотите масштабировать пространство, GFS, вероятно, стоит усилий. Кроме того, в примере GFS в качестве примера используется сеть Fibre Channel SAN, но это также может быть RAID, DAS или iSCSI SAN.
Наконец, обязательно изучите Jumbo Frames, и если целостность данных имеет решающее значение, используйте контрольную сумму CRC32, если вы используете iSCSI с Jumbo Frames.
У нас есть веб-кластер, ограничивающий нагрузку на 2 сервера. Мы попробовали следующие методы для синхронизации контента между серверами:
Самым быстродействующим общим диском был кластерный диск OCFS2 вплоть до тех пор, пока он не сошел с ума и не сломал кластер. Мы не смогли поддерживать стабильность с OCFS2. Как только несколько серверов получают доступ к одним и тем же файлам, нагрузка поднимается через крышу и серверы начинают перезагружаться. Это может быть провал тренировки с нашей стороны.
У SMB (CIFS) были некоторые проблемы с блокировкой. В частности, изменения в файлах на сервере SMB не были замечены веб-серверами. SMB также склонен зависать при сбое на SMB-сервере.
Мы пришли к выводу, что OCFS2 обладает наибольшим потенциалом, но требует много анализа, прежде чем использовать его в производстве. Если вы хотите что-то простое и надежное, я бы порекомендовал кластер NFS-сервера с Heartbeat для отработки отказа.
Есть ли разница в скорости передачи файлов через FTP и Samba?
У меня есть домашняя сеть с настольным ПК, двумя ноутбуками и настольным компьютером ubuntu server, подключенным к маршрутизатору (DD-WRT). Я хочу настроить сервер ubuntu на отдельном поддомене (по соображениям безопасности: у меня есть веб-сайты, входящие в сервер), но я также хочу иметь доступ к резервным дискам, которые я установил на сервере. Я знаю, что могу настроить FTP-сервер на Ubuntu, но мне интересно, потеряю ли я скорость при передаче таким образом. Кто-нибудь знает решение, которое я могу использовать?
2 ответов
по моему опыту, это действительно зависит от сборки и настройки сервера Linux.
Я видел реализации / сборки Samba, которые имеют ужасную производительность и другие сборки, где она кажется быстрее, чем Windows для Windows.
FTP, вероятно, самое прямое решение для установки, однако Samba гораздо более многофункциональна.
например, с Samba, вы можете отобразить диск, потоковое видео и многое другое-он действует как стандартный общий ресурс windows, где, как и без стороннего дополнения, FTP очень хорош для хранения и извлечения файлов,но это все.
Что касается других точек, маршрутизатор не имеет значения, я не уверен, что имеет какое-либо отношение к этой настройке, и нет необходимости в разных поддоменах, поскольку вы всегда можете использовать IP или другие параметры безопасности.
Это было немного сложно, если я что-то пропустил или вы хотите, чтобы я разъяснил какие-либо моменты, пожалуйста, скажите!
FTP должен быть быстрее, чем SMB /CIFS (протокол, реализуемый Samba), если вы просто передаете полные файлы. SMB / CIFS реализует полную файловую систему, и это всегда будет иметь больше накладных расходов, чем просто отправка кучу байтов на другую сторону.
Ftp или smb что лучше
Чтобы правильно оптимизировать систему, хотелось бы понимать что и для чего делаешь. Сейчас у меня цель добиться максимальной скорости чтения больших файлов с сервера.
Если с FTP все более-менее прозрачно (файл передается по TCP, FTP сервер ждет от FTP клиента только подтверждение о приеме всего файла, подтверждения приема пакетов лежит целиком на TCP, латентность практически не влияет на скрость при достаточно большом TCP окне), то про SMB я ничего не нашел. С точки зрения API программа на клиенте запрашивает только очередной блок, в принципе, произвольного размера, обычно равного размеру внутреннего буфера программы. Асинхрнное чтение если и поддерживается SMB, то явно его большинство программ не использует (никто не просит следующий блок до того, как получил полностью предыдущий). То есть получается, что скорость чтения файла по SMB, в отличии от FTP, очень сильно зависит от латентности сети. В итоге оптимизация для FTP и SMB должна выполнятся совершенно по разному. Например, значения interrupt moderation, настройки поллинга и т.п. должны быть совершенно разными. Или я не прав?
Кто-то вообще этот вопрос анализировал? Или все действуют только по принципу научного тыка?
| 1. «SMB протокол vs FTP» | |
Сообщение от idle  (ok) on 29-Июн-07, 11:02 | |
| Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору |
 | |
| 2. «SMB протокол vs FTP» | |
Сообщение от ptr  (??) on 29-Июн-07, 12:47 | |
Есть много существенных ограничений, не позволяющих использовать ftp. По всем критериям, кроме скорости, Samba для меня оптимальна на конкретном сервере и для конкретного применения. Домашний сервер. Часть 2. FTP, Samba и rTorrentПришло время организовывать файловое хранилище, как внутри сети так и снаружи. Данная статья является продолжением первой части, посвященной настройки WiFi роутера на Вашем домашнем сервере. Все жесткие диски с Вашего домашнего компьютера(кроме системного) можно перенести на сервер, поскольку скорость передачи данный колеблется в районе 10-20 мегабайт в секунду [данный параметр еще и очень сильно зависит от модели Вашего жесткого диска], да и кстати, давно уже пора для системного диска покупать SSD накопители. FTP Server. Теперь перейдем к описанию. Это консольный ftp server, у него нет GUI [графическая оболочка], поэтому вся настройка происходит в одном единственном конфиге, по адресу /etc/vsftpd.conf. В приведенном выше конфиге нет заморочек для распределения прав доступа отдельным пользователям, отдельных папок. Всё довольно просто и лаконично, настроил один раз и пользуешься [пользуются]. Vsftpd был выбран, потому что у него лучшая система настройки прав доступа, которая подразделяется на два вида: внутренняя, системная аутентификация и внешняя, с отдельным конфигурационным файлом для распределения прав доступа, но при этом, пользователи всё также берутся из системы. В данном примере и пользователи, и распределение прав доступа этих самых пользователей берется из системы, дополнительный конфиг-файл не используется. Samba. Изначально, при стандартной установке системы OpenSUSE всё что нужно для установки и настройки samba на сервере уже предустановлено. Поэтому перейдем непосредственно к настройке. Поскольку доступ из под ОС Windows в качестве «Подключения сетевого диска» будет доступен только внутри Вашей локальной сети Также, дополнительную настройку можно выполнить через встроенный в YaST GUI samba. Того пользователя, что мы указали в самом начале конфига, в данном примере это пользователь nobody, необходимо создать непосредственно в системе. Задать ему необходимые права (дома, имеет смысл поставить полные права, на создание, удаление, редактирование всех файлов и папок (т.е. права 777). Также, если Вы столкнетесь с ситуацией, когда по какой-то причине станет невозможным удаление/создание файлов в какой-либо из папок на сервере, то выполните команду: Разберем её, на всякий случай: rTorrent.
Собственно и все. Далее хитрый приём, — открываем консоль и пишем(можно и по ssh зайти на сервер):
Это говорит о том, что процесс Вашего торрент-клиента «закринин», то есть выполняется, но его при этом не видно. Для тех, адептов, кому всегда, всё интересно, может прочесть вот здесь про данную утилиту обременять голову такими вещами (хотя, они очень интересные и познавательные, и применяются часто) принудительно я не хочу. На этой «важной» ноте, я хочу закончить данную статью. Спасибо за внимание, и да, пользуйтесь поисковиком Google, он молодец! Если ошибся топиком, подскажите куда перенести.  Привет, друзья! Сегодня мы с вами поговорим о замечательной  Привет, дорогие дети! Сегодня я хочу рассказать вам  Дорогие дети, сегодня мы поговорим о загадочной поговорке «  Привет, дорогие дети! Сегодня мы поговорим о забавной | |
