NetScaler的cookieinsert和sourceip聯合保持機制
NetScaler的cookieinsert和sourceip聯合保持機制
使用NetScaler的cookieinsert和sourceip聯合進行session保持機制即主用cookieinsert方式進行保持，當cookieinsert失效時啟用sourceip的保持機制。
客戶端訪問到NetScaler的某一個vserver，NetScaler接收到第一個request時，使用load balance的算法（比如least connection）進行分發到真實服務器。當服務器返回response給NetScaler時，NetScaler會在這個response的 http頭部插入一個cookie，命名為NSC_xxxx
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.
但是在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的每個
一般最常用的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.
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的方式進行保持。
當然有些場景不需要我們了解到如此細致，就能夠滿足應用的需求做到session保持了。但是在某些場景（比如跨域訪問，可以參見上篇博文"初識P3P”）就需要非常註意這個操作原理，否則就會出現session保持不了的情況。
報表界面：
配置界面：
NetScaler的cookieinsert和sourceip聯合保持機制