Jakie są szczegółowe kroki modelu OSI związane z połączeniem ze stroną internetową?

Jakie są szczegółowe kroki związane z połączeniem się z witryną, taką jak strona główna superuser.com za pomocą nowo podłączonego komputera (http i nic buforowanego)? Co tak naprawdę dzieje się w tle, aby zbudować ostatni bit wysyłany przez sieć Ethernet?

Rozumiem, że na przykład zapytanie DNS jest przetwarzane w celu rozpoznania nazwy FQDN na adres IP (warstwa 7) lub potrójny uścisk dłoni w celu nawiązania połączenia (warstwa 4). Ale jak to się dzieje, gdy bit jest budowany? Czy różne warstwy przechowują dane, które będą częścią końcowego bitu, podczas gdy one same wysyłają zapytania / dane przez sieć Ethernet w celu zebrania odpowiednich informacji / nawiązania połączenia itp.? Jak to dokładnie działa?

Gdy omawiany jest model OSI lub model TCP / IP, ogólnie rzecz biorąc są przedstawiane jako dane budowane sekwencyjnie i spływające po warstwach, dopóki nie zostaną wysłane jako część, ale nie byłem w stanie znaleźć bardziej szczegółowego wyjaśnienia co do szczegółów związanych z każdym aspektem, w prostym przykładzie jako połączenie ze stroną internetową.

Obecnie aplikacje używają abstrakcyjnych bibliotek wysokiego poziomu do adresowania sieci, więc wiele z nich jest wykonywanych automatycznie przez system operacyjny. Im niższy OSI, tym bardziej automatyczny i tym mniej dba o to programista. Ponieważ twoje pytanie dotyczy struktur danych i warstw, tak naprawdę bardziej martwisz się górnymi warstwami, ponieważ niższe są bardziej elektrotechniczne, oprogramowania układowego i sterowników niż cokolwiek innego. na tej warstwie są to tylko bity lub sygnały elektryczne.

Warstwa aplikacji robi znacznie więcej niż jest to widoczne w modelu OSI, więc pierwszą rzeczą, którą powinieneś zrozumieć, jest to, że warstwa aplikacji napędza wszystko. Rzeczywiste zadanie tworzenia struktur danych na warstwach 3 i 4 jest obsługiwane przez metody (funkcje zaprogramowane), które działają na tych warstwach, ale warstwa aplikacji koordynuje każdą operację i przekazuje do każdej metody parametry, których potrzebuje, więc nie, warstwy nie „zatrzymują” swoje dane jako takie, a rzeczy niekoniecznie są „przekazywane” do kolejnej warstwy (choć w niektórych przypadkach są one dosłownie). Zamiast tego pomyśl o tym jako o zestawie wywołań funkcji, które definiują zadanie, tak, że wyjście jednej funkcji jest wejściem do drugiej. Chodzi o to, że miejsce kontroli zawsze znajduje się w warstwie aplikacji.

Tak więc, jak powiedziałem w moim komentarzu, większość nowoczesnych aplikacji wykorzystuje wariant standardu Berkley Sockets API . Ta biblioteka zawiera metody działające w warstwach OSI 7, 4, 3 i przechwytuje API OS IP.

1. Aplikacja zadzwoni, Sockets.Socket(type)aby utworzyć nowy port, i zostanie zwrócony nowy numer portu. To jest funkcja layer4.

2. Aplikacja zapyta system operacyjny, jaki jest jego adres IP, a następnie zadzwoni, Sockets.Bind(newPort, localIPAddr, addrLen)aby podłączyć nowe gniazdo do interfejsu IP. To jest funkcja warstwy 3.

3. Aplikacja zadzwoni, Sockets.Connect(newPort, remoteAddrandPort, addrlen)aby zainicjować połączenie za pomocą trójstronnego uzgadniania TCP.

4. Po tym wszystkim aplikacja może korzystać z funkcji Sockets.Send()i Sockets.Recv()do odczytu i zapisu zi do gniazda, tak jakby była to para we / wy. Wewnętrznie Send () / Recv () wywołują prywatne metody zdefiniowane w bibliotece gniazd, które hermetyzują dane na każdej warstwie, wykorzystując dane wyjściowe z poprzedniej struktury jako dane wejściowe do następnej niższej, dopóki nie powie lokalnemu stosowi IP, aby wysłał paczka. W większości przypadków aplikacje nie wiedzą ani nie dbają o nic poniżej warstwy 3, a gdy dbają o warstwy 3 lub 4, to tylko podają prawidłowe wartości parametrów.

Aplikacja odpowiada również za sekwencje poleceń protokołu. na przykład, aby połączyć się z superużytkownikiem, aplikacja musi komunikować się w sekwencjach poleceń HTTP .

Aby pobrać domyślną stronę tutaj na superuser.com, przeglądarka utworzy sekwencję:

GET / \HTTP/1.1;

Aplikacja może po prostu zapisać ten ciąg do portu, a zostanie on automatycznie zamknięty w segmencie TCP, pakiecie IP i ramce 802.11n, a sprzęt zostanie przekonwertowany na sygnał elektryczny.

Aplikacja może odczytywać z sieciowego strumienia IO, aby uzyskać odpowiedź jak

200: <!DOCTYPE html> <html itemscope itemtype="http://schema.org/QAPage"> <head> <title>networking - What are the detailed OSI model....

Przeglądarka następnie usuwa wartość 200 (wartość wskazująca, że ​​polecenie HTTP działało, a następnie znaczniki) i wyświetla stronę.

Tak więc nie jestem w pełni usatysfakcjonowany tą odpowiedzią, ponieważ zajęło mi to wiele lat zarówno w sieciowaniu, jak i kodowaniu, aby uzyskać całościowy mentalny obraz tego, jak to wszystko działa w rzeczywistości (w przeciwieństwie do wysoce abstrakcyjnego OSI) i wiem, że tam są co najmniej 3 różne perspektywy, na które możesz spojrzeć na łączność sieciową. W tym przypadku przetwarzanie sygnału jest już na miejscu i brzmi, jakbyś już poznał perspektywę specjalistów sieciowych, więc mam nadzieję, że ta perspektywa pomoże ci lepiej zrozumieć, gdzie teoria spotyka się z rzeczywistością.

Edytować:

Aha, a ponieważ wspomniałeś o DNS, większość aplikacji używa metod getaddrinfo / getnameinfo Sockets do wykonania szybkiego zapytania dns, przyjmując FQDN jako dane wejściowe. Te metody wewnętrznie tworzą, wiążą (), łączą (), kapsułkują datagram UDP (uwaga, DNS zwykle wykonuje się przez UDP, chociaż większość systemów można skonfigurować do korzystania z TCP) i wysyłają go, nasłuchują odpowiedzi, analizują strukturę i zwróć ją do aplikacji za pomocą jednego połączenia. jest całkiem schludne. W rzeczywistości, teraz, gdy o tym myślę, jest to uosobienie tego, co znaczy enkapsulacja.

W pewnym sensie ignoruję twój pierwszy akapit, co było przydatne, ponieważ brzmi to tak, jakbyś próbował uściślić w drugim akapicie. Więc ten akapit jest tym, na co szczegółowo odpowiem.

Ale jak to się dzieje, gdy bit jest budowany?

Zaproponowałeś własną odpowiedź z następnym pytaniem.

Czy różne warstwy przechowują dane, które będą częścią końcowego bitu, podczas gdy one same wysyłają zapytania / dane przez sieć Ethernet w celu zebrania odpowiednich informacji / nawiązania połączenia itp.?

Tak.

Jak to dokładnie działa?

Użytkownik powiedział przeglądarce, że informacje są potrzebne ze strony internetowej. Gdy użytkownik wpisuje ten adres w pasku adresu, sieć nie jest jeszcze zaangażowana; model OSI uznałby to za OSI Model Layer 7: Layer aplikacji.

Przeglądarka internetowa określiła, że ​​niepewna komunikacja jest w porządku. (Gdyby wymagane było zabezpieczenie, HTTPS zostałby wykonany. Jednak HTTP będzie działał, aby zapewnić niezabezpieczoną komunikację.) Tak więc HTTP powinno odbywać się w komunikacji (warstwa prezentacji, warstwa 6, nadal często obsługiwana przez aplikację). HTTP nie używa EBCDEC; komunikacja będzie wykorzystywała ASCII (kolejny szczegół związany z warstwą prezentacji, OSI Model Layer 6.)

Powinna nastąpić niezawodna komunikacja. Skorzystamy z sesji, więc rozmowa będzie się odbywać przez „połączenie” HTTP, które może obejmować wiele pakietów. Ideą takiego połączenia jest Session Layer (OSI Model Layer 5)

Komunikacja transportowa pozwala na wielokrotne rozmowy (takie jak wielokrotne jednoczesne przesyłanie danych) na ten sam adres IP. Gdy przychodzą lub wychodzą dane, te rozmowy są śledzone za pomocą wielu numerów „portowych”. Przeglądarka internetowa określa, że ​​chce przeprowadzić rozmowę z portem 80 www.superuser.com TCP. Określenie numeru portu przenosi się do dziedziny warstwy transportowej (OSI MOdel Layer 4).

Aplikacja (przeglądarka internetowa) komunikuje się ze „stosem sieciowym TCP / IP”, który zazwyczaj jest wbudowany w system operacyjny (obecnie… w czasach Windows 3.1 może być konieczne zainstalowanie „Trumpet Winsock”, a stos innych firm lub użyj stosu Microsoft, który można zainstalować za pomocą MS Internet Explorer dla Win 3.1).

Stos sieci zdaje sobie sprawę, że „www.superuser.com” to nazwa sieci. Tak więc używany jest kod „resolvera”. Ta nazwa nie znajduje się w pamięci podręcznej „rozpoznawania nazw” („resolver”), a próba wyszukania jej w „pliku hosts” nie ujawnia nazwy. Tak więc zapytanie DNS zostanie wysłane.

Ach, tak, twoje pytanie odnosiło się do „http” i „DNS”, więc ta odpowiedź jest nieco bardziej skomplikowana, patrząc zarówno na komunikację DNS, jak i komunikację HTTP. Najpierw przyjrzymy się komunikacji DNS, ponieważ, no cóż, tak się stanie, zanim OSI Model Layer 3 będzie miał coś wspólnego z jakimkolwiek ruchem HTTP.

Program tłumaczący rozpoczyna proces nawiązywania komunikacji DNS. Komputer otrzyma odpowiedź jako datagram DNS (port UDP 53, warstwa transportowa, warstwa 4).

Serwer DNS jest na komputerze. Udajemy, że jest na zdalnym komputerze. Będzie to wymagało komunikacji z adresem IP innego komputera. Będzie więc użyty pakiet IP (czyli warstwa sieciowa, warstwa modelu OSI 3). Dla zabawy powiedzmy, że jest to pakiet IPv4 (bez powodu, dlaczego nie). (Właściwie zacząłem pisać jako IPv6 ... postanowiłem wrócić do IPv4 dla krótszych przykładowych adresów. Ale zamiast tego można zrobić IPv6.)

Udawajmy, że komputer to router. Na podstawie adresu IP warstwy 3 nie chcemy wybierać trasy, która wyśle ​​ruch na górę do sypialni nastolatka. Chcemy wybrać trasę prowadzącą do Internetu. Ten pakiet IPv4 może być wysyłany przez sieć bezprzewodową lub przewodową. Zdecydujemy się użyć adresu IPv4, który korzysta z sieci przewodowej.

Ponieważ serwer DNS znajduje się w innej podsieci, będziemy musieli wysłać ruch do bramy. Ponieważ nie mam bardziej szczegółowej trasy (np. Do sypialni nastolatka), użyję „domyślnej bramy”, która jest używana, gdy nie jest dostępna bardziej konkretna opcja. Wiedza o tym, w jaki sposób wysłać ruch, to „routing”, główna cecha Warstwy 3.

Powiedzmy, że do tej komunikacji zostanie wykorzystana sieć przewodowa. Pakiet IP musi dostać się do serwera DNS (8.8.8.8, warstwa 3), ale tabela routingu wskazuje, że takie połączenia są kierowane przez adres bramy pod adresem 198.51.100.1 (warstwa 3). (Nawiasem mówiąc, 198.51.100.1 nie jest czymś, czego powinieneś używać w rzeczywistej sieci, ale wolno mi go używać w tym przykładzie, ponieważ śledzę RFC 5737 sekcja 3

Możemy komunikować się z 198.51.100.1 za pomocą ramki Ethernet. Pamięć podręczna ARP (odpowiednik IPv4 NDP IPv6) nie zawiera szczegółów, więc potrzebujemy ramki ARP WHO-HAS (równoważnej wykryciu sąsiada IPv6), aby dowiedzieć się, gdzie należy wysłać ramkę Ethernet. To odkrycie sąsiada wysyła transmisję Ethernet do FF-FF-FF-FF-FF-FF (IPv6 może korzystać z multiemisji jako części NDP), aby dowiedzieć się, kto ma ten adres Ethernet. Po odebraniu odpowiedzi informacje trafiają do pamięci podręcznej (pamięć ARP ... jeśli korzystamy z IPv6, będzie to pamięć podręczna NDP).

Teraz możemy wysłać ramkę Ethernet do systemu o numerze 192.168.0.1. Tak więc „stos sieciowy TCP / IP” umieszcza datagram UDP w pakiecie IP, który przejdzie do adresu IP 8.8.8.8, i umieszcza go w ramce Ethernet, która idzie do 01-23-45-67-89-AB . Ta ramka Ethernet jest wysyłana w warstwie 2.

Stos sieciowy TCP / IP wysyła ramkę Ethernetową w warstwie 2, komunikując się ze sterownikiem karty sieciowej (który może komunikować się z Ethernetem). Jednak stos sieciowy TCP / IP zapomina o bitach w tym datagramie UDP. W końcu UDP jest zawodny. Stos sieciowy TCP / IP nie jest wykonywany z żądaniem HTTP, ponieważ „resolver” wciąż czeka na odpowiedź w oparciu o „źródłowy” adres sieciowy wychodzącego pakietu UDP. Ale stos sieciowy TCP / IP nie przechowuje kopii bitów, które zostały niesolidnie wysłane w tym datagramie UDP. (Jeśli datagram UDP zostanie zgubiony, uważam, że „resolver” prawdopodobnie zawiedzie, a następnie przeglądarka internetowa może podjąć decyzję o ponownej próbie. W każdym razie część „ponawianie” nie jest obsługiwana przez niewiarygodną część dbania o datagram UDP. )

Sterownik Ethernet zawiesza się na pakiecie wystarczająco długo, aby mieć pewność, że pakiet nie zostanie uszkodzony przez kolizje Ethernetowe w warstwie modelowej OSI 1. Po przesłaniu Ethernetu bez problemu sterownik sieciowy zapomina o nim.

Brama domyślna odbiera ramkę Ethernet. Ponieważ jest to router, przekazuje ruch, co oznacza, że ​​musi nieco przyjrzeć się pakietom IP, które nie są do niego adresowane. Uważam to za „rozwiązłe”. Router sprawdza, gdzie powinien iść ruch, i wykonuje podobny proces, aby uzyskać ruch na innym routerze. Pakiet IP zostaje zmodyfikowany poprzez zmniejszenie TTL o 1, a router używa warstwy 2, aby uzyskać ruch do następnego routera. Proces ten powtarza się przez tyle routerów, ile potrzeba, i powinien działać dobrze, dopóki poziom TTL nie spadnie do niskiego poziomu, w którym to przypadku odpowiedź ICMP „Przekroczone TTL” powróci. Dla uproszczenia reszta tego przykładu będzie udawać, że tak się nie stało.

Później, być może po wielu tysiącach milisekund, które zajmują miliony megaherców czasu procesora, sterownik sieci (na komputerze z przeglądarką internetową) zauważa komunikację Ethernet. Ta ramka Ethernet ma docelowy adres MAC (OSI Model Layer 2), który należy do tego komputera z przeglądarką internetową. Ramka ma pole protokołu, które mówi, że jest to pakiet IP; w szczególności termin „pakiet IP” pochodzi ze starego standardu i oznacza pakiet IPv4 (OSI Model Layer 3). Ponieważ adres docelowy pasuje do tego komputera, komputer nie musi sprawdzać, czy jakieś oprogramowanie działa w „trybie rozwiązanym”. Tak więc sterownik sieci wysyła go do stosu sieciowego TCP / IP. Pakiet IP zawiera ostatecznie datagram UDP (OSI Model Layer 4) z serwera DNS. Tak więc stos sieciowy TCP / IP sprawdza listę otwartych portów (które można zobaczyć, uruchamiając „netstat -na” w systemie Unix lub Microsoft Windows). Lista otwartych portów jest sprawdzana pod kątem portu „LISTENING” i okazuje się, że resolver szuka odpowiedzi. Tak więc stos sieciowy TCP / IP wysyła ten datagram UDP do resolvera.

Teraz, gdy resolver zorientował się, że www.superuser.com to 203.0.113.50 (na przykład dozwolony przez RFC 5737 sekcja 3), stos sieciowy TCP / IP może utworzyć segment TCP, który będzie zawierał pakiet IP o wartości 203.0.113.50. Pierwszy pakiet IP konwersacji tak naprawdę nie zawiera żadnej interesującej zawartości i jest tylko częścią trójstronnego uzgadniania protokołu TCP. Po odpowiedzi część obsługi TCP stosu sieciowego TCP / IP wyśle ​​segment TCP wewnątrz pakietu IP. Proces ten jest bardzo podobny do obsługi datagramu UDP, z tym wyjątkiem, że gdy stos sieci TCP / IP pobiera pakiet IP zawierający segment TCP i wysyła te pakiety do sterownika sieciowego (w celu obsługi ramki Ethernet), TCP / Stos sieci IP zapamięta całą zawartość tego pakietu TCP, dopóki pakiet nie zostanie potwierdzony w segmencie TCP odpowiedzi. Jeśli pakiet TCP zostanie zgubiony podczas transportu, ostatecznie do zdalnego końca narzeka lub upłynie czas ważności, a pakiet TCP / IP wyśle ​​kolejny segment TCP z duplikatem niezbędnej zawartości. Ta próba „ponownej próby” powoduje, że TCP nazywa się „niezawodnym”.

Tym razem zamiast czekać na datagram UDP zawierający ruch DNS wysyłany do resolvera, stos sieciowy TCP / IP czeka na odpowiedź TCP. Niektóre losowe porty, np. Port 12345, są używane jako „port źródłowy” pierwszego żądania.

Wychodzący segment TCP zawiera żądanie „GET”, które jest częścią komunikacji HTTP wysyłanej przez przeglądarkę internetową.

Teraz przejdźmy do przodu przez obsługę pakietu IP (i ramki Ethernet).

Po otrzymaniu żądania przez serwer, serwer wyśle ​​dane do przeglądarki internetowej. Może się tak zdarzyć, gdy wiele segmentów TCP. Serwer WWW zapamiętuje zawartość każdego wysyłanego segmentu TCP, dopóki segment ten nie zostanie potwierdzony przez komputer z przeglądarką internetową.

Gdy komputer z przeglądarką internetową pobiera informacje z serwera WWW, zauważa ramki Ethernet (OSI Layer 2), które zawierają pakiety IP (OSI Layer 3), które zawierają segmenty TCP (OSI Layer 4), które pochodzą z portu TCP 80 (na przeglądarka internetowa) do lokalnego portu TCP, który nasłuchuje (np. wspomniana wcześniej 12345). Stos sieci TCP / IP zda sobie sprawę, że powinien przejść do przeglądarki internetowej.

Przeglądarka internetowa przetwarza informacje z połączenia (Warstwa 5, sesja), zdaje sobie sprawę, że ruch jest niezaszyfrowany (Warstwa 6, prezentacja) i nie zmienia koloru paska adresu na czerwony (tak jak w przypadku problemu z zabezpieczeniami HTTPS) . Wybór koloru paska adresu jest kwestią „interfejsu użytkownika”, która jest uważana za część warstwy 7 7-warstwowego modelu OSI.