Devinisi HTTP dan Perkembangannya

HTTP adalah protokol yang harus diketahui oleh setiap pengembang web karena memberi kekuatan pada seluruh web dan mengetahui bahwa itu pasti akan membantu Anda mengembangkan aplikasi yang lebih baik.

Pada artikel ini, saya akan membahas apa itu HTTP, bagaimana itu terjadi dalam ringkas sejarah dan perkembangannya hingga saat ini.

Apa itu HTTP?

HTTP adalah TCP/IP protokol komunikasi lapisan aplikasi berbasis yang menstandarkan bagaimana klien dan server berkomunikasi satu sama lain. Ini mendefinisikan bagaimana konten diminta dan dikirimkan melalui internet. Dengan protokol lapisan aplikasi, maksud saya ini hanya lapisan abstraksi yang menstandarkan bagaimana host (klien dan server) berkomunikasi dan itu sendiri tergantung pada TCP/IP untuk mendapatkan permintaan dan tanggapan antara klien dan server. Secara default port TCP 80  Digunakan tetapi port lain dapat digunakan juga. Namun HTTPS menggunakan port 443.

HTTP/0.9 – The One Liner (Tahun 1991)

Versi HTTP pertama yang didokumentasikan adalah HTTP/0.9 Yang diajukan pada tahun 1991. Itu adalah protokol paling sederhana yang pernah ada; memiliki metode tunggal yang disebut GET. Jika klien harus mengakses beberapa halaman web di server, itu akan membuat permintaan sederhana seperti di bawah ini

GET /index.html

Dan respon dari server akan terlihat sebagai berikut

(response body)
(connection closed)

Artinya, server akan mendapatkan permintaan, membalas dengan HTML sebagai tanggapan dan segera setelah konten telah ditransfer, koneksi akan ditutup. :

  • Tanpa header
  • GET adalah satu-satunya metode yang diizinkan
  • Respons harus berupa HTML

Seperti yang Anda lihat, protokol benar-benar tidak lebih dari menjadi batu loncatan untuk apa yang akan terjadi.

HTTP/1.0 – (Tahun 1996)

Pada tahun 1996, versi HTTP berikutnya yaitu HTTP/1.0 Yang berkembang dan jauh lebih baik dari versi aslinya.

Berbeda dengan HTTP/0.9 yang hanya dirancang untuk respons HTML, HTTP/1.0sekarang dapat menangani format respons lain yaitu gambar, file video, teks biasa, atau jenis konten lainnya. Itu menambahkan lebih banyak metode (yaitu POST dan HEAD), format permintaan / respons diubah, header HTTP ditambahkan ke permintaan dan respons, kode status ditambahkan untuk mengidentifikasi respons, dukungan set karakter diperkenalkan, tipe multi-bagian, otorisasi, caching , penyandian konten dan banyak lagi dimasukkan.

Berikut adalah bagaimana contoh HTTP/1.0  Permintaan Dan respons mungkin terlihat:

GET / HTTP/1.0
Host: santri.website
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

Seperti yang Anda lihat, di samping permintaan, klien juga telah mengirim informasi pribadinya, jenis respons yang diperlukan, dll. Sementara di HTTP/0.9  Klien tidak pernah dapat mengirim informasi seperti itu karena tidak ada tajuk.

Contoh respons terhadap permintaan di atas mungkin terlihat seperti di bawah ini

HTTP/1.0 200 OK 
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

(response body)
(connection closed)

Di bagian paling awal dari respons ada HTTP/1.0(HTTP diikuti oleh nomor versi), kemudian ada kode status 200 diikuti oleh frase alasan (atau deskripsi kode status, jika Anda mau).

Dalam versi yang lebih baru ini, header permintaan dan respons masih disimpan sebagai ASCII Yang Dikodekan, tetapi badan respons bisa dari jenis apa pun yaitu gambar, video, HTML, teks biasa atau jenis konten lainnya. Jadi, sekarang server dapat mengirim jenis konten apa pun ke klien; tidak lama setelah perkenalan, istilah “Hyper Text” di HTTP menjadi keliru. HMTP atau protokol transfer Hypermedia mungkin lebih masuk akal.

Salah satu kelemahan utama HTTP/1.0 Adalah Anda tidak dapat memiliki beberapa permintaan per koneksi. Artinya, setiap kali klien akan membutuhkan sesuatu dari server, ia harus membuka koneksi TCP baru dan setelah permintaan tunggal terpenuhi, koneksi akan ditutup. Dan untuk persyaratan selanjutnya, harus pada koneksi baru. Kenapa itu buruk? Baiklah, mari kita asumsikan bahwa Anda mengunjungi halaman web yang memiliki file 10 Gambar, 5 Stylesheet dan 5 Javascript , berjumlah total 20 item yang perlu diambil saat permintaan halaman web dibuat. Karena server menutup koneksi segera setelah permintaan terpenuhi, akan ada serangkaian 20 koneksi terpisah di mana masing-masing item akan dilayani satu per satu di koneksi masing-masing. Sejumlah besar koneksi ini menghasilkan hit kinerja serius karena memerlukan TCP koneksi baru mengenakan penalti kinerja yang signifikan karena jabat tangan tiga arah diikuti dengan start lambat.

Three-way Handshake

Jabat tangan tiga arah dalam bentuk sederhana adalah bahwa semua TCP koneksi dimulai dengan jabat tangan tiga arah di mana klien dan server berbagi serangkaian paket sebelum mulai berbagi data aplikasi.

  • SYN– Klien mengambil nomor acak, katakanlah x, dan mengirimkannya ke server.
  • SYN ACK– Server mengakui permintaan dengan mengirim ACK Paket Kembali ke klien yang terdiri dari nomor acak, misalkan ydiambil oleh server dan nomor dimana x+1 Mana nomor yang dikirim oleh klien
  • ACK– Klien menambah nomor yang yditerima dari server dan mengirim ACKpaket kembali dengan nomor tersebut y+1

Setelah jabat tangan tiga arah selesai, berbagi data antara klien dan server dapat dimulai. Perlu dicatat bahwa klien dapat mulai mengirim data aplikasi segera setelah mengirimkan ACKpaket terakhir tetapi server masih harus menunggu ACK paket diterima untuk memenuhi permintaan.

Namun, beberapa implementasi HTTP/1.0 Mencoba untuk mengatasi masalah ini dengan memperkenalkan header baru bernama Connection: keep-alive Yang Dimaksudkan untuk memberi tahu server “Hei server, jangan tutup koneksi ini, saya perlu lagi”. Tapi tetap saja, itu tidak didukung secara luas dan masalahnya masih ada.

Selain tidak terhubung, HTTP juga merupakan protokol stateless yaitu server tidak memelihara informasi tentang klien dan setiap permintaan harus memiliki informasi yang diperlukan untuk server untuk memenuhi permintaan itu sendiri tanpa ada hubungan dengan permintaan lama . Dan ini menambah bahan bakar ke api yaitu terlepas dari sejumlah besar koneksi yang klien harus buka, itu juga harus mengirim beberapa data yang berlebihan pada kabel yang menyebabkan peningkatan penggunaan bandwidth.

HTTP/1.1 – (Tahun 1999)

Setelah hanya 3 tahun HTTP/1.0, versi berikutnya yaitu HTTP/1.1 Dirilis pada tahun 1999; yang membuat banyak perbaikan dari pendahulunya. Perbaikan besar HTTP/1.0 Termasuk

  • Metode HTTP baru ditambahkan, yang diperkenalkan PUTPATCHOPTIONS,DELETE

  • Identifikasi Hostname Di HTTP/1.0 Hostheader tidak diperlukan tetapi HTTP/1.1  Membuatnya diperlukan.

  • Koneksi Persisten Seperti dibahas di atas, HTTP/1.0  Hanya ada satu permintaan per koneksi dan koneksi ditutup segera setelah permintaan terpenuhi yang mengakibatkan masalah kinerja dan latensi. HTTP/1.1memperkenalkan koneksi persisten yaitu koneksi tidak ditutup secara default dan tetap terbuka yang memungkinkan beberapa permintaan berurutan. Untuk menutup koneksi, tajuk Connection: close Harus tersedia atas permintaan. Klien biasanya mengirim tajuk ini dalam permintaan terakhir untuk menutup koneksi dengan aman.

  • Pipelining Ini juga memperkenalkan dukungan untuk pipelining, di mana klien dapat mengirim beberapa permintaan ke server tanpa menunggu respons dari server pada koneksi yang sama dan server harus mengirim respons dalam urutan yang sama ketika permintaan diterima. Tetapi bagaimana klien tahu bahwa ini adalah titik di mana unduhan respons pertama selesai dan konten untuk respons selanjutnya dimulai, Anda mungkin bertanya! Nah, untuk menyelesaikan ini, harus ada Content-Lengt Tajuk yang dapat digunakan klien untuk mengidentifikasi di mana respons berakhir dan dapat mulai menunggu respons berikutnya.

Perlu dicatat bahwa untuk mendapatkan manfaat dari koneksi yang terus-menerus atau pemipaan, Content-Length Header harus tersedia pada respons, karena ini akan memberi tahu klien ketika transmisi selesai dan dapat mengirim permintaan berikutnya (dengan cara normal berurutan mengirim permintaan) atau mulai menunggu respons selanjutnya (ketika pipelining diaktifkan).

Chunked Transfers  Jika konten dinamis, ketika server tidak dapat benar-benar mengetahui Content-Length kapan transmisi dimulai, ia mungkin mulai mengirim konten dalam potongan-potongan (chunk by chunk) dan menambahkan Content-Length untuk setiap chunk ketika dikirim. Dan ketika semua potongan dikirim yaitu seluruh transmisi telah selesai, ia mengirim potongan kosong yaitu satu dengan Content-Lengthset ke nol untuk mengidentifikasi klien bahwa transmisi telah selesai. Untuk memberi tahu klien tentang transfer yang dilakukan chunk, server menyertakan header Transfer-Encoding: chunked

  • Berbeda dengan HTTP/1.0 yang hanya memiliki otentikasi Dasar, HTTP/1.1 termasuk intisari digest dan proxy
  • Caching
  • Byte Ranges
  • Set karakter
  • Negosiasi bahasa
  • Cookie klien
  • Dukungan kompresi yang ditingkatkan
  • Kode status baru
  • ..dan lainnya

Saya tidak akan membahas semua HTTP/1.1 fitur dalam posting ini karena ini adalah topik tersendiri dan Anda sudah dapat menemukan banyak hal tentangnya. Salah satu dokumen yang saya sarankan untuk Anda baca adalah perbedaan utama antara HTTP/1.0 dan HTTP/1.1 dan di sini adalah tautan ke RFC Asli untuk orang-orang yang berprestasi.

HTTP/1.1 Diperkenalkan pada tahun 1999 dan telah menjadi standar selama bertahun-tahun. Meskipun, itu jauh lebih baik dari pendahulunya; dengan web berubah setiap hari, itu mulai menunjukkan usianya. Memuat halaman web saat ini lebih banyak sumber daya daripada sebelumnya. Halaman web sederhana hari ini harus membuka lebih dari 30 koneksi. Nah HTTP/1.1memiliki koneksi yang persisten, lalu mengapa begitu banyak koneksi? kamu bilang! Alasannya, di HTTP/1.1 dalamnya hanya dapat memiliki satu koneksi yang luar biasa setiap saat. HTTP/1.1 mencoba untuk memperbaikinya dengan memperkenalkan pipelining tetapi itu tidak sepenuhnya mengatasi masalah karena pemblokiran head-of-line di mana permintaan yang lambat atau berat dapat memblokir permintaan di belakang dan sekali permintaan macet di saluran pipa, itu harus menunggu permintaan berikutnya dipenuhi. Untuk mengatasi kekurangan ini HTTP/1.1, para pengembang mulai menerapkan solusi, misalnya penggunaan spritesheets, gambar yang disandikan dalam CSS, file humungous CSS / Javascript tunggal, Sharding domain dll.

SPDY – 2009

Google melanjutkan dan mulai bereksperimen dengan protokol alternatif untuk membuat web lebih cepat dan meningkatkan keamanan web sambil mengurangi latensi halaman web. Pada 2009, mereka mengumumkan SPDY.

SPDY adalah merek dagang dari Google dan bukan akronim.

Terlihat bahwa jika kita terus meningkatkan bandwidth, kinerja jaringan meningkat pada awalnya tetapi suatu titik datang ketika tidak ada banyak peningkatan kinerja. Tetapi jika Anda melakukan hal yang sama dengan latensi yaitu jika kami terus menjatuhkan latensi, ada peningkatan kinerja yang konstan. Ini adalah ide inti untuk mendapatkan kinerja di belakang SPDY, mengurangi latensi untuk meningkatkan kinerja jaringan.

Bagi mereka yang tidak tahu perbedaannya, latensi adalah keterlambatan yaitu berapa lama waktu yang diperlukan untuk perjalanan data antara sumber dan tujuan (diukur dalam milidetik) dan bandwidth adalah jumlah data yang ditransfer per detik (bit per detik).

Fitur SPDY termasuk, multiplexing, kompresi, penentuan prioritas, keamanan dll. Saya tidak akan masuk ke rincian SPDY, karena Anda akan mendapatkan ide ketika kita masuk ke seluk-beluk seluk HTTP/2di bagian berikutnya seperti yang saya katakan HTTP/2sebagian besar terinspirasi dari SPDY.

SPDYtidak benar-benar mencoba mengganti HTTP; itu adalah lapisan terjemahan atas HTTP yang ada di lapisan aplikasi dan memodifikasi permintaan sebelum mengirimnya ke kawat. Itu mulai menjadi standar de facto dan mayoritas browser mulai menerapkannya.

Pada 2015, di Google, mereka tidak ingin memiliki dua standar yang bersaing sehingga mereka memutuskan untuk menggabungkannya ke dalam HTTP sambil melahirkan HTTP/2dan mencabut SPDY.

HTTP/2 – ( Tahun 2015)

Sekarang, Anda harus yakin bahwa mengapa kami memerlukan revisi lain dari protokol HTTP. HTTP/2 Yang Dirancang untuk transportasi latensi rendah konten. Fitur utama atau perbedaan dari versi lama HTTP/1.1 termasuk

  • Biner bukan Tekstual
  • Multiplexing – Beberapa permintaan HTTP asinkron melalui satu koneksi
  • Kompresi header menggunakan HPACK
  • Server Push – Beberapa tanggapan untuk permintaan tunggal
  • Meminta Prioritas
  • Keamanan

1. Protokol Biner

HTTP/2 cenderung untuk mengatasi masalah latensi yang meningkat yang ada di HTTP / 1.x dengan menjadikannya protokol biner. Menjadi protokol biner, lebih mudah untuk diurai tetapi tidak seperti HTTP/1.x itu tidak lagi dapat dibaca oleh mata manusia. Blok bangunan utama HTTP/2 adalah Frames dan Streaming

Bingkai dan Aliran

Pesan HTTP sekarang terdiri dari satu atau lebih bingkai. Ada HEADERS bingkai untuk meta data dan DATA frame untuk payload dan terdapat beberapa jenis lain dari frame ( HEADERSDATARST_STREAMSETTINGSPRIORITY dll) yang Anda dapat memeriksa melalui spesifikasi HTTP/2

Setiap HTTP/2 Permintaan dan respons diberikan ID aliran unik dan dibagi menjadi bingkai. Frame tidak lain adalah potongan data biner. Kumpulan bingkai disebut Stream. Setiap frame memiliki id aliran yang mengidentifikasi aliran yang dimiliki dan setiap frame memiliki header yang sama. Selain itu, selain ID aliran yang unik, perlu disebutkan bahwa, setiap permintaan yang diprakarsai oleh klien menggunakan angka ganjil dan respons dari server memiliki nomor ID aliran.

Selain dari HEADERS dan DATA, jenis bingkai lain yang menurut saya layak disebutkan di sini adalah RST_STREAM jenis bingkai khusus yang digunakan untuk membatalkan beberapa aliran yaitu klien dapat mengirim bingkai ini untuk memberi tahu server bahwa saya tidak memerlukan aliran ini lagi. Dalam HTTP/1.1 satu-satunya cara untuk membuat server berhenti mengirimkan respon ke klien menutup koneksi yang mengakibatkan peningkatan latency karena koneksi baru harus dibuka untuk setiap permintaan berturut-turut. Sementara dalam HTTP / 2, klien dapat menggunakan RST_STREAM dan berhenti menerima aliran tertentu sementara koneksi masih terbuka dan aliran lainnya masih dalam permainan.

2. Multiplexing

Karena HTTP/2 sekarang merupakan protokol biner dan seperti yang saya katakan di atas bahwa ia menggunakan frame dan stream untuk permintaan dan respons, begitu koneksi TCP dibuka, semua stream dikirim secara tidak sinkron melalui koneksi yang sama tanpa membuka koneksi tambahan. Dan pada gilirannya, server merespons dengan cara asinkron yang sama yaitu respons tidak memiliki urutan dan klien menggunakan id aliran yang ditugaskan untuk mengidentifikasi aliran yang dimiliki paket tertentu. Ini juga memecahkan masalah pemblokiran head-of-line yang ada di HTTP / 1.x yaitu klien tidak harus menunggu permintaan yang membutuhkan waktu dan permintaan lainnya masih akan diproses.

3. Kompresi Header HPACK

Itu adalah bagian dari RFC terpisah yang secara khusus ditujukan untuk mengoptimalkan header yang dikirim. Inti dari itu adalah bahwa ketika kita terus mengakses server dari klien yang sama ada banyak data yang berlebihan yang kita kirim di header berulang-ulang, dan kadang-kadang mungkin ada cookie meningkatkan ukuran header yang menghasilkan penggunaan bandwidth dan latensi meningkat. Untuk mengatasinya, HTTP/2 diperkenalkan kompresi tajuk.

Tidak seperti permintaan dan respon, header tidak dikompresi dalam gzip atau compress format dll tapi ada mekanisme yang berbeda di tempat untuk kompresi header yang literal nilai dikodekan menggunakan kode Huffman dan meja header dikelola oleh klien dan server dan kedua klien dan server hilangkan setiap header berulang (mis. agen pengguna dll) dalam permintaan berikutnya dan referensi mereka menggunakan tabel header yang dikelola oleh keduanya.

Sementara kita berbicara header, izinkan saya menambahkan di sini bahwa header masih sama seperti pada HTTP / 1.1, kecuali untuk penambahan beberapa pseudo header yaitu :method:scheme:host dan:path

4. Server Push

Server push adalah fitur luar biasa lain di HTTP/2mana server, mengetahui bahwa klien akan meminta sumber daya tertentu, dapat mendorongnya ke klien tanpa klien memintanya. Sebagai contoh, katakanlah browser memuat halaman web, ia mem-parsing seluruh halaman untuk mengetahui konten jarak jauh yang harus dimuat dari server dan kemudian mengirimkan permintaan konsekuen ke server untuk mendapatkan konten itu.

Server push memungkinkan server untuk mengurangi pulang pergi dengan mendorong data yang diketahui bahwa klien akan menuntut. Cara melakukannya adalah, server mengirimkan kerangka khusus yang disebut PUSH_PROMISE memberi tahu klien bahwa, “Hei, saya akan mengirimkan sumber daya ini kepada Anda! Jangan tanya saya untuk itu. ” The PUSH_PROMISE frame terkait dengan aliran yang menyebabkan push terjadi dan berisi aliran ID yang dijanjikan yaitu aliran yang server akan mengirimkan sumber daya yang akan mendorong.

5. Meminta Prioritas

Klien dapat menetapkan prioritas untuk aliran dengan memasukkan informasi prioritas dalam HEADERS bingkai di mana aliran dibuka. Di lain waktu, klien dapat mengirim PRIORITY bingkai untuk mengubah prioritas aliran.

Tanpa informasi prioritas, server memproses permintaan secara tidak sinkron, yaitu tanpa urutan apa pun. Jika ada prioritas yang ditetapkan untuk streaming, maka berdasarkan informasi penentuan prioritas ini, server memutuskan berapa banyak sumber daya yang perlu diberikan untuk memproses permintaan mana.

6. Keamanan

Ada diskusi ekstensif tentang apakah keamanan (melalui TLS) harus dibuat wajib HTTP/2 atau tidak. Pada akhirnya, diputuskan untuk tidak menjadikannya wajib. Namun, sebagian besar vendor menyatakan bahwa mereka hanya akan mendukung HTTP/2 ketika sudah habis TLS. Jadi, meskipun HTTP/2 tidak memerlukan enkripsi berdasarkan spesifikasi tetapi itu tetap menjadi wajib secara default. Dengan cara itu, HTTP/2 ketika diimplementasikan lebih dari TLS itu memberlakukan beberapa persyaratan. TLS versi 1.2 atau lebih tinggi harus digunakan, harus ada tingkat minimum keysize tertentu, kunci sesaat diperlukan dll.

HTTP/2 ada di sini dan telah melampaui SPDY dalam adaptasi yang secara bertahap meningkat. HTTP/2 telah banyak menawarkan dalam hal perolehan kinerja dan sudah saatnya kita harus mulai menggunakannya.

Tinggalkan Komentar

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *