Notițe Curs CB PCom

Contribuții notițe curs

Oricine poate contribui pentru a îmbunătăți notitele de curs. Textul laboratoarelor îl găsiti în acest repo. În partea de sus dreaptă a fiecărei pagini există un buton de edit pe care îl puteți folosi pentru a sugera modificări. Va recomandam LanguageTool ca addon de corectura a textului.

Introducere

Orice rețea implică existența unei conexiuni stabilite între entitățile aflate la capetele canalului de comunicare (sender & receiver); această conexiune facilitează transmisia datelor, fiind implementată atât prin medii fizice, cât și prin medii wireless.

O conexiune este definită prin următoarele proprietăți:

  • latență (latency) - cât de repede se transmite un mesaj dintr-un punct A într-un punct B

  • lățime de bandă (bandwidth) - cât de multă informație se transmite dintr-un punct A intr-un punct B


  1. Medii fizice
wired.png
  • Exemplu de conectare a 5 puncte în mediul fizic:
mediifizice.png

  1. Medii wireless
wireless.png

Observație : prin conexiunea wireless nu se transmit doar date, ci și adresa punctului din care se comunică informația, și adresele punctelor către care se comunică informația.

Datele se transmit întotdeauna corect și complet indiferent de mediul de transmitere?

  • În funcție de mediul de transmitere a informației, ne putem confrunta într-o frecvență mai mare sau mai mică cu fenomenul de pierdere a datelor (package loss).


OSI Stack

osistack.png

2. Legătura de date. Servicii şi funcţii. Detecţia şi corectarea erorilor (checksum). Controlul transmisiei.

Nivelul Fizic

Orice rețea implică existența unei conexiuni stabilite între entitățile aflate la capetele canalului de comunicare (sender & receiver); această conexiune facilitează transmisia datelor, fiind implementată (low-level) printr-o serie de medii fizice, cu proprietăți distincte:

  1. Mediu electric (e.g. Ethernet)

    • se folosesc cabluri ce conțin perechi de fire electrice

    • biții mesajului sunt encodați/reprezentați cu ajutorul variației de tensiune prin cele două fire (la capătul dinspre sender se amplasează un senzor ce măsoară diferența de potențial dintre cele două fire)

    • se stabilește o corespondență (mapare) între biți și tensiunea asociată acestora (e.g. 1 $\rightarrow$ 5V; 0 $\rightarrow$ 0V)

      image-20240308190244288

    Obs: Firele electrice sunt folosite, în general,

    • pe distanțe scurte, cu viteze mari de transmisie

    • pe distanțe lungi, cu viteze scăzute

  2. Fibră optică

    • constituită dintr-o bucată subțire de plexiglas, înconjurată de un material cu indice de refracție mare
    • mesajul este transmis prin intermediul unui semnal laser, ce se refractă de-a lungul fibrei până la destinație
    • encodarea mesajului poate fi realizată în diverse moduri (e.g. variând lungimea de undă a laserului)
    • acest mediu prezintă o utilizare generalizată

  3. Unde electromagnetice

    • se folosește o antenă ce generează un semnal variat prin inducție electromagnetică
    • encodarea este realizată prin variația fazei sau a frecvenței semnalului
    • receptorul trebuie să reconstituie mesajul transmis

Indiferent de tipul mediului fizic, apare necesitatea unei înțelegeri privind frecvența de transmisie a informației ($\Rightarrow$​ introducerea protocoalelor).

Bandwidth = viteza de transmisie a unui link [bits / sec]

Problemă:

​ Transmisia informațiilor între două entități implică existența unor semnale de ceas sincronizate.

​ Desincronizarea acestora din urmă (clock slip) poate conduce la apariția unor biți în plus/minus față de codificarea mesajului inițial.

Soluții:

  1. Folosirea ceasurilor atomice (scumpe).

  2. Utilizarea unei perechi de fire pentru transmisia datelor, respectiv a unei alteia pentru semnalul de ceas. Citirea mesajului începe odată cu detectarea acestuia din urmă.

  3. Encodare Manchester - semnalul de ceas este încorporat în semnalul util, simbolurile fiind encodate prin tranziții.

    • utilizată în cadrul Ethernet

    • $\uparrow \iff 1 ; \\downarrow \iff 0;$

Rețelele sunt construite printr-un layering de niveluri; fiecare dintre acestea implementează noi funcționalități pornind de la interfața oferită de nivelul inferior.

Obs: Nivelurile de rețea se doresc a fi generice, oferind un protocol independent de cele subiacente și ușor de introdus în orice sistem.

image-20240308220100927

  • se ocupă de framing = încadrarea mesajului prin introducerea unor octeți speciali (flag) ce specifică începutul și sfârșitul acestuia $\Rightarrow$ FLAG | MESAJ | FLAG

    • FLAG = 01111110

    • pentru a acoperi cazul în care flag-ul este inclus în mesaj, nivelul fizic implementează protocolul de bit stuffing $\iff$ pentru mesajul 01111110, va fi trimis șirul 011111010.

    • nivelul fizic al receptorului va elimina bitul de 0 suplimentar

    • vezi HDLC = high-level datalink control

    image-20240308220100927

    API Datalink:

    ​ send(char buf[SIZE], int len)

    ​ $\downarrow$

    ​ recv(char buf[SIZE], int len)

Resurse:

  • https://www.computer-networking.info/2nd/html/principles/reliability.html
  • https://www.youtube.com/playlist?list=PLowKtXNTBypH19whXTVoG3oKSuOcw_XeW primele 6 clipuri.

Cursul 3

1. Legătura de date

PROTOCOL = set de reguli pe care sender-ul/receiver-ul le repetă

Protocol privind maparea bit-symbol și frecvența de transmisie:

protocol.png

Exemplu de protocol - Ethernet


2. Formatul frame-ului Ethernet. Încapsulare. PPPoE (Point-to-Point over Ethernet)

IEEE (The Institute of Electrical and Electronic Engineers) - organizația care realizează standardele pentru protocoale Ethernet.

  • Encodarea Manchester - realizează suma dintre semnalul util si clk, biți encodați de tranziție
manchester_encode.jpg

Ethernet - 4 perechi de fire electrice ⭢ pentru standardul de 10Mb/s se folosesc doar 2 perechi

Cablu Ethernet:

  • 2 fire A → B
  • 2 fire B → A
  • 1 bit la fiecare 100 nano-secunde → 1 bit/symbol

10Mb/s = 10 * 10^6 / s ↔ 1 / 10^7 s → timpul necesar pentru transmiterea unui bit ⭢ 10^2 nano-secunde ⭢ 1b / 100ns pentru Ethernet

Transmisie - least significant bit ⭢ most significant bit ⮕ trebuie citit invers

ethernetIFG.png

Bandwidth - viteza de transmisie a unui link

ex. Ethernet - pentru 100 de bytes date utile

10 Mb/s = THROUGHPUT (câți biți intră pe fir) → \frac{100}{120} = 8,4 Mb/s = GOODPUT (câți biți sunt utili din cei transmiși)

Obs. Durata/dimensiunea asociată transmisiei ⭢ crește probabilitatea de corupere a biților

datalink.png

Obs. Layerele din stivă trebuie să poată funcționa independent.



3. Protocoale de rețea:

  • HDLC (High-level Data Link) - destul de generic (nu depinde de PHY) încât să meargă pe orice nivel fizic.
hdlc.png

  • Ethernet - depinde de PHY, deci nu este la fel de generic.
  • Fibră optică - legături fizice PTP (point-to-point) ⮕ PPProtocol


  • WLAN - legătură broadcast, e nevoie de adresare (sursă/destinație), throughput scăzut

Obs. - Inițial Ethernet-ul folosea broadcast, apoi a trecut la Switched Ethernet.

The modern Ethernet - point to multipoint

headerethernet.jpg

  • DST MAC - medium access control, câmpuri encodate prin fir, scris în hexa

  • FCS - Frame Check Sequence

  • Dimensiune validă - minim 64 de bytes ⮕ PAYLOAD Size = 48 bytes - 9KB

!!! Cadrul se termină când începe următorul IFG (0V) ⮕ te duci înapoi cu 4 bytes.


API Ethernet - send(MAC, DST, ETH_TYPE, buffer, LEN)

⭢ multiplexare ⭢ ETH ⭢ demultiplexare ⭢ ETH_TYPE (specifică cui i se transmit pachetele la demultiplexare) ⭢ internet ⭢ SWITCH


CAM Table (Content Addressable Memory) - tabelă pentru a reține traficul din SWITCH

SWITCH - dacă la trimiterea pachetului nu se cunoaște portul detinație, celelalte device-uri verifică MAC-ul și dacă nu le este adresat, aruncă pachetul.


4. Adrese nivel de legătură

ierarhieprotocoale.jpg

  • Transport - asigură trnsmisia unformă a pachetelor de dimensiune arbitrară (TCP/UDP)

  • Network - conectează instanțe din rețele diferite (adrese independente - best effort de transmisie) (IP)

  • DL (Data Link Layer) - send/receive frames

  • PHY (The Physical Layer) - send/receive bits

  • DL, PHY - conexiune prin același tip de legătură fizică (Ethernet/WLAN)

Legături de date. Detecția și corectarea erorilor.

Din diverse cauze, în timpul transmiterii de date pot apărea fenomene ce duc la coruperea biților, cu alte cuvinte, la inversarea valorii acestora. Pentru a contracara acest fenomen și pentru a menține consistența datelor transmise se pot aplica două soluții:

  • mecanisme de detecție
  • mecanisme de corecție

Ambele metode se bazează pe adăugarea de "redundanță" în cadrul frame-urilor transmise, adică introducerea unor biți adiționali ce ajută la identificarea erorilor.

Principala diferență între cele două constă în ce se întâmplă cu pachetul la receptare. Mecanismul de detecție duce la aruncarea pachetului primit și trimiterea unei cereri de retransmisie, pe când cel de corecție aplică un set de reguli pentru a corecta erorile.

Pe legături de distanță mică poate fi mult mai eficient să retrimitem un pachet decât să încercăm să-l corectăm.

Ethernet:
           ETH HEADER           PAYLOAD    FCS - frame check sequence = 32 bits
     ______________________ _____________ _____
    |-----|-----|----------|-------------|-----|
    | DST | SRC | ETH TYPE |             |     |
    |-----|-----|----------|-------------|-----|
	                                        ↳ biți redundanți

Bitul de paritate

parity bit Dacă se vrea %n cu n > 2, sunt necesari biți redundanți suplimentari.

Checksum

Checksum este o metodă de detecție ce constă în însumarea octeților mesajului ce trebuie transmis.

Pe send se trimite ~CHECKSUM (checksum negat), iar pe receive se mai calculează odată CHECKSUM pe mesajul primit.

Mesajul este corect <=> ~CHECKSUM + CHECKSUM = 0

Implementare checksum (din laborator):

uint8_t simple_csum(uint8_t *buf, size_t len)
{
	if (!buf) return 0;

	uint8_t sum = 0;

	for (int i = 0; i < len; i++) {
		sum += buf[i];
	}

	return sum % 256;
}

Ciclic Redundancy Check

Detectează orice rafală (secvență de biți consecutivi) de erori cu lungime < 32 biți și orice număr impar de erori.

Implementare a CRC32 (din laborator):

uint32_t crc32(uint8_t *buf, size_t len)
{
	uint32_t crc = ~0;
	const uint32_t POLY = 0xEDB88320;

	for (int i = 0; i < len; i++) {
		crc ^= *buf++;

		for (int bit = 0; bit < 8; bit++) {
			if (crc & 1)
				crc = (crc >> 1) ^ POLY;
			else
				crc >>= 1;
		}
	}
	
	crc = ~crc;
	return crc;
}

Cod corector de erori

    1   1   0   0   1   1   0   0   | -> Se ia bitul majoritar
   / \ / \ / \ / \ / \ / \ / \ / \  |    => orice eroare de un singur bit
   111 110 000 000 111 101 010 000  |       va fi garantat corectată
   \ / \ / \ / \ / \ / \ / \ / \ /  |
    1   1   0   0   1   1   0   0   |

Cod Hamming

Inventat de Richard Hamming în 1950, codul Hamming este o metodă de corectare a erorilor ce constă în aplicarea următorilor pași:

Pentru codificare:

  • Codificarea în sistem binar a pozițiilor biților

  • Pe pozițiile care nu au index putere a lui 2 se vor pune biții corespunzători mesajul de transmis (biți de date)

  • Pe pozițiile cu index putere a lui 2 urmează să se regăsească biții de paritate ce vor fi calculați astfel:

    • Se reține poziția pe care se află valoarea 1 în reprezentarea binară a indexului bitului de paritate
    • Se execută XOR între toți biții de date ce au în reprezentarea binară a indexului valoarea 1 pe aceeași poziție cu cea anterior reținută
    • Rezultatul final reprezintă valoarea bitului de paritate
    • Se reia procesul pentru fiecare bit de paritate

  • Odata găsiți acești biți mesajul a fost codificat și este gata să fie transmis

Pentru corecție:

  • La recepție este posibil ca pe parcursul transmisiei să se fi corupt unul sau mai mulți biți. Codul Hemming poate corecta orice eroare de maxim 2 biți.
  • Pentru a face asta se recalculează biții de paritate, iar indicele bitului corupt va fi egal cu suma indicilor biților de paritate care au ieșit diferit după recalculare.

Exemplu Hemming(7,4)

d - bit de date
r - bit de paritate

*If it's too fast you can adjust the playback speed.

Bibliografie

Networking

Internet = conectarea mai multor rețele locale

-> există gateways/routers (au rol de a mișca pachetele dintr-o parte în alta)
-> oferă datagram services (posibilitatea de a trimite un pachet între sursă și destinație)

Când NU se poate trimite pachetul?

  • nu există legăturile necesare între routers
  • bit errors => pachet aruncat
  • router configurat greșit
  • trafic aglomerat pe acelși link => routerul folosește un buffer și încearcă să salveze stream-urile

alt text

BEST EFFORT DELIVERY (serviciu de bază) - încearcă să trimită pachetele, dar e posibil să eșueze din cauza pachetelor care se pierd.
Pachetele se pierd dacă:

  • nu există legătură la destinație
  • există buclă infinită
  • se schimbă biții și nu mai corespunde

ADRESA IP = identificator unic global

Configurația unui router:
alt text

Routerul așteaptă pachete de la cele 3 rețele:

if (MAC.DST != r1) DROP
else if (MAC.ETHER_TYPE == IP) => IP PROCESSING

Stiva IP:

alt text

if (IP.DST == R)    local_packet_process();
else FORWARD(PKT);

R = IP router

Routerul face longest prefix match.
Cu ajutorul tabelei de routare se alege portul de ieșire.

Tabelă de routare pentru R1:

alt text

Pentru a trimite informații la R2, avem nevoie de adresa MAC.

alt text

Prin protocolul ARP se face match între IP - MAC. Pentru a afla adresa lui R2 se trimite un pachet broadcast și se întoarce un UNICAST.

Ajungem la R2:

  • se uită la ETH.DST
  • se uită la ETH.TYPE (IP) => IP processing
  • se uită la IP.DST => e pentru mine?-> da, păstrez

-> nu, trimit la IP.DST prin lookup și forwarding

Adresele IP sunt globale (nu se schimbă) => avem nevoie de adrese locale (ETH) între rețele.

Costul/pachet nu depinde de mărimea pachetului, ci de capacitatea de pachete.

Planul de date = DATA PLANE se ocupă să trimită pachetele la destinația corectă.

Control plane controlează procesele de matching și forwarding. Are două tipuri de rute (statice și dinamice - adăugate folosind protocoale de routare: BGP, OSPF, ISIS, RIP).

Utilitare:

  • ping (ICMP)
  • traceroute -> calea completă până la destinație

192.168.240.0/24 => 11000000.10101000.11110000.00000000
Primii 24 de biți sunt adresa de NETWORK.
Dacă ultimii 8 biți sunt 0, atunci adresa nu e validă pentru host. Dacă ultimii 8 biți sunt 1 înseamnă că e broadcast.

Algoritmul de longest prefix match

P - prefix de lungime l (adresa la care trebuie să ajung)
V1: P >> (32 - l) ==? D >> (32 - l)
V2: Creez o mască NETMASK
/24 -> primii 24 biți 1, restul 0
/8 -> primii 8 biți 1, restul 0
D & M ==? P
Se alege adresa cu prefixul cel mai lung.

Headerul IP are un TTL (time to leave). La fiecare hop, TTL-ul scade și atunci când ajunge la 0, pachetul este aruncat pe jos. Se folosește pentru a evita ciclarea.

Nivelul IP

IP header

alt text

IHL - lungimea câmpului Options (de obicei 5 => Options are 4 * 5 octeți)
DSCP - clasa de prioritate a pachetului; folosit în centrele de date, nu în internet
ECN - folosit pentru congestion control
TOTAL LENGTH - dimensiunea pachetului
TTL - time-to-live
PROTOCOL - spune ce protocol urmează să prelucreze pachetul
CHECKSUM - acoperă doar headerul IP (nu și payload-ul); se recalculează după forwarding (din cauza TTL)
SRC, DST ADR
OPTIONS

alt text

Dimensiune frame = 9000 biți.
De la S la R1 avem 9000 biți, de la R1 la R2 avem 1500 și de la R2 la D avem 536.
Deoarece de la R1 la R2 sunt mai puțini biți (9000 > 1500) => ori drop, ori IP fragmentation.

IP fragmentation = sparge pachetul în bucăți dacă este mai mare.

Fragmentarea presupune copierea header-ului în întregime cu excepția: identification, flags, fragment offset.
flags: 0 DF MF, DF = don't fragment, MF = more fragment. Dacă DF == 1 => drop.

Dacă avem voie să fragmentăm: alt text

Destinația reasamblează pachetele.
Fragmentarea este rar folosită.

ICMP = protocol debugging peste IP

BORDER GATEWAY PROTOCOL (BGP)

Leagă organizații care își gestionează propriile rețele.
Autonomous Systems: AS, ASN.

BGP este un protocol hard state (ruta se anunță o singură dată și se ține minte).

User Datagram Protocol

UDP = protocl de nivel trasnport

Porturi de nivel trasnport = număr pe 2 octeți; a.î. pachetul să știe pe ce proces se duce.

Headerul UDP se pune după header IP.

UDP-header:

  • src port
  • dst port
  • length
  • checksum

Cursul 7 - Protocolul UDP. Nivelul Transport

image-20240308190244288

Nivelul Rețea prezintă următoarele neajunsuri:

  • nu garantează transmiterea datelor
  • nu poate detecta erori de transmisie
  • nu păstrează ordinea de transmisie a pachetelor

Protocoalele de nivel Transport își propun remedierea acestor puncte slabe: implementarea lor individualizează procesele locale și ramifică transmisia informației de la host la host prin introducerea porturilor.

Fiecare proces poate fi identificat printr-un port unic, asociat socket-ului deschis de către acesta din urmă. Astfel, este soluționată problema partajării concurente a resurselor de rețea (un proces nu așteaptă încheierea comunicației inițiate de către alte procese).

Obs: ID-ul unui port este reprezentat pe 2 octeți. Totodată, există porturi rezervate anumitor protocoale și servicii de sistem (ID-uri alocate între 0-1024).

Protocolul UDP

  • cel mai simplu protocol de transport

  • oferă light-checking pentru erori

  • nu stabilește o conexiune client-server!

    • se trimit direct datagrame
    • idee utilă atunci când nu este necesar / este prea costisitor să păstrăm o conexiune activă între entități

  • nu se garantează ordinea/corectitudinea pachetelor trimise (nu există a astfel de etapă de verificare)

  • prezintă overhead mic $\Rightarrow$ ieftin de implementat, dar nesigur

    • ex: Header UDP - 8 bytes VS Header TCP - 20 bytes

  • implementat de către Kernel-ul de Linux prin intermediul Socket API-ului; Network-Stack-ul devine responsabil de parsarea datagramelor UDP

image-20240308190244288

Schiță a implementării unui protocol de nivel Transport din Kernel (pseudocod):

vector <int> sockets;
pair <int, int> ports(socket, port);

// (1)
int create_unique_id() {
    int new_id = sockets[sockets.size() - 1] + 1;
    
    sockets.push(new_id);
    
    return new_id;
}

// (2)
void bind(int socket, int port) {
    ports.push((socket, port));
}

// (3)
void send(int socket, void *data, ... dest) {
    UDP_packet pkt;
    
    pkt.data = data;
    pkt.port_dst = dest.port;
    pkt.port_src = ...;	// random source port!
    
    send_ip(pkg, dest.ip);
}

// (4)
int recv(int socket) {
    pkt = packets.pop(port);
    UDP_packet p = (UDP_packet) pkt;
    
    verify_checksum(pkt);
    
    return p.data;
}

Concluzii UDP:

  • avantajos datorită vitezei

  • complexitate redusă & cost scăzut de implementare

  • pe baza lui se pot dezvolta alte protocoale

Îmbunătățiri posibile

1) Stop-and-Wait

  • se adaugă următoarele câmpuri la header-ul pachetelor: sequence_number, type (fiecare pe câte 2 octeți)
  • sender-ul trimite o datagramă UDP, așteaptă confirmarea receiver-ului printr-un pachet ACK, apoi trimite următoarea datagramă ș.a.m.d.
  • în cazul în care se pierde un pachet ACK, sender-ul așteaptă un interval de timp, după care retrimite pachetul inițial
  • dezavantaj: protocolul este unul lent

2) Select-and-Go

  • folosește fereastra glisantă
  • se trimite un număr de datagrame egal cu dimensiunea ferestrei (fiecare pachet va avea un seq_number asociat)
  • pentru fiecare datagramă se așteaptă un ACK de confirmare cu seq_number-ul corespunzător
  • dacă se pierde un pachet, ACK-urile primite vor avea seq_number-ul pachetului precedent; pachetul pierdut va fi retrimis, iar fereastra glisantă se va deplasa mai departe

Nivelul Transport. Fereastra glisantă. Retransmisii

Nivelul transport

O rețea este proiectată cu scopul ca mai multe aplicații de pe host-uri diferite să poată schimba informații între ele. Pentru a garanta că fiecare pachet primit ajunge la aplicația căruia îi este destinat se utilizează conceptul de porturi.

Un port este o entitate virtuală (un număr asignat unei conexiuni) ce face legătura între host și aplicație.

Astfel, la acest nivel are loc procesul de demultiplexare (vezi UDP) care asigură simplul transport al datelor. În plus, mai este necesară o transmitere sigură (să ajungă datele), în ordine și care să se facă o singură dată (vezi TCP).

transport

Ajustarea vitezei de transmisie

Protocolul de transport trebuie să se asigure că:

  • transmite cât se poate de repede
  • împarte echitabil resursele
  • folosește eficient resursele
              lungime fir
latența ≃ ─────────────────         d = delay (latență)
            viteza luminii          B = bandwidth (bit/s)
                                    D = dimensiunea fișierului

                            10 000 km 
ex: București-SUA => d = ─────────────── = 1/30s = 33ms
                         3 000 000 km/s 
RTT = 2*33ms = 66ms


▭ - pachet 1Mb
TS = D/B 
           ________________________
B=1 Gbps   |______________________| ▭ =>TS = 1Mb/1Gbps = 8ms
           ________________________
           |                      |   
           |                      |
B=10 Gbps  |                      | ▭ =>TS = 1Mb/10Gbps = 0.8ms
           |                      |
           |______________________|

TT = TS + d = 33+8 sau 33+0.8 = 41ms sau 33.8ms
Td(D, B, d) = D/B + d

  • Latența (timpul în care semnalul ajunge de la un capăt la celălalt al firului) unei transmisii depinde de lungimea firului (în cazul transmisiei prin fibră optică).

  • Round Trip Time (RTT) este durata de timp necesară transmiterii unui pachet și primirii unui răspuns (dublul latenței).

  • Timpul de serializare (TS) este timpul necesar de a lua un pachet și a-l pune pe fir.

  • Timpul de transfer (TT) este timpul necesar de a transmite un pachet.

  • Timpul de download (Td) este timpul necesar de a descarca un fișier.

Un mecanism prin care ne asigurăm că pachetele sunt transmise în ordine și o singură dată este mecanismul START-STOP. El presupune trimiterea unui pachet, așteptarea unui răspuns și, în funcție de răspuns, retrimiterea pachetului sau trimiterea pachetului următor.

Fereastra glisantă

Fereastră = numărul de pachete aflate în zbor pentru care nu am primit ACK.

ACK = informație de control (acknowledged)

Problema mecanismului start-stop este că de la o transmisie la alta cablul ar fi gol, iar astfel s-ar irosi mult timp. O soluție este să trimitem mai multe pachete pe fir fără a primi un răspuns.

fereastra

Astfel se poate ajusta cantitatea de date transmisă astfel încât transmisia să se facă în mod optim.

Mai multe animații aici

BPD = B * d (Bandwidth Delay Product) = MTU * d / TS(MTU, B)
MTU = Maximum Transmission Unit

d = 20ms     |
B = 100 Mbps | => BDP = 100Mbps * 20ms = 250 Kb

d = 20ms     |
B = 1 Gbps   | => BDP = 2,5 Mb

windowSize = [BPD / datagramSize] , datagramSize <= 1500 bytes

Pentru a asigura o transmisie optimă a datelor (cât mai mult, cât mai rapid, fără pierderi, la fel pentru toți) este necesară o modalitate de a regla dinamic mărimea ferestrei glisante. Vezi capitolul Congestion Control.

Retransmisii

Dat fiind că legăturile de date sunt predispuse să aibă pierderi, sunt necesare mecanisme ce asigură un transfer corect al pachetelor de date (complet și în ordine).

  • Cum știi că un pachet s-a pierdut? De obicei, pachetele ce urmează să fie trimise sunt acumulate într-un sendBuffer, iar atunci când sunt trimise pe fir le este asociat un timer. Dacă timpul de așteptare depășește valoarea RTO (Retransmit TimeOut), atunci pachetul poate fi considerat pierdut pe drum și este necesară retransmiterea lui.
  • RTO nu poate fi foarte agresiv, căci în cazul unei congestii în rețea durata de transmisie este inevitabil mai lungă decât într-o rețea "goală", iar atunci există șanse ca pachetul să fie fals declarat pierdut.

Mecanismul de retransmisie depinde de capacitatea receiverului de a prelucra informația primită:

  1. No receive buffer - La receptor, orice pachet care nu este așteptat va fi aruncat. Astfel, pachetele vor fi primite în ordine, dar pachetele neașteptate (care ar trebui să vină după pachetul așteptat, dar ajung înaintea lui) vor fi aruncate până la primirea pachetului așteptat. (GO-BACK-N)

no_buff

  1. Receive buffer - La receptor, fiecare pachet este salvat într-un buffer. Astfel, pachetele neașteptate nu vor mai fi aruncate, ci vor fi salvate pe poziția lor corespunzătoare, pachetul așteptat fiind și el salvat ulterior, când este primit, în fața pachetelor ce ar fi trebuit să vină după el.

buff

Bibliografie

Cursul 9 - Protocolul TCP

TCP = Transmission Control Protocol

image-20240308190244288

Obiective ale protocolului TCP:

  • transmisie sigură, în ordine

  • trimiterea pachetelor o singură dată

  • format = șir de octeți (protocolul nu mai e orientat pe pachete)

    • recv() poate primi doar o parte din octeți, caz în care se repetă operația

  • congestion-control

  • demultiplexare

În comparație cu UDP...

  • nu se garantează ordinea sau siguranța transmisiei
  • format = datagrame (totul sau nimic)
  • demultiplexare

Paralelă - Socket APIs

image-20240308190244288

image-20240308190244288

Stabilirea conexiunii TCP

Obs: Conexiunea TCP este bidirecțională și se bazează pe sincronizarea numerelor de secvență.

image-20240308190244288

Schiță a procesului de comunicație:

  • a) stabilirea conexiunii

image-20240308190244288

  • b) transmisia pachetelor

image-20240308190244288

Tipuri diferite de pachete ACK:

  • ACK cumulativ $\rightarrow$ garantează siguranța primirii (reliability)
  • SACK (selective ACK)

Congestion control

Este un algoritm executat independent pentru fiecare conexiune. Acesta ajustează CWND (Congestion Window) folosind feedback-ul din rețea (ACK-uri).

Algoritmul New RENO

alt text

Inițial slow_start_threshold are valoarea infinit.

  • ON_ACK():
        if(CWND < ssthresh)    //slow-start
            CWND++;        //creștere exponențială
        else                   //congestion avoidance
            CWND += 1/CWND;
  • ON_LOSS():
        CWND /= 2;
        ssthresh = CWND;
  • ON_TIMEOUT():
        ssthresh = CWND/2;
        CWND = 1;

Fairness (Chiu-Jain diagram)

Reprezintă un grafic în care apare CWND a doi senderi.

alt text

alt text

W (RTT) = o unitate pentru fiecare pachet

Pentru linerate avem:

  • (BDP + BUFFER) / 2 >= BDP
  • BUFFER >= BDP

Generez loss pentru a vedea ce capacitate am. Pentru echitabilitate(fairness) scad rata de transmisie, dar buffer-ul trebuie să fie foarte mare ca să nu pierd performanță.

BW = CWND * MSS / RTT

1 loss la w + w + 1 + ... + 2w pachete => w * 3w / 4 pachete transmise

p = 1 / (3 * w^2 / 4) => w^2 = 4 / 3p => w = √ (4 / 3p)  <=> aceeași fereastră pentru ambii senderi; aceeași pierdere și același throughput

p * CWND = probabilitatea să pierd un pachet

∆ = (1 - p) * 1 - p * CWND * (CWND / 2), p ≈ 0
∆ = 0 => se scoate CWND

Exerciții:

  • B = 1 Gbps
    S1, S2, RTT 10 ms

    BS1, BS2 = ?

    CWNDS1 = CWNDS2 = √ (2 / p)  => BS1 = BS2 = √ (2 / p)  * MSS / RTT
    BS1 + BS2 = B

  • Diferă RTT:
    RTTS1 = 1 ms
    RTTS2 = 10 ms

    CWNDS1 = CWNDS2 = CWND = √ (2 / p)  => BS1 = BS2 = √ (2 / p) 

    BS1 = CWND * MSS / 1ms (1)
    BS2 = CWND * MSS / 10ms (2)

    Din (1) și (2) => BS1 / BS2 = 10
    RTT mic => B mai mare (trimite mai repede)


alt text RTT = 1ms
C1 + C3 <= 1 Gbps
C2 + C3 <= 1 Gbps

C1 = √ (2 / p1)  * MSS / RTT (1)
C2 = √ (2 / p2)  * MSS / RTT (2)
C3 = √ (2 / (p1 + p2))  * MSS / RTT (3)

Din (1), (2) și (3) => C1, C2 ≈ √ (2 / p)  ; C3 ≈ √ (1 / p)  => C1 / C3 = C2 / C3 = √ 2  =>
C3 * ( √ 2  + 1) = 1 Gbps => C3 = 1000 Mbps / 2,41 => nu se împarte egal

Cursul 12 - World Wide Web

Domain Name System (DNS): nume -> IP

  • protocol peste UDP
  • nivel APP

File Transfer Protocol (FTP)

  • protocol peste TCP

Email

  • protocol peste TCP

Web

Standardized General Markup Language (SGML) -> apărut in 1950

  • referențiere a documentelor pe aceealși mașină
  • 2 tipuri de entități: Clienți (browser) + Servere (APACHE, IIS)
arboreFQDN.png

Componente WWW:

1. Adresare: Uniform Resource Identifier - mod unic de a identifica informația

2. HTML: Hypertext Markup Language - cum se afișează informația

3. HTTP: Hypertext Transfer Protocol - mod de a transmite cereri, peste TCP

Serializarea HTTP

arboreFQDN.png clientserver.png

HEADER HTTP:

METHOD     PATH     HTTP_VERSION

HEADERS (1 pe linie)

[MIME]

________ (linie goală)

(finalul request-ului)


TCP [GET/vasile     HTTP/1.0

HOST: www.upb.ro

USER AGENT: CHROME...

\n \n

]



clientserver.png

PRINTRE REPLY_HEADERS:

clientserver.png clientserver.png

Cursul 13

1. Domain Name System (DNS)

  • sistem distribuit
  • transforma NUME -> ADRESE
  • serviciu care traduce numele de domenii in adrese IP
  • ofera confort in accesarea de site-uri web

Fiecare host dintr-o rețea are o adresă IP unică.

    HOST.txt
 Nume      IP       -> flat addressing
______   ______     -> numele din HOST.txt trebuie să fie unice 
______   ______
______   ______


2.FQDN (Fully Qualified Domain Name)

  • label1 . label2 . label3 . ... . labeln . -> ultimul punct reprezintă rădăcina arborelui
  • numele unic al unui computer sau host pe internet, conține toate nivelurile superioare, inclusiv numele domeniului de nivel superior (TLD)

Ex. www.upb.ro

  • www = numele host-ului
  • example = numele domeniului
  • com = TLD

Arbore FQDN

arboreFQDN.png
  • Dacă pică root nameserver nu mai funcționează rețeaua
  • "UPB" este subdomeniul lui "RO"
  • Fiecare nod este fie un domeniu, fie o gazdă
  • Ierarhia permite ca organizații diferite să controleze rețele/domenii diferite
  • Orice punct din ierarhie poate răspunde la cererile din subpunctele sale
  • Fiecare domeniu are propriul NAMESERVER
  • "HOTNEWS.RO" -> definește un domeniu, dar nu e host
  • HOST -> frunză a arborelui
  • Domeniile trebuie să fie diferite între ele

curs.upb.uk ≠ curs.upb.ro

3. NAME RESOLUTION

  • procesul prin care dintr-un nume obținem o adresă IP

Ex. www.cs.upb.ro

  • Ne trebuie un IP al unui NAMESERVER
grafic.png

RESOLVER

  • un nameserver care face query-uri recursive pentru fiecare cale din arbore -> păstreză cererile într-un cache
  • oferă răspunsuri mai rapide clienților
  • reduce memoria folosită

UDP PORT 53 -> portul standard pentru serviciile DNS, utilizat pentru consultările DNS care sunt în principal de tip cerere-răspuns, trimise de la client la server

  • HEADER (conține câmpurile) ->            IP -> 16 biți

  • QUESTIONS                                          Flag QA -> (0 - query, 1 - answer)

  • ANSWERS                                             OPCODE -> ce operație facem, în general 0 - query

  • AUTHORITY                                          RD -> Recursion Desire

  • ADDITIONAL                                        AA -> Authoritative Answer

                                                                       RCODE -> codul de eroare

QUESTIONS, ANSWERS, AUTHORITY, ADDITIONAL -> Resource Records (RR)

  • entități de bază în sistemul DNS, folosite pentru a răspunde la cererile DNS, iar fiecare RR identifică o anumită resursă

  • NAME

  • TYPE -> NS - nameserver, A - iPv4, AAAA - iPv6, MX - mail exchanger

  • CLASS - setat pe IN (internet)

  • RDLENGTH - cât de mare e răspunsul


Cursul 14 - Securitatea rețelelor

1. THREAT MODEL

PASSIVE

Amenințările pasive implică interceptarea și monitorizarea traficului de rețea fără a modifica datele transmise.

  • SPLITTER - dispozitiv hardware care împarte semnalul pentru monitorizare fără a întrerupe traficul
  • TCPDump - software care capturează pachetele de date care traversează rețeaua
passive.png passive.png

ACTIVE

Amenințările active implică modificarea sau întreruperea traficului de rețea.

  • Man in the Middle - se bazează pe un punct de routare pe care se face spoofing (R în desenul de mai jos), atacatorul interceptează și eventual modifică comunicarea dintre două părți
  • Spoofing - atacatorul își asumă identitatea unei entități de încredere.
  • DENIAL OF SERVICE - se referă la resursele limitate (BANDWIDTH, memorie), atacul vizează limitarea resurselor pentru a întrerupe serviciile
passive.png passive.png

2. Primitive de securitate

One-time pad - sistem de criptare în care cheia este aleatorie și la fel de lungă ca mesajul

  • cheia trebuie să fie aleatorie și utilizată o singură dată.

  • cheia trebuie să fie la fel de lungă ca mesajul.


C = M + K (+ = XOR)

A <- C (cyphertext), R (random)

P ~ 50%

-> problemă: securitate, eficiență (cheia are lungimea mesajului)



3. Algoritmi cu cheie simetrică

E(M, K) => C - Criptare

D(C, K) => M - Decriptare

∀ M, K: D(E(M,K), K) = M


Exemple:

  • DES - cheie de 56 de biți

  • RCU

  • AES - cheie de 12811961256 de biți

  • Cha Cha

passive.png

keysize: 128-256 de biți

encriptare/decriptare rapidă -> 10Gbps/core



4. Algoritmi cu cheie publică

_K = (Kpub -> publică, Kpriv -> secretă)


Exemple:

  • RSA -> fact. nr. prime

  • ECDA -> în practică

∀ M, (Kpub, Kpriv) = M, dacă D(E(M, Kpub), Kpriv) = M

                                              D(E(M, Kpriv), Kpub) = M


5. Algoritmul (SHA - One-way functions)

Funcțiile hash produc un digest fix dintr-un input de dimensiune variabilă, asigurând integritatea datelor.

f: M -> DIGEST -> eficient

  • SHA       160

  • SHA2      256

  • MD5

passive.png

∃ Entități care atestă cheia publică a cuiva => Certificatul


TOFU - Trust of First Use

  • Se presupune prima dată că nu vb. cu atacator
  • Salvăm local cheia publică

Cursul 15 - Securitatea rețelelor

1. Primitive criptografice

Criptare simetrică: K, E, D (∀) KD(E(M, K)) = M

Criptare asimetrică: (Kpub, Kpriv) E, D (∀) K (∀) M

                                  D(E(M, Kpub), Kpriv) = M

                                                    și

                                  D(E(M, Kpriv), Kpub) = M


2. One-way-function

HASH(M) -> digest; computațional imposibil să găsești M având digest

HMAC(M, K) = HASH(M | K) -> Message Authentication Code (MAC)

E(M, K) MAC(E(M, K)) = M(C | K) - Encrypt and then MAC


3. Diffie Helman Key Exchange

passive.png passive.png

TRUST ON FIRST USE

passive.png

Public Key Infrastructure (PKT)

HOSTNAME -> PUBLIC KEY

  • entități terțe de încredere

Certification Authority <-> Registration Authority

Certificat PKT -> se face HASH, se adaugă semnătura

  • Document public

  • Cont -> Asocierea HOSTNAME -> PUBKEY

                   -> DATA -> EMIT

                                  -> EXP

                   -> Cine le-a emis


Transport Layer Security

  • APP
  • TLS
  • TCP

HTTPS - folosește TLS, rulează pe portul 443 HTTP - rulează pe portul 40

passive.png passive.png