Open Protocol tus, how it work ?
People are sharing more and more photos and videos every day. Mobile networks remain fragile however. Platform APIs are also often a mess and every project builds its own file uploader. There are a thousand one-week projects that barely work, when all we need is one real project. One project done right.
We are the ones who are going to do this right. Our aim is to solve the problem of unreliable file uploads once and for all. tus is a new open protocol for resumable uploads built on HTTP. It offers simple, cheap and reusable stacks for clients and servers. It supports any language, any platform and any network.
It may seem to be an impossible dream. Perhaps that is because no-one has managed to solve it yet. Still, we are confident and we are going to give it our best shot. Join us on GitHub and help us make the world a better place. Say “No!” to lost cat videos! Say “Yes!” to tus! (From tus.io)
》Improve reusable upload file protocol
We have various way to upload files, but they have different behavior on the cross platform, tus hopes to be cross platform and reliably.
》Just HTTP
The HTTP is for us to connect internet everyday, and tus is not the new connection protocol, its build on HTTP. It simple, cheap and reusable on any platform.
》Talk to server first
First, client should talk to the server when it will upload something. Client send POST method to server /uploads and two request headers Content-Length and Upload-Length; The Content-Length set zero in the first time request, the Upload-Length is talked to server how much file size will receiving. The server will be preparing it.
》Server respond an unique ID
The server received file upload request, and generated a random key for incoming file. The tus had not specific how to generate unique ID, it’s implement from server owner.
So, we can generate key easily by nodejs crypto, code like
crypto.randomBytes(32).toString('hex'); // 2b81ac12acc9af06fb6...Great, we finish the first phase.
》Client ready to upload file
Client send the second request by unique ID which generated from server, but it should be care about PATCH method, upload request method is PATCH NOT POST. And the request with two headers Content-Length and Upload-Offset, this time Content-Length is setting the file total size 10880(bytes) and Upload-Offset is ready for use in reusable upload we setting zero for first time.
》Server received data and save
Server respond the 204 No Content Status and Upload-Offset to client to check the file is upload completed or not.
Now we upload file successfully.
》When I lost connection during upload
The tus is savior when we lost the connection, the client can send a request to ask server how the file progress now ? it’s easily use HEAD method and file unique ID to server.
》Server respond file status
The server respond Upload-Offset 5000, it’s mean the file is only upload 5000 bytes but the origin file is 10880 bytes, so it will be continuing upload the remains data chunk by client until Upload-Offset is 10880 bytes.
》Continuing to upload file
This time client didn’t need to upload whole file size, it just upload the remains bytes start from Upload-Offset. Because origin file size is 10880 but we upload 5000 bytes already, so 10880 minus 5000 equals 5880, and it mean we can just start from 5001bytes to 10880bytes.
》Last check upload offset from server
When successfully upload file, server respond the 204 No Content and Upload-Offset header. Check it should be the same with origin upload file size.
Hope the article can help you, welcome to discussion :-)
