Protokol lapisan aplikasi HTTP mendasari Internet. Ini memulai hidupnya pada tahun 1991 sebagai HTTP / 0.9, dan pada tahun 1999 berubah menjadi HTTP / 1.1, yang distandarisasi oleh Internet Engineering Council (IETF).

HTTP / 1.1 memuaskan semua orang untuk waktu yang lama, tetapi meningkatnya kebutuhan Web membutuhkan peningkatan - dan pada 2015 mengadopsi HTTP / 2. Kisah itu tidak berakhir di sana: baru-baru ini, IETF mengumumkan versi baru HTTP / 3. Bagi sebagian orang, ini mengejutkan dan menimbulkan kebingungan. Jika Anda tidak memantau IETF, mungkin sepertinya HTTP / 3 datang entah dari mana. Namun demikian, kita dapat melacak asalnya sesuai dengan sejarah percobaan dan evolusi protokol web, khususnya, protokol transport QUIC.

Jika Anda tidak terbiasa dengan QUIC, rekan Cloudflare saya telah membahas berbagai aspek dengan beberapa detail: misalnya, lihat artikel tentang kekurangan nyata dari HTTP modern dan detail tentang protokol layer transport . Kami telah mengumpulkan ini dan materi lainnya di cloudflare-quic.com . Dan jika Anda tertarik, pastikan untuk memeriksa quiche : ini adalah implementasi QUIC kami sendiri, yang ditulis dalam Rust dengan kode sumber terbuka.

HTTP / 3 - terjemahan protokol transport QUIC untuk lapisan aplikasi. Nama HTTP / 3 secara resmi disetujui hanya baru-baru ini, dalam versi draft ke 17 ( draft-ietf-quic-http-17 ). Itu diusulkan pada akhir Oktober 2018, dan konsensus dicapai pada pertemuan IETF 103 di Bangkok pada bulan November.

Sebelumnya, HTTP / 3 dikenal sebagai HTTP oleh QUIC, dan sebelum itu - sebagai HTTP / 2 oleh gQUIC, dan bahkan sebelumnya - SPDY oleh gQUIC. Tetapi intinya adalah bahwa HTTP / 3 hanyalah sintaks HTTP baru yang berjalan pada protokol IETF QUIC, transportasi multipleks dan aman berdasarkan UDP.

Dalam artikel ini, kita akan melihat sejarah beberapa nama HTTP / 3 sebelumnya dan memperkenalkan motivasi untuk perubahan nama belakang. Mari kita kembali ke hari-hari pertama HTTP dan semua yang terjadi selama ini. Jika Anda ingin mendapatkan gambaran lengkapnya, Anda dapat langsung menuju ke akhir artikel atau membuka versi SVG yang sangat terperinci ini .

HTTP / 3 Layer Cake

Perabot

Tepat sebelum berfokus pada HTTP, perlu diingat bahwa ada dua protokol yang disebut QUIC. Seperti yang telah kami jelaskan , gQUIC biasanya digunakan sebagai singkatan dari Google QUIC (protokol sumber), dan QUIC sebagai versi IETF yang berbeda dari gQUIC.

Sejak awal tahun 90-an, kebutuhan internet telah berubah. Kami memiliki versi baru HTTP dan tingkat keamanan baru dalam bentuk protokol TLS (Transport Layer Security). Dalam artikel ini, kami hanya akan membahas TLS, dan di artikel lain dari blog kami, Anda dapat mempelajari topik lebih detail.

Sejarah HTTP dan TLS tidak dapat diungkapkan dengan daftar tanggal yang sederhana, karena beberapa cabang berkembang secara paralel dan tumpang tindih dalam waktu. Ketika Anda mencoba menghubungkan semua poin dalam hampir 30 tahun sejarah Internet, Anda tidak dapat melakukannya tanpa visualisasi. Jadi saya membuat jadwal ini: Cloudflare Secure Web Timeline. (catatan: secara teknis ini adalah cladogram , meskipun orang lebih akrab dengan kata "grafik").

Demi kecantikan, saya menjatuhkan beberapa informasi, hanya berfokus pada cabang-cabang yang sukses di ruang IETF. Misalnya, upaya kelompok kerja HTTP-NG dari konsorsium W3, serta beberapa teknologi eksotis, pengucapan yang masih coba dijelaskan oleh penulis tidak ditampilkan di sini: HMURR (diucapkan "hummer") dan WAKA (diucapkan "wah-kah").

Pada bagian berikut, kita akan melihat cladogram ini dan melihat beberapa titik kritis dalam sejarah HTTP. Saya harap ini membantu untuk memahami mengapa standardisasi bermanfaat bagi semua orang, dan bagaimana IETF mendekati masalah ini. Oleh karena itu, kami mulai dengan ikhtisar yang sangat singkat tentang topik sebelum kembali ke jadwal itu sendiri. Jangan lewatkan bagian berikutnya jika Anda sudah terbiasa dengan IETF.

Jenis-jenis Standar Internet

Biasanya, standar mendefinisikan kompetensi umum, ruang lingkup, batasan, penerapan, dan pertimbangan lainnya. Standar ada dalam banyak bentuk dan ukuran. Mereka dapat bersifat informal (standar de facto) atau formal (disepakati / diterbitkan oleh organisasi penetapan standar seperti IETF, ISO atau MPEG). Standar digunakan di banyak daerah, bahkan ada standar resmi Inggris untuk membuat teh - BS 6008.

Definisi HTTP dan SSL protokol pertama diterbitkan di luar IETF: mereka ditandai dengan garis merah pada grafik. Tetapi penggunaan yang luas telah menjadikannya standar de facto.

Pada titik tertentu, mereka memutuskan untuk meresmikan protokol ini (beberapa alasan dijelaskan di bawah). Standar Internet biasanya didefinisikan dalam IETF, yang dipandu oleh prinsip tidak resmi "konsensus teladan dan kode saat ini" berdasarkan aplikasi kehidupan nyata di Internet. Ini berbeda dari pendekatan ruang bersih ketika seseorang mencoba mengembangkan protokol ideal dalam ruang hampa.

Standar IETF umumnya dikenal sebagai RFC. Sulit untuk dijelaskan secara singkat, oleh karena itu saya merekomendasikan artikel "Cara membaca RFC" dari ketua bersama kelompok kerja QUIC Mark Nottingham. Workgroup atau WG pada dasarnya hanyalah sebuah milis.

Setiap tahun ada tiga pertemuan untuk pertemuan pribadi anggota semua kelompok kerja, jika mereka menginginkannya. Agenda untuk minggu-minggu ini bisa sangat sibuk, tidak ada cukup waktu untuk diskusi mendalam tentang masalah teknis. Oleh karena itu, beberapa lebih suka menyelenggarakan lebih banyak pertemuan jangka menengah antara pertemuan umum IETF. Kelompok kerja QUIC telah mengadakan beberapa pertemuan sementara sejak 2017, daftar lengkapnya tersedia di halaman rapat .

Pertemuan-pertemuan ini memiliki kesempatan untuk bertemu dengan para ahli dari organisasi lain, seperti Internet Architecture Council (IAB) atau Kelompok Riset Teknologi Internet (IRTF). Dalam beberapa tahun terakhir, akhir pekan sebelum IETF secara tradisional mengadakan hackathon IETF . Kode nyata dikembangkan di sini dan, yang penting, lulus tes kompatibilitas. Ini membantu untuk menemukan masalah dalam spesifikasi yang dapat didiskusikan langsung di pertemuan.

Penting untuk dipahami bahwa RFC tidak muncul begitu saja. Mereka melewati seluruh proses. Biasanya dimulai dengan draft IETF Internet Draft (ID), yang diajukan untuk ditinjau. Jika spesifikasi telah dipublikasikan, menyiapkan ID akan menjadi pemformatan ulang yang sederhana. Masa berlaku ID adalah 6 bulan sejak tanggal publikasi. Agar tetap aktif, Anda harus menerbitkan versi baru. Dalam praktiknya, tidak apa-apa bahwa ID berakhir. Ini cukup sering terjadi. Dokumen masih disimpan di situs web IETF dan terbuka untuk semua.

Pada cladogram, draft disajikan dalam warna ungu . Masing- masing memiliki namanya sendiri dalam format konsep- {penulis} - {kelompok kerja} - {topik} - {versi} . Bidang WG adalah opsional, mungkin menunjuk ke kelompok kerja IETF di masa depan, dan kadang-kadang berubah. Jika ID disetujui oleh IETF atau diinisiasi langsung di dalam IETF, maka draf tersebut disebut draft-ietf- {workgroup} - {topic} - {versi} . ID dapat bercabang, menggabungkan, atau memudar. Versi dimulai pukul 00 dan meningkat dengan setiap proyek baru satu. Misalnya, draf keempat akan menerima nomor versi 03. Setiap kali nama ID diubah, versinya di-reset ke 00.

Penting untuk dicatat bahwa siapa pun dapat mengirimkan draft mereka ke IETF: mereka tidak dapat dianggap sebagai standar. Tetapi jika proses standardisasi mencapai konsensus dan dokumen akhir lulus ujian, kita akan mendapatkan RFC. Pada titik ini, namanya berubah lagi. Setiap RFC menerima nomor unik, seperti RFC 7230 . Dokumen dengan status ini ditampilkan sebagai garis biru .

RFC dilarang untuk diubah. Artinya, perubahan pada RFC membutuhkan adopsi dokumen dengan nomor baru. Perubahan hanya diperbolehkan untuk koreksi kesalahan editorial atau teknis atau untuk optimasi tata letak sederhana. RFC baru dapat sepenuhnya menggantikan yang lama atau menambahnya.

Semua dokumen IETF tersedia untuk umum di http://tools.ietf.org . Secara pribadi, menurut saya sedikit lebih nyaman daripada Datatracker IETF , karena jalur dokumen dari ID ke RFC ditampilkan secara visual di sana.

Di bawah ini adalah contoh yang menunjukkan pengembangan standar RFC 1945 , yaitu HTTP / 1.0.

Sejarah RFC 1945 di Antarmuka Datatracker IETF

Menariknya, dalam perjalanan kerja, saya menemukan bahwa visualisasi di atas tidak benar. Entah mengapa, draft-ietf-http-v10-spec-05 hilang. Karena ID berumur 6 bulan, mungkin kadaluwarsa sebelum adopsi RFC, meskipun dalam kenyataannya draft itu aktif sampai Agustus 1996.

Mempelajari cladogram

Setelah pengantar teori singkat, kita bisa mulai mempelajari cladogram. Bagian ini menyajikan beberapa kutipan dengan bagian yang paling penting. Setiap titik menunjukkan tanggal dokumen atau fungsi diberikan. Untuk kejelasan, dokumen IETF menghilangkan nomor proyek, tetapi semuanya dalam versi lengkap .

HTTP muncul pada 1991 sebagai protokol HTTP / 0.9, dan pada 1994, draft-fielding-http-spec-00 diterbitkan. Segera diterima oleh IETF, dan karenanya namanya diubah menjadi draft-ietf-http-v10-spec-00 . Setelah enam edisi draft, standar RFC 1945 , HTTP / 1.0, diadopsi pada tahun 1996.

Namun, bahkan sebelum penyelesaian pekerjaan pada HTTP / 1.0, proyek HTTP / 1.1 yang terpisah diluncurkan. Versi konsep draft-ietf-http-v11-spec-00 diterbitkan pada November 1995, dan secara resmi diadopsi sebagai RFC 2068 pada tahun 1997. Mata yang tajam akan melihat bahwa cladogram tidak cukup mencerminkan urutan peristiwa ini - sebuah kesalahan yang tidak berhasil dari alat visualisasi. Saya mencoba meminimalkan masalah seperti itu bila memungkinkan.

Pada pertengahan 1997, revisi HTTP / 1.1 dimulai sebagai draft-ietf-http-v11-spec-rev-00 . Itu berakhir pada tahun 1999 dengan publikasi RFC 2616 . Hingga 2007, semuanya hening di dunia HTTP IETF. Kami kembali ke ini sedikit kemudian.

SSL dan Sejarah TLS

Kami mengalihkan perhatian kami ke lintasan SSL. Kami melihat bahwa spesifikasi SSL 2.0 dirilis sekitar 1995, dan SSL 3.0 dirilis pada November 1996. Menariknya, SSL 3.0 disetujui di RFC 6101 , yang muncul hanya pada Agustus 2011. Terletak di bagian sejarah . Menurut IETF , itu dibuat "untuk mendokumentasikan ide-ide yang dipertimbangkan dan dibuang, atau protokol yang sudah ada pada saat diputuskan untuk mendokumentasikannya." Dalam hal ini, saya membutuhkan dokumen IETF yang menggambarkan SSL 3.0 untuk menggunakannya di mana-mana sebagai tautan kanonik.

Kami lebih tertarik pada bagaimana SSL menginspirasi para insinyur untuk mengembangkan TLS, yang dimulai dengan konsep draft-ietf-tls-protocol-00 pada bulan November 1996. Itu pergi melalui 6 versi konsep dan diterbitkan sebagai RFC 2246 - TLS 1.0 pada awal 1999.

Pada 1995-1999, SSL dan TLS digunakan untuk melindungi koneksi HTTP di Internet. Ini berfungsi dengan baik sebagai standar de facto. Hanya pada bulan Januari 1998, standardisasi resmi HTTPS dimulai dengan publikasi draft draft-ietf-tls-https-00 . Pekerjaan selesai pada Mei 2000 dengan publikasi RFC 2616 - HTTP over TLS.

TLS terus berkembang dari tahun 2000 hingga 2007, dengan adopsi TLS 1.1 dan 1.2. Lalu ada jeda tujuh tahun sebelum pekerjaan dimulai pada versi berikutnya dari protokol TLS, yang akan diterbitkan sebagai draft-ietf-tls-tls13-00 pada April 2014, dan setelah 28 konsep akan disetujui sebagai RFC 8446 - TLS 1.3 pada Agustus 2018.

Proses standardisasi internet

Setelah berkenalan singkat dengan cladogram, saya berharap menjadi lebih baik untuk memahami cara kerja IETF. Saat membuat standar, peneliti atau insinyur mengembangkan protokol eksperimental untuk kasus penggunaan khusus. Di berbagai tingkatan, mereka bereksperimen dengan protokol publik atau pribadi. Informasi yang diterima memungkinkan Anda untuk mengidentifikasi masalah atau meningkatkan protokol. Publikasi karya membantu menjelaskan percobaan, pendapat pertemuan lingkaran spesialis yang lebih luas, atau untuk mencari bantuan dari pemain lain. Jika peserta lain menerima pekerjaan ini pada tahap awal, itu akan menjadi standar de facto, dan pada akhirnya akan ada momentum yang cukup untuk standardisasi resmi.

Status resmi protokol merupakan faktor penting bagi organisasi yang berpikir untuk menggunakannya. Proses standardisasi formal membuat standar de facto lebih menarik karena biasanya memberikan stabilitas. Sebuah organisasi terkemuka seperti IETF, yang mencerminkan minat dan pengalaman banyak peserta, memimpin dan memimpin. Tetapi harus dicatat bahwa tidak semua standar formal menjadi sukses.

Proses menciptakan standar hampir sama pentingnya dengan standar itu sendiri. Memproses ide awal, undangan untuk membahas orang-orang dengan pengetahuan yang lebih luas, pengalaman dan kasus penggunaan - semua ini membantu untuk menciptakan sesuatu yang lebih berguna bagi khalayak luas. Namun, proses standardisasi tidak selalu mudah. Ada jebakan dan rintangan. Terkadang suatu proses memakan waktu sangat lama sehingga hasilnya tidak lagi relevan.

Setiap organisasi yang mendefinisikan standar biasanya memiliki prosesnya sendiri, berfokus pada bidang kegiatan dan peserta. Menjelaskan semua detail cara kerja IETF jauh di luar cakupan artikel ini. Jika Anda tertarik, halaman "Bagaimana Kami Bekerja" di situs web IETF adalah titik awal yang bagus. Seperti biasa, cara terbaik untuk mengetahuinya adalah dengan mengambil bagian sendiri. Cukup untuk bergabung dengan milis atau diskusi di repositori GitHub yang sesuai.

Kode Kerja Cloudflare

Cloudflare bangga menjadi salah satu yang pertama yang memperkenalkan protokol baru, seperti halnya dengan HTTP / 2 dan teknologi lainnya. Kami juga menguji fitur eksperimental dan belum disetujui, seperti TLS 1.3 dan SPDY .

Menjalankan kode nyata membantu Anda memahami seberapa baik protokol akan bekerja dalam praktiknya. Kami menggabungkan pengetahuan para ahli dengan informasi eksperimental untuk membantu meningkatkan kode dan, di mana masuk akal, melaporkan masalah atau perbaikan ke kelompok kerja yang membakukan protokol.

Menguji inovasi bukan satu-satunya prioritas. Seorang inovator sejati selalu tahu kapan harus menunda inovasi sampai waktu yang lebih baik. Ini kadang-kadang berlaku untuk protokol berorientasi keamanan: misalnya, Cloudflare menonaktifkan SSLv3 secara default karena kerentanan POODLE. Dalam kasus lain, protokol diganti dengan yang lebih berteknologi maju: misalnya, kami mengganti SPDY dengan HTTP / 2 .

Mengaktifkan dan menonaktifkan protokol di Cloudflare diwakili oleh garis oranye . Tengara vertikal membantu menghubungkan peristiwa Cloudflare dengan dokumen IETF terkait. Sebagai contoh, Cloudflare memperkenalkan dukungan TLS 1.3 pada September 2016, dan RFC 8446 akhir diterbitkan hampir dua tahun kemudian, pada Agustus 2018.

Refactoring: HTTPbis

HTTP / 1.1 adalah protokol yang sangat sukses. Grafik tidak menunjukkan aktivitas tertentu dari IETF setelah 1999. Namun dalam kenyataannya, bertahun-tahun penggunaan protokol secara aktif memberi pengalaman dan mengungkapkan masalah tersembunyi RFC 2616, termasuk beberapa masalah kompatibilitas. Selain itu, protokol telah diperluas oleh RFC lain, seperti 2817 dan 2818. Akibatnya, pada 2007 diputuskan untuk memulai kegiatan untuk meningkatkan spesifikasi HTTP. Ini disebut HTTPbis (di mana "bis" berasal dari kata Latin "dua", "dua kali" atau "ulangi"). Piagam awal kelompok kerja yang baru menggambarkan dengan baik masalah-masalah yang ingin diselesaikannya.

Secara umum, HTTPbis telah mulai melakukan refactoring RFC 2616 . Ini mencakup perbaikan bug dan implementasi beberapa aspek dari spesifikasi lain yang diterbitkan pada saat yang sama. Diputuskan untuk membagi dokumen menjadi beberapa bagian. Hasilnya, enam draft diterbitkan pada Desember 2007:

draft-ietf-httpbis-p1-messaging
konsep-ietf-httpbis-p2-semantik
draft-ietf-httpbis-p4-kondisional
draft-ietf-httpbis-p5-range
draft-ietf-httpbis-p6-cache
draft-ietf-httpbis-p7-auth

Diagram menunjukkan bagaimana pekerjaan berkembang selama proses pembangunan tujuh tahun yang panjang. Sebelum standardisasi akhir, 27 draft telah diadopsi. Pada Juni 2014, seri RFC 723x (di mana x berkisar dari 0 hingga 5) dirilis. Ketua kelompok kerja HTTPbis mencatat pencapaian ini dengan frasa "RFC2616 sudah mati . " Jika ada yang tidak mengerti, dokumen-dokumen baru dikirim ke arsip RFC 2616 lama.

Apa hubungannya ini dengan HTTP / 3?

Sementara IETF sedang menyelesaikan RFC 723x, dunia tidak tinggal diam. Orang-orang terus memperluas dan melengkapi HTTP. Di antara mereka adalah insinyur Google, yang mulai bereksperimen dengan protokol mereka sendiri yang disebut SPDY (diucapkan "cepat"). Mereka mengatakan bahwa protokol ini mempercepat pemuatan halaman web, yang merupakan fitur penting dari HTTP. Pada akhir 2009, versi pertama diumumkan, dan pada 2010 SPDY v2 dengan cepat muncul.

Saya tidak ingin membahas detail teknis SPDY, tetapi penting untuk memahami bahwa SPDY mengambil paradigma HTTP dasar dan sedikit mengubah format pertukaran untuk optimisasi. Melihat ke belakang, kita melihat bahwa HTTP memiliki perbedaan yang jelas antara semantik dan sintaksis. Semantik menggambarkan konsep pertukaran permintaan dan tanggapan, termasuk metode, kode status, bidang header (metadata) dan badan (data berguna). Sintaksnya menjelaskan cara memetakan semantik ke byte di jaringan.

HTTP / 0.9, 1.0, dan 1.1 memiliki banyak semantik umum. Mereka juga menggunakan sintaksis umum dalam bentuk string karakter yang dikirim melalui koneksi TCP. SPDY mengambil semantik HTTP / 1.1 dan mengubah sintaks menjadi biner. Ini adalah topik yang sangat menarik, tetapi hari ini kita tidak akan mempelajari lubang kelinci ini.

Eksperimen dengan SPDY telah menunjukkan bahwa mengubah sintaks HTTP benar-benar membawa efek. Pada saat yang sama, penting untuk memelihara semantik yang ada. Misalnya, menyimpan format URL untuk menggunakan https:// menghindari banyak masalah yang dapat mempengaruhi implementasi HTTPS.

Setelah melihat beberapa hasil positif, IETF memutuskan sudah waktunya untuk mempertimbangkan opsi untuk HTTP / 2.0. Slide dari sesi HTTPbis selama pertemuan IETF 83 pada Maret 2012 menunjukkan persyaratan dan tujuan yang ditetapkan pengembang untuk diri mereka sendiri. Ini dengan jelas menyatakan: "HTTP / 2.0 hanya berarti protokol transport (format kawat) tidak kompatibel dengan HTTP / 1.x"

Selama pertemuan ini, masyarakat diundang untuk mengekspresikan ide-ide mereka. Draf yang diajukan termasuk draft-mbelshe-httpbis-spdy-00 , draft-montenegro-httpbis-speed-mobility-00, dan draft-tarreau-httpbis-network-friendly-00 . Pada akhirnya, draft SPDY diterima, dan pada November 2012 pekerjaan dimulai pada draft-ietf-httpbis-http2-00 . Setelah 18 konsep, RFC 7540 - HTTP / 2 muncul dalam waktu dua tahun. Pada 2015, sintaks HTTP / 2 sudah cukup tepat untuk membuat HTTP / 2 dan SPDY tidak kompatibel.

Tahun-tahun ini telah menjadi periode yang sangat menegangkan bagi kelompok kerja yang secara bersamaan refactored HTTP / 1.1 dan mengadopsi HTTP / 2. Ini sangat kontras dengan tahun-tahun tenang di awal tahun 2000-an. Pastikan untuk memeriksa cladogram lengkap untuk benar-benar menghargai jumlah pekerjaan yang dilakukan.

Meskipun ada standarisasi HTTP / 2, percobaan dengan SPDY tetap bermanfaat. Cloudflare memperkenalkan dukungan SPDY pada Agustus 2012 dan menghapusnya hanya pada Februari 2018, ketika statistik kami menunjukkan bahwa kurang dari 4% klien web yang memintanya. Sementara itu, tak lama setelah publikasi RFC pada Desember 2015, kami memperkenalkan dukungan HTTP / 2, ketika analisis menunjukkan dukungan yang signifikan untuk klien web.

Protokol SPDY dan HTTP / 2 menggunakan TLS secara default. Pengenalan SSL universal pada bulan September 2014 memungkinkan kami untuk menjamin bahwa semua pengguna Cloudflare akan menggunakan protokol baru saat mereka diperkenalkan.

GQUIC

Google terus bereksperimen dan hingga 2015 merilis versi lain dari SPDY v3 dan v3.1. Mereka juga mulai mengerjakan protokol gQUIC, draft pertama yang diterbitkan pada awal 2012.

Versi sebelumnya dari gQUIC menggunakan sintaks HTTP SPDY v3. Pilihan ini masuk akal karena HTTP / 2 belum disetujui. Sintaks biner SPDY dikemas dalam paket QUIC yang dikirim dalam datagram UDP. Ini adalah keberangkatan dari transportasi TCP yang secara tradisional diandalkan oleh HTTP. Seluruh sistem perakitan terlihat seperti ini:

Pie berlapis SPDY oleh gQUIC

GQUIC menggunakan trik untuk meningkatkan kinerja. Salah satunya adalah mengaburkan batas yang jelas antara aplikasi dan transportasi. Dalam praktiknya, ini berarti bahwa gQUIC hanya mendukung HTTP. Koneksi ini sangat kuat sehingga gQUIC, yang pada waktu itu disebut QUIC, dipandang sebagai kandidat untuk versi HTTP berikutnya. Meskipun banyak perubahan dilakukan untuk QUIC di masa depan, hingga hari ini, banyak orang percaya bahwa itu hanya mendukung HTTP. Sayangnya, ini mengarah pada kebingungan konstan ketika membahas protokol.

gQUIC terus berevolusi dan akhirnya beralih ke sintaks yang jauh lebih dekat dengan HTTP / 2. Begitu dekat sehingga kebanyakan orang mulai menyebutnya "HTTP / 2 oleh QUIC." Tetapi karena keterbatasan teknis, beberapa perbedaan yang sangat halus muncul. Salah satu contoh adalah serialisasi dan pertukaran tajuk HTTP. Ini adalah perbedaan kecil, tetapi dalam praktiknya itu berarti bahwa gQUIC HTTP / 2 tidak kompatibel dengan IETF HTTP / 2.

Last but not least, Anda harus selalu mempertimbangkan aspek keamanan dari protokol internet. Dan para pengembang gQUIC memutuskan untuk meninggalkan TLS demi pendekatan lain yang disebut QUIC Crypto. Salah satu inovasi menarik ada metode baru untuk mempercepat jabat tangan. Setelah membuat sesi aman dengan server, klien dapat menggunakan kembali informasi dan memperbaiki waktu “nol” jabat tangan, yaitu 0-RTT. Trik ini kemudian dimasukkan dalam protokol TLS 1.3.

Bisakah saya akhirnya mengetahui apa HTTP / 3 itu?

Hampir.

Sekarang kami mengerti cara kerja standardisasi. Jadi, pertimbangan GQUIC berjalan sesuai dengan skenario yang sama. Pada Juni 2015, konsep draft-tsvwg-quic-protocol-00 pertama , berjudul "QUIC: Transport Berbasis UDP yang Aman dan Andal untuk HTTP / 2," diperkenalkan. Tetapi jangan lupa bahwa pada akhirnya sintaks protokol hampir dibawa ke kompatibilitas dengan HTTP / 2.

Google telah mengumumkan bahwa "BoF akan diadakan pada pertemuan IETF 93 di Praha." Jika Anda tertarik dengan apa itu BoF, silakan merujuk ke RFC 6771 . Singkatnya, BoF ( Burung Bulu ) adalah pertemuan informal di sebuah konferensi.

Sebagai hasil dari diskusi dengan IETF, diputuskan bahwa QUIC memiliki banyak keuntungan di tingkat transportasi, Anda harus memisahkan protokol ini dari HTTP dan memperkenalkan kembali pemisahan yang jelas antara lapisan. Selain itu, untuk protokol ini mereka memutuskan untuk mengembalikan jabat tangan berdasarkan TLS (yang tidak terlalu buruk, karena pada saat itu TLS 1.3 dengan skema 0-RTT telah dikembangkan).

Sekitar setahun kemudian, pada tahun 2016, satu set draft baru dirilis:

Di sinilah kebingungan muncul lagi: draft-shade-quic-http2-mapping-00 disebut "HTTP / 2 Semantik Menggunakan QUIC Transport Protocol" dan menjelaskan "HTTP / 2 Semantic Mapping over QUIC". Namun, ini nama yang salah. Inti dari HTTP / 2 adalah mengubah sintaks dengan tetap mempertahankan semantik. Selain itu, "HTTP / 2 by gQUIC" tidak pernah menjadi deskripsi akurat tentang sintaks, karena alasan yang telah saya uraikan sebelumnya. Ingatlah hal ini ketika menjadi akrab dengan acara mendatang.

Versi QUIC dari IETF ini harus menjadi protokol transport yang sama sekali baru. Ini adalah perusahaan yang serius, sehingga IETF mencoba untuk mengevaluasi minat proyek dari para anggotanya. Untuk melakukan ini, pada pertemuan IETF 96 di Berlin pada tahun 2016, sesi BoF ( slide ) diadakan. Saya cukup beruntung untuk menghadiri pertemuan itu secara pribadi, yang menarik ratusan peserta, sebagaimana dibuktikan oleh foto Adam Roach . Akibatnya, tercapai konsensus: QUIC akan diadopsi dan distandarisasi oleh IETF.

Draf pertama IETF QUIC draft-ietf-quic-http-00 untuk menerjemahkan HTTP ke transport QUIC secara logis menyederhanakan nama protokol menjadi "HTTP over QUIC" (HTTP over QUIC). Sayangnya, pekerjaan itu tidak selesai, jadi istilah HTTP / 2 yang berbeda digunakan di seluruh organisasi. Mike Bishop, editor repositori draft standar baru, melihat masalahnya dan mulai memperbaiki referensi HTTP / 2 yang salah. Dalam versi protokol berikutnya, deskripsi berubah menjadi "pemetaan semantik HTTP atas QUIC".

Secara bertahap, seiring waktu dan versi yang lebih baru, istilah "HTTP / 2" mulai digunakan lebih jarang, jika perlu, hanya menunjuk ke RFC 7540 . Dua tahun kemudian, pada Oktober 2018, versi ketujuh belas rancangan (nomor 16) dirilis. Meskipun protokol HTTP over QUIC menyerupai HTTP / 2, pada dasarnya ini adalah sintaks HTTP yang independen dan tidak kompatibel. Namun demikian, bagi orang-orang yang tidak memonitor pekerjaan IETF (dan ini adalah persentase yang sangat besar dari populasi dunia), judul dokumen tidak mencerminkan perbedaan ini. Salah satu tugas utama standardisasi adalah promosi komunikasi dan interoperabilitas. Dan hal yang sederhana seperti penamaan telah menjadi penyebab utama kebingungan di masyarakat.

Ingat apa yang dikatakan pada tahun 2012: "Hanya HTTP / 2.0 berarti format tidak kompatibel dengan HTTP / 1.x untuk transportasi." IETF telah mengikuti preseden ini. Setelah banyak diskusi sebelum dan selama konferensi IETF 103, sebuah konsensus masih dicapai untuk mengubah nama "HTTP over QUIC" menjadi HTTP / 3.

Dunia menjadi lebih baik, dan kita bisa beralih ke diskusi yang lebih penting.

Tetapi RFC 7230 dan 7231 tidak setuju dengan definisi semantik dan sintaksis Anda!

Terkadang nama dokumen bisa membingungkan. Berikut adalah HTTP docs yang menjelaskan sintaks dan semantik:

RFC 7230 - Hypertext Transfer Protocol (HTTP / 1.1): Sintaks dan Perutean Pesan
RFC 7231 - Hypertext Transfer Protocol (HTTP / 1.1): Semantik dan Konten

Dengan nama-nama seperti itu, dapat diasumsikan bahwa semantik dasar HTTP adalah khusus untuk versi HTTP tertentu, yaitu, HTTP / 1.1. Tapi ini adalah efek samping acak dari pohon keluarga HTTP. Berita baiknya adalah bahwa kelompok kerja HTTPbis sedang mencoba menyelesaikan masalah. Beberapa anggota WG yang berani memulai putaran lain untuk merevisi dokumen. Pekerjaan ini sedang dilakukan saat ini dan dikenal sebagai karya HTTP Core (Anda mungkin pernah mendengar tentang workgroup ini dengan nama HTTPtre atau HTTPter: semuanya ambigu di sini juga) Upaya mereka akan memungkinkan Anda untuk mengompres enam draf menjadi tiga:

HTTP Semantics (draft-ietf-httpbis-semantics)
Caching HTTP (draft-ietf-httpbis-caching)
HTTP / 1.1 Sintaks dan Perutean Pesan (draft-ietf-httpbis-messaging)

Sebagai bagian dari kerangka kerja baru ini, menjadi lebih jelas bahwa HTTP / 2 dan HTTP / 3 adalah definisi sintaksis untuk semantik umum HTTP. Ini tidak berarti bahwa mereka tidak memiliki fungsi mereka sendiri di luar sintaks, tetapi ini akan membantu dalam diskusi lebih lanjut.

Menyatukan semuanya

Artikel ini secara dangkal menggambarkan proses standardisasi HTTP di IETF selama tiga dekade terakhir. Tanpa secara khusus menyentuh rincian teknis, saya mencoba menjelaskan bagaimana kita sekarang sampai di HTTP / 3. Jika Anda melewatkan bagian tengah dan mencari esensi dalam satu frasa, maka ini dia: HTTP / 3 hanyalah sintaks HTTP baru yang berfungsi pada IETF QUIC, transportasi multipleks dan aman berdasarkan UDP . Ada banyak nuansa teknis yang menarik, tetapi Anda harus menundanya untuk lain waktu.

Kami memeriksa langkah-langkah penting dalam mengembangkan HTTP dan TLS, tetapi terpisah satu sama lain. Sekarang di akhir artikel kami menerbitkan cladogram lengkap lagi. Anda dapat dengan tenang dan hati-hati mempelajarinya dalam suasana yang nyaman. Dan untuk supersisten: ini adalah versi yang sepenuhnya lengkap, termasuk konsep .

HTTP / 3: dari root ke ujung