DNS Round Robin: Apakah browser tetap menggunakan satu IP selama masih online?


14

Bagaimana sebagian besar peramban berperilaku jika mereka mendapatkan beberapa A-record dari server DNS? Apakah menempel pada satu IP selama itu dapat dijangkau (dan hanya menggunakan yang lain jika IP turun)? Atau apakah mereka beralih sepanjang waktu tanpa alasan?

Jika mayoritas browser saat ini menempel satu IP, DNS-RR akan cukup bagi saya sebagai solusi failover sederhana.


1
Saya tidak dapat menjawab pertanyaan Anda secara langsung, tetapi saya akan menunjukkan kepada Anda bahwa Anda harus berurusan dengan caching di tingkat browser dan OS! Selamat bersenang-senang :)
SpacemanSpiff


1
@Iain - Tautan luar biasa
SpacemanSpiff

Berapa banyak mesin yang Anda miliki untuk backend? Jika 2 mesin dengan aktif-pasif baik-baik saja, dapatkan alamat IP ketiga, dan gunakan detak jantung untuk mematikannya di antara mesin fisik. Atau, saya pikir ultramonkey mendukung penugasan ke backend berdasarkan sumber IP, yang hampir sama dengan satu klien. Anda mungkin juga bisa meretas sesuatu bersama-sama dengan meminta setiap backend menetapkan cookie unik, dan memiliki proxy server web frontend ke backend tergantung pada cookie. (Apache mod_rewrite mungkin bisa melakukannya.)
jon

Tidak ada aturan tunggal yang mencakup semua browser, jadi setidaknya Anda harus menentukan yang mana / yang Anda minati.
John Gardeniers

Jawaban:


7

Setiap browser memiliki metode sendiri dalam menangani round-robin DNS, saya telah menghabiskan waktu hari ini untuk meneliti masalah ini dan akan terus memperbarui jawaban saya karena saya menemukan bukti implementasi yang akan membatasi jawaban saya ke browser yang mengekspos perilaku mereka.

Google Chrome

Google Chrome (digunakan v58) akan meminta semua entri host untuk alamat (A, AAAA, CNAME) dan memasukkannya ke dalam array ( address_list ). Chrome kemudian akan mencoba untuk membuka soket pada setiap alamat IP dalam urutan dari pertama hingga terakhir, chrome tidak akan mencoba IP tercepat atau terdekat, mengasumsikan IP pertama (diberikan oleh resolver dns hulu Anda) adalah IP terbaik. Dalam tes saya mengikat dan windows dns server memberikan urutan IP yang berbeda per pencarian, memberikan apa yang tampak seperti 50/50 membagi bandwidth untuk setiap IP. Fungsi ini terbuka dichrome://net-internals/#events&q=type:SOCKET%20is:active

Curl (libcurl / 7.54.0)

Curl juga memiliki fungsi fail-over ini tetapi --connect-timeout jauh lebih lama daripada default di chrome, chrome gagal segera, Curl tidak. Jika Anda menggunakan libcurl dan ingin selamat dari contoh round-robin dns di mana satu IP gagal, (berfungsi dalam chrome tetapi tidak dalam kode) pastikan untuk menentukan nilai ini lebih rendah.

DEFAULT_CONNECT_TIMEOUT: 0 membuat saya berpikir ini tidak mungkin dengan curl.

* After 149990ms connect time, move on!

Di kedua browser , IP tidak lengket , mereka mengikuti TTL yang diberikan dalam DNS dan begitu ttl kedaluwarsa (chrome mempertahankan ini secara internal, curl bertanya pada setiap permintaan), pemilihan ip dilakukan setiap kali seperti dijelaskan di atas.

Apa artinya ini? DNS-RR ok untuk beberapa sistem, tetapi tidak dirancang untuk failover. Anda harus mengharapkan bahwa semua hasil dari pencarian DNS (sumber kebenaran) valid dan tersedia untuk melayani lalu lintas. Ada banyak cara untuk memastikan ketersediaan IP, seperti IP float virtual, BGP / Trik perutean, dll. Gunakan mereka .

Semua tes yang dilakukan di lingkungan IPv4 saja, akan kembali dengan hasil tumpukan ganda begitu infrastruktur tersedia untuk diuji.

Saya berspekulasi bahwa perubahan ini adalah efek samping dari IPv6-Fallback RFC Happy Eyeballs

Perbarui Pertimbangan yang bermanfaat, RR DNS hanya dapat membantu dengan load balancing, bukan kegagalan aplikasi, jika salah satu node Anda memiliki 503 Anda akan melayani 40-60% jika lalu lintas Anda 503s. Asumsi dibuat bahwa semua IP yang terdaftar adalah titik akhir kerja yang valid jika dapat dijangkau


2

sunting: Mengedit jawaban saya sejak HiPerFreak menyekolahkan saya.

Server DNS akan mengembalikan daftar semua catatan A yang dimilikinya untuk nama host yang diberikan. Di mana round robin masuk adalah bahwa itu berputar bagaimana daftar itu dipesan. Tautan yang diposkan itu adalah contoh yang bagus tentang bagaimana browser web akan menggunakan daftar itu.

Round Robinning dapat digunakan untuk bentuk penyeimbangan beban yang sangat primitif, tetapi merupakan pengganti yang sangat buruk untuk penyeimbangan beban nyata, karena jika salah satu host dalam rotasi round robin turun, server DNS akan menjadi lebih bijak dan akan tetap letakkan alamat IP dari simpul yang jatuh dalam daftar.


Server DNS selalu membagikan SEMUA alamat. Browser adalah satu-satunya, yang memutuskan mana yang akan digunakan (seperti dibahas berkali-kali di sini dan di tempat lain). Juga, OS meneruskan semua IP ke browser.
HiPerFreak

2
@HiPerFreak Konfigurasi yang sering dilihat (terutama untuk sejumlah besar A-Records) adalah bahwa DNS membagikan beberapa alamat (walaupun tidak semua, biasanya untuk memastikan mereka masuk ke paket UDP 512 byte dan tidak menimbulkan overhead yang tidak perlu) , biasanya dalam urutan yang berubah.
the-wabbit

Saya sedang memikirkan 2 atau 3 IP.
HiPerFreak

@HiPerFreak: Saya hanya ingin mengatakan bahwa Anda benar bahwa server DNS tidak membagikan semua catatan A ketika ditanya nama jika ada beberapa catatan A untuk nama itu. Saya memiliki server DNS dan baru saja melakukan pengambilan paket dengan Wireshark sementara saya melakukan ping pada nama host untuk mengonfirmasi. Terima kasih - saya belajar sesuatu hari ini! :)
Ryan Ries

2

Lihat ini pertanyaan saya (dan jawab): Bagaimana browser menangani banyak IP .

Robin dns putaran pendek tidak meningkatkan ketersediaan sama sekali. Browser memilih satu IP dan tetap menggunakannya, bahkan jika tidak merespons. (Diperiksa dengan FF dan chrome).

Setelah cache dns browser kedaluwarsa, nama host diselesaikan lagi dan proses diulangi, terlepas dari apakah IP menjawab atau tidak.

Untuk HA dasar, Anda dapat menggunakan DNS dinamis atau berbagai pendekatan berbasis IP.

EDIT: Perilaku ini akan terjadi ketika host yang tidak dapat diakses bertindak sebagai "lubang hitam". Jika tuan rumah sebaliknya menolak koneksi masuk, browser akan mencoba satu ip, mendapatkan penolakan dan segera menggunakan ip lain dan dengan demikian ia akan gagal dengan cukup baik.


2
Mungkin ini berubah dalam beberapa tahun terakhir, tetapi saya dapat mengonfirmasi bahwa pada beberapa pembaruan di Firefox, IP sebenarnya berubah, meskipun tidak terlalu sering. Mungkin jawaban ini kedaluwarsa?
Yeti

Penelitian saya (mulai 2015) adalah Chrome, Firefox, dan MSIE TIDAK berperilaku seperti yang dijelaskan oleh Sandman4. MSIE sangat berbeda karena membutuhkan waktu tunggu TCP penuh sebelum mencoba koneksi ke alamat berikutnya yang terdaftar jika yang pertama gagal.
symcbean

0

Mereka mengganti IP, itu bukan solusi failover.

Browser membiarkan OS untuk melakukan resolusi nama, dan untuk memeriksa Linux selalu mengacak alamat IP, coba host google.com beberapa kali. IP akan datang secara acak.


Mengapa mereka melakukan ini secara acak dan tanpa alasan? Tidakkah masuk akal untuk menggunakan kembali IP tahu-bekerja selama masih berjalan?
HiPerFreak

1
Ini untuk menyeimbangkan beban.
Batu


@HiPerFreak: Alasan mengapa tidak melekat pada IP yang dikenal bekerja adalah bahwa resolusi nama tidak tahu apa-apa tentang apakah IP itu berfungsi sekarang atau sudah di masa lalu. Browser tidak menempel pada satu IP, karena resolusi nama mengatakan itu untuk menggunakan IP yang berbeda. :-)
Sean Reifschneider

@Sean: Seperti yang dibahas dalam jawaban cepat, resolusi nama memberikan browser SEMUA IP dan browser memutuskan, mana yang akan digunakan. Dan browser tahu IP mana yang bekerja dan mana yang tidak. Jadi ini bukan alasannya.
HiPerFreak

0

DNS mengembalikan semua IP dalam daftar tetapi mereka mengubah urutan daftar dan urutan ini tidak acak atau berubah ketika 1 gagal tetapi mereka selalu mengembalikan IP dalam urutan yang sama untuk alasan penyeimbangan beban. Ketika browser menerima daftar, saya kira itu memilih 1 dalam daftar jika tidak dikenal sebagai tidak berfungsi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.