Bramka protokołu SMTP szyfrująca przesyłki w

Transkrypt

Rok akademicki 2013/2014
Politechnika Warszawska
Wydział Elektroniki i Technik Informacyjnych
Instytut Informatyki
PRACA DYPLOMOWA MAGISTERSKA
Tomasz Pieczerak
Bramka protokołu SMTP
szyfrująca przesyłki w standardzie S/MIME
na platformie Raspberry Pi
Opiekun pracy
dr inż. Grzegorz Blinowski
Ocena: .....................................................
.................................................................
Podpis Przewodniczącego
Komisji Egzaminu Dyplomowego
Kierunek:
Informatyka
Specjalność:
Inżynieria Systemów Informatycznych
Data urodzenia:
1988.03.14
Data rozpoczęcia studiów:
2012.10.01
Życiorys
Urodziłem w Warszawie, gdzie mieszkałem przez pierwszych 18 lat życia (w dzielnicy
Ursynów). Tam też uczęszczałem do Szkoły Podstawowej Nr 340 im. Profesora Bogusława
Molskiego i Gimnazjum z Oddziałami Integracyjnymi Nr 95 im. Ignacego Jana
Paderewskiego. Jestem absolwentem XIV Liceum Ogólnokształcącego im. Stanisława
Staszica, klasy o profilu matematyczno-fizycznym. W roku 2007 zdałem egzamin maturalny.
W lutym 2008 roku rozpocząłem studia stacjonarne pierwszego stopnia (inżynierskie) na
Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej, które
zakończyłem we wrześniu roku 2012 broniąc pracę dyplomową inżynierską o tytule „Bramka
protokołu SMTP, szyfrująca przesyłki w standardzie S/MIME”.
.......................................................
Podpis studenta
EGZAMIN DYPLOMOWY
Złożył egzamin dyplomowy w dniu ..................................................................................2014 r
z wynikiem ...................................................................................................................................
Ogólny wynik studiów: ................................................................................................................
Dodatkowe wnioski i uwagi Komisji: ..........................................................................................
.......................................................................................................................................................
.......................................................................................................................................................
STRESZCZENIE
Poczta elektroniczna jest jedną z najpopularniejszych form komunikacji w Internecie, a
jednym z istotnych zagadnień jej dotyczących jest bezpieczeństwo – szczególnie kwestie
związane z uwierzytelnianiem oraz zapewnieniem poufności i integralności przekazywanych
danych. W ramach niniejszej pracy dyplomowej zostały przeprowadzone badania wydajności
implementacji bramki protokołu SMTP, szyfrującej przesyłki pocztowe w standardzie
S/MIME – stworzonej przez autora w ramach pracy dyplomowej inżynierskiej.
Bramka została uruchomiona na platformie „Raspberry Pi”. Jest to jednopłytkowy komputer
osobisty wielkości karty kredytowej dostępny w cenie ok. 25 USD, który pojawił się na rynku
na początku 2012 roku, szybko zyskując dużą popularność i zastosowanie w wielu
dziedzinach informatyki. Drugim aspektem przeprowadzonych badań jest wydajność tego
rozwiązania w filtracji ruchu TCP/IP na poziomie aplikacyjnym (w protokole SMTP) oraz
filtracji wymagającej zastosowania kryptografii symetrycznej i asymetrycznej.
Słowa kluczowe: poczta elektroniczna,
kryptografia, S/MIME, PKI, Raspberry Pi
SMTP,
bezpieczeństwo
teleinformatyczne,
SMTP Gateway for E-mail Encryption in S/MIME Standard on the Raspberry Pi
One of the most popular form of Internet communication is e-mail. Its security is a crucial
problem – especially where: data confidentiality, authenticity and integrity are concerned.
This thesis' research concerns performance of the SMTP gateway for e-mail encryption,
which was implemented by author in his earlier thesis.
SMTP gateway was implemented on the “Raspberry Pi” platform. “Raspberry Pi” is a creditcard-sized single-board personal computer developed by the Raspberry Pi Foundation and
priced at 25 USD. Since initial sales in February 2012 it gained a huge popularity and now
finds application in various projects. This thesis analyses its performance in TCP/IP filtering
in application layer (SMTP) and filtering with symmetric and asymmetric data encryption.
Keywords: email, SMTP, computer security, cryptography, S/MIME, PKI, Raspberry Pi
Spis treści
1 Wprowadzenie
1.1 Bramka protokołu SMTP szyfrująca przesyłki
S/MIME . . . . . . . . . . . . . . . . . . . . .
1.2 Platforma Raspberry Pi . . . . . . . . . . . .
1.3 Słownik używanych pojęć . . . . . . . . . . .
1.4 Układ pracy i konwencje redakcyjne . . . . . .
2 Poczta elektroniczna i jej bezpieczeństwo
2.1 Protokół SMTP . . . . . . . . . . . . . . .
2.1.1 Opis protokołu . . . . . . . . . . .
2.1.2 Ruting poczty elektronicznej . . . .
2.2 Bezpieczna Poczta Elektroniczna . . . . .
2.2.1 Infrastruktura klucza publicznego .
2.2.2 Standard S/MIME . . . . . . . . .
3 Platforma Raspberry Pi
3.1 Rys historyczny . . . . .
3.2 Specyfikacja sprzętowa .
3.3 Zastosowania . . . . . .
3.4 Ocena i odbiór platformy
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
w standardzie
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
4 Bramka S/MIME na platformie Raspberry Pi
4.1 Uruchomienie bramki S/MIME na Raspberry Pi
4.2 Poprawki w kodzie źródłowym bramki S/MIME
4.3 Zarządzanie i administracja . . . . . . . . . . .
4.4 Środowisko testów i narzędzia pomocnicze . . .
4.5 Podsumowanie . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
3
4
.
.
.
.
.
.
5
5
6
9
11
12
16
.
.
.
.
22
22
23
24
25
.
.
.
.
.
27
27
28
29
30
30
5 Badanie wydajności platformy Raspberry Pi
32
5.1 Środowisko testowe . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.1 Konfiguracja przekaźnika . . . . . . . . . . . . . . . . . 34
2
SPIS TREŚCI
5.2
5.3
5.4
5.5
5.6
Monitorowanie pracy systemu . . . . . . . . . . . . . . . . . .
5.2.1 Obsługa programu vmstat . . . . . . . . . . . . . . . .
5.2.2 Obsługa programu iostat . . . . . . . . . . . . . . . .
5.2.3 Obsługa programu top . . . . . . . . . . . . . . . . . .
5.2.4 Czujnik temperatury w Raspberry Pi . . . . . . . . . .
Ruch TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Narzędzie nuttcp . . . . . . . . . . . . . . . . . . . . .
5.3.2 Testy wydajności TCP/IP . . . . . . . . . . . . . . . .
Poczta elektroniczna (SMTP) . . . . . . . . . . . . . . . . . .
5.4.1 Narzędzie Postal . . . . . . . . . . . . . . . . . . . . .
5.4.2 Testy wstępne i sposób opisu . . . . . . . . . . . . . . .
5.4.3 Testy ze względu na liczbę równoległych połączeń . . .
5.4.4 Testy ze względu na rozmiar przesyłek . . . . . . . . .
5.4.5 Testy ze względu na liczbę równoległych połączeń i rozmiar wiadomości . . . . . . . . . . . . . . . . . . . . .
5.4.6 Testy ze względu na liczbę wiadomości na sesję SMTP
5.4.7 Testy zbiorcze i podsumowanie . . . . . . . . . . . . .
Wydajność bramki S/MIME (OpenSSL) . . . . . . . . . . . .
5.5.1 Testy ze względu na liczbę szyfrowanych lub podpisywanych elektronicznie wiadomości . . . . . . . . . . . .
5.5.2 Testy ze względu na liczbę szyfrowanych przesyłek i
rozmiar wiadomości . . . . . . . . . . . . . . . . . . . .
Podsumowanie badań . . . . . . . . . . . . . . . . . . . . . . .
35
35
35
36
36
38
38
39
43
43
44
47
49
53
56
58
60
60
63
66
6 Podsumowanie
67
6.1 Ocena wydajności bramki S/MIME . . . . . . . . . . . . . . . 67
6.2 Ocena platformy Raspberry Pi . . . . . . . . . . . . . . . . . . 68
A Tabele pomiarów
A.1 Poczta elektroniczna (SMTP) . . . . . . . . . . . . . . . . .
A.1.1 Test wstępny . . . . . . . . . . . . . . . . . . . . . .
A.1.2 Testy ze względu na liczbę równoległych połączeń . .
A.1.3 Testy ze względu na rozmiar przesyłek . . . . . . . .
A.1.4 Testy ze względu na liczbę równoległych połączeń i rozmiar wiadomości . . . . . . . . . . . . . . . . . . . .
A.1.5 Testy ze względu na liczbę wiadomości na sesję . . .
A.1.6 Testy zbiorcze . . . . . . . . . . . . . . . . . . . . . .
A.2 Wydajność obliczeniowa (OpenSSL) . . . . . . . . . . . . . .
A.2.1 Testy ze względu na liczbę szyfrowanych wiadomości
A.2.2 Testy ze względu na liczbę wiadomości podpisanych
elektronicznie . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
69
69
69
70
74
.
.
.
.
.
82
107
113
114
114
. 133
3
SPIS TREŚCI
A.3 Testy w konfiguracji typu relay . . . . . . . . . . . . . . . . . 140
B Synchronizacja a sygnały
B.1 Opis problemu . . . . . . . . . . . . . . . . . . . . .
B.2 Przyczyny problemu i jego potencjalne rozwiązania
B.2.1 Typ sig atomic t . . . . . . . . . . . . . .
B.2.2 Semafory . . . . . . . . . . . . . . . . . . .
B.2.3 Blokowanie sygnału SIGCHLD . . . . . . . . .
B.3 Podsumowanie . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
142
142
144
145
146
149
150
Rozdział 1
Wprowadzenie
Wpływ wszechogarniającej nas sieci Internet z każdym rokiem jest coraz
większy. Powszechność jej wykorzystania implikuje wiele problemów, których jeszcze 20 lat temu nikt nie dostrzegał. Zaufanie pokładane w nowoczesnych technologiach oraz ich niezawodność sprawiły, że coraz częściej są
one wykorzystywane do realizacji zadań krytycznych. W komunikacji między
przedsiębiorstwami bardzo szybko istotne stało się zagadnienie bezpieczeństwa – zwłaszcza kwestie związane z uwierzytelnianiem oraz zapewnieniem
poufności i integralności przekazywanych danych.
Współcześnie poczta elektroniczna jest niewątpliwie jedną z najbardziej
popularnych form komunikacji w Internecie. Od wysłania pierwszej wiadomości poczty elektronicznej minęło już ponad 30 lat i przez ten czas przeszła ona
niemałą rewolucję – obecne możliwości poczty elektronicznej już dawno przerosły wyobrażenia jej twórców. Wykorzystuje się ją także w komunikacji między przedsiębiorstwami, tu jednak nierzadko stawia się przed nią wymagania
związane z bezpieczeństwem – wiele firm wymienia się informacjami, które
można określić jako poufne. Podobnie indywidualni użytkownicy potrzebują
w różnych sytuacjach przesyłać wiadomości, których treść nie powinna być
przejęta przez osoby trzecie.
Wychodząc naprzeciw tym potrzebom różne firmy i organizacja standaryzacyjna IETF (Internet Engineering Task Force) zaczęły w latach 90. rozwijać szereg standardów wspierających tzw. bezpieczną pocztę elektroniczną.
Niektóre z nich przyjęły się, inne zostały zaniechane. Wśród współcześnie
używanych rozwiązań należy wymienić dwa: OpenPGP i S/MIME.
W wielu dziedzinach informatyki dąży się wyeliminowania elementów zależnych od użytkownika. Człowiek jest tylko człowiekiem, zdarza mu się popełniać błędy czy zapominać. Powszechnie wiadomo, że najsłabszym elementem informatycznych systemów bezpieczeństwa są właśnie ludzie. Maszyny
są co prawda „głupsze” w tym sensie, że robią tylko i wyłącznie to, co im
Rozdział 1. Wprowadzenie
2
zaprogramowano, ale w systemie bezpieczeństwa kreatywność nie jest cechą
wymaganą. Stąd eksperci bezpieczeństwa starają się możliwie minimalizować
bezpośredni kontakt użytkowników z systemem – tym samym minimalizując
liczbę sytuacji, w których może wystąpić błąd ludzki.
1.1
Bramka protokołu SMTP szyfrująca
przesyłki w standardzie S/MIME
Wychodząc na przeciw tym potrzebom w ramach mojej pracy dyplomowej
inżynierskiej ([15]) stworzyłem implementację bramki protokołu SMTP szyfrującej i podpisującej przesyłki pocztowe w standardzie S/MIME. Ów projekt nie zakładał co prawda pełnej funkcjonalności aplikacji ze względu na
ograniczenia czasowe i trudność zadania, ale zakończył się sukcesem.
Bramka S/MIME jest rozwiązaniem łączącym w sobie wiele zalet i pozwala niewielkim kosztem wdrożyć bezpieczną komunikację pocztową opartą
na protokole S/MIME. To dobre rozwiązanie dla przedsiębiorstw, które nie
potrzebują wprowadzać pełnej infrastruktury klucza publicznego, ale potrzebują by cała lub część komunikacji pocztowej była zabezpieczona kryptograficznie. Bramka może także mieć zastosowanie w niewielkich sieciach prywatnych czy na użytek „domowy”.
1.2
Platforma Raspberry Pi
W pierwotnym zamyśle bramka S/MIME miała być tanim i nieingerującym
w istniejącą strukturę sieciową rozwiązaniem dla bezpiecznej poczty elektronicznej dla małych i średnich przedsiębiorstw. Stworzonemu przeze mnie w
ramach pracy dyplomowej inżynierskiej oprogramowaniu brakowało jednak
części sprzętowej.
W roku 2012 na rynku europejskim pojawił się nowy mini-komputer,
nazwany przez twórców Raspberry Pi , który mógł wypełnić tę lukę. Tym
bardziej, że był to jeden z rzadkich przypadków „wolnego sprzętu” – stworzonego nie jako produkt czysto komercyjny, ale edukacyjny. Dobrze pasowało
to do stworzonej przeze mnie w duchu wolnego oprogramowania (ang. free
software) bramki S/MIME, a dodatkowym atutem była niska, jak na tego
typu sprzęt, cena.
Szybko pojawiły się jednak pytania o kompatybilność i wydajność Raspberry Pi. Z jednej strony, czy w ogóle uda się uruchomić bramkę na nowej
platformie? Z drugiej, jaka będzie jej wydajność w tym zastosowaniu? Jasne
było, że Raspberry Pi nie jest typową platformą serwerową i nie był tworzony
3
z myślą o przetwarzaniu poczty elektronicznej ani kryptografii. Dostępne badania wydajności skupiają się głównie na zastosowaniach multimedialnych,
a jeśli nawet są zakrojone na szerszą skalę (patrz [18]), to analizują tylko
wybrane aspekty działania Raspberry Pi.
Tematem tej pracy dyplomowej są badania nad wydajnością minikomputera Raspberry Pi w zastosowaniu jako platforma dla bramki protokołu
SMTP szyfrującej pocztę elektroniczną. Wstępne rozpoznanie wykazało, że
możliwe jest skompilowanie i uruchomienie programu bramki na Raspberry
Pi . W drugiej fazie przeprowadziłem badania ogólnej wydajności sieciowej
(TCP/IP), by następnie przejść do testowania wydajności protokołu SMTP
i wydajności obliczeniowej w kontekście szyfrowania przesyłek pocztowych.
1.3
Słownik używanych pojęć
Tłumaczenie anglojęzycznej terminologii informatycznej bywa bardzo zdradliwe. Aby uniknąć niejednoznaczności, umieszczam poniżej krótki słownik
najczęściej używanych pojęć (te rzadziej używane są wytłumaczone w miejscu ich użycia):
• przesyłka pocztowa, wiadomość pocztowa – to przesyłka poczty elektronicznej (ang. mail object),
• odbiorca, adresat – użytkownik, do którego kierowana jest przesyłka
poczty elektronicznej (ang. recipient),
• wysyłający, nadawca – użytkownik, który wysyła przesyłkę poczty elektronicznej (ang. sender ),
• przetwarzanie kryptograficzne – to zbiór operacji w kryptografii klucza publicznego, do którego zaliczają się: szyfrowanie, deszyfrowanie,
podpisywanie cyfrowe danych i weryfikacja podpisów,
• bramka S/MIME – bramka protokołu SMTP, automatyzująca proces
szyfrowania i podpisywania przesyłek w standardzie S/MIME (ang.
S/MIME Gateway),
• mini-komputer, Raspberry Pi – jednopłytkowy komputer osobisty wyprodukowany przez Raspberry Pi Foundation, będący przedmiotem badań tej pracy dyplomowej.
1.4
4
Układ pracy i konwencje redakcyjne
Praca jest podzielona na sześć głównych rozdziałów: wprowadzenie, przegląd
dziedziny problemu, opis badanej platformy sprzętowej, opis uruchomienia
bramki S/MIME na owej platformie, opis przeprowadzonych badań i podsumowanie. Praca zawiera także dwa dodatki: w pierwszym znajdują się „surowe” pomiary ujęte w tabele (z dokładnym opisem parametrów każdego
testu), w drugim znajduje się analiza teoretyczna zagadnienia wynikłego w
trakcie badań, a niezwiązanego bezpośrednio z tematem pracy.
W całym tekście pracy stosuję następujące konwencje redakcyjne:
1. Wszystkie anglojęzyczne pojęcia są przetłumaczone na język polski;
gdy tłumaczenie może być niejednoznaczne, w pierwszym miejscu użycia w nawiasie podany jest angielski termin; np. przesyłka pocztowa
(ang. mail object),
2. Nazwy własne, nazwy dokumentów i nazwy standardów (poza akronimami) wyróżnione są kursywą; np. dokument RFC 5321 ,
3. Akronimy pisane są dużymi literami; w pierwszym miejscu użycia podane jest także rozwinięcie skrótu; np. SMTP (Simple Mail Transfer
Protocol ),
4. Wszelkie kody (np. znaków, komend) i symbole wyróżnione są kursywą;
np. komenda RSET ,
5. Kod źródłowy, ścieżki katalogowe, tekst plików konfiguracyjnych i polecenia terminala zawarte bezpośrednio w tekście pisane są czcionką
monotypiczną; np. nazwa-opcji SP "=" SP wartość LF
6. Dłuższe fragmenty kodu źródłowego i innych powyżej wymienionych
znajdują się w wydzielonych blokach; np.
1
5
int main ( void )
{
p r i n t f ( ” H e l l o , World ! \ n” ) ;
return 0 ;
}
Listing 1.1: Przykładowy listing programu.
Rozdział 2
Poczta elektroniczna i jej
bezpieczeństwo
2.1
Protokół SMTP
Protokół SMTP (Simple Mail Transfer Protocol , czyli prosty protokół transferu poczty) jest internetowym standardem przesyłania poczty elektronicznej
przez sieci IP, jego aktualną specyfikację można znaleźć w dokumencie [12]
– na jego podstawie napisałem tę sekcję. Standard został po raz pierwszy
zdefiniowany w dokumencie RFC 821 w roku 1982, a ostatnia aktualizacja
miała miejsce w roku 2008. Zadaniem protokołu jest zapewnienie efektywnego i niezawodnego transportu przesyłek poczty elektronicznej przez sieci
IP.
Zgodnie z nazwą SMTP jest stosunkowo prostym, tekstowym protokołem,
a przynajmniej był „prosty” na początku swojego istnienia. Wzrost popularności poczty elektronicznej w Internecie sprawił, że rozwiązania zaproponowane w 1982 roku szybko okazały się niewystarczające. Od tamtego czasu
protokół SMTP został rozszerzony i udoskonalony. Choć fundament pozostał ten sam, to obecnie pełna implementacja SMTP nie jest już zadaniem
trywialnym. Wszelkie rozszerzenia zostały wprowadzone tak, aby zapewnić
wsteczną zgodność z pierwotną wersją protokołu – za pomocą mechanizmu
rozszerzeń ESMTP (Extended SMTP , czyli Rozszerzone SMTP ). Stare serwery pocztowe, implementujące wersję protokołu z 1982 roku, powinny być
w stanie porozumieć się z nowoczesnymi serwerami (co nie znaczy, że taka
współpraca jest pożądana i zgodna ze stosowaną polityką).
Aktualnie obowiązujący dokument RFC 5321 – mający status standardu
internetowego (STD) – zbiera i uaktualnia specyfikacje zawarte w następujących dokumentach:
Rozdział 2. Poczta elektroniczna i jej bezpieczeństwo
6
• RFC 821 : pierwotna specyfikacja protokołu SMTP,
• RFC 1035 , RFC 974 : wymagania dotyczące systemu nazw domenowych (ang. Domain Name System, DNS ), tu w kontekście transportu
poczty elektronicznej,
• RFC 1123 : wymagania dotyczące hostów w sieci Internet,
• RFC 1869 : mechanizm rozszerzeń protokołu SMTP (ESMTP),
• RFC 2821 : nowsza specyfikacja SMTP, mająca status proponowanego
standardu.
Jednocześnie RFC 5321 dezaktualizuje wszystkie powyższe dokumenty
poza RFC 1035 oraz RFC 1123 . W tym ostatnim uaktualniona jest jedynie sekcja dotycząca transferu poczty elektronicznej (reszta dokumentu pozostaje niezmieniona). W RFC 821 zostały opisane pewne funkcjonalności,
które nie były w powszechnym użytku w latach 90. oraz dodatkowe modele
transferu poczty. W najnowszym dokumencie zostały one pominięte, gdyż nie
mają istotnego znaczenia we współczesnej sieci Internet – jednak pozostają
aktualne.
2.1.1
Opis protokołu
Protokół SMTP obejmuje następujące kwestie związane z przesyłaniem
poczty elektronicznej:
• specyfikacja protokołu wymiany danych,
• uwierzytelnianie,
• adresowanie przesyłek,
• ruting poczty elektronicznej.
Do kompetencji protokołu nie należą takie kwestie jak dostarczanie
poczty do klienta poczty elektronicznej (ang. Mail User Agent, MUA) ani
wewnętrzny format przesyłek.
2.1.1.1
Protokół komunikacji
SMTP jest protokołem tekstowym, a komunikacja opiera się na schemacie
komenda-odpowiedź, gdzie klient jest stroną wydającą komendy (ang. commands), a serwer realizującą je i powiadamiającą o efektach (także o błędach) przez odpowiedzi (ang. replies). Przesyłki pocztowe są transferowane
od klienta do serwera.
7
Podstawowy format zarówno komend, jak i odpowiedzi jest taki sam –
są to linie tekstu US-ASCII zakończone parą znaków CR oraz LF. Każda
komenda ma swój specyficzny format, ale w ogólności wszystkie one składają
się z następujących elementów:
• nazwa komendy,
• pojedyncza spacja, a po niej parametry zależne od komendy (opcjonalne),
• para znaków CR i LF .
Dla przykładu komenda, którą klient rozpoczyna sesję SMTP, ma następującą postać (w notacji ABNF):
ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
Odpowiedzi serwera mają bardzo podobną składnię:
• trzycyfrowy kod odpowiedzi,
• pojedyncza spacja, po niej linia tekstu,
• para znaków CR i LF .
Na przykład domyślna odpowiedź informująca o poprawnym przyjęciu
wysłanej komendy ma postać:
ok-rsp = "250" SP String CRLF
Linia tekstu jest zwykle opisem (dla człowieka) reakcji serwera na komendę. Klient powinien być przygotowany na odbiór odpowiedzi zawierającej sam kod odpowiedź (bez opisu), choć takie zachowanie serwera jest
niezalecane. Możliwe jest także wysłanie odpowiedzi składającej się z kilku
linii.
2.1.1.2
Maszyna stanów serwera SMTP
Reakcja serwera SMTP na poszczególne komendy zależna jest od aktualnego
kontekstu i stanu sesji – dlatego też możemy stworzyć maszynę stanów serwera (rys. 2.1). Na diagramie nie zaznaczyłem wszystkich możliwych komend
i tranzycji, a jedynie te najistotniejsze z punktu widzenia transferu przesyłki
pocztowej.
Po otwarciu połączenia przez klienta serwer wysyła odpowiedź powitalną
o kodzie 220 . Teraz klient może wydać komendę EHLO lub HELO, rozpoczynając tym samym sesję – serwer potwierdza tę komendę odpowiedzią o
kodzie 250 (domyślna odpowiedź, jeśli nie wystąpiły żadne błędy).
8
Rysunek 2.1: Maszyna stanów serwera SMTP
Wydając komendę MAIL (zawierającą, jako parametr, adres nadawcy),
klient rozpoczyna transakcję – od tej chwili kolejność komend jest ściśle określona. Teraz klient powinien wydać komendę RCPT (zawierającą, jako parametr, adres odbiorcy). W przypadku, gdy przesyłka jest adresowana do więcej
niż jednego odbiorcy, klient powinien wydać tę komendę dla każdego z nich.
Ostatnim elementem przesyłki jest treść wiadomości pocztowej – klient wydaje komendę DATA i po otrzymaniu odpowiedzi o kodzie 354 może zacząć
przesyłać wiadomość. Wiadomość musi być podzielona na linie (każda zakończona parą znaków CRLF ) i zawierać wyłącznie znaki US-ASCII (w pierwotnej wersji protokołu, obecnie jedno z rozszerzeń ESMTP pozwala wysyłać dowolne 8-bitowe znaki). Po przesłaniu ostatniej linii, klient wysyła sekwencję
znaków ’.’, CR i LF . Serwer zapisuje wiadomość w lokalnym systemie plików
9
i jeśli operacja się powiedzie odpowiada kodem 250 , co kończy transakcję.
Transakcja może w każdej chwili zostać przerwana przez klienta komendą
RSET – w takiej sytuacji serwer powinien zamknąć transakcję i usunąć
wszystkie odebrane do tej pory dane. Do zakończenia sesji SMTP służy komenda QUIT , po której serwer wysyła odpowiedź 221 i zamyka połączenie –
w konsekwencji trwająca transakcja, jeżeli taka istniała, zostaje przerwana.
Istnieją jeszcze dwie komendy niezaznaczone na rysunku 2.1: NOOP i
VRFY . Pierwsza z nich powoduje jedynie wysłanie odpowiedzi 250 przez
serwer (może służyć do podtrzymywania połączenia). Druga natomiast jest
prośbą o weryfikację nazwy użytkownika lub skrzynki pocztowej. Żadna z
nich nie powoduje zmiany stanu serwera i może być wydana w dowolnym
momencie po rozpoczęciu sesji.
2.1.1.3
Format przesyłek pocztowych
Serwery SMTP zajmują się przyjmowaniem i przekazywaniem przesyłek pocztowych (ang. mail objects). Przesyłka składa się z dwóch zasadniczych części:
koperty (ang. envelope) oraz treści przesyłki (ang. content).
Na kopertę składa się adres nadawcy, jeden lub więcej adresów odbiorców oraz opcjonalnie informacje dotyczące rozszerzeń protokołu. Koperta jest
przesyłana w serii komend protokołu SMTP – przede wszystkim MAIL (adres
nadawcy) i RCPT (adresy odbiorców).
Treść przesyłki wysyłana jest po komendzie DATA, jako kolejne linie tekstu zakończone parą znaków CRLF . Treść jest podzielona na nagłówek (ang.
header ) oraz część główną (ang. body) – ich format jest zdefiniowany w dokumentach RFC 5322 (Internet Message Format) oraz RFC 2045 (MIME ). Jak
wspominałem wcześniej, wewnętrzny format treści przesyłki nie jest przedmiotem zainteresowania protokołu SMTP.
2.1.2
Ruting poczty elektronicznej
Proces transferu przesyłki od nadawcy do odbiorcy nazywany jest rutingiem
(ang. routing). Wraz z rozbudową sieci Internet to zagadnienie stało się bardzo istotnym punktem protokołu SMTP. Samo dostarczenie przesyłki do celu
to nie wszystko, ważna jest także szybkość, niezawodność i koszt dostarczenia.
2.1.2.1
Model transferu poczty
W podstawowym modelu (rys. 2.2) transferu użytkownik, za pomocą programu pocztowego (ang. Mail User Agent, MUA), wysyła wiadomość pocz-
10
tową do serwera poczty elektronicznej (ang. Mail Transfer Agent, MTA), nazywanego czasem serwerem brzegowym. Ten transferuje wiadomość do serwera, który obsługuje adresata przesyłki – może, choć nie musi, to być to
jednocześnie maszyna przechowująca skrzynki pocztowe (ang. Post Office,
PO). Teraz odbiorca może pobrać przesłaną wiadomość ze swojej skrzynki.
Rysunek 2.2: Podstawowy model transferu poczty
Obecnie ten proces jest bardziej skomplikowany. Często przesyłki muszą
przejść przez kilka serwerów nim trafią do odbiorcy. Dochodzi też problem
uwierzytelniania serwerów między sobą i ochrony przed spamem.
2.1.2.2
Serwery pocztowe
Serwer poczty elektronicznej (ang. Mail Transfer Agent, MTA) zajmuje się
przesyłaniem przesyłek pocztowych między hostami wykorzystując protokół
SMTP. Program serwera musi implementować zarówno część kliencką (wysyłanie przesyłek do innych serwerów), jak i serwerową (odbieranie przesyłek
od użytkownika lub innego serwera) protokołu.
Serwer poczty elektronicznej odbiera przesyłki pocztowe od użytkowników bądź innych serwerów. Ze względów bezpieczeństwa potwierdzenie odebrania wiadomości wysyłane jest dopiero po zapisaniu jej do pamięci trwałej
(ang. non-volatile memory). Jeśli odbiorca przesyłki nie jest użytkownikiem
lokalnym (tj. nie posiada skrzynki na tej maszynie), jest ona przekazywana
do innego serwera. Proces wyboru kolejnego serwera jest opisany w protokole
SMTP, ale może być nadpisany przez ustawienia serwera (np. celem wybrania
konkretnej trasy).
2.1.2.3
11
Serwery pośredniczące
Serwerem pośredniczącym protokołu SMTP (ang. SMTP Proxy) nazywamy
wyspecjalizowany serwer poczty elektronicznej pośredniczący w sesjach protokołu SMTP między dwoma hostami. Może on wykorzystywać strategię
zapisz-i-przekaż (ang. store-and-forward ) lub też nie. W tym drugim przypadku przesyłka nie jest zapisywana do pamięci trwałej przed przekazaniem
jej do kolejnego serwera. Wszelkie informacje o stanie sesji i ewentualnych
błędach przekazywane są z powrotem do hosta, który zainicjował sesję.
Serwery pośredniczące znalazły wiele zastosowań w przetwarzaniu poczty
elektronicznej. W modelu transferu poczty możemy wyróżnić dwa miejsca
ich wykorzystania:
1. Dla ruchu sieciowego wychodzącego, czyli między klientem pocztowym
a serwerem brzegowym – w tym miejscu ich zadaniem jest przede
wszystkim blokowanie nieautoryzowanej poczty, filtrowanie spamu oraz
detekcja robaków internetowych w przesyłkach.
2. Dla ruchu sieciowego przychodzącego, czyli między siecią rozległą a
serwerem zbierającym pocztę i przekazującym ją do skrzynek użytkowników – tu serwery pośredniczące wykorzystuje się m.in. do integracji różnych technologii antyspamowych, równoważenia obciążenia sieci
(jest to lepsze rozwiązanie niż użycie DNS-ów z wieloma rekordami
MX), przekazywania przesyłek do konkretnych serwerów (np. w korporacjach z wieloma departamentami).
Dużą zaletą pocztowych serwerów pośredniczących jest możliwość ich łatwego wdrożenia w istniejących strukturach sieciowych. Wynika to z faktu,
iż możemy je łatwo łączyć w łańcuchy, gdzie kolejne serwery zajmują się
kolejnymi etapami przetwarzania. W najprostszym modelu należy ustawić
jeden serwer pośredniczący na wejściu z sieci rozległej, ów będzie przekazywał przesyłki do pierwszego w kolejce, ten do następnego i tak aż do serwera
zbierającego pocztę i przekazującego ją do skrzynek użytkowników.
2.2
Bezpieczna Poczta Elektroniczna
Problem zapewnienia bezpieczeństwa komunikacji pocztowej w sieciach rozległych pojawił się już na początku lat 90. Wtedy to organizacja IETF (Internet Engineering Task Force) zaczęła rozwijać standard PEM (Privacy Enhanced Mail ), ten jednak nigdy nie wszedł do powszechnego użytku – problemem było błędne założenie o możliwości stworzenia infrastruktury klucza
12
publicznego z jednym nadrzędnym centrum certyfikacji. Podobny los czekał późniejszy standard MOSS (MIME Object Security Services), choć jego
porażka w dużej mierze wynikała z rosnącej popularności rozwiązania zaproponowanego przez Phil’a Zimmermann’a w 1991 roku. Chodzi tu oczywiście
o program PGP (Pretty Good Privacy) wraz ze standardem OpenPGP. W
1998 roku organizacja IETF wystąpiła z propozycją nowego standardu, konkurencyjnego dla PGP, czyli S/MIME (Secure/Multipurpose Internet Mail
Extensions). Obecnie wydaje się, że przyszłość należy do ostatniej wymienionej technologii, zwłaszcza w komunikacji między firmami.
Największym konkurentem S/MIME pozostaje PGP, dlatego trzeba mieć
świadomość najistotniejszych cech tego rozwiązania. Najważniejszą innowacją PGP było oparcie weryfikacji poprawności kluczy publicznych o sieć zaufania (ang. web of trust). W obliczu raczkującej dopiero infrastruktury klucza publicznego (patrz rozdział 2.2.1) ten pomysł został bardzo dobrze przyjęty, co przyczyniło się do popularyzacji PGP. Sieci zaufania są zdecentralizowanym modelem zaufania, więc nie potrzeba tu urzędów certyfikacyjnych
ani rozbudowanej struktury organizacyjnej. Choć PGP zyskało dużą popularność w Internecie, nie jest to dobre rozwiązanie dla sieci korporacyjnych,
gdyż wszystkie decyzje dotyczące zaufania pozostają w rękach poszczególnych jednostek (pracowników), a nie pod nadzorem przedsiębiorstwa.
Z tego też powodu IETF wyszło z propozycją nowego standardu, opierającego się na modelu zaufania właściwym dla korporacyjnej infrastruktury
klucza publicznego – mowa oczywiście o S/MIME.
2.2.1
Infrastruktura klucza publicznego
Nim przejdę do opisu standardu S/MIME, który jest głównym obiektem
zainteresowania tej pracy, omówię szerzej infrastrukturę klucza publicznego 1
(ang. Public-Key Infrastructure, PKI ). Chociaż podstawy tej technologii zostały ustanowione ponad trzy dekady temu (wraz z opracowaniem kryptografii klucza publicznego w latach 70.), to zastosowania komercyjne są kwestią
ostatnich kilku lat. PKI nie jest już tylko ciekawostką techniczną, ale mądrze
wdrożona oferuje organizacjom wiele zalet wraz z możliwością dokonania znaczących oszczędności.
PKI może być podstawową technologią zapewniającą usługi uwierzytelniania, integralności i poufności danych oraz niezaprzeczalności. Implementuje się je łącząc techniki kryptografii symetrycznej i asymetrycznej, które
są udostępniane przy pomocy jednej, łatwej do zarządzania infrastruktury.
1
Dokument [28] opisuje standard ITU-T dla PKI.
2.2.1.1
13
Definiowanie infrastruktury klucza publicznego
W najprostszym ujęciu PKI jest powszechną infrastrukturą bezpieczeństwa,
w ramach której usługi są zaimplementowane i dostarczane za pomocą technik klucza publicznego2 . W pełni działająca infrastruktura PKI łączy w sobie
wiele komponentów i usług, wśród których należy wymienić:
• urząd certyfikacyjny (CA),
• repozytorium certyfikatów,
• unieważnianie certyfikatów,
• kopie zapasowe i odzyskiwanie kluczy,
• automatyczne uaktualnianie kluczy,
• zarządzanie historią kluczy,
• certyfikację wzajemną,
• obsługę niezaprzeczalności,
• znaczniki czasu,
• oprogramowanie klienta.
Nie zawsze do spełnienia wymagań bezpieczeństwa konieczne jest uruchamianie wszystkich wymienionych funkcji, jednak pełna PKI powinna być
niezależną jednostką infrastruktury, która może być zaimplementowana w
dowolnym środowisku – zatem w definicji należy zawrzeć je wszystkie. W
konkretnym wdrożeniu niepotrzebne usługi można wyłączyć.
2.2.1.2
Podstawowe usługi PKI
PKI zapewnia trzy podstawowe usługi związane z bezpieczeństwem: uwierzytelnianie, integralność oraz poufność. Poniżej krótkie omówienie każdej z
nich.
Uwierzytelnianie (ang. authentication) zapewnia, że dana jednostka jest
tą, za którą się podaje. Znajduje to zastosowanie przy identyfikacji jednostek
oraz identyfikacji pochodzenia danych.
Integralność (ang. integrity) danych daje gwarancje, że nie zostały one
zmienione podczas przesyłania między jednym miejscem a drugim ani między chwilą obecną a przeszłą (podczas przechowywania). Żadna zmiana, czy
to przypadkowa czy celowa (np. będąca efektem ataku), nie pozostanie niezauważona.
2
Definicja według [3, s. 56, 63-64].
14
Poufność (ang. confidentiality) zapewnia prywatność danych. Nikt poza
właściwym odbiorcą nie może ich odczytać. Poufność jest wymagana, gdy
dane są przechowywane na nośniku lub urządzeniu, do którego dostęp może
mieć niepowołana osoba oraz podczas przesyłania danych przez niechronioną
sieć.
2.2.1.3
Usługi „umożliwiane” przez PKI
Na podstawie usług bezpieczeństwa omówionych w poprzednim rozdziale możemy zbudować inne usługi, które niejako „umożliwia”3 infrastruktura PKI.
Jednak są to funkcjonalności dodatkowe i niektóre PKI mogą ich nie implementować.
Pierwszą usługą jest bezpieczna komunikacja, którą można zdefiniować
jako transmisję danych od nadawcy do odbiorcy przy zapewnieniu przynajmniej jednej z cech: autentyczności, integralności lub poufności. Tę usługę
wykorzystuje się w połączeniu ze stosowanymi protokołami sieciowymi – są
to tzw. rozszerzone usługi PKI. Wśród przykładów można wymienić: bezpieczną pocztę elektroniczną (np. wykorzystującą protokół S/MIME), bezpieczny dostęp do serwerów WWW (np. przy użyciu protokołu TLS lub SSL)
oraz bezpieczną wirtualną sieć prywatną, czyli VPN (np. za pomocą protokołu IPSec/IKE).
Dalej można wymienić bezpieczne znaczniki czasu, czyli znaczniki czasu
łączone z określonymi danymi (mającymi cechy autentyczności i integralności) przez zaufany urząd (ang. authority). Istotne jest nie tyle format znacznika, ale bezpieczeństwo powiązania danych z datą i czasem.
Usługa certyfikacji danych wykorzystuje usługę podstawową PKI, jaką
jest uwierzytelnienie, oraz bezpieczny znacznik czasu. Pozwala na wydanie,
przez jednostkę obdarzoną zaufaniem, certyfikatu poprawności danych, przy
czym definicja poprawności zależy od rodzaju danych. Przykładowo, certyfikat poprawności podpisu cyfrowego zapewnia, iż:
• weryfikacja podpisu jest poprawna matematycznie przy użyciu odpowiedniego klucza publicznego,
• klucz publiczny faktycznie należy do jednostki, która podpisała dane,
• wszystkie dane potrzebne do walidacji są dostępne i godne zaufania.
Obsługa niezaprzeczalności dotyczy usługi, która zapewnia nierozerwalność działań z tożsamością jednostek je wykonujących. Najczęściej używa się
dwóch typów niezaprzeczalności: niezaprzeczalność oryginału (użytkownik
Określenie zaczerpnięte z [3, s. 77]. Oznacza usługi, które nie są bezpośrednio związane
z PKI ani dla niej podstawowe, ale można je zbudować na podstawie usług PKI.
3
15
nie może zaprzeczyć, że utworzył dokument lub komunikat) i niezaprzeczalność otrzymania (użytkownik nie może zanegować otrzymania dokumentu
lub komunikatu). Usługa jest zapewniona w granicach możliwości technicznych – tzn. użytkownik jest kryptograficznie powiązany z danym działaniem tak, że jego późniejsze zaprzeczenie stanowi przyznanie się do złej woli
(świadome udostępnienie klucza prywatnego osobie trzeciej) lub zaniedbania
(klucz prywatny został ujawniony bez wiedzy użytkownika).
Zarządzanie uprawnieniami to zbiorcze określenie dla różnych funkcji bezpieczeństwa, takich jak autoryzacja, kontrola dostępu czy zarządzanie prawami lub zezwoleniami. Określają one do jakich zasobów dana jednostka
ma dostęp oraz jakie działania może wykonywać w ramach określonego środowiska. Dla każdej jednostki lub ich grup definiuje się reguły, określające,
jakie prawa one posiadają. Zarządzanie uprawnieniami obejmuje tworzenie i
realizację tychże reguł.
2.2.1.4
Usługi PKI w kontekście bezpiecznej poczty
Komponenty, usługi podstawowe i usługi umożliwiane przez PKI opisane w
poprzednich rozdziałach stanowią kompletną infrastrukturę klucza publicznego. Jest ona w pewnym sensie „idealna”, gdyż powinna spełniać wymagania niemal każdego środowiska. Jednak wiele wdrożonych PKI można rozpatrywać jako podzbiór pełnej architektury, ponieważ w danym zastosowaniu
nie wszystkie elementy są konieczne do realizacji potrzebnych funkcjonalności.
Na przykład przedsiębiorstwo chcące wykorzystać PKI jedynie do obsługi bezpiecznej poczty elektronicznej nie będzie potrzebowało uruchamiać
wszystkich elementów pełnego PKI. Jeśli jest to środowisko jednej firmy,
potrzebne są: zarządzanie cyklem życia kluczy i certyfikatów (urząd autoryzacji, repozytorium certyfikatów, unieważnianie certyfikatów, zarządzanie
historią kluczy, automatyczna aktualizacja kluczy oraz kopie zapasowe i odzyskiwanie kluczy), natomiast certyfikacja wzajemna nie jest już konieczna.
Oprogramowanie klienta można zrealizować jako wtyczki do standardowego
pakietu poczty elektronicznej. Spośród usług dostępnych w PKI potrzebne
będą tylko trzy podstawowe, czyli uwierzytelnianie, integralność i poufność.
Inne usługi nie są wykorzystywane, a zatem nie jest konieczne ich uruchamianie.
2.2.2
Standard S/MIME
2.2.2.1
Opis protokołu
16
S/MIME (Secure/Multipurpose Internet Mail Extensions) to internetowy
standard IETF opisujący spójny protokół wysyłania i odbierania zabezpieczonych kryptograficznie przesyłek pocztowych w formacie MIME (Multipurpose Internet Mail Extensions, standard definiujący strukturę przesyłek
poczty elektronicznej). Udostępnia następujące usługi kryptografii klucza publicznego:
• uwierzytelnianie,
• integralność,
• niezaprzeczalność,
• poufność danych.
S/MIME był początkowo rozwijany przez firmę RSA Data Security Inc.
i dopiero w 1998 został przejęty przez IETF. Aktualna wersja standardu jest
zdefiniowana w dokumentach RFC 5751 , RFC 5750 , RFC 3370 i RFC 5652
– jest to już trzecia wersja protokołu (dokładniej 3.2).
W swojej istocie S/MIME jest zestawem kilku standardów, tworzących
spójną całość. Najprościej można to zrozumieć analizując, jak zbudowana
jest wiadomość S/MIME. Jej tworzenie można podzielić na następujące kroki
(rys. 2.3):
1. Na wejściu mamy wiadomość protokołu MIME w postaci kanonicznej
(standardowy format przesyłek pocztowych),
2. Następnie zabezpieczamy ją protokołem CMS (Cryptographic Message
Syntax ) – na tym etapie następuje podpisywanie i/lub szyfrowanie wiadomości,
3. Całość kodowana jest w Base64 (rodzaj kodowania transportowego) do
postaci 7-bitowej,
4. Na końcu przesyłkę pieczętujemy nagłówkami SMTP i MIME (właściwymi dla przesyłek S/MIME) – w tej formie przesyłana jest ona pocztą
elektroniczną.
2.2.2.2
Standardy i technologie wykorzystywane przez S/MIME
S/MIME nie jest samodzielnym standardem. Jak wspomniałem wyżej, w
jego skład wchodzi szereg innych standardów i technologii, wśród których
17
Rysunek 2.3: Mechanizm tworzenia wiadomości S/MIME
można wymienić: MIME, CMS oraz Base64 . Poniżej krótki opis każdego z
tych elementów.
MIME, czyli Multipurpose Internet Mail Extensions to internetowy standard rozszerzający podstawowy format przesyłek pocztowych (zdefiniowany
w dokumencie RFC 822 ), aby umożliwić: przesyłanie tekstu w innym kodowaniu niż US-ASCII, nietekstowe załączniki, wiadomości wieloczęściowe oraz
nagłówki wiadomości zawierające znaki spoza US-ASCII. Standard MIME
jest zdefiniowany w sześciu powiązanych dokumentach: RFC 2045 , RFC
2046 , RFC 2047 , RFC 4288 , RFC 4289 i RFC 2049 .
CMS (Cryptographic Message Syntax ) jest protokołem przeznaczonym do
kryptograficznego zabezpieczania danych – dotyczy to zarówno podpisu cyfrowego, jak i szyfrowania (koperta cyfrowa) czy uwierzytelniania danych.
Najnowsza wersja CMS jest zdefiniowana w dokumencie RFC 5652 . Wiadomości CMS są zakodowane w BER (Basic Encoding Rules), wchodzącym w
skład notacji ASN.1 (opisany w dokumencie CCITT X.209 ). Wartości pól
zwykle są reprezentowane jako ciągi bajtów (ang. octet strings) – przez co
wiadomości CMS nie są czytelne dla człowieka ani nie da się ich bezpośrednio
przesyłać protokołami tekstowymi (takimi jak SMTP).
Base64 to rodzaj kodowania transportowego, który pozwala przedstawiać
dane binarne jako tekst w US-ASCII. Wykorzystuje się je wszędzie tam, gdzie
trzeba przysyłać dane binarne przez kanały lub protokoły zaprojektowane do
przesyłania wyłączne tekstowych danych – na przykład wiadomości CMS w
wiadomościach MIME. Kodowanie jest opisane w dokumencie RFC 4648 .
2.2.2.3
Szczegóły tworzenia wiadomości S/MIME
Standard S/MIME wprowadza do MIME dwa nowe nagłówki typu zawartości (ang. Content-Type) przeznaczone dla przesyłania zabezpieczonych
kryptograficznie wiadomości: application/pkcs7-mime i application/pkcs7signature. W tej formie możliwe jest przekazywanie wiadomości podpisanych
18
i/lub zaszyfrowanych, a także przesyłek zawierających tylko certyfikaty (są
to tzw. wiadomości zdegenerowane). Na listingu 2.1 pokazany jest klasyczny
przypadek wiadomości S/MIME (zarówno dla wiadomości podpisanej elektronicznie, jak i wiadomości zaszyfrowanej)4 .
1
5
From :
To :
MIME−V e r s i o n : 1 . 0
Content−Type : a p p l i c a t i o n / pkcs7−mime
Content−T r a n s f e r −Encoding : b a s e 6 4
4VQpfyF4IGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756 . . .
Listing 2.1: Przykładowa wiadomość protokołu S/MIME
Nowe typy zawartości, właściwe dla przesyłek zabezpieczonych przez
S/MIME, mogą mieć kilka opcjonalnych parametrów (podawanych zgodnie
ze zasadami zdefiniowanymi w standardzie MIME):
• parametr name określający nazwę pliku (to samo znaczenie ma parametr filename w ewentualnym nagłówku Content-Disposition); nazwa
może mieć do 8 znaków, a rozszerzenie 3 znaki; zwykle jako nazwę wykorzystuje się „smime”, a rozszerzenie jest zależne od rodzaju przesyłanej
wiadomości:
– .p7m dla typu MIME application/pkcs7-mime w przypadku wiadomości podpisanej elektronicznie albo w kopercie elektronicznej,
– .p7c dla typu MIME application/pkcs7-mime w przypadku, kiedy
wiadomość zawiera tylko zdegenerowaną wiadomość CMS zawierającą wyłącznie certyfikaty,
– .p7s dla typu MIME application/pkcs7-signature dla wieloczęściowej wiadomości podpisanej elektronicznie.
• parametr smime-type zawierający informację o zawartości wiadomości;
co prawda można ją uzyskać także z zawartości przesyłki, ale zdecydowanie łatwiej i szybciej zrobić to w ten sposób – jest to ułatwienie
dla twórców oprogramowania; parametr smime-type może przyjmować
następujące wartości:
– enveloped-data dla wiadomości w kopercie elektronicznej,
– signed-data dla wiadomości podpisanych elektronicznie,
4
Przykład pochodzi z publikacji [6, s. 484].
19
– certs-only dla wiadomości zdegenerowanych zawierających tylko
certyfikaty.
Na listingach 2.2 i 2.3 pokazane są: przykładowa wiadomość w kopercie
elektronicznej oraz wiadomość podpisana cyfrowo5 .
1
5
10
Content−Type : a p p l i c a t i o n / pkcs7−mime ;
smime−type=e nv el op ed −data ; name=smime . p7m
Content−D i s p o s i t i o n : attachment ; f i l e n a m e=smime . p7m
rfvbnj756tbBghyHhHUujhJ7n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpf7GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HGnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V . . .
Listing 2.2: Przykład wiadomości w kopercie elektronicznej
1
5
10
Content−Type : a p p l i c a t i o n / pkcs7−mime ; smime−type=s i g n e d −data ;
name=smime . p7m
Content−D i s p o s i t i o n : attachment ; f i l e n a m e=smime . p7m
567 GhIGfHfYT6ghyHhHUujpf8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75 . . .
Listing 2.3: Przykład wiadomości podpisanej elektronicznie
Standard S/MIME umożliwia także użycie istniejącego w MIME typu
multipart/signed dla przesyłek podpisanych elektronicznie. Dzięki temu przesyłka jest podzielona na dwie części: wiadomość jawną oraz podpis elektroniczny zgodny z normą CMS. Jest to przydatne w sytuacji, gdy przesyłki należy podpisać i rozesłać wielu adresatom, z których tylko niektórzy korzystają
z programów obsługujących S/MIME – dzięki temu rozwiązaniu wiadomość
pozostanie czytelna dla wszystkich, niezależnie od posiadanego oprogramowania. W pierwszej metodzie (typ application/pkcs7-mime) cała wiadomość
jest zamknięta w CMS, a więc jest ciągiem zakodowanym w BER, co skutecznie uniemożliwia jej odczytanie bez odpowiedniego programu. Użycie typu
multipart/signed niweluje ten problem. Poniżej, na listingu 2.4 pokazany jest
przykład takiej wiadomości6 .
Przykłady pochodzą z publikacji [6, s. 484] (wiadomość w kopercie elektronicznej)
oraz dokumentu [20, s. 27] (wiadomość podpisana cyfrowo).
6
Przykład pochodzi z dokumentu [20, s. 29].
5
1
20
Content−Type : m u l t i p a r t / s i g n e d ;
p r o t o c o l=a p p l i c a t i o n / pkcs7−s i g n a t u r e ; m i c a l g=sha1 ;
boundary=boundary42
5
−−boundary42
Content−Type : t e x t / p l a i n
This i s a c l e a r −s i g n e d message .
10
−−boundary42
Content−Type : a p p l i c a t i o n / pkcs7−s i g n a t u r e ; name=smime . p7s
Content−D i s p o s i t i o n : attachment ; f i l e n a m e=smime . p7s
15
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756 . . .
20
−−boundary42−−
Listing 2.4: Przykład wiadomości złożonej (multipart/signed )
2.2.2.4
Bariery wdrażania S/MIME
Infrastruktura PKI Wdrożenie bezpiecznej poczty opartej na S/MIME
wiąże się z jednoczesnym wdrożeniem infrastruktury klucza publicznego. Ta
inwestycja musi być biznesowo uzasadniona, gdyż ów proces jest skomplikowany i dosyć kosztowny. Konieczne jest m.in. stworzenie repozytorium certyfikatów wraz z urzędem certyfikacyjnym, zakup potrzebnego oprogramowania
oraz szkolenie pracowników (zarówno osób administrujących infrastrukturą,
jak i zwykłych pracowników, którzy będą korzystali z bezpiecznej poczty).
Problemy związane bezpośrednio z S/MIME Jeśli uda się pokonać
przeszkody związane z PKI, pozostają jeszcze te wynikające z cech protokołu
S/MIME.
Jako, że jest on standardem stosunkowo nowym, cały czas wiele popularnych programów pocztowych nie jest w stanie go poprawnie obsługiwać. Gdy
mamy do czynienia z wiadomością typu multipart/signed , wiadomość dalej
pozostaje czytelna dla użytkownika – jedynym problemem jest pojawienie
się załączników zawierających nieczytelny podpis. Jeśli natomiast cała wiadomość jest zabezpieczona protokołem CMS, taka przesyłka będzie bezużyteczna.
21
Model zabezpieczania przesyłek pocztowych S/MIME bywa przez niektórych uważany za nieodpowiedni dla przeglądarkowych klientów poczty
elektronicznej (ang. webmail ), zyskujących współcześnie coraz większą popularność. Wynika to z faktu, że do podpisywania przesyłki lub odszyfrowania
odległemu programowi pocztowemu potrzebny jest klucz prywatny użytkownika. Zatem na ten moment użytkownik traci kontrolę nad swoim kluczem
prywatnym, co jest sprzeczne założeniami kryptografii klucza publicznego.
Dodatkowym problemem jest brak możliwości skanowania zaszyfrowanej
poczty pod kątem obecności szkodliwego oprogramowania przez serwery pośredniczące. Przesyłka jest jawna jedynie dla nadawcy i odbiorcy, a więc tylko
w tych dwóch punktach skanowanie można zostać przeprowadzone – czasem
jest to niewystarczające.
2.2.2.5
Wnioski
Wdrażanie bezpiecznej poczty opartej na standardzie S/MIME okazuje się
być niełatwym zadaniem, wymagającym włożenia zarówno środków finansowych, jak i czasu – dlatego też taka inwestycja musi być uzasadniona biznesowo. Ów proces jest dodatkowo utrudniony ze względu na małą liczbę
dużych wdrożeń uruchomionych do tej pory – brak zatem wiarygodnych danych dotyczących skalowalności i wydajności dostępnych rozwiązań. Z tego
powodu często szuka się rozwiązań zastępczych.
Jedynym z nich jest bramka protokołu SMTP automatycznie szyfrująca
i podpisująca elektronicznie przesyłki pocztowe, której implementację stworzyłem w ramach mojej pracy inżynierskiej. Tamże znajduje się analiza wad
i zalet tego rozwiązania.
Rozdział 3
Platforma Raspberry Pi
Gdy pod koniec 2011 roku pojawiły się pierwsze informacje o nowym mikrokomputerze – nazwanym przez twórców „Raspberry Pi”– reklamowano
go jako „ jednopłytkowy komputer osobisty wielkości karty kredytowej za 25
dolarów”. W tym haśle zawiera się wiele cech nowej platformy, która szybko
zyskała ogromną popularność i zastosowania w różnych dziedzinach informatyki. Rosnącą sprzedaż urządzeń można by nazwać wielkim sukcesem finansowym, gdyby nie fakt, że nie został on wyprodukowany przez firmę, ale
fundację – Raspberry Pi Foundation założoną w 2009 roku przez pracowników
naukowych Uniwersytetu w Cambride. Poniższe rozdziały zostały napisane
w oparciu o [24].
3.1
Rys historyczny
Historia platformy Raspberry Pi zaczyna się w 2006 roku. Kilku pracowników Laboratorium Informatyki na Uniwersytecie w Cambridge – na czele z
Ebenem Uptonem1 – na podstawie doświadczeń dydaktycznych ze studentami rozpoczynającymi studia w kolejnych latach, sformułowało pewną tezę
dotyczącą powszechnej znajomości zagadnień informatyki. Zauważyli oni, że
z roku na rok umiejętności nowych studentów spadają. Bardzo rzadko można
spotkać wśród nich hobbystów i osoby zainteresowane informatyką samą w
sobie. Miało to być spowodowane przez coraz to nowszy, droższy i bardziej
wyrafinowany sprzęt (konsole do gier wideo i komputery osobiste), któremu
pod pewnymi względami daleko do starych komputerów – Amiga, Commodore 64 czy ZX Spectrum. Nowoczesny sprzęt stał się zbyt skomplikowany,
by każdy mógł próbować go oprogramowywać i zbyt drogi, by ryzykować
1
http://uk.linkedin.com/in/ebenupton
Rozdział 3. Platforma Raspberry Pi
23
eksperymentowanie. Z drugiej strony w szkołach naucza się obsługi pakietów
biurowych lub co najwyżej tworzenia prostych stron internetowych.
Głównym hasłem nowego projektu, w ramach którego miał powstać mały,
tani i łatwy do programowania komputer, było: „Putting the Fun Back into
Computing”. Raspberry Pi miał być przede wszystkim przeznaczony dla prywatnych użytkowników oraz do celów edukacyjnych. W latach 2006-2008 powstały pierwsze projekty (bazujące na mikrokontrolerze Atmel ATmega644 ).
Pierwsze egzemplarze ujrzały światło dzienne w sierpniu roku 2011 (wersja
α). Na początku 2012 roku na aukcji w serwisie eBay wystawiono pierwszą
serię dziesięciu gotowych i przetestowanych urządzeń, które sprzedały się za
zawrotną sumę 16 tysięcy funtów szterlingów – potem było już tylko lepiej. W
sierpniu tegoż roku sprzedano ich już ponad pół miliona, a popyt nie spadał.
3.2
Specyfikacja sprzętowa
Raspberry Pi wraz z opisem znajdujących się na nim układów i interfejsów
znajduje się na rysunku 3.1. Sercem tego mini-komputera jest układ scalony
typu system-on-a-chip firmy Broadcom – model BCM2835 – zawierający
procesor ARM11 o taktowaniu 700 MHz i procesor graficzny Broadcom VideoCore IV . Zależnie od wersji Raspberry Pi posiada 256 MB (model „A”)
lub 512 MB (model „B”) pamięci operacyjnej (dzielonej z procesorem graficznym). Całe urządzenie wymaga 5-woltowego zasilacza o minimalnej wydajności prądowej 300/700 mA (zależnie od wersji) podłączonym przez interfejs
microUSB lub GPIO. Nie ma przeszkód, by uruchomić na Raspberry Pi dowolny system operacyjny działający na procesorach o architekturze ARM.
Domyślnie dostarczana jest zmodyfikowana wersja dystrybucji Debian systemu GNU/Linux – nazwana Raspbian 2 .
Deklarowana wydajność multimedialna pozwala na płynne odtwarzanie
obrazu 2D w jakości BlueRay, a biblioteki 3D są sprzętowo wspierane przez
układ graficzny. Rzeczywista wydajność obliczeniowa CPU jest porównyR
R
2 o taktowaniu 300 MHz.
Pentium
walna do procesora Intel
2
http://www.raspbian.org/
24
Rysunek 3.1: Opis układów i interfejsów Raspberry Pi
3.3
Zastosowania
Jak już wspomniano wcześniej, platforma Raspberry Pi błyskawicznie znalazła zastosowanie w wielu dziedzinach życia i techniki. Zgodnie z pierwotnym
założeniem i hasłem reklamowym, Raspberry Pi można używać jako lekkiego
komputera osobistego, ale to nie koniec pomysłów, których wiele pojawiło
się na przestrzeni lat 2012-2013. Wśród najistotniejszych zastosowań można
wymienić:
• domowy serwer poczty elektronicznej lub WWW – z jednej strony mały
pobór prądu, a z drugiej pełna funkcjonalność systemu GNU/Linux,
sprawia, że jest to dobra platforma dla małego, domowego serwera3 ,
• domowe centrum multimedialne – dzięki możliwości płynnego odtwarzania filmów w jakości Blueray i dostępnemu złączu HDMI, Raspberry
Pi może być platformą dla prostego zestawu kina domowego czy odtwarzacza muzyki (opartego o system operacyjny XBMC4 ),
3
4
http://www.instructables.com/id/Raspberry-Pi-as-webserver/
http://xbmc.org/
25
• internetowy odbiornik radiowy – podłączony do Internetu poprzez sieć
bezprzewodową oraz wyposażony w głośniki Raspberry Pi może służyć
jako radio5 ,
• kontroler systemu ochrony – małe rozmiary pozwalają zamknąć Raspberry Pi w jednej obudowie z kamerą wideo monitorującą np. okolicę
domu czy podwórka6 ,
• konsola do (retro) gier – dzięki emulatorowi Multiple Arcade Machine
Emulator 7 dostępnemu na systemach GNU/Linux,
• komputer samochodowy – Raspberry Pi może obsługiwać i sterować
nawigacją GPS czy odtwarzaczem muzyki w samochodzie8 ,
• inteligentny dom – w połączeniu z płytką RaZberry 9 Raspberry Pi może
sterować „inteligentnymi” elementami domu (przez protokół ZWave),
• szerokie zastosowanie w robotyce i automatyce – jako kontroler robotów
i maszyn10 .
Powyższa lista nie jest oczywiście kompletna, bo nowe pomysły pojawiają się bardzo szybko – jedynym ograniczeniem jest wydajność Raspberry
Pi oraz wyobraźnia użytkowników. Znajduje on zastosowanie wszędzie tam
gdzie liczą się mały rozmiar oraz niski koszt (m.in. zastosowania „domowe”),
zastępując często profesjonalne urządzenia wbudowane, tam gdzie niezawodność nie jest krytycznym problemem. W mojej pracy dyplomowej zajmę się
zastosowaniem tego mini-komputera jako serwera poczty elektronicznej – a
konkretniej platformy sprzętowej dla bramki S/MIME.
3.4
Ocena i odbiór platformy
Popularność Raspberry Pi świadczy, że dobrze wpasował się on w zapotrzebowanie użytkowników. Można zadać pytanie, czy jest to faktycznie wartościowa platforma mająca szansę zrewolucjonizować informatykę? A może to
tylko kolejny gadżet lub zabawka?
Wielość i różnorodność projektów opartych o Raspberry Pi potwierdza
szerokie spektrum zastosowań tego rozwiązania – bynajmniej nie ograniczają
5
http://www.jan-holst.dk/pi-radio/pi-radio.html
http://www.raspberrypi.org/archives/5071
7
http://mamedev.org/
8
http://lifehacker.com/build-your-own-car-computer-with-a-raspberry-pi-1434527032
9
http://razberry.z-wave.me/
10
http://www.raspberrypi.org/archives/tag/robots
6
26
się one do środowisk akademickich. Bez wątpienia istotna jest tu cena i niskie
koszty eksploatacji, co pozwoliło na realizację wielu amatorskich projektów i
eksperymentowanie bez narażania się na duże straty finansowe. Błyskawicznie
wytworzyła się też duża i aktywna społeczność użytkowników (fora, blogi i
czasopisma) wspierająca osoby mniej obeznane w arkanach informatyki. Nie
sposób odmówić Raspberry Pi walorów edukacyjnych – nauczyciele dostali do
ręki nowe narzędzie do prezentacji wielu zagadnień informatyki. Dodatkową
zaletą jest tu fakt, że Raspberry Pi oparty jest prawie11 wyłącznie na wolnym
oprogramowaniu (ang. free software).
Pośród wielu entuzjastycznych głosów pojawili się jednak też ludzie sceptycznie podchodzący do nowej platformy12 . W pierwszej kolejności wymieniają oni niską wydajność i niewielką wartość biznesową – dla praktycznych,
dużych, komercyjnych projektów. Twierdzą, że to tylko zabawka, przejściowa
moda, która nie będzie miała większego wpływu na rozwój informatyki. Być
są to słuszne uwagi, ale pamiętajmy, że Raspberry Pi nie był projektowany do
celów biznesowych, a Eben Upton i jego koledzy nie stworzyli tezy o rewolucji
w informatyce. Raspberry Pi od początku miał być platformą wspomagającą
edukację.
Inną wadą jest brak dokumentacji sprzętowej układu BCM2835 . Niestety
firma Broadcom nie zgodziła się jej udostępnić. Ujęło to w pewnym stopniu
wartość edukacyjną platformy – nie pozwalając zainteresowanym użytkownikom „zajrzeć do środka”.
Wyjątkiem są tu biblioteki graficzne firmy Broadcom.
http://www.i-programmer.info/professional-programmer/i-programmer/
3419-raspberry-pi-or-programming.html
11
12
Rozdział 4
Bramka S/MIME na platformie
Raspberry Pi
Pierwsze pytanie związane z pomysłem uruchomienia bramki S/MIME na
platformie Raspberry Pi brzmiało: czy będzie możliwe jej poprawne skompilowanie i uruchomienie na niestandardowym sprzęcie i systemie operacyjnym? Zarówno architektura ARM, jak i system operacyjny Raspbian, były tu
potencjalnym źródłem problemów – czy ze względu na niekompatybilność bibliotek systemowych, czy brak potrzebnego oprogramowania. Zgodnie z jednym założeń projektowych bramka S/MIME miała być możliwie niezależna
od zewnętrznych bibliotek, aby zapewnić przenośność na inne platformy –
dawało to nadzieję na pomyślną instalację na nowej platformie.
4.1
Uruchomienie bramki S/MIME na Raspberry Pi
Domyślnie mini-komputery Raspberry Pi są dostarczane z systemem operacyjnym Raspbian preinstalowanym na karcie SD. Raspbian to wolny system
operacyjny oparty na dystrybucji Debian GNU/Linux , zoptymalizowany dla
konfiguracji sprzętowej Raspberry Pi – precyzyjniej oparty jest o wersję dystrybucji Debian (w wersji 7 „Wheezy”) na architekturę armhf i sprofilowany
dla zestawu instrukcji ARMv6 . Raspberry Pi Foundation, która opiekuje się
Raspbianem, dostarcza ponad 35 tysięcy pakietów oprogramowania zoptymalizowanych dla najlepszej wydajności na Raspberry Pi.
Bramka S/MIME poza bibliotekami standardowymi języka C oraz systemowymi (m.in. BSD sockets) dostępnymi w każdym systemie linuksowym
(a więc w Raspbianie także), wykorzystuje oprogramowanie kryptograficzne
Rozdział 4. Bramka S/MIME na platformie Raspberry Pi
28
OpenSSL. To popularna biblioteka dostępna na większości uniksopodobnych
systemów operacyjnych – nie zabrało jej również tutaj.
Kompilacja programu bramki w nowym środowisku przebiegła pomyślnie. Potrzebne paczki zawierające kompilator GCC, bibliotekę standardową
języka C, biblioteki systemowe oraz bibliotekę OpenSSL były domyślnie zainstalowane w systemie. Skompilowany w nowym środowisku program uruchomił się bez żadnych problemów.
4.2
Poprawki w kodzie źródłowym bramki
S/MIME
W trakcie pisania tej pracy dyplomowej oraz testów wydajności wykryłem
kilka drobnych błędów w działaniu programu bramki, czego wynikiem był
szereg poprawek w kodzie źródłowym. Do tego dołączyły się zmiany wynikające z potrzeb przeprowadzanych badań – skrypty tworzące środowisko dla
testów i wspomagające monitorowanie pracy systemu operacyjnego, a także
samej bramki S/MIME.
Wiele z nich to jedynie drobne modyfikacje związane z wyświetlaniem
komunikatów, porządkami w drzewie projektu i opisach, ale kilka zawiera
istotne poprawki błędów – wśród nich należy wymienić:
1. Naprawienie błędu związanego z odroczonym wysyłaniem przesyłek w
przypadku niedostępności serwera pocztowego – przez użycie niewłaściwej funkcji błąd połączenia z serwerem powodował zakończenie procesu. W efekcie odebrane i zapisane przesyłki zostawały w katalogu
tymczasowym zamiast zostać przeniesione do katalogu przesyłek niewysłanych, czyli w praktyce gubione.
2. Naprawienie błędu związanego z niepoprawnym działaniem licznika
procesów potomnych – był to problem bardzo trudny do zdiagnozowania i choć rozwiązanie okazało się proste, to rzecz jest na tyle ciekawa
i wieloaspektowa, że opisałem tę kwestię szerzej w Dodatku B.
3. Poprawienie obsługi źle sformatowanych wiadomości MIME w skrypcie smime-tool – wcześniej w przypadku wiadomości niezawierającej
nagłówka MIME skrypt zakańczał się bez komunikatu i bez zwrócenia kodu błędu, nie pozwalając w ten sposób na poprawną obsługę tej
sytuacji przez program bramki.
4. Poprawienie algorytmu rozszerzania bufora wiadomości – użyty wcześniej algorytm liniowy (rozszerzający bufor co 512 bajtów) powodował
29
problemy w wydajnością obsługi większych (ponad 90 KB) przesyłek
(patrz rozdział 5.4.4).
4.3
Zarządzanie i administracja
Rozbudowanie pliku Makefile o reguły instalacji skompilowanego programu
bramki S/MIME pozwoliło na łatwe uruchomienie jej w dowolnym uniksopodobnym systemie operacyjnym – w Raspbianie także. Konieczne było jedynie
dostosowanie konfiguracji do potrzeb badań wydajności (patrz rozdział 5.1).
Na listingach 4.1 i 4.2 są pokazane zawartości kolejno głównego pliku konfiguracyjnego i pliku z regułami szyfrowania przesyłek.
1
# S/MIME Gate c o n f i g u r a t i o n f i l e
# SMTP Port , smime−g a t e w i l l l i s t e n on i t
s m t p p o r t = 5555
5
# rules f i l e location
rules = ./ rules
10
# Mail s e r v e r a d d r e s s and p o r t
mail srv addr = 192.168.7.1
m a i l s r v p o r t = 5780
Listing 4.1: Zawartość pliku konfiguracyjnego /etc/smime-gate/config.
1
# S/MIME Gate r u l e s f i l e
# Encryption r u l e s
ENCR encrypt@example . o r g . / c e r t r e p o / ca / n e w c e r t s / 0 2 . pem
5
# Signing rules
SIGN sign@example . o r g . / c e r t r e p o / ca / n e w c e r t s / 0 1 . pem \
. / c e r t r e p o / newkey01 . pem qwerty
Listing 4.2: Zawartość pliku konfiguracyjnego /etc/smime-gate/rules.
Bramka S/MIME nasłuchiwała i odbierała przesyłki na porcie 5555. Przetworzone wiadomości były odsyłane do serwera SMTP dostępnego pod adresem 192.168.7.1 i nasłuchującego na porcie 5780. Podsieć 192.168.7.0/24
została utworzona specjalnie na potrzeby badań (patrz rozdział 5.1). Zarówno serwer SMTP, jak i bramka były uruchamiane z prawami zwykłego
użytkownika – dlatego nie używały typowego dla protokołu SMTP portu
578.
30
Na cele testów utworzyłem dwie reguły przetwarzania przesyłek. Pierwsza powoduje zaszyfrowanie przesyłek wysłanych na adres [email protected]. Według drugiej przesyłki wysłane z adresu
[email protected] są podpisywane cyfrowo. W obu przypadkach typ użytego klucza asymetrycznego to RSA o długości 2048-bit (certyfikaty zostały
wygenerowane za pomocą narzędzia openssl). Przesyłki były szyfrowane
przy pomocy algorytmu symetrycznego AES128, a używana w podpisie elektronicznym funkcja skrótu to SHA-1.
4.4
Środowisko testów i narzędzia pomocnicze
Na potrzeby wykonywania badań utworzyłem w drzewie projektu katalog
testing/smtp-benchmark, który był kompletnym środowiskiem potrzebnym
do uruchomienia bramki S/MIME (na Raspberry Pi) oraz serwera SMTP (po
stronie maszyny obciążającej). Znalazły się w nim:
• program prostego serwera SMTP,
• linki symboliczne do pliku wykonywalnego bramki S/MIME i narzędzia
smime-tool,
• pliki konfiguracyjne config i rules (patrz listingi 4.1 i 4.2),
• skrypty wspomagające przeprowadzanie testów:
– smime-gate-setenv: skrypt przygotowujący środowisko dla
bramki S/MIME według podanych parametrów,
– rpi-status: skrypt „sklejający” kilka programów monitorujących
stan systemu (patrz rozdział 5.2),
– templog: prosty skrypt logujący pomiary z czujnika temperatury
układu BCM2835 (patrz rozdział 5.2.4)
• repozytorium certyfikatów urzędu certyfikacji (ang. certificate authority, CA) utworzone na potrzeby badań.
4.5
Podsumowanie
Platforma Raspberry Pi pod względem programowym nie różni typowego systemu GNU/Linux. Dzięki temu można na niej łatwo uruchomić wiele popularnych aplikacji – w tym stworzoną przeze mnie w ramach pracy dyplomowej
31
inżynierskiej bramkę S/MIME. Uruchomienie całości rozwiązania (bramka
S/MIME plus Raspberry Pi) nie wymagało ani dużych nakładów finansowych
ani czasowych. Za tym można wnosić, że platforma Raspberry Pi jest dobrym
uzupełnieniem „sprzętowego braku” pierwotnej koncepcji bramki S/MIME.
Pozostaje jednak pytanie o wydajność takiego zestawu – tę kwestię rozważam
w rozdziale 5. Przeprowadzone badania i testy ujawniły w programie bramki
kilka błędów, które udało się pomyślnie naprawić – tym samym ją rozwijając
i udoskonalając.
Rozdział 5
Badanie wydajności platformy
Raspberry Pi
Podstawową kwestią w pytaniu o przydatność platformy Raspberry Pi w zastosowaniach profesjonalnych jest jej wydajność i niezawodność. Większość
firm elektroniczno-informatycznych wciąż podchodzi z dystansem do tego
mini-komputera, ale nawet w Polsce pojawiły się już pierwsze próby wykorzystania Raspberry Pi w przemyśle, m.in. w branży ciepłowniczej1 . Dodatkowym problemem w zastosowaniach przemysłowych jest odporność na trudne
warunki środowiska pracy – wysokie temperatury, drgania mechaniczne czy
zakłócenia w sieci elektrycznej.
W mojej pracy skupiłem się badaniu ograniczeń wydajnościowych minikomputera Raspberry Pi, pracującego jako serwer poczty elektronicznej. Testowałem przede wszystkim wydajność sieciową (TCP/IP + SMTP) i obliczeniową (szyfrowanie S/MIME) platformy. Nie poruszam natomiast zagadnienia odporności na warunki i środowisko pracy.
5.1
Środowisko testowe
Przeprowadzanie wiarygodnych badań wydajności platformy Raspberry Pi
wymagało przygotowania środowiska testowego, które pozwoliłoby na zdefiniowanie i utrzymanie stabilnych warunków wykonywania testów. Moim celem nie było tu stworzenie środowiska odpowiadającego rzeczywistemu, ale
pozwalającego maksymalnie obciążyć badany mini-komputer – pod względem wydajności filtracji ruchu TCP/IP na poziomie aplikacyjnym (w protokole SMTP) oraz filtracji wymagającej przetwarzania kryptograficznego.
Firma Newterm zaprojektowała i wyprodukowała zastępnik dla sterownika ZElektronik bazujący na platformie Raspberry Pi . Źródło: http://newterm.pl/node/79.
1
Rozdział 5. Badanie wydajności platformy Raspberry Pi
33
Należało zatem wziąć tu pod uwagę dwie kwestie – wydajność maszyny obciążającej oraz przepustowość połączenia sieciowego. Na rysunku 5.1 znajduje się zdjęcie podstawowego środowiska testowego użytego do badań nad
wydajnością Raspberry Pi .
Rysunek 5.1: Środowisko testowe dla badania wydajności bramki S/MIME
na Raspberry Pi (zdjęcie).
Wydajność obliczeniowa Raspberry Pi jest porównywalna do procesora
R
R
2 , dlatego też do testów wydajnościowych wystarczający
Pentium
Intel
był zwykły komputer klasy PC. Rolę maszyny obciążającej pełnił kompuR
R
ThinkPadTM Edge E431 , posiadający procesor Intel
ter przenośny Lenovo
CoreTM i5-3230M o taktowaniu 2,60GHz (4-rdzeniowy).
Aby uniknąć zakłóceń w transmisji pakietów między komputerem a Raspberry Pi, połączenie zostało realizowane jako połączenie bezpośrednie (ang.
direct connection) Ethernet o przepustowości 100 Mb/s. Dzięki takiej strukturze wykluczone zostały opóźnienia transmisji spowodowane przekazywaniem pakietów poprzez ruter (ang. router ) lub przełącznik (ang. switch).
Na komputerze ThinkPad działał zarówno program obciążający bramkę,
jak i prosty serwer SMTP, który odbierał przetworzone przesyłki, a także
serwer DHCP (ang. Dynamic Host Configuration Protocol ) – całość pod kontrolą systemu operacyjnego Debian GNU/Linux w aktualnej wersji testowej
(Jessie). W trakcie testów na Raspberry Pi uruchomiona była – poza programem bramki S/MIME – sesja programu SSH wraz z potrzebnymi programami monitorującymi wydajność i parametry pracy systemu. Dodatkowo w
tle działały wszystkie domyślnie uruchamiane serwisy i demony dla aktualnej
wersji systemu operacyjnego Raspbian.
5.1.1
34
Konfiguracja przekaźnika
Wszystkie testy wydajnościowe były wykonywane w opisanej powyżej konfiguracji, jednak celem weryfikacji, czy przepustowość łącza i wydajność maszyny obciążającej jest wystarczająca, powtórzyłem najistotniejsze testy w
konfiguracji przekaźnika (ang. relay) (rys. 5.2).
Rysunek 5.2: Środowisko testowe dla badania wydajności bramki S/MIME
na Raspberry Pi, konfiguracja przekaźnika.
Bramka ma tu uruchomione dwa interfejsy sieciowe, podobnie jak typowe serwery przekazujące pocztę elektroniczną (ang. mail relay), a odebrane wiadomości są przesyłane do innej maszyny niż maszyna obciążająca.
Raspberry Pi posiada tylko jedno złącze RJ-45, więc konieczne było użycie
klucza sprzętowego USB (ang. USB dongle) dodającego drugie złącze. Rolę
serwera SMTP odbierającego przetworzone przesyłki pełnił komputer klasy
R
R
Dual-Core E2160 o taktowaniu 1,8GHz
Pentium
PC z procesorem Intel
(2-rdzeniowy) pracujący pod kontrolą systemu operacyjnego Slackware GNU/Linux w wersji 14.1.
5.2
35
Monitorowanie pracy systemu
System operacyjny Debian GNU/Linux oferuje szereg narzędzi monitorujących jego wydajność. Spośród nich wybrałem trzy, dostarczające potrzebny
zestaw parametrów pracy systemu – część z nich jest powielona, ale każde
narzędzie wylicza statystyki w trochę inny sposób, stąd jest to korzystne.
Wybrane programy to vmstat, iostat oraz top.
5.2.1
Obsługa programu vmstat
Narzędzie vmstat raportuje statystki pamięci wirtualnej. Dostarcza informacji o procesach, pamięci operacyjnej, stronicowaniu, blokowym odczycie
i zapisie wejścia/wyjścia, przerwaniach, aktywności dysków oraz obciążeniu
procesora. Pobrane z wywołania vmstat 1 1 statystyki będą przestawiane
tak jak na listingu 5.1 – jest to pewien wybrany podzbiór parametrów, przedstawiony w formie podobnej do tej, jaką zwraca domyślnie program.
1
−p r o c s − −−−−−−−memory−−−−−−− −−−−i o −−−− −system−− −−−cpu−−−
r b
free
b u f f cache
bi
bo
in cs
us sy i d
0 0 372332
9860 28000
12
0 314 38
1 0 99
Listing 5.1: Wyjście programu vmstat dla nieobciążonego systemu.
Patrząc według kolumn, w pierwszej grupie (procs) znajdują się kolejno
liczba aktywnych procesów (r) oraz liczba uśpionych (oczekujących) procesów (b). Druga grupa (memory) to statystyki pamięci operacyjnej – kolejno
pamięć wolna (free), pamięć używana jako bufory (buff) oraz pamięć podręczna (cache) – wartości podane są w bajtach. Grupa io zawiera liczbę bloków pamięci odebranych (bi) oraz wysłanych (bo) przez urządzenie blokowe
(karta SD w przypadku Raspberry Pi ). Kolejna grupa, czyli system, jest bardzo istotna – jest to liczba przerwań (włącznie z przerwaniami zegara) (in)
i liczba przełączeń kontekstu (cs) w czasie jednej sekundy. Ostatnia grupa
(cpu) zawiera statystyki pracy procesora, czyli procent czasu spędzonego na
wykonywaniu kodu spoza jądra systemu (ang. user time) (us), wewnątrz
jądra (ang. system time) (sy) oraz czasu bezczynności (ang. idle) (id).
5.2.2
Obsługa programu iostat
Program iostat był używany pomocniczo i dostarcza bardziej szczegółowych statystyk dotyczących urządzeń wejścia/wyjścia. Na listingu 5.2 pokazane jest wyjście programu. W pierwszej linii znajdują się informacje o systemie operacyjnym (wersja jądra, nazwa hosta, aktualna data, architektura
36
procesora oraz liczba rdzeni/procesorów). Linia druga zawiera informacje o
obciążeniu jednostki obliczeniowej – jest tu więcej kategorii niż w przypadku
vmstat. Ostatnia grupa to statystyki pracy urządzania blokowego – w przypadku Raspberry Pi jest to karta SD (urządzenie mmcblk0 ). Kolejne kolumny
to: liczba transferów na sekundę (tps), wielkość odczytanych (kB read/s) i
zapisanych (kB wrtn/s) danych na sekundę oraz sumaryczna wielkość odczytanych (kB read) i zapisanych (kB wrtn) danych od uruchomienia systemu.
1
Linux 3 . 1 0 . 2 5 + ( g r a f z e r o )
avg−cpu :
%u s e r
0.97
02/16/2014
%n i c e %system %i o w a i t
0.00
2.10
0.24
armv6l
%s t e a l
0.00
( 1 CPU)
%i d l e
96.70
5
Dev ic e :
mmcblk0
tps
2.13
kB read / s
47.38
kB wrtn / s
1.63
kB read
43085
kB wrtn
1484
Listing 5.2: Wyjście programu iostat dla nieobciążonego systemu.
5.2.3
Obsługa programu top
Program top w większości powiela statystyki poprzednich narzędzi, jednakże
dostarcza szerszych informacji o aktualnie działających procesach i ich stanach. Listing 5.3 przedstawia nagłówek wyjścia programu, poniżej niego znajduje się lista procesów istniejących w systemie operacyjnym.
1
5
top − 0 7 : 5 1 : 5 6 up 15 min , 1 u s e r , l o a d a v e r a g e : 0 . 0 0 , 0 . 0 3 , 0 . 0 5
Tasks : 65 t o t a l , 1 running , 64 s l e e p i n g , 0 stopped , 0 zombie
%Cpu : 1 . 0 us , 2 . 0 sy , 0 . 0 ni , 9 6 . 7 id , 0 . 2 wa , 0 . 0 hi , 0 . 0 s i , 0 . 0 s t
KiB Mem: 448180 t o t a l , 60576 used , 387604 f r e e , 9792 b u f f e r s
KiB Swap : 102396 t o t a l ,
0 used , 102396 f r e e , 27944 cached
< l i s t a procesow>
Listing 5.3: Wyjście programu top dla nieobciążonego systemu.
5.2.4
Czujnik temperatury w Raspberry Pi
Raspberry Pi został wyposażony w jeden wewnętrzny czujnik temperatury
znajdujący się w układzie BCM2835 . Ze względu na fakt, że firma Broadcom nie udostępniła dokumentacji sprzętowej swojego produktu, zazwyczaj
stosowane w systemach Linux narzędzie lm-sensors nie potrafi go poprawnie
37
Temperatura układu BCM2835 (°C)
55
50
45
40
35
30
0
5
10
15
20
25
30
35
40
45
Czas (minuty)
Rysunek 5.3: Wykres temperatury układu BCM2835 w czasie pracy pod
obciążeniem.
wykryć. W zamian firma Broadcom w ramach wbudowanego oprogramowania (ang. firmware) udostępniła narzędzie vcgencmd, które wywołane z opcją
measure temp zwraca aktualną temperaturę układu (listing 5.4)
1
r o o t @ g r a f z e r o :˜# / opt / vc / b i n / vcgencmd measure temp
temp =42.8 ’C
Listing 5.4: Pomiar temperatury dla nieobciążonego systemu.
Wykres 5.3 przedstawia pomiary temperatury układu w czasie pracy pod
obciążeniem – od uruchomienia do osiągnięcia temperatury maksymalnej.
Nie odnotowano przegrzewania się komputera Raspberry Pi ani innych nieprawidłowości. Pod obciążeniem układ osiąga temperaturę około 52 stopni
Celsjusza.
5.3
38
Ruch TCP/IP
W pierwszej kolejności doświadczalnie sprawdziłem faktyczną przepustowość
połączenia między hostami. Jako, że sesje SMTP są realizowane przy pomocy
protokołu TCP, przetestowałem wydajność transmisji tego typu w sieci IP.
Testy miały odpowiedzieć na pytania: czy maszyna obciążająca jest w stanie
wygenerować odpowiednio duży ruch, a przez to w wystarczającym stopniu
obciążyć testowany mini-komputer? Jak duża jest wydajność Raspberry Pi
dla samej transmisji TCP/IP?
5.3.1
Narzędzie nuttcp
Do testowania wydajności transmisji TCP/IP użyłem programu nuttcp dostępnego w systemie Debian GNU/Linux . To typowe narzędzie używane do
pomiaru wydajności protokołu TCP lub UDP w sieci komputerowej. Posiada
on duże możliwości konfiguracyjne, jednak w wypadku testowania maksymalnej możliwej wydajności transferu, konfiguracja domyślna jest wystarczająca.
Program nuttcp bazuje na kodzie programu nttcp, który to z kolei jest
ulepszoną i rozszerzoną (przez jednego z pracowników firmy Silicon Graphics)
wersją oryginalnego programu ttcp, napisanego przez Mike’a Muussa w Ballistic Research Laboratory (około roku 1984). Z tego też powodu nuttcp ma
wiele zaszłości – m.in. tryby pracy dziś już niezalecane lub mało użyteczne
oraz kilka opcji, których znaczenie jest obecnie niewielkie. Rozszerza on za
to możliwości poprzedników o opcje TCP/IP wprowadzone w latach późniejszych – np. wsparcie dla IPv6 czy IPv4 multicast.
5.3.1.1
Obsługa programu nuttcp
W zalecanym trybie pracy, jeden z hostów przyjmuje rolę serwera (uruchamiany z opcją -S). Drugi natomiast zostaje klientem, który wysyła (-t) lub
odbiera (-r) ramki od serwera. Poza opcjami obowiązkowymi wykorzystałem
następujące:
• -T<liczba sekund> – określa jak długo ma być prowadzona transmisja
(domyślnie przez 10 sekund),
• -i<liczba sekund> – określa co ile sekund będzie wyświetlany raport
z transmisji (domyślnie brak – wyświetlane jest tylko podsumowanie
na koniec testu).
W domyślnej konfiguracji bufory danych są przesyłane pomiędzy pamięcią operacyjną hostów, bez zapisywania ich na nośniki trwałe. Istnieje co
39
prawda opcja -s pozwalająca modyfikować te cechę, ale w teście przepustowości połączenia ograniczyłoby to niepotrzebnie wydajność hostów.
5.3.2
Testy wydajności TCP/IP
Zakładając większą wydajność komputera ThinkPad , na nim uruchomiłem
serwer nuttcp – to nieduże, ale jednak istniejące obciążenie. Na Raspberry Pi
wywołałem polecenie klienta, kolejno z opcją -t oraz -r. Testy wykonałem
w domyślnym czasie 10 sekund.
Czas (s) Ilość danych (MB) Szybkość transferu (Mb/s)
1,00
11,1875
93,8362
1,00
11,1875
93,7857
1,00
11,2500
94,4369
1,00
11,1875
93,7471
1,00
11,2500
94,4247
1,00
11,1875
93,7987
1,00
11,2500
94,3787
1,00
11,1875
93,9024
1,00
11,2500
94,3671
1,00
11,1875
93,8549
Czas testu
10,00 s
Podsumowanie testu
Ilość przesłanych danych Szybkość transferu
RTT
TX
112,2405 MB
94,0811 Mb/s
0,70 ms 1%
Tablica 5.1: Test nuttcp dla odbiornika (-r).
W tabeli 5.1 znajdują się wyniki testu, gdy Raspberry Pi był odbiornikiem. Ruch był zatem generowany przez komputer ThinkPad i to jego wydajność tu badałem. W podsumowaniu testu widać, że w ciągu 10 sekund
zostało przesłanych 112,2405 MB danych, co daje przepustowość łącza na
poziomie 94 Mb/s – to wartość bliska przepustowości deklarowanej. Strata
około 6% przepustowości wynika z narzutu protokołów (kolejno Ethernet,
IP oraz TCP) – można więc uznać, że ograniczeniem jest tu wydajność łącza, a nie komputera. Zawarte w podsumowaniu kolumny TX i RX pokazują
procent zajętości karty sieciowej na Raspberry Pi – kolejno dla wysyłania
(TX) i odbioru (RX) ramek. Widać, że sam odbiór danych nie jest trudny
wydajnościowo, bo karta była obciążona tylko w połowie.
Tu należałoby zadać pytanie, czy łącze o przepustowości 100 Mb/s zdoła
wysycić bramkę S/MIME działającą na Raspberry Pi . Biorąc jednak pod
RX
52%
40
Czas (s) Ilość danych (MB) Szybkość transferu (Mbps)
1.00
8.0625
67.6315
1.00
8.0625
67.6331
1.00
8.1875
68.6828
1.00
8.1250
68.1569
1.00
8.1875
68.6824
1.00
8.1875
68.6810
1.00
8.1875
68.6818
1.00
8.1250
68.1581
1.00
8.1875
68.6816
1.00
8.1875
68.6823
Czas testu
10,00 s
Podsumowanie testu
RTT
TX RX
81,5625 MB
68,3725 Mb/s
0,87 ms 99% 8%
Tablica 5.2: Test nuttcp dla nadajnika (-t).
uwagę fakt konieczności zapisu każdej przesyłki na pamięć trwałą i ewentualne szyfrowanie, nie powinno to stanowić problemu. Właściwe testy wydajności działania bramki pokażą czy tak jest faktycznie.
Tabela 5.1 przedstawia wyniki testu, gdy Raspberry Pi był nadajnikiem,
a więc ruch był generowany przez niego. Można się zatem spodziewać, że
ujawni się ograniczenie wydajności Raspberry Pi , bo najbardziej wymagające
„obliczenia” są po jego stronie. Asymetria wyników jest bardzo wyraźna,
gdyż tym razem w ciągu 10 sekund udało się przesłać jedynie 81,5625 MB
danych – szybkość wynosi zatem około 68 Mb/s. To ponad 41 mniej niż przy
odbiorze. Powodem jest tu zbyt mała wydajność karty sieciowej Raspberry
Pi , która w czasie testu były całkowicie obciążona. To rozwiewa wątpliwości o
braku koniecznej mocy obliczeniowej lub za małej przepustowości łącza, aby
obciążyć badany mini-komputer. Tym bardziej, że działająca na Raspberry
Pi bramka S/MIME będzie zarówno odbierać, jak i wysyłać przesyłki.
1
−p r o c s − −−−−−−−memory−−−−−−− −−−−i o −−−− −−system−− −−−cpu−−−
r b
free
b u f f cache
bi
bo
in
cs
us sy i d
1 0 369960 11296 30280
12
1 4088 386
5 36 59
Listing 5.5: Wyjście programu vmstat podczas testu jako odbiornik.
Na koniec uruchomiłem testy dla dłuższego czasu (20 minut) i sprawdziłem stan systemu za pomocą programu vmstat. W obu przypadkach –
odbiornik (listing 5.5) i nadajnik (listing 5.6) – ponad połowę czasu procesor
41
jest bezczynny. Za to liczba przerwań i przełączeń kontekstu wzrosła znacznie – tu zatem prawdopodobnie znajduje się wąskie gardło. Dokładniej tę
kwestię zbadam przy właściwych testach bramki S/MIME.
1
r b
free
b u f f cache
bi
bo
in
cs
us sy i d
1 0 369176 11528 30284
9
1 5311 371
5 47 48
Listing 5.6: Wyjście programu vmstat podczas testu jako nadajnik.
5.3.2.1
Konfiguracja przekaźnika
Dla porównania przeprowadziłem testy drugiego połączenia sieciowego wykorzystywanego w konfiguracji przekaźnika (patrz rozdział 5.1.1). Wyniki
pomiarów przedstawione są w tabelach 5.3 i 5.4. Średnia prędkość odbioru
danych to 84,23 Mb/s, a wysyłania to 67,54 Mb/s. Pierwsza wartość jest
1
, co może wynikać z opóźnień w przesyłaniu danych przez
mniejsza o około 10
magistralę USB lub ograniczeń samego rozszerzenia sprzętowego (ang. dongle). Tę tezę nie-wprost potwierdza niezmieniona szybkość wysyłania danych
przez Raspberry Pi – można wnioskować, że zmierzone 84,23 Mb/s jest górnym ograniczeniem szybkości transferu danych przez dodany, zewnętrzny interfejs sieciowy.
W konfiguracji przekaźnika istotna jest jednak szybkość wysyłania danych
przez Raspberry Pi do serwera SMTP, a ta nie uległa zmianie. Ponownie ograniczeniem jest tu wydajność sprzętowa Raspberry Pi, a nie przepustowość
łącza.
42
Czas (s) Ilość danych (MB) Szybkość transferu (Mbps)
1.01
9.7500
80.9108
1.00
9.8125
82.6775
1.00
9.9375
82.9519
1.00
10.0625
84.4155
1.00
10.0625
84.4565
0.99
9.9375
84.2409
1.01
10.1875
84.4617
0.99
10.0000
84.4477
1.00
10.0625
84.3845
1.00
10.0625
84.5194
Czas testu
10,01 s
Podsumowanie testu
RTT
TX
100.5394 MB
84,2248 Mb/s
0.51 ms 0%
RX
94%
Tablica 5.3: Test nuttcp dla odbiornika (-r) w konfiguracji relay.
Czas (s) Ilość danych (MB) Szybkość transferu (Mb/s)
1.00
8.0000
67.1079
1.00
8.0000
67.1093
1.00
8.0000
67.1089
1.00
8.0000
67.1089
1.00
8.0625
67.6332
1.00
8.0625
67.6332
1.00
8.1250
68.1574
1.00
8.0625
67.6333
1.00
8.1250
68.1574
1.00
8.0625
67.6332
Czas testu
10,00 s
Podsumowanie testu
RTT
TX RX
80,5625 MB
67,5377 Mb/s
0,64 ms 99% 5%
Tablica 5.4: Test nuttcp dla nadajnika (-t) w konfiguracji relay.
5.4
5.4.1
43
Poczta elektroniczna (SMTP)
Narzędzie Postal
Do podstawowych testów wydajność bramki pod kątem protokołu SMTP wykorzystałem narzędzie Postal wchodzące w skład Linux Benchmark Suite 2 .
Dostępny tam program postal pozwala na łatwe testowanie wydajności serwerów SMTP – jest to prosty klient SMTP, który stara się możliwie szybko
wysyłać wiadomości o losowej treści do zadanego serwera.
5.4.1.1
Obsługa programu postal
Program postal udostępnia zestaw podstawowych opcji konfiguracyjnych,
które określają sposób działania klienta SMTP. Poniżej krótki opis wykorzystanych przy testach opcji:
• -m – maksymalny rozmiar przesyłki pocztowej podany w kilobajtach,
faktyczny rozmiar jest liczbą losową o rozkładzie równomiernym z zakresu ograniczonego zerem i tą wartością. Domyślny rozmiar przesyłek
to od 0 do 10 KB. Ustawienie jako maksimum wartości 0 sprawi, że
program będzie wysyłał wiadomości nie zawierające treści przesyłki
(ang. content) – pozwala to na testowanie wydajności obsługi samych
połączeń z serwerem. Modyfikacja tego parametru pozwoli sprawdzić
czy wąskim gardłem jest obsługa połączeń czy raczej przetwarzanie
wiadomości i jak zależy to od ich wielkości.
• -t – liczba równoległych wątków, w których wiadomości są wysyłane
do serwera. Zakładając, że komputer obciążający bramkę ma znacznie
większą wydajność, modyfikacja tego parametru pozwala symulować
wielu niezależnych klientów wysyłających przesyłki do serwera. Serwer SMTP z założenia powinien być współbieżny (i tak napisana jest
bramka S/MIME), należy jednak zadać pytanie o wydajność obsługi
wielu połączeń i granicę obciążenia, po przekroczeniu której serwer
przestanie nadążać z przetwarzaniem przesyłek.
• -c – liczba wiadomości wysyłanych w ramach jednej sesji SMTP. Ten
parametr pozwala sprawdzić, jak dużym narzutem jest obsługa połączenia i sesji. Faktyczna liczba wysłanych wiadomości jest liczbą losową
między 1 a ustawioną wartością (domyślnie: 1). Dla typowych serwerów
podłączonych bezpośrednio do sieci ta wartość powinna wynosić 2-3,
2
http://lbs.sourceforge.net/
44
dla dużych serwerów przekazujących pocztę (ang. mail relay) może natomiast przyjmować bardzo duże wartości (od kilkudziesięciu do kilku
tysięcy).
Poza powyższymi opcjonalnymi parametrami uruchamiając program należy określić oczywiście adres obciążanego serwera, port SMTP, a także listę
adresów nadawców i odbiorców. Powyżej wypunktowane opcje posłużą za
modyfikowalne parametry w testach wydajności.
5.4.2
Testy wstępne i sposób opisu
Pierwszy test wykonałem używając domyślnych opcji programu postal. Wiadomości były wysyłane przez jeden wątek, miały rozmiar od 0 do 10 KB, a w
czasie jednej sesji SMTP wysyłana była jedna wiadomość. Żadna wiadomość
nie była szyfrowana.
Czas (min) Liczba wiadomości Ilość danych Liczba sesji
1
1789
9720
1789
2
1785
9854
1785
3
1824
9890
1824
4
1775
9453
1775
5
1747
9585
1747
6
1778
9434
1778
7
1774
9714
1775
8
1787
9856
1787
9
1757
9690
1757
10
1818
9951
1818
Tablica 5.5: Test wstępny – czas testu: 10 minut, liczba wątków: 1, rozmiar
wiadomości: 0-10 KB, liczba wiadomości na sesję: 1, procent wiadomości
szyfrowanych: 0%.
Tabela 5.5 zawiera zestawienie pomiarów z testu wstępnego (ujęte w histogramy na rys. 5.4 i 5.5), który w moich badaniach jest również testem
odniesienia. W pierwszej kolumnie znajduje się oznaczenie czasu – pomiary
rejestrowane były co minutę, kolejne wiersze tabeli zawierają pomiary dla kolejnych minut testu. Czas testu to zawsze 10 minut. Druga kolumna zawiera
liczbę wysłanych wiadomości w danej minucie. W trzeciej znajduje się sumaryczny rozmiar przesłanych wiadomości w kilobajtach. Ostatnia zawiera
liczbę sesji SMTP, w których wiadomości zostały przesłane.
45
Liczba wiadomości (na minutę)
2000
1750
1500
1250
1000
750
500
250
0
1
2
3
4
5
6
7
8
9
10
Czas (min)
Rysunek 5.4: Wykres liczby przesłanych wiadomości w poszczególnych minutach testu.
12000
Wielkość danych (KB/min)
10000
8000
6000
4000
2000
0
1
2
3
4
5
6
7
8
9
10
Czas (min)
Rysunek 5.5: Wykres wielkości przesłanych danych w poszczególnych minutach testu.
46
Surowe dane pomiarowe nie są jednak najlepszym materiałem do analizy
wydajności bramki. Na ich podstawie można wyliczyć kilka wartości statystycznych, których użyłem w dalszej analizie:
• Nm – średnia liczba przesłanych wiadomości (na minutę),
• Nσ – odchylenie standardowe liczby przesłanych wiadomości,
• Vm – średnia wielkość przesłanych danych (na minutę),
• Sm – średni rozmiar pojedynczej przesyłki,
s
• Nm
– średnia liczba wiadomości na sesję.
Dla testu wstępnego wynoszą one kolejno:
Nm = 1783, 4 wiadomosci/min
Nσ = 23, 81
Vm = 9714, 7 KB/min
Sm = 5, 45 KB
s
= 1, 00 wiadomosci/sesje
Nm
Bramka S/MIME (w podstawowej konfiguracji) jest w stanie obsłużyć
około 1783 wiadomości na minutę (bez szyfrowania) przesyłając przy tym
około 9714,7 KB danych. Odchylenie standardowe liczby przesłanych wiadomości wynosi 23,81 – czyli wydajność odbioru przesyłek jest bardzo stabilna.
s
Parametry Sm i Nm
mają charakter kontrolny – tu są zgodne z oczekiwaniami, bo średni rozmiar wiadomości wynosi około 5 KB (co jest średnią w
rozkładzie równomiernym o zakresie od 0 do 10), a na każdą sesję przypada
jedna wiadomość (zgodnie z ustawieniami).
Wszystkie przeprowadzone pomiary ujęte są w tabele podobne do tabeli
5.5 i znajdują się w Dodatku A. Dla każdej 10-minutowej serii pomiarowej
wyliczyłem opisane powyżej wartości statystyczne, które znajdują się pod
każdą tabelą. Posłużyły one do dalszej analizy i wygenerowania wykresów
przedstawionych w kolejnych rozdziałach.
5.4.3
47
Testy ze względu na liczbę równoległych połączeń
Pierwszym badanym przeze mnie parametrem była liczba równoległych połączeń do bramki, co w przypadku używanego narzędzia postal przełożyło się
na zmianę liczby wątków programu (opcja -t). Raspberry Pi wyposażony jest
w jednordzeniowy procesor z rodziny ARM11 stąd należało się spodziewać
wysycenia już na poziomie kilku wątków.
Testy przeprowadziłem kolejno dla 1-5, 8, 10, 20 i 40 równoległych połączeń przy domyślnym ustawieniu pozostałych parametrów – rozmiar wiadomości 0-10 KB oraz jedna wiadomość na sesję SMTP. Wykonane pomiary
zawarte są w tabelach A.2-A.9. Uśrednione wyniki liczby przesłanych wiadomości oraz wielkości przesłanych danych na minutę dla poszczególnych
wartości parametru -t są przedstawione na rysunkach 5.6 i 5.7.
Oba wykresy są bardzo podobne, gdyż ze względu na stały średni rozmiar
wiadomości, liczba przesłanych wiadomości jest bezpośrednio skorelowana z
wielkością przesłanych danych. Zależność od liczby równoległych połączeń
jest zgodna z przewidywaniem, wysycenie następuje już dla 4-5 wątków. Zaobserwowany wzrost wydajności między 1 wątkiem a wartością maksymalną
wynosi około 12 .
3400
3200
3000
2800
2600
2400
2200
2000
1800
1600
0
5
10
15
20
25
30
35
40
Liczba wątków
Rysunek 5.6: Wykres liczby przesłanych wiadomości na minutę w zależności
od liczby równoległych połączeń.
48
19000
18000
17000
16000
15000
14000
13000
12000
11000
10000
9000
0
5
10
15
20
25
30
35
40
Liczba wątków
Rysunek 5.7: Wykres wielkości przesłanych danych na minutę w zależności
od liczby równoległych połączeń.
Otrzymane wyniki należy interpretować z dwóch perspektyw. Z jednej
wysnuwając wnioski na temat wydajności Raspberry Pi i jego układów, a z
drugiej patrząc na wydajność i poprawność implementacji programu bramki
S/MIME. Badania wydajności aplikacji wielowątkowych na Raspberry Pi
przeprowadzone w [18] potwierdzają, że powyżej kilku współbieżnych wykonań programu mimo większej liczby wątków wydajność wyjściowa pozostaje
stała. Wynika to z założeń architektury ARM skierowanej przede wszystkim na systemy wbudowane, a nie serwery usług sieciowych. Zaletą jest za
to skalowalność w sensie braku regresji wydajności przy zbyt dużej liczbie
działających aktywnie procesów.
Do analogicznych wniosków można dojść w odniesieniu do implementacji bramki S/MIME. Ta zależność wynika jednak z faktu, że bramka tworzy osobny, niezależny proces dla każdego połączenia i cały problem obsługi
współbieżności przeniesiony jest na system operacyjny. W tej perspektywie
zwiększanie liczby wątków nie powinno w żaden sposób wpłynąć na pracę
bramki poza mniejszą dostępnością zasobów systemowych (pamięci operacyjnej i czasu procesora).
Należy zadać jeszcze pytanie o faktyczny powód granicy maksymalnej wydajności. Na listingu 5.7 pokazane są statystyki pracy systemu pod obciążeniem. Jasno widać, że powodem tu nie jest zbyt mała wydajność obliczeniowa
49
procesora, ponieważ przez ponad 90% czasu i tak jest on bezczynny. Wzrosła
natomiast znacznie liczba przerwań oraz przełączeń kontekstu (kolumny in
oraz cs) w porównaniu z stanem systemu nieobciążonego (listing 5.1). Dodatkowo procesy bramki przez większość czasu wykonują procedury systemowe
(7,07% czasu), a nie własny kod (2,57% czasu). Wniosek z tego taki, że procesy bramki większość czasu spędzają czekając na obsługę stosu TCP/IP –
układ ten znajduje się poza procesorem (podłączony przez magistralę USB)
– dlatego nie widać tego w wygenerowanych statystykach. Drugim ograniczeniem jest czas tworzenia nowych procesów i przełączania kontekstu, co potwierdzają badania w [22]. Główną zaletą procesorów ARM pozostaje niski
pobór prądu, niestety uzyskany kosztem wydajności – zarówno obliczeniowej,
jaki i „systemowej” (tj. związanej z obsługą procesów, wywołań systemowych
R
AtomTM ) wyetc.). Niektóre alternatywne rozwiązania (np. procesory Intel
przedzają pod tym względem produkt firmy ARM Holdings, choć ta różnica
nie jest bardzo duża.
1
5
r b
free
b u f f cache
bi
bo
in
cs
us sy i d
24 0 357476 11948 31312
7
3
661 162
3 7 90
avg−cpu :
%u s e r
2.57
%system
7.07
%i o w a i t
0.04
%i d l e
90.32
Listing 5.7: Parametry pracy systemu podczas obciążenia 20 równoległymi
połączeniami do bramki S/MIME.
5.4.4
Testy ze względu na rozmiar przesyłek
W kolejnej grupie testów zbadałem wpływ rozmiaru przesyłek na liczbę
przesyłanych wiadomości oraz wielkość przesyłanych danych. W programie
postal użyłem opcji -m, która steruje maksymalnym rozmiarem wiadomości.
Tu jednak trzeba zaznaczyć, że faktyczny rozmiar wiadomości jest liczbą losową z przedziału od 0 do ustawionej wartości (domyślnie 10 KB). Nie jest to
błąd metodologiczny, gdyż ten test ma m.in. sprawdzić wydajność zarządzania pamięcią przez Raspberry Pi i jej fragmentacją. Dlatego też zmienny rozmiar jest w tym teście wręcz pożądany. Z punktu widzenia bramki S/MIME
przesyłanie mniejszej liczby większych przesyłek powinno redukować narzut
związany z sesją SMTP, a w konsekwencji prowadzić do większej przepustowości pod względem wielkości przesyłanych danych.
Istotną kwestią w ocenie tych testów jest rozmiar wiadomości przesyłanych w rzeczywistym środowisku – należy zatem odnieść się tu do statystyk z sieci Internet. Średni rozmiar przesyłki dla należącej do mnie skrzynki
50
pocztowej (używanej od sierpnia 2006 roku) wynosi około 77 KB. Według
badań przeprowadzonych w [2] dla przedsiębiorstw ta wartości wynosi około
20 KB (mediana natomiast jest nawet poniżej tej wartości). Stąd wniosek, że
większość przesyłanych wiadomości ma rozmiar co najwyżej kilkudziesięciu
kilobajtów.
Przeprowadzone testy wykazały, że użyty pierwotnie liniowy algorytm
rozszerzania bufora powoduje problemy z wydajnością dla większych przesyłek (o rozmiarze ponad 90 KB). Rozszerzanie bufora w sposób geometryczny
(podwajanie wielkości, tj. sn+1 = sn · 2) dało znaczy wzrost przepustowości. Dlatego też wszystkie testy zostały powtórzone dla poprawionej wersji
programu bramki.
5.4.4.1
Liniowy algorytm rozszerzania bufora
W wersji pierwotnej bramka S/MIME rozszerzała bufor wiadomości w sposób liniowy z krokiem 512 bajtów (tj. sn+1 = sn + 512). Jak wykazały przeprowadzone testy dla różnych rozmiarów wiadomości (tabele A.10-A.17), ta
metoda powodowała anomalie wydajności dla większych wiadomości. W tym
rozdziale analizuję ten problem, opisując z czego on wynika.
1800
Algorytm liniowy
Algorytm geometryczny
1600
1400
1200
1000
800
600
400
200
0
0
200
400
600
800
1000
1200
Rozmiar wiadomości (średni, KB)
od rozmiaru wiadomości.
51
Wykres liczby wiadomości pokazany na rysunku 5.8 („Algorytm liniowy”)
jest zgodny z przewidywaniami i nie wykazuje anomalii. Jeśli maksymalna
przepustowość jest stała, to zwiększenie rozmiaru wiadomości powoduje
zmniejszenie liczby przesyłanych wiadomości, co jednak nie powinno wiązać
się ze spadkiem wielkości przesyłanych danych. Tej tezy nie potwierdza jednak wykres wielkości przesłanych danych (rys. 5.9, „Algorytm liniowy”). Po
początkowym szybkim wzroście następuje załamanie (w okolicach 90 KB)
i szybki spadek wraz z dalszym zwiększaniem rozmiaru. Wyjaśnienie tego
osobliwego zjawiska wymaga zrozumienia, w jaki sposób bramka S/MIME
zarządza pamięcią podczas odbioru przesyłki pocztowej i jak może wpływać
to na pracę systemu operacyjnego.
1
5
10
#define MAIL START LEN
512
/∗ d e f a u l t m a i l b l o c k s i z e ∗/
/∗ s m t p r e c v m a i l d a t a − a c c e p t m a i l d a t a from c l i e n t ∗/
s s i z e t s m t p r e c v m a i l d a t a ( int s o c k f d , char ∗∗ b u f p t r ,
size t ∗ buf size )
{
s i z e t b u f l e n ; /∗ m a i l b u f f e r l e n g t h
∗/
size t n;
/∗ c u r r e n t b u f f e r s i z e ( r e a l ) ∗/
char ∗ buf ;
/∗ b u f f e r p o i n t e r
∗/
char ∗ temp buf ; /∗ temporary b u f f e r p o i n t e r
∗/
char ∗ p t r ;
/∗ c u r r e n t p o s i t i o n i n b u f f e r ∗/
[...]
i f ( n == b u f l e n ) {
b u f l e n += MAIL START LEN ;
temp buf = buf ;
buf = m a l l o c ( b u f l e n ∗ s i z e o f ( char ) ) ) ) ;
p t r = buf+n ;
memcpy ( buf , temp buf , n ) ;
f r e e ( temp buf ) ;
temp buf = NULL;
}
15
20
[...]
25
}
Listing 5.8: Zarządzanie pamięcią przez bramkę S/MIME w funkcji
smtp recv mail data().
Na listingu 5.8 pokazana jest procedura powiększania bufora danych (dla
większej czytelności bez obsługi błędów dla funkcji systemowych). Gdy wielkość odebranych danych przekroczy rozmiar bufora (linia 15), rezerwowany
jest nowy, większy bufor (linie 16-18), po czym zawartość starego bufora jest
52
kopiowana do nowego (linia 20) i na koniec stary bufor jest zwalniany (linia 21). To dosyć prymitywna metoda zarządzania pamięcią – jednak czas
zużyty na kopiowanie bufora nie jest tutaj jedynym problemem. Złożoność
funkcji memcpy() jest co najwyżej klasy O(N ) (zależna od wielkości kopiowanego obszaru). Podobnie liczba rozszerzeń bufora zależy liniowo od jego
rozmiaru. Tymczasem po przekroczeniu progu 90 KB przepustowość maleje
w sposób wielomianowy. To nie wielokrotne kopiowanie bufora jest zatem
głównym powodem anomalii.
Niezależnie od rozmiaru, wiadomość jest ostatecznie przechowywana w
jednym, ciągłym obszarze pamięci, zarezerwowanym biblioteczną (glibc)
funkcją malloc(). Jej ostatnie wywołanie w funkcji smtp recv mail data()
jest żądaniem obszaru pamięci o rozmiarze wiadomości – co w przypadku
dużych wiadomości sięga kilkuset do kilku tysięcy kilobajtów (od 217 do 221
bajtów). Należy zadać pytanie, czy i jak szybkość przydzielenia obszaru pamięci przez funkcję malloc() zależy od jego wielkości. Ta kwestia jest szerzej
opisana w [14] i [1].
Według przeprowadzonych tam badań czas wykonania funkcji malloc()
zaczyna rosnąć wykładniczo dla żądań obszarów większych niż około 64 KB.
Wśród powodów należy wymienić przede wszystkim fragmentację pamięci
90000
80000
70000
60000
50000
Algorytm liniowy
Algorytm geometryczny
40000
30000
20000
10000
0
0
200
400
600
800
1000
1200
od rozmiaru wiadomości.
53
i brak mechanizmów oddzielających alokacje małych obszarów od dużych.
Stąd wynika stosunkowo długi czas „oczekiwania” na przydzielenie bloku
pamięci. Ten czas potęguje dodatkowo fakt, że bramka dokonuje alokacji
nowego bufora co 512 bajtów (wartość stałej MAIL START LEN), więc np. w
przypadku przesyłki o rozmiarze 64 KB funkcja malloc() jest wołana aż
128 razy – ta liczba powtórzeń uwidacznia opóźnienia przydzielania bloków
pamięci.
5.4.4.2
Geometryczny algorytm rozszerzania bufora
Należało zatem zredukować liczbę relokacji bufora. Jedną z metod jest zmiana
algorytmu jego rozszerzania na geometryczny – tzn. mnożący rozmiar bufora
o stały czynnik (sn+1 = sn · q). Przeprowadziłem testy dla czynnika q = 2. Ta
prosta zmiana istotnie zmniejszyła liczbę rozszerzeń bufora (np. dla przesyłki
o rozmiarze 64 KB bufor będzie poszerzany zaledwie 8 razy) w efekcie dając
znaczną poprawę przepustowości bramki. Wyniki testów wykonane z nowym
algorytmem znajdują się w tabelach A.18-A.25.
Wzrost przepustowości jest już widoczny na wykresie liczby wiadomości
(rys. 5.8, „Algorytm geometryczny”), jednak zdecydowanie lepiej tę różnicę
widać na wykresie wielkości przesłanych danych (rys. 5.9, „Algorytm geometryczny”). Przede wszystkim nie ma tutaj punktu załamania – przepustowość
rośnie aż do średniego rozmiaru około 512 KB, gdzie następuje nasycenie.
Dalsze zwiększanie rozmiaru nie powoduje spadku wydajności. Według pomiarów wykonanych programem vmstat (listing 5.9) wąskim gardłem jest
tutaj moc jednostki obliczeniowej Raspberry Pi – 60% czasu procesor spędza
na wykonywaniu kodu w przestrzeni użytkownika, a 36% kodu systemowego.
1
r b
free
b u f f cache
bi
bo
in
cs
us sy i d
1 0 361280 12524 32436
34
14 3104 218
60 36 3
Listing 5.9: Parametry pracy systemu podczas obciążenia wiadomościami
o rozmiarze 0-2048 KB.
5.4.5
Testy ze względu na liczbę równoległych połączeń i rozmiar wiadomości
Rozszerzając testy przeprowadzone w rozdziałach 5.4.3 i 5.4.4 zbadałem zależność liczby przesłanych wiadomości i wielkości przesłanych danych jednocześnie od dwóch parametrów – liczby równoległych połączeń i rozmiaru
przesyłek. Wyniki pomiarów znajdują się w tabelach A.26-A.74. Testy były
54
przeprowadzone dla wszystkich kombinacji wartości parametrów użytych w
poprzednich testach – czyli kolejno dla 1-5, 8, 10 i 20 wątków (opcja -t) oraz
rozmiarów maksymalnych 10, 32, 64, 128, 256, 512, 1024 i 2048 KB (opcja
-m). Wykresy dla poszczególnych rozmiarów oznaczone są teoretyczną wartością średnią rozmiaru – wartość rzeczywista może nieco od niej odbiegać.
Testy były wykonane dla wersji programu z geometrycznym algorytmem rozszerzania bufora o czynniku q = 2.
Zależność od liczby przesłanych wiadomości ponownie nie zaskakuje (wykres na rys. 5.10). Wraz ze wzrostem rozmiaru spada liczba wiadomości, a
liczba równoległych połączeń przestaje mieć znaczenie. Ta ostatnia obserwacja prowadzi do wniosku, że wąskim gardłem jest tu narzut związany z sesją
SMTP i przetwarzaniem wiadomości. Liczba przesłanych wiadomości nie jest
jednak miarodajna – lepiej patrzeć na wydajność bramki przez pryzmat przepustowości mierzonej w wielkości przesłanych danych.
Wykres wielkości przesłanych danych znajduje się na rysunku 5.11 i w
charakterze zależności jest bardzo podobny do wykresu liczby wiadomości.
Wraz ze wzrostem rozmiaru zwiększa się przepustowość bramki, a liczba wątków przestaje mieć znaczenie. Dla większej klarowności przedstawiłem tę zależność na wykresie trójwymiarowym (rys. 5.12).
3500
5 KB
16 KB
32 KB
64 KB
128 KB
256 KB
512 KB
1024 KB
3000
2500
2000
1500
1000
500
0
0
2
4
6
8
10
12
14
16
18
20
Liczba wątków
od liczby równoległych połączeń i rozmiaru wiadomości.
90000
5 KB
16 KB
32 KB
64 KB
128 KB
256 KB
512 KB
1024 KB
80000
55
70000
60000
50000
40000
30000
20000
10000
0
0
2
4
6
8
10
12
14
16
18
20
Liczba wątków
Na podstawie tych pomiarów można wysnuć szereg wniosków dotyczących
granic wydajności bramki S/MIME:
• większy wpływ na wielkość przesłanych danych ma rozmiar wiadomości niż liczba równoległych połączeń – z czego wynika, że czynnikiem
ograniczającym jest narzut związany z sesją SMTP i przetwarzaniem
wiadomości,
• szybki wzrost wielkości przesłanych danych dla małych przesyłek wynika z faktu, że większość czasu proces obsługi spędza na czynnościach
związanych z przetwarzaniem przesyłki, a nie przesyłaniem jej przez
sieć – tu zwiększenie liczby wątków wypełnia „szczelniej” dostępną
przepustowość sieci (wydajność procesora nie gra tu roli, jak wynika
ze statystyk pracy systemu z listingu 5.7),
• maksymalna przepustowość dla wiadomości „średniej wielkości”, czyli
o rozmiarze średnim 64 KB, wynosi około 64 MB/min (1000 wiadomości/min) – tę wartość można uznać za przybliżoną maksymalną przepustowość w rzeczywistym środowisku,
56
90000
80000
70000
60000
50000
40000
30000
20000
10000
0
1200
1000
800
600
400
200
0
0
2
4
6
8
10
12
14
16
18
20
Liczba wątków
5.4.6
Testy ze względu na liczbę wiadomości na sesję
SMTP
Ostatnim badanym przeze mnie parametrem związanym z protokołem SMTP
była liczba wiadomości przesłana w jednej sesji (opcja -c). Testy te przedstawiam na końcu, gdyż wynikająca z nich zależność była łatwa do przewidzenia,
a same testy nie przyniosły tu zaskoczenia.
Zwiększenie liczby wiadomości przesyłanych w jednej sesji SMTP redukuje narzut związany z samą sesją – choć nie jest to tak znaczące, jak w
przypadku zmiany rozmiaru. Wykresy liczby przesłanych wiadomości (rys.
5.13) i wielkości przesłanych danych (rys. 5.14) pokazują identyczną zależność – ze względu na stały rozmiar przesyłek oba parametry są silnie skorelowane. Podobnie jak przy rozmiarze (opcja -m), faktyczna liczba wiadomości
wysłanych w jednej sesji jest liczbą losową o rozkładzie równomiernym ograniczonym jedynką i ustaloną wartością maksymalną.
Należy tu poświęcić akapit zdefiniowaniu czym jest „narzut na sesję
SMTP”. W najprostszym ujęciu są to wszystkie czynności niezwiązane bezpośrednio z przesyłaniem danych (tj. treści przesyłki) przez sieć. SMTP jest
protokołem tekstowym opierającym się na schemacie komenda-odpowiedź
(patrz rozdział 2.1.1.1) – pierwszą grupą będą więc opóźnienia związane
57
z „konwersacją” między serwerem a klientem (ustalenie parametrów sesji,
adresatów/nadawców wiadomości, zakończenie sesji). Należy tu uwzględnić
także opóźnienia nawiązywania i zamykania połączenia TCP/IP. Idąc dalej,
zgodnie z dokumentem [12] serwer ma obowiązek zapisać odebraną przesyłkę
na pamięć trwałą przed potwierdzeniem jej odbioru – to kolejny narzut. W
przypadku małych wiadomości samo jej przesłanie może trwać krócej niż
czynności związane z obsługą sesji SMTP.
Na potrzeby testów zmodyfikowałem kod bramki usuwając ograniczenie
liczby wiadomości na sesję (domyślnie ustawione na poziomie 10). Z pomiarów wynika jednak, że ustawienie tego parametru powyżej 10 nie przynosi
znacznego zysku przepustowości. Z kolei zmiana liczby równoległych połączeń nie wpływa na charakter zależności – większy wzrost wynika jedynie z
większej liczby procesów „korzystających” z nowego limitu. Przy założeniu,
że w granicy (wszystkie wiadomości wysyłane w jednej sesji) narzut związany
z obsługą sesji maleje do zera, to z otrzymanych pomiarów można wyliczyć
przybliżony narzut, jakim obarczona jest pojedyncza sesja SMTP – wynosi
on około 21 .
6500
6000
5500
5000
4500
1 wątek
8 wątków
4000
3500
3000
2500
2000
1500
0
10
20
30
40
50
60
Liczba wiadomości na sesję (średnia)
liczby wiadomości na sesję SMTP.
58
35000
30000
25000
1 wątek
8 wątków
20000
15000
10000
5000
0
10
20
30
40
50
60
Liczba wiadomości na sesję (średnia)
od liczby wiadomości na sesję SMTP.
5.4.7
Testy zbiorcze i podsumowanie
Na podstawie przeprowadzonych w rozdziałach 5.4.3, 5.4.4, 5.4.5 i 5.4.6 testów wydajności, ograniczających sensowne kombinacje parametrów, dobrałem je tak, aby uzyskać maksymalną przepustowość bramki S/MIME. Pomiary dla najlepszego znalezionego zestawu parametrów znajdują się w tabelach A.87 oraz A.88. Pierwsza seria dotyczy bramki z domyślnym ograniczeniem 10 wiadomości na sesję SMTP, druga przesuwa je do wartości 100.
Bramka S/MIME działająca na platformie Raspberry Pi jest w stanie
przesłać do 83,5 MB nieszyfrowanych wiadomości w ciągu jednej minuty,
co stanowi około 11% dostępnej przepustowości łącza. Optymalny zestaw
parametrów to:
• 3 równoległe połączenia,
• wiadomości o rozmiarze 0-1024 KB,
• 10 wiadomości na sesję SMTP.
Wyniki analogicznych testów dla konfiguracji przekaźnika znajdują się w
tabelach A.138 (por. A.1), A.139 (por. A.87) oraz A.140 (por. A.100). Nie
wykazały one jednak wyraźniej różnicy w wydajności bramki – stąd wniosek,
59
że konfiguracja standardowa z połączeniem dwukierunkowym nie ogranicza
przepustowości łącza w stopniu zniekształcającym wyniki właściwych testów.
Ta seria testów kończy badania wydajności protokołu SMTP na Raspberry Pi. Uzyskana przepustowość maksymalna wystarczy z pewnością do
zastosowań prywatnych i dla małych przedsiębiorstw. Przeprowadzone testy
ujawniły zarówno wady (niska wydajność CPU), jaki pozytywne cechy (skalowalność ze względu na liczbę równoległych połączeń i rozmiar wiadomości,
odporność na przeciążenia) implementacji bramki S/MIME i mini-komputera
Raspberry Pi. Właściwym jej przeznaczeniem nie było jednak zwykłe przekazywanie poczty, a szyfrowanie przesyłek – o tej kwestii traktuje kolejny
rozdział.
5.5
60
Wydajność bramki S/MIME (OpenSSL)
Celem powstania bramki S/MIME było przetwarzanie kryptograficzne przesyłek pocztowych według zadanych reguł. Dlatego też druga grupa testów
dotyczy wydajności obliczeniowej Raspberry Pi i działającej na nim bramki
S/MIME. Bardziej szczegółowe badania przeprowadziłem dla jednej formy
przetwarzania kryptograficznego – dla szyfrowania.
W testach opisanych w tym rozdziale badanym parametrem jest
liczba wiadomości szyfrowanych przez bramkę S/MIME. Tę wielkość wyrażam w procencie wiadomości, których dotyczy reguła szyfrowania. Reguły zdefiniowane na potrzeby testów są przedstawione na listingu 4.2
(patrz rozdział 4.3) – szyfrowane są wszystkie przesyłki wysłane na adres
[email protected]. Program postal pobiera adresy nadawców z podanego jako argument wywołania pliku – adresy są wybierane według prostego
algorytmu karuzelowego (ang. round robin), stąd wpisując w nim odpowiednią liczbę adresów [email protected] w stosunku do innych adresów
(np. [email protected]) można sterować liczbą wiadomości, które zostaną
zaszyfrowane.
5.5.1
Testy ze względu na liczbę szyfrowanych lub podpisywanych elektronicznie wiadomości
W pierwszej kolejności przeprowadziłem testy dla konfiguracji domyślnej (1
wątek, rozmiar wiadomości 0-10 KB, 1 wiadomość na sesję) i konfiguracji
optymalnej (3 wątki, rozmiar wiadomości 0-1024 KB, 10 wiadomości na sesję) zarówno dla szyfrowania, jak i podpisu elektronicznego. Ustaliłem następujące kwanty dla liczby przetwarzanych kryptograficznie wiadomości: 0%,
5%, 10%, 20%, 40%, 80% i 100%. Wiadomości były szyfrowane przy użyciu
algorytmu AES128, a funkcją skrótu użytą przy podpisie było SHA-1 – w obu
przypadkach użyty klucz asymetryczny to RSA o długości 2048-bit. Wyniki
pomiarów znajdują się w tabelach A.89-A.100 oraz A.126-A.137.
We wszystkich przypadkach testowych widocznych na wykresach 5.15
oraz 5.16 wraz ze wzrostem liczby przetwarzanych kryptograficznie wiadomości następuje szybki spadek przepustowości. W przypadku dużej liczby szyfrowanych wiadomości potrzeba było kilku minut na ustabilizowanie się pomiarów. Wynikało to z faktu, że obsługa wiadomości nieszyfrowanych trwała
znacznie krócej, przez co na początku testu, póki czas procesora nie był jeszcze wykorzystywany w większości na szyfrowanie, większa ich liczba przechodziła przez bramkę niejako „wyprzedzając” wiadomości przetwarzane kryptograficznie. Sytuacja odwrotna miała miejsce po zakończeniu testu – procesy
1800
1 wątek, 5KB, 1 wiad/sesję (AES128)
1 wątek, 5KB, 1 wiad/sesję (SHA-1)
3 wątki, 512KB, 10 wiad/sesję (AES128)
3 wątki, 512KB, 10 wiad/sesję (SHA-1)
1600
61
1400
1200
1000
800
600
400
200
0
0
20
40
60
80
100
Procent wiadomości szyfrowanych (%)
Rysunek 5.15: Wykres liczby przesłanych wiadomości na minutę w zależności liczby szyfrowanych (AES128) lub podpisanych elektronicznie (SHA-1)
wiadomości.
obsługujące zakolejkowane do zaszyfrowania wiadomości potrzebowały kilku
minut na zakończenie przetwarzania.
Bramka S/MIME używa do szyfrowania wiadomości narzędzia openssl
dostępnego z poziomu powłoki systemowej. Nie jest to najbardziej optymalne z punktu widzenia wydajności rozwiązanie. Decyzja projektowa dotycząca wyboru biblioteki/narzędzia szyfrującego wynikła z faktu, że w
tamtym czasie nie istniała inna, dobrej jakości i do tego bezpłatna biblioteka kryptograficzna obsługująca S/MIME. W efekcie bramka używa napisanego przeze mnie narzędzia smime-tool, które jest nakładką na narzędzie
openssl, ułatwiającą jego użycie przez bramkę. To rozwiązanie, z pewnością
wygodne, w pewnym stopniu ogranicza wydajność bramki. Pomijając fakt, że
smime-tool jest skryptem powłoki Bash zaszyfrowanie wiadomości wymaga
utworzenia aż trzech nowych procesów – procesu powłoki (w której zostanie uruchomiony skrypt), dodatkowego procesu (używanego przez skrypt do
wyłuskania wiadomości MIME z przesyłki pocztowej) i procesu openssl.
Na powyższe nakłada się ponadto niska wydajność procesora ARM11.
Na listingu 5.10 znajdują się wyniki pomiarów wydajności szyfrowania wykonane narzędziem openssl speed. Raspberry Pi w ciągu minuty jest w
stanie zaszyfrować około 900 MB danych algorytmem AES128, co przy śred-
90000
1 wątek, 5KB, 1 wiad/sesję (AES128)
1 wątek, 5KB, 1 wiad/sesję (SHA-1)
3 wątki, 512KB, 10 wiad/sesję (AES128)
3 wątki, 512KB, 10 wiad/sesję (SHA-1)
80000
62
70000
60000
50000
40000
30000
20000
10000
0
0
20
40
60
80
100
od liczby szyfrowanych (AES128) lub podpisanych elektronicznie (SHA-1)
wiadomości.
nim rozmiarze 512 KB daje 1757 wiadomości. Trudniejsze wydajnościowo
jest podpisywanie/szyfrowanie kluczem RSA – zaledwie 822 wiadomości na
minutę. Zakładając, że połowę czasu bramka spędzi na szyfrowaniu kluczem
symetrycznym, a połowę na szyfrowaniu kluczem prywatnym RSA (co raczej
nie jest prawdą, ale da to wyobrażenie rzędu wielkości), to bramka powinna
być w stanie zaszyfrować około 400 wiadomości na minutę – tymczasem dla
konfiguracji optymalnej przy wszystkich wiadomościach szyfrowanych ta wartość jest znacznie mniejsza.
1
5
OpenSSL 1 . 0 . 1 e 11 Feb 2013
b u i l t on : Sun Mar 24 1 2 : 4 4 : 0 0 UTC 2013
The ’ numbers ’ a r e i n 1000 s o f b y t e s p e r s e c o n d p r o c e s s e d .
type
16 b y t e s
64 b y t e s
256 b y t e s
1024 b y t e s
sha1
1895.72 k
6205.26 k
15451.14 k
24749.94 k
aes −128 cbc 1 3 0 0 2 . 3 6 k
15121.30 k
15474.86 k
15646.72 k
r s a 2048 b i t s
sign
0.072993 s
verify
0.002260 s
sign /s
13.7
verify /s
442.4
Listing 5.10: Pomiar wydajności algorytmów kryptograficznych na Raspberry Pi dla biblioteki OpenSSL.
1
5
63
−p r o c s − −−−−−−−memory−−−−−−− −−−−i o −−−− −system−− −−−cpu−−−
r b
free
b u f f cache
bi
bo
in cs
us sy i d
58 0
22644
3200 117136
52
244 586 318
66 21 13
Number o f smime−g a t e p r o c e s s e s : 230
Listing 5.11: Parametry pracy systemu w trakcie maksymalnego obciążenia.
Listing 5.11 przedstawia parametry pracy systemu pod maksymalnym
obciążeniem – 3 wątki, rozmiar wiadomości 0-1024 KB, 10 wiadomości na
sesję i 100% wiadomości szyfrowanych. Nawet w tej sytuacji czas procesora
nie jest w pełni wykorzystany (13% pozostaje bezczynne). Warto jednak zauważyć, że pod takim obciążeniem bramka „wyprodukowała” 230 procesów
(włączając w to procesy narzędzi smime-tool). Wysokie też pozostają wartości liczby przerwań i przełączeń kontekstu. Ilość wolnej pamięci operacyjnej
to zaledwie 22 MB.
Na wyjściową wydajność bramki, poza stosunkowo niewielką mocą obliczeniową CPU, ma wpływ szereg innych czynników. Przedstawione na listingu 5.10 przepustowości są wygenerowane przy założeniu, że program zajmuje się tylko i wyłącznie szyfrowaniem – co nie jest prawdą przy filtracji
przesyłek pocztowych. Jak pokazały wcześniejsze testy, już sama obsługa sesji
SMTP jest dla Raspberry Pi wymagająca. Dodatkowo system poświęca część
czasu procesora na tworzenie nowych procesów, zarządzanie nimi i przełączenie kontekstów. W efekcie przepustowość bramki w konfiguracji optymalnej
i szyfrującej każdą wiadomości wynosi około 5,8 MB/min.
5.5.2
Testy ze względu na liczbę szyfrowanych przesyłek i rozmiar wiadomości
Gwoli uzupełnienia przeprowadziłem testy szyfrowania dla różnych rozmiarów przesyłek, żeby sprawdzić czy wydajność przetwarzania ich przez bramkę
zależy od tego parametru. Wyniki są przedstawione na wykresach 5.17 i 5.18,
wygenerowanych na podstawie pomiarów znajdujących się w tabelach A.101A.125.
Oba wykresy wyglądają bardzo podobnie – widać na nich, że wraz ze
wzrostem liczby szyfrowanych wiadomości rozmiar traci na znaczeniu. Dla
ponad 80% szyfrowanych wiadomości wielkość przetwarzanych danych jest w
niewielkim stopniu zależna od rozmiaru wiadomości. Potwierdza to tezę, że
większość mocy obliczeniowej jest zużywana na czynności „dookoła” szyfrowania – m.in. odbiór/wysyłanie przesyłek.
1800
64
5 KB
16 KB
64 KB
128 KB
512 KB
1024 KB
1600
1400
1200
1000
800
600
400
200
0
0
20
40
60
80
100
od procenta szyfrowanych (AES128) wiadomości i ich rozmiaru.
90000
5 KB
16 KB
64 KB
128 KB
512 KB
1024 KB
80000
70000
60000
50000
40000
30000
20000
10000
0
0
20
40
60
80
100
Rysunek 5.18: Wykres wielkości przesłanych wiadomości na minutę w zależności od procenta szyfrowanych (AES128) wiadomości i ich rozmiaru.
65
90000
80000
70000
60000
50000
40000
30000
20000
10000
0
0
20
40
60
80
100
0
1100
1000
900
800
700
600
500
400 Rozmiar wiad. (średni, KB)
300
200
100
od liczby szyfrowanych wiadomości i ich rozmiaru.
5.6
66
Podsumowanie badań
Właściwie dobrane i użyte narzędzia oraz stabilne środowisko testów pozwoliło na przeprowadzenie wiarygodnych badań wpływu różnych czynników na
wydajność pracy bramki S/MIME na mini-komputerze Raspberry Pi . Ujawniły one kilka ukrytych aspektów obu komponentów rozwiązania – zarówno
pozytywnych (stabilność pracy pod obciążeniem, skalowalność), jak i negatywnych (niska wydajność CPU – pod względem mocy obliczeniowej, a także
wielozadaniowości). Wady nie są jednak krytyczne, powodują oczywiście problemy z wydajnością, ale nie występują żadne anomalie pracy.
Poprawienie obsługi szyfrowania w bramce S/MIME z pewnością zwiększyłoby jej wydajność, jednak nie rozwiąże to najistotniejszego problemu.
Badania pokazały, że Raspberry Pi nie oferuje dużej mocy obliczeniowej i
ma problemy z wydajnością przy zbyt dużej liczbie aktywnych procesów.
Ten wniosek nie dziwi – procesory ARM11 nie były projektowane z myślą
o zastosowaniach serwerowych, co jednak nie skreśla ich całkowicie z tego
zastosowania. W małej skali ta wada nie będzie odczuwalna, a niski pobór
prądu i niewielkie rozmiary czynią z Raspberry Pi godną rozważenia opcję
na „domowy” serwer.
Rozdział 6
Podsumowanie
W ramach niniejszej pracy dyplomowej przeprowadziłem badania wydajności
bramki protokołu SMTP szyfrującej i podpisującej przesyłki pocztowe na
platformie Raspberry Pi . Wykonane testy pozwoliły na ocenę jakości zarówno
implementacji bramki S/MIME, jak i mini-komputera Raspberry Pi. Dlatego
też rozbiłem podsumowanie i ocenę wydajności na dwie części.
6.1
Ocena wydajności bramki S/MIME
Ocena wydajności implementacji bramki S/MIME nie była głównym celem
badań, ale trudno ją pominąć, gdyż ma ona wpływ na efektywną wydajność całego rozwiązania. Szeroko zakrojone testy obciążeniowe pozwoliły
ujawnić kilka błędów w programie bramki, które wcześniej nie zostały zauważone. Wśród nich można wymienić kwestię licznika procesów potomnych
(opisaną w Dodatku B), poprawienie obsługi źle sformatowanych wiadomości
MIME, naprawienie błędu związanego z gubieniem odroczonych wiadomości,
a przede wszystkim zmianę algorytmu rozszerzania bufora wiadomości. Jeśli rzecz idzie o aspekty wydajnościowe, to bramka dobrze skaluje się przy
dużej liczbie jednoczesnych połączeń – nie występuje spadek wydajności po
przekroczeniu progu przeciążenia. Problemem jest wydajność przetwarzania
kryptograficznego. Na ile jest to wada istotna zależy od specyfiki użycia –
jeżeli szyfrowana ma być większość przesyłek, to spadek wydajność będzie
znaczny, jeżeli tylko niewielki procent (typowa sytuacja), to nie powinno to
mieć aż tak dużego znaczenia.
W tych wszystkich obserwacjach należy pamiętać, że już w założeniu
bramka S/MIME była skierowana do prywatnych zastosowań oraz małych
i średnich organizacji. Dlatego nie należy porównywać jej do dużych systemów pocztowych (np. postfix lub sendmail ) i wymagać dobrej wydajności w
Rozdział 6. Podsumowanie
68
każdych warunkach pracy. Wymienione powyżej ograniczenia implementacji
nie powodują żadnych widocznych anomalii działania, więc w ogólności jest
ona poprawna – choć nieoptymalna.
6.2
Ocena platformy Raspberry Pi
Jednoukładowy mini-komputer Raspberry Pi w ciągu zaledwie kilku miesięcy
zjednał sobie tysiące użytkowników – nie bez powodu. Ważnym czynnikiem
była tu oczywiście niska cena, ale także jakość za nią oferowana oraz atmosfera i środowisko jakie się wokół niego wytworzyło. Fora dyskusyjne, blogi czy
całe serwisy poświęcone Raspberry Pi – także dla użytkowników nie obeznanych w arkanach informatyki – spowodowały, że niemal każdy mógł po niego
sięgnąć. Efektem są setki pomysłów (wraz z instrukcjami), w jaki sposób
można wykorzystać ów mini-komputer.
W badaniach przeprowadzonych w ramach niniejszej pracy dyplomowej
skupiłem się na zastosowaniu Raspberry Pi jako serwera poczty elektronicznej
– na przykładzie platformy dla bramki S/MIME. Wykonane testy wykazały,
że Raspberry Pi dobrze radzi sobie w takim scenariuszu – o ile pozostajemy w
obszarze zastosowań prywatnych czy o niewielkiej skali. Uzyskana w korzystnych warunkach przepustowość 83 MB/min (bez szyfrowania, 163 przesyłek)
albo 5,6 MB/min (z szyfrowaniem, 10 przesyłek) powinna być zupełności
wystarczająca. Wąskim gardłem komputera Raspberry Pi okazała się niska
wydajność obliczeniowa oraz w pewnym stopniu problem z obsługą zbyt wielu
jednocześnie działających procesów – to koszt wybitnej energooszczędności
procesora ARM11. Jednakże podobnie jak w przypadku bramki, przeciążenie
nie powoduje anomalii działania, a jedynie określony spadek wydajności.
Platforma Raspberry Pi nie jest złotym rozwiązaniem dla wszystkich problemów, ale niewielki koszt płytki połączony z przyzwoitą wydajnością, energooszczędnością, a przede wszystkim stabilnością pracy, sprawia, że jest to
rozwiązanie godne uwagi i rozważenia.
Dodatek A
Tabele pomiarów
A.1
A.1.1
Poczta elektroniczna (SMTP)
Test wstępny
Czas (min) Liczba wiadomości (N) Wielkość danych (KB) Liczba sesji
1
1789
9720
1789
2
1785
9854
1785
3
1824
9890
1824
4
1775
9453
1775
5
1747
9585
1747
6
1778
9434
1778
7
1774
9714
1775
8
1787
9856
1787
9
1757
9690
1757
10
1818
9951
1818
s
Nm
Nσ
Vm
S m Nm
1783,4 23,81 9714,7 5,45 1,00
Tablica A.1: Test wstępny – czas testu: 10 minut, liczba wątków: 1, rozmiar
wiadomości: 0-10KB, liczba wiadomości na sesję: 1, procent wiadomości szyfrowanych: 0%.
Rozdział A. Tabele pomiarów
A.1.2
70
Testy ze względu na liczbę równoległych połączeń
1
2764
15086
2763
2
2824
15470
2825
3
2832
15199
2832
4
2793
15227
2793
5
2790
15274
2790
6
2820
15372
2820
7
2817
15447
2817
8
2821
15061
2821
9
2801
15359
2801
10
2804
15291
2804
s
Nm
Nσ
Vm
S m Nm
2806,6 20,43 15278,6 5,45 1,00
Tablica A.2: Test T1 – czas testu: 10 minut, liczba wątków: 2, rozmiar wiadomości: 0-10KB, liczba wiadomości na sesję: 1.
1
3231
17496
3231
2
3213
17599
3212
3
3222
17488
3223
4
3216
17449
3216
5
3217
17518
3216
6
3194
17427
3194
7
3236
17400
3236
8
3226
17473
3224
9
3210
17494
3210
10
3234
17629
3234
s
Nm
Nσ
Vm
S m Nm
3219,9 12,75 17497,3 5,44 1,00
71
1
3349
18127
3351
2
3341
18402
3342
3
3348
18139
3348
4
3348
18084
3349
5
3349
18219
3349
6
3365
18097
3365
7
3335
18345
3334
8
3352
18150
3353
9
3349
18152
3348
10
3356
18091
3356
s
Nm
Nσ
Vm
S m Nm
3349,2 8,00 18180,6 5,43 1,00
1
3368
18178
3370
2
3364
18262
3364
3
3365
18213
3364
4
3372
18282
3371
5
3370
18047
3371
6
3368
18047
3367
7
3349
18311
3350
8
3366
18230
3367
9
3372
18067
3373
10
3346
18422
3347
s
Nm
Nσ
Vm
S m Nm
3364,0 9,13 18205,9 5,41 1,00
72
1
3234
17507
3237
2
3328
18274
3328
3
3327
18252
3326
4
3346
17992
3348
5
3300
17713
3300
6
3357
18131
3355
7
3327
18078
3326
8
3346
17870
3345
9
3352
17966
3352
10
3314
18248
3313
s
Nm
Nσ
Vm
S m Nm
3323,1 35,97 18003,1 5,42 1,00
1
3355
18242
3353
2
3362
18088
3362
3
3343
18368
3341
4
3364
18014
3367
5
3334
18185
3336
6
3348
18100
3346
7
3345
18108
3344
8
3341
18186
3340
9
3342
17874
3343
10
3367
18342
3369
s
Nm
Nσ
Vm
S m Nm
3350,1 11,22 18150,7 5,42 1,00
Tablica A.7: Test T6 – czas testu: 10 minut, liczba wątków: 10, rozmiar
wiadomości: 0-10KB, liczba wiadomości na sesję: 1.
73
1
3357
18487
3356
2
3366
18311
3364
3
3356
18318
3357
4
3361
18259
3361
5
3358
18235
3358
6
3358
18185
3361
7
3348
18444
3345
8
3340
17960
3343
9
3362
18304
3360
10
3315
18155
3316
s
Nm
Nσ
Vm
S m Nm
3352,1 14,98 18265,8 5,45 1,00
1
3367
18104
3368
2
3360
18350
3355
3
3354
18323
3352
4
3369
18078
3365
5
3371
18184
3370
6
3350
18325
3352
7
3319
17845
3316
8
3369
18324
3370
9
3353
18311
3357
10
3360
18290
3356
s
Nm
Nσ
Vm
S m Nm
3357,2 15,35 18213,4 5,43 1,00
A.1.3
74
Testy ze względu na rozmiar przesyłek
1
1568
25915
1568
2
1601
25992
1601
3
1572
25393
1572
4
1549
25752
1549
5
1584
25776
1584
6
1560
25900
1560
7
1572
25278
1572
8
1560
25574
1560
9
1573
25439
1573
10
1572
26309
1572
s
Nm
Nσ
Vm
Sm
Nm
1571,1 14,18 25732,8 16,38 1,00
Tablica A.10: Test M1.1 – czas testu: 10 minut, liczba wątków: 1, rozmiar
1
1237
40955
1237
2
1258
41961
1258
3
1264
40283
1264
4
1231
40542
1231
5
1253
40657
1253
6
1241
41274
1241
7
1286
40191
1286
8
1252
39652
1252
9
1247
40802
1247
10
1259
40330
1259
s
Nm
Nσ
Vm
Sm
Nm
1252,8 15,61 40664,7 32,46 1,00
75
1
727
47314
727
2
737
47437
737
3
711
46777
711
4
715
46532
715
5
708
47196
708
6
735
46566
735
7
721
47070
721
8
732
46391
732
9
702
46789
702
10
715
46739
715
s
Nm
Nσ
Vm
Sm
Nm
720,3 12,05 46881,1 65,09 1,00
1
451
42973
451
2
446
42829
446
3
437
42526
437
4
431
42618
431
5
430
42659
430
6
420
42868
420
7
423
42621
423
8
436
43440
436
9
443
42679
443
10
431
42392
431
s
Nm
Nσ
Vm
Sm
Nm
434,8 9,84 42760,5 98,35 1,00
76
1
281
38135
281
2
294
37905
294
3
291
37663
291
4
313
38399
313
5
275
37748
275
6
285
38114
285
7
307
38894
307
8
310
38334
310
9
293
38154
293
10
288
38191
288
s
Nm
Nσ
Vm
Sm
Nm
293,7 12,66 38153,7 129,91 1,00
1
103
25645
103
2
90
25687
90
3
100
25848
100
4
107
26695
107
5
109
27122
109
6
113
26764
113
7
104
26562
104
8
100
26169
100
9
87
25521
87
10
94
25404
94
s
Nm
Nσ
Vm
Sm
Nm
100,7 8,33 26141,7 259,60 1,00
77
1
36
16965
36
2
36
16343
36
3
33
14256
33
4
34
16475
34
5
29
14068
29
6
33
15670
33
7
26
15070
26
8
31
14398
31
9
22
11317
22
10
31
15359
31
s
Nm N σ
Vm
Sm
Nm
31,1 4,43 14992,1 482,06 1,00
1
6
7664
6
2
6
7698
6
3
7
6004
7
4
6
8474
6
5
11
8555
11
6
4
5596
4
7
6
7068
6
8
8
7424
8
9
6
7457
6
10
3
6353
3
Nm
6,3
s
Nσ
Vm
Sm
Nm
2,16 7229,3 1147,51 1,00
78
1
1672
27215
1672
2
1670
27435
1670
3
1648
27169
1648
4
1647
27266
1647
5
1706
28117
1706
6
1670
27280
1670
7
1664
27303
1664
8
1666
27131
1666
9
1648
27405
1648
10
1642
27007
1642
s
Nm
Nσ
Vm
Sm
Nm
1663,3 18,81 27332,8 16,43 1,00
1
1368
44529
1368
2
1351
43827
1351
3
1376
44555
1376
4
1380
44708
1380
5
1390
45229
1390
6
1361
44397
1361
7
1367
44705
1367
8
1373
44033
1373
9
1398
44929
1398
10
1376
45133
1376
s
Nm
Nσ
Vm
Sm
Nm
1374,0 13,58 44604,5 32,46 1,00
79
1
898
58622
898
2
893
58478
893
3
898
58594
898
4
920
58052
920
5
903
58447
903
6
933
57770
933
7
900
57992
900
8
910
57625
910
9
890
58675
890
10
903
58033
903
s
Nm
Nσ
Vm
Sm
Nm
904,8 13,05 58228,8 64,36 1,00
1
694
66898
694
2
677
67859
677
3
682
68352
682
4
683
67247
683
5
697
66615
697
6
700
67072
699
7
681
67641
682
8
660
67334
660
9
683
67016
682
10
695
65671
696
s
Nm
Nσ
Vm
Sm
Nm
685,2 11,89 67170,5 98,03 1,00
80
1
562
71697
562
2
540
71586
540
3
560
71800
560
4
563
71859
563
5
548
73965
548
6
559
70822
559
7
541
72659
541
8
555
72042
555
9
548
72404
548
10
549
72695
549
s
Nm
Nσ
Vm
Sm
Nm
552,5 8,48 72152,9 130,59 1,00
1
306
79455
306
2
301
79351
301
3
327
78471
327
4
308
79451
308
5
302
78152
302
6
308
79212
308
7
301
79515
301
8
316
79146
316
9
322
79249
322
10
307
79371
307
s
Nm
Nσ
Vm
Sm
Nm
309,8 8,99 79137,3 255,45 1,00
81
1
152
81842
152
2
171
81633
171
3
168
82122
168
4
156
81523
156
5
157
81741
157
6
164
82412
164
7
159
81905
159
8
167
81155
167
9
161
82095
161
10
164
81667
164
s
Nm
Nσ
Vm
Sm
Nm
161,9 5,97 81809,5 505,31 1,00
1
77
82763
77
2
78
83066
78
3
78
82782
78
4
76
82291
76
5
89
82211
89
6
87
82355
87
7
78
81861
78
8
83
82445
83
9
78
82019
78
10
78
82826
78
s
Nm Nσ
Vm
Sm
Nm
80,2 4,52 82461,9 1028,20 1,00
A.1.4
82
Testy ze względu na liczbę równoległych połączeń i rozmiar wiadomości
1
2267
37236
2268
2
2235
37262
2235
3
2265
36773
2265
4
2278
36804
2279
5
2200
35761
2199
6
2239
37024
2239
7
2181
36155
2180
8
2265
37337
2266
9
2244
37064
2244
10
2278
37089
2278
s
Nm
Nσ
Vm
Sm
Nm
2245,2 32,86 36850,5 16,41 1,00
Tablica A.26: Test N2.1 – czas testu: 10 minut, liczba wątków: 2, rozmiar
1
1628
51800
1628
2
1595
50984
1594
3
1592
52774
1593
4
1635
52561
1634
5
1571
51685
1572
6
1617
51999
1617
7
1636
52390
1636
8
1600
52433
1600
9
1587
52305
1587
10
1612
51850
1612
s
Nm
Nσ
Vm
Sm
Nm
1607,3 21,87 52078,1 32,40 1,00
83
1
1018
64634
1018
2
997
65309
997
3
1026
64489
1026
4
984
66066
984
5
994
65388
994
6
1010
65128
1010
7
1001
64884
1001
8
1013
64674
1013
9
1033
64741
1033
10
1027
64790
1027
s
Nm
Nσ
Vm
Sm
Nm
1010,3 16,08 65010,3 64,35 1,00
1
570
73770
570
2
598
73287
598
3
595
73747
595
4
580
73635
578
5
565
74162
567
6
570
74051
570
7
586
73089
586
8
589
73677
589
9
572
73807
572
10
591
73797
591
s
Nm
Nσ
Vm
Sm
Nm
581,6 11,79 73702,2 126,72 1,00
84
1
314
78642
314
2
310
78615
310
3
315
78706
315
4
307
78917
307
5
300
78821
300
6
317
78877
317
7
314
78250
314
8
319
79111
319
9
307
78566
307
10
313
78654
313
s
Nm
Nσ
Vm
Sm
Nm
311,6 5,66 78715,9 252,62 1,00
1
157
81052
157
2
155
81118
155
3
151
80724
151
4
160
81679
160
5
165
80858
165
6
160
81266
160
7
158
80471
158
8
163
80478
163
9
153
81827
153
10
164
81052
164
s
Nm
Nσ
Vm
Sm
Nm
158,6 4,70 81052,5 511,05 1,00
85
1
85
81479
85
2
80
81484
80
3
71
81945
71
4
84
81019
84
5
72
80882
72
6
75
82411
75
7
81
81598
81
8
74
84160
74
9
79
80973
79
10
83
81020
83
s
Nm Nσ
Vm
Sm
Nm
78,4 5,08 81697,1 1042,06 1,00
1
2403
38519
2402
2
2383
38953
2383
3
2363
39285
2364
4
2380
39554
2379
5
2313
38808
2314
6
2384
39435
2383
7
2365
39098
2364
8
2363
39107
2364
9
2376
38834
2376
10
2361
38939
2360
s
Nm
Nσ
Vm
Sm
Nm
2369,1 23,65 39053,2 16,48 1,00
86
1
1637
52889
1638
2
1633
52892
1633
3
1611
53625
1611
4
1614
53070
1613
5
1643
53053
1644
6
1648
52734
1647
7
1621
51841
1622
8
1669
53202
1669
9
1607
53520
1608
10
1639
52665
1639
s
Nm
Nσ
Vm
Sm
Nm
1632,2 19,24 52949,1 32,44 1,00
1
986
64184
986
2
1018
64857
1018
3
1032
65141
1033
4
1041
64510
1041
5
992
65407
992
6
1032
64681
1032
7
998
64603
998
8
1013
64874
1013
9
1019
64925
1018
10
1028
64749
1029
s
Nm
Nσ
Vm
Sm
Nm
1015,9 18,57 64739,1 63,78 1,00
87
1
554
74105
554
2
577
73379
577
3
582
73236
581
4
587
73313
588
5
571
73802
570
6
584
73427
585
7
586
73531
586
8
600
73370
600
9
558
72429
558
10
565
73869
565
s
Nm
Nσ
Vm
Sm
Nm
576,4 14,34 73446,1 127,42 1,00
1
303
78463
303
2
278
79402
278
3
312
78311
312
4
305
78447
305
5
296
78202
296
6
311
78592
311
7
304
78975
304
8
326
77642
326
9
289
79055
289
10
308
76589
308
s
Nm
Nσ
Vm
Sm
Nm
303,2 13,22 78367,8 258,47 1,00
88
1
153
81723
153
2
161
79065
161
3
165
81136
165
4
157
80910
157
5
153
80866
153
6
162
80831
162
7
154
78648
154
8
159
80999
159
9
165
80408
165
10
162
80545
162
s
Nm
Nσ
Vm
Sm
Nm
159,1 4,65 80513,1 506,05 1,00
1
71
83339
71
2
87
80846
87
3
80
81533
80
4
77
79966
77
5
78
84044
78
6
71
79037
71
7
74
82781
74
8
71
82439
71
9
85
81542
85
10
93
80693
93
s
Nm Nσ
Vm
Sm
Nm
78,7 7,59 81622,0 1037,13 1,00
89
1
2386
38955
2387
2
2378
38869
2377
3
2384
38943
2383
4
2367
38810
2368
5
2368
39236
2367
6
2315
39160
2316
7
2368
39265
2367
8
2395
39039
2395
9
2376
38564
2377
10
2374
38979
2373
s
Nm
Nσ
Vm
Sm
Nm
2371,1 21,66 38982,0 16,44 1,00
1
1641
52815
1641
2
1578
54152
1577
3
1622
53072
1623
4
1637
52963
1635
5
1615
53577
1617
6
1584
52508
1583
7
1645
52703
1645
8
1614
53383
1614
9
1665
52586
1665
10
1666
52379
1666
s
Nm
Nσ
Vm
Sm
Nm
1626,7 30,13 53013,8 32,59 1,00
90
1
1006
64850
1005
2
997
65149
998
3
1002
65199
1002
4
1005
65081
1004
5
1006
65720
1007
6
994
63856
994
7
1021
64736
1021
8
999
65226
998
9
984
65158
985
10
1000
64983
1000
s
Nm
Nσ
Vm
Sm
Nm
1001,4 9,57 64995,8 64,91 1,00
1
572
73120
572
2
601
72934
601
3
566
73628
565
4
565
73742
565
5
577
73487
578
6
570
73376
570
7
569
73421
569
8
573
73428
573
9
554
73761
553
10
573
73626
574
s
Nm
Nσ
Vm
Sm
Nm
527,0 11,97 73452,3 128,41 1,00
91
1
283
78647
284
2
312
77909
312
3
332
78184
331
4
320
78126
321
5
302
78154
302
6
306
78674
306
7
306
78009
306
8
311
78297
311
9
304
78332
304
10
317
78066
317
s
Nm
Nσ
Vm
Sm
Nm
309,3 12,88 78239,8 252,96 1,00
1
147
81038
147
2
155
80840
155
3
159
79825
159
4
155
81585
155
5
157
78619
156
6
142
81429
143
7
145
79646
145
8
153
80912
153
9
146
81145
146
10
160
80736
160
s
Nm
Nσ
Vm
Sm
Nm
151,9 6,38 80577,5 530,46 1,00
92
1
74
80206
74
2
76
82337
76
3
86
80029
86
4
84
83316
84
5
81
80068
81
6
78
80594
78
7
83
80540
83
8
78
83289
78
9
79
80966
79
10
79
81430
79
s
Nm Nσ
Vm
Sm
Nm
79,8 3,71 81277,5 1018,52 1,00
1
2365
39100
2364
2
2379
38829
2379
3
2371
39502
2373
4
2370
38933
2368
5
2378
38818
2380
6
2375
38600
2375
7
2333
38432
2333
8
2371
39324
2371
9
2340
39599
2337
10
2384
38859
2386
s
Nm
Nσ
Vm
Sm
Nm
2366,6 16,32 38999,6 16,48 1,00
93
1
1633
52899
1634
2
1645
52799
1644
3
1623
53170
1623
4
1619
53172
1620
5
1623
53470
1622
6
1640
52927
1640
7
1626
53234
1626
8
1638
52984
1638
9
1635
53053
1634
10
1626
52906
1627
s
Nm
Nσ
Vm
Sm
Nm
1630,8 8,61 53061,4 32,54 1,00
1
986
65213
987
2
1011
64993
1011
3
999
65152
999
4
986
64941
986
5
995
65191
995
6
1008
65078
1008
7
1015
64804
1014
8
984
64944
985
9
1008
64791
1008
10
1015
64738
1014
s
Nm
Nσ
Vm
Sm
Nm
1000,7 12,33 64984,4 64,94 1,00
94
1
577
73098
577
2
568
73563
568
3
584
73026
584
4
571
73369
571
5
564
73736
564
6
567
73258
565
7
589
73260
591
8
572
73278
572
9
557
73935
557
10
562
73413
562
s
Nm
Nσ
Vm
Sm
Nm
571,1 9,89 73393,6 128,51 1,00
1
321
78080
321
2
288
78486
288
3
309
78030
309
4
299
77731
299
5
281
78734
281
6
288
78480
288
7
303
78771
303
8
282
77007
281
9
310
78685
311
10
294
77823
294
s
Nm
Nσ
Vm
Sm
Nm
297,5 13,24 78182,7 262,80 1,00
95
1
165
81331
165
2
156
80904
156
3
161
79053
161
4
154
82008
154
5
144
80860
144
6
155
80377
155
7
153
78703
153
8
161
80292
161
9
146
80878
146
10
151
80285
151
s
Nm
Nσ
Vm
Sm
Nm
154,6 6,62 80469,1 520,50 1,00
1
83
84606
83
2
79
79762
79
3
83
82134
83
4
82
81707
82
5
80
81221
80
6
78
81812
78
7
81
81328
81
8
72
80320
72
9
83
81643
83
10
76
81787
76
s
Nm Nσ
Vm
Sm
Nm
79,7 3,59 81632,0 1024,24 1,00
96
1
2362
39100
2362
2
2349
39296
2348
3
2379
38846
2379
4
2334
38179
2336
5
2420
39078
2420
6
2301
38586
2300
7
2347
39133
2347
8
2347
39218
2346
9
2386
39471
2387
10
2355
38910
2352
s
Nm
Nσ
Vm
Sm
Nm
2358,0 32,05 38981,7 16,53 1,00
1
1610
53132
1611
2
1662
52299
1660
3
1631
52849
1633
4
1623
52903
1625
5
1670
52082
1669
6
1635
52846
1637
7
1612
53175
1611
8
1602
52040
1603
9
1659
52463
1658
10
1620
52673
1621
s
Nm
Nσ
Vm
Sm
Nm
1632,4 23,78 52646,2 32,25 1,00
97
1
996
64814
995
2
984
65122
985
3
1005
64447
1005
4
971
65196
971
5
1006
64701
1006
6
1011
64607
1010
7
1003
64401
1003
8
980
65293
978
9
1010
64757
1013
10
1003
64851
1003
s
Nm
Nσ
Vm
Sm
Nm
996,9 13,81 64818,9 65,02 1,00
1
575
72862
574
2
558
73416
559
3
595
72411
595
4
568
73214
568
5
549
73176
548
6
570
73191
570
7
563
72724
563
8
571
73011
571
9
568
73032
569
10
546
73818
546
s
Nm
Nσ
Vm
Sm
Nm
566,3 13,87 73085,5 129,06 1,00
98
1
301
77464
301
2
304
78461
304
3
300
77409
300
4
292
76716
292
5
300
77312
300
6
294
78260
293
7
313
77723
314
8
301
78162
301
9
304
78013
304
10
315
77394
315
s
Nm
Nσ
Vm
Sm
Nm
302,4 7,23 77691,4 256,92 1,00
1
147
80169
147
2
152
80445
152
3
146
80485
146
4
153
79181
153
5
148
81688
148
6
159
79454
159
7
158
81853
158
8
158
78342
158
9
158
81391
158
10
149
79697
149
s
Nm
Nσ
Vm
Sm
Nm
152,8 5,14 80270,5 525,33 1,00
99
1
84
82977
84
2
75
76329
75
3
83
82248
83
4
78
82234
78
5
79
83794
79
6
75
80133
75
7
90
80137
90
8
76
81466
76
9
76
82039
76
10
70
81285
70
s
Nm Nσ
Vm
Sm
Nm
78,6 5,70 81264,2 1033,90 1,00
1
2357
38625
2357
2
2333
39213
2332
3
2351
38889
2353
4
2354
39277
2351
5
2312
38672
2314
6
2350
38920
2348
7
2379
38446
2380
8
2354
38833
2356
9
2378
38361
2378
10
2358
38668
2358
s
Nm
Nσ
Vm
Sm
Nm
2352,6 19,54 38790,4 16,49 1,00
100
1
1603
53126
1605
2
1613
53137
1612
3
1656
52239
1655
4
1619
52970
1620
5
1594
51909
1594
6
1601
53365
1600
7
1641
52436
1638
8
1617
52957
1617
9
1639
52612
1640
10
1604
53026
1605
s
Nm
Nσ
Vm
Sm
Nm
1618,7 20,34 52777,7 32,61 1,00
1
1001
64269
1001
2
1028
64082
1029
3
1015
64405
1016
4
1000
64716
1000
5
1007
63548
1006
6
1019
64197
1020
7
1010
64569
1007
8
1022
64383
1024
9
1009
65431
1009
10
1030
64107
1029
s
Nm
Nσ
Vm
Sm
Nm
1014,1 10,52 64370,7 63,48 1,00
101
1
579
72523
577
2
559
72830
561
3
561
72949
561
4
573
72831
573
5
576
72764
576
6
583
73017
582
7
569
72129
570
8
572
72909
571
9
564
73151
564
10
561
73037
562
s
Nm
Nσ
Vm
Sm
Nm
569,7 8,29 72814,0 127,81 1,00
1
308
78044
308
2
299
77435
299
3
327
76699
326
4
312
78238
313
5
304
77924
303
6
309
77284
309
7
301
77813
302
8
307
76860
305
9
319
78146
320
10
289
78304
290
s
Nm
Nσ
Vm
Sm
Nm
307,5 10,57 77674,7 252,60 1,00
102
1
161
80336
160
2
156
80807
157
3
153
78433
152
4
159
80849
160
5
161
79360
161
6
159
79906
159
7
145
80011
145
8
155
80073
155
9
163
79203
163
10
159
80228
158
s
Nm
Nσ
Vm
Sm
Nm
157,1 5,22 79920,6 508,72 1,00
1
79
81150
79
2
81
81486
81
3
80
79345
79
4
80
85046
81
5
78
77090
78
6
80
80412
80
7
81
83848
81
8
81
80059
81
9
87
78958
87
10
81
79967
81
s
Nm N σ
Vm
Sm
Nm
80,8 2,39 80736,1 999,21 1,00
103
1
2388
38575
2389
2
2361
39162
2359
3
2342
39282
2342
4
2356
39214
2360
5
2368
39426
2367
6
2382
38428
2378
7
2369
38193
2369
8
2377
39357
2379
9
2359
39121
2358
10
2383
38277
2383
s
Nm
Nσ
Vm
Sm
Nm
2368,5 14,34 38903,5 16,43 1,00
1
1612
52424
1612
2
1631
52185
1630
3
1605
52709
1604
4
1612
52623
1610
5
1593
52974
1597
6
1615
52455
1613
7
1614
52878
1613
8
1602
52387
1603
9
1616
52348
1619
10
1633
52291
1633
s
Nm
Nσ
Vm
Sm
Nm
1613,3 12,13 52527,4 32,56 1,00
104
1
1009
64191
1008
2
960
65220
959
3
975
63179
976
4
990
65356
992
5
990
64690
989
6
1026
63599
1027
7
1015
64142
1014
8
981
63566
981
9
1006
64302
1008
10
992
64645
992
s
Nm
Nσ
Vm
Sm
Nm
994,4 19,87 64289,0 64,65 1,00
1
558
70947
559
2
553
72611
553
3
539
72975
539
4
557
72487
558
5
574
72526
573
6
575
71926
576
7
573
71973
571
8
584
72084
585
9
570
71982
570
10
579
71894
579
s
Nm
Nσ
Vm
Sm
Nm
566,2 13,93 72140,5 127,41 1,00
105
1
312
77009
312
2
306
76549
304
3
285
76308
285
4
311
77659
310
5
295
76036
298
6
303
77637
302
7
290
77782
291
8
306
75934
306
9
301
77088
301
10
305
77136
305
s
Nm
Nσ
Vm
Sm
Nm
301,4 8,83 76913,8 255,19 1,00
1
145
78044
145
2
176
78551
176
3
158
79852
158
4
160
77968
159
5
153
78584
154
6
152
78601
151
7
153
82395
154
8
163
76204
162
9
154
80813
155
10
157
81425
157
s
Nm
Nσ
Vm
Sm
Nm
157,1 8,28 79243,7 504,42 1,00
106
1
75
80662
76
2
76
81220
76
3
70
83401
70
4
76
80852
76
5
73
77989
72
6
80
78495
81
7
79
82704
79
8
77
74980
77
9
78
84373
78
10
84
78879
84
s
Nm Nσ
Vm
Sm
Nm
76,8 3,85 80355,5 1046,30 1,00
A.1.5
107
Testy ze względu na liczbę wiadomości na sesję
1
2267
12224
1137
2
2248
12418
1107
3
2288
12381
1172
4
2240
12260
1101
5
2291
12523
1130
6
2237
12052
1110
7
2205
11730
1096
8
2227
11980
1142
9
2319
12746
1141
10
2278
12412
1142
s
Nm
Nσ
Vm
S m Nm
2260,0 34,82 12272,6 5,43 2,00
Tablica A.75: Test L1.1 – czas testu: 10 minut, liczba wątków: 1, rozmiar
wiadomości: 0-10KB, liczba wiadomości na sesję: 1-3.
1
2551
13733
834
2
2536
13572
852
3
2551
13826
859
4
2543
13953
834
5
2514
13800
836
6
2462
13317
817
7
2231
12038
747
8
2492
13412
835
9
2502
13619
835
10
2491
13518
836
s
Nm
Nσ
Vm
S m Nm
2487,3 94,80 13478,8 5,42 3,00
108
1
2823
15154
507
2
2782
15260
516
3
2710
14787
507
4
2769
14817
493
5
2816
15264
513
6
2810
14874
519
7
2786
15160
485
8
2807
15115
517
9
2791
14945
512
10
2750
15066
479
s
Nm
Nσ
Vm
S m Nm
2784,4 34,42 15044,2 5,40 5,52
1
3007
16277
285
2
2892
15894
279
3
2975
16113
284
4
3007
16162
293
5
3015
16212
284
6
2954
15932
279
7
2951
15907
268
8
3006
16140
294
9
3023
16630
297
10
2976
16354
278
s
Nm
Nσ
Vm
Sm
Nm
2980,6 40,15 16162,1 5,42 10,50
109
1
3110
16742
124
2
3261
17489
130
3
3181
17382
127
4
2952
16203
115
5
2641
14512
103
6
3070
16872
122
7
3126
16895
124
8
3124
16902
121
9
3044
16532
122
10
3133
16802
127
s
Nm
Nσ
Vm
Sm
Nm
3064,2 169,55 16633,1 5,43 25,22
1
3238
17555
69
2
3150
17130
60
3
3205
17460
70
4
3114
16707
57
5
3131
17091
66
6
3131
17060
72
7
3128
16993
56
8
3265
17624
72
9
3360
18343
62
10
3296
18043
74
s
Nm
Nσ
Vm
Sm
Nm
3201,8 85,04 17400,6 5,44 48,66
110
1
4385
24105
2196
2
4386
23982
2202
3
4424
23738
2198
4
4394
23900
2202
5
4411
23713
2201
6
4393
24172
2178
7
4390
23889
2200
8
4392
23747
2202
9
4398
23435
2193
10
4450
24009
2213
s
Nm
Nσ
Vm
S m Nm
4402,3 20,60 23869,0 5,42 2,00
1
4950
26616
1632
2
4935
27055
1619
3
4946
26868
1618
4
4948
27202
1638
5
4915
26638
1639
6
4924
26660
1624
7
4928
26344
1679
8
4915
26592
1671
9
4941
26506
1640
10
4931
26482
1647
s
Nm
Nσ
Vm
S m Nm
4933,3 12,95 26696,3 5,41 3,01
111
1
5520
29868
1028
2
5543
30180
1003
3
5559
30162
996
4
5519
29852
1019
5
5499
30022
1024
6
5529
29895
1024
7
5571
30111
997
8
5565
30109
1011
9
5576
30176
1033
10
5578
29884
980
s
Nm
Nσ
Vm
S m Nm
5545,9 27,87 30025,9 5,42 5,48
1
5947
32163
576
2
5922
32211
575
3
5931
32471
553
4
5999
32312
581
5
5875
31925
557
6
5994
32462
559
7
5981
32241
551
8
5983
31956
561
9
5964
32005
577
10
5907
32065
582
s
Nm
Nσ
Vm
Sm
Nm
5950,3 41,11 32181,1 5,41 10,49
112
1
6265
33728
260
2
6246
33704
270
3
6224
33832
253
4
6224
33788
251
5
6241
33737
256
6
6247
33685
245
7
6261
33593
270
8
6237
33589
241
9
6266
34148
247
10
6219
33355
240
s
Nm
Nσ
Vm
Sm
Nm
6243,0 17,32 33715,9 5,40 24,65
1
6373
34539
132
2
6281
33418
124
3
6390
34197
122
4
6258
33956
115
5
6305
33490
132
6
6379
34557
120
7
6249
33913
132
8
6273
34064
117
9
6339
34168
121
10
6276
33751
122
s
Nm
Nσ
Vm
Sm
Nm
6312,3 53,47 34005,3 5,39 51,03
A.1.6
113
Testy zbiorcze
1
171
83788
37
2
155
83539
26
3
159
84047
24
4
163
83571
32
5
158
84471
27
6
148
84319
26
7
168
83343
31
8
172
83362
30
9
174
82347
31
10
169
84181
32
s
Nm
Nσ
Vm
Sm
Nm
163,7 8,51 83696,8 511,28 5,53
Tablica A.87: Test Z1 – czas testu: 10 minut, liczba wątków: 3, rozmiar
1
199
94356
1
2
119
68574
5
3
163
81074
5
4
148
81101
5
5
174
86535
2
6
159
83598
3
7
135
71140
2
8
162
86199
3
9
150
75270
2
10
159
84129
2
s
Nm
Nσ
Vm
Sm
Nm
156,8 21,55 81197,6 517,84 52,27
Tablica A.88: Test Z2 – czas testu: 10 minut, liczba wątków: 3, rozmiar
A.2
A.2.1
114
Wydajność obliczeniowa (OpenSSL)
Testy ze względu na liczbę szyfrowanych wiadomości
1
1390
7570
1390
2
1310
7288
1310
3
1283
6973
1283
4
1367
7442
1367
5
1306
7143
1306
6
1287
6735
1287
7
1331
7255
1331
8
1290
7108
1290
9
1321
7366
1321
10
1385
7500
1385
s
Nm
Nσ
Vm
S m Nm
1327,0 40,30 7238,0 5,45 1,00
Tablica A.89: Test S1.1 – czas testu: 10 minut, liczba wątków: 1, rozmiar
115
1
1009
5381
1009
2
1010
5649
1009
3
939
5052
939
4
959
5180
959
5
927
5116
927
6
1027
5511
1027
7
1017
5672
1017
8
1063
5793
1063
9
945
5108
946
10
1086
5898
1086
s
Nm
Nσ
Vm
S m Nm
998,2 54,05 5436,0 5,45 1,00
1
668
3535
669
2
649
3495
648
3
696
3741
697
4
670
3641
670
5
596
3252
596
6
617
3548
617
7
630
3467
630
8
620
3476
620
9
652
3507
652
10
612
3319
612
s
Nm
Nσ
Vm
S m Nm
641,0 31,24 3498,1 5,56 1,00
116
1
326
1840
326
2
332
1726
332
3
383
2063
383
4
355
1900
355
5
355
1951
355
6
351
1957
350
7
389
2051
389
8
339
1919
339
9
353
1907
354
10
382
1995
382
s
Nm
Nσ
Vm
S m Nm
356,5 21,84 1930,9 5,42 1,00
1
193
1037
193
2
187
1016
186
3
195
1066
196
4
189
1016
189
5
194
1061
194
6
193
1024
193
7
198
1083
198
8
183
1017
182
9
183
944
183
10
190
1002
191
s
Nm
Nσ
Vm
S m Nm
190,5 5,04 1026,6 5,39 1,00
117
1
154
821
154
2
156
832
156
3
153
830
152
4
152
841
153
5
159
775
159
6
158
837
158
7
156
772
155
8
151
869
152
9
155
847
155
10
152
839
151
s
Nm
Nσ
Vm
S m Nm
154,6 2,68 826,3 5,35 1,00
1
47
21632
9
2
46
22833
9
3
36
21589
9
4
34
20998
9
5
39
20005
7
6
54
25123
11
7
52
26314
9
8
50
28053
11
9
69
37409
17
10
71
39893
14
s
Nm
Nσ
Vm
Sm
Nm
49,8 12,56 26384,9 529,82 4,74
wiadomości: 0-1024KB, liczba wiadomości na sesję: 10, procent wiadomości
szyfrowanych: 5%.
118
1
40
18596
7
2
36
18633
7
3
33
19113
7
4
44
22381
4
5
43
21397
7
6
39
19382
8
7
30
15348
6
8
38
18381
5
9
34
18826
9
10
32
17257
4
s
Nm N σ
Vm
Sm
Nm
36,9 4,70 18931,4 513,05 5,77
szyfrowanych: 10%.
1
34
15189
4
2
25
15091
4
3
35
14651
7
4
26
14016
5
5
21
11470
4
6
22
13231
6
7
22
10865
5
8
18
11680
6
9
26
10969
5
10
23
11385
3
s
Nm N σ
Vm
Sm
Nm
25,2 5,47 12854,7 510,11 5,14
szyfrowanych: 20%.
119
1
20
9704
4
2
20
10442
2
3
16
10055
3
4
21
9785
4
5
22
11267
5
6
17
10380
2
7
16
9082
3
8
20
10065
4
9
15
8680
3
10
17
9322
2
s
Nm Nσ
Vm
Sm
Nm
18,4 2,46 9878,2 536,86 5,75
szyfrowanych: 40%.
1
13
6633
2
2
15
7942
3
3
11
7300
3
4
15
7829
2
5
14
7571
3
6
16
7147
2
7
12
7413
3
8
11
5957
1
9
16
6971
3
10
14
6155
0
s
Nm Nσ
Vm
Sm
Nm
13,7 1,89 7091,8 517,95 6,23
szyfrowanych: 80%.
120
1
15
5331
2
2
10
5910
2
3
11
5225
4
4
9
5425
2
5
9
5333
2
6
9
5537
1
7
10
4528
0
8
8
4837
2
9
10
4795
3
10
8
5395
2
Nm
9,9
s
Nσ
Vm
Sm
Nm
2,02 5231,6 528,44 4,95
szyfrowanych: 100%.
1
638
10347
639
2
725
11525
725
3
703
11342
703
4
680
11300
680
5
676
11155
676
6
695
11789
695
7
771
12439
771
8
700
11461
699
9
635
10370
636
10
706
11413
706
s
Nm
Nσ
Vm
Sm
Nm
692,9 39,83 11314,1 16,33 1,00
121
1
364
5884
364
2
388
6621
388
3
335
5404
334
4
418
7052
418
5
411
7069
411
6
416
6913
416
7
395
6761
395
8
408
6826
408
9
410
6501
410
10
411
6958
411
s
Nm
Nσ
Vm
Sm
Nm
395,6 26,84 6598,9 16,68 1,00
1
207
3515
207
2
224
3986
225
3
226
3578
225
4
212
3668
213
5
209
3692
209
6
196
3309
196
7
208
3480
208
8
243
3787
243
9
225
3663
225
10
194
3214
194
s
Nm
Nσ
Vm
Sm
Nm
214,4 15,06 3589,2 16,74 1,00
122
1
114
1883
115
2
119
1836
118
3
110
1766
111
4
118
2029
117
5
115
1955
116
6
108
1836
108
7
115
1877
115
8
111
2012
111
9
107
1884
106
10
110
1803
111
s
Nm
Nσ
Vm
Sm
Nm
112,7 4,11 1888,1 16,75 1,00
1
90
1459
91
2
96
1395
96
3
90
1548
90
4
89
1417
89
5
90
1576
89
6
81
1554
82
7
87
1474
87
8
86
1541
86
9
82
1495
82
10
87
1560
87
s
Nm N σ
Vm
Sm
Nm
87,8 4,32 1501,9 17,11 1,00
123
1
269
17413
269
2
225
14232
225
3
316
20578
316
4
240
15545
240
5
257
16424
257
6
258
16890
258
7
234
14945
234
8
360
22107
360
9
197
12734
197
10
298
19857
297
s
Nm
Nσ
Vm
Sm
Nm
265,4 47,90 17072,5 64,33 1,00
szyfrowanych: 10%.
1
135
9047
135
2
131
8427
131
3
155
9234
155
4
158
9457
158
5
135
8542
135
6
129
8527
129
7
161
9959
160
8
144
8979
145
9
125
8068
125
10
152
11152
152
s
Nm
Nσ
Vm
Sm
Nm
142,5 13,19 9139,2 64,14 1,00
szyfrowanych: 20%.
124
1
82
5101
82
2
63
4082
63
3
85
5717
85
4
71
4779
71
5
75
4724
75
6
68
4690
68
7
85
5377
84
8
75
5296
76
9
94
5723
94
10
73
5063
73
s
Nm N σ
Vm
Sm
Nm
77,1 9,30 5055,2 65,57 1,00
szyfrowanych: 40%.
1
45
2839
45
2
42
2767
41
3
44
2473
45
4
40
2446
39
5
38
2975
39
6
40
2556
40
7
40
2525
40
8
39
2529
39
9
39
2259
39
10
45
2575
45
s
Nm N σ
Vm
Sm
Nm
41,2 2,62 2594,4 62,97 1,00
szyfrowanych: 80%.
125
1
37
2190
36
2
29
2267
30
3
32
2014
32
4
34
1889
34
5
31
2022
30
6
31
2255
32
7
30
2042
30
8
31
1934
30
9
33
2173
34
10
29
2055
29
s
Nm N σ
Vm
Sm
Nm
31,7 2,45 2084,1 65,75 1,00
szyfrowanych: 100%.
1
148
20230
148
2
166
22940
166
3
158
20820
157
4
155
18755
156
5
141
17442
141
6
142
17022
142
7
166
20101
166
8
131
16745
131
9
118
15509
118
10
129
17749
129
s
Nm
Nσ
Vm
Sm
Nm
145,4 16,21 18731,3 128,83 1,00
szyfrowanych: 10%.
126
1
72
9565
71
2
74
9396
75
3
74
10643
74
4
58
6776
58
5
59
6899
59
6
54
7755
54
7
53
6578
53
8
49
6283
49
9
92
10995
92
10
79
10847
79
s
Nm
Nσ
Vm
Sm
Nm
66,4 13,83 8573,7 129,12 1,00
szyfrowanych: 20%.
1
37
4608
37
2
41
4918
40
3
42
5629
43
4
48
5450
48
5
36
5137
36
6
41
4651
41
7
40
5329
40
8
40
5055
40
9
45
5840
45
10
41
5882
41
s
Nm Nσ
Vm
Sm
Nm
41,1 3,48 5249,9 127,74 1,00
szyfrowanych: 40%.
127
1
23
2731
23
2
21
2658
21
3
22
2852
22
4
20
2502
20
5
21
2838
21
6
22
3031
22
7
19
2691
19
8
17
2365
17
9
20
2860
20
10
26
2941
26
s
Nm Nσ
Vm
Sm
Nm
21,1 2,42 2746,9 130,19 1,00
szyfrowanych: 80%.
1
23
2448
23
2
17
2141
17
3
17
2202
17
4
17
2073
17
5
16
2358
16
6
19
2423
19
7
19
2300
19
8
12
2071
12
9
17
2327
17
10
13
2428
13
s
Nm Nσ
Vm
Sm
Nm
17,0 3,09 2277,1 133,95 1,00
szyfrowanych: 100%.
128
1
32
17896
32
2
29
12553
29
3
21
10868
21
4
21
14436
21
5
45
21737
45
6
40
22784
40
7
30
15392
30
8
42
21384
42
9
56
27147
56
10
31
15313
31
s
Nm
Nσ
Vm
Sm
Nm
34,7 11,02 17951,0 517,32 1,00
szyfrowanych: 10%.
1
38
19010
39
2
23
10188
23
3
12
8189
12
4
11
8601
11
5
22
9429
22
6
26
14103
26
7
26
12929
26
8
21
12580
21
9
23
10241
23
10
24
13581
24
s
Nm N σ
Vm
Sm
Nm
22,6 7,55 11885,1 525,89 1,00
szyfrowanych: 20%.
129
1
14
5633
14
2
9
4037
9
3
7
4463
7
4
8
4071
8
5
10
4225
10
6
9
5622
9
7
13
5638
13
8
10
5859
10
9
10
4738
10
10
9
4531
9
Nm
9,9
s
Nσ
Vm
Sm
Nm
2,13 4881,7 493,10 1,00
szyfrowanych: 40%.
1
5
3334
5
2
7
3183
7
3
5
3344
5
4
7
3812
7
5
9
3682
9
6
8
3490
8
7
5
3716
5
8
7
3032
7
9
10
3317
9
10
8
2702
9
Nm
7,1
s
Nσ
Vm
Sm
Nm
1,73 3361,2 473,41 1,00
szyfrowanych: 80%.
130
1
7
3380
7
2
4
3245
4
3
5
3124
5
4
6
2943
6
5
5
2679
5
6
4
2586
4
7
9
2519
9
8
5
2387
5
9
5
2663
5
10
5
2229
5
Nm
5,5
s
Nσ
Vm
Sm
Nm
1,51 2775,5 504,64 1,00
szyfrowanych: 100%.
1
19
20183
19
2
24
25275
24
3
25
22123
25
4
31
31996
31
5
24
24532
24
6
20
21279
20
7
22
23756
22
8
20
18695
20
9
17
15625
17
10
17
17440
17
s
Nm Nσ
Vm
Sm
Nm
21,9 4,28 22090,4 1008,69 1,00
szyfrowanych: 10%.
131
1
9
9487
9
2
16
13631
16
3
18
12257
18
4
8
9252
8
5
10
8994
10
6
10
12877
10
7
11
12233
11
8
14
12645
14
9
9
11964
9
10
7
9869
7
s
Nm Nσ
Vm
Sm
Nm
11,2 3,62 11320,9 1010,80 1,00
szyfrowanych: 20%.
1
12
7170
12
2
5
6186
5
3
8
7308
8
4
6
6784
5
5
4
6750
5
6
6
7630
6
7
5
5655
5
8
5
5913
5
9
6
6263
6
10
5
5442
5
Nm
6,2
s
Nσ
Vm
Sm
Nm
2,30 6510,1 1050,02 1,00
szyfrowanych: 40%.
132
1
3
3986
3
2
4
2863
4
3
5
4136
5
4
4
3394
4
5
2
3696
2
6
3
2389
3
7
3
3048
3
8
2
3846
2
9
2
3216
2
10
3
3248
3
Nm
3,1
s
Nσ
Vm
Sm
Nm
0,99 3382,2 1091,03 1,00
szyfrowanych: 80%.
1
1
3440
1
2
5
3079
5
3
2
2045
2
4
2
2309
2
5
3
2321
3
6
1
3748
1
7
2
2308
2
8
3
2631
3
9
4
1752
4
10
1
3290
1
Nm
2,4
s
Nσ
Vm
Sm
Nm
1,35 2692,3 1121,79 1,00
szyfrowanych: 100%.
A.2.2
133
Testy ze względu na liczbę wiadomości podpisanych elektronicznie
1
1208
6681
1208
2
1189
6392
1189
3
1168
6464
1168
4
1335
7409
1334
5
1331
7212
1332
6
1171
6313
1172
7
1086
5829
1086
8
1329
7165
1328
9
1202
6794
1203
10
1268
6949
1268
s
Nm
Nσ
Vm
S m Nm
1228,7 83,97 6720,8 5,47 1,00
Tablica A.126: Test P1.1 – czas testu: 10 minut, liczba wątków: 1, rozmiar
wiadomości: 0-10KB, liczba wiadomości na sesję: 1, procent wiadomości podpisywanych elektronicznie: 5%.
134
1
843
4581
843
2
872
4671
872
3
820
4561
820
4
831
4395
830
5
888
4751
889
6
898
4974
898
7
952
5221
952
8
893
4938
893
9
881
4746
881
10
827
4495
827
s
Nm
Nσ
Vm
S m Nm
870,5 40,94 4733,3 5,44 1,00
1
472
2432
471
2
450
2464
451
3
482
2725
482
4
498
2784
498
5
484
2643
483
6
494
2681
495
7
489
2689
488
8
527
2836
528
9
499
2716
499
10
498
2619
498
s
Nm
Nσ
Vm
S m Nm
489,3 20,04 2658,9 5,43 1,00
135
1
256
1415
256
2
293
1744
294
3
258
1407
257
4
264
1347
265
5
288
1513
288
6
257
1408
257
7
277
1519
277
8
271
1430
271
9
272
1555
271
10
255
1388
256
s
Nm
Nσ
Vm
S m Nm
269,1 13,62 1472,6 5,47 1,00
1
148
819
148
2
148
837
148
3
148
795
147
4
148
747
149
5
144
766
143
6
142
759
142
7
134
731
135
8
139
790
138
9
138
792
139
10
139
736
138
s
Nm
Nσ
Vm
S m Nm
142,8 5,16 777,2 5,44 1,00
136
1
119
646
119
2
119
649
119
3
118
652
118
4
116
660
115
5
121
602
122
6
117
652
116
7
118
656
118
8
119
600
120
9
119
617
119
10
118
657
118
s
Nm
Nσ
Vm
S m Nm
118,4 1,35 639,1 5,40 1,00
1
82
42745
16
2
59
29215
14
3
55
28369
9
4
56
28017
9
5
44
22629
5
6
44
24115
8
7
51
28616
9
8
65
30819
13
9
77
32418
15
10
68
36896
12
s
Nm
Nσ
Vm
Sm
Nm
60,1 12,90 30383,9 505,56 5,46
podpisywanych elektronicznie: 5%.
137
1
45
23943
7
2
46
22103
11
3
41
18718
9
4
34
17808
6
5
37
20714
6
6
48
25876
7
7
47
24214
8
8
41
19207
6
9
30
17775
6
10
31
16029
5
s
Nm N σ
Vm
Sm
Nm
40,0 6,68 20638,7 515,97 5,63
1
25
14661
3
2
31
14363
4
3
24
14600
3
4
24
13456
3
5
30
14067
6
6
28
13158
4
7
24
12323
2
8
23
12758
4
9
22
12492
6
10
22
10211
2
s
Nm N σ
Vm
Sm
Nm
25,3 3,23 13208,9 522,09 6,84
138
1
15
9585
1
2
17
10438
4
3
16
9062
3
4
17
9437
2
5
16
8981
3
6
18
8687
4
7
19
8273
3
8
18
8223
4
9
17
9016
3
10
16
8365
3
s
Nm Nσ
Vm
Sm
Nm
16,9 1,20 9006,7 532,94 5,63
1
15
6378
2
2
15
5162
3
3
9
7801
2
4
10
5809
1
5
10
6635
2
6
12
6264
2
7
16
5242
4
8
13
6259
3
9
7
5078
0
10
13
5809
3
s
Nm Nσ
Vm
Sm
Nm
12,0 2,94 6043,7 503,64 5,46
139
1
9
5522
2
2
12
5842
1
3
14
6320
3
4
7
5863
1
5
12
6062
1
6
14
5734
2
7
11
6091
3
8
9
5155
1
9
14
6734
3
10
10
4953
4
s
Nm Nσ
Vm
Sm
Nm
11,2 2,44 5827,6 520,32 5,33
A.3
140
Testy w konfiguracji typu relay
1
1768
9571
1768
2
1728
9556
1728
3
1767
9546
1767
4
1799
9940
1798
5
1745
9539
1746
6
1750
9441
1750
7
1742
9206
1742
8
1799
9839
1799
9
1782
9926
1782
10
1768
9599
1768
s
Nm
Nσ
Vm
S m Nm
1764,8 23,91 9616,3 5,45 1,00
Tablica A.138: Test R1 – czas testu: 10 minut, liczba wątków: 1, rozmiar
1
156
80999
25
2
151
81591
32
3
153
79377
31
4
164
83144
25
5
161
80485
29
6
171
83636
30
7
161
80992
30
8
163
81480
28
9
152
79159
30
10
168
82993
30
s
Nm
Nσ
Vm
Sm
Nm
160,0 6,85 81385,6 508,66 5,52
141
1
8
6006
1
2
9
4963
1
3
13
4927
2
4
10
5778
1
5
8
3493
1
6
7
5598
1
7
10
4469
2
8
9
5668
0
9
7
4141
2
10
8
4577
1
Nm
8,9
s
Nσ
Vm
Sm
Nm
1,79 4962,0 557,53 7,42
szyfrowanych: 100%.
Dodatek B
Synchronizacja a sygnały
Podczas testów wydajności bramki S/MIME znalazłem istotny, choć nie krytyczny, błąd w jej działaniu. Program bramki, co typowe dla programów serwerowych w systemach uniksopodobnych, tworzy (ang. fork ) proces potomny
do obłsugi każdego nowego połączenia . Dobrą praktyką programistyczną jest
kontrolowanie liczby aktywnych podprocesów i jej ograniczenie – zabezpiecza
to przed atakami typu DoS (ang. denial of service), polegającymi na przepełnieniu tablicy procesów w systemie operacyjnym. Bramka S/MIME została
napisana z zachowaniem tych zasad.
B.1
Opis problemu
Podczas dużego obciążenia (a zatem dużej liczby równolegle tworzonych i
zamykanych połączeń) okazało się, że licznik aktywnych procesów potomnych nie działa poprawnie. Po pewnym czasie (kilka do kilkunastu minut)
licznik wskazuje liczbę większą od rzeczywistej. Stąd wniosek, że jego inkrementacja przebiega poprawnie, za to niektóre wywołania dekrementacji są
prawdopodobnie gubione – średnio około 0, 005% wywołań.
Na listingu B.1 pokazane są fragmenty kodu źródłowego funkcji main()
związane z tworzeniem procesów potomnych. W linii 11 rejestrowana jest
obsługa sygnału SIGCHLD, używanego do komunikacji z procesami potomnymi. Sygnał SIGCHLD jest wysyłany przez proces potomny przechodzący w
stan zombie do procesu rodzica, by ten mógł wywołać funkcję wait() i przez
to usunąć go permanentnie z systemowej tabeli procesów. W liniach 20-27
widać procedurę tworzenia nowych procesów, gdzie w pierwszej kolejności
sprawdzane jest, czy nie została przekroczona dopuszczalna liczba procesów
potomnych. Po pomyślnym utworzeniu procesu inkrementowany jest licznik
sproc counter.
Rozdział B. Synchronizacja a sygnały
1
5
143
/∗ ∗ G l o b a l V a r i a b l e s ∗ ∗/
int s p r o c c o u n t e r = 0 ; /∗ f o r k e d s u b p r o c e s s c o u n t e r ∗/
/∗ S/MIME Gate main f u n c t i o n ∗/
int main ( int argc , char ∗∗ argv )
{
[...]
/∗ s e t a p p r o p r i a t e h a n d l e r f o r SIGCHLD ∗/
S i g n a l (SIGCHLD, s i g c h l d ) ;
10
[...]
/∗ SMTP S e r v e r ’ s main l o o p ∗/
f or ( ; ; ) {
[...]
15
/∗ c h e c k w h e t h e r s u b p r o c e s s l i m i t i s not e x c e e d e d ∗/
i f ( s p r o c c o u n t e r < MAXSUBPROC) {
i f ( ( c h i l d p i d = Fork ( ) ) == 0 ) {
/∗ c h i l d p r o c e s s ∗/
Close ( l i s t e n f d ) ;
/∗ c l o s e l i s t e n i n g s o c k e t ∗/
s m i m e g a t e s e r v i c e ( connfd ) ; /∗ p r o c e s s t h e r e q u e s t ∗/
exit (0);
}
++s p r o c c o u n t e r ;
}
else
err msg ( ” subprocess l i m i t exceeded ” ) ;
20
25
C l o s e ( connfd ) ;
30
/∗ p a r e n t c l o s e s c o n n e c t e d s o c k e t ∗/
}
}
/∗ end o f main ( ) ∗/
Listing B.1: Tworzenie procesów potomnych w funkcji main().
Licznik jest zmniejszany w funkcji obsługi sygnału SIGCHLD widocznej
na listingu B.2. Jako, że w trakcie obsługi sygnału mogą nadejść kolejne sygnały tego samego typu (które zostaną automatycznie zablokowane) funkcja
waitpid() jest wywoływana w pętli, która będzie się wykonywać dopóty,
dopóki istnieją procesy potomne w stanie zombie. Dla każdego usuniętego
procesu licznik jest dekrementowany. Ważną obserwacją wynikłą w trakcie
testów jest fakt, że program główny nie pozostawia żadnych procesów zombie – stąd można wnosić, że funkcja działa poprawnie, a problemem jest
synchronizacja dostępu do zmiennej sproc counter.
1
void s i g c h l d ( int s i g n o
{
p i d t pid ;
int s t a t ;
attribute
144
((
unused
)))
5
while ( ( p i d = w a i t p i d ( −1 , &s t a t , WNOHANG) ) > 0 ) {
−−s p r o c c o u n t e r ;
e r r m s g ( ” c h i l d %d t e r m i n a t e d ” , p i d ) ;
}
return ;
10
}
Listing B.2: Obsługa sygnału SIGCHLD.
Potencjalne przyczyny występowania problemu:
• wyścig lub błędna optymalizacja w dostępie do zmiennej
sproc counter – procedura obsługi przerwania nie jest co prawda
uruchamiana w osobnym wątku, ale sygnały systemowe są asynchroniczne i mogą pojawić się w dowolnym momencie (nawet podczas
obsługi innego sygnału),
• usuwanie procesów potomnych przez inny proces – to jednak nie powinno nastąpić, póki istnieje proces główny,
• proces potomny nie przechodzi w stan zombie tylko jest od razu lub
automatycznie usuwany z tabeli procesów – podobnie jak wyżej taka
sytuacja nie ma prawa wystąpić w systemie Linux.
Zakładając poprawność działania systemu, jednym powodem pozostaje
synchronizacja dostępu do zmiennej. Ta jednak w przypadku zdarzeń asynchronicznych nie jest oczywista. W kolejnych rozdziałach opisałem możliwe
rozwiązania tego problemu.
B.2
Przyczyny problemu i jego potencjalne
rozwiązania
Ewidentnym powodem błędnego działania licznika jest brak synchronizacji
dostępu do zmiennej sproc counter. Najprawdopodobniej „zgubienie” dekrementacji licznika następuje w momencie, gdy modyfikacja wartości zmiennej przez wątek główny zostaje przerwana przez sygnał SIGCHLD. Rzecz
można rozważać tylko teoretycznie ze względu na znikomy procent przypadków, kiedy się to zdarza. Prawdopodobna sekwencja instrukcji powodujących
błąd jest następująca:
1. Wątek główny pobiera wartość X do rejestru ze
sproc counter (znajdującej się w pamięci operacyjnej),
145
zmiennej
2. Przychodzi sygnał SIGCHLD w wyniku czego następuje przekazanie sterowania do funkcji obsługi sygnału,
3. Funkcja obsługi sygnału pobiera tę samą wartość X do rejestru, a następnie odejmuje od niej 1 i zapisuje z powrotem do pamięci (wartość
X − 1),
4. Sterowanie wraca do wątku głównego, który dodaje 1 do wartości przechowywanej w rejestrze i zapisuje ją do pamięci (wartość X + 1), nadpisując tym samym modyfikację wykonaną w funkcji obsługi sygnału.
W efekcie powyższej sekwencji wydarzeń, wartość licznika wynosi X + 1 zamiast X (jedna operacja dodawania, jedna odejmowania). Istnieje co najmniej kilka sposobów podejścia do tego problemu.
B.2.1
Typ sig atomic t
Rozwiązaniem powinna być tutaj deklaracja zmiennej jako volatile
sig atomic t. Według [17, 24.4.7.2] sig atomic t jest typem całkowitoliczbowym, do którego dostęp jest atomowy, nawet w przypadku obecności w systemie sygnałów asynchronicznych. Kwalifikator volatile dodatkowo zapewnia, że kompilator nie będzie optymalizował instrukcji dostępu do zmiennej.
Jednak ponowne testy wykazują, że mimo użycia tego typu, licznik nie działa
poprawnie. Dokładniejsza lektura wspomnianego dokumentu oraz standardu
[9] wyjaśnia tę kwestię.
Dokument [17] przez „dostęp do zmiennej” rozumie odczyt lub zapis między pamięcią a rejestrami procesora, co implikuje, że tylko instrukcje odczytu
i zapisu zmiennej należy uznawać za atomowe – tzw. „słaba atomowość”
(ang. weak atomicity). Na wszystkich nowoczesnych procesorach obsługiwanych przez kompilator GCC zwykły typ int jest w tym sensie atomowy –
dlatego właśnie w bibliotece C (glibc) typ sig atomic t jest zdefiniowany
następująco:
1
typedef int
sig atomic t ;
Taka implementacja jest w pełni zgodna ze standardem [9], który określa
następujące wymagane cechy zmiennej typu sig atomic t (§5.1.2.3 pt. 5,
§7.14 pt. 2 oraz §7.14.1.1 pt. 5):
• wartość obiektu tego typu, który był modyfikowany wewnątrz funkcji
obsługi sygnału, musi być zdefiniowana po powrocie do wątku głównego,
146
• jest to typ całkowitoliczbowy, który można traktować jako atomowy
dla operacji odczytu i zapisu w obecności sygnałów asynchronicznych,
Z powyższych wynika, że jedynie operacje zapisu i odczytu do/z pamięci
należy traktować jako niepodzielne, a zatem nieprzerywalne przez sygnały
asynchroniczne. Natomiast wszystkie inne operacje, takie jak dowolne modyfikacje wartości (w szczególności inkrementacja lub dekrementacja), nie
muszą już być atomowe. Potwierdza to skompilowane do kodu maszynowego
wywołanie dekrementacji licznika:
1
movl
subl
movl
s p r o c c o u n t e r (% r i p ) , %eax
\$1 , %eax
%eax , s p r o c c o u n t e r (% r i p )
Potrzeba aż trzech instrukcji, żeby zmodyfikować wartości zmiennej w
pamięci operacyjnej. W pierwszej kolejności program pobiera z pamięci wartość zmiennej i zapisuje ją do rejestru procesora, następnie odejmuje 1 od
wartości zapisanej w rejestrze i na koniec z powrotem zapisuje zawartość rejestru do pamięci. Każda instrukcja z osobna jest niepodzielna, ale te trzy
razem już nie. Jasne zatem staje się, że zmienna typu sig atomic t wymaga
dodatkowej synchronizacji w sytuacji wielodostępu.
B.2.2
Semafory
B.2.2.1
Sekcja krytyczna
Naturalnym rozwiązaniem problemu synchronizacji dostępu byłoby utworzenie sekcji krytycznej za pomocą semaforów (z biblioteki LinuxThreads).
Na listingach B.3 i B.4 są pokazane wymagane modyfikacje kodu programu
bramki.
1
5
10
15
p t h r e a d m u t e x t sp r o c mu te x = PTHREAD MUTEX INITIALIZER ;
{
[...]
i f ( ( c h i l d p i d = Fork ( ) ) == 0 ) {
exit (0);
}
p t h r e a d m u t e x l o c k ( s p ro c mu te x ) ;
147
p t h r e a d m u t e x u n l o c k ( sp ro c mu te x ) ;
20
}
[...]
Listing B.3: Tworzenie procesów potomnych w funkcji main() – sekcja
krytyczna.
1
{
p i d t pid ;
int s t a t ;
attribute
((
unused
)))
5
}
return ;
10
}
Listing B.4: Obsługa sygnału SIGCHLD – sekcja krytyczna.
Przeprowadzone ponownie testy wykazały jednak wciąż niepoprawne
wskazania licznika. Ta anomalia jest jednak wyjaśniona w [13] – żadna z
funkcji obsługujących muteksy nie jest bezpieczna w przypadku istnienia sygnałów asynchronicznych, a co za tym idzie nie powinny być on wywoływane
w funkcjach obsługi sygnałów – co więcej ich użycie w może doprowadzić
do zakleszczenia wywołującego je wątku. Tego efektu nie zaobserwowałem,
natomiast jasne jest, że semafory nie działały poprawnie.
B.2.2.2
Sekcja krytyczna poza obsługą sygnału
Bardziej poprawną wersją rozwiązania z użyciem semaforów jest przeniesienie sekcji krytycznej poza funkcję obsługi sygnału SIGCHLD. Bezpieczną
metodą, sugerowaną przez [17, 24.4.7.3], jest utworzenie zmiennej powiadamiającej (ang. flag) o konieczności wywołania waitpid() na zakończonych
procesach potomnych i sprawdzaniu jej stanu co jakiś czas w innym miejscu w
kodzie programu. Ponadto dzięki takiemu rozwiązaniu czas obsługi sygnału
jest możliwie krótki, co jest zgodne z dobrą praktyką.
W tej wersji rozwiązania funkcja obsługi sygnału zawiera tylko jedno
wywołanie, zmieniające stan zmiennej powiadamiającej – patrz listing B.5.
Zdecydowałem, że nie będzie dobrą rzeczą realizowanie obsługi sygnału w
148
wątku głównym – powinien on być możliwe dostępny dla klientów. Dlatego
też utworzyłem dedykowany wątek dla czynności związanych z usuwaniem
zakończonych procesów potomnych. Kod wątku, pokazany na listingu B.6, nie
różni się bardzo od pierwotnej funkcji obsługi sygnału – zmiany są dwie. Po
pierwsze całość wywoływana jest w pętli (linie 6-19). Po drugie na początku
tejże pętli wątek sprawdza wartość zmiennej sigchld notify i jeśli nie jest
ona ustawiona, usypia na określony czas (linie 7-10). W przeciwnym wypadku
usuwa w pętli zakończone procesy potomne (linie 12-17), a na koniec zeruje
zmienną powiadamiającą (linia 18).
1
volatile sig atomic t s i g c h l d n o t i f y = 0;
5
{
sigchld notify = 1;
return ;
}
attribute
((
unused
)))
Listing B.5: Obsługa sygnału SIGCHLD – ustawianie zmiennej powiadamiającej.
1
void ∗ c h i l d p r o c e s s g u a r d ( void ∗ a r g )
{
p i d t pid ;
int s t a t ;
5
f or ( ; ; ) {
i f ( 0 == s i g c h l d n o t i f y ) {
u s l e e p (SIGCHLD SLEEP ) ;
continue ;
}
10
}
sigchld notify = 0;
15
}
return NULL;
20
}
Listing B.6: Wątek dedykowany zajmujący się obsługą sygnału SIGCHLD.
To zwięzłe rozwiązanie ma jednak ukrytą wadę, która może ujawnić się
w programie bramki – problem dotyczy tworzonych procesów potomnych.
149
Niestety łączenie tworzenia procesów potomnych z wielowątkowością potencjalnie powoduje wiele trudnych do zdiagnozowania błędów. Rzecz wynika
z zachowania funkcji fork(), która według opisu w [11], kopiuje do nowego
procesu tylko jeden wątek procesu rodzica – ten, który ją wywołał. To pozornie właściwa cecha, bo w bramce S/MIME procesy obsługi są jednowątkowe. Jednak proces potomny dziedziczy także wszelkie blokady systemowe
i deskryptory plików. Także te używane przez wątki inne niż skopiowany,
gdyż należą one do procesu, a nie poszczególnych wątków. Jeżeli utworzenie
procesu nastąpi np. w trakcie wołania procedury systemowej, która zakłada
jakieś blokady, w nowym procesie pozostaną one w tym stanie i to już permanentnie – wątek, który mógłby je zdjąć nie został skopiowany. Dlatego
też łączenie w jednym programie tworzenia procesów i wielowątkowości jest
niezalecane i zawsze ryzykowne.
Testy przeprowadzone na tej wersji programu wykazały poprawność działania licznika. Jednak teoretyczna możliwość wystąpienia trudnych do zdiagnozowania błędów dyskwalifikuje takie rozwiązanie. Nawet jeśli w krótkim
teście błędy nie wystąpiły, to nie wiadomo czy i kiedy mogą się one ujawnić
podczas pracy w rzeczywistym środowisku.
B.2.3
Blokowanie sygnału SIGCHLD
Ostatnią metodą rozwiązania problemu błędnie działającego licznika jest wykorzystanie blokowania sygnałów. Ta jednak zadziała tylko, jeśli faktycznym
i jedynym powodem błędu jest wyścig spowodowany przez obsługę sygnału
SIGCHLD. Jako, że program bramki nie korzysta z innych sygnałów, to założenie powinno być poprawne.
Rozwiązanie z blokowaniem sygnałów zdecydowanie w najmniejszym
stopniu ingeruje w pierwotny kod programu. Zmiany dotyczą jedynie funkcji
main() (listing B.7). W liniach 9-10 przygotowywana jest maska z ustawionym sygnałem SIGCHLD, która w liniach 25-27 jest potem użyta do zablokowania sygnału na czas inkrementacji licznika.
Warto tu dodać, że blokowanie sygnału nie jest równoznaczne z jego ignorowaniem. Sygnały blokowane nigdy nie są gubione, a ich obsługa jest jedynie odkładana do czasu odblokowania. Nie ma zatem niebezpieczeństwa, że
proces potomny, który zakończył się w trakcie inkrementacji zostanie zapomniany.
1
5
{
s i g s e t t mask , chld mask ;
[...]
150
/∗ s e t a p p r o p r i a t e h a n d l e r f o r SIGCHLD ∗/
S i g n a l (SIGCHLD, s i g c h l d ) ;
s i g e m p t y s e t (& chld mask ) ;
s i g a d d s e t (&chld mask , SIGCHLD ) ;
10
[...]
/∗ SMTP S e r v e r ’ s main l o o p ∗/
f or ( ; ; ) {
[...]
15
i f ( ( c h i l d p i d = Fork ( ) ) == 0 ) {
exit (0);
}
s i g p r o c m a s k (SIG BLOCK , &chld mask , &mask ) ;
s i g p r o c m a s k (SIG SETMASK, &mask , NULL ) ;
}
else
err msg ( ” subprocess l i m i t exceeded ” ) ;
20
25
30
[...]
}
}
Listing B.7: Blokowanie sygnału SIGCHLD w funkcji main().
Przeprowadzone testy wykazały poprawność rozwiązania – tak zabezpieczony licznik pokazuje faktyczną liczbę istniejących podprocesów. W porównaniu z klasyczną sekcją krytyczną jest też to „lżejsza” metoda, niewymagająca użycia ani wątków ani semaforów.
B.3
Podsumowanie
Ten prosty przykład pokazuje, jak wiele uwagi i wiedzy wymaga programowanie systemowe, jak subtelne potrafią różnice między implementacją poprawną
i błędną. Dlatego właśnie tak ważną rzeczą jest znajomość i przestrzeganie tzw. „dobrych praktyk” programistycznych, które pozwalają ustrzec się
przed wieloma błędami. Tym bardziej, że wiele z nich ujawnia się dopiero
151
w pewnych konkretnych sytuacjach. Dobrze, jeśli testy je objęły i błąd został zdiagnozowany i usunięty. Gorzej, jeżeli błąd ujawni się dopiero podczas
pracy w środowisku produkcyjnym.
Bibliografia
[1] Benchmarks of the Lockless Memory Allocator. Lockless Inc., kwiecień 2011. http://locklessinc.com/benchmarks_allocator.shtml
[dostęp: 2014-02-21 11:58].
[2] 2013 Email Marketing Metrics Benchmark Study: An Analysis of Messages Sent Q1-Q4, 2012. Silverpop, kwiecień 2013.
[3] C. Adams, S. Lloyd. PKI. Podstawy i zasady działania. Wydawnictwo
Naukowe PWN SA, Warszawa, wydanie pierwsze, 2007.
[4] K. Bhargavan, C. A. Gunter. Formal Methods in System Design: Network Event Recognition. Springer Science + Business Media, 27:213–
251, 2005.
[5] R. Cocker. Manual page for postal. Linux Benchmark Suite, wydanie
0.72, 2012. http://www.coker.com.au/postal/.
[6] L. Dostalek. Bezpieczeństwo protokołu TCP/IP. Wydawnictwo Naukowe
PWN SA, Warszawa, wydanie pierwsze, 2006.
[7] B. Fink. Manual page for nuttcp. US Naval Research Lab, Washington,
wydanie 6.1.2, 2007. http://www.lcp.nrl.navy.mil/nuttcp/.
[8] N. Freed, N. Borenstein, K. Moore.
Multipurpose Internet Mail Extensions (MIME). Internet RFCs 2045, 2046,
2047, 2049.
Internet Engineering Task Force, listopad 1996.
http://tools.ietf.org/html/rfc2045,
http://tools.ietf.
org/html/rfc2046,
http://tools.ietf.org/html/rfc2047,
http://tools.ietf.org/html/rfc2049.
[9] ISO C Working Group. ISO/IEC 9899:2011 – Information technology –
Programming languages – C. ISO (International Organization for Standardization), kwiecień 2011. http://www.open-std.org/jtc1/sc22/
wg14/www/docs/n1570.pdf.
BIBLIOGRAFIA
153
[10] R. Housley. Cryptographic Message Syntax (CMS). Internet RFC 5652.
Internet Engineering Task Force, wrzesień 2009. http://tools.ietf.
org/html/rfc5652.
[11] M. Kerrisk. Linux Programmer’s Manual. The Linux Kernel Organization, marzec 2013. ://www.kernel.org/doc/man-pages/.
[12] J. Klensin. Simple Mail Transfer Protocol. Internet RFC 5321. Internet
Engineering Task Force, październik 2008. http://tools.ietf.org/
html/rfc5321.
[13] X. Leroy. Manual page for pthread mutex lock. Free Software Foundation, Inc., wydanie 0.7, 1997. http://pauillac.inria.fr/~xleroy/
linuxthreads/.
[14] R. Manghwani, T. He.
Scalable Memory Allocation.
New
York University, maj 2012. http://cs.nyu.edu/~lerner/spring12/
Preso05-MemAlloc.pdf [dostęp: 2014-02-21 12:00].
[15] T. Pieczerak. Bramka protokołu SMTP, szyfrująca przesyłki w standardzie S/MIME. Politechnika Warszawska, Wydział Elektroniki i Technik
Informacyjnych, 2012.
[16] J. B. Postel. Simple Mail Transfer Protocol. Internet RFC 821. Internet
Engineering Task Force, sierpień 1982. http://tools.ietf.org/html/
rfc821.
[17] The GNU Project. The C GNU Library Manual. Free Software Foundation, Inc., sierpień 2013. http://www.gnu.org/software/libc/
manual/ [dostęp: 2014-01-19 12:03].
[18] Longbottom R. Roy Longbottom’s Raspberry Pi Benchmarks. Roy
Longbottom’s PC Benchmark Collection, luty 2014. http://www.
roylongbottom.org.uk/Raspberry%20Pi%20Benchmarks.htm [dostęp:
2014-02-21 12:07].
[19] B. Ramsdell, S. Turner. Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.2. Certificate Handling. Internet RFC 5750. Internet Engineering Task Force, styczeń 2010. http://tools.ietf.org/
html/rfc5750.
[20] B. Ramsdell, S. Turner. Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.2. Message Specification. Internet RFC 5751. Internet Engineering Task Force, styczeń 2010. http://tools.ietf.org/
html/rfc5751.
BIBLIOGRAFIA
154
[21] K. Sacha. Inżynieria oprogramowania. Wydawnictwo Naukowe PWN
SA, Warszawa, wydanie pierwsze, 2010.
[22] R. Schwebel. Performance Measurement on ARM. Pengutronix,
czerwiec 2013. http://www.pengutronix.de/development/kernel/
arm-benchmarks-20100729_en.html [dostęp: 2014-02-21 13:22].
[23] W. R. Stevens. UNIX Programowanie usług sieciowych - API: gniazda
i XTI. Wydawnictwo Naukowo-Techniczne, Warszawa, wydanie drugie,
2002.
[24] Raspberry Pi Team. Raspberry Pi — An ARM GNU/Linux box for
$25. Take a byte! Raspberry Pi Foundation, 2012. http://www.
raspberrypi.org/ [dostęp: 2014-02-10 18:21].
[25] Wikipedia. S/MIME. Wikimedia Foundation, 2011. http://en.
wikipedia.org/wiki/S/MIME [dostęp: 2012-01-22 21:48].
[26] Wikipedia.
Email.
Wikimedia Foundation, 2012.
wikipedia.org/wiki/Email [dostęp: 2012-01-15 10:32].
http://en.
[27] Wikipedia. Pretty Good Privacy. Wikimedia Foundation, 2012. http:
//en.wikipedia.org/wiki/Pretty_Good_Privacy [dostęp: 2012-08-14
20:05].
[28] ITU-T Recommendation X.509. Information technology - Open Systems
Interconnection - The Directory: Public-key and attribute certificate frameworks. International Telecommunication Union, listopad 2008. (odpowiednik ISO/IEC 9594-8 ).

Bramka protokołu SMTP szyfrująca przesyłki w

Transkrypt

Podobne dokumenty

pobierz plik pdf

Pobierz PDF