%% network.tex
%%
-%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
+
\chapter{Introduzione alla programmazione di rete}
\label{cha:network}
Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un
modello abbastanza complesso\footnote{infatti per memorizzarne i vari livelli
- è stata creata la frase \texttt{All people seem to need data processing}, in
+ è stata creata la frase \textit{All people seem to need data processing}, in
cui ciascuna parola corrisponde all'iniziale di uno dei livelli.}, tanto che
usualmente si tende a suddividerlo in due parti, secondo lo schema mostrato in
fig.~\ref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda
\hline
\hline
Livello 4&\textit{Application} &\textsl{Applicazione}&
- Telnet, FTP, etc. \\
+ Telnet, FTP, ecc. \\
Livello 3&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
Livello 2&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
Livello 1&\textit{Link} &\textsl{Collegamento}&
Comment} ed è la procedura attraverso la quale vengono proposti gli
standard per Internet.}).
\item I dati delle applicazioni vengono inviati al livello di trasporto usando
- un'interfaccia opportuna (i \textit{socket}\index{socket}, che esamineremo
- in dettaglio in cap.~\ref{cha:socket_intro}). Qui verranno spezzati in
- pacchetti di dimensione opportuna e inseriti nel protocollo di trasporto,
- aggiungendo ad ogni pacchetto le informazioni necessarie per la sua
- gestione. Questo processo viene svolto direttamente nel kernel, ad esempio
- dallo stack TCP, nel caso il protocollo di trasporto usato sia questo.
+ un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
+ cap.~\ref{cha:socket_intro}). Qui verranno spezzati in pacchetti di
+ dimensione opportuna e inseriti nel protocollo di trasporto, aggiungendo ad
+ ogni pacchetto le informazioni necessarie per la sua gestione. Questo
+ processo viene svolto direttamente nel kernel, ad esempio dallo stack TCP,
+ nel caso il protocollo di trasporto usato sia questo.
\item Una volta composto il pacchetto nel formato adatto al protocollo di
trasporto usato questo sarà passato al successivo livello, quello di rete,
che si occupa di inserire le opportune informazioni per poter effettuare
scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
errati o non recapitabili.
-L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
-di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
-natura inaffidabile, in quanto non è assicurata né una percentuale di
-successo né un limite sui tempi di consegna dei pacchetti.
+L'incarico di rendere il recapito pacchetti affidabile non spetta al livello
+di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura
+inaffidabile, in quanto non è assicurata né una percentuale di successo né un
+limite sui tempi di consegna dei pacchetti.
È il livello di trasporto che si deve occupare (qualora necessiti) del
controllo del flusso dei dati e del recupero degli errori; questo è realizzato
-dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
-al livello di trasporto o ai livelli superiori.
+dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è
+pertanto al livello di trasporto o ai livelli superiori.
Infine le singole stazioni collegate alla rete non fungono soltanto da punti
terminali di comunicazione, ma possono anche assumere il ruolo di
due livelli centrali, e soprattutto quello di trasporto.
La principale interfaccia usata nella programmazione di rete, quella dei
-socket\index{socket}, è infatti un'interfaccia nei confronti di quest'ultimo.
-Questo avviene perché al di sopra del livello di trasporto i programmi hanno a
-che fare solo con dettagli specifici delle applicazioni, mentre al di sotto
-vengono curati tutti i dettagli relativi alla comunicazione. È pertanto
-naturale definire una interfaccia di programmazione su questo confine, tanto
-più che è proprio lì (come evidenziato in fig.~\ref{fig:net_osi_tcpip_comp})
-che nei sistemi Unix (e non solo) viene inserita la divisione fra kernel space
-e user space.
+socket (vedi sez.~\ref{cha:socket_intro}), è infatti un'interfaccia nei
+confronti di quest'ultimo. Questo avviene perché al di sopra del livello di
+trasporto i programmi hanno a che fare solo con dettagli specifici delle
+applicazioni, mentre al di sotto vengono curati tutti i dettagli relativi alla
+comunicazione. È pertanto naturale definire una interfaccia di programmazione
+su questo confine, tanto più che è proprio lì (come evidenziato in
+fig.~\ref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non solo) viene
+inserita la divisione fra kernel space e user space.
In realtà in un sistema Unix è possibile accedere anche agli altri livelli
inferiori (e non solo a quello di trasporto) con opportune interfacce di
I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i
seguenti:
-
\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
\item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
orientato alla connessione che provvede un trasporto affidabile per un
flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
di tutti gli aspetti del trasporto, come l'acknoweledgment, i timeout, la
- ritrasmissione, etc. È usato dalla maggior parte delle applicazioni.
+ ritrasmissione, ecc. È usato dalla maggior parte delle applicazioni.
\item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
venire usato direttamente da alcuni programmi come \cmd{ping}. A volte ci
si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
\item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
- protocollo di livello 2 usato per il \textit{multicasting} (vedi
- sez.~\ref{sec:xxx_multicast}). Permette alle stazioni remote di notificare
- ai router che supportano questa comunicazione a quale gruppo esse
- appartengono. Come ICMP viene implementato direttamente sopra IP.
+ protocollo di livello 2 usato per il \itindex{multicast}
+ \textit{multicast} (vedi sez.~\ref{sec:xxx_multicast}). Permette
+ alle stazioni remote di notificare ai router che supportano questa
+ comunicazione a quale gruppo esse appartengono. Come ICMP viene
+ implementato direttamente sopra IP.
\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
- reti di tipo broadcast come Ethernet, Token Ring o FDDI che hanno associato
- un indirizzo fisico (il \textit{MAC address}) alla interfaccia, ma non serve
- in connessioni punto-punto.
+ reti di tipo \itindex{broadcast} \textit{broadcast} come Ethernet, Token
+ Ring o FDDI che hanno associato un indirizzo fisico (il \textit{MAC
+ address}) alla interfaccia, ma non serve in connessioni punto-punto.
\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
mappando un indirizzo hardware in un indirizzo IP. Viene usato a volte per
IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
a parte applicazioni particolari si preferisce sempre usare i servizi messi a
-disposizione dai due protocolli precedenti. Per questo motivo a parte alcuni
-brevi accenni su IP in questa sezione ci concentreremo sul livello di
+disposizione dai due protocolli precedenti. Per questo, motivo a parte alcuni
+brevi accenni su IP in questa sezione, ci concentreremo sul livello di
trasporto.
\subsection{Internet Protocol (IP)}
Internet Protocol nasce per disaccoppiare le applicazioni della struttura
hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
dei dati indipendente dal sottostante substrato di rete, che può essere
-realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
+realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, ecc.).
Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
all'altro della rete; le caratteristiche essenziali con cui questo viene
realizzato in IPv4 sono due:
internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
problemi si è perciò definita una nuova versione del protocollo, che (saltando
un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
-IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
+IPv4, mantenendone inalterate le funzioni che si sono dimostrate valide,
eliminando quelle inutili e aggiungendone poche altre per mantenere il
protocollo il più snello e veloce possibile.
supportare una gerarchia con più livelli di indirizzamento, un numero di
nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi.
\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
- si aggiunge agli usuali \textit{unycast} e \textit{multicast}.
+ si aggiunge agli usuali \textit{unicast} e \itindex{multicast}
+ \textit{multicast}.
\item la semplificazione del formato dell'intestazione (\textit{header}) dei
pacchetti, eliminando o rendendo opzionali alcuni dei campi di IPv4, per
- eliminare la necessità di riprocessamento della stessa da parte dei router e
+ eliminare la necessità di rielaborazione della stessa da parte dei router e
contenere l'aumento di dimensione dovuto all'ampliamento degli indirizzi.
\item un supporto per le opzioni migliorato, per garantire una trasmissione
più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
\subsection{User Datagram Protocol (UDP)}
\label{sec:net_udp}
-UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è
+UDP è un protocollo di trasporto molto semplice; la sua descrizione completa è
contenuta dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in
-sostanza esso è una semplice interfaccia a IP dal livello di trasporto. Quando
-un'applicazione usa UDP essa scrive un pacchetto di dati (il cosiddetto
-\textit{datagram} che da il nome al protocollo) su un socket\index{socket}, al
+sostanza esso è una semplice interfaccia al protocollo IP dal livello di
+trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto di dati (il
+cosiddetto \textit{datagram} che da il nome al protocollo) su un socket, al
pacchetto viene aggiunto un header molto semplice (per una descrizione più
accurata vedi sez.~\ref{sec:udp_protocol}), e poi viene passato al livello
superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione. Dato
pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
questo di nuovo deve tenere conto l'applicazione.
-Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
+Un altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
destinazione esso viene passato all'applicazione ricevente in tutta la sua
lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
viene anche essa trasmessa all'applicazione all'atto del ricevimento.
Infine UDP è un protocollo che opera senza connessione
(\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
-in cui un client può scrivere su uno stesso socket\index{socket} pacchetti
-destinati a server diversi, o un server ricevere su un socket\index{socket}
-pacchetti provenienti da client diversi. Il modo più semplice di immaginarsi
-il funzionamento di UDP è quello della radio, in cui si può
-\textsl{trasmettere} e \textsl{ricevere} da più stazioni usando la stessa
-frequenza.
+in cui un client può scrivere su uno stesso socket pacchetti destinati a
+server diversi, o un server ricevere su un socket pacchetti provenienti da
+client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è
+quello della radio, in cui si può \textsl{trasmettere} e \textsl{ricevere} da
+più stazioni usando la stessa frequenza.
Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
grande pregio della velocità, che in certi casi è essenziale; inoltre si
presta bene per le applicazioni in cui la connessione non è necessaria, e
costituirebbe solo un peso in termini di prestazioni, mentre una perdita di
-pacchetti può essere tollerata, ad esempio le applicazioni di streaming e
-quelle che usano il multicasting.
+pacchetti può essere tollerata: ad esempio le applicazioni di streaming e
+quelle che usano il \itindex{multicast} \textit{multicast}.
\subsection{Transport Control Protocol (TCP)}
\label{sec:net_tcp}
Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
del tempo di andata e ritorno dei pacchetti fra un client e un server (il
-cosiddetto RTT, \textit{round-trip time}), che lo rende in grado di adattarsi
-alle condizioni della rete per non generare inutili ritrasmissioni o cadere
-facilmente in timeout.
+cosiddetto RTT, \itindex{Round~Trip~Time} \textit{Round Trip Time}), che lo
+rende in grado di adattarsi alle condizioni della rete per non generare
+inutili ritrasmissioni o cadere facilmente in timeout.
Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
-byte su un socket\index{socket} TCP, questi potranno essere spezzati dal
-protocollo in due segmenti (le unità di dati passate da TCP a IP vengono
-chiamate \textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
-sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
-i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
+byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
+segmenti (le unità di dati passate da TCP a IP vengono chiamate
+\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di sequenza
+$1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se i
+segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
più volte a causa di ritrasmissioni dovute alla perdita degli
\textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
scartare i duplicati.
Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
cioè specifica sempre all'altro capo della trasmissione quanti dati può
-ricevere tramite una \textit{advertised window} (letteralmente
-\textsl{finestra annunciata)}, che indica lo spazio disponibile nel buffer di
-ricezione, cosicché nella trasmissione non vengano inviati più dati di quelli
-che possono essere ricevuti.
+ricevere tramite una \itindex{advertised~window} \textit{advertised window}
+(letteralmente ``\textsl{finestra annunciata}''), che indica lo spazio
+disponibile nel buffer di ricezione, cosicché nella trasmissione non vengano
+inviati più dati di quelli che possono essere ricevuti.
Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
-socket\index{socket} ed aumentando con la lettura di quest'ultimo da parte
+socket ed aumentando con la lettura di quest'ultimo da parte
dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un ritmo che il
del controllo di flusso e della gestione della sequenzialità dei dati viene
effettuato per entrambe le direzioni di comunicazione.
+% TODO mettere riferimento alla appendice su TCP quando ci sarà
%% Una descrizione più accurata del protocollo è fornita in appendice
%% sez.~\ref{sec:tcp_protocol}.
\label{sec:net_lim_dim}
Un aspetto di cui bisogna tenere conto nella programmazione di rete, e che
-ritornerà anche più avanti, è che ci sono una serie di limiti a cui la
-trasmissione dei dati attraverso i vari livelli del protocollo deve
-sottostare, limiti che è opportuno tenere presente perché in certi casi si
-possono avere delle conseguenze sul comportamento delle applicazioni.
+ritornerà in seguito, quando tratteremo gli aspetti più avanzati, è che ci sono
+una serie di limiti a cui la trasmissione dei dati attraverso i vari livelli
+del protocollo deve sottostare; limiti che è opportuno tenere presente perché
+in certi casi si possono avere delle conseguenze sul comportamento delle
+applicazioni.
Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed
alle eventuali implicazioni che possono avere, è il seguente:
l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
campo apposito nell'header di IP che è lungo 16 bit (vedi
fig.~\ref{fig:IP_ipv4_head}).
-\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
+\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte;
il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
un pacchetto usando la \textit{jumbo payload option}.
-\item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
- dipende dal protocollo specifico usato al livello di connessione fisica. Il
- più comune è quello di ethernet che è pari a 1500 byte, una serie di altri
- valori possibili sono riportati in tab.~\ref{tab:net_mtu_values}.
+\item Molte reti fisiche hanno una MTU \itindex{Maximum~Transfer~Unit}
+ (\textit{Maximum Transfer Unit}) che dipende dal protocollo specifico usato
+ al livello di connessione fisica. Il più comune è quello di ethernet che è
+ pari a 1500 byte, una serie di altri valori possibili sono riportati in
+ tab.~\ref{tab:net_mtu_values}.
\end{itemize}
+\itindbeg{Maximum~Transfer~Unit}
Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
dimensioni eccedono la MTU viene eseguita la cosiddetta
\textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
X.25 & 576 \\
\hline
\end{tabular}
- \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di
- reti diverse.}
+ \caption{Valori della MTU (\textit{Maximum Transfer Unit}) per una serie di
+ diverse tecnologie di rete.}
\label{tab:net_mtu_values}
\end{table}
La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
- MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
+ MTU}, che dice qual è la lunghezza massima oltre la quale un pacchetto
inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
conto che non è affatto detto che la \textit{path MTU} sia la stessa in
entrambe le direzioni, perché l'instradamento può essere diverso nei due
Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
frammentano i pacchetti che ritrasmettono (anche se possono frammentare i
-pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una
-volta frammentati i pacchetti possono essere riassemblati solo alla
-destinazione.
+pacchetti che generano loro stessi), al contrario di quanto fanno i router
+IPv4. In ogni caso una volta frammentati i pacchetti possono essere
+riassemblati solo alla destinazione.
Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
pacchetto non deve essere frammentato; un router che riceva un pacchetto le
Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti
comporta inefficienza, normalmente viene utilizzato un procedimento, detto
\textit{path MTU discovery} che permette di determinare il \textit{path MTU}
-fra due stazioni; per la realizzazione del procedimento si usa il flag DF di
-IPv4 e il comportamento normale di IPv6 inviando delle opportune serie di
-pacchetti (per i dettagli vedere
+fra due stazioni; per la realizzazione del procedimento si usa il flag
+\texttt{DF} di IPv4 e il comportamento normale di IPv6 inviando delle
+opportune serie di pacchetti (per i dettagli vedere
l'\href{http://www.ietf.org/rfc/rfc1191.txt}{RFC~1191} per IPv4 e
l'\href{http://www.ietf.org/rfc/rfc1981.txt}{RFC~1981} per IPv6) fintanto che
non si hanno più errori.
potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
conoscere da subito il \textit{path MTU}.
-Infine TCP definisce una MSS \textit{Maximum Segment Size} che annuncia
-all'altro capo della connessione la dimensione massima dimensione del segmento
-di dati che può essere ricevuto, così da evitare la frammentazione. Di norma
-viene impostato alla dimensione della MTU dell'interfaccia meno la lunghezza
-delle intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
+Infine TCP definisce una \itindex{Maximum~Segment~Size} \textit{Maximum
+ Segment Size} (da qui in avanti abbreviata in MSS) che annuncia all'altro
+capo della connessione la dimensione massima dimensione del segmento di dati
+che può essere ricevuto, così da evitare la frammentazione. Di norma viene
+impostato alla dimensione della MTU dell'interfaccia meno la lunghezza delle
+intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
\const{TCP\_MSS} è 512.
+\itindend{Maximum~Transfer~Unit}
-%\subsection{Il passaggio dei dati in TCP}
-%\label{sec:net_tcp_pass}
-
-%\subsection{Il passaggio dei dati in UDP}
-%\label{sec:net_udp_pass}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+
+% LocalWords: TCP multitasking client ftp telnet ssh cap thread peer to three
+% LocalWords: Napster routing tier two middle International Standards Systems
+% LocalWords: Organization Interconnection tab Application Presentation All of
+% LocalWords: Session Transport DataLink Physical people seem need processing
+% LocalWords: fig upper layer lower kernel DoD Department Defense Connection
+% LocalWords: sez UDP ICMP IGMP device Trasmission Control Protocol l'IP l'UDP
+% LocalWords: IPv ethernet SMTP RFC Request For Comment socket stack PPP ARP
+% LocalWords: router instradatori version RARP l'autoconfigurazione anycast Di
+% LocalWords: l'acknoweledgment Datagram Message host ping ICPMv ICMPv Group
+% LocalWords: multicast Address Resolution broadcast Token FDDI MAC address DF
+% LocalWords: Reverse EGP Exterior Gateway gateway autonomous systems OSPF GRE
+% LocalWords: Shortest Path First Generic Encapsulation Authentication Header
+% LocalWords: IPSEC ESP Encapsulating Security Payload Point Line over raw QoS
+% LocalWords: dall' Universal addressing Best effort unicast header dell' RTT
+% LocalWords: datagram connectionless streaming nell' acknowlegment trip flow
+% LocalWords: segment control advertised window nell'header dell'header option
+% LocalWords: payload MTU Transfer Unit Hyperlink IBM Mbit sec IEEE path but
+% LocalWords: dell'MTU destination unreachable fragmentation needed packet too
+% LocalWords: big discovery MSS Size
projects / gapil.git / blobdiff