ทำไมโปรโตคอลอินเทอร์เน็ตจำนวนมากจึงใช้ข้อความ?


47

จากสิ่งที่ฉันได้พบเป็นมากจำนวนมากของโปรโตคอลที่เดินทางผ่านทางอินเทอร์เน็ตเป็น "ข้อความตาม" มากกว่าไบนารี โปรโตคอลที่เป็นปัญหานั้นรวมถึง แต่ไม่ จำกัด เพียง HTTP, SMTP, FTP (ฉันคิดว่าอันนี้เป็นข้อความทั้งหมดหรือไม่), WHOIS, IRC

ในความเป็นจริงบางส่วนของโปรโตคอลเหล่านี้กระโดดผ่านห่วงบางเมื่อใดก็ตามที่พวกเขาต้องการที่จะส่งข้อมูลไบนารี

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


โดยการใช้ข้อความฉันหมายถึงตัวละครส่วนใหญ่ที่ใช้ในโปรโตคอลอยู่ระหว่าง0x20(ช่องว่าง) และ0x7E( ~) โดยมี "speical character" เป็นครั้งคราวที่ใช้เพื่อจุดประสงค์พิเศษเช่น newlines, null, ETX และ EOT ตรงข้ามกับการส่งข้อมูลดิบข้อมูลไบนารีผ่านการเชื่อมต่อ

ตัวอย่างเช่นการส่งจำนวนเต็ม123456เป็นข้อความจะเกี่ยวข้องกับการส่งสตริง123456(แสดงเป็น31 32 33 34 35 36เลขฐานสิบหก) ในขณะที่ค่าไบนารีแบบ 32 บิตจะถูกส่งเป็น (แสดงเป็นเลขฐานสิบหก) 0x0001E240(และตามที่คุณเห็น "มี" อักขระ null พิเศษ .


3
จากโพรโทคอลที่กล่าวถึง 5 โพรโทคอล, HTTP, SMTP, WHOIS และ IRC นั้นส่วนใหญ่คิดเพื่อแลกเปลี่ยนข้อมูลที่เป็นข้อความ
el.pescado

4
โปรดทราบว่าHTTP / 2เป็นโปรโตคอลไบนารี
isanae

4
คุณส่วนใหญ่อ้างถึงโปรโตคอลและชั้นของการนำเสนอ โปรโตคอลระดับล่าง (TCP, IP, Ethernet) เกือบเป็นเลขฐานสองเสมอ
Nick T

2
FTP มีโหมดไบนารีซึ่งค่อนข้างสำคัญที่จะใช้เมื่อทำการถ่ายโอนไฟล์ไบนารีเนื่องจากโหมดการถ่ายโอนปกติในไคลเอนต์จำนวนมากจะเขียนการสิ้นสุดบรรทัดใหม่อีกครั้งเพื่อให้ตรงกับการประชุมของโฮสต์ซึ่งจะทำให้ไบนารีเสียหายเมื่อทำการโอนย้ายระหว่างโฮสต์ โหมดไบนารีนี้ใช้สำหรับการถ่ายโอนไฟล์เท่านั้นและไม่มีผลกระทบต่อสิ่งที่สั่ง
casey

2
FTP ใช้การเชื่อมต่อเครือข่ายสองการเชื่อมต่อหนึ่งข้อความ (ช่องคำสั่ง) และหนึ่งฐานสอง (ช่องข้อมูล)
นามแฝง

คำตอบ:


40

เมื่อโลกอายุน้อยกว่าและคอมพิวเตอร์ไม่ใช่พีซีที่ได้รับการยกย่องขนาดต่าง ๆ ของคำ (ธันวาคม 2563 เรามีประมาณ 36 บิตคำ) รูปแบบของข้อมูลไบนารีเป็นปัญหาที่ถกเถียงกัน (endian ใหญ่ vs endian น้อยและแม้แต่ weirder คำสั่งของบิตเป็นเรื่องธรรมดาพอสมควร) มีฉันทามติเล็กน้อยเกี่ยวกับขนาดตัวอักษร / การเข้ารหัส (ASCII, EBCDIC เป็นผู้เข้าชิงหลัก DEC ของเรามีการเข้ารหัส 5/6/7/8 บิต / ตัวอักษร) ARPAnet (ผู้บุกเบิกอินเทอร์เน็ต) ได้รับการออกแบบมาเพื่อเชื่อมต่อเครื่องของคำอธิบายใด ๆ ตัวหารร่วมคือ (และยังคงเป็น) ข้อความ คุณอาจมั่นใจได้อย่างแน่นอนว่าข้อความที่เข้ารหัส 7 บิตจะไม่ถูกรบกวนด้วยวิธีการพื้นฐานในการจัดส่งข้อมูล (จนกระทั่งเมื่อเร็ว ๆ นี้การส่งอีเมลในการเข้ารหัส 8 บิตบางอย่างเป็นการรับประกันว่าผู้รับจะได้รับข้อความที่ถูกทำให้เสียหาย

หากคุณค้นหาเช่นคำอธิบายโปรโตคอล telnet หรือ FTP (โปรโตคอลอินเทอร์เน็ตแรกแนวคิดเครือข่ายจะต้องเชื่อมต่อกับ "ซูเปอร์คอมพิวเตอร์" และสลับไฟล์ไปมาจากระยะไกล) คุณจะเห็นว่าการเชื่อมต่อมีการเจรจารายละเอียดมากมาย เราสวมเครื่องแบบเหมือนกัน

ใช่ไบนารีจะมีประสิทธิภาพมากขึ้น (บิต) แต่เครื่องจักรและความทรงจำ (และเครือข่าย) ก็เพิ่มขึ้นอย่างมหาศาลดังนั้นการเบี่ยงเบนเล็กน้อยของสมัยก่อนจึงเป็นเรื่องของอดีต (ส่วนใหญ่) และไม่มีใครในใจที่ถูกต้องของพวกเขาจะแนะนำให้ฉีกโปรโตคอลที่มีอยู่ทั้งหมดเพื่อแทนที่พวกเขาด้วยไบนารี นอกจากนี้โปรโตคอลข้อความยังมีเทคนิคการดีบักที่มีประโยชน์มาก วันนี้ฉันไม่เคยติดตั้งเซิร์ฟเวอร์ telnet (ควรใช้โปรโตคอล SSH ที่เข้ารหัสสำหรับการเชื่อมต่อระยะไกล) แต่ต้อง telnet client สะดวกในการ "พูดคุย" กับเซิร์ฟเวอร์ errant บางตัวเพื่อหาปัญหา วันนี้คุณอาจจะใช้netcatหรือncatเพื่อกำจัดอนาคต ...


10
ความง่ายในการแก้ไขปัญหาก็เพิ่มขึ้นอย่างมากเช่นกัน การอ่านการจับแพ็คเก็ตนั้นยากพอมันทำให้แย่ยิ่งขึ้นเมื่อแอปพลิเคชันไม่ส่งข้อความในรูปแบบที่มนุษย์อ่านได้
Nanban Jim

5
"และไม่มีใครในใจที่ถูกต้องของพวกเขาจะแนะนำให้ฉีกโปรโตคอลที่มีอยู่ทั้งหมดเพื่อแทนที่มันด้วยไบนารี่" - แต่คุณต้องเจรจาต่อรองของคุณเพิ่มขึ้นจากโปรโตคอลที่เป็นข้อความไปจนถึงสิ่งที่คุณคิดว่าดีกว่า SPDY ร้องขอการบีบอัดส่วนหัวและตอนนี้เป็นส่วนหนึ่งของ HTTP / 2 หรือสำหรับเรื่องนั้นจาก HTTP ไปเป็นชนิดเนื้อหาไบนารีหรือการเข้ารหัสการถ่ายโอน
Steve Jessop

4
โปรโตคอลข้อความธรรมดายังช่วยให้คุณสามารถตรวจสอบข้อมูลที่อาจเป็นอันตรายหรือไม่น่าเชื่อถือได้อย่างปลอดภัย ตัวอย่างเช่นฉันใช้ telnet เมื่อฉันได้รับจดหมายขยะ / ฟิชชิ่งซึ่งฉันสามารถรับประกันได้ว่าจะไม่เป็นอันตรายต่อระบบของฉัน การเข้าถึงระบบข้อความเป็นสิ่งสำคัญ แม้กระทั่งทุกวันนี้คุณจะทราบว่า HTTP / 1.1 นั้นไม่ใช่ "ข้อความธรรมดา" เนื่องจากส่วนหัวการยอมรับการเข้ารหัสอนุญาตให้ทำการบีบอัดซึ่งผู้ใช้เบราว์เซอร์และเซิร์ฟเวอร์ส่วนใหญ่สนับสนุนเพื่อโหลดหน้าเว็บที่เร็วขึ้น
phyrfox

ที่งาน Vintage Computer Fair ของมิดเวสต์ฉันพบว่ามันน่าสนใจที่เครื่องอย่าง Altair 680 จำเป็นต้องได้รับรหัสในรูปแบบบันทึกของ Motorola S ซึ่งใช้ตัวอักษร 76 ตัวสำหรับข้อมูล 32 ไบต์ทุกตัว (44 ตัวของค่าใช้จ่าย) แม้ว่าจะถูก จำกัด ให้ใช้ชุด 41 ตัวอักษรเช่น 0-9 AZ + - * / = ก็ควรจะสามารถลดสิ่งที่ใกล้เคียงกับ 57 ตัวอักษร (25 ตัวอักษรของค่าใช้จ่าย) ซึ่งจะลดเวลาสำหรับ ASR-33 ให้ฟีดโค้ด 1K จาก 4 นาทีไปจนถึงประมาณสาม ด้วยความเร็ว I / O ที่ช้าฉันสงสัยว่าทำไมเรื่องแบบนี้ถึงไม่ทำแบบธรรมดา
supercat

24

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

ไม่มีอะไรขัดขวางคุณในวันนี้และยุคนี้จากการเขียนรหัสในAssemblyหรือBrainf * ckและคุณอาจประหยัดบิตได้บ้างโดยการทำเช่นนั้น อย่างไรก็ตามการอธิบายสิ่งที่คุณทำกับคนอื่นเพื่อให้พวกเขาสามารถเข้าใจและโต้ตอบกับโค้ดของคุณจะไม่ง่ายหากคุณทำเช่นนั้น

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

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


หากโปรโตคอลได้รับการออกแบบมาเป็นไบนารีในสถานที่แรกแทนที่จะเป็นชวเลขไบนารีสำหรับโปรโตคอลข้อความที่มีอาจจะไม่ได้เป็นEHLOบ่อยตามที่ตกลงระยะเช่น ส่วนหน้าที่มนุษย์สามารถใช้งานได้สำหรับโพรโทคอลไบนารีอาจสร้างชื่อของตนเองขึ้นมาถ้ามาตรฐานไบนารีไม่ได้ตั้งชื่อไว้0x18ในตำแหน่งนี้
Peter Cordes

10

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

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

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

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

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

จากประสบการณ์ส่วนตัวฉันได้ทำงานให้กับเราเตอร์ของ บริษัท และฉันก็ยังทำงานให้กับ บริษัท ในการสร้างอุปกรณ์ telemetry ดังนั้นฉันจึงมีประสบการณ์มากมายในการทำงานกับโปรโตคอลไบนารีเช่น TCP / IP, ARP, IEC60870-5- 101 และ DNP3 ฉันยังทำงานกับโปรโตคอลข้อความเช่น HTTP, POP3 และ NMEA ฉันยังทำงานกับรูปแบบข้อมูลไบนารีเช่น ASN.1 และรูปแบบข้อมูลข้อความเช่น JSON และ XML ถ้าฉันจะเลือกฉันจะเลือกข้อความเกือบทุกครั้ง ครั้งเดียวที่ฉันเลือกไบนารีคือถ้าโปรโตคอลอยู่ในระดับต่ำจริง ๆ (จากนั้นฉันก็จะใช้งานได้มากพอที่จะทำให้ฉันสามารถใช้โพรโทคอลแบบข้อความด้านบนหรือมัน) หรือข้อมูลนั้นเป็นไบนารีแบบธรรมชาติ (เช่นไฟล์เสียง) .


3

โครงสร้างไบนารียังมีข้อ จำกัด ในการขยาย มันเป็นวันของฉันในการทำงานกับ FidoNet และสร้างเกตเวย์ระหว่างมันกับ UUCP / USNET ส่วนหัวของข้อความของ Fidonet เป็นไบนารีที่มีโครงสร้าง การขยายโดยเพียงแค่พยายามเพิ่มไบต์บางแห่งหมายถึงการทำลายทุกสิ่งในนั้นที่พยายามจะทำงานด้วย การมีส่วนหัวของข้อความหรือโปรโตคอลช่วยให้คุณสามารถขยายบางสิ่งโดยไม่ทำลายสิ่งต่างๆ


เรียนรู้บทเรียน: ใส่แท็กเวอร์ชันในข้อมูลไบนารี
ปีเตอร์ - Reinstate Monica

3

คำถามของคุณสามารถตีความได้สามวิธี:

  1. เพราะเหตุใดข้อมูลตัวเลขจึงถูกส่งผ่านข้อความที่เป็นข้อความราวกับว่ามันถูกพิมพ์ด้วยเช่นprintf()?
  2. ทำไมโปรโตคอลแอปพลิเคชันเลเยอร์คลาสสิก - เช่น ftp control channel, smtp, http - ตามเนื้อผ้าทั้งหมดใช้ชุดอักขระ ASCII 7 บิต? (7 บิต ASCII ถือเป็น "text" เนื่องจากไบต์ส่วนใหญ่สอดคล้องกับร่ายมนตร์ที่พิมพ์ได้หรือรหัสควบคุมข้อความเช่นบรรทัดใหม่และจากฟีด)
  3. เหตุใด Blobs ของข้อมูลไบนารีจึงถูกแปลงเป็น 7 บิต ASCII เมื่อส่งผ่านอินเทอร์เน็ตเช่นเป็นไฟล์แนบอีเมล

คำตอบแรกคือการทำงานร่วมกัน จำนวนเต็มและค่าทศนิยมมีการแสดงเลขฐานสองที่แตกต่างกันในเครื่องที่แตกต่างกันหรือแม้กระทั่งคอมไพเลอร์หรือแม้กระทั่งกับตัวเลือกคอมไพเลอร์ที่แตกต่างกัน การส่งสัญญาณอย่างมีประสิทธิภาพผ่านทางprintf/scanfทำให้การทำงานร่วมกันเป็นเรื่องง่าย โปรดทราบว่าตัวเลือกนี้ถูกสร้างขึ้นมาสำหรับโปรโตคอลระดับสูงเท่านั้น บนข้อมูลเลเยอร์เครือข่ายจะถูกส่งแบบไบนารี สำหรับสิ่งนี้ TCP / IP กำหนดการแทนค่าจำนวนเต็มแบบไบนารีและไลบรารีที่ใช้ TCP / IP จะให้วิธีการแปลงระหว่างการโฮสต์และเครือข่ายกับhtonlและเพื่อน

คำตอบสำหรับคำถามที่สองอาจเป็นไปได้ว่าRFC 206 (หมายเหตุหมายเลขต่ำสุด - 1971!) อธิบายโปรโตคอล telnet ซึ่งเป็นโปรโตคอลชั้นแอปพลิเคชันจำนวนมากซึ่งใช้แทนการพิมพ์โดยตรง

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

(เน้นในข้อความต้นฉบับ) อย่างน้อยบางชนิดและเครือข่ายโทรพิมพ์เฉพาะอย่างยิ่งใช้ ASCII 7 บิตเป็นชุดอักขระที่ต้องทำให้มันเป็นทางเลือกที่เป็นธรรมชาติ

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.