Jak zatrzymać milion jednoczesnych połączeń TCP?

Question

Mam zaprojektować serwer, który musi obsługiwać miliony klientów, które są jednocześnie połączone z serwerem za pośrednictwem protokołu TCP.

Ruch danych między serwerem a klientami będzie niewielki, dlatego problemy z przepustowością mogą zostać zignorowane.

Jednym z ważnych wymagań jest to, że gdy serwer musi wysłać dane do dowolnego klienta, powinien użyć istniejącego połączenia TCP zamiast otwierania nowego połączenia w kierunku klienta (ponieważ klient może znajdować się za zaporą).

Czy ktoś wie, jak to zrobić, a jaki sprzęt/oprogramowanie jest potrzebne (przy najniższym koszcie)?

Answer 1

Jakie systemy operacyjne rozważasz w tym celu?

Jeśli używasz systemu operacyjnego Windows i używasz czegoś później niż Vista, nie powinieneś mieć problemu z wieloma tysiącami połączeń na jednym komputerze. Uruchomiłem testy (tutaj: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html) z niską specyfikacją systemu Windows Server 2003 i łatwo osiągnąłem ponad 70 000 aktywnych połączeń TCP. Niektóre limity zasobów, które mają wpływ na liczbę możliwych połączeń, zostały znacznie podniesione w systemie Vista (patrz tutaj: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html), więc możesz prawdopodobnie osiągnąć swój cel za pomocą małej grupy komputerów. Nie wiem, czego potrzebujesz przed tymi, którzy kierują połączeniami.

System Windows udostępnia obiekt o nazwie Porty ukończenia operacji wejścia/wyjścia (zobacz: http://msdn.microsoft.com/en-us/magazine/cc302334.aspx), które umożliwiają obsługę wielu tysięcy równoczesnych połączeń przy użyciu bardzo niewielu wątków (wczytałem wczoraj testy z 5000 połączeń przesyłających łącze do serwera za pomocą 2 wątki do przetwarzania I/O ...). Zatem podstawowa architektura jest bardzo skalowalna.

Jeśli chcesz uruchomić kilka testów, to mam na swoim blogu kilka darmowych narzędzi, które pozwalają ci na wyrzucenie prostego serwera echa za pomocą wielu tysięcy połączeń (1) i (2) i trochę darmowego kodu, którego możesz użyć na początek (3)

Druga część twojego pytania, z twoich komentarzy, jest trudniejsza. Jeśli adres IP klienta ciągle się zmienia i nie ma nic między Tobą a nim, który zapewnia NAT w celu uzyskania spójnego adresu IP, wtedy ich połączenia bez wątpienia zostaną przerwane i trzeba będzie je przywrócić. Jeśli klienci wykryją to połączenie, oderwij się, gdy ich adres IP ulegnie zmianie, wtedy mogą ponownie połączyć się z serwerem, jeśli tego nie zrobi, sugerowałbym, aby klienci musieli odpytywać serwer co jakiś czas, aby wykryć utratę połączenia i na nowo połączyć. Nie ma tu nic, co mógłby zrobić serwer, ponieważ nie jest w stanie przewidzieć nowego adresu IP i odkryje, że stare połączenie nie powiodło się podczas próby wysłania danych.

I pamiętaj, że twoje problemy dopiero zaczynają, gdy pojawi się system skalowania do tego poziomu ...

Answer 2

Ten problem jest związany z tak zwanym problemem o nazwie C10K. Strona C10K zawiera listę wielu dobrych zasobów do rozwiązania problemów, które napotkasz, próbując zezwolić tysiącom klientów na połączenie się z tym samym serwerem.

Answer 3

EDIT: Jak wspomniano w komentarzach poniżej, moje oryginalne twierdzenie, że istnieje granica 64K na podstawie liczby portów jest błędne, jednak nie jest limit 32K od liczby gniazdo obsługuje, więc moja sugerowany projekt jest ważny.

Przy typowym projekcie serwera TCP/IP masz ograniczoną liczbę jednoczesnych otwartych połączeń, jakie możesz mieć. Serwer ma jeden port nasłuchujący, a gdy klient się z nim łączy, serwer wykonuje połączenie akceptujące i tworzy nowe gniazdo na losowym porcie dla pozostałej części połączenia.

Aby obsłużyć więcej niż 64K jednoczesnych połączeń, myślę, że musisz użyć UDP zamiast tego. Potrzebujesz tylko jednego portu, aby serwer mógł nasłuchiwać, i musisz zarządzać połączeniami za pomocą 32-bitowego identyfikatora klienta w danych pakietowych, zamiast mieć osobny port dla każdego klienta. 32-bitowy identyfikator klienta może być adresem IP klienta, a klient może nasłuchiwać na znanym porcie UDP dla wiadomości przychodzących z serwera. Ten port będzie jedynym, który musi być otwarty na zaporze.

W ten sposób jedynym ograniczeniem jest szybkość obsługi wiadomości UDP i odpowiedzi na nie. Mając miliony klientów, nawet niewielki ruch może spowodować duże skoki, a jeśli nie odczytasz pakietów wystarczająco szybko, twoja kolejka wejściowa wypełni się i zaczniesz upuszczać pakiety. Strona Greg C10K wskazuje na strategie na to.

Answer 4

Po pewnym czasie natknąłem się na APE Project . Wydaje się, że marzenie się spełniło. Mogą obsługiwać do 100 000 równoczesnych klientów w jednym węźle. Rozłóż je na 10 lub 20 węzłach i możesz obsłużyć miliony. Idealny do zastosowań RESTful. Może chcieć zagłębić się we wspólną przestrzeń nazw. Wadą jest to, że jest to samodzielny serwer, jako uzupełnienie serwera WWW. Ten serwer to oczywiście Open Source, więc wszelkie koszty związane są ze sprzętem/usługodawcą internetowym.

Answer 5

Nie można używać UDP. Jeśli klient wyśle ​​żądanie i nie odpowiesz natychmiast, router zapomni o odwrotnej trasie w 30 sekund lub mniej, więc twój serwer nigdy nie będzie w stanie odpowiedzieć klientowi.

TCP jest jedyną opcją, która również da ci ból głowy. Większość routerów zapomni o trasie i/lub zrzuci połączenie po kilku minutach, więc twój kod klienta/serwera będzie musiał wysyłać "keep alives" dość często.

Polecam skonfigurować "sniffer", aby zobaczyć, jak firmy telekomunikacyjne pozostają w kontakcie ze smartfonem pod kątem technologii "push". Skopiuj wszystko, co robią, ponieważ te rzeczy działa!

Answer 6

Jak wspomniał Greg, problem, który opisujesz, to C10K (lub raczej "C1M" w twoim przypadku) Niedawno stworzyłem prosty serwer TCP echo na platformie linux, który bardzo dobrze skaluje się z liczbą sesji (tylko testowane do 200 000) za pomocą kolejki epoll. Na BSD masz coś podobnego o nazwie kqueue. Jeśli chcesz, możesz sprawdzić numer code. Mam nadzieję, że to pomoże i powodzenia!