FMUSER Wirless ส่งวิดีโอและเสียงได้ง่ายขึ้น!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> แอฟริคานส์
sq.fmuser.org -> แอลเบเนีย
ar.fmuser.org -> ภาษาอาหรับ
hy.fmuser.org -> อาร์เมเนีย
az.fmuser.org -> อาเซอร์ไบจัน
eu.fmuser.org -> บาสก์
be.fmuser.org -> เบลารุส
bg.fmuser.org -> บัลแกเรีย
ca.fmuser.org -> คาตาลัน
zh-CN.fmuser.org -> ภาษาจีน (ประยุกต์)
zh-TW.fmuser.org -> ภาษาจีน (ดั้งเดิม)
hr.fmuser.org -> โครเอเชีย
cs.fmuser.org -> เช็ก
da.fmuser.org -> เดนมาร์ก
nl.fmuser.org -> ดัตช์
et.fmuser.org -> เอสโตเนีย
tl.fmuser.org -> ฟิลิปปินส์
fi.fmuser.org -> ฟินแลนด์
fr.fmuser.org -> ฝรั่งเศส
gl.fmuser.org -> กาลิเซีย
ka.fmuser.org -> จอร์เจีย
de.fmuser.org -> เยอรมัน
el.fmuser.org -> กรีก
ht.fmuser.org -> ชาวเฮติครีโอล
iw.fmuser.org -> ภาษาฮิบรู
hi.fmuser.org -> ภาษาฮินดี
hu.fmuser.org -> ฮังการี
is.fmuser.org -> ไอซ์แลนด์
id.fmuser.org -> ชาวอินโดนีเซีย
ga.fmuser.org -> ไอริช
it.fmuser.org -> อิตาเลี่ยน
ja.fmuser.org -> ภาษาญี่ปุ่น
ko.fmuser.org -> ภาษาเกาหลี
lv.fmuser.org -> ลัตเวีย
lt.fmuser.org -> ลิทัวเนีย
mk.fmuser.org -> มาซิโดเนีย
ms.fmuser.org -> มาเลย์
mt.fmuser.org -> มอลตา
no.fmuser.org -> นอร์เวย์
fa.fmuser.org -> เปอร์เซีย
pl.fmuser.org -> โปแลนด์
pt.fmuser.org -> โปรตุเกส
ro.fmuser.org -> โรมาเนีย
ru.fmuser.org -> รัสเซีย
sr.fmuser.org -> เซอร์เบีย
sk.fmuser.org -> สโลวัก
sl.fmuser.org -> สโลวีเนีย
es.fmuser.org -> สเปน
sw.fmuser.org -> ภาษาสวาฮิลี
sv.fmuser.org -> สวีเดน
th.fmuser.org -> ไทย
tr.fmuser.org -> ตุรกี
uk.fmuser.org -> ยูเครน
ur.fmuser.org -> ภาษาอูรดู
vi.fmuser.org -> เวียดนาม
cy.fmuser.org -> เวลส์
yi.fmuser.org -> ยิดดิช
ผลักดันข้อตกลง
ก่อนอื่นเรามาแนะนำกันก่อนว่ามีโปรโตคอลพุชอะไรบ้างสถานะปัจจุบันข้อดีและข้อเสียในช่องการถ่ายทอดสด
RTMP
WebRTC
โปรโตคอลที่เป็นกรรมสิทธิ์ตาม UDP
HLS
FLV
RTMP
RTMP เป็นคำย่อของ Real Time Messaging Protocol โปรโตคอลขึ้นอยู่กับ TCP และเป็นตระกูลโปรโตคอลซึ่งรวมถึงโปรโตคอลพื้นฐาน RTMP และ RTMPT / RTMPS / RTMPE และตัวแปรอื่น ๆ อีกมากมาย RTMP เป็นโปรโตคอลเครือข่ายที่ออกแบบมาสำหรับการสื่อสารข้อมูลแบบเรียลไทม์ ส่วนใหญ่จะใช้สำหรับการสื่อสารด้วยเสียงวิดีโอและข้อมูลระหว่างแพลตฟอร์ม Flash / AIR และสตรีมมิงมีเดีย / เซิร์ฟเวอร์โต้ตอบที่รองรับโปรโตคอล RTMP ซอฟต์แวร์ที่สนับสนุนข้อตกลงนี้ ได้แก่ Adobe Media Server / Ultrant Media Server / red5 เป็นต้น
RTMP เป็นโปรโตคอลการส่งผ่านสื่อสตรีมมิ่งกระแสหลักในปัจจุบันซึ่งใช้กันอย่างแพร่หลายในด้านการถ่ายทอดสด กล่าวได้ว่าผลิตภัณฑ์ถ่ายทอดสดส่วนใหญ่ในตลาดใช้โปรโตคอลนี้
ความได้เปรียบ
การสนับสนุน CDN เป็นสิ่งที่ดีผู้จำหน่าย CDN หลักสนับสนุน
โปรโตคอลที่เรียบง่ายใช้งานง่ายบนแพลตฟอร์มต่างๆ
ข้อเสียเปรียบ
ขึ้นอยู่กับ TCP ต้นทุนการส่งสูงและปัญหาสำคัญเมื่ออัตราการสูญเสียแพ็กเก็ตสูงในสภาพแวดล้อมเครือข่ายที่อ่อนแอ
ไม่รองรับการกดเบราว์เซอร์
ข้อตกลงที่เป็นกรรมสิทธิ์ของ Adobe Adobe ไม่อัปเดตอีกต่อไป
ปัญหาความเสถียรที่คาดเดาไม่ได้ยังมีแนวโน้มที่จะเกิดขึ้นเมื่อมีการทำงานพร้อมกันจำนวนมาก
WebRTC
WebRTC ซึ่งมีชื่อมาจากตัวย่อของ Web Real-Time Communication (อังกฤษ: Web Real-Time Communication) เป็น API ที่รองรับเว็บเบราว์เซอร์สำหรับการสนทนาด้วยเสียงหรือวิดีโอแบบเรียลไทม์ เปิดให้บริการเมื่อวันที่ 1 มิถุนายน 2011 และรวมอยู่ในมาตรฐานที่แนะนำของ W3C ของ World Wide Web Consortium โดยการสนับสนุนของ Google, Mozilla และ Opera
ความได้เปรียบ
มาตรฐาน W3C การสนับสนุนระดับสูงโดยเบราว์เซอร์หลัก
Google อยู่เบื้องหลังและมีการใช้งานอ้างอิงบนแพลตฟอร์มต่างๆ
เลเยอร์ด้านล่างขึ้นอยู่กับ SRTP และ UDP และมีพื้นที่มากมายสำหรับการปรับให้เหมาะสมในสภาพเครือข่ายที่อ่อนแอ
การสื่อสารแบบจุดต่อจุดสามารถรับรู้ได้โดยมีความล่าช้าต่ำระหว่างฝ่ายสื่อสาร
ข้อเสียเปรียบ
ICE, STUN, TURN CDN แบบดั้งเดิมไม่ได้ให้บริการที่คล้ายกัน
โปรโตคอลที่เป็นกรรมสิทธิ์ตาม UDP
แอปพลิเคชั่นถ่ายทอดสดบางรายการจะใช้ UDP เป็นโปรโตคอลพื้นฐานในการพัฒนาโปรโตคอลส่วนตัว เนื่องจากข้อดีของ UDP ในสภาพแวดล้อมเครือข่ายที่อ่อนแอสามารถบรรลุผลการเพิ่มประสิทธิภาพเครือข่ายที่อ่อนแอได้ดีกว่าผ่านการปรับจูนเองบางส่วน แต่ยังผูกพันที่จะเป็นส่วนตัว มาตรการ.
ความได้เปรียบ
พื้นที่เพิ่มเติมสำหรับการปรับแต่งและเพิ่มประสิทธิภาพ
ข้อเสียเปรียบ
ต้นทุนการพัฒนาสูง
CDN ไม่เป็นมิตรคุณต้องสร้าง CDN ของคุณเองหรือบรรลุข้อตกลงกับ CDN
ต่อสู้อย่างอิสระไม่สามารถพัฒนาร่วมกับชุมชนได้
ข้อตกลงอื่น ๆ
FLV
โปรโตคอล FLV ได้รับการส่งเสริมโดย Adobe เป็นหลัก รูปแบบนี้ง่ายมากยกเว้นว่าข้อมูลส่วนหัวของเครื่องหมายบางส่วนจะถูกเพิ่มลงในเฟรมวิดีโอขนาดใหญ่และส่วนหัวของเสียงและวิดีโอ เนื่องจากความเรียบง่ายอย่างยิ่งนี้จึงเป็นผู้ใหญ่ในแง่ของประสิทธิภาพการหน่วงเวลาและการทำงานพร้อมกันขนาดใหญ่ ข้อบกพร่องเพียงอย่างเดียวคือการสนับสนุนบนเบราว์เซอร์มือถือมี จำกัด มาก แต่เหมาะอย่างยิ่งสำหรับใช้เป็นโปรโตคอลการถ่ายทอดสดของแอปบนอุปกรณ์เคลื่อนที่
HLS
โซลูชันที่ Apple นำเสนอจะแบ่งวิดีโอออกเป็นส่วนวิดีโอขนาดเล็ก 5-10 วินาทีจากนั้นจัดการด้วยตารางดัชนี m3u8 เนื่องจากวิดีโอที่ลูกค้าดาวน์โหลดเป็นข้อมูลที่สมบูรณ์ประมาณ 5-10 วินาทีความราบรื่นของวิดีโอจึงดีมาก ดี แต่ยังแนะนำการหน่วงเวลามาก (ความล่าช้าโดยทั่วไปของ HLS อยู่ที่ประมาณ 10-30 วินาที) เมื่อเทียบกับ FLV แล้ว HLS รองรับ iPhone และเบราว์เซอร์มือถือ Android ส่วนใหญ่ดังนั้นจึงมักใช้สำหรับการแชร์ URL ใน QQ และ WeChat Moments
เครือข่ายการขนส่ง
สื่อสตรีมมิ่งที่เราผลักดันออกไปจำเป็นต้องถูกส่งไปยังผู้ชม ลิงค์ทั้งหมดคือเครือข่ายการส่ง การเปรียบเทียบโลจิสติกส์การขนส่งสินค้าคือระยะทางทั้งหมดจากจุดเริ่มต้นไปยังปลายทาง หากความจุของถนนไม่เพียงพอก็จะทำให้การจราจรติดขัดซึ่งก็คือความแออัดของโครงข่าย ในเวลานี้เราจะเปลี่ยนระยะทางซึ่งเรียกว่าการตั้งเวลาอัจฉริยะ แต่เครือข่ายการส่งจะกำหนดเวลาจากมุมมองทั่วโลกดังนั้นจะมีผลดีกว่าการตั้งเวลาของโลกปรมาณู เป็นไปได้ว่ามีเทพเจ้ามองลงมาที่ต้นทางและปลายทางบนท้องฟ้า ข้อมูลการจราจรทั้งหมดในเวลานั้นและเป็นแบบเรียลไทม์จากนั้นให้คุณมีถนนที่ชัดเจนมีมนต์ขลังเพียงใด
ก่อนอื่นเรามาดูเครือข่ายการกระจายเนื้อหาแบบเดิม
เหตุใดจึงมีเครือข่ายการกระจายเนื้อหาที่มาของเครือข่ายการกระจายเนื้อหา
อินเทอร์เน็ตมีต้นกำเนิดมาจากเครือข่ายภายในของกองทัพสหรัฐฯ Tim Berners-Lee เป็นหนึ่งในผู้คิดค้นอินเทอร์เน็ต เขาเล็งเห็นตั้งแต่เนิ่นๆว่าความแออัดของเครือข่ายจะกลายเป็นอุปสรรคที่ใหญ่ที่สุดในการพัฒนาอินเทอร์เน็ตในอนาคตอันใกล้ดังนั้นเขาจึงเกิดปัญหาทางวิชาการขึ้น ในการคิดค้นวิธีการแก้ปัญหาแบบใหม่และเป็นพื้นฐานเพื่อให้ตระหนักถึงการกระจายเนื้อหาทางอินเทอร์เน็ตที่ปราศจากความแออัดในที่สุดปัญหาทางวิชาการนี้ก็ก่อให้เกิดบริการอินเทอร์เน็ตที่เป็นนวัตกรรมใหม่ - CDN ในเวลานั้นดร. เบอร์เนอร์ส - ลีอยู่ถัดจากห้องทำงานของศาสตราจารย์ทอมเลห์ตันศาสตราจารย์ด้านคณิตศาสตร์ประยุกต์ที่สถาบันเทคโนโลยีแมสซาชูเซตส์ เขาถูกกระตุ้นโดยความท้าทายของเบอร์เนอร์ส - ลี ในที่สุดเล็ตตันก็แก้ปัญหานี้และเริ่มแผนธุรกิจของตัวเองก่อตั้ง Akamai กลายเป็น บริษัท CDN แห่งแรกของโลก
สถาปัตยกรรม CDN แบบดั้งเดิม
รูปด้านบนเป็นแผนผังของการปรับใช้สามระดับของระบบ CDN ทั่วไป โหนดเป็นยูนิตการปรับใช้พื้นฐานที่สุดในระบบ CDN แบ่งออกเป็นการปรับใช้สามระดับโหนดกลางโหนดระดับภูมิภาคและโหนดขอบ ระดับบนสุดคือโหนดกลางและโหนดกลางคือโหนดกลาง ระดับนี้เป็นโหนดระดับภูมิภาคและโหนดขอบจะกระจายไปตามพื้นที่โดยให้บริการการเข้าถึงเนื้อหาในบริเวณใกล้เคียงแก่ผู้ใช้
ต่อไปนี้จะแนะนำการจำแนกประเภทของโหนด CDN ซึ่งส่วนใหญ่แบ่งออกเป็นสองประเภทโหนดกระดูกสันหลังและโหนด POP และโหนดกระดูกสันหลังจะแบ่งออกเป็นโหนดกลางและโหนดระดับภูมิภาค
โหนดกระดูกสันหลัง
โหนดกลาง
โหนดพื้นที่
โหนด POP
โหนดขอบ
ตามหลักเหตุผลโหนดกระดูกสันหลังส่วนใหญ่มีหน้าที่ในการกระจายเนื้อหาและกลับไปยังแหล่งที่มาเมื่อพลาดโหนดขอบและโหนด POP มีหน้าที่หลักในการให้บริการการเข้าถึงเนื้อหาในบริเวณใกล้เคียงแก่ผู้ใช้ อย่างไรก็ตามหากขนาดเครือข่าย CDN มีขนาดใหญ่โหนดขอบจะกลับไปที่โหนดกลางโดยตรงจะทำให้เกิดแรงกดบนอุปกรณ์หลักของเลเยอร์กลางมากเกินไป แนะนำโหนดระดับภูมิภาคเพื่อรับผิดชอบในการจัดการพื้นที่ทางภูมิศาสตร์และบันทึกข้อมูลร้อนบางส่วน
จุดเจ็บปวดของเครือข่ายการถ่ายทอดสดที่แตกต่างจาก CDN แบบเดิม
ด้วยการถือกำเนิดของยุค Live การถ่ายทอดสดได้กลายเป็นอีกหนึ่งสนามรบที่สำคัญสำหรับผู้จำหน่าย CDN ในปัจจุบัน CDN ต้องรองรับบริการประเภทใดในยุค Live?
รองรับโปรโตคอลสื่อสตรีมมิ่งรวมถึง RTMP, HLS, HTTP-FLV เป็นต้น
หน้าจอแรกจะเปิดในไม่กี่วินาทีและการควบคุมจะอยู่ภายในไม่กี่วินาทีจากการคลิกของผู้ใช้ไปจนถึงการเล่น
1 ~ 3 การควบคุมความล่าช้าตั้งแต่การสตรีมจนถึงสิ้นสุดการเล่นความล่าช้าจะถูกควบคุมระหว่าง 1 ถึง 3 วินาที
การกำหนดเส้นทางอัจฉริยะทั่วโลกของเครือข่ายทั้งหมดสามารถใช้โหนดทั้งหมดในเครือข่าย CDN ทั้งหมดเพื่อให้บริการผู้ใช้รายเดียวโดยไม่คำนึงถึงข้อ จำกัด ทางภูมิศาสตร์ ด้วยความก้าวหน้าอย่างต่อเนื่องของกระบวนการบูรณาการระดับโลกการถ่ายทอดสดในภูมิภาคประเทศและทวีปต่างๆจึงกลายเป็นบรรทัดฐาน เป็นไปได้มากว่าสมอจะอยู่ในยุโรปและสหรัฐอเมริกาและผู้ใช้จะอยู่ในเอเชีย
โหนดระดับวันกำลังเพิ่มขึ้นตามความต้องการและ บริษัท จีนที่เดินทางไปต่างประเทศก็กลายเป็นเทรนด์ CDN ต้องการโหนดในต่างประเทศมากขึ้น ปัจจุบันโหนดในต่างประเทศจำนวนมากขึ้นแข่งขันกันเพื่อการปรับใช้อย่างรวดเร็ว ใช้เวลาหนึ่งวันตั้งแต่การเพิ่มความต้องการโหนดไปจนถึงการเชื่อมต่อกับเครือข่ายเพื่อให้บริการ ภายในสิ่งนี้มีข้อกำหนดที่สูงมากในการดำเนินการและการบำรุงรักษาและการวางแผนของ CDN แผนรายเดือนเดิมและการเข้าถึงเครือข่ายไม่สามารถตอบสนองความต้องการขั้นสูงได้
การกำหนดเส้นทางลิงค์ CDN แบบดั้งเดิม
CDN ขึ้นอยู่กับโทโพโลยีเครือข่ายแบบต้นไม้ แต่ละเลเยอร์มี GSLB (Global Server Load Balancing) สำหรับการทำโหลดบาลานซ์ของโหนด CDN หลายโหนดในเลเยอร์เดียวกัน มีประโยชน์อย่างไร?
ในสถานการณ์จำลองแอปพลิเคชัน CDN ที่กล่าวถึงข้างต้นการเร่งความเร็วเว็บการเร่งความเร็ววิดีโอและการเร่งความเร็วในการถ่ายโอนไฟล์ล้วนอาศัยระบบ GSLB และแคชในเวลาเดียวกัน ระบบแคชเป็นต้นทุนของระบบ CDN ทั้งหมดและสามารถขยายโครงสร้างแผนผังการออกแบบได้สูงสุด ประหยัดเงินลงทุนของระบบ Cache เนื่องจากมีเพียงโหนดกลางเท่านั้นที่จำเป็นต้องเก็บสำเนาแคชทั้งหมดของโอกาสจึงลดลงทีละขั้นตอนและโหนดขอบต้องการแคชร้อนเพียงเล็กน้อยเพื่อเข้าถึงคำขอเข้าถึง CDN ส่วนใหญ่ซึ่งช่วยลดต้นทุนได้มาก เครือข่าย CDN ซึ่งสอดคล้องกับเวลาด้วย ความต้องการของผู้ใช้ CDN เป็นสถานการณ์ที่ชนะ
แต่ในยุค Live บริการถ่ายทอดสดเป็นบริการสตรีมมิ่งและไม่ค่อยเกี่ยวข้องกับระบบ Cache โดยทั่วไปทรัพยากรที่จัดเก็บสามารถปล่อยได้หลังจากการออกอากาศเสร็จสิ้น แม้ว่าข้อกำหนดในการจัดเก็บจะเป็นเพราะเหตุผลด้านนโยบาย แต่ก็เป็นห้องเย็นทั้งหมด การลงทุนในพื้นที่จัดเก็บข้อมูลค่อนข้างถูกมากและไม่จำเป็นต้องมีพื้นที่จัดเก็บในทุกโหนดตราบใดที่ข้อมูลสามารถตรวจสอบย้อนกลับและพร้อมใช้งานได้
ลองมาดูโครงสร้างเครือข่ายแบบต้นไม้ จำนวนลิงก์ที่พร้อมใช้งานสำหรับผู้ใช้มี จำกัด ดังแสดงในรูปด้านล่างจำนวนลิงก์ที่มีให้สำหรับผู้ใช้ในบางพื้นที่คือ 2 * 5 = 10
หากผู้ใช้อยู่ในพื้นที่ใดพื้นที่หนึ่ง GSLB (โดยปกติคือ Smart DNS ที่ระดับโหนดขอบ) จะกำหนดเส้นทางผู้ใช้ไปยังโหนดขอบในพื้นที่และชั้นบนจะกำหนดเส้นทางผู้ใช้ไปยังโหนดพื้นที่ (ในที่นี้ GSLB โดยปกติจะเป็น ตัวจัดสรรภาระงานภายใน) และสุดท้ายกลับไปที่โหนดกลางโหนดกลางจะเชื่อมโยงสถานีต้นทาง
สมมติฐานที่นี่คือ:
โหนดที่เร็วที่สุดที่ผู้ใช้สามารถเข้าถึงได้ต้องเป็นโหนดขอบในพื้นที่ หากไม่มีโหนดขอบในพื้นที่โหนดที่เร็วที่สุดจะต้องเป็นโหนดขอบในพื้นที่ที่อยู่ติดกันเชิงตรรกะ
โหนดที่เร็วที่สุดที่โหนดขอบสามารถเข้าถึงได้ต้องเป็นโหนดพื้นที่ในพื้นที่และต้องไม่ใช่โหนดในพื้นที่อื่น
โหนดภูมิภาคไปยังโหนดกลางต้องเร็วที่สุดและความเร็วและแบนด์วิดท์ของลิงก์นี้เหมาะสมที่สุด
แต่เป็นเช่นนั้นจริงหรือ? เป็นความจริงหรือไม่ที่จะแนะนำสมมติฐานมากมาย?
ในความเป็นจริงแม้ว่าในทางทฤษฎีเราสามารถพิสูจน์ได้ว่าสมมติฐานข้างต้นนั้นถูกต้อง แต่การวางแผนโหนดและการกำหนดค่าภูมิภาคส่วนใหญ่ขึ้นอยู่กับการออกแบบและการวางแผนของผู้คน เราทราบดีว่าผู้คนจำนวนมากไม่น่าเชื่อถือและแม้ว่าการวางแผนระดับภูมิภาคจะถูกต้องในเวลานั้นใครสามารถรับประกันได้ว่าการวางแผนเครือข่ายคงที่เหล่านี้จะเปลี่ยนไปเนื่องจากการวางไฟเบอร์หรือเนื่องจากการกดดัน IDC บางอย่างมากเกินไปหรือไม่ ดังนั้นเราสามารถกระโดดออกจากห่วงของโทโพโลยีเครือข่ายแบบต้นไม้และสำรวจโทโพโลยีเครือข่ายใหม่ที่เหมาะสำหรับการเร่งความเร็วในการถ่ายทอดสด
เพื่อกำจัดข้อ จำกัด การกำหนดเส้นทางลิงก์ที่ จำกัด และเปิดใช้งานความสามารถในการจัดระเบียบเครือข่ายเราสามารถเปลี่ยนโหนดด้านบนให้เป็นโทโพโลยีเครือข่ายตาข่าย:
เราได้เห็นแล้วว่าเมื่อเราเปลี่ยนโครงสร้างเครือข่ายเป็นโครงสร้างแบบเมชลิงก์ที่ผู้ใช้เลือกได้จะกลายเป็น: เส้นทางทั้งหมดระหว่างจุดสองจุดที่ระบุในกราฟที่ไม่ได้กำหนดทิศทางตามที่นักเรียนที่ศึกษาทฤษฎีกราฟทราบจำนวนจะส่ายไปมา
ระบบสามารถเลือกได้เร็วที่สุด เชื่อมโยงผ่านการกำหนดเส้นทางอัจฉริยะแทนที่จะอาศัยการวางแผนด้วยตนเองที่ล้าสมัยในระหว่างการปรับใช้ระบบ ไม่ว่าจะเป็นการเพิ่มเส้นใยระหว่างลิงก์บางลิงก์หรือแรงกดดันที่มากเกินไปของ IDC บางอย่าง ก็สามารถสะท้อนให้เห็นในเครือข่ายการตกแต่งในแบบเรียลไทม์ เพื่อช่วยให้ผู้ใช้ผลักดันลิงก์ที่เหมาะสมที่สุดในแบบเรียลไทม์ ในเวลานี้ เราสามารถลบสมมติฐานก่อนหน้านี้บางส่วนและวางแผนการกำหนดเส้นทางลิงก์ของเครือข่ายในแบบเรียลไทม์ผ่านเครื่องแทนมนุษย์ งานประมวลผลขนาดใหญ่แบบเรียลไทม์ดังกล่าวไม่ใช่จุดแข็งของมนุษย์โดยเนื้อแท้ และเราควรมอบสิ่งเหล่านี้ให้กับสายพันธุ์ที่เหมาะสมกว่า
การขยาย CDN
ดังที่ได้กล่าวไว้ก่อนหน้านี้การไปต่างประเทศของ บริษัท จีนกลายเป็นแนวโน้มทั่วไปและความต้องการโหนดในต่างประเทศของ CDN ก็เพิ่มมากขึ้น ในสถานการณ์นี้ผู้จำหน่าย CDN จำเป็นต้องปรับใช้เครือข่ายกระดูกสันหลังและโหนดขอบใหม่ในภูมิภาคใหม่และจำเป็นต้องมีการวางแผนเครือข่ายโดยละเอียด เวลามีการเปลี่ยนแปลง เดิมทีผู้ใช้ CDN เป็นผู้ใช้ระดับองค์กรทั้งหมดและวงจรการวนซ้ำของสายธุรกิจของพวกเขานั้นยาวนานมีแผนใช้เวลานานและผู้ขาย CDN ยังเหลือเวลาอีกมาก บริษัท อินเทอร์เน็ตให้ความสำคัญกับความเร็ว การทำซ้ำทุกสองสัปดาห์กลายเป็นบรรทัดฐาน สิ่งนี้เกี่ยวข้องกับความขัดแย้งระหว่างต้นทุนและความเร็วในการตอบสนอง หากมีการติดตั้งโหนดล่วงหน้าก็จะสามารถให้บริการ บริษัท อินเทอร์เน็ตเหล่านี้ได้ดีขึ้น แต่ก็มีแรงกดดันด้านต้นทุนที่สูงกว่าและในทางกลับกัน ไม่สามารถตอบสนองต่อ บริษัท อินเทอร์เน็ตที่เติบโตอย่างรวดเร็วเหล่านี้
ตามหลักการแล้วหากผู้ใช้ส่งต่อข้อกำหนดผู้ผลิต CDN จะประเมินภายในให้ข้อเสนอแนะในวันเดียวกันและปรับใช้ในวันเดียวกันลูกค้าสามารถทดสอบโหนดใหม่ในพื้นที่ใหม่ในวันเดียวกันได้ จะจัดการกับมันอย่างไร?
คำตอบคือเครือข่ายแบบเพียร์ทูเพียร์ที่ใช้โครงสร้างเครือข่ายแบบเมช ในโทโพโลยีแบบเมชแต่ละโหนดคือเพียร์ ตามเหตุผลแล้วบริการที่จัดเตรียมโดยแต่ละโหนดจะเทียบเท่ากัน ไม่จำเป็นต้องออกแบบโครงสร้างเครือข่ายที่ซับซ้อนตามภูมิภาค หลังจากโหนดออนไลน์แล้วไม่จำเป็นต้องมีขั้นตอนการปรับใช้ที่ซับซ้อนและคุณสามารถลงทะเบียนข้อมูลโหนดออนไลน์ได้โดยตรงเพื่อให้บริการแก่ผู้ใช้ ตามทฤษฎีแล้วเวลาก่อนและหลังรวมกับเทคโนโลยีเวอร์ชวลไลเซชันสามารถควบคุมได้ภายในหนึ่งวัน
|
ป้อนอีเมลเพื่อรับเซอร์ไพรส์
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> แอฟริคานส์
sq.fmuser.org -> แอลเบเนีย
ar.fmuser.org -> ภาษาอาหรับ
hy.fmuser.org -> อาร์เมเนีย
az.fmuser.org -> อาเซอร์ไบจัน
eu.fmuser.org -> บาสก์
be.fmuser.org -> เบลารุส
bg.fmuser.org -> บัลแกเรีย
ca.fmuser.org -> คาตาลัน
zh-CN.fmuser.org -> ภาษาจีน (ประยุกต์)
zh-TW.fmuser.org -> ภาษาจีน (ดั้งเดิม)
hr.fmuser.org -> โครเอเชีย
cs.fmuser.org -> เช็ก
da.fmuser.org -> เดนมาร์ก
nl.fmuser.org -> ดัตช์
et.fmuser.org -> เอสโตเนีย
tl.fmuser.org -> ฟิลิปปินส์
fi.fmuser.org -> ฟินแลนด์
fr.fmuser.org -> ฝรั่งเศส
gl.fmuser.org -> กาลิเซีย
ka.fmuser.org -> จอร์เจีย
de.fmuser.org -> เยอรมัน
el.fmuser.org -> กรีก
ht.fmuser.org -> ชาวเฮติครีโอล
iw.fmuser.org -> ภาษาฮิบรู
hi.fmuser.org -> ภาษาฮินดี
hu.fmuser.org -> ฮังการี
is.fmuser.org -> ไอซ์แลนด์
id.fmuser.org -> ชาวอินโดนีเซีย
ga.fmuser.org -> ไอริช
it.fmuser.org -> อิตาเลี่ยน
ja.fmuser.org -> ภาษาญี่ปุ่น
ko.fmuser.org -> ภาษาเกาหลี
lv.fmuser.org -> ลัตเวีย
lt.fmuser.org -> ลิทัวเนีย
mk.fmuser.org -> มาซิโดเนีย
ms.fmuser.org -> มาเลย์
mt.fmuser.org -> มอลตา
no.fmuser.org -> นอร์เวย์
fa.fmuser.org -> เปอร์เซีย
pl.fmuser.org -> โปแลนด์
pt.fmuser.org -> โปรตุเกส
ro.fmuser.org -> โรมาเนีย
ru.fmuser.org -> รัสเซีย
sr.fmuser.org -> เซอร์เบีย
sk.fmuser.org -> สโลวัก
sl.fmuser.org -> สโลวีเนีย
es.fmuser.org -> สเปน
sw.fmuser.org -> ภาษาสวาฮิลี
sv.fmuser.org -> สวีเดน
th.fmuser.org -> ไทย
tr.fmuser.org -> ตุรกี
uk.fmuser.org -> ยูเครน
ur.fmuser.org -> ภาษาอูรดู
vi.fmuser.org -> เวียดนาม
cy.fmuser.org -> เวลส์
yi.fmuser.org -> ยิดดิช
FMUSER Wirless ส่งวิดีโอและเสียงได้ง่ายขึ้น!
ติดต่อ
ที่ตั้ง:
เลขที่ 305 อาคาร HuiLan เลขที่ 273 Huanpu Road Guangzhou China 510620
หมวดหมู่
จดหมายข่าว