Iværksætter som (cloud?) Service

Jeg må erkende at det har været en noget anderledes sommerferie end det plejer.

Ret meget af ferien er gået med en ny græsplæne (det projekt dukker op ovre i PHloggen på ing.dk) men den sidste uge var jeg i "Ausfart" ⅓ nede i det Sydlige Udland for at deltage en en "HTTP Workshop".

Jeg har ikke tal på hvor mange gange jeg har kørt igennem Münster med tog eller forbi "Ausfart Münster" skiltet på autobahn'en, men jeg er ikke af den opfattelse at jeg er gået glip af noget: Münster er en tysk by der har øl, pølser, sauerkraut, ting der blev bombet men repareret, ting der blev bombet men ikke repareret, folk der leger Pavarotti-light foran operaen og de tager ikke udenlandske kreditkort.

Men HTTP Workshop'en var god, lærerig og produktiv for alle parter tror jeg. Man ved at det har været turen værd når mange diskussioner ender med "Ohh... I didn't think of that".

Alle i rummet havde samme overordnede mål: At få web-traffik til at virke bedre, men der er relativt langt fra en "traffic-designer" på de helst store sites til folk der laver Internet of Shi^H^H^HThings, en målgruppe der desværre kun var repræsenteret af mig (som standin) og præcis hvad "bedre" er afhænger meget af hvad man måler på.

Meget til min lettelse var der faktisk enighed om at det var en fejl at stable HTTP/2 ovenpå en enkelt TCP forbindelse, fordi ethvert pakketab forsinker alt hvad der er på forbindelsen, i modsætning til HTTP/1 hvor de (typisk) 5 andre TCP forbindelser ikke rammes.

Men omvendt er HTTP/2 en forbedring på andre områder, f.eks har den bedre chancer for at slippe ud af TCP's slow-start regime.

Men på den lange bane holder det ikke: TCP er designet til at flytte en stor datastrøm, HTTP prøver at flytte mange små.

Fremtiden hedder UDP og der er både tekniske og politiske problemer at løse. Googles "QUIC" er en interessant prototype og forhåbentlig bliver den hverken forgyldt som TCP2 eller HTTP3 af et panikslagent IETF, på samme måde som SPDY blev til HTTP2.

Vel hjemme igen og på plads bag skrivebordet er jeg nødsaget til at citere Britney Spears, fordi Varnish har grundlagt endnu et firma.

Jeg har ingen ide om hvor mange mennesker der alene har et job på grund af Varnish idag, men i den håndfuld af virksomheder der er startet direkte på Varnish nærmer tallet sig 4-5 hundrede og det gør ikke frygten for "The Fraud Police" mindre her på addressen.

Jeg håber at I også har haft en god sommer?

phk

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Carsten Gehling

"og de tager ikke udenlandske kreditkort."

Og det er de ikke ene om. Stort set hele Tyskland er håbløs bagud, hvad angår elektronisk betaling. Det er svært at begå sig i Berlin i længere tid af gangen, uden at have kontanter i lommen, og det samme gør sig gældende i de fleste (mange) byer, som jeg har besøgt dernede.

VISA/MC og venner er simpelthen for dyrt i gebyr for butikkerne til, at de vil acceptere det som betalingsmiddel (med mindre du køber for større beløb).

  • 2
  • 0
#3 Poul-Henning Kamp Blogger

Bufferbloat har bestemt en masse med det at gøre, men det fundamentale problem er at FTP er bygget til TELNET og FTP.

TELNET er nogle få bytes hist og her og en fornuftig kort retransmissions tid.

FTP handler om at "fylde røret" uden at vælte resten af nettet.

HTTP er ingen af delene: Det handler om op til hundredevis af requests/response transaktioner i parallel.

  • 2
  • 0
#4 Claus Pedersen

Tillykke med det nye projekt.

Section.io ser spændende ud og helt klart noget vi ville kunne bruge. Dog ikke før I er klar med valg af POP.

Vi har vores webservere i DK, men har lokale Varnish installationer i forskellige lande. På den måde får vi cached content tæt på brugerne. section.io kunne være en let måde for os at styre det på, hvis vi kunne vælge hvilket land et givent site skulle køre i.

  • 0
  • 0
#6 Lars Bjerregaard

section.io ser interessant ud. Det er vel sådan set "Varnish as a service"?

Må jeg tillade mig at være ignorant og stille det dumme spørgsmål: Hvorfor er UDP fremtiden, når langt de fleste applikationer (ignorerer video og audio) vel stadig væk gerne vil have at alle pakkerne ankommer og helst i ordnet rækkefølge?

  • 2
  • 0
#7 Jacob Christian Munch-Andersen

Må jeg tillade mig at være ignorant og stille det dumme spørgsmål: Hvorfor er UDP fremtiden, når langt de fleste applikationer (ignorerer video og audio) vel stadig væk gerne vil have at alle pakkerne ankommer og helst i ordnet rækkefølge?

Internettet kan basalt set ikke garantere nogen af delene, TCP har bare en række procedurer til at rette op på det, defineret som en del af protokollen. Vi kan sende vores trafik i UDP pakker, og gøre præcis de samme ting uden for protokollen, og ende med præcis det same featureniveau.

Fordelen ved at bruge UDP er at vi nu ikke er tvunget til at gøre præcis det samme som TCP. Eksempelvis kan vi med lidt smart matematik sende nogle få redundante pakker som kan erstatte en hvilken som helst tabt pakke, på den måde kan vi i de fleste tilfælde undgå at skulle sende "jeg mangler en pakke"-beskeder, med deraf følgende forsinkelse. Den eksakte protokol kan justeres, alt efter formål, til at vægte båndbredde versus latency. Hvis pakkerne ikke kommer i rækkefølge kan vi i nogle tilfælde begynde at behandle data i den rækkefølge det kommer. Og helt generelt kan vi komme ud over at TCP basalt set er et meget forsigtigt design, som hellere sender én protokolpakke for meget end én for lidt.

  • 2
  • 0
#8 Jens Jönsson

Måske et dumt spørgsmål, har ikke læst så meget om Varnish, men kan jeg gemme flere webservere bag en firewall og lade Varnish svare på den offentlige IP-adresse, for alle domæner på alle webservere, som har private IP-adresser ?

  • 0
  • 0
#10 Peter Makholm Blogger

Hvorfor er UDP fremtiden, når langt de fleste applikationer (ignorerer video og audio) vel stadig væk gerne vil have at alle pakkerne ankommer og helst i ordnet rækkefølge?

Både ja og nej. Hvis vi ser på det enkelte HTTP-request, så er de fleste applikationer nok interesseret i at svaret kommer pænt ordnet. Men hvis vi ser på en moderne webapplikation, så vi den typisk sende mange HTTP-requests og er forberedt på at håndtere svarene asynkront.

Det kan vi løse på to måder 1) åbne flere parallelle, eventuelt kortlivede, TCP-forbindelser eller 2) implementere multiplexing af flere datastrømme oven på TCP. Ingen af løsningerne arbejder specielt godt sammen med TCP.

Alternativet er derfor en erstatning for TCP, som ikke arver det utidssvarende designvalg bag TCP. Dette alternativ kan enten baseres rå IP-pakker eller på UDP-pakker. Ud fra en teoretisk overvejelse ville det nok være indlysende at lave et protokollag direkte over IP-laget, men i praksis er dette umuligt.

Poul-Henning, hvad er din holdning til SCTP?

  • 1
  • 0
Log ind eller Opret konto for at kommentere