Az adatok a hálózaton és az interneten át a TCP / IP protokoll. A TCP / IP nem tökéletes, de könnyebben megvalósítható, mint az adatkommunikáció során megfogalmazott más protokollok, például az ISO OSI modell. Mint minden technikai dolog, a TCP / IP-nek is vannak hibái Silly Window szindróma az egyik ilyen hibák létrehozása. A Silly Window-szindróma vagy az SWS megértéséhez először meg kell értened a TCP / IP-ben az adatkommunikáció alapját.
Silly Window szindróma
Az ablak és méretének megértése
Ha két pont kommunikál a TCP / IP alatt, akkor magában foglal egy elismerési mechanizmust. Ez az elismerési mechanizmus az, ami a Silly Window-szindrómát okozza. A pontok két számítógépre, kliensre és szerverre vonatkozhatnak.
SWS is caused by the receiver advancing the right window edge whenever it has any new buffer space available to receive data and by the sender using any incremental window, no matter how small, to send more data. The result can be a stable pattern of sending tiny data segments, even though both sender and receiver have a large total buffer space for the connection, says MSDN.
Amikor egy számítógép, mondja A, egy adatcsomagot küld egy másik B számítógéphez, az utóbbinak tudnia kell és válaszolnia kell arról, hogy megkapta az adatcsomagot. A nyugtázással párhuzamosan meg kell adnia az adott kommunikációs szálhoz tartozó puffertároló méretét is. Ez általában a kommunikációhoz szabadon bocsátott bájtok száma.
Tehát amikor a B azt mondja, hogy a 100B elérhető a következő üzenethez, a 100B a Silly Window-szindróma ablak. Vagyis a puffer mérete. Saját hibájával a TCP / IP mechanizmus csökkentheti a buffer méretét minden egyes kommunikációra / adatot illetően. Ez azt jelenti, hogy amikor az A üzenetet küld, a B feltételezi, hogy a puffer mérete csökken, és kisebb számot küld. Így az ablak mérete tovább csökken, és egy ponton a kommunikáció csak megáll, miközben a B 0B ablakméretet ad át.
Hogyan működik a Silly Window szindróma
Az A és B fenti példája szerint, ha B 1000B-t küld ablakméretként, akkor A két 500B-ra osztja és két 500B-os csomagot küld. Az első csomag beérkezésekor a B egy nyugtázást küld, amely szerint az 500B elérhető az ablaknak, mivel a második csomag még nem érkezik meg. Az A feltételezi, hogy az 500B az ablakméret, és ennek megfelelően 250B-os csomagot küld. Míg a B, 500B és 500-at csak megkapják, a 0B-t a rendelkezésre álló állomásról küldi. Ezen a ponton az A nem vállal semmilyen ablakot, bár előfordulhat, hogy a puffer üres, mivel a processzor az ott tárolt adatokat használja. A továbbra is küld egy kisebb csomagot, hogy megnézze, van-e elérhető ablak. Ha a B-puffer tartalmát még nem távolították el, akkor továbbra is válaszként / nyugtázásként 0 lesz.
Így az ablak mérete folyamatosan csökken, mivel a B minden esetben megkapja a nyugtázást, amikor egy A csomagot kap. Ez a méret általában kisebb, mint az előző nyugtázás, mivel B adatcsomagokat kap részekben. Nem lenne semmi gond, ha az A képes lenne olyan csomagot küldeni, amely elég nagy ahhoz, hogy egyszerre fedje le a puffert. De ez további mechanizmusokat igényel, és így Silly Window-szindrómát igényel. A kommunikáció megszakad, miután A-t kap 0-tól két-háromszor.
Hogyan lehet megakadályozni Silly Window szindróma (SWS)
Van egy egyszerű algoritmus, amelyet végre kell hajtani az SWS megszabadulása érdekében. A kezdeti csomag fogadásakor a B a fele a ténylegesen rendelkezésre álló helyet adja ki az ablaknak. Ezáltal A küld kisebb csomagokat. Következésképpen, ha a csomagok túlságosan kisebbek, akkor B elküldi a teljes puffer méretét, hogy az A nagyobb adatbájtokat küldjön újra.
Más szóval, ha az 1000B elérhető, a B 500B-t küld visszaigazolásként. Ennek megfelelően az A 250B x 2 csomagot küld. Ehhez az A 100B nyugtázást kap. Amikor 50B csomagot kap, B 1000B-50B-t küld az A-nak. Ezzel az egész beszélgetés ismét működik. Ez kis késést okozhat a feldolgozásban, de megakadályozza a Silly Window szindróma kialakulását és a teljes beszélgetés megállítását.
Összefoglalva, az SWS a címzetthez rendelkezésre álló pufferméreten és a feladó által kiszámított feltételezett méreten alapul. Az SWS megakadályozása érdekében a késleltetés beindul, és szándékosan kisebb ablakméretet vált ki, amíg a csomag mérete túl kicsi lesz. Ezután a címzett közzéteszi a ténylegesen rendelkezésre álló ablakméretet. Az egész folyamat folyamatosan megismétlődik, amíg a kommunikáció befejeződik.
Bár az ablakot és a puffert felcserélhettem. Nem értem különbséget köztük. Az SWS vizsgálatokban a puffer az ablak.
Ha további információkra van szüksége, itt részletes ismertető található a tcpipguide.com oldalon.
