Zaproponuj błyskawiczny, funkcjonalny i bezpieczny serwer WWW z systemem Linux do obsługi zawartości statycznej [zamknięte]


14

Lista niezbędnych wymagań:

  • być w stanie obsługiwać statyczne strony HTML i pliki (obrazy, skompresowane archiwa, pliki tekstowe ASCII itp.) przez HTTP.
  • bądź konserwatywny w stosunku do zasobów . Wykorzystuje to, co jest potrzebne do przesyłania danych przez sieć w postaci pamięci i procesora, i niewiele więcej.
  • mieć niewielką powierzchnię instalacyjną.
  • używaj tylko tyle pasma sieci, ile jest konieczne.
  • być dojrzałym .
  • być łatwy w konfiguracji.
  • być skompilowanym w natywnym kodzie. Bez Python lub Java itp.

Czego nie potrzebuję:

  • Złożone opcje konfiguracji. W razie potrzeby przejdę na httpd Apache.
  • Obsługa uruchamiania CGI, Perl, PHP, Java, po stronie serwera lub innych „dodatków”.

Wszelkie sugestie proszę?


9
Nazwałbym to błyskawicą, wolną od cech, bezpiecznym serwerem WWW dla Linuksa. Nie jestem jednak pewien, czy ta nazwa się przyda.
Dominic Rodger

Myślę, że oni też o tym pomyśleli, ale zdecydowali się na `nginx '.

Zawsze możesz użyć pythona: „python -m SimpleHTTPServer”, to serwer będzie serwował bieżący katalog na porcie 8000.
Gert M

Odpowiedzi:




8

Jest wiele, ale osobiście lubię Cherokee. Jest stosunkowo nowy, ale także bardzo prosty w konfiguracji z wbudowanym GUI.


czy to jest nadal ważne?
BigSack,

8

Może zostanę przegłosowany, ponieważ te rozwiązania nie są skompilowane w natywnym kodzie zgodnie z listą „must have” pytania, ale w przypadku treści statycznych nie jest to znacznie łatwiejsze niż udostępnienie bieżącego katalogu za pomocą linijki Pythona:

python -m SimpleHTTPServer 9914

Zauważ, że port 9914 jest dowolny i po prostu użyłem przykładu, w którym znalazłem to rozwiązanie: http://linux.byexamples.com/archives/506/python-simple-http-server-for-file-sharing

Oczywiście możesz to również zrobić za pomocą Perla:

perl -MIO::All -e 'io(":8080")->fork->accept->(sub { $_[0] < io(-x $1 ? "./$1 |" : $1) if /^GET \/(.*) / })'

. . . zgodnie z opisem na stronie http://search.cpan.org/~ingy/IO-All-0.39/lib/IO/All.pod#A_Tiny_Web_Server



5

Serwer, który dokładnie opisałeś:

  • kHTTPd - w jądrze, bardzo prosty serwer. Tylko pliki statyczne.

Płonące szybkie serwery, które w razie potrzeby mogą również obsługiwać strony dynamiczne:

  • LigHTTPd - serwer wykonany jako dowód koncepcji rozwiązania problemu C10K.
  • nginx - bardzo popularny, często używany do przesyłania strumieniowego lub jako odwrotne proxy.

4

Kilku komentatorów wspomniało o lighttpd. Inną opcją jest thttpd.


1
wygląda dobrze, czy tego właśnie używa Wile E Coyote? ;)

Czy to wciąż żyje? Ostatnie wydanie miało miejsce w grudniu 03, a archiwum listy mailingowej zatrzymało się w maju 08
JonDrnek

4

Szybkie, bezpieczne, wydajne, niskie cechy: plik publiczny Dan Bernstein.


Korzystamy z pliku publicznego w kilku miejscach, w tym do prostych zadań, takich jak wewnętrzna dystrybucja plików konfiguracyjnych WPAD. Bardzo szybki, bardzo prosty, zawsze działa.
mikebabcock,

3

czy kHTTPd - serwer wbudowany w jądro Linuksa?


Pierwsza rzecz, która przyszła mi do głowy. Nie korzystałem z niego, ale widziałem tę opcję za każdym razem, gdy konfiguruję jądro.

BTW, ze strony internetowej: „Od jądra 2.3.14 kHTTPd jest zintegrowany z jądrem”. Tak było kilka razy wokół bloku.

5
Jednak od jądra 2.6 nie jest ono już wbudowane w jądro.
MarkR

3

Poszedłbym tu z Cherokee . Poza tym zapomnę o Apache. Wszyscy dorastaliśmy, czule, używając apache, dobrze się z tym bawiąc i mysql. Wszyscy mamy wspaniałe wspomnienia i wszyscy wiemy, jak z nich korzystać. :)

To jednak przeszłość, zabarwiona przez szklanki w kolorze różowym. Wykorzystanie pamięci fat ass, procesy tłuszczu, złożone pliki konfiguracyjne, wbudowane interpretery .. feh. W dzisiejszych czasach VPS nikt już nie potrzebuje apaszki na grubą dupę. Uwielbiaj wspomnienia, ale zapisz pamięć RAM dla swoich aplikacji.


2

Używam mathopd przez ostatnie 2 lata do udostępniania treści statycznych [mieszanka zdjęć na stronie e-commerce + kilka dużych plików do pobrania]. bez bólu głowy - łatwy w konfiguracji, po prostu działa i pozostawia procesor obok bezczynności.


2

Od lat mam doskonałe wyniki dzięki thttpd , często obsługując ponad 250 żądań na sekundę (i to uśredniałem w ciągu godziny) i aż 400 równoczesnych żądań. Zużycie pamięci jest niskie, stabilność bardzo wysoka, a obciążenie systemu jest prawie niczym, nawet przy dużym obciążeniu / s.

Bill the Cat z Hrabstwa Bloom wyjaśnia, jak wymówić thttpd .


1

Możesz zajrzeć na http://www.lighttpd.net/. Nie jestem pewien, czy to przesada w stosunku do twoich wymagań.


1

Istnieje komercyjny serwer WWW o nazwie Zeus, który jest dość szeroko stosowany w branżach związanych z treścią, charakteryzujących się dużą ilością treści statycznych. IIRC opiera się na asynchronizacji. I / O, co jest bardzo wydajne na procesorze. Może robić, co chcesz, ale nie jest za darmo.


1

Możesz spróbować okws .

OKWS to serwer sieciowy, specjalizujący się w tworzeniu szybkich i bezpiecznych usług internetowych. Zapewnia programistom sieci Web niewielki zestaw narzędzi, które okazały się wystarczająco potężne, aby tworzyć złożone systemy przy ograniczonym wysiłku. Pomimo nacisku na bezpieczeństwo, OKWS wykazuje przewagę wydajności w stosunku do popularnych konkurentów: podczas obsługi w pełni dynamicznych obciążeń bazy danych niepowiązanych z dyskami, przepustowość i szybkość reakcji OKWS przewyższa Apache , Flash (królujący król wydajności serwerów WWW) i Haboob ( system akademicki uważany za najszybszy serwer Java w sieci w tym bloku). Doświadczenie handlowe z OKWS sugeruje, że system może obniżyć koszty sprzętu i zarządzania systemem, zapewniając jednocześnie gwarancje bezpieczeństwa nieobecne w obecnych systemach.

skopiowane z okws.org


1

Aby być mniej lub bardziej kompletnym, nie zapomnij o Hiawatha . Rozwój tego jest dość aktywny i ma przyjazną i pomocną społeczność.


0

Wspomniano już o większości bezpiecznych i lekkich serwerów sieciowych (np. Plik publiczny, Nginx, Cherokee itp.). Jeśli żadne z nich nie przejdzie do twoich wymagań, myślę, że proponuję hostować twoje pliki statyczne (zasoby) w AWS S3 i CloudFront i Witrynach Google dla twoich stron internetowych.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.