Applikation tcp ip klientserver. Klient-serverapplikation på en TCP-strömsocket. Ställa in IP-parametervärden

Servrar som implementerar dessa protokoll i företagsnätverk, förse klienten med en IP-adress, gateway, nätmask, namnservrar och till och med en skrivare. Användare behöver inte konfigurera sina värdar manuellt för att kunna använda nätverket.

Operativsystemet QNX Neutrino implementerar ett annat autokonfigurationsprotokoll som kallas AutoIP, som är ett projekt av IETF-kommittén om automatisk inställning. Detta protokoll används i små nätverk för att tilldela länklokala (länklokala) IP-adresser till värdar. AutoIP-protokollet bestämmer den länklokala IP-adressen på egen hand med hjälp av ett förhandlingsschema med andra värdar och utan åtkomst till en central server.

Använder PPPoE-protokollet

Förkortningen PPPoE står för "Point-to-Point Protocol over Ethernet". Detta protokoll kapslar in data för överföring över ett Ethernet-nätverk med en överbryggad topologi.

PPPoE är en specifikation för användaranslutning Ethernet-nätverk till Internet via en bredbandsanslutning, till exempel en hyrd digital abonnentlinje, trådlös enhet eller kabelmodem. Användningen av PPPoE-protokollet och ett bredbandsmodem ger användarna en lokal datornätverk individuell autentiserad åtkomst till höghastighetsdatanätverk.

PPPoE-protokollet kombinerar Ethernet-teknik med PPP-protokollet, vilket gör att du effektivt kan skapa en separat anslutning till en fjärrserver för varje användare. Åtkomstkontroll, anslutningsredovisning och val av tjänsteleverantör definieras för användare, inte för värdar. Fördelen med detta tillvägagångssätt är att varken telefonbolaget eller internetleverantören behöver ge något särskilt stöd för detta.

Till skillnad från uppringda anslutningar är DSL- och kabelmodemanslutningar alltid aktiva. Eftersom den fysiska anslutningen till fjärrtjänstleverantören delas av flera användare, behövs en redovisningsmetod som registrerar trafiksändare och destinationer och debiterar användare. PPPoE-protokollet tillåter en användare och en fjärrvärd som deltar i en kommunikationssession att lära sig varandras nätverksadresser under ett första utbyte som kallas upptäckt(upptäckt). När en session mellan en enskild användare och en fjärrvärd (t.ex. Internetleverantör) har upprättats, kan den sessionen övervakas för att göra periodiseringar. Många hem, hotell och företag delar Internet via digitala abonnentlinjer som använder Ethernet-teknik och PPPoE-protokollet.

En PPPoE-anslutning består av en klient och en server. Klienten och servern fungerar med alla gränssnitt som ligger nära Ethernet-specifikationerna. Det här gränssnittet används för att utfärda IP-adresser till klienter och binda dessa IP-adresser till användare och, valfritt, till arbetsstationer, istället för autentisering som endast baseras på arbetsstationen. PPPoE-servern skapar en punkt-till-punkt-anslutning för varje klient.

Konfigurera en PPPoE-session

För att skapa en PPPoE-session bör du använda tjänstenpppoed. Modulio-pkt-*sTillhandahåller PPPoE-protokolltjänster. Först måste du springaio-pkt-*Medlämplig förare. Exempel:

Klient-serverapplikation på en TCP-strömsocket

Följande exempel använder TCP för att tillhandahålla ordnade, pålitliga tvåvägsbyteströmmar. Låt oss bygga en komplett applikation som inkluderar en klient och en server. Först visar vi hur man konstruerar en server på TCP-strömuttag och sedan en klientapplikation för att testa vår server.

Följande program skapar en server som tar emot anslutningsförfrågningar från klienter. Servern byggs synkront, därför blockeras exekveringen av tråden tills servern går med på att ansluta till klienten. Denna applikation visar en enkel server som svarar på en klient. Klienten avslutar anslutningen genom att skicka ett meddelande till servern .

TCP-server

Skapandet av serverstrukturen visas i följande funktionsdiagram:

Här fullständig kod SocketServer.cs-program:

// SocketServer.cs använder System; använder System.Text; använder System.Net; använder System.Net.Sockets; namnutrymme SocketServer ( klass Program ( static void Main(string args) ( // Ställ in den lokala slutpunkten för sockeln IPHostEntry ipHost = Dns.GetHostEntry("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint(= new IPEndPoint(= new IPEndPoint 11000 ); // Skapa en Tcp/Ip-socket Socket sListener = new Socket(ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp); // Tilldela socket till lokal slutpunkt och lyssna efter inkommande sockets try (Bind(sListend.Point) ; sListener. Listen(10); // Börja lyssna efter anslutningar medan (true) (Console.WriteLine("Väntar på en anslutning på port (0)", ipEndPoint); // Programmet pausar och väntar på ett inkommande anslutning Sockethanterare = sListener.Accept(); string data = null; // Vi väntade på en klient som försöker ansluta till oss byte bytes = new byte; int bytesRec = handler.Receive(bytes); data += Encoding.UTF8. GetString(bytes, 0, bytesRec); // Visa data på konsolen Console.Write("Received text: " + data + "\n\n"); // Skickar ett svar till klienten\ string reply = "Tack för begäran i " + data.Length.ToString() + " tecken"; byte msg = Encoding.UTF8.GetBytes(reply); handler.Send(msg); if (data.IndexOf(" ") > -1) ( Console.WriteLine("Server avslutade anslutning med klient."); break; ) handler.Shutdown(SocketShutdown.Both); handler.Close(); ) ) catch (Undantag ex) ( Console.WriteLine (ex.ToString()); ) slutligen ( Console.ReadLine(); ) ) ) )

Låt oss titta på strukturen för detta program.

Det första steget är att ställa in den lokala slutpunkten för sockeln. Innan du öppnar ett uttag för att lyssna efter anslutningar måste du förbereda en lokal slutpunktsadress för det. Den unika TCP/IP-tjänsteadressen bestäms av kombinationen av värdens IP-adress med tjänstportnumret som skapar tjänstens slutpunkt.

Dns-klassen tillhandahåller metoder som returnerar information om nätverksadresserna som stöds av enheten i lokalt nätverk. Om en LAN-enhet har mer än en nätverksadress, returnerar Dns-klassen information om alla nätverksadresser, och applikationen måste välja rätt adress för att betjäna från arrayen.

Skapa en IPEndPoint för servern genom att kombinera den första värd-IP-adressen som erhålls från metoden Dns.Resolve() med portnumret:

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

Här representerar IPEndPoint-klassen localhost på port 11000. Skapa sedan en ny instans av Socket-klassen stream-uttag. Genom att ställa in en lokal slutpunkt för att lyssna efter anslutningar kan du skapa en socket:

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

Uppräkning AdressFamilj anger de adresseringsscheman som en instans av klassen Socket kan använda för att lösa en adress.

I parameter SocketType TCP- och UDP-uttag skiljer sig åt. Det kan innehålla följande värden:

Stöder datagram. Dgram-värdet kräver att du anger Udp för protokolltypen och InterNetwork i adressfamiljeparametern.

Stöder åtkomst till det underliggande transportprotokollet.

Stöder stream-uttag. Streamvärdet kräver att Tcp anges för protokolltypen.

Den tredje och sista parametern anger vilken typ av protokoll som krävs för sockeln. I parameter ProtocolType du kan ange följande viktigaste värden - Tcp, Udp, Ip, Raw.

Nästa steg bör vara att tilldela uttaget med metoden Binda(). När en socket öppnas av en konstruktör tilldelas den inget namn, bara ett handtag är reserverat. Metoden Bind() anropas för att tilldela ett namn till serversocket. För att klientuttaget ska kunna identifiera strömmen TCP-uttag, serverprogrammet måste namnge sin socket:

SListener.Bind(ipEndPoint);

Metoden Bind() binder en socket till en lokal slutpunkt. Du måste anropa Bind()-metoden innan några försök att anropa Listen()- och Accept()-metoderna.

Nu, efter att ha skapat en socket och kopplat ett namn till den, kan du lyssna på inkommande meddelanden med metoden lyssna(). I lyssningsläge väntar uttaget på inkommande anslutningsförsök:

SListener.Listen(10);

Parametern definierar eftersläpning (eftersläpning) A som anger det maximala antalet anslutningar som väntar på att bearbetas i kön. I koden ovan tillåter parameterns värde att upp till tio anslutningar ackumuleras i kön.

I lyssningsläge måste du vara redo att acceptera att ansluta till klienten, för vilken metoden används acceptera(). Denna metod erhåller en klientanslutning och fullbordar kopplingen mellan klient- och servernamn. Accept()-metoden blockerar det anropande programmets tråd tills en anslutning tas emot.

Accept()-metoden hämtar den första anslutningsbegäran från kön av väntande förfrågningar och skapar en ny socket för att hantera den. Medan den nya socket skapas fortsätter den ursprungliga socket att lyssna och kan användas med multithreading för att acceptera flera anslutningsförfrågningar från klienter. Ingen serverapplikation ska stänga avlyssningsuttaget. Den måste fortsätta att fungera tillsammans med sockets som skapats av Accept-metoden för att behandla inkommande klientförfrågningar.

While (true) (Console.WriteLine("Väntar på en anslutning på port (0)", ipEndPoint); // Programmet pausar och väntar på en inkommande anslutning Sockethanterare = sListener.Accept();

När klienten och servern har upprättat en förbindelse sinsemellan kan du skicka och ta emot meddelanden med metoderna Skicka() och motta() Uttagsklass.

Metoden Send() skriver utgående data till uttaget som är anslutet till. Metoden Receive() läser in inkommande data på stream-socket. När du använder ett TCP-baserat system måste en anslutning upprättas mellan uttagen innan metoderna Send() och Receive() körs. Det exakta protokollet mellan två interagerande enheter måste bestämmas i förväg så att klient- och serverapplikationerna inte blockerar varandra, utan att veta vem som ska skicka deras data först.

När datautbytet mellan servern och klienten är slutfört måste du stänga anslutningen med metoderna stänga av() och Stänga():

Handler.Shutdown(SocketShutdown.Both); handler.Close();

SocketShutdown är en uppräkning som innehåller tre värden för att stoppa: Både- slutar skicka och ta emot data på uttaget, motta- slutar ta emot data på uttaget och skicka- stoppar uttaget från att skicka data.

Socket stängs när metoden Close() anropas, vilket också ställer in sockets Connected-egenskap till false.

Klient på TCP

Funktionerna som används för att skapa en klientapplikation är mer eller mindre som en serverapplikation. När det gäller servern används samma metoder för att bestämma slutpunkten, instansiera socket, skicka och ta emot data och stänga socket.

Resa genom nätverksprotokoll.

TCP och UDP är båda transportlagerprotokoll. UDP är ett anslutningslöst protokoll med icke-garanterad paketleverans. TCP (Transmission Control Protocol) är ett anslutningsorienterat protokoll med garanterad leverans av paket. Först inträffar ett handslag (Hej | Hej | Låt oss chatta? | Kom igen.), varefter anslutningen anses vara upprättad. Vidare skickas paket fram och tillbaka över denna anslutning (det finns en konversation), och med en kontroll om paketet har nått mottagaren. Om paketet tappas bort eller nås, men med ett slagträ kontrollsumma, sedan skickas den igen ("upprepa, hörde inte"). Således är TCP mer tillförlitligt, men det är svårare när det gäller implementering och kräver följaktligen fler cykler / minne, vilket inte är det senaste värdet för mikrokontroller. Exempel på applikationsprotokoll som använder TCP inkluderar FTP, HTTP, SMTP och många andra.

TL;DR

HTTP (Hypertext Transfer Protocol) är ett applikationsprotokoll med vilket servern skickar sidor till vår webbläsare. HTTP är nu allmänt förekommande i world wide web för att få information från webbplatser. På bilden sitter lampan på en mikrokontroller med ett OS ombord, där färger ställs in via en webbläsare.

HTTP-protokollet är textbaserat och ganska enkelt. Det är faktiskt så här GET-metoden som skickas av netcat-verktyget till den lokala IPv6-adressen för servern med lampor ser ut:

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

HTTP-metoden är vanligtvis ett kort engelskt ord skrivet med versaler, skiftlägeskänsligt. Varje server måste stödja åtminstone metoderna GET och HEAD. Förutom metoderna GET och HEAD används ofta metoderna POST, PUT och DELETE. GET-metoden används för att begära innehållet i den angivna resursen, i vårt fall här GET /b HTTP/1.0 där /b-sökvägen är ansvarig för färgen (blå). Serversvar:

HTTP/1.0 200 OK Server: Contiki/2.4 http://www.sics.se/contiki/ Anslutning: stäng Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0 Content- typ: text/html

Rött är AV

Grönt är AV

Blått är PÅ

Statuskoden (vi har 200) är en del av den första raden i serverns svar. Det är ett tresiffrigt heltal. Den första siffran anger statusklassen. Svarskoden följs vanligtvis av en mellanslagsseparerad förklarande fras på engelska, som förklarar för personen orsaken till ett sådant svar. I vårt fall fungerade servern utan fel, allt var i ett gäng (OK).

Både begäran och svaret innehåller rubriker (varje rad är ett separat rubrikfält, namn-värde-paret separeras med ett kolon). Rubriker slutar med en tom rad, varefter data kan följa.

Min webbläsare vägrar att öppna en lokal IPv6-adress, så en extra adress är registrerad i mikrokontrollerns firmware och samma prefix måste också tilldelas simulatorns virtuella nätverksgränssnitt:

~$ sudo ip-adr lägg till abcd::1/64 dev mazko # linux ~$ netsh-gränssnitt ipv6 ange adress mazko abcd::1 # windows ~$ curl http://

TCP integreras naturligt i klient/servermiljön (se figur 10.1). Serverapplikation buggar(lyssna) inkommande anslutningsförfrågningar. Till exempel, tjänsterna WWW, filöverföring eller terminalåtkomst lyssnar efter förfrågningar från klienter. Kommunikation i TCP initieras av lämpliga subrutiner som initierar anslutningen till servern (se kapitel 21 om sockets API).

Ris. 10.1. Klienten anropar servern.

I verkligheten kan klienten vara en annan server. Till exempel kan e-postservrar ansluta till andra e-postservrar för att skicka e-postmeddelanden mellan datorer.

I vilken form ska applikationer skicka data i TCP? Hur överför TCP data till IP? Hur identifierar sändande och mottagande TCP-protokoll en applikation-till-applikation-anslutning och de dataelement som krävs för att implementera den? Alla dessa frågor besvaras i följande avsnitt, som beskriver de grundläggande koncepten för TCP.

Konceptuell anslutningsmodellen förutsätter att en applikation skickar en dataström till en peer-applikation. Samtidigt kan den ta emot en dataström från sin anslutningspartner. TCP tillhandahåller full duplex(full duplex) driftläge där båda två strömmar data (se figur 10.2).

Ris. 10.2. Applikationer utbyter dataströmmar.

TCP kan konvertera den utgående dataströmmen från en applikation till en form som lämpar sig för placering i datagram. Hur?

Applikationen skickar data till TCP, och detta protokoll lägger in den utgångsbuffert(skicka buffert). Därefter skär TCP bitar av data från bufferten och skickar dem och lägger till en rubrik (i det här fallet, segment segmentet). På fig. 10.3 visar hur uppgifterna från utgångsbuffert TCP:er paketeras i segment. TCP skickar segmentet till IP för leverans som ett enda datagram. Att packa data i bitar av rätt längd säkerställer effektiv vidarebefordran, så TCP väntar tills lämplig mängd data finns i utdatabufferten innan ett segment skapas.

Ris. 10.3 Skapa ett TCP-segment

Men stora mängder data är ofta inte tillämpliga på verkliga tillämpningar. Till exempel, när ett slutanvändarklientprogram initierar en interaktiv session med en fjärrserver, anger användaren bara kommandon (följt av att trycka på lämna tillbaka).

Användarens klientprogram behöver TCP för att veta att data skickas till fjärrvärden och för att utföra denna operation omedelbart. I det här fallet används det extrudering(tryck).

Om du tittar på operationerna i en interaktiv session kan du hitta många shards med lite data, och vad mer är, popning kan hittas i nästan varje data shard. Popping bör dock inte användas under filöverföringar (förutom för det allra sista segmentet), och TCP kommer att kunna packa data i segment mest effektivt.

Applikationens modell för vidarebefordran av data antar en ordnad ström av bytes på väg till destinationen. Med hänvisning till exemplet med den interaktiva sessionen, anta att användaren tryckte på en tangent uppmärksamhet(uppmärksamhet) eller ha sönder(avbryta). Fjärrapplikationen måste kunna hoppa över de störande byten och svara på tangenttryckningen så snart som möjligt.

Mekanism brådskande uppgifter(brådskande data) markerar särskild information i segmentet som brådskande. Med denna TCP talar om för sin peer att segmentet innehåller brådskande data och kan indikera var det är. Partnern bör vidarebefordra denna information till destinationsansökan så snart som möjligt.

Kunden måste identifiera den tjänst den vill ha tillgång till. Detta görs genom specifikationen av värdtjänstens IP-adress och dess TCP-portnummer. Precis som med UDP sträcker sig TCP-portnummer från 0 till 65535. Portar från 0 till 1023 är kända som välkända portar och används för att komma åt standardtjänster.

Några exempel på välkända portar och deras motsvarande tillämpningar visas i Tabell 10.1. Tjänster Kassera(port 9) och laddad(port 19) är TCP-versioner av de tjänster vi redan känner till från UDP. Tänk på att trafik på TCP-port 9 är helt isolerad från trafik på UDP-port 9.

Tabell 10.1 Välkända TCP-portar och deras motsvarande applikationer

Hur är det med portarna som används av klienter? I sällsynta fall körs inte klienten på en välkänd port. Men i sådana situationer, när man vill öppna en anslutning, ber det ofta operativsystemet att tilldela en oanvänd och oreserverad port till den. I slutet av anslutningen måste klienten returnera denna port, varefter porten kan återanvändas av en annan klient. Eftersom det finns över 63 000 TCP-portar i den icke-reserverade nummerpoolen kan klientportgränserna ignoreras.

Som vi redan vet kallas kombinationen av IP-adress och port för kommunikation uttagsadress. En TCP-anslutning identifieras helt av en socket-adress i varje ände av den anslutningen. På fig. Figur 10.4 visar en anslutning mellan en klient med socketadress (128.36.1.24, port = 3358) och en server med socketadress (130.42.88.22, port = 21).

Ris. 10.4. uttagsadresser

Rubriken på varje datagram innehåller käll- och destinations-IP-adresserna. I det följande kommer du att se att käll- och destinationsportnumren anges i TCP-segmenthuvudet.

Vanligtvis är en server kapabel att hantera flera klienter samtidigt. En servers unika socket-adresser tilldelas samtidigt till alla dess klienter (se figur 10.5).

Ris. 10.5. Flera klienter anslutna till serversockets adresser

Eftersom datagrammet innehåller ett TCP-anslutningssegment som identifieras av IP-adresser och portar, är det mycket enkelt för en server att hålla reda på flera anslutningar till klienter.

I det här avsnittet kommer vi att titta på TCP-mekanismen som används för att leverera data på ett tillförlitligt sätt samtidigt som vi bevarar vidarebefordran och undviker förlust eller dubbelarbete.

TCP använder numrering och bekräftelse (ACK) för att säkerställa tillförlitlig dataöverföring. TCP-numreringsschemat är något ovanligt: varje vidarebefordras över anslutningen oktett anses ha ett serienummer. TCP-segmenthuvudet innehåller ett sekvensnummer den första datoktetten i detta segment.

Mottagaren måste bekräfta mottagandet av uppgifterna. Om ingen ACK anländer inom timeout-intervallet sänds data om. Denna metod kallas positiv kvittering med relä(positiv bekräftelse med återsändning).

Mottagaren av TCP-data utför en strikt kontroll av de inkommande sekvensnumren för att kontrollera sekvensen i vilken data togs emot och att det inte finns några förlorade delar. Eftersom ACK slumpmässigt kan gå förlorad eller fördröjas, kan duplicerade segment komma fram till mottagaren. Sekvensnummer låter dig bestämma dupliceringen av data, som sedan kasseras.

På fig. Figur 10.6 visar en förenklad vy av timeout och återsändning i TCP.

Ris. 10.6. Timeout och återsändning i TCP

Såsom visas i fig. 10.7 ger de första fälten i TCP-huvudet utrymme för käll- och destinationsportvärdena, sekvensnumret för den första byten av inbäddade data och en ACK lika med sekvensnumret Nästa byte förväntas i andra änden. Med andra ord, om TCP:n tar emot alla bytes upp till 30 från sin peer, kommer detta fält att ha värdet 31, vilket indikerar segmentet som ska vidarebefordras härnäst.

Ris. 10.7. Initiala värden i TCP-huvudfält

En liten detalj bör noteras. Antag att TCP har skickat byte 1 till 50 och att det inte finns mer data att skicka. Om data tas emot från en peer måste TCP bekräfta mottagandet genom att skicka en rubrik utan data kopplad till den. Naturligtvis finns ACK-värdet i denna rubrik. I sekvensfältet - värdet 51, dvs. nästa bytenummer avser skicka TCP. När TCP:n skickar nästa data kommer den nya TCP-huvudet också att ha värdet 51 i sekvensfältet.

Hur är de två applikationerna kopplade? Före kommunikation anropar var och en av dem en rutin för att bilda ett minnesblock som kommer att användas för att lagra TCP- och IP-parametrarna för denna anslutning, såsom uttagsadresser, aktuellt sekvensnummer, initialt livstidsvärde och så vidare.

Serverapplikationen väntar på att en klient ska dyka upp, som vill komma åt servern och skickar en begäran till förening(anslut) som identifierar serverns IP-adress och port.

Det finns en teknisk funktion. Varje sida börjar numrera varje byte, inte från en, utan från slumpmässigt serienummer(Vi får se varför detta görs senare.) Den ursprungliga specifikationen rekommenderar att man genererar det initiala sekvensnumret baserat på en 32-bitars extern timer som ökar ungefär var fjärde µs.

Anslutningsproceduren hänvisas ofta till som en trevägshandskakning, eftersom tre meddelanden utbyts för att upprätta en anslutning - SYN, SYN och ACK.

Under upprättandet av en anslutning utbyter partner tre viktiga delar av information:

1. Mängden buffertutrymme för att ta emot data

2. Den maximala mängden data som transporteras i det inkommande segmentet

3. Initialt sekvensnummer som används för utgående data

Observera att varje sida använder operationerna 1 och 2 för att indikera gränser för vilka den andra parten kommer att agera. En persondator kan ha en liten mottagningsbuffert, medan en superdator kan ha en enorm buffert. Minnesstrukturen hos en persondator kan begränsa de inkommande delarna av data till 1 KB, och superdatorn styrs med stora segment.

Möjligheten att kontrollera hur den andra sidan skickar data är en viktig funktion som gör TCP/IP skalbar.

På fig. Figur 10.8 visar ett exempel på anslutningsskript. Mycket enkla startsekvensnummer tillhandahålls för att inte överbelasta figuren. Observera att i denna figur kan klienten ta emot större segment än servern.

Ris. 10.8. Att upprätta en koppling

Följande operationer utförs:

1. Servern initieras och blir redo att ansluta till klienter (det här tillståndet kallas passiv öppen - passiv öppen).

2. Klienten ber TCP att öppna en anslutning till servern på angiven IP-adress och port (detta tillstånd kallas aktiv öppen).

3. Klientens TCP tar emot det initiala sekvensnumret (1000 i detta exempel) och skickar tidssegment(synkronisera segment - SYN). I detta segment skickas sekvensnumret, storleken på mottagningsfönstret (4K) och storleken på det största segmentet som klienten kan ta emot (1460 byte).

4. När en SYN anländer tar serverns TCP emot mina startsekvensnummer (3000). Den skickar ett SYN-segment som innehåller det initiala sekvensnumret (3000), ACK 1001 (vilket innebär numrering av den första byten som skickats av klienten som 1001), mottagarfönsterstorleken (4K) och storleken på det största segmentet som servern kan ta emot (1024 byte).

5. Klientens TCP, efter att ha tagit emot ett SYN/ACK-meddelande från servern, skickar tillbaka ACK 3001 (den första byten av data som skickas av servern ska numreras som 3001).

6. Klient-TCP säger till sin applikation att öppna en anslutning.

7. Serverns TCP, som har mottagit ett ACK-meddelande från klientens TCP, informerar sin applikation om att anslutningen har öppnats.

Klienten och servern tillkännager sina regler för mottagen data, synkroniserar sina sekvensnummer och blir redo att utbyta data. TCP-specifikationen tillåter också ett annat scenario (inte särskilt bra) där peer-applikationer aktivt öppnar varandra samtidigt.

En applikations begäran om att upprätta en anslutning kan också ange parametrar för de IP-datagram som ska bära anslutningens data. Om inget specifikt parametervärde anges används standardvärdet.

Till exempel kan en applikation välja önskat värde för IP-prioritet eller typ av tjänst. Eftersom var och en av de anslutna parterna självständigt anger sin egen prioritet och typ av tjänst, kan dessa värden teoretiskt skilja sig åt för olika riktningar av dataflöden. Som regel gäller i praktiken samma värden för varje utbytesriktning.

När ett program använder statliga eller militära säkerhetsalternativ måste varje anslutningsändpunkt använda samma säkerhetsnivåer annars kommer anslutningen att misslyckas.

Dataöverföringen startar efter slutförandet av bekräftelsen på att skapa en anslutning i tre steg (se figur 10.9). TCP-standarden tillåter att normal data inkluderas i bekräftelsesegment, men den kommer inte att levereras till applikationen förrän anslutningen är klar. För att förenkla numreringen används 1000-byte meddelanden. Varje TCP-huvudsegment har ett ACK-fält som identifierar bytesekvensnumret som förväntas tas emot från anslutningspartnern..

Ris. 10.9. Enkelt dataflöde och ACK

Det första segmentet som skickas av klienten innehåller bytes från 1001 till 2000. Dess ACK-fält måste innehålla värdet 3001, vilket anger bytesekvensnumret som förväntas tas emot från servern.

Servern svarar klienten med ett segment som innehåller 1000 byte data (som börjar med nummer 3001). Dess ACK-fält i TCP-huvudet kommer att indikera att byte 1001 till 2000 redan har tagits emot framgångsrikt, så nästa förväntade segmentsekvensnummer från klienten bör vara 2001.

Klienten skickar sedan segment som börjar med byte 2001, 3001 och 4001 i den ordningen. Observera att klienten inte förväntar sig ett ACK efter varje skickat segment. Data skickas till peeren tills dess buffertutrymme är fullt (vi kommer att se nedan att mottagaren mycket exakt kan specificera mängden data som ska skickas till den).

Servern sparar anslutningsbandbredd genom att använda en enda ACK för att indikera att alla segment har vidarebefordrats.

På fig. Figur 10.10 visar vidarebefordran av data när det första segmentet går förlorat. När timeouten löper ut sänds segmentet om. Notera att vid mottagande av ett förlorat segment skickar mottagaren ett ACK som bekräftar vidarebefordran av båda segmenten.

Ris. 10.10. Dataförlust och återöverföring

Normal avslutning av en anslutning utförs med samma trippelhandskakningsprocedur som när en anslutning öppnas. Varje part kan börja stänga anslutningen i följande scenario:

A:

B:"Bra".

PÅ:— Jag avslutade också jobbet.

A:"Bra".

Följande scenario är också acceptabelt (även om det används extremt sällan):

A:"Jag har avslutat jobbet. Det finns ingen mer data att skicka."

PÅ:"Bra. Men det finns vissa uppgifter..."

PÅ:— Jag avslutade också jobbet.

A:"Bra".

I exemplet nedan stänger anslutningen servern, vilket ofta är fallet för klient/server-kommunikation. I det här fallet, efter att användaren går in i sessionen telnet logout kommando (logga ut från systemet) servern initierar en begäran om att stänga anslutningen. I den situation som visas i fig. 10.11 utförs följande åtgärder:

1. Applikationen på servern uppmanar TCP att stänga anslutningen.

2. Serverns TCP skickar ett Final Segment (FIN) och informerar sin peer om att det inte finns mer data att skicka.

3. Klientens TCP skickar ett ACK på FIN-segmentet.

4. Klientens TCP talar om för sin applikation att servern vill stänga anslutningen.

5. Klientapplikationen informerar sin TCP om att anslutningen är stängd.

6. Klientens TCP skickar ett FIN-meddelande.

7. Serverns TCP tar emot FIN från klienten och svarar med ett ACK-meddelande.

8. Serverns TCP säger åt sin applikation att stänga anslutningen.

Ris. 10.11. Stänger en anslutning

Båda parter kan börja stänga samtidigt. I detta fall slutförs den normala stängningen av anslutningen efter att var och en av peers skickar ett ACK-meddelande.

Båda parterna kan begära ett abrupt avbrott av anslutningen. Detta är acceptabelt när ett program vill avsluta en anslutning, eller när TCP upptäcker ett allvarligt kommunikationsproblem som det inte kan lösa på egen hand. En abrupt avslutning begärs genom att skicka ett eller flera återställningsmeddelanden till peeren, vilket indikeras av en specifik flagga i TCP-huvudet.

TCP-mottagaren laddas med den inkommande dataströmmen och bestämmer hur mycket information den kan acceptera. Denna begränsning påverkar TCP-avsändaren. Följande förklaring av denna mekanism är konceptuell, och utvecklare kan implementera den på olika sätt i sina produkter.

Under anslutningsuppsättningen tilldelar varje peer utrymme för anslutningens ingångsbuffert och meddelar den andra parten om detta. Vanligtvis uttrycks buffertstorleken som ett heltal av maximala segmentstorlekar.

Dataströmmen går in i ingångsbufferten och lagras där tills den vidarebefordras till applikationen (bestäms av TCP-porten). På fig. Figur 10-12 visar en ingångsbuffert som kan ta 4 KB.

Ris. 10.12. Fönstret för mottagning av inmatningsbuffert

Buffertutrymmet fylls upp när data anländer. När den mottagande applikationen hämtar data från bufferten blir det frigjorda utrymmet tillgängligt för ny inkommande data.

mottagningsfönster(mottagningsfönster) - vilket utrymme som helst i inmatningsbufferten som inte redan är upptaget av data. Data förblir i inmatningsbufferten tills den används av målapplikationen. Varför samlar inte applikationen in data omedelbart?

Ett enkelt scenario hjälper dig att besvara denna fråga. Låt oss anta att en klient har laddat upp en fil till en FTP-server som körs på en mycket upptagen dator med flera användare. FTP-programmet måste sedan läsa data från bufferten och skriva till disken. När servern utför disk I/O-operationer väntar programmet på att dessa operationer ska slutföras. Vid denna tidpunkt kan ett annat program starta (till exempel enligt ett schema) och när FTP-programmet startar igen kommer nästa data redan att finnas i bufferten.

Mottagningsfönstret utökas från den senast bekräftade byten till slutet av bufferten. På fig. 10.12 är hela bufferten först tillgänglig, och därför är ett 4K-mottagningsfönster tillgängligt. När den första KB anländer kommer mottagningsfönstret att reduceras till 3 KB (för enkelhetens skull antar vi att varje segment är 1 KB stort, även om detta värde i praktiken varierar beroende på applikationens behov). Ankomsten av de kommande två 1K-segmenten kommer att minska mottagningsfönstret till 1K.

Varje ACK som skickas av mottagaren innehåller information om det aktuella tillståndet för mottagningsfönstret, beroende på vilket dataflöde från källan som regleras.

För det mesta ställs storleken på ingångsbufferten in vid anslutningens starttid, även om TCP-standarden inte anger hur denna buffert ska hanteras. Inmatningsbufferten kan växa eller krympa för att ge feedback till avsändaren.

Vad händer om ett inkommande segment kan placeras i mottagningsfönstret, men det kommer ur funktion? Det anses allmänt att alla implementeringar lagrar inkommande data i mottagningsfönstret och skickar en bekräftelse (ACK) endast för ett helt sammanhängande block av flera segment. Detta är det korrekta sättet, för annars försämrar prestanda avsevärt att kassera data som inte fungerar.

Ett system som sänder data måste hålla reda på två egenskaper: hur mycket data som redan har skickats och bekräftats, och den aktuella storleken på mottagarens mottagningsfönster. Aktiva skicka utrymme(sänd mellanslag) Sträcker sig från den första okvitterade oktetten till vänster om det aktuella mottagningsfönstret. Del fönster Begagnade att skicka, anger hur mycket ytterligare data som kan skickas till partnern.

Det initiala sekvensnumret och det initiala mottagningsfönstrets storlek ställs in under anslutningsinstallationen. Ris. 10.13 illustrerar några av funktionerna i dataöverföringsmekanismen.

1. Avsändaren börjar med ett sändningsfönster på 4 KB.

2. Avsändaren skickar 1 KB. En kopia av dessa data bevaras tills en bekräftelse (ACK) tas emot eftersom den kan behöva sändas om.

3. En ACK för den första KB kommer och nästa 2 KB data skickas. Resultatet visas i den tredje delen från toppen av fig. 10.13. Lagring av 2 KB fortsätter.

4. Slutligen anländer en ACK för all sänd data (d.v.s. all mottagen av mottagaren). ACK återställer sändningsfönstrets storlek till 4 KB.

Ris. 10.13. Skicka fönster

Flera intressanta egenskaper bör påpekas:

■ Avsändaren väntar inte på ett ACK för vart och ett av de datasegment som den skickar. Den enda begränsningen för överföringen är storleken på mottagningsfönstret (till exempel måste avsändaren bara överföra 4K enbytesegment).

■ Antag att avsändaren skickar data i flera mycket korta segment (till exempel 80 byte). I detta fall kan data omformateras för effektivare överföring (t.ex. till ett enda segment).

På fig. Figur 10.14 visar segmentformatet (TCP-huvud och data). Rubriken börjar med käll- och destinationsport-ID. Nästa fält serienummer(sekvensnummer) indikerar positionen i den utgående dataströmmen som detta segment upptar. Fält ACK(bekräftelse) innehåller information om det förväntade nästa segmentet som ska visas i indataströmmen.

Ris. 10.14. TCP-segment

Det finns sex flaggor:

Fält dataförskjutningar(Data Offset) innehåller storleken på TCP-huvudet i 32-bitars ord. TCP-huvudet måste sluta på en 32-bitars gräns.

Parameter "maximal segmentstorlek"(maximal segmentstorlek - MSS) används för att deklarera den största biten av data som kan tas emot och bearbetas av systemet. Rubriken är dock något felaktig. Vanligtvis i TCP segmentet behandlas som header plus data. i alla fall maximal segmentstorlek definierad som:

Storleken på det största datagrammet som kan tas emot är 40

Med andra ord, MSS speglar det största nyttolast vid mottagaren när TCP- och IP-huvudena är 20 byte långa. Om det finns ytterligare parametrar, bör deras längd subtraheras från den totala storleken. Därför definieras mängden data som kan skickas i ett segment som:

Deklarerat MSS-värde + 40 - (summan av TCP- och IP-huvudlängder)

Vanligtvis utbyter peers MSS-värden i initiala SYN-meddelanden när en anslutning öppnas. Om systemet inte annonserar den maximala segmentstorleken, används standardvärdet på 536 byte.

Den maximala segmentstorleken kodas med en 2-byte ingress följt av ett 2-byte värde, dvs. det största värdet skulle vara 2 16 -1 (65 535 byte).

MSS sätter en hård gräns för data som skickas till TCP: mottagaren kommer inte att kunna behandla stora värden. Avsändaren använder dock segment mindre storlek eftersom MTU-storleken längs rutten också bestäms för anslutningen.

Det första segmentet som skickas för att öppna en anslutning har en SYN-flagga på 1 och en ACK-flagga på 0. Den initiala SYN är det enda ett segment som har ett ACK-fält på 0. Observera att säkerheten använder den här funktionen för att upptäcka inkommande förfrågningar om en TCP-session.

Fält serienummer innehåller startsekvensnummer(initial sekvensnummer), fält fönster - initial storlek mottagningsfönster. Den enda TCP-inställning som för närvarande definieras är den maximala segmentstorleken (när den inte anges används standardvärdet på 536 byte) som TCP ska ta emot. Detta värde är 32 bitar långt och finns vanligtvis i anslutningsbegäran i fältet alternativ(Alternativ). Längden på TCP-huvudet som innehåller MSS-värdet är 24 byte.

I ett tillåtet svar på en anslutningsbegäran är båda flaggorna (SYN och ACK) satta till 1. Det svarande systemet indikerar startsekvensnumret i motsvarande fält och mottagarfönstrets storlek i fältet Fönster. Den maximala segmentstorleken som mottagaren vill använda finns vanligtvis i anslutningssvaret (i alternativ). Detta värde kan skilja sig från värdet på den part som begär anslutningen, dvs. två olika värden kan användas.

En anslutningsbegäran kan avvisas genom att ange en återställningsflagga (RST) med värdet 1 i svaret.

TCP-specifikationen förutsätter att varje part väljer under upprättandet av en anslutning startsekvensnummer(baserat på det aktuella värdet för den 32-bitars interna timern). Hur görs det?

Föreställ dig vad som händer när systemet kraschar. Anta att användaren öppnade en anslutning precis innan kraschen och skickade en liten mängd data. Efter återställning kommer systemet inte längre ihåg något som gjordes före kraschen, inklusive anslutningar som redan körs och tilldelade portnummer. Användaren återupprättar anslutningen. Portnumren stämmer inte överens med de ursprungliga tilldelningarna, och vissa av dem kan redan användas av andra anslutningar som upprättats några sekunder före kraschen.

Därför kanske den andra sidan i slutet av anslutningen inte är medveten om att dess partner gick igenom en krasch och sedan återställdes. Allt detta kommer att leda till allvarliga störningar, speciellt när det tar lång tid innan den gamla datan passerar genom nätverket och blandas med data från den nyskapade anslutningen. Att välja en starttimer med en uppdatering (nystart) eliminerar sådana problem. De gamla data kommer att ha en annan numrering än sekvensnummerintervallet för den nya anslutningen. När hackare spoofar en käll-IP-adress för en betrodd värd, försöker de få tillgång till datorer genom att ange ett förutsägbart startsekvensnummer i meddelandet. En kryptografisk hashfunktion baserad på interna nycklar är det bästa sättet att välja säkra frönummer.

När TCP-huvudet förbereds för överföring, anges sekvensnumret för den första oktetten av de överförda data i fältet serienummer(Sekvensnummer).

Numret på nästa oktett som förväntas från anslutningspartnern anges i fältet Bekräftelse(Bekräftelsenummer) när ACK-biten är inställd på 1. Fält fönster(Fönster) är för den aktuella mottagningsfönstrets storlek. Detta fält innehåller antalet byte från bekräftelsenumret som kan accepteras. Observera att detta värde tillåter exakt kontroll av dataflödet. Med detta värde indikerar peeren det faktiska tillståndet för mottagningsfönstret under utbytessessionen.

Om en applikation indikerar en TCP-push-operation, så sätts PUSH-flaggan till 1. Den mottagande TCP:n MÅSTE svara på denna flagga genom att snabbt leverera data till applikationen så snart avsändaren önskar vidarebefordra den.

BRINGT-flaggan, om satt till 1, innebär en brådskande dataöverföring, och motsvarande pekare måste peka på den sista oktetten av brådskande data. En typisk användning för brådskande data är att skicka signaler från terminalen för att avbryta eller avbryta.

Brådskande data kallas ofta information utanför bandet(utanför bandet). Denna term är dock felaktig. Brådskande data skickas på en normal TCP-ström, även om individuella implementeringar kan ha speciella mekanismer för att indikera för en applikation att brådskande data har anlänt, och applikationen måste undersöka innehållet i brådskande data innan alla bytes i meddelandet anländer.

RESET-flaggan är satt till 1 när en anslutning ska avbrytas. Samma flagga sätts i svaret när ett segment tas emot som inte är associerat med någon av de aktuella TCP-anslutningarna.

FIN-flaggan är satt till 1 för meddelanden om anslutningsstängning.

IP-kontrollsumman är endast för IP-huvudet, medan TCP-kontrollsumman beräknas för hela segmentet såväl som pseudohuvudet som genereras från IP-huvudet. Under beräkningen av TCP-kontrollsumman sätts motsvarande fält till 0. I fig. Figur 10-15 visar ett pseudohuvud som är mycket likt det som används i UDP-kontrollsumman.

Ris. 10.15. Pseudohuvudfält inkluderat i TCP-kontrollsumman

TCP-längden beräknas genom att lägga till längden på TCP-huvudet till längden på data. TCP-kontrollsumman är obligatorisk, inte som i UDP. Kontrollsumman för det inkommande segmentet beräknas först av mottagaren och jämförs sedan med innehållet i TCP-huvudets kontrollsummafält. Om värdena inte stämmer överens slängs segmentet.

Ris. 10.16, analysatorprotokoll Sniffer av Network General, är en sekvens av TCP-segment. De tre första segmenten upprättar anslutningen mellan klienten och servern telnet. Det sista segmentet bär 12 byte data.

Ris. 10.16. TCP Header Display av Sniffer Parser

Analysator Snifferöversätter de flesta värden till decimaler. Flaggvärden matas dock ut som hexadecimala. Flaggan med värde 12 är 010010. Kontrollsumman matas också ut i hexadecimal form.

En snabb avsändare och en långsam mottagare kan bilda ett 0-byte mottagningsfönster. Detta resultat kallas fönster stängs(Stäng fönstret). När det finns ledigt utrymme för att uppdatera mottagarfönstrets storlek, används ACK. Men om ett sådant meddelande går förlorat måste båda parter vänta på obestämd tid.

För att undvika denna situation sätter avsändaren spara timer(beständig timer) när du stänger ett premiumfönster. Värdet på timern är återsändningstidsgränsen. I slutet av timern skickas ett segment till partnern avkänningsfönster(fönstersond; vissa implementeringar inkluderar data). Sonden får kamraten att skicka tillbaka en ACK som rapporterar fönstrets aktuella status.

Om fönstret fortfarande är noll, fördubblas värdet på den ihållande timern. Denna process upprepas tills timervärdet når maximalt 60 s. TCP kommer att fortsätta att skicka sondmeddelanden var 60:e sekund tills ett fönster öppnas, tills användaren avslutar processen eller tills programmet tar slut.

Anslutningspartnern kan krascha eller bli helt avbruten på grund av ett gateway- eller länkfel. För att förhindra återöverföring av data i TCP finns det flera mekanismer.

När den första tröskeln för återsändning (relä) nås, säger TCP till IP att leta efter den trasiga routern och informerar samtidigt applikationen om problemet. TCP fortsätter att skicka data tills det andra gränsvärdet nås, och först då stänger anslutningen.

Innan detta händer kan det naturligtvis finnas ett ICMP-meddelande som indikerar att destinationen av någon anledning inte går att nå. I vissa implementeringar, även efter detta, kommer TCP att fortsätta att försöka komma åt destinationen tills timeout-intervallet löper ut (då problemet kan vara åtgärdat). Därefter informeras applikationen om att destinationen inte går att nå.

En applikation kan ställa in sin egen dataleverans timeout och utföra sina egna operationer när detta intervall löper ut. Vanligtvis avslutas anslutningen.

När en oavslutad anslutning har data att skicka under en längre tid, får den inaktiv status. Under en period av inaktivitet kan en nätverkskrasch eller ett fysiskt länkfel inträffa. Så fort nätverket är i drift igen kommer partnerna att fortsätta utbyta data utan att avbryta kommunikationssessionen. Denna strategi uppfyllde kraven från försvarsministeriet.

Men varje anslutning - aktiv eller inaktiv - tar upp mycket datorminne. Vissa administratörer behöver returnera oanvända resurser till systemen. Därför är många TCP-implementeringar kapabla att skicka ett meddelande om upprätthålla en anslutning(keep-alive) som testar inaktiva anslutningar. Sådana meddelanden skickas med jämna mellanrum till partnern för att kontrollera dess existens i nätverket. Svaret måste vara ACK-meddelanden. Det är valfritt att använda meddelanden om att hålla liv vid liv. Om systemet har denna förmåga kan applikationen åsidosätta den på egen hand. Beräknad period standard för anslutningens underhållstimeout är hela två timmar!

Kom ihåg att applikationen kan ställa in sin egen timer, enligt vilken den på sin nivå kommer att besluta om uppsägning av anslutningen.

Hur effektivt är TCP? Resursprestanda påverkas av många faktorer, de viktigaste är minne och bandbredd (se figur 10.17).

Ris. 10.17. TCP-prestandafaktorer

Bandbredd och förseningar i det fysiska nätverket som används begränsar kraftigt genomströmningen. Dålig dataöverföringskvalitet resulterar i en stor volym kasserade datagram, vilket orsakar omsändningar och följaktligen minskar bandbreddseffektiviteten.

Den mottagande sidan måste tillhandahålla tillräckligt buffertutrymme för att tillåta avsändaren att överföra data utan pauser i driften. Detta är särskilt viktigt för nätverk med hög latens, där det går lång tid mellan att skicka data och ta emot ACK (och även när man förhandlar om fönsterstorleken). För att upprätthålla en stadig ström av data från källan måste den mottagande sidan ha ett fönster som inte är mindre än produkten av bandbredd och fördröjning.

Till exempel, om källan kan skicka data med en hastighet av 10 000 byte/s, och det tar 2 sekunder att returnera en ACK, måste mottagningsfönstret på andra sidan vara minst 20 000 byte stort, annars kommer dataflödet att inte vara kontinuerlig. En mottagningsbuffert på 10 000 byte kommer att halvera genomströmningen.

En annan viktig faktor för prestanda är värdens förmåga att svara på högprioriterade händelser och snabbt utföra kontextbyte, dvs. slutföra en operation och byta till en annan. Värden kan interaktivt stödja flera lokala användare, batch-bakgrundsprocesser och dussintals samtidiga kommunikationsanslutningar. Kontextväxling gör att du kan utföra alla dessa operationer och dölja belastningen på systemet. Implementationer som integrerar TCP/IP med operativsystemets kärna kan avsevärt minska belastningen från att använda kontextväxling.

Dator-CPU-resurser krävs för TCP-huvudbearbetningsoperationer. Om processorn inte snabbt kan beräkna kontrollsummorna leder detta till en minskning av hastigheten på dataöverföringen över nätverket.

Dessutom bör utvecklare försöka förenkla konfigurationen av TCP-inställningar så att en nätverksadministratör kan anpassa dem för att passa deras lokala krav. Till exempel kommer möjligheten att justera buffertstorleken för bandbredd och nätverkslatens att förbättra prestandan avsevärt. Tyvärr uppmärksammar många implementeringar inte detta problem tillräckligt och hårdkodar kommunikationsparametrarna.

Låt oss anta att nätverksmiljön är perfekt: det finns tillräckliga resurser och sammanhangsbyte går snabbare än vad cowboys drar. Kommer utmärkt prestanda att uppnås?

Inte alltid. Kvaliteten på TCP-programvaruutveckling spelar också roll. Under årens lopp har många prestandaproblem diagnostiserats och lösts i olika TCP-implementeringar. Det kan anses att den bästa mjukvaran kommer att vara den som överensstämmer med RFC 1122, som definierar kraven för kommunikationslagret hos Internetvärdar.

Ett lika viktigt undantag och tillämpningen av Jacobson, Kern och Partridge algoritmer (dessa intressanta algoritmer kommer att diskuteras nedan).

Mjukvaruutvecklare kan få betydande fördelar genom att skapa program som eliminerar onödiga små dataöverföringar och har inbyggda timers för att frigöra nätverksresurser som för närvarande inte används.

För att gå vidare till en introduktion till den ganska komplexa delen av TCP, kommer vi att titta på mekanismer för att förbättra prestanda och hantera genomströmningsförsämringar. Det här avsnittet diskuterar följande frågor:

■ långsam start(långsam start) förhindrar att en stor mängd nätverkstrafik används för en ny session, vilket kan leda till overhead.

■ Läkning från Clueless Window Syndrome(silly window syndrome) förhindrar dåligt designade applikationer från att översvämma nätverket med meddelanden.

■ Försenad ACK(fördröjd ACK) minskar trängseln genom att minska antalet oberoende bekräftelsemeddelanden för dataöverföring.

■ Beräknad tidsgräns för återsändning(timeout för återsändning av datorer) förlitar sig på sessionsförhandling i realtid, vilket minskar onödiga omsändningar samtidigt som det inte orsakar stora förseningar för faktiskt nödvändiga datautbyten.

■ TCP-vidarebefordran stannar när överbelastningar på nätverket tillåter routrar att återgå till sitt ursprungliga läge och dela nätverksresurser för alla sessioner.

■ Frakt dubbletter av ACK(duplicera ACK) vid mottagande av ett segment i ur sekvens, tillåter peers att återsända innan en timeout inträffar.

Om alla elektriska hushållsapparater slås på samtidigt hemma, kommer elnätet att överbelastas. I datornätverk långsam start förhindrar att nätsäkringarna går.

En ny anslutning som omedelbart börjar skicka en stor mängd data på ett redan upptaget nätverk kan leda till problem. Tanken med en långsam start är att säkerställa att den nya anslutningen startar upp framgångsrikt med en långsam ökning av dataöverföringshastigheten i enlighet med den faktiska belastningen på nätverket. Avsändaren begränsas av storleken på laddningsfönstret, inte av det större mottagningsfönstret.

laddningsfönstret(överbelastningsfönster) börjar med en storlek på 1 segment. För varje segment med ett framgångsrikt mottaget ACK, ökas laddningsfönstrets storlek med 1 segment, så länge det förblir mindre än mottagningsfönstret. Om nätverket inte är överbelastat kommer laddningsfönstret gradvis att nå storleken på mottagningsfönstret. I ett normalt vidarebefordranstillstånd kommer dessa fönster att ha samma storlek.

Observera att en långsam start inte är så långsam. Efter den första ACK är laddningsfönstrets storlek 2 segment, och efter en lyckad ACK för två segment kan storleken öka till 8 segment. Med andra ord ökar fönsterstorleken exponentiellt.

Låt oss anta att istället för att ta emot ett ACK har en timeout-situation inträffat. Laddningsfönstrets beteende i detta fall diskuteras nedan.

I de tidiga implementeringarna av TCP/IP stötte utvecklare på fenomenet Clueless Window Syndrome(Silly Window Syndrome - SWS), som yttrade sig ganska ofta. För att förstå vad som händer, överväg följande scenario, vilket leder till oönskade konsekvenser, men det är fullt möjligt:

1. Den sändande applikationen skickar data snabbt.

2. Den mottagande applikationen läser 1 byte data från inmatningsbufferten (dvs långsamt).

3. Inmatningsbufferten fylls snabbt efter avläsning.

4. Den mottagande applikationen läser 1 byte och TCP:n skickar en ACK som betyder "Jag har ledigt utrymme för 1 byte data".

5. Den sändande applikationen skickar ett TCP-paket på 1 byte över nätverket.

6. Den mottagande TCP:n skickar ett ACK som betyder "Tack. Jag har tagit emot paketet och har inget mer ledigt utrymme."

7. Den mottagande applikationen läser igen 1 byte och skickar en ACK, och hela processen upprepas.

En långsam mottagningsapplikation väntar länge på att data ska komma fram och skjuter hela tiden den mottagna informationen till den vänstra kanten av fönstret och utför en helt värdelös operation som genererar ytterligare trafik på nätverket.

Verkliga situationer är naturligtvis inte så extrema. En snabb avsändare och en långsam mottagare kommer att utbyta små (i förhållande till den maximala segmentstorleken) databitar och växla över ett nästan fullt mottagningsfönster. På fig. 10.18 visar förutsättningarna för uppkomsten av "dumma fönster"-syndromet.

Ris. 10.18. Ta emot fönsterbuffert med mycket lite ledigt utrymme

Att lösa detta problem är enkelt. Så snart mottagningsfönstret reduceras med en längd som är mindre än den givna målstorleken, börjar TCP lura avsändaren. I denna situation får TCP inte peka avsändaren på ytterligare utrymme i fönstret när den mottagande applikationen läser data från bufferten i små bitar. Istället bör frigöra resurser hållas hemliga för avsändaren tills det finns tillräckligt med dem. En enstaka segmentstorlek rekommenderas, såvida inte hela ingångsbufferten lagrar ett enda segment (i det senare fallet används en storlek lika med halva bufferten). Målstorleken som TCP ska rapportera kan uttryckas som:

minimum (1/2 ingångsbuffert, max segmentstorlek)

TCP börjar fuska när fönsterstorleken är mindre än denna storlek, och kommer att berätta sanningen när fönsterstorleken inte är mindre än värdet som ges av formeln. Observera att det inte är någon skada för avsändaren, eftersom den mottagande applikationen fortfarande inte skulle kunna bearbeta mycket av den data den förväntar sig.

Den föreslagna lösningen är lätt att kontrollera i det ovan diskuterade fallet med utmatningen av ACK för var och en av de mottagna byten. Samma metod är också lämplig för fallet då ingångsbufferten kan lagra flera segment (som ofta händer i praktiken). Den snabba avsändaren kommer att fylla inmatningsbufferten, men mottagaren kommer att indikera att den inte har något ledigt utrymme att lagra information och kommer inte att öppna denna resurs förrän dess storlek når hela segmentet.

Avsändaren måste, oavsett mottagare, undvika att skicka mycket korta segment genom att samla data innan sändning. Nagles algoritm implementerar en mycket enkel idé för att minska antalet korta datagram som skickas över nätverket.

Algoritmen rekommenderar att fördröja dataöverföringen (och poppa) medan du väntar på ett ACK från tidigare överförda data. Den ackumulerade datan sänds efter att ha mottagit en ACK till en tidigare sänd information, eller efter mottagande för att skicka data i storleken av ett helt segment, eller efter fullbordandet av en timeout. Denna algoritm bör inte användas för realtidsapplikationer som behöver skicka data så snabbt som möjligt.

En annan prestandaförbättringsmekanism är hur ACK fördröjs. Att minska antalet ACK:er minskar mängden bandbredd som kan användas för att skicka annan trafik. Om TCP-partnern försenar sändningen av ACK något, då:

■ Flera segment kan kvitteras med en enda ACK.

■ Den mottagande applikationen kan ta emot en viss mängd data inom timeoutintervallet, dvs. utmatningshuvudet kan inkluderas i ACK och inget separat meddelande behöver genereras.

För att undvika förseningar vid vidarebefordran av en ström av fullängdssegment (till exempel vid utbyte av filer), bör ett ACK skickas för minst vartannat fullängdssegment.

Många implementeringar använder en 200ms timeout. Men en försenad ACK minskar inte växelkursen. När ett kort segment anländer finns det fortfarande tillräckligt med ledigt utrymme i ingångsbufferten för att ta emot ny data, och avsändaren kan fortsätta överföringen (dessutom går återsändningen vanligtvis mycket långsammare). Om ett helt segment anländer måste du svara på det med ett ACK-meddelande i samma sekund.

Efter att ha skickat segmentet ställer TCP in en timer och övervakar ankomsten av en ACK. Om en ACK inte tas emot inom timeoutperioden sänder TCP om segmentet (reläet). Men vad ska timeoutperioden vara?

Om den är för kort kommer avsändaren att översvämma nätverket med onödiga segment som duplicerar den information som redan skickats. En för lång timeout kommer att förhindra att de segment som faktiskt är skadade under överföringen snabbt repareras, vilket kommer att minska genomströmningen.

Hur väljer man rätt intervall för timeout? Ett värde som är lämpligt för ett höghastighets-LAN kommer inte att vara lämpligt för en fjärranslutning med många träffar. Därför är principen om "ett värde för alla förhållanden" helt klart olämplig. Dessutom, även för en befintlig specifik anslutning, kan nätverksförhållandena ändras och förseningar kan öka eller minska.

Algoritmer av Jacobson, Kern och Partridge (beskrivs i artiklar , Van Jacobson och Förbättring av tidsuppskattningar för tur och retur i tillförlitliga transportprotokoll, Karn och Partridge) tillåter TCP att anpassa sig till förändrade nätverksförhållanden. Dessa algoritmer rekommenderas för användning i nya implementeringar. Vi kommer kortfattat att gå igenom dem nedan.

Sunt förnuft säger att den bästa grunden för att uppskatta rätt timeouttid för en viss anslutning kan vara att spåra cykeltid(tur- och returtid) som intervallet mellan sändning av data och mottagande av bekräftelse på deras mottagande.

Bra lösningar för följande kvantiteter kan erhållas baserat på elementär statistik (se figur 10.19) som hjälper till att beräkna timeout. Men lita inte på medelvärden, eftersom mer än hälften av poängen kommer att vara högre än det statistiska genomsnittet. Genom att överväga ett par varianser kan bättre uppskattningar erhållas som tar hänsyn till normalfördelningen och minskar för lång återsändningslatens.

Ris. 10.19. Fördelning av cykeltider

Det finns inget behov av en stor mängd beräkningar för att få formella matematiska uppskattningar av avvikelser. Du kan använda ganska grova uppskattningar baserade på det absoluta värdet av skillnaden mellan det senaste värdet och den genomsnittliga uppskattningen:

Senaste avvikelsen = | Senaste cykeln - Genomsnittlig |

För att beräkna rätt timeout-värde är en annan faktor att ta hänsyn till förändringen i cykeltid på grund av nuvarande nätverksförhållanden. Det som hände online i sista minuten är viktigare än det som hände för en timme sedan.

Antag att du beräknar cykelgenomsnittet för en mycket lång session. Antag att nätverket i början var lätt belastat och vi bestämde 1000 små värden, men sedan ökade trafiken med en betydande ökning av fördröjningstiden.

Till exempel, om 1000 värden gav ett medelvärde på 170 enheter, men då 50 värden mättes med ett medelvärde på 282, då skulle det aktuella medelvärdet vara:

170x1000/1050 + 282x50/1050 = 175

Mer rimligt vore det utjämnad cykeltid(Smoothed Round-Trip Time - SRTT), som tar hänsyn till prioriteten för senare värden:

Ny SRTT = (1 – α)×(gammal SRTT) + α×Sista cykelvärde

Värdet på α är mellan 0 och 1. Öka a resulterar i ett större inflytande av den aktuella cykeltiden på det utjämnade medelvärdet. Eftersom datorer snabbt kan dividera med 2 potenser genom att flytta binära tal åt höger, är värdet för α alltid (1/2) n (vanligtvis 1/8), så:

Ny SRTT = 7/8×gammal SRTT + 1/8×Sista cykeltid

Tabell 10.2 visar hur formeln för SRTT anpassar sig till det aktuella SRTT-värdet på 230 enheter när en förändring i nätverksförhållandena resulterar i en sekventiell ökning av cykeltiden (förutsatt att ingen timeout inträffar). Värdena i kolumn 3 används som värden i kolumn 1 för nästa rad i tabellen (dvs den gamla SRTT).

Tabell 10.2 Beräkning av utjämnad cykeltid

Nu uppstår frågan om att välja ett värde för återsändningstidsgränsen. En analys av cykeltiderna visar en signifikant avvikelse av dessa värden från det aktuella genomsnittet. Det är vettigt att sätta en gräns för storleken på avvikelser (avvikelser). Bra värden för återsändningstidsgränsen (kallad Retransmission TimeOut - RTO i RFC-standarderna) ges av följande formel med en begränsad utjämnad varians (SDEV):

T = Timeout för återsändning = SRTT + 2×SDEV

T = SRTT + 4×SDEV

För att beräkna SDEV, bestäm först det absoluta värdet av den aktuella avvikelsen:

DEV = | Senaste cykeltid - Gamla SRTT |

Sedan används en utjämningsformel för att ta hänsyn till det sista värdet:

Ny SDEV = 3/4×gammal SDEV + 1/4×DEV

En fråga kvarstår - vilka initiala värden ska man ta? Rekommenderad:

Initial timeout = 3 s

Initial SRTT = 0

Initial SDEV = 1,5 s

Van Jacobson har definierat en snabb algoritm som beräknar återsändningstiden mycket effektivt.

Hur bra kommer timeouten som beräknats ovan att fungera? Vid implementering av det erhållna värdet observerades betydande prestandaförbättringar. Ett exempel skulle vara kommandostatistik netstat mottas i systemet tiger- en internetserver som nås av många värdar från hela världen.

1510769 paket (314955304 byte) togs emot i sekvens

systemet tiger mindre än 2,5 % av TCP-datasegmenten återsändes. För en och en halv miljon inkommande datasegment (resten är rena ACK) duplicerades endast 0,6 %. I det här fallet bör det tas med i beräkningen att nivån av förluster i indata ungefär motsvarar nivån för utgångssegmenten. Den värdelösa vidaresändningstrafiken är alltså cirka 0,6 % av den totala trafiken.

Ovanstående formler använder cykeltidsvärdet som intervallet mellan sändning av ett segment och mottagande av en bekräftelse på dess mottagande. Anta dock att ingen bekräftelse tas emot under timeoutperioden och att data måste skickas om.

Kerns algoritm utgår från att cykeltiden i detta fall inte bör ändras. Det aktuella utjämnade värdet för cykeltiden och utjämnad avvikelse behålla sina värden tills en bekräftelse tas emot för att skicka något segment utan att skicka det igen. Från och med denna tidpunkt återupptas beräkningarna baserat på de lagrade värdena och nya mätningar.

Men vad händer innan bekräftelse tas emot? Efter en omsändning förändras TCP:s beteende drastiskt, främst på grund av dataförlust från nätverksöverbelastning. Därför kommer svaret på att skicka om data vara:

■ Minskad återsändningshastighet

■ Bekämpa nätstockningar genom att minska den totala trafiken

Efter en omsändning fördubblas timeout-intervallet. Men vad händer när timern svämmar över igen? Data kommer att skickas igen och återsändningsperioden fördubblas igen. Denna process kallas exponentiell bromsning(exponentiell backoff).

Om nätverksfelet fortsätter att inträffa kommer timeoutperioden att fördubblas tills den når ett förinställt maxvärde (vanligtvis 1 minut). Efter timeout kan endast ett segment skickas. Timeout inträffar också när det förinställda värdet för antalet dataöverföringar utan att ta emot en ACK överskrids.

Att minska mängden data som skickas är något mer komplicerat än de mekanismer som diskuterats ovan. Det börjar fungera, som den redan nämnda långsamma starten. Men eftersom en gräns är satt för trafiknivån, vilket initialt kan leda till problem, kommer växelkursen faktiskt att sakta ner på grund av ökningen av storleken på lastfönstret för ett segment. Du måste ställa in gränsvärdena för en reell minskning av sändningshastigheten. Först beräknas farotröskeln:

Gräns ​​- 1/2 minimum (aktuellt laddningsfönster, partnermottagningsfönster)

Om det resulterande värdet är mer än två segment används det som en gräns. Annars är kantstorleken inställd på två segment. Den fullständiga återställningsalgoritmen kräver:

■ Ställ in laddningsfönstrets storlek till ett segment.

■ För varje mottagen ACK, öka storleken på laddningsfönstret med ett segment tills gränsen nås (ungefär som mekanismen för långsam start).

■ Därefter, med varje mottagen ACK, lägg till ett mindre värde till laddningsfönstret, vilket väljs baserat på ökningshastigheten i ett segment under cykeltiden (ökningen beräknas som MSS/N, där N är storleken på laddningsfönster i segment).

Scenariot för det ideala fallet kan vara en förenklad representation av hur återställningsmekanismen fungerar. Antag att kamratens mottagningsfönster (och nuvarande belastningsfönster) var 8 segment innan timeouten upptäcktes, och gränsen definieras till 4 segment. Om den mottagande applikationen omedelbart läser data från bufferten, kommer mottagarfönstrets storlek att förbli på 8 segment.

■ 1 segment skickas (laddningsfönster = 1 segment).

■ ACK mottagen - 2 segment skickas.

■ ACK mottagen för 2 segment - 4 segment skickas, (gränsen nådd).

■ Mottaget ACK för 4 segment. 5 segment skickas.

■ Mottog ACK för 5 segment. 6 segment skickas.

■ ACK mottagen för 6 segment. 7 segment skickas.

■ ACK mottagen för 7 segment. 8 segment skickas (laddningsfönstret är återigen lika stort som mottagningsfönstret).

Eftersom all sänd data måste bekräftas under återsändningstiden, fortsätter processen tills laddningsfönstret når mottagarfönstrets storlek. De inträffade händelserna visas i fig. 10.20. Fönsterstorleken ökar exponentiellt, fördubblas under den långsamma startperioden, och när gränsen nås är ökningen linjär.

Ris. 10.20. Forward rate limit under trängsel

I vissa implementeringar används en valfri funktion - den sk snabb återfrakt(snabb återsändning) - för att påskynda vidaresändningen av data under vissa förutsättningar. Dess huvudidé är relaterad till att mottagaren skickar ytterligare ACK som indikerar en lucka i mottagen data.

Vid mottagning av ett segment som inte fungerar, skickar mottagaren tillbaka ett ACK som pekar på den första byten. förlorat data (se figur 10.21).

Ris. 10.21. Dubbletter av ACK

Avsändaren utför inte omedelbar återsändning av data eftersom IP normalt kan leverera data till mottagaren utan en sändningssekvens. Men när flera ytterligare ACKs tas emot för duplicering av data (till exempel tre), kommer det saknade segmentet att skickas utan att vänta på att timeouten ska slutföras.

Observera att varje dubblett av ACK indikerar mottagandet av ett datasegment. Flera dubbletter av ACK gör det klart att nätverket kan leverera tillräckligt med data och därför inte är för hårt belastat. Som en del av den övergripande algoritmen utförs en liten minskning av storleken på lastfönstret med en reell ökning av nätverkstrafiken. I det här fallet gäller inte processen med drastisk storleksändring vid återställning av arbetet.

Enligt standarden Värdkrav(värdkrav) TCP måste utföra samma långsamma start som beskrivs ovan vid källsläckning. Att rapportera detta är dock inte riktat eller effektivt, eftersom anslutningen som tog emot meddelandet kanske inte genererar för mycket trafik. Nuvarande specifikation Routerkrav(routerkrav) anger att routrar borde inte skicka meddelanden om källundertryckning.

Slutligen, låt oss ta en titt på statistikmeddelandena för kommandot netstat, för att se många av de mekanismer som beskrivs ovan i funktion.

879137 datapaket (226966295 byte)

21815 datapaket (8100927 byte) återsänds

132957 ack-only-paket (104216 försenade)

fördröjda ACKs.

storlek noll.

762469 acks (för 226904227 byte)

ur sekvens.

1510769 paket (314955304 byte)

9006 fullständigt duplicerade paket (867042 byte)

leverans av data.

74 paket med en del dup. data (12193 byte duperad)

en del data packades om för att inkludera extra byte vid omsändning.

13452 paket i oordning (2515087 byte)

530 paket (8551 byte) med data efter fönster

ingår i de klingande meddelandena.

402 paket mottagna efter stängning

sändning.

108 kasseras för dåliga kontrollsummor

0 kasseras för dåliga rubrikförskjutningsfält

7 kasseras eftersom paketet är för kort

14677 anslutningar upprättade (inklusive accepterar)

18929 anslutningar stängda (inklusive 643 droppar)

4100 embryonala anslutningar tappade

572187 segment uppdaterade rtt (av 587397 försök)

cykeltid, eftersom ACK inte anlände innan timeouten gick ut,

26 anslutningar avbröts av rexmit timeout

skicka igen, vilket indikerar en förlorad anslutning.

noll fönster.

tomgångsanslutning.

472 anslutningar tappade av keepalive

Den nuvarande TCP-standarden kräver att implementeringar strikt följer proceduren för långsam start vid initiering av en anslutning och använder Kern och Jacobsons algoritmer för att uppskatta timeout för återsändning och kontrollbelastning. Tester har visat att dessa mekanismer leder till betydande prestandaförbättringar.

Vad händer när du installerar ett system som inte strikt följer dessa standarder? Det kommer inte att ge tillräcklig prestanda för sina egna användare och kommer att vara en dålig granne för andra system på nätverket, vilket förhindrar normal drift från att återställas efter en tillfällig överbelastning och genererar överdriven trafik som resulterar i tappade datagram.

TCP har bevisat sin flexibilitet genom att arbeta i nätverk med överföringshastigheter på hundratals eller miljoner bitar per sekund. Detta protokoll har uppnått goda resultat i moderna lokala nätverk med Ethernet, Token-Ring och Fiber Distributed Data Interface (FDDI) topologier, såväl som för låghastighetslänkar eller långdistansanslutningar (som satellitlänkar).

TCP är designat för att reagera på extrema förhållanden, såsom överbelastning i nätverket. Den nuvarande versionen av protokollet har dock funktioner som begränsar prestanda i framväxande teknologier som erbjuder hundratals och tusentals megabyte bandbredd. För att förstå problemen som uppstår, överväg ett enkelt (om än orealistiskt) exempel.

Låt oss anta att när du flyttar en fil mellan två system vill du utbyta en kontinuerlig ström så effektivt som möjligt. Låt oss anta att:

■ Den maximala destinationssegmentstorleken är 1 KB.

■ Mottagningsfönster - 4 KB.

■ Bandbredden låter dig skicka två segment per 1 s.

■ Den mottagande applikationen förbrukar data när den anländer.

■ ACK-meddelanden kommer efter 2 sekunder.

Avsändaren kan skicka data kontinuerligt. När allt kommer omkring, när volymen som tilldelats för fönstret är full, kommer ett ACK, vilket gör att ett annat segment kan skickas:

Efter 2 s:

FÅ ACK PÅ SEGMENT 1, KAN SKICKA SEGMENT 5.

FÅ ACK PÅ SEGMENT 2, KAN SKICKA SEGMENT 6.

FÅ ACK PÅ SEGMENT 3, KAN SKICKA SEGMENT 7.

FÅ ACK PÅ SEGMENT 4, KAN SKICKA SEGMENT 8.

Efter ytterligare 2 s:

FÅ ACK PÅ SEGMENT 5, KAN SKICKA SEGMENT 9.

Om mottagningsfönstret bara var 2K skulle avsändaren behöva vänta en sekund av varannan innan nästa data skickades. Faktum är att för att hålla en kontinuerlig dataström måste mottagningsfönstret vara minst:

Fönster = Bandbredd × Cykeltid

Även om exemplet är något överdrivet (för att ge enklare siffror) kan ett litet fönster leda till problem med satellitanslutningar med hög latens.

Låt oss nu titta på vad som händer med höghastighetsanslutningar. Till exempel, om bandbredden och överföringshastigheten mäts vid 10 Mbps, men cykeltiden är 100 ms (1/10 av en sekund), måste mottagningsfönstret för en kontinuerlig ström lagra minst 1 000 000 bitar, dvs. 125 000 byte. Men det största antalet som kan skrivas i rubrikfältet för ett TCP-mottagningsfönster är 65 536.

Ett annat problem uppstår vid höga baudhastigheter, eftersom sekvensnummer tar slut mycket snabbt. Om anslutningen kan skicka data med en hastighet av 4 GB / s, bör sekvensnumren uppdateras varje sekund. Det kommer inte att finnas något sätt att skilja mellan gamla dubbletter av datagram som försenades med mer än en sekund när de reste över Internet, och färsk ny data.

Ny forskning bedrivs aktivt för att förbättra TCP/IP och undanröja de ovan nämnda hindren.

Det här kapitlet täcker de många funktionerna i TCP. De viktigaste är listade nedan:

■ Associera portar med anslutningar

■ Initiering av anslutningar genom trestegsbekräftelse

■ Utför en långsam start för att undvika överbelastning i nätverket

■ Datasegmentering under transport

■ Datanumrering

■ Hantera inkommande dubbletter av segment

■ Kontrollsummaberäkning

■ Reglering av dataflödet genom mottagningsfönstret och sändningsfönstret

■ Avsluta anslutningen på föreskrivet sätt

■ Avbryta anslutningen

■ Vidarebefordra brådskande data

■ Positiv återsändningsbekräftelse

■ Beräkning av timeout för återsändning

■ Minska omvänd trafik under nätverksöverbelastning

■ Signalering av segment som inte fungerar

■ Undersöka stängningen av mottagningsfönstret

En TCP-anslutning går igenom flera steg: en anslutning upprättas genom ett meddelandeutbyte, sedan skickas data och sedan stängs anslutningen med ett utbyte av specialmeddelanden. Varje steg i driften av anslutningen motsvarar en viss skick detta samband. TCP-mjukvaran i varje ände av anslutningen övervakar ständigt det aktuella tillståndet på den andra sidan av anslutningen.

Nedan kommer vi kortfattat att överväga en typisk förändring i tillståndet för en server och en klient som finns i olika ändar av anslutningen. Vi strävar inte efter att ge en uttömmande beskrivning av alla möjliga tillstånd vid överföring av data. Det ges i RFC 793 och dokument Värdkrav.

Under upprättandet av anslutningar går servern och klienten igenom liknande sekvenser av tillstånd. Servertillstånden visas i Tabell 10.3 och klienttillstånden visas i Tabell 10.4.

Tabell 10.3 Servertillståndssekvens

Tabell 10.4 Klientstatussekvens

Om kamraterna försökte upprätta en förbindelse med varandra samtidigt (vilket är extremt sällsynt), skulle var och en gå igenom tillstånden STÄNGD, SYN-SÄKT, SYN-MOTTAD och ETABLERAD.

Slutparterna av anslutningen förblir i ETABLISTERAT tillstånd tills en av parterna fortsätter till stängning anslutning genom att skicka ett FIN-segment. Under en normal stängning går den som initierar stängningen igenom tillstånden som visas i tabell 10.5. Hennes partner går igenom tillstånden som visas i Tabell 10.6.

Tabell 10.5 Tillståndssekvensen för sidan som stänger anslutningen

Tabell 10.6 Anslutning nära partnertillståndssekvens

Team netstat -an låter dig kontrollera anslutningens aktuella tillstånd. Följande visar anslutningar i stater lyssna, starta, etablera, avsluta och tid vänta.

Observera att anslutningsportnumret finns i slutet av varje lokal och extern adress. Du kan se att det finns TCP-trafik för både ingångs- och utgångsköerna.

Pro Recv-Q Send-Q Lokal adress Utländsk adress (stat)

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 ETABLERAD

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 ETABLERAD

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 ETABLERAD

Tcp 0 0 128.121.50.145.1082 128.121.50.141.6000 ETABLERAD

TCP 0 0 128.121.50.145.1022 128.121.50.141.1017 ETABLERAD

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 ETABLERAD

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 ETABLERAD

Tcp 0 0 128.121.50.145.119 192.67.243.13.3704 ETABLERAD

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 ETABLERAD

Från allra första början har TCP-protokollet designats för interoperabilitet mellan nätverksutrustning från olika tillverkare. TCP-specifikationen anger inte exakt hur implementeringens interna strukturer ska fungera. Dessa frågor lämnas till utvecklare, som uppmanas att hitta de bästa mekanismerna för varje enskild implementering.

Även RFC 1122 (dokument Värdkrav- värdkrav) lämnar gott om utrymme för variation. Var och en av de implementerade funktionerna är märkta med en viss nivå av kompatibilitet:

■ MAJ (tillåtet)

■ FÅR INTE

Tyvärr finns det ibland produkter som inte implementerar MUST-kraven. Som ett resultat upplever användarna besväret med minskad prestanda.

Vissa goda genomförandepraxis omfattas inte av standarderna. Till exempel kan säkerheten förbättras genom att begränsa användningen av välkända portar till privilegierade processer på systemet, om denna metod stöds på det lokala operativsystemet. För att förbättra prestandan bör implementeringar göra så lite kopiering och flyttning av skickade eller hämtade data som möjligt.

Standardgränssnitt för applikationsprogrammering inte bestämd(liksom säkerhetspolicyn), så att det finns ett fritt aktivitetsområde för att experimentera med olika uppsättningar av mjukvaruverktyg. Detta kan dock resultera i olika programmeringsgränssnitt på varje plattform och förhindra att applikationsprogramvara flyttas mellan plattformar.

Faktum är att utvecklare baserar sina verktygssatser på Socket API, lånat från Berkeley. Vikten av programmeringsgränssnittet ökade med tillkomsten av WINSock (Windows Socket), vilket ledde till en spridning av nya skrivbordsapplikationer som kunde köras ovanpå vilket TCP/IP-stackkompatibelt WINSock-gränssnitt som helst.

Den ursprungliga TCP-standarden definieras i RFC 793. Uppgraderingar, korrigeringar och kompatibilitetskrav täcks av RFC 1122. Kern (Kash) och Partridge (Partridge) publicerade en artikel Förbättra uppskattningar för tur och retur i tillförlitliga transportprotokoll I tidningen Proceedings of the ACM SIGCOMM 1987. Jacobsons artikel Undvikande och kontroll av trängsel framträdde i Proceedings of ACM SIGCOMM 1988 Workshop. Jacobson publicerade också flera RFC:er som reviderar algoritmer för att förbättra prestanda.