Ile połączeń przez gniazdo może obsłużyć serwer WWW?


114

Powiedzmy, że gdybym miał uzyskać hosting współdzielony, wirtualny lub dedykowany, czytałem gdzieś, że serwer / maszyna może obsłużyć tylko 64 000 połączeń TCP jednocześnie, czy to prawda? Ile może obsłużyć dowolny typ hostingu niezależnie od przepustowości? Zakładam, że HTTP działa przez TCP.

Czy oznaczałoby to, że tylko 64 000 użytkowników mogłoby połączyć się z witryną, a gdybym chciał obsługiwać więcej, musiałbym przenieść się na farmę internetową?


2
Przepraszam ratowników, przedarłem się przez ten wątek jak tornado. Jak na mój gust, było po prostu zbyt wiele błędnych odpowiedzi i nadal brakowało bezpośredniej odpowiedzi. Często używam stackoverflow i znajduję wiele wysokiej jakości odpowiedzi. Mam nadzieję, że inni będą mogli znaleźć ten wątek i znaleźć użyteczną, świadomą odpowiedź.
Todd

Cześć David, czy znalazłeś właściwą odpowiedź na to pytanie?
Danie

64000 połączeń TCP na jednym IP serwera. Można uaktualnić swoją sieć serwerów do skali i obsługiwać więcej niż 64000.
Airy

Odpowiedzi:


109

Krótko mówiąc: powinieneś być w stanie osiągnąć w liczbę milionów jednoczesnych aktywnych połączeń TCP i przez rozszerzenie żądania HTTP. Dzięki temu uzyskasz maksymalną wydajność, jakiej możesz oczekiwać dzięki odpowiedniej platformie i odpowiedniej konfiguracji.

Dzisiaj martwiłem się, czy IIS z ASP.NET będzie obsługiwał w kolejności 100 jednoczesnych połączeń (spójrz na moją aktualizację, oczekuj ~ 10 tys. Odpowiedzi na sekundę w starszych wersjach ASP.Net Mono). Kiedy zobaczyłem to pytanie / odpowiedzi, nie mogłem się powstrzymać od odpowiedzi, wiele odpowiedzi na to pytanie jest całkowicie błędnych.

Najlepszy przypadek

Odpowiedź na to pytanie musi dotyczyć tylko najprostszej konfiguracji serwera, aby oddzielić ją od niezliczonych zmiennych i konfiguracji możliwych do wykonania na dalszych etapach.

Rozważ więc następujący scenariusz mojej odpowiedzi:

  1. Brak ruchu na sesjach TCP, z wyjątkiem pakietów utrzymujących aktywność (w przeciwnym razie oczywiście potrzebowałbyś odpowiedniej przepustowości sieci i innych zasobów komputera)
  2. Oprogramowanie zaprojektowane do korzystania z asynchronicznych gniazd i programowania zamiast wątku sprzętowego na żądanie z puli. (tj. IIS, Node.js, Nginx ... serwer sieciowy [ale nie Apache] z aplikacjami zaprojektowanymi asynchronicznie)
  3. Dobra wydajność / dolarowy procesor / pamięć RAM. Dziś arbitralnie powiedzmy i7 (4 rdzenie) z 8 GB pamięci RAM.
  4. Dobry firewall / router.
  5. Brak wirtualnego limitu / zarządcy - tj. Linux somaxconn, IIS web.config ...
  6. Brak zależności od innego wolniejszego sprzętu - brak odczytu z dysku twardego, ponieważ byłby to najniższy wspólny mianownik i wąskie gardło, a nie sieciowe IO.

Szczegółowa odpowiedź

Synchroniczne projekty powiązane z wątkami mają zwykle najgorszą wydajność w porównaniu z implementacjami asynchronicznych operacji we / wy.

WhatsApp uzyskuje milion z ruchem na pojedynczym systemie operacyjnym o smaku Unix - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .

I wreszcie ten, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , zawiera wiele szczegółów , badając, jak można osiągnąć nawet 10 milionów. Serwery często mają sprzętowe silniki odciążania TCP, układy ASIC zaprojektowane do tej konkretnej roli wydajniej niż procesory ogólnego przeznaczenia.

Dobre możliwości projektowania oprogramowania

Projektowanie asynchronicznych operacji we / wy będzie się różnić w zależności od systemów operacyjnych i platform programowania. Node.js został zaprojektowany z myślą o asynchroniczności . Powinieneś przynajmniej użyć Promises, a kiedy pojawi się ECMAScript 7, async/ await. C # / .Net ma już pełną obsługę asynchroniczną, taką jak node.js. Niezależnie od systemu operacyjnego i platformy, asynchroniczne powinny działać bardzo dobrze. Niezależnie od wybranego języka poszukaj słowa kluczowego „asynchroniczny”. Większość współczesnych języków będzie miała pewne wsparcie, nawet jeśli jest to jakiś dodatek.

Do WebFarm?

Bez względu na ograniczenia w twojej konkretnej sytuacji, tak, farma internetowa to dobre rozwiązanie do skalowania. Istnieje wiele architektur, które to umożliwiają. Jednym z nich jest równoważenie obciążenia (dostawcy hostingu mogą je oferować, ale nawet oni mają limit wraz z limitem przepustowości), ale nie preferuję tej opcji. W przypadku aplikacji jednostronicowych z długotrwałymi połączeniami wolę zamiast tego mieć otwartą listę serwerów, z których aplikacja kliencka będzie wybierać losowo podczas uruchamiania i ponownie używać przez cały okres istnienia aplikacji. Eliminuje to pojedynczy punkt awarii (moduł równoważenia obciążenia) i umożliwia skalowanie w wielu centrach danych, a tym samym znacznie większą przepustowość.

Obalamy mit - porty 64K

Aby odpowiedzieć na pytanie dotyczące „64 000”, jest to błędne przekonanie. Serwer może łączyć się z wieloma ponad 65535 klientami. Zobacz /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284

Nawiasem mówiąc, Http.sys w systemie Windows umożliwia wielu aplikacjom współużytkowanie tego samego portu serwera w ramach schematu adresu URL HTTP. Każdy z nich rejestruje oddzielne powiązanie domeny, ale ostatecznie istnieje jedna aplikacja serwerowa, która przekazuje żądania do odpowiednich aplikacji.

Aktualizacja 2019-05-30

Oto aktualne porównanie najszybszych bibliotek HTTP - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

  • Data testu: 2018-06-06
  • Używany sprzęt: Dell R440 Xeon Gold + 10 GbE
  • Lider ma ~ 7 mln odpowiedzi w postaci zwykłego tekstu na sekundę (odpowiedzi, a nie połączenia)
  • Drugi Fasthttp dla golanga reklamuje 1,5 mln równoczesnych połączeń - patrz https://github.com/valyala/fasthttp
  • Wiodącymi językami są Rust, Go, C ++, Java, C, a nawet C # w rankingu 11 (6,9 mln na sekundę). Scala i Clojure zajmują niższe pozycje. Python zajmuje 29 miejsce z szybkością 2,7 mln na sekundę.
  • Na dole listy notuję laravel i cakephp, rails, aspnet-mono-ngx, symfony, zend. Wszystko poniżej 10 tys. Na sekundę. Uwaga, większość tych frameworków jest zbudowana dla stron dynamicznych i jest dość stara, mogą istnieć nowsze warianty, które znajdują się wyżej na liście.
  • Pamiętaj, że jest to zwykły tekst HTTP, a nie specjalizacja Websocket: wiele osób przyjeżdżających tutaj będzie prawdopodobnie zainteresowanych równoczesnymi połączeniami dla protokołu Websocket.

2
Dziękujemy za dołączenie linków do osób, które mówią o tym, jak to robią.
Rick Smith

Co się stanie, jeśli pojedynczy serwer, do którego jest podłączony klient, ulegnie awarii? A co, jeśli całe Twoje SPA zostanie przypadkowo połączone z jednym serwerem i przeciążone? Pomysł na użycie loadbalancerów nie polega tylko na użyciu 1, możesz używać wielu, ile chcesz
pyros2097

3
Klienci losowo wybierają serwer. Szanse na przypadkowe połączenie się z jednym są praktycznie niemożliwe. Chociaż można śledzić liczbę klientów, a serwer mógłby poprosić klienta o przeniesienie się na inny serwer, jeśli jest zbyt przepełniony.
Todd

1
Re: ograniczenie 64 KB - to, co mówisz, jest prawdą, ale jest dość powszechne, że aplikacja serwera wysyła żądania proxy przez niektóre usługi backendu, w którym to przypadku „serwer” staje się teraz „klientem” i może mieć martwić się o efemeryczne wyczerpanie portu (np .: nginx.com/blog/overcoming-ephemeral-port-exhaustion-nginx-plus ). Na pewno o tym wiesz, ale wspominam o tym dla innych (:
jwd

@jwd to dobra uwaga, kontekstowa dla nginx w aplikacji internetowej, ale w przypadku podstawowej witryny internetowej takie proxy nie musiało występować. To samo można powiedzieć o łączeniu się z bazą danych przez TCP przez aplikację internetową. Teoretycznie można to rozwiązać, używając wszystkich adresów z zakresu 127. *. *. *, Ale w praktyce nie wiem, czy jest to dostępna opcja.
Todd

54

To dość trudne pytanie. Nie ma rzeczywistego ograniczenia oprogramowania co do liczby aktywnych połączeń, które może mieć komputer, chociaż niektóre systemy operacyjne są bardziej ograniczone niż inne. Problem staje się jednym z zasobów. Na przykład, powiedzmy, że pojedynczy komputer chce obsługiwać 64 000 jednoczesnych połączeń. Jeśli serwer używa 1 MB pamięci RAM na połączenie, potrzebuje 64 GB pamięci RAM. Jeśli każdy klient musi odczytać plik, obciążenie dostępu do dysku lub macierzy pamięci staje się znacznie większe niż te urządzenia mogą obsłużyć. Jeśli serwer musi rozwidlać jeden proces na połączenie, system operacyjny będzie spędzał większość czasu na przełączaniu kontekstu lub ograniczaniu czasu procesora.

Strona z problemem C10K zawiera bardzo dobre omówienie tego zagadnienia.


3
Trochę mieszana odpowiedź. Wydaje się, że PO odnosi się do najlepszego scenariusza i zawiera informacje o tym, jaki byłby korzystny, a nie do znalezienia najgorszego przypadku, a następnie do artykułu, który może zawierać rozwiązanie. Zwrócenie uwagi na wąskie gardło dysku jest przydatne. Korzystając z asynchronicznych operacji we / wy, można osiągnąć bardzo dużą liczbę współbieżnych klientów.
Todd

Jak możesz powiedzieć, że nie ma prawdziwego ograniczenia oprogramowania, ponieważ sam rozmiar portu wynosi 16 bitów, co sprawia, że ​​maksymalna liczba portów nie jest dostępna w dowolnym momencie przy maks. 65,5K. Uważam, że twoja odpowiedź jest nieprawidłowa.
आनंद

Twoje urządzenie może mieć więcej niż 1 adres IP, więc dostępnych jest więcej niż 2 ^ 16 portów.
Arman Ordookhani

8

Aby dodać moje dwa centy do konwersacji, proces może mieć jednocześnie otwartą liczbę podłączonych gniazd równą tej liczbie (w systemach typu Linux) / proc / sys / net / core / somaxconn

cat / proc / sys / net / core / somaxconn

Ta liczba może być modyfikowana w locie (oczywiście tylko przez użytkownika root)

echo 1024> / proc / sys / net / core / somaxconn

Ale całkowicie zależy od procesu serwera, sprzętu maszyny i sieci, rzeczywistej liczby gniazd, które można podłączyć przed awarią systemu


1
Chociaż prawdopodobnie dotyczy to Linuksa, odnosi się to do wirtualnego limitu, a nie testu porównawczego możliwości. Ta odpowiedź jest trochę specyficzna dla mojego gustu i nie zawiera żadnej liczby ani wskazania liczby równoczesnych połączeń. Mimo twoich wysiłków nie jest to zbyt przydatne. Może mógłbyś samodzielnie odpowiedzieć na pytanie: „Dlaczego nie mogę serwerować więcej niż X równoczesnych połączeń TCP w systemie Linux”
Todd

2
O ile wiem, to jest złe . somaxconn to maksymalna liczba połączeń w kolejce na otwartym gnieździe (tj. jest to maksymalna wartość parametru backlog wynosząca listen(int socket, int backlog). Nie jest związana z liczbą gniazd, które proces może mieć otwarte.
Timmmm

8

Wygląda na to, że odpowiedź brzmi co najmniej 12 milionów, jeśli masz mocny serwer, oprogramowanie serwera jest do tego zoptymalizowane, masz wystarczającą liczbę klientów. Jeśli testujesz od jednego klienta do jednego serwera, liczba numerów portów na kliencie będzie jednym z oczywistych ograniczeń zasobów (każde połączenie TCP jest definiowane przez unikalną kombinację adresu IP i numeru portu u źródła i miejsca docelowego).

(Musisz uruchomić wielu klientów, ponieważ w przeciwnym razie najpierw osiągniesz limit 64K numerów portów)

Sprowadzając do tego, jest to klasyczny przykład dowcipu, że „różnica między teorią a praktyką jest znacznie większa w praktyce niż w teorii” - w praktyce osiągnięcie wyższych liczb wydaje się być cyklem a. zaproponować określoną konfigurację / architekturę / zmiany w kodzie, b. testuj, aż osiągniesz limit, c. Skończyłem? Jeśli nie, to d. ustal, co było czynnikiem ograniczającym, np. wróć do kroku a (przepłucz i powtórz).

Oto przykład z 2 milionami połączeń TCP na potężnym pudełku (128 GB pamięci RAM i 40 rdzeni) z oprogramowaniem Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - zakończyły się potrzebujących około 50 rozsądnie ważnych serwerów tylko po to, aby zapewnić obciążenie klienta (ich początkowi mniejsi klienci osiągnęli maksymalny poziom za wcześnie, np. „maksymalizowali nasze 4-rdzeniowe / 15 gb box przy 450 tys. klientów”).

Oto kolejna referencja dla go tym razem na 10 milionów: http://goroutines.com/10m .

Wygląda na to, że jest oparty na Javie i ma 12 milionów połączeń: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/


Świetne nowe linki, z poprawnym zrozumieniem pytania. Podoba mi się ogólna rada dotycząca bariery uderzenia -> napraw barierę. Każdy ma inną konkretną sytuację, ale przynajmniej ma tutaj wskazówkę, co jest ekonomicznie / praktycznie osiągalne. W najbliższym czasie nie należy obiecać klientowi 100 milionów na serwer.
Todd

5

Zwróć uwagę, że HTTP zazwyczaj nie utrzymuje otwartych połączeń TCP dłużej niż jest to potrzebne do przesłania strony do klienta; i zazwyczaj przeczytanie strony internetowej zajmuje użytkownikowi znacznie więcej czasu niż jej pobranie ... gdy użytkownik przegląda stronę, nie dodaje żadnego obciążenia do serwera.

Zatem liczba osób, które mogą jednocześnie przeglądać Twoją witrynę internetową, jest znacznie większa niż liczba połączeń TCP, które może ona jednocześnie obsługiwać.


12
To wcale nie odpowiada na pytanie. Niezależnie od dokładności tego, co powiedziałeś, w danym momencie nadal istniałoby kilka równoczesnych połączeń TCP, jaka jest maksymalna? To jest istota pytania.
Todd

3
Jeśli masz coś wartościowego do wniesienia, Todd, zrób to.
Jeremy Friesner

8
Miałem już odpowiedź 28 marca, musiałaś ją przegapić. We współczesnym świecie aplikacji jednostronicowych z połączeniami typu long-polling i połączeniami z gniazdem internetowym HTTP nie zawsze jest krótkotrwały. Ale nawet jeśli jest krótkotrwały, nadal istnieje maksymalna liczba jednoczesnych połączeń. Próba wyjaśnienia pytania nie jest odpowiedzią IMO. Ta odpowiedź byłaby lepiej umieszczona jako komentarz do pytania, z pewnością jest przydatna, ale pytanie dotyczy „połączeń gniazd”, a nie „ludzi”. W razie potrzeby osobnym pytaniem powinno być pytanie o stosunek (użytkownicy: aktywne połączenia).
Todd

1
Funkcja Keep Alive on HTTP TCP jest obecna i żądana przez przeglądarki od ostatniego tysiąclecia - od serwera zależy, czy pozwoli to na utrzymanie połączenia i jaki będzie limit czasu bezczynności. Umożliwienie zachowania aktywności zmniejsza opóźnienie grupy żądań (np. Strony html i powiązanych z nią zasobów), ale zwiększa wykorzystanie zasobów na serwerze.
iheggie

1

w przypadku protokołu IPv4, serwer z jednym adresem IP, który nasłuchuje tylko na jednym porcie, może obsłużyć 2 ^ 32 adresy IP x 2 ^ 16 portów, czyli 2 ^ 48 unikalnych gniazd. Jeśli mówisz o serwerze jako o maszynie fizycznej i jesteś w stanie wykorzystać wszystkie 2 ^ 16 portów, to może istnieć maksymalnie 2 ^ 48 x 2 ^ 16 = 2 ^ 64 unikalnych gniazd TCP / IP dla jednego adresu IP. Należy pamiętać, że niektóre porty są zarezerwowane dla systemu operacyjnego, więc ta liczba będzie niższa. Podsumowując:

1 IP i 1 port -> 2 ^ 48 gniazd

1 IP i wszystkie porty -> 2 ^ 64 gniazda

wszystkie unikalne gniazda IPv4 we wszechświecie -> 2 ^ 96 gniazd


0

Są tutaj dwie różne dyskusje: Pierwsza dotyczy tego, ile osób może połączyć się z Twoim serwerem. Inni odpowiedzieli odpowiednio na to pytanie, więc nie będę się w to rozwodził.

Inne jest to, na ilu portach Twój serwer może nasłuchiwać? Myślę, że stąd pochodzi liczba 64K. W rzeczywistości protokół TCP używa 16-bitowego identyfikatora portu, co przekłada się na 65536 (nieco więcej niż 64 KB). Oznacza to, że możesz mieć na serwerze tyle różnych „nasłuchiwaczy” na jeden adres IP.


dla twojej korzyści dodałem dodatkową sekcję do mojej odpowiedzi, odnoszącą się do twojego błędnego przekonania. Również to pytanie dotyczy „połączeń gniazd”, a nie „ludzi”, co jest ważnym rozróżnieniem w kontekście tego pytania.
Todd

Jeśli mówimy o jednej maszynie serwerowej i jednym routerze, myślę, że ta odpowiedź jest właściwa. Ale @Todd zajmuje się farmą maszyn serwerowych, które użytkownik może łączyć się z dowolnym z nich losowo za pomocą modułu równoważenia obciążenia.
Amr

@amr to nieprawidłowe. Moja odpowiedź dotyczy jednej maszyny. „Farma internetowa?” Sekcja zawiera kontrast i porady dotyczące wychodzenia poza ramy i stwierdza, że ​​moduły równoważenia obciążenia nie są konieczne przy dobrej architekturze. Po prostu jeszcze nie przeczytałeś dokładnie mojej odpowiedzi.
Todd

0

Myślę, że liczba równoczesnych połączeń przez gniazdo, które może obsłużyć jeden serwer WWW, w dużej mierze zależy od ilości zasobów zużytych przez każde połączenie i całkowitej ilości zasobów dostępnych na serwerze, z wyjątkiem konfiguracji ograniczającej inne zasoby serwera WWW.

Aby to zilustrować, jeśli każde połączenie przez gniazdo zużywa 1 MB zasobów serwera, a serwer ma 16 GB dostępnej pamięci RAM (teoretycznie), oznaczałoby to, że byłby w stanie obsłużyć tylko (16 GB / 1 MB) jednoczesnych połączeń. Myślę, że to takie proste ... NAPRAWDĘ!

Zatem niezależnie od tego, jak serwer WWW obsługuje połączenia, każde połączenie ostatecznie zużyje trochę zasobów.

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.