왜 이렇게 작은 이메일 첨부 파일에 파일 크기 제한이 있습니까? [닫은]

영광스러운 2011 년에 서로 1GB 파일을 이메일로 보내지 못하게하는 기술적 한계는 무엇입니까?

아니면 주요 전자 메일 플랫폼이 발을 끌고 있습니까?

받은 편지함에서 머리글 만 가져 오도록 설정 한 다음 원하는 경우 전체 첨부 파일을 설정할 수 있다면 무엇이 문제입니까?

이메일 첨부 파일 크기가 1992 년에 멈춘 것 같습니다 ...

문제는 이것입니다. 전자 메일 (SMTP / POP3 / IMAP / what-have-you)은 원래 신뢰할 수있는 네트워크에서 일반 텍스트 메시지를 보내기위한 고대의 간단한 프로토콜입니다. 오늘날의 인터넷을 통해 대량의 이진 데이터를 보내거나받는 데 사용하는 것은 원래 사용 사례와 완전히 다른 볼트 방식의 해킹이며이 역할에서 다소 비참하게 수행됩니다.

전자 메일에 파일을 첨부하면 base64로 인코딩되어 크기가 1/3 증가합니다. 따라서 1GB 파일이 300MB 더 커집니다. 또한 다운로드 프로토콜에 대한 압축이 기본적으로 제공되지 않으므로 전송 속도를 높일 수있는 방법이없고 (일부 경우 (전송 용 SMTP, 수 신용 POP3)) 끊어진 전송 을 재개 할 방법조차 없습니다. 연결이 1.2에서 끊어졌습니다. GB? 죄송합니다. 다시 전송해야합니다. 또한 SMTP는 저장 후 전달 프로토콜입니다. 맞춰봐? 그렇습니다. 1.3GB 파일을 여러 서버에 복사해야합니다. 메일 서버 관리자로부터 무한한 행복을 느끼십시오.

유용한 대안 (FTP? HTTP / 1.0? Puh-leeze)이 없었던 1990 년대의 문제였다. 그러나 2011 년 영광스러운 해에 클라우드에서 데이터를 원활하게 업로드 / 다운로드하는 다양한 방법 (예 : Dropbox, Ubuntu One, Amazon S3, 가장 잘 알려진 이름)으로 "이 작업을 수행하는 다른 유용한 방법은 없습니다" "는 더 이상 사실이 아닙니다.

또한 모든 사람이 인터넷에 대한 100Mbit 링크에 있지는 않습니다 (예 : 모바일 및 스마트 폰). 하지 모든 메일 클라이언트 (예 : POP3 많은 아직 사용) 헤더 만 다운로드 할 수있는, 그리고 모든 사용자가 20 피할 수없는 "이 funneh 1기가바이트 비디오 봐"를 다운로드 할 의사가 일주일에 이메일는 것입니다 (표시 사람들은 시스템이 허용하는만큼 큰 파일을 보내 게되며, 대부분의 ISP에는 FUP와 같은 것이 있습니다.

TL; DR : 기술적으로 1GB 파일을 이메일로 보내는 것과 같은 작업을 수행하는 것이 가능하지만, 드라이버를 사용하여 못을 박는 것이 기술적으로 가능할 수도 있습니다. 그러한 작업에 더 적합한 도구.

동일하지만 약간 다른 관점에서 :

이메일은 전자 메일입니다. 당신은 메일을 다른 작은 종이 봉투에 담긴이 고대 종이라고 생각합니다. 당신은 그것에 많은 텍스트를 쓸 수 있지만 5 ~ 6 페이지를 넘지 않아야합니다. 그리고 이메일은 동일하지만 전자적입니다. 텍스트 (타자기와 같은 일반 텍스트)를 위해 설계되었습니다. 그런 다음 멋진 빨간색으로 깜박이는 HTML 메일을 보낼 수있는 MIME 확장명이있었습니다.

세상 어느 누구도 불평하지 않고 "주후 1322 년에 우편물이 갇혔습니다. 왜 코끼리를 종이 봉투에 보낼 수 없습니까?" 그 방법입니다. 이런 종류의 물건을 위해 사람들은 패킷이나 운송 컨테이너와 같은 것을 발명했습니다. 이것은 상품과 코끼리를 보내는 방법입니다. 그리고 인터넷 사람들은 FTP (파일 전송 프로토콜)를 발명했습니다.

실제로 FTP는 대체로 파일을 전송하지 않고 보안에있어 단점이 큰 고대 프로토콜이기 때문에 FTP에 대한 많은 대안이 있습니다. 그러나 HTTP는 메타 데이터가 포함 된 중앙 집중식 문서 저장 소용으로 개발되었으므로 대안 이 아닙니다 . 파일을 다운로드하고 업로드 할 수 있다는 것은 그에 대한 잔인한 확장입니다.

따라서 문자를 사용하여 문자를 보내고 패킷을 사용하여 상품을 보내십시오. 이메일을 사용하여 정보를 전송하고 파일 전송 프로토콜을 사용하여 파일을 전송하십시오.

그림을 유지하려면 다음을 추가해야합니다. 현지 우체국에서 코끼리를 종이 봉투에 넣고 추가 비용을 지불하도록 설득하더라도 코끼리를 배달하는 당사자가 더 많습니다. 우체부가 다음 우체국에 가지고 다녀야 할 것입니다. 아마도 코끼리가 들어갈 수있는 적절한 가방이 없을 것입니다. 그러나 아마도 다음 우체국에 배달하고 싶을 것입니다. 우리는 코끼리를 받아들이지 않습니다. "

그러면 어떻게해야합니까? 현실 세계의 훌륭한 우체부는 코끼리를 첫 번째 우체국으로 보낸 후 나중에 보낸 사람에게 돌려 보냅니다. (전자 세계에서 이것은 코끼리를 쏘아서 보낸 사람에게만 사망 증명서를 전달해야하기 때문에 나쁜 우체부 일 것입니다 ).

따라서 사후 배달 체인의 모든 링크가 코끼리를 받아들이도록 설득 할 수 있다고해도 수령인이 직면하게됩니다. 그는 코끼리를 원하지만 레터 박스가 너무 작아서 코끼리가 들어갈 수 없을 것이라고 말했습니다. (해당 코끼리가 발신자의 레터 박스에 맞지 않으면 어떻게되는지 언급하지 마십시오 ...)

경영진이 "전자 메일 크기 제한 없음"철학을 구독 한 Exchange 2007의 상황에 처해있는 경우 :

내부 사용자가 음악 CD의 .iso를 사용하여 핫메일 주소로 메시지를 보냈습니다. 메시지를 처리하는 동안 하나의 전송 서버에서 큐를 막았으며, 불이 켜졌으며 메시지 제출을 중지했습니다. 그런 다음 사용자의 시야는 작동중인 다른 전송 서버로 메시지를 정식으로 다시 제출했습니다. 배압, 메시지 제출 없음.

두 전송 서버가 메시지를 질식 시키면 모든 아웃 바운드 전자 메일이 약 90 초 동안 중지되었습니다. 물론 핫메일은 메시지를 거부했다. 얼마 지나지 않아 크기 제한이있었습니다.

또 다른 견해는 다음과 같습니다.

이메일은 도중에 여러 인스턴스에 저장되므로 1GB 파일을 보내는 것은 그 몇 배가 될 것입니다.

일반적으로 "보낸 편지함"의 클라이언트 사본이며, IMAP를 사용하는 경우 서버의 사본도 계정에 나타날 수 있습니다.

그런 다음 수신 측은 수신 측의 로컬 클라이언트와 사본 (서버)을 보관합니다. IMAP을 사용하는 경우 서버에서 삭제되지 않습니다 (다시 한 번).

단일 1GB 파일의 경우 총 4GB입니다. 물론 백업으로 간주 할 수 있지만 더 나은 옵션도 있습니다. 사용자 사서함이 무한정 증가하기 때문에 서버에서 발생할 수있는 속도 저하는 말할 것도 없습니다.

그리고 방금 파일이 base64로 인코딩되어 있으면 더 커질 것입니다 (약 33 % 더 커질 것입니다).

Piskvor의 답변을 보완합니다.

예, "주요 이메일 플랫폼"이 발을 끌고 있습니다. 오늘날 표준에 맞지 않는 프로토콜 (SMTP)을 사용하여 여러 가지 방법으로이를 수행합니다.

오늘날 세계에서는 현재 첨부 파일 문제를 해결할 SMTP를 대체 할 프로토콜을 쉽게 설계 할 수 있습니다.

문제는 세상이 세상으로 바뀌게하는 것입니다.

언급 된 문제는 대부분 데이터 저장 및 전송과 관련된 물류 문제입니다. 현대 클라우드 추상화에서는 더 이상 파일이 물리적이어야 할 필요가 없습니다. 파일 처리 추상화는 다양한 스토리지 방법 (예 : 로컬 디스크, ftp)을 감싸는 데 사용될 수 있습니다 , http, 토런트, youtube, 클라우드 스토리지, 다크 넷, 첨부 파일, 노새, 분산 fs, 발췌, 개정)-이것은 새로운 아이디어가 아니며 완전히 여기 또는 한 조각이 아닙니다. 도착시 또는 도착하면 메일 첨부 파일은 단순히 직접 사용할 수있는 파일 포인터입니다.(예 : .torrent 파일이나 링크가 아님) 비디오 플레이어 또는 기타 소프트웨어 컨텐츠 다운로드 또는 스토리지의 실제 처리는 투명하게 이루어지며, 컨텐츠는 협업 적으로 수정 가능한 매니페스트에 정의 된 여러 소스 (예 : .torrent 파일과 유사하지만 보편적으로 수용 가능하며 수정 가능한 가용성 및 로컬 제약 조건)에서 부분적으로 위치 할 수 있습니다. 실제 다운로드 및 저장 / 캐싱은 조회 한 부분과 콘텐츠에 액세스하기 위해 귀찮은 경우에 따라 부분적으로 표시 될 수 있습니다. 따라서 시어머니의 큰 부착물은 사내 대역폭을 전혀 차지하지 않습니다. 당신이 그녀의 이메일을 좋아하지 않는다면. 영속성 또는 가용성을 위해 아마도