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.
 | |
| Standar internasional | RFC 1945 HTTP/1.0 (1996) RFC 2616 HTTP/1.1 (1999) |
|---|---|
| Dikembangkan oleh | Mulanya CERN; IETF, W3C |
| Diperkenalkan | 1991 |
Pengembangan HTTP diprakarsai oleh Tim Berners-Lee di CERN pada tahun 1989. Pengembangan Permintaan HTTP awal untuk Komentar (RFC) adalah upaya terkoordinasi oleh Internet Engineering Task Force (IETF) dan World Wide Web Consortium (W3C), dengan pekerjaan kemudian pindah ke IETF.
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/2 adalah ekspresi semantik HTTP yang lebih efisien "on the wire", dan diterbitkan pada 2015; sekarang didukung oleh hampir semua peramban web[2] dan server web utama melalui Transport Layer Security (TLS) menggunakan ekstensi Application-Layer Protocol Negotiation (ALPN)[3] di mana diperlukan TLS 1.2 atau yang lebih baru.[4]
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-hosting situs 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.
Sumber daya HTTP diidentifikasi dan ditempatkan di jaringan oleh Uniform Resource Locators (URL), menggunakan skema http dan https Uniform Resource Identifiers (URI). Seperti yang didefinisikan dalam RFC 3986, URI dikodekan sebagai hyperlink dalam dokumen HTML, sehingga dapat membentuk dokumen hypertext yang saling terkait.
Sejarah
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:
- RFC 7230, HTTP/1.1: Sintaks dan Routing Pesan
- RFC 7231, HTTP/1.1: Semantik dan Konten
- RFC 7232, HTTP/1.1: Permintaan Bersyarat
- RFC 7233, HTTP/1.1: Rentang Permintaan
- RFC 7234, HTTP/1.1: Caching
- RFC 7235, HTTP/1.1: Autentikasi
HTTP/2 diterbitkan sebagai RFC 7540 pada Mei 2015.
| Tahun | Versi HTTP |
|---|---|
| 1991 | 0.9 |
| 1996 | 1.0 |
| 1997 | 1.1 |
| 2015 | 2.0 |
| 2018 | 3.0 |
Sesi HTTP
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.
Status sesi HTTP
HTTP adalah stateless protocol. Stateless protocol tidak memerlukan server HTTP untuk menyimpan informasi atau status tentang setiap pengguna selama beberapa permintaan. Namun, beberapa aplikasi web menerapkan independen atau sesi sisi server semenggunakan misalnya cookie HTTP atau variabel tersembunyi dalam formulir web.
Autentikasi HTTP
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
Pesan permintaan terdiri dari:
- baris permintaan (mis., GET /images/logo.png HTTP / 1.1, yang meminta sumber daya yang disebut
/images/logo.pngdari server) - bidang tajuk permintaan (mis., Bahasa Terima: id)
- garis kosong
- badan pesan opsional
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]
| Metode HTTP | RFC | Permintaan memiliki body | Respons memiliki body | Aman | Idempoten | Cacheable |
|---|---|---|---|---|---|---|
| GET | RFC 7231 | Optional | Ya | Ya | Ya | Ya |
| HEAD | RFC 7231 | Optional | Tidak | Ya | Ya | Ya |
| POST | RFC 7231 | Ya | Ya | Tidak | Tidak | Ya |
| PUT | RFC 7231 | Ya | Ya | Tidak | Ya | Tidak |
| DELETE | RFC 7231 | Optional | Ya | Tidak | Ya | Tidak |
| CONNECT | RFC 7231 | Optional | Ya | Tidak | Tidak | Tidak |
| OPTIONS | RFC 7231 | Optional | Ya | Ya | Ya | Tidak |
| TRACE | RFC 7231 | Tidak | Ya | Ya | Ya | Tidak |
| PATCH | RFC 5789 | Ya | Ya | Tidak | Tidak | Tidak |
Respon pesan
Pesan respons terdiri dari berikut ini:
- baris status yang mencakup kode status dan pesan alasan (e.g., HTTP/1.1 200 OK, yang mengindikasikan bahwa permintaan klien berhasil)
- bidang header respons (mis., Content-Type: text/html)
- Sebuah garis kosong
- Sebuah message body opsional
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]
Kode status
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.1
Host: 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.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: 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
Lihat pula
- Fiddler (perangkat lunak)
- Kompresi HTTP
- Daftar kode status HTTP
- Objek varian
- Temblok web
- WebSocket
- Wireshark
Referensi
Pranala luar
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
