Azok a kiszolgálók, amelyek végrehajtják ezeket a protokollokat vállalati hálózat, biztosítson az ügyfélnek egy IP -címet, átjárót, hálózati maszkot, névszervereket és még nyomtatót is. A felhasználóknak nem kell manuálisan konfigurálniuk a gazdagépeket a hálózat használatához.

A QNX Neutrino operációs rendszer egy másik plug and play protokollt valósít meg, AutoIP néven, amely az IETF vázlata automatikus hangolás... Ezt a protokollt kis hálózatokon IP-címek hozzárendelésére használják a hivatkozás-lokális állomásokhoz. Az AutoIP protokoll önállóan határozza meg a csatorna helyi IP -címét, tárgyalási séma segítségével más gazdagépekkel és anélkül, hogy kapcsolatba lépne egy központi szerverrel.

A PPPoE protokoll használata

A PPPoE jelentése Point-to-Point Protocol over Ethernet. Ez a protokoll az áthidalott Ethernet hálózaton keresztül történő adattovábbítást foglalja magában.

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

A PPPoE egyesíti az Ethernetet a PPP -vel, hogy hatékonyan hozzon létre külön kapcsolatot a távoli szerverrel minden felhasználó számára. A hozzáférés-szabályozás, a kapcsolat-elszámolás és a szolgáltatóválasztás felhasználó-specifikus, nem 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 telefonos kapcsolatokkal ellentétben a DSL és a kábelmodem kapcsolatok mindig aktívak. Mivel a távoli szolgáltatóhoz való fizikai kapcsolatot több felhasználó is megosztja, olyan elszámolási módszerre van szükség, amely regisztrálja a forgalom feladóit és célállomásait, és a felhasználókat is felszámítja. A PPPoE lehetővé teszi a kommunikációban részt vevő felhasználóknak és távoli állomásoknak, hogy megtanulják egymás hálózati címeit a kezdeti csere során. érzékelés(felfedezés). Egy egyéni felhasználó és távoli csomópont(például az internetszolgáltatója által) beállítva, ez a munkamenet nyomon követhető töltés céljából. Sok otthonban, szállodában és vállalatban az internet -hozzáférés megosztott digitális előfizetői vonalakon Ethernet és PPPoE használatával.

A PPPoE kapcsolat kliensből és szerverből áll. A kliens és a szerver bármilyen interfészen keresztül működik, amely közel áll az Ethernet specifikációkhoz. Ez az interfész arra szolgál, hogy IP -címeket bocsásson ki az ügyfeleknek, és ezeket az IP -címeket a felhasználókhoz, illetve opcionálisan a munkaállomásokhoz kösse, csak hitelesítésen alapuló munkaállomás... A PPPoE szerver pont-pont kapcsolatot hoz létre minden ügyfél számára.

PPPoE szekció létrehozása

A 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ő vezető... Példa:

Ügyfél-szerver alkalmazás a TCP streaming aljzaton

A következő példában a TCP segítségével rendezett, megbízható kétirányú bájtfolyamokat biztosítunk. Építsünk egy komplett alkalmazást, amely tartalmaz egy ügyfelet és egy szervert. Először bemutatjuk, hogyan kell szervert építeni a TCP streaming aljzatokon, majd egy kliens alkalmazást a szerver 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 szinkron módon épül fel, ezért a szál végrehajtása blokkolva van, amíg a szerver beleegyezik, hogy csatlakozzon az ügyfélhez. Ez az alkalmazás egy egyszerű szervert mutat be, amely válaszol az ügyfélre. Az ügyfél úgy fejezi be a kapcsolatot, hogy üzenetet küld a szervernek .

TCP szerver

A szerverstruktúra létrehozását a következő funkcionális diagram mutatja be:

Itt található a SocketServer.cs program teljes kódja:

// SocketServer.cs a System használatával; a System.Text használatával; a System.Net használatával; a System.Net.Sockets használatával; namespace SocketServer (class Program (static void Main (string args)) // // Állítsa be a helyi végpontot az IPHostEntry foglalathoz ipHost = Dns.GetHostEntry ("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint = új IPEnd ; // Tcp / Ip foglalat létrehozása sListener. Hallgassa meg (10); // Kezdje el hallgatni a kapcsolatokat, miközben (true) (Console.WriteLine ("Várakozás a kapcsolatra a (0) porton", ipEndPoint); // A program leáll, vár a bejövő kapcsolatra Socket handler = sListener.Accept (); string data = null; // Vártunk egy ügyfelet, aki megpróbál kapcsolatba lépni velünk byte byte = new byte; int bytesRec = handler.Recept (byte); data + = Encoding.UTF8.GetString (bytes , 0, bytesRec); // Adatok megjelenítése a konzolon Console.Write ("Fogadott szöveg: " + adatok +" \ n \ n "); // Válasz küldése az ügyfélnek \ string answer = "Köszönjük a kérést a" + data.Length.ToString () + "karakterekben; byte msg = Encoding.UTF8.GetBytes (válasz); handler.Send (msg); if (data.IndexOf (" ")> -1) (Console.WriteLine (" A szerver befejezte a kapcsolatot az ügyféllel. "); Break;) handler.Shutdown (SocketShutdown.Both); handler.Close ();)) catch (Exception ex) (Console.WriteLine (ex.ToString ());) végül (Console.ReadLine ();))))

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

Az első lépés egy helyi végpont létrehozása az aljzathoz. Mielőtt megnyitná az aljzatot a kapcsolatok figyeléséhez, elő kell készítenie egy helyi végpontcímet. Az egyedi TCP / IP szolgáltatáscímet a gazdagép IP -címének és a szolgáltatás végpontját létrehozó szolgáltatásport -számnak a kombinációja határozza meg.

A Dns osztály olyan módszereket kínál, amelyek visszaadják az eszközön támogatott hálózati címekről szóló információkat helyi hálózat... Ha egy LAN -eszköznek több hálózati címe is van, a Dns osztály az összes hálózati címre vonatkozó információt ad vissza, és az alkalmazásnak ki kell választania a kiszolgálni kívánt tömbből a megfelelő címet.

Hozzon létre egy IPEndPoint -pontot a kiszolgálóhoz a Dns.Resolve () metódus első gazdagép IP -címének kombinálásával a port számával:

IPHostEntry ipHost = Dns.GetHostEntry ("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint = új IPEndPoint (ipAddr, 11000);

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

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

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

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

Dgram

Támogatja a datagramokat. A Dgram érték megköveteli, hogy a címcsalád -paraméterben Udp -t adjon meg a protokoll típusához és az InterNetwork -hez.

Nyers

Támogatja az alapul szolgáló szállítási protokoll elérését.

Folyam

Támogatja a streaming aljzatokat. A Folyamat értéke megköveteli a Tcp megadását a protokoll típusához.

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

A következő lépés az aljzat hozzárendelése a módszerrel Kötés ()... Amikor a konstruktor kinyit egy foglalatot, nem rendel hozzá nevet, csak egy leíró van fenntartva. A Bind () metódust hívják meg, hogy nevet rendeljen a szerver foglalathoz. Ahhoz, hogy a kliens socket azonosítani tudja a TCP streaming socketet, a szerverprogramnak meg kell neveznie socketjét:

SListener.Bind (ipEndPoint);

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

Most, miután létrehozott egy foglalatot, és hozzárendelt egy nevet, meghallgathatja a bejövő üzeneteket a módszer használatával Hallgat ()... Figyelő állapotban az aljzat várja a bejövő csatlakozási kísérleteket:

SListener.Figyelj (10);

A paraméter határozza meg hátralék jelezve maximális szám a várólistán függőben lévő kapcsolatok. A megadott kódban a paraméter értéke legfeljebb tíz kapcsolat felhalmozását teszi lehetővé a sorban.

Figyelő állapotban készen kell állnia arra, hogy hozzájáruljon az ügyféllel való kapcsolathoz, amelyhez a módszert használják Elfogad ()... Ez a módszer megszerzi az ügyfélkapcsolatot, és befejezi az ügyfél / szerver név társítását. Az Elfogadás () módszer blokkolja a hívó fél szálát, amíg meg nem érkezik a kapcsolat.

Az Accept () metódus lekéri az első csatlakozási kérelmet a függőben lévő kérési sorból, és létrehoz egy új foglalatot annak kezelésére. Bár új foglalat jön létre, az eredeti foglalat továbbra is hallgat, és többszálas lehet, hogy több csatlakozási kérelmet fogadjon az ügyfelektől. Egyetlen kiszolgálóalkalmazás sem zárhatja le a hallgatási aljzatot. Továbbra is működnie kell az Elfogadás módszerrel létrehozott foglalatok mellett a bejövő ügyfélkérések kezelésére.

Míg (igaz) (Console.WriteLine ("Várakozás a kapcsolatra a (0) porton", ipEndPoint); // A program megáll, vár a bejövő kapcsolatra Socket handler = sListener.Accept ();

Miután az ügyfél és a szerver kapcsolatot létesített egymással, a módszerek használatával üzeneteket küldhet és fogadhat Küld ()és Fogadás () Socket osztály.

A Send () metódus kimenő adatokat ír a foglalatba, amelyhez a kapcsolat létrejött. A Receive () módszer bejövő adatokat olvas be egy stream aljzatba. TCP-alapú rendszer használatakor kapcsolatot kell létrehozni az aljzatok között a Send () és a Receive () metódus végrehajtása előtt. A két interakciós entitás közötti pontos protokollt előre meg kell határozni, hogy a kliens- és szerveralkalmazások ne blokkolják egymást, ne tudják, ki küldje el először az adataikat.

Amikor a kiszolgáló és az ügyfél közötti adatcsere befejeződött, a módszerekkel le kell zárnia a kapcsolatot Leállitás ()és Bezárás ():

Handler.Shutdown (SocketShutdown.Both); kezelő.Close ();

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

Az aljzat bezáródik a Close () metódus meghívásakor, amely szintén az aljzat Connected tulajdonságát állítja hamisra.

Ügyfél a TCP -n

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

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

A TCP és az UDP egyaránt szállítási réteg protokoll. 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 csomagküldéssel. Először van egy kézfogás (Helló. | Helló. | Beszélgessünk? | Gyerünk.), Amely után a kapcsolat létrejöttnek tekinthető. Továbbá csomagokat küldünk oda -vissza ezen a kapcsolaton keresztül (beszélgetés van), és ellenőrizzük, hogy a csomag elérte -e a címzettet. Ha a csomag elveszett, vagy megérkezett, de egy kis ellenőrző összeggel, akkor újra elküldi ("ismételje meg, nem hallotta"). Így a TCP megbízhatóbb, de a megvalósítás szempontjából bonyolultabb, és ennek megfelelően több órát / memóriát igényel, ami a legkevésbé fontos a mikrovezérlők számára. A TCP -t használó alkalmazásprotokollok például az FTP, a HTTP, az SMTP és még sok más.

TL; DR

A HTTP (Hypertext Transfer Protocol) egy olyan alkalmazásprotokoll, amelyen keresztül a szerver oldalakat küld a böngészőnknek. A HTTP ma már mindenhol jelen van a világhálón, hogy információkat szerezzen be a webhelyekről. A képen egy mikrokontroller fénye látható, fedélzeti operációs rendszerrel, amelyben a színek a böngészőn keresztül vannak beállítva.

A HTTP protokoll szöveges és meglehetősen egyszerű. Valójában ez így néz ki GET módszer a netcat segédprogram küldte az izzószerver helyi IPv6 címére:

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

A HTTP módszer általában egy rövid, nagybetűs angol szó, kis- és nagybetűk megkülönböztetése. Minden szervernek támogatnia kell legalább a GET és a HEAD módszereket. A GET és a HEAD metódusok mellett gyakran használják a POST, PUT és DELETE módszereket. A GET módszerrel kérhetjük a megadott erőforrás tartalmát, esetünkben itt a GET / b HTTP / 1.0, ahol a / b útvonal felelős a színért (kék). Szerver válasza:

HTTP/ 1.0 200 OK Szerver: Contiki/ 2.4 http://www.sics.se/contiki/ Kapcsolat: bezár Cache-Control: nincs gyorsítótár, nincs tárolás, újra kell érvényesíteni Pragma: nincs gyorsítótár Lejárat: 0 Tartalom- típus: text / html

A piros ki van kapcsolva

A zöld ki van kapcsolva

A kék be van kapcsolva

Az állapotkód (200 van) 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 jelzi. A válaszkódot általában magyarázó magyar mondat követi, szóközzel elválasztva, amely elmagyarázza a személynek a válasz okát. Esetünkben a szerver hibamentesen működött, minden csomós volt (OK).

A kérés és a válasz is tartalmaz fejléceket (minden sor külön fejlécmező, a név-érték pár kettősponttal elválasztott). A fejlécek üres sorral végződnek, utána mehetnek az adatok.

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

~ $ sudo ip addr add abcd :: 1/64 dev mazko # linux ~ $ netsh interface ipv6 set address mazko abcd :: 1 # windows ~ $ curl http: //

A TCP természetesen integrálódik a kliens / szerver környezetbe (lásd 10.1. Ábra). Szerver alkalmazás hallgat(figyelje) a bejövő csatlakozási kérelmeket. Például a WWW, a File Transfer vagy a Terminal Access szolgáltatások figyelik az ügyfelek kéréseit. A kommunikációt a TCP -ben a megfelelő rutinok indítják el, amelyek kezdeményezik a kapcsolatot a szerverrel (lásd a socket programozási felület 21. fejezetét).

Rizs. 10.1. Az ügyfél felhívja a szervert.

A valóságban az ügyfél lehet egy másik szerver. Például a levelezőszerverek csatlakozhatnak más levelezőszerverekhez, hogy továbbítsák az e-mail üzeneteket a számítógépek között.

10.2 TCP fogalmak

Milyen formában kell az alkalmazásoknak adatokat küldeniük TCP -n keresztül? Hogyan továbbítja a TCP az adatokat az IP -re? Hogyan azonosítják a küldő és fogadó TCP protokollok az alkalmazások és a megvalósításhoz szükséges adatelemek közötti kapcsolatot? Mindezekre a kérdésekre választ kap a következő szakaszokban, amelyek a TCP alapfogalmait írják le.

10.2.1 Bemeneti és kimeneti adatfolyamok

Fogalmi a kapcsolatmodell feltételezi, hogy az alkalmazás adatfolyamot küld a társalkalmazásnak. Ugyanakkor képes adatfolyamot fogadni csatlakozási partnerétől. A TCP biztosítja teljes duplex(full duplex) üzemmód, amelyben egyszerre két patak adatok (lásd 10.2. ábra).

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

10.2.2 Szegmensek

A TCP az alkalmazást elhagyó adatfolyamot alakíthatja át adatgramokban való elhelyezésre alkalmas formává. Hogyan?

Az alkalmazás TCP -ben továbbítja az adatokat, és ez a protokoll beteszi azokat kimeneti puffer(puffer küldése). Ezután a TCP kivág egy darab adatot a pufferből, és fejlécet ad hozzá (ebben az esetben szegmensek- szegmens). Ábrán. A 10.3 mutatja, hogyan származnak adatok kimeneti puffer A TCP szegmensekbe van csomagolva. A TCP külön adatgramként továbbítja a szegmenst az IP -hez. Az adatok megfelelő hosszúságú darabokra csomagolása biztosítja az adatok hatékony elküldését, így a TCP megvárja, amíg a megfelelő mennyiségű adat megjelenik a kimeneti pufferben, mielőtt létrehoz egy szegmenst.

Rizs. 10.3 TCP szegmens létrehozása

10.2.3 Kidobás

A nagy mennyiségű adatot azonban gyakran lehetetlen alkalmazni a valós alkalmazásokhoz. Például, amikor egy végfelhasználói ügyfélprogram interaktív munkamenetet kezdeményez a következővel: távoli szerver, akkor a felhasználó csak parancsokat ír be (ezt követően nyomja meg a gombot Visszatérés).

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

Ha megnézi a műveleteket egy interaktív munkamenetben, sok szegmenst találhat kevés adatokkal, és ráadásul szinte minden adatszegmensben megtalálhatók a dudorok. Azonban a push nem alkalmazható a fájlátvitel során (kivéve az utolsó szegmenst), és a TCP képes lesz a leghatékonyabban adatokat csomagolni szegmensekbe.

10.2.4 Sürgős adatok

Az alkalmazástovábbítási modell feltételezi a rendelt bájtfolyam alkalmazását, amely a célállomásra utazik. Ismét az interaktív munkamenetre hivatkozva tegyük fel, hogy a felhasználó megnyomta a gombot Figyelem(figyelem) ill szünet(megszakítani). 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 adatok) a szegmensben található speciális információkat asként jelöli sürgős. Ezzel a TCP tájékoztatja társát, hogy a szegmens sürgős adatokat tartalmaz, és jelezheti, hol van. A partnernek a lehető leghamarabb továbbítania kell ezt az információt a rendeltetési alkalmazáshoz.

10.2.5 Alkalmazásportok

Az ügyfélnek azonosítania kell azt a szolgáltatást, amelyhez hozzá kíván férni. Ez a gazdagép 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 és 65535 között van. A 0 és 1023 közötti tartományban lévő portok jól ismertek, és a szabványos szolgáltatások elérésére szolgálnak.

A 10.1. Táblázat számos példát tartalmaz a jól ismert portokra és a hozzájuk tartozó alkalmazásokra. Szolgáltatások Dobd el(9. port) és chargen(19. port) az UDP -ből már ismert szolgáltatások TCP -verziói. Ne feledje, hogy a TCP 9. port forgalma teljesen elszigetelt az UDP 9. port forgalmától.

10.1. Táblázat Általánosan ismert TCP portok és azok megfelelő alkalmazásai

Kikötő	Alkalmazás	Leírás
9	Dobd el	Az összes bejövő adat törlése
19	Chargen	Szimbólumgenerátor. Karakterfolyam cseréje
20	FTP-adatok	FTP adattovábbító port
21	FTP	Port az FTP beszélgetéshez
23	TELNET	Port a távoli Telnet regisztrációhoz
25	SMTP	SMTP port
110	POP3	Levélszolgáltatás lekérése 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 kéri az operációs rendszert, hogy rendeljen hozzá egy nem használt és nem fenntartott portot. A kapcsolat végén az ügyfél köteles ezt a portot visszaadni, ezt követően egy másik ügyfél újra használhatja a portot. Mivel több mint 63 000 TCP-port található a nem lefoglalt számok tárában, az ügyfélport-korlátozások figyelmen kívül hagyhatók.

10.2.6 socket címek

Mint már tudjuk, az IP -cím és a port kommunikációjának kombinációját hívják foglalat. A TCP -kapcsolatot teljes mértékben azonosítja a kapcsolat mindkét végén található foglalatcím. Ábrán. A 10.4 ábra a kapcsolatot mutatja a socketben lévő kliens (128.36.1.24, port = 3358) és a socketben lévő szerver között (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ímet. Később látni fogjuk, hogy a forrás- és a célportszámok a TCP szegmens fejlécében vannak feltüntetve.

Általában egy szerver képes egyszerre több ügyfelet kezelni. A szerver egyedi socket címei egyszerre kerülnek hozzá az összes ügyfélhez (lásd 10.5. Ábra).

Rizs. 10.5. Több kliens csatlakozik a szerver socket címekhez

Mivel a datagramma egy TCP kapcsolati szegmenst tartalmaz, amelyet IP -címek és portok azonosítanak, a szerver nagyon könnyen nyomon követheti a 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ó szállítására használnak, miközben fenntartják a továbbítási sorrendet, és elkerülik a veszteséget vagy a többszörözést.

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 biztosítása érdekében. A TCP számozási rendszer kissé szokatlan: minden egyes kapcsolat továbbítva oktett sorszámmal rendelkezik. A TCP szegmens fejléce sorszámot tartalmaz ennek a szegmensnek az első adat oktettje.

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

A vevő TCP alaposan figyeli a bejövő sorszámokat, hogy megbizonyosodjon arról, hogy az adatok következetesen érkeznek, és nincsenek hiányzó részek. Mivel az ACK -k véletlenszerűen elveszhetnek vagy késleltethetők, ismétlődő szegmensek érkezhetnek a címzetthez. A sorszámok lehetővé teszik az ismétlődő adatok azonosítását, amelyeket ezután elvetnek.

Ábrán. A 10.6 a TCP időtúllépés és az újraküldés egyszerűsített pillantását mutatja.

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

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

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

Rizs. 10.7. Kezdeti értékek a TCP fejlécmezőkben

Egy apró részletet meg kell jegyezni. Tegyük fel, hogy a TCP 1 -től 50 -ig terjedő bájtokat küldött, és nincsenek adatok. Ha adatokat kapnak egy partnertől, a TCP köteles visszaigazolni az átvételét, amelyhez fejlécet küld, amelyhez nincsenek adatok csatlakoztatva. Ez a fejléc természetesen tartalmazza az ACK értéket. A sorozat mező tartalmazza az 51 értéket, azaz a következő bájt száma szándékozik TCP küldése. Amikor a TCP elküldi a következő adatokat, az új TCP fejléc értéke 51 lesz a sorozat mezőben.

10.4 Kapcsolat létrehozása

Hogyan kapcsolódik a két alkalmazás egymáshoz? A kommunikáció előtt mindegyikük meghív egy alprogramot, hogy memóriablokkot képezzen, amelyet a kapcsolat TCP és IP paramétereinek tárolására használnak, például socket címek, aktuális sorszám, élettartam kezdeti értéke stb.

A szerveralkalmazás megvárja, amíg megjelenik egy ügyfél, amely hozzáférni akar a szerverhez, kérést küld összetett(connect) azonosítja a szerver IP -címét és portját.

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

10.4.1 Csatlakozási parancsfájl

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

A kapcsolat beállítása során a partnerek három fontos információt cserélnek:

1. Az adatok fogadására szolgáló puffertér mennyisége

2. A bejövő szegmensben tárolt maximális adatmennyiség

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

Vegye figyelembe, hogy mindkét oldal az 1. és 2. műveletet alkalmazza a jelzéshez azokat a korlátokat, amelyeken belül a másik fél működni fog. A személyi számítógépek kis fogadási pufferrel, a szuperszámítógép pedig hatalmas pufferrel rendelkezhetnek. A személyi számítógép memóriastruktúrája 1 KB -ra korlátozhatja a bejövő adatrészeket, és a szuperszámítógépet nagy szegmensekkel vezérelheti.

A TCP / IP skálázhatóság szempontjából fontos tulajdonság a másik fél adatküldésének szabályozása.

Ábrán. A 10.8 egy példát mutat egy kapcsolati szkriptre. Nagyon egyszerű kezdeti sorszámok kerülnek bemutatásra, hogy ne terheljék túl a rajzot. Vegye figyelembe, hogy ezen az ábrán az ügyfél nagyobb szegmenseket tud fogadni, mint a szerver.

Rizs. 10.8. Kapcsolat létesítése

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

1. A szerver inicializálva van és készen áll az ügyfelekkel való kapcsolatra (ezt az állapotot passzív nyitottnak hívják).

2. Az ügyfél felkéri a TCP -t, hogy nyisson kapcsolatot a szerverrel a megadott IP -címen és porton (ezt az állapotot aktív nyitottnak nevezik).

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

4. Amikor egy SYN megérkezik, a szerver TCP fogadja enyém kezdő sorszám (3000). Küld egy SYN szegmenst, amely tartalmazza a kezdő sorszámot (3000), az ACK 1001 -et (ami azt jelenti, hogy az ügyfél által küldött első bájt 1001 -es számozású), a fogadási ablak méretét (4K) és a legnagyobb szegmenst, amelyet a szerver fogadni tud (1024 bájt) ).

5. A kliens TCP, miután megkapta a SYN / ACK üzenetet a szervertől, visszaküldi az ACK 3001 -et (a szerver által küldött adatok első bájtját 3001 -nek kell számozni).

6. Az ügyfél TCP utasítja alkalmazását a kapcsolat megnyitására.

7. A szerver TCP, miután megkapta az ACK üzenetet az ügyfél TCP -től, tájékoztatja alkalmazását a kapcsolat megnyitásáról.

Az ügyfél és a szerver bejelentik a fogadott adatokra vonatkozó szabályaikat, szinkronizálják sorszámukat és készen állnak az adatok cseréjére. A TCP specifikáció egy másik (nem túl sikeres) forgatókönyvet is lehetővé tesz, amikor a társalkalmazá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érése paramétereket is megadhat azokhoz az IP -adatgramokhoz, amelyek az adott kapcsolat adatait hordozzák. Ha nincs megadva konkrét paraméterérték, akkor az alapértelmezett érték kerül alkalmazásra.

Például egy alkalmazás kiválaszthatja a kívánt értéket az IP prioritáshoz vagy a szolgáltatástípushoz. Mivel a kapcsolt felek mindegyike önállóan határozza meg saját prioritását és a szolgáltatás típusát, elméletileg ezek az értékek eltérhetnek az adatfolyamok különböző irányaiban. Általában a gyakorlatban ugyanazokat az értékeket használják minden csereirányra.

Ha egy alkalmazás biztonsági lehetőségeket használ a kormányzati vagy katonai ügynökségek számára, akkor a kapcsolat végpontjainak mindegyikének azonos 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áromlépcsős megerősítésének befejezése után kezdődik (lásd 10.9. Ábra). A TCP szabvány lehetővé teszi a normál adatoknak a nyugtázási szegmensekbe való beillesztését, de addig nem kerülnek az alkalmazáshoz, 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 szegmenshez tartozik egy ACK mező, amely azonosítja a bájt sorszámát, amelyet várhatóan megkap a kapcsolattól..

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

Az ügyfél által küldött első szegmens 1001 és 2000 közötti bájtokat tartalmaz. Az ACK mezőben 3001 értéket kell tartalmaznia, amely azt jelzi, hogy a szerverről várhatóan mennyi bájt sorszáma van.

A szerver 1000 bájt adatot tartalmazó szegmenssel válaszol az ügyfélnek (3001 -től kezdődően). A TCP fejléc ACK mezője azt jelzi, hogy az 1001–2000 bájt már sikeresen megérkezett, így a következő várható szegmens sorszáma 2001 -nek kell lennie.

Az ügyfél ezután 2001, 3001 és 4001 bájtokkal kezdődő szegmenseket küld ebben a sorrendben. Ne feledje, hogy az ügyfél nem vár ACK -t minden elküldött szegmens után. Az adatokat addig küldik a partnernek, amíg a puffertér megtelik (az alábbiakban látni fogjuk, hogy a címzett nagyon pontosan tudja jelezni a neki küldött adatok mennyiségét).

A szerver megőrzi a sávszélességet egyetlen ACK használatával, jelezve az összes szegmens sikeres továbbítását.

Ábrán. A 10.10 az adatátvitelt mutatja az első szegmens elvesztésekor. Amikor az időtúllépés lejár, a szegmens újraküldésre kerül. Ne feledje, hogy az elveszett szegmens fogadása után a vevő egy ACK -t küld, megerősítve, hogy mindkét szegmens el lett küldve.

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

10.6 Kapcsolat lezárása

A kapcsolat normál leállí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ő esetben:

V:

B:"Jó".

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

V:"Jó".

A következő forgatókönyv is elfogadható (bár ritkán használják):

V:"Végeztem. Nincs több kü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 szervert, ahogy az a kliens / szerver kommunikáció esetében gyakran előfordul. Ebben az esetben, miután a felhasználó belép a munkamenetbe telnet kijelentkezési parancsokat, 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. Egy alkalmazás a szerveren azt mondja a TCP -nek, hogy zárja be a kapcsolatot.

2. A TCP szerver elküldi a FIN szegmenst (Final Segment, FIN), amelyben tájékoztatja társát, hogy nincs több küldendő adat.

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

4. Az ügyfél TCP -je közli alkalmazásával, hogy a szerver le akarja zárni a kapcsolatot.

5. Az ügyfélalkalmazás azt mondja a TCP -nek, hogy zárja be a kapcsolatot.

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

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

8. A TCP szerver utasítja alkalmazását a kapcsolat lezárására.

Rizs. 10.11. Kapcsolat lezárása

Mindkét oldal egyszerre kezdheti el a zárást. Ebben az esetben a normál kapcsolat lezárása befejeződik, miután minden partner elküldi az ACK üzenetet.

10.6.1 Hirtelen megszűnés

Mindkét fél kérheti a kapcsolat hirtelen lezárását. Ez akkor elfogadható, ha egy alkalmazás meg akarja szakítani a kapcsolatot, vagy amikor a TCP komoly kommunikációs problémával találkozik, amelyet nem tud önmagában megoldani. A hirtelen megszüntetést úgy kell kérni, hogy egy vagy több visszaállítási üzenetet küld a társnak, amint azt a TCP fejlécben megadott 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 -feladót érinti. Ennek a mechanizmusnak az alábbi magyarázata koncepcionális, és a fejlesztők különböző módon tudják megvalósítani termékeikben.

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

Az adatfolyam belép a bemeneti pufferbe, és ott tárolja, mielőtt elküldi az alkalmazásnak (a TCP -port határozza meg). Ábrán. A 10.12. Ábra olyan bemeneti puffert mutat, amely képes 4KB fogadására.

Rizs. 10.12. A bemeneti puffer fogadó ablaka

A puffertér az adatok beérkezésekor megtelik. Amikor a fogadó alkalmazás lekéri az adatokat a pufferből, a felszabadult hely elérhető lesz az új bejövő adatok számára.

10.7.1 Fogadóablak

Fogadó ablak(fogadási ablak) - minden olyan hely a bemeneti pufferben, amelyet még nem foglaltak el az adatok. Az adatok addig maradnak a bemeneti pufferben, amíg a célalkalmazás el nem fogyasztja őket. Miért nem veszi fel azonnal az alkalmazás az adatokat?

Egy egyszerű forgatókönyv segít válaszolni erre a kérdésre. Tegyük fel, hogy egy ügyfél feltöltött egy fájlt egy nagyon forgalmas, többfelhasználós számítógépen futó FTP -kiszolgálóra. Az FTP programnak ezután ki kell olvasnia az adatokat a pufferből, és le kell írnia a lemezre. Amikor a szerver lemez I / O műveleteket hajt végre, a program megvárja a műveletek befejezését. Ekkor elindulhat egy másik program (például ütemterv szerint), és míg az FTP program újra elindul, 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 rendelkezésre áll, és így 4KB fogadási ablak áll rendelkezésre. Amikor megérkezik az első KB, a fogadóablak 3 KB -ra csökken (az egyszerűség kedvéért feltételezzük, hogy minden szegmens mérete 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ése 1 KB -ra csökkenti a fogadóablakot.

A vevő által küldött minden ACK információt tartalmaz a fogadó ablak aktuális állapotáról, attól függően, hogy a forrásból származó adatáramlást melyik szabályozza.

A bemeneti puffer mérete nagyrészt a kapcsolat indításakor van beállítva, bár a TCP szabvány nem határozza meg ennek a puffernek a kezelését. A bemeneti puffer növekedhet vagy zsugorodhat, hogy visszajelzést adjon a feladónak.

Mi történik, ha egy bejövő szegmens elhelyezhető a fogadóablakban, de nem érkezett meg rendben? Általában azt feltételezik, hogy minden megvalósítás tárolja a fogadott adatokat a fogadási ablakban, és nyugtázást (ACK) küld csak több szegmens egész, összefüggő blokkjára. Ez a helyes módszer, mert különben a soron kívüli adatok elvetése jelentősen rontja a teljesítményt.

10.7.2 Küldés ablak

Az adatokat továbbító rendszernek két jellemzőt kell követnie: a már elküldött és megerősített adatok mennyiségét, valamint a vevő fogadóablakának aktuális méretét. Aktív feladási hely(send space) az első nyugtázatlan oktettől az aktuális fogadóablak bal oldalára bővül. Rész ablak használva küldeni, jelzi, hogy mennyi további adat küldhető a partnernek.

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

1. A feladó 4KB küldési ablakkal kezdődik.

2. A feladó 1 KB -ot küld. Ezen adatok egy példányát megőrizzük a nyugtázás (ACK) beérkezéséig, mivel szükség lehet az újraküldésre.

3. Megérkezik az első KB ACK üzenete, és a következő 2 KB adat kerül elküldésre. Az eredmény az ábra felső részének harmadik részében látható. 10.13. A 2 KB -os tárolás folytatódik.

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

Rizs. 10.13. Küldés ablak

Számos érdekes tulajdonságra kell felhívni a figyelmet:

S A feladó nem várja meg az ACK -t minden egyes elküldött adatszegmenshez. Az egyetlen átviteli korlátozás a fogadási ablak mérete (például a feladó csak 4K egybájtos szegmenseket küldjön).

■ Tegyük fel, hogy a feladó több nagyon rövid szegmensben (például 80 bájt) küld adatokat. 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 a cél port azonosítóival kezdődik. Következő következő mező sorozatszám(sorszám) azt a pozíciót jelzi a kimenő adatfolyamban, amelyet ez a szegmens foglal el. Terület ACK(nyugtázás) információkat tartalmaz a bemeneti adatfolyamban várhatóan megjelenő következő szegmensről.

Rizs. 10.14. TCP szegmens

Hat zászló van:

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

10.8.1 Opció a maximális szegmensmérethez

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

Az elfogadható legnagyobb datagram 40

Más szóval, az MSS tükrözi a legnagyobbat hasznos teher a vevőegységben, 20 bájtos TCP és IP fejlécekkel. Ha vannak további paraméterek, akkor azok hosszát ki kell vonni a teljes méretből. Ezért a szegmensben küldhető adatmennyiséget a következőképpen határozzák meg:

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

Általában a társak MSS -értékeket cserélnek a kezdeti SYN -üzenetekben, amikor a kapcsolat létrejön. Ha a rendszer nem hirdet maximális szegmensméret -értéket, akkor az alapértelmezett 536 bájtos értéket használja.

A maximális szegmens méretét 2 bájtos előtaggal kódolják, amelyet 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 ír elő a TCP -hez küldött adatokra: a vevő nem lesz képes nagy értékek feldolgozására. A feladó azonban szegmenseket használ kisebb, mivel az út mentén lévő MTU is a kapcsolatra van meghatározva.

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

A kapcsolat megnyitásához küldött első szegmens SYN jelzője 1 és ACK jelzője 0. A kezdeti SYN az az egyetlen egy szegmens, amelynek ACK mezője 0. Ne feledje, hogy a biztonság ezt a funkciót használja a TCP -munkamenet bejövő kéréseinek észlelésére.

Terület sorozatszám tartalmaz kezdeti sorszám(kezdeti sorszám), mező ablak - kezdeti méret fogadóablak. Az egyetlen TCP -paraméter jelenleg a maximális szegmensméret (ha nincs megadva, az alapértelmezett érték 536 bájt), amelyet a TCP vár. Ez az érték 32 bit hosszú, és általában jelen van a mezőben a csatlakozási kérelemben 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écmezők használata a kapcsolat válaszában

A csatlakozási kérelemre adott válasz engedélyezésekor mindkét jelző (SYN és ACK) egyenlő 1. A válaszadó rendszer jelzi a kezdő sorszámot a megfelelő mezőben, és a fogadóablak méretét a mezőben Ablak... A címzett által használni kívánt maximális szegmensméret általában megtalálható a csatlakozási kérésre adott válaszban (a lehetőségek). Ez az érték eltérhet a csatlakozást kérő fél értékétől, azaz két különböző érték használható.

A csatlakozási kérelem elutasítható, ha a válaszban 1 értékű reset jelzőt (RST) ad meg.

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

A TCP specifikáció feltételezi, hogy a kapcsolat létrehozása során minden fél választ kezdeti sorszám(a 32 bites belső időzítő aktuális értékénél). 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 megnyitott egy 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éssel, és néhányat már használhatnak más kapcsolatok, amelyek néhány másodperccel az összeomlás előtt létrejöttek.

Ezért a másik fél a kapcsolat legvégén nem biztos, hogy tudja, hogy partnere összeomlott, és a munkáját ezután helyreállították. Mindez súlyos fennakadásokhoz vezet, különösen akkor, ha hosszú időbe telik, amíg a régi adatok áthaladnak a hálózaton, és keverednek az újonnan létrehozott kapcsolat adataival. Az újraindítás időzített kiválasztása kiküszöböli az ilyen problémákat. A régi adatok más számozást kapnak, mint az új kapcsolat sorszámtartománya. A hackerek, amikor meghamisítják a megbízható gazdagép IP -címét, megpróbálnak hozzáférni a számítógépekhez azáltal, hogy egy előre látható kezdő sorszámot adnak meg az üzenetben. A biztonságos kulcsszámok kiválasztásának legjobb módja a belső kulcsokon alapuló kriptográfiai kivonatfüggvény.

10.8.5 A mezők közös használata

A TCP fejléc továbbításra való előkészítésekor a mezőben megjelenik az átvitt adatok első oktettjének sorszáma sorszám(Sorszám).

A mezőbe be kell írni a csatlakozási partnertől elvárt következő oktett számot megerősítés(Nyugtázási szám), ha az ACK bit értéke 1. Mező ablak(Ablak) a fogadó ablak aktuális méretére vonatkozik. Ez a mező tartalmazza az elfogadható bájtok száma a megerősítési számból... Vegye figyelembe, hogy ez az érték lehetővé teszi az adatáramlás pontos szabályozását. Ezzel az értékkel a partner jelzi a fogadó ablak valódi állapotát a cserefolyamat során.

Ha az alkalmazás TCP push műveletre mutat, akkor a PUSH jelző értéke 1.

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

Gyakran hívják a sürgős adatokat sávon kívüli információk(sávon kívüli). Ez a kifejezés azonban pontatlan. A gyorsított adatokat rendszeres TCP -folyam küldi, bár egyes megvalósítások speciális mechanizmusokkal rendelkezhetnek, amelyek segítségével az alkalmazás értesítheti a sürgős adatok fogadásáról, és az alkalmazásnak ellenőriznie kell a sürgős adatok tartalmát, mielőtt az üzenet összes bájtja megérkezik.

A RESET jelző értéke 1 a kapcsolat megszakításához. Ugyanez a zászló van beállítva a válaszban, amikor olyan szegmens érkezik, amely nincs társítva az aktuális TCP kapcsolatokkal.

A FIN jelző 1 -re van állítva a kapcsolatzáró üzeneteknél.

10.8.6 Ellenőrző összeg

Az IP ellenőrzőösszeg csak az IP fejlécre vonatkozik, a TCP ellenőrző összeg pedig a teljes szegmensre, valamint az IP fejlécből generált álfejlécre vonatkozik. A TCP ellenőrző összeg kiszámítása során a megfelelő mező értéke 0. A 10.15. Ábra egy álfejlécet mutat, amely nagyon hasonló az UDP ellenőrző összegben használthoz.

Rizs. 10.15. Az álfejléc mező a TCP ellenőrzőösszegében található

A TCP hosszát úgy számítják ki, hogy hozzáadják a TCP fejléc hosszát az adathosszhoz. A TCP ellenőrző összege az kötelező, nem úgy, mint az UDP. A fogadott szegmens ellenőrző összegét először a vevő számítja ki, majd összehasonlítja a TCP fejléc ellenőrző összeg mezőjének tartalmával. Ha az értékek nem egyeznek, a szegmens elvetésre kerül.

10.9 TCP szegmens példa

Rizs. 10.16, elemző működési protokoll Szippantás a Network General, a 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ájt adatot tartalmaz.

Rizs. 10.16. A Sniffer Analyzer TCP fejlécének megjelenítése

Elemző Szippantás a legtöbb értéket tizedesre fordítja. A jelzőé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 Session támogatás

10.10.1 Ablak szondázás

A gyors küldő és a lassú vevő 0 bájtos fogadási 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éhez, akkor az ACK használható. Ha azonban egy ilyen üzenet elveszik, mindkét félnek végtelen ideig várnia kell.

Ennek elkerülése érdekében a feladó beállítja tárolt időzítő(tartós időzítő), ha az ablak csukva van. Az időzítő értéke az újraküldés időtúllépése. Amikor az időzítő lejár, egy szegmenst küld a partnernek. hangzó ablak(ablak szonda; néhány megvalósítás tartalmaz adatokat is). A szondázás hatására a kortárs visszaküldi az ACK -t, amely jelenti az ablak aktuális állapotát.

Ha az ablak még mindig nulla méretű, akkor 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éri a maximum 60 másodpercet. A TCP továbbra is 60 másodpercenként küld szondaüzeneteket - az ablak megnyitásáig, amíg a felhasználó le nem zárja a folyamatot, vagy amíg az alkalmazás időtúllépést nem mutat.

10.11 Kijelentkezés

10.11.1 Időtúllépés

A kapcsolatpartner ö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 újraküldje az adatokat.

Miután elérte az újraküldés (továbbítás) első küszöbértékét, a TCP utasítja az IP -t, hogy ellenőrizze a meghibásodott útválasztót, és egyúttal tájékoztatja a probléma alkalmazását. A TCP továbbítja az adatok küldését a második határérték eléréséig, és csak ezután szakítja meg a kapcsolatot.

Természetesen, mielőtt ez megtörténne, érkezhet egy ICMP üzenet, amely szerint a cél valamilyen okból nem érhető el. Bizonyos implementációkban a TCP még akkor is megpróbálja elérni a célállomást, amíg az időkorlát le nem telik (ezt követően a probléma megoldható). Ezt követően az alkalmazás értesítést kap arról, hogy a célállomás nem érhető el.

Az alkalmazás beállíthatja saját adatszolgáltatási időtúllépését, és ezen intervallum végén elvégezheti saját műveleteit. A kapcsolat általában megszakad.

10.11.2 A kapcsolat fenntartása

Ha egy hiányos kapcsolat hosszú ideig rendelkezik adattovábbítással, az inaktív állapotot kap. A tétlenség időszakában hálózati összeomlás vagy fizikai kapcsolatok elvesztése fordulhat elő. Amint a hálózat újra működőképessé válik, a partnerek a kommunikációs munkamenet megszakítása nélkül folytatják az adatok cseréjét. Ez a stratégia megfelelt a Honvédelmi Minisztérium követelményeinek.

Azonban minden kapcsolat - aktív vagy inaktív - sok számítógép memóriát foglal el. Néhány rendszergazdának vissza kell adnia a fel nem használt erőforrásokat a rendszerekhez. Ezért sok TCP implementáció képes üzenetet küldeni a a kapcsolat megtartása(életben tartani) az inaktív kapcsolatok tesztelése. Az ilyen üzeneteket rendszeresen elküldik a partnernek annak ellenőrzésére, hogy létezik -e a hálózaton. Az ACK üzeneteket válaszként kell fogadni. A megőrző ü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őtúllépése 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ést hoz a kapcsolat végéről.

10.12 Teljesítmény

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

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

A sávszélesség és a késleltetés a használt fizikai hálózatban jelentősen korlátozza a sávszélességet. A rossz adatátviteli minőség nagy mennyiségű leesett datagramot eredményez, 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 feladó megszakítás nélkül átvihesse 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 elküldése és az ACK fogadása között (és az ablakméret egyeztetésekor is). A forrásból származó stabil adatáramlás fenntartásához a fogadó oldalnak legalább olyan sávszélességű ablakkal kell rendelkeznie, mint a késleltetett termék.

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 visszaadása, akkor a másik oldalon legalább 20 000 bájtos fogadóablakot kell megadnia, ellenkező esetben az adatáramlás nem lesz folyamatos. A 10 000 bájtos fogadási puffer felére csökkenti az átviteli sebességet.

A teljesítmény másik fontos tényezője, hogy a gazda képes reagálni a kiemelt eseményekre és gyorsan végrehajtani kontextusváltás, azaz végezzen el néhány műveletet, és váltson át másokra. A házigazda interaktívan támogathat sok helyi felhasználót, kötegelt háttérfolyamatokat és több tucat egyidejű kommunikációs kapcsolatot. A kontextusváltás lehetővé teszi ezeknek a műveleteknek a kiszolgálását, miközben elrejti a rendszer terhelését. Azok a megvalósítások, amelyek integrálják a TCP / IP -t az operációs rendszer kerneljével, jelentősen csökkenthetik a környezetváltásból származó terhelést.

A számítógép CPU -jának erőforrásaira van szükség a TCP -fejlécek feldolgozásához. Ha a processzor nem tudja gyorsan kiszámítani az ellenőrző összegeket, lelassítja az adatok hálózati átviteli sebességét.

Ezenkívül a fejlesztőknek fontolóra kell venniük a TCP -beállítások egyszerű konfigurálását, hogy a hálózati rendszergazda személyre szabhassa azokat a helyi követelményeknek megfelelően. Például a pufferméret sávszélességre és hálózati késleltetésre történő beállítása jelentősen javítja a teljesítményt. Sajnos sok megvalósítás 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 a cowboyok, akik előveszik revolvereiket. Kiváló teljesítményt fog kapni?

Nem mindig. A TCP szoftverfejlesztés minősége is számít. Sok teljesítményproblémát diagnosztizáltak és oldottak meg az évek során a különböző TCP -implementációkban. A legjobb szoftver az RFC 1122, amely meghatározza az internetgazdák kommunikációs rétegének követelményeit.

Ugyanilyen fontos a kivétel valamint a Jacobson, Kern és Partridge algoritmusok alkalmazása (ezeket az érdekes algoritmusokat az alábbiakban tárgyaljuk).

A szoftverfejlesztők jelentős előnyökhöz juthatnak, ha 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ához.

10.13 Teljesítményjavító algoritmusok

A TCP meglehetősen összetett részére áttérve megvizsgáljuk a teljesítmény javításának mechanizmusait és a sávszélesség szűk keresztmetszeteinek megoldását. Ez a szakasz 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 új munkamenetre használják fel, ami általános költségekhez vezethet.

■ Felépülés ostoba ablak szindróma(buta 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ó nyugtázó üzenetek számát.

■ Számított újraküldési időtúllépés(számítási újraküldési időtúllépés) 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 ténylegesen szükséges adatcserékben.

■ Lassítsa le a TCP továbbítást, amikor túlterhelések a hálózaton lehetővé teszi, hogy az útválasztók visszatérjenek eredeti módjukba, és megoszthassák a hálózati erőforrásokat az összes munkamenethez.

■ Küldés duplikált ACK -k(duplikált ACK), amikor egy szegmenst soron kívül kap, lehetővé teszi a társak számára, hogy újra küldjenek, mielőtt az időtúllépés bekövetkezik.

10.13.1 Lassú indítás

Ha otthon minden háztartási készüléket egyszerre kapcsol be, akkor az elektromos hálózat túlterhelődik. Számítógépes hálózatokban lassú indítás megakadályozza a hálózati biztosítékok kiégését.

Egy új kapcsolat, amely azonnal elindítja a nagy mennyiségű adat továbbítását egy már betöltött hálózaton, problémákat okozhat. A lassú indítás mögött az az ötlet áll, hogy biztosítsuk az új kapcsolat sikeres elindítását, miközben lassan növeljük az adatátviteli sebességet a tényleges hálózati terhelésnek megfelelően. A feladót a betöltőablak mérete korlátozza, nem a nagy fogadóablak.

Ablak betöltése(torlódási ablak) 1 szegmens méretével kezdődik. A sikeresen fogadott ACK -val rendelkező szegmensek esetében a betöltési ablak 1 szegmenssel nö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 feltételek mellett 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 szegmenssel egyenlő, és miután sikeresen megkapta az ACK -t két szegmensre, a méret 8 szegmensre nőhet. Más szóval, az ablak mérete exponenciálisan nő.

Tegyük fel, hogy az ACK fogadása helyett 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 Clueless Window szindróma

A TCP / IP első megvalósításai során a fejlesztők szembesültek a jelenséggel ostoba ablak szindróma(Silly Window Syndrome - SWS), ami elég gyakran jelent meg. A történések megértéséhez fontolja meg a következő forgatókönyvet, amely nemkívánatos következményekhez vezet, de ez teljesen lehetséges:

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

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

3. A bemeneti puffer gyorsan megtelik olvasás után.

4. A fogadó alkalmazás 1 bájtot olvas, a TCP pedig ACK -t küld, ami azt jelenti, hogy "szabad helyem van 1 bájt adathoz".

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: "Köszönöm. Csomagot kaptam, é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 lassú fogadó alkalmazás sokáig várja az adatok megérkezését, és folyamatosan a beérkező információkat az ablak bal szélére tolja, és teljesen haszontalan műveletet hajt végre, amely további forgalmat generál a hálózaton.

A valós élethelyzetek persze nem olyan extrémek. A gyors küldő és a lassú fogadó kicsiny (a maximális szegmensmérethez képest) adatcsomagokat cserél, és majdnem teljes fogadási ablakot vált. Ábrán. A 10.18. Ábra a "hülye ablak" szindróma megjelenésének feltételeit mutatja be.

Rizs. 10.18. Ablakpuffer fogadása nagyon kicsi szabad hellyel

Ezt a problémát nem nehéz megoldani. Amint a fogadási ablak kisebb lesz a megadott célméretnél, a TCP becsapni kezdi a feladót. Ebben a helyzetben a TCP nem irányíthatja a feladót további teret az ablakban, amikor a fogadó alkalmazás apró darabokban olvassa az adatokat a pufferből. Ehelyett a felszabadított erőforrásokat addig kell titkolni a feladó elől, amíg nincs elég belőle. Az ajánlott méret egy szegmens, kivéve, ha a teljes bemeneti puffer egyetlen szegmenst tartalmaz (utóbbi esetben a puffer felével egyenlő 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 csalni kezd, amikor az ablak mérete kisebb, mint ez a méret, és igazat fog mondani, ha az ablak mérete nem kisebb, mint a képlet által kapott érték. Ne feledje, hogy nem árt a feladónak, 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ő egy ACK kimenettel minden fogadott bájthoz. Ugyanez a módszer alkalmas arra az esetre is, amikor a bemeneti puffer több szegmenst képes tárolni (ahogy ez a gyakorlatban gyakran előfordul). A gyors feladó kitölti a bemeneti puffert, de a vevő jelzi, hogy nincs szabad helye információ tárolására, és nem nyitja meg ezt az erőforrást, amíg mérete el nem éri az egész szegmenst.

10.13.3 Nagle algoritmusa

A feladónak a címzettől függetlenül ki kell zárnia a nagyon rövid szegmensek átvitelét azáltal, hogy adatokat gyűjt a küldés előtt. 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), várva az ACK -ra a korábban továbbított adatokból. A felhalmozott adatokat a rendszer elküldi, miután megkapta az ACK -t egy korábban elküldött információról, vagy miután egy teljes szegmens méretű adatot kapott küldésre, vagy az időkorlát lejártát követően. 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 -k 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ársa kissé késlelteti az ACK küldését, akkor:

■ Egy ACK -val nyugtázhatja több szegmens fogadását.

■ A fogadó alkalmazás bizonyos mennyiségű adatot képes fogadni az időkorláton belül; a kimeneti fejléc beilleszthető az ACK -ba, és nem igényel külön üzenetet.

Annak érdekében, hogy elkerüljük a késéseket a teljes méretű szegmensek küldésekor (például fájlcserénél), ACK-t kell küldeni legalább minden második teljes szegmensre.

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

10.13.5 Ú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 az időkorláton belül nem érkezik ACK, a TCP újra elküldi a szegmenst (relét). Azonban mi legyen az időtúllépési időszak?

Ha túl rövid, a feladó feltölti a hálózatot szükségtelen szegmensekkel, amelyek megismétlik a már elküldött információkat. A túl hosszú időtúllépés megakadályozza, hogy gyorsan rögzítse azokat a szegmenseket, amelyek valóban rosszak az átvitel során, ami csökkenti az átviteli sebességet.

Hogyan válasszuk ki a megfelelő időkorlátot? A nagy sebességű LAN-hoz megfelelő érték nem alkalmas többütemű távoli kapcsolathoz. Ez azt jelenti, hogy az "egy érték minden feltételhez" elv nyilvánvalóan alkalmatlan. Ezenkívül még egy meglévő speciális kapcsolat esetén is megváltozhatnak a hálózati feltételek, és a késések növekedhetnek vagy csökkenhetnek.

Jacobson, Kern és Partridge algoritmusok (cikkekben leírtak) , Van Jacobson és Az oda-vissza időbecslések javítása a megbízható szállítási protokollokban, Karn és Partridge) lehetővé teszik, hogy a TCP alkalmazkodjon a változó hálózati feltételekhez. Ezeket az algoritmusokat ajánlott új implementációkban használni. Az alábbiakban röviden ismertetjük őket.

A józan ész azt diktálja, hogy a legjobb alap az adott kapcsolat helyes időtúllépésének becsléséhez lehet ciklusidő(oda-vissza út), mint az adatok elküldése és az átvételük visszaigazolása között eltelt idő.

A következő mennyiségekre vonatkozó jó döntések az alapvető statisztikákból (lásd 10.19. Ábra) származhatnak, amelyek segíthetnek az időtúllépési idők kiszámításában. Nem kell azonban átlagokra hagyatkozni, mivel a becslések több mint fele nagyobb lesz az átlagnál. Ha néhány eltérést megvizsgál, akkor pontosabb becsléseket kaphat, 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, hogy formális matematikai becsléseket kapjunk az eltérésekről. 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 - átlagos |

Egy másik tényező, amelyet figyelembe kell venni a helyes időtúllépési érték kiszámításakor, a ciklusidő változása a jelenlegi hálózati feltételek miatt. Ami az interneten az utolsó pillanatban történt, sokkal fontosabb, mint az egy órával ezelőtti.

Tegyük fel, hogy egy nagyon hosszú munkamenet ciklusátlagát számítja ki. Annak ellenére, hogy a hálózat kezdetben enyhén terhelve volt, és 1000 kis értéket határoztunk meg, a forgalom növekedett, és a késleltetés jelentősen megnőtt.

Például, ha 1000 érték átlagosan 170 egységet adott, de 50 értéket 282 átlaggal mértek, akkor a jelenlegi á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) + α × Az utolsó ciklus értéke

Az α érték 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 bináris számok jobbra tolásával gyorsan oszthatnak 2 -es hatványokkal, az α mindig (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 azt mutatja be, hogyan igazodik az SRTT képlet az aktuális SRTT 230 értékhez, ha a hálózati állapot változása a ciklusidő progresszív növekedését eredményezi (feltéve, hogy időkorlát nem következik be). A 3. oszlopban szereplő értékeket a táblázat következő sorának 1. oszlopában lévő értékekként használjuk (azaz a régi SRTT -hez hasonlóan).

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

Régi SRTT	A legújabb 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 egy kérdés merül fel az újraküldési időtúllépés értékének kiválasztásával kapcsolatban. A ciklusidők elemzése ezen értékek jelentős eltérését mutatja az aktuális átlagtól. Ésszerű határértéket szabni az eltérések (eltérések) nagyságának. Az újraküldési időtúllépésre vonatkozó jó értékeket (az RFC szabványokban Retransmission TimeOut - RTO -nak nevezik) a következő képlet adja meg, simított eltérési korlátozással (SDEV):

T = Újraküldés időtúllépése = SRTT + 2 × SDEV

T = SRTT + 4 × SDEV

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

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

A simító képletet ezután az utolsó érték figyelembevételére használják:

Ú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 újraküldési időtúllépést.

10.13.6 Példa statisztikákra

Mennyire fog működni a fent számított időtúllépés? Amikor ezt az értéket realizálták, jelentős teljesítményjavulások figyelhetők meg. Ilyen például a csapatstatisztika netstat kapott a rendszeren tigris- egy internetes szerver, amelyhez számos gazda fér hozzá a világ minden tájáról.

1510769 csomag (314955304 bájt) kapott sorban

Rendszer tigris a TCP -adatszegmensek kevesebb, mint 2,5% -át küldték újra. Másfél millió bejövő adatszegmens esetében (a többi tiszta ACK üzenet) csak 0,6% -át másolták meg. Nem szabad megfeledkezni arról, hogy a bemeneti adatok veszteségének szintje nagyjából megfelel a kimeneti szegmensek szintjének. Így a haszontalan továbbküldési forgalom a teljes forgalom mintegy 0,6% -át teszi ki.

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

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

Kern algoritmusa 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őrizzék meg értékeiket mindaddig, amíg nyugtát nem kapnak egy bizonyos szegmens újraküldés nélküli elküldésére. Ekkor a számítások a tárolt értékek és az új mérések alapján folytatódnak.

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

De mi történik a megerősítés előtt? Az újraküldés után a TCP viselkedése gyökeresen megváltozik, főként a hálózati torlódásokból származó adatvesztés miatt. Ezért az adatok újraküldésére adott válasz a következő lesz:

■ Az újratöltés sebességének csökkentése

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

10.13.9 Exponenciális fékezés

Az újraküldés után az időtúllépési idő megduplázódik. Mi történik azonban, ha az időzítő ismét túlcsordul? Az adatok ismét elkü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 előfordul, ha túllépik az ACK fogadása nélküli adatátvitel számának előre meghatározott értékét.

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

Az átvitt adatmennyiség csökkentése valamivel összetettebb, mint a fent tárgyalt mechanizmusok. Működni kezd, mint a már említett lassú indítás. De mivel a forgalom szintjének határa van beállítva, ami kezdetben problémákhoz vezethet, az árfolyam valójában lelassul az egyik szegmens betölté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élyes küszöböt kell kiszámítani:

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

Ha a kapott érték több mint két szegmens, akkor határként használják. Ellenkező esetben a szegély két szegmensre van állítva. A teljes helyreállítási algoritmus megköveteli:

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

■ Minden fogadott ACK esetén növelje a terhelési ablak méretét egy szegmenssel, amíg el nem éri a határt (nagyon hasonlóan a lassú indítási mechanizmushoz).

■ Ezután minden fogadott ACK -val adjon hozzá egy kisebb értéket a betöltési ablakhoz, amelyet a ciklusidő egy szegmensének növekedési üteme alapján választanak ki (a növekedés MSS / N -ként kerül kiszámításra, ahol N a terhelés mérete) ablak szegmensekben).

Egy ideális forgatókönyv egyszerűsítheti a helyreállítási mechanizmus működését. Tegyük fel, hogy a partner fogadóablaka (és az aktuális betöltési ablak) 8 szegmens méretű volt az időkorlát észlelése előtt, és a határ 4 szegmens volt. 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 Fogadott - 2 szegmens kerül elküldésre.

■ ACK 2 szegmens fogadása esetén - 4 szegmens kerül elküldésre (a határ elérte).

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

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

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

■ Az ACK 7 szegmensre érkezett. 8 szegmens kerül elküldésre (a betöltési ablak ismét megegyezik a fogadóablakkal).

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 zajló eseményeket az ábra mutatja. 10.20. Az ablak mérete exponenciálisan nő, megduplázódik a lassú indítás időszakában, és a határ elérésekor lineárisan nő.

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

10.13.11 Ismétlődő ACK -k

Néhány megvalósításban opcionális funkciót használnak - az ún gyors újraszállítás(gyors továbbküldés) - annak érdekében, hogy bizonyos feltételek mellett felgyorsítsa az adatok újraküldését. Fő gondolata a vevő további ACK -k küldéséhez kapcsolódik, jelezve a hiányosságot a fogadott adatok között.

A soron kívüli szegmenst fogadva a vevő visszaküldi az első bájtra mutató ACK-t elveszett adatok (lásd 10.21. ábra).

Rizs. 10.21. Ismétlődő ACK -k

A feladó nem küldi azonnal újra az adatokat, mert az IP általában képes adatokat továbbítani a címzettnek küldési sorrend nélkül. De ha több további ACK -t kap az ismétlődő adatokhoz (például hármat), akkor a hiányzó szegmens elküldésre kerül anélkül, hogy meg kellene várnia az időtúllépést.

Vegye figyelembe, hogy minden ismétlődő ACK jelzi az adatszegmens fogadását. Néhány ismétlődő ACK tájékoztatja Önt arról, 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 terhelési ablak méretének kicsi csökkentése valósul meg a hálózati forgalom valódi növekedésével. Ebben az esetben a munka helyreállításakor a radikális átméretezés folyamata nem alkalmazható.

A szabvány szerint A hoszt követelményei(host követelmények) A TCP -nek ugyanazt a lassú indítást kell végrehajtania, mint a fent leírtak a forrás kioltásakor (source quench). Ennek bejelentése azonban nem célzott vagy hatékony, mert az üzenetet fogadó kapcsolat nem generál túl nagy forgalmat. Jelenlegi specifikáció Az útválasztó követelményei(router követelmények) azt jelzi, hogy az útválasztók nem kelleneüzeneteket küldeni a forrás leállításáról.

10.13.13 TCP statisztika

Végül nézzük meg a parancs statisztikai üzeneteit netstat, hogy a fent leírt mechanizmusok közül sok működjön.

A szegmenseket csomagok nevezik.

879137 adatcsomag (226966295 bájt)

21815 adatcsomag (8100927 bájt) újraküldése

Újraszállítás.

132957 csak ack csomag (104216 késik)

Megjegyezzük, hogy nagy számban

késleltetett ACK.

Szondázó ablaknyitás

nulla méret.

Ezek SYN és FIN üzenetek.

762469 akk (226904227 bájtért)

Figyelmeztetés az érkező csomagokra

sorrenden kívül.

1510769 csomag (314955304 bájt)

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

A valós idejű időtúllépés eredménye

adatszállítás.

74 csomag némi duplával. adatok (12193 bájt duplikálva)

A nagyobb hatékonyság érdekében

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

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

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

Talán ezek az adatok voltak

benne van az érzékelő üzenetekben.

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

Ezek az utólagos ismétlések

küldés.

108 elvetve rossz ellenőrző összegek miatt

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

0 elvetve a rossz fejléc -eltolási mezők miatt

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

14677 kapcsolat létesült (beleértve az elfogadásokat)

18929 kapcsolat lezárva (köztük 643 csepp)

4100 embrionális kapcsolat megszakadt

572187 szegmens frissítette az RTT -t (587397 kísérletből)

Sikertelen változtatási kísérletek

a ciklusidő, mivel az ACK -nak nem volt ideje megérkezni az időtúllépés lejárta előtt,

Az újraküldési időtúllépés miatt 26 kapcsolat megszakadt

A későbbi sikertelen kísérletek

újraküldés, ami elveszett kapcsolatot jelez.

Időzítések vizsgálata

nulla ablak.

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

megszakadt kapcsolat.

472 kapcsolat megszakadt a keepalive segítségével

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

A jelenlegi TCP szabvány megköveteli, hogy a megvalósítások betartsák a lassú indítási eljárást a kapcsolat inicializálásakor, és Kern és Jacobson algoritmusok segítségével becsüljék meg az újraküldési időtúllépést és kezeljék a terhelést. A tesztek azt mutatták, hogy ezek a mechanizmusok jelentős teljesítményjavulásokhoz 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ói számára, és szegény szomszédja lesz a hálózat többi rendszere számára, megakadályozva a normál működés helyreállítását ideiglenes torlódások után, és túlzott forgalmat generálva, ami a datagramok elvesztéséhez vezet.

10.15 A teljesítmény korlátai

A TCP bebizonyította rugalmasságát, és több száz vagy millió bit / másodperces árfolyamú hálózatokon dolgozik. Ez a protokoll jó eredményeket ért el a modern helyi hálózatokban, Ethernet, Token-Ring és Fibre Distributed Data Interface (FDDI) topológiákkal, valamint alacsony sebességű kommunikációs vonalak vagy távolsági kapcsolatok (például műholdas kapcsolatok) esetében.

A TCP -t úgy tervezték, hogy reagáljon olyan extrém körülményekre, mint a hálózati torlódások. A protokoll jelenlegi verziója azonban olyan funkciókkal rendelkezik, amelyek korlátozzák a teljesítményt az ígéretes technológiákban, amelyek több száz és ezer megabájt sávszélességet kínálnak. A felmerülő problémák megértéséhez fontoljon meg 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 szegmensméret 1 KB.

■ Fogadóablak - 4 KB.

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

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

S ACK üzenetek 2 másodpercen belül érkeznek.

A feladó képes folyamatosan adatokat küldeni. Végtére is, amikor az ablakhoz rendelt kötet megtelt, egy ACK érkezik, amely lehetővé teszi egy másik szegmens küldését:

2 s után:

AZ 1. SZEGMENT VÉTELE, AZ 5. SZEGMENTET ELKÜLDHETŐ.

A 2. SZEGMENT VÉTELE, A 6. SZEGMENTET ELKÜLDHETŐ.

A 3. SZEGMENT VÉTELE, A 7. SZEGMENTET ELKÜLDHETŐ.

A 4. SZEGMENT VÉTELE, KÜLDHETŐ A 8. SZEGMENT.

2 másodperc múlva:

AZ 5. SZEGMENT VÉTELE, KÜLDHETŐ A 9. SZEGMENT.

Ha a fogadási ablak csak 2 KB volt, a feladónak minden másodikból egy másodpercet kell várnia, mielőtt elküldi a következő adatokat. Valójában a folyamatos adatfolyam fenntartásához a fogadási ablaknak legalább a következőnek kell lennie:

Ablak = sávszélesség × ciklusidő

Bár a példa kissé túlzó (az egyszerűbb számok érdekében), a kis ablak problémákat okozhat a nagy késleltetésű műholdas kapcsolatokkal.

Most nézzük meg, mi történik a nagy sebességű kapcsolatokkal. Például, ha a sávszélességet és az átviteli sebességet másodpercenként 10 millió bitre mérik, de a ciklusidő 100 ms (1/10 másodperc), akkor a folyamatos adatfolyam esetén a fogadási 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 átviteli sebességnél jelentkezik, mivel a sorszámok nagyon gyorsan elfogynak. Ha a kapcsolat 4 GB / s sebességgel tud adatokat továbbítani, akkor a sorszámokat másodpercenként frissíteni kell. Nem lehet megkülönböztetni a régi duplikált datagramokat, amelyek több mint egy másodperccel késtek az interneten való mozgás során, a friss új adatoktól.

Új kutatás folyik a TCP / IP javítása és a fenti akadályok megszüntetése érdekében.

10.16 TCP funkciók

Ez a fejezet a TCP számos jellemzőjére összpontosít. A főbbeket az alábbiakban soroljuk fel:

■ Portok kötése a kapcsolatokhoz

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

■ Lassú indítást végez a hálózati torlódások elkerülése érdekében

■ Az átvitt adatok szegmentálása

■ Adatok számozása

■ A bejövő duplikált szegmensek kezelése

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

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

■ A kapcsolat megszüntetése a megszokott módon

■ A kapcsolat megszakítása

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

■ Pozitív megerősítés az újraszállításról

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

■ Csökken a visszatérő forgalom a hálózati torlódások során

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

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

10.17 A TCP állapota

A TCP kapcsolat több szakaszon megy keresztül: a kapcsolat létrejön üzenetváltáson keresztül, majd az adatok elküldésre kerülnek, majd a kapcsolat speciális üzenetek cseréjével lezárul. 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 figyeli a kapcsolat másik oldalának aktuális állapotát.

Az alábbiakban röviden megvizsgáljuk a szerver és az ügyfél tipikus állapotátmenetét a kapcsolat különböző végein. Nem kívánunk kimerítő leírást adni az összes lehetséges állapotról az adatátvitel során. Ez megtalálható az RFC 793 -ban és a dokumentumban A hoszt követelményei.

A kapcsolatok létrehozása során a szerver és az ügyfél hasonló állapotsorozatokon megy keresztül. A szerverállapotokat a 10.3. Táblázat, az ügyfélállapotokat a 10.4. Táblázat mutatja.

10.3. Táblázat Szerver állapot sorrend

Szerver állapota	Esemény	Leírás
ZÁRVA (zárva)		Fiktív állapot a kapcsolat megkezdése előtt.
	Passzív nyitás szerver alkalmazás által.
LISTEN (követés)		A szerver ügyfélkapcsolatra vár.
	A TCP szerver SYN -t fogad é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 fogadja az ACK -t.
LETTETT (telepítve)		ACK fogadva, a kapcsolat nyitva.

10.4. Táblázat Ügyfél állapot sorrend

Ha a partnerek egyszerre próbálnának kapcsolódni egymáshoz (ami rendkívül ritka), akkor mindegyik a ZÁRVA, SZINT-ELKÜLDETT, SZIN-RECEVÁLT és LÉTESÍTETT állapotokon megy keresztül.

A kapcsolat végoldalai KIÁLLÍTOTT állapotban maradnak, amíg az egyik oldal be nem indul záró kapcsolatokat egy FIN szegmens elküldésével. Normál záráskor a zárást kezdeményező fél átmegy a 10.5. Táblázatban látható állapotokon. Társa átmegy a 10.6 táblázatban látható állapotokon.

10.5. Táblázat A kapcsolatot lezáró fél állapotának sorrendje

Záró oldali állapotok	Esemény	Leírás
ALAPÍTOTT	A helyi alkalmazás kéri a kapcsolat lezárását.
	A TCP FIN / ACK -t küld.
FIN-WAIT-1		A fedő fél várja a partner válaszát. Emlékezzünk vissza, hogy előfordulhat, hogy új adatok érkeznek 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 várja a FIN -t, elfogadja a beérkező adatokat.
	A TCP FIN / ACK -t kap.
	ACK -t küld.
IDŐ-VÁR		A kapcsolat határozatlan állapotban van fenntartva, hogy a hálózaton még létező ismétlődő adatok vagy ismétlődő FIN -ek megérkezzenek vagy megszakadjanak. A várakozási idő kétszerese a maximális szegmens élettartam becslésnek.
ZÁRVA

10.6. Táblázat A partnerállamok sorrendje a kapcsolat lezárására

Partner státusz	Esemény	Leírás
ALAPÍTOTT	A TCP FIN / ACK -t kap.
ZÁRÓ VÁR		Megérkezett a FIN.
	A TCP ACK -t küld.
		A TCP várja, hogy alkalmazása bezá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 -t küld.
LAST-ACK		A TCP várja az utolsó ACK -t.
	A TCP ACK -t kap.
ZÁRVA		Eltávolította az összes csatlakozási információt.

10.17.1 TCP kapcsolati állapotok elemzése

Parancs netstat -an lehetővé teszi a kapcsolat aktuális állapotának ellenőrzését. Az állapotok közötti kapcsolatok az alábbiakban láthatók figyelj, indítás, megalapozott, lezárásés idő-várakozás.

Vegye figyelembe, hogy a csatlakozási port száma minden helyi és külső cím végén található. Látható, hogy a be- és kilépési sorokhoz egyaránt van TCP -forgalom.

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ÉTESÍTETT

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ÉTESÍTETT

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ÉTESÍTETT

Tcp 0 0 128.121.50.145.1082 128.121.50.141.6000 LÉTESÍTETT

Tcp 0 0 128.121.50.145.1022 128.121.50.141.1017 LÉTESÍTETT

Tcp 0 0 128.121.50.145.514 128.121.50.141.1020 ZÁRVA

Tcp 0 1152 128.121.50.145.119 192.67.239.23.3572 LÉTESÍTETT

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ÉTESÍTETT

Tcp 0 0 128.121.50.145.119 192.67.243.13.3704 LÉTESÍTETT

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ÉTESÍTETT

10.18 Megvalósítá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, hogyan kell működnie a belső implementációs struktúráknak. Ezeket a kérdéseket a fejlesztők hagyják, hogy megtalálják a legjobb mechanizmusokat az egyes megvalósításokhoz.

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

■ MAY (engedélyezett)

■ NEM KELL

Sajnos néha vannak olyan termékek, amelyek nem valósítják meg a KÖVETKEZŐ követelményeket. Ennek eredményeként a felhasználók teljesítménycsökkenést tapasztalnak.

Néhány jó végrehajtási gyakorlatot nem vesznek figyelembe a szabványok. Például a biztonság javítása azáltal lehetséges, hogy a jól ismert portok használatát korlátozják a privilegizált rendszerfolyamatokra, ha ezt a módszert támogatja a helyi operációs rendszer. A teljesítmény javítása érdekében az implementációknak a lehető legkevesebbet kell másolniuk és áthelyezniük az elküldött vagy visszakeresett adatokat.

Standard API meghatározatlan(valamint a biztonsági politikát), hogy szabad tevékenységi terület álljon rendelkezésre a különböző szoftvereszköz -készletekkel való kísérletezéshez. Ez azonban azt eredményezheti, hogy minden egyes platformon különböző API -kat használnak, és megakadályozza az alkalmazásszoftverek platformok közötti áthelyezését.

Valójában a fejlesztők a Berkeley -től kölcsönzött Socket API -ra alapozzák eszköztárukat. A programozási felület jelentősége a WINSock (Windows Socket) megjelenésével megnőtt, ami új asztali alkalmazások elterjedéséhez vezetett, amelyek bármilyen TCP / IP veremmel kompatibilis WINSock interfész tetején futhatnak.

10.19 További olvasmányok

Az eredeti TCP szabványt az RFC 793 határozza meg. A frissítések, javítások és kompatibilitási követelmények az RFC 1122. cikkben találhatók. Kern és Partridge közzétett egy cikket Az oda-vissza becslések javítása a megbízható szállítási protokollokban A folyóiratban Az ACM SIGCOMM folyóirata 1987. Jacobson cikke A torlódások elkerülése és ellenőrzése megjelent Az ACM SIGCOMM 1988 Workshop folyóirata. Jacobson számos RFC -t is kiadott, amelyek felülvizsgálták a teljesítményjavító algoritmusokat.