Cookieinsert and SOURCEIP Joint maintenance mechanism of NetScaler

Cookieinsert and SOURCEIP Joint maintenance mechanism of NetScaler

Using NetScaler's Cookieinsert and Sourceip, the session hold mechanism is maintained by the main cookieinsert mode, when Cookieinsert The retention mechanism of SOURCEIP is enabled when the failure occurs.

Client access toOne of the NetScalervSERVERNetScaler received the firstWhen you request, use theThe load balance algorithm (e.g.least connection) is distributed to the real server. When the server returnsResponse toWhen NetScaler,NetScaler will be in thisResponse's HTTP header inserts a cookie, named nsc_xxxx. When the next request comes with this cookie,NetScaler will keep the session based on the cookie . The following is an official description of this cookie:
The system inserts the following cookie nsc_xxxx= where
XXXX is the encrypted name of the virtual server serving the request;
SERVICEIP is the hexadecimal value of the physical service ' s IP address;
Serviceport is the hexadecimal value of the physical service ' s port.

But inNetScaler version6.1 and8.0 about thisThe insert action of the cookie is different, as follows:
1, inNetScaler Ns6.1:build 96,Cookieinsert This action is in the sameSession ofeach oneresponse are inserted, regardless of timeout time set to how much (including Span lang= "en-us" >0),  
2, while in netscaler NS8.0: Build 53.2, cookieinsert This action when the set time is 0 is in the same session the The first response , Follow-up will not be inserted (can be httpwatch view proof, in fact, this change in ns7.0 is updated). However, the time of cookie is set to non-cookieinsert This action is in the same session each response because to tell client to do this The time of the cookie is updated.

The general most commonly used session keeping mechanism is to use Cookieinsert (0mins) as the main,Sourceip as the backup mechanism. This is how the government describes the principle:
The Backup persistence option is used if the primary configured persistence mechanism on virtual server fails. For example, if the primary persistence are Cookie Insert, the backup persistence can be set to Source IP to handle any CLI ENT browsers that don't support cookies.

The "Any client browsers" that does not support cookies is worth our scrutiny. Generally, we think that whenNetScaler finished the first timeResponse InsertionThe NSC immediately after receiving theThe request should contain thisNSC, but when there is no thisNSC,NetScaler is usedThe backup mechanism is maintained. But it's actually wrong.NetScaler How to judgeWhat about browser do and support cookies? The principle is as follows:
ns receive the next request, this request will be viewed http header exists cookie field:  
 cookie field exists, and then see if there is ns itself inserted cookie ( nsc)  
    √    if present in accordance with this nsc for distribution;  
    √   if not present or nsc value error (possibly tampered), will be based on lb Algorithm for distribution (originally understood to be based on backup way);  
 cookie field does not exist, it is maintained according to backup.

Of course, some scenarios do not require us to understand so carefully, we can meet the needs of the application to keep the session. However, in some scenarios (such as cross-domain access, you can see the previous post " P3P") You need to pay great attention to this principle of operation, otherwise the session will not be able to maintain the situation.

Report Interface:

Configuration Interface:

Cookieinsert and SOURCEIP Joint maintenance mechanism of NetScaler