Praca magisterska z sieci komputerowych to nie jest projekt, w którym „opisujesz jak działa TCP/IP”. Promotorzy na tym kierunku oczekują konkretnych pomiarów, powtarzalnych eksperymentów i wniosków opartych na danych. Jeśli twoja praca wygląda jak rozszerzony artykuł z Wikipedii, przepadniesz na obronie.
Ten przewodnik napisałam na podstawie współpracy z dziesiątkami studentów informatyki i telekomunikacji. Pokazuję, jak dobrać temat, zaprojektować środowisko testowe, zebrać sensowne wyniki i opisać to wszystko tak, żeby komisja miała do czego się odnieść.
Jakie typy prac dominują na tym kierunku
Na sieci komputerowe i administrację systemami składa się kilka wyraźnych nurtów badawczych. Nim wybierzesz temat, warto zrozumieć, w którym z nich chcesz się poruszać.
Analiza wydajności sieci to klasyczny wybór. Mierzysz przepustowość, opóźnienia, jitter i straty pakietów w różnych warunkach. Testujesz np. jak zachowuje się TCP NewReno vs CUBIC pod dużym obciążeniem albo jak VoIP radzi sobie przy packet loss powyżej 3%.
Wdrożenie i ocena protokołu polega na implementacji lub konfiguracji konkretnego rozwiązania, a potem jego pomiarach. Dobry przykład: porównanie BGP vs OSPF w topologii multi-AS pod kątem czasu konwergencji po awarii łącza.
Bezpieczeństwo sieciowe to temat, który zyskuje na popularności. Możesz analizować skuteczność reguł firewalla, testować IDS/IPS na zestawie wzorców ataków, porównywać IPsec i OpenVPN pod kątem narzutu na przepustowość.
SDN i NFV to bardziej zaawansowany nurt. Prace z Software-Defined Networking wymagają zwykle pracy z OpenDaylight, ONOS lub Mininet i dotyczą sterowania ruchem, orkiestracji funkcji sieciowych albo elastyczności w chmurze.
Sieci IoT to rosnąca nisza. Tutaj pracujesz z MQTT, CoAP, Zigbee lub LoRaWAN i mierzysz np. zużycie energii sensorów vs częstotliwość transmisji albo niezawodność w gęsto zaludnionym spektrum 2,4 GHz.
Analiza ruchu sieciowego (traffic analysis) skupia się na klasyfikacji protokołów, detekcji anomalii lub identyfikacji aplikacji na podstawie cech statystycznych strumieni. Tu przydaje się Machine Learning, ale praca jest wtedy interdyscyplinarna.
QoS (Quality of Service) obejmuje mechanizmy kolejkowania (FIFO, WFQ, DSCP marking), priorytetyzację ruchu i pomiar jak dane ustawienia wpływają na opóźnienia aplikacji krytycznych.
Jak wybrać temat, który da się obronić
Temat musi spełniać dwa warunki: być mierzalny i być oryginalny w jakimś sensible zakresie.
„Analiza bezpieczeństwa sieci bezprzewodowych” to nie temat, to kategoria. „Porównanie czasu wykrycia ataku deautentykacji przez Snort 3.x i Suricata 7.x w środowisku WPA3-Enterprise przy różnych progach alertów” to temat.
Dobry temat z sieci komputerowych zazwyczaj ma formę: „Ocena/Porównanie/Projekt X przy warunku/parametrze Y z użyciem narzędzia/środowiska Z”.
Kilka konkretnych przykładów, które da się zrealizować w ciągu semestru:
- Porównanie skuteczności mechanizmów QoS dla ruchu VoIP w środowisku wirtualizowanym z użyciem GNS3
- Analiza wydajności tuneli IPsec vs WireGuard pod kątem narzutu CPU i przepustowości na urządzeniach ARM
- Implementacja sieci definiowanej programowo (SDN) z kontrolerem ONOS i ocena czasu reakcji na zmiany topologii
- Detekcja anomalii w ruchu sieciowym metodami uczenia maszynowego na zestawie danych CICIDS2017
- Ocena niezawodności sieci sensorycznej LoRaWAN w środowisku przemysłowym z zakłóceniami RF
Sprawdź przed wyborem: czy możesz powtórzyć eksperymenty co najmniej 30 razy? Czy masz dostęp do sprzętu lub softu do symulacji? Czy promotor ma doświadczenie w tym obszarze?
Środowisko testowe i metodologia
To jest serce pracy. Komisja ocenia nie tylko wyniki, ale to, czy metodologia jest powtarzalna i wiarygodna.
Symulacje vs pomiary rzeczywiste
Masz do wyboru trzy podejścia, często łączone:
Symulatory sieciowe dają pełną kontrolę nad topologią i parametrami. GNS3 pozwala emulować prawdziwe urządzenia Cisco, Juniper, MikroTik z rzeczywistymi obrazami IOS. Cisco Packet Tracer jest prostszy, ale ograniczony do symulacji, nie emulacji. NS-3 to symulator dyskretno-zdarzeniowy z bardzo dokładnymi modelami protokołów, dobry do badań nad TCP i routingiem. Mininet emuluje sieci SDN z prawdziwymi kernelami Linuksowymi, idealny do prac z OpenFlow.
Testbed fizyczny to najbardziej wiarygodne podejście, ale kosztowne. Jeśli masz dostęp do laboratorium uczelnianego z przełącznikami i routerami, skorzystaj. Prawdziwe pomiary na fizycznym sprzęcie mają większą wartość w pracy badawczej.
Środowiska wirtualne to kompromis. Możesz postawić klaster VM (KVM, VirtualBox, VMware) i testować konfiguracje sieciowe bez zakupu sprzętu. Pamiętaj jednak, że wirtualizacja wprowadza własny narzut (CPU scheduling, virtual switch latency), który musisz opisać jako ograniczenie metodologii.
Jak zaplanować eksperymenty
Przed pierwszym pomiarem napisz „protokół eksperymentu”: co mierzysz, w jakich warunkach, ile iteracji, jak izolujesz zmienne.
Standardowa praktyka: zmień jeden parametr na raz. Jeśli testujesz wpływ packet loss na throughput TCP, nie zmieniaj jednocześnie przepustowości łącza. Jeśli porównujesz dwa protokoły, uruchom je w identycznych warunkach, na tej samej topologii.
Minimalna liczba powtórzeń: 30 dla każdego punktu pomiarowego, żeby można było użyć statystyk parametrycznych (średnia, odchylenie standardowe, przedziały ufności). Przy mniejszych próbach użyj testów nieparametrycznych (Mann-Whitney U).
Opisz w pracy: wersje software, konfigurację systemu operacyjnego, sprzęt (lub parametry VM), czas trwania każdego testu, warunki izolacji (brak ruchu tła, dedykowany hardware).
Wyślij fragment tekstu, bezpłatną wycenę otrzymasz w 24 h. Poprawki bez limitu w cenie usługi.
Metryki, które musisz znać i umieć mierzyć
Nie pisz „zmierzyłem wydajność sieci”. Napisz, które metryki mierzyłeś i jak.
Przepustowość (throughput) mierzy się w Mbps lub Gbps. Rozróżniaj: przepustowość nominalna (przepustowość łącza) vs efektywna (rzeczywista liczba danych aplikacyjnych na sekundę). iperf3 jest tu podstawowym narzędziem. Uruchom test TCP i UDP osobno.
Opóźnienie (latency/RTT) to czas Round-Trip Time w milisekundach. Mierz za pomocą ping (ICMP), ale pamiętaj, że ICMP bywa depriorytetyzowany przez routery. Lepszy jest pomiar RTT na poziomie aplikacyjnym (np. czas odpowiedzi HTTP z wget/curl z opcją -w "%{time_total}").
Jitter to wariancja opóźnień, szczególnie ważna dla VoIP i video streaming. Wartości powyżej 30-50 ms powodują problemy ze słyszalnością w VoIP. iperf3 w trybie UDP raportuje jitter bezpośrednio.
Packet loss wyrażasz w procentach. Nawet 0,1% straty pakietów dramatycznie redukuje throughput TCP przez mechanizm slow start. Testuj warunki 0%, 0,1%, 0,5%, 1%, 2%, 5% i opisz nieliniowość tej zależności.
SINR (Signal-to-Interference-plus-Noise Ratio) to metryka specyficzna dla sieci WiFi i 5G. Mierzona w dB, określa jakość sygnału radiowego. SINR powyżej 25 dB daje pełną przepustowość, poniżej 0 dB połączenie jest niemożliwe. W badaniach WiFi zbierasz SINR razem z MCS index (Modulation and Coding Scheme), żeby zrozumieć dlaczego adaptujesz modulację.
Czas konwergencji jest metryką dla protokołów routingu. Ile czasu zajmuje sieci osiągnięcie stabilnego stanu po awarii węzła lub łącza? Mierzysz to obserwując tabele routingu i licząc czas od zdarzenia do stabilizacji.
CPU overhead przy testach VPN i kryptografii. WireGuard ma znacznie mniejszy narzut niż IPsec IKEv2, co możesz pokazać mierząc % CPU podczas transferu.
Narzędzia, które warto znać
Dobra praca magisterska z sieci pokazuje, że student potrafi pracować z profesjonalnymi narzędziami diagnostycznymi.
Wireshark to absolutna podstawa. Używasz go do: analizy protokołów (filtr tcp.analysis.flags), identyfikacji retransmisji TCP, podglądu nagłówków MPLS/VLAN, wizualizacji okna przeciążeniowego TCP (Statistics > TCP Stream Graphs). W pracy opisz jakich filtrów używałeś i co z nich odczytałeś.
tcpdump jest konsolowym odpowiednikiem Wiresharka. Niezbędny gdy pracujesz na serwerze bez GUI. Przechwytuj ruch do pliku PCAP (tcpdump -i eth0 -w capture.pcap) i analizuj później w Wiresharku.
iperf3 to standardowe narzędzie do pomiaru throughput i jitter. Uruchamiasz serwer (iperf3 -s) i klienta (iperf3 -c 192.168.1.1 -t 60 -P 8). Flaga -P 8 oznacza 8 równoległych strumieni, co lepiej reprezentuje ruch produkcyjny. UDP test: iperf3 -c 192.168.1.1 -u -b 100M.
nmap służy do skanowania sieci, ale w pracach badawczych używasz go też do mapowania topologii, identyfikacji wersji usług i jako źródło testowego ruchu sieciowego dla IDS/IPS.
OpenWRT pozwala na zainstalowanie Linuksa na routerach klasy consumer i przeprowadzanie zaawansowanych eksperymentów z QoS, firewallem (nftables), tunelami VPN lub protokołami routingu (BIRD, Quagga/FRRouting).
SNMP + Nagios/Zabbix to narzędzia monitoringu. Jeśli praca dotyczy administracji systemami, pokaż jak zbierasz metryki z urządzeń sieciowych (ifInOctets, ifOutOctets, CPU load przez OID .1.3.6.1.4.1.2021.11.9.0), jak je wizualizujesz i jak ustawiasz alerty.
Ansible do konfiguracji: jeśli wdrażasz protokoły w środowisku multi-node, nie rób tego ręcznie na każdym urządzeniu. Pokaż playbooki Ansible do automatycznej konfiguracji BGP na 5 routerach. To pokazuje dojrzałość inżynierską i jest osobną wartością pracy.
Snort 3.x / Suricata 7.x to IDS/IPS. W pracach z bezpieczeństwa konfigurujesz reguły, generujesz testowy ruch ataku (nmap -sS, Metasploit, hping3) i mierzysz detection rate, false positive rate i opóźnienie detekcji.
Protokoły, o których musisz pisać ze zrozumieniem
Komisja zapyta o szczegóły. Pamiętaj, że protokoły to nie „etykiety”, tylko mechanizmy z konkretnymi właściwościami.
TCP/IP stack: rozumiej slow start, congestion avoidance, fast retransmit i fast recovery. Wireshark pokazuje okno przeciążeniowe w czasie. Różnice między TCP Reno, CUBIC i BBR są istotne przy latencjach powyżej 50 ms.
BGP vs OSPF: BGP to protokół ePath vector dla routingu między AS, OSPF to link-state wewnątrz AS. Czas konwergencji BGP po awarii łącza może wynieść kilka minut (hold timer = 90s domyślnie), OSPF konwerguje w sekundy przy BFD (Bidirectional Forwarding Detection). To jest konkretna różnica warta zbadania.
MPLS: Label Switching zamienia adresację IP na etykiety na krawędzi sieci, redukując czas przeszukiwania tablic routingu. W testach mierzysz wpływ MPLS na latencję w porównaniu z klasycznym IP forwarding.
VLAN i VxLAN: VLAN (802.1Q) segmentuje sieć na poziomie L2. VxLAN rozszerza tę segmentację przez sieci IP i jest podstawą wirtualizacji w datacenter (EVPN/VXLAN). Jeśli piszesz o SDN lub chmurze, VxLAN się pojawi.
WPA3: w porównaniu do WPA2, WPA3 wprowadza SAE (Simultaneous Authentication of Equals) zamiast PSK handshake, co eliminuje ataki słownikowe offline. W pracy możesz mierzyć czas asocjacji i narzut CPU access pointa.
5G NR (New Radio): jeśli praca dotyczy sieci mobilnych, SINR, RSRP i RSRQ to trzy metryki, które musisz znać. Subcarrier spacing w 5G FR1 to 15, 30 lub 60 kHz, a FR2 (mmWave) do 120 kHz.
Analiza bezpieczeństwa sieci jako temat pracy
Prace z bezpieczeństwa wymagają szczególnej metodologii, bo masz do czynienia z „przeciwnikiem”.
Środowisko izolowane jest obowiązkiem. Nigdy nie testuj exploitów ani skanerów portów w sieci produkcyjnej lub uczelnianej bez pisemnej zgody. Zawsze używaj izolowanej sieci testowej (VLAN, personal lab, VM bez dostępu do internetu).
Analiza reguł firewalla polega na: opisaniu polityki (deny-by-default czy allow-by-default), identyfikacji zbędnych reguł (shadow rules, redundant rules), pomiarze wpływu liczby reguł na latencję pakietów. W Linuksie używasz iptables/nftables i mierzysz throughput z iperf3 przed i po dodaniu zestawu reguł.
IDS/IPS (Snort, Suricata): skonfiguruj reguły dla kilku klas ataków (port scan, DoS SYN flood, DNS amplification), uruchom testy z Nmap i hping3, zmierz: detection rate (% prawdziwych ataków wykrytych), false positive rate (% legalnego ruchu błędnie oznaczonego), czas od ataku do alertu. Te trzy liczby to rdzeń rozdziału wynikowego.
VPN: IPsec vs OpenVPN vs WireGuard: porównujesz je pod kątem: throughput przy tym samym łączu, CPU overhead na 100 Mbps transferze, czas nawiązywania połączenia (handshake), podatności (IPsec ma pełną historię CVE, WireGuard jest relatywnie nowym i mniejszym kodem).
Jak opisać topologię sieci w pracy
Każda praca z sieci musi mieć schemat topologii. Nie wstawiaj screenshota z GNS3, zrób porządny diagram.
Użyj draw.io (bezpłatny, działa w przeglądarce) lub Cisco Visio Stencils. Na diagramie pokaż: adresy IP każdego interfejsu, numerację AS jeśli dotyczy, przepustowość łączy (np. 100 Mbps, 1 Gbps), nazwy protokołów routingu na strzałkach.
W tekście opisz topologię słowami, zakładając, że czytelnik nie widzi diagramu: „Środowisko testowe składa się z czterech routerów Cisco 7200 emulowanych w GNS3. Router R1 pełni rolę węzła brzegowego AS 65001 z połączeniem BGP do R3 (AS 65002) przez łącze 100 Mbps z dodanym jitterem 10 ms i packet loss 0,5% za pomocą tc netem.”
Struktura rozdziałów
Praca z sieci komputerowych zazwyczaj ma 5 rozdziałów. Poniżej przykładowy szkielet dla pracy porównawczej.
Rozdział 1: Wstęp (5-8 stron)
Motywacja (dlaczego ten problem jest aktualny), cel i zakres pracy, metoda badawcza w jednym akapicie, opis zawartości kolejnych rozdziałów.
Rozdział 2: Podstawy teoretyczne i przegląd literatury (25-35 stron)
Tu opisujesz protokoły, mechanizmy, istniejące prace badawcze. Cytuj artykuły z IEEE Xplore, ACM Digital Library i IETF RFCs. Każdy RFC to potencjalne źródło. Opisuj mechanizmy na poziomie, który pozwoli zrozumieć wyniki, bez przepisywania podręcznika.
Rozdział 3: Projekt środowiska testowego i metodologia (20-30 stron)
To Twoja praca. Opisz topologię, narzędzia, konfiguracje (z fragmentami plików konfiguracyjnych), procedurę eksperymentów, jak zbierałeś dane, jakie statystyki stosujesz. Ktoś po przeczytaniu tego rozdziału powinien być w stanie powtórzyć Twoje eksperymenty.
Rozdział 4: Wyniki i analiza (25-40 stron)
Tabele z danymi surowymi (lub odwołania do aneksu), wykresy (liniowe dla szeregów czasowych, słupkowe dla porównań, boxplot dla rozkładów), analiza statystyczna (średnie, odchylenia, przedziały ufności 95%), interpretacja wyników. Nie pisz „wyniki są dobre”. Pisz: „Mediana RTT dla WireGuard wyniosła 1,8 ms wobec 3,4 ms dla IPsec IKEv2, co stanowi redukcję o 47%.”
Rozdział 5: Wnioski (8-12 stron)
Co udało się potwierdzić, co zaprzeczyć hipotezom, ograniczenia środowiska testowego, kierunki dalszych badań.
Najczęstsze błędy w pracach z sieci
Po przejrzeniu wielu prac z tego zakresu widzę te same problemy.
Brak hipotezy badawczej. „Celem pracy jest analiza sieci VPN” to nie hipoteza. „Hipoteza: WireGuard osiągnie co najmniej 2x wyższy throughput niż IPsec IKEv2 przy tym samym narzucie CPU, mierzonym na urządzeniu ARM Cortex-A72.” To jest hipoteza, którą możesz potwierdzić lub obalić.
Za małe próby. 5 pomiarów na punkt to za mało. Widziałam prace, gdzie jedyne „dane” to jeden wykres z Wiresharka. To nie jest podstawa do wniosków.
Brak izolacji zmiennych. Zmieniono jednocześnie protokół i topologię, więc nie wiadomo, co wpłynęło na wyniki.
Screenshoty zamiast danych. Wstaw tabele z liczbami, nie screenshoty z terminala. Dane muszą być reprodukowalne i możliwe do analizy.
Opis narzędzi zamiast wyników. „Wireshark to program do analizy pakietów, stworzony przez Geralda Combsa w 1998 roku.” Komisja to wie. Napisz, co z nim zrobiłeś i co znalazłeś.
Brak walidacji środowiska. Zanim zaczniesz eksperymenty właściwe, pokaż, że środowisko działa zgodnie z oczekiwaniami: pomiar throughput bez narzutów powinien odpowiadać nominalnej przepustowości łącza z marginesem do 5%.
Zbyt ogólne wnioski. „Bezpieczeństwo sieci jest ważne.” To nie wniosek z pracy badawczej. Wniosek to: „Snort 3.1 z włączonym GPU offloading wykrywa 94,3% testowanych wzorców ataków przy false positive rate 2,1%, podczas gdy konfiguracja CPU-only osiąga 89,7% przy 1,8% FPR, co oznacza wzrost detection rate o 5,1 pp kosztem wzrostu FPR o 0,3 pp.”
FAQ
Czy praca z sieci komputerowych musi mieć część implementacyjną?
Nie musi, ale zwykle ją ma. Możesz napisać pracę czysto badawczą (pomiary i analiza istniejących systemów), ale promotorzy częściej doceniają prace, gdzie student coś skonfigurował, zaimplementował lub wdrożył. Implementacja może polegać na napisaniu skryptów do automatyzacji testów, konfiguracji środowiska GNS3, zbudowaniu playbooka Ansible do wdrożenia protokołu w topologii wielowęzłowej.
Ile urządzeń (fizycznych lub emulowanych) potrzebuję w środowisku testowym?
Zależy od tematu. Do porównania protokołów routingu wystarczą 3-4 routery. Do testów IDS/IPS potrzebujesz co najmniej 3 węzły: atakujący, sieć z IDS, cel. Do analizy QoS potrzebujesz węzeł generujący mieszany ruch (iPerf3 + VoIP sink + tle transfery HTTP) i węzeł pośredni z konfiguracją QoS. GNS3 pozwala emulować dziesiątki węzłów na jednym komputerze z 16 GB RAM.
Jak cytować RFC w bibliografii?
Styl IEEE zalecany dla prac z informatyki. RFC cytuje się tak: P. Srisuresh i K. Mayer, „NAT-Protocol Translation,” IETF RFC 2663, sierpien 1999. [Online] Dostepne: https://www.rfc-editor.org/rfc/rfc2663. Zawsze podaj numer RFC, autorów, tytul i rok.
Czy mogę używać danych z publicznych datasetów zamiast własnych pomiarów?
Tak, ale to podejście wymaga uzasadnienia. CICIDS2017, CAIDA Anonymized Internet Traces i CTU-13 to popularne datasety do analizy ruchu sieciowego i detekcji anomalii. Praca na publicznym datasecie jest wiarygodna (reprodukowalna przez innych), ale komisja zapyta o to, co Ty wniосles ponad istniejące analizy tego datasetu. Odpowiedz na to pytanie zanim skonfrontujesz się z nim na obronie.
Jak długo trwa zebranie danych do pracy z sieci?
Przy dobrze zaplanowanym środowisku testowym: 2-4 tygodnie aktywnych eksperymentów. Problem polega na tym, że pierwsze 2 tygodnie zwykle schodzą na debugowanie środowiska, walke z konfiguracją GNS3 i naprawianie błędów w skryptach pomiarowych. Zaplanuj 6-8 tygodni na cały etap badawczy i zacznij go co najmniej 3 miesiące przed planowanym oddaniem pracy.
