Protokol Transfer Hiperteks (bahasa Inggris: Hypertext Transfer Protocol, disingkat HTTP) adalah protokol pada lapisan aplikasi untuk sistem informasi hypermedia yang terdistribusi dan kolaboratif.[1] HTTP adalah dasar komunikasi data untuk World Wide Web, di mana dokumen hiperteks menyertakan hyperlink ke sumber daya lain yang dapat dengan mudah diakses pengguna, misalnya dengan mengklik mouse atau dengan mengetuk layar di peramban web.
HTTP/1.1 pertama kali didokumentasikan dalam RFC 2030 pada tahun 1997. Spesifikasi itu sudah usang oleh RFC 2616 pada tahun 1999, yang juga digantikan oleh keluarga RFC 7230 RFC pada tahun 2014.
HTTP/3 adalah penerus yang diusulkan untuk HTTP/2,[5] yang sudah digunakan di web, menggunakan UDP bukan TCP untuk protokol transportasi yang mendasarinya. Seperti HTTP/2, protokol ini tidak ketinggalan versi utama sebelumnya. Dukungan untuk HTTP/ 3 ditambahkan ke Cloudflare dan Google Chrome pada September 2019,[6] dan dapat diaktifkan di versi stabil Chrome dan Firefox.[7]
Gambaran teknikal
HTTP berfungsi sebagai protokol permintaan-respons dalam model komputasi klien-server. Peramban web, misalnya, mungkin klien dan aplikasi yang berjalan di komputer yang meng-hostingsitus web mungkin adalah server. Klien mengirimkan pesan permintaan HTTP ke server. Server, yang menyediakan sumber daya seperti file HTML dan konten lainnya, atau melakukan fungsi lain atas nama klien, mengembalikan pesan respons ke klien. Respons tersebut berisi informasi status penyelesaian tentang permintaan dan mungkin juga berisi konten yang diminta di badan pesannya.
Peramban web adalah contoh user agent (UA). Jenis lain dari agen pengguna termasuk perangkat lunak pengindeksan yang digunakan oleh penyedia pencarian (perayap web), peramban suara, aplikasi seluler, dan perangkat lunak lain yang mengakses, menggunakan, atau menampilkan konten web.
HTTP dirancang untuk mengizinkan elemen jaringan perantara untuk meningkatkan atau mengaktifkan komunikasi antara klien dan server. Situs web dengan lalu lintas tinggi sering kali mendapatkan keuntungan dari server cache web yang mengirimkan konten atas nama server hulu untuk meningkatkan waktu respon. Tembolok peramban web sebelumnya mengakses sumber daya web dan menggunakannya kembali, jika memungkinkan, untuk mengurangi lalu lintas jaringan. Server proxy HTTP pada batas jaringan pribadi dapat memfasilitasi komunikasi untuk klien tanpa alamat yang dapat dirutekan secara global, dengan menyampaikan pesan dengan server eksternal.
Istilah hypertext diciptakan oleh Ted Nelson pada tahun 1965 di Proyek Xanadu, yang pada gilirannya terinspirasi oleh visi 1930-an Vannevar Bush tentang pengambilan informasi berbasis mikrofilm dan sistem "memex" manajemen yang dijelaskan dalam esai 1945-nya "As We May Think". Tim Berners-Lee dan timnya di CERN dikreditkan dengan menciptakan HTTP asli, bersama dengan HTML dan teknologi terkait untuk server web dan browser web berbasis teks. Berners-Lee pertama kali mengusulkan proyek "WorldWideWeb" pada tahun 1989 - sekarang dikenal sebagai World Wide Web. Versi pertama protokol hanya memiliki satu metode, yaitu GET, yang akan meminta halaman dari server.[8] Respons dari server selalu berupa halaman HTML.[9]
Versi HTTP terdokumentasi pertama adalah HTTP V0.9 (1991). Dave Raggett memimpin Kelompok Kerja HTTP (HTTP WG) pada tahun 1995 dan ingin memperluas protokol dengan operasi yang diperpanjang, negosiasi yang lebih luas, meta-informasi yang lebih kaya, diikat dengan protokol keamanan yang menjadi lebih efisien dengan menambahkan metode tambahan dan bidang header.[10]RFC 1945 secara resmi memperkenalkan dan mengakui HTTP V1.0 pada tahun 1996.
Pada tahun 2007, Kelompok Kerja HTTP dibentuk, sebagian, untuk merevisi dan mengklarifikasi spesifikasi HTTP/1.1. Pada Juni 2014, WG merilis spesifikasi enam bagian yang diperbarui RFC 2616 yang sudah usang:
Sesi HTTP adalah urutan transaksi respons-permintaan jaringan. Klien HTTP memulai permintaan dengan membuat koneksi Transmission Control Protocol (TCP) ke port tertentu pada server (biasanya port 80, terkadang port 8080; lihat Daftar nomor port TCP dan UDP). Server HTTP yang mendengarkan port itu menunggu pesan permintaan klien. Setelah menerima permintaan, server mengirim kembali baris status, seperti "HTTP/1.1 200 OK", dan pesannya sendiri. Isi pesan ini biasanya adalah sumber yang diminta, meskipun pesan kesalahan atau informasi lain juga dapat dikembalikan.[1]
Koneksi persisten
Dalam HTTP/0.9 dan 1.0, koneksi ditutup setelah satu pasangan permintaan / respons. Dalam HTTP/1.1 mekanisme keep-hidup diperkenalkan, di mana koneksi dapat digunakan kembali untuk lebih dari satu permintaan. Koneksi persisten seperti itu mengurangi latensi permintaan dengan jelas, karena klien tidak perlu menegosiasikan kembali koneksi TCP 3-Way-Handshake setelah permintaan pertama dikirim. Efek samping positif lainnya adalah, secara umum, koneksi menjadi lebih cepat seiring berjalannya waktu karena mekanisme slow-start-TCP.
Versi 1.1 protokol juga membuat peningkatan optimasi bandwidth ke HTTP/1.0. Misalnya, HTTP/1.1 memperkenalkan chunked transfer encoding untuk memungkinkan konten pada koneksi yang persisten di-stream daripada buffer. Perpipaan HTTP lebih lanjut mengurangi waktu jeda, memungkinkan klien untuk mengirim beberapa permintaan sebelum menunggu setiap tanggapan. Tambahan lain untuk protokol adalah byte serving, di mana server mentransmisikan hanya sebagian dari sumber daya yang secara eksplisit diminta oleh klien.
HTTP menyediakan beberapa skema otentikasi seperti otentikasi akses dasar dan intisari akses otentikasi yang beroperasi melalui mekanisme respons-respons di mana server mengidentifikasi dan mengeluarkan tantangan sebelum menyajikan konten yang diminta.
HTTP menyediakan kerangka kerja umum untuk kontrol akses dan otentikasi, melalui serangkaian skema otentikasi respons-responsif, yang dapat digunakan oleh server untuk menantang permintaan klien dan oleh klien untuk memberikan informasi otentikasi.[11]
Alam autentikasi
Spesifikasi Otentikasi HTTP juga menyediakan konstruksi sewenang-wenang, spesifik implementasi untuk membagi lebih lanjut sumber daya yang umum untuk URI root yang diberikan. String nilai ranah, jika ada, dikombinasikan dengan URI akar kanonik untuk membentuk komponen ruang perlindungan dari tantangan. Ini berlaku memungkinkan server untuk menentukan cakupan otentikasi terpisah di bawah satu URI root.[11] bocor
Format pesan
Klien mengirim permintaan ke server dan server mengirim tanggapan.
Permintaan pesan
Permintaan HTTP 1.1 dibuat menggunakan telnet. Pesan permintaan, bagian tajuk respons, dan badan respons disorot.
Pesan permintaan terdiri dari:
baris permintaan (mis., GET /images/logo.png HTTP / 1.1, yang meminta sumber daya yang disebut /images/logo.png dari server)
Baris permintaan dan bidang tajuk lainnya masing-masing harus diakhiri dengan <CR> <LF> (yaitu, karakter carriage return diikuti oleh karakter umpan baris). Baris kosong harus terdiri dari hanya <CR> <LF> dan tidak ada spasi putih lainnya.[1] Dalam protokol HTTP/1.1, semua bidang tajuk kecuali Host adalah opsional.
Baris permintaan yang hanya berisi nama jalur diterima oleh server untuk menjaga kompatibilitas dengan klien HTTP sebelum spesifikasi HTTP/1.0 dalam RFC 1945[12]
Metode permintaan
HTTP mendefinisikan metode (kadang-kadang disebut sebagai kata kerja, tetapi tidak ada dalam spesifikasi yang menyebutkan kata kerja, juga OPTIONS atau HEAD kata kerja) untuk menunjukkan tindakan yang diinginkan untuk dilakukan pada sumber daya yang diidentifikasi. Sumber daya ini mewakili, apakah data yang sudah ada sebelumnya atau data yang dihasilkan secara dinamis, tergantung pada implementasi server. Seringkali, sumber daya berhubungan dengan file atau output dari executable yang berada di server. Spesifikasi HTTP/1.0[13] mendefinisikan metode GET, HEAD dan POST dan spesifikasi HTTP/1.1[1] menambahkan lima metode baru: OPTIONS, PUT, DELETE, TRACE, dan CONNECT.
HEAD
Metode HEAD meminta respons yang identik dengan permintaan GET, tetapi tanpa badan respons. Ini berguna untuk mengambil meta-informasi yang ditulis di header respons, tanpa harus mengangkut seluruh konten.
GET
Meminta representasi sumber tertentu. Permintaan menggunakan GET (dan beberapa metode HTTP lain) "tidak boleh memiliki kepentingan melakukan tindakan selain pengaksesan". W3C telah menerbitkan prinsip panduan mengenai perbedaan ini dengan menyatakan, "desain aplikasi web harus mematuhi prinsip di atas, serta batasan sejenis."[14]
POST
Metode POST meminta server menerima entitas yang terlampir dalam permintaan sebagai bawahan baru sumber daya web yang diidentifikasi oleh URI. Data POSTed mungkin, misalnya, anotasi untuk sumber daya yang ada; pesan untuk papan buletin, newsgroup, milis, atau utas komentar; blok data yang merupakan hasil dari mengirimkan formulir web ke proses penanganan data; atau item untuk ditambahkan ke database.[1]
PUT
Metode PUT meminta entitas terlampir disimpan di bawah URI yang disediakan. Jika URI mengacu pada sumber daya yang sudah ada, itu diubah; jika URI tidak menunjuk ke sumber daya yang ada, maka server dapat membuat sumber daya dengan URI itu.[1]
DELETE
Metode DELETE menghapus sumber daya yang ditentukan.
TRACE
Metode TRACE menggemakan permintaan yang diterima sehingga klien dapat melihat apa (jika ada) perubahan atau penambahan yang telah dilakukan oleh server perantara.
OPTIONS
Metode OPTIONS mengembalikan metode HTTP yang didukung server untuk URL yang ditentukan. Ini dapat digunakan untuk memeriksa fungsionalitas server web dengan meminta '*' alih-alih sumber daya tertentu.
CONNECT
[1] Metode CONNECT mengubah koneksi permintaan ke terowongan TCP / IP transparan, biasanya untuk memfasilitasi komunikasi terenkripsi SSL (HTTPS) melalui proxy HTTP yang tidak terenkripsi.[15] Lihat metode HTTP CONNECT.
PATCH
Metode PATCH menerapkan modifikasi parsial ke sumber daya.[16]
Semua server HTTP tujuan umum wajib menerapkan setidaknya metode GET dan HEAD, dan semua metode lain dianggap opsional oleh spesifikasi.[1]
Keamanan
Metode TRACE dapat digunakan sebagai bagian dari kelas serangan yang dikenal sebagai cross-site tracing; untuk alasan itu, saran keamanan umum adalah agar dinonaktifkan di konfigurasi server.[17] Microsoft IIS mendukung metode "TRACK", yang berperilaku sama, dan yang juga direkomendasikan untuk dinonaktifkan.[17]
Baris status dan bidang header lainnya harus diakhiri dengan <CR><LF>. Baris kosong harus terdiri dari hanya <CR><LF> dan tidak ada spasi putih lainnya.[18] Persyaratan ketat ini untuk <CR><LF> adalah berelaksi dalam badan pesan untuk penggunaan konsisten dari linebreak sistem lain seperti <CR> atau <LF> saja.[19]
Dalam HTTP/1.0 dan sejak itu, baris pertama dari respons HTTP disebut baris status dan termasuk kode status numerik (seperti "404") dan frase alasan tekstual (seperti "Not Found"). Cara agen pengguna menangani respons bergantung terutama pada kode, dan yang kedua pada bidang header respons lainnya. Kode status khusus dapat digunakan, karena jika agen pengguna menemukan kode yang tidak dikenali, ia dapat menggunakan digit pertama dari kode untuk menentukan kelas umum dari respons.[20]
Ungkapan alasan standar hanya rekomendasi, dan dapat diganti dengan "setara lokal" atas kebijakan pengembang web. Jika kode status menunjukkan masalah, agen pengguna mungkin menampilkan frasa alasan kepada pengguna untuk memberikan informasi lebih lanjut tentang sifat masalah. Standar juga memungkinkan agen pengguna untuk mencoba menafsirkan frasa alasan, meskipun ini mungkin tidak bijaksana karena standar secara eksplisit menentukan bahwa kode status dapat dibaca mesin dan frasa alasan dapat dibaca oleh manusia. Kode status HTTP terutama dibagi menjadi lima kelompok untuk penjelasan permintaan dan tanggapan yang lebih baik antara klien dan server seperti yang disebutkan:
Informational 1XX
Berhasil 2XX
Pengalihan 3XX
Klien Error 4XX
Server Error 5XX
Koneksi terenkripsi
Cara paling populer untuk membangun koneksi HTTP terenkripsi adalah HTTPS.[21] Dua metode lain untuk membuat koneksi HTTP terenkripsi juga ada: Secure Hypertext Transfer Protocol, dan menggunakan header Upgrade HTTP/1.1 untuk menentukan peningkatan ke TLS. Dukungan browser untuk keduanya, bagaimanapun, hampir tidak ada.[22][23]
Contoh sesi
Di bawah ini adalah contoh percakapan antara klien HTTP dan server HTTP yang berjalan di www.example.com, port 80.
Permintaan klien
GET/HTTP/1.1Host:www.example.com
Permintaan klien (terdiri dalam kasus ini dari garis permintaan dan hanya satu bidang tajuk) diikuti oleh garis kosong, sehingga permintaan berakhir dengan dua baris baru, masing-masing dalam bentuk carriage return diikuti oleh umpan baris. Bidang "Host" membedakan antara berbagai nama DNS yang berbagi alamat IP tunggal, yang memungkinkan hosting virtual berbasis nama. Sementara opsional dalam HTTP/1.0, itu wajib di HTTP/1.1. ("/" Berarti /index.html jika ada.)
Respon server
HTTP/1.1200OKDate:Mon, 23 May 2005 22:38:34 GMTContent-Type:text/html; charset=UTF-8Content-Length:155Last-Modified:Wed, 08 Jan 2003 23:11:55 GMTServer:Apache/1.3.3.7 (Unix) (Red-Hat/Linux)ETag:"3f80f-1b6-3e1cb03b"Accept-Ranges:bytesConnection:close<html><head><title>An Example Page</title></head><body><p>Hello World, this is a very simple HTML document.</p></body></html>
Bidang header ETag (tag entitas) digunakan untuk menentukan apakah versi cache dari sumber daya yang diminta identik dengan versi sumber daya saat ini di server. Content-Type menentukan jenis media Internet dari data yang disampaikan oleh pesan HTTP, sementara Content-Length menunjukkan panjangnya dalam byte. Server web HTTP / 1.1 menerbitkan kemampuannya untuk menanggapi permintaan untuk rentang bita tertentu dari dokumen dengan mengatur bidang Accept-Ranges: bytes. Ini berguna, jika klien hanya perlu memiliki porsi tertentu[24] dari sumber daya yang dikirim oleh server, yang disebut byte serving. Ketika Connection: close dikirim, itu berarti bahwa server web akan menutup koneksi TCP segera setelah transfer tanggapan ini.
Sebagian besar baris header adalah opsional. Ketika Content-Length menghilang panjang ditentukan dengan cara lain. Pengkodean transfer chunked menggunakan ukuran chunk 0 untuk menandai akhir konten. Pengodean identitas tanpa Content-Length membaca konten sampai soket ditutup.
Content-Encoding seperti gzip dapat digunakan untuk mengompresi data yang dikirimkan.
Protokol serupa
Protokol Gopher adalah protokol pengiriman konten yang digantikan oleh HTTP pada awal 1990-an.
Protokol SPDY adalah alternatif untuk HTTP yang dikembangkan di Google, digantikan oleh HTTP/2.
^Nielsen, Henrik Frystyk; Berners-Lee, Tim; Fielding, Roy T. "Hypertext Transfer Protocol -- HTTP/1.0". tools.ietf.org (dalam bahasa Inggris). Diakses tanggal 2020-06-23.
