From dc4c3c46e44b4632b8963a7a8486adff92162880 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?G=C3=B6ran=20Uddeborg?= Date: Tue, 23 Aug 2022 22:10:00 +0200 Subject: [PATCH] Minor language corrections in the Swedish version. --- sv/part1.md | 6 +++--- sv/part10.md | 2 +- sv/part11.md | 2 +- sv/part2.md | 10 +++++----- sv/part3.md | 8 ++++---- sv/part4.md | 6 +++--- sv/part5.md | 26 +++++++++++++------------- sv/part6.md | 30 +++++++++++++++--------------- sv/part7.md | 18 +++++++++--------- sv/part8.md | 35 +++++++++++++++++++---------------- 10 files changed, 73 insertions(+), 70 deletions(-) diff --git a/sv/part1.md b/sv/part1.md index be72c52..ab9a92c 100644 --- a/sv/part1.md +++ b/sv/part1.md @@ -6,9 +6,9 @@ sedemera gjordes om och breddades till ett fullt utvecklat dokument med alla detaljer och riktiga förklaringar. RFC 7540 är det officiella namnet på den slutliga http2-specifikationen och den -blev publicerad den 15:e maj 2015: https://www.rfc-editor.org/rfc/rfc7540.txt +publicerades den 15:e maj 2015: https://www.rfc-editor.org/rfc/rfc7540.txt -Alla misstag i det är dokumentet är mina egna och resultatet av mina fel. Peka +Alla misstag i det här dokumentet är mina egna och resultatet av mina fel. Peka gärna ut dem så åtgärdar vi dem till en kommande uppdatering. I det här dokumentet har jag försökt att konsekvent använda ordet "http2" för @@ -18,7 +18,7 @@ ett bättre flöde i texten. ## 1.1 Författaren -Mitt namn är Daniel Stenberg och jag jobbar för Mozilla. Jag har arbetat med +Mitt namn är Daniel Stenberg. Jag har arbetat med open source och nätverk i över tjugo år i otaliga projekt. Möjligvis är jag mest känd för att jag är huvudutvecklaren av curl och libcurl. Jag har varit involverad i IETF och dess HTTPbis arbetsgrupp under flera år och där har jag diff --git a/sv/part10.md b/sv/part10.md index b0d7c18..1861aff 100644 --- a/sv/part10.md +++ b/sv/part10.md @@ -18,7 +18,7 @@ Skriv in “chrome://flags/#enable-spdy4" i din webbläsares adressfält och kli ## 10.2. Endast TLS -Kom ihåg at Chrom bara implementerat http2 över TLS. Du kommer endast see +Kom ihåg at Chrome bara implementerat http2 över TLS. Du kommer endast see http2 i aktion i Chrome när du går til https://-sajter som erbjuder http2-support. ## 10.3. Se HTTP/2-anvädning diff --git a/sv/part11.md b/sv/part11.md index cb8d704..646a611 100644 --- a/sv/part11.md +++ b/sv/part11.md @@ -10,7 +10,7 @@ webbsajter och vi tänker fortsätta med det för http2 också. curl använder det separata biblioteket [nghttp2](https://nghttp2.org/) för all funktionalitet i http2-lagret. curl kräver nghttp2 1.0 eller senare. -Notera att just nu skippas curl på linux inte alltid med http2-support +Notera att just nu skeppas curl på linux inte alltid med http2-support påslaget. ## 11.1. HTTP 1.x-liknande diff --git a/sv/part2.md b/sv/part2.md index bcc990d..f1cb507 100644 --- a/sv/part2.md +++ b/sv/part2.md @@ -8,7 +8,7 @@ saker att köra över HTTP hellre än att bygga något som är helt nytt och ege ## 2.1 HTTP 1.1 är stort När HTTP skapades och slängdes ut i världen ansågs det antagligen vara ett -ganska enkelt och rakt-fram protokoll, men tiden har bevisat att detta inte är +ganska enkelt och rättframt protokoll, men tiden har bevisat att detta inte är sant. HTTP 1.0 är RFC 1945 som är en 60 sidors specifikation släppt 1996. RFC 2616, som beskriver HTTP 1.1, släpptes bara tre år senare 1999, och växte avsevärt till sina 176 sidor. Trots att den redan växt så, delade IETF senare @@ -24,7 +24,7 @@ senare utökningar har lett till ett ekosystem av programvara där nästan ingen implementation någonsin implementerar allting - och det är inte ens möjligt att riktigt säga vad "allting" är. Det ledde till en situation där funktioner i protokollet som utnyttjades väldigt lite ofta inte alls implementerades - i -början - och de fall när någon faktiskt implementerade dem såg de väldigt +början - och i de fall när någon faktiskt implementerade dem såg de väldigt liten användning. Senare skapade detta interoperabilitetsproblem när klienter och servrar väl @@ -50,7 +50,7 @@ avsnitten belyser några av de existerande bristerna. När man tittar på trenden för några av de mest populära sajterna på webben idag och vad det krävs för att ladda ner deras framsidor, så ser man ett tydligt mönster. Genom åren har mängden data som behöver laddas ner gradvis -ökat till och förbi 2.1MB. Vad som är än viktigare i det här sammanhanget är +ökat till och över 2,1 MB. Något som är än viktigare i det här sammanhanget är att i genomsnitt så behövs det över ett hundra enskilda objekt för att visa varje sida. @@ -70,7 +70,7 @@ HTTP 1.1 är väldigt känsligt för fördröjningar (latency), delvis för att Pipelining fortfarande är fyllt med problem och är avslaget per default hos en stor andel av användarna. -Medan vi sett en rejäl ökning i tillgänglig bandbredd hos människor över de +Medan vi sett en rejäl ökning i tillgänglig bandbredd för användare över de senaste åren, så har vi inte sett samma förbättring i att minska fördröjningar. Länkar med stora fördröjningar, som många nuvarande mobila teknologier, gör det riktigt svårt att få en bra och snabb upplevelse av @@ -96,7 +96,7 @@ rätt kö, och ibland kan du till och med starta en ny, egen kö, men hur du än gör så kan du inte undvika att ta ett beslut och när det väl är taget kan du inte byta kö. -Skapa nya köer är också belagt med prestanda- och resurs-förluster så det +Skapa nya köer är också belagt med prestanda- och resursförluster så det skalar inte upp bra till mer än ett ganska lågt antal köer. Det finns helt enkelt ingen perfekt lösning för detta. diff --git a/sv/part3.md b/sv/part3.md index fac89ca..e638781 100644 --- a/sv/part3.md +++ b/sv/part3.md @@ -52,7 +52,7 @@ logiskt resonemang bakom. Från början sade HTTP 1.1-specifikationen att en klient endast var tillåten att använda maximalt två TCP-koppel till varje host. Så, för att inte bryta -mot specen uppfann smarta sajter nya host namn och - voilá - så kunde du få +mot specen uppfann smarta sajter nya hostnamn och - voilá - så kunde du få många fler koppel till din sajt och minska sidladdningstider. Över tid har den gränsen tagits bort och dagens klienter använder lätt 6-8 @@ -61,17 +61,17 @@ fortsätter att använda den här tekniken för att öka antalet koppel. Med ett ständigt ökande antal objekt (som jag visade tidigare) så måste ett än större antal koppel användas för att få HTTP att prestera bra och göra din sajt snabb. Det är inte ovanligt att enskilda sajter använder långt över 50 eller -upp och förbi 100 koppel tack vare den här tekniken. Färsk statistik från +upp till och över 100 koppel tack vare den här tekniken. Färsk statistik från httparchive.org visar att av de 300 000 mest populära URLerna i världen så behövs i genomsnitt 40(!) TCP-koppel för att visa sajten, och trendkurvan säger att det fortsätter växa. En annan anledning att också lägga bilder och liknande resurser på ett separat hostnamn som inte använder cookies, är att storleken på cookies idag kan bli -betydande. Genom att använda cookie-lösa bild-värdar så kan du ibland öka +betydande. Genom att använda cookie-lösa bildvärdar så kan man ibland öka prestandan enbart genom att HTTP-förfrågningarna blir så mycket mindre! -Bilden nedan visar paket-spårning och hur det ser ut när en webbläsare besöker +Bilden nedan visar paketspårning och hur det ser ut när en webbläsare besöker en av Sveriges toppsajter, och hur förfrågningarna är distribuerade över flera olika hostnamn. diff --git a/sv/part4.md b/sv/part4.md index eaf6114..f9d5202 100644 --- a/sv/part4.md +++ b/sv/part4.md @@ -17,8 +17,8 @@ practices", HTTP och mängder med protokollvarianter som aldrig kom någon vart. Inom IETF formas arbetetsgrupper (working groups) med ett avgränsat arbetsområde som jobbar mot ett mål. De etablerar en stadga med ett antal -riktlinjer och begränsningar för vad de ska åstadkomma. Alla som vill är -tillåtna att delta i diskussionerna och utvecklingen. Alla som deltar och +riktlinjer och begränsningar för vad de ska åstadkomma. Alla som vill får +lov att delta i diskussionerna och utvecklingen. Alla som deltar och säger något har samma vikt och chans att påverka utgången, och alla är där som enskilda individer. Det läggs väldigt liten vikt vid vilka företag individerna jobbar för. @@ -52,7 +52,7 @@ som i fallet för HTTP 1.1. [SPDY](https://en.wikipedia.org/wiki/SPDY) är ett protokoll som utvecklades och togs fram av Google. De utvecklade det visserligen öppet och bjöd in alla som ville att delta, men det var tydligt att de utnyttjade sin situation med att -kontrollera både en populär webbläsare och ett signifikant server-bestånd med +kontrollera både en populär webbläsare och ett signifikant serverbestånd med välanvända tjänster. När HTTPbis-arbetsgruppen bestämde att det var dags att börja jobba på http2 diff --git a/sv/part5.md b/sv/part5.md index b81ca82..9a96970 100644 --- a/sv/part5.md +++ b/sv/part5.md @@ -6,18 +6,18 @@ satte sig för att göra? De var faktiskt ganska strikta och satte ett antal begränsningar för gruppens möjligheter att förnya protokollet. -- Det måste behålla HTTP:s paradigmer. Det måste fortfarande ett protokoll där - klienten skickar förfrågningar till en server över TCP. +- Det måste behålla HTTP:s paradigmer. Det måste fortfarande vara ett protokoll + där klienten skickar förfrågningar till en server över TCP. -- http://- och https://-URLer kan inte ändras. Det kan inte göras ett nytt +- http://- och https://-URLer får inte ändras. Det får inte göras ett nytt schema. Mängden innehåll som redan använder sådana URLer är helt enkelt för stor för att tro att de kan ändras. - HTTP1-servrar och klienter kommer finnas kvar i decennier, vi måste kunna erbjuda proxys för http2-servrar. -- Därför måste proxys kunna mappa http2-funktioner till HTTP 1.1-klienter, ett - till ett. +- Därför måste proxys kunna översätta http2-funktioner till HTTP 1.1-klienter, + en till en. - Ta bort eller minska antalet valbara delar i protokollet. Det var inte riktigt ett krav men mer som ett mantra som följde med från SPDY och @@ -25,14 +25,14 @@ möjligheter att förnya protokollet. inte något sätt som man kan undvika att implementera allt nu och sedan upptäcka problemen i framtiden. -- Ingen mera fraktionsdel i versionsnumret. Det beslöts att klienter och +- Ingen mera decimaldel i versionsnumret. Det beslöts att klienter och servrar är antingen kompatibla med http2 eller så är de det inte. Om det kommer ett behov att utöka protokollet eller ändra saker så kommer http3 att skapas. Det finns inte något "minor version" i http2. ## 5.1. http2 för existerande URI-scheman -Som tidigare nämnts så kan inte existerande URI-scheman ändras, så http2 var +Som tidigare nämnts så får inte existerande URI-scheman ändras, så http2 var tvunget att göras med de redan existerande. Eftersom de används för HTTP 1.x idag så behövde vi förstås ett sätt att uppgradera protokollet till http2 eller på något vis be servern använda http2 istället för äldre protokoll. @@ -67,7 +67,7 @@ mellan-boxar att blanda sig i och förstöra trafik när det faktiskt är något annat protokoll som pratas där. Obligatorisk TLS är ett ämne som orsakat mycket handviftande och upprörda -röster på mailinglistor och möten - är det bra eller är det ondska? Det är ett +röster på mailinglistor och möten - är det gott eller är det ont? Det är ett infekterat ämne - var medveten om detta när du kastar den här frågan i ansiktet på en HTTPbis-deltagare! @@ -82,7 +82,7 @@ finns krav på vilka chiffer som måste användas. Next Protocol Negotiation (NPN), är tillägget som användes i SPDY för att förhandla med TLS-servrar. Eftersom det inte var en riktig standard så togs -det till IETF och igenom och det som kom ut blev ALPN: Application Layer +det till och igenom IETF och det som kom ut blev ALPN: Application Layer Protocol Negotiation. ALPN är det som nu lyfts upp för att användas i http2, medan SPDY-klienter och -servrar fortsätter använda NPN. @@ -92,7 +92,7 @@ servrar är gjorda att använda båda dessa tillägg när de förhandlar http2. Vidare, eftersom NPN används för SPDY och många servrar ju stöder både SPDY och http2 så är det vettigt att stödja både NPN och ALPN på sådana servrar. -ALPN skiljer sig i huvudsak från NPN genom vet det är som bestämmer vilket +ALPN skiljer sig i huvudsak från NPN genom vem det är som bestämmer vilket protokoll som pratas. Med ALPN är det klienten som ger servern en lista med protokoll i den ordningen den föredrar att använda dem, och servern väljer det protokoll den vill ha, medan för NPN så är det klienten som gör det slutliga @@ -102,9 +102,9 @@ valet. Som tidigare nämnts i förbifarten, för klartext-HTTP 1.1 så är mekanismen att förhandla http2 att fråga servern med en Upgrade:-header. Om servern då pratar -http2 svarar den med en "101 Byter" status och från då och framöver pratar den -istället http2 på det kopplet. Du inser förstås att den -uppgraderingsproceduren kostar en hel nätverks fram-och-tillbaka-tur men en +http2 svarar den med en "101 Byter" status och från det och framöver pratar den +istället http2 på det kopplet. Man inser förstås att den +uppgraderingsproceduren kostar en hel fram-och-tillbaka-tur i nätverket men en fördel är att ett http2-koppel bör vara möjligt att hålla levande och återanvända i mycket högre grad än HTTP1-koppel generellt är. diff --git a/sv/part6.md b/sv/part6.md index 415b9ab..f9f869f 100644 --- a/sv/part6.md +++ b/sv/part6.md @@ -36,14 +36,14 @@ liknande. -http2 skickar binära paket ("frames"). Det finns olika paket-typer som kan +http2 skickar binära paket ("frames"). Det finns olika pakettyper som kan skickas och de har allihop samma upplägg: -Längd, typ, flaggor, ström-id och paket-data ("payload"). +Längd, typ, flaggor, ström-id och paketdata ("payload"). -Det finns tio olika paket-typer definierade i http2-specen och de två kanske +Det finns tio olika pakettyper definierade i http2-specen och de två kanske mest fundamentala som direkt mappar HTTP 1.1-funktioner är DATA och -HEADERS. Jag kommer beskriva några av paket-typerna i närmare detaljer nedan. +HEADERS. Jag kommer beskriva några av pakettyperna i närmare detaljer nedan. ## 6.3. Multiplexade strömmar @@ -56,7 +56,7 @@ Ett enda http2-koppel kan överföra många samtidiga strömmar mellan ändpunkterna genom att skicka paket från olika strömmar över kopplet. Strömmar kan etableras och användas ensidigt eller delas av både klienten och servern och de kan stängas av endera sidan. Ordningen som paketen skickas inom -strömmen behålls, så mottagaren tar emot de i samma ordning som de skickades. +strömmen behålls, så mottagaren tar emot dem i samma ordning som de skickades. Multiplexande strömmar betyder att paket från många strömmar blandas och skickas över samma koppel. Två (eller fler) individuella tåg med data trycks @@ -77,11 +77,11 @@ resursbrist tvingar servern att välja vilka strömmar som ska skickas först. Genom att använda ett PRIORITY-paket kan en klient också berätta för servern vilken annan ström den beror på. Detta möjliggör för en klient att bygga ett -"träd" med prioriteter där flera "barn-strömmar" kan bero att +"träd" med prioriteter där flera "barn-strömmar" kan bero på att "föräldra-strömmar" först avslutas. Prioritetsvikter och beroenden kan ändras dynamiskt under körning, vilket bör -tillåta webbläsare att se till att när användare scrollar ner en sida full med +göra att webbläsare kan se till att när användare scrollar ner en sida full med bilder så kan den berätta vilka bilder som är viktigast, eller om du byter tabbar så kan den prioritera en ny uppsättning strömmar som då plötsligt kommer i fokus. @@ -91,10 +91,10 @@ kommer i fokus. HTTP är ett state-löst protokoll. I korthet betyder det att varje förfrågan måste ta med sig precis så mycket detaljer som servern behöver för att serva den frågan utan att servern ska behöva mellanlagra info eller meta-data från -tidigare förfrågningar. Eftersom http2 inte ändra några sådana paradigmer så -måste det också fungera så. +tidigare förfrågningar. Eftersom http2 inte får ändra några sådana paradigmer +så måste det också fungera så. -Detta gör HTTP repetativt. När en klient frågar efter många resurser från +Detta gör HTTP repetitivt. När en klient frågar efter många resurser från samma server, typ bilder på en webbsida, så kommer det göras en lång serie med förfrågningar som ser nästan identiska ut. En serie med nästan identiska någonting ber om komprimering. @@ -122,8 +122,8 @@ Att komprimera dynamiskt innehåll för ett protokoll utan att bli sårbar för dessa attacker kräver lite omtanke och försiktiga övervägningnar. Det är vad HTTPbis-teamet försökte sig på. -In kommer då [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt), Header- -komprimering för http2, vilket – som namnet lämpligt indikerar - är ett +In kommer då [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt), +Header-komprimering för http2, vilket – som namnet lämpligt indikerar - är ett komprimeringsformat speciellt framtaget för http2-headers och det är strikt talat specificerat i en egen specifikation. Det nya formatet, tillsammans med andra motåtgärder, som en bit som ber mellanhänder att inte komprimera en viss @@ -147,7 +147,7 @@ det kommer till priset av att du måste förhandla upp ett nytt TCP-koppel igen. En bättre lösning skulle vara att bara stoppa meddelandet och skicka ett nytt. Det kan göras med http2:s RST_STREAM-paket som därmed hjälper till att -undvika slösa på bandbredd och onödiga nedrivningar av koppel. +undvika att slösa på bandbredd och onödiga nedrivningar av koppel. ## 6.7. Server push @@ -163,9 +163,9 @@ pushad ström med RST_STREAM ifall den inte vill ha den. ## 6.8. Flödeskontroll -Varje individuell ström över http2 har sin eget annonserade flödesfönster som +Varje individuell ström över http2 har sitt eget annonserade flödesfönster som den andra sidan är tillåten att sända data för. Det är väldigt likt hur SSH -fungerar i stil och koncept, om du råkar veta hur det fungerar. +fungerar i stil och koncept, om du råkar känna till hur det fungerar. För varje ström måste båda sidor berätta för den andra hur mycket utrymme det finns att lagra inkommande data i, och den andra änden har bara tillåtelse att diff --git a/sv/part7.md b/sv/part7.md index 21c9e8b..b3336b0 100644 --- a/sv/part7.md +++ b/sv/part7.md @@ -1,9 +1,9 @@ # 7. Utökningar Protokollet kräver att en mottagare måste ta emot och ignorera alla paket som -innehåller okända paket-typer. Två parter kan därmed förhandla om en -användning av nya paket-typer på hop-by-hop basis (dvs överenskommelsen -gäller endast mellan dessa två ändpunkter och inte längre än så), och de paket +innehåller okända pakettyper. Två parter kan därmed förhandla om en +användning av nya pakettyper på hop-by-hop basis (dvs överenskommelsen +gäller endast mellan dessa två ändpunkter och inte längre än så), och de paketen kan då inte ändra state och de kan inte flödeskontrolleras. Frågan huruvida http2 skulle tillåta utökningar eller inte debatterades länge @@ -11,7 +11,7 @@ medan protokollet utvecklades med åsikter som svängde åt båda hållen. Efter draft-12 svängde pendeln tillbaks en sista gång och utökningar tilläts igen. Utökningar är därmed inte del av det egentliga protokollen utan kommer -dokumenteras utanför huvudspecen. Redan nu finns det två paket-typer som har +dokumenteras utanför huvudspecen. Redan nu finns det två pakettyper som har diskuterats för att inkluderas i protokollet och som troligen tillhör de första typerna att skickas som utökningar. Jag beskriver dem här bara på grund deras popularitet och deras tidigare roll som "inhemska" typer. @@ -19,9 +19,9 @@ deras popularitet och deras tidigare roll som "inhemska" typer. ## 7.1. Alternativa tjänster När http2 antas, finns det anledning att misstänka att TCP-koppel kommer bli -mycket långvariga och hållas levande mycket längre än vad HTTP 1.x-kopper +mycket långvariga och hållas levande mycket längre än vad HTTP 1.x-koppel någonsin hållits. En klient bör kunna göra mycket av vad den vill över ett -enda koppel per varje host/sajt och det enda kopplet kan då potentiellt hållas +enda koppel per host/sajt och det enda kopplet kan då potentiellt hållas uppe riktigt länge. Detta påverkar hur HTTP-loadbalancerare arbetar och det kan komma situationer @@ -54,12 +54,12 @@ TLS och en del människor är emot det konceptet väldigt starkt. Ett paket av den här typen är tänkt att skickas exakt en gång av en http2-part när denne har data att skicka men flödeskontroll förbjuder den att skicka -data. Tanken är att ifall din implementation tar emot ett sådant paket så vet -du att din implementation har strulat till någonting och/eller du får mindre +data. Tanken är att ifall implementationen tar emot ett sådant paket så vet +man att implementationen har strulat till någonting och/eller får mindre än optimal överföringshastighet på grund av det. Ett citat från draft-12, innan det här paketet togs ut och blev en utökning: -> “Paket-typen BLOCKED är med i den här draft-versionen för att erbjuda +> “Pakettypen BLOCKED är med i den här draft-versionen för att erbjuda > experimentering. Om resultaten av experimenten inte resulterar i positiv > feedback kommer den tas bort. diff --git a/sv/part8.md b/sv/part8.md index c234131..2f80035 100644 --- a/sv/part8.md +++ b/sv/part8.md @@ -10,21 +10,22 @@ och räkna baserat på det och andra experiment som gjorts tidigare. http2 minskar antalet turer fram och tillbaks över nätverket och det undviker först-i-kön-blockeringsproblemen genom att multiplexa och att kunna avsluta -oönskad strömmar snabbt. +oönskade strömmar snabbt. Det tillåter ett stort antal parallella strömmar som i antal vida överstiger -antal koppel host även de mest shardade sajterna av idag. +antal koppel hos även de mest shardade sajterna av idag. -Med prioriteter använda ordentligt på strömmarna finns chansen att klient -mycket bättre kommer kunna få den viktiga datan före den mindre viktiga +Med prioriteter använda ordentligt på strömmarna finns chansen att klienten +på ett mycket bättre sätt kommer kunna få den viktiga datan före den mindre +viktiga datan. Allt sammantaget, skulle jag säga att chanserna är väldigt goda att det kommer leda till snabbare sidladdning och mer responsiva webbsajter. Kort sagt: en bättre webbupplevelse. Hur mycket snabbare och hur mycket förbättringar vi kommer se tror jag inte vi -kan säga ännu. Först och främst är ju teknologin fortfarnade väldigt ung och +kan säga ännu. Först och främst är ju teknologin fortfarande väldigt ung och sen har vi knappt ens börjat se klienter och servrar trimma sina -implementationer till att verkligen dra nytta av alla de krafter detta nya +implementationer till att verkligen dra nytta av alla de möjligheter detta nya protokoll erbjuder. ## 8.2. Hur kommer http2 påverka webbutveckling? @@ -65,12 +66,12 @@ versionen. Firefox har varit webbläsaren som varit först med support för de allra senaste versionerna av specen. Twitter har hängt med och erbjuder sina tjänster över http2. Google började under april 2014 att erbjudera http2-support på en del -test servrar som kör deras tjänster och sedan maj 2014 har de erbjudit http2 -support för deras utvecklingsversion av Chrome. Microsoft har visat en "tech -preview" med http2 support i deras nästa Internet Explorer-version. Safari och +testservrar som kör deras tjänster och sedan maj 2014 har de erbjudit +http2-support för sin utvecklingsversion av Chrome. Microsoft har visat en "tech +preview" med http2-support i deras nästa Internet Explorer-version. Safari och Opera har båda sagt att de kommer stöda http2. -curl och libcurl stöder osäker http2 likväl som TLS-baserad, användades en av +curl och libcurl stöder osäker http2 likväl som TLS-baserad, användandes en av flera olika TLS-bibliotek. [H2O](https://h2o.examp1e.net/), [Apache Traffic @@ -110,9 +111,11 @@ uppmanar servrar att migrera till http2 istället. ### 8.4.2. “Protokollet är endast användbart för webbläsare" -Det här är typ sant. En av de primära drivarna bakom utvecklingen av http2 var +Det här är typ sant. En av de primära drivkrafterna bakom utvecklingen av +http2 var att fixa HTTP pipeliningen. Om ditt användningsfall inte har något behov av -pipeliningen så finns det en sannolikhet att http2 inte kommer gör mycket bra +pipeliningen så finns det en sannolikhet att http2 inte kommer vara till +mycket nytta för dig. Det är inte den enda förbättringen i protokollet men en stor sådan. Så snart tjänster börjar använda den fulla kraften och möjligheterna med @@ -136,7 +139,7 @@ Det kan vara sant till viss utsträckning. TLS-handskakningen lägger på lite extra men det finns redan pågående ansträngningar att reducera antalet tur-och-retur varv ännu mer för TLS. Den extra kostnaden för att använda TLS över kabeln istället för klartext är inte osignifikant och tydligt noterbar så -mer CPU och kraft kommer användas för samma trafik mönster som ett osäkert +mer CPU och kraft kommer användas för samma trafikmönster än för ett osäkert protokoll. Hur mycket och vilken effect det får är ett ämne för tyckande och mätningar. Se till exempel [istlsfastyet.com](https://istlsfastyet.com/) för en källa till sådan info. @@ -145,7 +148,7 @@ Telecom och andra nätverskoperatörer, till exempel inom ATIS Open Web Alliance, säger att [de behöver okrypterad trafik](https://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf) för att erbjuder cache, komprimering och andra tekniker som är nödvändiga för -att tillhandahålla en snabb webbupplevelse över satelit, i flygplan och +att tillhandahålla en snabb webbupplevelse över satellit, i flygplan och liknande. http2 gör inte TLS obligatoriskt så vi ska inte blanda ihop termerna. @@ -153,9 +156,9 @@ Många Internet-användare har uttalat sina preferenser för att TLS ska använd mer utbrett och vi borde hjälpa till att skydda användarnas integritet. Experiment har visat att genom att använda TLS så får man en högre grad av -framgång än när man implementerar ny klartext-protokoll över port 80, eftersom +framgång än när man implementerar nya klartextprotokoll över port 80, eftersom det finns lite för många mellan-boxar där ute i världen som ingriper i det som -de tror är HTTP 1.1 om det kommer över port och ibland kan se ut som HTTP. +de tror är HTTP 1.1 om det kommer över port 80 och ibland kan se ut som HTTP. Till slut, tack vare https multiplexande strömmar över ett fysikt koppel, så kommer vanliga användningsfall med webbläsare ändå göra väsentligt färre