ทำไมการสำรวจจึงยอมรับในการเขียนโปรแกรมเว็บ?

ขณะนี้ฉันกำลังทำงานกับโครงการRuby on Railsซึ่งแสดงรายการรูปภาพ

สิ่งที่ต้องมีสำหรับโครงการนี้คือมันแสดงโพสต์ใหม่แบบเรียลไทม์โดยไม่จำเป็นต้องรีเฟรชหน้าเว็บ หลังจากค้นหาไประยะหนึ่งฉันได้พบกับโซลูชันและบริการ JavaScript บางอย่างเช่น PubNub; อย่างไรก็ตามไม่มีวิธีการแก้ปัญหาใด ๆ ที่ให้มา

ในโซลูชัน JavaScript ( การทำโพล ) จะเกิดสิ่งต่อไปนี้:

• ผู้ใช้ 1 ดูรายการภาพถ่าย
• ในพื้นหลังรหัส JavaScript จะทำการสำรวจจุดสิ้นสุดทุกวินาทีเพื่อดูว่ามีการโพสต์ใหม่หรือไม่
• ผู้ใช้ 2 เพิ่มรูปภาพใหม่
• มีความล่าช้า 50 วินาทีก่อนที่จะมีการเรียกใช้รอบใหม่และดึงข้อมูลใหม่
• เนื้อหาใหม่จะถูกโหลดในDOM

ดูเหมือนแปลกเมื่อแปลเป็นตัวอย่างในโลกแห่งความจริง:

• ผู้ใช้ 1 ถือกองรูปภาพไว้บนโต๊ะของเขา / เธอ
• เขา / เธอเดินไปที่ช่างภาพทุกวินาทีและถามว่าเขามีใหม่หรือไม่
• ช่างภาพสร้างภาพใหม่
• วินาทีนี้เมื่อเขา / เธอเดินเข้ามาเธอสามารถถ่ายรูปและวางลงบนกอง

ในความคิดของฉันทางออกควรเป็นดังนี้:

• ผู้ใช้ 1 ถือกองรูปภาพไว้บนโต๊ะของเขา / เธอ
• ช่างภาพจะถ่ายรูปใหม่
• ช่างภาพเดินไปที่กองและวางไว้กับส่วนที่เหลือ

วิธีการ PubNub นั้นเหมือนกัน แต่คราวนี้มีการฝึกงานระหว่างฝ่ายต่าง ๆ เพื่อแบ่งปันข้อมูล

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

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

การพุชทำงานได้ดีสำหรับ 1 หรือผู้ใช้ในจำนวน จำกัด

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

ช่างภาพกำลังยุ่งอยู่กับการเดินตลอดเวลาและไม่ถ่ายรูปใหม่

พื้นฐาน: แบบจำลองแบบดึง / สำรวจจะช่วยให้ผู้อ่านที่ไม่น่าเชื่อถือจำนวนมากมีความต้องการแบบเรียลไทม์หลวม (ถ้ารูปภาพใช้เวลา 10 วินาทีต่อมาก็จะมาถึงกองขยะนั่นเป็นเรื่องใหญ่)

ที่กล่าวว่าแบบจำลองการกดยังดีกว่าในหลาย ๆ สถานการณ์ หากคุณต้องการเวลาแฝงที่ต่ำ (คุณต้องการ 5s รูปถ่ายใหม่หลังจากถ่ายเสร็จ) หรือการอัปเดตนั้นหายากและร้องขอบ่อยและคาดการณ์ได้ (ขอให้ช่างภาพทุก ๆ 10 วินาทีเมื่อเขาสร้างภาพใหม่ต่อวัน) การดึงนั้นไม่เหมาะสม ขึ้นอยู่กับสิ่งที่คุณพยายามจะทำ NASDAQ: การผลักดัน บริการสภาพอากาศ: ดึง ช่างภาพงานแต่งงาน: อาจจะดึง สำนักข่าวภาพ: อาจผลักดัน

ฉันประหลาดใจจริงๆว่าเพียงคนเดียวได้กล่าวถึงWebSockets มีการสนับสนุนในเบราว์เซอร์หลัก ๆ ทุกตัว

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

ในตัวอย่างของคุณลองนึกภาพสิ่งที่ชอบ:

1. ผู้ใช้ช่วยให้ช่างภาพรู้ว่าเขาต้องการรู้เกี่ยวกับรูปถ่ายในอนาคตทั้งหมด
2. ช่างภาพพูดผ่านลำโพงว่ามีรูปภาพใหม่ให้ใช้งาน
3. ผู้ใช้ถามช่างภาพเพื่อถ่ายรูป

นี่เป็นวิธีการแก้ปัญหาตัวอย่างดั้งเดิมของคุณ มันมีประสิทธิภาพมากกว่าการสำรวจเพราะลูกค้าไม่จำเป็นต้องส่งข้อมูลใด ๆ ไปยังเซิร์ฟเวอร์ (ยกเว้นอาจจะเต้นของหัวใจ )

นอกจากนี้ตามที่คนอื่น ๆ พูดถึงมีวิธีการอื่น ๆ ที่ดีกว่าการทำโพลแบบง่ายๆที่ทำงานในเบราว์เซอร์รุ่นเก่า ( longpolling, et al .)

บางครั้งก็ดีพอก็ดีพอ

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

โปรโตคอล HTTP ถูก จำกัด ว่าลูกค้าจะต้องเป็นคนหนึ่งที่จะเริ่มต้นการร้องขอ เซิร์ฟเวอร์ไม่สามารถสื่อสารกับลูกค้าได้เว้นแต่จะตอบกลับคำขอของลูกค้า

ดังนั้นในการปรับตัวอย่างโลกแห่งความจริงของคุณให้เพิ่มข้อ จำกัด ต่อไปนี้:

• ผู้ใช้ 2 เท่านั้นสามารถตอบคำถามของผู้ใช้ 1 ด้วยการตอบประโยคเดียวหลังจากนั้นผู้ใช้ 1 จะต้องออกจาก ผู้ใช้ 2 ไม่มีวิธีการสื่อสารอื่น

ด้วยความยับยั้งชั่งใจใหม่นี้คุณจะทำอย่างอื่นนอกเหนือจากการเลือกตั้งได้อย่างไร

ทำไมการสำรวจจึงเป็นที่ยอมรับ? เพราะในความเป็นจริงการแก้ปัญหาทุกอย่างแท้จริงแล้วเป็นการสำรวจในระดับต่ำ!

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

การเชื่อมต่อ stateful ทั้งหมด (ตัวอย่างเช่น TCP / IP) ทำงานเหมือนกันเนื่องจากคุณสามารถส่งแพ็กเก็ตข้อมูลเอกพจน์ผ่านอินเทอร์เน็ตเท่านั้น คุณไม่มีทางรู้ว่าอีกฝ่ายยังอยู่ที่นั่นหรือไม่

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

ดังนั้นวิธีที่ดีที่สุดน่าจะเป็นการหยั่งเสียงระยะยาว:

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

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

ข้อดีอย่างหนึ่งของการสำรวจคือการ จำกัด อันตรายที่อาจเกิดขึ้นหากข้อความหายไปหรือสถานะของบางสิ่งผิดพลาด ถ้า X ถาม Y ถึงสถานะของมันทุก ๆ ห้าวินาทีการสูญเสียการร้องขอหรือการตอบกลับจะส่งผลให้ข้อมูลของ X นั้นล้าสมัยไปสิบวินาทีแทนที่จะเป็น 5 หาก Y ได้รับการรีบูท X จะสามารถหาข้อมูลได้ในครั้งต่อไป เวลา Y สามารถตอบกลับข้อความใดข้อความหนึ่งของ X ถ้า X ถูกรีบูทมันอาจจะไม่ทำให้ Y ถามอะไรหลังจากนั้น แต่ใครก็ตามที่สังเกตสถานะของ X ควรรู้ว่ามันถูกรีบูทแล้ว

ถ้าแทนที่จะเป็นโพล Y, X พึ่งพา Y เพื่อแจ้งให้ทราบเมื่อมีการเปลี่ยนแปลงสถานะจากนั้นหากสถานะของ Y เปลี่ยนไปและส่งข้อความถึง X แต่ด้วยเหตุผลใดก็ตามที่ไม่ได้รับข้อความ X อาจไม่ทราบถึงการเปลี่ยนแปลง . เช่นเดียวกันถ้า Y ถูกรีบูทและไม่เคยมีเหตุผลอะไรเลยที่จะส่ง X ข้อความเกี่ยวกับอะไรเลย

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

การลงคะแนนเลือกตั้งอาจมีข้อได้เปรียบเพิ่มเติมเมื่อใช้สื่อการสื่อสารที่อาจไม่น่าเชื่อถือ (เช่น UDP หรือวิทยุ): ส่วนใหญ่สามารถกำจัดความต้องการการตอบรับลิงก์เลเยอร์ หาก X ส่ง Y คำขอสถานะ Q, Y ตอบกลับด้วยรายงานสถานะ R และ X ได้ยิน R, X ไม่จำเป็นต้องได้ยินการตอบรับลิงก์เลเยอร์ใด ๆ สำหรับ Q เพื่อรับทราบว่าได้รับแล้ว ในทางกลับกันเมื่อ Y ส่ง R มันไม่จำเป็นต้องรู้หรือสนใจว่า X ได้รับมาหรือไม่ หาก X ส่งการร้องขอสถานะและไม่ได้รับการตอบกลับก็สามารถส่งคำขออื่นได้ หาก Y ส่งรายงานและ X ไม่ได้ยิน X จะส่งคำขออีกครั้ง หากคำขอแต่ละครั้งออกไปหนึ่งครั้งและตอบสนองหรือไม่ตอบก็ไม่ฝ่ายใดฝ่ายหนึ่งต้องรู้หรือสนใจว่าได้รับข้อความใดเป็นพิเศษหรือไม่ เนื่องจากการส่งการตอบรับอาจใช้แบนด์วิดท์เกือบเท่าคำขอหรือรายงานสถานะ การใช้การร้องขอไปกลับรายงานไม่ได้มีค่าใช้จ่ายมากไปกว่าการรายงานและการตอบรับที่ไม่พึงประสงค์ หาก X ส่งคำขอสองสามโดยไม่ได้รับคำตอบอาจเป็นไปได้ว่าในเครือข่ายที่กำหนดเส้นทางแบบไดนามิกบางอย่างจำเป็นต้องเปิดใช้งานการตอบรับระดับลิงก์ (และขอในคำขอของมันที่ Y ทำเช่นเดียวกัน) เส้นทางใหม่ แต่เมื่อสิ่งต่าง ๆ ทำงานเป็นแบบจำลองการร้องขอรายงานจะมีประสิทธิภาพมากกว่าการใช้การตอบรับระดับลิงก์

คำถามคือเพื่อสมดุลจำนวนโพลที่ไม่จำเป็นเทียบกับจำนวนโพลที่ไม่จำเป็น

หากคุณสำรวจความคิดเห็น:

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

หากคุณกด:

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

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

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

วิธีการพุชที่ใช้การเข้าสู่ระบบคำอธิบายของข้อมูลที่ต้องการและในที่สุดการออกจากระบบจะมีประสิทธิภาพมากที่สุด แต่อาจซับซ้อนเกินไปสำหรับ "script-kiddy" เฉลี่ยและจำเป็นต้องจัดการกับคำถาม: จะเกิดอะไรขึ้นหากผู้ใช้ เพียงแค่ปิดเบราว์เซอร์และออกจากระบบไม่สามารถทำได้?

อาจจะเป็นการดีกว่าถ้ามีผู้ใช้เพิ่มขึ้น (เนื่องจากการเข้าถึงนั้นง่ายกว่า) เพื่อประหยัด bucks บางอย่างบนแคชเซิร์ฟเวอร์อื่น

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

1. แบนด์วิดธ์เป็นปัญหา
2. การเชื่อมต่ออาจไม่ต่อเนื่อง
3. เบราว์เซอร์ไม่มีพลังในการคำนวณมากนัก
4. มีวิธีการอื่นในการเข้าถึงเนื้อหา เว็บไม่ใช่ w3

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

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