POP3 vs HTTP

[Duke]

И ждал подтверждение или опровержение своих догадок.

Помойму ты их получил

Насколько могу судить, не совсем так.
Вэб-интерфейс работает через HTTP в котором нет таких "потерь".

Совсем так ! Потери есть, причём такие же ! Да и как их может не быть, если протокол то един. И еслиб Веб интерфейс перекодировал подругому, то удалённый клиент его бы не понял!

т.е. тот же index.htm не является файлом?
Введи в любом поисковике строку "передача файлов через http" и увидишь предназначен он для этого или нет

Если так рассуждать, то можно сказать, что "можно смотреть ВЕБ страници по протоколам POP(Если ктонить сайт отправит), FTP(если ктонить зальёт), даже через шару )))

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

Нет. Все письма хранятся в одном файле ! Причём,ещё раз подчеркну, ВСЕ письма данной папки пользователя(например "корзина" "входящие") вместе с прекреплёнными,перекодированными файлами. Причём на всех почт. серверах, что под Windows, что под Linux.

И я больше двух лет не наблюдал.

Ага . Я тож не замечал больше 5 лет  

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

Всё тоже самое !

Естьли у кого-нибудь возможность погонять файл размером хотябы 1Мб и замерить при этом статистику отправленных/полученных байт через почтовик/вэб-интерфейс. Поделитесь пожалуйста этой самой статистикой.

Сильно не гонял. Килобайты не ловил ! И зделал вывод.
без разнице почтовик это либо Веб интерфейс. Плюс, минус несколько КБ! Чего я сразу и говорил. От стандарта протокола не уйдёш.
Совет: Хочеш обмениваться файлами большого размера используй FTP.

[Salagin]

EvgIg
Немного плаваете, учите мат.часть.


Советую глянуть описание bace64, mime64, plain/text

[EvgIg]

Salagin

Немного плаваете

Можно поконкретнее? Где и в чем я плаваю

За мат часть особая благодарность.
Читал про все это где-то в 96-98 годах в файлах скаченных из ФИДО. Подзабылось.
Вот что удалось добыть:

base64_encode() возвращает data закодированные в кодировке base64. Эта кодировка разработана для того, чтобы передовать двоичные данные через транспортные слои, которые не содержат восьмой бит, такие как почтовые тела.
Данные в кодировке Base64 занимают примерно на 33% больше места, чем оригинал.

Взято [Для просмотра ссылки зарегистрируйтесь]
О чем и было сказано выше.

Duke

Сильно не гонял.

Ладно. Пришлось.

Тест на передачу архивного файла по электронной почте и через вэб интерфейс.
Передача файла осущевствлялась с [Для просмотра ссылки зарегистрируйтесь] на [Для просмотра ссылки зарегистрируйтесь].
Размер файла 100 000 байт ровно.
Само письмо пустое.
В Bat'е письмо имеет размер 137 739 байт.
Для измерения объемов передаваемых данных был использован прокси сервер UserGate 2.8.0.142

Код Выделить Развернуть


                             Отправлено   Получено (в байтах)
Передача файла:
Bat                             137 833      639
mail.yandex.ru           108 231      59 157
Прием файла:
Bat                             107           140 200
pop3.freemail.ru         776           100 164
Всего за сеанс:
                                 322 162     596 044
Накладные расходы веб:
                                 75 215       295 884


Пояснения:
При передаче с [Для просмотра ссылки зарегистрируйтесь] было получено больше, т.к. после отправки сообщения загрузилось окно-сообщение об удачной отправке письма.
При приеме в Bat'e использовался диспетчер писем (прием заголовков) что вызвало бополнительный объем данных.
"Всего за сеанс" - это полный объем переданных данных включая авторизацию на yandex'e и freemail'e, загрузка страниц отправки и получения почты.
"Накладные расходы веб" - переданные данные при авторизации, загрузке страниц почтового вэб-интерфейса, загрузка картинок(забыл отключить ), плюс, как оказалось, оба почтовика еще лазют по куче всяких сайтов.

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

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

[Duke]

EvgIg Да помойму твои иследования интересны чисто теоритически ! Ибо разница в копейки между методами отправки. А исходящий трафик почти не у кого не платится. Разве что GPRS. Забей на это дело и отправляй так, как тебе удобнее. Ну а есл большой файл нужно отправить, заливай на ФТП, будет один в один.

[Salagin]

EvgIg

Для измерения объемов передаваемых данных был использован прокси сервер UserGate 2.8.0.142

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

При приеме в Bat'e использовался диспетчер писем (прием заголовков) что вызвало бополнительный объем данных.

Заголовки принимаются всегда, ведь вы получаете все письмо, а не только его body? Если вы используете фишку "Показать заголовки" то это никак не отражается на объеме трафика.

[EvgIg]

Duke

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

В принцыпе да.

Ибо разница в копейки между методами отправки.

33% - это не копейки, если файлы передаются часто и большого объема.
У меня есть клиенты, которые предают почти каждый день с десяток отсканированных страниц А4 формата (заполнены от руки, поэтому о распознавании речь не идет, а для читабельности приходится увеличивать разрешение) по модему.

А исходящий трафик почти не у кого не платится.

Как раз сижу на GPRS   У многих на этом форуме (и у моих знакомых) до сих пор модемное соединение.

Забей на это дело и отправляй так, как тебе удобнее.

Обычно у меня нет необходимости в отправке больших файлов. Просто так получилось ну и понесло. И пользоваться в ближайшее время буду Bat'ом.

заливай на ФТП

Может посоветуешь какой-нибудь ФТП сервер? Буду очень признателен.

Salagin

Я не понял, мы говорим о конечном объеме файла, положенного в ящик, или о трафике, который затратили на отправку/получение письма?

См. [Для просмотра ссылки зарегистрируйтесь] Там было сказано:

Вопрос - кто расточительнее?

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

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

Заголовки принимаются всегда, ведь вы получаете все письмо, а не только его body? Если вы используете фишку "Показать заголовки" то это никак не отражается на объеме трафика.

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

###
Еще раз вернусь:

Да помойму твои иследования интересны чисто теоритически !

Шепотом, озираясь. "Мне кажется, что это заговор!"
См. выше:

которые не содержат восьмой бит, такие как почтовые тела.

Теоретически современные протоколы способны передавать файлы без всяких перекодировок.
Но монстрам программной индустрии, видимо, не выгодно менять стандарты и как следствие свои программы. С нетерпением жду появление почтового протокола что-то навроде POP3(IMAP)+SMTP+FTP
А вся полемика с моей стороны началась из-за... ладно не будем об этом.
Лучше скажу так(приблизительно и грубо):
Все протоколы (POP3, HTTP, SMTP, FTP по крайней мере) работают примерно по одному принципу.
Клиент "стучится" на сервер и они некоторое время мило беседуют определяя кто есть кто.
Дальше идет передача информации Клиент-Сервер и Сервер-Клиент.
Среди этой информации есть и передача файлов.
Все это происходит в рамках протокола TCP/IP, поэтому передача файлов происходит почти один в один если не считать подтверждения приема, дополнительные запросы и повторную передачу потеряных пакетов.
А отличаются протоколы лишь тем, что клиент и сервер "разговаривают" на определенном языке который отличается от протокола к протоколу и описан в соответствующих стандартах.
В связи с тем, что передача файлов происходит почти один в один и было сделано предположение, что почтовые программы более расточительны (в связи с перекодировкой файла и, как следствие, непропорционального увеличения размера письма)  при передаче файла (а не письма как такового) нежели передача через веб-интерфейс. Что и было доказано практикой.

###
Кстати, в рамках проекта "Экономь свой трафик"  
Теоретически пока что
Если ваше соединение оплачивается по трафику и приходится много скачивать различных файлов с помощью различных менеджеров закачки, то советую вам уменьшить количество однавременно закачиваемых секций до 1 (единицы). Т.к. на каждую секцию создается новое подключение к серверу.

Пока что все.
PS: Если есть желание раскажу где и в чем вы не правы. Чего и от вас прошу в мою сторону.

[Salagin]

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

Насколько я понял, речь идет о поставляемом с Батом спам-фильтре BayesIt (не гарантирую точность написания), то он действительно работает с заголовками.

советую вам уменьшить количество однавременно закачиваемых секций до 1 (единицы). Т.к. на каждую секцию создается новое подключение к серверу.

Ну там трафика - все те же копейки...

[EvgIg]

Salagin

Насколько я понял, речь идет о поставляемом с Батом спам-фильтре BayesIt (не гарантирую точность написания), то он действительно работает с заголовками.

Речь шла о встроенном инструменте  "Диспетчер писем" (Account/Dispatch mail on Server/New messages only Ctrl+F2 в русской кажется так и называется "Диспетчер писем", сорри нет под рукой).
Так или иначе прием заголовков - дополнительный трафик в любом случае т.к. письмо получается сначала.

Ну там трафика - все те же копейки...

Копейка рубль бережет
Как говорится: наше дело предложить - ваше дело отказаться.

[Duke]

33% - это не копейки, если файлы передаются часто и большого объема.

Я не понял.... где ты эти 33% выиграть собираешся ? Уже же выяснили, что этих потерь не избежать, а разница в отправке между клиентами и вэб - КОПЕЙКИ !!!

Как раз сижу на GPRS

Но ты же не будеш 10мегов по GPRS постоянно пересылать...чтоб потери то почуствовать...

У многих на этом форуме (и у моих знакомых) до сих пор модемное соединение.

Ну и что ?  Вот как раз трафик на модеме,как правило, и не важен, а подождать пару минут закачивая лишнии 33% не критично .

Может посоветуешь какой-нибудь ФТП сервер? Буду очень признателен.

Для мелких нужд можеш поюзать [Для просмотра ссылки зарегистрируйтесь] Дают чегото около 32 мегов.
А поболе я честно говоря незнаю. Потому,как, у меня свой ФТП сервер в инете. Поищи в поисковиках.

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

Опять же не пойму....что и где было доказанно ? Ты как понять то не можеш, что ВЕБ интерфейс это просто интерфейс для того же самого ПОЧТОВОГО КЛИЕНТА !  

[EvgIg]

Duke

Уже же выяснили, что этих потерь не избежать, а разница в отправке между клиентами и вэб - КОПЕЙКИ !!!

Пожалуйста, читай внимательнее сколко байт было отправлено через почтовик и через вэб. То же самое с приемом. (См. ниже)

Но ты же не будеш 10мегов по GPRS постоянно пересылать...чтоб потери то почуствовать...

Лично я - нет, но, например, наш директор постоянно отправляет/принимает объемные письма через GPRS.

Вот как раз трафик на модеме,как правило, и не важен, а подождать пару минут закачивая лишнии 33% не критично .

Т.е. не важно 10 минут или 15?

New Mail

Благодарю.

Немного из более раннего:

Нет. Все письма хранятся в одном файле ! Причём,ещё раз подчеркну, ВСЕ письма данной папки пользователя(например "корзина" "входящие") вместе с прекреплёнными,перекодированными файлами. Причём на всех почт. серверах, что под Windows, что под Linux.

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

Ты как понять то не можеш, что ВЕБ интерфейс это просто интерфейс для того же самого ПОЧТОВОГО КЛИЕНТА !

Еще раз прошу - изучи внимательно таблицу теста.
По твоим выкладкам можно сделать выовод, что  137 833 байт =  108 231 байт, т.е. трафик в почтовике равен трафику в вэбе при отправке, а так же  140 200 = 100 164 при приеме.
(вопрос: куда деваются 40 килобайт при отправке/получении через вэб?)
Если так рассуждать, то заливаем сайт через FTP, потом смотрим его через HTTP и получается FTP=HTTP.
Хорошо, другой пример. Не сочтите за рекламу.
Заходим на сайт [Для просмотра ссылки зарегистрируйтесь], который является по своей сути файловым архивом и выбираем любой реферат. У нас есть два способа получить сей реферат: либо скачать по HTTP, либо заказать его на почту. Дак вот, закачивая через HTTP мы получаем "чистый" архив, а получая через почту с прибавкой в те самые 33%.
(упс, они отключили возможность доставки по почте, но суть от этого не меняется. Одной из возможных причин отключения может быть то о чем мы беседуем. Т.е. расход лишнего трафика)
Абстрагируйся от протоколов как таковых. Есть какое-то хранилище данных(не важно БД, архив файлов или еще что-то) к которым есть несколько способов доступа. И эти данные передаются в формате того способа доступа, который мы выбираем. Нам не надо задумываться как и что - сервер все делает за нас и, если необходимо, перегоняет данные из одного формата в другой.
При передаче файла без разницы какой протокол(pop3,smtp,http,ftp) - он передается один в один.
Но при передаче архива по почте письмо больше(максимум) на 33%.
Лишний трафик получается не из-за протокола передачи как такового, а из-за формата хранения передаваемых данных.

И еще из раннего:

Если так рассуждать, то можно сказать, что "можно смотреть ВЕБ страници по протоколам POP(Если ктонить сайт отправит), FTP(если ктонить зальёт), даже через шару)))

В точку! Насчет "можно смотреть ВЕБ страници по протоколам POP". Если не в курсе, то Оутлук создает письма в HTML формате(есть HTML/Text режимы) и в письме может быть что угодно - те же кнопки, галочки, списки, формы отправки заявок (конечно, возможно, порезанный, но HTML). В Бате встроенный (читай - урезаный) HTML редактор/просмотрщик. При этом Оутлук может ползать в инет через HTTP для закачки картинок по имеющимся в теле HTML письма ссылкам.