ทำไมเรายังคงมีข้อ จำกัด ขนาดไฟล์แนบของอีเมลเช่นนี้ [ปิด]

อะไรคือข้อ จำกัด ทางเทคนิคที่ทำให้เราในปี 2011 อันรุ่งโรจน์จากการส่งอีเมลไฟล์ 1GB ซึ่งกันและกัน

หรือเป็นเพียงแพลตฟอร์มอีเมลหลักที่ลากเท้าของพวกเขา

หากฉันสามารถตั้งค่ากล่องจดหมายให้คว้าเฉพาะส่วนหัวและจากนั้นแนบไฟล์แบบเต็มถ้าฉันต้องการปัญหาคืออะไร

ฉันรู้สึกว่าขนาดไฟล์แนบของอีเมลติดอยู่ในปี 1992 ...

ปัญหาคือ: อีเมล (SMTP / POP3 / IMAP / สิ่งที่คุณมี) เป็นโปรโตคอลโบราณที่เรียบง่าย แต่เดิมมีไว้สำหรับการส่งข้อความธรรมดาในเครือข่ายที่เชื่อถือได้ การใช้เพื่อส่งหรือรับข้อมูลไบนารีจำนวนมากผ่านทางอินเทอร์เน็ตในปัจจุบันนั้นเป็นการแฮ็คแบบกลอนซึ่งแตกต่างจากกรณีการใช้งานดั้งเดิมอย่างสิ้นเชิงและทำงานได้ค่อนข้างแย่ในบทบาทนี้

เมื่อคุณแนบไฟล์ไปกับอีเมลไฟล์นั้นจะได้รับการเข้ารหัส base64 ซึ่งจะเพิ่มขนาดไฟล์ 1/3 ดังนั้นไฟล์ 1 GB ของคุณจะใหญ่ขึ้นอีก 300 MB ไม่มีการบีบอัดในตัวโปรโตคอลดาวน์โหลดดังนั้นจึงไม่มีวิธีเพิ่มความเร็วในการโอน (และในบางกรณี (SMTP สำหรับส่ง, POP3 สำหรับรับ) แม้จะไม่มีวิธีการถ่ายโอนที่เสียหายอีกต่อไป - การเชื่อมต่อแตกที่ 1.2 GB? ขออภัยคุณต้องส่งอีกครั้งทั้งหมด) ยิ่งกว่านั้น SMTP เป็นโปรโตคอลการจัดเก็บและส่งต่อ คาดเดาอะไร ใช่จำเป็นต้องคัดลอกไฟล์ 1.3 GB ข้ามหลายเซิร์ฟเวอร์ อ้างถึงความสุขที่ไม่มีขอบเขตจากผู้ดูแลระบบเซิร์ฟเวอร์อีเมล

นี่เป็นปัญหาในปี 1990 เมื่อไม่มีทางเลือกที่มีประโยชน์ (FTP? HTTP / 1.0? Puh-leeze); แต่ในปี 2011 อันรุ่งโรจน์ด้วยวิธีการที่หลากหลายของการเพิ่ม / ดาวน์โหลดข้อมูลไปยัง / จากระบบคลาวด์ (เช่น Dropbox, Ubuntu One, Amazon S3, เพื่อตั้งชื่อที่รู้จักมากที่สุด) ข้ออ้างของ "ไม่มีวิธีอื่นที่เป็นประโยชน์ในการทำเช่นนี้ "ไม่เป็นความจริงอีกต่อไป

โปรดทราบว่าไม่ใช่ทุกคนที่อยู่บนลิงก์ 100 Mbit ไปยังอินเทอร์เน็ต - เช่นโทรศัพท์มือถือและสมาร์ทโฟน ไม่ได้ mail ของลูกค้าทุกคนมีความสามารถในการดาวน์โหลดส่วนหัวเท่านั้น (เช่น POP3 ยังคงอยู่ในการใช้งานมาก) และไม่ได้ใช้ทุกคนยินดีที่จะดาวน์โหลด "ดูที่ funneh 1 GB วิดีโอนี้" 20 สิ่งที่หลีกเลี่ยงอีเมลต่อสัปดาห์ที่จะปรากฏ ( ผู้คนจะส่งไฟล์ขนาดใหญ่เท่าที่ระบบจะยอมให้และใช่มีบางอย่างเช่น FUP กับ ISP ส่วนใหญ่)

TL; DR : แม้ว่ามันจะเป็นไปได้ในทางเทคนิคที่จะทำสิ่งต่าง ๆ เช่นการส่งอีเมลไฟล์ 1GB แต่ในทางเทคนิคแล้วมันอาจเป็นไปได้ที่จะทุบตะปูด้วยไขควงโดยใช้เทคนิค - มันไม่ใช่วิธีที่ดีที่จะทำเช่นนั้น เครื่องมือที่เหมาะสมสำหรับงานดังกล่าวมากขึ้น

เหมือนกัน แต่จากมุมมองที่แตกต่างกันเล็กน้อย:

อีเมลเป็นจดหมายอิเล็กทรอนิกส์ คุณรู้ว่าเมลเป็นกระดาษโบราณนี่คือสิ่งที่อยู่ในซองกระดาษอีกอัน คุณสามารถเขียนข้อความจำนวนมากได้ แต่ไม่เกิน 5 หรือ 6 หน้า และอีเมลก็เหมือนกัน แต่เป็นอิเล็กทรอนิกส์ มันถูกออกแบบมาสำหรับข้อความ (ข้อความธรรมดาเหมือนบนเครื่องพิมพ์ดีด) จากนั้นก็มีนามสกุล MIME ที่คุณสามารถส่งอีเมล HTML ที่กระพริบตาแดงเหล่านี้ได้

ไม่มีใครในโลกที่จะบ่นและพูดว่า "โอ้เมลติดอยู่ในแบบที่มันเป็นที่ 1322 AD ทำไมฉันไม่สามารถส่งช้างในซองกระดาษ?" มันเป็นอย่างไร สำหรับสิ่งของประเภทนี้ผู้คนคิดค้นบางสิ่งเช่นแพ็คเก็ตหรือภาชนะขนส่ง นี่คือวิธีการส่งสินค้าและช้าง และคนในอินเทอร์เน็ตคิดค้น FTP (โปรโตคอลการถ่ายโอนไฟล์) มีชื่อใช่ไหม

ในโลกแห่งความเป็นจริงมีทางเลือกมากมายสำหรับ FTP เพราะ FTP เป็นโปรโตคอลโบราณที่มีข้อเสียใหญ่ (ส่วนใหญ่อยู่ในความปลอดภัยและไม่ได้ถ่ายโอนไฟล์) แต่ HTTP ไม่ใช่ทางเลือกเนื่องจากถูกพัฒนาขึ้นสำหรับการจัดเก็บเอกสารส่วนกลางด้วย data meta ที่คุณสามารถดาวน์โหลดและอัพโหลดไฟล์นั้นเป็นส่วนเสริมที่โหดร้ายได้

ดังนั้นใช้จดหมายเพื่อส่งข้อความและแพ็คเก็ตเพื่อส่งสินค้า ใช้อีเมลเพื่อส่งข้อมูลและโปรโตคอลการส่งไฟล์เพื่อส่งไฟล์

หากต้องการอยู่ในภาพฉันต้องเพิ่ม: แม้ว่าคุณจะโน้มน้าวให้ที่ทำการไปรษณีย์ในท้องที่ของคุณยอมรับช้างในซองกระดาษ (และชำระค่าธรรมเนียมเพิ่มเติม) มีฝ่ายต่างๆที่เกี่ยวข้องกับการส่งช้างมากขึ้น มีคนส่งไปรษณีย์ที่ต้องส่งไปที่ที่ทำการไปรษณีย์ถัดไปและบางทีเขาอาจจะไม่มีกระเป๋าที่เหมาะสมสำหรับช้างที่จะเข้าไปข้างใน แต่บางทีเขาอาจจะมีและต้องการส่งไปยังที่ทำการไปรษณีย์ถัดไปซึ่งในทางกลับกันก็บอกว่า: "ไม่ เราไม่ยอมรับช้าง "

ถ้าอย่างนั้นจะทำอย่างไร? บุรุษไปรษณีย์ที่ดีในโลกแห่งความจริงจะพาช้างกลับไปที่ที่ทำการไปรษณีย์แห่งแรก - ส่งต่อให้ผู้ส่งภายหลัง (ในโลกอิเล็กทรอนิกส์นี่จะเป็นบุรุษไปรษณีย์ที่ไม่ดีเพราะเขาควรจะยิงช้างและส่งมอบใบรับรองการตายให้กับผู้ส่งเท่านั้น)

ดังนั้นแม้ว่าคุณจะสามารถโน้มน้าวใจทุกการเชื่อมโยงในห่วงโซ่ของการจัดส่งโพสต์เพื่อยอมรับช้างที่คุณกำลังเผชิญกับผู้รับ เขาสามารถพูดได้ว่าเขาต้องการช้าง แต่ตู้ไปรษณีย์นั้นเล็กเกินไปที่จะให้ช้างเข้าไปได้ซึ่งจะนำไปสู่การส่งช้างกลับคืนสู่ผู้ส่ง (ไม่ต้องพูดถึงจะเกิดอะไรขึ้นถ้าช้างไม่พอดีในกล่องจดหมายของผู้ส่ง ... )

เคยอยู่ในสถานการณ์ที่มี Exchange 2007 ซึ่งผู้บริหารสมัครเป็นสมาชิกกับปรัชญา "ไม่ จำกัด ขนาดอีเมล":

ผู้ใช้ภายในส่งข้อความไปยังที่อยู่ hotmail ด้วย. iso ของซีดีเพลง ติดคิวในเซิร์ฟเวอร์การขนส่งหนึ่งขณะประมวลผลข้อความเพิ่มความกดดันย้อนกลับหยุดการส่งข้อความ มุมมองของผู้ใช้จากนั้นส่งข้อความไปยังเซิร์ฟเวอร์การขนส่งอื่นที่ใช้งานได้ตามหน้าที่ แรงดันกลับไม่มีการส่งข้อความ

เมื่อเซิร์ฟเวอร์การขนส่งทั้งสองสำลักข้อความอีเมลขาออกทั้งหมดหยุดทำงานประมาณ 90 วินาที แน่นอน Hotmail ปฏิเสธข้อความ หลังจากนั้นไม่นานขนาดก็ จำกัด ขนาด

นี่คือมุมมองอื่น:

เนื่องจากอีเมลถูกเก็บไว้ในหลายอินสแตนซ์ไปพร้อมกันการส่งไฟล์ 1 GB จะใช้งานได้หลายครั้ง

โดยปกติจะเป็นการคัดลอกลูกค้าของคุณใน "รายการที่ถูกส่ง" และหากใช้ IMAP สำเนาบนเซิร์ฟเวอร์อาจปรากฏขึ้นเช่นกัน (ในบัญชีของคุณ)

จากนั้นจุดสิ้นสุดการรับจะเก็บสำเนา (เซิร์ฟเวอร์) รวมถึงที่ไคลเอ็นต์ภายในเครื่องที่จุดรับ หากใช้ IMAP จะไม่ถูกลบบนเซิร์ฟเวอร์ (อีกครั้ง)

นั่นคือทั้งหมด 4 GB สำหรับไฟล์ 1GB ไฟล์เดียว แน่นอนคุณสามารถพิจารณาว่าเป็นการสำรองข้อมูล แต่มีตัวเลือกที่ดีกว่าสำหรับสิ่งนั้นเช่นกัน ไม่ต้องพูดถึงความช้าที่อาจเกิดขึ้นบนเซิร์ฟเวอร์เพราะกล่องจดหมายของผู้ใช้จะเพิ่มขึ้นเรื่อย ๆ

และฉันเพิ่งรู้ว่าถ้าไฟล์นั้นเข้ารหัส base64 มันจะยิ่งใหญ่กว่า (ประมาณ 33% ที่ใหญ่กว่าฉันเดา)

เพื่อเสริมคำตอบของ Piskvor

ใช่ "แพลตฟอร์มอีเมลหลัก" กำลังลากเท้าของพวกเขา พวกเขาทำได้โดยใช้โปรโตคอล (SMTP) ที่ไม่เป็นไปตามมาตรฐานของวันนี้ (ในหลาย ๆ ด้าน)

ในโลกปัจจุบันเราสามารถออกแบบโปรโตคอลเพื่อแทนที่ SMTP ที่จะแก้ปัญหาไฟล์แนบปัจจุบันได้อย่างง่ายดาย

ปัญหาจะทำให้โลกเปลี่ยนไป

ปัญหาดังกล่าวส่วนใหญ่เป็นปัญหาด้านโลจิสติกส์กับการจัดเก็บและการส่งข้อมูล - ในนามธรรมที่ทันสมัยของคลาวด์, ไฟล์ไม่จำเป็นต้องเป็นทางกายภาพอีกต่อไป - สิ่งที่เป็นนามธรรมของการจัดการไฟล์อาจถูกใช้เพื่อพันรอบวิธีการจัดเก็บต่างๆ , http, torrent, youtube, ที่เก็บข้อมูลบนคลาวด์, darknet, สิ่งที่แนบมา, ล่อ, fs ที่กระจายออก, ข้อความที่ตัดตอนมา, การแก้ไข) - นี่ไม่ใช่ความคิดใหม่ แต่ก็ยังไม่ครบที่นี่หรือในชิ้นเดียว เมื่อมาถึงหรือไม่สิ่งที่แนบมากับอีเมลของคุณจะเป็นตัวชี้ไฟล์ที่สามารถใช้งานได้โดยตรง(เช่นไม่ใช่ไฟล์. ฝึกงานหรือลิงก์) โดยเครื่องเล่นวิดีโอหรือซอฟต์แวร์ใด ๆ การจัดการการดาวน์โหลดหรือการจัดเก็บเนื้อหาที่เกิดขึ้นจริงจะเกิดขึ้นอย่างโปร่งใสเนื้อหาอาจอยู่บางส่วนจากหลายแหล่งที่กำหนดไว้ในรายการร่วมกันที่แก้ไขได้ (เช่นไฟล์ .torrent แต่ได้รับการยอมรับในระดับสากล การดาวน์โหลดและการจัดเก็บ / แคชจริงมักจะเป็นบางส่วนขึ้นอยู่กับว่ามีใครดูบ้างและถ้าคุณใส่ใจที่จะเข้าถึงเนื้อหา - ดังนั้นไฟล์แนบขนาดใหญ่ของกฎหมายแม่ของคุณจะไม่กินแบนด์วิธในบ้านของคุณ หากคุณไม่ใช่แฟนของอีเมลของเธอ เพื่อความคงทนหรือความพร้อมใช้งานบางทีคุณอาจ