Zum Ende des vierten Quartals sind wieder vermehrt Cookies im Umlauf. Wie entstehen diese und wie kann der Client damit umgehen? Gerade die modifizierten Cookies können Probleme verursachen, sowohl beim Client als auch auf dem Server. Die richtige Vorbereitung kann helfen, mit dieser Gefahr umzugehen.
Modifizierte Cookies
Laut Informationen der WBF (Windows Baking Foundation) sind in der letzten Zeit wieder vermehrt modifizierte Cookies im Umlauf. Diese werden wie bei allen Cookies üblich ganz normal vom Server per REST-Protokoll (Restless Eating Sweets Transport) an den Client übergeben. Einmal beim Client angekommen und verarbeitet, können diese aber weitere Auswirkungen auf das Client-System haben. Die gefährlichste Variante veranlasst den Client, weitere Cookie-Anfragen an den Server zu schicken. Dies birgt Gefahren sowohl für den Client als auch für den Server. Der Client kann durch zu viel abgespeicherte Cookies mit einer Overflow-Exception reagieren. Der Server reagiert durch zu viele Client-Anfragen im Worst Case mit einer 503 Response, d.h. Service Unavailable. Schickt der Client die nachträglichen Cookie-Requests in zu kurzer Reihenfolge, so kann es sein, dass die Ressource nicht gefunden wurde, weil der Verarbeitungsprozess noch nicht abgeschlossen ist.
Was ist die Ursache für dieses Verhalten auf Server-Seite? Bereits standardmäßige Cookies können bei zu vielen Anfragen den Server überlasten. Die modifizierten Cookies benötigen jedoch zusätzliche Ressourcen, die zunächst angefordert werden müssen, und die die Verarbeitung verlangsamen. Die wichtigste zusätzlich benötigte Ressource sind Objekte vom Typ Mac.Adam.IA. Diese müssen zunächst über ein CDN (Christmas Delivery Nutwork) bezogen werden. Üblicherweise handelt es sich dabei um Marketplaces, die eine Face-To-Face-Connection erfordern. Hat der Server die Ressourcen allokiert, muss er sie in kleine Stücke, Chunks, zerlegen. Dazu wird hardwareseitig ein Splitter benötigt. Des Weiteren werden abweichend vom Standardvorgehen statt den schwarzen die weißen Bytes benötigt. Auch diese müssen gesplittet werden. Die weitere Verarbeitung der Eingaben erfolgt mit Hilfe des Standard-Build-Prozesses, auf einem oVEN-Server. Neben des bUTTeR-Packages sollten auch die Mail-Library und die sucER-Dll inkludiert werden. Ganz wichtig ist auch das aus der Kryptographie bekannte Salt. Alle Komponenten werden miteinander verbunden und das Kompilat wird in einem zweiten Buildschritt in einen auslieferungsfähigen Zustand versetzt. Wichtig ist hierbei die Verteilung der zusammengefügten Komponenten. Diese dürfen nicht zu dicht gekoppelt werden, da sonst Abhängigkeiten entstehen, die sich nur schwer lösen lassen. Als ideal hat sich hier eine 3×3-Matrix erwiesen. Dieser zweite Buildschritt dauert üblicherweise 10 Minuten. Danach stehen 9 Artefakte zur Verfügung, die vor dem Deployment auf ein Grid verschoben werden müssen. D.h. der Buildprozess stellt ein Bottleneck dar. Mit nur einem Buildserver werden, ohne Berücksichtigung der Kompilierung, in der Stunde maximal 54 Artefakte erzeugt. Kommen nun mehr als 54 Client-Requests an, ist der Server überfordert und reagiert mit den üblichen Status-Codes.
Auf Client-Seite kann die Installation von zu vielen parallelen Cookies zu einem Overflow führen. Dies kann im schlimmsten Fall einen Absturz verursachen, wonach der Client keine weiteren Cookies verarbeiten kann. Abhilfe schafft hier die Drosselung des Clients. Es ist darauf zu achten, dass dieser nicht mehrere Cookies parallel verarbeiten muss und auch rechtzeitig die Annahme verweigert. Die Aufnahmekapazität ist vom Client abhängig, und muss individuell ermittelt werden.
Prinzipiell ist clientseitige Verarbeitung von Cookies nicht schädlich, muss jedoch gemonitored werden. Der Server sollte auf die zurzeit häufig aufkommenden Anfragen vorbereitet werden, um Denial-Of-Service-Attacken zu umgehen. Hier können mehrere parallele Buildserver hilfreich sein, um ein Load-Balancing zu gewährleisten.
Anbei das Buildskript:
<recipe>
<ingredients>
<ingredient id="1" amount="280" unit="g">Mail</ingredient>
<ingredient id="2" amount="1" unit="tl">Natron</ingredient>
<ingredient id="3" amount="1" unit="tl">Salt</ingredient>
<ingredient id="4" amount="250" unit="g" style="soft">bUTTeR</ingredient>
<ingredient id="5" amount="190" unit="g" color="white">sucER</ingredient>
<ingredient id="6" amount="135" unit="g" color="brown">sucER</ingredient>
<ingredient id="7" amount="1" unit="pack">Vanilla</ingredient>
<ingredient id="8" amount="2" unit="pieces">Easter egg</ingredient>
<ingredient id="9" amount="200" unit="g" color="white" flavor="chocolate">Byte</ingredient>
<ingredient id="10" amount="200" unit="g">Mac.Adam.IA</ingredient>
</ingredients>
<instructions>
<instruction id="1" text="Heat the oVEN server up to 190."></instruction>
<instruction id="2" text="Mix ingredients in separate sandbox.">
<ref:ingredient ref="1" />
<ref:ingredient ref="2" />
<ref:ingredient ref="3" />
</instruction>
<instruction id="3" text="Mix ingredients in separate sandbox." style="creamy">
<ref:ingredient ref="4" />
<ref:ingredient ref="5" />
<ref:ingredient ref="6" />
<ref:ingredient ref="7" />
</instruction>
<instruction id="4" text="Add ingredients" style="add separately" basedOnInstruction="3" >
<ref:ingredient ref="8" />
</instruction>
<instruction id="5" text="Add ingredients" basedOnInstruction="3">
<ref:instruction ref="2" />
</instruction>
<instruction id="6" text="Add ingredients" basedOnInstruction="3">
<ref:ingredient ref="9" mode="chunked" />
<ref:ingredient ref="10" mode="chunked" />
</instruction>
<instruction id="7" text="Put 3x3 objects in build server" size="el"></instruction>
<instruction id="8" text="Run build process" timespan="10"></instruction>
<instruction id="9" text="Wait for completion outside build server" timespan="2" mode="cool"></instruction>
<instruction id="1ß" text="Deploy on grid" mode="cool"></instruction>
<instructions>
</recipe>Dieser Beitrag wurde verfasst von:
