Czy przeglądarki internetowe używają różnych portów wychodzących dla różnych kart?


58

W przeglądarce internetowej obsługującej wiele kart, takiej jak Firefox, wykonaj różne karty, które przechodzą do różnych domen witryny, używając dedykowanego portu dla każdej domeny ?.

Czy też przeglądarka używa jednego portu do zarządzania wszystkimi kartami, a tym samym wszystkimi domenami ?.


Przeglądarki używają 2 portów do łączenia się ze stronami internetowymi, 80 dla połączeń HTTP, 443 dla połączeń https. en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Moab

7
Wiem, porty używane do łączenia się z serwerem, ale zastanawiałem się nad numerami portów używanych do łączenia z klientem (komputerem hosta).
yoyo_fun

2
Myślę, że termin „porty wychodzące” jest nieprecyzyjny. Porty są dwukierunkowe. Może mógłbyś powiedzieć. zamiast tego „porty lokalne”. Porty lokalne są używane jako porty źródłowe (wychodzące) do wysyłania żądań, a porty docelowe (przychodzące) do odbierania odpowiedzi.
Ron Maupin,

6
Porty są przypisywane przez system operacyjny, a do każdego nowego połączenia przypisywany jest nowy port lokalny, aby odróżniał się od wszystkich innych otwartych połączeń.
Ex Umbris

1
@ExUmbris: To może być rozsądna i prosta strategia, ale połączenia TCP są identyfikowane przez quad {lokalny adres IP, lokalny port, zdalny adres IP, zdalny port}. Port lokalny nie jest konieczny do unikalności, co jest dobre: ​​serwer WWW nie może w ogóle używać swojego portu lokalnego do unikatowości. Z punktu widzenia serwera zdalnego IP również nie jest unikalne, ponieważ wielu użytkowników może znajdować się za jedną bramą / proxy.
MSalters

Odpowiedzi:


55

Czy przeglądarki używają różnych portów do łączenia się z różnymi stronami internetowymi?

Tak, robią.

Oto przykład pokazujący moje obecne połączenia z Firefoksem (mam 9 otwartych kart) w systemie Windows 7:

wprowadź opis zdjęcia tutaj

Uwagi:

  • Widać, że porty lokalne są różne.

  • Zdalne porty to zwykle 80 (HTTP), 443 (HTTPS) lub 8080 (HTTP Alternate).

  • Pełny proces renderowania strony internetowej opisano poniżej. Zobacz w szczególności kroki 5, 6, 13 i 15 (pogrubione):

    • Ogólnie renderowanie pojedynczej strony internetowej wykorzystuje wiele połączeń, z których nie wszystkie będą miały ten sam zdalny adres.

    • Wynika to z faktu, że strony internetowe często zawierają zasoby hostowane gdzie indziej (pliki javascript itp.).

  • Wiele połączeń z tą samą witryną (np. Stackoverflow.com) ma również różne porty lokalne (ponieważ są to osobne połączenia na różnych kartach, które wyświetlają różne strony).


Renderowanie strony internetowej - krok po kroku

Uwaga:

  • Kroki 5, 6, 13 i 15 (pogrubione) są bezpośrednio związane z pytaniem.

Czy kiedykolwiek myślałeś o tym, co się dzieje, gdy surfujesz po Internecie? To nie jest tak proste, jak się wydaje:

  1. Wpisujesz adres URL w pasku adresu w preferowanej przeglądarce.
  2. Przeglądarka analizuje adres URL, aby znaleźć protokół, host, port i ścieżkę.
  3. Tworzy żądanie HTTP (najprawdopodobniej protokół)
  4. Aby dotrzeć do hosta, musi najpierw przetłumaczyć hosta czytelnego dla człowieka na numer IP i robi to poprzez sprawdzenie DNS na hoście
  5. Następnie należy otworzyć gniazdo z komputera użytkownika na ten numer IP, na określonym porcie (najczęściej port 80)
  6. Gdy połączenie jest otwarte, żądanie HTTP jest wysyłane do hosta
  7. Host przekazuje żądanie do oprogramowania serwera (najczęściej Apache) skonfigurowanego do nasłuchiwania na określonym porcie
  8. Serwer sprawdza żądanie (najczęściej tylko ścieżkę) i uruchamia wtyczkę serwera potrzebną do obsługi żądania (odpowiadającego używanemu językowi serwera, PHP, Java, .NET, Python?)
  9. Wtyczka uzyskuje dostęp do pełnego żądania i zaczyna przygotowywać odpowiedź HTTP.
  10. Aby zbudować odpowiedź, można uzyskać dostęp do bazy danych (najprawdopodobniej). Wyszukiwanie w bazie danych odbywa się na podstawie parametrów ścieżki (lub danych) żądania
  11. Dane z bazy danych wraz z innymi informacjami, które wtyczka postanawia dodać, są łączone w długi ciąg tekstu (prawdopodobnie HTML).
  12. Wtyczka łączy te dane z niektórymi metadanymi (w postaci nagłówków HTTP) i wysyła odpowiedź HTTP z powrotem do przeglądarki.
  13. Przeglądarka odbiera odpowiedź i analizuje HTML (który z 95% prawdopodobieństwem jest uszkodzony) w odpowiedzi
  14. Drzewo DOM jest zbudowane z uszkodzonego HTML
  15. Do serwera wysyłane są nowe żądania dla każdego nowego zasobu znalezionego w źródle HTML (zwykle obrazy, arkusze stylów i pliki JavaScript). Wróć do kroku 3 i powtórz dla każdego zasobu.
  16. Arkusze stylów są analizowane, a informacje o renderowaniu w każdym z nich są dołączane do pasującego węzła w drzewie DOM
  17. JavaScript jest analizowany i wykonywany, a węzły DOM są przenoszone, a informacje o stylu są odpowiednio aktualizowane
  18. Przeglądarka renderuje stronę na ekranie zgodnie z drzewem DOM i informacjami o stylu dla każdego węzła
  19. Zobaczysz stronę na ekranie
  20. Denerwujesz się, że cały proces był zbyt wolny.

Źródło Renderowanie strony internetowej - krok po kroku


63

Każde połączenie ze stroną internetową korzysta z innego gniazda z domyślnym docelowym portem TCP 80 dla zwykłego HTTP i 443 dla HTTPS. Aby gniazdo było unikalne, kombinacja źródłowego adresu IP, źródłowego portu TCP, docelowego adresu IP i docelowego portu TCP musi być inna.

Jeśli masz wiele połączeń z tą samą witryną (zakładając, że witryna używa tylko 1 adresu IP) z tego samego komputera, należy użyć innego źródłowego portu TCP. W ten sposób każde połączenie jest unikalne.

Należy jednak zauważyć, że od HTTP 1.1 wszystkie połączenia są trwałe przez określony czas (chyba że zadeklarowano inaczej). Oznacza to, że to samo połączenie może zostać ponownie wykorzystane przez przeglądarkę, jeśli zażądanych jest wiele zasobów z tej samej strony (np. Pliki css / js). Dotyczy to również sytuacji, gdy masz wiele wystąpień tej samej witryny w przeglądarce.

Jeśli korzystasz z systemu Windows, netstat -no -p TCPpolecenie wyświetli wszystkie aktywne gniazda TCP i odpowiadające im identyfikatory procesów, w tym również przeglądarki:

wprowadź opis zdjęcia tutaj

Jeśli korzystasz z systemu Unix / Linux (w tym przypadku Debian), możesz użyć polecenia netstat -ntplub ss -t:

wprowadź opis zdjęcia tutaj


4
Zauważ, że netstat pokaże także połączenia inne niż przeglądarka, na przykład połączenia e-mail dla klienta e-mail, połączenia wiadomości dla czytnika wiadomości. Połączenia te będą realizowane na różnych zdalnych portach.
DavidPostill

Chyba że czegoś mi brakuje, wygląda na to, że zakładasz, że pytający korzysta z systemu Windows, chociaż nie wspomniał o systemie operacyjnym. Dobrze jest też wymienić system operacyjny, do którego się odwołujesz za każdym razem, gdy udostępniasz polecenia konsoli.
user45623,

9
@ user45623: Chociaż zrzut ekranu jest zrzutem ekranu systemu Windows, netstat -npowinien działać w większości systemów operacyjnych, w tym Linux i Mac OS.
Heinzi

1
W systemie Windows (być może także w innych systemach operacyjnych) możesz netstat -n -osprawdzić, który proces utworzył połączenie. Możesz też uruchomić tcpview SysInternal, aby zobaczyć listę w GUI, z nazwami procesów i ikonami.
Jonathan

Teraz pytanie brzmi: czy przeglądarki internetowe ponownie wykorzystują połączenia z różnych kart, jeśli prowadzą do tego samego serwera?
John Dvorak

11

Jeśli chodzi o zakładki do różnych stron internetowych, w TCP nie ma nic, co wymagałoby innego portu lokalnego, o ile krotka {lokalny adres IP, lokalny port, docelowy adres IP, port docelowy} jest unikalny. W przypadku zakładek do tej samej strony sytuacja jest znacznie bardziej złożona.

Przeglądarka, podobnie jak każde inne oprogramowanie klienckie, używa innego portu lokalnego dla każdego połączenia wychodzącego z tym samym celem. Zasadniczo utworzy wiele połączeń z dowolną witryną, aby pobrać osadzone zasoby, takie jak obrazy, CSS, JavaScript itp. Będzie także łączyć te połączenia w celu ewentualnego ponownego wykorzystania.

Nie można powiedzieć, czy różne karty w tej samej witrynie będą używać odrębnych połączeń, ponieważ (a) i tak zwykle nie ma jednego połączenia na kartę, oraz (b) w zależności od czasu i uwierzytelnienia połączenia mogą być ponownie użyte między kartami; a ponieważ nie można zidentyfikować połączeń, nie można również zidentyfikować portów lokalnych.


Dzięki. Co oznacza „łączenie” połączenia?
yoyo_fun

Zamiast go zamykać, zwróć go do puli i zamykaj tylko wtedy, gdy pozostaje bezczynny przez pewien czas; i najpierw szukam w puli przed utworzeniem nowego połączenia z tym celem. W ten sposób wdrażany jest protokół HTTP.
user207421,

Więc pula to struktura danych w pamięci, która przechowuje otwarte i jeszcze nie zamknięte połączenia?
yoyo_fun

Zgadza się, zwykle mapa kluczowana docelowym adresem IP: port.
user207421,

2
@EJP: Należy pamiętać, że w przypadku HTTPS kluczowanie mapy według docelowego adresu IP i portu nie jest bezpieczne; musisz także rozróżnić połączenia z różnymi nazwami hostów, nawet jeśli rozpoznają one ten sam adres IP i port. Prawdopodobnie przeglądarka powinna również utrzymywać osobne połączenia dla różnych kart, jeśli co najmniej jedna karta jest w trybie incognito.
Henning Makholm

6

Tak. Nie, może. To zależy.

Po pierwsze, przeglądarka może wykorzystywać dowolną z następujących strategii połączeń:

  1. Pojedyncze połączenie (mało prawdopodobne dla żadnej przeglądarki nowszej niż 1995)
  2. Jedno połączenie na kartę (w zasadzie takie samo jak nr 1, tylko nieznacznie lepsze)
  3. Jedno połączenie na zasób (naiwne, ale nie działa tak źle)
  4. Pula połączeń z utrzymywanymi przy życiu połączeniami do ponownego użycia
  5. Coś innego (czytaj jako: dziwne rzeczy)

Nie masz możliwości poznania strategii, z której skorzysta przeglądarka, chociaż rozsądnym założeniem jest użycie puli połączeń (i ponowne użycie połączeń).

Po drugie, w jaki sposób działa TCP, masz port źródłowy i port docelowy dla każdego połączenia. Para źródłowego i docelowego adresu / portu określa połączenie.
Zawsze [1] używasz dobrze znanego portu (takiego jak 80 lub 443), aby połączyć się z serwerem (do którego nasłuchuje na jego reklamowanym adresie), ale drugi port jest wybierany losowo. Dlatego w zależności od tego, z której strony patrzysz na połączenie, ma ono jeden lub wiele możliwych portów.

Zatem ta sama karta może (i zwykle będzie) korzystać z kilku różnych portów na swoim końcu, ale w zasadzie różne karty mogą (jeśli połączenia są połączone w pulę i różne zasoby na różnych kartach są ładowane z tego samego serwera) korzystać z tego samego portu.

Ponieważ pytanie wyraźnie wspomina wychodzące , w „normalnym” przypadku numery portów byłyby takie same, niezależnie od tego, w której zakładce się znajdują, lub jednego z dwóch możliwych portów (80 i 443). Chociaż oczywiście można jawnie poprosić o inny port (np. 8080) w adresie URL. To trochę rzadkie.


[1] Cóż, nie zawsze ... ale nie komplikujmy tego zbytnio.


Jeszcze jeden czynnik ... port po stronie klienta jest zazwyczaj wybierany przez system operacyjny, a nie przeglądarkę; a port po stronie klienta widziany przez serwer może być inny niż w przeglądarce, jeśli połączenie przechodzi przez urządzenie NAT. Większość systemów operacyjnych przydziela liniowo lub losowo w obrębie (konfigurowalnego) efemerycznego zakresu portów, ale przeglądarka może żądać tego samego portu źródłowego przez wiele połączeń z różnymi serwerami. (A OP pyta o porty klienta, a nie porty serwera.)
David

@ David: Trudno powiedzieć, która z nich jest słuszna (lub co odpowiedzieć), ponieważ Q jest niejednoznacznym smakołykiem, stąd moja dość długa wycieczka obejmująca całe pokrycie. OP pyta o port wychodzący na kliencie. „Klient” sugeruje, że mówimy o porcie źródłowym (w kategoriach TCP), który jest tym, który jest swobodnie lub losowo wybierany (przez implementację), ale „wychodzący” sugeruje, że to naprawdę port docelowy , o którym mówimy. Który jest znacznie lepiej opisany jako „port na serwerze”. Twój komentarz do NAT jest poprawny, jak widać z serwera, ale nie wpływa na klienta.
Damon
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.