Czy to prawda, że TCP jest skrótem od TCP / IP i oznaczają to samo?
Czy to prawda, że TCP jest skrótem od TCP / IP i oznaczają to samo?
Odpowiedzi:
TCP i IP (v4 i v6) są zdecydowanie rozdzielne, a jedno nie implikuje drugiego, co udowodniono na przykładzie TCP przez IPX ( RFC 1791 ).
Nie można jednak zbudować protokołu TCP za pomocą dowolnego protokołu sieciowego. Dwa powody:
Specyfikacja TCP, RFC 793 , nie jest dobrym źródłem do rozstrzygnięcia tego pytania, ponieważ przyznaje, że pozostawia swój interfejs z dolną warstwą w dużej mierze nieokreślony.
Uwaga a) Aby TCP mógł ponownie złożyć datagramy wydrukowane na małych arkuszach papieru (niezależnie od tego, czy są one przenoszone przez gołębie, czy bardziej inteligentną sieć Corvid), rozmiar ładunku musiałby być zapisany w standardowej lokalizacji. Alternatywnie warstwa adaptacyjna może heurystycznie określić rozmiar segmentu. Skaner optyczny zastosowany w implementacji stosu hosta specyfikacji ptasich nośników ( RFC 1149 ) zawierał taką heurystyczną warstwę adaptacyjną, ale pozostaje nieudokumentowany.
Nie przeczytałem całego RFC, ale język w sekcji 1.4 wydaje się sugerować, że można użyć dowolnego protokołu „niższego poziomu”.
Interfejs między TCP a protokołem niższego poziomu jest zasadniczo nieokreślony, z wyjątkiem tego, że zakłada się, że istnieje mechanizm, dzięki któremu oba poziomy mogą asynchronicznie przekazywać sobie informacje. Zazwyczaj oczekuje się, że protokół niższego poziomu określi ten interfejs. TCP został zaprojektowany do pracy w bardzo ogólnym środowisku połączonych sieci. Protokół niższego poziomu przyjęty w tym dokumencie to protokół internetowy.
TCP nie jest skrótem od TCP / IP.
TCP / IP jest często używany jako skrótowy sposób powiedzenia „ pakiet protokołów internetowych ” i zwykle obejmuje inne standardowe protokoły. Kiedy ludzie mówią, że TCP / IP, zwykle zawierają UDP przez IP (w którym UDP jest używany zamiast TCP) i wiele innych protokołów, takich jak ARP, ICMP, DNS, SNMP i inne protokoły warstwy aplikacji.
Aplikacje używają protokołów warstwy aplikacji, takich jak SMTP (do wiadomości e-mail). Są one oparte na jednym z dwóch protokołów warstwy transportowej - TCP i UDP. Kilka protokołów warstwy aplikacji będzie używać jednego lub obu protokołów UDP i TCP, ale większość z nich jest używana tylko z jednym protokołem warstwy transportowej.
TCP i UDP to dwa protokoły warstwy transportowej używane w pakiecie Internet Protocol Suite. Jeśli są jeszcze inne, nie znam ich, a każdy inny reprezentowałby znikomo małe zastosowanie specjalistyczne. Inne protokoły warstw transportowych zostały zdefiniowane - ich użycie prawdopodobnie stanowi jedynie niewielką część globalnego ruchu IP †
Chociaż teoretycznie może być możliwe użycie TCP przez coś innego niż IP, w praktyce TCP jest zawsze używany przez IP - protokół internetowy. IP przenosi pakiety między sieciami (pomyśl o IP jako o połączeniu wielu sieci LAN razem)
Ethernet to tylko najpopularniejsza rodzina niskopoziomowych protokołów warstwy łącza, na których przenoszony jest protokół TCP / IP, ale protokół TCP / IP jest również szeroko stosowany w bankomatach i innych urządzeniach.
Jedynymi protokołami warstwy transportowej, które są często używane w sieciach korzystających z pakietu protokołów internetowych, są TCP i UDP.
† Dla zabawy zmierzyłem ruch w mojej (bardzo) małej sieci LAN, w tym NetBIOS (przez TCP), SSH, Rsync, e-mail, aktualizacje oprogramowania, DNS, ogólne rozmowy Windows-box i kilka innych rodzajów ruchu.
Zwróć także uwagę na to oświadczenie w często zadawanych pytaniach Google dotyczące ich protokołu QUIC
Dlaczego nie zbudowałeś zupełnie nowego protokołu zamiast korzystania z UDP? Środkowe pola w Internecie dzisiaj zwykle blokują ruch, chyba że jest to ruch TCP lub UDP
(mój nacisk)
Powodem, dla którego TCP / IP jest tak powszechnym skrótem (w przeciwieństwie do, powiedzmy, UDP / IP lub SCTP / IP), jest to, że oba protokoły zostały zaprojektowane razem, aw oryginalnym artykule Vinta Cerfa i Boba Kahna dwie koncepcje były połączone razem w jeden protokół. Wkrótce potem zostały podzielone na IP, aby zapewnić routing i TCP, aby zapewnić kontrolę przepływu, multipleksowanie, wykrywanie błędów itp. Dopiero sześć lat później wprowadzono UDP w celu zapewnienia „lekkiej” warstwy multipleksującej bez reszty narzut związany z TCP.
Mimo to TCP i IP to dwie osobne rzeczy, całkowicie i celowo niezależne. Fakt, że TCP nie wymaga IP, jest od razu widoczny, ponieważ TCP może działać bez modyfikacji zarówno na IPv4, jak i IPv6, które są dwoma zupełnie różnymi protokołami.
Przy odrobinie pracy możesz stworzyć konkurencyjny protokół IP, który służyłby tym samym celom, ale prawdopodobnie musiałby zawierać większość, jeśli nie wszystkie z tych samych funkcji, i prawdopodobnie wyglądałby podobnie do IP. Można argumentować, że rozszerzenia IP (takie jak IPSec) są w rzeczywistości alternatywnymi protokołami warstwy 3, więc proszę bardzo.
TCP i IP są jak masło zamiast chleba.
Można powiązać czegokolwiek innego, który działa zarówno z protokołem, ale te dwa są więc komplementarne to tylko pycha niezawodny sposób , aby przesyłać dane i napełnić brzuch z danych internetowych. Smaruje rurkę, aby umożliwić obsługę innych suchych produktów spożywczych i uzgadnianie danych w celu obsługi tego parowania. Ale w żadnym wypadku nie jest to wyjątkowe.
P Czy jednak nie jest możliwe zbudowanie TCP na innym protokole oprócz IP?
Tak jest to możliwe. Lubię przykłady Morse'a i Pigeon TCP bez IP.
Zawsze słyszałem, że TCP to skrót od TCP / IP
W rzeczywistości oznacza Protokół kontroli transmisji przez protokół internetowy
i mają na myśli to samo.
To nie jest poprawne
Po pierwsze, Ethernet to niskopoziomowy system sprzętowy, który kontroluje sposób działania rzeczywistych części sprzętowych.
Następnie pomyśl o IP jako systemie telefonicznym lub o znakach drogowych. Zapewnia podstawową kontrolę połączenia dwóch punktów razem.
Z drugiej strony TCP przypomina bardziej system komunikacji lub oficera kontroli ruchu, który kieruje wiadomości / samochody do właściwego punktu.
Podsumowując, protokół TCP / IP zapewnia niezawodny system przesyłania danych do i z dowolnych dwóch podłączonych urządzeń.
W Internecie, gdy chcesz wysyłać lub odbierać dane, część IP systemu to część kontrolująca nawiązywanie rzeczywistych połączeń sprzętowych za pomocą przewodów (lub fal bezprzewodowych). Część systemu TCP to oprogramowanie, które jest odpowiedzialne za pobieranie danych i ich dzielenie, wysyłanie, ponowne składanie otrzymanych danych oraz sprawdzanie danych i ponowne wysyłanie, jeśli to konieczne.
Istnieje niezliczona ilość wyjaśnień z analogiami i szczegółami technicznymi, szczególnie w formie wideo . DifferenceBetween.net ma szczególnie dobre zdanie na ten temat .
Czy jednak nie jest możliwe zbudowanie TCP na innym protokole oprócz IP?
Tak, naprawdę możesz stworzyć system alternatywny do TCP, który używa IP. Spójrz na pakiet protokołu internetowego, aby uzyskać szczegółowe informacje.
> the fact that !TCP can go over IP does not necessarily mean TCP can go over !IP Huh?
psusi stara się być sprytnym, używając „!” jako „nie operator”. Jego komentarz powinien brzmieć: „fakt, że coś, co nie jest TCP, może przejść przez IP, niekoniecznie oznacza, że TCP może przejść przez coś, co nie jest IP”. Odbywa się to w odniesieniu do ostatniego zdania twojej odpowiedzi, które pokazało istnienie „Alternate systems to TCP”. Jednak wykazanie, że istnieją alternatywy dla TCP niekoniecznie oznacza ani nie sugeruje, że istnieją alternatywy dla IP.
TCP to protokół warstwy 4. Zapewnia gwarantowany transport danych w postaci uporządkowanego strumienia z jednego procesu na komputerze do innego procesu na tym samym / innym komputerze.
IP to protokół warstwy 3. Zapewnia transport z jednego hosta do drugiego.
Tak długo, jak istnieje protokół umożliwiający przesyłanie danych między hostami, protokół TCP będzie działał.
Tak więc, TCP może być zaimplementowany na dowolnym protokole, ale, Stworzyliśmy tylko IP. IP jest proste i działa.
Nie ma potrzeby stosowania innego protokołu warstwy 3.
Projektując sieć, musisz wybrać zestaw protokołów (które są w zasadzie zestawami reguł komunikacji między komputerami) dla każdej z różnych „warstw” (które możesz sobie wyobrazić jako różne poziomy abstrakcji, które projektanci sieci lubią należy pamiętać o tworzeniu i łączeniu protokołów).
Prostsza wersja: protokoły są jak skrzynki, w których umieszczamy nasze wiadomości . Te pudełka mają różne rozmiary, a Ty umieszczasz swoją wiadomość w najmniejszym pudełku, a następnie w najmniejszym pudełku w pudełku, które jest trochę większe itp. Wybranie zestawu protokołów oznacza wybranie rodzaju pudełek, które będą używane dla każdego „ warstwa ”otaczająca wiadomość.
TCP i IP to protokoły dwóch niezależnych warstw, które zostały utworzone razem i mogą być użyteczne razem; ale bardzo dobrze może być używany z innymi protokołami. Zdarza się to dość często: możesz używać IP wraz z protokołem innym niż TCP lub TCP wraz z protokołem innym niż IP .
Powodem, dla którego TCP / IP jest tak powszechnym skrótem, jest to, że te dwa protokoły stanowiły razem podstawę Internetu i były kluczem do jej sukcesu .
(TCP i IP mają pewne funkcje, które zostały zaprojektowane specjalnie dla nich, aby działały razem, na co często narzekają purystowie, ale tak naprawdę nie uniemożliwiają połączenia ich z innymi protokołami)
Myślę, że można uruchomić TCP przez transport IPX, jeśli chcesz przejść na retro.
Czy jednak nie jest możliwe zbudowanie TCP na innym protokole oprócz IP?
Oprócz klasycznych protokołów TCP / IPv4 i TCP / IPv6 zaprojektowano kilka protokołów eksperymentalnych, na przykład:
W ramach naszych wysiłków Net100 i Probe w celu poprawy masowych transferów w szybkich sieciach o dużych opóźnieniach opracowaliśmy oprzyrządowaną i przestrajalną wersję TCP, która działa przez UDP. Transport podobny do UDP TCP służy jako zestaw testowy do eksperymentowania z kontrolkami podobnymi do TCP na poziomie aplikacji podobnym do TReno.
I iproxy: Uruchamianie usług TCP przez UDP , co jest przyjemniejsze:
iproxy składa się z serwera proxy po stronie klienta i serwera proxy po stronie serwera, który pozwala na uruchamianie dowolnych usług TCP / IP przez UDP Broadcast, Multicast lub Unicast. Pierwotnie był pomyślany jako metoda konfiguracji serwerów, którym nie przydzielono adresu IP w sieci LAN przy użyciu interfejsu sieciowego.
Widzisz więc: TCP na UDP emisji pojedynczej, a nawet TCP na UDP emisji lub multiemisji !
AFAIK tylko TCP / IPv4 i TCP / IPv6 cieszą się dużym wdrożeniem.
Odpowiedź brzmi nie! Na przykład istnieje stary RFC opisujący TCP przez IPX: http://tools.ietf.org/html/rfc1791
Dla osób z krótkimi wspomnieniami IPX był protokołem Novell Netware: http://en.wikipedia.org/wiki/Internetwork_Packet_Exchange
Istnieją już implementacje TCP oprócz różnych protokołów, które obsługują transport podstawowego datagramu. W rzeczywistości nie trzeba nawet określać informacji o routingu (TCP nie potrzebuje nawet IP do pracy, wystarczyłoby tylko łącze serila z niejawnym odbiorcą).
Więc masz TCP zaimplementowany w górnej części UDP (zaleta: używasz jednego portu po stronie „serwera” lub możesz osadzić go w istniejącym połączeniu transportującym różne multipleksowane kanały). Tylko poziom IP zapewnia routing, ale TCP go nie potrzebuje. Liczy się tylko to, że pojęcie MTU zapewnia dolna warstwa.
Dzięki temu protokół może ominąć ograniczenia translacji NAT, bez konieczności rejestrowania portu translacji UPnP dla określonego hosta. Umożliwia niezależne dostrajanie MTU i MSS, zoptymalizowane dla każdego klienta zamiast dla każdego pośredniego współdzielonego routera. Możliwe są inne protokoły routingu (w tym do dostarczania za pośrednictwem multiemisji i sieci rozgłoszeniowych). I masz wybór mechanizmów bezpieczeństwa.
Przykładem zastosowania jest Gogo6.net (który implementuje swój kanał transportowy IPv6 w sesji TCP przy użyciu ponownej implementacji TCP przez UDP v4 (działa na większości domowych routerów dostępowych, które wciąż mają tylko adres IPv4 i nie zawsze wspierają metodę UPnP ; bez potrzeby konfigurowania go przez użytkowników korzystających ze stałego numeru portu specyficznego dla aplikacji, nawet gdy nie jest uruchomiona)
Innymi przykładami jest hermetyzacja TCP przez HTTP (lub HTTPS) w wersji 1.1 z natywnym jego „strumieniowym” rozszerzeniem. Większość sieci VPN, które pozwalają na mostkowanie sieci przez Internet, zrobi to samo. Most może nawet hermetyzować wiele protokołów: Ethernet, PPP, IPv4 i IPv6 (rozszerzenie tylko lokalnej sieci LAN lub segmentu Ethernet), NetBEUI / LanMan, wykrywanie routera (w sieci zmostkowanej), w tym w trybie surowym (zezwalając na DHCPv4 lub DHCPv6) w zmostkowana sieć. HTTPS jest używany, ponieważ hermetyzacja przez HTTPS umożliwia także szyfrowanie i uwierzytelnianie w celu ustanowienia i zabezpieczenia mostu, ale nie wymaga kompleksowego uwierzytelniania / szyfrowania dla klientów i serwerów w sieci pomostowej oraz ponieważ routery są wysoce zoptymalizowane pod kątem HTTP i HTTPS.
Istnieją przykłady systemów komunikacji w wojsku wykorzystujących TCP, ale nie IP, ponieważ ścieżka komunikacyjna jest połączeniem typu szeregowego, które nie jest routowane przez routery itp. Jeśli spojrzysz na pakiet TCP, zanim zostanie on obsadzony przez pola IP, wydaje się, że nie można używać IP, jeśli Twój protokół „routingu” jest inny.