Tại sao chúng ta vẫn có những hạn chế tập tin đính kèm email nhỏ như vậy? [đóng cửa]

Giới hạn kỹ thuật nào ngăn chúng ta, trong năm vinh quang 2011, gửi email cho nhau các tệp 1GB?

Hay đó chỉ là nền tảng email chính kéo chân họ?

Nếu tôi có thể đặt hộp thư đến của mình chỉ lấy các tiêu đề, và sau đó đính kèm đầy đủ nếu tôi muốn, vấn đề là gì?

Tôi cảm thấy như kích thước tệp đính kèm email bị kẹt vào năm 1992 ...

Vấn đề là ở đây: e-mail (SMTP / POP3 / IMAP / what-have-you) là một giao thức đơn giản, cổ xưa ban đầu được dự định để gửi tin nhắn văn bản gốc trong một mạng đáng tin cậy. Sử dụng nó để gửi hoặc nhận một lượng lớn dữ liệu nhị phân trên Internet ngày nay là một vụ tấn công được củng cố, hoàn toàn khác với trường hợp sử dụng ban đầu và nó thực hiện khá thảm hại trong vai trò này.

Khi bạn đính kèm một tập tin vào e-mail, nó sẽ được mã hóa base64, làm tăng kích thước của nó lên 1/3. Do đó, tệp 1 GB của bạn trở nên lớn hơn 300 MB; Ngoài ra, không có nén tích hợp vào giao thức tải xuống, do đó không có cách nào để tăng tốc độ truyền (và trong một số trường hợp (SMTP để gửi, POP3 để nhận), thậm chí không có cách nào để tiếp tục chuyển bị hỏng - kết nối bị hỏng ở mức 1.2 GB? Xin lỗi, bạn cần truyền lại tất cả một lần nữa). Hơn nữa, SMTP là một giao thức lưu trữ và chuyển tiếp. Đoán xem cái gì? Đúng, tập tin 1,3 GB đó cần được sao chép trên nhiều máy chủ; cue hạnh phúc không giới hạn từ quản trị viên máy chủ thư.

Đây là một vấn đề trong những năm 1990, khi không có sự thay thế hữu ích (FTP? HTTP / 1.0? Puh-leeze); nhưng trong năm vinh quang 2011, với nhiều cách khác nhau để tải / tải dữ liệu liên tục đến / từ đám mây (ví dụ Dropbox, Ubuntu One, Amazon S3, để đặt tên cho cái được biết đến nhiều nhất), lý do "không có cách nào hữu ích khác để làm điều này "Không còn đúng nữa.

Cũng lưu ý rằng không phải ai cũng có liên kết 100 Mbit với Internet - ví dụ như điện thoại di động và điện thoại thông minh; không phải mọi ứng dụng thư khách chỉ có khả năng tải xuống các tiêu đề (ví dụ: POP3 vẫn còn được sử dụng nhiều) và không phải người dùng nào cũng sẵn sàng tải xuống 20 email "không thể tránh khỏi" trong email này, mỗi tuần sẽ xuất hiện ( mọi người sẽ gửi các tệp lớn như hệ thống sẽ cho phép họ và vâng, có một cái gì đó giống như FUP với hầu hết các ISP).

TL; DR : mặc dù về mặt kỹ thuật có thể thực hiện những việc như gửi e-mail tệp 1GB, về mặt kỹ thuật cũng có thể giã nát móng tay bằng tuốc nơ vít - đó không phải là cách tốt để làm điều đó, vì có các công cụ phù hợp hơn cho các nhiệm vụ như vậy.

Giống nhau nhưng từ một cái nhìn hơi khác:

Email là thư điện tử. Bạn biết thư như một thứ giấy cổ này trong một phong bì giấy nhỏ khác. Bạn có thể viết rất nhiều văn bản trên đó nhưng không quá 5 hoặc 6 trang. Và email là như nhau nhưng điện tử. Nó được thiết kế cho văn bản (văn bản đơn giản như trên một máy đánh chữ). Sau đó, có một tiện ích mở rộng MIME nơi bạn có thể gửi các thư HTML nhấp nháy màu đỏ lạ mắt này.

Không ai trên thế giới sẽ phàn nàn và nói "Ồ thư bị kẹt theo cách đó là vào năm 1322 sau Công nguyên. Tại sao tôi không thể gửi một con voi trong một phong bì giấy?" Nó là như thế nào Đối với loại công cụ này, người ta đã phát minh ra thứ gì đó như gói hoặc thùng chứa vận chuyển. Đây là cách gửi hàng hóa và voi. Và những kẻ Internet đã phát minh ra FTP (giao thức truyền tệp), có tên không?

Trong thế giới thực, có rất nhiều lựa chọn thay thế cho FTP vì FTP cũng là một giao thức cổ với những nhược điểm lớn (chủ yếu là về bảo mật và không phải là truyền tệp). Nhưng HTTP không phải là một giải pháp thay thế vì nó được phát triển để lưu trữ tài liệu tập trung với dữ liệu meta. Rằng bạn có thể tải xuống và tải lên các tập tin là một phần mở rộng tàn bạo với nó.

Vì vậy, sử dụng một lá thư để gửi văn bản và một gói để gửi hàng hóa; sử dụng email để gửi thông tin và giao thức truyền tệp để gửi tệp.

Để ở trong hình tôi phải thêm: Ngay cả khi bạn thuyết phục bưu điện địa phương của bạn chấp nhận voi trong phong bì giấy (và trả phí bổ sung), vẫn có nhiều bên tham gia giao voi. Có một người đưa thư phải mang nó đến bưu điện tiếp theo và có lẽ anh ta không có chiếc túi phù hợp cho con voi. Nhưng có lẽ anh ta có và muốn giao nó cho bưu điện tiếp theo nói: "Không chúng tôi không chấp nhận voi ".

Làm gì sau đó? Người đưa thư giỏi trong thế giới thực sẽ mang con voi trở lại bưu điện đầu tiên - trở lại người gửi sau đó. (Trong thế giới điện tử, đây sẽ là một người đưa thư tồi vì anh ta nên bắn con voi và chỉ giao giấy chứng tử cho người gửi).

Vì vậy, ngay cả khi bạn có thể thuyết phục tất cả các liên kết trong chuỗi gửi thư để chấp nhận những con voi mà bạn phải đối mặt với người nhận. Anh ta có thể nói rằng anh ta muốn con voi nhưng hộp thư quá nhỏ để một con voi phù hợp. Dẫn đến việc giao voi trở lại cho người gửi. (Không đề cập đến những gì xảy ra nếu con voi không vừa trong hộp thư của người gửi ...)

Đã từng ở trong một tình huống với Exchange 2007 khi quản lý đăng ký triết lý "không giới hạn kích thước email":

Một người dùng nội bộ đã gửi tin nhắn đến địa chỉ hotmail của họ bằng .iso của một đĩa nhạc. Kẹt hàng đợi trên một máy chủ vận chuyển trong khi xử lý tin nhắn, bật lại áp lực, dừng gửi tin nhắn. Triển vọng của người dùng sau đó mạnh dạn gửi lại tin nhắn đến máy chủ vận tải khác đang hoạt động; áp lực trở lại, không gửi tin nhắn.

Với cả hai máy chủ vận chuyển nghẹt thở trong tin nhắn, tất cả các email gửi đi tạm dừng trong khoảng 90 giây. Hotmail, tất nhiên, từ chối tin nhắn. Có một giới hạn kích thước tại chỗ rất nhanh sau đó.

Đây là một góc nhìn khác:

Vì một email được lưu trữ trong nhiều trường hợp trên đường đi, việc gửi tệp 1 GB sẽ sử dụng nhiều lần trong suốt quá trình.

Nó thường sẽ là một bản sao trên máy khách của bạn trong "Các mục đã gửi" và nếu sử dụng IMAP, một bản sao trên máy chủ cũng có thể hiển thị (trên tài khoản của bạn).

Sau đó, kết thúc nhận sẽ giữ một bản sao (máy chủ), cũng như tại máy khách cục bộ ở đầu nhận. Nếu sử dụng IMAP, nó sẽ không bị xóa trên máy chủ (một lần nữa).

Đó là tổng cộng 4 GB cho một tệp 1 GB. Tất nhiên, bạn có thể coi nó là một bản sao lưu, nhưng cũng có những lựa chọn tốt hơn cho điều đó. Chưa kể sự chậm chạp có thể xảy ra trên máy chủ vì hộp thư của người dùng phát triển vô thời hạn.

Và tôi chỉ nhận ra rằng nếu tập tin được mã hóa base64 thì nó sẽ còn lớn hơn (tôi đoán là lớn hơn khoảng 33%).

Để bổ sung cho câu trả lời của Piskvor.

Có, "nền tảng email chính" đang kéo chân họ. Họ làm điều này bằng cách sử dụng một giao thức (SMTP) không theo tiêu chuẩn ngày nay (theo nhiều cách).

Trong thế giới ngày nay, chúng ta có thể dễ dàng thiết kế một giao thức để thay thế SMTP sẽ giải quyết vấn đề đính kèm hiện tại.

Vấn đề sẽ là khiến thế giới chuyển sang nó.

Vấn đề được đề cập chủ yếu là các vấn đề hậu cần với việc lưu trữ và truyền dữ liệu - trong trừu tượng đám mây hiện đại, một tệp không còn cần phải là vật lý - một trừu tượng xử lý tệp có thể được sử dụng để bọc xung quanh các phương thức lưu trữ khác nhau (ví dụ: đĩa cục bộ, ftp , http, torrent, youtube, lưu trữ đám mây, darknet, tệp đính kèm, con la, phân phối fs, đoạn trích, sửa đổi) - đây không phải là một ý tưởng mới, nó chỉ chưa hoàn toàn ở đây hoặc trong một mảnh. khi hoặc nếu nó đến, tệp đính kèm thư của bạn chỉ đơn giản là một con trỏ tệp có thể được sử dụng trực tiếp(ví dụ: không phải tệp .torrent cũng không phải liên kết) bởi trình phát video hoặc bất kỳ phần mềm nào. việc xử lý thực tế tải xuống hoặc lưu trữ nội dung sẽ diễn ra một cách minh bạch, nội dung có thể được định vị một phần từ nhiều nguồn được xác định trong bảng kê khai có thể xem lại được (ví dụ như tệp .torrent nhưng được chấp nhận phổ biến và với các ràng buộc về tính sẵn có và có thể xem lại được); tải xuống và lưu trữ / bộ nhớ đệm thực tế thường có thể là một phần, tùy thuộc vào phần nào được xem và nếu bạn thậm chí còn bận tâm truy cập nội dung - vì vậy tệp đính kèm khổng lồ của mẹ chồng bạn sẽ không ăn hết băng thông trong nhà của bạn nếu bạn không phải là một fan hâm mộ của email của cô ấy. Đối với vĩnh viễn hoặc có sẵn, có thể bạn '