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 komunikat TFTP nagłówek IP opcode=1,2 UDP filename 0 mode 0 20 bit 8 bit 2 n bitów 1 n bitów 1 Opcode komunikat 1 RRQ 2 WRQ 3 data 4 ACK 5 error opcode=3 2 opcode=4 2 opcode=5 2 block nr data 2 0-512 bitów block nr 2 error nr error message 0 2 n bitów 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-2 HTTP-3 FTP-1 HTTP Request HTTP Request
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 Logiczna warstwa pośrednia Serwer WWW Apache + PHP Baza danych Serwer aplikacji Zasoby danych Translator formatów z/do XML(HTML) 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