Mengapa kita masih memiliki batasan kecil file lampiran lampiran email? [Tutup]


52

Apa batasan teknis yang mencegah kita, pada tahun 2011 yang mulia, untuk saling mengirim email 1GB?

Atau hanya platform email utama yang menyeret mereka?

Jika saya dapat mengatur kotak masuk saya untuk mengambil header saja, dan kemudian lampiran penuh jika saya menginginkannya, apa masalahnya?

Saya merasa seperti ukuran lampiran email macet pada tahun 1992 ...


23
Ukuran lampiran macet pada tahun 1992? Puh-leeze. Saya ingin melihat Anda mentransfer file 50 MB pada tahun 1992, dengan metode apa pun yang tersedia, apalagi melampirkannya ke email (ya, saya punya beberapa email seperti itu dari bulan ini di tahun 2011 ini, tidak, saya Saya tidak begitu senang tentang hal itu). Petunjuk: metode yang disukai, pada tahun 1992, dapat mencakup menyalin ke tape dan mengemudi ke tujuan, atau mungkin dial-up dan uucpsesi sepanjang malam .
Piskvor

4
@Piskvor: Atau, kantong belanjaan yang penuh dengan disk berisi arsip multi-volume-span. Agak tidak terkait: cs-exhibitions.uni-klu.ac.at/index.php?id=187
sum1stolemyname

17
Bandwidth sedikit atau tidak ada hubungannya dengan itu; jika apa yang Anda harus berkomunikasi dengan orang lain lebih besar dari 20 megabita, email bukanlah cara untuk mengirimnya .
Shadur

2
@ Shadur: Ya, dalam kasus surat yang tidak diinginkan - tautan dalam surel (yang dipilih penerima untuk diklik atau tidak) membutuhkan ribuan byte pada ujung ekstrem; file terlampir dalam email, dalam banyak kasus, diunduh tanpa diminta (saya mengetahui kemampuan IMAP dalam hal ini, tetapi sebagian besar pengguna memiliki set ini untuk "mengunduh semuanya", yang agak akan mempengaruhi bandwidth - juga digunakan untuk keperluan lain selain surat: keluhan umum para pengguna non-IT sebelum broadband: "Mengapa web saya sangat lambat? Ya, saya memang mengirim email 10MB dengan babi menari dengan 100 orang di BCC, bagaimana itu relevan? ")
Piskvor

4
@Piskvo "Jangan pernah meremehkan bandwidth truk yang penuh dengan kaset"; sama benarnya hari ini seperti sebelumnya: Anda bisa mendapatkan> 1TB dalam satu kaset ....
Richard

Jawaban:


163

Masalahnya adalah ini: e-mail (SMTP / POP3 / IMAP / what-have-you) adalah protokol kuno dan sederhana yang awalnya ditujukan untuk mengirim pesan plaintext di jaringan tepercaya. Menggunakannya untuk mengirim atau menerima data biner dalam jumlah besar di internet saat ini adalah hack yang dibaut, sangat berbeda dari use case asli, dan kinerjanya lumayan menyedihkan dalam peran ini.

Saat Anda melampirkan file ke surel, ia akan disandikan base64, yang memperbesar ukurannya 1/3. Dengan demikian, file 1 GB Anda menjadi 300 MB lebih besar; juga, tidak ada kompresi bawaan untuk protokol pengunduhan, sehingga tidak ada cara untuk mempercepat transfer (dan dalam beberapa kasus (SMTP untuk pengiriman, POP3 untuk menerima), bahkan tidak ada cara untuk melanjutkan transfer yang rusak - koneksi terputus pada 1.2 GB? Maaf, Anda harus mengirim ulang semuanya lagi). Selain itu, SMTP adalah protokol store-and-forward. Tebak apa? Yup, file 1,3 GB itu perlu disalin ke beberapa server; isyarat kebahagiaan tak terbatas dari admin server mail.

Ini adalah masalah di tahun 1990-an, ketika tidak ada alternatif yang berguna (FTP? HTTP / 1.0? Puh-leeze); tetapi di tahun yang gemilang 2011, dengan berbagai cara dengan mulus / mengunduh data ke / dari cloud (mis. Dropbox, Ubuntu One, Amazon S3, untuk nama yang paling dikenal), alasan "tidak ada cara lain yang berguna untuk melakukan ini "Tidak benar lagi.

Perhatikan juga bahwa tidak semua orang memiliki tautan 100 Mbit ke Internet - mis. Ponsel dan smartphone; tidak setiap klien email hanya mampu mengunduh header (mis. POP3 masih banyak digunakan), dan tidak setiap pengguna bersedia mengunduh 20 email yang tak terelakkan "lihat video 1 GB video" email lucu ini per minggu yang akan muncul ( orang-orang akan mengirim file besar seperti sistem membiarkannya, dan ya, ada sesuatu seperti FUP dengan sebagian besar ISP).

TL; DR : walaupun secara teknis dimungkinkan untuk melakukan hal-hal seperti mengirim email file 1GB, secara teknis juga mungkin untuk menumbuk kuku menggunakan obeng - itu bukan cara yang baik untuk melakukannya, karena ada alat yang lebih cocok untuk tugas seperti itu.


10
+1 Itu adalah satu jawaban yang sangat bagus :)
Antoine Benkemoun

1
Tautan 100 MB? Kecuali Anda seorang korporasi, tidak ada yang memiliki tautan 100MB di Australia.
Matthew Scharley

15
+1 untuk versi TLDR :-)
Reinstate Monica

2
Klien email saya akan menyukai file 1GB yang disandikan di base64.
Tahanan

3
+1 tidak dapat melanjutkan transfer yang rusak.
mr_eclair

32

Sama tetapi dari tampilan yang sedikit berbeda:

Email adalah surat elektronik. Anda tahu surat sebagai benda kuno di kertas kecil lain. Anda dapat menulis banyak teks di atasnya tetapi tidak lebih dari 5 atau 6 halaman. Dan email itu sama tetapi elektronik. Ini dirancang untuk teks (teks biasa seperti pada mesin tik). Lalu ada ekstensi MIME di mana Anda bisa mengirim email HTML mewah yang berkedip merah ini.

Tidak ada seorang pun di dunia ini yang akan mengeluh dan berkata, "Oh, surat macet seperti pada 1322 Masehi. Mengapa saya tidak bisa mengirim gajah ke dalam amplop kertas?" Begitulah adanya. Untuk hal-hal semacam ini orang-orang menciptakan sesuatu seperti paket atau wadah transportasi. Ini adalah cara mengirim barang dan gajah. Dan orang-orang Internet menemukan FTP (protokol transfer file), dapatkan namanya?

Di dunia nyata ada banyak alternatif untuk FTP karena FTP juga merupakan protokol kuno dengan kerugian besar (kebanyakan dalam keamanan dan tidak dalam mentransfer file). Tetapi HTTP bukan alternatif karena dikembangkan untuk penyimpanan dokumen terpusat dengan data meta. Anda dapat mengunduh dan mengunggah file adalah ekstensi brutal untuknya.

Jadi gunakan surat untuk mengirim teks dan paket untuk mengirim barang; menggunakan email untuk mengirim informasi dan protokol pengiriman file untuk mengirim file.


Sunting:

Untuk tetap dalam gambar, saya harus menambahkan: Bahkan jika Anda meyakinkan kantor pos setempat untuk menerima gajah dalam amplop kertas (dan membayar biaya tambahan), ada lebih banyak pihak yang terlibat dalam pengiriman gajah. Ada tukang pos yang harus membawanya ke kantor pos berikutnya dan mungkin dia tidak memiliki tas yang pas untuk gajah. Tapi mungkin dia punya dan ingin mengirimkannya ke kantor pos berikutnya yang pada gilirannya mengatakan: "Tidak kami tidak menerima gajah ".

Lalu apa yang harus dilakukan? Tukang pos yang baik di dunia nyata akan membawa gajah kembali ke kantor pos pertama - kembali ke pengirim sesudahnya. (Dalam dunia elektronik ini akan menjadi tukang pos yang buruk karena ia seharusnya menembak gajah dan hanya memberikan sertifikat kematian kembali ke pengirim).

Jadi, bahkan jika Anda bisa meyakinkan semua tautan dalam rantai pengiriman pos untuk menerima gajah, Anda dihadapkan dengan penerima. Dia bisa mengatakan bahwa dia menginginkan gajah tetapi kotak suratnya terlalu kecil untuk ditampung oleh gajah. Menuju pengiriman gajah yang dikirim ke pengirim. (Belum lagi apa yang terjadi jika gajah tidak muat di kotak surat pengirim ...)


18
Ayo pada ! Selama ada Content-Type: application/x-pachydermtajuk, HTTP sangat mampu mentransmisikan gajah;) Poin bagus, meskipun protokol pilihan saya akan rsync- tersedia dengan cukup baik, memungkinkan untuk kompresi, sinkronisasi delta, transfer lanjutan, plus bekerja dengan baik dengan SSH (untuk auth + enkripsi).
Piskvor

1
Bahkan pendekatan P2P masuk akal. Itu tergantung pada audiens. Melakukan multicasting file melalui email harus membunyikan bel alarm semua orang. Dan seperti yang Anda katakan dengan kata lain, seseorang seharusnya tidak mengikuti pendekatan ini: "Jika Anda hanya memiliki palu maka setiap masalah terlihat seperti paku".
mailq

Hmm, ya - untuk beberapa penerima yang dituju, misalnya torrent sangat masuk akal; tetapi dalam pengalaman saya, Anda masih membutuhkan (FTP? HTTP?) mundur untuk pengguna yang tidak memahami semua protokol transfer bermodel baru ini. Tergantung audiensnya, seperti yang Anda katakan.
Piskvor

17

Setelah berada dalam situasi dengan Exchange 2007 di mana manajemen berlangganan filosofi "tidak ada batasan ukuran email":

Pengguna internal mengirim pesan ke alamat hotmail mereka dengan iso CD musik. Membuat antrian macet pada satu server transportasi saat memproses pesan, menyalakan kembali tekanan, menghentikan pengiriman pesan. Pandangan pengguna kemudian dengan patuh mengirimkan kembali pesan ke server transportasi lain yang berfungsi; tekanan kembali, tidak ada pengiriman pesan.

Dengan kedua server transportasi tersedak pesan, semua email keluar terhenti sekitar 90 detik. Hotmail, tentu saja, menolak pesan itu. Ada batasan ukuran segera setelah itu.


sekitar tahun 90-an saya menerima email 20MB. email sebenarnya dikirim ke kotak surat saya, tetapi server mengirim kembali kesalahan ukuran 4,5.1. pada titik mana server pengirim membenci pesan. membuat loop yang terus berulang sampai kotak surat saya atau server kami sudah penuh dan harus diperbaiki secara manual oleh admin dengan menghapus email dari antrian.
eMBee

5

Ini pandangan lain:

Karena email disimpan dalam banyak contoh di sepanjang jalan, mengirimkan file 1 GB akan menghabiskan beberapa kali lebih baik.

Biasanya akan menjadi salinan pada klien Anda di "Item terkirim", dan jika menggunakan IMAP, salinan di server mungkin juga muncul (di akun Anda).

Kemudian pihak penerima akan menyimpan salinan (server), juga di klien lokal di pihak penerima. Jika menggunakan IMAP, maka itu tidak akan dihapus di server (sekali lagi).

Itu adalah total 4 GB untuk satu file 1GB. Tentu saja, Anda dapat menganggapnya sebagai cadangan, tetapi ada opsi yang lebih baik untuk itu juga. Belum lagi kelambatan yang mungkin terjadi di server karena kotak pesan pengguna tumbuh tanpa batas.

Dan saya baru sadar bahwa jika file tersebut di-encode base64 akan lebih besar lagi (kira-kira 33% lebih besar kurasa).



-2

Masalah yang disebutkan sebagian besar masalah logistik dengan penyimpanan dan pengiriman data - dalam abstraksi cloud modern, file tidak lagi perlu bersifat fisik - abstraksi file-handle dapat digunakan untuk membungkus berbagai metode penyimpanan (misalnya disk lokal, ftp , http, torrent, youtube, penyimpanan cloud, darknet, lampiran, bagal, fs, kutipan, revisi yang didistribusikan) - ini bukan ide baru, hanya belum sepenuhnya di sini atau belum dalam satu potong. ketika atau jika itu tiba, lampiran email Anda hanya akan menjadi penunjuk file yang dapat digunakan secara langsung(mis. bukan file .torrent atau tautan) oleh pemutar video atau perangkat lunak apa pun. penanganan aktual pengunduhan atau penyimpanan konten akan terjadi secara transparan, konten mungkin sebagian terletak dari berbagai sumber yang didefinisikan dalam manifes yang dapat direvisi secara kolaboratif (mis. seperti file .torrent tetapi diterima secara universal, dan dengan ketersediaan yang dapat direvisi dan kendala lokalitas); unduhan dan penyimpanan / cache yang sebenarnya mungkin sering parsial, tergantung pada bagian mana yang dilihat dan jika Anda bahkan repot-repot mengakses konten - sehingga lampiran besar ibu mertua Anda tidak akan memakan bandwidth rumah Anda jika Anda bukan penggemar emailnya. Untuk keabadian atau ketersediaan, mungkin Anda


2
Seperti saya membenci terminologi "cloud", deskripsi Anda setengah benar; tetapi masih ada persyaratan transfer (bandwidth), penyimpanan bahkan jika itu hanya sedang, dan penundaan yang signifikan dapat disebabkan oleh kurangnya kehadiran di server "lokal". Bahkan jika file tidak pernah diakses oleh penerima, pengirim asli masih harus mengirimkan seluruh file "ke cloud", "cloud" harus menahan seluruh file (mungkin tanpa batas waktu), dan struktur untuk berkomunikasi semua ini akan harus diberlakukan. Jika kita menciptakan kembali roda, itu bisa dilakukan lebih baik dari ini.
Chris S

1
"file tidak lagi harus bersifat fisik" - tunggu sementara saya menyingkirkan disk saya, karena mereka tidak lagi diperlukan untuk file - file spiritual ;) Anda memiliki poin yang baik bahwa penyimpanan dan transfer dapat diabstraksi. , tapi mereka hanya disembunyikan di suatu tempat oleh abstraksi, tidak hilang. Anda membutuhkan pipa yang sangat gemuk untuk mengurangi latensi akses file - mis. Mulai memutar video HD, cari ke tengah, putar-putar ibu jari Anda selama beberapa menit sementara data yang diminta dialirkan ke Anda (bukan hanya milidetik untuk penyimpanan lokal) . Dan ada juga kecepatan cahaya sial satu kaki per nanodetik.
Piskvor

true - ini semua bisa menjadi sangat lambat jika lokasi atau ketersediaan tidak didefinisikan atau diimplementasikan dengan baik. tetapi pengguna dapat mendefinisikannya dan mengambil tanggung jawab untuk berbagai pertukaran kecepatan, bandwidth, ketersediaan, dan sebagainya, menggunakan kebijakan yang telah dikemas, aturan filter, atribut, tag, aturan menyimpulkan. ketika saya mengirim email dengan lampiran, saya tidak perlu 'mengunggah' mereka, karena data hanya tersedia untuk penerima, maka data memindahkan atau mereplikasi dirinya ke disk dan / atau penyimpanan cloud berdasarkan perilaku dua pihak aturan inferensi yang dikonfigurasi pengguna 'manajer penyimpanan'.
Alife Toy

"pengguna harus mendefinisikannya dan bertanggung jawab" - Anda harus menjadi manajer.
Chris S

bukan manajer tetapi sesuatu yang jauh lebih buruk - futuris yang rusak
Alife Toy
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.