HTTP/2 Kontrolværktøj

HTTP/2 Kontrolværktøj er et gratis værktøj, der kontrollerer, om et website bruger netværksprotokollen HTTP/2.

Hvad undersøger en HTTP/2-kontrol egentlig?

En HTTP/2-kontrol afgør, om en webserver kan kommunikere via HTTP/2 for det angivne website. HTTP/2 er en version af Hypertext Transfer Protocol, som er det regelsæt, browsere og servere bruger til at anmode om og levere sider, billeder, scripts og andre webressourcer.

På et website med HTTPS vælger klienten og serveren normalt en protokol, mens den sikre forbindelse oprettes. Denne forhandling sker ofte via Application-Layer Protocol Negotiation, også kaldet ALPN. HTTP/2 identificeres som h2, mens en ældre forbindelse kan bruge http/1.1.

HTTP/2 bevarer velkendte HTTP-begreber som metoder, statuskoder og headers, men overfører dem i binære frames. Protokollen kan håndtere flere datastrømme gennem én forbindelse og komprimere HTTP-headers. Det kan reducere belastningen fra forbindelser, især på sider med mange separate ressourcer. HTTP/2 gør dog ikke i sig selv langsom programkode, store billeder eller forsinkede databaseforespørgsler hurtigere.

Hvordan kontrollerer jeg, om et website bruger HTTP/2?

Indtast det website, du vil kontrollere for HTTP/2-understøttelse, og start kontrollen. Inputtet sendes til serveren via HTTPS, hvor kontrollen udføres, og det gemmes ikke.

Domænenavne med accenter eller ikke-latinske tegn repræsenteres i DNS som IDNA A-labels, der bruger kodningsalgoritmen Punycode.

Indsend ikke adgangstokens eller andre følsomme oplysninger. Selvom inputtet ikke gemmes, sendes det stadig til værktøjets server, så kontrollen kan udføres på serversiden.

Hvordan læser jeg HTTP/2-resultatet?

Resultatet fortæller, om det kontrollerede website bruger HTTP/2. Betragt det som dokumentation for det konkrete website, ikke som en samlet vurdering af websitets hastighed eller konfiguration.

• Et positivt resultat bekræfter, at protokollen bruges. Et negativt resultat betyder, at kontrollen ikke kunne bekræfte HTTP/2, men fortæller ikke i sig selv, hvad årsagen er.

Antag som eksempel, at et website får et positivt HTTP/2-resultat. Det bekræfter HTTP/2 for det kontrollerede website. Det beviser ikke, at separate tjenester eller en ældre origin-server bruger samme protokol.

Hvis resultatet ikke bekræfter HTTP/2, kan du undersøge det pågældende website med HTTP headers opslag og kontrollere indstillingerne på webserveren eller CDN'et. Browserens udviklerværktøjer kan også vise protokollen for hver anmodning, typisk som h2 eller http/1.1.

Almindelige problemer, som kontrollen kan afsløre

En HTTP/2-kontrol er nyttig efter ændringer af hosting, proxy eller CDN, fordi den viser, om det offentlige endpoint leverer den forventede protokol. I følgende almindelige situationer kan resultatet hjælpe med at afgrænse problemet.

1. Et CDN er netop blevet aktiveret. Kontrollér det offentlige website i stedet for origin-serverens private eller midlertidige adresse. Hvis det offentlige website bruger HTTP/2, men origin-serveren ikke gør, kan det være helt normalt, da forbindelsen mellem browseren og CDN'et er adskilt fra forbindelsen mellem CDN'et og origin-serveren.
2. En browser viser stadig HTTP/1.1. Sørg for, at browseren og kontrolværktøjet tester det samme website. En side kan hente ressourcer fra flere domæner, og hver forbindelse forhandler sin egen protokol. At en enkelt anmodning til et tredjepartsscript bruger HTTP/1.1, betyder ikke, at hoveddokumentet gør det.
3. Der vises en certifikatadvarsel efter flytning af en server. Håndtering af HTTPS-certifikater og forhandling af HTTP-protokollen er relaterede dele af forbindelsens oprettelse, men et HTTP/2-resultat er ikke en fuldstændig certifikatdiagnose. Kontrollér separat certifikatets værtsnavn, udløbsdato og certifikatkæde samt serverens konfiguration.

Denne kontrol kan ikke forklare alle langsomme sideindlæsninger. Understøttelse af HTTP/2 siger ikke noget entydigt om serverens svartid, afviklingen af JavaScript, billedstørrelser eller overbelastning på forbindelsen mellem en bestemt besøgende og serveren. Brug Ping, hvis du har brug for en separat vurdering af netværkets tilgængelighed og svartider.

Hvorfor kan cache og udrulning få resultatet til at se forkert ud?

DNS-cache og udrulning af konfigurationsændringer kan i en periode sende forskellige kontroller til forskellige servere. Når en DNS-record er blevet ændret, kan rekursive resolvere fortsætte med at bruge det tidligere svar, indtil dets time to live udløber. Et serverbaseret kontrolværktøj og din forbindelse på kontoret eller derhjemme kan derfor nå frem til forskellige IP-adresser.

Det kan også tage tid, før ændringer i CDN'er og load balancere når ud til alle edge-lokationer. Ét endpoint kan have HTTP/2 aktiveret, mens et andet stadig bruger den tidligere konfiguration. Kontrollér de aktuelle DNS-svar, bekræft, at alle origin- eller edge-servere bruger de tilsigtede indstillinger, og gentag sammenligningen efter den relevante cacheperiode.

Browsere kan skabe yderligere forvirring, fordi de genbruger åbne forbindelser. En fane kan fortsætte med at bruge en eksisterende HTTP/1.1-forbindelse, indtil den lukkes, mens en ny kontrol på serversiden forhandler HTTP/2. Luk browserforbindelsen, eller start en ny privat browsersession for at få en mere pålidelig sammenligning.

Ofte stillede spørgsmål

Kan et website understøtte både HTTP/1.1 og HTTP/2?

Ja. En server kan understøtte begge dele og vælge den version, som den tilsluttede klient forstår. Denne kompatibilitet gør det muligt for ældre klienter at bruge HTTP/1.1, mens nyere klienter forhandler HTTP/2.

Kan et website bruge både HTTP/3 og HTTP/2?

Ja. Mange opsætninger beholder HTTP/2 som reserveløsning, fordi HTTP/3 bruger en anden transportprotokol og muligvis ikke er tilgængelig på alle netværk. Et HTTP/2-resultat fastslår ikke, om HTTP/3 også er aktiveret.

Kræver HTTP/2 HTTPS?

HTTP/2 kan bruges over ukrypteret TCP med forhåndskendskab, mens brugen af det tidligere HTTP/1.1 Upgrade-token h2c er udfaset. Almindelige browsere bruger normalt HTTP/2 via HTTPS. For et offentligt website er en gyldig TLS-konfiguration derfor som regel nødvendig for at gøre HTTP/2 tilgængelig for browsere.

Kan HTTP/2 løse problemet med en høj time to first byte?

Nej. En høj time to first byte skyldes ofte serverbehandling, netværksafstand, manglende cachetræf eller overbelastet infrastruktur. HTTP/2 kan forbedre den måde, flere anmodninger deler en forbindelse på, men protokollen fjerner ikke forsinkelsen, før serveren begynder at svare.

Som afsluttende kontrol kan du sammenligne det samme website i kontrolværktøjet, browserens udviklerværktøjer og DNS-records. Hvis resultaterne er forskellige, skal du notere den IP-adresse, der blev fundet, og teste igen, når de eksisterende DNS- og CDN-caches er udløbet.