SK Moduł 12 - Studia Informatyczne

Transkrypt

1 1 z :29 SK Moduł 12 From Studia Informatyczne W tym rozdziale zostaną omówione i przedstawione podstawowe usługi sieciowe, z którymi większość użytkowników ma styczność na codzień. Część z nich jest nawet postrzegana jako synonim posiadania dostępu do sieci Internet, np. usługi WWW, poczta elektroniczna, a ich brak zmniejsza w znaczącym stopniu atrakcyjność posiadania tegoż dostępu. Oprócz nich istnieje liczna grupa usług, nieco mniej popularnych, wykorzystywanych w sieciach lokalnych i coraz częściej w sieciach rozległych, np. usługi terminalowe, o których również będzie

2 2 z :29 mowa w tym rozdziale. Kolejność omawiania usług będzie następująca: poczta elektroniczna, transmisja danych, usługi terminalowe, serwisy informacyjne, synchronizacja czasu, dostęp do informacji o użytkownikach. Na działanie niektórych z wymienionych usług składa się jeden lub więcej zaprojektowanych dla tego celu protokołów. W omówieniu działania tych usług, protokoły te zostaną również przedstawione. Idea przesyłania informacji w postaci elektronicznej między użytkownikami w sieci jest tak samo stara, jak pomysł połączenia komputerów w sieć. Najczęściej pierwszym doświadczeniem z sieciami dla większości użytkowników było wysłanie/odebranie a. Wygoda, szybkość i prostota programów pocztowych sprawiają, że poczta elektroniczna jest najczęściej wykorzystywaną usługą w sieciach. Co więcej, dla licznej grupy użytkowników dostępność tej usługi całkowicie zaspokaja ich potrzeby wykorzystania sieci. Przedstawione poniżej protokoły ukrywają przed użytkownikiem mechanizm przesyłania poczty między serwerami oraz metody dostępu do jego skrzynek pocztowych.

3 3 z :29 Simple Mail Transfer Protocol służy tylko i wyłącznie do przesyłania poczty między komputerami. Nie specyfikuje on systemu pocztowego wysyłającego ani odbierającego, nazw użytkowników, sposobu przechowywania informacji przez serwery pocztowe, wielkości przesyłki, liczby przesyłek. Są to najczęściej parametry konfigurowane przez administratorów serwerów pocztowych i nie mają nic wspólnego z protokołem SMTP jako takim. Standard SMTP określa jedynie format komunikatów wymienianych przez maszynę nadającą przesyłkę i odbierającą ją. Komunikaty te są przesyłane w postaci czytelnych tekstów ASCII, co pozwala na komunikację dowolnych serwerów pocztowych bazujących na dowolnych systemach operacyjnych. Zestaw znaków ASCII jest bardzo prosty i znany większości użytkowników. Standardowa procedura wysyłania listu opiera się na utworzeniu połączenia TCP

4 4 z :29 ze zdalną maszyną i oczekiwaniu aż ta przyśle komunikat: 220 <nazwa maszyny> ESMTP server ready. Dalej następuje, np.: HELO <nazwa maszyny wysyłającej> 250 <nazwa maszyny odbierającej> Hello <nazwa maszyny wysyłającej> [<adres IP maszyny wysyłającej> ], pleased to meet you MAIL FROM: <xxx@domena.pl> <xxx@domena.pl>... Sender ok. RCPT TO: <yyy@domena.com> <yyy@domena.com>... Recipient ok. DATA 354 Enter mail, end with "." on a~line by itself <treść listu> SMTP nie przewiduje przesyłania danych w kodzie innego typu niż ASCII. Aby umożliwić dołączanie do listów poczty elektronicznej plików różnego rodzaju aplikacji, IETF (ang.internet Engineering Task Force) zdefiniowała rozszerzenie SMTP zwane MIME (ang. Multipurpose Internet Mail Extensions). Umożliwia ono zakodowanie dowolnego typu danych w ASCII. Dzięki temu, przy pomocy SMTP można przesyłać w listach różnego rodzaju załączniki. Dane zakodowane przez MIME w nagłówkach zawierają informację konieczną do ich zdekodowania. W szczególności jest w nich zawarty typ zakodowanych danych, sposób kodowania oraz wersja MIME. List zawiera również podobnego typu informacje, aby umożliwić przesyłanie danych dowolnego typu. Przykład przesyłki zawierającej załącznik przedstawiony jest na slajdzie.

5 5 z :29 Jak widać, w nagłówku listu jest umieszczona informacja o użyciu MIME w wersji 1.0 oraz o tym, że list składa się z kilku części (Content-Type: multipart/mixed). Każda z nich może być zakodowana w innym formacie, co również przedstawia przykład. Standard MIME wymaga od aplikacji używania pary identyfikatorów, rozdzielonych znakiem "/" w nagłówku Content-Type. Pierwszy identyfikator, oprócz przedstawionego w przykładzie, informuje o typie danych. Możliwe są następujące typy: text - tekst, image - obrazy typu GIF, JPEG, BMP, itd; audio - dane audio, video - dane video, application - dane programu, message - list poczty elektronicznej. Drugi identyfikator natomiast definiuje dokładniej, jakiego typu są to dane. Standard MIME wymusza również, aby dany typ danych zawierał konkretne "podtypy", np. dane audio nie mogą w podtypie zawierać gif.

6 6 z :29 Dla przedstawionego w przykładzie typu multipart, oprócz danych mixed IETF przewidział inne typy danych: alternative - wiele typów kodowania tych samych danych, parallel - gdy pojedyncze części powinny być oglądane wspólnie, np. audio i video, digest - gdy przesyłka zawiera zbiór innych listów, np. fragment archiwum jakiejś listy dyskusyjnej. Dostarczanie przesyłek poczty elektronicznej odbywa się w następujący sposób. Nadawca tworzy list, a następnie łączy się przy pomocy swojego klienta pocztowego (MUA - ang. Mail User Agent) z serwerem (MTA - ang. Mail Transfer Agent), który go wyśle. Jeżeli połączenie się nie uda, to list nie jest wysyłany. Najczęściej program wysyłającego umieszcza go w swojej lokalnej kolejce listów oczekujących na wysłanie. Po ustalonym czasie lub przy próbie wysłania kolejnego listu i nawiązaniu połączenia z serwerem, wszystkie listy oczekujące na wysłanie zostaną przekazane do serwera. Przykład konfiguracji klienta poczty przedstawia slajd. Serwer pocztowy gromadzi listy do wysłania w zdefiniowanych kolejkach. Po umieszczeniu przesyłki w kolejce, serwer nawiązuje połączenie z odległym serwerem pocztowym. Na podstawie informacji w nagłówkach listu, lokalny

7 7 z :29 serwer wie, w jakiej domenie DNS znajduje się adresat. Dzięki temu oraz rekordom MX systemu DNS może ustalić nazwę i adres IP maszyny obsługującej pocztę elektroniczną w domenie adresata. Po ustaleniu adresu IP próbuje nawiązać połączenie TCP z odległą maszyną. Jeśli się to uda, przesyła wiadomość do tej maszyny i po potwierdzeniu jej odebrania likwiduje kopię przesyłki w lokalnej kolejce. Zgromadzone w kolejkach przesyłki mogą przebywać w nich określony, zdefiniowany czas. Jeśli ten limit czasowy zostanie przekroczony i list nie zostanie w tym czasie wysłany do odbiorcy, serwer usuwa taką wiadomość ze swoich kolejek. Nadawca jest informowany o tym fakcie przez otrzymanie komunikatu o błędzie od serwera. Najczęstszą przyczyną powstawania tego typu sytuacji są błędne informacje w nagłówkach listów lub brak odpowiednich wpisów w rekordach systemu DNS. Drugą z możliwych przyczyn jest awaria, niedostępność odległego serwera pocztowego w tym czasie. Zgodnie ze standardami serwer powinien przechowywać listy przez 5 dni. Utrzymywanie serwerów pocztowych na komputerze każdego użytkownika oraz ich ciągła praca w ciągu doby są zbyt kosztowne dla większości firm. Poza tym jest to zbyt skomplikowane w przypadku, gdy użytkownicy nie potrafią rozwiązać problemów powstających przy obsłudze serwera. Dlatego też w prawie 100% firm jest uruchomiony jeden lub kilka serwerów pocztowych dla użytkowników. Ułatwia to ich administrację oraz utrzymanie. Jednocześnie powstaje problem dostępu do skrzynek pocztowych użytkowników na serwerze. Najczęściej administratorzy chcą unikać sytuacji, w której dostęp do serwera pocztowego ma każdy użytkownik chcący przeczytać pocztę elektroniczną. Z wysłaniem nie ma problemu, gdyż wystarczy otworzyć sesję TCP z serwerem i przekazać mu wiadomość. W celu rozwiązania problemu w dokumencie RFC 1939 został zdefiniowany protokół dostępu do skrzynek pocztowych -- POP3 (and. Post Office Protocol Version 3). Służy on do wykonywania operacji

8 8 z :29 kasowania oraz odczytywania listów przechowywanych w skrzynce pocztowej na innym komputerze. Alternatywnym protokołem dla POP3 jest opisany w dalszej części IMAP. Użytkownik konfigurując swojego klienta pocztowego zazwyczaj może wybrać jeden z tych protokołów. Przykład przedstawia slajd. W tym celu, na komputerze (niekoniecznie na serwerze pocztowym), przez który użytkownicy mają mieć możliwość sięgania do swoich skrzynek pocztowych, na 110 porcie TCP uruchamiany jest proces demon oczekujący na połączenia. Program pocztowy użytkownika otwiera połączenie TCP z serwerem POP3 i oczekuje na zgłoszenie się serwisu. Następnie wydaje ciąg komend oczekując na odpowiedzi od serwera. Po ich wykonaniu następuje rozłączenie. Zbiór komend rozumianych przez serwer POP3 jest ściśle zdefiniowany. Komendy muszą być przesyłane w ASCII, argumenty oddzielone spacjami, nie mogą być dłuższe niż 40 znaków. Serwer musi odpowiadać na nieznane, nie zaimplementowane komendy informacją o błędzie -ERR lub +OK w przeciwnym wypadku. W ramach jednej sesji serwer POP3 pracuje kolejno w kilku trybach. Zaraz po nawiązaniu połączenia znajduje się w trybie autoryzacji. Przejście do następnego trybu następuje, gdy klient pomyślnie przejdzie proces identyfikacji -- poda prawidłową nazwę użytkownika i hasło. Serwer wówczas uzyskuje prawo do przeczytania zawartości skrzynki użytkownika. Po przeczytaniu informuje o liczbie wiadomości w skrzynce i przechodzi do trybu transakcyjnego. Po przesłaniu wiadomości ze skrzynki serwer czeka na komendę QUIT. Po jej otrzymaniu przechodzi do trybu odświeżania informacji na serwerze. W tym trybie aktualizowana jest informacja o przeczytanych bądź nieprzeczytanych wiadomościach w skrzynce użytkownika oraz zwalniane są uprzednio zajęte zasoby systemu. Następnie serwer zamyka połączenie TCP. Przed wejściem w tryb transakcyjny serwer POP3 blokuje dostęp do skrzynki, aby ochronić ją przed modyfikacją zanim serwer przejdzie do trybu odświeżania

9 9 z :29 informacji o skrzynce. Po otwarciu skrzynki serwer POP3 przypisuje każdej wiadomości numer (zaczynając od 1) oraz sprawdza wielkość każdej z nich w bajtach. Gdy serwer zmienia tryb pracy na transakcyjny, jest wyświetlana informacja o liczbie wiadomości i ich łącznej wielkości. Prezentuje to przykład na slajdzie. W trybie transakcyjnym serwer może otrzymać komendy: stat - odpowiada liczbą wiadomości oraz ich łączną wielkością w bajtach, list - podaje numer każdej wiadomości oraz jej wielkość w bajtach, retr <numer_wiadomości> - przesyła wraz z nagłówkami treść wiadomości o podanym numerze, dele <numer_wiadomości> - usuwa wiadomość o podanym numerze, noop - serwer nic nie robi, odpowiada +OK, rset - jeśli jakiekolwiek wiadomości były zaznaczone jako "usunięte" znaczniki usunięcia są cofane, top <numer_wiadomości> <liczba> - komenda może dotyczyć tylko wiadomości nie oznaczonych jako skasowane. Serwer odpowiada liczbą linii (począwszy od nagłówka) wskazanej wiadomości, uidl - <numer_wiadomości> - serwer odpowiada unikalnym numerem wiadomości. Numer ten jest zawsze stały niezależnie od sesji. Służy programom klientów do rozróżnienia, które

10 10 z :29 wiadomości są nowe, a które były już wcześniej odczytane. W przypadku nie podania numeru wiadomości serwer przedstawia identyfikatory dla wszystkich wiadomości w skrzynce, quit - rozłączenie. Oprócz identyfikacji przez nazwę użytkownika i hasło niektóre serwery POP3 mają zaimplementowaną metodę, w której użytkownik jest rozpoznawany na podstawie nazwy oraz skrótu MD5 znacznika czasowego oraz podanej frazy. W ten sposób hasło użytkownika nie jest przesyłane otwartym tekstem przez sieć. Protokół ten został zdefiniowany w dokumencie RFC1730. Jego uaktualnienie zawiera RFC3501. Przedstawione poniżej omówienie odnosi się do wersji 4 protokołu IMAP. Poprzednie, 2 i 2bis, są raczej rzadko używane. Podobnie jak POP3, protokół IMAP pozwala użytkownikom na zdalny dostęp do swoich skrzynek pocztowych na serwerach, ich modyfikowanie, przeszukiwanie, tworzenie folderów, ustawianie flag. Nie pozwala na wysyłanie wiadomości poczty elektronicznej. Klient pocztowy użytkownika, podobnie jak w poprzednim przypadku, musi nawiązać połączenie TCP z serwerem IMAP, port 143. Przed każdą komendą klient generuje dla niej identyfikator tzw. tag, np. A0001. Do serwera wysyłana jest cała komenda poprzedzona tym identyfikatorem. W przypadku wystąpienia błędu serwer odpowiada komunikatem BAD i podaje identyfikator komendy, która spowodowała błąd. W przeciwnym przypadku

11 11 z :29 serwer zwraca OK. Jest jeszcze jeden rodzaj komunikatu - NO - zwracany przez serwer, gdy wystąpi błąd nie związany z formatem komendy lub protokołem. Komendy wysyłane do/lub z serwera są w postaci normalnego tekstu. Serwery IMAP również pracują w kilku trybach. Większość komend, które klient może wydać serwerowi jest ściśle przypisana do trybu pracy. Komend jest znacznie więcej w porównaniu z protokołem POP3. Tryby pracy to: nie autentyzowany - serwer pracuje w tym stanie dopóki, użytkownik nie zostanie prawidłowo zidentyfikowany, autentyzowany - serwer przechodzi do tego trybu po podaniu przez użytkownika informacji potrzebnych do jego rozpoznania; klient musi w tym trybie wybrać skrzynkę pocztową, modyfikacje skrzynki - użytkownik może modyfikować wybraną skrzynkę, rozłączanie - zakończenie sesji. W przeciwieństwie do POP3, przy pomocy protokołu IMAPv4 użytkownik może mieć zdefiniowane na serwerze kilka katalogów ze skrzynkami pocztowymi. Dlatego też wymagane jest określenie jednej skrzynki jako głównej. Kolejne mogą być podane w dowolnej kolejności. Ponieważ to serwer wykonuje

12 12 z :29 zlecone mu zadania zarządzania skrzynkami, może on w dowolnym momencie wysłać do klienta komunikat, np. o pojawieniu się w skrzynce nowej poczty czy też prośbę o potwierdzenie usunięcia wiadomości. Co więcej, serwer może przetwarzać kolejne polecenia klienta bez czekania na zakończenie poprzednich komend. Odstępstwem od tego jest sytuacja, w której wynik działania poprzednich komend może mieć wpływ na następne. Serwer sam rozpoznaje taką sytuację i wówczas czeka na zakończenie poprzednich poleceń. Po otwarciu sesji TCP między klientem a serwerem, klient może wydać serwerowi następujące komendy: CAPABILITY - serwer odpowiada listą obsługiwanych przez niego opcji, NOOP - nie robi nic, LOGOUT - rozłączenie. Są to jedyne trzy komendy, które klient może wydać serwerowi w każdym stanie. Przedstawia to przykład na slajdzie. Po otwarciu sesji TCP z serwerem klient protokołu IMAP znajduje się w pierwszym z wymienionych trybów pracy. Przebywając w nim może wydać serwerowi komendę AUTHENTICATE lub LOGIN. Komendy te mogą mieć kilka różnych argumentów, które określają sposób autoryzacji użytkownika. Jeśli serwer obsługuje wybrany sposób autoryzacji, to rozpoczyna wysyłanie serii zapytań do klienta. Każde z tych zapytań musi zaczynać się od +. Komunikaty są kodowane przy użyciu kodowania BASE64. Jeśli klient chce przerwać proces

13 13 z :29 autoryzacji, to wysyła do serwera znak *. Oprócz samego procesu autoryzacji serwer może negocjować z klientem sposób zabezpieczenia tej sesji. Jeśli obie strony zgodzą się na stosowanie wybranego mechanizmu ochrony sesji, to jest on stosowany do każdego komunikatu wymienianego między serwerem a klientem. Nie ma jednak wymagań na to, które z metod autoryzacji muszą być obsługiwane przez serwer, jak również wymagań stosowania określonych sposobów zabezpieczania sesji. Najprostszym sposobem jest podanie nazwy użytkownika i hasła. Prezentuje to przykład na slajdzie.

14 14 z :29 Po rozpoznaniu użytkownika przez serwer następuje przejście do kolejnego z wymienionych trybów pracy. Użytkownik może wysyłać do serwera polecenia: SELECT - wybór skrzynki pocztowej; serwer musi odpowiedzieć ustawiając jedną z flag: <n> EXISTS - liczba wiadomości w skrzynce, <n> RECENT - liczba nowych wiadomości od czasu ostatniego jej czytania, OK [UIDVALIDITY <n>] - unikalny identyfikator skrzynki; jest on stały dla wszystkich sesji. Serwer może modyfikować tylko jedną skrzynkę na raz. Zmiana skrzynki powoduje, że poprzednia przestaje być dostępna. Jeśli wybrana skrzynka również okaże się niedostępna, to serwer nie będzie operował na żadnej skrzynce czekając znowu na komendę SELECT. Po wydaniu komendy SELECT skrzynka jest otwarta w trybie read-write. EXAMINE - działa tak samo jak SELECT, ale otwiera skrzynkę w trybie read-only, CRATE - tworzy nową skrzynkę o nazwie podanej

15 15 z :29 jako argument, DELETE - usuwa skrzynkę o podanej nazwie, RENAME - zmienia nazwę podanej skrzynki na nową, SUBSCRIBE - dodaje skrzynkę do zbioru aktywnych lub inaczej zapisanych; klient IMAP4 może użytkownikowi pokazywać wiadomości, pojawiające się tylko w tych skrzynkach, do których użytkownik jest zapisany, UNSUBSCRIBE - działanie odwrotne, LIST - służy do pobierania z serwera listy elementów pasujących do wzorca, z miejsca wskazanego argumentem komendy, np.: C: a005 list "~/Mail/" "% S: * LIST (\Noselect) "/" ~/Mail/foo S: * LIST () "/" ~/Mail/archive S: a005 OK LIST completed Pierwszym argumentem zazwyczaj jest katalog ze skrzynkami pocztowymi. Drugi wyszukuje skrzynki zgodnie z maską; możliwe jest podawanie wzorców np, "%", który oznacza skrzynkę o dowolnej nazwie w katalogu podanym jako argument pierwszy, LSUB - komenda działa tak samo jak LIST z tym, że brane są pod uwagę tylko skrzynki oznaczone jako aktywne, APPEND - zapisuje do wskazanej skrzynki podany argument tesktowy (wiadomość). Jak widać możliwości, które oferuje serwer IMAP, są znacznie większe niż w protokole POP3. Daje on użytkownikowi duże możliwości zarządzania swoimi wiadomościami na serwerze. Dodatkowo możliwości te są poszerzone o zbiór komend dostępny w trybie czytania wiadomości z wybranej skrzynki: CHECK - wymusza na serwerze sprawdzanie wszelkiego typu statusu lub stanów skrzynki, np. synchronizację zawartości skrzynki w pamięci serwera z zawartością zapisaną na dysku, CLOSE - usuwa wszystkie wiadomości z ustawioną flagą usunięta oraz zamyka wybraną wcześniej skrzynkę; serwer przechodzi do trybu oczekiwania wyboru skrzynki przez klienta, EXPUNGE - usuwa z aktualnej skrzynki wszystkie wiadomości z ustawioną flagę usunięta, SEARCH - przeszukuje wiadomości pod kątem zawierania wskazanego kryterium; dopuszczalne są logiczne wyrażenia: OR, AND i NOT; serwer zwraca

16 16 z :29 identyfikator wiadomości spełniającej podane warunki przeszukiwania, FETCH - pozwala na pobranie z serwera danych związanych z daną wiadomością, między innymi przez komendy (są to tylko przykłady większej liczby komend tego typu): ALL - cała wiadomość, BODY - treść wiadomości, BODY[<section>] - treść ze wskazanej sekcji (przydatne przy wiadomościach typu multipart/mixed PARTIAL - pozwala na pobranie z serwera konkretnej liczby bajtów, od wskazanej pozycji wybranej wiadomości, ALTER - zapisuje zmiany wprowadzone w wiadomości w skrzynce, COPY - zapisuje wskazaną wiadomość do wskazanej skrzynki. Z punktu widzenia użytkownika, najważniejszą funkcją oferowaną przez serwery IMAP, jest możliwość dokładnego zarządzania wiadomościami na serwerze oraz możliwość szybkiego ich odbierania. W przeciwieństwie do serwerów POP3, serwery IMAP mogą wysyłać klientowi tylko nagłówki wiadomości bez ich treści. Dla użytkowników łączących się z siecią przez zwykłe modemy jest to ogromne udogodnienie. Mogą od razu kasować niechciane wiadomości bez przesyłania ich na swój lokalny komputer. Użytkownicy mogą sortować nadchodzące przesyłki i zapisywać je do różnych skrzynek zgodnie ze zdefiniowanymi przez siebie regułami. Inną zaletą korzystania z serwerów IMAP jest możliwość rozsyłania wiadomości w grupie użytkowników bez potrzeby obciążania serwera pocztowego. Wystarczy, że zapisze on wiadomość w podanej skrzynce, którą będą mogli

17 17 z :29 wybrać użytkownicy tej grupy w konfiguracji swoich klientów IMAP. W przypadku serwera POP3 konieczne w takim wypadku jest rozesłanie wiadomości do wszystkich użytkowników. W konfiguracji klienta POP3 można też stworzyć dodatkowe konto u każdego klienta w grupie, a klientom kazać odbierać pocztę również z tych dodatkowych kont. Jest to jednak rozwiązanie bardziej złożone niż w protokole IMAP. Przesyłanie plików przez użytkowników jest jedną z najczęściej wykonywanych operacji. Stanowią one znaczną część ruchu w sieciach komputerowych. Protokoły do tego używane zapewniają dostęp do plików na innych komputerach dwiema drogami: albo przez kopiowanie (FTP, SCP) albo jako dostęp zintegrowany z systemem operacyjnym, gdzie operacje dostępu do zdalnych plików są dla użytkownika niewidoczne (NFS, CIFS). W obu jednak przypadkach protokoły muszą uwzględniać prawa dostępu do pliku (nie zawsze zapisywane w ten sam sposób jak w systemie lokalnym), różnice w nazwach plików, różnice w reprezentacjach binarnych (choć czasami konwersja formatów powodowałaby utratę danych i jest niemożliwa).

18 18 z :29 FTP (ang. File Transfer Protocol) był pierwszym z protokołów przeznaczonych specjalnie do transferu plików. Aby z niego korzystać, użytkownik musi mieć program klienta. Program klienta oferuje użytkownikowi dostęp interakcyjny. Program ten łączy się ze wskazanym serwerem FTP, próbując otworzyć sesję TCP na porcie 21. Przed wykonaniem jakichkolwiek operacji przesłania danych do lub z serwera, użytkownik musi podać identyfikator w postaci nazwy użytkownika i hasła. Serwer i klient FTP używają odrębnego połączenia do przesyłania danych sterujących oraz odrębnych połączeń do transmisji każdego z czytanych lub zapisywanych plików z osobna. Połączenie sterujące jest otwarte tak długo jak trwa sesja FTP. Wszystkie komendy wysyłane do serwera oraz jego odpowiedzi są przesyłane w kodzie ASCII (tak samo jak w przypadku SMTP, POP3, IMAP).

19 19 z :29 Do transmisji danych wykorzystywany jest protokół UDP. Klient lokalnie używa dowolnego, numeru portu niezajętego przez inną aplikację. Wysyła do serwera jego numer i czeka, aż serwer wybierze swój port. Następnie klient otwiera połączenie ze wskazanym portem i transmituje dane. Jest to tzw. tryb active pracy klienta. Serwer może również do tego celu użyć zastrzeżonego numeru portu TCP Alternatywą trybu active jest passive. W trybie tym to serwer pracuje tylko i wyłącznie na porcie 20. W trakcie pracy z serwerem użytkownik może specyfikować format zapisywanych lub odczytywanych danych (dane binarne, w kodzie ASCII). Oprócz tego może wydawać serwerowi cały szereg dodatkowych komend. Ich listę można uzyskać przez uruchomienie klienta ftp i wydaniu komendy help. Oprócz protokołu FTP istnieje TFTP (ang. Trivial FTP). W odróżnieniu od FTP protokół ten nie ma wbudowanych mechanizmów autoryzacji i nie ma możliwości pracy w trybie interakcyjnym z użytkownikiem. Dzięki temu pliki binarne klienta TFTP oraz serwera zajmują niewiele miejsca w pamięci. Korzystają z tego producenci urządzeń sieciowych, którzy na kliencie TFTP opierają możliwości instalowania nowszych wersji oprogramowania, bezdyskowe stacje robocze, które przy pomocy TFTP pobierają z serwera pliki z obrazem jądra. Sieciowy system plików (ang. Network File System) został opracowany przez firmę Sun Microsystems. System ten zapewnia użytkownikowi "przezroczysty" dostęp do plików i programów położonych na innych komputerach. Konieczne do tego jest jedynie uruchomienie serwera NFS oraz wyposażenie użytkownika w program klienta. Klient może wysyłać do serwera polecenia otwarcia, zapisania, odczytania pliku. Serwer sprawdza czy użytkownik, który wysyła te polecenia ma prawo do wykonania tych operacji. Informacje o tym są pobierane przez serwer na podstawie identyfikatora użytkownika, który albo istnieje w lokalnych dla serwera plikach konfiguracyjnych (np. /etc/passwd i musi być identyczny na stacji użytkownika i serwerze w systemach UNIX) albo są dostępne przez serwisy takie jak NIS lub NIS+ (ang. Network Information Service). Oprócz tego

20 20 z :29 serwer określa z jakimi prawami udostępniane są wskazane w konfiguracji zasoby. W szczególności może zabronić wykonywania programów z ustawionym bitem SUID [*]. Projektanci NFS oparli ten protokół o dwa wcześniej opracowane protokoły: RPC (ang. Remote Procedure Call) oraz XDR (ang. external Data Representation). Mechanizm RPC daje możliwość podzielenia kodu aplikacji na kod serwera i klienta. Programista może wydzielić wybrane funkcje jako odległe i wskazać to kompilatorowi. Kompilator wówczas dołącza odpowiednie kody procedur RPC w trakcie kompilacji programu. RPC ukrywa przed programistą wszelkie szczegóły protokołów. Dzięki temu jest chętnie wykorzystywany do budowy systemów rozproszonych. Program klient wywołując zdalną procedurę sam tworzy odpowiedni rodzaj komunikatu i wysyła go do serwera. Nawiązanie połączenia jest zupełnie niewidoczne dla użytkownika. Drugi z protokołów, XDR, daje możliwość przekazywania danych w środowisku heterogenicznym bez konieczności ich konwersji do odpowiednich typów standardów sprzętowych. Jego główną zaletą jest automatyczna konwersja formatów danych między klientami a serwerami systemu NFS. SCP (ang. Secure Copy) jest usługą najczęściej interpretowaną jako fragment oprogramowania SSH (opisanego w dalszej części). Wynika to stąd, że usługa ta jest instalowana w systemach przy okazji uruchamiania tego serwisu. Można z niej jednak korzystać bez instalacji całego SSH. W chwili obecnej dostępne są programy SCP działające zarówno w środowisku Windows (WinSCP, pscp) jak i wszelkiego typu systemach UNIX. Slajd przedstawia przykład działania programu WinSCP. W swoim działaniu, z dotychczas wymienionych usług, SCP najbardziej przypomina FTP. Oferuje mechanizm autoryzacji użytkownika przed wykonaniem operacji odczytu lub zapisu plików. W przeciwieństwie jednak do FTP, SCP nie używa dwóch odrębnych kanałów do komunikacji i transferu danych. Poza tym nie pracuje w trybie interaktywnym z użytkownikiem, choć

21 21 z :29 niektóre programy np. WinSCP pozwalają na to. To, co wyróżnia SCP, to stosowanie mechanizmów kryptograficznych przy wymianie danych między serwerem a klientem. Najczęściej są to te same mechanizmy, które oferuje SSH, gdyż to właśnie ta usługa jest wykorzystywana do zestawiania sesji, wymiany kluczy między serwerem a klientem, ustalaniu parametrów transmisji (kompresja przesyłanych danych lub jej brak, częstotliwość wymiany klucza). Dosyć często zdarza się sytuacja, w której użytkownicy chcieliby mieć możliwość korzystania z zasobów innych komputerów pracujących w odległych miejscach, nie posiadając dostępu do konsoli tych maszyn. Jednym ze sposobów zapewniających ten rodzaj pracy są serwisy WWW, np. wyszukiwarki internetowe. Poprzez odpowiedni interfejs oferują one dostęp do bazy adresów oraz możliwość ich przeszukiwania. Nie zawsze jednak chodzi tylko o tego typu dostęp. Często np. studenci chcą korzystać z kompilatorów zainstalowanych na serwerach uczelnianych, pracownicy ze specjalistycznego oprogramowania używanego w firmie, itd. Wówczas nieocenione stają się możliwości korzystania z opisanych poniżej protokołów oferujących dostęp do wszystkich poleceń na odległym systemie.

22 22 z :29 Protokół ten umożliwia użytkownikowi zestawienie sesji TCP między dwoma odległymi systemami. Na jednym z nich musi pracować proces serwera TELNET. Użytkownik musi być wyposażony w program klienta. Użytkownik może wskazać serwer TELNET podając jego nazwę lub numer IP. Serwer przeprowadza autoryzację użytkownika. W tym celu musi on podać nazwę użytkownika i hasło. Jednak przesyłane dane, pomiędzy klientem i serwerem, nie są w żaden sposób zabezpieczone przed podsłuchem. Po nawiązaniu sesji TCP klient przesyła do serwera informacje o wszystkich naciśniętych klawiszach. Zwrotnie przyjmuje znaki, które przysłał serwer i wyświetla je na terminalu użytkownika. Ponieważ serwer TELNET musi obsługiwać wiele sesji jednocześnie, zazwyczaj jeden proces serwera oczekuje na nowe połączenia na porcie 23 TCP. Dalej przekazuje on obsługę połączenia

23 23 z :29 tworzonemu w tym celu procesowi podrzędnemu. Dla użytkownika, po nawiązaniu sesji przy pomocy TELNET, praca z odległym systemem przebiega w sposób przypominający pracę na lokalnej konsoli. Największy problem, z jakim mieli do czynienia autorzy tego protokołu, to różnorodność systemów operacyjnych na jakich może działać klient i serwer. Heterogeniczność środowisk niesie za sobą różną interpretację znaków pochodzących z klawiatury, możliwość używania 7 bitowego lub 8 bitowego zbioru znaków ASCII. W celu rozwiązania problemu TELNET definiuje tzw. sieciowy terminal wirtualny (ang. Network Virtual Terminal - NVT). Dzięki niemu klient i serwer posługują się tym samym interfejsem w komunikacji między sobą. Poza tym protokół umożliwia negocjowanie opcji (oprócz zbioru opcji standardowych) oraz nie wymaga, aby dane wejściowe klienta pochodziły z klawiatury, a dane wyjściowe były wyświetlane na ekranie. Sieciowy terminal wirtualny wykorzystuje mechanizm tzw. pseudoterminali w systemach operacyjnych.

24 24 z :29 Oferują one działającym programom dostęp do systemu przekazując znaki przesyłane przez klienta tak jakby pochodziły z klawiatury. Bez tego mechanizmu budowa serwerów TELNET byłaby niemożliwa. To, czy wiersze tekstu powinny się kończyć znakiem CR, LF, czy też CR-LF, który z klawiszy (lub ich sekwencji) daje możliwość przerwania programu, zależy od systemu operacyjnego. Dlatego też polecenia użytkownika są tłumaczone na format NVT i wysyłane do serwera. Wirtualny terminal po stronie serwera tłumaczy je na format swojego systemu operacyjnego. Podobnie dzieje się przy przesyłaniu odpowiedzi serwera do klienta. Umożliwienie przerywania działających programów jest bardzo istotne. Dzięki temu program, działający bez kontroli, wywołany przez użytkownika, może zostać zatrzymany bez zbędnego obciążania serwera. NVT do tego celu używa funkcji sterujących pokazanych na slajdzie. Projektanci NVT zdecydowali o rozdzieleniu poleceń od zwykłych danych przesyłanych w kodzie ASCII między klientem a serwerem. Dzięki temu definiowanie nowych funkcji kontrolnych jest bardzo przejrzyste i elastyczne. Nie ma kłopotu z interpretacją, czy znak powinien być potraktowany jako dane czy jako funkcja kontrolna. Aby zapanować nad programem, który nie działa prawidłowo na odległej maszynie, to jednak czasami nie wystarczające. W przypadku, gdy program użytkownika wykonuje nieskończone pętle, nie czytając danych z wejścia i nie generując danych na wyjściu, w pewnym momencie bufory systemu operacyjnego mogą się zapełnić. Serwer nie będzie mógł wówczas zapisać większej ilości danych w buforze pseudoterminalu. Musi więc zaprzestać czytania danych z połączenia TCP, co spowoduje zapełnienie buforów