Transmission Control Protocol

Az oldal jelenlegi verzióját még nem ellenőrizték tapasztalt közreműködők, és jelentősen eltérhet a 2022. szeptember 28-án felülvizsgált verziótól ; az ellenőrzéshez 1 szerkesztés szükséges .
TCP
Név Transmission Control Protocol
Szint ( az OSI modell szerint ) Szállítás
Család TCP/IP
Leírás RFC 793 (1981. szeptember) / STD 7
Főbb megvalósítások UNIX , Linux , BSD , Windows
Bővíthetőség Lehetőségek
 Médiafájlok a Wikimedia Commons oldalon

A Transmission Control Protocol (TCP, Transmission Control Protocol) az internet egyik fő adatátviteli protokollja . Internetes adatok átvitelének kezelésére tervezték . A TCP-ben lévő csomagokat szegmenseknek nevezzük .

A protokollveremben a TCP/IP látja el az OSI modell szállítási rétegének funkcióit .

A TCP-mechanizmus egy kapcsolat-előre beállított adatfolyamot biztosít , adatvesztés esetén újra kéri az adatokat, és kiküszöböli a duplikációt, ha ugyanabból a csomagból két másolatot kap, ezáltal garantálja (az UDP -vel ellentétben ) a továbbított adatok sértetlenségét, és értesíti a küldőt az átvitel eredményeit.

A TCP-megvalósítások általában az operációs rendszer kerneleibe vannak beépítve . Vannak olyan TCP-megvalósítások, amelyek felhasználói térben futnak .

Az interneten keresztül számítógépről számítógépre történő átvitel során a TCP a legfelső szinten működik két végrendszer, például egy böngésző és egy webszerver között. A TCP egy bájtfolyam megbízható átvitelét végzi egyik folyamatból a másikba.

TCP szegmens fejléc

Fejléc szerkezete
Bit 0-3 4-6 7-15 16-31
0 Forrás Port  Célkikötő _
32 Sorozatszám (SN)
64 Nyugtázási szám (ACK SN)
96 Fejléc hossza, ( Adateltolás ) fenntartott Zászlók Ablak mérete
128 Ellenőrző összeg, ellenőrző összeg Fontossági mutató, Sürgős pont
160 Opciók (opcionális, de szinte mindig használt)
160/192+ Adat

Forrás port, célport

Ezek a 16 bites mezők portszámokat tartalmaznak  – olyan számokat, amelyeket egy speciális lista határoz meg .

A forrásport azonosítja azt az ügyfélalkalmazást, amelyről a csomagokat küldi. A válaszadatok e szám alapján kerülnek elküldésre az ügyfélnek.

A célport azonosítja azt a portot, amelyre a csomagot küldték.

Sorszám

Sorozatszám (32 bit) - bájtokban mérve, és a hasznos terhelés (payload) minden egyes átvitt bájtja 1-gyel növeli ezt az értéket.

Ha a SYN jelző be van állítva (munkamenet jön létre), akkor a mező tartalmazza a kezdeti sorszámot - ISN (Initial Sequence Number). Biztonsági okokból ez az érték véletlenszerűen jön létre, és 0 és 2 32 −1 (4294967295) között lehet. A létrehozandó munkamenet első hasznos adatbájtja ISN+1 lesz.

Ellenkező esetben, ha a SYN nincs beállítva, a csomagban továbbított első adatbájtnak ez a sorszáma van.

Mivel egy TCP adatfolyam általában hosszabb lehet, mint a mező különböző állapotainak száma, a sorszámon végzett összes műveletet modulo 2 32 kell végrehajtani . Ez gyakorlati korlátokat szab a TCP használatának. Ha a kommunikációs rendszer adatátviteli sebessége olyan, hogy az MSL (Maximum Segment Lifetime) alatt sorszám-túlcsordulás lép fel, akkor a hálózatban két azonos számú, a folyam különböző részeihez tartozó szegmens jelenhet meg, és a vevő hibás adatokat fog kapni.

Visszaigazolási szám

Nyugtázási szám (ACK SN)  (32 bit) - Ha az ACK jelző be van állítva, akkor ez a mező annak az oktettnek a sorszámát tartalmazza, amelyet ennek a szegmensnek a küldője szeretne fogadni. Ez azt jelenti, hogy az összes korábbi oktett ( ISN+1 -től ACK-1- ig) sikeresen érkezett.

Mindegyik oldal kiszámítja a saját sorszámát a továbbított adatokhoz, és külön nyugtázási számot a fogadott adatokhoz. Az egyes oldalak sorszáma megegyezik a másik oldal nyugtázási számával.

Fejléc hossza (adateltolás)

A fejléc hossza (Data offset) 4 bit, és a fejléc hosszának 32 bites szavakban mért értékét jelzi . A minimális méret 20 bájt (öt 32 bites szó ), a maximális pedig 60 bájt (tizenöt 32 bites szó ). A fejléc hossza határozza meg a hasznos teher eltolását a szegmens elejétől. Például az 1111 2 adateltolás  azt jelzi, hogy a fejléc tizenöt 32 bites szóból áll (15 sor * 32 bit soronként / 8 bit = 60 bájt).

Fenntartva

Fenntartva (3 bit) jövőbeli használatra, és nullára kell állítani.

Flags (vezérlőbitek)

Ez a mező 9 bites zászlókat tartalmaz:

Ablak mérete

A Window Size önállóan határozza meg az adatbájtok számát ( payload ), amelynek továbbítása után a küldő visszaigazolást vár a címzetttől, hogy az adatok megérkeztek. Más szóval, a csomag vevőjének van egy "ablakméret" bájt hosszúságú puffere az adatok fogadására.

Alapértelmezés szerint az ablak méretét bájtokban mérik, így 2 16 (65535) bájtra korlátozódik. A TCP Window scale opciónak köszönhetően azonban ez a méret 1 GB-ra növelhető. Az opció engedélyezéséhez mindkét félnek meg kell állapodnia erről a SYN szegmensében.

Ellenőrző összeg

Az ellenőrző összeg mező az összes 16 bites fejlécszó (beleértve a pszeudofejlécet is) és az adatok összegének 16 bites kiegészítése . Ha az ellenőrző összeget kiszámító szegmens hossza nem 16 bit többszöröse, akkor a szegmens hosszát 16 többszörösére növeljük úgy, hogy a jobb oldalon nulla kitöltőbiteket adunk hozzá. A kitöltési bitek (0) nem kerülnek elküldésre az üzenetben, és csak az ellenőrző összeg kiszámítására használják őket. Az ellenőrző összeg kiszámításakor magának az ellenőrzőösszeg mezőnek az értékét 0-nak tételezzük fel.

Sürgős mutató

16 bites pozitív eltolási érték a sorszámhoz képest ebben a szegmensben. Ez a mező a sürgős adatokat lezáró oktett sorszámát jelzi. A mező csak az URG jelzővel rendelkező csomagok esetében kerül figyelembevételre. A sávon kívüli adatokhoz használják .

Opciók

Bizonyos esetekben használható a protokoll kiterjesztésére. Néha tesztelésre használják. Jelenleg az opciók szinte mindig tartalmazzák a 2 bájt NOP (jelen esetben 0x01) és 10 bájt időbélyegeket . Az opciómező hosszát az eltolási mező értékén keresztül számíthatja ki.

A protokoll hatásmechanizmusa

Ellentétben a hagyományos alternatívával, az UDP-vel, amely azonnal elkezdheti a csomagok továbbítását, a TCP olyan kapcsolatokat hoz létre, amelyeket létre kell hozni az adatok továbbítása előtt. A TCP kapcsolat 3 szakaszra osztható:

TCP munkamenet állapotok

TCP munkamenet állapotok
ZÁRVA A csomópont kezdeti állapota. Valójában fiktív
HALLGAT A szerver csatlakozási kérelmeket vár a klienstől
SYN-SENT A kliens kérést küldött a szervernek a kapcsolat létrehozására, és válaszra vár
SZIN A szerver csatlakozási kérelmet kapott, válaszkérést küldött, és nyugtázásra vár
ALAPÍTOTT Kapcsolat létrejött, adatátvitel folyamatban
FIN-WAIT-1 Az egyik fél (nevezzük csomópont-1) úgy fejezi be a kapcsolatot, hogy elküld egy szegmenst a FIN jelzővel
ZÁR-VÁR A másik oldal (2. csomópont) egy ACK szegmens küldésével kerül ebbe az állapotba, és folytatja az egyirányú átvitelt
FIN-WAIT-2 Az 1-es csomópont ACK-t kap, folytatja az olvasást, és vár egy szegmensre a FIN jelzővel.
LAST-ACK A 2. csomópont befejezi az átvitelt, és elküld egy szegmenst a FIN jelzővel
IDŐ-VÁR Az 1-es csomópont kapott egy szegmenst FIN jelzővel, küldött egy szegmenst ACK jelzővel, és vár 2*MSL másodpercet, mielőtt véglegesen lezárta a kapcsolatot
ZÁRÓ Mindkét fél egyszerre kezdeményezte a kapcsolat bezárását: a FIN jelzővel ellátott szegmens elküldése után az 1-es csomópont is FIN szegmenst kap, ACK-t küld, és ACK szegmensre vár (a leválasztási kérelmének nyugtázása)

Kapcsolat létrehozása

A TCP-munkamenet indításának folyamata (más néven kézfogás  ) három lépésből áll.

1. A kapcsolatot létesíteni szándékozó kliens sorszámmal és SYN jelzővel ellátott szegmenst küld a szervernek.

2. Ha a kliens SYN jelzővel ellátott szegmenst kap, akkor megjegyzi a sorszámot és elküldi a szegmenst az ACK jelzővel.

3. Ha a SYN-RECEIVED állapotban lévő szerver ACK jelzővel ellátott szegmenst kap, akkor átvált az ESTABLISHED állapotba.

A folyamatot „háromirányú kézfogásnak” ( angolul  three way handshake ) nevezik, mert annak ellenére, hogy a kapcsolat létrehozásának folyamata négy szegmenssel lehetséges (SYN a szerver felé, ACK a kliens felé, SYN a kliens felé). kliens, ACK a szerver felé), a gyakorlatban három szegmenst használnak az időmegtakarítás érdekében.

Példa egy alapvető 3 lépésből álló tárgyalásra:

TCP A TCP B 1. ZÁRT HALLGATÁS 2. SYN-RECEIVED --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED 3. LÉPTETÉS <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 4. LÉPTETT --> <SEQ=101><ACK=301><CTL=ACK> --> LÉPTETÉS 5. LÉPTETÉS <-- <SEQ=301><ACK=101><CTL=ACK> <-- LÉPTETT

A 2. sorban a TCP A megkezdi a SYN szegmens küldését, amely jelzi a 100-tól kezdődő sorszámok használatát;

A 3. vonalon a TCP B egy SYN-t és egy nyugtát küld a vett SYN-ről az A-nak. A nyugtázási mezőben a TCP B látható, amely a 101-es sorszámra vár, és a 100-as SYN-számot nyugtázza;

A 4. sorban a TCP A üres szegmenssel válaszol ACK-vel a TCP B SYN szegmensére;

Az 5. vonalon a TCP B küld néhány adatot. Vegye figyelembe, hogy a szegmens nyugtázási száma az 5. sorban (ACK=101) megegyezik a 4. sorban lévő sorszámmal (SEQ=101), mivel az ACK nem foglal el sorszámteret (ha ezt megteszi, nyugtáznia kell köszönetnyilvánítás - ACK az ACK-ért).

A TCP protokollnak vannak kísérleti kiterjesztései, amelyek csökkentik a csomagok számát a kapcsolat létesítésekor, ilyen például a TCP Fast Open . Korábban volt egy T/TCP kiterjesztés is . Az átlátható adattitkosításhoz a tcpcrypt kiterjesztést javasoljuk .

Adatátvitel

Az adatcsere során a vevő a vett szegmensekben található sorszámot használja fel az eredeti sorrend visszaállítására. A vevő a nyugtázási szám mezőben való feltüntetésével értesíti az adó felet arról, hogy melyik sorszámig sikeresen vett adatot. A rendszer figyelmen kívül hagy minden olyan adatot, amely a megerősített szekvenciák tartományán belül van. Ha a vett szegmens a vártnál nagyobb sorszámot tartalmaz, akkor a szegmens adatai pufferelve lesznek, de a nyugtázott sorszám nem változik. Ha ezt követően a várt sorszámnak megfelelő szegmens érkezik, az adatsorrend automatikusan átrendeződik a szegmensekben lévő sorszámok alapján.

Annak biztosítására, hogy az adó oldal ne küldjön intenzívebben adatot, mint amennyit a vevő képes feldolgozni, a TCP folyamvezérlő eszközöket tartalmaz. Ehhez az "ablak" mezőt használják. A vevőtől az adó oldalra küldött szegmensekben az "ablak" mező a vételi puffer aktuális méretét jelzi. A küldő oldal megtartja az ablak méretét, és nem küld több adatot, mint a vevő által megadott. Ha a vevő nulla ablakméretet adott meg, akkor addig nem küldenek adatokat az adott csomópont irányába, amíg a vevő nem jelez nagyobb ablakméretet.

Egyes esetekben a küldő alkalmazás kifejezetten kérheti, hogy bizonyos sorrendig adatokat küldjenek el a fogadó alkalmazásnak anélkül, hogy azt pufferelné. Ehhez a PSH jelzőt használják. Ha a PSH jelző megtalálható a vett szegmensben, akkor a TCP implementáció az összes jelenleg pufferelt adatot visszaküldi a fogadó alkalmazásnak. A "push" kifejezést például interaktív alkalmazásokban használják. A hálózati terminálokon nincs értelme várni a felhasználói bevitelre, miután befejezték a parancs beírását. Ezért a parancsot tartalmazó utolsó szegmensnek tartalmaznia kell a PSH jelzőt, hogy a fogadó oldalon lévő alkalmazás elkezdhesse végrehajtani.

Kapcsolat megszakítása

A kapcsolat megszakítása három lépésben lehetséges:

  1. FIN jelző küldése a klienstől a szerverhez a kapcsolat befejezéséhez.
  2. A szerver ACK, FIN válaszjelzőket küld a kliensnek, hogy a kapcsolat megszakadt.
  3. Miután megkapta ezeket a jelzőket, a kliens lezárja a kapcsolatot, és ACK-t küld a szervernek, megerősítve, hogy a kapcsolat megszakadt.

Ismert problémák

Maximális szegmensméret

A TCP kifejezett maximális szegmensméretet ( MSS ) ír elő, ha a virtuális kapcsolat olyan hálózati szegmensen keresztül jön létre, ahol a maximális egységméret ( MTU ) kisebb, mint a szabványos Ethernet MTU (1500 bájt).

Az olyan alagútkezelési protokollokban, mint a GRE , IPIP és PPPoE , az alagút MTU kisebb, mint a szabványos, így a maximális méretű TCP szegmens csomaghossza nagyobb, mint az MTU. Ez töredezettséghez és a hasznos adatok átviteli sebességének csökkenéséhez vezet. Ha a töredezettség bármely csomóponton le van tiltva, akkor a felhasználó szemszögéből ez a kapcsolatok "lefagyásának" tűnik. Ebben az esetben a „lefagyás” tetszőleges időpontokban fordulhat elő, nevezetesen, amikor a küldő a megengedettnél hosszabb szegmenseket használt. A probléma megoldására az útválasztók tűzfalszabályokat használnak, amelyek hozzáadják az MSS-paramétert minden kapcsolatot kezdeményező csomaghoz, így a küldő érvényes méretű szegmenseket használ.

Az MSS az operációs rendszer beállításaival is vezérelhető.

Hibaészlelés adatátvitel közben

Bár a protokoll minden szegmensen ellenőrzőösszeg-ellenőrzést végez, a használt algoritmus gyengének minősül [1] .

Általánosságban elmondható, hogy az elosztott hálózati alkalmazások további szoftverek használatát javasolják a továbbított információ integritásának biztosítására [2] .

Protokoll támadások

A protokoll hiányosságai sikeres elméleti és gyakorlati támadásokban nyilvánulnak meg, amelyek során a támadó hozzáférhet a továbbított adatokhoz, kiadhatja magát a másik félnek, vagy nem működő állapotba hozhatja a rendszert.

Megvalósítás

Pseudo-cím

A TCP fejléc nem tartalmaz információt a feladó és a címzett címéről, így még ha a címzett portja egyezik is, nem lehet biztosan megmondani, hogy az üzenet jó helyre érkezett-e. Mivel a TCP protokoll célja az üzenetek megbízható kézbesítése, ez alapvető fontosságú. Ezt a problémát többféleképpen is meg lehetne oldani. A legkézenfekvőbb az, hogy a célcímről információt adunk a TCP fejléchez, de ez egyrészt az információk megkettőzéséhez vezet, ami csökkenti a TCP-szegmens által szállított hasznos információk arányát, másrészt sérti a címzett beágyazásának elvét. OSI modell. Ezért a protokollfejlesztők a másik utat választották, és egy további pszeudofejlécet használtak:

IPv4 TCP pszeudo fejléc

bitek 0 egy 2 3 négy 5 6 7 nyolc 9 tíz tizenegy 12 13 tizennégy tizenöt 16 17 tizennyolc 19 húsz 21 22 23 24 25 26 27 28 29 harminc 31
0-31 Feladó IP-címe (Forrás címe)
32-63 Cél IP-címe
64-95 0 0 0 0 0 0 0 0 Jegyzőkönyv TCP szegmens hossza (TCP hossz)

IPv6 TCP pszeudo fejléc

bitek 0 egy 2 3 négy 5 6 7 nyolc 9 tíz tizenegy 12 13 tizennégy tizenöt 16 17 tizennyolc 19 húsz 21 22 23 24 25 26 27 28 29 harminc 31
0-95 Feladó IP-címe (Forrás címe)
128-223 Cél IP-címe
224-255 TCP szegmens hossza (TCP hossz)
256-287 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Felső szintű protokoll (Következő fejléc)

A pszeudofejléc nem szerepel a TCP szegmensben. Az ellenőrzőösszeg kiszámítására szolgál az üzenet elküldése előtt és fogadásakor (a fogadó létrehozza a saját pszeudofejlécét a gazdagép címének, ahonnan az üzenet érkezett és a saját címének felhasználásával, majd kiszámítja az ellenőrző összeget).

Felmentés az ellenőrzőösszeg számítás alól

A TCP/IP-verem számos megvalósítása lehetőséget biztosít hardveres támogatás használatára az ellenőrzőösszeg automatikus kiszámításához a hálózati adapterben, mielőtt a hálózatra továbbítaná, vagy miután ellenőrzésre megkapta a hálózattól. Ez megszabadíthatja az operációs rendszert attól, hogy értékes processzorciklusokat veszítsen az ellenőrző összeg kiszámításakor.

Ez a szolgáltatás azt okozhatja , hogy a forgalomelemzők , amelyek rögzítik a kimenő csomagokat, mielőtt azokat elküldik a hálózati adapternek, és nincsenek tudatában az ellenőrzőösszeg számításának a hálózati adapterre delegálásának, ellenőrzőösszeg-hibát jelenthetnek a kimenő csomagokban.

Lásd még

Irodalom

Linkek

  Ugrás a Wikidata elemre  Szótárak és enciklopédiák