Jakie techniczne ograniczenia uniemożliwiają nam, w chwalebnym roku 2011, wysyłanie sobie nawzajem plików 1 GB?
Czy to tylko główne platformy e-mailowe zwlekają?
Jeśli mogę ustawić moją skrzynkę odbiorczą, aby pobierała tylko nagłówki, a następnie pełne załączniki, jeśli ich chcę, jaki jest problem?
Wydaje mi się, że rozmiary załączników wiadomości e-mail utknęły w 1992 roku ...
email
attachment
Rysował
źródło
źródło
uucp
sesję.Odpowiedzi:
Problem jest następujący: e-mail (SMTP / POP3 / IMAP / what-have-you) to starożytny, prosty protokół pierwotnie przeznaczony do wysyłania wiadomości w postaci zwykłego tekstu w zaufanej sieci. Używanie go do wysyłania lub odbierania dużych ilości danych binarnych przez dzisiejszy Internet to haczykowaty atak, całkowicie odmienny od pierwotnego przypadku użycia, i raczej nieszczęśliwie pełni tę rolę.
Po dołączeniu pliku do wiadomości e-mail kodowany jest w formacie base64, co zwiększa jego rozmiar o 1/3. W ten sposób Twój plik 1 GB staje się o kolejne 300 MB większy; ponadto nie ma wbudowanej kompresji protokołu pobierania, więc nie ma sposobu na przyspieszenie transferu (aw niektórych przypadkach (SMTP do wysyłania, POP3 do odbierania), nawet nie ma możliwości wznowienia zerwanego transferu - połączenie zostało zerwane na 1,2 GB? Przepraszamy, musisz ponownie przesłać wszystko ponownie). Ponadto SMTP jest protokołem przechowywania i przesyłania. Zgadnij co? Tak, ten plik 1,3 GB należy skopiować na wiele serwerów; wskazuj nieograniczone szczęście od administratorów serwera pocztowego.
Był to problem w latach 90., kiedy nie było żadnej użytecznej alternatywy (FTP? HTTP / 1.0? Puh-leeze); ale w chwalebnym roku 2011, z różnymi sposobami bezproblemowego pobierania / pobierania danych do / z chmury (np. Dropbox, Ubuntu One, Amazon S3, aby wymienić najbardziej znane), wymówka „nie ma innego przydatnego sposobu, aby to zrobić „nie jest już prawdą.
Należy również pamiętać, że nie każdy ma łącze 100 Mbit do Internetu - np. Telefon komórkowy i smartfon; nie każdy klient poczty jest w stanie pobierać tylko nagłówki (np. POP3 jest nadal w użyciu) i nie każdy użytkownik jest skłonny pobrać 20 nieuniknionych wiadomości e-mail z „funneh 1 GB wideo” na tydzień, które się pojawią ( ludzie wyślą tak duże pliki, na ile pozwala im system; i tak, jest coś takiego jak FUP z większością dostawców usług internetowych).
TL; DR : chociaż technicznie możliwe byłoby robienie takich rzeczy, jak wysyłanie e-mailem pliku 1 GB, technicznie możliwe byłoby również wbicie gwoździa za pomocą śrubokręta - to po prostu nie jest dobry sposób, aby to zrobić, ponieważ istnieją narzędzia bardziej odpowiednie do takich zadań.
źródło
To samo, ale z nieco innego punktu widzenia:
E-mail to poczta elektroniczna. Znasz pocztę jako tę starożytną papierową rzecz w kolejnej małej papierowej kopercie. Możesz napisać na nim dużo tekstu, ale nie więcej niż 5 lub 6 stron. I e-mail jest taki sam, ale elektroniczny. Jest przeznaczony do tekstu (zwykły tekst jak na maszynie do pisania). Potem było rozszerzenie MIME, w którym możesz wysyłać te fantazyjne, migające na czerwono wiadomości HTML.
Nikt na świecie nie narzekałby i nie powiedziałby: „Och, poczta utknęła tak, jak w 1322 r. Dlaczego nie mogę wysłać słonia w papierowej kopercie?” Tak to jest. Do tego rodzaju rzeczy ludzie wymyślili coś w rodzaju paczki lub kontenera transportowego. Oto jak wysyłać towary i słonie. A faceci z Internetu wymyślili FTP (protokół przesyłania plików), masz nazwę?
W prawdziwym świecie istnieje wiele alternatyw dla FTP, ponieważ FTP to również starożytny protokół z dużymi wadami (głównie pod względem bezpieczeństwa, a nie przesyłania plików). Ale HTTP nie jest alternatywą, ponieważ został opracowany do scentralizowanego przechowywania dokumentów z metadanymi. To, że możesz pobierać i przesyłać pliki, jest brutalnym rozszerzeniem tego.
Więc użyj listu, aby wysłać tekst i paczki, aby wysłać towary; użyj wiadomości e-mail, aby wysłać informacje i protokołów transportu plików, aby wysłać pliki.
Edytować:
Aby pozostać na zdjęciu, muszę dodać: Nawet jeśli przekonasz lokalny urząd pocztowy, aby zaakceptował słonie w papierowych kopertach (i uiścił dodatkową opłatę), jest więcej stron zaangażowanych w dostarczanie słonia. Jest listonosz, który musi zanieść go na następną pocztę i prawdopodobnie nie ma odpowiedniej torby dla słonia. Może jednak ma i chce dostarczyć ją na następną pocztę, która z kolei mówi: „Nie nie akceptujemy słoni ”.
Co wtedy zrobić? Dobry listonosz w prawdziwym świecie zabrałby słonia z powrotem na pierwszą pocztę, a potem do nadawcy. (W świecie elektronicznym byłby to zły listonosz, ponieważ powinien był zastrzelić słonia i dostarczyć tylko nadawcy świadectwo śmierci).
Więc nawet jeśli zdołasz przekonać wszystkie linki w łańcuchu doręczeń pocztowych do przyjęcia słoni, masz do czynienia z odbiorcą. Mógłby powiedzieć, że chce słonia, ale skrzynka na listy jest za mała, żeby mógł się zmieścić. Prowadzi do dostawy słonia z powrotem do nadawcy. (Nie wspominając o tym, co się stanie, jeśli słoń nie zmieści się w skrzynce pocztowej nadawcy ...)
źródło
Content-Type: application/x-pachyderm
nagłówek, HTTP doskonale nadaje się do przesyłania słoni;) Dobre punkty, chociaż mój protokół z wyboru byłbyrsync
- dość dobrze dostępny, pozwala na kompresję, synchronizację delta, ciągły transfer, a także dobrze współpracuje z SSH (dla auth + szyfrowanie).Będąc w sytuacji z Exchange 2007, w której kierownictwo przyjęło filozofię „bez limitu rozmiaru wiadomości e-mail”:
Użytkownik wewnętrzny wysłał wiadomość na swój adres Hotmail z .iso płyty CD z muzyką. Zablokowano kolejkę na jednym serwerze transportowym podczas przetwarzania wiadomości, zapalono ciśnienie wsteczne, zatrzymano przesyłanie wiadomości. Perspektywa użytkownika następnie posłusznie przesłała wiadomość do innego działającego serwera transportowego; przeciwciśnienie, brak przesyłania wiadomości.
Gdy oba serwery transportu dławią wiadomość, wszystkie wychodzące wiadomości e-mail zostały zatrzymane na około 90 sekund. Hotmail oczywiście odrzucił wiadomość. Niedługo potem obowiązywał limit wielkości.
źródło
Oto inny widok:
Ponieważ wiadomość e-mail jest przechowywana w wielu instancjach, wysłanie pliku 1 GB zużyłoby to kilka razy.
Zwykle będzie to kopia na twoim kliencie w „Wysłane elementy”, a jeśli używasz IMAP, kopia na serwerze może się również pojawić (na Twoim koncie).
Następnie strona odbierająca zachowa kopię (serwer), a także u lokalnego klienta po stronie odbierającej. Jeśli używasz IMAP, nie zostanie on usunięty na serwerze (ponownie).
To w sumie 4 GB na pojedynczy plik 1 GB. Oczywiście możesz uznać to za kopię zapasową, ale są też lepsze opcje. Nie wspominając o powolności, która może wystąpić na serwerze, ponieważ skrzynki pocztowe użytkowników rosną w nieskończoność.
I właśnie zdałem sobie sprawę, że jeśli plik jest zakodowany w standardzie base64, będzie jeszcze większy (chyba o 33% większy).
źródło
Aby uzupełnić odpowiedź Piskvora.
Tak, „główne platformy e-mailowe” zwlekają. Robią to za pomocą protokołu (SMTP), który nie spełnia dzisiejszych standardów (na wiele sposobów).
W dzisiejszym świecie moglibyśmy z łatwością zaprojektować protokół zastępujący SMTP, który rozwiązałby bieżący problem z załącznikiem.
Problem polegałby na tym, żeby świat się na to przełączył.
źródło
Wspomniany problem dotyczy głównie problemów logistycznych związanych z przechowywaniem i przesyłaniem danych - we współczesnej abstrakcji chmury plik nie musi już być fizyczny - abstrakcja uchwytu pliku może być używana do owijania różnych metod przechowywania (np. Dysk lokalny, ftp , http, torrent, youtube, przechowywanie w chmurze, darknet, załącznik, muł, rozproszone pliki, fragmenty, wersje) - to nie jest nowy pomysł, po prostu nie jest jeszcze w pełni tutaj ani w jednym kawałku. kiedy lub jeśli nadejdzie, załącznik będzie po prostu wskaźnikiem pliku, którego można użyć bezpośrednio(np. nie plik .torrent ani łącze) odtwarzaczy wideo lub innego oprogramowania. faktyczna obsługa pobierania lub przechowywania treści odbywałaby się w sposób transparentny, treść może być częściowo zlokalizowana z wielu źródeł zdefiniowanych w manifeście podlegającym wspólnej weryfikacji (np. jak plik .torrent, ale powszechnie akceptowany, z możliwością zmiany ograniczeń dostępności i lokalizacji); rzeczywiste pobieranie i przechowywanie / buforowanie może często być częściowe, w zależności od tego, która część została wyświetlona, a nawet jeśli masz problem z dostępem do treści - tak, aby ogromny załącznik teściowej nie pochłonął żadnej z przepustowości twojego domu jeśli nie jesteś fanem jej e-maili. Aby uzyskać trwałość lub dostępność, może „
źródło