[neofita - C/C++] Pacchetti IP raw. Definizione?

[wartpro]

Salve a tutti,

è la prima volta che posto un thread qui nella sezione di Programmazione. Sono un neofita di questo mondo ed è da poco che mi sono affacciato nel mondo C/C++.

Dato che non ho trovato una definizione di questo termine la chiedo a voi che di sicuro saprete darmi la risposta.

Cosa sono i "pacchetti IP raw" ?
Cosa significa che sono "pacchetti non formattati" ?



Grazie a tutti.
wart

[wartpro]

Dimenticavo! Spero di non aver sbagliato sezione del forum!!!

[MItaly]

Suppongo si parli di pacchetti IP prima che se ne estragga il payload e venga passato agli strati superiori dello stack di rete (ad esempio TCP). Per capirci, il concetto è lavorare direttamente sui pacchetti IP così come arrivano, senza astrazioni come i socket che "simulano" un flusso continuo di dati.

[wartpro]

Grazie per la risposta MItaly.

Permettimi però un'espressione:

C'è da studiare..

[MItaly]

Leggiti qualcosa sul modello ISO-OSI, dopo dovresti capire più o meno cosa ho scritto sopra.


--- da leggere solo dopo aver capito qualcosa del modello in questione ---
Per dirla ancora in altri termini: le applicazioni normalmente stanno in cima allo stack e lavorano "con tutte le astrazioni" fornite dai protocolli sottostanti, mentre un'applicazione che lavora con pacchetti IP raw (=grezzi) va a pescarsi direttamente quello che sta al livello del protocollo IP, non ancora elaborato dai protocolli che ci stanno sopra.

[wartpro]

Mh. Lo farò.

Per ora posso dire che ho un'infarinatura di ciò che sono i pacchetti IP, TPC, ecc.

Permettimi un esempio (illustrato al contrario):

---
|IP |
---
|
|--> Sta dentro --> ------
| TCP |
------

..e così via..


Spero di non aver detto una baggianata

Ma il pacchetto IP non è "l'ultimo frutto" di tutta la comunicazione?

[wartpro]

Il mio disegnino è stato sfasciato... ...vabè hai capito cmq.

[MItaly]

Se ho capito il disegnino, la stai vedendo al contrario.

Prendiamo il caso di un browser che si collega con un sito web. Semplificando, una volta risolto il nome del sito nel suo indirizzo IP, si limita a fare una richiesta di collegamento alla porta 80 dell'IP in questione, ed ottiene uno "stream" bidirezionale di dati, da cui può scrivere e leggere, un po' come quando uno scrive su un terminale. Questo è quello che vede l'applicazione.

I dati che vanno e vengono sono in prima istanza gestiti dal protocollo TCP, che fornisce il livello di trasporto. I dati che l'applicazione invia come un flusso continuo vengono di fatto spezzettati in tanti pacchetti numerati dal protocollo TCP. Questo ci aggiunge qualche informazione addizionale (checksum & co) e li passa al livello inferiore dello stack.

Questo livello è quello del protocollo IP. La roba che il protocollo IP gestisce (il "payload") sono i pacchetti che gli vengono passati dai livelli superiori; il protocollo IP ci aggiunge un po' di header, tra cui quelli che specificano il destinatario finale dei pacchetti, e decide se il destinatario è nella subnet corrente (e quindi non c'è bisogno di routing) o fuori; in quest'ultimo caso sceglie a che router (contenuto nella subnet corrent) vanno girati perché possano arrivare a destinazione.

Il lavoro di invio vero e proprio viene delegato allo strato inferiore, ovvero il livello di "collegamento", in genere ethernet; questo, in collaborazione con il protocollo ARP, trasforma l'indirizzo locale (destinatario se la macchina è nella subnet corrente, router se è "fuori") a cui girare il pacchetto in un MAC address sul segmento di rete locale. Il datagramma ethernet così costruito viene passato al livello inferiore.

Questo è il livello fisico, ovvero effettivamente i circuiti che generano i segnali elettrici in cui vengono trasformati i datagrammi ethernet.

Se la macchina è nel segmento locale, il "pacchettone" (contenente gli "inscatolamenti" dati da tutti i protocolli oltre ai dati veri e propri) arriva subito; altrimenti (come tipicamente accade) ci sarà il passaggio per uno o più router. In ciascuno di questi passaggi il pacchetto viene rispacchettato fino al livello del protocollo IP, il software del router esamina il pacchetto a livello IP e decide a che altro router girarlo, reimpacchettandolo poi a livello di collegamento e a livello fisico per fargli effettivamente raggiungere il router successivo.

Quando si arriva finalmente al destinatario effettivo, il pacchetto viene spacchettato fino al livello IP. Il software TCP a questo punto attende man mano l'arrivo dei pacchetti, eventualmente li riordina (l'ordine può variare se vari pacchetti hanno fatto strade diverse), e quindi li fornisce all'applicazione come un flusso continuo di dati.
Per ogni pacchetto correttamente ricevuto manda una conferma di ricezione (che viene incapsulata come qualunque pacchetto TCP) al mittente, altrimenti, se vede che un pacchetto è danneggiato o si è perso, richiede al mittente rispedire il pacchetto in questione.

Lavorare sui pacchetti IP raw in sostanza vuol dire bypassare le comodità offerte dal protocollo TCP ed esaminare direttamente quello che arriva dal protocollo IP. In ogni caso in genere si lavora sui pacchetti IP raw solo per scopo di troubleshooting/sniffing, se semplicemente non servono tutte le comodità del TCP in genere si usa il protocollo UDP.

[wartpro]

14239 + 1 messaggi inviati parlano chiaro.



Grazie per la risposta esaurientissima. Non sono al tuo livello ma presto, rileggendo queste righe, forse, ci arriverò.

[MItaly]