Textbook FreeBSD, OpenBSD, NetBSD, szitakötő b
B.1. Osztályozása hálózati protokollok
B.1.1. A fizikai réteg az OSI B.1.2. Az adatkapcsolati réteg az OSI B.1.3. Hálózati OSI B.1.3.1 szinten. ARP B.1.3.2. RARP B.1.3.3. IP B.1.3.4. IPv6 B.1.4. A szállítási réteg az OSI B.1.4.1. ICMP B.1.4.2. UDP B.1.4.3. TCP B.1.4.3.1. A szerkezet a TCP B.1.4.3.2 csomagot. Nyitvatartási TCP kapcsolat kézfogás hármas B.1.4.3.3. Záró TCP B.1.4.3.4 kapcsolatot. Az állam a TCP kapcsolatok B.1.5. alkalmazás-szintű bemutatása és munkamenet
A besorolás a hálózati protokollokat használnak úgynevezett benchmark hét elem modelljét OSI (lásd [url: // wiki-OSI-ru].).
OSI hálózati modell (angol Nyílt rendszerek összekapcsolása Reference Model -. Modell a nyílt rendszerek összekapcsolása) - elméleti modellje a hálózati kommunikációs és hálózati protokollok fejlesztése.
A modell felosztja a hálózati protokollok a hét szint:
- A fizikai réteg (Fizikai réteg).
- A kapcsolati réteg (adatkapcsolati réteg);
- Hálózati réteg (hálózati réteg);
- A szállítási réteg (transport layer);
- Session Layer (session réteg);
- Megjelenítési réteg (Megjelenítési réteg);
- Az alkalmazási réteg (Alkalmazási réteg);
B.1.1. Fizikai OSI
A fizikai réteg közvetlenül használjuk jelátvitelre. A protokoll a fizikai réteg van leírva, például, meg kell elrendezni vonal (csavart érpár) úgy, hogy garantált, hogy hiányzik jelet a Ethernet 100BASE-TX szabvány: a vastagsága az egyes magok, ellenállásukat, a gyakorisága csomagolást, a minimális távolság a vezetéket a tápkábel, maksismalnoe menetszáma az öbölben és a minimális sugara az öböl, a vezeték hossza a átjátszó ismétlő számú vezeték-típusú vegyületek rozerka, az eljárás élt huzalcsatlakozóját RJ45.
A fizikai szinten vannak csomópontok és az ismétlő (repeater-ként is ismert). Egy tagjának kinevezése átjátszók, hogy növeljék a jelet. Ezek szükségesek abban az esetben, meg kell a jelet tovább annál, mint amit a szabvány. A koncentrátor (is ismert, mint egy hub) van szükség annak érdekében, hogy fokozza nemcsak a jel, hanem továbbítja az egyik vezetéket a több más így hub kell kombinálni több eszköz be Ethernet szegmenst.
B.1.2. OSI kapcsolati réteg
kapcsolók (switch) munkája ezen a szinten, bridge (híd), és természetesen, a tényleges Ethernet-kártya (NIC).
Ha a hálózat nem gyűjtik a kapcsolók és elosztók (azaz nem switch'ah és hub'ah, van apt egy szleng-kifejezés „obszcén Network” hálózat), az összes keretet elküldeni minden. Egy ilyen szervezet rossz, nem csak a biztonság szempontjából, de főleg a teljesítmény tekintetében. Ha két Ethernet eszközök egyidejűleg küldött a szegmensben a keret, akkor nem lesz konfliktus - mind a keret, eltűnnek. újraküldi a keretek végezzük. A konfliktusok nem történik meg újra, újra küldő késik egy véletlenszerű ideig. Minél eszközök a hálózat, annál nagyobb a valószínűsége, ütközések. Pro eszköz, amely képes lép egy ilyen konfliktus, azt mondják, hogy ők a „ütközési tartományt”. Így a fő előnye switch'ey előtt hub'ami az, hogy szét a hálózaton a sok kis ütközési tartományok, ezáltal jelentősen javul a hálózat teljesítményét.
Figyelemmel kíséri az adatkapcsolati réteg fejlécet a programban tcpdump (1), -e lehetőség. (Lásd. Fejezet 6.11 „bemutatása az alapvető készségek a segédprogram a tcpdump (1)”).
B.1.3. OSI hálózati réteg
Ezen a szinten működő IP protokoll, az IPv6, ARP, RARP, és mások, de itt vagyunk érdekli csak a négy.
B.1.3.1. ARP
B.1.3.2. RARP
B.1.3.3. IP
IP protokoll csomagok küldését, a feladat a csomagot alkotó, hiba ellenőrzés IP protokoll funkciókat nem tartalmazza. Ez az előjoga a magasabb szintű protokollok, mint a TCP, UDP, ICMP.
Az Alapszabály 6.11 „bemutatása az alapvető készségek dolgozó tcpdump (1) segédprogram” a tcpdump mısorok (1) a lehallgatás két ICMP csomagokat. Ebben a példában részletesen, hogy mi van a csomag IP fejléc.
B.1.3.4. IPv6
B.1.4. Szállítás OSI
Megjegyzés: Az ICMP kiegészítő kódok adhatunk valamilyen más, újabb RFC. Például az RFC 950 üzeneteket vett Címmaszk Request (kód: 17), és címmaszk válasz (kód 18)
A legtöbb izvetsnye ICMP üzeneteket, talán ez a visszhang kérést és visszhang válasz. Ezeket gyakran használják tesztelési célokra. A 6.4.2, «traceroute (1)” írja le, hogyan traceroute program (8) rajtuk keresztül határozza meg az útvonalat pontról pontra.
B.1.4.2. UDP
UDP protokoll elvén működik „tűz és felejtsd el”. Ő nem csak nem garantálja szállítási csomagokat, de nem is garantálja, hogy a szállított csomagokat fog ugyanabban a sorrendben, ahogy küldtek. Mindazonáltal a megbízható hálózatok nevét termelékenység növekedésének lehetséges bizonyos alkalmazások használata az UDP protokollt. Egy időben a hálózat NFS fájlrendszer alapul UDP protokollt, és a hiba ellenőrzést hajtottak végre magasabb OSI rétegekben. Jelenleg azonban ez a gyakorlat csökkent.
B.1.4.3. TCP
Végül a TCP protokollt UDP protokoll különbözik az a tény, hogy működik hiba ellenőrzési mechanizmust. Ahhoz, hogy végre e mechanizmust a fejlécben hozzáadunk további mezőt a TCP zászlók. (Ez nem az egyetlen komplikáció képest UDP, és mi érdekli de ez van.) Minden TCP csomag megerősíti csomagot ACK flag (nyugta). Egy csomag ACK flag lehet kézhezvételét néhány csomagot. A protokoll meghatározott nehéz ellenőrizni, amelyek akkor jelentkeznek, amikor nyitása és zárása a kapcsolat.
B.1.4.3.1. A szerkezet a TCP csomag
Táblázat B.2. A formátum a TCP fejléc
Forrás Port Port feladó 16 bit - port számát. Destination Port Destination Port, 16 bit - száma a rendeltetési kikötőbe. Sequence Number száma sorban 32 bit - a sorszám az első adatok oktett ebben a szegmensben (kivéve, amikor a szinkronizálás SYN jelző jelen van). Ha a SYN jelző jelen van, akkor a sorszám az inicializáló (ISN), és a szám az első adatok oktett - ISN + 1. Elismervényt szám ellenőrzés száma, 32 bit - Ha az ACK flag, akkor ez a mező a következő sorszámot, hogy a feladó a datagram akar vissza. Megerősítő szám folyamatosan küldi, amint a kapcsolat létrejön. Adatok Offset eltolás adatok, 4 bit - A szám a 32 bites szó a TCP fejléc. Ez jelzi a kezdetét az adatmező. TCP fejléc mindig befejezi a 32 bites szó határt, akkor is, ha ő lehetőségeket. Fenntartva fenntartva mezőt kell nullákkal töltjük fel. 6 bit. Bitek zászlók TCP, 8 bit (nyolc zászlók). Zászlók balról jobbra: CWR, ECE, URG, ACK, PSH, RST, SYN, FIN. Az első két zászló a régi kézikönyvek gyakran ottsutstvuyut. A zászlók táblázatban adjuk B.3 «TCP Flags”. Ablak Ablak, 16 bit - A szám adatok oktettek kezdődő nyolcas akinek több van megadva a megerősítési mezőben. A oktettek száma, amely megvárja megkapta a küldő e szegmensben. Az ellenőrző ellenőrző 16 bites Sürgős Pointer Pointer 16 bit sürgősség - Ez a mező mutatja az aktuális értéket sürgős mutatóját. Az utóbbi egy pozitív érték - eltolva a sor számát ebben a szegmensben. Sürgős mutató megmondja a sorszámát az oktett következő sürgős adatok. Ez a mező értelmezése csak abban az esetben, ha a szegmens van téve URG zászló. Opció, hossza változó.
Táblázat B.3. TCP zászlók
a feladó tájékoztatja a címzett a küldemény lassuló (lásd. [RFC-3168])
Sürgős pointer mező részt
Field visszaigazolás részt
újraindítása a vegyület
szinkronizálása sorszámok
nincs több küldendő adat
B.1.4.3.2. Nyitvatartási TCP kapcsolatok hármas kézfogás
TCP vegyület, ellentétben az UDP, támogatja az elképzelést, a „kommunikáció session”. Ez azt jelenti, hogy az adatokat megy a forrástól a cél egy áramlását. A protokoll biztosítja hibajavítás. Az adatok nem veszhetnek el, vagy ismétlődő vagy megelőzni egymást. Ennek a végrehajtására trebovniya szervezett visszatérő forgalmat a vevő a feladó, hogy a címzetthez, hogy milyen csomagok megkapta, és jelenteni azok ellenőrző. Ebből a célból küldött csomagokat az ACK flag készlet.
A fenti vázlat szemlélteti egyirányú adatfolyam. Ie még egy egyirányú szükséges adatforgalmat át csomagokat mindkét irányban. Eközben a legtöbb TCP kapcsolatok kétirányú mint alkalmazási protokollok (HTTP, SMTP, stb) át adatokat mindkét irányban. Például, ha a böngésző letölthető a forrás, akkor a böngésző elküldi a GET kérés <имя ресурса>, és a szerver saját forrásait. Gondold át, hogyan kell megnyitni egy kétirányú kapcsolat.
Először is, az egyik fél, akkor hívja őt „ügyfél” küld egy másik Stronie ( „kiszolgáló”) csomag kitett zászló SYN. Ez a fajta iránti kérelem kapcsolat megnyitása.
A szerver nyugtázni a csomagot, és küldje vissza a csomagot az ACK flag készlet. De mivel a kapcsolat kell lennie kétirányú, akkor is el kell küldenie a csomagot a kliens a kérelmet a nyitás a kapcsolat, azaz SYN flag. Ez a két csomag zászlókkal SYN ACK, és kombinálható egyetlen csomagban.
Az ügyfél megkapta a SYN csomagot a szerverre, most meg kell bizonyítani, és azt elküldi a kiszolgáló egy ACK csomagot megerősítve a felfedezés a kapcsolatot a szerver a kliens.
Így a kliens és a szerver között váltott három csomag: 1) az ügyfél kérelmet megnyitni egy kapcsolatot a klienstől a szerverhez; 2) A szerver megerősítette az E vegyület felfedezése és kérelmet a kapcsolat megnyitása a szerver a kliens; 3) kapcsolat megnyitása ügyfél megerősítette a szerver a kliens. Ez az eljárás a három csomag csere eljárás „háromutas kézfogás» (háromutas kézfogás).
Az első három csomag, hogy látjuk, csak hivatkozni kell az eljárás három-utas kézfogás. Látható, hogy az első SYN csomagot egy zászló (ezt jelzi a nagybetű S a nyomat), szintén egy második SYN és az ACK flag alku. A harmadik csomag nem volt zászló eltérő ACK.
A következő két csomag (4. és 5.) a mi nyomtatás csomag felelős az adatok továbbításának HTTP-n keresztül. Az első, az ügyfél kért http erőforrás protokoll HTTP GET parancs. Mivel az egész kérést csomagolva egy csomagban, PSH (push) a zászlót fel ebben a csomagban. Ez a zászló kerül ahhoz, hogy a szerver küld a felhalmozódott csomagokat az alkalmazás vár rájuk (azaz web szerver). Erre válaszul a szerver küld a html oldalt. Ez az oldal is fér egy csomagot, és ezért úgy is állítani PSH jelzőt.
Végül az utolsó négy csomagokat megfelelnek a bezárása TCP kapcsolatok és az eljárást az alábbiakban tárgyaljuk.
B.1.4.3.3. Záró TCP-kapcsolat
TCP kapcsolat, mint már említettük, a kétirányú, tehát bezárul külön kliens és szerver. Így létrehozott csomag 4: 1), a szerver küld egy értesítést a csatorna lezárás a kiszolgáló az ügyfél, a FIN a csomag; 2) Az ügyfél megerősíti annak kézhezvételét egy ACK csomagot zászló; 3) A kliens elküldi a FIN csomag - értesítés lezárását a csatorna a ügyfél-kiszolgáló; 4) A kiszolgáló elismeri annak átvételét. Néha csomagok 2. és 3. egyesítjük az ugyanolyan módon történik a tripla kézfogás.
Miután a gazda küldött csomagot a FIN, ő már nem a jogot, hogy adatokat küldjön keresztül ugyanazt a socket.
Miért nem az ügyfél küld egy FIN csomagot ugyanabban a csomagban, amely elküldi az ACK flag? Mivel a záró csatornák - független eljárást. Úgy hajtjuk végre, amikor az alkalmazás (böngésző vagy webszerver) függvények egy hívást, hogy lezárja (2). Elvileg a kapcsolat létrejötte után a szerver a kliens zárva volt, és továbbra is egy félig zárt állapotban, az ügyfél továbbra is folyamatosan küldi néhány adatot a szerverre.
Ebben az eljárásban van némi probléma, ha az ügyfél megkapta az utolsó csomagot az ACK flag megerősíti átvételét a csomagot a FIN szerver, ő nem küld a szerverre. Mivel a szerver tudja, hogy az ügyfél megkapta a csomagot ACK? Annak érdekében, hogy ne essen bele az ördögi kört, és kiutasítani végtelenbe megerősítés a megerősítő, az alábbi algoritmust választja TCP protokollt: van egy absztrakt mennyiség úgynevezett „marginális késedelem részes» (MSL szegmens maximális élettartam). Ez a paraméter jellemzi a becsült maximális lehetséges ideje egy szegmens a hálózaton elöntés előtt máshol. A [RFC-793] javasolt érték MSL 2 perc. A gyakorlatban ez az idő függ a konkrét megvalósítására az operációs rendszer és kisebb lehet. A szerver elküldése után az ACK csomagot vár kétszer annyi idő MSL, és ha ez idő alatt nem tudott újra FIN csomagot, úgy véli, hogy az ACK csomagot biztonságosan az ügyfél és lezárja a foglalatot.
B.1.4.3.4. A TCP-kapcsolatok állapotát
Megjegyzés: a TIME_WAIT állapotban, mint már említettük, úgy kétszer annyi idő az MSL, azaz 4 perc. Ebben az állapotban lesz csak a párt, amely végrehajtja az aktív szoros kapcsolatban vannak. A csökkentett gráf egy kliens és egy kinyomtatott tcpdump (1) a példában a webszerver, ez volt szerver. Egy olyan helyzetben, ahol a szerver végez aktív közeli (és egy webszerver ez igaz) halmozódik fel a számos kiemelkedő aljzatok. Előbb vagy utóbb, túlterhelt web szerver válhat komoly bajban van. Emiatt a legtöbb modern operációs rendszerek, ezen a helyen nem felel meg az RFC. FreeBSD a TIME_WAIT állapotban egy percig.