Εμβάθυνση και Ασκήσεις στο Επίπεδο Μεταφοράς και στο Επίπεδο Εφαρμογής Ιωάννης Κορίνθιος Δρ. Ηλεκτρολόγος Μηχανικός ΕΜΠ Σελ 1
Επίπεδο Μεταφοράς του Διαδικτύου Transmission Control Protocol (TCP) RFCs: 793, 1122, 1323, 2018, 2581 User Datagram Protocol (UDP) RFC: 768 σελ 2
Αξιόπιστη Μεταφορά Δεδομένων με το TCP Το TCP προσφέρει αξιόπιστη μεταφορά δεδομένων πάνω από το IP (που είναι αναξιόπιστο). Η υπηρεσία αυτή προσφέρεται στο επίπεδο εφαρμογής. Συγκεκριμένα φροντίζει για την αξιόπιστη μεταφορά της πληροφορίας μεταξύ απομακρυσμένων οντοτήτων του επιπέδου εφαρμογής (εφαρμογές) από-άκρη-σε-άκρη (δηλαδή μεταξύ απομακρυσμένων Host). Για να πετύχει το στόχο του υλοποιεί τρεις διακριτούς και αλληλοσυμπληρωμένους μηχανισμούς: Ο μηχανισμός Ελέγχου Λαθών υλοποιείται από αλγόριθμους που επιλύουν την απώλεια πακέτων και φροντίζει να μεταφερθεί όλο το περιεχόμενο σωστά από άκρη-σε-άκρη. Ο μηχανισμός Ελέγχου Ροής (Flow Control) υλοποιείται από αλγόριθμους που προλαμβάνουν την αποστολή πληροφορίας από την πηγή με μεγαλύτερο ρυθμό από αυτόν που μπορεί να παραληφθεί από τον προορισμό. Ο μηχανισμός Ελέγχου Συμφόρησης (Congestion Control) υλοποιείται από αλγόριθμους που υλοποιούνται στην πηγή και που προλαμβάνουν ή/και αντιμετωπίζουν την υπερφόρτωση του δικτύου Οι παραπάνω μηχανισμοί/αλγόριθμοι υλοποιούνται στην πηγή και δεν απασχολούν καθόλου το δίκτυο (IP). Ο προορισμός υλοποιεί απλώς ένα απαντητικό μηχανισμό που επιβεβαιώνει την παραλαβή του περιεχομένου, ενημερώνει την πηγή και ενδεχομένως (είναι προαιρετικό) τοποθετεί τα πακέτα (segments) στη σειρά. σελ 3
Αξιόπιστη Μεταφορά Δεδομένων με το TCP Για να πετύχει την αποστολή του το TCP εγκαθιστά κατ αρχήν μια λογική επικοινωνία απόάκρη-σε-άκρη (end-to-end) μεταξύ των απομακρυσμένων host. Για το λόγο αυτό λέμε ότι είναι ένα πρωτόκολλο που προσφέρει υπηρεσία με σύνδεση (Connection-oriented protocol). Όταν ολοκληρωθεί η μεταφορά του περιεχομένου τότε πρέπει να κλείσουν οι λογικές συνδέσεις. Η επικοινωνία είναι από-σημείο-σε-σημείο (point-to-point) και πλήρως αμφίδρομη (bidirectional). Δηλαδή υπάρχει μια πηγή/αποστολέας (source/sender) και ένας προορισμός/δέκτης (destination/receiver) και οι ρόλοι εναλλάσσονται ανά κατεύθυνση μετάδοσης. Το δίκτυο παρέχει τον μηχανισμό μεταφοράς των πακέτων μέσω του επιπέδου δικτύου (IP). Οι κόμβοι του δικτύου δεν ασχολούνται με την πληροφορία που ανταλλάσσεται στο επίπεδο μεταφοράς ή στο επίπεδο εφαρμογής μεταξύ των απομακρυσμένων hosts. Η πληροφορία αυτή είναι διάφανη (transparent) στους κόμβους του δικτύου και αξιοποιείται μόνο στα άκρα (απομακρυσμένοι hosts). σελ 4
Αξιόπιστη Μεταφορά Δεδομένων με το TCP Βασικές του λειτουργίες του TCP είναι επίσης: Αποστολή Λήψη Τεμαχίζει τα δεδομένα του επιπέδου εφαρμογής σε πακέτα πληροφορίας που στο TCP τα ονομάζουμε τεμάχια (Segment) εφόσον αυτό είναι αναγκαίο και τα διοχετεύει στο στρώμα δικτύου Πολυπλέκει (multiplexing) τα δεδομένα που προέρχονται από το στρώμα εφαρμογής (Διευθυνσιοδότηση) Συναρμολογεί τα τεμάχια και τα διοχετεύει στο επίπεδο εφαρμογής Αποπολυπλέκει (demultiplexing) τα δεδομένα, έτσι ώστε να τα παρέχει στο στρώμα εφαρμογής (Διευθυνσιοδότηση) σελ 5
Χαρακτηριστικά της Αξιόπιστης Μεταφοράς Δεδομένων με το TCP Το TCP αντιλαμβάνεται την ανταλλαγή δεδομένων σαν μια συνεχή ροή (stream) από bytes (και όχι μια συνεχή ροή από μηνύματα). Άρα, η αρίθμηση αναφέρεται επίσης σε bytes. To TCP αναλαμβάνει την αρίθμησή των bytes που στέλνει και τον έλεγχο της παραλαβή τους. Τα πακέτα του TCP (τεμάχια/segments) και έχουν ένα μέγιστο μήκος MSS (Maximum Segment Size) που εξαρτάται από το επίπεδο σύνδεσης δεδομένων. Για την επιβεβαίωση της σωστής παραλαβής εκδίδονται ACKnowledments από τον προορισμό προς την πηγή. Τα ACK μπορεί να είναι σωρευτικά (cumulative) δηλαδή μπορεί να επιβεβαιώνουν περισσότερα από ένα segment. Αναμεταδόσεις συμβαίνουν: Αν εκπνεύσει το Retransmission TimeOut (RTO) Αν παραληφθούν στην πηγή πολλαπλές ACK σελ 6
Sequence Numbers και Acknowledgments στο TCP Το TCP βλέπει την ανταλλαγή δεδομένων σαν μια ροή (ακολουθία) από bytes και όχι μια ροή από μηνύματα. Άρα, η αρίθμηση αναφέρεται επίσης σε bytes. Παράδειγμα Έστω ότι έχουμε ένα αρχείο 500,000 bytes και το Maximum Segment Size (MSS) είναι 1000 Byte. Το αρχείο θα χωριστεί σε 500 segments. Έστω για απλούστευση ότι το πρώτο byte αριθμείται με 0. Sequence numbers: O αύξων αριθμός του πρώτου byte από το segment που αποστέλλει η πηγή. Στο παράδειγμα το πρώτο segment θα πάρει τον sequence number 0 Το δεύτερο segment θα πάρει τον sequence number 1000 κλπ ώσπου να ολοκληρωθεί ο αριθμός των bytes προς αποστολή. Acknowledge numbers: Acknowledge Number είναι ο αύξων αριθμός του επόμενου byte από το τελευταίο byte του τελευταίου segment που παραλήφθηκε σε σωστή σειρά. Σηματοδοτεί το επόμενο byte που αναμένει να παραλάβει ο προορισμός. Άρα, αν στο παράδειγμα έχει παραληφθεί το 2ο segment, τότε το acknowledge number θα είναι το 2,000. Με βάση τη λογική αυτή το TCP παρέχει cumulative (σωρευτικές) acknowledgments. σελ 7
Χαρακτηριστικά της Αξιόπιστης Μεταφοράς Δεδομένων με το TCP Το TCP χρησιμοποιεί το Retransmission TimeOut (RTO) για να μπορέσει να επαναλάβει τη μετάδοση στις περιπτώσεις που κάποιο ACK δεν έχει παραληφθεί από την πηγή (είτε διότι χάθηκε το αρχικό μήνυμα προς τον προορισμό είτε διότι χάθηκε το ACK του μηνύματος αυτού). Το RTO πρέπει να είναι κατάλληλης διάρκειας για την κίνηση που αντιμετωπίζει το δίκτυο. Για το λόγο αυτό υπολογίζεται δυναμικά με βάση ένα σταθμισμένο κινούμενο μέσο όρο των στιγμιαίων RTT (Round Trip Time) καθώς και την απόκλιση αυτών από το μέσο όρο (η απόκλιση λειτουργεί σαν περιθώριο ασφάλειας). Το πολύ ένα μοναδικό RTO μπορεί είναι ενεργοποιημένο σε κάθε χρονική στιγμή! Θα περίμενε κανείς να υπάρχει ενεργοποιημένο ένα RTO για κάθε τεμάχιο (segment) που δεν έχει επιβεβαιωθεί με ACK. Αλλά αυτό δεν συμβαίνει για λόγους απλότητας της υλοποίησης. Το ενεργοποιημένο RTO κάθε χρονική στιγμή αφορά το παλαιότερο μη επιβεβαιωμένο segment. σελ 8
Ένας απλοποιημένης TCP Αποστολέας/Πηγή (simplified TCP Sender/Source) Για την καλύτερη κατανόηση θεωρούμε έναν απλοποιημένο TCP Αποστολέα επικεντρώνοντας στην αξιόπιστη μετάδοση (έλεγχος λαθών) Αγνοούμε την αναμετάδοση λόγω πολλαπλών ACK Αγνοούμε τον έλεγχο ροής (flow control) Αγνοούμε τον έλεγχο συμφόρησης (congestion control) O απλοποιημένος TCP αποστολέας αντιδρά κατά συνέπεια σε τρία διακριτά γεγονότα (events): Λήψη δεδομένων από την εφαρμογή Λήψη Επιβεβαίωσης (ACK) από τον προορισμό (TCP Receiver/Destination) Εκπνοή του Retransmission TimeΟut (RTO) σελ 9
Αντίδραση του απλοποιημένου TCP Αποστολέα (TCP Sender) στα Διακριτά Γεγονότα (Events) που παρατηρεί Λήψη δεδομένων από την εφαρμογή Δημιουργείται νέο segment με SeQuence Number (SQN) τον αριθμό του byte που αντιστοιχεί στο 1 ο byte του segment και το αποστέλλει στο δίκτυο. Έναρξη του RTO, εάν δεν έχει ήδη ενεργοποιηθεί Το RTO αντιστοιχεί στο παλαιότερο μη επιβεβαιωμένο segment. H διάρκεια του RTO έχει υπολογιστεί σύμφωνα με συγκεκριμένο αλγόριθμο. Εφόσον μόνο ένα μόνο RTO είναι ενεργοποιημένο σε μία χρονική στιγμή, αυτό σημαίνει ότι αν έχει ήδη ενεργοποιηθεί ένα RTO, δεν θα ενεργοποιηθούν περισσότερα. Λήψη Επιβεβαίωσης (ACK) από τον προορισμό (TCP Receiver/Destination) Εάν το συγκεκριμένο ACK επιβεβαιώνει segments που δεν έχουν επιβεβαιωθεί, τότε ενημερώνεται κατάλληλα η μεταβλητή που καθορίζει το παλαιότερο μη επιβεβαιωμένο segment Στην περίπτωση αυτή εάν υπάρχουν μη επιβεβαιωμένα segments ενεργοποιείται το RTO για το τελευταίο μη επιβεβαιωμένο segment. Αν δεν υπάρχουν μη επιβεβαιωμένα segments τότε προφανώς δεν ενεργοποιείται RTO. Εκπνοή του Retransmission Timeout (RTO) Στην περίπτωση αυτή αποστέλλεται ξανά το παλιότερο μη επιβεβαιωμένο segment για το οποίο συνέβηκε το timeout Ενεργοποιείται το RTO για το segment αυτό. σελ 10
Ψευδο-κώδικας του απλοποιημένου TCP Αποστολέα (simplified TCP Sender) NextSeqNum = InitialSeqNum / *Variable for Next Sequence Number in Bytes*/ SendBase = InitialSeqNum / *Variable for Last Acknowledged Sequence Number in Bytes*/ loop (forever) { switch(event) event: data received from application layer above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ σελ 11
Ένα παράδειγμα ανταλλαγής δεδομένων στο TCP Στο παράδειγμα (καθώς και στα επόμενα παραδείγματα) περιλαμβάνονται όλα τα κύρια πεδία ενός TCP μηνύματος. Υποθέτουμε ότι έχει ήδη εγκατασταθεί λογική σύνδεση από-άκρη-σε-άκρη και τυχόν προηγούμενα segment έχουν επιβεβαιωθεί και από τις δύο πλευρές. Η πλευρά Α στέλνει διαδοχικά στην πλευρά Β δύο segments. Ο DPN αντιστοιχεί σε Web server. Το πρώτο περιλαμβάνει 20 bytes και το δεύτερο 40 bytes. Έστω αρχίζει να μετράει από το Sequence Number 100. Έστω ότι ούτε το πρώτο ούτε το δεύτερο segment που αποστέλλονται επιβεβαιώνουν την λήψη bytes. Πρακτικά το ACK Flag έχει λάβει την τιμή 0, άρα το περιεχόμενο του ACKN αγνοείται (αυτό συμβολίζεται με αστερίσκο (wildcard *)). Μετά την αποστολή του 1 ου Segment, αρχικοποιείται ο RTO παίρνοντας την τιμή που προκύπτει από τον αλγόριθμο υπολογισμού (έστω RTO1). Ο RTO τίθεται πάντα για το παλαιότερο ανεπιβεβαίωτο segment που έχει αποσταλεί. Η πλευρά B (TCP Receiver) επιβεβαιώνει τα segment διαδοχικά στέλνοντας αντίστοιχες ACK. Όταν φτάσει η επιβεβαίωση (ACK) του 1 ου segment, σταματάει ο RTO1 και αρχικοποιείται ο RTO2 για το 2 ο segment (για το παλιότερο ανεπιβεβαίωτο segment που είναι το 2 ο ). Όταν φτάσει η επιβεβαίωση (ACK) του 2 ου segment, σταματάει και ο RTO2. Εφόσον δεν υπάρχουν ανεπιβεβαίωτα segment δεν ενεργοποιείται κάποιο RTO. Η επιβεβαίωση τόσο του πρώτου όσο και του δεύτερου segment φθάνει πριν την εκπνοή των αντίστοιχων RTO (δηλ. χωρίς Timeout). σελ 12
Ένα παράδειγμα στο TCP όπου χάνεται ένα ACK χωρίς να χρειαστεί retransmission Η πλευρά Α στέλνει διαδοχικά στην πλευρά Β δύο segmentς. Το πρώτο περιλαμβάνει 20 bytes και το δεύτερο 40 bytes. Έστω αρχίζει να μετράει από το Sequence Number 100. Μετά την αποστολή του 1 ου Segment, αρχικοποιείται ο RTO παίρνοντας την τιμή που προκύπτει από τον αλγόριθμο υπολογισμού (έστω RTO1). Η πλευρά B (TCP Receiver) επιβεβαιώνει τα segment διαδοχικά στέλνοντας αντίστοιχες ACK. Η πρώτη επιβεβαίωση (ACK) του 1 ου segment χάνεται και δεν φτάνει ποτέ. Η δεύτερη επιβεβαίωση (ACK) φτάνει πριν να λήξει ο RTO1. Εκλαμβάνεται σαν σωρευτική (cumulative) ACK. Εφόσον δεν υπάρχουν ανεπιβεβαίωτα segment δεν ενεργοποιείται κάποιο RTO. σελ 13
Ένα παράδειγμα στο TCP όπου χάθηκε το ACK και αυτό είχε σαν αποτέλεσμα εκπνοή του RTO και retransmission Η πλευρά Α στέλνει διαδοχικά στην πλευρά Β δύο segmentς. Το πρώτο περιλαμβάνει 20 bytes και το δεύτερο 40 bytes. Αρχίζει να μετράει από το Sequence Number 100. Μετά την αποστολή του 1 ου Segment, αρχικοποιείται ο RTO παίρνοντας την τιμή που προκύπτει από τον αλγόριθμο υπολογισμού (έστω RTO1). Η πλευρά B (TCP Receiver) επιβεβαιώνει τα segment διαδοχικά στέλνοντας αντίστοιχες ACK. Η πρώτη επιβεβαίωση (ACK) του 1 ου segment χάνεται και δεν φτάνει ποτέ. Λήγει το RTO1, αποστέλλεται ξανά το 1 ο segment και ενεργοποιείται ο RTO2 για το παλιότερο ανεπιβεβαίωτο segment που είναι το 1 ο. Η δεύτερη επιβεβαίωση (ΑCK), φτάνει (μετά τη λήξη του RTO1). Εφόσον επιβεβαιώνει σωρευτικά τόσο το 2 ο segment όσο και το 1 ο Segment, και δεν υπάρχει ανεπιβεβαίωτο segment ο timer σταματάει. Η νέα επιβεβαίωση τόσο του 1 ου όσο και του 2 ου segment όταν φθάσει δεν έχει κανένα αποτέλεσμα. σελ 14
Διάρκεια Retransmission TimeOut (RTO) στο TCP Η διάρκεια του χρονομέτρου αναμετάδοσης (Retransmission Timeout, RTO) είναι σημαντικός παράγοντας στη καλή λειτουργία TCP Αν είναι μικρή έχουμε πρόωρο timeout και κατά συνέπεια άσκοπες αναμεταδόσεις Αν είναι μεγάλη έχουμε καθυστερήσεις σε περιπτώσεις χαμένων segment Η βασική απαίτηση είναι το RTO να είναι μεγαλύτερο από το Round Trip Time (RTT) To RTT ορίζεται σαν ο χρόνος από τη στιγμή που ένα segment μεταδίδεται από την πηγή ως τη στιγμή που το αντίστοιχο ACK λαμβάνεται από πηγή Η στιγμιαία τιμή του RTT για ένα segment ονομάζεται SampleRTT και όπως είναι αναμένεται είναι διαφορετική για κάθε segment Η βασική απαίτηση είναι απλή αλλά το πρόβλημα είναι ότι η Στιγμιαία RTT (SampleRTT) μεταβάλλεται πολύ γρήγορα ανά segment (λόγω κατ αρχήν της λειτουργίας του επιπέδου δικτύου IP). Επειδή το SampleRTT μεταβάλλεται πολύ γρήγορα χρειάζεται μια εξομαλυμένη τιμή για το RTT σελ 15
Διάρκεια Retransmission TimeOut (RTO) στο TCP Η εκτιμώμενη τιμή του RTT (ΕstimatedRTT) και δίνεται από τον τύπο EstimatedRTT n+1 = (1 α ) EstimatedRTT n + α SampleRTT n+1 όπου α=1/8=0.125 (προτεινόμενη τιμή, RFC6298) Πρόκειται για ένα σταθμισμένο κινούμενο μέσο όρο των SampleRTT Υπολογίζεται η DevRTΤ, δηλαδή ένα μέτρο της απόκλισης του SampleRTT από την εκτιμώμενη τιμή DevRTT n+1 = (1 β) DevRTT n + β ( SampleRTT n+1 EstimatedRTT n+1 ) όπου β=1/4=0.250 (προτεινόμενη τιμή, RFC6298) Το RTO που είναι και το ζητούμενο υπολογίζεται ως εξής: RTO n+1 = EstimatedRTT n+1 + 4 DevRTT n+1 Αρχικές Συνθήκες RTO 0 = 1 sec (προτεινόμενη τιμή, RFC6298) Estimated RTT 1 = SampleRTT 1 DevRTT 1 = SampleRTT 1 / 2 RTO 1 = EstimatedRTT 1 + 4 DevRTT 1 Σχόλιο:Όταν συμβεί timeout, η τιμή του RTO διπλασιάζεται (εκθετική οπισθοχώρηση) παραμένοντας μικρότερη από 64 second σύμφωνα με τον τύπο: RTOn+1 = min (2 RTOn, 64) second σελ 16
Estimated RTT σε αντιστοιχία με την Sample RTT Η εκτιμώμενη τιμή του RTT (ΕstimatedRTT) είναι ένας σταθμισμένος κινούμενος μέσος όρος των Στιγμιαίων RTT (SampleRTT) σελ 17
Παράδειγμα Υπολογισμού Retransmission TimeOut (RTO) στο TCP Σε μετάδοση τριών segment μετρήθηκαν από τον αποστολέα τα εξής RTT: RTT 1 = 80 msec RTT 2 = 60 msec RTT 3 = 100 msec Υποθέτοντας ότι αυτά είναι τα πρώτα segment που αποστέλλονται, να υπολογιστούν τα RTO0, RTO1, RTO2 και RTO3, αν α= 0.125 και β=0.250 Ξέρουμε ότι RTO n = EstimatedRTT n + 4 DevRTT n Υπολογίζουμε πρώτα τα EstimatedRTT n Η εξίσωση είναι: EstimatedRTT n+1 = (1 α ) EstimatedRTT n + α SampleRTT n+1 EstimatedRTT 1 = SampleRTT 1 = 80 msec Αρχική Συνθήκη, στο πρώτο segment το EstimatedRTT και το SampleRTT συμπίπτουν. EstimatedRTT 2 = (1 0.125) EstimatedRTT 1 + α SampleRTT 2 = 0.875 80 + 0.125 60 = 77,5 msec EstimatedRTT 3 = (1 0.125) EstimatedRTT 2 + α SampleRTT 3 = 0.875 80 + 0.125 100 = 80,3125 msec σελ 18
Παράδειγμα Υπολογισμού Retransmission TimeOut (RTO) στο TCP Υπολογίζουμε στην συνέχεια τα DevRTT n DevRTT n+1 = (1 β) DevRTT n + β ( SampleRTT n+1 EstimatedRTT n+1 ) DevRTT 1 = SampleRTT 1 /2 = 40 msec Αρχική Συνθήκη, στο πρώτο segment το DevRTT υπολογίζεται ως το μισό του SampleRTT. DevRTT 2 = (1 0.250) 40+ β 60 77,5 =34,375 DevRTT 3 = (1 0.250) 34,375+ β 100 80,3125 =30,703125 Τέλος υπολογίζουμε τα RTO RTO n+1 = EstimatedRTT n+1 + 4 DevRTT n+1 RTO 0 = 1 sec = 1000 msec Αρχική Συνθήκη, στο πρώτο segment το RTO τίθεται από το σύστημα (προτεινόμενη τιμή 1 sec) RTO 1 = EstimatedRTT 1 + 4 DevRTT 1 =240 msec RTO 2 = EstimatedRTT 2 + 4 DevRTT 2 =215 msec RTO 3 = EstimatedRTT 3 + 4 DevRTT 3 =203,125 msec σελ 19
Έλεγχος Ροής (Flow Control) στο TCP Ο έλεγχος ροής αναφέρεται στον έλεγχο που εκτελείται από την πηγή, έτσι ώστε να μην στείλει τα δεδομένα υπερβολικά γρήγορα, σε σημείο που να προκαλέσει πρόβλημα υπερχείλισης (overflow) στον προορισμό (receiver). Στην ουσία με τον έλεγχο ροής επιτυγχάνουμε τόσο η πηγή όσο και ο προορισμός να ρυθμιστούν στην ίδια ροή. O προορισμός μπορεί έτσι να αναγκάσει την πηγή να στείλει σε ένα ρυθμό που να μπορεί να ανταπεξέλθει. Στον προορισμό (receiver) ορίζουμε τις παρακάτω μεταβλητές: RcvBuffer: το μέγεθος του Receive Buffer (bytes) που έχει δεσμεύσει η πλευρά του προορισμού για μια TCP σύνδεση, έτσι ώστε να αποθηκεύονται προσωρινά εκεί τα δεδομένα, ώσπου να τα διαβάσει η Διαδικασία Εφαρμογής (Application Process). rwnd: το μέγεθος του Receive Window (bytes) που απομένει για να χρησιμοποιήσει η πλευρά του προορισμού για να αποθηκεύσει προσωρινά δεδομένα. LastByteRead: ο αριθμός του τελευταίου byte δεδομένων που διαβάστηκε από την εφαρμογή στην πλευρά του προορισμού. LastByteRcvd: ο αριθμός του τελευταίου byte δεδομένων που έφτασε επιτυχώς από το δίκτυο στην πλευρά του προορισμού (LastByteRcvd LastByteRead). Receive Window (rwnd) rwnd = RcvBuffer [LastByteRcvd LastByteRead] σελ 20
Παράδειγμα Ελέγχου Ροής στο TCP Περιγραφή του προβλήματος Έστω Hosts A & B με μεταξύ τους αποκλειστική και κατευθείαν φυσική σύνδεση με χωρητικότητα 100Mbps. Επίσης, υπάρχει εγκατεστημένη μια TCP σύνδεση μεταξύ των δύο hosts. Ο Host A στέλνει στον Β ένα τεράστιο αρχείο πολλών GB και επίσης μπορεί να στείλει δεδομένα στον Host B με μέγιστη ταχύτητα 50 Mbps. O Host B μπορεί να διαβάσει από τον buffer του και να προωθήσει στην εφαρμογή με μέγιστη ταχύτητα 10 Mbps. Ζητείται Να περιγραφεί η διαδικασία ελέγχου ροής για την συγκεκριμένη περίπτωση. Η διαφορά στη μέγιστη ταχύτητα αποστολής και λήψης δεδομένων τι αποτέλεσμα έχει? Τελικά με ποια μέση ταχύτητα θα αποστέλλει δεδομένα ο Host A στον Β? Θα βελτιωθεί η μέση ταχύτητα αν μεγαλώσει η χωρητικότητα του buffer στον Host B? Αναμένεται κάποιο πρόβλημα με τη χωρητικότητα του φυσικού μέσου? σελ 21
Προτεινόμενη λύση του προβλήματος Επίλυση Παραδείγματος Ελέγχου Ροής Ο Host A μπορεί να στείλει δεδομένα γρηγορότερα (50 Mbps) από ότι ο Host B μπορεί να διαβάσει (10 Mbps). Άρα, ο buffer στον Host B γεμίζει με ταχύτητα 40 Mbps. Εφόσον το αρχείο είναι τεράστιο σε μικρό χρόνο ο buffer του προορισμού θα γεμίσει εντελώς. Άρα, το Receive Window (rwnd) πολύ γρήγορα θα μηδενιστεί. Αυτό θα επικοινωνηθεί στον Host Α, ο οποίος θα αναγκαστεί να σταματήσει την αποστολή δεδομένων. Θα περιμένει τον Host B να προωθήσει τα segments στην εφαρμογή και να αδειάσει μέρος του buffer του. Εφόσον το αρχείο είναι αρκετά μεγάλο η επικοινωνία θα γίνει με τον μέγιστο ρυθμό που επιτρέπει ο περισσότερο αργός κρίκος στην αλυσίδα της επικοινωνίας. Άρα, στην περίπτωσή μας θα επιτύχουμε τελικά μέσο ρυθμό 10 Mbps. Εφόσον το αρχείο είναι αρκετά μεγάλο η χωρητικότητα του Buffer θα εξαντληθεί σύντομα ακόμα και αν γίνει μεγαλύτερος. Επειδή το αρχείο είναι αρκετά μεγάλο αν μεγαλώσει η χωρητικότητα του buffer δεν θα υπάρχει επίπτωση στην μέση ταχύτητα που πάλι θα είναι 10 Mbps. Κανένα πρόβλημα δεν αναμένεται με την χωρητικότητα του φυσικού μέσου διότι είναι πολύ μεγαλύτερη από τον μέσο ρυθμό που μπορούν να υποστηρίξουν τόσο ο Host A όσο και ο Host B. Αυτό φυσικά ισχύει εφόσον η φυσική σύνδεση είναι αποκλειστική και κατευθείαν. Σχόλιο Το παραπάνω πρόβλημα είναι ενδεικτικό της ανάγκης για έλεγχο ροής! σελ 22
Έλεγχος Συμφόρησης στο TCP Το TCP υλοποιεί ένα μηχανισμό έλεγχου συμφόρησης από-άκρη-σε-άκρη. Αυτό είναι αναμενόμενο διότι: ένας μηχανισμός ελέγχου συμφόρησης είναι απαραίτητος στο Διαδίκτυο το IP δεν διαθέτει τέτοιο μηχανισμό και βασίζεται σε λογική best effort το TCP λειτουργεί από-άκρη-σε-άκρη Ο μηχανισμός ελέγχου συμφόρησης του TCP Υλοποιείται στην πηγή Βασίζεται στην ανάδραση και στο μέγεθος ενός παραθύρου συμφόρησης μέσα στα πλαίσια του οποίου επιτρέπεται η αποστολή segment χωρίς τη λήψη επιβεβαίωσης (ACK). Οι πηγές προσπαθούν να ανακαλύψουν τη διαθέσιμη χωρητικότητα του δικτύου Το TCP αποστέλλει segments και αντιδρά στα γεγονότα που παρατηρούνται σελ 23
Παράδειγμα Ελέγχου Συμφόρησης στο TCP Περιγραφή του προβλήματος Έστω Hosts A & B που έχουν εγκαταστημένη σύνδεση TCP. O Host A στέλνει στο Host B ένα αρχείο 100 kbyte. Ta segment έχουν MSS (Maximum Segment Size) 1000 byte. Το μέσο RTT είναι 100 msec. Υποθέτουμε ότι βρισκόμαστε σε αργή αρχή (slow start) σε όλη τη διάρκεια αποστολής του αρχείου. Επίσης, υποθέτουμε ότι δεν γίνονται λάθη στη μετάδοση. Ζητείται Πόσο χρόνο θα χρειαστεί για να μεταδοθεί (επιβεβαιωμένα) όλο το αρχείο? Τι ρυθμό (Mbps) θα επιτύχουμε, αν υποθέσουμε ότι οι Host A & B αλλά και το δίκτυο έχουν τους διαθέσιμους πόρους και μπορούν χωρίς πρόβλημα να υποστηρίξουν τους ρυθμούς που απαιτούνται σε όλη τη διάρκεια της επικοινωνίας αυτής. σελ 24
Επίλυση Παραδείγματος Ελέγχου Συμφόρηση Προτεινόμενη λύση του προβλήματος Πρώτα πρέπει να βρούμε τον αριθμό των segments που θα αποσταλούν. Εφόσον έχουμε 100 Kbyte αρχείο, θα πρέπει αυτό να κομματιαστεί σε 100 Segment το καθένα από τα οποία θα έχει μήκος 1000 byte=1 Kbyte (=MSS). H slow start πρακτικά σημαίνει ότι σε κάθε RTT ο αριθμός των segment που μπορούν να σταλούν επιβεβαιωμένα διπλασιάζεται (αρχίζοντας από το 1). Άρα, για να στείλουμε 100 segments χρειάζεται χρόνος 7 RTTs (διότι 1+2+4+8+16+32+64=127>100) υποθέτοντας ότι για να βεβαιωθούμε ότι έφτασαν τα δεδομένα πρέπει η πηγή να περιμένει και τα αντίστοιχα ACK. Δηλαδή απαιτείται χρόνος 7*100=700 msec. Εφόσον σε 700msec=0,7sec μεταφέρθηκαν 100kByte=800kbits, πετύχαμε ταχύτητα 800/0,7=1141,86 kbps=1,14186 Mbps Σχόλιο Το παραπάνω πρόβλημα είναι ενδεικτικό του τι ακριβώς συμβαίνει και τι ρυθμούς μπορούμε να επιτύχουμε κατά τη μεταφορά σχετικά μικρών αρχείων μέσω TCP! σελ 25
Μερικές Ερωτήσεις στο TCP Q1: Στο TCP ο προορισμός/δέκτης (TCP receiver) αναδιατάσσει τα μηνύματα (segments) που έχουν φτάσει με λανθασμένη σειρά και πως? Α1: Όχι απαραίτητα, δεν προβλέπεται από τις προδιαγραφές και άρα επαφίεται στην συγκεκριμένη υλοποίηση. Αν δεν υποστηρίζεται η αναδιάταξη από την υλοποίηση τότε τα εκτός σειράς segment απορρίπτονται και δεν επιβεβαιώνονται. Q2: Τι είναι δικτυακή συμφόρηση? Τι είναι ο έλεγχος Συμφόρησης? Τι κατηγορίες ελέγχων συμφόρησης μπορεί να υπάρχουν στα δίκτυα? Σε ποια κατηγορία ανήκει ο έλεγχος συμφόρησης του TCP και ποια είναι η βασική ιδέα που υλοποιεί? Α2: Συμφόρηση είναι κατάσταση κατά την οποία η χωρητικότητα του δικτύου αδυνατεί να εξυπηρετήσει την προσφερόμενη κίνηση με αποτέλεσμα «χαμένα» πακέτα. Ο έλεγχος συμφόρησης στόχο έχει να προλαμβάνει ή/και να αντιμετωπίζει την υπερφόρτωση του δικτύου. Υπάρχουν δύο μεγάλες κατηγορίες ελέγχων συμφόρησης Έλεγχος Συμφόρησης από Άκρη-σε-άκρη (End-to-end Congestion Control) Δικτυακά Υποβοηθούμενος Έλεγχος Συμφόρησης (Network-Assisted Congestion Control) Το TCP πραγματοποιεί έλεγχο συμφόρησης από άκρη-σε-άκρη. Η βασική ιδέα είναι ότι η πηγή αποστέλλει segments και παρατηρεί τα γεγονότα (ACKs, RTOs) που συμβαίνουν ρυθμίζοντας παράλληλα το ρυθμό με τον οποίο στέλνει με στόχο να μην παρατηρηθεί συμφόρηση. σελ 26
Επίπεδο Εφαρμογής του Διαδικτύου σελ 27
Αρχιτεκτονικές Δικτυακών Εφαρμογών Αρχιτεκτονική Πελάτη-Εξυπηρετητή (Client-server): Υπάρχει ένας Host, που ονομάζεται εξυπηρετητής (Server) και που εξυπηρετεί αιτήσεις προερχόμενες από πολλούς άλλους Hosts, που ονομάζονται πελάτες (Clients). Παράδειγμα: Web client/web server, ftp client/ ftp server Αρχιτεκτονική Peer-to-peer (P2P): Yπάρχει άμεση επικοινωνία μεταξύ ζευγών περιστασιακά συνδεομένων μεταξύ τους Hosts, που ονομάζονται ομότιμοι (peers). Παράδειγμα: Bittorrent/Gnutella Υβριδική Αρχιτεκτονική: Συνδυάζει στοιχεία από τις δύο παραπάνω αρχιτεκτονικές. Παράδειγμα: Skype σελ 28
Διευθυνσιοδότηση Διεργασιών (Παράδειγμα) Η χρήση των Αριθμών Θύρας Πηγής και Προορισμού στην περίπτωση που δύο clients από δύο διαφορετικούς host προσπαθούν να προσπελάσουν ένα Web server αναδεικνύεται στο συγκεκριμένο παράδειγμα. O Host C έχει συγχρόνως επικοινωνία με τον ίδιο Server B από δύο ανεξάρτητες διεργασίες. O Host A έχει πρόσβαση στο Server B από μια διεργασία. Έχουμε επικεντρώσει στη μια κατεύθυνση και παρατηρούμε ότι η Θύρα Προορισμού σε όλες τις περιπτώσεις είναι η ίδια εφόσον μιλάμε για web service (Θύρα 80). Ο συνδυασμός Διεύθυνση IP (Πηγής/Προορισμού) και Θύρα (Πηγής/Προορισμού) είναι η τετραπλέτα της διευθυνσιοδότησης που οδηγεί σε μοναδικότητα της επικοινωνίας στο TCP. Ο Εξυπηρετητής (Server) έχει ενεργοποιήσει μια διεργασία (process) για κάθε πελάτη (client). σελ 29
Μερικές Ερωτήσεις στο Επίπεδο Εφαρμογής Q1: To Επίπεδο Εφαρμογής χρησιμοποιεί τις υπηρεσίες του Επιπέδου Μεταφοράς. Πότε το επίπεδο εφαρμογής χρησιμοποιεί τις υπηρεσίες του TCP και πότε του UDP? Να εξηγηθεί και να δοθούν παραδείγματα πρωτοκόλλων εφαρμογής που χρησιμοποιούν TCP ή UDP. A1: To επίπεδο εφαρμογής αποφασίζει τι είδους υπηρεσία χρειάζεται από το επίπεδο μεταφοράς. Αν χρειάζεται μια αξιόπιστη υπηρεσία με σύνδεση τότε χρησιμοποιεί το TCP. Αν χρειάζεται μια αναξιόπιστη αλλά ταχύτατη υπηρεσία τότε χρησιμοποιεί το UDP. Δυνητικά το επίπεδο εφαρμογής έχει τη δυνατότητα να χρησιμοποιήσει και τις δύο υπηρεσίες. Με δεδομένο ότι το επίπεδο δικτύου είναι αναξιόπιστο οι περισσότερες εφαρμογές χρησιμοποιούν το TCP που είναι δημοφιλέστατο. To http, το ftp και πολλά άλλα πρωτόκολλα επιπέδου εφαρμογής χρησιμοποιούν το TCP. To DNS και η ιντερνετική τηλεφωνία (π.χ. Skype) χρησιμοποιούν το UDP. σελ 30
Μερικές Ερωτήσεις στο Επίπεδο Εφαρμογής Q2: Υπάρχουν δύο τρόποι λειτουργίας του HTTP. Να αναφερθούν και να περιγραφούν. Ποιος είναι ο δημοφιλέστερος (default) τρόπος λειτουργίας? Α2: Oι δύο τρόποι λειτουργίας σχετίζονται με το αν το HTTP χρησιμοποιεί μια TCP σύνδεση για να μεταφέρει περισσότερες από μια HTTP requests/responses. Έτσι έχουμε, Το HTTP με μη επίμονη TCP σύνδεση (non-persistent connection). Στην περίπτωση αυτή μετά από κάθε http request & το αντίστοιχο http reply που περιέχει ένα αντικείμενο (object) ηtcp σύνδεση κλείνει. Το HTTP με επίμονη TCP σύνδεση (persistent connection ή keep alive). Στην περίπτωση αυτή πολλαπλά http request & τα αντίστοιχα http responses που το καθένα από αυτά περιέχει ένα ξεωριστό αντικείμενο (object) μπορούν να ανταλλαγούν πριν ηtcp σύνδεση κλείσει. Υπάρχουν δύο υποπεριπτώσεις: HTTP χωρίς συνεχή παροχή (no pipelining) Στην περίπτωση αυτή νέα HTTP requests στέλνονται μόνο αφού έχει παραληφθεί το προηγούμενο HTTP response HTTP με συνεχή παροχή (pipelining) Στην περίπτωση αυτή τα HTTP requests μπορούν να αποστέλλονται συνεχώς χωρίς απαραίτητα να έχουν παραληφθεί τα προηγούμενα HTTP responses. Το HTTP με επίμονη TCP σύνδεση και με συνεχή παροχή είναι το δημοφιλέστερο. σελ 31
Ευχαριστώ! σελ 32