Timeout Problems: Web Server + PHP

What?

First there is an HTTP request and that will hit your Web server, then it will pass the request via TCP- or UNIT-Socket via FastCGI to your PHP-FPM Daemon, here we will start a new PHP process and in this process we will connect e.g. to the database and run some queries.

PHP-Request

The Problem!

There are different timeout problems here because we connect different pieces together and this parts need to communicate. But what if one of the pieces does not respond in a given time or, even more bad, if one process is running forever like a bad SQL-query.

Understand your Timeouts.

Timeouts are a way to limit the time that a request can run, and otherwise an attacker could simply run a denial-of-service with a simple request. But there are many configurations in several layers: Web server, PHP, application, database, curl, …

– Web server

Mostly you will use Apache or Nginx as Web server and in the end it makes not really a difference, there are different timeout settings, but the idea is almost the same: The Web server will stop the execution and kills the PHP process, now you got a 504 HTTP error (Gateway Timeout) and you will lose your stack trace and error-tracking because we killed our application in the middle of nothing. So, we should keep the Web server running as long as needed.

“`grep -Ri timeout /etc/apache2/“`

/etc/apache2/conf-enabled/timeout.conf:Timeout 60

/etc/apache2/mods-available/reqtimeout.conf:<IfModule reqtimeout_module>

/etc/apache2/mods-available/reqtimeout.conf: # mod_reqtimeout limits the time waiting on the client to prevent an

/etc/apache2/mods-available/reqtimeout.conf: # configuration, but it may be necessary to tune the timeout values to

/etc/apache2/mods-available/reqtimeout.conf: # mod_reqtimeout per virtual host.

/etc/apache2/mods-available/reqtimeout.conf: # Note: Lower timeouts may make sense on non-ssl virtual hosts but can

/etc/apache2/mods-available/reqtimeout.conf: # cause problem with ssl enabled virtual hosts: This timeout includes

/etc/apache2/mods-available/reqtimeout.conf: RequestReadTimeout header=20-40,minrate=500

/etc/apache2/mods-available/reqtimeout.conf: RequestReadTimeout body=10,minrate=500

/etc/apache2/mods-available/reqtimeout.load:LoadModule reqtimeout_module /usr/lib/apache2/modules/mod_reqtimeout.so

/etc/apache2/mods-available/ssl.conf: # to use and second the expiring timeout (in seconds).

/etc/apache2/mods-available/ssl.conf: SSLSessionCacheTimeout 300

/etc/apache2/conf-available/timeout.conf:Timeout 60

/etc/apache2/apache2.conf:# Timeout: The number of seconds before receives and sends time out.

/etc/apache2/apache2.conf:Timeout 60

/etc/apache2/apache2.conf:# KeepAliveTimeout: Number of seconds to wait for the next request from the

/etc/apache2/apache2.conf:KeepAliveTimeout 5

/etc/apache2/mods-enabled/reqtimeout.conf:<IfModule reqtimeout_module>

/etc/apache2/mods-enabled/reqtimeout.conf: # mod_reqtimeout limits the time waiting on the client to prevent an

/etc/apache2/mods-enabled/reqtimeout.conf: # configuration, but it may be necessary to tune the timeout values to

/etc/apache2/mods-enabled/reqtimeout.conf: # mod_reqtimeout per virtual host.

/etc/apache2/mods-enabled/reqtimeout.conf: # Note: Lower timeouts may make sense on non-ssl virtual hosts but can

/etc/apache2/mods-enabled/reqtimeout.conf: # cause problem with ssl enabled virtual hosts: This timeout includes

/etc/apache2/mods-enabled/reqtimeout.conf: RequestReadTimeout header=20-40,minrate=500

/etc/apache2/mods-enabled/reqtimeout.conf: RequestReadTimeout body=10,minrate=500

/etc/apache2/mods-enabled/reqtimeout.load:LoadModule reqtimeout_module /usr/lib/apache2/modules/mod_reqtimeout.so

/etc/apache2/mods-enabled/ssl.conf: # to use and second the expiring timeout (in seconds).

/etc/apache2/mods-enabled/ssl.conf: SSLSessionCacheTimeout 300

Here you can see all configurations for Apache2 timeouts, but we only need to change etc/apache2/conf-enabled/timeout.conf`` because it will overwrite `/etc/apache2/apache2.conf` anyway.

PS: Remember to reload / restart your Web server after you change the configurations.

If we want to show the user at least a custom error page, we could add something like:

ErrorDocument503 /error.php?errorcode=503
ErrorDocument 504 /error.php?errorcode=504

… into our Apache configuration or in a .htaccess file, so that we can still use PHP to show an error page, also if the requested PHP call was killed. The problem here is that we will lose the error message / stack trace / request etc. from the error, and we can’t send e.g. an error into our error logging system. (take a look at sentry, it’s really helpful)

– PHP-FPM

Our PHP-FPM (FastCGI Process Manager) pool can be configured with a timeout (request-terminate-timeout), but just like the Web server setting, this will kill the PHP worker in the middle of the process, and we can’t handle the error in PHP itself. There is also a setting (process_control_timeout) that tells the child processes to wait for this much time before executing the signal received from the parent process, but I am uncertain if this is somehow helpfully here? So, our error handling in PHP can’t catch / log / show the error, and we will get a 503 HTTP error (Service Unavailable) in case of a timeout.

Shutdown functions will not be executed if the process is killed with a SIGTERM or SIGKILL signal. :-/

Source: register_shutdown_function

PS: Remember to reload / restart your PHP-FPM Daemon after you change the configurations.

– PHP

The first idea from most of us would be maybe to limit the PHP execution time itself, and we are done, but that sounds easier than it is because `max_execution_time` ignores time spent on I/O (system commands e.g. `sleep()`, database queries (SELECT SLEEP(100)). But these are the bottlenecks of nearly all PHP applications, PHP itself is fast but the external called stuff isn’t.

Theset_time_limit()function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running. This is not true on Windows where the measured time is real.

Source: set_time_limit

– Database (MySQLi)

Many PHP applications spend most of their time waiting for some bad SQL queries, where the developer missed adding the correct indexes and because we learned that the PHP max execution time did not work for database queries, we need one more timeout setting here.

There is the MYSQLI_OPT_CONNECT_TIMEOUT and MYSQLI_OPT_READ_TIMEOUT (Command execution result timeout in seconds. Available as of PHP 7.2.0. – mysqli.options) setting, and we can use that to limit the time for our queries.

In the end you will see a “Errno: 2006 | Error: MySQL server has gone away” error in your PHP application, but this error can be caught / reported, and the SQL query can be fixed, otherwise the Apache or PHP-FPM would kill the process, and we do not see the error because our error handler can’t handle it anyway.

Summary:

It’s complicated. PHP is not designed for long execution and that is good as it is, but if you need to increase the timeout it will be more complicated than I first thought. You need for example different “timeout”-code for testing different settings:

// DEBUG: long-running sql-call
// Query(‘SELECT SLEEP(600);’);

// DEBUG: long-running system-call
// sleep(600);

// DEBUG: long-running php-call
// while (1) { } // infinite loop

Solution:

We can combine different timeout, but the timeout from the called commands e.g. database, curl, etc. will be combined with the timeout from PHP (max_execution_time) itself. The timeout from the Web server (e.g. Apache2: Timeout) and from PHP-FPM (request_terminate_timeout) need to be longer than the combined timeout from the application so that we still can use our PHP error handler.

e.g.: ~ 5 min. timeout

  1. MySQL read timeout: 240s ⇾ 4 min.
    link->options(MYSQLI_OPT_READ_TIMEOUT, 240);
  2. PHP timeout: 300s ⇾ 5 min.
    max_execution_time = 300
  3. Apache timeout: 360s ⇾ 6 min.
    Timeout 360
  4. PHP-FPM: 420s ⇾ 7 min.
    request_terminate_timeout = 420

 

Links:

HTTP/2 ist angekommen | Apache 2.4.17

Was ist HTTP/2? Diese Frage haben andere bereits ausführlich geklärt. https://http2.github.io/faq/ :) daher wollen wir dies heute in Kombination mit dem Apache Webserver ausprobieren.

Im Februar 2015 hat Google den Support für SPDY bereits zugunsten von HTTP/2 eingestellt. Und die Kompatibilität von HTTP/2 ist in fast allen aktuellen Webbrowsern gegeben, so das es bereits seit einiger Zeit keinen Grund gibt, nicht auf das neue Protokoll zu setzen. Seit dieser Woche unterstützt auch der Apache Webserver (2.4.17) das Protokoll, “Stefan Eissing” hat das Module “mod_http2” gesponsert, welches wir im folgenden testen werden.

Installation unter Ubuntu 14.04 via Fremdquellen (PPA)

Warnung: “Zusätzliche Fremdquellen können das System gefährden.”
–> https://wiki.ubuntuusers.de/paketquellen_freischalten/ppa

Zu beginn stellen wir sicher, dass SPDY nicht mehr verwendet wird.

a2dismod spdy

Und deinstallieren dies am besten direkt, falls dies über den Paket-Manager installiert wurde.

apt-get purge mod-spdy-beta

service apache2 restart

Um die Quellen (/etc/apt/sources.list.d/) nicht manuell zu ändern, installieren wir kurzerhand das Programm “add-apt-repository” via:

aptitude install software-properties-common

# Web: https://launchpad.net/~ondrej/+archive/ubuntu/apache2
# Issues: https://github.com/oerdnj/deb.sury.org/issues
#
add-apt-repository ppa:ondrej/apache2

Falls es beim Hinzufügen des Keys zu Problem kommt, kann man dies auch manuell durchführen:

apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 4F4EA0AAE5267A6C

Anschließend installieren wir das Update via “aptitude“, sodass wir mehr Kontrolle über den Update-Prozess haben.

apt-get update; aptitude

aptitude

Nach der Installation können wir das “http2”-Module wie folgt aktivieren.

cd /etc/apache2/mods-available/

vim http2.load

# Depends: setenvif mime socache_shmcb
LoadModule http2_module /usr/lib/apache2/modules/mod_http2.so

vim http2.conf

<IfModule http2_module>
ProtocolsHonorOrder On
Protocols h2 h2c http/1.1
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Und anschließend muss das Module nur noch aktiviert werden:

a2enmod http2

service apache2 restart

Um zu testen, ob HTTP/2 via https genutzt wird, können wir z.B. direkt im Chrome nachschauen. Dafür öffnen wir einfach die Seite chrome://net-internals und nutzen oben links im DropDown-Menü den Punkt “HTTP/2”.

chrome_http2

 

Quellen:

Server-Probleme im Zeitalter von HTTP/2

Ich hatte heute das Problem, dass einige Webseiten extrem langsam bis gar nicht mehr vom Webserver ausgeliefert wurden. Also prüfe ich als erstes mit “htop” ob die CPU ausgelastet ist, danach via “iotop” die Festplatte, mit “iftop” den Traffic, mit “netstat” die offenen Netzwerkverbindungen und via “free” wie viel Speicher noch zur Verfügung steht. Und die Hardware war nicht mal ansatzweise ausgelastet. Nach einigen weitere Tests ist schnell aufgefallen, dass nur “http”-Anfragen betroffen waren. Selbst eine einfach GET-Anfrage eines Bildes ist zeitweise fehlgeschlagen.

Die größte Änderung am Vortag war, dass eine Webseite mit zirka 1 Millionen Usern komplett auf “https://” umgestellt wurde. Daher habe ich kurzfristig wieder auf “http://” umgestellt, jedoch ohne eine Änderung festzustellen.

linux_kill_9
Quelle: http://www.reddit.com/r/ProgrammerHumor/comments/27vcjg/signal_kill/

Zeitgleich ist aufgefallen das der MySQL-Prozess nicht korrekt neugestartet ist, somit liefen zwei MySQL-Server (ps aux | grep mysql), wobei nur einer wirklich Anfragen angenommen hat. Der zweite Prozess wollte sich nicht mehr via “service mysql restart” neustarten lassen, hat die Fehlermeldung “Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysql.sock’” produziert und wurde daher via “kill” getötet und anschließend der MySQL-Server neugestartet.

Dies hat auch das Problem mit den langsamen Webseiten behoben, zumindest kurzweilig. Danach hatten “http”-Anfragen wieder Probleme. Im “error”-Logfile (/var/log/apache2/error.log) vom Apache habe ich dann endlich eine Meldung gefunden, welche mich auf die richtige Fährte gebracht hat: “server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers settings”

website-download-with-spdy

Vor einer Woche hatte ich das “SPDY“-Protokoll auf dem Server aktiviert und getestet, alles hat ohne Probleme funktioniert. Dann habe ich gestern die bereits erwähnte Webseite komplett auf “https” umgeroutet und noch immer kein Problem festgestellt. Am Morgen wurden dann Newsletter versendet und eine ganze Menge Leute sind in kurzer Zeit via “https” auf die Webseite gekommen, da das “SPDY”-Protokoll nur mit “https” arbeite haben diese User nicht die üblichen Anfragen  (HTTP 1.0 / 1.1) an den Server gestellt, sondern durch Multiplexverfahren mehrere Anfragen gleichzeitig verarbeitet werden.

http-diagram-spdy
Quelle: http://stackoverflow.com/questions/10480122/difference-between-http-pipeling-and-http-multiplexing-with-spdy

Die erste Intuition, dass es etwas mit der “SSL”-Umstellung zu tun hatte war schon mal nicht verkehrt, jedoch hatte ich die entsprechenden Einstellungen nur in der “.htaccess” auskommentiert, die “https”-Verbindungen jedoch nicht zurück nach “http” umgeleitet …

RewriteCond %{SERVER_PORT} !^443
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

… und den Apache nicht neugestartet, somit waren die aktuellen Anfragen noch aktiv und Nutzer welche auf der Webseite waren haben weiter “https”-Anfragen generiert.

Im nächsten Schritt musste nun festgestellt werden, wie viele Apache Prozesse bzw. gleichzeitige Verbindungen einstellt werden mussten und wie man dies am besten konfiguriert. Die Apache-Dokumentation sagt hierzu folgendes:

“The MaxRequestWorkers directive sets the limit on the number of simultaneous requests that will be served … For non-threaded servers (i.e., prefork), MaxRequestWorkers translates into the maximum number of child processes that will be launched to serve requests. The default value is 256; to increase it, you must also raise ServerLimit.”

Also habe ich via …

netstat -anp | grep -E ":80|:443" | grep ESTABLISHED | wc -l

… bzw. zur groben Orientierung via …

ps aux | grep apache | wc -l

… herausgefunden wie viele http(s) Anfragen bzw. Apache Prozesse aktuell vorhanden sind und habe diese Einstellungen zunächst entsprechend hoch eingestellt (“/etc/apache2/mods-enabled/mpm_prefork.conf”), so dass die Webseite wieder korrekt funktionierte. Anschließend habe ich die zuvor beschriebenen Befehle verwendet, um die endgültigen Einstellungen zu ermitteln. Die folgenden Einstellungen sind an einen Server mit 32G Arbeitsspeicher getestet und sollte nicht einfach übernommen werden.

<IfModule mpm_prefork_module>
ServerLimit                                    1024
StartServers                                        1
MinSpareServers                              32
MaxSpareServers                          250
MaxRequestWorkers              1024
MaxConnectionsPerChild             0
</IfModule>

————————————————–

Lösung: Wenn man das “SPDY”-Modul aktiviert und später auf “SSL” umstellt, sollten man vorher die Apache-Konfiguration anpassen! ;)

————————————————–

Es folgt noch ein kleines Tutorial, wie man “SPDY” für Apache installieren kann. Jeder der bereits auf “nginx” umgestiegen ist, kann dies ggf. bereits ohne weitere Installation ausprobieren: http://ginx.org/en/docs/http/ngx_http_spdy_module.html

Installation: SPDY für Apache 2.2

Download: https://developers.google.com/speed/spdy/mod_spdy/

# z.B.: wget https://dl-ssl.google.com/dl/linux/direct/mod-spdy-beta_current_amd64.deb
dpkg -i mod-spdy-*.deb
apt-get -f install

Installation: spdy für Apache 2.4

apt-get -y install git g++ apache2 libapr1-dev libaprutil1-dev patch binutils make devscripts fakeroot
cd /usr/src/
git clone https://github.com/eousphoros/mod-spdy.git
## wähle deine Apache Version  
# z.B.: git checkout apache-2.4.7
# z.B.: git checkout apache-2.4.10
cd mod-spdy/src
./build_modssl_with_npn.sh
chmod +x ./build/gyp_chromium
rm -f out/Release/mod-spdy-beta*.deb
BUILDTYPE=Release make linux_package_deb
dpkg-i out/Release/mod-spdy-beta*.deb

Video:

Links:

– Projekt Webseite: http://www.chromium.org/spdy/

– Quellcode: https://code.google.com/p/mod-spdy/wiki/GettingStarted

– “mod_spdy” für Apache 2.2: https://developers.google.com/speed/spdy/mod_spdy/

– “mod_spdy” für Apache 2.4: https://github.com/eousphoros/mod-spdy

– Online-Test für “SPDY”: https://spdycheck.org/

– Präsentation zum Thema “HTTP/2” von @derschepphttps://schepp.github.io/HTTP-2/

– Browserkompatibilität mit “SPDY”: http://caniuse.com/#search=spdy

“gzip” für Webseiten

Um das Verhalten von “gzip / deflate” besser zu verstehen, möchte ich als erstes ganz kurz auf den Algorithmus hinter der Komprimierung eingehen. Dafür muss man zumindest zwei Grundlegende Theorien verstehen. Zum einen die sogenannte Huffman-Kodierung, dabei geht darum Text mit möglichst wenig Bits (0 || 1) zu übersetzen.

Es folgt ein einfaches Beispiel:

String: “im westen nichts neues”

Die Länge des Strings beträgt 22 Zeichen, was bei einem 4-Bit-Code (0000, 0001 …) eine Anzahl von 22 * 4 Bit = 88 Bit ergeben würde.

Berücksichtigt man jedoch die Häufigkeit der wiederkehrenden Zeichen, kann man für bestimmte Zeichen, welche oft im String vorkommen, kürzere Bit-Codes nutzen.

huff1

Als erstes Zählen wir die Anzahl der vorkommenden Zeichen. Die Zeichen welche die geringste Häufigkeit aufweisen werden anschließend als erstes miteinander Verknüpft und jeweils addiert.

huff4

Wie man bereits erkennt bekommen die Zeichen welche nicht so häufig auftreten längere Strecken und somit gleich auch längere Bit-Codes.

huff7

Wenn man alle Zweige verknüpft hat, entsteht daraus dann ein Binär-Baum, welcher von oben nach unten gelesen wird.

Die eindeutigen Bit-Codes sind nun z.B.: 00 für e, 100 für n, 1011 für t und so weiter. Nun benötigen wir nur noch 73 Bit anstatt 88 Bit, um den String binär darzustellen. ;)

Das zweite Prinzip hat auch mit Wiederholung von Zeichen zu tun. Die sogenannte “LZ77″ Kompression, welche wiederkehrende Muster in Strings erkennt und durch Referenzen von vorherigen Strings ersetzt.

Es Folgt ein einfaches Beispiel:

String: “Blah blah blah blah blah!”

 vvvvv     vvvvv     vvv
Blah blah blah blah blah!
      ^^^^^     ^^^^^

Wenn man nun die Wiederholung durch eine Referenz angibt, welche aus der Länge des Wortes (” blah” = 5) und Länge der Wiederholungen. (“lah blah blah blah” = 18). Daraus ergibt sich anschließend der folgende komprimierte Text.

Blah b(5,18)!

… aber nun endlich zum praktischen Teil! Es folgen ein paar Beispiele und Überlegungen im Zusammenhang mit Webseiten / Webservern.

1.) “gzip”, ABER weniger ist manchmal mehr

Bei kleinen Webseiten und schwachen V-Servern kann es vorkommen, dass die serverseitige Komprimierung im Gesamtkontext keinen Geschwindigkeitsvorteil bietet, da die Komprimierung ggf. mehr Overhead (Payload, CPU-Rechenzeit, Verzögerung der Auslieferung) mit sich bringt als es Vorteile (geringere Dateigröße) bietet. Zumal viele Dateien (Bilder, CSS, JS) nach dem ersten Seitenaufruf im Cache sind und nicht wieder vom Server ausgeliefert werden müssen. Gerade für mobile Geräte macht die Komprimierung jedoch fast immer Sinn, daher würde ich die Komprimierung immer aktivieren!

PS: hier noch ein Blog-Post zum Thema Webseiten Beschleunigen

moelleken_org-gzip
mit gzip

moelleken_org-nogzip
ohne gzip

GRÜN = Download
GELB = Wartet
BLAU = Verbindung zum / vom Server

Bei “nginx” gibt es zudem ein Modul (HttpGzipStaticModule) welches direkt vorkomprimierte Dateien ausliefert, anstatt diese bei Anfrage zu komprimieren. Jedoch muss man bisher selber dafür sorgen, dass eine entsprechende Datei mit dem selben Timestamp vorhanden ist. (z.B.: main.css & main.css.gz) Falls jemand hier eine Alternative oder ein einfaches Script zum erstellen der zu komprimierenden Dateien hat, meldet euch bitte bei mir oder einfach in den Kommentaren.

2.) “gzip”, ABER nicht für alles

Zunächst sollte man bereits komprimierte Dateien (z.B. JPEG, PNG, zip etc.) nicht noch zusätzlich via „gzip“ ausliefern, da die Dateigröße im schlimmsten Fall noch steigen kann oder zumindest wird für sehr wenig Dateigröße, sehr viel CPU-Zeit auf der Server (Komprimierung) und auf dem Client (Dekomprimierung) verbraucht.

gzip_images

Ich empfehle an dieser Stelle mal wieder die “.htaccess“-Datei vom HTML5-Boilerplate, welche bereits viele Einstellungen für den Apache-Webserver liefert. Außerdem gibt es dort auch eine optimierte Konfiguration “nginx.conf” für den nginx-Webserver.

3.) “gzip”, ABER nicht immer

Die “gzip”-Komprimierung kann Ihre Stärken bei größeren Dateien viel besser ausspielen, da wir ja bereits im theoretischen Teil gelernt haben, dass die Komprimierung auf Wiederholungen aufbaut und wenn wenig wiederkehrende Zeichen und Muster vorhanden sind lässt es sich schlecht komprimieren.

Beim “nginx”-Webserver kann man die minimale zu bearbeitende Dateigröße angeben, sodass eine 6 Byte große Datei mit dem Inhalt “foobar” bei schwacher „gzip“ nicht auf 40 Byte vergrößert wird.

gzip_small_file

4.) “gzip”, ABER nicht so hoch

Zudem sollte man nicht mit der höchsten Komprimierungsstufe komprimieren, da man pro Komprimierungsstufe immer weniger Erfolg bei immer mehr CPU-Zeit bekommt. Man sollte weniger stark komprimieren und dadurch Rechenleistung /-zeit einsparen, um die Webseite schneller ausliefern zu können.

gzip_level

test2_1.js.gz (schwache Komprimierung)
test2_2.js.gz (normale Komprimierung)
test2_3.js.gz (starke Komprimierung)

5.) „gzip“ + Minifizierung

Durch Minifizierung von CSS und JS kann man die Dateigröße ebenfalls reduzieren, auch wenn man nicht an die Dateigröße von komprimierten Dateien herankommt, außerdem sinkt der Erfolg der Komprimierung, da wir durch die Minifizierung bereits einige Wiederholungen minimiert haben.

Es folgt ein Beispiel mit „jquery.js / jquery.min.js“:

Zustand

Größe der Datei

gewonnene Größe durch die Komprimierung

nicht minifiziert + nicht komprimiert Datei

250 kB (¼ MB)

nicht minifiziert + schnelle Komprimierung

76,3 kB

173,7 kB

nicht minifiziert + normale Komprimierung

68,3 kB

181,7 kB

nicht minifiziert + hohe Komprimierung

68 kB

182 kB

minifiziert + nicht komprimiert Datei

82,3 kB

minifiziert + schnelle Komprimierung

30,8 kB

51,5 kB

6.) “gzip” + Komprimierung verbessern

Im Gegensatz zur Programmierung, wo man Wiederholungen vermeidet, sollte man im Frontend (HTML, CSS) gezielt Wiederholungen nutzen, um die Komprimierung zu optimieren. So zeigt  das folgende Beispiel wie man die Dateigröße durch die korrekte Positionierung von Attributen der HTML-Tags verbessern kann.

Zwei Dateien mit dem selben Dateigröße, nur die Reihenfolge der Attribute in der zweiten HTML-Dateien (“test1_2.html”) wurden nicht in der selben Reihenfolge angegeben.

html_order_3
test1_1.html

html_order_2
test1_2.html

html_order

Wie man in dem Bild erkennen kann, haben wir die Dateigröße der HTML-Datei um zirka 10% reduziert indem wir den Komprimierungsalgorithmus  bei der Arbeit unterstützen. ;)

Videos:

 

PHP-Sicherheit erhöhen – Teil 1

 Jeder Server welcher PHP-Skripte verarbeitet, sollte zumindest zwei Sicherheitsschlösser eingebaut haben, so dass man nicht jedem Tür & Tor öffnet. 

 

1.) suPHP oder suexec + fcgid

Wir sollten PHP-Skript nicht alle mit dem selben User-Berechtigungen (z.B. apache) laufen lassen, daher empfiehlt es sich auf kleinen Webservern suPHP und auf Webseiten mit mehr Traffic “Fast CGI” zu installieren. Alternativ kann man PHP mit “PHP-FPM” (FastCGI Process Manager) auch jeweils als eigenständigen Prozess laufen lassen. 

2.) Suhosin

Da einige PHP-Projekte nicht wirklich für Ihre Sicherheit bekannt sind, empfiehlt es sich zudem die “Suhosin” Erweiterung für PHP zu installieren. “Es wurde entworfen, um den Server und die Benutzer vor bekannten und unbekannten Fehlern in PHP-Anwendungen und im PHP-Kern zu schützen.” – Wiki

PS: auf der Webseite -> http://www.dotdeb.org <- findet man einfach zu installierende .deb-Pakete für Debian / Ubuntu in welchen die Suhosin-Erweiterung bereits integriert ist und liegt zudem als “php5-fpm” Version zur Verfügung. ;) 

 

mehr Sicherheit:

Mod-Security und Apache

Mod-Spamhaus und Apache

– WordPress Sicherheit erhöhen

– php.ini / php.net

www.howtoforge.com | viele gute HowTo’s 

Dienste unter Debian / Ubuntu deaktivieren

Da ich vor einiger Zeit von “Apache2” zu “nginx” als Webserver umgestiegen bin, den “alten Indianer” jedoch in der Zwischenzeit noch auf einem anderen Port (127.0.0.1:8080) aktiv hatte, war es nun an der Zeit diesen abzuschalten.


Jeder Dienst besitzt ein Start-/Stop-Skript im Verzeichnis /etc/init.d diese werden dann den verschiedenen Runleveln zugeordnet.


/etc/rc0.d – Während das System herunterfährt
/etc/rcS.d – Während des Bootens ausführen
/etc/rc1.d – Arbeiten als einzelner Benutzer
/etc/rc2.d – Mehrbenutzerbetrieb inkl. Netzwerk
/etc/rc3.d bis /etc/rc5.d – Nicht genutzt
/etc/rc6.d – Während das System neu startet


Der Standard Runlevel von Debian / Ubuntu ist 2. Um diese Zuordnungen zu verstehen, zeige ich einfach ein Beispiel:

Befehl:

ls -alhF /etc/rc2.d/S20php5-fpm

Ausgabe:

lrwxrwxrwx 1 root root 18 28. Aug 02:10 /etc/rc2.d/S20php5-fpm -> ../init.d/php5-fpm*

Wie man sieht handelt es sich hierbei um einen Symbolischer-Link welcher auf ein Start-/Stop-Skript zeigt. Um diese Zuordnung zu ändern gibt es den Befehl “update-rc.d”

update-rc.d apache2 defaults

Defaults bedeutet, dass Apache in den Runleveln 2-5 gestartet und in allen anderen beendet wird.
In meinem Fall wollte ich den Dienst ausschauten und daher die Links entfernen, dies hab ich mittels diesem Befehl gemacht.

update-rc.d -f apache2 remove

Die Reihenfolge, vor/nach welchen anderen Scripts ein Dienst starten soll, wird über folgende Einstellungen geregelt.

Möchte man Apache z.B so einrichten, dass er nur in Runlevel 4 und 5 und nach allen anderen Diensten gestartet wird (99) , benutzt man folgende Zeile:

update-rc.d apache2 start 99 4 5 stop 01 0 1 2 3 6

Die Zeile hat folgende Bedeutung: Füge Startlinks (die mit “S99…” beginnen) in /etc/rc4.d und /etc/rc5.d ein, füge außerdem Stoplinks (die mit “K01…” beginnen) in den anderen rc.xd-Verzeichnissen ein. Apache wird also bei Runlevel-Wechseln zuletzt gestartet und zuerst wieder beendet.


Alternativ gibt es ein Front-End, welches dies ebenfalls erledigen kann, dieses muss in den meisten Fällen jedoch erst-einmal installiert werden.


aptitude install sysv-rc-conf
sysv-rc-conf

Mit dem Befehl “sysv-rc-conf” kannst du nun sehr bequem Dienst ein-/ und ausschalten. (dies hat natürlich keinen Einfluss auf die momentan laufenden Prozesse, dieser musst du z.B. mit “/etc/init.d/apache2 stop” oder “pkill apache2” beenden)

Webserver beschleunigen

Zurück zur “Webseiten beschleunigen” – Übersicht

5.) Webserver beschleunigen

5.1) Apache-Module deaktivieren


Ggf. kann man auch einige Module (Erweiterungen) von Apache abschaltet, wer z.B. auf seiner Webseite gar keine SSL-Verschlüsselung verwendet, könnte das entsprechende Modul deaktivieren.

a2dismod  ssl
/etc/init.d/apache2 restart

Die momentan aktiven Erweiterungen kann man unter “/etc/apache2/mods-enabled/” einsehen, die installierten Erweiterungen sind unter “/etc/apache2/mods-available/” zu finden.

Dynamische Seiten:
mod_log_config erlaubt die access_log-Dateien in div. Formaten.
mod_cgi braucht man, wenn man CGI zulassen will.
mod_suexec erlaubt CGIs als ein bestimmter User zu laufen.
mod_perl braucht man nicht um Perl als CGI auszuführen!
mod_php5 ist schneller als suphp (aber nicht so sicher).
mod_suphp führt php Skript mit den Rechten des entsprechenden webs aus.
mod_include erlaubt die Verwendung von SSI.

URL-Manipulationen:
mod_alias braucht man zum Einblenden von virtuellen Verzeichnissen.
mod_rewrite erlaubt URL-Manipulationen, kostet aber Performance.
mod_autoindex & mod_dir erlauben eine Navigation ohne index.html
mod_userdir erlaub User-URLs mit z.B.: www.huschi.net/~huschi/
mod_negotiation analysiert Accept-Anfragen.
mod_vhost_alias erlaubt das Anlegen von virtuellen Hosts.

Environment- & Header-Manipulation:
mod_mime setzt automatisch den richtigen Header anhand der Dateiendung.
mod_env & mod_setenvif erlauben die modifizierung von ENV-Variablen.
mod_expires erlaubt die HTTP-Header Manipulation des Expires-Date (Verfall-Zeit).
mod_ssl erlaubt die Verwendung von SSL (https).

Zudem kann man folgende Option in der Apache-Konfiguration ändern, so dass man DNS-Lookups reduziert.

vim /etc/apache2/apache2.conf

HostNameLookups off

5.2) Reverse Proxy (Nginx)

nginx_logo
Wir wollen unsere Webseite mal wieder ein wenig beschleunigen, dies können wir auf verschiedenen Wegen bewerkstelligen, heute beschäftigen wir uns mit dem Reverse-Proxy vor einem Webserver, in diesem Beispiel nutzen wir für diesen Zweck Nginx + apache2. Der große Vorteil von einen Proxy vor dem Webserver ist, dass mehrere Anfragen gleichzeitig gestellt werden könne, um die Performance von statischen Daten zu steigern. Die Anfragen an dynamische Inhalte werden dann noch immer an einen zweiten bzw. an mehrere Webserver, hinter dem Proxy weitergereicht.

Wer sich jetzt fragt, warum man nicht komplett auf Nginx umsteigen sollte, da die Benchmarks zeigen, dass dieser schneller ist als der Apache Webserver, derjenige hat nicht bedacht, dass bei diesen Tests nur die Reaktionen des Webservers auf eine gewisse Anzahl von Anfragen geprüft wird, wenn man jedoch mit “nginx + fcgi” viele php-Dateien verarbeiten möchte, ist ein “apache + mod_php” schneller, zudem kann man diese Daten z.B. mittels eAccelerator zusätzlich cachen, was die Geschwindigkeit von php-Daten noch einmal positiv beeinflusst.

Update: Inzwischen konnte ich die ganzer Sache ausgiebig testen und setzte momentan eine Kombination aus “Varnish” + “Nginx” + “php5-fpm” (+ xcache) ein, so werden die Seiten von Varnish zwischengespeichert alle neue Anfragen von Nginx entgegengenommen, Bilder etc. sofort ausgeliefert und PHP-Anfragen an einen laufendem PHP-Daemon weitergereicht, jedoch erst-einmal zurück zum Beispiel mit Nginx als Reverse-Proxy…

Als Lösung für diese Problem habe ich mir einen Nginx-Proxy gebastelt, der statische Daten (Bilder…) ausliefert und diese zusätzlich für 24 Stunden zwischenspeichert, alle andern dynamischen Inhalte (php,cgi…) werden sofort an apache durch-gereicht. In diesem Beispiel laufen sowohl der Proxy als auch Apache auf einem Server.
reverse_proxy

5.2.1.) Apache auf einem neuen Port laufen lassen

Folgende Datei öffnen…

vim /etc/apache2/ports.conf

…Port “80” durch z.B. “127.0.0.1:8080” ersetzen.

[stextbox id=”warning”]!!! Wichtig ist hier, darauf zu achten, dass der Apache selber nicht mehr über eine Öffentliche IP-Adresse erreichbar ist. !!![/stextbox]

Ggf. helfen dir die folgenden Zeilen weiter, um alle Einträge in einer Datei zu Ändern (mit vi / vim).

:%s/^80/127.0.0.1:8080/g

:%s/SERVER_IP_ADRESSE:80/127.0.0.1:8080/g

SERVER_IP_ADRESSE muss nun noch mit der IP-Adresse des Servers ersetzte werden und anschließend musst du den Apache Webserver noch neu-starten. Ggf. müssen noch weitere Dateien von Apache angepasst werden.

Mit dem folgendem Befehl kannst du prüfen, ob noch weitere Einträge (Port 80) in der Apache Konfiguration sind.

/bin/grep -wr 80 /etc/apache2/


5.2.2) Ggf. ISPConfig anpassen

Falls du z.B. ISPConfig installiert hat, werden wie Änderungen am Apache Webserver, bei der nächsten Änderung über die Admin-Oberfläche wieder verworfen, daher müssen wir das Template von ISPConfig dementsprechend anpassen.

vim ~/ispconfig/isp/conf/vhost.conf.master

NameVirtualHost 127.0.0.1:8080


5.2.3.) Reverse-Proxy: nginx installieren & konfigurieren

aptitude install nginx
vim /etc/nginx/nginx.conf
user www-data;
worker_processes 4;
worker_rlimit_nofile 3000;
pid /var/run/nginx.pid;

# [ debug | info | notice | warn | error | crit ]
error_log /var/log/nginx/error.log;

#google_perftools_profiles /tmp/profile/;

events {
        worker_connections 2048;
        # use [ kqueue | rtsig | epoll | /dev/poll | select | poll ] ;
        use epoll;
        multi_accept on;
}

http {
        server_names_hash_bucket_size 64;

        ## Size Limits
        client_max_body_size        10M;
        client_header_buffer_size   32k;
        client_body_buffer_size     128k;
        large_client_header_buffers 64 8k;

        ## Timeouts
        client_body_timeout   3m;
        client_header_timeout 3m;
        send_timeout          3m;
        #expires              24h;
        keepalive_timeout     120 120;

        ## General Options
        ignore_invalid_headers   on;
        keepalive_requests       100;
        limit_zone normal $binary_remote_addr 5m;
        recursive_error_pages    on;
        sendfile                 on;
        server_name_in_redirect  off;
        server_names_hash_max_size 512;
        server_tokens            off;
        set_real_ip_from 127.0.0.1;
        real_ip_header X-Forwarded-For;

        ## TCP options
        #tcp_nopush on;
        tcp_nodelay off;
        #send_lowat 12000;

        include mime.types;
        default_type application/octet-stream;

        access_log /var/log/nginx/access.log;

        log_format main '$remote_addr - $remote_user [$time_local] $status '
        '\"$request\" $body_bytes_sent \"$http_referer\" '
        '\"$http_user_agent\" \"http_x_forwarded_for\"';

        ## Cache
        open_file_cache max=1000 inactive=24h;
        open_file_cache_valid    24h;
        open_file_cache_min_uses 2;
        open_file_cache_errors   on;

        ## Compression
        gzip              on;
        gzip_static       on;
        gzip_disable      "MSIE [1-6]\.";
        gzip_buffers      32 8k;
        gzip_comp_level   5;
        gzip_http_version 1.0;
        gzip_min_length   0;
        gzip_proxied      any;
        gzip_types text/plain text/css text/xml text/javascript application/json application/xml application/xml+rss application/x-javascript image/x-icon application/x-perl application/x-httpd-cgi;
        gzip_vary         on;

        output_buffers   10 128k;
        postpone_output  1500;

        # Beispiel: Loadbalance
        #upstream webbackend  {
                #ip_hash;
                #server web1.domain.lan weight=10 max_fails=3 fail_timeout=30s;
                #server web2.domain.lan weight=1 backup;
        #}
        # Beispiel: Reverse-Proxy
        #server {
                #access_log  /var/log/nginx/access.proxy.log main;
                #error_log   /var/log/nginx/error.proxy.log;
                #listen      80;
                #server_name _;

                ## PROXY - Web
                #location ~ \.php$ {
                        #proxy_cache            cache;
                        #proxy_pass  http://127.0.0.1:8080;
                #}
        #}

        # Beispiel: HTTP Server (sollte jedoch besser unter /etc/nginx/sites-available/ angelegt werden)
        #server {
                #listen       8000;
                #listen       somename:8080;
                #server_name  somename  alias  another.alias;

                #location / {
                        #root   html;
                        #index  index.html index.htm;
                        #}
                #}

        # Beispiel: HTTPS Server (sollte jedoch besser unter /etc/nginx/sites-available/ angelegt werden)
        #server {
                #listen       443;
                #server_name  localhost;

                #ssl                  on;
                #ssl_certificate      cert.pem;
                #ssl_certificate_key  cert.key;

                #ssl_session_timeout  5m;

                #ssl_protocols  SSLv2 SSLv3 TLSv1;
                #ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
                #ssl_prefer_server_ciphers   on;

                #location / {
                #root   html;
                #index  index.html index.htm;
                #}
        #}

include /etc/nginx/proxy.conf;
include /etc/nginx/sites-enabled/*.conf;
}
vim /etc/nginx/proxy.conf
proxy_buffering            on;
proxy_cache_min_uses       3;
proxy_cache_path           /usr/local/nginx/proxy_cache/ levels=1:2 keys_zone=cache:10m inactive=24h max_size=1000M;
proxy_cache                cache;
proxy_cache_valid          200 24h;
proxy_cache_use_stale      error timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_ignore_client_abort  off;
proxy_intercept_errors     on;
proxy_next_upstream        error timeout invalid_header;
proxy_redirect             off;
proxy_set_header           Host            $host;
proxy_set_header           X-Real-IP       $remote_addr;
proxy_set_header           X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffers              32 1M;
proxy_busy_buffers_size    31M;
proxy_temp_file_write_size 30M;
proxy_buffer_size          30M;
proxy_connect_timeout      90;
proxy_send_timeout         90;
proxy_read_timeout         90;
proxy_ignore_headers       Expires Cache-Control;
mkdir /usr/local/nginx/proxy_cache/
chown -R www-data:www-data /usr/local/nginx/proxy_cache/

Link:
wiki.nginx.org/NginxHttpProxyModule

/etc/init.d/apache2 restart
/etc/init.d/nginx restart

Nginx läuft nun auf Port 80 und nimmt die Anfragen von Client an und der Apache wartet auf die weitergeleiteten Anfragen von Reverse-Proxy.

[stextbox id=”info”]Bei mir hat der cache (Zwischenspeicherung) jedoch Probleme verursacht, so dass Captcha’s nicht mehr funktioniert haben, daher habe ich diesen im Nachhinein abgeschaltet.[/stextbox]


Links:
www.joeandmotorboat.com/2008/02/28/apache-vs-nginx


5.2.4.) Logfiles korrigieren

Nun stehen wir noch vor dem Problem, dass im Logfile von apache die IP-Adresse vom Reverse-Proxy auftauscht und zwar nur noch diese, um dies zu umgehen installieren wir nun noch folgendes…

aptitude install libapache2-mod-rpaf

Nun noch folgendes in den Vhost-Einträgen bzw. in dem ISPConfig Template ergänzen.


RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1

/etc/init.d/apache2 reload

…und schon haben wir einen Reverse-Proxy (“Apache” + “Nginx”) installiert. Unter Punkt 5.3 zeige ich wie du ganz auf Nginx setzten kannst und somit nicht zwei Webserver, betreiben & konfigurieren musst.