Preuzeto sa https://github.com/quicwg

HTTP/3 Intro

HTTP/3 protokol je nastavak HTTP/2 a za razliku od njega koristi QUIC koji je baziran na UDP. Razlog koriscenja UDP jeste nisko kasnjenje, brzina isporuke dok kompletan HTTP protokol sa svim porukama, kodovima, standardom ostaje isti. Vazno je napomenuti da je QUIC "nastavak" na TLS 1.3 gdje ima lista prosirenja (npr ALPN i slicno) TLS protokola. Tako da je moguce koristiti na drugacije nacine TLS.

Brzina, benchmark i kasnjenje HTTP/3

Prema stranici , performanse su:

Connection Setup Time: HTTP/1 (50–120ms), HTTP/2 (40-100ms), HTTP/3 (20–50ms in low-latency networks)

File Download (1MB with 2% packet loss): HTTP/1 (1.8s), HTTP/3 (1.2s)

Page Load Latency (mobile 3G): HTTP/1 (600ms), HTTP/3 (300ms)

HTTP/2 unaprijedio web performanse sa omogucavanjem visestrukih zahtjeva i odgovora na jednoj konekciji, redukujuci kasnjenje. HTTP/3, baziran na QUIC, unapredjuje brzinu i smanjuje kasnjenje kroz zamjenu TCP sa UDP-baziranim-transportom, cineci ih eksponencijalno brzim, posebno za real-time aplikacije i mobilne uredjaje.

Prema testu sa stranice imamo performanse za poredjenje:

Ucitavanje tipicno E-commerce stranice (100 resursa):

HTTP/1.1: • Otvara 6–8 paralelnih konekcija • Sekvencijalno procesuiranje svake konekcije• Totalno vrijeme ucitavanja: ~8 sekundi

HTTP/2: • Jedna konekcija sa multipleksiranje • Kompresija headera i push sa servera • Totalno vrijeme ucitavanja: ~4 seconds

HTTP/3: • QUIC eliminise ostala uska grla • Bolje handlovanje izgubljenih paketa • Totalno vrijeme ucitavanja: ~3.2 seconds

Provjera browsera/web servera i instalacija HTTP/3 na Ubuntu 24.04/Nginx

Provjera Browsera

Jedan od prvih uslova jeste da nas browser podrzava HTTP/3 tako sto odemo na stranicu: https://quic.nginx.org/ ( lista browsera i verzija koji podrzavaju HTTP/3 )

Instalacija zadnje verzije nginx (1.29.0) na Ubuntu 24.04

U ovom dijelu cu zaobici podesavanja nginx konfiguracije, firewalla - vec cu direktno ici na podesavanja i instalaciju nginx.

Koraci za instalaciju zadnje verzije nginx na Ubuntu (preuzeto sa stranice):

sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
    | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg

Poslije zadnje komande se ocekuje output:

pub   rsa4096 2024-05-29 [SC]  8540A6F18833A80E9C1653A42FD21310B49F6B46
uid    nginx signing key 

pub   rsa2048 2011-08-19 [SC] [expires: 2027-05-24] 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62
uid    nginx signing key 

pub   rsa4096 2024-05-29 [SC]  9E9BE90EACBCDE69FE9B204CBCDCD8A38D88A2B3
uid    nginx signing key 

Dalji koraci (koristimo mainline repo, tj zadnju verziju nginx-a):

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/mainline/ubuntu `lsb_release -cs` nginx" \
    | sudo tee /etc/apt/sources.list.d/nginx.list

U slucaju da zelimo stabilnu verziju, komanda umjesto gornje:

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" \
    | sudo tee /etc/apt/sources.list.d/nginx.list

Sljedeci korak:

echo -e "Package: *\nPin: origin nginx.org\nPin: release o=nginx\nPin-Priority: 900\n" \
    | sudo tee /etc/apt/preferences.d/99nginx

sudo apt update
sudo apt install nginx

Da provjerimo instalaciju:

nginx -v

output: nginx version: nginx/1.29.0

nginx -V
output: nginx version: nginx/1.29.0
built by gcc 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04)
built with OpenSSL 3.0.13 30 Jan 2024
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid --lock-path=/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module ***--with-http_v3_module*** --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/home/builder/debuild/nginx-1.29.0/debian/debuild-base/nginx-1.29.0=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/home/builder/debuild/nginx-1.29.0/debian/debuild-base/nginx-1.29.0=/usr/src/nginx-1.29.0-1~noble -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'

Gdje se nalazi u zadnjem dijelu dio "--with-http_v3_module" koji nam omogucava HTTP/3.

Podesavanje nginx

Sljedeca podesavanja mozete naci na stranici: https://nginx.org/en/docs/quic.html

Da bi smo podesili nginx da radi, imamo dva dijela podesavanja. Prvi je nginx.conf a drugi je nas server/domena koji trebaju podesavanja.

Brisemo liniju(nove verzije ne koriste vise ovo): ssl on;

Dodajemo:

quic_retry on;

ssl_early_data on;

quic_gso on;



U dijelu:

server {

        listen 443 quic reuseport;

        listen 443 ssl;

      index index.php; #u slucaju da imamo ovo podeseno, podesiti PHP

       location / {

        add_header Alt-Svc 'h3=":443"; ma=86400';

       }

      location ~ \.php$ {

                add_header Alt-Svc 'h3=":443"; ma=86400';

      }

}

Poslije ovoga mozemo izvrsiti komandu nginx -t gdje bi trebalo da izadje:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Onda mozemo i systemctl restart nginx.

Gdje mozemo vidjeti na UDP portu:

Testiranje web servera

Testiranje web servera mozemo uraditi na (mozete izabrati neku drugu domenu, ova je podesena kao test): https://http3check.net/?host=https%3A%2F%2Fwww.vladimircicovic.com%2F

Sa Inspect(Chrome) mozemo na Networking vidjeti ucitavanje H3 tj HTTP/3:

Testiranje sa cuRl:

curl --http3-only -vvvv https://www.vladimircicovic.com/

ili u slucaju da nema http3 prebaci na http2 il http 1.1

curl --http3 -vvvv https://www.vladimircicovic.com/

starija verzija cuRl-a bi mogla raditi sa:

curl --alt-svc altcache -vvvv https://www.vladimircicovic.com/

Dodatne analize naseg TLS podesavanja, mozemo na: https://www.ssllabs.com/ssltest/analyze.html?d=www.vladimircicovic.com

Preuzeto sa https://www.linkedin.com/pulse/why-developer-should-learn-devops-sandip-das/

Svi su nekad u nekom momentu postali DevOps. Logicno su ili presli il poceli da rade sa DevOps pozicijama/alatima/kulturom.

Ja sam postao DevOps jer nisam izbora. Firma za koju sam radio 2012 godine je odlucila da zatvori poslovnicu sa 30ak radnika, ukljucujuci i mene. Jedini nacin da preokrenemo situaciju je bila da neko pocne da radi projekte.

Tim u kojem sam bio (sistem administratori) imao je princip "mi nista ne programiramo" nametnuto od strane tim lidera. Zasto i kako, takvo nesto ostace trajno nepoznato. Moje vidjenje te situacije je bilo da ljudi koji su "pravi" sistem admini ne rade "programiranje" (??)

Projekti su bili izlazna putanja iz problema.

Unutar tih projekata imao sam klijenta koji je htio da testira servis, ima produckiju. Logicno je bilo da koristim bazu koda, a unutar iste da imam odvojene branchove. Dev i production.

A posto je sve to manualno radjeno, onda je bilo logicno da uradim automatizaciju (testiranje servisa, deploy servisa). Ovo je radjeno sa skriptama. Shvatio sam da ako stavim gomilu koda, da ce mi se "odbiti" od glavu. Onda sam poceo da dodajem na dnevnom nivou manje koda, deploy za test, testovi. I onda cekam da klijent odobri date izmjene kako bi islo u produkciju.

Projekat koji sam radio je bio za Vodafon, pokrivao je citavu Njemacku i bio je muzicki servis za prodaju i slusanje muzike. Tehnicki je bio nesto sto sam kombinovao sve svoje vjestine i znanje. A sljedece apliciranje 2016 god za firmu u Holandiji, osoba koja je vidjela moj CV je zvala prvo mene da me pita da li sam radio taj projekat (jer nije vjerovao) a onda je zvao mog ex sefa (jer i dalje nije vjerovao da sam uradio taj projekat).

Preuzeto sa https://www.tripwire.com/sites/default/files/Security-at-the-Speed-of-DevOps.jpg

Projekat je bio prijedlog jedne firme (koja nije povezana sa Vodafonom) za 15ak kompanija u svijetu. To nisam znao dok projekat nije bio zavrsen. Tu su bili Amazon, Akmai, Leaseweb i jos 10-13 CDN firmi koje su imale preko 1000 softwerskih inzinjera. Ako mislite da je mozda u pitanje znanje pa ne. Rekao bih sreca. U tim kompanijama nikada ne fali znanja i ljudi sa vjestinama.

Vecinu stvari koje sam radio, nisam radio iz nekog "ma ovo je kul" vec sto je prakticno. I to sto je bilo prakticno je zapravo bilo DevOps (Ci/CD, pipeline, ostalo)

Taj projekat je spasio firmu, 50ak radnih mjesta (van BiH takodje, ne samo ovih 30ak u BiH)

Danas imam neko dublje shvatanje DevOpsa zbog sebe.

2014 godine cu saznati da sam DevOps kroz interakciju sa drugim ljudima i firmama.

DevOpsDays Berlin 2013

It was the end of 2011 - I apply to a new company. System Administrator position. Inside of this company - I would stay for the next 4 years. The only reason why I leave this company, I leave Bosnia and Herzegovina. Like most of the youth people who don't want to live in Bosnia and Herz - simple to say there is no future with the current political system and process. I describe the situation in Corruption in RS and how IT was destroyed because of a lack liberal market.

So back to story. Inside of this company - I got 2 more co-worker system administrators. One of them was team-lead. Complete decision and the rest of the process were under one person - team leader. The company was doing a content delivery network. One of the first in the world. Ipercast. From there start Akamai CDN. Anyway - so the position of sysadmin simple described: just process(add user, troubleshooting, etc) at that time. So no coding (little shell script but not more than that).

Complication

So after 5 months, we got visited by the owner of the company. In front of the complete company, he tells us that our BU(business unit) in Bosnia and Herz would be closed in the next 3 months. One of the smartest people in the room asked: "what we could do to change the situation?" He was a front-end developer. The answer is "little or nothing".

In that time - I did not know that most of the software project for back-end was rejected by our team leader. He did not like coding/programming. He was bad at that. Next 2-3 weeks after this meeting, one of my CTO try to ask me could I build some shell script that would make the database/list and send it to some HTTP API. He asks me because the rest of the team (other 2 guys) did not want to spend time on that.

After the script was done - he asks me to review some projects that the company has. I did not know what was talking about - so I ask him to show me. In a moment I got the idea that we have outside BU that bring us projects - but no one in the company (actually sysadmin team) did not want to deal with it. Reason: The team leader was not able to do programming.

My CTO picks up the most paid project from the list. It was a huge list of TODO. He explains to me that we already fail this part once. Ex-CTO (a co-worker of my CTO and my ex-CTO) tries to build one project in PHP and it fails. He has 12 years in this company and he could do many things that complete my sysadmin team. But also he did not find a proper way to build this project. It happens. People get tired of duty or get pissed off by owners, or just want to leave the company and don't care at all.

So, I review things: he uses PHP, Apache. Already it makes me cry. I move to Lighttpd. Try to build a different approach. Then I got an idea. Why not build the C plugin/module for Lighttpd? Why? Simple it is faster than PHP. It has better and faster work.

The task was like this: provide unique access to some file with timelimit and IP limit. In 2 days, the demo was done.

Germans BU ask the company that orders this project to start testing. After testing they just ask me how much time I need? I was not sure so take 1-3 days to review complete TODOs and to get an idea about the project. Simple: Download files but each is encrypted with unique key as URL also that has limited values(time, IP, start limit), with token. Also, preview files as streaming services.
I told my CTO we need like 2 months. And he responds with taking 6 months. I was like ... ok.

German BU shows my results of testing: - 100% unique token URLs - 50 clients - 26 ms response - 25 clients - 25 ms response.

and before this was: - 60% unique token URLs - 50 clients - 3-sec response - 25 clients - 1 sec response.

This solution was made in PHP and speed as to how it was worked - was not so the best way to do. On this demo - my company earns half a million euros for development and we stay in the game. Later it would be used in different companies (RAI IT, Sony Germany, etc) for streaming, live streaming - all well know the platform.

DevOps thinking and implementation

DevOps have 2 parts: tools and processes. Most of the process comes as logical, as must be like this. Some processes got improved later.

From the start - we implement the best way to move from test server to production. So we optimize all parts: building, testing, moving to production.

It was natural to be done like that way. I did not saw the issue. The only thing we did not do is rollback. But we did have commit inside of git so we could reverse to old code. Also moving from test server to production - after client review - was manual. Why? Simple on the start if goes wrong I want to know ASAP and stop updating. We use the load-balancing and 2 servers.

It was June 2013 - the project was finished and the company was saved. As also 25 working places. In the first 24h, there were 150 million unique IPs. One of the rare stories that I am proud of. I use all my skills to get this product to Vodafone Germany (yea, we did not know until last day). C/Java/Shell scripting, Cryptography, Linux engineering, network, NFS, rtmp/rtp/htps low-level manipulation, and others. It was a really good product that was in usage for a long time. One thing I did not mention: after I finish the complete project they told me this solution would be used for complete Germany. Then it was used for Vodaphone - and they show me all documents from other companies who apply: Akamai, Amazon, Leaseweb, MaxCDN, and 10 more. My solution was 100% that they asked. The hardest part was encryption on the fly. Each time file is downloaded to the client - it has a unique key for decryption. So mp3 was not possible to share without a key. With all my Linux engineering tricks we got ~400 files per second. And it was not bad at all.

Later, thinking and approach would be part of DevOps. Many things - but still a good way of delivering code and services.