Tcp ip kliens szerver alkalmazás. Hálózati programozás - TCP

Kliens-szerver alkalmazás a TCP streaming socketen

A következő példában TCP-t használunk rendezett, megbízható kétirányú bájtfolyamok biztosítására. Készítsünk egy komplett alkalmazást, amely tartalmaz egy klienst és egy szervert. Először bemutatjuk, hogyan kell felépíteni egy szervert TCP streaming socketekre, majd egy kliens alkalmazást a szerverünk tesztelésére.

A következő program létrehoz egy kiszolgálót, amely fogadja a csatlakozási kéréseket az ügyfelektől. A szerver szinkronban épül fel, ezért a szál végrehajtása blokkolva van, amíg a szerver beleegyezik a klienshez való csatlakozásba. Ez az alkalmazás egy egyszerű szervert mutat be, amely válaszol az ügyfélnek. A kliens a kapcsolatot úgy fejezi be, hogy üzenetet küld a szervernek .

TCP szerver

A szerverstruktúra létrehozását az alábbi funkcionális diagram mutatja:

Íme a SocketServer.cs program teljes kódja:

// SocketServer.cs a rendszer használatával; a System.Text használatával; a System.Net használatával; a System.Net.Sockets használatával; névtér SocketServer (osztály Program (statikus void Main (string args)) (// A socket helyi végpontjának beállítása IPHostEntry ipHost = Dns.GetHostEntry ("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPointPoint (IPEndPoint) új ipEndPoint // Hozzon létre egy Tcp / Ip Socketet sListener = new Socket (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp); // Rendelje hozzá a socketet a helyi végponthoz, és figyelje a bejövő socketeket, próbálkozzon (sListener.Bind (ipEndPoint); sListener. Listen (10); // Indítsa el a kapcsolatok figyelését miközben (true) (Console.WriteLine ("Várakozás a kapcsolatra a (0) porton", ipEndPoint); // A program szünetel, bejövő kapcsolatra vár Socket-kezelő = sListener.Accept (); string data = null; // Vártuk, hogy egy kliens megpróbáljon csatlakozni hozzánk byte byte = new byte; int bytesRec = handler.Receive (bytes); data + = Encoding.UTF8.GetString (bytes) , 0, bytesRec); // Adatok megjelenítése a konzolon Console.Write ("Fogadott szöveg: "+ adat +" \ n \ n "); // Válasz küldése a kliensnek \ string reply = "Köszönjük a kérést" + data.Length.ToString () + "karakterek"; byte msg = Kódolás.UTF8.GetBytes (válasz); kezelő.Küldés (üzenet); if (data.IndexOf (" ")> -1) (Console.WriteLine (" A szerver befejezte a csatlakozást a klienshez. "); Szakadás;) handler.Shutdown (SocketShutdown.Both); handler.Close ();)) catch (Kivétel ex) ( Console.WriteLine (pl.ToString ());) végül (Console.ReadLine ();))))

Nézzük meg ennek a programnak a felépítését.

Az első lépés egy helyi végpont létrehozása a socket számára. Mielőtt megnyitna egy socketet a kapcsolatok figyeléséhez, elő kell készítenie egy helyi végpont címet. A TCP/IP szolgáltatás egyedi címét a gazdagép IP-címének és a szolgáltatás végpontját létrehozó portszámnak a kombinációja határozza meg.

A Dns osztály olyan metódusokat biztosít, amelyek információkat adnak vissza a helyi hálózaton lévő eszközök által támogatott hálózati címekről. Ha egy LAN-eszköznek egynél több hálózati címe van, a Dns osztály az összes hálózati címről információt ad vissza, és az alkalmazásnak ki kell választania egy megfelelő címet a tömbből a kiszolgáláshoz.

Hozzon létre egy IPEndPointot a szerver számára a Dns.Resolve () metódusból származó első gazdagép IP-címének a portszámmal való kombinálásával:

IPHostEntry ipHost = Dns.GetHostEntry ("localhost"); IP-cím ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint = új IPendPoint (ipAddr, 11000);

Itt az IPEndPoint osztály az 11000-es porton lévő localhostot képviseli. Ezután hozzon létre egy adatfolyam socketet a Socket osztály új példányával. A kapcsolatok figyelésére beállított helyi végponttal egy socket hozható létre:

Socket sListener = új Socket (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp);

Felsorolás CímCsalád meghatározza azokat a címzési sémákat, amelyeket a Socket osztály egy példánya használhat egy cím feloldására.

A paraméterben SocketType vannak TCP és UDP socketek. Ebben többek között a következő értékeket határozhatja meg:

Dgram

Támogatja a datagramokat. A Dgram értékhez meg kell adni az Udp protokolltípust és az InterNetwork-t a címcsalád paraméterében.

Nyers

Támogatja az alapul szolgáló szállítási protokollhoz való hozzáférést.

Folyam

Támogatja a streaming aljzatokat. A Stream értékhez meg kell adni a Tcp protokolltípust.

A harmadik és egyben utolsó paraméter határozza meg a foglalathoz szükséges protokoll típusát. A paraméterben Protokolltípus a következő legfontosabb értékeket adhatja meg - Tcp, Udp, Ip, Raw.

A következő lépés a socket hozzárendelése a metódus segítségével Kötés ()... Amikor egy socketet megnyit a konstruktor, nem ad hozzá nevet, csak egy leíró van lefoglalva. A Bind () metódus meghívása a szerver sockethez való név hozzárendelésére szolgál. Ahhoz, hogy a kliens socket azonosítani tudja a TCP streaming socketet, a szerverprogramnak el kell neveznie a socketjét:

SListener.Bind (ipEndPoint);

A Bind () metódus a socketet a helyi végponthoz köti. Meg kell hívnia a Bind () metódust, mielőtt megpróbálná meghívni a Listen () és Accept () metódusokat.

Most, miután létrehozott egy socketet, és hozzárendelt egy nevet, meghallgathatja a bejövő üzeneteket a módszerrel Hallgat ()... Figyelő állapotban a socket megvárja a bejövő csatlakozási kísérleteket:

SListener.Listen (10);

A paraméter határozza meg hátralék amely megadja a függőben lévő kapcsolatok maximális számát a sorban. Az adott kódban a paraméterérték legfeljebb tíz kapcsolat halmozását teszi lehetővé a sorban.

Hallgató állapotban készen kell állni arra, hogy hozzájáruljon a klienssel való kapcsolathoz, amelyhez a módszert használják Elfogad ()... Ezzel a módszerrel létrejön egy ügyfélkapcsolat, és befejeződik az ügyfél/kiszolgáló név-összerendelése. Az Accept () metódus blokkolja a hívó szálát, amíg a kapcsolat meg nem érkezik.

Az Accept () metódus lekéri az első kapcsolódási kérelmet a függőben lévő kérelmek sorából, és új socketet hoz létre a kezeléséhez. Bár az új socket létrejön, az eredeti socket továbbra is figyel, és többszálas lehet, hogy több csatlakozási kérést fogadjon az ügyfelektől. Egyetlen szerveralkalmazás sem zárhatja be a lehallgató socketet. Továbbra is működnie kell az Accept metódussal létrehozott socketekkel a bejövő klienskérések kezelésére.

While (true) (Console.WriteLine ("Várakozás a kapcsolatra a (0) porton", ipEndPoint); // A program szünetel, bejövő kapcsolatra vár Socket handler = sListener.Accept ();

Miután a kliens és a szerver kapcsolatot létesített egymás között, üzeneteket küldhet és fogadhat a metódusok használatával Küld ()és Fogadás () Aljzat osztály.

A Send () metódus a kimenő adatokat arra a socketre írja, amelyhez a kapcsolat létrejön. A Receive () metódus beolvassa a bejövő adatokat egy adatfolyam-foglalatba. TCP-alapú rendszereken a Send () és a Fogadás () metódusok végrehajtása előtt kapcsolatot kell létesíteni a socketek között. A két kölcsönhatásban lévő entitás közötti pontos protokollt előre meg kell határozni, hogy a kliens és a szerver alkalmazások ne blokkolják egymást, nem tudva, kinek kell először elküldenie az adatait.

Amikor az adatcsere a szerver és a kliens között befejeződött, a kapcsolatot a metódusokkal kell lezárni Leállitás ()és Bezárás ():

Handler.Shutdown (SocketShutdown.Both); kezelő.Bezárás ();

A SocketShutdown egy felsorolás, amely három leállítandó értéket tartalmaz: Mindkét- leállítja az adatátvitelt és -fogadást az aljzaton keresztül, Kap- leállítja az adatok fogadását az aljzaton, és Küld- leállítja az adatátvitelt az aljzaton keresztül.

A socket bezárul a Close () metódus meghívásakor, amely a socket Connected tulajdonságát is false értékre állítja.

Kliens TCP-n

Az ügyfélalkalmazások létrehozásához használt funkciók többé-kevésbé hasonlítanak egy szerveralkalmazásra. A szerverhez hasonlóan a végpont meghatározására, a socket példányosítására, az adatok küldésére és fogadására, valamint a socket bezárására is ugyanazokat a módszereket használják.

A TCP természetesen integrálódik a kliens/szerver környezetbe (lásd: 10.1. ábra). Szerver alkalmazás hallgat(meghallgatni) a bejövő kapcsolódási kéréseket. Például a WWW, a fájlátviteli vagy a terminálhozzáférési szolgáltatások figyelik az ügyfelek kéréseit. A TCP-ben a kommunikációt a megfelelő szubrutinok kezdeményezik, amelyek kezdeményezik a kapcsolatot a szerverrel (lásd a 21. fejezetet a socket programozási felületről).

Rizs. 10.1. A kliens hívja a szervert.

A valóságban a kliens lehet egy másik szerver is. Például a levelezőszerverek kapcsolódhatnak másokhoz levelezőszervereküzenetek továbbításához Email számítógépek között.

10.2 TCP-fogalmak

Milyen formában küldjenek adatokat az alkalmazások TCP-n keresztül? Hogyan továbbítja a TCP az adatokat IP-re? Hogyan azonosítja a küldő és fogadó TCP protokoll az alkalmazások és a megvalósításhoz szükséges adatelemek közötti kapcsolatot? Mindezekre a kérdésekre választ kapunk a következő szakaszokban, amelyek az alapvető TCP-fogalmakat ismertetik.

10.2.1 Bemeneti és kimeneti adatfolyamok

Fogalmi a kapcsolati modell feltételezi, hogy az alkalmazás adatfolyamot küld a peer alkalmazásnak. Ugyanakkor képes adatfolyamot fogadni kapcsolati partnerétől. A TCP biztosítja full duplex(full duplex) üzemmód, amelyben egyidejűleg két patak adatok (lásd 10.2. ábra).

Rizs. 10.2. Az alkalmazások adatfolyamokat cserélnek.

10.2.2 Szegmensek

A TCP képes az alkalmazásból kilépő adatfolyamot datagramokban való elhelyezésre alkalmas formává alakítani. Hogyan?

Az alkalmazás TCP-ben továbbítja az adatokat, és ez a protokoll helyezi be kimeneti puffer(puffer küldése). Ezután a TCP kivágja az adatdarabokat a pufferből, és fejléc hozzáadásával elküldi azokat (ebben az esetben szegmensek- szegmens). ábrán. 10.3 megmutatja, hogy az adatok hogyan kimeneti puffer A TCP szegmensekre van csomagolva. A TCP külön datagramként továbbítja a szegmenst az IP-nek, hogy továbbítsa azt. Az adatok megfelelő hosszúságú darabokba való becsomagolása biztosítja az adatok hatékony küldését, így a TCP megvárja, amíg a megfelelő adatmennyiség megjelenik a kimeneti pufferben, mielőtt létrehozna egy szegmenst.

Rizs. 10.3 TCP szegmens létrehozása

10.2.3 Kidobás

Azonban nagy mennyiségű adatot gyakran lehetetlen alkalmazni a valós alkalmazásokban. Például amikor egy végfelhasználói kliensprogram interaktív munkamenetet kezdeményez egy távoli szerverrel, akkor a felhasználó csak parancsokat ír be (ezt követően nyomja meg a Visszatérés).

A felhasználó kliensprogramjának szüksége van a TCP-re, hogy tudjon az adatok távoli gazdagépnek történő elküldéséről, és ezt azonnal meg is tegye. Ebben az esetben használja kilökődés(nyom).

Ha egy interaktív munkamenetben nézzük a műveleteket, sok olyan szegmenst találhatunk, ahol kevés adat van, sőt, szinte minden adatszegmensben ütések találhatók. A push-t azonban nem szabad fájlátvitel során alkalmazni (kivéve a legutolsó szegmenst), és a TCP képes lesz a leghatékonyabban szegmensekbe csomagolni az adatokat.

10.2.4 Sürgős adatok

Az alkalmazás-továbbítási modell egy rendezett bájtfolyam alkalmazását feltételezi, amely eljut a célhoz. Ismét hivatkozva az interaktív munkamenet példájára, tegyük fel, hogy a felhasználó megnyomta a billentyűt Figyelem(figyelem) ill szünet(megszakít). A távoli alkalmazásnak képesnek kell lennie arra, hogy kihagyja a zavaró bájtokat, és a lehető leghamarabb válaszoljon a billentyűleütésre.

Gépezet sürgős adatok(sürgős adat) speciális információkat jelöl a szegmensben mint sürgős. Ezzel a TCP tájékoztatja a társát, hogy a szegmens sürgős adatokat tartalmaz, és jelezni tudja, hol van. A partnernek ezt az információt a lehető leghamarabb továbbítania kell a célpályázatnak.

10.2.5 Alkalmazási portok

Az ügyfélnek azonosítania kell azt a szolgáltatást, amelyhez hozzá szeretne férni. Ez a gazdagép szolgáltatási IP-címének és TCP-portszámának megadásával történik. Az UDP-hez hasonlóan a TCP-portok száma 0-tól 65535-ig terjed. A 0-tól 1023-ig terjedő tartományba eső portokat jól ismertnek nevezzük, és szabványos szolgáltatások elérésére használják.

A 10.1. táblázatban számos példa látható a jól ismert portokra és a hozzájuk tartozó alkalmazásokra. Szolgáltatások Eldobni(9-es port) és chargen(19-es port) az UDP-ből már ismert szolgáltatások TCP-verziói. Ne feledje, hogy a TCP 9-es port forgalma teljesen el van szigetelve a 9-es UDP-port forgalmától.

10.1. táblázat Általánosan ismert TCP-portok és a hozzájuk tartozó alkalmazások

Kikötő	Alkalmazás	Leírás
9	Eldobni	Minden bejövő adat törlése
19	Chargen	Szimbólum generátor. Karakterfolyam csere
20	FTP-adatok	FTP adattovábbítási port
21	FTP	Port az FTP beszélgetéshez
23	TELNET	Port távoli Telnet regisztrációhoz
25	SMTP	SMTP port
110	POP3	Levelezési szolgáltatás személyi számítógépekhez
119	NNTP	Hozzáférés az online hírekhez

Mi a helyzet az ügyfelek által használt portokkal? Ritka esetekben az ügyfél nem egy jól ismert porton keresztül működik. De ilyen helyzetekben, amikor kapcsolatot akar nyitni, gyakran megkéri az operációs rendszert, hogy rendeljen hozzá egy nem használt és lefoglalt portot. A kapcsolat végén a kliens köteles ezt a portot visszaadni, ami után a portot egy másik kliens újra felhasználhatja. Mivel a nem fenntartott számkészletben több mint 63 000 TCP-port található, az ügyfélportok korlátai figyelmen kívül hagyhatók.

10.2.6 socket címek

Mint már tudjuk, az IP-cím és a kommunikációs port kombinációját hívják foglalat. A TCP-kapcsolatot teljes mértékben a kapcsolat mindkét végén található socket-cím azonosítja. ábrán. A 10.4 egy kapcsolatot mutat be a socketben lévő kliens (128.36.1.24, port = 3358) és a kiszolgáló között a socketben (130.42.88.22, port = 21).

Rizs. 10.4. Socket címek

Minden datagram fejléc tartalmazza a forrás és a cél IP-címét. Később látni fogjuk, hogy a forrás és a cél port száma a TCP szegmens fejlécében van feltüntetve.

Jellemzően egy szerver képes több kliens egyidejű kezelésére. Egy szerver egyedi socket címei egyszerre vannak hozzárendelve az összes klienshez (lásd: 10.5. ábra).

Rizs. 10.5. Több kliens csatlakozik a szerver socket címéhez

Mivel a datagramok IP-címek és portok által azonosított TCP-kapcsolati szegmenst tartalmaznak, a szerver nagyon könnyen nyomon követheti több ügyfélkapcsolatot.

10.3 TCP megbízhatósági mechanizmus

Ebben a részben megvizsgáljuk azt a TCP-mechanizmust, amelyet az adatok megbízható kézbesítésére használnak, miközben fenntartják a továbbítási sorrendet, és elkerülik az adatvesztést vagy a duplikációt.

10.3.1 Számozás és megerősítés

A TCP számozást és nyugtázást (ACK) használ a megbízható adatátvitel érdekében. A TCP számozási séma kissé szokatlan: minden egyes kapcsolat-továbbítás oktett sorszámmal rendelkezőnek tekintendő. A TCP szegmens fejléce sorszámot tartalmaz ennek a szegmensnek az első adatoktettje.

Az átvevő köteles visszaigazolni az adatok átvételét. Ha nem érkezik ACK az időtúllépési időn belül, az adatok újraküldésre kerülnek. Ezt a módszert hívják pozitív nyugtázás relével(pozitív nyugtázás újraküldéssel).

A vevő TCP szorosan figyeli a bejövő sorszámokat, hogy biztosítsa az adatok következetes vételét, és hogy ne legyenek hiányzó részek. Mivel az ACK-k véletlenszerűen elveszhetnek vagy késhetnek, duplikált szegmensek érkezhetnek a címzetthez. A sorszámok lehetővé teszik a duplikált adatok azonosítását, amelyeket aztán eldobnak.

ábrán. A 10.6 egyszerűsített áttekintést nyújt a TCP időtúllépéséről és az újraküldésről.

Rizs. 10.6. Időtúllépés és újraküldés TCP-ben

10.3.2 Port, Sequence és ACK mezők a TCP fejlécben

ábrán látható módon. 10.7, a TCP-fejléc első néhány mezője helyet biztosít a forrás- és célportoknak, a beágyazott adatok első bájtjának sorszámának, valamint a sorszámmal megegyező ACK-nek. következő bájt várható a másik végén. Más szóval, ha a TCP a 30. bájtig minden bájtot megkap a társától, akkor ennek a mezőnek az értéke 31 lesz, jelezve a továbbítandó szegmenst.

Rizs. 10.7. Kezdeti értékek a TCP fejléc mezőiben

Egy apró részletet meg kell jegyezni. Tegyük fel, hogy a TCP 1 és 50 vagy több bájtot küldött, nincs küldendő adat. Ha partnertől adat érkezik, a TCP köteles visszaigazolni az átvételt, amelyhez adatkapcsolat nélküli fejlécet küld. Ez a fejléc természetesen tartalmazza az ACK értéket. A sorozatmező az 51-es értéket tartalmazza, azaz. a következő bájt száma szándékában áll küldje el a TCP-t. Amikor a TCP elküldi a következő adatot, az új TCP-fejléc értéke is 51 lesz a sorozatmezőben.

10.4 Kapcsolat létrehozása

Hogyan kapcsolódik egymáshoz a két alkalmazás? Kommunikáció előtt mindegyik meghív egy szubrutint, hogy létrehozzon egy memóriablokkot, amely a kapcsolat TCP és IP paramétereinek tárolására szolgál, például socket címek, aktuális sorszám, élettartam kezdeti értéke stb.

A szerveralkalmazás megvárja egy kliens megjelenését, amely a szerverhez való hozzáféréshez kérést ad ki összetett(csatlakozás) azonosítja a szerver IP-címét és portját.

Van egy technikai sajátosság. Minden oldal nem eggyel kezdi az egyes bájtok számozását, hanem ezzel véletlenszerű sorszám(Az alábbiakban megtudjuk, miért történik ez). Az eredeti specifikáció azt tanácsolja: generáljon egy kezdeti sorszámot egy 32 bites külső időzítő alapján, amely körülbelül 4 μs-ként növekszik.

10.4.1 Csatlakozási parancsfájl

A csatlakozási eljárást gyakran háromirányú kézfogásnak nevezik, mivel a kapcsolat létrehozásához három üzenetet cserélnek – SYN, SYN és ACK.

A kapcsolat létrehozása során a partnerek három fontos információt cserélnek ki:

1. Az adatok fogadásához szükséges pufferterület mennyisége

2. A bejövő szegmensben szállított adatok maximális mennyisége

3. A kimenő adatokhoz használt kezdő sorszám

Vegye figyelembe, hogy mindkét oldal az 1. és 2. műveletet alkalmazza a jelzésre a másik fél működési korlátai. Egy személyi számítógépnek lehet kis vételi puffere, a szuperszámítógépnek pedig hatalmas puffere lehet. A memória szerkezete személyi számítógép 1 KB-ra tudja korlátozni a bejövő adatdarabokat, és a szuperszámítógépet nagy szegmensek vezérlik.

A TCP / IP méretezhetőség fontos tulajdonsága, hogy a másik fél hogyan küldje el az adatokat.

ábrán. A 10.8 példát mutat egy kapcsolati parancsfájlra. Nagyon egyszerű kezdő sorszámok jelennek meg, hogy ne terheljék túl a rajzot. Vegye figyelembe, hogy ezen az ábrán a kliens nagyobb szegmenseket tud fogadni, mint a szerver.

Rizs. 10.8. Kapcsolat létrehozása

A következő műveleteket hajtják végre:

1. A szerver inicializálva van, és készen áll a kliensekhez való csatlakozásra (ezt az állapotot passzív nyitottnak nevezzük).

2. A kliens megkéri a TCP-t, hogy nyisson kapcsolatot a szerverrel a megadott IP-címen és porton (ezt az állapotot nevezzük aktív nyitottnak).

3. A kliens TCP megkapja a kezdeti sorszámot (ebben a példában - 1000), és elküldi szinkron szegmens(szegmens szinkronizálása - SYN). Ez a szegmens tartalmazza a sorszámot, a fogadási ablak méretét (4K) és a kliens által fogadható legnagyobb szegmenst (1460 bájt).

4. Amikor egy SYN érkezik, a szerver TCP fogadja enyém kezdő sorszám (3000). Egy SYN szegmenst küld, amely tartalmazza a kezdő sorszámot (3000), az ACK 1001-et (ami azt jelenti, hogy a kliens által küldött első bájt számozása 1001), a fogadási ablak méretét (4K), valamint a szerver által fogadható legnagyobb szegmenst (1024 bájt). ).

5. A kliens TCP, miután SYN / ACK üzenetet kapott a szervertől, visszaküldi az ACK 3001-et (a szerver által küldött adatok első bájtja 3001 legyen).

6. A kliens TCP utasítja alkalmazását, hogy nyissa meg a kapcsolatot.

7. A szerver TCP, miután ACK üzenetet kapott a kliens TCP-től, értesíti alkalmazását a kapcsolat megnyitásáról.

A kliens és a szerver kihirdetik a fogadott adatokra vonatkozó szabályaikat, szinkronizálják sorszámukat és készen állnak az adatcserére. A TCP specifikáció egy másik (nem túl sikeres) forgatókönyvet is lehetővé tesz, amikor a peer alkalmazások egyidejűleg aktívan megnyitják egymást.

10.4.2 IP-paraméterértékek beállítása

Az alkalmazás csatlakozási kérelme paramétereket is megadhat azon IP-datagramokhoz, amelyek az adott kapcsolat adatait hordozzák. Ha nincs megadva konkrét paraméterérték, akkor a rendszer az alapértelmezett értéket használja.

Például egy alkalmazás kiválaszthatja a kívánt értéket az IP-prioritáshoz vagy a szolgáltatás típusához. Mivel a kapcsolódó felek mindegyike önállóan állítja be a saját prioritását és szolgáltatástípusát, elméletileg ezek az értékek eltérőek lehetnek az adatáramlás különböző irányaiban. Általános szabály, hogy a gyakorlatban ugyanazokat az értékeket használják minden csereirányhoz.

Ha egy alkalmazás biztonsági beállításokat használ kormányzati vagy katonai ügynökségek számára, akkor minden kapcsolati végpontnak ugyanazt a biztonsági szintet kell használnia, különben a kapcsolat nem jön létre.

10.5 Adatátvitel

Az adatátvitel a kapcsolat létrehozásának három lépéses megerősítése után kezdődik (lásd 10.9. ábra). A TCP-szabvány lehetővé teszi a normál adatok felvételét a nyugtázási szegmensekbe, de azok nem kerülnek az alkalmazásba, amíg a kapcsolat létre nem jön. A számozás megkönnyítése érdekében 1000 bájtos üzeneteket használnak. Minden TCP-fejléc szegmensnek van egy ACK mezője, amely azonosítja annak a bájtnak a sorszámát, amelyet a kapcsolat peer-től várhatóan fogadni kell..

Rizs. 10.9. Egyszerű adatáramlás és ACK

A kliens által küldött első szegmens 1001-től 2000-ig terjedő bájtokat tartalmaz. ACK mezőjének 3001-es értéket kell tartalmaznia, amely a szervertől várhatóan fogadni kívánt bájt sorszámát jelzi.

A szerver egy 1000 bájtnyi adatot tartalmazó szegmenssel válaszol a kliensnek (3001-től kezdve). A TCP fejléc ACK mezője azt jelzi, hogy az 1001-től 2000-ig terjedő bájtok már sikeresen vételre kerültek, így a következő várt szegmens sorszámának 2001-nek kell lennie.

Az ügyfél ezután 2001, 3001 és 4001 bájtokkal kezdődő szegmenseket küld el ebben a sorrendben. Vegye figyelembe, hogy a kliens nem vár ACK-t minden egyes elküldött szegmens után. Az adatokat addig küldjük a partnernek, amíg annak puffertere meg nem telik (lent látni fogjuk, hogy a címzett nagyon pontosan tudja jelezni a neki küldött adatmennyiséget).

A szerver sávszélességet takarít meg egyetlen ACK használatával, amely jelzi az összes szegmens sikeres továbbítását.

ábrán. A 10.10 mutatja az adatátvitelt az első szegmens elvesztésekor. Amikor az időkorlát lejár, a szegmens újraküldésre kerül. Vegye figyelembe, hogy az elveszett szegmens fogadásakor a vevő egy ACK-t küld, megerősítve, hogy mindkét szegmens elküldésre került.

Rizs. 10.10. Adatvesztés és újraküldés

10.6 Kapcsolat lezárása

A kapcsolat normál megszakítása ugyanazzal a hármas kézfogási eljárással történik, mint a kapcsolat megnyitásakor. Mindegyik fél megkezdheti a kapcsolat lezárását a következő forgatókönyv szerint:

V:

B:"Jó".

V:– Én is befejeztem a munkát.

V:"Jó".

A következő forgatókönyv szintén elfogadható (bár rendkívül ritkán használják):

V:"Befejeztem. Nincs több elküldendő adat."

V:"Jó. Van azonban néhány adat..."

V:– Én is befejeztem a munkát.

V:"Jó".

Az alábbi példában a kapcsolat bezárja a kiszolgálót, ahogy ez gyakran előfordul a kliens/szerver kommunikációnál. Ebben az esetben, miután a felhasználó belép a munkamenetbe telnet A kijelentkezési parancsok a szerver kérést kezdeményez a kapcsolat lezárására. ábrán látható helyzetben. 10.11, a következő műveleteket hajtják végre:

1. A szerveren lévő alkalmazás utasítja a TCP-t, hogy zárja be a kapcsolatot.

2. A TCP-szerver végső szegmenst (FIN) küld, tájékoztatva partnerét, hogy nincs több küldendő adat.

3. Az ügyfél TCP-je ACK-t küld a FIN szegmensre.

4. A kliens TCP-je közli az alkalmazással, hogy a szerver meg akarja zárni a kapcsolatot.

5. Az ügyfélalkalmazás utasítja a TCP-jét, hogy zárja be a kapcsolatot.

6. Az ügyfél TCP-je FIN üzenetet küld.

7. A TCP szerver megkapja a FIN-t a klienstől, és ACK üzenettel válaszol.

8. A TCP-kiszolgáló utasítja alkalmazását a kapcsolat megszakítására.

Rizs. 10.11. Kapcsolat lezárása

Mindkét oldal elkezdheti a zárást egyszerre. Ebben az esetben a kapcsolat normál lezárása azután fejeződik be, hogy minden partner ACK üzenetet küld.

10.6.1 Hirtelen felmondás

Mindegyik fél kérheti a kapcsolat hirtelen megszakítását. Ez elfogadható, ha egy alkalmazás meg akarja szakítani a kapcsolatot, vagy ha a TCP komoly kommunikációs problémába ütközik, amelyet önmagában nem tud megoldani. A hirtelen leállítást egy vagy több alaphelyzetbe állítási üzenet elküldésével kell kérni a peer-nek, amint azt a TCP-fejlécben egy adott jelző jelzi.

10.7 Áramlásszabályozás

A TCP-vevőt betölti a bejövő adatfolyam, és meghatározza, hogy mennyi információt tud fogadni. Ez a korlátozás a TCP-küldőt érinti. Az alábbi magyarázat erre a mechanizmusra koncepcionális, és a fejlesztők különféle módokon valósíthatják meg termékeikben.

A kapcsolat felállítása során minden partner helyet foglal a kapcsolat bemeneti pufferének, és erről értesíti a másik oldalt. A pufferméretet általában a maximális szegmensméretek egész számában fejezik ki.

Az adatfolyam belép a bemeneti pufferbe, és ott tárolódik, mielőtt elküldené az alkalmazásnak (a TCP port határozza meg). ábrán. A 10.12 olyan bemeneti puffert mutat, amely 4 KB befogadására képes.

Rizs. 10.12. A bemeneti puffer vételi ablaka

A pufferterület megtelik az adatok megérkezésével. Amikor a fogadó alkalmazás adatokat kér le a pufferből, a felszabadult terület elérhetővé válik az új bejövő adatok számára.

10.7.1 Fogadási ablak

Fogadó ablak(fogadási ablak) - a bemeneti pufferben lévő tetszőleges hely, amelyet még nem foglaltak el adatok. Az adatok a bemeneti pufferben maradnak mindaddig, amíg a célalkalmazás fel nem használja. Miért nem veszi fel az alkalmazás azonnal az adatokat?

Egy egyszerű forgatókönyv segít megválaszolni ezt a kérdést. Tegyük fel, hogy egy ügyfél feltöltött egy fájlt egy FTP-kiszolgálóra, amely egy nagyon elfoglalt többfelhasználós számítógépen fut. Az FTP programnak ezután ki kell olvasnia az adatokat a pufferből, és ki kell írnia a lemezre. Amikor a szerver lemez I/O műveleteket hajt végre, a program megvárja, hogy ezek a műveletek befejeződjenek. Ekkor egy másik program indulhat el (például ütemterv szerint), és míg az FTP program újraindul, a következő adatok már megérkeznek a pufferbe.

A fogadási ablak az utolsó nyugtázott bájttól a puffer végéig bővül. ábrán. 10.12 először a teljes puffer elérhető, és így egy 4 KB-os fogadási ablak áll rendelkezésre. Az első KB megérkezésekor a fogadási ablak 3 KB-ra csökken (az egyszerűség kedvéért feltételezzük, hogy minden szegmens 1 KB, bár a gyakorlatban ez az érték az alkalmazás igényeitől függően változik). A következő két 1 KB-os szegmens érkezésével a fogadási ablak 1 KB-ra csökken.

Minden, a vevő által küldött ACK információt tartalmaz a vételi ablak aktuális állapotáról, attól függően, hogy a forrásból érkező adatáramlást melyik szabályozza.

A bemeneti puffer méretét többnyire a kapcsolat indulásakor állítják be, bár a TCP szabvány nem írja elő, hogyan kell kezelni ezt a puffert. A bemeneti puffer növekedhet vagy csökkenhet, hogy visszajelzést adjon a küldőnek.

Mi történik, ha egy bejövő szegmens elhelyezhető a fogadó ablakban, de nem érkezett meg rendben? Általában feltételezik, hogy minden implementáció tárolja a bejövő adatokat a vételi ablakban, és csak több szegmensből álló teljes, összefüggő blokkra küld visszaigazolást (ACK). Ez a helyes módszer, mert különben a nem megfelelő adatok elvetése jelentősen rontja a teljesítményt.

10.7.2 Beküldési ablak

Az adatokat továbbító rendszernek két jellemzőt kell nyomon követnie: mennyi adatot már elküldtek és nyugtáztak, valamint a címzett fogadóablakának aktuális méretét. Aktív feladási tér(küldési szóköz) az első nyugtázatlan oktetttől az aktuális fogadóablak bal oldalára bővül. Rész ablak használva küldeni, azt jelzi, hogy mennyi további adatot lehet továbbítani a partnernek.

A fogadóablak kezdeti sorszáma és kezdeti mérete a kapcsolat beállítása során kerül beállításra. Rizs. A 10.13 az adatátviteli mechanizmus néhány jellemzőjét szemlélteti.

1. A feladó egy 4 KB-os küldési ablakkal indul.

2. A feladó 1 KB-ot küld. Ezeknek az adatoknak egy másolata mindaddig megőrződik, amíg egy nyugtát (ACK) nem kap, mivel előfordulhat, hogy újra el kell küldeni.

3. Megérkezik az első KB ACK üzenet, és elküldésre kerül a következő 2 KB adat. Az eredmény a harmadik részben látható az ábra tetejétől. 10.13. A 2 KB tárolása folytatódik.

4. Végül egy ACK érkezik az összes továbbított adatra (vagyis a vevő által vett összes adatra). Az ACK visszaállítja a küldési ablak méretét 4K-ra.

Rizs. 10.13. Küldési ablak

Számos érdekes tulajdonságot kell kiemelni:

S A küldő nem vár ACK-t minden egyes elküldött adatszegmensre. Az egyetlen átviteli korlátozás a fogadási ablak mérete (például a küldő csak 4K egybájtos szegmenseket küldhet).

S Tegyük fel, hogy a feladó több nagyon rövid szegmensben küld adatokat (például 80 bájt). Ebben az esetben az adatok újraformázhatók a hatékonyabb átvitel érdekében (például egyetlen szegmensbe).

10.8 TCP fejléc

ábrán. A 10.14 a szegmens formátumát mutatja (TCP fejléc és adatok). A fejléc a forrás- és célport-azonosítókkal kezdődik. Következő következő mező sorozatszám(sorszám) azt a pozíciót jelzi a kimenő adatfolyamban, amelyet ez a szegmens elfoglal. Terület ACK(nyugtázás) információkat tartalmaz a bemeneti adatfolyamban várható következő szegmensről.

Rizs. 10.14. TCP szegmens

Hat zászló van:

Terület adat torzítás(Data Offset) a TCP fejléc méretét tartalmazza 32 bites szavakban. A TCP-fejlécnek 32 bites határon kell végződnie.

10.8.1 Maximális szegmensméret opció

Paraméter "maximális szegmensméret"(maximális szegmensméret – MSS) a rendszer által fogadható és feldolgozható legnagyobb adatcsomag hirdetésére szolgál. A cím azonban kissé pontatlan. Általában TCP-ben szegmens fejléc plusz adatként kezeljük. de maximális szegmensméret ként meghatározott:

A legnagyobb fogadható datagram a 40

Más szóval, az MSS tükrözi a legjobbat hasznos teher a vevőben 20 bájt hosszúságú TCP és IP fejlécekkel. Ha van ilyen Extra lehetőségek, hosszukat le kell vonni a teljes méretből. Ezért egy szegmensben elküldhető adatmennyiség a következőképpen van meghatározva:

MSS deklarált érték + 40 - (TCP és IP fejléchosszak összege)

A partnerek általában az MSS-értékeket cserélik ki a kezdeti SYN-üzenetekben, amikor a kapcsolat megnyílik. Ha a rendszer nem hirdet maximális szegmensméretet, akkor az alapértelmezett 536 bájt értéket használja.

A maximális szegmens méretét egy 2 bájtos preambulum kódolja, amelyet egy 2 bájtos érték követ, azaz. a legnagyobb érték 2 16 -1 (65 535 bájt) lesz.

Az MSS szigorú korlátot szab a TCP-nek küldött adatoknak: a vevő nem tud nagy értékeket feldolgozni. A feladó azonban szegmenseket használ kisebb, mert a kapcsolathoz az útvonal mentén az MTU is meg van határozva.

10.8.2 Fejlécmezők használata csatlakozási kérelemben

A kapcsolat megnyitására küldött első szegmens SYN jelzője 1 és ACK jelzője 0. A kezdeti SYN az egyetlen egy szegmens, amelynek ACK mezője 0. Vegye figyelembe, hogy a biztonság ezt a szolgáltatást használja a TCP-munkamenetre vonatkozó bejövő kérések észlelésére.

Terület sorozatszám tartalmaz kezdő sorszám(kezdeti sorszám), mező ablak - kezdeti méret fogadóablak. Az egyetlen jelenleg definiált TCP-paraméter az a maximális szegmensméret (ha nincs megadva, az alapértelmezett érték 536 bájt), amelyet a TCP fogadni vár. Ez az érték 32 bit hosszú, és általában jelen van a csatlakozási kérelemben a mezőben lehetőségek(Választási lehetőség). Az MSS-értéket tartalmazó TCP-fejléc 24 bájt hosszú.

10.8.3 Fejléc mezők használata a kapcsolati válaszban

A kapcsolódási kérelemre adott engedélyezési válasz esetén mindkét jelző (SYN és ACK) 1-gyel egyenlő. A válaszoló rendszer a megfelelő mezőben jelzi a kezdeti sorszámot, és a mezőben a fogadási ablak méretét. Ablak. Maximális méret A címzett által használni kívánt szegmens általában a csatlakozási kérelemre adott válaszban található (a lehetőségek). Ez az érték eltérhet a csatlakozást kérő fél értékétől, pl. két különböző érték használható.

A csatlakozási kérés elutasítható egy 1-es értékű reset flag (RST) megadásával a válaszban.

10.8.4 A kezdő sorszám kiválasztása

A TCP specifikáció feltételezi, hogy a kapcsolat létrehozása során mindegyik fél választ kezdő sorszám(a 32 bites belső időzítő aktuális értékén). Hogyan történik ez?

Képzeld el, mi történik, ha a rendszer összeomlik. Tegyük fel, hogy a felhasználó közvetlenül az összeomlás előtt nyitott kapcsolatot, és kis mennyiségű adatot küldött. A helyreállítás után a rendszer már nem emlékszik semmire, ami az összeomlás előtt történt, beleértve a már futó kapcsolatokat és a hozzárendelt portszámokat. A felhasználó újra létrehozza a kapcsolatot. A portszámok nem egyeznek az eredeti hozzárendelésekkel, és előfordulhat, hogy néhányukat már használják más kapcsolatok, amelyeket néhány másodperccel az összeomlás előtt hoztak létre.

Emiatt a kapcsolat legvégén lévő másik fél nem tudhatja, hogy partnere összeomláson ment keresztül, és a munkája ezután helyreállt. Mindez komoly fennakadásokhoz vezet, különösen akkor, ha hosszú időbe telik, amíg a régi adatok átjutnak a hálózaton, és keverednek az újonnan létrehozott kapcsolat adataival. Az újraindítás időzítőjének kiválasztása kiküszöböli az ilyen problémákat. A régi adatok számozása más lesz, mint az új kapcsolat sorszámtartománya. A hackerek, amikor meghamisítják a forrás IP-címét egy megbízható gazdagéphez, megpróbálnak hozzáférni a számítógépekhez úgy, hogy az üzenetben megjósolható kezdő sorszámot adnak meg. A belső kulcsokon alapuló kriptográfiai hash funkció szolgál a legjobb mód biztonságos magszámok kiválasztásához.

10.8.5 A mezők általános használata

A TCP fejléc átvitelre való előkészítésekor a mezőben az átvitt adatok első oktettjének sorszámát kell feltüntetni. sorszám(Sorszám).

A mezőbe a kapcsolati partnertől várt következő oktettszám kerül beírásra megerősítés(Nyugtázási szám), ha az ACK bit 1-re van állítva. Mező ablak(Ablak) a fogadó ablak aktuális méretére vonatkozik. Ez a mező tartalmazza a megerősítő számból az elfogadható bájtok száma... Vegye figyelembe, hogy ez az érték lehetővé teszi az adatfolyam pontos szabályozását. Ezzel az értékkel a partner jelzi a fogadóablak valós állapotát a cseremenet során.

Ha az alkalmazás egy TCP leküldéses műveletre mutat, akkor a PUSH jelző 1-re van állítva. A fogadó TCP-nek válaszolnia KELL, hogy gyorsan elküldi az adatokat az alkalmazásnak, amint a küldő el akarja küldeni.

A SÜRGŐS jelző, ha 1-re van állítva, sürgős adatátvitelt jelent, és a megfelelő mutatónak a sürgős adatok utolsó oktettjére KELL hivatkoznia. A sürgős adatok tipikus használata törlési vagy megszakítási jelek küldése a terminálról.

Sürgős adatokat gyakran hívnak sávon kívüli információk(sávon kívüli). Ez a kifejezés azonban pontatlan. A gyorsított adatok egy normál TCP adatfolyamon kerülnek elküldésre, bár egyes megvalósítások speciális mechanizmusokkal utasíthatják az alkalmazást sürgős adatok fogadására, és az alkalmazásnak ellenőriznie kell a sürgős adatok tartalmát, mielőtt az üzenet összes bájtja megérkezne.

A RESET jelző 1-re van állítva a kapcsolat megszakításához. Ugyanez a jelző lesz beállítva a válaszban, amikor olyan szegmens érkezik, amely nincs társítva az aktuális TCP-kapcsolatok egyikéhez sem.

A FIN 1-re van állítva a kapcsolatzárási üzenetekhez.

10.8.6 Ellenőrző összeg

Az IP-ellenőrző összeg csak az IP-fejlécre vonatkozik, a TCP-ellenőrző összeget pedig a teljes szegmensre, valamint az IP-fejlécből generált pszeudofejlécre számítják ki. A TCP ellenőrző összeg kiszámításakor a megfelelő mező 0-ra van állítva. A 10.15 egy pszeudofejlécet mutat, amely nagyon hasonlít az UDP-ellenőrző összegben használthoz.

Rizs. 10.15. A pszeudofejléc mezőt a TCP ellenőrző összeg tartalmazza

A TCP hosszát úgy számítjuk ki, hogy a TCP fejléc hosszát hozzáadjuk az adathosszhoz. A TCP ellenőrző összeg kötelező, nem úgy, mint az UDP. A vett szegmens ellenőrző összegét a vevő először kiszámítja, majd összehasonlítja a TCP fejléc ellenőrző összeg mezőjének tartalmával. Ha az értékek nem egyeznek, a szegmenst el kell vetni.

10.9 Példa TCP szegmensre

Rizs. 10.16, analizátor protokoll Szippantó a Network General által TCP szegmensek sorozata. Az első három szegmens kapcsolatot létesít a kliens és a szerver között Telnet... Az utolsó szegmens 12 bájtnyi adatot hordoz.

Rizs. 10.16. TCP-fejléc megjelenítése a Sniffer Analyzer által

Elemző Szippantó a legtöbb értéket decimálisra fordítja. A zászlóértékek azonban hexadecimális formában jelennek meg. A 12 értékű zászló 010010. Az ellenőrző összeg hexadecimális formában is megjelenik.

10.10 Munkamenet-támogatás

10.10.1 Ablakszondázás

Egy gyors küldő és egy lassú vevő 0 bájtos vételi ablakot alkothat. Ezt az eredményt ún az ablak bezárása(ablak bezárása). Ha van szabad hely a fogadási ablak méretének frissítésére, ACK-t használunk. Ha azonban egy ilyen üzenet elveszik, mindkét félnek a végtelenségig várnia kell.

Ennek elkerülése érdekében a küldő beállítja tárolt időzítő(persist timer), ha az ablak be van zárva. Az időzítő értéke az újraküldés időtúllépése. Az időzítő végén egy szegmens kerül elküldésre a partnernek hangzó ablak(window probe; egyes implementációk adatokat is tartalmaznak). A tesztelés hatására a partner visszaküld egy ACK-t, amely jelenti az ablak aktuális állapotát.

Ha az ablak még mindig nulla méretű, a tárolt időzítő értéke megduplázódik. Ezt a folyamatot addig ismételjük, amíg az időzítő el nem éri a maximum 60 másodpercet. A TCP továbbra is 60 másodpercenként küld vizsgálóüzeneteket – az ablak megnyitásáig, amíg a felhasználó le nem fejezi a folyamatot, vagy amíg az alkalmazás le nem jár.

10.11 Kijelentkezés

10.11.1 Időtúllépés

A kapcsolati partner összeomolhat vagy teljesen megszakadhat átjáró vagy kommunikációs hiba miatt. Számos mechanizmus létezik annak megakadályozására, hogy a TCP újra küldjön adatokat.

Az újraküldés (továbbítás) első küszöbének elérésekor a TCP utasítja az IP-t, hogy ellenőrizze a hibás útválasztót, és egyúttal értesíti az alkalmazást a problémáról. A TCP a második határérték eléréséig folytatja az adatok küldését, és csak ezután szakítja meg a kapcsolatot.

Természetesen, mielőtt ez megtörténne, megérkezhet egy ICMP üzenet, amely szerint a cél valamilyen okból elérhetetlen. Egyes megvalósításokban a TCP akkor is megpróbálja elérni a célt, amíg az időtúllépési idő le nem telik (ezt követően a probléma megoldódhat). Ezután az alkalmazás értesíti, hogy a cél elérhetetlen.

Az alkalmazás saját adatszállítási időtúllépést állíthat be, és ennek az intervallumnak a végén saját műveleteket hajthat végre. A kapcsolat általában megszakad.

10.11.2 A kapcsolat fenntartása

Ha egy nem teljes kapcsolatnak hosszú ideig van adatátvitele, akkor inaktív állapotba kerül. Inaktivitási időszak alatt hálózati összeomlás vagy megszakítás léphet fel fizikai vonalak kommunikáció. Amint a hálózat újra működőképes lesz, a partnerek a kommunikációs munkamenet megszakítása nélkül folytatják az adatcserét. Ez a stratégia összhangban volt a Honvédelmi Minisztérium követelményeivel.

Azonban bármilyen kapcsolat – aktív vagy inaktív – sok számítógépmemóriát foglal el. Egyes rendszergazdáknak vissza kell adniuk a fel nem használt erőforrásokat a rendszereknek. Ezért sok TCP-megvalósítás képes üzenetet küldeni a a kapcsolat megtartása(életben tartás) inaktív kapcsolatok tesztelése. Az ilyen üzeneteket rendszeres időközönként elküldik a partnernek, hogy ellenőrizzék a hálózaton való létezését. Válaszként ACK üzeneteket kell kapni. Az életben maradó üzenetek használata nem kötelező. Ha a rendszer rendelkezik ezzel a képességgel, az alkalmazás saját eszközeivel törölheti azt. Becsült időszak alapértelmezett a kapcsolat fenntartásának időkorlátja teljes két óra!

Emlékezzünk vissza, hogy az alkalmazás beállíthat saját időzítőt, amely szerint a saját szintjén dönt a kapcsolat megszakításáról.

10.12 Teljesítmény

Mennyire hatékony a TCP? Sok tényező befolyásolja az erőforrások teljesítményét, amelyek közül a memória és a sávszélesség a fő tényező (lásd 10.17. ábra).

Rizs. 10.17. TCP teljesítménytényezők

A használt fizikai hálózat sávszélessége és késleltetése súlyosan korlátozza a sávszélességet. A rossz adatátviteli minőség nagy mennyiségű adatcsomag kiesését eredményezi, ami újraküldést okoz, és ennek következtében csökkenti a sávszélesség hatékonyságát.

A fogadó oldalnak elegendő pufferterületet kell biztosítania ahhoz, hogy a küldő megszakítás nélkül küldhesse az adatokat. Ez különösen fontos a nagy késleltetésű hálózatok esetében, ahol hosszú idő telik el az adatok küldése és az ACK fogadása között (és az ablakméret egyeztetésekor). A forrásból származó stabil adatfolyam fenntartásához a fogadó oldalon legalább a sávszélesség és a késleltetés szorzatának megfelelő ablakkal kell rendelkeznie.

Például, ha a forrás 10 000 bájt/s sebességgel tud adatokat küldeni, és 2 másodpercbe telik az ACK visszaküldése, akkor a másik oldalon legalább 20 000 bájtos fogadási ablakot kell biztosítani, ellenkező esetben az adatáramlás nem lesz folyamatos. A 10 000 bájtos vételi puffer a felére csökkenti az átviteli sebességet.

A teljesítmény másik fontos tényezője a fogadó azon képessége, hogy reagáljon a kiemelt fontosságú eseményekre és gyorsan végrehajtsa kontextusváltás, azaz hajtson végre néhány műveletet, és váltson át másokra. A gazdagép több helyi felhasználót is képes interaktívan támogatni, kötegelt háttérfolyamatokés több tucat egyidejűleg kommunikációs kapcsolatok... A kontextusváltás lehetővé teszi ezen műveletek kiszolgálását, miközben elrejti a rendszer terhelését. A TCP / IP-t az operációs rendszer kernellel integráló megvalósítások jelentősen csökkenthetik a környezetváltás használatának többletköltségét.

A TCP-fejlécek feldolgozásához számítógépes CPU-erőforrásokra van szükség. Ha a processzor nem képes gyorsan kiszámolni az ellenőrző összegeket, akkor lelassítja az adatátviteli sebességet a hálózaton keresztül.

Ezenkívül a fejlesztőknek fontolóra kell venniük a TCP-paraméterek egyszerű konfigurálását, hogy a hálózati rendszergazda testreszabhassa azokat a helyi követelményeknek megfelelően. Például a puffer méretének a sávszélességhez és a hálózati késleltetéshez való hangolása drámaian javítja a teljesítményt. Sajnos sok implementáció nem fordít kellő figyelmet erre a problémára, és keményen kódolja a kommunikációs paramétereket.

Tegyük fel, hogy a hálózati környezet tökéletes: elegendő erőforrás áll rendelkezésre, és a kontextusváltás gyorsabb, mint ahogy a cowboyok előrántják a revolvereiket. Kiváló teljesítményt fog elérni?

Nem mindig. A TCP szoftverfejlesztés minősége is számít. Számos teljesítményproblémát diagnosztizáltak és megoldottak az évek során a különböző TCP-megvalósításokban. Feltételezhetjük, hogy a legjobb lesz szoftver, amely megfelel az RFC 1122 szabványnak, amely meghatározza az internetes gazdagépek kommunikációs rétegére vonatkozó követelményeket.

Ugyanilyen fontos a kivétel valamint a Jacobson, Kern és Partridge algoritmusok alkalmazása (ezekről az érdekes algoritmusokról alább lesz szó).

A szoftverfejlesztők jelentős előnyökhöz juthatnak azáltal, hogy olyan programokat hoznak létre, amelyek kiküszöbölik a kis mennyiségű adat szükségtelen átvitelét, és beépített időzítőkkel rendelkeznek a jelenleg nem használt hálózati erőforrások felszabadítására.

10.13 Algoritmusok a teljesítmény javítására

Továbblépve a TCP meglehetősen összetett részére, megvizsgáljuk a teljesítmény javításának és a sávszélesség szűk keresztmetszetek megoldásának mechanizmusait. Ez a rész a következő kérdéseket tárgyalja:

■ Lassú indítás(lassú indítás) megakadályozza, hogy a hálózati forgalom nagy részét egy új munkamenethez használják fel, ami többletterheléshez vezethet.

■ Helyreállítás ostoba ablak szindróma(bolond ablak szindróma) megakadályozza, hogy a rosszul megtervezett alkalmazások túlterheljék a hálózatot üzenetekkel.

■ Késleltetett ACK(késleltetett ACK) csökkenti a torlódást azáltal, hogy csökkenti a független továbbítási nyugtázási üzenetek számát.

■ Számított újraküldési időtúllépés(computing retransmission timeout) a valós idejű munkamenet-idő egyeztetésen alapul, csökkentve a szükségtelen újraküldéseket, de nem okoz nagy késéseket a valóban szükséges adatcseréknél.

■ Lassítsa le a TCP-továbbítást, ha túlterhelések A hálózaton keresztül az útválasztók visszatérhetnek eredeti módjukba, és megoszthatják a hálózati erőforrásokat az összes munkamenethez.

■ Küldés duplikált ACK-ek(duplikált ACK) a sorrenden kívüli szegmens fogadása esetén lehetővé teszi a partnerek számára, hogy az időtúllépés előtt újraküldjék.

10.13.1 Lassú indítás

Ha otthon minden háztartási elektromos készüléket egyszerre kapcsol be, az elektromos hálózat túlterhelése lép fel. V számítógépes hálózatoklassú indítás megakadályozza a hálózati biztosítékok kiolvadását.

Egy új kapcsolat, amely azonnal elindítja a nagy mennyiségű adat átvitelét egy már betöltött hálózaton, problémákhoz vezethet. A lassú indítás mögött meghúzódó gondolat az, hogy az új kapcsolat sikeresen induljon, miközben lassan növeli az adatátviteli sebességet a hálózat tényleges terhelésének megfelelően. A küldőt a betöltési ablak mérete korlátozza, nem a nagy fogadási ablak.

Betöltési ablak(torlódási ablak) 1 szegmensméretnél kezdődik. Minden sikeresen fogadott ACK szegmensnél a betöltési ablak 1 szegmenssel megnövekszik, amíg kisebb marad, mint a fogadási ablak. Ha a hálózat nincs túlterhelve, a betöltési ablak fokozatosan eléri a fogadóablak méretét. Normál továbbítási körülmények között ezek az ablakok azonos méretűek lesznek.

Vegye figyelembe, hogy a lassú indítás nem olyan lassú. Az első ACK után a betöltési ablak mérete 2 szegmensnek felel meg, két szegmensre sikeres ACK fogadása után pedig 8 szegmensre nőhet. Más szóval, az ablak mérete exponenciálisan növekszik.

Tegyük fel, hogy ahelyett, hogy ACK-t kapna, időtúllépés történt. A betöltőablak viselkedését ebben az esetben az alábbiakban tárgyaljuk.

10.13.2 Tanácstalan ablak szindróma

A TCP / IP első implementációi során a fejlesztők szembesültek a jelenséggel ostoba ablak szindróma(Silly Window Syndrome – SWS), ami elég gyakran felbukkant. A lezajlott események megértéséhez vegye figyelembe a következő forgatókönyvet, amely nemkívánatos következményekkel jár, de nagyon is lehetséges:

1. A küldő alkalmazás gyorsan küld adatokat.

2. A fogadó alkalmazás 1 bájtnyi adatot olvas be a bemeneti pufferből (azaz lassan).

3. A bemeneti puffer a kiolvasás után gyorsan megtelik.

4. A fogadó alkalmazás 1 bájtot olvas, és a TCP ACK-t küld, ami azt jelenti, hogy "1 bájtnyi adat számára van szabad helyem."

5. A küldő alkalmazás 1 bájtos TCP-csomagot küld a hálózaton keresztül.

6. A fogadó TCP ACK-t küld, aminek jelentése "Köszönöm. Kaptam egy csomagot, és nincs több szabad helyem."

7. A fogadó alkalmazás ismét 1 bájtot olvas és ACK-t küld, és az egész folyamat megismétlődik.

A lassan fogadó alkalmazás sokáig vár az adatok megérkezésére, és folyamatosan az ablak bal szélére tolja a kapott információkat, teljesen haszontalan műveletet hajtva végre, amely további forgalom online.

A valós élethelyzetek persze nem ilyen szélsőségesek. A gyors küldő és a lassú vevő kis (a maximális szegmensmérethez képest) adatdarabokat cserél, és szinte teljes vételi ablakot vált. ábrán. A 10.18 mutatja a "bolond ablak" szindróma megjelenésének feltételeit.

Rizs. 10.18. Nagyon kis szabad hellyel rendelkező ablakpuffer fogadása

Ezt a problémát nem nehéz megoldani. Amint a fogadási ablak a megadott célméretnél kisebbre zsugorodik, a TCP elkezdi becsapni a küldőt. Ebben a helyzetben a TCP-nek nem szabad a feladóra irányítania további hely az ablakban, amikor a fogadó alkalmazás kis darabokban olvas adatokat a pufferből. Ehelyett a felszabadított erőforrásokat titokban kell tartani a feladó előtt, amíg nem lesz elegendő belőlük. Az ajánlott méret egy szegmens, kivéve, ha a teljes bemeneti puffer egyetlen szegmenst tartalmaz (ez utóbbi esetben a puffer felével megegyező méretet használunk). A TCP által jelentendő célméret a következőképpen fejezhető ki:

minimum (1/2 bemeneti puffer, maximális szegmensméret)

A TCP akkor kezd csalni, ha az ablak mérete kisebb lesz ennél, és akkor mond igazat, ha az ablak mérete nem kisebb, mint a képlet által kapott érték. Ne feledje, hogy a küldőt nem éri kár, mert a fogadó alkalmazás továbbra sem tudja feldolgozni a várt adatok nagy részét.

A javasolt megoldás a fenti esetben könnyen ellenőrizhető minden fogadott bájthoz tartozó ACK kimenettel. Ugyanez a módszer alkalmas arra az esetre is, amikor a bemeneti puffer több szegmenst is képes tárolni (ahogy ez a gyakorlatban gyakran előfordul). A gyors küldő kitölti a bemeneti puffert, de a vevő jelzi, hogy nincs szabad helye az információ befogadására, és addig nem nyitja meg ezt az erőforrást, amíg mérete el nem éri a teljes szegmenst.

10.13.3 Nagle algoritmusa

A feladónak – a címzetttől függetlenül – ki kell zárnia a nagyon rövid szegmensek továbbítását, amelyek küldés előtt felhalmozzák az adatokat. A Nagle algoritmus egy nagyon egyszerű ötletet valósít meg a hálózaton keresztül küldött rövid datagramok számának csökkentésére.

Az algoritmus azt javasolja, hogy késleltesse az adatátvitelt (és nyomja meg) a korábban továbbított adatok ACK-jének megvárásával. A felhalmozott adatok elküldése egy korábban elküldött információ ACK jelzése után, vagy egy teljes szegmens méretű adat vétele után küldésre, vagy egy időkorlát lejárta után kerül elküldésre. Ezt az algoritmust nem szabad olyan valós idejű alkalmazásokhoz használni, amelyeknek a lehető leggyorsabban kell adatokat küldeniük.

10.13.4 Késleltetett ACK

Egy másik teljesítménynövelő mechanizmus az ACK késleltetési módszer. Az ACK-ek számának csökkentése csökkenti az egyéb forgalom továbbítására használható sávszélességet. Ha a TCP-társ kissé késlelteti az ACK küldését, akkor:

■ Több szegmens vételét nyugtázhatja egy ACK-val.

■ A fogadó alkalmazás képes bizonyos mennyiségű adat fogadására az időkorláton belül; a kimeneti fejléc szerepelhet az ACK-ban, és nem kell külön üzenetet generálnia.

A késések elkerülése érdekében a teljes méretű szegmensek folyamának küldésekor (például fájlok cseréjekor) legalább minden második teljes szegmensre ACK-t kell küldeni.

Sok megvalósítás 200 ms időtúllépést használ. De a késleltetett ACK nem lassítja az árfolyamot. Ha egy rövid szegmens érkezik, a bemeneti pufferben még mindig van elég szabad hely az új adatok fogadásához, és a küldő tovább tud küldeni (ráadásul az újraküldés általában sokkal lassabb). Ha egy egész szegmens érkezik, akkor ugyanabban a másodpercben ACK üzenettel kell válaszolnia rá.

10.13.5 Az újraküldés időtúllépése

A szegmens elküldése után a TCP beállít egy időzítőt, és figyeli az ACK érkezését. Ha nem érkezik ACK az időkorláton belül, a TCP újraküldi a szegmenst (relét). De mi legyen az időkorlát?

Ha túl rövid, a küldő feltölti a hálózatot felesleges szegmensekkel, amelyek megkettőzik a már elküldött információkat. A túl hosszú időtúllépés megakadályozza, hogy gyorsan kijavítsa a nagyon rossz szegmenseket az átvitel során, ami csökkenti az átviteli sebességet.

Hogyan válasszam ki a megfelelő időt az időkorláthoz? A nagy sebességű LAN-hoz jó érték nem jó egy többleütéses távoli kapcsolathoz. Ez azt jelenti, hogy az „egy érték minden feltételhez” elve nyilvánvalóan alkalmatlan. Sőt, még egy meglévő kapcsolat esetén is változhatnak a hálózati feltételek, és a késések növekedhetnek vagy csökkenhetnek.

Jacobson, Kern és Partridge algoritmusok (leírása a cikkekben , Van Jacobson és Az oda-vissza utazási idő becslésének javítása a megbízható szállítási protokollokban, Karn és Partridge) lehetővé teszik a TCP számára, hogy alkalmazkodjon a változó hálózati feltételekhez. Ezeket az algoritmusokat új implementációkhoz ajánljuk. Az alábbiakban röviden foglalkozunk velük.

A józan ész azt diktálja, hogy egy adott kapcsolat megfelelő időtúllépési idejének becsléséhez a legjobb alap lehet ciklusidő(oda-vissza út) az adatok elküldése és az átvételről szóló visszaigazolás kézhezvétele közötti intervallum.

A következő mennyiségekre jó döntéseket hozhatunk az alapvető statisztikákból (lásd 10.19. ábra), amelyek segíthetnek az időtúllépési idő kiszámításában. Ne hagyatkozzon azonban az átlagokra, mivel a becslések több mint fele nagyobb lesz az átlagnál. Néhány eltérést megnézve pontosabb becsléseket kaphatunk, figyelembe véve a normál eloszlást és csökkentve a túl hosszú újraküldési várakozási időt.

Rizs. 10.19. A ciklusidők megoszlása

Nincs szükség nagy mennyiségű számításra az eltérések formális matematikai becsléséhez. Durva becslések használhatók az utolsó érték és az átlagos becslés közötti különbség abszolút értéke alapján:

Utolsó eltérés = | Utolsó ciklus - Átlag |

Egy másik tényező, amelyet figyelembe kell venni a megfelelő időtúllépés kiszámításakor, a ciklusidő változása az aktuális hálózati feltételek miatt. Ami az utolsó pillanatban történt a weben, az fontosabb, mint ami egy órája történt.

Tegyük fel, hogy egy nagyon hosszú munkamenet ciklusátlagát számítja ki. Annak ellenére, hogy a hálózat eleinte enyhén volt terhelve, és 1000 kis értéket határoztunk meg, a forgalom jelentős növekedést mutatott a késleltetési idő jelentős növekedésével.

Például, ha 1000 érték átlagosan 170 egységet adott, de akkor 50 értéket mértek átlagosan 282-vel, akkor az aktuális átlag a következő lesz:

170 × 1000/1050 + 282 × 50/1050 = 175

Ésszerűbb lenne az érték simított ciklusidő(Smoothed Round-Trip Time – SRTT), amely figyelembe veszi a későbbi értékek prioritását:

Új SRTT = (1 - α) × (régi SRTT) + α × Utolsó ciklus értéke

Az α értéke 0 és 1 között van. Növelje a az aktuális ciklusidő nagyobb befolyását eredményezi a simított átlagra. Mivel a számítógépek gyorsan tudnak osztani 2 hatványaival a bináris számok jobbra tolásával, α-t mindig úgy választjuk, hogy (1/2) n (általában 1/8), így:

Új SRTT = 7/8 × régi SRTT + 1/8 × Utolsó ciklusidő

A 10.2. táblázat bemutatja, hogy az SRTT képlete hogyan igazodik az aktuális 230-as SRTT értékhez, amikor a hálózati állapot változása a ciklusidő fokozatos növekedését eredményezi (feltételezve, hogy nem következik be időtúllépés). A 3. oszlopban szereplő értékek az 1. oszlopban szereplő értékekként használatosak következő sor táblázatok (azaz mint a régi SRTT).

10.2. táblázat A simított ciklusidő kiszámítása

Régi SRTT	Legutóbbi RTT	(7/8) × (régi SRTT) + (1/8) × (RTT)
230.00	294	238.00
238.00	264	241.25
241.25	340	253.59
253.59	246	252.64
252.64	201	246.19
246.19	340	257.92
257.92	272	259.68
259.68	311	266.10
266.10	282	268.09
268.09	246	265.33
265.33	304	270.16
270.16	308	274.89
274.89	230	269.28
269.28	328	276.62
276.62	266	275.29
275.29	257	273.00
273.00	305	277.00

Most jön az újraadási időtúllépés értékének megválasztásának kérdése. A ciklusidők elemzése azt mutatja, hogy ezek az értékek jelentős eltérést mutatnak a jelenlegi átlagtól. Az eltérések (eltérések) nagyságának határértékét célszerű meghatározni. Az újraküldési időtúllépés jó értékeit (az RFC szabványokban Retransmission TimeOut - RTO-nak hívják) a következő képlet adja meg simított eltérési megszorítással (SDEV):

T = Retransmission Timeout = SRTT + 2 × SDEV

T = SRTT + 4 × SDEV

Az SDEV kiszámításához először határozza meg az aktuális eltérés abszolút értékét:

DEV = | Utolsó ciklusidő – régi SRTT |

A simítási képlet ezután az utolsó érték figyelembevételére szolgál:

Új SDEV = 3/4 × régi SDEV + 1/4 × DEV

Egy kérdés marad: mik a kezdeti értékek? Ajánlott:

Kezdeti időtúllépés = 3 s

Kezdeti SRTT = 0

Kezdeti SDEV = 1,5 s

Van Jacobson definiált egy gyors algoritmust, amely nagyon hatékonyan számítja ki az újraadási időtúllépést.

10.13.6 Statisztikai példa

Mennyire fog működni a fent kiszámított időtúllépés? Jelentős teljesítménynövekedés volt megfigyelhető, amikor a kapott érték realizálódott. Példa erre a csapatstatisztika netstat kapott a rendszerben tigris- Internet szerver, amelyhez számos gazdagép fér hozzá a világ minden tájáról.

1510769 csomag (314955304 bájt) érkezett egymás után

Rendszer tigris a TCP adatszegmensek kevesebb mint 2,5%-a került újraküldésre. Másfél millió bejövő adatszegmensnél (a többi tiszta ACK üzenet) mindössze 0,6% duplikált. Nem szabad megfeledkezni arról, hogy a bemeneti adatok veszteségi szintje megközelítőleg megfelel a kimeneti szegmensek szintjének. Így a haszontalan újraadási forgalom a teljes forgalom mintegy 0,6%-át teszi ki.

10.13.7 Számítások újraküldés után

A fenti képletek a ciklusidő értékét használják a szegmens küldése és a nyugtázás fogadása közötti intervallumként. Tegyük fel azonban, hogy az időtúllépési időszak alatt nem érkezik visszaigazolás, és az adatokat újra el kell küldeni.

A Kern-algoritmus feltételezi, hogy a ciklusidőt ebben az esetben nem szabad megváltoztatni. A ciklusidő aktuális simított értéke és simított eltérés megőrzik értékeiket, amíg nem érkezik visszaigazolás egy bizonyos szegmens újraküldése nélkül történő elküldésére. Ezen a ponton a számítások folytatódnak a mentett értékek és az új mérések alapján.

10.13.8 Műveletek az újraküldés után

De mi történik a megerősítés megérkezése előtt? Az újraküldést követően a TCP viselkedése gyökeresen megváltozik, főként a hálózati torlódásból eredő adatvesztés miatt. Ezért a reakció az adatok újraküldésére a következő lesz:

■ Az újraszállítás sebességének csökkentése

■ Csökkentse a hálózati torlódást a teljes forgalom csökkentésével

10.13.9 Exponenciális fékezés

Az újraküldést követően az időkorlát megduplázódik. De mi történik, ha az időzítő ismét túlcsordul? Az adatok újraküldésre kerülnek, és az újraküldési időszak ismét megduplázódik. Ezt a folyamatot ún exponenciális lassulás(exponenciális visszalépés).

Ha a hálózati hiba továbbra is fennáll, az időtúllépési idő megduplázódik, amíg el nem éri az előre beállított maximális értéket (általában 1 perc). Az időtúllépés után csak egy szegmens küldhető el. Az időtúllépés akkor is bekövetkezik, ha az ACK fogadása nélküli adatátvitelek számának előre meghatározott értékét túllépik.

10.13.10 A torlódások csökkentése a hálózaton keresztül küldött adatmennyiség csökkentésével

Az átvitt adatok mennyiségének csökkentése valamivel bonyolultabb, mint a fent tárgyalt mechanizmusok. Kezd működni, mint a már említett lassú indítás. De mivel a forgalmi szint határa meg van határozva, ami kezdetben problémákhoz vezethet, az árfolyam valójában lelassul az egyik szegmens terhelési ablakának növekedése miatt. Be kell állítania a határértékeket, hogy valóban csökkentse a feltöltési sebességet. Először a veszélyküszöböt számítják ki:

Határ – minimum 1/2 (aktuális betöltési ablak, partner fogadási ablaka)

Ha a kapott érték több mint két szegmens, akkor határként kerül felhasználásra. Ellenkező esetben a szegély két szegmensre lesz beállítva. A teljes helyreállítási algoritmus megköveteli:

■ Állítsa be a betöltőablak méretét egy szegmensre.

S Minden egyes fogadott ACK esetén növelje a betöltési ablakot egy szegmenssel, amíg el nem éri a határt (nagyon hasonlóan egy lassú indítási mechanizmushoz).

■ Ezután minden egyes ACK fogadásakor adjon hozzá egy kisebb értéket a betöltési ablakhoz, amely a ciklusidő egy szegmensének növekedési sebessége alapján kerül kiválasztásra (a növekedés MSS / N-ként kerül kiszámításra, ahol N a betöltési ablak szegmensekben).

Egy ideális forgatókönyv leegyszerűsítheti a helyreállítási mechanizmus munkáját. Tegyük fel, hogy a partner fogadási ablaka (és az aktuális betöltési ablak) 8 szegmens méretű volt az időtúllépés észlelése előtt, és a határ 4 szegmensben volt meghatározva. Ha a fogadó alkalmazás azonnal kiolvassa az adatokat a pufferből, a fogadási ablak 8 szegmensben marad.

■ 1 szegmens kerül elküldésre (betöltési ablak = 1 szegmens).

■ ACK érkezett – 2 szegmens kerül elküldésre.

■ ACK fogadott 2 szegmensre – 4 szegmens kerül elküldésre (elérte a határt).

■ ACK érkezett 4 szegmensre. 5 szegmens kerül elküldésre.

■ ACK érkezett 5 szegmensre. 6 szegmens kerül elküldésre.

■ ACK érkezett 6 szegmensre. 7 szegmens kerül elküldésre.

■ ACK érkezett 7 szegmensre. 8 szegmens kerül elküldésre (a betöltési ablak ismét megegyezik a fogadási ablak méretével).

Mivel az újraküldési időtúllépés során minden elküldött adat nyugtázása szükséges, a folyamat addig folytatódik, amíg a betöltési ablak el nem éri a fogadási ablak méretét. A megtörtént eseményeket az ábra mutatja. 10.20. Az ablak mérete exponenciálisan növekszik, a lassú indítási periódus alatt megduplázódik, a határ elérésekor pedig lineárisan növekszik.

Rizs. 10.20. Az átviteli sebesség korlátozása torlódások idején

10.13.11 Ismétlődő ACK-ek

Egyes megvalósításokban egy opcionális szolgáltatást használnak - az ún gyors újraszállítás(gyors újraküldés) - az adatok bizonyos feltételek melletti újraküldésének felgyorsítása érdekében. Fő gondolata a vevő által további ACK-ek küldésére vonatkozik, jelezve a kapott adatok hiányát.

Rendkívüli szegmens fogadásakor a vevő az első bájtra mutató ACK-t küld vissza. elveszett adatok (lásd 10.21. ábra).

Rizs. 10.21. Megkettőzött ACK-ek

A feladó nem küldi el azonnal újra az adatokat, mivel az IP rendszerint küldési sorrend nélkül is tud adatot eljuttatni a címzetthez. De ha több további ACK érkezik az ismétlődő adatokhoz (például három), akkor a hiányzó szegmens elküldésre kerül anélkül, hogy megvárná az időtúllépés lejártát.

Vegye figyelembe, hogy minden duplikált ACK egy adatszegmens fogadását jelzi. Számos ismétlődő ACK jelzi, hogy a hálózat elegendő adatot képes szállítani, ezért nincs túlterhelve. Az általános algoritmus részeként a betöltési ablak méretének kismértékű csökkentését hajtják végre a hálózati forgalom valódi növekedésével. Ebben az esetben a radikális átméretezés folyamata a munka helyreállításakor nem érvényes.

A szabvány szerint Host követelmények(hoszt követelmények) A TCP-nek ugyanazt a lassú indítást kell végrehajtania, mint fentebb a forrás kioltásakor (forrás quench). Ennek jelentése azonban nem célzott és nem hatékony, mert előfordulhat, hogy az üzenetet fogadó kapcsolat nem generál túl nagy forgalmat. Jelenlegi specifikáció Router követelmények(router követelmények) azt jelzi, hogy az útválasztók nem kelleneüzeneteket küldeni a forrás elnyomásáról.

10.13.13 TCP-statisztika

Végül vessünk egy pillantást a parancs statisztikai üzeneteire netstat, hogy a fent leírt mechanizmusok közül sok működjön.

A szegmenseket csomagoknak nevezzük.

879137 adatcsomag (226966295 bájt)

21815 adatcsomag (8100927 bájt) újraküldve

Újraszállítás.

132957 csak fogadható csomag (104216 késleltetett)

Megjegyezzük, hogy nagy számban

késleltetett ACK.

Ablaknyílás szondázása

nulla méret.

Ezek SYN és FIN üzenetek.

762469 akk (226904227 bájt esetén)

Figyelmeztetés az érkező csomagokra

soron kívül.

1510769 csomag (314955304 bájt)

9006 teljesen duplikált csomag (867042 bájt)

Az időtúllépés eredménye, amikor az igazi

adatok szállítása.

74 csomag némi duppal. adatok (12193 bájt átverve)

A nagyobb hatékonyság érdekében

az adatok egy részét újracsomagolták, hogy az újraküldéskor további bájtokat tartalmazzanak.

13452 soron kívüli csomag (2515087 bájt)

530 csomag (8551 bájt) adat az ablak után

Talán ez az adat volt

szerepelnek az érzékelõ üzenetekben.

402 csomag érkezett bezárás után

Ezek utólagos ismétlések

küldés.

108-at elvettük rossz ellenőrző összegek miatt

Érvénytelen TCP-ellenőrző összeg.

0 elvetve rossz fejléceltolási mezők miatt

7 eldobva, mert a csomag túl rövid

14677 kapcsolat létrejött (beleértve az elfogadásokat is)

18929 kapcsolat lezárva (ebből 643 csepp)

4100 embrionális kapcsolat megszakadt

572187 szegmens frissítve rtt (587397 próbálkozásból)

Sikertelen változtatási kísérletek

a ciklusidő, mivel az ACK-nek nem volt ideje megérkezni az időkorlát lejárta előtt,

26 kapcsolat megszakadt a rexmit időtúllépése miatt

Későbbi sikertelen próbálkozások

újraküldés, ami a kapcsolat megszakadását jelzi.

Időtúllépések vizsgálata

nulla ablak.

Kijelentkezési időtúllépések

megszakadt kapcsolat.

472 kapcsolat megszakadt a Keepalive által

10.14 A fejlesztői követelményeknek való megfelelés

A jelenlegi TCP-szabvány megköveteli, hogy a megvalósítások tartsák be a lassú indítási eljárást a kapcsolat inicializálása során, és Kern és Jacobson algoritmusokat használjanak az újraküldési időtúllépés becslésére és a terhelés kezelésére. A tesztek kimutatták, hogy ezek a mechanizmusok jelentős teljesítményjavuláshoz vezetnek.

Mi történik, ha olyan rendszert telepít, amely nem felel meg ezeknek a szabványoknak? Nem lesz képes megfelelő teljesítményt nyújtani saját felhasználóinak, és rossz szomszédja lesz a hálózat többi rendszerének, megakadályozva a normál működés helyreállítását átmeneti torlódások után, és túlzott forgalmat generál, ami datagramok kiesését eredményezi.

10.15 A teljesítmény akadályai

A TCP bizonyította rugalmasságát, több száz vagy millió bit/s átváltási sebességű hálózatokon működik. Ez a protokoll jó eredmények elérését tette lehetővé a modern helyi hálózatok Ethernet, Token-Ring és Fibre Distributed Data Interface (FDDI) topológiákkal, valamint kis sebességű vagy nagy távolságú kapcsolatokkal (például műholdkapcsolatokkal).

A TCP-t úgy tervezték, hogy reagáljon a szélsőséges körülményekre, például a hálózati torlódásokra. A protokoll jelenlegi verziója azonban olyan funkciókkal rendelkezik, amelyek korlátozzák a teljesítményt ígéretes technológiák amelyek több száz és több ezer megabájtos sávszélességet kínálnak. A felmerülő problémák megértéséhez vegyünk egy egyszerű (bár irreális) példát.

Tegyük fel, hogy amikor egy fájlt két rendszer között mozgat, a lehető leghatékonyabban szeretne folyamatos adatfolyamot cserélni. Tegyük fel, hogy:

■ A maximális célszegmens mérete 1 KB.

■ Fogadási ablak - 4 Kbyte.

■ A sávszélesség lehetővé teszi két szegmens küldését 1 másodperc alatt.

■ A fogadó alkalmazás a beérkezésükkor fogyaszt adatokat.

SACK üzenetek 2 másodpercen belül megérkeznek.

A feladó képes folyamatosan adatokat küldeni. Végül is, amikor az ablakhoz lefoglalt kötet megtelik, egy ACK érkezik, amely lehetővé teszi egy újabb szegmens küldését:

2 mp után:

AZ 1. SZEGMENT VISSZAFOGLALÁSA, KÜLDHETŐ AZ 5. RÉSZ.

A 2. SZEGMENT VISSZAFOGLALÁSA, KÜLDHETŐ A 6. RÉSZ.

A 3. SZEGMENS VISSZAFOGLALÁSA, KÜLDHETŐ A 7. RÉSZ.

A 4. SZEGMENT VISSZAFOGLALÁSA, KÜLDHETŐ A 8. RÉSZ.

További 2 mp után:

AZ 5. SZEGMENT VISSZAFOGLALÁSA, KÜLDHETŐ A 9. RÉSZ.

Ha a fogadási ablak csak 2 KB lenne, a küldőnek minden másodikból egy másodpercet kell várnia, mielőtt elküldené a következő adatot. Valójában a folyamatos adatfolyam fenntartásához a vételi ablaknak legalább a következőnek kell lennie:

Ablak = Sávszélesség × Ciklusidő

Bár a példa némileg eltúlzott (hogy egyszerűbb számokat adjunk), a kis ablak problémákhoz vezethet a nagy késleltetésű műholdkapcsolatoknál.

Most pedig nézzük meg, mi történik a nagy sebességű kapcsolatokkal. Például, ha a sávszélesség és az átviteli sebesség mérése 10 millió bit/s, de a ciklusidő 100 ms (1/10 másodperc), akkor folyamatos adatfolyam esetén a vételi ablaknak legalább 1 000 000 bitet kell tárolnia, azaz... 125 000 bájt. De a TCP fogadási ablak fejlécébe írható legnagyobb szám 65 536.

Egy másik probléma a nagy adatátviteli sebességnél jelentkezik, mivel a sorszámok nagyon gyorsan elfogynak. Ha a kapcsolat 4 GB / s sebességgel képes adatátvitelre, akkor a sorszámokat másodpercenként frissíteni kell. Nem lehet majd különbséget tenni a régi duplikált datagramok között, amelyek több mint egy másodpercet késtek az interneten való böngészés közben a friss új adatoktól.

Új kutatások folynak a TCP / IP javítására és a fenti akadályok megszüntetésére.

10.16 TCP-funkciók

Ez a fejezet a TCP számos szolgáltatására összpontosít. A főbbeket az alábbiakban soroljuk fel:

■ Portok összekötése a csatlakozásokkal

■ A kapcsolatok inicializálása 3 lépéses megerősítéssel

■ A hálózati torlódások elkerülése érdekében lassú indítást hajt végre

■ Az átvitel során lévő adatok szegmentálása

■ Adatok számozása

■ Bejövő ismétlődő szegmensek kezelése

■ Ellenőrző összegek kiszámítása

■ Az adatáramlás szabályozása a fogadó és a küldő ablakon keresztül

■ Kapcsolat megszakítása a kialakult módon

■ A kapcsolat megszakítása

■ Sürgős adatok továbbítása

■ Pozitív visszaigazolás az újraszállításról

■ Az újraküldés időtúllépésének kiszámítása

■ Csökkentett visszatérő forgalom hálózati torlódások esetén

■ Riasztás a renden kívüli szegmens érkezésére

■ A fogadóablak bezárásának érzékelése

10.17 TCP állapotok

A TCP kapcsolat több szakaszon megy keresztül: üzenetváltással jön létre a kapcsolat, majd elküldik az adatokat, majd speciális üzenetváltással lezárják a kapcsolatot. A kapcsolat munkájának minden lépése megfelel egy bizonyos állapot ezt a kapcsolatot. A kapcsolat mindkét végén található TCP szoftver folyamatosan figyel Jelen állapot a kapcsolat másik oldala.

Az alábbiakban röviden áttekintjük a kapcsolat különböző végein elhelyezkedő szerver és kliens tipikus állapotát. Nem kívánunk minden lehetséges állapotot kimerítően leírni az adatátvitel során. Megtalálható az RFC 793-ban és azokban Host követelmények.

A kapcsolatok létrehozása során a szerver és a kliens hasonló állapotsorozatokon megy keresztül. A kiszolgáló állapotait a 10.3. táblázat, a kliensállapotokat pedig a 10.4. táblázat mutatja.

10.3. táblázat Szerver állapotsorrendje

Szerver állapota	Esemény	Leírás
ZÁRVA (zárva)		Fiktív állapot a kapcsolat létrehozása előtt.
	Passzív megnyitás szerveralkalmazás által.
HALLGAT (követés)		A szerver ügyfélkapcsolatra vár.
	A TCP szerver SYN-t kap, és SYN/ACK-t küld.	A szerver SYN-t kapott és SYN/ACK-t küldött. Megvárja az ACK-t.
SYN-RECEIVED	A TCP szerver megkapja az ACK-t.
LÉPTETT (telepítve)		ACK érkezett, kapcsolat megszakadt.

10.4. táblázat Kliens állapot szekvencia

Ha a partnerek egyidejűleg próbálnának kapcsolódni egymáshoz (ami rendkívül ritka), mindegyik átmenne a ZÁRVA, SZIN-KÜLDÉS, SZIN-RECEIVED és LÉTESÍTETT állapotokon.

A kapcsolat végoldalai LÉTESÍTETT állapotban maradnak mindaddig, amíg az egyik oldal meg nem kezdődik záró kapcsolatokat FIN szegmens küldésével. A normál zárás során a lezárást kezdeményező fél a 10.5. táblázatban látható állapotokon megy keresztül. Társa a 10.6. táblázatban látható állapotokon megy keresztül.

10.5. táblázat A kapcsolatot lezáró fél állapotsorrendje

Záró oldalállapotok	Esemény	Leírás
ALAPÍTOTT	Helyi alkalmazás a kapcsolat lezárását kéri.
	A TCP FIN / ACK üzenetet küld.
FIN-WAIT-1		A lefedő fél a partner válaszát várja. Ne feledje, hogy továbbra is érkezhetnek új adatok a partnertől.
	A TCP ACK-t kap.
FIN-WAIT-2		A záró oldal ACK-t kapott a partnertől, de a FIN még nem érkezett meg. A záró oldal FIN-t vár, elfogadva a bejövő adatokat.
	A TCP FIN / ACK üzenetet kap.
	ACK-t küld.
IDŐ-VÁR		A kapcsolat határozatlan állapotban van fenntartva, hogy lehetővé tegye a duplikált adatok vagy a hálózaton még meglévő duplikált FIN-k megérkezését vagy megszakítását. A várakozási idő kétszerese a szegmens maximális élettartamának becsült értékének.
ZÁRVA

10.6. táblázat Partnerállapotok sorozata a kapcsolat lezárásához

Partner státusz	Esemény	Leírás
ALAPÍTOTT	A TCP FIN / ACK üzenetet kap.
ZÁR-VÁR		FIN megérkezett.
	A TCP ACK-t küld.
		A TCP megvárja, amíg az alkalmazása lezárja a kapcsolatot. Ezen a ponton az alkalmazás meglehetősen nagy mennyiségű adatot tud küldeni.
	A helyi alkalmazás kezdeményezi a kapcsolat lezárását.
	A TCP FIN / ACK üzenetet küld.
LAST-ACK		A TCP az utolsó ACK-re vár.
	A TCP ACK-t kap.
ZÁRVA		Minden kapcsolati információ eltávolítva.

10.17.1 A TCP-kapcsolat állapotának elemzése

Parancs netstat -an lehetővé teszi a kapcsolat aktuális állapotának ellenőrzését. Az alábbiakban láthatók a kapcsolatok állapotaiban figyel, indítás, alapítás, bezárásés idő-várás.

Vegye figyelembe, hogy a csatlakozási port száma minden helyi és külső cím végén szerepel. Látható, hogy van TCP-forgalom mind a bemeneti, mind a kilépési sorhoz.

Pro Recv-Q Send-Q Helyi cím Külföldi cím (állam)

Tcp 0 0 128.121.50.145.25 128.252.223.5.1526 SYN_RCVD

Tcp 0 0 128.121.50.145.25 148.79.160.65.3368 LÉPTETT

Tcp 0 0 127.0.0.1.1339 127.0.0.1.111 TIME_WAIT

Tcp 0 438 128.121.50.145.23 130.132.57.246.2219 LÉPTETÉS

Tcp 0 0 128.121.50.145.25 192.5.5.1.4022 TIME_WAIT

Tcp 0 0 128.121.50.145.25 141.218.1.100.3968 TIME_WAIT

Tcp 0 848 128.121.50.145.23 192.67.236.10.1050 LÉPTETÉS

Tcp 0 0 128.121.50.145.1082 128.121.50.141.6000 LÉPTETÉS

Tcp 0 0 128.121.50.145.1022 128.121.50.141.1017 LÉPTETÉS

Tcp 0 0 128.121.50.145.514 128.121.50.141.1020 CLOSE_WAIT

Tcp 0 1152 128.121.50.145.119 192.67.239.23.3572 LÉPTETT

Tcp 0 0 128.121.50.145.1070 192.41.171.5.119 TIME_WAIT

Tcp 579 4096 128.121.50.145.119 204.143.19.30.1884 LÉPTETÉS

Tcp 0 0 128.121.50.145.119 192.67.243.13.3704 LÉPTETT

Tcp 0 53 128.121.50.145.119 192.67.236.218.2018 FIN_WAIT_1

Tcp 0 0 128.121.50.145.119 192.67.239.14.1545 LÉPTETÉS

10.18 Végrehajtási megjegyzések

A TCP-t kezdettől fogva úgy tervezték, hogy együttműködjön a különböző gyártók hálózati berendezéseivel. A TCP specifikáció nem határozza meg pontosan, hogy a belső megvalósítási struktúráknak hogyan kell működniük. Ezeket a kérdéseket a fejlesztőkre kell bízni, hogy megtalálják a legjobb mechanizmusokat az egyes megvalósításokhoz.

Még az RFC 1122 is (dokumentum Gazdakövetelmények - host követelmények) elegendő teret hagy a variációnak. A megvalósított funkciók mindegyike meg van jelölve egy bizonyos szintű kompatibilitási szinttel:

■ MÁJUS (megengedett)

■ NEM KELL

Sajnos néha vannak olyan termékek, amelyek nem teljesítik a MUST követelményeket. Ennek eredményeként a felhasználók a teljesítmény csökkenésével kapcsolatos kellemetlenségeket tapasztalják.

Néhány helyes végrehajtási gyakorlatot nem vesznek figyelembe a szabványok. Például a biztonság javítása lehetséges a jól ismert portok privilegizált rendszerfolyamatok általi használatának korlátozásával, ha a helyi operációs rendszer ez a módszer támogatott. A teljesítmény maximalizálása érdekében az implementációknak a lehető legkevesebbet kell másolni és mozgatni az elküldött vagy visszakeresett adatokat.

Szabványos API meghatározatlan(valamint a biztonsági politika), hogy legyen szabad tevékenységi terület a különböző készletekkel való kísérletezéshez szoftver eszközök... Ez azonban azt eredményezheti, hogy az egyes platformokon különböző API-k kerülnek felhasználásra, és megakadályozza az alkalmazásszoftverek platformok közötti áthelyezését.

Valójában a fejlesztők eszközkészleteiket a Berkeley Socket API-jára alapozzák. A programozói felület jelentősége megnőtt a WINSock (Windows Socket) megjelenésével, ami az új alkalmazások gyors növekedéséhez vezetett. asztali rendszerek amely a TCP / IP veremmel kompatibilis bármely WINSock interfész tetején futhat.

10.19 További olvasmányok

Az eredeti TCP-szabványt az RFC 793 határozza meg. A frissítésekkel, javításokkal és együttműködési követelményekkel az RFC 1122 foglalkozik. Kern (Kash) és Partridge (Partridge) közzétett egy cikket Az oda-vissza becslések javítása a megbízható szállítási protokollokban A magazinban Az ACM SIGCOMM 1987. évi közleménye. Jacobson cikke Torlódások elkerülése és ellenőrzése megjelent Az ACM SIGCOMM 1988 Workshop anyaga. Jacobson több RFC-t is kiadott a teljesítményjavító algoritmusok felülvizsgálatára.

Utazás hálózati protokollokon keresztül.

A TCP és az UDP is protokoll szállítóréteg... Az UDP egy kapcsolat nélküli protokoll nem biztonságos csomagküldéssel. A TCP (Transmission Control Protocol) egy kapcsolatorientált protokoll garantált csomagszállítással. Először kézfogás következik (Hello. | Hello. | Csevegés? | Gyerünk.), Utána a kapcsolat létrejöttnek minősül. Továbbá ezen a kapcsolaton keresztül a csomagokat oda-vissza küldik (beszélgetés van), és ellenőrzi, hogy a csomag eljut-e a címzetthez. Ha a csomag elveszett, vagy megérkezett, de kis ellenőrzőösszeggel, akkor újra elküldi ("ismétlés, nem hallottam"). Így a TCP megbízhatóbb, de a megvalósítás szempontjából bonyolultabb, ezért több órajelet/memóriát igényel, ami a mikrokontrollereknél nem a legkevésbé fontos. A TCP-t használó alkalmazásprotokollok példái közé tartozik az FTP, a HTTP, az SMTP és sok más.

TL; DR

A HTTP (Hypertext Transfer Protocol) egy alkalmazásprotokoll, amelyen keresztül a szerver oldalakat küld a böngészőnknek. A HTTP már mindenütt jelen van A világháló információkért a weboldalakról. A képen egy OS-es mikrokontroller lámpája látható, amelyben a színek a böngészőn keresztül állíthatók be.

A HTTP protokoll szöveges és meglehetősen egyszerű. Valójában így néz ki a GET metódus, amelyet a netcat segédprogram a szerver helyi IPv6-címére küldött jelzőfényekkel:

~ $ nc fe80 :: 200: e2ff: fe58: b66b% mazko 80<

A HTTP-módszer általában egy rövid, nagybetűs angol szó, megkülönböztetve a kis- és nagybetűket. Minden szervernek támogatnia kell legalább a GET és a HEAD metódusokat. A GET és HEAD metódusok mellett gyakran használják a POST, PUT és DELETE metódusokat. A GET metódus a megadott erőforrás tartalmának lekérésére szolgál, esetünkben itt GET / b HTTP / 1.0 ahol a / b elérési út felelős a színért (kék). Szerver válasz:

HTTP / 1.0 200 OK Szerver: Contiki / 2.4 http://www.sics.se/contiki/ Csatlakozás: bezárás Cache-Control: nincs gyorsítótár, nincs áruház, újra kell érvényesíteni Pragma: nincs gyorsítótár Lejár: 0 Tartalom- típusa: szöveg / html

A piros KI

A zöld KI van kapcsolva

A kék be van kapcsolva

Az állapotkód (nálunk 200) a szerver válasz első sorának része. Ez egy háromjegyű egész szám. Az első számjegy a feltétel osztályát jelöli. A válaszkódot általában egy magyarázó mondat követi angolul, szóközzel elválasztva, amely elmagyarázza a személynek ennek a konkrét válasznak az okát. Nálunk a szerver hiba nélkül működött, minden egy csomóban (OK).

A kérés és a válasz is tartalmaz fejlécet (minden sor külön fejléc mező, a név-érték pár kettősponttal van elválasztva). A fejlécek üres sorral végződnek, amely után mehet az adatok.

A böngészőm nem hajlandó megnyitni a helyi IPv6-címet, ezért a mikrokontroller firmware-ébe egy további cím kerül beírásra, és ugyanazt az előtagot kell hozzárendelni a szimulátor virtuális hálózati interfészéhez is:

~ $ sudo ip addr add abcd :: 1/64 dev mazko # linux ~ $ netsh interfész ipv6 cím beállítása mazko abcd :: 1 # windows ~ $ curl http: //

Az ezeket a protokollokat a vállalati hálózaton megvalósító szerverek IP-címet, átjárót, hálózati maszkot, névszervereket és még nyomtatót is biztosítanak a kliens számára. A felhasználóknak nem kell manuálisan konfigurálniuk gazdagépeiket a hálózat használatához.

A QNX Neutrino operációs rendszer egy másik AutoIP nevű plug-and-play protokollt valósít meg, amely az IETF automatikus konfigurációs bizottság projektje. Ezt a protokollt kis hálózatokon használják IP-címek hozzárendelésére a link-local gazdagépekhez. Az AutoIP protokoll önállóan határozza meg a csatorna helyi IP-címét, más gazdagépekkel folytatott tárgyalási sémát használva anélkül, hogy kapcsolatba lépne egy központi szerverrel.

PPPoE protokoll használata

A PPPoE az Etherneten keresztüli Point-to-Point Protocol rövidítése. Ez a protokoll beágyazza az adatokat áthidaló Ethernet-hálózaton keresztüli továbbításhoz.

A PPPoE egy specifikáció az Ethernet-felhasználók internethez való csatlakoztatására szélessávú kapcsolaton, például bérelt vonalon, vezeték nélküli eszközön vagy kábelmodemen keresztül. A PPPoE és a szélessávú modem használata a helyi számítógépes hálózat felhasználói számára egyéni hitelesített hozzáférést biztosít a nagy sebességű adathálózatokhoz.

A PPPoE egyesíti az Ethernetet a PPP-vel, hogy hatékonyan hozzon létre külön kapcsolatot egy távoli szerverrel minden felhasználó számára. A hozzáférés-szabályozás, a kapcsolat elszámolása és a szolgáltató kiválasztása felhasználó-, nem pedig gazdagép-specifikus. Ennek a megközelítésnek az az előnye, hogy ehhez sem a telefontársaságnak, sem az internetszolgáltatónak nem kell külön támogatást nyújtania.

A betárcsázós kapcsolatoktól eltérően a DSL és a kábelmodemes kapcsolatok mindig aktívak. Mivel a fizikai kapcsolatot egy távoli szolgáltatóval több felhasználó osztja meg, olyan elszámolási módszerre van szükség, amely regisztrálja a forgalom küldőit és célállomásait, és díjat számít fel a felhasználóknak. A PPPoE lehetővé teszi a kommunikációban részt vevő felhasználó és távoli gazdagép számára, hogy megtanulják egymás hálózati címét a kezdeti csere során. érzékelés(felfedezés). Miután létrejött egy munkamenet egy egyéni felhasználó és egy távoli hely (például egy internetszolgáltató) között, a munkamenet nyomon követhető az elhatárolások szempontjából. Sok otthonban, szállodában és vállalatnál az internet-hozzáférést digitális előfizetői vonalakon osztják meg Ethernet és PPPoE technológia segítségével.

A PPPoE kapcsolat egy kliensből és egy szerverből áll. A kliens és a szerver bármilyen interfészen működik, amely közel áll az Ethernet specifikációhoz. Ez az interfész IP-címek kibocsátására szolgál a klienseknek, és ezeket az IP-címeket a felhasználókhoz és opcionálisan a munkaállomásokhoz köti, a csak munkaállomásos hitelesítés helyett. A PPPoE szerver pont-pont kapcsolatot hoz létre minden ügyfél számára.

PPPoE munkamenet létrehozása

PPPoE munkamenet létrehozásához használja a szolgáltatástpppoed... Modulio-pkt- * nPPPoE protokoll szolgáltatásokat nyújt. Először futni kellio-pkt- *val velmegfelelő sofőr... Példa: