usługi tftp

USŁUGI TFTP
ładowanie początkowe systemów operacyjnych, do bezdyskowych stacji
roboczych (np. Xterminale)
przesyłanie kopii systemu operacyjnego, np. routery CISCO.
wykorzystuje UDP 69 oraz TFTP multicast 1758
architektura klient/serwer
nie zawiera pól przeznaczonych na użytkownika i hasło (zabezpieczenia)
W dokumentacji RFC 1350 zamieszczony jest opis obowiązującej
obecnie 2 wersji protokołu TFTP.
KOMUNIKATY TFTP
datagram IP
datagram UDP
n bitów
1
n bitów
blocknr
2
2
2
blocknr
Opcode
komunikat
1 RRQ
2 WRQ
3 data
4 ACK
5 error
mode
2
2
2
data
0-512 bitów
error nr
8 bit
0
opcode=3
20 bit
filename
opcode=4
UDP
opcode=5
nagłówek
IP
opcode=1,2
komunikat TFTP
error message
0
2
n bitów
1
0
1
ODCZYT DANYCH W TFTP
Każdy pakiet danych zawiera pole block number, które jest
wykorzystywane do potwierdzania odebrania pakietu.
Dla przykładu, podczas chęci czytania pliku klient wysyła komunikat
RRQ, z umieszczoną w nim nazwą pliku oraz określonym typem
przesyłanych danych (pole mode). Jeżeli możliwe jest czytanie
wskazanego pliku przez klienta, serwer odsyła pakiet danych z polem
block number­ = 1. Potwierdzeniem odbioru pakietu danych jest
odesłanie przez klienta komunikatu ACK z polem block number = 1.
Serwer odpowiada wysłaniem kolejnego pakietu danych z block
number = 2. Procedura ta jest powtarzana do momentu aż cały plik
zostanie przesłany. Każdy pakiet z danymi musi zawierać 512 bitów
danych z wyjątkiem ostatniego, którego rozmiar pola data będzie
mniejszy niż 512.
ZAPIS DANYCH I BŁĘDY W TFTP
Trochę inaczej wygląda przebieg procesu zapisu pliku na serwerze.
Klient wysyła komunikat WRQ z określoną nazwą pliku oraz typem
przesyłanych danych (pole mode). Jeżeli plik może zostać zapisany
przez klienta na serwerze, to serwer odsyła komunikat ACK z polem
block number­ = 0. Następnie klient wysyła pierwsze 512 bitów jako
pakiet z block number­ = 1. Serwer odpowiada komunikatem ACK
(block number­ = 1).
Komunikat z polem opcode = 5, jest komunikat błędu (error message).
Generacja tego komunikatu odbywa się w chwili, gdy serwer nie może
obsłużyć czytania, bądź zapisu pliku, także podczas transmisji. W tym
momencie transmisja zostaje przerwana. Pole error number zwraca
numer kodu błędu, natomiast pole error message może zawierać
dodatkowe informacje systemu operacyjnego przedstawione w postaci
znaków ASCII.
PODSTAWY HTTP
Protokół HTTP (RFC 2616) leży u podstaw działania World Wide Web od
1990 roku. Określa sposób formatowania i przesyłania dokumentów oraz
komendy sterujące pracą serwerów internetowych i przeglądarek.
„HTTP jest to protokół poziomu aplikacji z wydajnością i szybkością
konieczną
dla
rozproszonego
multimedialnego
systemu
informacyjnego”. RFC 2616
Poważną wadę HTTP stanowi brak możliwości zapamiętywania informacji
o wcześniejszych wywołaniach - każde polecenie wykonywane jest
niezależnie od wyniku poprzednich. Uniemożliwia to w praktyce tworzenie
witryn zdolnych w sposób interaktywny reagować na poczynania
użytkownika. Stało się to głównym impulsem do opracowania nowych
technologii, które pozwoliłyby ominąć te niedogodności (ActiveX, ASP,
CGI, cookie, Java).
URI (UNIVERSAL RESOURCE IDENTIFIER)
W przeglądarkach internetowych możliwa jest także obsługa innych
usług niż tylko HTTP. Uzyskuje się to poprzez stosowanie uniwersalnej
metody adresowania URI (Universal Resource Identifier):
pełny adres URI: usługa://host/ścieżka
http://www.neuron.pol.lublin.pl/activity
częściowy URI: /ścieżka (/obrazki/nowe)
Adresy URI są także znane pod innymi nazwami, jako: adresy WWW,
Universal Document Identifiers, Universal Resource Identifiers, a także
jako kombinacja adresów Uniform Resource Locators and Names. W
nazwach URI dodatkowo mogą pojawiać się znaki określające numer
portu wykorzystywanego przez usługę (usługa://host:port).
POŁĄCZENIA HTTP - CZ.I
Klient – przeglądarka internetowa wysyła zapytania do serwera
WWW; wymiana danych jest inicjowana przez klienta (user agent)
jako zapytanie o stosowne zasoby na serwerze; pojedyncze
połączenie (v) pomiędzy klientem (UA) i serwerem początkowym (S).
POŁĄCZENIA HTTP – CZ. II
W bardziej złożonych przypadkach, gdy występuje jeden lub kilka
punktów pośredniczących (bramy sieciowe, tunele, serwery proxy)
łańcuch zapytań jest bardziej skomplikowany.
Transmisja musi być więc zrealizowana przez cztery niezależne
połączenia (często wykorzystujące różne media transmisyjne).
Różnice te są bardzo istotne, ponieważ niektóre opcje transmisji
HTTP mogą być stosowane wyłącznie w połączeniu z najbliższym,
„nietunelowanym” sąsiadem.
POŁĄCZENIA HTTP – CZ. III
W praktyce każdy punkt może być zaangażowany wielokrotnie w
przeprowadzanie równoczesnych transmisji, np. B może odbierać
zapytania od wielu klientów z wyłączeniem A, i/lub przesyłać dalej
zapytania do serwera w tym samym czasie.
Transmisja HTTP jest utożsamiana z warstwą aplikacji, która znajduje
się powyżej warstwy TCP/IP. Domyślnym portem HTTP jest 80, ale
mogą być wykorzystywane także inne numery. W transmisji HTTP 1.0
większość zapytań/odpowiedzi jest realizowana za pomocą nowych
połączeń. W HTTP 1.1 jedno połączenie może być wykorzystane do
wymiany zapytań/odpowiedzi.
PROTOKÓŁ HTTP V.1.1
Każdorazowe zestawianie połączeń TCP dla każdego URL powoduje
nadmierne obciążanie serwerów HTTP oraz co za tym idzie, może być
przyczyną powstawania zatorów w sieci Internet. Złożoność stron
WWW (rysunki, pliki z dźwiękiem, inne dane) powoduje konieczność
zestawiania przez klienta połączeń wielokrotnych z tym samym
serwerem w krótkich odstępach czasu.
Zalety protokołu HTTP 1.1:
Zapytania i odpowiedzi HTTP są przesyłane kolejno (pipeline) przez
jedno połączenie. Pipelining umożliwia klientowi tworzenie
wielokrotnych zapytań bez konieczności oczekiwania na poprzednią
odpowiedź. Taka organizacja ruchu umożliwia bardziej efektywne
wykorzystanie łącza TCP w krótszym czasie.
Prawdopodobieństwo wystąpienia zatoru w sieci jest redukowane
poprzez zmniejszenie ruchu pakietów związanych z organizacją
(otwieraniem, zamykaniem) połączeń TCP.
DOBÓR PLATFORMY HHTP
Wybór platformy programowej, mającej stanowić narzędzie do
budowy serwisów WWW to dopiero początek planowania pracy
przez administratora.
Obecne serwisy WWW, w dużej części dynamiczne i
wykorzystujące bazy danych, swoją specyfiką są bardziej zbliżone
do rozproszonych aplikacji sieciowych niż do swoich
pierwowzorów
Poważnym problemem administratorów jest przygotowanie
serwerów internetowych do rosnącej w sposób niemalże
nieprzewidywalny liczby odwiedzin.
Zachowania społeczności Internetu są trudne do przewidzenia.
To, że nagle nasz serwis WWW odwiedza 10 razy więcej osób
niż zwykle, może być efektem bardziej lub mniej kontrolowanych
działań.
Prognozowanie obciążenia witryny okazuje się więc jednym z
najważniejszych elementów projektu serwisu WWW.
PLANOWANIE SYSTEMÓW HTTP
W rozwoju każdego większego serwisu WWW można wskazać
następujące etapy:
planowanie zawartości i dostępnych funkcji,
analiza rynku,
instalacja w środowisku docelowym,
akcja promocyjna (nie zawsze),
rozwój i utrzymanie ruchu.
Planowanie wydajności lub zdolności obsługi jest procesem ciągłym i
powinno się zacząć w pierwszym etapie realizacji serwisu WWW - już
wówczas można uzyskać pierwsze prognozy co do liczby wizyt w danym
okresie czasu.
To z kolei może posłużyć do stworzenia prostego i niedoskonałego
jeszcze modelu analitycznego, który przy założeniu kilku empirycznych
lub katalogowych wskaźników wstępnie przybliży zapotrzebowanie na
wydajność.
MODEL UPROSZCZONY – CZ. I
Dla przykładu przeprowadźmy wstępną analizę dla następujących
przewidywanych warunków:
dziennie będzie składanych ok. 25 000 wizyt, każda potrwa
średnio 15 minut;
serwis będzie witryną statyczną z kilkoma skryptami, których typ
musimy określić (kwestia doboru modułów);
użytkownik w czasie pojedynczej wizyty odwiedzi 10 stron, w
tym 4 razy skorzysta ze strony dynamicznej.
MODEL UPROSZCZONY – CZ. II
Resztę parametrów możemy przyjąć domyślnie (na podstawie
opracowań udostępnionych przez firmę Microsoft):
średnia objętość kodu strony HTML - 7 kB;
średnia objętość grafiki - 16 kB;
średnia liczba grafik pobieranych z każdą stroną HTML - 4
(część wcześniej pobranych grafik przeglądarki zwykle
wyciągają z własnej pamięci cache);
stosunek liczby odwiedzin w okresie godzin szczytu 10-14
(peak load) - 200 proc. obciążenia bazowego;
MODEL UPROSZCZONY – CZ. III
Na tej podstawie możliwe jest przeprowadzenie następujących wyliczeń:
średnia "waga" strony HTML - 7 + 4 * 16 = 71 kB;
średnia liczba użytkowników odwiedzających witrynę w tym samym czasie 20x+4*2x=25000, gdzie x-obciążenie w godzinach normalnej aktywności NA;
obciążenie normalne x = 892 odwiedziny/godzinę;
obciążenie szczytowe 2x = 1785 odwiedzin/godzinę;
892*15 minut/60 minut = 223 użytkowników jednocześnie w godzinach NA;
1785*15 minut/60 minut = 446 użytkowników jednocześnie w godzinach
szczytowej aktywności;
średnia liczba równocześnie wykonywanych skryptów ASP:
obciążenie normalne: 892 * 4/ 3600 skrypt/sekundę,
obciążenie szczytowe: 1785 *4/ 3600 skrypty/sekundę;
średnia wymagana przepustowość serwera i sieci:
w godzinach normalnej aktywności: 892*10*71 kB = 609 MB/godz. = 173,5 kB/s,
w godzinach szczytowej aktywności: 1218 MB/godz. = 347 kB/s.
MODEL UPROSZCZONY - ANALIZA
Dobrym nawykiem przy szacowaniu zapotrzebowania na
wydajność serwera czy łącza jest przyjmowanie jako docelowego
obciążenia o 50 proc. większego od maksymalnego,
przewidywanego w obecnej sytuacji.
Należy zauważyć, że wzrost liczby odwiedzin o 50 proc.
spowoduje wzrost wymaganej szczytowej przepustowości do
ponad 520 kB/s. Choć maksymalny transfer dla kart sieciowych
10Base-T wynosi 1,2 MB/s, zaleca się, aby obciążenie
pojedynczego segmentu Ethernet 10 Mb/s nie przekraczało 36
proc. jego maksymalnej przepustowości (czyli 460 kB/s) - w
przeciwnym razie w sieci zacznie dość gwałtownie wzrastać liczba
kolizji ramek i ogólna wydajność kanału spadnie.
Osobną sprawą jest zapewnienie odpowiednio szybkiego
połączenia naszego serwera z Internetem - przy wymaganej
maksymalnej przepustowości w granicach 520 kB/s jedynie łącze o
szybkości przynajmniej 1 Mb/s będzie mogło zaspokoić nasze
potrzeby.
MODEL UPROSZCZONY – WNIOSKI – CZ. I
Nie należy zapominać, że dokładanie kolejnego procesora lub
zwiększanie szybkości pracy procesora oraz rozszerzanie dostępnej
ilości pamięci RAM nie są jedynymi możliwościami zwiększenia
wydajności serwera WWW.
Czasami, szczególnie z punktu widzenia większej niezawodności,
bardziej będzie się opłacało uruchomienie dodatkowego komputera i
odpowiednie rozłożenie pomiędzy oba ruchu generowanego przez
użytkowników (load balancing).
HTTP-1
HTTP
Request
HTTP Request
HTTP-2
HTTP-3
FTP-1
MODEL UPROSZCZONY – WNIOSKI - CZ.II
Architektura z więcej niż jednym serwerem zalecana jest w
przypadku aplikacji internetowych opartych na bazach danych wtedy np. dwie maszyny pełnią funkcje serwerów aplikacji (HTML+
skrypty), a trzecia zajmuje się obsługą wykorzystywanych przez
aplikację baz danych.
Takie rozwiązania jak wyżej, lecz ze znacznie większą liczbą
serwerów, stosowane są m.in. w firmach prowadzących duże portale
internetowe
STRUKTURA PORTALU INTERNETOWEGO
Warstwa
klienta
Interfejs użytkownika
przeglądarka WWW
Serwer WWW
Apache + PHP
Logiczna
warstwa
pośrednia
Serwer
aplikacji
Baza danych
Translator formatów z/do
XML(HTML)
Zasoby danych
Serwer
NEWS
Dokumenty
XML na
WWW
Inne dokumenty na
WWW: HTML,
Word, PDF, …
Inne bazy
danych XML
WARSTWY LOGICZNE PORTALU
Warstwa klienta
Warstwa klienta, to nic innego jak interfejs użytkownika,
przedstawiający
wynik
działania
procesu,
jakim
jest
przekształcenie poszukiwanych informacji i prezentacja jej w
prosty, zwięzły i przede wszystkim zrozumiały dla klienta sposób.
Fizycznie jest to komputer z przeglądarką internetową, palmtop,
telefon komórkowy.
Logiczna warstwa pośrednia
Jest to miejsce, w którym dokonywane jest scalanie wszystkich
posiadanych informacji przez system, ujednolicenie jej i
sformatowanie w celu dalszej prezentacji.
Fizycznie jest to komputer, serwer WWW, korzystający z
wewnętrznej i zewnętrznych baz danych oraz serwerów aplikacji.
Zasoby danych
Są to wszystkie posiadane zasoby: dokumenty w różnych
postaciach (np. doc, PDF, HTML, XML i inne), informacje zawarte
w bazach danych.
Fizycznie są to serwery baz danych, serwery plików i inne.
PORTAL INTERNETOWY A REPREZENTACJA DANYCH
Idea serwerów aplikacji wyłoniła się z konieczności bardziej
zaawansowanego rozwoju serwisów i stron WWW oraz jako naturalne
rozszerzenie aplikacji typu klient – serwer.
STRUKTURA SOFTWEROWA PORTALU
Narodził się pomysł podziału takiego systemu na kilka warstw, gdzie
oddzielono logikę działania aplikacji od warstwy prezentacji i warstwy
danych, co znacznie ułatwiło wszelkie modyfikacje i budowę nowych
serwisów. Taka architektura składa się z trzech warstw:
z jednego lub wielu tzw. systemów zaplecza (back­end),
z interfejsu użytkownika, inaczej warstwy prezentacji (front­end),
z warstwy pośredniej (middleware), w której umieszcza się
oprogramowanie logiki biznesowej systemu (gdzie zapisane są
wszystkie reguły rządzące działaniem aplikacji i procesy
biznesowe).
SERWERY WIRTUALNE WWW
Z serwerami wirtualnymi
Bez serwerów wirtualnych
Niezaprzeczalnie najpopularniejszym serwerem WWW jest Apache.
W Polsce Apache ma 50% rynku. Jest to wartość podobna, jak w
innych krajach, gdzie Apache ma od 40% do 60% rynku