ประโยชน์ด้านประสิทธิภาพ

บทนำ: สาเหตุและการลดเวลาในการตอบสนองของ DNS

เมื่อหน้าเว็บซับซ้อนยิ่งขึ้น การอ้างอิงทรัพยากรจากโดเมนจำนวนมาก การค้นหา DNS จึงเป็นจุดคอขวดที่สำคัญในการท่องเว็บ เมื่อใดก็ตามที่ไคลเอ็นต์ต้องการค้นหารีโซลเวอร์ DNS ผ่านเครือข่าย เวลาในการตอบสนองที่แนะนำจะมีนัยสำคัญ ทั้งนี้ขึ้นอยู่กับความใกล้เคียงและจำนวนของเนมเซิร์ฟเวอร์ที่รีโซลเวอร์ต้องค้นหา (มีมากกว่า 2 ประเภทซึ่งเกิดขึ้นไม่บ่อยนักแต่อาจเกิดขึ้นได้) ดูตัวอย่างภาพหน้าจอต่อไปนี้แสดงเวลาที่เครื่องมือวัดประสิทธิภาพเว็บของ Page Speed รายงานไว้ แต่ละแถบแสดงทรัพยากรที่อ้างอิงจากหน้าเว็บ ส่วนกลุ่มสีดำจะระบุถึงการค้นหา DNS ในหน้านี้จะมีการค้นหา 13 รายการภายใน 11 วินาทีแรกที่โหลดหน้าเว็บ แม้ว่าการค้นหาหลายครั้งจะทำพร้อมกัน แต่ภาพหน้าจอแสดงให้เห็นว่าต้องใช้เวลาในการค้นหาแบบอนุกรม 5 ครั้ง ซึ่งคิดเป็นหลายวินาทีจากทั้งหมด 11 วินาทีในการโหลดหน้าเว็บ

เวลาในการตอบสนองของ DNS มี 2 องค์ประกอบดังนี้

• เวลาในการตอบสนองระหว่างไคลเอ็นต์ (ผู้ใช้) กับเซิร์ฟเวอร์แปลง DNS ในกรณีส่วนใหญ่ สาเหตุส่วนใหญ่มักเกิดจากข้อจํากัดของเวลารับส่งข้อมูล (RTT) ตามปกติในระบบเครือข่าย ได้แก่ ความห่างทางภูมิศาสตร์ระหว่างเครื่องไคลเอ็นต์และเซิร์ฟเวอร์ ความคับคั่งของเครือข่าย การสูญเสียแพ็กเก็ตและความล่าช้าในการส่งซ้ำ (โดยเฉลี่ย 1 วินาที) เซิร์ฟเวอร์ทำงานหนักเกินไป การโจมตีแบบปฏิเสธการให้บริการ และอื่นๆ
• เวลาในการตอบสนองระหว่างเซิร์ฟเวอร์การแปลงค่าและเนมเซิร์ฟเวอร์อื่นๆ แหล่งที่มาของเวลาในการตอบสนองนี้มีสาเหตุหลักมาจากปัจจัยต่อไปนี้
  • ไม่พบแคช หากการตอบสนองจากแคชของรีโซลเวอร์ทำไม่ได้ แต่ต้องมีการค้นหาเนมเซิร์ฟเวอร์อื่นซ้ำๆ เวลาในการตอบสนองของเครือข่ายที่เพิ่มก็จะต้องได้รับการพิจารณา โดยเฉพาะอย่างยิ่งหากเซิร์ฟเวอร์ที่เชื่อถือได้อยู่ห่างไกลกันในทางภูมิศาสตร์
  • การจัดสรรน้อยเกินไป หากรีโซลเวอร์ DNS ทำงานหนักเกินไป รีโซลเวอร์จะต้องจัดคิวคำขอและคำตอบในการแก้ปัญหา DNS และอาจเริ่มทิ้งและส่งแพ็กเก็ตอีกครั้ง
  • การเข้าชมที่เป็นอันตราย แม้ว่าบริการ DNS จะมีการจัดสรรมากเกินไป แต่การรับส่งข้อมูล DoS ก็อาจทำให้เซิร์ฟเวอร์มีภาระงานเกินควรได้ ในทำนองเดียวกัน การโจมตีรูปแบบ Kaminsky อาจเกี่ยวข้องกับรีโซลเวอร์น้ำท่วมซึ่งมีคำค้นหาที่รับประกันว่าจะข้ามแคชและต้องส่งคำขอขาออกสำหรับการแก้ไข

เราเชื่อว่าปัจจัยการพลาดของแคชเป็นสาเหตุหลักของเวลาในการตอบสนองของ DNS ซึ่งเราจะกล่าวถึงรายละเอียดเพิ่มเติมด้านล่าง

ไม่พบข้อมูลในแคช

แม้ว่ารีโซลเวอร์จะมีทรัพยากรในเครื่องมากมาย แต่ความล่าช้าพื้นฐานที่เกี่ยวข้องกับการติดต่อกับเนมเซิร์ฟเวอร์ระยะไกลก็หลีกเลี่ยงได้ยาก กล่าวคือ สมมติว่ามีการจัดสรรรีโซลเวอร์ดีพอเพื่อให้ Hit แคชใช้เวลาเป็นศูนย์ในฝั่งเซิร์ฟเวอร์ การไม่พบแคชจะมีราคาแพงมากในแง่ของเวลาในการตอบสนอง ในการจัดการการสูญหาย รีโซลเวอร์จะต้องสื่อสารกับเนมเซิร์ฟเวอร์ภายนอกอย่างน้อย 1 รายการ แต่บ่อยครั้งก็มักจะเป็นเซิร์ฟเวอร์ภายนอกอย่างน้อย 2 รายการ เมื่อใช้โปรแกรมรวบรวมข้อมูลเว็บของ Googlebot เราพบว่าเนมเซิร์ฟเวอร์ที่มีการตอบสนองใช้เวลาเฉลี่ย 130 มิลลิวินาที อย่างไรก็ตาม คำขอทั้ง 4-6% จะหมดเวลาเนื่องจากแพ็กเก็ต UDP สูญหายและเซิร์ฟเวอร์เข้าถึงไม่ได้ หากเราพิจารณาข้อผิดพลาดต่างๆ เช่น แพ็กเก็ตสูญหาย เนมเซิร์ฟเวอร์ที่ใช้งานไม่ได้ ข้อผิดพลาดในการกำหนดค่า DNS ฯลฯ เวลาในการแก้ปัญหาเฉลี่ยจากต้นทางถึงปลายทางตามจริงคือ 300-400 มิลลิวินาที อย่างไรก็ตาม มีความแปรปรวนสูงและมีระยะเวลายาว

แม้ว่าอัตราการพลาดของแคชอาจแตกต่างกันไปสำหรับเซิร์ฟเวอร์ DNS แต่พื้นฐานแล้ว การไม่พบแคชอาจหลีกเลี่ยงได้ยากด้วยเหตุผลดังต่อไปนี้

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

การบรรเทาปัญหา

ใน Google Public DNS เราได้ใช้หลายวิธีในการเพิ่มความเร็วในการค้นหา DNS โดยบางวิธีเป็นวิธีการมาตรฐานที่ค่อนข้างมาตรฐาน ขณะที่วิธีการอื่นๆ ยังอยู่ในขั้นทดลอง

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

การจัดสรรคลัสเตอร์ที่ให้บริการอย่างเพียงพอ

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

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

การจัดสรรภาระงานสำหรับการแคชที่แชร์

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

หากต้องการเพิ่มอัตรา Hit สำหรับชื่อที่แคชได้ สิ่งสำคัญคือเซิร์ฟเวอร์ที่มีการจัดสรรภาระงานเพื่อให้แคชไม่แยกส่วน ใน Google Public DNS เรามีการแคชสองระดับ ในกลุ่มเครื่อง 1 เครื่องที่ใกล้กับผู้ใช้มาก แคชต่อเครื่องขนาดเล็กจะมีชื่อที่ได้รับความนิยมมากที่สุด หากไม่พบคำค้นหาจากแคชนี้ ระบบจะส่งรายการดังกล่าวไปยังกลุ่มเครื่องอื่นที่แบ่งพาร์ติชันแคชตามชื่อ สำหรับแคชระดับที่ 2 นี้ ระบบจะส่งคำค้นหาทั้งหมดที่มีชื่อเดียวกันไปยังเครื่องเดียวกัน โดยที่ชื่อนั้นจะมีการแคชไว้หรือไม่ก็ได้

การกระจายคลัสเตอร์ที่แสดงผลสำหรับการครอบคลุมทางภูมิศาสตร์ในวงกว้าง

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

DNS สาธารณะของ Google โฮสต์อยู่ในศูนย์ข้อมูลทั่วโลก และใช้การกำหนดเส้นทาง Anycast เพื่อส่งผู้ใช้ไปยังศูนย์ข้อมูลที่อยู่ใกล้ที่สุด

นอกจากนี้ Google Public DNS ยังรองรับซับเน็ตไคลเอ็นต์ EDNS (ECS) ซึ่งเป็นส่วนขยายโปรโตคอล DNS สำหรับรีโซลเวอร์เพื่อส่งต่อตำแหน่งไคลเอ็นต์ไปยังเนมเซิร์ฟเวอร์ ซึ่งจะแสดงการตอบกลับที่อิงตามตำแหน่งซึ่งเพิ่มประสิทธิภาพสำหรับที่อยู่ IP ของไคลเอ็นต์จริง แทนที่จะเป็นที่อยู่ IP ของรีโซลเวอร์ โปรดอ่านรายละเอียดในคำถามที่พบบ่อยนี้ DNS สาธารณะของ Google ตรวจหาเนมเซิร์ฟเวอร์โดยอัตโนมัติ ที่รองรับซับเน็ตไคลเอ็นต์ EDNS