Membutuhkan jawaban yang lebih teknis untuk pertanyaan wawancara tentang bagaimana internet bekerja dari awal hingga akhir [ditutup]


13

Saya telah melakukan wawancara dengan 5 orang yang terpisah selama dua minggu terakhir dan tiga dari lima orang itu telah menanyakan pertanyaan ini kepada saya: Jelaskan apa yang terjadi antara memukul "Google.com" dan halaman yang muncul di layar. Pada dasarnya, bagaimana Internet bekerja. Saya pikir setelah tiga kali saya lebih siap jika saya mendapatkan pertanyaan ini lagi.

Saya tahu beberapa hal, tetapi saya tidak sepenuhnya yakin bahwa jawaban saya cukup baik. Pada dasarnya, saya menyebutkan bahwa server DNS menerjemahkan "google.com" menjadi alamat IP. Saya agak mengabaikan TCP / IP, kemudian berbicara tentang server web secara harfiah melayani halaman yang diminta yang dikirim kembali ke browser yang kemudian ditafsirkan oleh browser dan ditampilkan.

Seperti yang saya katakan sebelumnya, saya tidak yakin jawaban saya cukup teknis. Apa langkah-langkah yang saya tinggalkan?

Untuk apa nilainya, dua dari tiga kali berada di perusahaan yang sama dan saya dipanggil kembali untuk wawancara ketiga dengan mereka, jadi saya tidak bisa mengebomnya terlalu keras.


1
Apa sifat dari posisi yang Anda wawancarai?
smp7d

3
Jika tiga dari lima pewawancara mengajukan pertanyaan ini, saatnya bagi Anda untuk melakukan penelitian / penelitian dan mendapatkan jawaban yang baik yang menunjukkan bahwa Anda sepenuhnya memahaminya. Jika Anda dipanggil untuk wawancara ketiga di perusahaan yang sama dan Anda ditanya pertanyaan lagi, Anda akan menunjukkan bahwa Anda cukup peduli untuk menopang pengetahuan Anda, atau tidak.
Robert Harvey

1
Selain itu, saya akan mencoba mempersempit ruang lingkup pertanyaan dengan menanyakan bagian proses mana yang paling mereka minati. Mereka mungkin tidak peduli bahwa Anda tahu banyak tentang hal-hal seperti tujuh lapisan model OSI , misalnya, tetapi Anda harus tetap memiliki pengetahuan yang berfungsi.
Robert Harvey

1
Di sisi lain, mungkin jawabannya terlalu teknis. Mungkin mereka ingin melihat bagaimana Anda bisa menghubungkan informasi kepada orang-orang dengan cara non-teknis?
Matt

1
Jika pertanyaan diajukan untuk melihat seberapa baik Anda berkomunikasi, maka mungkin lebih baik untuk bertanya kembali tentang pertanyaan itu daripada hanya memberikan jawaban untuk pertanyaan yang sangat luas. Anda bisa memberikan jawaban teknis yang sangat terperinci dan menghabiskan waktu seharian untuk menjelaskannya. Saya kira itu bukan tujuan dari pertanyaan itu.
Matt

Jawaban:


29
  1. Browser Anda terlebih dahulu memiliki tampilan OS di file "host" untuk entri yang akan menerjemahkan nama domain ke alamat IP. Ini adalah fitur lawas yang diwarisi dari ARPANET, ketika dimungkinkan untuk satu file teks berisi nama yang dapat dipahami untuk setiap komputer yang dapat diakses melalui ARPANET, dan untuk setiap komputer yang terhubung dengannya memiliki salinan yang relatif baru. Dulu memiliki beberapa nilai yang tersisa di jaringan kecil komputer yang tidak memiliki NetBIOS atau protokol penamaan node yang serupa, tetapi saat ini cenderung menjadi target peretas (yang dapat menggunakannya untuk mem-bypass DNS dan mengarahkan komputer Anda ke situs mereka mengontrol) untuk memiliki penggunaan yang sah untuk komputer klien atau pengguna / pemiliknya.
  2. Dengan anggapan komputer Anda tidak memiliki entri HOSTS untuk domain ini, browser Anda mengirimkan permintaan UDP ke server DNS yang dikonfigurasikan dalam pengaturan Internet OS untuk koneksi yang digunakan, dengan mengirimkan "nama host" alias nama domain permintaan (semuanya) antara "http: //" dan tanda titik dua atau garis depan pertama yang mengikuti berikutnya; yaitu "www.google.com"). Server DNS ini biasanya milik perusahaan Anda atau Penyedia Layanan Internet lokal Anda.
    • UDP adalah singkatan dari "Universal Datagram Protocol", dan merupakan protokol "transport-layer" di kelas yang sama dengan TCP (di atas protokol IP "network-layer", di bawah protokol "application-layer" seperti HTTP, FTP, SMTP dll. ). Sementara TCP menyediakan banyak kemampuan pengecekan kesalahan dan toleransi kesalahan (menambahkan data tambahan dan dengan demikian meningkatkan biaya overhead), UDP mengambil pendekatan yang jauh lebih ringan, meningkatkan bandwidth data bersih; tradeoffnya adalah protokol tidak mendukung fitur yang tersedia dalam TCP seperti membagi data besar menjadi beberapa paket (jadi pesan harus berukuran kecil) atau mengirim kembali paket yang hilang dalam perjalanan. Ini bagus untuk pesan kecil dan sederhana (seperti DNS) dan streaming, data tipe telemetri yang tidak masalah jika satu paket hilang.
  3. Server DNS ini akan mengetahui satu dari tiga hal: bagaimana menerjemahkan nama domain secara langsung ke alamat IP (artinya itu adalah "server nama otoritatif" atau ANS untuk domain itu); alamat IP ANS atau induknya; atau nameserver induknya sendiri yang lebih mungkin untuk mengetahui cara mencapai ANS. Jika server tidak menerjemahkan permintaan itu sendiri, ia akan meneruskan permintaan baik "turun" ke ANS yang diketahui, atau "naik" ke NS induknya, dan proses ini berulang secara berulang.
    • "Rooting" dari struktur pohon ini adalah server tunggal yang tidak melakukan apa pun kecuali meneruskan permintaan yang diterimanya ke salah satu dari sejumlah "domain tingkat atas" atau server TLD. Misalnya, ada server nama ".com", yang tahu cara menemukan alamat IP dari domain ".com" di planet ini (dengan meneruskan permintaan ini ke server nama tingkat ISP). TLD ini meneruskan permintaan untuk server nama domain yang tidak dikenal oleh DNS apa pun dalam "cabang" spesifik internet milik ISP.
  4. Setelah server nama otoritatif ditemukan dan telah menerjemahkan nama domain menjadi alamat IP, alamat ini dikembalikan ke klien dan perambannya. Jika ANS tidak dapat ditemukan dalam permintaan "time to live" (TTL; jumlah maksimum kali permintaan harus diteruskan antara server, untuk menghindari siklus tak terbatas antara server yang salah konfigurasi), kesalahan dikembalikan ke klien oleh simpul di yang permintaannya "time out" (atau node yang merupakan server otoritatif untuk domain tetapi itu tidak dapat menerjemahkan awalan domain tertentu).
  5. Browser, untuk koneksi HTTP, kemudian mengirimkan permintaan "TCP SYN" ke alamat IP dan port yang ditentukan (atau port HTTP default 80) untuk membuat koneksi. Ini adalah permintaan tingkat protokol, berlapis di atas tajuk IP "tingkat jaringan", yang berisi informasi seperti port respons pilihan klien ("port sumber"), preferensi untuk komunikasi TCP seperti ukuran segmen, skala jendela , dan penggunaan fitur protokol opsional.
  6. Permintaan dialihkan pada "level tautan" (mengatur bagaimana rangkaian listrik aktual dimanipulasi untuk mengirimkan data yang terkandung pada jaringan, lapisan transportasi dan aplikasi) melalui struktur Internet; biasanya data akan melakukan perjalanan sepanjang kawat atau serat ke "Kantor Pusat" rumah atau bisnis Anda (ini disebut "last mile" dan biasanya merupakan sirkuit yang menunjukkan hambatan terbesar terhadap bandwidth) yang kurang lebih merupakan "onramp" untuk Superhighway Informasi. CO kemudian memiliki akses ke pipa bandwidth tinggi (T-carrier, SONET, dll) yang mengirimkan permintaan Anda, bersama dengan miliaran orang lain, di seluruh dunia ke CO tujuan, yang meneruskannya ke server atau jaringan tujuan.
    • "IP routing" ini bekerja dengan cara yang secara konsep sama dengan resolusi DNS; "top-tier" ISP ditugaskan seluruh jaringan IP "kelas A" (setiap alamat mungkin diberikan byte pertama yang diketahui) oleh ICANN, dan ISP lain tahu siapa yang memiliki jaringan Kelas A itu dan bagaimana cara mendapatkan data ke jaringan terdekat "depan" pintu ", menggunakan informasi dalam" tabel routing ". ISP tingkat atas ini kemudian menyewakan blok alamat, beberapa ke ISP lokal, lainnya langsung ke pengguna korporat, dan ISP dan korporasi ini memiliki router yang menggunakan alamat IP (dan tabel peruteannya sendiri) untuk menentukan apakah akan mengirim paket ke yang lain sirkuit terdekat, menyamping ke router ISP lokal lainnya, atau hingga trunk dan router tingkat tinggi.
  7. Server menerima permintaan ini (asalkan tidak ditolak pada lapisan abstraksi yang lebih rendah seperti soket atau firewall), dan jika memutuskan untuk menerima koneksi, server akan mengirimkan langkah respons permintaan "SYN-ACK", keduanya mengakui meminta dan menetapkan preferensi sendiri (termasuk preferensi klien yang dapat diakomodasi, tetapi mengubah apa pun yang tidak dapat atau tidak ditentukan).
  8. Jika klien mendukung komunikasi menggunakan opsi yang disediakan server, itu akan mengirim respons ACK, dan sekarang koneksi telah "dibuat".
  9. Browser selanjutnya mengirimkan permintaan "HTTP GET". Permintaan tersebut mencakup URI lengkap dari sumber daya yang diminta oleh browser (meskipun kami tahu kami sedang berbicara dengan www.google.com, kami mengirim string itu sebagai bagian dari permintaan sehingga server dapat, jika mau, menginterpretasikan lebih lanjut nama domain untuk mengarahkan permintaan). Permintaan ini mungkin termasuk "cookies"; data yang disimpan pada klien yang dapat diberikan ke server untuk membantu dalam memproses permintaan secara efisien dan nyaman (seperti mengidentifikasi preferensi pengguna).
  10. Server menerima permintaan GET, dan pertama-tama memutuskan apakah ingin menghormatinya (server mungkin telah mendengarkan permintaan ke port TCP 80, tetapi mengharapkan pesan dari protokol aplikasi yang berbeda seperti FTP atau VoIP; ini jarang terjadi pada port 80 tetapi lebih umum untuk jenis port lain). Kami akan menganggap itu menerimanya; server kemudian mengembalikan respons HTTP yang berisi sumber daya yang diminta (dalam hal ini, HTML untuk halaman default yang merupakan halaman pencarian Google di mana-mana). Respons juga dapat mencakup "cookie", yang diminta server untuk disimpan oleh klien (klien mungkin atau mungkin tidak melakukannya).
  11. HTML dicerna oleh browser dan ditampilkan untuk menggambar halaman di jendela browser. Sementara ini terjadi, lebih banyak permintaan HTTP GET untuk Javascript, style sheet, gambar, dan data lain yang diperlukan untuk menampilkan semua konten halaman dengan cara yang ditentukan oleh HTML dikirim oleh klien dan data yang dihasilkan disediakan oleh server.
  12. Di masa lalu, Google didasarkan pada bentuk statis; Anda mengetik apa yang ingin Anda cari ke dalam kotak teks dan menekan "Cari" (atau "Saya Merasa Beruntung"). Ketika Anda melakukan ini, permintaan HTTP POST dikirim oleh klien ke server; permintaan berisi lokasi, ditentukan oleh klien, bahwa informasi harus dikirim, dan tentu saja informasi itu sendiri. Informasi ini dicerna oleh server, yang menggunakannya untuk menemukan hasil pencarian, dan server membuat halaman dari hasil ini yang dikirimkan kepada Anda. Atau, ia dapat mengubah istilah pencarian menjadi "string kueri", dan merespons dengan "redirect"; permintaan browser untuk mengirim permintaan lain ke URI berbeda yang ditentukan dalam pesan. Browser akan melakukannya, dan kemudian server akan membangun dan mengirimkan bahwa halaman.
  13. Di zaman modern, halaman depan Google jauh lebih dinamis. Saat Anda mengetik, JavaScript yang dijalankan di sisi klien dalam browser mengirimkan apa yang Anda ketikkan ke Google di sepanjang "saluran samping" (ini menggunakan protokol yang sama untuk komunikasi, tetapi karena bukan browser itu sendiri yang mengirimkan permintaan untuk seluruh halaman , layar browser tidak dibersihkan sepenuhnya dan ditarik kembali). Untuk halaman depan, ini digunakan untuk memberikan petunjuk kueri (saran lengkapi otomatis untuk hal-hal yang mungkin Anda cari karena orang lain baru saja melakukannya); pada halaman hasil, ia melakukan hal yang sama tetapi juga dapat digunakan untuk memberikan hasil pencarian real-time dan sepenuhnya menggambar ulang halaman, tanpa memerlukan memuat halaman penuh oleh browser. Jenis-jenis trik ini termasuk dalam judul umum AJAX (Asynchronous JavaScript and XML,

Film ini , yang merupakan film yang mereka perlihatkan kepada mahasiswa baru kelas "Intro to IT" di perguruan tinggi, memiliki dasar-dasar yang diilustrasikan dalam format yang ramah dan analog. Ini tidak teknis dengan cara apa pun, tetapi memberikan gambaran konseptual yang baik dari potongan-potongan teka-teki ini.


1
Ini adalah jawaban yang baik, tetapi menyoroti banyak detail yang kebanyakan orang akan menganggap tidak perlu. (Saya tidak mengatakan Anda perlu menambahkan detail ini; Saya hanya menunjukkan bahwa ada lebih banyak hal yang terjadi daripada yang disarankan pos Anda.)
greyfade

1
Ya, Anda harus masuk ke TCP vs UDP untuk pencarian DNS. Jika TCP, Anda harus masuk ke jabat tangan TCP 3 arah. Mungkin aman untuk mengasumsikan sistem entah bagaimana memiliki server nama domain yang ditentukan (oleh DHCP atau konfigurasi jaringan sebelumnya) ....
Alan Shutko

1
@AlanShutko - Saya tidak menyebutkan jabat tangan 3-way; SYN / SYN-ACK / ACK bolak-balik. Saya tidak menyebutkan UDP meskipun itu adalah protokol utama untuk DNS.
KeithS

@KeithS, oops, kau benar, aku mencarinya saat memeriksa DNS, bukan nanti. DNS mungkin mundur ke TCP jika ada respons yang lebih besar dari 512 byte dan terpotong.
Alan Shutko

1
ANS - "Server Nama Resmi", server DNS yang memiliki pengetahuan dan tanggung jawab langsung untuk titik akhir dari nama domain tertentu. ALD salah ketik. Pos telah diedit agar lebih jelas dalam kedua hal.
KeithS

1

Meninggalkan menyebutkan cookie dan firewall akan menjadi beberapa hal yang hilang di sini. Ada sesuatu yang bisa dikatakan untuk cookie yang dikirim sehingga "Google.com" dapat mengenali pengguna dan menyajikan halaman yang mungkin berbeda untuk seseorang yang tidak masuk ke Google. Ada juga pertanyaan di mana orang mencari ini: Smartphone, tablet atau komputer biasa (laptop atau desktop)?

Saya ingin tahu apakah mungkin ada beberapa pertanyaan sampingan yang harus Anda tanyakan tetapi bukankah itu bisa menjadi faktor di sini. Ini lebih merupakan pertanyaan tentang bagaimana Web bekerja karena Internet akan sedikit lebih luas dan termasuk e-mail dan hal-hal lain yang saya pikir.


Dugaan saya adalah itu lebih merupakan tes kemampuan komunikasi Anda. Bisakah Anda mengambil pertanyaan yang agak teknis dan memecahnya sehingga teknis dan non-teknis akan memahaminya? Apa jenis pertanyaan yang akan Anda kembalikan ketika diminta untuk menjelaskan seseorang yang membawa beranda "Google.com" di peramban mereka? Apakah Anda membuat banyak asumsi atau mengajukan pertanyaan? Dalam beberapa hal saya melihat ini sebagai paralel dengan pertanyaan papan tulis di mana hal-hal dibiarkan cukup samar sehingga Anda akan mengajukan pertanyaan sehingga Anda dapat memberikan jawaban yang benar tepat atau Anda membuat asumsi dalam memberikan jawaban.


5
Pertanyaan tentang internet dalam benak saya akan lebih banyak bertanya tentang jaringan secara umum; bagaimana rute ditemukan? Apa tujuan dan makna suatu paket dan bagaimana mereka mengirimkan informasi? Bagaimana cara kerja abstraksi TCP terhadap paket dan mengapa? Tetapi pertanyaannya benar-benar kabur, mungkin menanyakan tentang HTTP, atau HTML, atau switch jaringan, atau ISP dan tulang punggung atau apa pun, mungkin ia ingin tahu bagaimana buffer frame NIC Anda dikorek dan jika OS, CPU atau NIC melakukannya ...
Jimmy Hoffa

@JimmyHoffa: Memang, ini adalah pertanyaan luas. Pewawancara yang menanyakannya mengatakannya sedemikian rupa sehingga saya yakin fokusnya ada di sisi jaringan - mulai dari permintaan halaman hingga halaman dapatkan. Ada banyak hal yang terjadi dan saya curiga mereka akan senang tidak peduli rute mana yang saya ambil selama itu cukup teknis dan saya tahu apa yang saya bicarakan.
Megacannon

1
Saya juga berpikir mereka mencari jawaban non-teknis untuk melihat seberapa baik Anda dapat mengkomunikasikan ide. Seringkali kita kehilangan hutan karena pepohonan, tidak bisa melihat gambaran luas.
Matt

@ JimmyHoffa, poin bagus. Anda mungkin harus mulai dengan alamat IP server DNS Anda dan menentukan apakah mereka berada di subnet yang sama melalui topeng bersih, dan jika demikian, menggunakan ARP untuk menemukannya. Kalau tidak, paket dikirim ke gateway.
Alan Shutko
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.