使用NetScaler的cookieinsert和sourceip联合进行session保持机制即主用cookieinsert方式进行保持，当cookieinsert失效时启用sourceip的保持机制。
客户端访问到NetScaler的某一个vserver，NetScaler接收到第一个request时，使用load balance的算法（比如least connection）进行分发到真实服务器。当服务器返回response给NetScaler时，NetScaler会在这个response的http头部插入一个cookie，命名为NSC_xxxx。当下一个request中带有这个cookie时，NetScaler就会根据这个cookie进行session保持。如下是这个cookie的官方说明：
The system inserts the following cookie NSC_XXXX=<ServiceIP ><ServicePort> 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.
The system inserts the following cookie NSC_XXXX=<ServiceIP ><ServicePort> 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.
但是在NetScaler版本6.1和8.0关于这个cookie的插入动作有区别，如下：
1， 在NetScaler NS6.1: Build 96上，cookieinsert这个动作是在同一个session的 每一个response里都插入的，不管timeout时间设置为多少（包括0）；
2， 而在NetScaler NS8.0: Build 53.2上，cookieinsert这个动作当设置时间为0时是在同一个session的 第一个response里插入的，后续的不会插入了（可以通过httpwatch查看证明，实际上这个改动在NS7.0就更新了）。但是将cookie的时间设置为非0时，cookieinsert这个动作是在同一个session的 每个response里都插入的，因为要告知client进行此cookie的时间更新。
1， 在NetScaler NS6.1: Build 96上，cookieinsert这个动作是在同一个session的 每一个response里都插入的，不管timeout时间设置为多少（包括0）；
2， 而在NetScaler NS8.0: Build 53.2上，cookieinsert这个动作当设置时间为0时是在同一个session的 第一个response里插入的，后续的不会插入了（可以通过httpwatch查看证明，实际上这个改动在NS7.0就更新了）。但是将cookie的时间设置为非0时，cookieinsert这个动作是在同一个session的 每个response里都插入的，因为要告知client进行此cookie的时间更新。
一般最常用的session保持机制就是使用cookieinsert（0mins）为主，sourceip为backup机制。官方是这样说明原理的：
The Backup persistence option is used when the primary configured persistence mechanism on virtual server fails. For example, if the primary persistence is Cookie Insert, the backup persistence can be set to Source IP to handle any client browsers that do not support cookies.
The Backup persistence option is used when the primary configured persistence mechanism on virtual server fails. For example, if the primary persistence is Cookie Insert, the backup persistence can be set to Source IP to handle any client browsers that do not support cookies.
Any client browsers that do not support cookies，这句话值得我们深究。一般我们是认为当NetScaler完成了第一次response插入NSC后紧接着接收到的request中应该带有这个NSC，但是当没有这个NSC时，NetScaler就是用backup机制进行保持。但是实际上这是错误的。NetScaler怎样判断browser do not support cookies呢？原理如下：
NS接收到下一个request时，会查看这个request的http头中是否存在cookie字段：
■ Cookie字段存在，然后查看是否有NS自己插入的cookie（NSC）
√ 如果存在就根据此NSC进行分发；
√ 如果不存在或者NSC值错误（可能被篡改），就会根据lb的算法进行分发（原来理解为根据backup的方式）；
■ Cookie字段不存在，就根据backup的方式进行保持。
NS接收到下一个request时，会查看这个request的http头中是否存在cookie字段：
■ Cookie字段存在，然后查看是否有NS自己插入的cookie（NSC）
√ 如果存在就根据此NSC进行分发；
√ 如果不存在或者NSC值错误（可能被篡改），就会根据lb的算法进行分发（原来理解为根据backup的方式）；
■ Cookie字段不存在，就根据backup的方式进行保持。
当然有些场景不需要我们了解到如此细致，就能够满足应用的需求做到session保持了。但是在某些场景（比如跨域访问，可以参见上篇博文"初识P3P”）就需要非常注意这个操作原理，否则就会出现session保持不了的情况。
本文转自 chris_lee 51CTO博客，原文链接：http://blog.51cto.com/ipneter/150993，如需转载请自行联系原作者
