Hikayat Sang Protokol Menuju http://www.google.com

 

Ini tulisan yang sekedar mengingatkan kepada anda semua, terutama saya (hehe), bagaimana cara komunikasi antar node bisa terjadi. Bagaimana kita bisa internet-an dan melihat web situs-situs tertentu dari browser yang tampaknya gak ribet-ribet amat… Karena pada umumnya setiap browser hanya ada inputan URL web, tombol “Go”, dan tempat display webnya tentu saja… Ternyata dibalik kesederhanaan tampilan itu, kerja para “kru-kru” dibelakang layarnya lumayan banyak loh.. Hehehe.. Mari kita jalan-jalan kebelakang panggung… Jangan di depan panggung terus dong. Ntar ga tau, ternyata jadi protokol komunikasi (saya ambil contoh TCP/IP based) itu ribet juga kerjaanya… Wongeh dwechh… 😀

Pertama-tama, kita asumsikan PC tempat kita nge-browsing adalah sbb:

Nama Host kita : ENIAC

MAC address kita : 00:1b:24:2a:3e:e0

IP address kita : 192.168.70.19

Subnetmask kita : 255.255.255.0

Default Gateway kita : 192.168.70.1

DNS Server kita : 192.168.7.2 (primary), dan 10.10.1.1 (secondary)

Website tujuan kita : http://www.google.com

Contoh Topologi Menuju Node Webserver Google
Contoh Topologi Menuju Node Webserver Google

Oke, sekarang buka browser anda… Yang “masih” pake Windows, silakan ke Start ? Program ? [Cari browser favorit Anda]. Contoh browser yaitu: Mozilla Firefox, Google Chrome, Opera, Sea Monkey, Safari, Microsoft Internet Explorer, Lynx, dan masih banyak lagi… tapi yang saya sebutin ini yang saya tau tentu saja… hehe…

Di browser cari inputan tempat masukin URL.. biasanya di atas (hihihi.. segitunya saya.. sampe ngasi tau segala..). Ketikkan di input URL tersebut: “http://www.google.com” atau jika browser anda termasuk golongan browser yang pinter, biasanya anda cukup memasukkan “google.com” dan nanti browser anda sendiri yang menambahkan prefix protokol “http://” dan subdomain (third level domain) “www” jika diperlukan…

Oke, udah? Sekarang klik tombol “Go” nya… atau klo browser anda sudah rada canggih, tekan aja tombol “ENTER” (hahahah..) Tunggu beberapa saat…. Nah, nongol dweh tu tampilan website di domain google.com ‘kan???

Udah deh…. (Lah?? Cuman gitu? Nenek saya juga bisa…) Segitu simple kan menggunakan browser? Tapi bukan ini yang kita bahas.. Yang kita bahas adalah “ilmu”nya… atau kesibukan protokol-protokol di belakang layarnya! Oke??! Kita bahas satu-satu deh:

  1. Anda dilangkah pertama tadi ‘kan buka aplikasi browser.. hehehehe… 😀
  2. Sementara itu, sebenarnya ketika anda tersambung ke jaringan, tanpa anda sadari ada ARP, protokol TCP/IP pada layer 2 host ENIAC kita ini, yang melakukan request sekaligus broadcast ARP ke node yang lain. Isinya antara lain berkata: “Hoy semua, gue punya IP 192.168.70.19 dengan alamat MAC 00:1b:24:2a:3e:e0. Save yaa… Gue minta juga punya kalian… Bales yaa…
  3. Broadcast dan balasan reply di-“kirim-terima”-nya via Layer 1 (layer fisik)
  4. ARP broadcast dari si ENIAC ini akan menambah ARP table pada node yang lain. Sehingga komputer yang berada pada satu jaringan bisa mengetahui alamat IP dan MAC untuk ENIAC.
  5. ARP reply akan menambah informasi untuk ENIAC, node-node yang lain dalam satu jaringannya, mempunya IP dan MAC address berapa…
  6. Anda memasukkan “http://www.google.com” ke input URL browser
  7. Browser melakukan parsing terhadap setiap inputan URL anda (dalam hal ini “http://www.google.com” menjadi “www.google.com
  8. Browser siap-siap melakukan “DNS Query” ke DNS server yang kita sudah setting… Yap, menuju ke 192.168.7.2 (primary) atau ke DNS server 10.10.1.1 (secondary) jika terjadi timed-out pas nanya ke primary DNS…
  9. Di layer aplikasi, DNS query dibuat… Paket itu isinya kalo secara manusiawi kayak gini: “Kepada: Yth. 192.168.7.2 port 53 (port DNS) | Berapakah IP untuk domain: google.com? | Hormat Saya: 192.168.70.19. Tolong balas ke IP saya ini…”.
  10. Sampai tahap ini, jika browser anda menggunakan Mozilla Firefox, di status bar akan muncul tulisan “Looking up www.google.com
  11. Di kirim ke layer transport. UDP yang akan dipake… Port asal yang akan menerima hasil query nama domain ini, katakanlah port 1031 (ini akan berbeda-beda di setiap kesempatan. Karena port asal client random) dan port tujuan kita adalah 53 (well-known port, untuk DNS Server).
  12. Di layer network, header paket dibaca alamat asal dan tujuannya.
  13. Host ENIAC membaca konfigurasi dirinya… Mulai dari IP addressnya berapa, subnetmask nya, default gatewaynya, sampe alamat IP DNS Server nya…
  14. Didapatkan: IP address gue adalah 192.168.70.19 cuy… Gua berada di jaringan 192.168.70.X (didapatkan dengan cara meng-“AND”-kan dengan subnetmask)… Kalo ada yang nanya ke gue, IP yang lain dari format 192.168.70.X itu, gue serahin ke gateway gue di 192.168.70.1… Lah, alamat tujuan paket ini 192.168.7.2… (perhatikan dengan seksama… itu angka 7.. bukan 70… berarti beda jaringan dengan 192.168.70.X kan?!). Oke, berarti paket ini harus gue lewatin gateway… Tujuannya ternyata gak se-Jaringan sama gue…. (eh, bentar… yang ngomong Gue-Elu tuh komputer ENIAC yak! Hehe)
  15. Dikirim ke layer 2. Di layer ini, ditambahkan informasi di header paket alamat MAC address ENIAC, dan alamat MAC address tujuan ENIAC (alamat tujuan MAC gateway ya!! BUKAN alamat tujuan MAC DNS Server tujuan asli kita! Soalnya beda jaringan…). Paket dan header baru ini digabungkan. Gabungan dua makhluk ini (hihi) disebut dengan “Frame”
  16. Di kirim frame itu secara fisik dari MAC address kita menuju sebuah switch di jaringan kita.
  17. Frame dikirim melalui medium (Layer 1) ke switch
  18. Switch menerima frame dari MAC address kita. Tujuan MAC address nya juga dibaca.
  19. Sebelumnya, ARP sudah mengupdate informasi untuk switch kan? (Baca lagi langkah nomer 2 di atas… Ketika si ENIAC kita ini baru terkoneksi secara fisik dengan jaringan…)
  20. Switch melihat MAC tujuan. Kemudian mengirimkan paket melalui port switch yang sesuai dengan alamat MAC tujuannya. (Beda dengan HUB kan? Kalo hub gimana hayooo??)
  21. Frame diterima router. Router mengekstrak header frame yang isinya alamat MAC dari ENIAC itu… Terus membaca header untuk layer 3 spesialisnya dia… Didapatkan alamat IP tujuan adalah 192.168.7.2. Di proses dengan subnetmask router, dibaca di routing table, adakah interface yang menuju LANGSUNG ke jaringan 192.168.7.X, kalo ga ada, dilewatin lagi default gateway router
  22. Untuk diketahui, router juga melakukan ARP broadcast & reply di setiap interfacenya. Kalo router kita mempunyai 3 Network-Interface, berarti ada 3 proses ntu di router…
  23. Ternyata (dalam kasus ini) IP 192.168.7.2 berada di jaringan yang sama dengan salah satu interface router… yaitu interface router yang IP addressnya 192.168.7.1.
  24. Router kemudian membuat header berisi MAC address punya si 192.168.7.1 dengan tujuan MAC address punya si 192.168.7.2 untuk pengiriman secara fisik…
  25. Frame dikirimkan secara fisik ke switch disitu… lewat layer 1…
  26. Switch melihat MAC tujuan. Kemudian mengirimkan paket melalui port switch yang sesuai dengan alamat MAC tujuannya. (Beda dengan HUB kan? Kalo hub gimana hayooo??)
  27. DNS Server Layer 2 dengan MAC tujuan menerima frame dari switch. Karena dia bukan mode promiscious, dia mencocokkan MAC addressnya dengan MAC address tujuan. Kalo sama, baru bisa diproses lanjut…
  28. DNS Server Layer 3 mengekstrak header frame, kemudian melihat alamat IP tujuan. Ternyata alamat IP tujuan adalah alamat IP dirinya.
  29. Layer 4 mengekstrak header paket menjadi satu segmen. Untuk kemudian membaca header segment berisi port tujuan yang ingin diakses paket ini. Ternyata port tujuannya adalah 53 (Domain Service)
  30. Layer 5 mengekstrak header segmen untuk melihat isi data
  31. Ternyata isinya adalah DNS query… Nanya IP untuk domain google.com…
  32. DNS Server membaca databasenya berisi nama domain dan IP domain tersebut
  33. DNS Server memberikan hasil query google.com, untuk ditujukan ke sang penanya
  34. DNS Server Layer Transport: Menggunakan UDP… Port asal 53 dan port tujuan sama dengan port penanya yang bakal nerima, yaitu 1031
  35. Layer Network membaca IP tujuan… 192.168.70.19.. Bukan di network 192.168.7.2… Oke de… mari kita serahkan ke gateway 192.168.7.1.
  36. Layer Data-link menambahkan header berisi alamat MAC address asal (192.168.7.2) dan alamat MAC address tujuan (192.168.7.1) menjadi sebuah frame. Jangan lupa alamat MAC address didapatkan berkat jasa ARP request… juga berkat kebaikan node-node yang lain melakukan ARP broadcast… Hehehe…
  37. Layer Fisik mengirim frame menuju switch
  38. Switch melihat MAC tujuan. Kemudian mengirimkan paket melalui port switch yang sesuai dengan alamat MAC tujuannya. (Beda dengan HUB kan? Kalo hub gimana hayooo??)
  39. Frame diterima router. Router mengekstrak header frame yang isinya alamat MAC dari ENIAC itu… Terus membaca header untuk layer 3 spesialisnya dia… Didapatkan alamat IP tujuan adalah 192.168.70.19. Di proses dengan subnetmask router, dibaca di routing table, adakah interface yang menuju LANGSUNG ke jaringan 192.168.70.X, kalo ga ada, dilewatin lagi default gateway router
  40. Untuk diketahui, router secara periodik melakukan ARP broadcast & reply di setiap interfacenya. Kalo router kita mempunyai 3 Network-Interface, berarti ada 3 proses ntu di router…
  41. Ternyata (dalam kasus ini) IP 192.168.70.19 berada di jaringan yang sama dengan salah satu interface router… yaitu interface router yang IP addressnya 192.168.70.1.
  42. Router kemudian membuat header berisi MAC address punya si 192.168.70.1 dengan tujuan MAC address punya si 192.168.70.19 untuk pengiriman secara fisik…
  43. Frame dikirimkan secara fisik ke switch jaringan kita…
  44. Switch melihat MAC tujuan. Kemudian mengirimkan paket melalui port switch yang sesuai dengan alamat MAC tujuannya. (Beda dengan HUB kan? Kalo hub gimana hayooo??)
  45. Layer 2 menerima Frame dari layer 1 ENIAC…
  46. Layer 3 mengekstrak header frame menjadi satu paket. Kemudian header paket di baca. Ternyata paket itu betul untuk IP ENIAC…
  47. Layer 4 mengekstrak header paket menjadi satu segmen. Kemudian header segmen dibaca, di dapat port tujuan adalah 1031, dari port 53.
  48. Layer 5 mengekstrak header segmen dan melihat isi data melalui port 1031. Dalam data itu, ketika dilihat isinya sbb: “64.233.181.104”. Ini apaan hayo?? Yak, betul sekali, ini adalah IP www.google.com yang tadi ditanyain sama port 1031 kan?
  49. Sampe langkah ke-48 ini baru terpecahkan alamat google.com loh! Hahahahh…
  50. Hmm… sebenarnya, kita bisa browsing halaman web google.com dengan langsung mengetikkan alamat IP addressnya saja. Coba aja di browser ketik http://64.233.181.104/ dijamin tampilannya juga sama kayak kalo masukin http://www.google.com. Bedanya, kalo kita masukin direct IP address ke input URL browser, maka kita tidak perlu lagi step-step yang panjang sebelumnya, untuk me-resolv nama domain. Lebih efisien? Ya bisa saja lebih efisien. Tapi apakah besok anda masih ingat IP google.com itu? Saya sih mending hapalin “google.com” ketimbang “ 64.233.181.104”… Hehehehe…
  51. Inisialisasi HTTP pada layer 5 ENIAC… Isi datanya adalah “SYN”… Karena kita menggunakan TCP untuk transmisi nya. Sehingga connection-oriented. SYN berarti melakukan proses minta ijin kepada node tujuan. Kalo anda menggunakan browser Mozilla Firefox, ada tulisan “Connecting to google.com
  52. Layer 4 menerima data, dan ditambahkan di header data port asal 1032 (ini pasti ada, tapi random ‘kan…) dengan port tujuan 80 (http). Penambahan header membuat data menjadi satu segmen.
  53. Layer 3 membaca alamat tujuan “64.233.181.104”. Di proses dengan subnetmask ENIAC, ternyata alamat ini tidak sesuai dengan format 192.168.70.X. Berarti kasih ke gateway…
  54. Layer 2 mengisi MAC asal dan MAC tujuan (MAC address gateway)
  55. Layer 1 ngirim…
  56. Switch melihat MAC tujuan. Kemudian mengirimkan paket melalui port switch yang sesuai dengan alamat MAC tujuannya. (Beda dengan HUB kan? Kalo hub gimana hayooo??)
  57. Layer 1 router menerima frame dari switch
  58. Layer 2 router mengekstrak header frame dsb… dst…
  59. Layer 3 router membaca network tujuan “64.233.181.104”. Setelah itu diproses dengan subnetmask, dsb… Dicari di routing table, ternyata alamat “64.233.181.104” ga ada di routing table. Router kemudian meneruskan paket ke default gateway router (external network).
  60. Layer 2 router mengisi MAC asal (MAC address router kita) dengan MAC tujuannya (default gateway-nya router kita).
  61. Layer 1 mengirim frame secara fisik ke default gateway router. Entah itu pake Kabel UTP lagi, pake Kabel Fiber Optic, bukan kabel tapi pake Wireless HSDPA, atau apapun dahhh…. Hehe…
  62. Default gateway layer1 menerima frame dari router kita
  63. Default gateway layer 2 mengekstrak header frame, didapatkan paket tujuan
  64. Default gateway layer 3 membaca header paket. Diproses dengan subnetmask dia. Dicari di routing table, kalo alamat “64.233.181.104” ga ada di routing table diteruskan lagi ke default gatewaynya dia.. teruuuussssssssssss begitu sampai dapat…
  65. Sampai akhirnya ditemukan host “64.233.181.104” yang satu fisik dengan router tertentu di jaringan siapa… Saya juga ga tau letak persisnya dimana… Hehe.. Untuk mengetahui router-router yang kita lewati pada saat mengirimkan paket ke IP tujuan tertentu adalah dengan aplikasi “TRACEROUTE”. Pada mesin Windows anda, tinggal ke command prompt dan ketikkan di situ “tracert [iptujuan]”. Dalam hal ini, coba ketikkan: “tracert 64.233.181.104”
  66. Inget.. node yang satu fisik dengan node lainnya, pasti mengirimkan data secara fisik pake MAC address to MAC address… Kalo beda fisik (via router) baru dimanfaatkanlah IP address sebagai pengalamatannya
  67. Lah, itu baru SYN… Webserver google.com kemudian mengirim SYN/ACK untuk IP tujuan. SYN/ACK dikirimkan kalo webserver siap melayani permintaan kita… Nah, webserver bisa menolak layanan kita dengan “RST” (Reset). Kalo pake browser Mozilla Firefox, jika anda pernah browsing ke suatu site terus ada tulisan “The connection was reset“. Penyebabnya karena RST dari webserver ini… Ok?
  68. IP tujuannya ternyata adalah tidak satu jaringan dengan webserver google.com “64.X.X.X”
  69. Lewatin router-router yang lain… seterusnya sampe dapet…
  70. Akhirnya sampe ke ENIAC, dibales dengan ACK lagi ke webserver google.com
  71. Hingga akhirnya ACK sampe ke webserver google.com…
  72. Sampai sini koneksi baru tercipa loh! Webserver google.com baru “ready” untuk menerima request HTTP dari kita. Kalo anda menggunakan browser Mozilla Firefox, ada tulisan “Connected to google.com
  73. ENIAC mengirim TCP state PUSH ke “64.233.181.104”… Sesaat setelah itu mengirim command “GET / HTTP/1.1” untuk webserver di domain google.com. Sambil proses itu berlangsung, browser kita nunggu, dan kalo anda menggunakan browser Mozilla Firefox, di status bar tulisannya berubah jadi “Waiting for google.com
  74. Bla..bla..bla..
  75. Sampe ke webserver google.com, di-ekstrak-proses-ekstrak-proses teruusss sampe layer 5, diterima data dari host kita isinya adalah “GET / HTTP/1.1”
  76. HTTP Server pada layer aplikasi mengerti maksudnya. Dan memberikan balasan dengan isi data sesuai yang diminta HTTP client. Karena kita minta domain rootnya (“/”) nya berarti yang dikasih adalah halaman root directory webserver google.com itu.. Isinya misalnya sbb: “<html><body>welkom tu gugel dot kom</body></html>”. Ini akan beda lagi kalo kita mintanya adalah (misal: GET /images/logo_gugel.jpg HTTP/1.1). Maka balasan webserver adalah data file “logo_gugel.jpg” kalo ada. Kalo file itu ternyata ga ada, ada pesan error code 404 dari webserver ‘kan? 🙂
  77. Data berisi <html><body>welkom tu gugel dot kom</body></html> di arsipkan (deflate), biasanya dalam format *.gz
  78. Dikirmkan dengan IP tujuan: IP kita, port tujuan: 1032. Selama proses pengiriman paket *.gz, jika browser anda menggunakan Mozilla Firefox, di status barnya akan ada tulisan “Transferring data from google.com
  79. Bla..bla..bla..
  80. Sampe lah diterima oleh port 1032. Browser kita sudah nunggu dari tadi nih di port 1032… 🙂
  81. Pada layer 5, data dibaca ternyata isinya adalah: <html><body>welkom tu gugel dot kom</body></html>
  82. Browser membaca isi HTML secara keseluruhan. Kalo yang pake Mozilla Firefox, status barnya memunculkan tulisan “Read google.com
  83. Taaa…da… nongol lah tampilan simple tapi elegan web google.com di browser kita
  84. Sampe sini belum selesai! Ini kan koneksi TCP! Jangan melupakan webserver google.com nun jauh disana yang sudah menunggu kabar dari kita… Apakah paketnya sudah sampai atau tidak… TCP Connection Oriented ‘kan?? Hehehe…
  85. Kita kasih kabar kalo paket sudah sampai dengan mengirimkan ACK ke “64.233.181.104”… Ya ya.. mengirimkan ACK ke google.com maksudnya.. Hehehe..
  86. Terakhir kita juga harus memutus koneksi ke server. Dengan cara mengirim TCP state FIN ke webserver “64.233.181.104”
  87. Webserver membalas dengan FIN/ACK
  88. Terakhir kita membalas dengan ACK….
  89. Dan lihat tampilannya sekali lagi… Website yang simple elegan dari google.com. Status bar di browser kesayangan Mozilla Firefox juga udah berubah jadi “Done

Wah ternyata banyak juga ya langkah-langkahnya. Padahal ini udah dipotong-potong dengan asumsi saya dan Anda masih bisa mengerti. Kalo ga dipotong-potong, langkah-langkah browsing ke google.com aja bisa ratusan langkah! Yah, seperti itulah… Hehehehe… 😉

Tapi saya harap, anda membaca dengan seksama seluruh poin-poin tersebut… Biar bisa troubleshooting jika suatu saat browsing terasa lambat… Anda jadi bisa berhipotesa, node mana yang seharusnya dipersalahkan… Heheheyy…

7 thoughts on “Hikayat Sang Protokol Menuju http://www.google.com

  1. web saya kalo diakses kadang-kadang muncul pesan “The connection was reset”.
    Jadi yang masalah tempat server tempat hostingnya ya?
    Mohon petunjuknya .. 😀

    Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *