Re: Verarbeiten von *grossen* HTTP-uploads

On 2007-10-19 21:35, Ulli Horlacher <framstag@xxxxxxxxxxxxxxxxxxxx> wrote:
Ich muss *richtig* *GROSSE* HTTP-uploads verarbeiten. Das kann bis in den
TB-Bereich gehen.

Der Apache (2.0) streikt schon bei laecherlichen 2 GB, also habe ich
selber einen Mini-Webserver (cgilaunch) geschrieben, der im Wesentlichen
nur CGIs startet mit exec($cgi). Meine CGI-Scripte benutzen das Perl
CGI-Modul.

Bei HTTP GET funktioniert das auch einwandfrei, nur bei HTTP POST haengen
sich die cgis auf. Ich hab das Problem dann lokalisiert: CGI.pm wertet
leider CONTENT_LENGTH nicht aus, sondern liest bis EOF. Das kommt aber
nicht, der Client haelt die Verbindung offen.

Mein Workaround ist nun, dass mein cgilaunch die Daten vom Client liest
und sie via pipe an das cgi-script weiterreichen und nach CONTENT_LENGTH
Bytes die Pipe schliesst (*). Dann bekommt CGI.pm sein EOF und alles
funktioniert.

Das ist kein Workaround, das muss so sein. HTTP ist ein Protokoll, CGI
ist ein anderes Protokoll. Der Client spricht mit dem Webserver HTTP,
der Webserver mit dem CGI-Script CGI. Der Client kennt das CGI-Protokoll
nicht, also kannst Du ihn nicht direkt mit dem CGI-Script reden lassen -
du brauchst einen "Protokoll-Übersetzer" dazwischen. (Alternativ kannst
Du natürlich Scripts schreiben, die nicht CGI sondern HTTP sprechen -
nachdem Du ohnehin schon einen Webserver geschrieben hast, ist das
wahrscheinlich die sinnvollere Variante).


Leider ist das im GB-Bereich nicht grad effizient. Im top sehe ich, dass
cgilaunch und das cgi-script sich um die CPU pruegeln. Beide sind so bei
knapp 50%.

Das soll ja idealerweise auch so sein. Du kopierst von Memory eines
Prozesses ins Memory eines anderen Prozesses. Dazwischen ist kein
I/O-Gerät, auf das man warten müsste, also ist das vollständig CPU-bound
und beide haben ungefähr den gleichen Anteil daran.

(in der Praxis tun Deine Prozesse natürlich noch anderes: Der Webserver
liest von einem Socket und der CGI-Prozess schreibt vermutlich auf die
Disk - wenn Du nicht ein sehr schnelles Netzwerk und sehr sehr
schnelle Disks hast, würde ich das Bottleneck eher dort erwarten).

Die entscheidendere Frage ist, welche Übertragungsraten erreichst Du da?
Sind die in der Gegend von dem, was Du auf Grund der Hardware erwarten
kannst (zum Vergleich: Auf eim 1.86 GHz Core2 erreiche ich ca. 800
MByte/s).


(*) Code-Schnipsel dazu:

if ($cl = $ENV{CONTENT_LENGTH}) {
if (open P,"|$cgi") {
nvt_print("HTTP/1.1 200 OK");
nvt_print("Server: cgilaunch");
$rb = 0;
$bs = 512;

512 ist verdammt klein. Im schlimmsten Fall ergibt das einen
Kontext-Switch alle 512 Bytes, und im besten Fall hast Du noch den
Interpreter-Overhead, alle 512 Bytes ein paar Perl-Operationen aufrufen
zu müssen. Ich würde das auf mindestens 4096 oder wahrscheinlich eher
auf 1 MB oder so erhöhen.

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@xxxxxx |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
.

Relevant Pages

  • Re: Verarbeiten von *grossen* HTTP-uploads
    ... und sie via pipe an das cgi-script weiterreichen und nach CONTENT_LENGTH ... Bytes die Pipe schliesst. ... mit dem Webserver HTTP, der Webserver mit dem CGI-Script CGI. ... Bei HTTP GET brauch ich das nicht, ...
    (de.comp.lang.perl.cgi)
  • Re: Verarbeiten von *grossen* HTTP-uploads
    ... Bei HTTP GET funktioniert das auch einwandfrei, ... dass mein cgilaunch die Daten vom Client liest ... und sie via pipe an das cgi-script weiterreichen und nach CONTENT_LENGTH ... Der Client spricht mit dem Webserver HTTP, ...
    (de.comp.lang.perl.cgi)
  • Re: Verarbeiten von *grossen* HTTP-uploads
    ... und sie via pipe an das cgi-script weiterreichen und nach CONTENT_LENGTH ... mit dem Webserver HTTP, der Webserver mit dem CGI-Script CGI. ... Bei HTTP GET brauch ich das nicht, ... Aus dem CGI-Header einen HTTP-Header basteln und an den Client ...
    (de.comp.lang.perl.cgi)
  • =?iso-8859-1?q?SSL_Serverver=F6ffentlichung,_intern_nur_HTTP,_Erkennung_auf_Webserver=3F?=
    ... ISA zum Webserver erfolgt nur via HTTP. ... Gibt es eine Möglichkeit den Verbindungstyp (verwendet der Client bis ...
    (microsoft.public.de.german.isaserver)
  • Re: How to secure a webserver in a DMZ
    ... If your webserver gets comprised, your DB is open as well. ... How easy would it be for an "advanced agressor" to load evil code (for ssh-over-https-tunneling i.e.) from the internet, if the only connection to the webserver is encrypted http inbound and outbound traffic is not allowed? ... If anybody was able to compromise the Reverse proxy over https, than he could even go further and compromise the backand webserver through tricky-http stuff also? ...
    (Security-Basics)