Teoria IT. Sieci i protokoły sieciowe

Praw­ie każ­da aplikac­ja jest obec­nie aplikacją w jak­iś sposób korzys­ta­jącą z sieci — najczęś­ciej za pośred­nictwem pro­tokołu HTTP. Cza­sem jed­nak koniecz­na jest wiedza ‘jak to dzi­ała pod spo­dem’ i o tym będzie kole­j­na część Niezbęd­ni­ka Juniora.
Ten wpis będzie raczej teo­re­ty­czny — obec­nie bard­zo rzad­ko konieczne jest pro­gramowanie bezpośred­nio z uży­ciem połączeń sieciowych. Mimo tego zagad­nienia z tym związane pojaw­ia­ją się pod­czas rekru­tacji, wiedza na ten tem­at pomoże Ci też zrozu­mieć dlaczego pewne ele­men­ty dzi­ała­ją tak, a nie inaczej. Ale prze­jdźmy do rzeczy.

Model ISO / OSI

Mod­el ten jest stan­dar­d­em, jeśli chodzi o opis sieci. O ile nie apliku­jesz na stanowisko inżyniera sieci, nie musisz znać go na pamięć — warto jed­nak pamię­tać nazwę, aby móc odnieść się do niego w razie potrzeby.

Mod­el ten opisu­je tzw. stos sieciowy — czyli log­iczny podzi­ał kom­po­nen­tów związanych z komu­nikacją sieciową na odd­zielne warst­wy. W prak­tyce częs­to jed­no urządze­nie / opro­gramowanie obe­j­mu­je kil­ka warstw, jed­nak nadal rozróżnie­nie to jest istotne szczegól­nie przy opisy­wa­niu i szuka­niu infor­ma­cji. Co ważne — mod­el ten obow­iązu­je dla wszys­t­kich typów sieci, nie tylko Eth­er­net czy WiFi — dzię­ki abstrak­cyjne­mu pode­jś­ciu, pozwala na stosowanie wspól­nych mech­a­nizmów dla różnych zas­tosowań, typów sieci czy nośnika.

Wyróż­ni­amy 7 warstw (w tabelce przed­staw­iono także pro­tokoły na poszczegól­nych warst­wach oraz odniesie­nie do Inter­ne­tu — który dzi­ała z uży­ciem tego mod­elu, ale rozróż­nia nieco inne warstwy):

Dzię­ki takiej orga­ni­za­cji warst­wa ‘wyżej’ nie musi się martwić o to, co jest ‘poniżej’, pomi­ja­jąc warst­wę z którą bezpośred­nio sąsiadu­je. Dlat­ego np. Two­ja aplikac­ja nie musi rozróż­ni­ać pomiędzy połącze­niem za pośred­nictwem kabla oraz wifi czy wręcz rodza­jem kabla użytego do połączenia — intere­su­ją ją tylko pro­tokoły warst­wy 5 i wyższych. Poszczególne warst­wy mają określone funkcje:

• warst­wa 1 (fizy­cz­na) — określa jak reprezen­towana jest infor­ma­c­ja (np. bina­rnie, gdzie syg­nał elek­tryczny ‘wyso­ki’ oznacza 1), przykła­dem może być Eth­er­net lub RS-232 (połacze­nie szeregowe)
• warst­wa 2 (łącza danych) — określa, jak dwa połąc­zone za pomocą warst­wy pier­wszej urządzenia mogą ze sobą roz­maw­iać (np. jak zapewnić komu­nikację w obu kierunk­ach, jak rozwiązy­wać kon­flik­ty itp), przykła­dem może być pro­tokół PPP (uży­wany np. w modemach ADSL — pop­u­larnej niegdyś neostradzie) czy IEEE 802.2 (uży­wana np. przy WiFi) lub MAC (uży­wany w sieci­ach Ethernet)
• warst­wa 3 (sieci) — określa sposób, w jaki mogą być trans­mi­towane dane o różnej dłu­goś­ci oraz to, jak komu­nikac­ja może się odby­wać pomiędzy więk­szą ilośćią węzłów w tej samej sieci w uporząd­kowany sposób, przykłada­mi są pro­tokoły IPv4 oraz IPv6
• warst­wa 4 (trans­portowa) — defini­u­je w jaki sposób zapewnić nieza­wod­ność trans­misji seg­men­tów (paki­etów) danych lub inne charak­terysty­ki związane z trans­misją, przykła­dem są pro­tokoły TCP oraz UDP
• warst­wy 5–7 cza­sem bywa­ją przed­staw­iane razem, jako że niek­tóre pro­tokoły czy aplikac­je zacier­a­ją granice pomiędzy nimi — for­mal­nie są one jed­nak odd­ziel­ny­mi warstwami 
  • warst­wa 5 (sesji) — określa co oznacza ‘połącze­nie’ czy ‘poje­dyncza ses­ja’, jak takie połącze­nie prze­b­ie­ga oraz jak należy zainicjować / zakończyć sesję, przykłada­mi są pro­tokoły TLS/SSL, HTTP, SMTP, SSH
  • warst­wa 6 (prezen­tacji) — określa ‘znacze­nie’ danych, czyli sposób inter­pre­tacji danych, przykłada­mi są np. JSON, XML, CSS czy HTML (choć nie zwyk­liśmy myśleć o nich jak o pro­tokołach, w isto­cie stan­dardy te określa­ją pewien kon­trakt pomiędzy ‘twór­cą’ i ‘czy­ta­ją­cym’ — są więc protokołem)
  • warst­wa 7 (aplikacji) — są to wysokopoziomowe API oraz inter­fe­jsy pozwala­jące na korzys­tanie z niższych warstw, do przykłądów zal­iczymy np. JSP czy ogól­nie J2EE

Cza­sem możesz się spotkać z określe­ni­a­mi typu ‘load­bal­ancer warst­wy 4’ (ang. ‘lay­er 4 load­bal­anc­ing’) — oznacza to tyle, że dla tego load­bal­ancera istotne (i dostęp­ne) są tylko infor­ma­c­je do warst­wy 4 (trans­portowej) — a więc np. adres IP, port itp, ale nie ‘rozu­mie’ on (i nie potrafi na tej pod­staw­ie pode­j­mować decyzji) zapy­tań HTTP. Tego typu urządzenia są częs­to real­i­zowane jako urządzenia elek­tron­iczne, pod­czas gdy w warst­wie 7 częs­to mają one for­mę opro­gramowa­nia (w prak­tyce sto­su­je się je cza­sem łącznie lub tylko jeden z nich, w zależnoś­ci od potrzeb).

To tyle z wstępu, którego nie musisz pamię­tać :) Prze­jdźmy do najważniejszych protokołów.

Ważne protokoły sieciowe

Ta wiedza jest już bardziej potrzeb­na — o ile nie ma potrze­by nauczenia się wszys­tkiego ‘na blachę’, warto znać różnice pomiędzy TCP i UDP, a także do czego służy FTP, SMTP czy TLS (w paru słowach, bez szczegółów).

IP

Pro­tokół IP to jeden z pod­sta­wowych pro­tokołów inter­ne­towych, który w skró­cie określa w jaki sposób jeden kom­put­er może roz­maw­iać bezpośred­nio z drugim — defini­u­je on stan­dard adresowa­nia kom­put­erów (i innych urządzeń podłąc­zonych do sieci), dzię­ki czemu naw­iązu­jąc komu­nikację może­my jed­noz­nacznie określić, z jakim urządze­niem chce­my się komunikować.

Obec­nie najczęś­ciej uży­waną wer­sją pro­tokołu jest IPv4, w którym adresy IP składa­ją się z czterech liczb z zakre­su 0–255, połąc­zonych krop­ka­mi, np. 127.0.0.1 (jest to jeden ze ‘spec­jal­nych’ adresów — w tym wypad­ku oznacza­ją­cy zawsze kom­put­er lokalny). Nowsza wer­s­ja pro­tokołu — IPv6 — znaczą­co pow­ięk­sza pulę dostęp­nych adresów (co jest coraz więk­szym prob­le­mem w przy­pad­ku IPv4), są one jed­nak mniej czytelne dla ludzi (przykład­owy adres wyglą­da następu­ją­co: 2001:0db8:0000:0000:0000:0000:1428:57ab).

Pro­tokół IP jest bazowym ‘klock­iem’ budul­cowym — defini­u­je on, że dane pomiędzy dwoma sys­tema­mi są przesyłane w postaci tzw. paki­etów. Jeden paki­et zaw­iera dane oraz nagłówek, gdzie w nagłówku zapisane są infor­ma­c­je takie jak źródło paki­etu, cel (adres docelowy), suma kon­trol­na (pozwala na szy­bką wery­fikację, czy pod­czas trans­misji danych nie wys­tąpił błąd trans­misji), czas życia paki­etu (po upły­wie tego cza­su paki­et, o ile nie trafi do adresa­ta, zostanie porzu­cony) czy tzw. fla­gi (są to spec­jalne ‘właś­ci­woś­ci’ paki­etu, które moż­na przełączać pomiędzy wartoś­cią prawda/fałsz).

Zgod­nie z zasadą sep­a­racji warstw (patr­rz wyżej), pro­tokół IP może dzi­ałać w opar­ciu o różne pro­tokoły niższego rzę­du — zarówno Eth­er­net (zwykłe połącze­nie kablowe), jak i IEEE 802.11 (WiFi). Doku­ment RFC 1149 opisu­je także wyko­rzys­tanie gołębii do trans­misji paki­etów IP — choć był to pri­maapril­isowy żart, tech­nicznie jest to możli­we do imple­men­tacji rozwiązanie ;)

Więcej infor­ma­cji o samym pro­tokole IP oraz szczegółowy opis paki­etu zna­jdziesz np. na wikipedii.

TCP i UDP

TCP oraz UDP są podob­ny­mi pro­tokoła­mi, które bazu­ją na pro­tokole IP (z tego powodu częs­to możesz spotkać się z określe­niem TCP/IP — oznacza to pro­tokół TCP dzi­ała­ją­cy przy wyko­rzys­ta­niu pro­tokołu IP). Tech­nicznie rzecz ujmu­jąc TCP jest określone odd­ziel­nie od IP i możli­we jest wyko­rzys­tanie innego pro­tokołu (jako przykład w doku­men­tacji moż­na znaleźć np. kom­bi­nację TCP / IPX).

Pod­sta­wową różnicą pomiędzy TCP oraz UDP jest to, że TCP gwaran­tu­je dostar­cze­nie paki­etu lub zwróce­nie błę­du (inny­mi słowy nadaw­ca ma pewność, że infor­ma­c­ja została dostar­c­zona), UDP z kolei nie zapew­nia żad­nego mech­a­niz­mu tego typu. Ponieważ ‘powiadomie­nie’ wyma­ga wysła­nia infor­ma­cji powrot­nej, pro­tokół TCP jest wol­niejszy od UDP jeśli chodzi o przesyłanie danych (for­mal­nie — wyma­ga więcej inter­akcji, co powodu­je, że ilość przesyłanych danych w sum­ie jest więk­sza). Z tego powodu UDP jest uży­wany w sytu­ac­jach kiedy czas ma więk­sze znacze­nie niż dostar­cze­nie wszys­t­kich danych w niezmienionej postaci — np. stream­ing audio/video czy syn­chro­niza­c­ja zegarów, a także w przy­pad­kach kiedy niskie obciąże­nie sieci jest ważnym czyn­nikiem — np. wykry­wanie kom­put­erów i urządzeń podłąc­zonych do tej samej sieci. TCP z kolei jest zori­en­towany na połącze­nie i dłuższą komu­nikację, lep­iej nada­je się do zas­tosowań, w których spójność danych i fakt ich dostar­czenia w kole­jnoś­ci jest znacznie ważniejszy od szy­bkoś­ci — ma to miejsce np. w przy­pad­ku komu­nikacji email, chatów, czy web­ser­wisów. Bardziej dokładne porów­nanie i różnice zna­jdziesz np. na stron­ie diffen.com .

Poza powyższy­mi różni­ca­mi pro­tokoły te są do siebie podob­ne — defini­u­ją one porty, dzię­ki którym na jed­nym urządze­niu może nieza­leżnie dzi­ałać wiele usług. Ist­nieją stan­dar­d­owe porty dla różnych pro­tokołów wyższego rzę­du (np. 80 — HTTP, 21 — FTP, 22 — SSH, 443 — HTTPS etc), nie ma jed­nak ograniczeń co do ich uży­wa­nia (poza zabez­pieczeni­a­mi sys­te­mu oper­a­cyjnego) — Two­ja aplikac­ja może uży­wać dowol­nego z portów do komu­nikacji. Pro­tokoły te posi­ada­ją własne nagłów­ki — określa­jące m.in. port źródłowy i docelowy, oraz oczy­wiś­cie właś­ci­we dane. Wszys­tkie te infor­ma­c­je trafi­a­ją do sekcji danych paki­etu IP.

Więcej infor­ma­cji zna­jdziesz na wikiedii: TCP oraz UDP .

SSL i TLS

TLS oraz SSL to pro­tokoły związane z bez­pieczeństem komu­nikacji i jej szyfrowaniem, które zapew­ni­a­ją uwierzytel­ni­an­ie (obus­tronne — zarówno ser­w­era jak i klien­ta), szyfrowanie oraz inte­gral­ność danych. Ponieważ TLS jest nowszą wer­sją SSL oraz oba pro­tokoły częs­to bywa­ją nazy­wane po pros­tu SSL, takiego skró­tu będziemy uży­wać w dal­szej częś­ci tej sekcji.

SSL (akro­n­im od ang­iel­skiego Secure Sock­et Lay­er) to zbiór tech­nologii oraz pro­tokołów pozwala­ją­cych zabez­pieczyć dowol­ną komu­nikację — choć najczęś­ciej jest uży­wana (i przez to utoższa­mi­ana) z pro­tokołem HTTP (HTTPS), zna­j­du­je zas­tosowanie także w innych pro­tokołach i aplikac­jach (np. SSH — umożli­wia­ją­cym bez­pieczną komu­nikację pomiędzy dwoma komputerami).

Przyjrzyjmy się poszczegól­nym ele­men­tom bliżej:

Uwierzytelnianie i wymiana kluczy

Uwierzytel­ni­an­ie to pro­ces, w którym potwierdza­my toższamość drugiej strony komu­nikacji. W przy­pad­ku SSL uwierzytel­ni­an­ie jest nie­jako pobocznym ele­mentem — jest ono możli­we bez zas­tosowa­nia żad­nych dodatkowych zabiegów, ale nie jest inte­gral­ną częś­cią pro­tokołu. Cały mech­a­nizm opiera się o tzw. wymi­anę kluczy — jest to pro­ces, pod­czas którego obie strony w bez­pieczny sposób usta­la­ją między sobą jed­no­ra­zowe klucze, które będą uży­wane do szyfrowa­nia dal­szej komu­nikacji. Jeśli jesteś zain­tere­sowana, jak to się dzieje dokład­nie, pole­camy zapoz­nać się z artykuła­mi na tem­at PKI (pub­lic Key Infra­struc­ture) oraz algo­ryt­mu Diffiego-Hell­mana. Wystar­czy wiedzieć, że moż­na w tym pro­ce­sie wyko­rzys­tać cer­ty­fikaty — o ile cer­ty­fikat jest zau­fany (np. został wys­taw­iony przez nas w przeszłoś­ci lub przez zau­fane cen­trum cer­ty­fikacji — przykła­dem może być pod­pis elek­tron­iczny), dane zapisane w takim cer­ty­fika­cie moż­na uznać za bez­pieczne i na ich pod­staw­ie potwierdz­ić tożsamość drugiego uczest­ni­ka komunikacji.

Szyfrowanie

Szyfrowanie to dru­gi bard­zo ważny aspekt pro­tokołu SSL — sam pro­tokół wspiera wiele różnych algo­ryt­mów szyfrowa­nia, konkret­ny jest dobier­any za każdym razem kiedy inicjowana jest komu­nikac­ja mając na uwadze takie czyn­ni­ki jak bez­pieczeńst­wo, wyda­jność oraz obsłu­ga poprzez obie strony (niek­tóre algo­ryt­my mogą nie być wspier­ane przez którąś ze stron). Za pomocą kluczy (ustalonych w pier­wszym kroku), wszys­tkie trans­mi­towane dane są szyfrowane, aby uniemożli­wić ich odczytanie.

Integralność danych

Inte­gral­ność danych to inny­mi słowy zapewnie­nie, że dane nie zostały zmody­fikowane pod­czas trans­misji. Zas­tanaw­iasz się pewnie jak to możli­we — prze­cież dane są zaszyfrowane, powin­ny więc być bez­pieczne? Otóż szyfrowanie to nic innego jak pro­ces matem­aty­czny, częs­to niepozbaw­iony wad i słaboś­ci. Wielu pasjonatów anal­izu­je algo­ryt­my szyfru­jące zna­j­du­jąc ich prob­le­my i słaboś­ci, co przekła­da się na bez­pieczeńst­wo ich stosowa­nia. Co więcej, niek­tóre algo­ryt­my są podatne na spec­jal­ny rodzaj manip­u­lacji, w której nie odszyfrowu­jąc wiado­moś­ci może­my zmienić jej treść w określony sposób! Było­by to bard­zo niebez­pieczne, biorąc pod uwagę że ataku­ją­cy mógł­by np. zmienić numer kon­ta w naszym zlece­niu przelewu na swo­je, czy też zmienić kwotę, nie mówiąc już o zmi­an­ie rozkazów w wojsku czy infor­ma­cji od szpiegów i innych jed­nos­tek (bo nie ukry­wa­jmy — armie i pow­iązane orga­ni­za­c­je są obec­nie najbardziej akty­wne na polu tworzenia i anal­izy algo­ryt­mów szyfru­ją­cych ;) ). Inte­gral­ność danych w SSL zapew­ni­ana jest poprzez dołącze­nie ‘pod­pisu’ — pod­pis ten wyko­rzys­tu­je także klucze użyte do szyfrowa­nia i zaw­iera unikalny ‘skrót’ wiado­moś­ci — nie jest możli­we jego praw­idłowe zmody­fikowanie zmieni­a­jąc część wiado­moś­ci, wyma­ga ponownego wyliczenia i zna­jo­moś­ci kluczy szyfru­ją­cych. Dzię­ki takiej kom­bi­nacji pro­tokół SSL zapew­nia, że dane nie są zmanipulowane.

Więcej o pro­tokole SSL oraz szczegółach jego dzi­ała­nia zna­jdziesz np. na wikipedii.

Pozostałe

Ist­nieje oczy­wiś­cie wiele innych pro­tokołów — nie wnika­jąc w szczegóły każdego z nich, poniżej przed­staw­iamy krótką listę pro­tokołów wraz z opisem do czego służy. Po szczegóły odsyłamy do Wikipedii lub dokumentacji :)

• DNS — pro­tokół, który pozwala zamieni­ać ‘przy­jazne’ nazwy (np. google.pl czy kobietydokodu.pl) na adres IP zrozu­mi­ały dla komputerów
• HTTP — pod­sta­wowy pro­tokół inter­ne­towy, więcej o nim zna­jdziesz w naszym wpisie na jego temat
• FTP — pozwala na wymi­anę plików pomiędzy dwoma komputerami
• SMTP — służy do przesyła­nia (wysyła­nia) pocz­ty elektronicznej
• POP3 — służy do komu­nikacji z ser­w­erem i odczy­ty­wa­nia pocz­ty elektronicznej
• IMAP — bardziej rozbu­dowany pro­tokół do odczy­ty­wa­nia pocz­ty elek­tron­icznej (w odróżnie­niu od POP3 pozwala np. na syn­chro­niza­c­je sta­tusu wiado­moś­ci — czy jest przeczytana/oznaczona jako waż­na itp — oraz wyszuki­wanie wiado­moś­ci po stron­ie serwera)

Jeśli chci­ałabyś poczy­tać więcej o pro­tokołach, które ‘tworzą’ inter­net, jaki znamy, na Wikipedii zna­j­du­je się rewela­cyjne pod­sumowanie wraz ze szczegółowy­mi opisa­mi wszys­t­kich.

Rodzaje komunikacji pomiędzy aplikacjami

Aplikac­je mogą także komu­nikować się ze sobą na różne sposo­by — pro­tokoły może­my podzielić wg dwóch zasad­niczych kryteriów:

1. czy aplikac­je komu­niku­ją się bezpośred­nio ze sobą czy uczest­niczy w tym także ser­w­er ‘cen­tral­ny’
2. czy aplikac­je komu­niku­ją się tylko w przy­pad­ku wys­tąpi­enia jakiegoś zdarzenia (np. wpisanie adresu w przeglą­darce) czy utrzy­mu­ją połącze­nie cały czas

Komunikacja P2P i za pośrednictwem serwera centralnego

Te dwa mod­ele komu­nikacji różnią się w szczegól­noś­ci tym, jaka jest ‘trasa’ wymieni­anych danych.

Komunikacja P2P

Komu­nikac­ja P2P (ang. point-to-point) to sytu­ac­ja, w której dwa urządzenia komu­niku­ją się bezpośred­nio ze sobą, bez udzi­ału cen­tral­nego ser­w­era pośred­niczącego w komu­nikacji. Taka komu­nikac­ja ma kil­ka zalet — zwyk­le jest szyb­sza, odporniejsza na ata­ki (brak cen­tral­nego ser­w­era, który mógł­by ‘pod­słuchać’ wszys­tko) oraz awarie (nie ma znaczenia, czy ser­w­er dzi­ała czy nie, jeśli nie uczest­niczy w komu­nikacji). Jest ona jed­nak bardziej wyma­ga­ją­ca w imple­men­tacji — oba urządzenia muszą się ‘widzieć’ — tj muszą być w stanie roz­maw­iać ze sobą bezpośred­nio, muszą też ‘odnaleźć’ się na początku komu­nikacji — co może nie być proste, z uwa­gi na zmieni­a­jące się adresy IP w przy­pad­ku domowych łącz internetowych.

Komunikacja z wykorzystaniem serwera centralnego

W tym mod­elu komu­nikac­ja odby­wa się wyłącznie pomiędzy ser­w­erem a klien­tem — jeśli infor­ma­c­ja ma trafić do innego klien­ta, jest ona przekazy­wana przez ser­w­er. Taki mod­el znaczą­co upraszcza imple­men­tację, ponieważ ser­w­er najczęś­ciej jest widoczny ‘pub­licznie’ (tj. w Internecie) oraz moż­na go ‘odnaleźć’ korzys­ta­jąc z łatwej nazwy (np. google.com — nawet jeśli fizy­cznie ser­w­er zostanie prze­nie­siony, to nadal może być dostęp­ny pod tą samą nazwą). Wadą takiej komu­nikacji jest dłuższa ‘trasa’ danych, co ma wpływ na szy­bkość trans­misji (z tego powodu komu­nika­to­ry trans­mi­tu­jące wideo częs­to nie korzys­ta­ją z tej metody). Tworzy to także cen­tral­ny punkt, który może zaw­ieść (ang. sin­gle point of fail­ure, SPOF) — jeśli ser­w­er cen­tral­ny uleg­nie awarii lub zostanie prze­ję­ty, zagrożona będzie cała komu­nikac­ja lub klien­ci nie będą w stanie przesyłać żad­nych informacji.

Każdy z tych mod­eli ma wady i zale­ty — ważne jest, żeby wiedzieć o ist­nie­niu obu oraz dobrać poprawne rozwiązanie do zas­tosowa­nia, nad którym aktu­al­nie pracujesz :)

Komunikacja zapytanie-odpowiedź oraz strumieniowa

Dru­gi podzi­ał rozróż­nia sposób, w jaki dane są przesyłane — czy w odpowiedzi na konkretne zapy­tanie czy raczej jako ciągły ‘stru­mień’.

Komu­nikac­ja zapy­tanie-odpowiedź ma miejsce wtedy, kiedy jed­na strona odpowia­da na konkrente zapy­tanie drugiej strony — bard­zo dobrym przykła­dem jest pro­tokół HTTP, w którym klient wysyła zapy­tanie (z infor­ma­cją o adresie strony, jaką chce wyświ­etlić, przesyłanych danych itp), na które ser­w­er wysyła odpowiedź (przy­go­towaną pod to konkretne zapy­tanie — np kod HTML strony).

Komu­nikac­ja stru­mieniowa to komu­nikac­ja, w której dane są przesyłane w sposób ciągły, a nie w odpowiedzi na konkretne zapy­tanie. Przykła­dem może być tutaj trans­mis­ja wideo w komu­nika­torze czy np. obraz z kamery inter­ne­towej lub inter­ne­towego radio.

Podsumowanie

W tym wpisie było sporo teorii — nie martw się jeśli nie pamię­tasz wszys­tkiego, zawsze możesz wró­cić za jak­iś czas i popraw­ić swo­ją wiedzę :) Z punk­tu widzenia szuka­nia pra­cy oraz codzi­en­nej pra­cy, możesz się sprawdz­ić czy potrafisz odpowiedzieć na poniższe pytania:

• Jaka jest różni­ca pomiędzy TCP a UDP?
• Imple­men­tu­jąc komu­nika­tor video, użyłabyś pro­tokołu UDP czy TCP i dlaczego?
• Do czego służy pro­tokół SMTP / POP3 / HTTP / DNS / SSH / TLS … ?
• Jakie znasz pro­tokoły związane z sieci­a­mi? Wymień i krótko opisz 3
• Czym się różni aplikac­ja korzys­ta­ją­ca z P2P od takiej, która korzys­ta z ser­w­era centralnego?
• W jaki sposób mogą się komu­nikować dwie aplikac­je (chodzi o wyjaśnie­nie różni­cy pomiędzy komu­nikacją zapy­tanie-odpowiedź oraz komu­nikacją stru­mieniową (streamingiem)?