Вопрос: Почему у нас все еще есть такие небольшие ограничения на вложения файлов вложений? [закрыто]


Каково техническое ограничение, препятствующее нам в славном году 2011 года отправлять по электронной почте друг другу 1 ГБ файлы?

Или это просто основные платформы электронной почты, тащат ноги?

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

Я чувствую, что размеры вложений электронной почты застряли в 1992 году ...


50
2017-08-24 07:30


Источник


Размеры вложений застряли в 1992 году? Puh-leeze. я бы хотел увидеть тебя перевод файл в 50 МБ в 1992 году Любые метод, не говоря уже о прикреплении его к электронному письму (да, у меня есть несколько таких электронных писем с этого текущего месяца в 2011 году, нет, я не очень этому доволен). Подсказка: предпочтительный метод, в 1992 году, мог включать в себя копирование на магнитную ленту и движение к месту назначения, или, возможно, ночной дозвон и uucp сессия. - Piskvor
@Piskvor: Альтернативно, продуктовый мешок, полный дисков, содержащих многотомные архивы arj. Непонятно: cs-exhibitions.uni-klu.ac.at/index.php?id=187 - sum1stolemyname
Пропускная способность имеет мало или ничего общего с ней; если то, что вам нужно общаться с кем-то еще, превышает 20 мегабайт, электронная почта не способ отправить его, - Shadur
@Shadur: он делает, в случае нежелательной почты - ссылку в электронном письме (который получатель выбирает щелчок или нет) берет тысячи байтов в крайнем конце; прикрепленный файл в электронном письме в большинстве случаев загружается без подсказки (я знаю о возможностях IMAP в этом отношении, но у большинства пользователей этот набор «загружает все», что в некотором роде влияют на пропускную способность - также используются для других целей, кроме почты: обычная жалоба не ИТ-пользователей перед широкополосной связью: «Почему мой веб настолько медленный? Да, я отправил электронную почту 10 МБ с танцевальными свиньями со 100 людьми в BCC , как это уместно? ») - Piskvor
@Piskvo «Никогда не недооценивайте полосу пропускания грузовика с лентами»; как сегодня, так и сегодня: вы можете получить> 1 ТБ на один лента.... - Richard


Ответы:


Проблема заключается в следующем: электронная почта (SMTP / POP3 / IMAP / what-have-you) представляет собой древний простой протокол, первоначально предназначенный для отправки сообщений открытого текста в доверенной сети. Использование его для отправки или получения большого количества двоичных данных через сегодняшний Интернет - это взломанный взлом, полностью отличный от исходного варианта использования, и он выполняет довольно скудную роль в этой роли.

Когда вы прикрепляете файл к электронной почте, он получает base64-кодировку, что увеличивает его размер на 1/3. Таким образом, ваш 1-гигабайтный файл станет еще больше на 300 МБ; также нет встроенного сжатия для протокола загрузки, таким образом, нет возможности ускорить передачу (и в некоторых случаях (SMTP для отправки, POP3 для приема), даже нет способа продолжить сломанная передача - соединение сломалось на 1,2 ГБ? Извините, вам нужно снова передать все это снова). Кроме того, SMTP - это протокол хранения и передачи. Угадай, что? Yup, что файл объемом 1,3 ГБ необходимо скопировать на нескольких серверах; cue неограниченное счастье от админов почтового сервера.

Это было проблемой в 1990-х годах, когда не было никакой полезной альтернативы (FTP? HTTP / 1.0? Puh-leeze); но в славном году 2011 года, с различными способами плавного добавления / загрузки данных в / из облака (например, Dropbox, Ubuntu One, Amazon S3, чтобы назвать наиболее известных), оправдание «нет другого полезного способа сделать это «больше не соответствует действительности.

Также обратите внимание, что не все находятся на 100 Мбит ссылке в Интернет - например, мобильный и смартфон; не каждый почтовый клиент способен загружать только заголовки (например, POP3 по-прежнему пользуется большим спросом), и не каждый пользователь хочет загрузить 20 неизбежных «взглядов на это funneh 1 ГБ видео» по электронной почте в неделю, будем (люди будут отправлять как большие файлы, так и система, и да, есть что-то вроде FUP с большинством интернет-провайдеров).

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


160
2017-08-24 07:48



+1 Это очень хороший ответ :) - Antoine Benkemoun
Ссылка 100Mb? Если вы не являетесь корпорацией, никто имеет ссылку 100Mb здесь, в Австралии. - Matthew Scharley
+1 для версии TLDR :-) - Doctor Jones
Мой почтовый клиент будет любить 1GB-файл, закодированный в base64. - Prisoner
+1 никоим образом не возобновить сломанную передачу. - mr_eclair


То же самое, но с несколько иной точки зрения:

Электронная почта - электронная почта. Вы знаете почту как эту древнюю бумажную штучку в другом маленьком бумажном конверте. Вы можете написать много текста, но не более 5 или 6 страниц. И электронная почта такая же, но электронная. Он предназначен для текста (обычный текст, например, на пишущей машинке). Затем было расширение MIME, где вы могли отправить эти модные красные мигающие письма HTML.

Никто в мире не пожаловался бы и не сказал бы: «О, почта застряла так, как это было в 1322 году нашей эры. Почему я не могу отправить слона в бумажный конверт?» Так оно и есть. Для такого рода вещей люди изобретали нечто вроде пакета или транспортного контейнера. Вот как отправить товар и слонов. И интернет-парни изобрели FTP (протокол передачи файлов), получили имя?

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

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


Редактировать:

Чтобы остаться на картинке, я должен добавить: Даже если вы убедите свое местное почтовое отделение принять слонов в бумажных конвертах (и заплатите дополнительную плату), есть еще несколько сторон, которые доставляют слона. Есть почтальон, который должен отнести его на следующее почтовое отделение, и, возможно, у него нет подходящей сумки для слона, чтобы вписаться. Но, возможно, он имеет и хочет доставить его на следующее почтовое отделение, которое, в свою очередь, говорит: «Нет мы не принимаем слонов ».

Что делать тогда? Хороший почтальон в реальном мире перенесет слона обратно в первое почтовое отделение - обратно к отправителю. (В электронном мире это было бы Плохо mailman, потому что он должен был расстрелять слона и вернуть свидетельство о смерти обратно отправителю).

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


30
2017-08-24 11:04



Приехать на! Пока есть Content-Type: application/x-pachyderm заголовок, HTTP вполне способен передавать слонов;) Хорошие моменты, хотя мой протокол выбора был бы rsync - достаточно хорошо доступен, позволяет выполнять сжатие, дельта-синхронизацию, непрерывную передачу, плюс хорошо работает с SSH (для шифрования auth +). - Piskvor
Даже подход P2P является разумным. Это зависит от аудитории. Многоадресная рассылка файла по электронной почте должна звонить всем тревожным звонкам. И, как вы сказали, другими словами, не следует следовать этому подходу: «Если у вас есть только молоток, то каждая проблема будет выглядеть как гвоздь». - mailq
Хм, да - для нескольких предполагаемых получателей, например. торренты имеют большой смысл; но по моему опыту вам по-прежнему нужен резерв (FTP? HTTP?) для тех пользователей, которые не разбираются во всех этих новомодных протоколах передачи. Как вы сказали, зависит от аудитории. - Piskvor


В ситуации с Exchange 2007, где руководство подписалось на философию «Без ограничений по размеру электронной почты»:

Внутренний пользователь отправил сообщение на свой адрес hotmail с .iso музыкального компакт-диска. Застревание очереди на одном транспортном сервере при обработке сообщения, освещенное обратное давление, прекращение подачи сообщения. Пользовательский взгляд затем покорно переслал сообщение другому рабочему транспортному серверу; противодавление, отсутствие подачи сообщений.

Когда оба транспортных сервера задыхаются от сообщения, вся исходящая электронная почта останавливается примерно на 90 секунд. Hotmail, конечно, отклонил сообщение. Очень скоро было ограничение размера.


16
2017-08-24 17:43





Вот еще один взгляд:

Поскольку электронное письмо хранится в нескольких экземплярах на этом пути, отправка файла объемом 1 ГБ будет использоваться в течение нескольких раз.

Обычно это будет копия на вашем клиенте в разделе «Отправленные», а при использовании IMAP может появиться и копия на сервере (в вашей учетной записи).

Затем принимающая сторона будет хранить копию (сервер), а также локальный клиент на принимающей стороне. Если вы используете IMAP, он не будет удален на сервере (еще раз).

Это всего 4 ГБ для одного 1 ГБ файла. Конечно, вы можете считать это резервной копией, но есть и другие варианты. Не говоря уже о медлительности, которая может возникнуть на сервере, потому что почтовые ящики пользователей растут бесконечно.

И я просто понял, что если файл закодирован base64, он будет еще больше (примерно на 33% больше, я думаю).


5
2017-08-24 13:53





Дополнить ответ Писквора.

Да, «основные платформы электронной почты» тащит ноги. Они делают это, используя протокол (SMTP), который не соответствует сегодняшним стандартам (во многих отношениях).

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

Проблема заключалась бы в том, чтобы мир переключился на него.


4
2017-08-24 15:25



В самом деле. «Электронная почта - это таракан средств коммуникации: вы просто не можете его убить». - Piskvor


Описанная проблема связана главным образом с проблемами логистики при хранении и передаче данных - в современной абстракции облаков файл больше не должен быть физическим - абстракция файла-дескриптора может использоваться для обертывания различных методов хранения (например, локальный диск, ftp , http, torrent, youtube, облачное хранилище, darknet, вложение, мул, распределенные fs, выдержки, ревизии) - это не новая идея, она просто не полностью здесь или в одной части. когда или когда он поступит, ваше почтовое вложение будет просто указателем файла, который можно использовать непосредственно (например, не файл .torrent, ни ссылка) видеоплеерами или любым другим программным обеспечением. фактическая обработка загрузки или хранения контента будет прозрачной, контент может быть частично расположен из нескольких источников, определенных в манифесте, совместимом с процессом (например, как .torrent-файл, но общепринятый и с возможностью пересмотра доступности и локальности); фактическая загрузка и хранение / кэширование часто могут быть частичными, в зависимости от того, какая часть была просмотрена, и если вы даже потрудились получить доступ к контенту, - поэтому огромная привязанность вашей тещи не съела бы вашу собственную пропускную способность если вы не поклонник ее писем. Для обеспечения стабильности или доступности, возможно, у вас будет почтовый клиент, который может фильтровать и пересматривать манифест хранилища, что приводит к переносу определенного нераскрытого вложения из его источников в хранилище облаков, когда его доступность сокращается, например


-2
2017-08-24 18:37



Насколько я ненавижу терминологию «облака», вы - описание наполовину верно; но все еще существуют требования к передаче (пропускная способность), хранение, даже если оно только промежуточное, и значительная задержка может быть вызвана отсутствием присутствия на «локальном» сервере. Даже если файл никогда не получает доступ получателем, первоначальный отправитель все равно должен передать весь файл «в облако», «облако» должно содержать весь файл (возможно, на неопределенный срок), а структуры для передачи всего этого могли бы должны быть введены в действие. Если мы изобретаем колесо, это может быть сделано лучше, чем это. - Chris S
«файл больше не должен быть физическим» - держитесь, когда я избавлюсь от своих дисков, поскольку они больше не нужны для тех духовный файлы;) У вас есть хорошая точка, что хранение и передача могут быть отвлечены, но они просто скрыты где-то по абстракции, не ушел. Вам понадобится действительно жирную трубку, чтобы уменьшить задержку доступа к файлу - например, начните воспроизведение HD-видео, ищите середину, закрутите большие пальцы в течение нескольких минут, пока запрашиваемые данные будут переданы вам (в отличие от нескольких миллисекунд для локального хранилища). И есть также одна-носовая-на-наносекундная скорость света. - Piskvor
true - все это может стать довольно медленным, если локальность или доступность не определены или не реализованы хорошо. но пользователь может определить их и взять на себя определенную ответственность за различные компромиссы скорости, пропускной способности, доступности и т. д., используя предварительно упакованные политики, правила фильтрации, атрибуты, теги, правила вывода. когда я отправляю электронное письмо с вложением, мне не нужно «загружать» их, поскольку данные просто становятся доступными получателю, затем данные перемещаются или копируются на диски и / или облачные хранилища на основе поведения двух сторон «правила управления выводами для менеджеров хранилищ». - Alife Toy
«пользователь определяет их и берет на себя определенную ответственность». Вы должны быть менеджером. - Chris S
не менеджер, а что-то гораздо хуже - сломанный футурист - Alife Toy