Automatic Repeat ReQuests, często w skrócie ARQ, to protokół kontroli błędów w transmisji danych. Wykorzystując kody wykrywania błędów i potwierdzenia, protokoły ARQ mogą zagwarantować bezbłędne dostarczanie danych, zapewniając, że odbiorca otrzyma dokładną kopię danych przesłanych przez nadawcę.
Pochodzenie i wczesna historia automatycznych żądań powtórzeń
Korzenie automatycznych żądań powtórzeń sięgają początków telegrafii w XIX wieku. Operatorzy telegraficzni ręcznie żądali retransmisji wiadomości, które były niejasne lub zniekształcone. Jednakże pierwszą wzmiankę o zautomatyzowanym systemie podobnym do ARQ można znaleźć w patencie A. Harry'ego Nyquista z 1924 r. dotyczącym „Systemu powtarzania telegrafu”.
Rozwój i udoskonalanie protokołów ARQ zaczęło gwałtownie wzrastać wraz z pojawieniem się cyfrowej transmisji danych w XX wieku. Najbardziej znaczącym krokiem naprzód w tej epoce było być może wprowadzenie w latach sześćdziesiątych XX wieku cyklicznej kontroli nadmiarowej (CRC), schematu kodowania wykrywającego błędy nadal szeroko stosowanego we współczesnych implementacjach ARQ.
Istota automatycznych żądań powtórzeń
Automatyczne żądania powtórzeń mają fundamentalne znaczenie w systemach transmisji danych i zapewniają integralność danych podczas transmisji. Aby to osiągnąć, protokoły ARQ wykorzystują trzy podstawowe mechanizmy: wykrywanie błędów, potwierdzanie i retransmisję.
W systemie ARQ nadawca dołącza kod wykrywania błędu (np. CRC) do wychodzących danych. Po otrzymaniu odbiorca wykorzystuje ten sam algorytm wykrywania błędów do sprawdzania poprawności danych. Jeżeli dane są wolne od błędów, odbiorca przesyła potwierdzenie do nadawcy. W przypadku wykrycia błędu odbiorca wysyła negatywne potwierdzenie (NAK) lub w niektórych przypadkach po prostu milczy, prosząc nadawcę o ponowne przesłanie danych.
Mechanizmy stojące za automatycznymi żądaniami powtórzeń
Protokoły ARQ zasadniczo działają na zasadach opisanych powyżej, ale różnią się sposobem radzenia sobie z określonymi sytuacjami. Niektóre z rozważań przy projektowaniu ARQ obejmują:
- Co powoduje retransmisję?
- Jak sobie radzić z pakietami poza kolejnością?
- Jak zoptymalizować wydajność i przepustowość systemu?
Dokładne zasady obsługi tych scenariuszy definiują zachowanie i charakterystykę wydajności protokołu ARQ. Na przykład sposób, w jaki protokół reaguje na wiele nieudanych transmisji, może mieć wpływ na jego niezawodność w hałaśliwym lub zawodnym środowisku komunikacyjnym.
Kluczowe cechy automatycznych żądań powtórzeń
Do najważniejszych cech protokołów ARQ należą:
- Bezbłędne dostarczanie danych: protokoły ARQ mogą zagwarantować, że odbiorca otrzyma dokładną kopię danych przesłanych przez nadawcę.
- Możliwość adaptacji: ARQ może dostosować się do różnych poziomów szumów i błędów w kanale komunikacyjnym.
- Wydajność: retransmitując jedynie błędne dane, ARQ unika marnowania pasma na niepotrzebne transmisje.
Rodzaje automatycznych żądań powtórzeń
W systemach transmisji danych powszechnie stosowane są trzy typy protokołów ARQ:
- Zatrzymaj i czekaj ARQ: Najprostsza forma ARQ, w której nadawca zatrzymuje się i czeka na potwierdzenie po każdej transmisji. Jeżeli w określonym czasie nie zostanie odebrane żadne potwierdzenie, nadawca ponownie przesyła dane.
- Go-Back-N ARQ: W tym podejściu nadawca może przesłać serię pakietów bez czekania na potwierdzenia, aż do pewnego limitu (N). Jeśli zostanie wykryty błąd, nadawca „wraca” i ponownie przesyła wszystkie pakiety od tego momentu.
- Selective Repeat ARQ: Ulepszenie w stosunku do Go-Back-N, Selective Repeat ARQ pozwala odbiornikowi akceptować pakiety spoza kolejności i żądać retransmisji tylko błędnych.
Praktyczne zastosowania i wyzwania
Protokoły ARQ znajdują zastosowanie w niemal każdym aspekcie cyfrowej transmisji danych, w tym w sieciach komórkowych, Wi-Fi, komunikacji satelitarnej i przesyłaniu plików przez Internet.
Jednak korzystanie z ARQ nie jest pozbawione wyzwań. Na przykład dodatkowe dane potrzebne do wykrycia błędów i potwierdzenia mogą zmniejszyć użyteczną przepustowość. Co więcej, opóźnienia spowodowane retransmisją mogą mieć wpływ na aplikacje komunikacyjne działające w czasie rzeczywistym, takie jak VoIP i strumieniowe przesyłanie wideo.
Porównanie z innymi protokołami kontroli błędów
Oprócz ARQ w transmisji danych wykorzystywane są dwa inne podstawowe protokoły kontroli błędów:
-
Korekcja błędów w przód (FEC): FEC koduje dane w sposób umożliwiający odbiorcy skorygowanie ograniczonej liczby błędów. W przeciwieństwie do ARQ, FEC nie wymaga retransmisji danych, ale wymaga większej przepustowości dla dodatkowych kodów korygujących błędy.
-
Hybrydowy ARQ (HARQ): HARQ łączy w sobie elementy ARQ i FEC. Jeśli odebrany pakiet zawiera błędy, HARQ najpierw próbuje je skorygować za pomocą FEC. Jeśli to się nie powiedzie, następuje powrót do mechanizmu ARQ polegającego na żądaniu retransmisji.
Przyszłe perspektywy i technologie
Wraz z ciągłą ewolucją technologii transmisji danych, protokoły ARQ są również udoskonalane i optymalizowane. Na przykład protokoły zaprojektowane dla nowych sieci 5G wykorzystują wyrafinowane schematy HARQ, które mogą dostosowywać się do warunków kanału komunikacyjnego w czasie rzeczywistym, maksymalizując przepustowość danych i minimalizując opóźnienia.
Co więcej, przyszłe badania w dziedzinie komunikacji i obliczeń kwantowych mogą doprowadzić do powstania nowych typów protokołów kontroli błędów, potencjalnie zastępujących lub uzupełniających tradycyjne ARQ.
Serwery proxy i automatyczne powtarzanie żądań
Serwery proxy, takie jak te dostarczane przez OneProxy, również mogą korzystać z protokołów ARQ. Jako pośrednicy pomiędzy klientem a Internetem, serwery proxy mogą wykorzystywać ARQ w celu zapewnienia integralności przesyłanych za ich pośrednictwem danych. Na przykład serwer proxy może używać ARQ do retransmisji danych, jeśli napotka błędy spowodowane przeciążeniem sieci, utratą pakietów lub innymi problemami.
W ten sposób serwery proxy mogą poprawić niezawodność połączenia klienta, szczególnie w scenariuszach z niestabilnymi lub zawodnymi sieciami.
powiązane linki
Dalsze informacje na temat automatycznych żądań powtórzeń i powiązanych koncepcji można znaleźć w następujących zasobach:
