Mengunggah video berukuran dua gigabita melalui WiFi kedai kopi adalah sebuah bentuk optimisme. Anda melihat bilah kemajuan merayap menuju tujuh puluh persen, lalu koneksi berkedip. Unggahan gagal. Saat Anda mencoba lagi, server mengharapkan file yang benar-benar baru. Anda mulai dari nol. Bagi siapa pun yang membangun aplikasi yang menangani video buatan pengguna, ini bukanlah kasus langka. Ini adalah hal yang lumrah. Protokol tus dibangun khusus untuk mengatasi masalah ini. Ini adalah standar terbuka yang berjalan di atas HTTP biasa dan memberikan "ingatan" pada proses unggah. Saat jaringan pulih, transfer file akan berlanjut tepat di tempat ia terhenti.
Mengapa Unggahan Standar Gagal
Unggahan file multipart standar memperlakukan seluruh payload sebagai satu transaksi tunggal. Browser atau aplikasi membuka koneksi TCP, mengalirkan byte, dan mengharapkan respons 200 OK di akhir. Jika koneksi terputus karena pengguna beralih dari LTE ke WiFi, atau karena laptop masuk ke mode tidur, server tidak memiliki cara untuk mengetahui byte mana yang telah sampai dengan aman. Sebagian besar framework hanya membuang data parsial tersebut. Pengguna hanya ditinggalkan dengan formulir yang gagal dan suasana hati yang buruk. File video memperparah rasa sakit ini karena ukurannya besar, sering diunggah dari perangkat seluler pada jaringan yang tidak stabil, dan sering kali dikodekan dalam format yang tidak dapat diproses sampai seluruh file utuh.
Bagaimana Tus Mengubah Segalanya
Tus memikirkan ulang proses unggah sebagai percakapan yang memiliki status (stateful) alih-alih pengiriman satu kali jalan. Alih-alih mengirimkan file dalam satu aliran byte yang berkelanjutan, klien memecah payload menjadi beberapa chunk. Yang lebih penting, server mengingat offset, yaitu jumlah byte tepat yang telah diterimanya sejauh ini. Persistensi status inilah yang memungkinkan adanya kelanjutan (resumption). Protokol ini sengaja dibuat sederhana. Ia tidak memerlukan WebSockets, gRPC, atau SDK proprietary. Ia menggunakan metode HTTP yang sudah Anda kenal.
Tiga Permintaan yang Menggerakkan Kelanjutan Unggahan
Setiap unggahan tus mengikuti alur yang dapat diprediksi.
Pertama, klien mengirimkan permintaan POST ke endpoint tus yang sudah diketahui. Header mendeskripsikan file tersebut. Header Upload-Length menyatakan ukuran akhir dalam byte, dan metadata opsional seperti nama file atau tipe konten dikirimkan dalam header Upload-Metadata sebagai daftar pasangan kunci-nilai (key-value pairs) terpisah koma yang dikodekan dalam base64. Server membuat sumber daya unggahan kosong dan merespons dengan status 201 Created ditambah header Location yang mengarah ke URL unik. URL ini adalah alamat unggahan tersebut selama sisa masa hidupnya.
Berikutnya adalah permintaan PATCH. Klien mengirimkan chunk data biner mentah ke URL unik tersebut. Dua header penting menyertai payload tersebut. Content-Type harus berupa application/offset+octet-stream, dan Upload-Offset harus sesuai dengan posisi byte tempat chunk ini dimulai. Server memverifikasi bahwa offset tersebut sesuai dengan catatannya sendiri. Jika tidak sesuai, server mengembalikan 409 Conflict, untuk melindungi dari status yang korup. Jika semuanya selaras, server menambahkan byte tersebut, memperbarui offset internalnya, dan mengembalikan respons 204 No Content bersama dengan Upload-Offset yang baru. Ukuran chunk dapat dikonfigurasi, tetapi praktik umum berada di antara beberapa ratus kilobita hingga beberapa megabita. Chunk yang lebih kecil menciptakan lebih banyak overhead HTTP tetapi pulih lebih cepat dari kesalahan. Chunk yang lebih besar mengurangi round trips tetapi membuang lebih banyak bandwidth jika gagal di tengah jalan.
Terakhir, permintaan HEAD. Ini adalah jaring pengaman. Jika sebuah PATCH gagal di tengah-tengah chunk, misalnya setelah tiga megabita dari potongan lima megabita, koneksi terputus. Saat klien mendapatkan kembali akses jaringan, ia mengirimkan permintaan HEAD ke URL unggahan. Server membalas dengan Upload-Offset saat ini. Klien membandingkan