Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

HTTP Ringkas: Koneksi HTTP

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Messages
HTTP Succinctly: HTTP Web Architecture

Indonesian (Bahasa Indonesia) translation by Ilham Saputra (you can also view the original English article)

Dalam artikel terakhir kami melihat pesan HTTP dan melihat contoh perintah teks dan kode yang mengalir dari klien ke server dan kembali dalam transaksi HTTP. Namun, bagaimana informasi dalam pesan-pesan ini bergerak melalui jaringan? Ketika membuka koneksi jaringan? Ketika koneksi ditutup? Ini adalah beberapa pertanyaan yang akan dijawab artikel ini karena kami melihat HTTP dari perspektif tingkat rendah. Tetapi pertama-tama, kita perlu memahami beberapa abstraksi di bawah HTTP.


Jaringan Tur Angin Puyuh

Untuk memahami koneksi HTTP kita harus tahu sedikit tentang apa yang terjadi pada lapisan di bawah HTTP. Komunikasi jaringan, seperti banyak aplikasi, terdiri dari lapisan. Setiap lapisan dalam tumpukan komunikasi bertanggung jawab untuk sejumlah tanggung jawab yang spesifik dan terbatas.

Sebagai contoh, HTTP adalah apa yang kita sebut protokol layer aplikasi karena memungkinkan dua aplikasi untuk berkomunikasi melalui jaringan. Cukup sering salah satu aplikasi adalah browser web, dan aplikasi lainnya adalah server web seperti IIS atau Apache. Kami melihat bagaimana pesan HTTP memungkinkan browser untuk meminta sumber daya dari server. Tapi, spesifikasi HTTP tidak mengatakan apa-apa tentang bagaimana pesan benar-benar melintasi jaringan dan mencapai server-itu adalah pekerjaan protokol lapisan bawah. Sebuah pesan dari browser web harus melakukan perjalanan ke serangkaian lapisan, dan ketika itu tiba di server web, ia melakukan perjalanan melalui serangkaian lapisan untuk mencapai proses layanan web.

Figure 4: Protocol layers
Lapisan protokol

Lapisan di bawah HTTP adalah protokol lapisan transport. Hampir semua lalu lintas HTTP berjalan melalui TCP (kependekan dari Transmission Control Protocol), meskipun ini tidak diperlukan oleh HTTP. Ketika pengguna mengetikkan URL ke browser, browser terlebih dahulu mengekstrak nama host dari URL (dan nomor port, jika ada), dan membuka soket TCP dengan menentukan alamat server (berasal dari nama host) dan port (yang default ke 80).

Setelah aplikasi memiliki soket terbuka, ia dapat mulai menulis data ke soket. Satu-satunya hal yang perlu dikhawatirkan oleh browser adalah menulis pesan permintaan HTTP yang diformat dengan benar ke dalam soket. Lapisan TCP menerima data dan memastikan pesan dikirim ke server tanpa tersesat atau diduplikasi. TCP secara otomatis akan mengirim ulang informasi yang mungkin hilang dalam perjalanan, dan inilah mengapa TCP dikenal sebagai protokol yang dapat diandalkan. Selain deteksi kesalahan, TCP juga menyediakan kontrol aliran. Algoritma kontrol aliran dalam TCP akan memastikan pengirim tidak mengirim data terlalu cepat bagi penerima untuk memproses data. Kontrol aliran penting dalam dunia bervariasi jaringan dan perangkat.

Singkatnya, TCP menyediakan layanan penting untuk pengiriman pesan HTTP yang sukses, tetapi melakukannya dengan cara transparan sehingga sebagian besar aplikasi tidak perlu khawatir tentang TCP. Seperti yang ditunjukkan gambar sebelumnya, TCP hanyalah lapisan pertama di bawah HTTP. Setelah TCP pada lapisan transport datang IP sebagai protokol lapisan jaringan.

IP merupakan kependekan Internet Protocol. Sementara TCP bertanggung jawab untuk deteksi kesalahan, kontrol aliran, dan keandalan keseluruhan, IP bertanggung jawab untuk mengambil potongan informasi dan memindahkannya melalui berbagai switch, router, gateway, repeater, dan perangkat lain yang memindahkan informasi dari satu jaringan ke jaringan berikutnya dan di seluruh dunia. IP berusaha keras untuk mengirim data ke tujuan (tetapi tidak menjamin pengiriman-itu adalah pekerjaan TCP). IP membutuhkan komputer untuk memiliki alamat (alamat IP yang terkenal, contohnya adalah 208.192.32.40). IP juga bertanggung jawab untuk memecah data menjadi paket (sering disebut datagrams), dan terkadang mem-fragmen dan merakit kembali paket-paket ini sehingga mereka dioptimalkan untuk segmen jaringan tertentu.

Semua yang telah kita bicarakan sejauh ini terjadi di dalam komputer, tetapi pada akhirnya paket-paket IP ini harus melakukan perjalanan melalui selembar kawat, kabel serat optik, jaringan nirkabel, atau tautan satelit. Ini adalah tanggung jawab lapisan data link. Pilihan umum teknologi saat ini adalah Ethernet. Pada tingkat ini, paket data menjadi bingkai, dan protokol tingkat rendah seperti Ethernet difokuskan pada 1s, 0s, dan sinyal listrik.

Akhirnya sinyal mencapai server dan masuk melalui kartu jaringan di mana prosesnya dibalik. Lapisan data link memberikan paket ke lapisan IP, yang menyerahkan data ke TCP, yang dapat mengumpulkan kembali data ke pesan HTTP asli yang dikirim oleh klien dan mendorongnya ke dalam proses server web. Ini adalah karya yang dirancang dengan sangat baik, semua dimungkinkan oleh standar.


Permintaan HTTP Cepat Dengan Soket dan C#

Jika Anda bertanya-tanya apa yang tampak seperti menulis aplikasi yang akan membuat permintaan HTTP, maka kode C# berikut adalah contoh sederhana tentang bagaimana tampilan kode tersebut. Kode ini tidak memiliki penanganan kesalahan, dan mencoba menulis respons server apa pun ke jendela konsol (jadi Anda harus meminta sumber daya teks), tetapi berfungsi untuk permintaan sederhana. Salinan contoh kode berikut ini tersedia dari https://bitbucket.org/syncfusion/http-succafly. Contoh nama adalah sockets-sample.

Perhatikan bagaimana program perlu mencari alamat server (menggunakan Dns.GetHostEntry), dan merumuskan pesan HTTP yang tepat dengan operator GET dan header Host. Bagian jaringan yang sebenarnya cukup mudah, karena implementasi soket dan TCP menangani sebagian besar pekerjaan. TCP memahami, misalnya, bagaimana mengelola beberapa koneksi ke server yang sama (mereka semua akan menerima nomor port yang berbeda secara lokal). Karena ini, dua permintaan yang luar biasa ke server yang sama tidak akan membingungkan dan menerima data yang ditujukan untuk yang lain.


Jaringan dan Wireshark

Jika Anda ingin beberapa visibilitas ke TCP dan IP Anda dapat menginstal program gratis seperti Wireshark (tersedia untuk OSX dan Windows dari wireshark.org). Wireshark adalah penganalisis jaringan yang dapat menunjukkan kepada Anda setiap bit informasi yang mengalir melalui antarmuka jaringan Anda. Menggunakan Wireshark Anda dapat mengamati handshake TCP, yang merupakan pesan TCP yang diperlukan untuk membuat koneksi antara klien dan server sebelum pesan HTTP yang sebenarnya mulai mengalir. Anda juga dapat melihat TCP dan IP header (masing-masing 20 byte) pada setiap pesan. Gambar berikut menunjukkan dua langkah terakhir dari handshake, diikuti oleh permintaan GET dan pengalihan 304.

Figure 5: Using Wireshark
Menggunakan Wireshark

Dengan Wireshark, Anda dapat melihat ketika koneksi HTTP dibuat dan ditutup. Bagian penting untuk mengambil dari semua ini bukanlah bagaimana handshake dan TCP bekerja pada level terendah, tetapi HTTP hampir sepenuhnya mengandalkan TCP untuk menangani semua kerja keras dan TCP melibatkan beberapa overhead, seperti handshake. Dengan demikian, karakteristik kinerja HTTP juga bergantung pada karakteristik kinerja TCP, dan ini adalah topik untuk bagian selanjutnya.


HTTP, TCP, dan Evolusi Web

Pada masa yang sangat tua di web, sebagian besar sumber daya adalah tekstual. Anda dapat meminta dokumen dari server web, pergi dan membaca selama lima menit, lalu minta dokumen lain. Dunia ini sederhana.

Untuk web saat ini, sebagian besar laman web memerlukan lebih dari satu sumber daya untuk sepenuhnya dirender. Setiap halaman dalam aplikasi web memiliki satu atau lebih gambar, satu atau lebih file JavaScript, dan satu atau lebih file CSS. Ini tidak biasa untuk permintaan awal untuk halaman rumah untuk menghasilkan 30 atau 50 permintaan tambahan untuk mengambil semua sumber daya lain yang terkait dengan halaman.

Di masa lalu itu juga sederhana untuk browser untuk membuat koneksi dengan server, mengirim permintaan, menerima respon, dan menutup koneksi. Jika browser web hari ini membuka koneksi satu per satu, dan menunggu setiap sumber daya untuk sepenuhnya mengunduh sebelum memulai unduhan berikutnya, web akan terasa sangat lambat. Internet penuh dengan latency. Sinyal harus melakukan perjalanan jarak jauh dan angin melalui berbagai perangkat keras. Ada juga beberapa overhead dalam membangun koneksi TCP. Seperti yang kita lihat di screenshot Wireshark, ada handshake tiga langkah yang harus diselesaikan sebelum transaksi HTTP dapat dimulai.

Evolusi dari dokumen sederhana ke halaman yang rumit telah membutuhkan kecerdikan dalam penggunaan praktis HTTP.


Koneksi Paralel

Kebanyakan agen pengguna (alias browser web) tidak akan membuat permintaan dalam mode satu per satu serial. Sebaliknya, mereka membuka beberapa koneksi paralel ke server. Misalnya, ketika mengunduh HTML untuk halaman, browser mungkin melihat dua tag <img> di halaman, sehingga peramban akan membuka dua koneksi paralel untuk mengunduh dua gambar secara bersamaan. Jumlah koneksi paralel tergantung pada agen pengguna dan konfigurasi agen.

Untuk waktu yang lama kami menganggap dua sebagai jumlah maksimum koneksi paralel yang akan dibuat browser. Kami menganggap dua sebagai maksimal karena browser paling populer selama bertahun-tahun-Internet Explorer (IE) 6-hanya akan memungkinkan dua koneksi simultan ke host tunggal. IE hanya mematuhi aturan yang dijabarkan dalam spesifikasi HTTP 1.1, yang menyatakan:

Seorang klien pengguna tunggal TIDAK HARUS memelihara lebih dari 2 koneksi dengan server atau proxy apa pun.

Untuk meningkatkan jumlah unduhan paralel, banyak situs web menggunakan beberapa trik. Sebagai contoh, batas dua koneksi adalah per host, yang berarti browser seperti IE 6 akan dengan senang hati membuat dua koneksi paralel ke www.odetocode.com, dan dua koneksi paralel ke images.odetocode.com. Dengan menghosting gambar di server yang berbeda, situs web dapat meningkatkan jumlah unduhan paralel dan membuat laman mereka dimuat lebih cepat (meskipun data DNS disiapkan untuk menunjukkan keempat permintaan ke server yang sama, karena batas dua sambungan per host nama, bukan alamat IP).

Hal berbeda hari ini. Sebagian besar agen pengguna akan menggunakan serangkaian heuristik yang berbeda ketika memutuskan berapa banyak koneksi paralel yang harus dibuat. Sebagai contoh, Internet Explorer 8 sekarang akan membuka hingga enam sambungan.

Pertanyaan sebenarnya untuk ditanyakan adalah: berapa banyak koneksi yang terlalu banyak? Koneksi paralel akan mematuhi hukum hasil yang semakin berkurang. Terlalu banyak koneksi dapat menjenuhkan dan membuat jaringan menjadi padat, terutama ketika perangkat seluler atau jaringan yang tidak dapat diandalkan terlibat. Dengan demikian, memiliki terlalu banyak koneksi dapat merusak kinerja. Juga, server hanya dapat menerima sejumlah koneksi terbatas, jadi jika 100.000 browser secara bersamaan membuat 100 koneksi ke satu server web, hal-hal buruk akan terjadi. Namun, menggunakan lebih dari satu koneksi per agen lebih baik daripada mengunduh semuanya secara serial.

Untungnya, koneksi paralel bukan satu-satunya optimalisasi kinerja.


Koneksi Persisten

Pada hari-hari awal web, agen pengguna akan membuka dan menutup koneksi untuk setiap permintaan yang dikirim ke server. Implementasi ini sesuai dengan gagasan HTTP untuk menjadi protokol yang sepenuhnya tanpa negara. Karena jumlah permintaan per halaman bertambah, begitu pula biaya overhead yang dihasilkan oleh TCP handshake dan struktur data di memori yang diperlukan untuk membuat setiap soket TCP. Untuk mengurangi overhead ini dan meningkatkan kinerja, spesifikasi HTTP 1.1 menyarankan bahwa klien dan server harus mengimplementasikan koneksi persisten, dan membuat koneksi persisten tipe koneksi default.

Koneksi persisten tetap terbuka setelah penyelesaian satu transaksi permintaan-respons. Perilaku ini membuat agen pengguna dengan soket yang sudah terbuka dapat digunakan untuk terus membuat permintaan ke server tanpa overhead membuka soket baru. Koneksi persisten juga menghindari strategi start lambat yang merupakan bagian dari kontrol kemacetan TCP, membuat koneksi persisten berkinerja lebih baik dari waktu ke waktu. Singkatnya, koneksi persisten mengurangi penggunaan memori, mengurangi penggunaan CPU, mengurangi kepadatan jaringan, mengurangi latensi, dan secara umum meningkatkan waktu respons halaman. Namun, seperti segala sesuatu dalam hidup ada kerugian.

Seperti disebutkan sebelumnya, server hanya dapat mendukung sejumlah koneksi masuk yang terbatas. Jumlah pasti tergantung pada jumlah memori yang tersedia, konfigurasi perangkat lunak server, kinerja aplikasi, dan banyak variabel lainnya. Sulit untuk memberikan angka yang tepat, tetapi secara umum, jika Anda berbicara tentang mendukung ribuan koneksi bersamaan, Anda harus memulai pengujian untuk melihat apakah server akan mendukung beban. Bahkan, banyak server dikonfigurasi untuk membatasi jumlah koneksi bersamaan jauh di bawah titik di mana server akan jatuh. Konfigurasi adalah langkah pengamanan untuk membantu mencegah denial of service attacks. Ini relatif mudah bagi seseorang untuk membuat program yang akan membuka ribuan koneksi persisten ke server dan menjaga server dari menanggapi klien nyata. Koneksi persisten adalah optimasi kinerja tetapi juga kerentanan.

Berpikir di sepanjang garis kerentanan, kita juga harus bertanya-tanya berapa lama untuk menjaga koneksi tetap terbuka. Di dunia skalabilitas tak terbatas, koneksi bisa tetap terbuka selama program agen pengguna berjalan. Tapi, karena server mendukung sejumlah koneksi terbatas, sebagian besar server dikonfigurasi untuk menutup koneksi persisten jika tidak digunakan selama beberapa waktu (lima detik di Apache, misalnya). Agen pengguna juga dapat menutup koneksi setelah jangka waktu idle. Satu-satunya visibilitas ke koneksi tertutup adalah melalui penganalisis jaringan seperti Wireshark.

Selain menutup koneksi persisten secara agresif, sebagian besar perangkat lunak server web dapat dikonfigurasi untuk menonaktifkan koneksi persisten. Hal ini umum dengan server bersama. Server bersama mengorbankan kinerja untuk memungkinkan koneksi sebanyak mungkin. Karena koneksi persisten adalah gaya koneksi default dengan HTTP 1.1, server yang tidak mengizinkan koneksi persisten harus menyertakan header Connection di setiap respons HTTP. Kode berikut ini adalah contoh.

Connection: close header adalah sinyal ke agen pengguna bahwa koneksi tidak akan persisten dan harus ditutup sesegera mungkin. Agen tidak diperbolehkan membuat permintaan kedua pada koneksi yang sama.


Koneksi dengan Pipelined

Koneksi paralel dan koneksi persisten banyak digunakan dan didukung oleh klien dan server. Spesifikasi HTTP juga memungkinkan untuk pipelined connections, yang tidak didukung secara luas oleh server atau klien. Dalam koneksi pipelined, agen pengguna dapat mengirim beberapa permintaan HTTP pada koneksi sebelum menunggu tanggapan pertama. Pipelining memungkinkan pengemasan permintaan menjadi paket yang lebih efisien dan dapat mengurangi latensi, tetapi tidak didukung secara luas sebagai koneksi paralel dan persisten.


Di mana kita?

Dalam bab ini kita telah melihat koneksi HTTP dan berbicara tentang beberapa optimasi kinerja yang dimungkinkan oleh spesifikasi HTTP. Sekarang setelah kita menggali jauh ke dalam pesan HTTP dan bahkan memeriksa koneksi dan dukungan TCP di bawah protokol, kami akan mengambil langkah mundur dan melihat ke Internet dari perspektif yang lebih luas.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.