DNS Round Robin: เบราว์เซอร์เชื่อมต่อกับ IP เดียวตราบใดที่ยังออนไลน์อยู่หรือไม่

เบราว์เซอร์ส่วนใหญ่จะทำงานอย่างไรหากได้รับ A-records หลายรายการจากเซิร์ฟเวอร์ DNS ติดกับ IP หนึ่งตราบใดที่สามารถเข้าถึงได้ (และใช้อีกหาก IP นั้นลง)? หรือพวกเขาสลับตลอดเวลาโดยไม่มีเหตุผล?

หากเบราว์เซอร์ปัจจุบันส่วนใหญ่ยึดติดกับ IP เดียว DNS-RR จะเพียงพอสำหรับฉันในฐานะวิธีการแก้ปัญหาความล้มเหลวอย่างง่าย

เบราว์เซอร์แต่ละตัวมีวิธีจัดการ DNS รอบโรบินเป็นของตัวเองฉันได้ใช้เวลาในวันนี้เพื่อค้นคว้าปัญหานี้และจะอัปเดตคำตอบของฉันต่อไปเนื่องจากฉันพบหลักฐานการใช้งานซึ่งจะ จำกัด คำตอบของฉันสำหรับเบราว์เซอร์

Google Chrome

Google Chrome (ใช้ v58) จะขอรายการโฮสต์ทั้งหมดสำหรับที่อยู่ (A, AAAA, CNAME) และใส่ไว้ในอาร์เรย์ ( address_list ) Chrome จะพยายามเปิดซ็อกเก็ตในที่อยู่ IP แต่ละแห่งตามลำดับจากคนแรกถึงครั้งสุดท้ายโครมจะไม่พยายามใช้ IP ที่เร็วที่สุดหรือใกล้เคียงที่สุดโดยจะถือว่า IP แรก (ที่ได้รับจากตัวแก้ไข DNS ต้นน้ำของคุณ) เป็น IP ที่ดีที่สุด ในการทดสอบของฉันเซิร์ฟเวอร์ bind และ windows dns ให้ลำดับของ IP ต่อการค้นหาที่แตกต่างกันซึ่งทำให้ดูเหมือนว่า 50/50 แบ่งแบนด์วิดท์ให้กับแต่ละ IP ฟังก์ชั่นนี้มีการเปิดเผยchrome://net-internals/#events&q=type:SOCKET%20is:active

Curl (libcurl / 7.54.0)

Curl ยังมีฟังก์ชั่นล้มเหลวนี้ แต่ --connect-timeoutมีความยาวมากกว่าค่าเริ่มต้นใน chrome, chrome ล้มเหลวทันที, Curl ไม่ทำงาน หากคุณใช้ libcurl และต้องการเอาตัวรอดอินสแตนซ์ round-robin dns ที่ IP หนึ่งล้มเหลว (ทำงานใน chrome แต่ไม่อยู่ในโค้ด) ต้องแน่ใจว่าระบุค่านี้ต่ำกว่า

DEFAULT_CONNECT_TIMEOUT: 0ทำให้ฉันคิดว่านี่เป็นไปไม่ได้ด้วย curl

* After 149990ms connect time, move on!

ในเบราว์เซอร์ทั้งสองIP ไม่ติดหนึบพวกเขาติดตาม TTL ที่ระบุใน DNS และเมื่อ ttl หมดอายุแล้ว (โครเมี่ยมยังคงอยู่ภายในนี้ curl ถามคำขอแต่ละครั้ง) การเลือก ip จะดำเนินการทุกครั้งตามที่อธิบายไว้ข้างต้น

สิ่งนี้หมายความว่า? DNS-RR ใช้ได้กับบางระบบ แต่ไม่ได้ออกแบบมาสำหรับระบบล้มเหลว คุณควรคาดหวังว่าผลลัพธ์ทั้งหมดจากการค้นหา DNS นั้นถูกต้อง (แหล่งที่มาของความจริง) และสามารถใช้เพื่อรับส่งข้อมูลได้ มีหลายวิธีที่จะตรวจสอบความพร้อม IP เช่น IP ที่เสมือนลอย BGP / เทคนิคเส้นทาง ฯลฯใช้พวกเขา

การทดสอบทั้งหมดดำเนินการในสภาพแวดล้อม IPv4 เท่านั้นจะกลับมาพร้อมกับผลลัพธ์แบบสแต็กคู่เมื่อมีโครงสร้างพื้นฐานเพียงพอที่จะทดสอบ

ฉันคาดการณ์การเปลี่ยนแปลงเหล่านี้เป็นผลข้างเคียงของHappy Eyeballsของ IPv6-Fallback RFC

อัปเดต การพิจารณาที่มีประโยชน์ RR DNS สามารถช่วยในการทำโหลดบาลานซ์เท่านั้นไม่ใช่ความล้มเหลวของแอปพลิเคชันหากหนึ่งในโหนดของคุณมี 503 คุณจะให้บริการ 40-60% หากปริมาณข้อมูลของคุณ 503 มีการสันนิษฐานว่า IP ทั้งหมดที่ระบุไว้เป็นจุดสิ้นสุดการทำงานที่ถูกต้องหากเข้าถึงได้

แก้ไข: แก้ไขคำตอบของฉันตั้งแต่ HiPerFreak เรียนฉัน

เซิร์ฟเวอร์ DNS จะส่งคืนรายการระเบียน A ทั้งหมดที่มีให้สำหรับชื่อโฮสต์ที่ระบุ เมื่อโรบินกลมเข้ามาก็จะหมุนตามลำดับรายการ ลิงค์ที่โพสต์ไว้เป็นตัวอย่างที่ดีว่าเว็บเบราว์เซอร์จะใช้ประโยชน์จากรายการนั้นอย่างไร

Round Robinning สามารถใช้สำหรับการโหลดบาลานซ์ในรูปแบบดั้งเดิม แต่เป็นการทดแทนที่แย่มากสำหรับการปรับสมดุลการโหลดจริงเนื่องจากหากหนึ่งในโฮสต์ในการหมุนรอบโรบินหมุนลงเซิร์ฟเวอร์ DNS จะไม่ฉลาดและจะยังคงอยู่ ใส่ที่อยู่ IP ของโหนดที่ downed ในรายการ

ดูคำถามของฉัน (และคำตอบ): วิธีที่เบราว์เซอร์จัดการหลาย IPIPs

ไม่นาน - รอบโรบิน DNS ไม่ได้ปรับปรุงความพร้อมใช้งานเลย เบราว์เซอร์เลือกหนึ่ง IP และเกาะติดแม้ว่าจะไม่ตอบสนอง (ตรวจสอบด้วย FF และโครเมี่ยม)

เมื่อเบราว์เซอร์แคช DNS หมดอายุชื่อโฮสต์จะถูกแก้ไขอีกครั้งและกระบวนการซ้ำโดยไม่คำนึงถึงว่า IP ตอบหรือไม่

สำหรับ HA พื้นฐานคุณสามารถใช้ DNS แบบไดนามิกหรือวิธีการอิง IP แบบต่างๆ

แก้ไข: พฤติกรรมนี้จะเกิดขึ้นเมื่อไม่สามารถเข้าถึงโฮสต์ทำหน้าที่เป็น "หลุมดำ" ถ้าเจ้าบ้านปฏิเสธการเชื่อมต่อที่เข้ามาแทนเบราว์เซอร์จะลองหนึ่งไอพีรับปฏิเสธและใช้ไอพีอื่นทันทีและมันจะล้มเหลวได้ค่อนข้างดี

พวกเขาเปลี่ยน IP มันไม่ใช่วิธีแก้ปัญหาล้มเหลว

เบราว์เซอร์ช่วยให้ระบบปฏิบัติการจำแนกชื่อได้และสำหรับการตรวจสอบ Linux จะสุ่มที่อยู่ IP ให้ลองโฮสต์ google.comหลายครั้ง IP จะมาตามลำดับแบบสุ่ม

DNS ส่งคืน IP ทั้งหมดในรายการ แต่จะเปลี่ยนลำดับของรายการและคำสั่งนี้จะไม่สุ่มหรือเปลี่ยนแปลงเมื่อ 1 ล้มเหลว แต่จะส่งคืน IP ในลำดับเดียวกันเสมอสำหรับเหตุผลในการโหลดบาลานซ์ เมื่อเบราว์เซอร์ได้รับรายการฉันคิดว่าเบราว์เซอร์จะเลือกอันดับที่ 1 ในรายการหากไม่ทราบว่าไม่ทำงาน