Strona internetowa w C++

0

Witam,

Czy warto napisać swój własny serwer http w c++ zamiast używać apache do wielkiego serwisu internetowego?

Pisząc własny serwer miałbym pewność, że nie ma w nim żadnych luk, do podstron zamiast używać php bym je pisał w c++ jako aplikacja wielowątkowa (wg. mnie szybciej by się generowały niż te w php). SQL też mógłbym używać bez problemu.

Czy jest sens takiego rozwiązania? Czy narzuca to jakieś ograniczenia? A może apache jest napisane perfekcyjnie, że zawsze będzie szybsze niż mój wielowątkowy serwer.

Pozdrawiam,
Kokoroko

0

Napisz od razu system operacyjny pod ten serwer będzie wtedy 100% pewności że nic nie zawiedzie [green] .

0
Kokoroko napisał(a)

Pisząc własny serwer miałbym pewność, że nie ma w nim żadnych luk

Skoro miałbyś pewność to daj sobie spokój z byle serwerem HTTP, idź co Microsoftu kernele pisać za grubą kasę. Tak całkiem poważnie - każdy popełnia błędy, nowy kod ma wręcz gwarancję posiadania pewnego bagażu błędów. Statystycznie wychodzi od 5 do 50 bugów na tysiąc linii kodu, istniejący dłuższy czas soft ma już część z tego naprawione.

Kokoroko napisał(a)

do podstron zamiast używać php bym je pisał w c++ jako aplikacja wielowątkowa (wg. mnie szybciej by się generowały niż te w php).

Największe obciążenie i tak stanowi baza danych. Kod w języku skryptowym można po prostu przeedytować - chcesz przy dodaniu kropki cały serwer rekompilować? Obecne na rynku serwery HTTP są wielowątkowe i w jakimś stopniu zoptymalizowane, wielkiego przyrostu wydajności nie uzyskasz, o ile w ogóle.

Co z wygodą i szybkością tworzenia tej 'strony internetowej'? Do innych języków istnieją świetne frameworki webowe, są ORM-y (rzecz niemożliwa do sensownego zaimplementowania w C++). Naprawdę chcesz tracić czas na pisanie wszystkiego od podstaw?

Kokoroko napisał(a)

A może apache jest napisane perfekcyjnie, że zawsze będzie szybsze niż mój wielowątkowy serwer.

Jest napisane tragicznie. Do PHP się jednak sprawdza nieźle... może dlatego, że interpreter PHP jest równie tragiczny.

Jak sobie radzisz z wielowątkowością, jak znasz protokoły sieciowe, pod jaki system to ma być? Naprawdę nie widzę sensu wynajdywania koła na nowo, do tego z użyciem jednej z wredniejszych technologii (C++).

0

Pod windows'a (przez kilkanaście lat używania go za bardzo się przyzwyczaiłem do niego)

A napisałem, że będę miał pewność, że będzie bez luk bo ten serwer byłby krótki (w linijkach kodu), wg. mnie wystarczyło by żeby tylko obsługiwało post, get i inne podstawowe pakiety. Nie musi przecież być tak rozwinięty jak apache. I bez problemu bym wyłapał wszystkie buffer overflow itd, błędy z backtrack dir, a w takich apache to nie mam pewności, że tam tego nie ma. A planuje serwis na kilkaset tysięcy użytkowników (mam pomysł jak to osiągnąć) więc na pewno ktoś będzie się próbował znaleźć jakąś lukę.

Pozdrawiam i z góry dziękuję za odpowiedź

0

To może, zamiast Apache to nginx, z którego sam korzystam do RoR'a. Wprawdzie PHP tylko przez FastCGI, ale chyba i tak jest szybsze.

0

Statystycznie wychodzi od 5 do 50 bugów na tysiąc linii kodu, istniejący dłuższy czas soft ma już część z tego naprawione.
Dokładnie. NASA na przykład szuka błędów tak długo, aż znajdzie się ich statystycznie przewidywana liczba…

0

I czego się czepiasz? To autentyczne oszacowania dla bardziej skomplikowanego oprogramowania. Nikt nie mówi, że tyle tego dokładnie jest.

0

Google App Engine się świetnie skaluje, można spokojnie zrobić na nim cały serwis oprócz modułu płatności, bo numery kart kredytowych / kont bankowych itp itd to wrażliwa sprawa i należy to trzymać na prywatnym serwerze. Baza danych oparta na BigTable też należy do najszybszych.

0

Postaw sobie ten serwer na INDY - IdHTTPServer. Kiedy już ci wyjdzie bokiem - daj znać. Na kilkadziesiąt tysięcy userów robienie autorskiego skryptu to samobójstwo.

1 użytkowników online, w tym zalogowanych: 0, gości: 1