mikrostosTCP

Wykład Mikrosystemy Elektroniczne
1
Mikrostos TCP/IP
1. Wstęp
Wykład dotyczący minimalnej implementacji stosu TCP/IP (mikrostos TCP/IP) powstał na
podstawie rozdziału 2 pracy dyplomowej dyplomanta Dariusza Załęskiego pt.: Opracowanie i
realizacja mikroserwera TCP/IP opartego na układach AT89S53 i CS8900A.
Zawarto w nim podstawowe informacje na temat sieci Ethernet oraz protokołów sieciowych
wykorzystywanych przez mikroserwer. Opisano również zaimplementowane protokoły warstwy
aplikacji, tj. własny protokół oraz protokół wykorzystywany w usłudze wysyłania wiadomości
e-mail SMTP.
Ethernet jest obecnie najszerzej na świecie wykorzystywaną technologią lokalnych sieci
komputerowych (ang. LAN Local Area Network). Standard Ethernet dla sieci pracującej z
prędkością 10 Mb/s opublikowało w roku 1980 konsorcjum DEC-Intel-Xerox (DIX). Wtedy też
organizacja IEEE rozpoczęła prace zmierzające do opracowania własnego standardu, bazującego
na specyfikacji sieci lokalnej podanej przez DIX. W roku 1985 po raz pierwszy opublikowano
standard IEEE 802.3 Ethernet o pełnej nazwie Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical Layer Specifications.
Do tej chwili powstało wiele rozszerzeń standardu IEEE 802.3, wprowadzających
komunikację z dużo większymi przepływnościami, aż do 1000 Mb/s (IEEE 802.3z). W dalszej
części omówiono transmisję danych z prędkością do 10 Mb/s w nieekranowanej skrętce
miedzianej (ang. Unshielded Twisted Pair - UTP), którego warstwę fizyczną opisuje standard
IEEE 802.3i (10BaseT), wydany w 1990 roku.
2. Warstwa fizyczna
Warstwa fizyczna jest najniższą warstwą sieci Ethernet. Definiuje ona typ okablowania,
zastosowanych złącz oraz określa sposób kodowania informacji i poziomy sygnałów
elektrycznych.
Mikroserwer pracuje w standardzie sieci 10BaseT, która charakteryzuje się następującymi
parametrami:
topologia gwiazdy,
jako medium transmisyjne wykorzystywana jest skręcona nieekranowana para
przewodów miedzianych skrętka (UTP) o impedancji 100 &!. Stosuje się skrętkę co
najmniej 4-tej kategorii o maksymalnym paśmie przenoszenia 20 MHz,
złącza typu RJ45, przy czym kable zakończone są wtykami, gniazda zaś posiadają
urządzenia sieciowe np. router y, karty sieciowe, hub y, switch e,
maksymalna odległość pomiędzy dwoma urządzeniami sieciowymi wynosi 100 m,
maksymalna prędkość transmisji dochodzi do 10 Mb/s,
transmisja różnicowa dwiema parami przewodów,
kodowanie Manchester.
Na poniższym rysunku 1 przedstawiono zasadę pracy kodera Manchester oraz typowy
poziom sygnału w sieci Ethernet 10BaseT.
Wykład Mikrosystemy Elektroniczne
2
0 0 1 1 0 1 0 0 1
+2,5V
0
-2,5V
Rys. 1. Kod Manchester.
2.1. Ramka sieci Ethernet, adres MAC
W sieci Ethernet wszystkie urządzenia posiadają unikalne (niepowtarzalne) fizyczne adresy
48-bitowe, zapisywane szesnastkowo w postaci 6 bajtów, oddzielonych dwukropkami lub
myślnikami. Są to tzw. adresy MAC (ang. Media Access Code). Każdy producent komputerowej
karty sieciowej lub niezależnego urządzenia sieciowego nadaje mu adres należący do przyznanej
danemu producentowi puli adresów. Przykładowe adresy MAC mają postać:
00-00-1F-15-AA-C8
00-E0-7D-00-68-58
Dodatkowo zdefiniowany jest tzw. rozgłoszeniowy adres MAC. Wysłanie ramki Ethernet do
odbiorcy z tym adresem powoduje, iż odbiorą ją wszystkie komputery działające w danym
segmencie sieci. Adres rozgłoszeniowy składa się z 48 bitów o wartości 1 , czyli 6 bajtów o
wartości 255:
FF-FF-FF-FF-FF-FF
Wszystkie 16- i 32-bitowe liczby w protokołach sieciowych zapisywane są w konwencji
Big-Endian, tzn. najstarszy bajt pierwszy. Dane zaś przesyłane są w pakietach o długości od 72
do 1526 bajtów. Rysunek 2 przedstawia wygląd ramki ethernetowej (ang. frame) w standardzie
Ethernet II.
Rys. 2. Ramka sieci Ethernet.
Na początku wysyłana jest preambuła (ang. preamble) stały ciąg siedmiu zer i jedynek
naprzemiennie (1010101) mający na celu zsynchronizowanie odbiornika umieszczonego w
Wykład Mikrosystemy Elektroniczne
3
zdalnym urządzeniu sieciowym z nadajnikiem, a następnie jeden bajt o wartości 10101011,
wskazujący na początek ramki SFD (ang. Start-of-Frame Delimiter). Tuż po SFD przesyłane są
adresy MAC odbiorcy (ang. Destination Address DA) i nadawcy ramki (ang. Source Address
SA), każdy po 6 bajtów, pole (LLC data) zawierające typ protokołu wyższej warstwy lub długość
danych oraz blok danych o długości maksimum 1500 bajtów (ang. Logical Link Control LLC),
zakończony 32-bitową sumą kontrolną (ang. Frame Check Sequence FCS).
Minimalna długość ramki Ethernet to 64 bajty. W przypadku, gdy pole danych jest mniejsze
od 46 bajtów istnieje potrzeba jego wydłużenia, tak by cała ramka miała długość 64 bajtów.
Wówczas na końcu pola danych zostaje dodane pole PAD wypełnione odpowiednią liczbą zer.
Interpretacja wspomnianego wyżej 16-bitowego pola długość/typ (na rys. Length Field)
zależy od jego wartości. Jeżeli zawiera się w nim liczba mniejsza lub równa maksymalnemu
rozmiarowi pola danych (1500 bajtów), określa ono długość pola danych. Było to
wykorzystywane w starszych protokołach rodziny IEEE 802.2. Jeżeli natomiast to pole ma
wartość większą niż 1500, jest ona interpretowana jako identyfikator protokołu wyższej warstwy,
zawartego (zagnieżdżonego) w polu danych. Przykładowo liczba 0x0806 (dziesiętnie 2054)
jednoznacznie identyfikuje protokół ARP, a liczba 0x0800 (dziesiętnie 2048) protokół IP. Taka
budowa ramki sieci Ethernet określona jest jako standard Ethernet II.
Na rysunku 3 przedstawiono przykład ramki Ethernet niosącej wiadomość ARP. Pole PAD
zostało dodane aby spełniony był warunek minimalnej długości ramki równej 64 bajty.
typ/długość LLC data
DA SA 0x0806 ARP message PAD FCS
Rys. 2.3. Wiadomość ARP osadzona w ramce Ethernet II.
3. Protokoły sieciowe
3.1. Protokół ARP
ARP (Address Resolution Protocol) jest protokołem najniższej warstwy modelu ISO/OSI
warstwy fizycznej. Jego zadaniem jest mapowanie adresu logicznego IP na adres fizyczny MAC.
Komputer chcący wysłać datagram IP zna jedynie adres IP odbiorcy. Natomiast w sieci Ethernet
wszystkie przesyłane ramki powinny być opatrzone adresem MAC docelowego urządzenia
sieciowego (pole DA). Protokół ARP definiuje sposoby wyszukiwania i konwersji 32-bitowych
adresów IP na adresy wymagane przez warstwę dostępu do medium w przypadku sieci Ethernet
będą to 48-bitowe adresy MAC.
Protokół ARP zakłada dynamiczne pozyskiwanie informacji o poszukiwanym adresie MAC.
W tym celu w sieci Ethernet rozgłaszane są ramki o określonej strukturze, zawierającej m.in.
adresy MAC i IP nadawcy oraz adres IP poszukiwanego urządzenia. Urządzenie, które rozpozna
swój adres IP, odsyła do nadawcy odpowiedz, zawierającą również jego adres MAC.
Wykład Mikrosystemy Elektroniczne
4
W celu uzyskania odpowiedzi, komputer wysyła pakiet ARP stanowiący zapytanie (ang. ARP
Request), pozostawiając wyzerowane pole adresu sprzętowego stacji poszukiwanej. Ramka
Ethernet zawierająca pakiet ARP jest rozgłaszana do wszystkich odbiorców w sieci lokalnej
poprzez podanie adresu MAC odbiorcy równego FF-FF-FF-FF-FF-FF.
Urządzenie, które rozpozna swój adres IP, odsyła do nadawcy pakiet ARP z odpowiedzią
(ang. ARP Reply). W tym celu zamienia blok adresów nadawcy i odbiorcy, wypełniając
dodatkowo swój adres MAC. Odpowiedz ARP jest kierowana bezpośrednio do nadawcy.
Mechanizm pozyskiwania adresów sprzętowych oparty na protokole ARP jest prosty i
wydajny. W celu zmniejszenia ilości wysyłanych zapytań ARP, każdy komputer dysponuje
tablicą przypisań, odwzorowującą adresy IP na adresy MAC urządzeń, do których się ostatnio
odwoływał. W celu zapobieżenia nieskończonemu przyrostowi ilości magazynowanych adresów,
są one usuwane z tablicy, jeżeli nie były przez pewien czas potrzebne.
Dla przykładu - jeśli komputer A o adresie sprzętowym MAC 00-00-1F-15-AA-C8 i
adresie IP 192.168.0.5 chce nawiązać połączenie z komputerem B o adresie IP 192.168.0.8, i nie
zna adresu MAC komputera B, to wysyła ramkę zapytania ARP, której postać przedstawia
tabela 1. Zacieniowane wiersze stanowią nagłówek ramki Ethernet II, pozostałe tworzą pakiet
ARP.
Z kolei komputer B, o ile jest aktywny, natychmiast odsyła odpowiedz ARP zawierającą jego
adres MAC 00-0C-76-8A-11-DE. Postać odpowiedzi ARP przedstawia tabela 2.
Tab. 1. Postać ramki zapytania ARP.
długość pola opis zawartość
6 bajtów adres MAC odbiorcy (DA) FF-FF-FF-FF-FF-FF
6 bajtów adres MAC nadawcy (SA) 00-00-1F-15-AA-C8
2 bajty typ/długość 0x0806 ARP
2 bajty protokół sprzętowy 0x0001 Ethernet
2 bajty protokół logiczny 0x0800 IP
1 bajt długość adresu fizycznego (MAC) 0x06 6 bajtów
1 bajt długość adresu logicznego (IP) 0x04 4 bajty
2 bajty kod operacji 0x0001 zapytanie ARP
6 bajtów adres sprzętowy (MAC) nadawcy 00-00-1F-15-AA-C8
4 bajty adres logiczny (IP) nadawcy C0-A8-00-05 - 192.168.0.5
6 bajtów adres sprzętowy (MAC) odbiorcy 00-00-00-00-00-00
4 bajty adres logiczny (IP) odbiorcy C0-A8-00-08 - 192.168.0.8
Tab. 2. Postać ramki odpowiedzi ARP.
długość pola opis zawartość
6 bajtów adres MAC odbiorcy (DA) 00-00-1F-15-AA-C8
6 bajtów adres MAC nadawcy (SA) 00-0C-76-8A-11-DE
2 bajty typ/długość 0x0806 ARP
2 bajty protokół sprzętowy 0x0001 Ethernet
2 bajty protokół logiczny 0x0800 IP
1 bajt długość adresu fizycznego (MAC) 0x06 6 bajtów
1 bajt długość adresu logicznego (IP) 0x04 4 bajty
2 bajty kod operacji 0x0002 odpowiedz ARP
Wykład Mikrosystemy Elektroniczne
5
6 bajtów adres sprzętowy (MAC) nadawcy 00-0C-76-8A-11-DE
4 bajty adres logiczny (IP) nadawcy C0-A8-00-08 - 192.168.0.8
6 bajtów adres sprzętowy (MAC) odbiorcy 00-00-1F-15-AA-C8
4 bajty adres logiczny (IP) odbiorcy C0-A8-00-05 - 192.168.0.5
W mikroserwerze zaimplementowano pełny protokół ARP, tj. mikroserwer ma możliwość
wysyłania odpowiedzi ARP (jako serwer) jak i wysyłania zapytań ARP (jako klient).
3.2. Stos protokołów TCP/IP
W latach 1973-78 Agencja DARPA i Stanford University opracowały dwa wzajemnie
uzupełniające się protokoły: połączeniowy TCP (Transmision Control Protocol) i
bezpołączeniowy IP (Internet Protocol). Protokoły te służą do łączenia oddzielnych fizycznie
sieci w jedną sieć logiczną. Wykorzystywane są w sieciach lokalnych i rozległych.
Najistotniejsze zalety protokołów TCP/IP:
otwartość i niezależność od specyfikacji sprzętowo-programowej systemów
komputerowych,
możliwość integracji wielu różnych rodzajów sieci komputerowych,
wspólny schemat adresacji pozwalający na jednoznaczne zaadresowanie każdego
użytkownika w sieci,
istnienie standardowych protokołów warstw wyższych.
Współcześnie protokoły TCP/IP to zestaw (stos) wielu protokołów przeznaczonych do:
transferu danych: IP, TCP, UDP (User Datagram Protocol),
kontroli poprawności połączeń: ICMP (Internet Control Message Protocol),
zarządzania siecią: SNMP (Simple Network Management Protocol),
zdalnego logowania się do sieci: TELNET,
usług aplikacyjnych, np. przesyłanie plików: FTP (File Transfer Protocol),
Architektura protokołów TCP/IP jest czterowarstwowa w odróżnieniu od siedmio-
warstwowej architektury ISO/OSI. Obie architektury przedstawia tabela 3.
Tab. 3. Warstwowy model ISO/OSI i TCP/IP.
ISO/OSI TCP/IP
warstwa aplikacji
warstwa prezentacji warstwa aplikacji
warstwa sesji
warstwa transportowa warstwa transportowa
warstwa sieciowe warstwa Internetu
warstwa łącza danych
warstwa dostępu do sieci
warstwa fizyczna (sprzętowa)
Jak w każdym modelu warstwowym, dane generowane przez programy aplikacyjne są
przekazywane w dół stosu, kiedy mają być wysłane przez sieć i w górę stosu przy odbiorze.
Każda warstwa stosu dodaje do danych przekazywanych z warstwy wyższej informacje sterujące
w postaci nagłówków. Nagłówek dodany w warstwie wyższej jest traktowany jako dane w
Wykład Mikrosystemy Elektroniczne
6
warstwie niższej (tzw. enkapsulacja). Nazewnictwo struktur danych w zależności od
wykorzystywanego protokołu transportowego przedstawia tabela 4.
Tab. 4. Nazewnictwo jednostki danych w zależności od warstwy.
TCP UDP
warstwa aplikacji strumień (ang. stream) wiadomość (ang. message)
warstwa transportowa segment pakiet
warstwa Internet datagram datagram
warstwa dostępu do sieci ramka (ang. frame) ramka (ang. frame)
Zadania poszczególnych warstw są następujące:
warstwa dostępu do sieci
Najniższa w hierarchii architektury protokołów TCP/IP. Jej funkcje odpowiadają w przybliżeniu
funkcjom trzech najniższych warstw modelu ISO/OSI. Do komunikacji w sieciach rozległych lub
przez łącza szeregowe wykorzystuje m.in. takie protokoły jak: X.25 (w sieciach pakietowych),
PPP (Point-to-Point Protocol) lub SLIP (Serial Line IP).
warstwa Internet
Podstawowym protokołem tej warstwy jest IP, który jest odpowiedzialny za przesyłanie pakietów
zwanych datagramami między użytkownikami sieci. Jest to protokół bezpołączeniowy, co
oznacza, że datagramy są przesyłane przez sieć bez kontroli poprawności ich dostarczenia. W
efekcie datagram może zostać zgubiony w sieci, przekłamany lub zniekształcony.
Drugim protokołem tej warstwy jest ICMP ściśle związany z IP. Służy on do przesyłania
komunikatów o nieprawidłowościach w pracy sieci. Protokół pozwala na przesyłanie wiadomości
sterujących między węzłami sieci. Wiadomości te dotyczą sterowania przepływem, testowania
połączeń, wskazania alternatywnych połączeń i wykrywania niedostępnych użytkowników.
warstwa transportowa
Zapewnia bezpośrednie połączenie między końcowymi użytkownikami (systemami)
wymieniającymi informacje. Najważniejsze protokoły tej warstwy to TCP oraz UDP.
Protokół TCP jest protokołem połączeniowym umożliwiającym wykrywanie błędów na obu
końcach połączenia. Ma on możliwość ustanowienia i utrzymania połączenia wirtualnego między
dwoma użytkownikami w celu przesyłania danych, sterowania przepływem, przesyłania
potwierdzeń oraz kontroli i korekcji błędów. Protokół UDP jest protokołem bezpołączeniowym,
nie posiada mechanizmów sprawdzania poprawności dostarczenia danych do miejsca
przeznaczenia. Segmenty TCP jak i pakiety UDP w celu ich dalszego przesłania są umieszczane
wewnątrz datagramu IP.
warstwa aplikacji
Protokoły tej warstwy dostarczają użytkownikom różnych usług wykorzystując jako protokołów
transportowych TCP lub UDP.
Najbardziej znane protokoły warstwy aplikacji korzystające z TCP to:
TELNET umożliwia zdalne łączenie z systemem,
FTP - przesyłanie plików przez sieć,
Wykład Mikrosystemy Elektroniczne
7
SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol ver.3) dla wymiany
poczty elektronicznej,
HTTP (ang. Hyper Text Transfer Protocol) przeglądanie stron WWW (ang. World Wide
Web).
Natomiast do bardziej znanych protokołów warstwy aplikacji korzystających z protokołu UDP
należą:
DNS (Domain Name Service) odpowiada za zamianę adresów IP na tzw. adresy
domenowe,
RIP (Routing Information Protocol) - wymiana informacji związanych z aktualizacją reguły
doboru tras w węzłach sieci (routing),
NFS (Network File System) - współdzielenie plików przez wiele komputerów dołączonych
do sieci.
Każda aplikacja korzystająca z protokołów TCP lub UDP jest identyfikowana za pomocą
numeru portu. W Internecie niektóre numery portów są zarezerwowane i wstępnie przypisane do
tzw. dobrze znanych usług (ang. well known port numbers). Dobrze znane usługi to np. takie
protokoły sieciowe jak FTP: porty 20 i 21, TELNET: 23, SMTP: 25, POP3: 110, HTTP: 80, itd.
Protokoły TCP/IP używają również pojęcia gniazda. Gniazdo to kombinacja adresu IP i
numeru portu. W związku z tym gniazdo jednoznacznie określa proces w Internecie, czy
zakończenie logicznego łącza komunikacyjnego między dwiema aplikacjami. Jeśli aplikacje
realizowane są na dwóch różnych komputerach, to para odpowiadających im gniazd definiuje
połączenie w protokole połączeniowym TCP.
3.3. Protokół IP
Jak już wspomniano wcześniej protokół IP umożliwia transmisję bloków informacji zwanych
datagramami, pomiędzy dwoma urządzeniami (ang. host), identyfikowanymi przez 32-bitowe
adresy IP. Prócz tego protokół IP zapewnia mechanizmy fragmentacji i składania datagramów o
długości przekraczającej możliwości protokołów sieciowych niższej warstwy. Nie jest
realizowane natomiast sterowanie przepływem danych ani żadna kontrola poprawności przekazu
informacji między nadawcą a odbiorcą.
32-bitowe adresy IP są zwykle przedstawiane w formie 4 bajtów zapisanych dziesiętnie,
oddzielonych kropkami. Przykładowe adresy IP mają postać:
100.200.100.253 80.50.38.114
Urządzenia pogrupowane są w podsieci, określane również przez 32-bitowe adresy. Każde
urządzenie z przypisanym adresem IP przynależy do jednej podsieci i musi prócz swego adresu
znać również tzw. maskę podsieci (ang. subnet mask). Maska podsieci jest 32-bitowa i
zapisujemy ją podobnie jak adres IP. Przykładowa maska podsieci:
255.255.255.0
Wykład Mikrosystemy Elektroniczne
8
Grupa bitów ustawionych w masce sieciowej (w przykładzie: 24 najstarsze bity adresu)
definiuje zakres bitów określający podsieć. Grupa bitów wyzerowanych (tutaj 8 najmłodszych
bitów) definiuje zakres bitów określający numer hosta komputera lub innego urządzenia
sieciowego.
Dla pierwszego z przykładowych adresów IP na podstawie maski podsieci można obliczyć
numer podsieci mnożąc logicznie (operacja AND) maskę podsieci z adresem IP. Należy
pamiętać, że wszystkie adresy są po prostu 32-bitowymi liczbami, tyle że zapisanymi w
specyficzny sposób:
100.200.100.253 AND 255.255.255.0 = 100.200.100.0
Wyróżnia się grupę adresów IP, które nie mogą być przyznawane urządzeniom, ani nie
określające numerów podsieci. Jest wśród nich m.in. adres rozgłoszeniowy
(ang. broadcast) używany w celu wysłania informacji do wszystkich komputerów
odbierających nadaną ramkę (połączonych co najwyżej koncentratorami lub przełącznikami).
Adres rozgłoszeniowy składa się z 32 ustawionych bitów:
255.255.255.255
Istnieje również specjalny adres rozgłoszeniowy podsieci, używany w celu transmisji
informacji jedynie do hostów działających w danej podsieci. Tworzy się go poprzez ustawienie
wszystkich bitów adresu podsieci przypisanych do numeru hosta. Matematycznie ujmując, w celu
obliczenia adresu rozgłoszeniowego podsieci należy do numeru podsieci dodać logicznie
(operacja OR) zanegowaną maskę podsieci. Na przykład:
100.200.100.0 OR (NOT 255.255.255.0) = 100.200.100.255
W omawianym wcześniej standardzie Ethernet II, datagramy protokołu IP są enkapsulowane
w polu danych przesyłanej ramki. Pole określające typ zawiera natomiast wartość 0x0800, co
jednoznacznie identyfikuje protokół IP.
Poniżej w tabeli 5 przedstawiono budowę nagłówka datagramu IP. W pierwszym wierszu
umieszczono numery bitów w 32-bitowych słowach nagłówka.
Tab. 5. Nagłówek IP.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
wersja IHL ToS długość całkowita
identyfikator flagi przesunięcie fragmentu
TTL protokół suma kontrolna nagłówka
adres zródłowy IP
adres docelowy IP
Pole wersja (ang. version) zawiera, w datagramach protokołu IP wersji czwartej, wartość 4
(binarnie: 0100). Istnieje również szósta wersja protokołu IP, znacznie bardziej rozwinięta i do tej
pory bardzo mało rozpowszechniona w Internecie.
Wykład Mikrosystemy Elektroniczne
9
Pole IHL (ang. Internet Header Length) specyfikuje długość nagłówka liczoną w słowach
32-bitowych. Nagłówki datagramów IP mogą zawierać dodatkowe pola opcji, zapisywane
bezpośrednio za polem adresu docelowego. W opcjach są zapisywane parametry bezpieczeństwa,
specjalne informacje na temat wyznaczania trasy datagramu (ang. routing) czy też dane o czasie
wysłania datagramu (ang. timestamp). Najczęściej jednak dodatkowe opcje nie są doklejane do
nagłówków datagramów IP i 4-bitowe pole IHL ma wartość 5 (długość nagłówka wynosi 20
bajtów).
Pole ToS czyli typ usługi (ang. Type of Service) pozwala na określenie parametrów
pomocnych w wyznaczaniu trasy datagramu. Podzielone jest na 5 fragmentów o długości od 1 do
3 bitów, których znaczenie podano w tabeli 6.
Tab. 6. Zawartość pola ToS.
bit znaczenie
0 2 pierwszeństwo
3 opóznienie: 0 normalne, 1 niskie
4 przepustowość: 0 normalna, 1 wysoka
5 pewność transmisji: 0 normalna, 1 wysoka
6 7 bity zarezerwowane
W praktyce wykorzystuje się bity 3 5 pola ToS w takich usługach jak VoIP (ang. Voice
over IP) czy wideokonferencjach internetowych, choć do niedawna produkowane routery nie
analizowały zawartości pola ToS i nie uwzględniały go w procesie określania trasy transmisji
datagramu. Zapewnienie jakości usług poprzez m.in. specyfikację typu usługi dla
przekazywanego datagramu okazało się niezbędne do poprawnego przekazu głosu przez sieć tak
rozległą, jak Internet. Dlatego większość obecnie produkowanego osprzętu sieciowego analizuje
pole ToS .
16-bitowe pole długość całkowita (ang. total length) datagramu IP zawiera liczoną w
bajtach sumę długości nagłówka (podaną w polu IHL ) i ilości danych występujących tuż za
nagłówkiem. Każde urządzenie sieciowe musi być przygotowane do obróbki datagramów o
całkowitej długości nie mniejszej niż 576 oktetów. Z wielkości pola wynika, iż najdłuższe
transmitowane datagramy nie mogą przekraczać 65535 oktetów. Jednak w praktyce maksymalna
długość datagramu jest ograniczona do rozmiaru pola danych ramki Ethernet o maksymalnej
długości (1518 bajtów) i jest nie większa niż 1500 bajtów.
Identyfikator (ang. identification) datagramu IP stanowi liczba 16-bitowa, inna dla każdego
nadawanego datagramu. Bardzo ważna jest dla prawidłowego złożenia datagramu podzielonego
na fragmenty, którego każdy przesyłany fragment otrzymuje ten sam identyfikator.
3-bitowe pole flagi (ang. flags) specyfikuje, czy niższa warstwa protokołów sieciowych ma
nie dzielić datagramu na fragmenty (zapalony bit 17 drugiego słowa datagramu flaga Don t
Wykład Mikrosystemy Elektroniczne
10
Fragment ) oraz, dla datagramu podzielonego na fragmenty, czy będą przesyłane kolejne
fragmenty (zapalony bit numer 18, flaga More Fragments ). Pierwszy bit pola flagi nie jest
używany i w wysyłanych datagramach musi miećwartość 0.
13-bitowe pole przesunięcie fragmentu (ang. fragment offset) określa, do którego miejsca
datagramu dany fragment należy. Przesunięcie fragmentu jest mierzone w jednostkach po 8
bajtów a pierwszy z wysyłanych fragmentów musi mieć w tym polu wstawioną wartość 0.
Pole TTL (ang. Time To Live) datagramu IP określa czas życia datagramu. Jest on liczony
w ilości węzłów, przez które musi przejść datagram aż zostanie zatrzymany nie przesłany dalej.
Taki mechanizm zabezpiecza przed nieskończoną transmisją datagramu w razie niemożliwości
znalezienia właściwej drogi do odbiorcy oraz pozwala ograniczyć transmisję do małego obszaru
geograficznego, np. jednego państwa. Nadanie polu TTL zbyt niskiej wartości spowoduje, że
nie dotrze on do zbyt odległego, w sensie ilości pośrednich węzłów, odbiorcy. Najczęściej polu
TTL przy wysyłaniu datagramu nadawana jest stała wartość, np. 64.
8-bitowe pole protokół (ang. protocol) specyfikuje protokół wyższej warstwy
komunikacyjnej, którego pakiet jest enkapsulowany w polu danych datagramu IP.
Oprogramowanie mikroserwera będzie wymagało implementacji protokołów: ICMP (o
identyfikatorze 1) oraz TCP (o identyfikatorze 6).
Integralność informacji zawartych w nagłówku datagramu IP zapewnia 16-bitowa suma
kontrolna nagłówka (ang. header checksum). Jest ona obliczana według prostego algorytmu,
zakładającego zsumowanie wszystkich słów nagłówka jako liczb 16-bitowych a następnie
dopełnienie do jedności otrzymanej liczby. Otrzymana liczba jest 24-bitowa i nie można jej
umieścić w 16-bitowym polu sumy kontrolnej. Dokonuje się tutaj prostego zabiegu najstarszy
bajt tej liczby jest odcinany a następnie dodawany do otrzymanej w ten sposób liczby 16-
bitowej. Na czas obliczeń pole sumy kontrolnej jest zerowane. Poniżej zamieszczono
przykładowy nagłówek IP oraz sposób obliczenia sumy kontrolnej nagłówka (tabela 7).
Ostatnie dwa 32-bitowe słowa nagłówka datagramu IP stanowią: adres zródłowy IP (adres
nadawcy datagramu) oraz adres docelowy IP (adres odbiorcy).
Tab. 7. Przykładowy nagłówek IP.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0100 (4) 0101 (5) 00000000 0000000001011100 (92 bajty)
000 0000000000000000
1100110111001101 (52685)
10000000 (128) 00000110 (6 TCP) 1110101101110001 (EB70)
11000000101010000000000000000101 (192.168.0.5)
11000000101010000000000000001000 (192.168.0.8)
Nagłówek z tabeli 7 zakodowany heksalnie ma postać:
45 00 00 5C
CD CD 00 00
80 06 EB 70
C0 A8 00 05
C0 A8 00 08
Wykład Mikrosystemy Elektroniczne
11
By obliczyć sumę kontrolną należy najpierw zsumować przedstawione liczby jako
16-bitowe (po 2 bajty):
45 00
00 5C
CD CD
00 00
80 06
wyzerowane pole sumy kontrolnej
00 00
C0 A8
00 05
C0 A8
+00 08
03 14 8C
W kolejnym kroku najstarszy bajt liczby 24-bitowej trzeba odciąć i dodać do uzyskanej liczby
16-bitowej:
14 8C
00 03
+
14 8F
Teraz pozostaje tylko uzyskaną liczbę 148F odjąć od liczby FFFF, co daje liczbę EB70, która
jest szukaną sumą kontrolną nagłówka IP.
W układzie mikroserwera, ze względu na ograniczone zasoby sprzętowe i moc obliczeniową
mikrokontrolera, wprowadzono pewne założenia odnośnie protokołu IP:
pole wersja zawsze przyjmuje wartość dziesiętna 4, zaś pole IHL wartość 5,
pola: ToS , flagi , przesunięcie fragmentu są wypełnione zerami,
długość całkowita nie może przekraczać maksymalnego rozmiaru pola danych ramki
Ethernet II, który wynosi 1500 bajtów,
pole identyfikator może przyjmować dowolną wartość stałą, ponieważ nie przewiduje się
fragmentacji,
pole TTL posiada stałą, niską wartość (np. TTL=32),
w polu protokół wartości dozwolone to: 1 ICMP, 6 TCP (tylko te dwa protokoły
zostały zaimplementowane). Datagramy IP z innymi wartościami tego pola będą
ignorowane.
3.4. Protokół ICMP
Jak wcześniej wspomniano Internet Protocol realizuje zawodne przenoszenie pakietów bez
użycia połączenia za pomocą przekazywania datagramów w routerach. Datagram wędruje od
nadawcy przez różne sieci i routery aż do końcowego odbiorcy. Jeżeli router nie potrafi ani
wyznaczyć trasy ani dostarczyć datagramu, albo gdy wykrywa sytuację mającą wpływ na
możliwość dostarczenia datagramu (np. przeciążenie sieci, wyłączenie maszyny docelowej,
wyczerpanie się licznika czasu życia datagramu) to musi poinformować pierwotnego nadawcę,
aby podjął działania w celu uniknięcia skutków tej sytuacji.
Protokół komunikatów kontrolnych Internetu ICMP powstał aby umożliwić routerom
oznajmianie o błędach oraz udostępnianie informacji o niespodziewanych sytuacjach. Protokół
Wykład Mikrosystemy Elektroniczne
12
ICMP jest traktowany jako wymagana część IP i musi być realizowany przez każdą
implementację IP, ponieważ wiadomość ICMP jest enkapsulowana w datagramie IP, którego
pole protokół przyjmuje wartość 1.
Chociaż protokół ICMP powstał, aby umożliwić routerom wysyłanie komunikatów to każda
maszyna może wysyłać komunikaty ICMP do dowolnej innej. Z technicznego punktu widzenia
ICMP jest mechanizmem powiadamiania o błędach. Udostępnia on routerom, które rozpoznają
błąd, sposób powiadomienia o nim nadawcy, którego błąd dotyczy. Chociaż w specyfikacji
protokołu są określone zamierzone sposoby korzystania z ICMP i sugestie na temat tych działań,
które mogą być podejmowane w odpowiedzi na komunikaty o błędach, ICMP nie dla każdego
możliwego błędu wyszczególnia działania, jakie mają być zapoczątkowane.
Tak więc gdy datagram powoduje błąd, ICMP może jedynie powiadomić pierwotnego
nadawcę o przyczynie. Nadawca musi otrzymaną informację przekazać danemu programowi
użytkownika, albo podjąć inne działanie mające na celu uporanie się z tym problemem.
Każdy komunikat ICMP ma własny format, ale wszystkie zaczynają się trzema takimi
samymi polami. Budowę wiadomości ICMP przedstawia tabela 8.
Tab. 8. Wiadomość ICMP.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
typ kod suma kontrolna ICMP
dane
Pole typ (ang. type) jednoznacznie określa typ wiadomości ICMP, zaś pole kod (ang.
code) specyfikuje dokładniej wiadomość w obrębie danego typu. Suma kontrolna wiadomości
ICMP (ang. ICMP checksum) wyznacza się w podobny sposób jak dla nagłówka IP, lecz
obejmuje ona całą wiadomość ICMP, tzn. łącznie z polem dane .
W układzie mikroserwera implementacja protokołu ICMP ograniczać się będzie jedynie do
obsługi odsyłania odpowiedzi na wiadomość żądania echa (typ=8), którą można wysłać z
komputera przy pomocy standardowego programu ping.
Format wiadomości ICMP nakazującej wysłanie echa (ang. Echo Request) przedstawia
tabela 9.
Tab. 9. Wiadomość Echo Request.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0x08 (typ 8) 0x00 (kod 0) suma kontrolna wiadomości ICMP
identyfikator numer sekwencji
Dane (32 bajty)
Wiadomość Echo Request zawiera, prócz wcześniej omówionych pól, 16-bitowy
identyfikator oraz 16-bitowy numer sekwencji. Te pola mogą przyjmować wartość zerową lub
inną dowolnie wybraną i są pomocne w dopasowaniu wysyłanych wiadomości Echo Reply do
odebranych odpowiedzi.
Wykład Mikrosystemy Elektroniczne
13
Po odebraniu skierowanej do niego wiadomości ICMP Echo , urządzenie sieciowe ma
obowiązek odesłać nadawcy potwierdzenie w postaci wiadomości ICMP Echo Reply .
Wiadomość ta musi zawierać dane identyczne z odebranymi, ten sam identyfikator i numer
sekwencji a różni się jedynie zawartością pola typ , które tym razem przyjmuje wartość 0.
Mechanizm automatycznego odsyłania odpowiedzi na wiadomość ICMP Echo Request
daje użytkownikowi komputera wygodną możliwość sprawdzenia, czy dane urządzenie sieciowe
działa poprawnie i można się z nim skomunikować. W każdym sieciowym systemie operacyjnym
istnieje polecenie ping, w którego wywołaniu należy podać nazwę lub numer IP komputera, do
którego chcemy wysłać wiadomość ICMP Echo Request . Przykładowo: ping
192.168.0.5
Podczas implementacji protokołu ICMP przyjęto następujące założenia:
ze wszystkich wiadomości ICMP mikroserwer będzie reagował wyłącznie na żądanie
echa,
minimalny rozmiar pola danych w wiadomości ICMP Echo Reply wynosi
0 bajtów, maksymalny ograniczono do 128 bajtów,
suma kontrolna wiadomości ICMP jest obliczana w uproszczony sposób. Wykorzystano
tu fakt, iż odpowiedz na żądanie echa różni się jedynie wartością pola typ (typ=0) i
sumy kontrolnej. Z zasady tworzenia sumy kontrolnej wynika, że jej wartość w
wiadomości ICMP Echo Reply jest o 0x8000 większa niż wiadomości ICMP Echo
Request . Dwubajtowa liczba 0x8000 wzięła się z bajtów pola typ i kod . Zatem w
momencie odsyłania odpowiedzi na żądanie echa do wartości sumy kontrolnej
wiadomości żądania echa, dodawana jest liczba 0x8000, przy czym jeśli wystąpi
przepełnienie, to do LSB sumy kontrolnej dodawana jest liczba 1 (przeniesienie z MSB).
3.5. Protokół TCP
Jak już wcześniej wspomniano, protokół TCP tworzy wirtualne połączenie pomiędzy dwoma
użytkownikami umożliwiając na bezpieczny (bezbłędny) transfer danych. Do wyspecyfikowania
odbiorcy za pomocą 32-bitowej adresacji, wspieranej przez protokół IP, TCP dodaje mechanizm
wyróżniający w każdym urządzeniu 65536 tzw. portów. Port jest logiczną jednostką, do której
kierowane są informacje. Do każdego portu może być przypisany program odbierający wyłącznie
informację skierowaną do danego portu. Istnieje grupa wyróżnionych numerów portów, dla
których podano standardowy program obsługujący i rodzaj przesyłanych danych, np. informacji z
serwerów nazw DNS (ang. Domain Name Server) czy podających aktualny czas.
Do portów o numerach poniżej 1024 są przypisane konkretne usługi np. TELNET port 23.
Ich użycie do innych celów jest utrudnione lub wręcz uniemożliwione w zwykłym
oprogramowaniu użytkowym działającym pod kontrolą niektórych sieciowych systemów
operacyjnych. Korzystanie przez aplikacje z portów o wysokich numerach (czasami dopiero tych
przekraczających 16383) jest dozwolone i zalecane dla niestandardowych usług systemowych.
Nagłówek pojedynczego segmentu TCP przedstawia tabela 10.
Wykład Mikrosystemy Elektroniczne
14
Tab. 10. Nagłówek TCP.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
port zródłowy (nadawcy) port docelowy (odbiorcy)
numer porządkowy
numer potwierdzenia
dłg.nagłówka zarezerwowane bity kontrolne rozmiar okna
suma kontrolna wskaznik pilnych danych
dane
Ze względu na okrojoną implementacje protokołu TCP w układzie mikroserwera, tylko
niektóre pola nagłówka TCP zostały wyjaśnione.
Pole port zródłowy (ang. source port) zawiera numer portu, jakiego użył nadawca przy
wysyłaniu strumienia TCP, zaś port docelowy (ang. destination port) zawiera numer portu
odbiorcy, do którego jest skierowany ów strumień. Np. użytkownik przegląda sobie strony
WWW (ang. World Wide Web). Przeglądarka internetowa w jego komputerze wysyła
odpowiednio segmenty TCP z zapytaniami do serwera WWW, w których port docelowy
zawiera liczbę 80 (80 standardowy port usługi WWW). Podobnie serwer stron WWW
odpowiada segmentami TCP, w których pole port zródłowy jest równe 80. Numer portu
zródłowego w segmentach użytkownika oraz portu docelowego w segmentach serwera WWW
jest również taki sam. Zatem przy wzajemnej wymianie danych pomiędzy hostami, każdy z nich
musi zamieniać miejscami pola port zródłowy i port docelowy w nagłówku TCP.
32-bitowe pole numer porządkowy (ang. sequence number) oraz numer potwierdzenia
(ang. acknowledgment number) zostanie omówione pózniej.
Długość nagłówka (ang. data offset) zawiera liczbę całkowitą, która określa długość
nagłówka segmentu mierzoną w wielokrotnościach 32 bitów. Dla typowego segmentu TCP pole
ma wartość 5.
Ponieważ niektóre segmenty mogą przenosić tylko potwierdzenia, inne dane, inne zaś
zawierają prośby o ustanowienie lub zamknięcie połączenia - pole bity kontrolne (ang. control
bits) zawiera informację o przeznaczeniu zawartości segmentu. Zawartość pola zostanie opisana
bardziej szczegółowo pózniej.
Przy każdym wysłaniu segmentu oprogramowanie TCP klienta proponuje ile danych może
przyjąć od serwera, umieszczając rozmiar swojego bufora w polu rozmiar okna (ang. window).
Sumę kontrolną w segmencie TCP oblicza się w podobny sposób jak dla nagłówka IP, lecz tu
sumowany jest tzw. pseudo-nagłówek IP, nagłówek TCP oraz dane, przy czym dane są
dopełniane zerami tak, by ich rozmiar w bajtach był liczbą parzystą. W tabeli 11 przedstawiono
postać pseudo-nagłówka IP.
Wykład Mikrosystemy Elektroniczne
15
Tab. 11. Pseudo-nagłówek IP.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
zródłowy adres IP
docelowy adres IP
00000000 typ protokołudługość całkowita
Pole długość całkowita w pseudo-nagłówku IP zawiera rozmiar całego segmentu TCP,
czyli jest sumą długości jego nagłówka oraz danych przez niego niesionych. Dla odróżnienia w
nagłówku IP pole długość całkowita jest sumą długości nagłówka IP i danych po nim
następujących.
Poniżej przedstawiono sposób obliczenia sumy kontrolnej segmentu TCP maszyny o adresie
IP 192.168.0.5, która chce nawiązać połączenie z serwerem FTP w sieci lokalnej o adresie IP
192.168.0.8. W tabeli 12 przedstawiono postać pseudo-nagłówka IP, a w tabeli 13 postać
segmentu TCP, dla opisanej sytuacji.
Tab. 2.12. Przykładowy pseudo-nagłówek IP.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0xC0A80005 (192.168.0.5)
0xC0A80008 (192.168.0.8)
00000000 0x06 (TCP) 0x0014 (20 bajtów)
Tab. 2.13. Przykładowy nagłówek TCP.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0x0400 (port 1024) 0x0015 (port 21 FTP)
0xFE5D99B1
0x00000000
0101 (5) 0x0 000010 (SYN) 0x2000 (8192)
suma kontrolna 0x0000
Dane zawarte w pseudo-nagłówku IP oraz nagłówku TCP należy zsumować jako liczby
dwubajtowe. Na czas sumowania nagłówka TCP pole sumy kontrolnej jest wyzerowane.
C0 A8
00 05
pseudo-nagłówek C0 A8
00 08
IP
00 06
00 14
04 00
00 15
FE 5D
99 B1
tu powinno być pole
50 02
numer potwierdzenia
+ 20 00
3 8D 9C
W słupku nie zapisano pola numer potwierdzenia i suma kontrolna ponieważ oba pola są
puste (wypełnione zerami). Strzałką oznaczono liczby powstałe z pseudo-nagłówka IP, pozostałe
Wykład Mikrosystemy Elektroniczne
16
liczby powstały z segmentu TCP. W podanym przykładzie nie występuje również pole z danymi,
bo jest to segment rozpoczynający negocjację otwarcia połączenia TCP.
W kolejnym kroku najstarszy bajt liczby 24-bitowej trzeba odciąć i dodać do uzyskanej
liczby 16-bitowej:
8D 9C
00 03
+
8D 9F
Na koniec pozostało jeszcze uzyskaną liczbę dopełnić do jedności, czyli przeprowadzić
operację: 0xFFFF - 0x8D9F = 0x7260. Liczba 0x7260 jest poszukiwaną sumą kontrolną
nagłówka TCP.
3.5.1. Graf przejść stanów TCP
Aby zagwarantować, że dane przesyłane z jednej maszyny do drugiej nie są ani tracone, ani
duplikowane używa się podstawowej metody znanej jako pozytywne potwierdzanie z
retransmisją. Metoda ta wymaga, aby odbiorca komunikował się z nadawcą, wysyłając mu w
momencie otrzymania danych komunikat potwierdzenia (ang. acknowledge - ACK). Nadawca
zapisuje sobie informację o każdym wysłanym pakiecie i przed wysłaniem następnego czeka na
potwierdzenie. Oprócz tego nadawca uruchamia zegar w momencie wysyłania pakietu i wysyła
ten pakiet ponownie, gdy minie odpowiedni czas, a potwierdzenie nie nadejdzie. Idea ta została
zilustrowana na rysunku 4.
wydarzenia po stronie komunikaty wydarzenia po stronie
nadawcy sieciowe odbiorcy
wysłanie pakietu 1
odebranie pakietu 1
wysłanie ACK 1
odebranie ACK 1
wysłanie pakietu 2
odebranie pakietu 2
wysłanie ACK 2
odebranie ACK 2
Rys. 4. Idea transmisji z potwierdzeniem.
Kolejny rysunek 5 pokazuje co się dzieje gdy pakiet został zgubiony lub gdy przekroczony
został limit czasu. Po wysłaniu pakietu nadawca włącza zegar. Gdy mija określony czas, w czasie
którego powinno nadejść potwierdzenie ACK nadawca przyjmuje, że pakiet został zagubiony i
wysyła go ponownie.
Wykład Mikrosystemy Elektroniczne
17
wydarzenia po stronie komunikaty wydarzenia po stronie
nadawcy sieciowe odbiorcy
wysłanie pakietu 1 strata pakietu
Spodziewane
uruchomienie zegara
przybycie pakietu 1
powinno zostać
powinno przybyć
wysłane ACK
ACK 1
przekroczenie limitu
czasowego
retransmisja
odebranie pakietu 1
pakietu 1
wysłanie ACK 1
odebranie ACK 1
Rys. 5. Retransmisja niepotwierdzonego pakietu.
Pomimo swojej prostoty metoda ta jest jednak mało efektywna. Nadawca nie może wysłać
kolejnego pakietu, dopóty nie odbierze potwierdzenia odebrania pakietu poprzedniego. Dane w
danym momencie płyną tylko w jednym kierunku i to nawet wtedy, kiedy sieć umożliwia
jednoczesną komunikację w obu kierunkach. Ponadto sieć nie będzie używana, kiedy maszyny
będą zwlekać z odpowiedziami np. podczas wyliczania sum kontrolnych. Takie rozwiązanie
powoduje znaczne marnowanie przepustowości sieci.
Technika przesuwającego się okna (ang. sliding window) lepiej wykorzystuje przepustowość
sieci, gdyż umożliwia wysyłanie wielu pakietów przed otrzymaniem potwierdzenia. W
rozwiązaniu tym umieszcza się na ciągu pakietów ustalonego rozmiaru okna i przesłanie
wszystkich pakietów, które znajdują się w jego obrębie. Mówimy, że pakiet jest
niepotwierdzony, jeżeli został wysłany, a nie nadeszło dla niego potwierdzenie. Liczba pakietów
niepotwierdzonych w danej chwili jest wyznaczona przez rozmiar okna. Dla protokołu z
przesuwającym się oknem , którego rozmiar jest np. równy 8, nadawca ma możliwość wysłania
przed otrzymaniem potwierdzenia do 8 pakietów. Gdy nadawca odbierze potwierdzenie dla
pierwszego pakietu, okno przesuwa się i zostaje wysłany następny pakiet. Okno przesuwa się
dalej gdy przychodzą kolejne potwierdzenia.
Zarówno idea transmisji z potwierdzeniem, retransmisji pakietu gdy nie nadeszło
potwierdzenie i przekroczony został timeout oraz technika przesuwającego się okna jest używana
w protokole TCP.
Algorytm przesuwającego się okna wykorzystuje wymienione wcześniej pola: numer
porządkowy , numer potwierdzenia , rozmiar okna oraz flagi zawarte w polu bity kontrolne
(rysunek 6). Zdefiniowano następujące flagi:
SYN flaga inicjująca połączenie TCP,
Wykład Mikrosystemy Elektroniczne
18
FIN flaga zamykająca połączenie TCP,
ACK flaga ważnego potwierdzenia,
URG flaga zawarta w segmencie danych pilnych,
RST odbiorca przerywa połączenie,
PSH jak najszybsze przesłanie danych do warstwy aplikacji.
Rys. 6. Wymiana numerów: porządkowego i potwierdzenia.
Nawiązanie połączenia w protokole TCP odbywa się na drodze tzw. wymiany trójetapowej
pomiędzy klientem i serwerem. Wymiana jest pewnego rodzaju protokołem handshake u i
podlegają jej: numer porządkowy, numer potwierdzenia oraz flagi. Ideę wymiany przedstawia
rysunek 7. Podczas otwierania połączenia pole ACK w segmencie klienta jest równe zero.
Rys. 7. Wymiana trójetapowa otwieranie połączenia TCP.
Po otwarciu połączenia, przy wysłaniu każdego segmentu TCP z danymi przez serwer
towarzyszy ustawienie flagi ACK. Jak już wcześniej wspomniano, serwer wyśle co najwyżej taką
liczbę niepotwierdzonych segmentów, dla której suma całkowitych długości tych segmentów nie
przekracza rozmiarowi okna, jakie zaproponował klient. Jednocześnie klient potwierdza
nadchodzenie kolejnych poprawnych segmentów z serwera, wysyłając segmenty pozbawione
danych i ustawioną flagą ACK. Podczas transmisji ideę wymianę pól numer porządkowy i
numer potwierdzenia można przedstawić równaniami:
ACK =SEQS+dlgOS
ńł
K
dla klienta
�łSEQ =ACK ,
ół K S
Wykład Mikrosystemy Elektroniczne
19
ACK =SEQK
ńł
S
dla serwera
�łSEQ =ACK +dlgWK ,
ół S K
gdzie dla klienta:
ACK numer potwierdzenia w kolejnym segmencie u klienta,
K
SEQS numer porządkowy w ostatnim segmencie odebranym z serwera,
dlgOS długość całkowita ostatniego segmentu odebranego z serwera,
SEQK numer porządkowy w kolejnym segmencie u klienta,
ACK numer potwierdzenia w ostatnim segmencie odebranym z serwera.
S
gdzie dla serwera:
ACK numer potwierdzenia w kolejnym segmencie serwera,
S
SEQK numer porządkowy w ostatnim segmencie odebranym od klienta,
SEQS numer porządkowy w kolejnym segmencie serwera,
ACK numer potwierdzenia w ostatnim segmencie odebranym od klienta,
K
dlgWK długość całkowita kolejnego segmentu wysyłanego do klienta,
W protokole TCP rozróżnia się dwa rodzaje uczestników transmisji: uczestnik aktywny oraz
uczestnik pasywny. Pierwszy z nich jest klientem, stroną która zaczyna transmisję. Uczestnikiem
pasywnym jest serwer, który oczekuje na nadchodzące połączenia pod określony numer portu.
Podobnie jak przy otwieraniu połączenia, tak i przy jego zamykaniu wyróżnia się stronę
aktywną i pasywną. Stroną aktywną dokonuje zamknięcia pierwsza, zazwyczaj jest nią klient.
Stroną pasywną najczęściej jest serwer, który zamyka połączenie jako ostatni. Przebieg procesu
zamykania połączenia pokazano na rysunku 8.
klient serwer
zamknięcie aktywne FIN m
brak danych do wysłania
ACK m+1
FIN n zamknięcie pasywne
ACK n+1
Rys 8. Zamykanie połączenia TCP.
Całość stanów w jakim może się znajdować klient oraz serwer, wraz z warunkami przejścia
pomiędzy tymi stanami tworzy graf (diagram) przejść stanów TCP. Postać grafu przedstawia
rysunek 9.
Wykład Mikrosystemy Elektroniczne
20
Rys 9. Graf przejść stanów TCP.
Przedstawiony graf przejść stanów TCP pokazuje zarówno stany dla serwera jak
i klienta. Przy każdej strzałce znajduje się flaga warunek przejścia do kolejnego stanu. Dla
przykładu FIN/ACK oznacza, że warunkiem przejścia ze stanu FIN_OCZEKIWANIE_1 do stanu
ZAMYKANIE jest odebranie segmentu z flagą FIN oraz wysłanie segmentu z ustawioną flagą
ACK.
W układzie mikroserwera zaimplementowano graf przejść stanów TCP zarówno dla serwera
jak i klienta. Przed implementacją postać grafu uproszczono do minimalnej. Została ona
przedstawiona na rysunku 10.
Wykład Mikrosystemy Elektroniczne
21
FIN+ACK/ACK ACK
CLOSED
connect/SYN
LISTEN
SYN/SYN+ACK
SYN_SENT
SYNC_RECVD
SYN+ACK/ACK
ACK
ESTABLISHED
disconnect/FIN+ACK FIN+ACK/FIN+ACK
FIN_WAIT_2 LAST_ACK
Rys 10. Zaimplementowany graf TCP w mikroserwerze.
Przejścia pomiędzy stanami w grafie realizowane przez klienta oznaczono przerywanymi
strzałkami. Dla serwera kolejność przejść stanów jest odpowiednia:
Po włączeniu zasilania, restarcie mikrokontrolera lub przy nieaktywnym połączeniu, TCP
znajduje się w stanie LISTEN (ang. nasłuch). Serwer oczekuje na nadchodzące połączenia
na portach 23 i 1024.
Jeśli odebrany zostanie segment TCP z flaga SYN, to wysłany zostaje segment
z ustawioną flagą SYN i ACK. TCP przechodzi do stanu SYN_RECVD
(ang. odebrano SYN).
Nadejście segmentu z flaga ACK powoduje otwarcie wirtualnego połączenia. TCP
przechodzi do stanu ESTABLISHED (ang. ustanowione).
Klient chcąc zakończyć połączenie z serwerem wysyła segment TCP z ustawionymi
flagami FIN i ACK. Serwer odpowiada takim samym segmentem, zaś TCP przechodzi do
stanu LAST_ACK (ang. oczekiwanie na ostatnie ACK).
W mikroserwerze nie przewidziano możliwości zamykania połączenia przez serwer.
Po odebraniu segmentu z flaga ACK połączenie zostaje prawidłowo zakończone. TCP
przechodzi do stanu CLOSED (ang. zamknięte), a następnie do stanu LISTEN.
Mikroserwer ma również zaimplementowaną kliencką część grafu TCP. Jest ona
wykorzystywana tylko i wyłącznie podczas nawiązywania połączenia z serwerem poczty SMTP
przy wysyłaniu wiadomości e-mail. W przypadku klienta przejścia między stanami są
następujące:
Naciśnięcie microswitch a wyzwalającego przerwanie zewnętrzne INT0 początkuje proces
nawiązywania połączenia. Do serwera SMTP o znanym adresie IP i MAC, wysyłany jest
segment o ustawionej fladze SYN. TCP przechodzi do stanu SYN_SENT (ang. wysłano
SYN).
Wykład Mikrosystemy Elektroniczne
22
Serwer odpowiada segmentem z flagami SYN i ACK. Wówczas zostaje odesłany segment z
flagą ACK. Wirtualne połączenie zostaje otwarte, zaś TCP jest w stanie ESTABLISHED.
Połączenie zostaje zamknięte przez serwer lub klienta. Zamknięcie przez serwer omówiono
wyżej. Zamknięcie połączenia przez klienta jest zapoczątkowane wysłaniem przez niego
segmentu z ustawionymi flagami FIN i ACK. TCP przechodzi do stanu FIN_WAIT_2.
Po odebraniu z serwera segmentu z ustawionymi flagami FIN i ACK, zostaje wysłany
segment z flaga ACK. Połączenie zostało pomyślnie zamknięte, zaś TCP przechodzi do
stanu CLOSED, a następnie LISTEN.
Oczywiście w dowolnym stanie grafu TCP następuje odpowiednia, przedstawiona wcześniej,
wymiana numeru potwierdzenia (ACK) i porządkowego (SEQ).
Podczas konstruowania mikroserwera przyjęto następujące założenia odnośnie protokołu
TCP:
pole numer potwierdzenia w trakcie nawiązywania połączenia z klientem przyjmuje
zawsze tą samą wartość (0x1000),
rozmiar okna przyjęto na 0xFF,
pole numer porządkowy w trakcie nawiązywania połączenia z innym serwerem
przyjmuje zawsze stałą wartość (0x1000),
serwer nie ma możliwość zamknięcia aktywnego połączenia,
nie ma możliwość automatycznego powrotu do stanu CLOSED jeśli próba wysłania
wiadomości e-mail nie powiodła się. Mogło to nastąpić w wyniku błędnego adresu IP, gdy
na danym hoście nie jest aktywny demon SMTP lub w wyniku błędów podczas dialogu
SMTP. Jedynym wyjściem ze tego stanu jest restart mikrokontrolera,
mikroserwer wykorzystuje porty: 23, 1024 i 1023,
niezaimplementowana została retransmisja przy braku potwierdzenia. W takiej sytuacji
mikroserwer zakleszcza się w odpowiednim stanie grafu TCP dopóty transmisja nie
zostanie wznowiona lub mikroserwer zostanie zrestartowany.
Port 23 związany jest z usługą TELNET. Jeśli połączenie zostało otwarte, to zawartość
wszystkich odbieranych segmentów TCP zostaje przesłana na interfejs szeregowy. Dane zaś
odebrane z interfejsu szeregowego zostają wysłane poprzez sieć do klienta.
Na porcie 1024 zrealizowano własny protokół wymiany danych, który przedstawiony jest w
kolejnym punkcie. Na ten port wysyłane są wszelkie dane powstałe w wyniku działania aplikacji
sterownika (rozdział 7) do mikroserwera.
Port 1023 jest portem zródłowym mikroserwera podczas połączenia z serwerem SMTP
wiadomości e-mail. Segmenty TCP o numerach portów różnych od wymienionych są
ignorowane.
4. Protokoły warstwy aplikacyjnej
W mikroserwerze zaimplementowano dwa protokoły warstwy aplikacyjnej. Pierwszym z
nich jest własnym protokołem za pomocą, którego odbywa się sterowanie mikrosewerem przez
Wykład Mikrosystemy Elektroniczne
23
aplikację sterownika pracującą na komputerze PC. Drugi z protokołów SMTP jest
standardowym protokołem transferu wiadomości e-mail do serwera poczty elektronicznej.
4.1. Protokół własny
Własny protokołu został opracowany w celu sterowania mikroserwerem za pomocą
aplikacji sterownika pracującej na komputerze PC. Ułatwia on mikroserwerowi rozpoznania
przeznaczenia danych odbieranych na porcie 1024. Pierwszy bajt danych jednoznacznie
charakteryzuje operację związaną z danymi za nim następującymi. W tabeli 14 przedstawiono
wartość i znaczenie bajtu sterującego.
Tab. 14. Znaczenie rozkazów zastosowanych we własnym protokole.
wartość bajtu(hex) znaczenie
0x01
dane przeznaczone do transmisji przez interfejs szeregowy
0x09
bajt danych do wyświetlenia na diodach LED
żądanie wysłania segmentu TCP z bajtem ustawionym na
0x10
przełączniku DIP
0x19
treść i znaczniki wiadomości e-mail
W przypadku wiadomości e-mail jej treść wraz z całymi komendami SMTP jest formowana
w aplikacji sterownika i wysyłana do mikroserwera w trzech segmentach TCP. W celu
odróżnienia poszczególnych fragmentów wiadomości e-mail wprowadzono drugi bajt sterujący.
Znaczenie poszczególnych kodów zawarte jest w tabeli 15.
Tab. 15. Znaczenie drugiego bajtu sterującego.
wartość I bajtu(hex) wartość II bajtu (hex) znaczenie
0x01
adres e-mail nadawcy
0x19 0x02 adres e-mail odbiorcy
0x03 treść wiadomości e-mail
4.2. Protokół SMTP
SMTP jest protokołem powszechnie stosowanym podczas wysyłania poczty elektronicznej,
który pracuje standardowo na porcie 25. Dialog pomiędzy klientem maszyną wysyłającą
wiadomość e-mail, a serwerem SMTP odbywa się czystym tekstem z wykorzystaniem komend
protokołu SMTP.
Protokół SMTP definiuje trzycyfrowe kody odpowiedzi serwera na uzyskane połączenie lub
wysyłane doń komendy. Za każdym kodem zamieszczona jest krótka informacja dodatkowo
opisująca znaczenie komendy. Ogólnie przyjęto, że kody: 1yz, 2yz, 3yz (y,z dowolne liczby)
oznaczają odpowiedz pozytywną serwera, zaś kody: 4yz, 5yz odpowiedz negatywną. Druga z
cyfr charakteryzuje czego dany kod dotyczy (x, z dowolne liczby):
x0z składnia poleceń,
x1z informacje (status, informacje pomocnicze),
x2z połączenie.
Poniżej przedstawiono przykładowy dialog, o minimalnej liczbie komend, klienta z
serwerem SMTP (rys. 11).
Wykład Mikrosystemy Elektroniczne
24
Rys. 11. Dialog klienta i serwera SMTP podczas transferu wiadomości e-mail.(Oznaczenia: S serwer, C klient)
Jak to wynika z rysunku, po uzyskaniu połączenia z serwerem SMTP klient odbiera linijkę
tekstu zaczynającą się od kodu 220 lub 421. Pierwszy oznacza , że serwer jest gotowy do dialogu
z klientem, drugi zaś sygnalizuje o braku gotowości serwera SMTP. Zawsze po kodzie 220
znajduje się adres domenowy serwera.
Następnie klient wysyła komendę HELO oraz swoją nazwę domenową lub nazwę komputera
w sieci lokalnej. Administrator serwera SMTP może zastrzec, że proces wysyłania wiadomości e-
mail, będzie przebiegał dalej jeśli podana nazwa domenowa odpowiada adresowi IP klienta.
Najczęściej jednak akceptowany jest dowolny ciąg znaków. Pozytywna odpowiedz serwera
rozkaz HELO to kod 250, negatywna 500, 501, 504, 421.
Po uzyskaniu kodu 250 klient wysyła ciąg znaków reprezentujący swój adres e-mail. Ciąg
znaków ma składnią: MAILFROM:.
Znacznik oznacza spację (ang. space) (kod ASCII 0x20), oznacza powrót karetki
(ang. Cariage-Return) przejście kursora na początek linii (kod ASCII 0x0d), a oznacza
wysunięcie linii (ang. LineFeed) przejście kursora do nowej linii (kod ASCII 0x0a).
Podawany adres e-mail musi mieć prawidłową składnię. Poprawność operacji potwierdzona jest
kodem 250, a każdy inny kod oznacza błąd.
W kolejnym etapie klient wysyła adres e-mail odbiorcy. Jest to ciąg znaków postaci:
RCPTTO:. Podobnie jak przy komendzie
MAIL jedynie kod 250 oznacza poprawność operacji, pozostałe kody sygnalizują błąd. Podany
adres e-mail musi dotyczyć dowolnej skrzynki będącej na serwerze SMTP, z którym nawiązało
się połączenie. Innymi słowy musi istnieć konto o podanym adresie e-mail na serwerze SMTP.
Wykład Mikrosystemy Elektroniczne
25
Teraz pozostaje wysłać tylko treść wiadomości e-mail. Informuje się o tym serwer SMTP
wysyłając rozkaz: DATA. Serwer odpowie kodem 354 oraz zakomunikuje by
zakończyć treść wiadomości sekwencją znaków .. Na początku treści
wiadomości stosuje się dodatkowe znaczniki. Najbardziej popularne wyjaśniono poniżej:
Date: data wysyłania wiadomości.
From: imię lub pseudonim nadawcy.
To: imię lub pseudonim odbiorcy.
Subject: temat wiadomości e-mail.
Kolejność wystąpienia znaczników jest dowolna. Ich poprawną interpretacją zajmie się
program pocztowy odbiorcy. Ważne jest aby oddzielić znaczniki od właściwej treści wiadomości
ciągiem znaków . Koniec treści wiadomości e-mail, jak wcześniej wspomniano,
sygnalizuje się wysyłając ciąg .. Jeśli serwer nie stwierdził błędu, to
odpowiada kodem 250. Każdy inny kod oznacza wystąpienie błędu.
Na koniec pozostaje tylko zakończyć połączenie z serwerem SMTP. Dokonuje się tego
wysyłając komendę: QUIT. Serwer odpowiada kodem 221, po czym zamyka
połączenie. Tak przesłana wiadomość e-mail zostanie dostarczona poprawnie do odbiorcy o ile
podano jego poprawny adres e-mail i jego serwer pocztowy jest aktywny.
Poniżej wymieniono najczęściej występujące kody SMTP wraz z ich znaczeniem:
211 informacje statusowe serwera lub pomocnicza podpowiedz,
214 informacje pomocy serwera,
220 serwer gotowy,
221 serwer zamyka połączenie,
250 operacja MAIL lub RCPT zakończona sukcesem,
354 oczekiwanie na treść wiadomości e-mail,
421 serwer niedostępny,
450 dana skrzynka pocztowa jest zajęta lub niedostępna,
451 lokalny błąd serwera,
452 zbyt mało pamięci by kontynuować operację,
500 błąd składni, niepoprawna komenda,
501 błąd składni w parametrach lub argumentach,
502 nieznana komenda,
503 niepoprawna sekwencja komend,
504 komenda bez parametrów,
550 operacja wstrzymana podana skrzynka pocztowa niedostępna,
552 za duży rozmiar wiadomości,
553 niedozwolona nazwa skrzynki pocztowej,
554 transakcja zakończona błędem.
Podczas implementacji klienta SMTP w mikroserwerze przyjęto następujące założenia i
ograniczenia:
maksymalna długość adresu e-mail nadawcy i odbiorcy to 32 znaki,
maksymalna długość treści wiadomości e-mail to 256 znaków (łącznie z nagłówkami
From, To, Subject),
Wykład Mikrosystemy Elektroniczne
26
w aplikacji sterownika ograniczono rozmiar pola From i To na 32 znaki, a Subject na
64 znaki,
rozkazy wysyłane są w pojedynczym segmencie TCP, podobnie treść wiadomości e-mail,
która zawiera znaczniki From, To i Subject, łącznie z ciągiem znaków
. kończącym transfer treści.
W łatwy sposób można powiększyć rozmiar wysyłanej wiadomości e-mail, należy jednak
pamiętać o tym, że rozmiar ten nie może być większy od rozmiaru pola danych ramki Ethernet o
maksymalnej długości (1500 bajtów) oraz, że od tego rozmiaru należy odjąć długość nagłówka
IP (20 bajtów), nagłówka TCP (20 bajtów) i długość pól: From, To i Subject. Dodatkowo
rozmiar ten należy pomniejszyć o liczbę znaków użytych do formowania dodatkowych
nagłówków oraz końca treści (łącznie 32 bajty). Zatem maksymalna liczba znaków będących
treścią wiadomości e-mail może wynosić co najwyżej 1300 znaków.
We wstępnej fazie implementacji protokołu SMTP założono, że do nawiązania połączenia z
serwerem SMTP konieczne będzie podanie jego adresu IP i MAC. Pózniej zdecydowano się
zaimplementować w protokole ARP możliwość wysyłania zapytania i dlatego podczas
nawiązywania połączenia z serwerem SMTP wymagane jest jedynie podanie jego adresu IP.
Mikroserwer sam pozyska jego adres MAC korzystając z ARP.

Wyszukiwarka

Podobne podstrony:
Przygotowanie próbek do badań mikroskopowych
Wykład 1 Nowoczesne techniki mikroskopowe
Badania mikroskopowestopów aluminium i magnezu
mikrosuper smanual elemis
wstępne badania mikroskopowe 2015
analiza mikroskopowa osadu czynnego cw 6 i 7
MIKROSKOPIA OSADU CZYNNEGO
tok?dan mikroskopowych
Barwienie komórek Analiza mikroskopowa obrazu
IFPAN101210a Pierwsze swiatlo mikroskopu elektronowego
optyka mikroskopowa
14A Mikroskopia Fluorescencyjna i konfokalna
3 Mikroskopia optyczna(1)
[mkIV] Uszkodzony mikrostyk, al Nieznany
Mikroskopia optyczna 2

więcej podobnych podstron