HTTPDNS:Praktik terbaik

Skenario: Node layanan HTTPDNS tertentu tidak tersedia

Informasi latar belakang

Dalam kasus ekstrem, seperti bencana alam, pemblokiran oleh penyedia layanan Internet (ISP), atau kegagalan jaringan, satu titik masuk layanan HTTPDNS mungkin menjadi tidak tersedia, yang dapat memengaruhi resolusi nama domain.

Solusi

1. Failover alamat IP startup

   • Sisipkan beberapa alamat IP startup atau nama domain dalam aplikasi untuk memastikan konektivitas berkelanjutan dengan HTTPDNS.

   • Jika permintaan gagal, alamat IP startup berikutnya akan digunakan secara otomatis.

2. Pembaruan dinamis daftar alamat IP layanan

   Bagan alir berikut menunjukkan cara memperoleh alamat IP layanan dengan mengirim permintaan ke alamat IP startup.

Untuk informasi selengkapnya, lihat Scheduling Service Interface.

3. Kebijakan failover

   Saat menggunakan HTTPDNS, mekanisme rotasi IP diterapkan. Jika suatu alamat IP tidak dapat dijangkau, sistem akan beralih ke alamat IP berikutnya untuk mencoba ulang, sehingga memastikan HTTPDNS tetap berfungsi meskipun satu alamat IP layanan menjadi tidak tersedia. Saat permintaan resolusi dikirim ke server, sistem mengambil alamat IP layanan yang tersedia dari daftar alamat IP layanan global. Jika resolusi menggunakan alamat IP layanan saat ini berhasil, SDK akan terus menggunakan alamat IP tersebut sepanjang lifecycle-nya. Jika resolusi menggunakan alamat IP layanan saat ini gagal, sistem beralih ke alamat IP berikutnya dalam daftar alamat IP layanan global untuk mencoba ulang. Jika percobaan ulang juga gagal, sistem mengembalikan null dan mencoba beralih ke alamat IP layanan lainnya lagi.

Jika semua alamat IP layanan HTTPDNS gagal merespons, kembali menggunakan Domain Name System (DNS) lokal, yaitu rantai DNS native dari sistem operasi. Jika Anda menggunakan OkHttp sebagai library jaringan untuk mengintegrasikan HTTPDNS pada Android, Anda dapat menggunakan kode berikut untuk melakukan resolusi menggunakan DNS lokal:

List<InetAddress> result = okhttp3.Dns.SYSTEM.lookup(host);

val result: List<InetAddress> = Dns.SYSTEM.lookup(host)

Untuk iOS, hindari melakukan penggantian Host atau intersepsi permintaan, sehingga permintaan asli tetap tidak berubah:

NSMutableURLRequest *request = [[NSMutableURLRequest alloc] initWithURL:url];
// Kirim permintaan.
NSURLSession *session = [NSURLSession sharedSession];
NSURLSessionDataTask *task = [session dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
    if (error) {
        NSLog(@"error: %@", error);
    } else {
        NSLog(@"response: %@", response);
    }
}];
[task resume];

var request = URLRequest(url: url)
// Kirim permintaan.
let session = URLSession.shared
let task = session.dataTask(with: request) { (data, response, error) in
    if let error = error {
        print("error: \(error)")
    } else {
        print("response: \(response?.description ??  "")")
    }
}
task.resume()

4. Resolusi non-blocking

   Gunakan metode asinkron dalam aplikasi Anda untuk mengakses HTTPDNS. Dengan demikian, bisnis Anda tidak perlu terganggu menunggu hasil resolusi.

Skenario: Bottleneck performa akibat kueri yang sering

Informasi latar belakang

Jika permintaan ke HTTPDNS dilakukan untuk resolusi nama domain pada setiap permintaan jaringan, latensi bisnis dan konsumsi bandwidth akan meningkat secara signifikan. Mengingat bahwa hasil resolusi nama domain memiliki nilai cache time to live (TTL), Anda dapat menerapkan caching berdasarkan nilai tersebut.

Solusi

1. Cache lokal

   • Sesuai standar DNS RFC 1034, hasil resolusi dapat di-cache berdasarkan nilai TTL.

2. Pre-resolving

2. Penggunaan koneksi ulang

   Anda dapat mengaktifkan fitur penggunaan koneksi ulang dari client HTTP untuk mengurangi waktu yang diperlukan dalam membuat koneksi TCP dan menurunkan latensi resolusi HTTPDNS.

3. Caching persisten

   Anda dapat menyimpan hasil resolusi secara persisten yang diperoleh sebelumnya. Setelah aplikasi dimulai ulang, hasil resolusi akan diprioritaskan dimuat dari lapisan persistensi. Hal ini meningkatkan kecepatan pemuatan pertama.

Skenario: Latensi akses akibat resolusi lintas ISP

Informasi latar belakang

Saat Anda menggunakan nama domain akselerasi CDN atau nama domain yang dikonfigurasi dengan resolusi routing cerdas, jika client menyimpan cache alamat IP yang diperoleh dari resolusi DNS berdasarkan nilai TTL, masalah dapat muncul ketika lingkungan jaringan berubah. Misalnya, jaringan 4G berubah menjadi Wi-Fi atau sebaliknya. Dalam kasus seperti itu, alamat IP yang di-cache mungkin tidak lagi sesuai dengan rute optimal untuk lingkungan jaringan baru, yang berpotensi menyebabkan degradasi performa pada permintaan jaringan terkait bisnis.

Solusi

1. Pemantauan lingkungan jaringan

   • Pantau perubahan jaringan client, misalnya dari Wi-Fi ke data seluler.

   • Secara proaktif refresh cache lokal untuk memastikan hasil resolusi kompatibel dengan lingkungan jaringan saat ini.

2. Pengujian kecepatan dan pengurutan

   Gunakan pengujian asinkron ICMP atau TCP untuk mengurutkan hasil resolusi dan memprioritaskan alamat IP dengan waktu respons tercepat.

Skenario: Permintaan resolusi dibajak atau bocor

Informasi latar belakang

API resolusi tanpa mekanisme autentikasi menimbulkan risiko keamanan, karena dapat dieksploitasi pihak ketiga untuk mencuri traffic dan menimbulkan biaya.

Solusi

1. Resolusi dengan autentikasi

   Kami menyarankan Anda menggunakan Operasi API dengan autentikasi untuk melakukan resolusi nama domain. Anda dapat memilih apakah akan menonaktifkan Operasi API tanpa autentikasi di Konsol HTTPDNS.

   • Saat Anda memanggil operasi ini untuk melakukan resolusi nama domain, HTTPDNS menggunakan kunci rahasia untuk menghasilkan string terenkripsi dan menyertakan string tersebut dalam permintaan untuk autentikasi. Kunci rahasia tidak disertakan dalam permintaan, sehingga mengurangi risiko eksposur dan menjamin keamanan permintaan resolusi.

   • Untuk informasi selengkapnya, lihat Implement authenticated access.

2. Gunakan HTTPS untuk komunikasi aman

   • Jika Anda menggunakan protokol HTTPS, verifikasi sertifikat kustom diperlukan. Verifikasi harus dikonfigurasi untuk mengarah ke 203.107.1.1 atau resolvers-cn.httpdns.aliyuncs.com.

   • Untuk informasi implementasi di Android, lihat Best practices for using HTTPDNS with HttpURLConnection on Android.

   • Untuk skenario iOS, lihat Integrate HTTPDNS SDK for iOS.