Pada dasarnya: browser menyertakan nama domain dalam permintaan HTTP, sehingga server web tahu domain mana yang diminta dan dapat meresponsnya.
Permintaan HTTP
Begini cara permintaan HTTP tipikal Anda terjadi:
Pengguna menyediakan URL, dalam formulir http://host:port/path
.
Browser mengekstrak bagian host (domain) dari URL dan menerjemahkannya ke alamat IP jika perlu, dalam proses yang dikenal sebagai resolusi nama . Terjemahan ini dapat terjadi melalui DNS, tetapi tidak harus (misalnya, hosts
file lokal pada OS umum melewati DNS).
Browser membuka koneksi TCP ke port yang ditentukan, atau default ke port 80, pada alamat IP itu.
Browser mengirim permintaan HTTP. Untuk HTTP / 1.1, tampilannya seperti ini:
GET /path HTTP/1.1
Host: example.com
( Host
Header adalah standar dan diperlukan dalam HTTP / 1.1. Itu tidak ditentukan dalam spesifikasi HTTP / 1.0, tetapi beberapa server tetap mendukungnya.)
Dari sini, server web memiliki beberapa informasi yang dapat digunakan untuk memutuskan apa yang seharusnya menjadi respons. Perhatikan bahwa dimungkinkan untuk satu server web terikat ke beberapa alamat IP.
- Alamat IP yang diminta, dari soket TCP
- Alamat IP klien juga tersedia, tetapi ini jarang digunakan - terkadang untuk memblokir / memfilter
- Port yang diminta, dari soket TCP
- Nama host yang diminta, seperti yang ditentukan dalam
Host
header oleh browser dalam permintaan HTTP.
- Jalur yang diminta
- Header lainnya (cookie, dll.)
Seperti yang Anda perhatikan, pengaturan hosting bersama yang paling umum akhir-akhir ini menempatkan banyak situs web pada satu alamat IP: kombinasi port, hanya menyisakan Host
perbedaan antara situs web.
Ini dikenal sebagai Host Virtual Berbasis-Nama di Apache-land, sementara Nginx menyebut mereka Nama Server di Blok Server dan IIS lebih suka Server Virtual .
Bagaimana dengan HTTPS?
HTTPS sedikit berbeda. Semuanya identik dengan pembentukan koneksi TCP, tetapi setelah itu terowongan TLS terenkripsi harus dibuat. Tujuannya adalah untuk tidak membocorkan informasi tentang permintaan tersebut.
Untuk memverifikasi bahwa server benar-benar memiliki domain ini, server harus mengirim sertifikat yang ditandatangani oleh pihak ketiga yang tepercaya. Browser kemudian akan membandingkan sertifikat ini dengan domain yang diminta.
Ini menimbulkan masalah. Bagaimana server mengetahui sertifikat host (situs web) mana yang akan dikirim, jika perlu melakukan ini sebelum permintaan HTTP diterima?
Secara tradisional, ini diselesaikan dengan memiliki alamat IP khusus (atau port) untuk setiap situs web yang membutuhkan HTTPS. Jelas, ini menjadi bermasalah ketika kita mulai kehabisan alamat IPv4.
Masukkan SNI (Indikasi Nama Server). Browser sekarang melewati nama host selama negosiasi TLS, sehingga server memiliki info ini cukup awal untuk mengirim sertifikat yang benar. Di sisi server, konfigurasi sangat mirip dengan bagaimana virtual host HTTP dikonfigurasikan.
Kelemahannya adalah nama host sekarang disahkan sebagai teks biasa sebelum enkripsi, dan pada dasarnya adalah informasi yang dibocorkan. Ini biasanya dianggap sebagai tradeoff yang dapat diterima, mengingat nama host biasanya diekspos dalam permintaan DNS.
Bagaimana jika Anda meminta situs hanya dengan alamat IP?
Apa yang dilakukan server ketika tidak tahu host spesifik mana yang Anda minta tergantung pada implementasi dan konfigurasi server. Biasanya, ada situs "default", "catchall" atau "fallback" yang ditentukan yang akan memberikan respons terhadap semua permintaan yang tidak secara spesifik menentukan host.
Situs default ini dapat berupa situs independennya sendiri (sering menampilkan pesan kesalahan), atau bisa juga situs lain di server, tergantung pada preferensi admin server.
Host:
header. Dalam hal hosting bersama, server web dapat dikonfigurasikan oleh penyedia untuk menangani ini dengan cara yang berbeda (misalnya memiliki default, mengarahkan ulang ke penyedia, dll.).