Score:0

ฉันจะแน่ใจได้อย่างไรว่าการเปลี่ยนแปลง DNS มีผลภายใน TTL แม้ว่าเบราว์เซอร์จะใช้การเชื่อมต่อ HTTP ซ้ำ

ธง gr

ฉันกำลังช่วยติดตั้ง CloudFront CDN สำหรับต้นทางวิดีโอ NGINX HLS หากคุณไม่คุ้นเคย HLS ในเบราว์เซอร์จะใช้ XHR หรือการดึงข้อมูลเพื่อขอไฟล์ .m3u8 และ .ts อย่างต่อเนื่องผ่าน HTTP และแสดงในองค์ประกอบวิดีโอ ฉันได้จำลองปัญหาที่ฉันอธิบายไว้ด้วยการเรียก AJAX อย่างง่ายตามช่วงเวลา ดังนั้นปัญหาจึงไม่เฉพาะเจาะจงกับ HLS ฉันต้องการสลับการรับส่งข้อมูลระหว่าง CDN และ direct-to-origin โดยมีผลกระทบต่อผู้ใช้น้อยที่สุด ฉันได้สร้างสิ่งนี้ขึ้นมาแล้ว และสามารถสลับระหว่าง CloudFront และ direct-to-origin ได้โดยเปลี่ยน DNS ใน Route 53 ระเบียน DNS มี TTL 1 นาที

อย่างไรก็ตาม เมื่อฉันทำเช่นนั้น บางครั้งที่อยู่ IP ที่ใช้โดยเบราว์เซอร์จะไม่เปลี่ยนแปลง - แม้จะผ่านไปนานหลังจาก DNS TTL แคช DNS ระดับระบบปฏิบัติการและเบราว์เซอร์แสดงที่อยู่ IP ที่คาดหวัง แต่เบราว์เซอร์ (ตามที่แสดงในเครื่องมือสำหรับนักพัฒนา -> เครือข่าย) แสดงว่ายังคงใช้ที่อยู่ IP "เก่า" สามารถทำได้ต่อเนื่องหลายชั่วโมงหลังจาก DNS TTL แม้แต่การรีเฟรชหน้าก็จะไม่บังคับให้รับ IP ใหม่สำหรับโดเมน จนถึงตอนนี้ ฉันพบเพียง chrome://net-internals/#sockets -> Flush Socket Pools หรือการปิดอินสแตนซ์ของเบราว์เซอร์ทั้งหมดโดยสมบูรณ์ บังคับให้เบราว์เซอร์รับที่อยู่ IP ใหม่สำหรับโดเมน

ดังนั้นฉันค่อนข้างแน่ใจว่าปัญหาคือ Chrome (ทดสอบ FireFox ด้วย อาจเป็นเบราว์เซอร์ทั้งหมด) รักษาการเชื่อมต่อและไม่ค้นหา DNS อีกจนกว่าการเชื่อมต่อจะปิด โดยไม่คำนึงถึง DNS TTL โดยเฉพาะอย่างยิ่งกับบางอย่างเช่น HLS วิดีโอหรือการสำรวจ ajax อย่างต่อเนื่องซึ่งมีการใช้การเชื่อมต่อทุกๆ สองสามวินาที ฉันสามารถควบคุมสิ่งนี้ได้โดยการตั้งค่า Connection:close หรือ Keep-Alive:timeout=5s ส่วนหัวที่จุดเริ่มต้น อย่างไรก็ตาม ฉันไม่สามารถควบคุมสิ่งเหล่านี้ได้ที่ CloudFront แม้จะใช้ฟังก์ชันแบบกำหนดเองก็ตาม นอกจากนี้ หากฉันเปิดใช้งาน HTTP2 ที่ต้นทางและ/หรือ CloudFront ส่วนหัวเหล่านี้จะไม่ได้รับอนุญาตหรือใช้ แต่ฉันยังคงเห็นพฤติกรรมที่คล้ายกัน

ฉันยังสามารถส่งคืน HTTP 421 Misdirected Request จากต้นทางและบังคับให้ลูกค้ากดปุ่มต้นทางเพื่อรีเฟรช อย่างไรก็ตาม สิ่งนี้ใช้ไม่ได้จาก CloudFront - การใช้ฟังก์ชัน CloudFront เพื่อแก้ไขโค้ดตอบกลับทำให้เกิดข้อผิดพลาด และ 421 ที่ส่งคืนจากต้นทางไปยัง Cloudfront ทำให้เกิดข้อผิดพลาดและไม่ทำให้ไคลเอ็นต์รีเฟรช

จากทั้งหมดนี้ ฉันจะแน่ใจได้อย่างไรว่าการเปลี่ยนแปลง DNS มีผลในเบราว์เซอร์ภายใน TTL ของรายการ DNS มีส่วนหัวหรือการตั้งค่า CloudFront ที่ฉันสามารถใช้ได้หรือไม่ ฉันสามารถควบคุมไคลเอนต์บางตัวได้ แล้วมีจาวาสคริปต์ ส่วนหัวคำขอ หรือเคล็ดลับ XHR ใดที่จะบังคับให้เบราว์เซอร์รับและใช้ TTL ใหม่หรือไม่

Patrick Mevzek avatar
cn flag
"อย่าค้นหา DNS อีกจนกว่าจะปิดการเชื่อมต่อ" เพราะอะไร DNS ถูกใช้เพื่อเปิดการเชื่อมต่อ เมื่อเปิดและยังคงเปิดอยู่ DNS ก็ไร้ประโยชน์/ไม่จำเป็น การใช้ Keep Live ด้วยวิธีนั้นจะสิ้นเปลืองทรัพยากรจำนวนมาก หากการเชื่อมต่อเปิดอยู่และเบราว์เซอร์ได้รับจากสิ่งที่ต้องการ/ร้องขอ เหตุใดจึงต้องตรวจสอบ DNS อีกครั้งและอาจเปิดการเชื่อมต่อใหม่หากที่อยู่ IP ปัจจุบันนั้นดีพอ (ตอบสนอง) ปัญหาของคุณดูเหมือนจะไม่เกี่ยวข้องกับ DNS หรือเบราว์เซอร์จริงๆ เสียด้วยซ้ำ เพียงแต่เกี่ยวกับการควบคุมที่คุณมีหรือไม่มีบนเซิร์ฟเวอร์มากกว่า
us flag
กรณีการใช้งานจริงสำหรับการสลับระหว่างเซิร์ฟเวอร์ต้นทางและ CDN คืออะไร คุณกำลังพยายามบรรลุอะไร
gr flag
@Tero กรณีการใช้งานคือเราต้องการเปลี่ยนผู้ชมจากการรับวิดีโอจาก CloudFront เป็นการรับโดยตรงจากแหล่งกำเนิดภายในองค์กรและในทางกลับกันวีซ่าอย่างรวดเร็วและราบรื่นที่สุด เราต้องการจ่ายสำหรับ CloudFront เมื่อเราคาดว่าจะโหลดสูงเท่านั้น เมื่อเราไม่ต้องการ CloudFront อีกต่อไป เราสามารถเปลี่ยน DNS เพื่อให้การเชื่อมต่อใหม่แก้ไขกลับไปยังต้นทางภายในองค์กร สิ่งนี้ได้ผล อย่างไรก็ตาม เราพบว่าการเชื่อมต่อบางอย่าง "ติด" ที่ CloudFront ผ่าน DNS TTL ไปแล้ว และจำกัดให้เหลือพฤติกรรมการเชื่อมต่อแบบถาวรนี้
gr flag
@PatrickMevzek ใช่ DNS และเบราว์เซอร์กำลังทำงานในลักษณะที่เหมาะสมระหว่างการใช้งานปกติ ฉันแค่มองหาวิธีกระตุ้นการค้นหา DNS ใหม่ทุกครั้งที่เราเปลี่ยน DNS "ทำไมต้องกังวล" คือเราต้องจ่ายเงินสำหรับ CloudFront - เราต้องการให้การรับส่งข้อมูลนั้นกลับมาจาก CloudFront และตรงไปยังต้นทางโดยเร็วที่สุด - อย่างน้อยก็ภายใน TTL ที่เราตั้งไว้สำหรับ DNS ตามที่เป็นอยู่ ทราฟฟิกสามารถ "ติด" ที่ CloudFront ผ่าน DNS TTL ไปแล้ว - ฉันวัดผล 4+ ชั่วโมงในการทดสอบบางอย่าง
us flag
ตัวเลือกเดียวของคุณน่าจะมองหา CDN อื่น ๆ ที่คุณสามารถใช้รหัสสถานะ `421` ได้อย่างถูกต้อง หรือถาม AWS ว่าสามารถเปลี่ยนการใช้งานได้หรือไม่ เบราว์เซอร์ทำงานในแบบที่พวกเขาทำ และคุณไม่สามารถเปลี่ยนพฤติกรรมของพวกเขาได้จริงๆ

โพสต์คำตอบ

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