înregistrare Logare
Puncte:0
avatar Server

Cum mă pot asigura că modificările DNS au efect în TTL, chiar și atunci când browserul reutiliza conexiunile HTTP?

drapel gr
Daniel

Ajut la implementarea CloudFront CDN pentru o origine video NGINX HLS. Dacă nu sunteți familiarizat, HLS în browser folosește doar XHR sau preluare pentru a solicita în mod constant fișiere .m3u8 și .ts prin HTTP și pentru a le afișa într-un element video. Am replicat problema pe care o descriu cu apeluri simple AJAX la un interval, deci problema nu este specifică HLS. Aș dori să pot comuta traficul între CDN și direct la origine, cu un impact minim asupra utilizatorilor. Am construit acest lucru și pot comuta între CloudFront și direct la origine, schimbând DNS-ul în Route 53. Înregistrarea DNS are un TTL de 1 minut

Cu toate acestea, când fac acest lucru, uneori adresa IP folosită de browser nu se schimbă - chiar și la mult timp după DNS TTL. Cache-ul DNS la nivel de sistem de operare și browser arată adresa IP așteptată, dar browserul (așa cum se arată în Instrumente pentru dezvoltatori -> Rețea) arată că încă folosește adresa IP „veche”. Poate continua să facă acest lucru timp de câteva ore după DNS TTL. Nici măcar reîmprospătarea paginii nu o va forța să obțină un nou IP pentru domeniu. Până acum, am găsit doar chrome://net-internals/#sockets -> Flush Socket Pools sau închiderea completă a tuturor instanțelor browserului forțează browserul să obțină o nouă adresă IP pentru domeniu.

Deci, sunt destul de sigur că problema este că Chrome (a testat și FireFox, probabil toate browserele), menține o conexiune și nu mai caută DNS până când conexiunea este închisă, indiferent de DNS TTL, mai ales cu ceva de genul HLS video sau un sondaj ajax continuu în care conexiunea este utilizată la fiecare câteva secunde. Pot controla oarecum acest lucru setând anteturile Connection:close sau Keep-Alive:timeout=5s la origine. Cu toate acestea, nu le pot controla la CloudFront, chiar și cu o funcție personalizată. Mai mult, dacă activez HTTP2 la origine și/sau CloudFront, aceste anteturi nu sunt permise sau utilizate, dar încă văd un comportament similar.

De asemenea, pot returna o solicitare HTTP 421 greșit direcționată de la origine și pot forța clienții care lovesc originea să se reîmprospăteze. Cu toate acestea, acest lucru nu funcționează de la CloudFront - utilizarea unei funcții CloudFront pentru a modifica codul de răspuns provoacă o eroare, iar un 421 returnat de la origine la Cloudfront provoacă o eroare și nu determină reîmprospătarea clienților.

Având în vedere toate acestea, cum mă pot asigura că modificările DNS au efect în browser în cadrul TTL al intrării DNS? Există vreo setare antet sau CloudFront pe care să le pot folosi? Pot controla unii dintre clienți, așa că există vreun truc javascript, antet de solicitare sau XHR pentru a forța browserul să obțină și să utilizeze noul TTL?

148
0 + 0
Patrick Mevzek avatar
drapel cn
Patrick Mevzek
„Nu căutați din nou DNS până când conexiunea este închisă” De ce ar trebui? DNS-ul este folosit doar pentru a deschide conexiunea, odată ce este deschis și rămâne deschis, DNS-ul este inutil/nu este necesar. Implementarea unui menținere în viață în acest fel ar irosi o mulțime de resurse. Dacă conexiunea este deschisă și browserul primește de la ea ceea ce are nevoie/a solicitat, de ce ar trebui să se deranjeze să consulte din nou DNS-ul și, eventual, să deschidă o nouă conexiune dacă adresa IP actuală este suficient de bună (răspunde)? Problema dvs. nu pare legată cu adevărat de DNS sau browsere, ci mai mult în jurul controlului pe care îl aveți sau nu pe server
0
Răspunde
drapel us
Tero Kilkanen
Care este cazul real de utilizare pentru comutarea între serverul de origine și CDN? Ce încerci să obții?
0
Răspunde
drapel gr
Daniel
@Tero Cazul de utilizare este că dorim să putem schimba spectatorii de la obținerea de videoclipuri de la CloudFront la obținerea directă de la origine locală și invers, cât mai repede și fără probleme. Vrem să plătim pentru CloudFront doar atunci când ne așteptăm la o sarcină mare. Când nu mai dorim CloudFront, putem schimba DNS, astfel încât noile conexiuni să se rezolve înapoi la originea locală. Acest lucru funcționează. Cu toate acestea, constatăm că unele conexiuni „lipsesc” la CloudFront cu mult peste TTL DNS și l-au restrâns la acest comportament persistent de conexiune.
0
Răspunde
drapel gr
Daniel
@PatrickMevzek Da, DNS și browserul se comportă într-un mod care are sens în timpul utilizării normale. Caut doar o modalitate de a declanșa o nouă căutare DNS ori de câte ori schimbăm DNS. „De ce ar trebui să deranjeze” este că trebuie să plătim pentru CloudFront - vrem ca traficul să se întoarcă de la CloudFront și să meargă direct la origine cât mai repede posibil - cel puțin în cadrul TTL pe care l-am stabilit pentru DNS. Așa cum este, traficul se poate „lipi” la CloudFront cu mult peste DNS TTL - am măsurat peste 4 ore în unele teste.
0
Răspunde
drapel us
Tero Kilkanen
Singura dvs. opțiune este probabil să caute un alt CDN unde puteți implementa corect codul de stare `421`. Sau întrebați AWS dacă își pot schimba implementarea. Browserele funcționează așa cum o fac și nu le puteți schimba cu adevărat comportamentul.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.