Moment mal! Wo ist mein HTTP/2 hin?

Internetseite, mit geöffneten Developertools
Meine Seite, mit geöffneten Developertools

Das HTTP/2 Protokoll gehört heutzutage ja bereits zum Standard, wenn es um performante Internetseiten geht. Die Vorteile wie, die Anzahl der Verbindungen zum Server oder der parallelen Datenübertragung, liegen klar auf der Hand und sind auch dem meist nicht so technisch versierten Kunden schnell erklärt. So gehörte auch auf meiner kleinen Internetpräsenz HTTP/2 längst zu den Standardeinstellungen meines V-Hosts.    

Dennoch fiel mir vor Kurzem auf, dass mein Webserver die Daten nur noch über HTTP/1.0 bzw. HTTP/1.1 auslieferte. Diese Verhalten überraschte mich und ich begann die Konfiguration meines V-Hosts zu prüfen. 

Um HTTP/2 bei einen einfachen Apache Webserver, wie ich ihn nutze, zu verwenden, bedarf es nicht viel Aufwand. Es muss lediglich das Modul für HTTP/2 aktiviert und ein Eintrag in der Konfiguration des V-Hosts erstellt werden, schon läuft der Hase. Na ja, eigentlich… bei meinem Server schien ich etwas vergessen zu haben. Daher ging ich wie folgt vor, um dem Fehler auf die Spur zu kommen. 

Das Apache Modul prüfen

Der erste Gedanke der mir kam, war das sich aus irgendeinem Grund das HTTP/2 Modul deaktiviert hat oder das es beim laden des Moduls einen Fehler gab. So warf ich also einen Blick in das Verzeichnis in dem die Module gelistet sind.

Auflistung der aktivierten Apache2 Module
ls /etc/apache2/mods-enabled

Dort fand ich, wie eigentlich auch zu erwarten, einen Eintrag für das HTTP/2 Modul. Zu erkennen an dem http2.load Link.

Die V-Host Konfiguration prüfen

Der zweite Gedanke, der mir kam war, dass es ein Problem mit der V-Host Konfiguration gab. Um HTTP/2 zu verwenden, muss hier nämlich der Eintrag “Protocols” gesetzt sein, welcher genau definiert welche Protokolle unterstützt werden. Dieser war aber wie im Bild zu sehen bei mir hinterlegt. Somit konnte das auch nicht der Grund sein.

Auszug der V-Host Konfiguration
Auszug der V-Host Konfiguration

Reboot tut gut

Frei nach alter Windows-Manier dachte ich mir, ok… dann starte ich mal den Apache Service neu. Vllt. hat sich dieser ja nur “verschluckt” und danach gehts wieder. Leider war das nicht der Fall und meine Seite wurde auch weiterhin nicht über HTTP/2 ausgeliefert. 

Logging ist alles

Als letztes nahm ich mir die Log-Files der V-Hosts und des Services an sich vor. Dort fand ich dann endlich einen Hinweis. Während ich in den V-Host Logs zwar nur auf gähnende Leere blickte, offenbarte sich mir in den Logs des Services der Grund für mein Problem. 

[mpm_prefork:notice] [pid 32690] AH00169: caught SIGTERM, shutting down

[http2:warn] [pid 16336] AH10034: The mpm module (prefork.c) is not supported by mod_http2. The mpm determines how things are processed in your server. HTTP/2 has more demands in this regard and the currently selected mpm will just not do. This is an advisory warning. Your server will continue to work, but the HTTP/2 protocol will be inactive.

Tadaa… da stand der Grund und nach dem ich mich etwas zurückerinnerte ergab sich mir auch der Ursprung des Problems. 

Die Ursache

Seit dem ich denken kann, hatte ich den Server bei Server4You gehostet und war da auch jahrelang ein zufriedener Kunde. Das änderte sich allerdings als ich, Monate nach Veröffentlichung, immer noch nicht auf Debian Stretch updaten konnte. Nach einigen hitzigen Mails mit dem Kundensupport, tat ich das, was jeder verärgerte Kunde macht, ich ging …

Das wiederum führte dazu, das mein Server sowie auch die Domain zu einem neuen Dienstleister umzogen. 

Beim Aufsetzen des Webservers ergab sich dann der Unterschied zum alten Setup. Auf dem alten System lief Apache in Verbindung mit PHP-FPM. Das war notwendig, da das Hostsystem meines V-Servers, den mir zugesicherten RAM frei nach Schnauze umverteilte. Dieses Verhalten führte dann dazu das mein Apache Service mit Mod PHP regelmäßig einen Seg-Fault-Tod starb und ich quasi stündlich den Service neu starten musste. PHP-FPM ist da etwas lockerer. Starb dort ein Prozess den Memory-Tod war nur dieser eine betroffen, die anderen waren in der Lage weitere Requests zu verarbeiten. Das gab dem System mehr Stabilität und mir deutlich weniger “service restart” – Momente. 

Auf dem neuen System war das allerdings nicht der Fall, ich guten Gewissens wieder Apache mit Mod PHP installieren konnte. Was ich dabei allerdings übersah, war, dass Mod PHP auf MPM Prefork aufsetzt welches HTTP/2 nicht unterstützt. Damit hatte ich den Grund für mein Problem gefunden.

Die Lösung

Wie auch schon auf meinem alten Server, war auch hier PHP-FPM die Lösung. Also schnell libapache-mod-fcgid und php7.3-fpm installiert, die V-Host Konfiguration so angepasst, das alle PHP Requests an den FPM geleitet werden, die Prefork Module deaktivieren und den Apache Service neu starten. 

Angepasste V-Host Konfiguration
Alle .php Dateien werden vom Apache an PHP-FPM weitergeleitet

Was dann allerdings geschah, hatte ich nicht erwartet. Statt meiner Website, die per HTTP/2 ausgeliefert wird, erhielt ich nun gar keine Seite, sondern nur den hier zu sehenden “No Response”-Error. 

Fehlerseite des Browsers
Der Apache2 Service ließ sich nicht mehr starten

Was war hier also schief gelaufen? Nach dem ich mich eine Weile mit Dr. Google unterhalten hatte, fiel mir auf, dass ich in der Hektik alle MPM Module deaktiviert hatte. Das wiederum war fatal, denn ohne MPM Event funktioniert auch PHP-FPM nicht. Also schnell noch einmal das MPM Event Module wieder aktiviert und mein Problem war gelöst. 

Aktivierung des mpm_event mods
sudo a2enmod mpm_event 

Fazit

Der Teufel steckt wieder mal im Detail. Hätte ich auf meinem alten Server nicht wegen anderer Umstände auf PHP-FPM wechseln müssen, hätte ich mir nicht unbewusst die Grundlagen für HTTP/2 geschaffen. Somit wäre mir das Problem vermutlich deutlich eher aufgefallen, nämlich schon bei der initialen Einrichtung und nicht erst Monate nach dem Umzug auf das neue System.