Phenquestions
Az adatokat a hálózaton és az interneten keresztül továbbítják a TCP / IP protokoll. A TCP / IP nem tökéletes, de könnyebben megvalósítható az adatkommunikációhoz teoretizált más protokollokhoz képest ... mint például az ISO OSI modell. Mint minden technikai dolognál, a TCP / IP-nél is vannak hibák és Buta ablak szindróma az egyik ilyen hiba létrehozása. A Silly Window szindróma vagy az SWS megértéséhez először meg kell értenie a TCP / IP adatkommunikációjának mögöttes mechanizmusát.
Buta ablak szindróma
Az ablak és annak méretének megértése
Amikor két pont TCP / IP alatt kommunikál, akkor nyugtázási mechanizmust tartalmaz. Ez a nyugtázási mechanizmus okozza a Silly Window szindrómát, amint azt tovább magyarázzuk. A pontok két számítógépre, kliensre és szerverre stb. Vonatkozhatnak.
Az SWS-t az okozza, hogy a vevő előrelép a jobb ablak szélén, amikor új puffertér áll rendelkezésre az adatok fogadására, és a küldő bármilyen növekményes ablakot használ, függetlenül attól, hogy milyen kicsi, hogy további adatokat küldjön. Az eredmény stabil minta lehet az apró adatszegmensek elküldésében, annak ellenére, hogy mind a küldőnek, mind a vevőnek nagy a teljes puffertereje a kapcsolathoz - mondja az MSDN.
Amikor egy számítógép, mondjuk A, adatcsomagot küld egy másik B számítógépnek, akkor annak el kell nyugtáznia és válaszolnia, hogy megkapta az adatcsomagot. A nyugtázással együtt el kell küldenie az adott kommunikációs szál számára elkülönített puffer méretét is. Ez általában a kommunikációra szabadon bájtok száma.
Tehát amikor B azt mondja, hogy a 100B elérhető a következő üzenethez, akkor a 100B az ablak a Silly Window szindrómában. Vagyis ez a puffer mérete. Saját hibájával a TCP / IP mechanizmus csökkentheti az A-ból érkező minden kommunikáció / adat pufferméretét. Vagyis amikor A üzenetet küld, B feltételezi, hogy a puffer mérete csökkent, és kisebb számot küld. Így az ablak mérete folyamatosan csökken, és egy pillanat alatt a kommunikáció csak leáll, amikor B ablakméretként elküldi 0B-t.
Hogyan működik a Silly Window szindróma
Az A és B fenti példa szerint, ha B 1000B-t küld ablakméretként, A két 500B-ra osztja és két 500B-s csomagot küld. Az első csomag kézhezvétele után B nyugtázást küld, mondván, hogy 500B elérhető az ablakhoz, mivel a második csomag még nem érkezett meg. Egy feltételezés szerint 500B az ablakméret, és ebből következően két 250B-s csomagot küld. Míg a B-nél 500B-t használnak és 500-at csak fogadnak, 0B-t fog küldeni, ahogy rendelkezésre áll. Ezen a ponton A feltételezi, hogy nincs elérhető ablak, bár előfordulhat, hogy a puffer üres, mivel a processzor felhasználta az ott lévő adatokat. A továbbra is küld egy kisebb csomagot, hogy megnézze, van-e elérhető ablak. Ha a B-n lévő puffer tartalmát még nem távolítják el, akkor továbbra is 0-t kap válaszként / nyugtázásként.
Így az ablak mérete folyamatosan csökken, mivel B nyugtázást küld minden alkalommal, amikor csomagot kap A-tól. Ez a méret általában kisebb, mint az előző nyugtázás, mivel B az adatcsomagokat részenként fogadja. Nem lenne probléma, ha A egy akkora csomagot küldhetne, amely egyszerre lefedi a B puffer méretét. Ehhez azonban további mechanizmusokra lenne szükség, és ezáltal a Silly Window szindrómára. A kommunikáció leáll, miután A kétszer vagy háromszor 0-t kap.
A Silly Window szindróma (SWS) megelőzése
Az SWS-től való megszabaduláshoz egyszerű algoritmust kell megvalósítani. A kezdeti csomag fogadásakor B a ténylegesen rendelkezésre álló hely felét küldi ablakként. Ettől az A kisebb csomagokat küld. Következésképpen, ha a csomagok túlságosan kisebbek lesznek, akkor B elküldi a teljes pufferméretet, hogy A újra elkezdhesse a nagyobb adatbájtok küldését.
Más szóval, ha 1000B elérhető, B 500B-t küld nyugtázásként. Ennek megfelelően A 250B x 2 csomagot küld. Ehhez A 100B-t kap nyugtázásként. Amikor 50B csomagot kap, B 1000B - 50B-t küld A-nak. Ez az egész beszélgetést ismét működőképessé teszi. Ez némi késedelmet okozhat a feldolgozásban, de megakadályozza a Silly Window szindróma előfordulását és az egész beszélgetés leállítását.
Összefoglalva: az SWS a címzettnél elérhető pufferméreten és a feladó által kiszámított feltételezett méreten alapul. Az SWS megakadályozása érdekében késleltetést vezet be, és szándékosan kisebb ablakméretet viszonoz, amíg a csomag mérete túl kicsi lesz. Ezután a címzett közli a ténylegesen elérhető ablakméretet. Az egész folyamat addig ismétlődik, amíg a kommunikáció befejeződik.
Bár lehet, hogy felváltva használtam az ablak és a puffer szavakat. Nem akarok különbséget tenni közöttük. Az SWS-vizsgálatokban a puffer az ablak.
Ha további információkra van szüksége, részletes magyarázat található itt a tcpipguide oldalon.com.
