INF.03 · strony i aplikacje internetowe

Usługi sieciowe i technologie webowe

dwie pary lekcyjne

Najpierw przypominamy, co działa w sieci i po czym to rozpoznać. Potem patrzymy, z czego zbudowana jest strona — i gdzie kończy się przeglądarka, a zaczyna serwer.

INF.03.1 — charakteryzowanie usług sieciowych · INF.03.2 — rozróżnianie technologii webowych (część 1)

Lekcja 1 · Usługi sieciowe · INF.03.1

Usługa = program, który nasłuchuje

W sieci nic nie dzieje się „samo”. Po jednej stronie jest klient, który pyta, po drugiej serwer — program czekający na porcie na pytanie.

Klient

przeglądarka, program pocztowy, ping. Wysyła żądanie i czeka.

Serwer

program nasłuchujący na porcie. Przyjmuje żądanie, odpowiada i wraca do nasłuchiwania.

Port

numer 0–65535. Jeden adres IP, wiele usług — port mówi, do której.

Zapamiętaj rozróżnienie. Serwer to i komputer, i program. Na jednym komputerze może działać wiele serwerów-programów: www, pocztowy, bazy danych.

Lekcja 1 · Usługi sieciowe · INF.03.1

Porty i protokoły — tabela do pamięci

TCP — połączeniowy

21 FTP · 22 SSH · 25 SMTP · 80 HTTP · 110 POP3 · 143 IMAP · 443 HTTPS · 3306 MySQL

Nawiązuje połączenie, potwierdza odbiór, wysyła ponownie to, co zginęło.

UDP — bezpołączeniowy

53 DNS · 67/68 DHCP · 123 NTP

Bez potwierdzeń. Szybciej, ale bez gwarancji — dobre tam, gdzie lepiej zgubić pakiet niż czekać.

Pytanie egzaminacyjne w typowej formie: „podaj numer portu usługi X” albo odwrotnie — „jaka usługa działa na porcie 143”. Tych kilkanaście liczb trzeba znać na pamięć.

Lekcja 1 · Usługi sieciowe · INF.03.1

DNS — zamienia nazwę na adres

Wpisujesz suzik.cloud, a karta sieciowa potrzebuje liczby. Tę zamianę robi DNS — i robi ją, zanim poleci jakikolwiek pakiet HTTP.

A / AAAA

nazwa → adres IPv4 / IPv6

CNAME

nazwa → inna nazwa (alias)

MX

gdzie dostarczać pocztę domeny

NS

który serwer odpowiada za strefę

TXT

dowolny tekst — np. potwierdzenie własności

PTR

adres → nazwa (zapytanie odwrotne)

Po czym poznać awarię DNS. ping 1.1.1.1 działa, a ping google.com nie — sieć jest, nazwy nie działają.

Lekcja 1 · Usługi sieciowe · INF.03.1

DHCP — skąd komputer bierze adres

Nikt nie wpisuje adresu ręcznie. Komputer po włączeniu pyta sieć i dostaje konfigurację na czas określony.

1. DISCOVER   klient pyta: „jest tu jakiś serwer DHCP?”
2. OFFER      serwer proponuje: adres, maska, brama, DNS
3. REQUEST    klient: „biorę tę propozycję”
4. ACK        serwer: „zatwierdzam, dzierżawa na 24 h”

Co dokładnie przychodzi: adres IP, maska podsieci, brama domyślna i adresy serwerów DNS. Dlatego zła konfiguracja DHCP potrafi „zepsuć internet”, choć kabel jest sprawny.

Adres 169.254.x.x oznacza, że DHCP nie odpowiedział i system nadał adres sam. To objaw, nie rozwiązanie.

Lekcja 1 · Usługi sieciowe · INF.03.1

HTTP i HTTPS — rozmowa przeglądarki z serwerem

https://  suzik.cloud  :443  /karty/app  ?set=07-formularze-cz2
protokół    domena      port    ścieżka      parametry zapytania

Metody

GET — pobierz · POST — wyślij dane · PUT — zastąp · DELETE — usuń

Kody odpowiedzi

2xx dobrze · 3xx przekierowanie · 4xx wina klienta (404, 403) · 5xx wina serwera

HTTPS to HTTP w szyfrowanym tunelu TLS. Treść jest nieczytelna dla podsłuchującego, a certyfikat potwierdza, że serwer jest tym, za kogo się podaje. Sam protokół HTTP się nie zmienia.

Lekcja 1 · Usługi sieciowe · INF.03.1

Poczta — trzy protokoły, trzy zadania

SMTP · 25

Wysyłanie. Od klienta do serwera i między serwerami. Tylko w jedną stronę — nigdy nie odbiera.

POP3 · 110

Odbiór z pobraniem. Ściąga wiadomości na jedno urządzenie i zwykle usuwa je z serwera.

IMAP · 143

Odbiór z synchronizacją. Poczta zostaje na serwerze, foldery widać tak samo na telefonie i na laptopie.

Klasyczna pułapka na egzaminie: „na telefonie widzę maile, na komputerze zniknęły”. To POP3 z usuwaniem. Rozwiązanie — IMAP.

Lekcja 1 · Usługi sieciowe · INF.03.1

Pliki i dostęp zdalny

Transfer plików

FTP · 21 — stary, hasło leci jawnym tekstem

FTPS — FTP z TLS

SFTP · 22 — transfer wewnątrz SSH, dziś domyślny wybór

Praca na zdalnej maszynie

SSH · 22 — zaszyfrowana konsola

Telnet · 23 — to samo bez szyfrowania, w produkcji zakazany

RDP · 3389 — zdalny pulpit Windows

Reguła, która porządkuje całą tę listę: jeśli istnieje wersja szyfrowana, to nieszyfrowanej się nie używa. FTP → SFTP, Telnet → SSH, HTTP → HTTPS.

Lekcja 1 · Usługi sieciowe · INF.03.1

Usługi, o których łatwo zapomnieć

NTP · 123

Synchronizacja czasu. Rozjechany zegar psuje certyfikaty i logowanie.

Proxy

Pośrednik w ruchu. Filtruje, buforuje, ukrywa klienta.

VPN

Szyfrowany tunel. Zdalny komputer zachowuje się jak sprzęt w sieci lokalnej.

Serwer www

Apache, nginx, IIS — przyjmuje żądania HTTP i oddaje pliki albo odpytuje interpreter.

Serwer bazy · 3306

MySQL, PostgreSQL. Nie rozmawia z przeglądarką — rozmawia z kodem serwerowym.

Hosting

Usługa gotowa: serwer www, baza, poczta i domena w jednym pakiecie.

Praktyka 1 · ~35 min

Praktyka 1: rozpoznaj usługę po objawach

Otwórz terminal i sprawdź każde polecenie na własnym komputerze. Zapisuj wynik — będzie potrzebny w karcie pracy.

ipconfig /all             # Windows: adres, maska, brama, DNS — co dał DHCP
ip a ; ip route           # Linux: to samo
nslookup suzik.cloud      # jaki adres ma domena (rekord A)
nslookup -type=mx wp.pl   # gdzie trafia poczta domeny
ping 1.1.1.1              # czy jest sieć
ping suzik.cloud          # czy działa zamiana nazw
curl -I https://suzik.cloud/   # nagłówki i kod odpowiedzi HTTP
netstat -an | find "LISTEN"    # co nasłuchuje u mnie (Windows)
ss -ltn                        # to samo na Linuksie

Zadanie do opisania: ping 1.1.1.1 odpowiada, ping suzik.cloud nie. Która usługa nie działa i jakim jednym poleceniem to potwierdzisz?

Lekcja 2 · Technologie webowe · INF.03.2

Z czego naprawdę zbudowana jest strona

Do tej pory patrzyliśmy na stronę z zewnątrz — jako na usługę na porcie 443. Teraz zaglądamy do środka.

Jedno pytanie porządkuje cały dział: gdzie wykonuje się dany kod — na moim komputerze czy na serwerze? Od odpowiedzi zależy wszystko: co widzi użytkownik, co da się podejrzeć i co da się oszukać.

Lekcja 2 · Technologie webowe · INF.03.2

Front-end i back-end

Front-end — przeglądarka

HTML, CSS, JavaScript. Kod przychodzi do użytkownika i wykonuje się u niego.

Każdy może go zobaczyć i zmienić. Dlatego nigdy nie trzymamy tu haseł ani sprawdzania uprawnień.

Back-end — serwer

PHP, Node.js, Python, Java, C#. Kod nie opuszcza serwera, na zewnątrz wychodzi tylko wynik.

Tu żyją dane, logowanie i reguły, których użytkownik nie może obejść.

Sprawdzenie poprawności danych robimy dwa razy. W przeglądarce — żeby było wygodnie i szybko. Na serwerze — żeby było bezpiecznie. Samo front-endowe sprawdzenie da się wyłączyć w dziesięć sekund.

Lekcja 2 · Technologie webowe · INF.03.2

Strona statyczna i dynamiczna

Statyczna

Serwer oddaje gotowy plik .html. Każdy dostaje to samo.

Szybka, tania, trudna do zepsucia. Zmiana treści = edycja pliku.

Dynamiczna

HTML powstaje przy każdym żądaniu — z danych w bazie i tego, kim jest użytkownik.

Logowanie, koszyk, komentarze. Wymaga interpretera i bazy.

Uwaga na mylący trop. Strona z animacjami i rozwijanym menu nadal może być w pełni statyczna — JavaScript w przeglądarce to nie to samo co strona dynamiczna. Decyduje to, czy serwer buduje odpowiedź za każdym razem.

Lekcja 2 · Technologie webowe · INF.03.2

Trzy warstwy front-endu

HTML — treść i struktura

Co to jest: nagłówek, akapit, tabela, formularz. Znaczenie, nie wygląd.

CSS — wygląd

Kolory, odstępy, układ, zachowanie na telefonie. Ten sam HTML, dowolnie wiele wyglądów.

JavaScript — zachowanie

Reakcja na kliknięcie, sprawdzanie formularza, pobieranie danych bez przeładowania strony.

Test na zrozumienie podziału: wyłącz CSS — treść zostaje, wygląd znika. Wyłącz JavaScript — strona się pokaże, ale przestanie reagować. Usuń HTML — nie ma nic.

Lekcja 2 · Technologie webowe · INF.03.2

Technologie serwerowe i bazy danych

PHP

Najczęstszy na hostingach. WordPress, Drupal.

Node.js

JavaScript na serwerze — jeden język po obu stronach.

Python

Django, Flask. Mocny tam, gdzie dane i analiza.

Java · C#

Duże systemy firmowe, Spring i ASP.NET.

SQL

MySQL, PostgreSQL — dane w tabelach i relacjach.

NoSQL

MongoDB, Redis — dane bez sztywnej struktury.

Czego nie widać z przeglądarki. Patrząc na stronę, nie poznasz pewnie, czy stoi na PHP czy na Node. Podpowiedzi dają nagłówki odpowiedzi, rozszerzenia w adresach i komunikaty błędów — ale to tylko wskazówki.

Lekcja 2 · Technologie webowe · INF.03.2

Droga jednego żądania

przeglądarka
   |  1. DNS: suzik.cloud -> adres IP
   |  2. TCP + TLS na port 443
   v  3. GET /karty/app?set=07
serwer www (nginx / Apache)
   |  4. to nie jest zwykły plik -> oddaj do interpretera
   v
kod serwerowy (PHP / Node / Python)
   |  5. SELECT ... FROM ...
   v
baza danych
   |  6. wiersze wyników
   v
kod serwerowy składa HTML
   |  7. 200 OK + treść
   v
przeglądarka rysuje stronę i pobiera CSS, JS, obrazki

Po tej ścieżce diagnozuje się awarie. Błąd 404 — serwer www nie znalazł ścieżki. 500 — wywalił się kod serwerowy. Strona jest, ale bez danych — najczęściej baza. Strona bez stylów — nie pobrał się CSS.

Lekcja 2 · Technologie webowe · INF.03.2

Gdzie składa się HTML: SSR i CSR

SSR — na serwerze

Serwer wysyła gotowy HTML. Pierwsze wyświetlenie szybkie, wyszukiwarki widzą treść.

Każde kliknięcie zwykle przeładowuje stronę.

CSR — w przeglądarce

Serwer wysyła prawie pusty HTML i JavaScript, który dopiero buduje widok z danych.

To SPA — aplikacja jednostronicowa. Płynna, ale pierwszy start wolniejszy.

Jak to rozpoznać w praktyce. Zobacz źródło strony skrótem Ctrl+U. Widzisz treść — to SSR. Widzisz kilka linijek i podpięte skrypty — CSR.

Lekcja 2 · Technologie webowe · INF.03.2

CMS, frameworki, kod własny

CMS

WordPress, Joomla. Gotowy system, treść przez panel, bez programowania. Szybko — za cenę elastyczności.

Framework

Laravel, Django, Spring, React. Gotowy szkielet i reguły, kod piszesz sam.

Kod własny

Pełna kontrola, najwięcej pracy. Sensowny, gdy wymagania są nietypowe.

Wybór nie jest kwestią gustu. Blog firmowy na własnym kodzie to strata tygodni. Sklep z nietypowymi regułami rozliczeń wciśnięty w CMS to walka z narzędziem przez cały czas życia projektu.

Praktyka 2 · ~35 min

Praktyka 2: rozbierz stronę na warstwy

Otwórz suzik.cloud/karty/ i narzędzia programisty klawiszem F12. Pracuj po kolei.

1. Elements   znajdź formularz logowania. Które znaczniki HTML go budują?
2. Network    odśwież stronę. Wypisz 3 pierwsze żądania: adres, metoda, kod.
3. Network    zaloguj się błędnym hasłem. Jakie żądanie poleciało? Jaki kod wrócił?
4. Ctrl+U     źródło strony: widać treść czy tylko skrypty? SSR czy CSR?
5. Console    wyłącz CSS i opisz, co zostało:
              document.querySelectorAll("link[rel=stylesheet]").forEach(e => e.remove())

Wniosek, który trzeba zapisać własnymi słowami. Sprawdzenie hasła odbywa się na serwerze — w zakładce Network widać żądanie wychodzące i odpowiedź. Gdyby hasło sprawdzał JavaScript w przeglądarce, dałoby się je odczytać z kodu strony.

Podsumowanie

Co trzeba wynieść z tych dwóch lekcji

Usługi sieciowe

Usługa to program na porcie. Znasz numery portów, wiesz co robi DNS i DHCP, rozróżniasz SMTP od IMAP i wybierasz wersję szyfrowaną.

Technologie webowe

Wiesz, co wykonuje się u klienta, a co na serwerze. Rozróżniasz stronę statyczną i dynamiczną, HTML/CSS/JS, SSR i CSR.

Na następnych zajęciach — część 2: API i format JSON, formularze i metody HTTP od strony serwera, sesje i ciasteczka, podstawy bezpieczeństwa aplikacji webowych.

Karta pracy jest na suzik.cloud/karty — kod lekcji podam na tablicy.