Dlaczego nie ma sensu przeznaczać więcej niż jednego portu TCP / IP na HTTP? Wprawdzie naiwne, ale czy intuicyjne jest myślenie, że wydajność serwera można w jakiś sposób zwiększyć?
Dlaczego nie ma sensu przeznaczać więcej niż jednego portu TCP / IP na HTTP? Wprawdzie naiwne, ale czy intuicyjne jest myślenie, że wydajność serwera można w jakiś sposób zwiększyć?
Odpowiedzi:
Port 80 jest znanym portem, co oznacza, że jest dobrze znany jako lokalizacja, w której zwykle znajdują się serwery HTTP. Można go znaleźć w dokumentacji RFC HTTP / 1.1 .
Ustawienie domyślne jest przydatne właśnie dlatego, że nie musisz wpisywać go w przeglądarce za pomocą identyfikatora URI. Jeśli uruchamiasz serwer HTTP (lub w rzeczywistości dowolną usługę) na niestandardowym porcie, zmuszasz klienta do zapamiętania wybranego 16-bitowego numeru i wpisania go.
Oprócz tej nieprzyjazności nie ma żadnej korzyści w zakresie wydajności: port jest tylko jedną częścią (dst ip:port, src ip:port)
4-krotek, która jednoznacznie identyfikuje połączenie TCP. Jeśli dwa połączenia współużytkują a dst ip:port
, nie oznacza to, że współużytkują niektóre zasoby systemowe - mogą znajdować się w różnych wątkach lub różnych procesach.
Teraz, jeśli masz logicznie różne usługi, które zarówno zdarzyć w użyciu HTTP, nie ma problemu z uruchomieniem ich na różnych portach. To tylko sprawia, że URI jest trochę brzydszy.
Serwer nie marnuje zasobów, obsługując połączenia w co najmniej jednym porcie. Zasoby serwera są przydzielane do obsługi połączeń, a numer portu jest tylko sposobem na połączenie konkretnego programu z określonym połączeniem.
Na przykład: serwer HTTP wie, że będzie nasłuchiwał połączeń przychodzących na porcie 80. A serwer wie, że za każdym razem, gdy odbierze jakieś żądanie na porcie 80, przetworzy je na serwer http. Następnie serwer HTTP zajmie się komunikacją, a następnie zużyje zasoby.
Wydaje się, że myślisz o portach jako o czymś realnym; jest to tylko 16-bitowa liczba bez znaku (0-65535), która jest etykietą w nagłówku pakietu IP. Pomaga to w multipleksowaniu na poziomie aplikacji. Gdy przychodzący pakiet dociera do karty sieciowej, system operacyjny otrzymuje powiadomienie. Sprawdza, do którego portu został skierowany pakiet przychodzący, a następnie przekazuje pakiet tylko do właściwej aplikacji. Jeśli korzystasz z serwera WWW (nginx), aby nasłuchiwać na porcie 80, tylko nginx pobiera pakiety wysyłane do portu 80.
Gdy klient (IP: 100.200.100.200) wysyła żądanie HTTP do serwera (55.55.55.55), przesyła to żądanie do docelowego portu 80 na serwerze (55.55.55.55:80), ale port źródłowy jest losowo wybierany przez System operacyjny dla przeglądarki internetowej (coś w rodzaju 45490). Odpowiedź HTTP z serwera sieciowego pochodzi wtedy (55.55.55.55:80), ale jest wysyłana do miejsca docelowego (twojego adresu IP) (100.200.100.200:45490). System operacyjny komputera wie, że pakiety przychodzące na porcie 45490 (z 55.55.55.55:80) należy przekazać przeglądarce internetowej, która wysłała żądanie. Ponieważ każde unikalne połączenie z witryną od klienta otrzymuje unikalny losowy port, możesz mieć wiele przeglądarek internetowych łączących się z tą samą witryną, a gdy strona zostanie przeładowana w jednej przeglądarce, nie ma to wpływu na inne okna.
Każdy pakiet IP ma w nagłówku zarówno źródłowy, jak i docelowy adres IP oraz port. System operacyjny i aplikacja (przeglądarka internetowa lub serwer WWW) mogą użyć obu tych elementów, aby dowiedzieć się, jakie działanie należy wykonać w celu przetworzenia pakietu.
Porty 80 i 443 są „domyślnymi” portami dla HTTP / HTTPS
Oznacza to, że nie musisz określać portu ( http://www.example.com:80 , https://www.example.com:443 ) podczas korzystania z przeglądarki internetowej.
Jeśli chcesz, aby serwer WWW nasłuchiwał na innych portach, użytkownicy muszą ręcznie dodać port do adresu URL lub musi być zakodowany w dowolnym łączu do tego konkretnego portu.
Ponadto większość serwerów proxy i zapór ogniowych nie zezwala na połączenia z tymi portami, chyba że jest to specjalnie skonfigurowane (bez konfiguracji wychodzące serwery proxy nie będą nasłuchiwać portów innych niż domyślne, a zatem nie przekierują żądania do serwerów sieciowych, a zapory ogniowe po prostu blokowanie prób połączeń innych niż TCP80 / 443)
Wszystko to ogranicza to, co można zrobić na poziomie TCP / IP
Jednym ze sposobów na zwiększenie wydajności byłoby posiadanie urządzenia / usługi równoważenia obciążenia nasłuchującego TCP80 / 443, które przekierowałyby następnie żądanie do serwerów na różnych portach i / lub ip (równoważenie lokalne) lub nawet w innych zdalnych witrynach (równoważenie globalne). Ale to zupełnie inny temat
Dodanie dodatkowych portów nie zwiększa przepustowości ani nic takiego, port jest bardziej etykietą niż rura , może „rosnąć” tak szeroko, jak potrzebujesz, bez zwalniania z powodu zapełnienia rury.
Jeśli serwer otrzyma zbyt wiele żądań, serwer oczywiście spowolni, ale nie jest to problem, który można rozwiązać, dodając inny numer portu.
Jeśli używałeś losowych portów, użytkownik musiałby dodawać prawidłowe numery portów za każdym razem, gdy odwiedzał twoją stronę. tj. www.example.com:80; www.example.com:81; www.example.com:82 itd
Korzystanie z większej liczby portów nie zwiększy wydajności. Porty źródłowe dla każdego połączenia są efemerycznymi, a więc i tak różnymi
Każde połączenie TCP / IP ma sourceIP: sourcePort i destinationIP: destinationPort.
Podczas inicjowania połączenia zawsze używałbyś 80 jako portu docelowego (co ma sens, ponieważ serwer musi nasłuchiwać tylko na porcie 80 dla HTTP, a nie na kilku portach). Sztuka polega na tym, że sourcePort jest dynamiczny dla każdego połączenia.
Przykład:
użytkownik1: 1.1.1.1:29999 do 2.2.2.2:80
użytkownik2: 1.1.1.2:45333 do 2.2.2.2:80
Nie pomyl innego portu z innym połączeniem fizycznym lub wyższą przepustowością sieci lub wydajnością przetwarzania serwera. Serwer otrzymuje pakiety TCP lub UDP, które mają numer portu jako część adresu. Nadal przechodzą przez te same przewody, przechodzą przez ten sam sprzęt i sterownik interfejsu sieciowego i tak dalej.
Jeśli miałbyś wysłać dwa pakiety do serwera, pod względem zasobów serwer zamierza przetworzyć te dwa pakiety, nie ma znaczenia, czy jeden z dwóch ma inne numery portów lub te same numery portów powiązane z nimi, wewnętrzna obsługa będzie być bliskie identyczności.
Dlatego nie jest to metoda na zwiększenie wydajności w jakikolwiek sposób.
Jedynym możliwym wyjątkiem jest sytuacja, gdybyś skojarzył dwa różne demony (lub dwie ich kopie) działające w tym samym czasie z dwoma różnymi numerami portów i gdyby każdy z tych demonów skalował się wyjątkowo źle przy obciążeniu. Co zwykle nie jest prawdą.
Jak wspomniano Remi, porty 80 i 443 są „domyślnymi” portami dla HTTP / HTTPS.
Większość sieci i zapór nie blokuje ruchu przechodzącego przez te porty. Dlatego korzystanie z tych portów jest łatwiejsze, ponieważ przez większość czasu nie musisz się martwić zaporami blokującymi twoją usługę, w przeciwnym razie możesz przejść przez rekonfigurację reguł zapory i uzyskać dla nich zgody od zgodności / bezpieczeństwa.
Jak wszyscy inni tutaj powiedzieli, zasadniczo nie ma sensu hostować serwera WWW na jakimkolwiek porcie innym niż port 80 ... chyba że hostujesz go z domu. Wielu dostawców usług internetowych ogranicza przepustowość wychodzących portów TCP / UDP 80 i 443 ( IANA definiuje odpowiednio jako HTTP i HTTPS ), w tym przypadku użycie tych portów obniży szybkość ładowania witryny itp. Jednak IANA przypisała 3 porty HTTP-ALT dla zarówno TCP, jak i UDP. Są to: 591, 8008 i 8080. Korzystanie z tych portów jest również dopuszczalne, ale życie administratorów serwerów będzie piekłem.
Źródło numerów portów: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml