Protokoły przesyłania plików

• File Transfer Protocol (FTP)

• Trivial File Transfer Protocol (TFTP)

• HyperText Transfer Protocol (HTTP)

• Network File System (NFS)

• Web Distributed Authoring and Versioning (WebDAV)
  - Rozproszone tworzenie i obsługa wersji w WWW

• Remote Copy Protocol (RCP) - Protokół zdalnego kopiowania

Protokół przesyłania plików
File Transfer Protocol (FTP)

Protokół FTP, zdefiniowany w dokumencie RFC 959
uaktualnionym przez RFC 2228,

Jeden z najstarszych protokołów internetowych
i zarazem jeden z najszerzej stosowanych

Wykorzystuje oddzielne połączenia dla poleceń i dla danych

• Proces przesyłania danych (DTP - Data Transfer Processes) przesyła dane pomiędzy klientem a serwerem FTP

• Interpretator protokołu (PI - Protocol Interpreter) przesyła polecenia pomiędzy klientem a serwerem FTP

DTP i PI korzystają z oddzielnych sesji TCP.

Serwer FTP oczekują na sygnał od klienta na porcie 21

Serwer inicjuje połączenia przesyłania danych z portu 20 serwera
do przydzielonego losowo portu klienta.

Połączenie przesyłania danych może być stosowane w obu kierunkach i nie musi istnieć przez cały czas.

Passive FTP - w odpowiedzi na wysłane przez klienta polecenie PASV
server przesyła do niego numer portu (powyżej 1024), na którym oczekuje połączenia inicjowanego przez klienta oraz przesyłu danych.

• Polecenia sterujące dostępem

• Polecenia sterujące przesyłaniem

• Polecenia przesyłania plików

• Polecenia zarządzania plikami i katalogami

• Polecenia pomocy i kontroli sesji

• Odpowiedzi serwera FTP

Polecenia FTP sterujące dostępem

Polecenie	Opis
OPEN [serwer]	Ustanawia sesję FTP z serwerem
USER [nazwa]	Określa użytkownika (pierwsze polecenie)
PASS [hasło]	Przesłanie hasła użytkownika (drugie polec.)
...
QUIT	Koniec sesji

Polecenia FTP sterujące przesyłaniem

Polecenie	Opis
PORT ##	Wybór gniazda po stronie klienta ##=a,a,a,a,p,p gdzie a i p - kolejne bajty adresu IP i nr portu
PASV	Polecenie Passive - serwer będzie pasywnie oczekiwał na ustanowienie sesji danych przez klienta
TYPE	Polecenie Representation Type - określa format repr. danych serwera: ASCII, EBCDIC, Image
STRU	Polecenie File Structure: files, records, pages
MODE	Polecenie Transfer Mode: Stream, Block, Compressed

Struktura plików i tryby przesyłania protokołu FTP

struktura pliku — nie ma żadnej struktury wewnętrznej, a plik uważany jest za nieprzerwany ciąg bajtów danych,

struktura rekordu — plik składa się z rekordów sekwencyjnych,

struktura strony — plik składa się z niezależnych stron indeksowanych.

Strukturą domyślną jest struktura pliku, ale zarówno struktura pliku, jak i struktura rekordu są akceptowane dla plików tekstowych, takich jak pliki ASCII, przez wszystkie implementacje protokołu FTP. Struktura pliku ma wpływ zarówno na jego tryb przesyłania, jak i na jego interpretację i przechowywanie.

Są trzy tryby przesyłania:

Tryb strumieniowy — plik jest transmitowany jako strumień bajtów, bez żadnych ograniczeń dotyczących wykorzystywanego typu danych. Dozwolone są struktury rekordu.

W pliku o strukturze rekordu, koniec rekordu (End-of-Record, EOR) oraz koniec pliku (End-of-File, EOF) identyfikowane są po 2-bajtowym kodzie kontrolnym. W strukturze pliku, zamknięcie połączenia przesyłania danych przez hosta wysyłającego wyznacza EOF. Wszystkie bajty w komunikacie o strukturze pliku są więc bajtami danych.

Tryb blokowy — plik jest transmitowany jako szereg bloków danych poprzedzonych jednym lub większą ilością bajtów nagłówka. Bajty nagłówka zawierają pole liczby oraz kod deskryptora. Pole liczby zawiera całkowitą długość bloku danych w bajtach, oznaczając w ten sposób początek następnego bloku danych. Kod deskryptora definiuje atrybuty bloków, takie jak ostatni blok w pliku (EOF), ostatni blok w rekordzie (EOR), znacznik ponownego uruchomienia, czy dane podejrzane. W tym trybie dozwolone są struktury rekordu i może być stosowany każdy typ reprezentacji.

Tryb skompresowany — umożliwia kompresję danych składających się z bajtów wypełniacza lub replikacji. Nagłówek trybu zagęszczonego określa liczbę takich bajtów (do 127). Te są następnie wysyłane po upakowaniu do pojedynczego bajta.

Polecenia FTP służące do przesyłania plików

Polecenie	Opis
ASCII	Włącza tryb ASCII jest to tryb domyślny
BINARY	Włącza tryb binarny - stosowany do przesyłania wszystkich typów plików - poza tekstowymi
TYPE	Kontrola trybu
PUT [plokalny] [pzdalny]	= SEND
GET [pzdalny] [plokalny]	= RECV
MPUT [plokalny]
MGET [pzdalny]
PROMPT

Polecenia FTP do zarządzania plikami i katalogami

Polecenie	Opis
DELETE [pzdalny]
MDELETE [pzdalny]
LCD [katalog]
CD [katalog]
MKDIR [katalog]
RMDIR [katalog]
RENAME [naz1] [naz2]
DIR, LS
PWD

Polecenia pomocy i kontroli stanu sesji

Polecenie	Opis
!
?
HELP
STATUS
VERBOSE
OPEN
CLOSE
BYE

Komendy klienta ftp
! [command] [args]]	wywołuje powłokę na lokalnym komputerze, powrót do programu ftp po wydaniu komendy exit.
append local-file [remote-file]	kopiuje plik [local-file] dodając go do końca pliku [remote-file].
ascii	ustawia tryb przesyłania plików na tekstowy.
bell	powoduje, że po zakończeniu transferu ftp generuje sygnał dźwiękowy.
binary	ustawia tryb przesyłania plików na binarny.
bye	kończy połączenie ze zdalnym komputerem i pracę programu.
cd remote-directory	ustawia katalog roboczy na zdalnym komputerze.
close	zamyka połączenie ze zdalnym komputerem nie kończąc pracy programu ftp.
delete remote-file	kasuje plik na zdalnym komputerze.
dir [remote-directory] [local-file]	listuje zawartoć katalogów na zdalnym komputerze.
disconect	zamyka połączenie ze zdalnym komputerem nie kończąc pracy programu ftp.
get  remote-file [local-file]	kopiuje plik ze zdalnego komputera do komputera lokalnego.
glob	przełącza rozszerzenie nazw plików zgodnie z konwencją stosowaną w csh.
hash	przełącza drukowanie znaków po przesłaniu każdego bloku 1024 bajtów danych.
help [command]	wyświetla podstawowe informacje o dostępnych komendach programu ftp.
lcd [local-directory]	zmienia lokalny katalog roboczy na katlog [local-directory]
literal	wysyła samodzielnie polecenie ftp.
ls	listuje zawartość katalogów na zdalnym komputerze.
mdelete [remote-files]	kasuje zbiory plików na zdalnym komputerze.
mget [remote-files]	kopiuje zbiory plików ze zdalnego komputera.
mkdir directory-name	tworzy na zdalnym komputerze katalog o podanej nazwie.
mls remote-files local-files	zapisuje skrócony listing katalogu zdalnego komputera na komputerze lokalnym.
mput local-files	kopiuje pliki z lokalnego komputera na zdalny.
open server-host [port-number]	otwiera połączenie z serwerem używając portu o numerze port-number.
prompt	przełącza opcję interaktywnego potwierdzania podczas przesyłania każdego pliku w trakcie wykonywania komend mget, mput i podczas listowania komendą dir.
put local-file	kopiuje plik na zdalny komputer.
pwd	wypisuje nazwę bieżącego katalogu na zdalnym komputerze.
quit	kończy połączenie ze zdalnym komputerem i pracę programu.
quote arguments	wysyła argument w niezmienionej postaci do serwera.
recv remote-file	kopiuje plik ze zdalnego komputera do komputera lokalnego.
remotehelp command-name	żada informacji o komendach realizowanych przez serwer.
rename remote-from remote-to	zmienia nazwę pliku
rmdir remote-directory	kasuje katalog na zdalnym komputerze.
send local-file [remote-file]	kopiuje plik na zdalny komputer.
status	informuje w jakim stanie znajduje się program ftp.
trace	przełącza śledzenie pakietów.
type [type-name]	ustawia tryb transmisji plików
user user-name [password] [account]	wysyła informacje o nowym użytkowniku
verbose	przełącza tryb pełnej informacji.
?	drukuje pomoc.

Kody odpowiedzi serwera (pierwszy znak)

Wartośc	Nazwa
1yz	Pozytywna odpowiedź wstępna
2yz	Pozytywna odpowiedź końcowa
3yz	Pozytywna odpowiedź pośrednia
4yz	Negatywna odpowiedź tymczasowa
5yz	Negatywna odpowiedź trwała

Kody odpowiedzi serwera (drugi znak)

Wartośc	Nazwa
X0z	Składnia
x1z	Dane
x2z	Połączenie
x3z	Uwierzytelnienie i rejestracja
x4z	Nieokreślony
x5z	System plików

RFC 959Prosty protokół przesyłania plików (TFTP)

Protokół TFTP, zdefiniowany w specyfikacji RFC uaktualnianej przez RFC 1783, 1785, 2347 oraz 2349, jest względnie prostym protokołem wykorzystywanym do przesyłania plików, które są (zazwyczaj) małe
i nie wymagają wiele fragmentacji.

Jest on implementowany na protokole UDP, chociaż jego definicja nie wyklucza stosowania innych protokołów datagramów.

Jest on pozbawiony większości funkcji protokołu FTP — na przykład nie może wyświetlać katalogów, ani uwierzytelniać użytkowników —
a jego jedynym zadaniem jest odczytywanie plików z komputera zdalnego i transmitowanie do niego plików.

Protokół TFTP jest przeważnie wykorzystywany do pobierania plików inicjujących drukarek, koncentratorów, przełączników, ruterów

Używają go także bezdyskowe stacje będące klientami DHCP.

MS wykorzystuje TFTP do instalacji zdalnej.

Przesył TFTP rozpoczyna się od żądania odczytu lub zapisu pliku, które żąda również połączenia.

Plik wysyłany jest w blokach o stałej długości 512 bajtów.

Każdy z pakietów musi być potwierdzony przez pakiet potwierdzający, zanim będzie mógł zostać wysłany następny pakiet.

Pakiet danych mniejszy niż 512 bajtów wskazuje zakończenie przesyłu.

Jeżeli jakiś pakiet ulegnie zagubieniu, to u planowanego odbiorcy następuje przeterminowanie, a ten następnie żąda przesyłania zagubionego pakietu.

Pakiet retransmitowany w tym przypadku, to ostatni pakiet poprzedniej przesyłania, więc nadawca musi zachować do reprzesyłania tylko jeden pakiet. Poprzednie potwierdzenia gwarantują, że pakiety uprzednio wysłane zostały otrzymane.

Każdemu z pakietów danych towarzyszy numer bloku.
Numery bloków są kolejne i zaczynają się od jeden, za wyjątkiem pozytywnej odpowiedzi na żądanie zapisu, która jest pakietem potwierdzającym o numerze bloku zero. Zazwyczaj pakiet potwierdzający zawiera numer bloku potwierdzanego pakietu danych.

Tryby przesyłania protokołu TFTP

Protokół TFTP obsługuje trzy tryby przesyłania,
chociaż tylko dwa z nich są zazwyczaj wykorzystywane:

Netascii — standardowy 8-bitowy kod ASCII zmodyfikowany przez specyfikację protokołu Telnet (RFC 854).

Octet — wykorzystywany do przesyłania informacji bit po bicie. Tryb ten składa się z „surowych” 8-bitowych bajtów i jest on podobny do trybu binarnego protokołu FTP.

Poczta — znaki Netascii wysyłane do użytkownika zamiast pliku. Choć jest wciąż obsługiwany, tryb ten jest przestarzały i nie powinien być implementowany ani używany.

System Windows 2000 domyślnie obsługuje tylko tryby netascii i oktet.

Struktura pakietów protokołu TFTP

Protokół TFTP obsługuje pięć typów pakietów, z których każdy ma swój własny kod operacji (opcode).

Typy pakietów TFTP

Opcode	Typ pakietu
1	Żądanie odczytu (RRQ)
2	Żądanie zapisu (WRQ)
3	Dane (DATA)
4	Potwierdzenie (ACK)
5	Błąd (ERROR)

Pakiety RRQ i WRQ zawierają następujące pola:

Opcode — to 16-bitowe pole zawiera opcode,

Filename — to pole o zmiennej długości zawiera nazwę pliku, który ma zostać przesłany jako ciąg bajtów netascii.

Filename terminator — to 8-bitowe pole zawiera wartość zero, która wskazuje koniec pola Filename.

Mode — to pole o zmiennej długości zawiera netascii, oktet, lub (rzadko) poczta jako szereg bajtów netascii. Tekst może być napisany dużymi literami, małymi literami, lub połączeniem jednych i drugich.

Mode terminator — to 8-bitowe pole zawiera wartość zero, która wskazuje koniec pola Mode.

Specyfikacja RFC 2347 rozszerza pakiety RRQ i WRQ, aby hosty wysyłające i odbierające mogły negocjować dodatkowe opcje TFTP. Do potwierdzania żądania negocjacji opcji zgłoszonego przez klienta wykorzystywany jest nowego typu pakiet TFTP, potwierdzenie opcji (OACK). Specyfikacja RFC 2349 jeszcze bardziej rozszerza pakiety RRQ i WRQ, aby umożliwić hostom protokołu TFTP uzgadnianie interwałów przeterminowania oraz rozmiarów przesyłu. Pełne szczegóły podane są w dokumentach RFC.

Do wysyłania określonego pliku wykorzystywane są pakiety DATA; zawierają one następujące pola:

Opcode — w przypadku pakietów DATA, to 16-bitowe pole zawiera wartość 3.

Numer bloku — to16-bitowe pole zawiera numer bloku. W przypadku pakietów DATA, zaczyna się ono od 1 i wzrasta o 1 wraz z każdym wysłanym blokiem danych.

Data — to pole o zmiennej długości zawiera dane. W przypadku tradycyjnego TFTP to pole zawiera 512 bajtów — chyba że pakiet sygnalizuje koniec przesyłu; w takim wypadku pole Data zawiera mniej niż 512 bajtów. Jeżeli wynegocjowana zostanie opcja rozmiaru bloku, to rozmiar pola dla przesyłu danych może być inny niż 512 bajtów. Koniec przesyłu, podobnie jak wcześniej, będzie sygnalizowany przez mniejszy rozmiar pola.

Potwierdzane są wszystkie pakiety, poza podwojonymi ACK oraz pakietami DATA sygnalizującymi zakończenie, chyba że wystąpi przeterminowanie. Pakiet DATA potwierdza pakiet ACK poprzedniego pakietu DATA. Pakiety ACK lub ERROR potwierdzają pakiety WRQ i DATA, a pakiety DATA lub ERROR potwierdzają pakiety RRQ oraz ACK. Pakiet ACK o numerze bloku zero potwierdza WRQ.

Pakiet ACK zawiera następujące pola:

Opcode — w przypadku pakietów ACK, to 16-bitowe pole zawiera wartość 4.

Block number — numer bloku w pakiecie ACK potwierdza numer bloku pakietu DATA, który potwierdza. To pole zawiera wartość zerową, jeśli ACK potwierdza WRQ.

Pakiet ERROR może być potwierdzeniem każdego innego typu pakietu. Zawiera on następujące pola:

Opcode — w przypadku pakietów ERROR to 16-bitowe pole zawiera wartość 5.

Error code — to 16-bitowe pole zawiera kod błędu,

Errmsg — to pole o zmiennej długości zawiera czytelny dla człowieka komunikat o błędzie w netascii.

Errmsg terminator — to 8-bitowe pole zawiera wartość zerową
i wskazuje koniec komunikatu o błędzie. Jest ono czasem uważane za część pola errmsg, a nie oddzielne pole.

Kody błędów TFTP

Kod błędu	Znaczenie
0	Niezdefiniowany. Sprawdź komunikat o błędzie (jeżeli jest).
1	Nie znaleziono pliku.
2	Naruszenie dostępu.
3	Dysk pełny lub przekroczona alokacja.
4	Zabroniona operacja TFTP.
5	Nieznana tożsamość przesyłu.
6	Plik już istnieje.
7	Nie ma takiego użytkownika.

Protokół przesyłania hipertekstu (HTTP)

Protokół HTTP w wersji 1.1, opisany w dokumencie RFC 2068, jest faktycznym standardem przesyłu dokumentów WWW.

Działa on poprzez połączenia protokołu TCP, zazwyczaj wykorzystując port 80, chociaż można określić inny port (na przykład 8080).

Po ustanowieniu połączenia, klient transmituje do serwera komunikat żądania, a ten wysyła odpowiedź.

Protokół HTTP jest zazwyczaj wykorzystywany przez takie aplikacje, jak przeglądarki.

Najprostszą funkcją, lub metodą, protokołu HTTP jest GET, która pobiera informacje zapamiętane w witrynie WWW, lub na serwerze WWW. Jednak systemy informacyjne o pełnych możliwościach wymagają szerszego zestawu funkcji, łącznie z wyszukiwaniem, uaktualnianiem oraz przypisami.

Protokół HTTP zapewnia zestaw metod sygnalizujących cel danego żądania. Wykorzystuje on ujednolicony identyfikator zasobów (URI) albo jako ujednolicony lokalizator zasobów (URL), albo jako ujednoliconą nazwę zasobów (URN), aby wskazać zasób, wobec którego ma zostać zastosowana metoda. Komunikaty są przekazywane w formacie podobnym do tego, który wykorzystuje poczta internetowa, zdefiniowanym przez standard uniwersalnych rozszerzeń internetowej poczty elektronicznej (MIME)
(RFC od 2045 do 2049).

Protokół HTTP jest również używany do komunikacji pomiędzy agentami użytkownika a bramami do innych systemów internetowych, łącznie z tymi, które są obsługiwane przez protokoły SMTP, NNTP oraz FTP. W ten sposób umożliwia on podstawowy dostęp hipermedialny do zasobów dostępnych z różnorodnych aplikacji.

Metody HTTP

Dokument RFC 2616 definiuje zestaw wspólnych metod HTTP.

Dokument ten nie wyklucza dodatkowych metod, ale przestrzega,
iż metody spoza wspólnej listy „mogą nie posiadać takiej samej semantyki dla oddzielnie rozszerzonych klientów i serwerów”. Innymi słowy, jeżeli zdefiniujesz i będziesz korzystał z dodatkowych metod, to mogą wystąpić niezgodności pomiędzy niektórymi hostami i niektórymi serwerami.

Wspólne metody HTTP są następujące:

OPTIONS — pozwala klientowi ustalić opcje i/lub wymagania związane z danym zasobem, albo możliwości danego serwera, nie implikując działań zasobu i nie inicjując pobierania zasobu.

GET — pobiera informacje (w formie jednostki) zidentyfikowane przez URI, do którego zostało zgłoszone żądanie.

Warunkowy komunikat GET zawiera pole nagłówka If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, lub If-Range.
Pozwala to na odświeżanie buforowanych jednostek bez potrzeby wielokrotnego przesyłu, czy żądania danych, które są już w posiadaniu klienta.
GET częściowy żąda, aby przesłana została tylko część jednostki, określona przez pole nagłówka Range.

HEAD — identyczny z GET, z tym że serwer nie zwraca w odpowiedzi treści komunikatu. Metoda ta uzyskuje informacje dotyczące jednostki nie przesyłając samej treści jednostki i jest wykorzystywana do testowania ważności, dostępności oraz niedawnych modyfikacji łączy hipertekstowych.

POST — żąda, aby serwer przyjął załączone dane, jako nową publikację zasobu zidentyfikowanego przez URI, do którego zostało zgłoszone żądanie. POST jest wykorzystywany do przypisywania zasobów, do wysyłania komunikatów (na przykład do elektronicznego biuletynu informacyjnego), do przedkładania danych formularzy oraz do rozszerzania bazy danych poprzez operację dołączania. Funkcja pełniona przez metodę POST określana jest przez serwer i zazwyczaj jest uzależniona od URI.

PUT — żąda, aby załączone dane w żądaniu zostały zapamiętane pod wskazanym URI, do którego zostało zgłoszone żądanie. Jeżeli dany zasób wspomniany w URI już istnieje, to przesyłaną jednostkę uznaje się za wersję zmodyfikowaną. Jeżeli URI nie wskazuje na istniejący zasób, a żądający użytkownik może zdefiniować URI jako nowy zasób, to zasób jest tworzony na serwerze.

DELETE — żąda, aby serwer usunął zasób zidentyfikowany przez URI.

TRACE — wywołuje zdalną pętlę zwrotną komunikatu żądania. Ostateczny odbiorca żądania odbija otrzymany komunikat z powrotem do klienta. TRACE pozwala klientowi zobaczyć co jest odbierane na drugim końcu łańcucha żądania. Informacja ta może być wykorzystywana do testowania, lub znajdywania uszkodzeń.

CONNECT — nazwa metody zarezerwowana do wykorzystywania wraz z proxy, który może dynamicznie przełączyć się na pełnienie funkcji tunelu, przy użyciu, na przykład,
tunelowania z wykorzystaniem warstwy zabezpieczeń łączy (SSL). Proxy to program pośredniczący, pełniący zarówno funkcję serwera, jak i klienta, w celu zgłaszania żądań w imieniu innych klientów.

Kody stanu protokołu HTTP

Kody stanu HTTP są wykorzystywane przez metody podczas normalnej pracy, albo wysyłane do użytkownika, jeżeli wystąpi błąd. Jest pięć klasyfikacji kodów stanu:

Informacyjny (1xx) — sygnalizuje prowizoryczną (zazwyczaj pośrednią) odpowiedź. Te kody wskazują, że dana metoda przebiega normalnie i miało miejsce oczekiwane zdarzenie. Jeżeli serwer protokołu HTTP 1.1 wykryje klienta protokołu HTTP 1.0, to nie będzie wysyłał komunikatów informacyjnych, ponieważ nie są one zdefiniowane dla HTTP 1.0.

Pomyślny (2xx) — sygnalizuje, że żądanie klienta zostało pomyślnie otrzymane, zrozumiane i przyjęte.

Readresowanie (3xx) — sygnalizuje, że agent użytkownika musi podjąć dalsze działania, aby spełnić żądanie. Działania te mogą być przeprowadzane automatycznie przez agenta użytkownika (jeżeli wykorzystywaną metodą jest GET, lub HEAD) albo mogą wymagać interwencji użytkownika.

Błąd klienta(4xx) — sygnalizuje, że występuje, lub wydaje się, że występuje, błąd klienta. Za wyjątkiem przypadku odpowiadania na żądanie HEAD, komunikat zawiera wyjaśnienie błędu i informuje użytkownika, czy jest on tymczasowy, czy stały.

Błąd serwera (5xx) — sygnalizuje, że serwer zdaje sobie sprawę,
iż wygenerował błąd, albo że nie jest w stanie wykonać żądania.
Za wyjątkiem przypadku odpowiadania na żądanie HEAD, komunikat zawiera wyjaśnienie błędu i informuje użytkownika, czy jest on tymczasowy, czy stały.

Wskazówka: Witryny WWW znajdujące się na serwerze IIS systemu Windows 2000 mogą być konfigurowane tak, aby wysyłały wygodne w użyciu komunikaty o błędach.

Poniższa tabela podaje kody stanu i komunikaty protokołu HTTP.
Szczegóły można znaleźć w paragrafie 10 dokumentu RFC 2616.

Kody stanu i komunikaty protokołu HTTP

Kod stanu	Komunikat	Kod stanu	Komunikat
100	Kontynuuj	404	Nie znaleziony
101	Przełączanie protokołów	405	Metoda niedozwolona
200	OK	406	Nie do przyjęcia
201	Utworzony	407	Wymagane uwierzytelnienie proxy
202	Przyjęty	408	Przeterminowanie żądania
203	Nie autorytatywny	409	Konflikt
204	Bez treści	410	Minęło
205	Resetuj treść	411	Wymagana długość
206	Treść częściowa	412	Warunek wstępny nie powiódł się
300	Wiele opcji	413	Jednostka żądania zbyt duża
301	Przeniesiony na stałe	414	URI żądania zbyt duży
302	Znaleziony	415	Nieobsługiwany typ nośnika
303	Zobacz inny	416	Żądany zakres nie do spełnienia
304	Nie zmodyfikowany	417	Oczekiwanie nie powiodło się
305	Użyj proxy	500	Wewnętrzny błąd serwera
307	Readresowanie tymczasowe	501	Nie zaimplementowany
400	Złe żądanie	502	Zła brama
401	Nieautoryzowany	503	Usługa niedostępna
402	Wymagana opłata	504	Przeterminowanie bramy
403	Wzbroniony	505	Nieobsługiwana wersja HTTP

Zabezpieczony protokół HTTP (HTTPS)

Sieć WWW jest intensywnie wykorzystywana do wymiany informacji na skalę ogólnoświatową, szczególnie dla potrzeb biznesowych. Pociąga to za sobą kilka kwestii związanych z bezpieczeństwem:

Uwierzytelnianie serwerów — klienty muszą sprawdzać, czy serwer,
z którym się komunikują jest tym, za kogo się podaje.

Uwierzytelnianie klientów — serwery muszą sprawdzać tożsamość klienta i wykorzystywać ją jako podstawę podejmowania decyzji dotyczących kontroli dostępu.

Poufność — aby zapobiec przechwytywaniu poufnych informacji przesyłanych poprzez publiczne łącza internetowe, potrzebne jest szyfrowanie danych pomiędzy klientem a serwerem.

Protokół SSL wersji 3 (SSL3) oraz protokół zabezpieczeń warstwy transportu (TLS) odgrywają ważną rolę przy zaspokajaniu tych potrzeb. SSL3 i TLS są elastycznymi protokołami zabezpieczeń, które mogą być umiejscowione w górnej warstwie protokołów transportowych, takich jak HTTP. Bazują one na technologii uwierzytelniania opartego na kluczach publicznych (PK) i wykorzystują opartą na PK negocjację kluczy do generowania niepowtarzalnego klucza szyfrującego dla każdej sesji typu klient — serwer. Kiedy dla danej strony WWW włączone jest szyfrowanie SSL, to rezultatem tego jest zabezpieczony protokół HTTP, określany jako HTTPS. Procedura mająca na celu ustawienie zabezpieczonej witryny WWW opisana jest w podrozdziale rozwiązań natychmiastowych niniejszego rozdziału.

Wskazówka: IIS5 mogą być zabezpieczane przy użyciu innych protokołów niż SSL3/TLS — na przykład Fortezza, Digest Authentication, PKCS#7 oraz PKCS#10 (PKCS jest akronimem od Public Key Cryptography Standard — standard kryptografii klucza publicznego). Domyślny protokół uwierzytelniania systemu Windows 2000, Kerberos 5

Prosty protokół przesyłania poczty
Simple Mail Transfer Protocol (SMTP)

Protokół SMTP, zdefiniowany w dokumencie RFC 821, jest zaprojektowany do niezawodnego i wydajnego przesyłania poczty elektronicznej. Jest on niezależny od zastosowanego protokołu przesyłania i wymaga jedynie niezawodnego kanału uporządkowanego strumienia danych.

Oznacza to, że SMTP będzie działał poprzez (na przykład) usługę transportu protokołu kontroli sieci (NCP), czy niezależną od sieci usługę transportu (NITS), jak również poprzez TCP.

A zatem protokół SMTP może przekazywać pocztę w obrębie różnych środowisk usług transportu.

Jak działa protokół SMTP

Kiedy użytkownik zgłasza żądanie poczty elektronicznej
(tj. wysyła wiadomość poczty elektronicznej), ma miejsce następujący ciąg zdarzeń:

1. Nadawca (klient) SMTP inicjuje połączenie na port 25 serwera. Serwer sygnalizuje akceptację komunikatem 220 <Ready>.

2. Nadawca żąda ustanowienia sesji wysyłając polecenie HELO (lub EHLO) wraz ze swoją w pełni kwalifikowaną nazwą domenową.
   Serwer odpowiada komunikatem 250 <OK>

3. Nadawca SMTP wysyła polecenie MAIL TO, wskazujące nadawcę poczty. Jeżeli odbiorca SMTP może przyjąć pocztę, to reaguje odpowiedzią OK.

4. Nadawca SMTP wysyła polecenie RCPT, identyfikujące adresata poczty. Jeżeli odbiorca SMTP może przyjąć pocztę dla tego adresata, to reaguje odpowiedzią OK; jeżeli nie, to reaguje odpowiedzią odrzucającą tego adresata (ale nie całą transakcję pocztową, ponieważ nadawca i odbiorca mogą wynegocjować kilku adresatów).

5. Kiedy adresaci zostaną wynegocjowani, nadawca SMTP wysyła dane pocztowe. Jeżeli odbiorca SMTP przetworzy dane pomyślnie, to reaguje odpowiedzią OK.

6. Nadawca sygnalizuje koniec danych sekwencją CR-LF . CR-LF
   Odbiorca (serwer) zamyka sesję i wysyła komunikat 221.

Jeżeli host wysyłający i odbierający są połączeni z tą samą usługą transportu, to SMTP może transmitować pocztę bezpośrednio od nadawcy do odbiorcy. W przeciwnym razie wiadomość transmitowana jest poprzez jeden lub więcej serwerów przekazujących. W takim przypadku serwer przekazujący SMTP musi otrzymać nazwę ostatecznego hosta docelowego, jak również nazwę docelowej skrzynki pocztowej.

SMTP może implementować usługę przekazywania, która jest wykorzystywana, kiedy ścieżka określona przez polecenie RCPT jest niewłaściwa, ale odbiorca SMTP zna właściwe miejsce docelowe. W tym przypadku wysyłana jest jedna z następujących odpowiedzi, w zależności od tożsamości nadawcy i odbiorcy oraz od tego, czy odbiorca SMTP może wziąć na siebie odpowiedzialność za przekazanie wiadomości:

Polecenia VRFY oraz EXPN protokołu SMTP, odpowiednio, weryfikują nazwę użytkownika i rozwijają listę dystrybucyjną. Obydwa polecenia mają ciągi znaków jako argumenty. Ciągiem w przypadku polecenia VRFY jest nazwa użytkownika, a odpowiedź musi zawierać skrzynkę pocztową użytkownika i może zawierać pełną nazwę użytkownika.

Ciąg w przypadku polecenia EXPN identyfikuje listę dystrybucyjną, a odpowiedź musi zawierać skrzynkę pocztową użytkownika i może zawierać pełną nazwę użytkownika.

Wskazówka: Dokument RFC wykazuje, całkiem umyślnie, ambiwalencję w kwestii określenia „nazwa użytkownika”. W niektórych systemach poczty elektronicznej nazwa użytkownika jest tym samym, co skrzynka pocztowa użytkownika. Jeśli dany system poczty elektronicznej postanowi wybrać jakiś inny ciąg na nazwę użytkownika, to specyfikacja zezwala na to pod warunkiem, że ciągi dla polecenia VRFY i odpowiedzi EXPN również identyfikują skrzynkę pocztową użytkownika.

Wysyłanie i wysyłanie pocztą

Niektóre hosty dostarczają wiadomości do terminala użytkownika (pod warunkiem, że użytkownik jest aktywny na danym hoście), a nie do skrzynki pocztowej użytkownika. Dostawa do skrzynki pocztowej zwana jest wysyłaniem pocztą; dostawa do terminala zwana jest wysyłaniem. Implementacje wysyłania pocztą i wysyłania są prawie identyczne i w SMTP są one zazwyczaj połączone. Jednak użytkownicy powinni być w stanie kontrolować, czy na ich terminalach pisane są wiadomości; przy czym dokument RFC 821 definiuje polecenia wysyłania (choć nie są one wymagane przy implementacji minimalnej).

Aby obsłużyć funkcję wysyłania, można zamiast polecenia MAIL użyć w transakcji pocztowej następujących poleceń:

SEND — dostarcza dane pocztowe do terminala użytkownika. Jeżeli dany użytkownik nie jest aktywny na danym hoście (albo nie przyjmuje wiadomości terminala), może zostać zwrócona odpowiedź 450 (patrz: tabela 9.5).

SOMAIL (wyślij lub wyślij pocztą) — dostarcza pocztę do terminala użytkownika, jeżeli użytkownik jest aktywny na danym hoście i przyjmuje wiadomości terminala. W przeciwnym razie poczta jest dostarczana do skrzynki pocztowej użytkownika.

SAML (wyślij i wyślij pocztą) — dostarcza pocztę do terminala użytkownika, jeżeli użytkownik jest aktywny na danym hoście i przyjmuje wiadomości terminala. Poczta jest dostarczana do skrzynki pocztowej użytkownika niezależnie od tego, czy jest dostarczana do terminala, czy nie.

Polecenia i komunikaty SMTP

Polecenie	Opis
HELO	Inicjuje połączenie i identyfikuje nadawcę SMTP dla odbiorcy SMTP.
MAIL FROM	Inicjuje transakcję pocztową.
RCPT TO	Identyfikuje pojedynczego adresata.
DATA	Identyfikuje wiersze następujące po poleceniu jako dane pocztowe od nadawcy.
RSET	Przerywa bieżącą transakcję pocztową.
SEND	Dostarcza pocztę do terminala.
SOML	Dostarcza pocztę do terminala. Jeżeli ta operacja się nie powiedzie, poczta zostanie dostarczona do skrzynki pocztowej.
SAML	Dostarcza pocztę do terminala. Poczta jest również dostarczana do skrzynki pocztowej.
VRFY	Weryfikuje nazwę użytkownika.
EXPN	Rozwija listę dystrybucyjną.
HELP	Sprawia, że odbiorca wysyła przydatne informacje.
NOOP	Żąda, by odbiorca wysłał odpowiedź OK, ale w przeciwnym razie nie określa żadnych działań.
QUIT	Żąda, by odbiorca wysłał odpowiedź OK, a następnie zamknął kanał transmisyjny.
TURN	Żąda, by odbiorca przejął rolę nadawcy. Jeżeli zostanie otrzymana odpowiedź OK, to nadawca staje się odbiorcą.

Kody odpowiedzi SMTP

Kod odpowiedzi	Znaczenie
211	Odpowiedź stanu systemu lub pomocy systemowej.
214	Komunikat pomocy.
220	Usługa gotowa.
221	Usługa zamyka kanał transmisyjny.
250	Żądane działanie poczty OK, zakończone.
251	Użytkownik nielokalny; przekażę do ścieżki przekazywania.
354	Rozpocznij wprowadzanie poczty.
421	Usługa niedostępna, zamykam kanał transmisyjny.
450	Żądane działanie poczty nie zostało podjęte: skrzynka pocztowa niedostępna.
451	Żądane działanie zostało przerwane.
452	Żądane działanie nie zostało podjęte: niewystarczająca ilość pamięci systemowej.
500	Błąd składniowy, polecenie nierozpoznane.
501	Błąd składniowy w parametrach lub argumentach.
502	Polecenie nie zostało implementowane.
503	Zła kolejność poleceń.
504	Parametr polecenia nie został implementowany.
550	Żądane działanie poczty nie zostało podjęte: skrzynka pocztowa niedostępna.
551	Użytkownik nielokalny; spróbuj wykorzystać ścieżkę przekazywania.
552	Żądane działanie poczty zostało przerwane: przekroczona alokacja pamięci.
553	Żądane działanie nie zostało podjęte: niedozwolona nazwa skrzynki pocztowej.
554	Transakcja nie powiodła się.

Dodatkowe dokumenty RFC protokołu SMTP

Dodatkowe dokumenty RFC dostarczają informacji na temat RFC 821 lub proponują jego rozszerzenia. Te ostatnie są albo proponowanymi standardami, albo też są eksperymentalne lub informacyjne. Aby uzyskać więcej informacji, --> odwołaj się[Author:PO] do następujących dokumentów RFC: 2645, 2554, 2502, 2487, 2442, 2197, 2034, 1985, 1891, 1870, 1869, 1846, 1845, 1830, 1652 oraz 1428.

Protokół odbierania poczty (POP)

Protokół POP3, zdefiniowany w dokumencie RFC 1939 uaktualnionym przez RFC 1957 oraz 2449, pozwala klientowi, który może mieć ograniczone zasoby, na dynamiczny dostęp do skrzynki pocztowej na serwerze i (przeważnie) na pobieranie poczty, którą serwer dla niego przechowuje. Protokół ten wymaga niewielkich zasobów i ma ograniczone możliwości. Zazwyczaj poczta jest pobierana, a następnie usuwana, ale nie jest manipulowana w żaden inny sposób.

Klient, który chce skorzystać z usługi POP3, ustanawia połączenie z portem TCP 110 na serwerze POP3. Kiedy połączenie zostanie ustanowione, serwer POP3 wysyła komunikat powitalny. Wtedy klient i serwer wymieniają polecenia i odpowiedzi (odpowiednio), dopóki połączenie nie zostanie zamknięte lub przerwane. Działanie POP3 wykorzystuje stany i przebiega w następujący sposób:

Połączenie TCP zostaje otworzone, a klient otrzymuje komunikat powitalny.

Sesja wchodzi w stan AUTORYZACJI.

Klient pozwala się zidentyfikować serwerowi, który następnie pozyskuje zasoby związane ze skrzynką pocztową klienta.

Sesja wchodzi w stan TRANSAKCJI.

Klient żąda, aby na serwerze zostały przeprowadzone działania.

Klient wydaje polecenie QUIT.

Sesja wchodzi w stan UAKTUALNIANIA.

Serwer POP3 uwalnia wszelkie zasoby pozyskane podczas --> w stanie[Author:PO] TRANSAKCJI i wysyła komunikat pożegnalny.

Połączenie TCP zostaje zamknięte.

Wskazówka: Jeżeli serwer ma czasomierz wylogowania automatycznego i czasomierz ten ulegnie przeterminowaniu z powodu braku aktywności ze strony klienta, to serwer zamyka połączenie TCP nie usuwając żadnych wiadomości i nie wysyłając żadnej odpowiedzi do klienta.

Polecenia protokołu POP3

Polecenie	Aktualny stan	Opis
USER	AUTORYZACJA	Identyfikuje daną skrzynkę pocztową.
PASS	AUTORYZACJA	Zapewnia hasło wyłączne dla serwera-skrzynki pocztowej.
QUIT	AUTORYZACJA	Zakańcza sesję nie wchodząc w stan UAKTUALNIANIA.
STAT	TRANSAKCJA	Dostarcza informacji (na przykład rozmiar i liczba wiadomości) dotyczących skrzynki pocztowej. Określa się to drop listing.
LIST	TRANSAKCJA	Określa numer wiadomości i rozmiar wiadomości. Określa się to jako scan listing.
RETR	TRANSAKCJA	Przy użyciu tego polecenia klient wysyła numer wiadomości. Serwer odpowiada zawartością wiadomości.
DELE		Przy użyciu tego polecenia klient wysyła numer wiadomości, a serwer oznacza wiadomość jako usuniętą. W rzeczywistości wiadomość nie zostanie usunięta, do momentu kiedy transakcja wejdzie w stan UAKTUALNIANIA.
NOOP		Kiedy klient wyśle ten komunikat, to serwer udzieli pozytywnej odpowiedzi, ale nie udzieli żadnych innych informacji.
RSET		Usuwa oznaczenie ze wszelkich wiadomości, które zostały oznaczone na serwerze jako usunięte.
QUIT		Sprawia, że sesja wchodzi w stan UAKTUALNIANIA. Wtedy klient wysyła komunikat pożegnalny.
APOP	AUTORYZACJA	Identyfikuje skrzynkę pocztową oraz ciąg MD5 w celu uwierzytelnienia oraz ochrony przed atakami powtórzeń.
TOP		Określa numer wiadomości oraz numer (n) wierszy. Serwer zwraca wiersze wiadomości o najwyższym n.
UIDL		Podaje numer wiadomości oraz niepowtarzalną tożsamość, które razem tworzą niepowtarzalny listing id dla wiadomości.

Protokół sieciowego przesyłania grup dyskusyjnych (NNTP)

NNTP, określony w specyfikacji RFC 977, wykorzystywany jest do dystrybucji, przeglądania, pobierania i wysyłania artykułów grup dyskusyjnych przy użyciu niezawodnego protokołu opartego na przesyłaniu strumieniowym (takiego jak TCP) oraz poleceń i odpowiedzi podobnych do SMTP. Usługa NNTP wykorzystuje port 119 TCP.

Artykuły grup dyskusyjnych przechowywane są w centralnej bazie danych, a abonenci wybierają tylko te pozycje, które chcą przeczytać. Indeksowanie jest włączone, podobnie jak odsyłanie i przeterminowanie starych artykułów. Zazwyczaj NNTP działa w środowisku klient — serwer z pojedynczym centralnym magazynem informacji grup dyskusyjnych. Jednak serwery wymieniające artykuły grup dyskusyjnych są wyposażone w interaktywny mechanizm decydowania o tym, co transmitować.

Odpowiedzi na polecenia NNTP mogą być albo raportami tekstowymi (artykuły grup dyskusyjnych), albo raportami stanu, poprzedzonymi liczbą trzycyfrową. Raporty stanu są podobne do kodów odpowiedzi SMTP wypisanych w tabeli 9.5 i są zazwyczaj przechwytywane przez oprogramowanie klienckie, które przekształca je na komunikaty bardziej wygodne w użyciu.

Polecenia NNTP

Polecenia NNTP są wypisane w tabeli 9.7. Dokument RFC 977 nie określa żadnych dodatkowych poleceń.

Podobnie jak polecenia SMTP i POP3, polecenia NNTP wykorzystywane są przez programy użytkowe, a nie bezpośrednio przez użytkownika. Szczegóły dotyczące składni poleceń oraz kody odpowiedzi komunikatów podane są w dokumencie RFC 977. Struktury protokołów tekstowych, takich jak SMTP, POP3 oraz NNTP, zdefiniowane są w dokumencie RFC 822, uaktualnionym przez RFC 1123, 1138, 1148 oraz 2156.

Wskazówka: Opcje serwera SMTP, POP3 oraz NNTP dla protokołu dynamicznej konfiguracji hosta (DHCP) mogą być dodawane dla zapewnienia obsługi klientom DHCP, którzy je rozpoznają. Opcje te zostały zarezerwowane oraz określone do wykorzystania w dokumencie RFC 2132, ale nie są aktualnie wstępnie zdefiniowane w menadżerze DHCP systemu Windows 2000. Protokół DHCP jest opisany w rozdziale 11.

Tabela 9.7. Polecenia protokołu NNTP

Polecenie	Opis
--> NNTP[Author:PO]	Określa artykuł albo po numerze, albo po tytule. Serwer zwraca artykuł (albo kod błędu).
BODY	Określa artykuł albo po numerze, albo po tytule. Serwer zwraca tekst podstawowy artykułu.
GROUP	Określa nazwę grupy dyskusyjnej. Serwer zwraca numery pierwszego i ostatniego artykułu w danej grupie, oraz oszacowanie liczby artykułów w danej grupie.
HEAD	Określa artykuł albo po numerze, albo po tytule. Serwer zwraca nagłówek artykułu.
HELP	Określa polecenie. Serwer zwraca krótki opis.
IHAVE	Informuje serwer, że klient ma artykuł (określony przez identyfikator wiadomości). Serwer informuje klienta czy chce kopię, czy nie.
LAST	Rozkazuje serwerowi, aby ustawił wskaźnik bieżącego artykułu na poprzedni artykuł w bieżącej grupie.
LIST	Rozkazuje serwerowi, aby zwrócił listę ważnych grup dyskusyjnych i związane z nimi informacje.
NEWSGROUPS	Serwer zwraca listę grup dyskusyjnych utworzonych od określonej daty i czasu. Dodatkowo polecenie może również określać listę grup dystrybucyjnych, a serwer może zwracać listę grup dyskusyjnych, które pasują do grup dystrybucyjnych.
NEWNEWS	Określa datę, czas i jedną lub więcej grup dyskusyjnych. Serwer zwraca listę tożsamości komunikatów artykułów wysłanych do określonych grup dyskusyjnych, albo od nich otrzymanych, od tej daty i czasu.
NEXT	Rozkazuje serwerowi, aby ustawił wskaźnik bieżącego artykułu na następny artykuł w bieżącej grupie.
POST	Klient wysyła to polecenie (bez argumentu), aby ubiegać się o pozwolenie na przedłożenie dokumentu. Jeżeli pozwolenie zostanie przyznane, to klient wysyła artykuł, słowo w słowo, do nadawcy.
QUIT	Serwer potwierdza to polecenie, a następnie zamyka połączenie z klientem.
SLAVE	Informuje serwer, że połączenie klienckie jest połączeniem do serwera podległego, a nie do użytkownika. Funkcja ta mogłaby być (przykładowo) użyta, aby dać priorytet żądaniom od serwerów podległych, ponieważ obsługują one więcej niż jednego użytkownika.
STAT	Określa artykuł albo po numerze, albo po tytule. Serwer zwraca tożsamość artykułu i ustawia wskaźnik bieżącego artykułu.

Wskazówka: Polecenie IHAVE pomyślane jest dla artykułów, które już zostały wysłane gdzieś indziej, być może na inny serwer i które mają już tożsamość wiadomości. Polecenie POST jest zwykle używane w przypadku nowych wiadomości.

... zajrzyj ...

Strona: 57
... stanu ...

Strona: 63
W oryginale: ARTICLE

---