注冊(cè)和登錄幾乎是所有產(chǎn)品的必備功能之一，本文作者以細(xì)節(jié)規(guī)則為例，講解了注冊(cè)、登錄功能背后的設(shè)計(jì)原理，一起來(lái)看一下吧。

注冊(cè)和登錄功能幾乎是所有產(chǎn)品的必備功能之一。對(duì)于用戶，注冊(cè)、登錄后就可以生成唯一標(biāo)識(shí)用戶身份的信息，并基于此信息同步用戶行為數(shù)據(jù)。對(duì)于平臺(tái)或公司，用戶注冊(cè)時(shí)填寫的有效信息可以有利于后期的精細(xì)化運(yùn)營(yíng)。

下面以細(xì)節(jié)規(guī)則為例講解注冊(cè)、登錄功能背后的設(shè)計(jì)原理。

一、校驗(yàn)信息時(shí)的正則表達(dá)式

如圖6-1所示，這是一款需要用戶提供手機(jī)號(hào)和驗(yàn)證碼進(jìn)行注冊(cè)、登錄的App。在用戶輸入正確的手機(jī)號(hào)和驗(yàn)證碼后，App服務(wù)器會(huì)校驗(yàn)該手機(jī)號(hào)是否已注冊(cè)，若用戶未注冊(cè)就點(diǎn)擊“登錄”按鈕，App會(huì)先幫用戶完成注冊(cè)，若用戶已注冊(cè)，則會(huì)成功登錄。

再來(lái)對(duì)比兩種情況。第一種情況，將手機(jī)斷網(wǎng)并設(shè)為飛行模式。當(dāng)手機(jī)號(hào)碼輸入框中沒(méi)有任何內(nèi)容時(shí)，發(fā)送驗(yàn)證碼的按鈕處于置灰狀態(tài)且顯示“請(qǐng)輸入11位手機(jī)號(hào)碼”的提示文案。當(dāng)在手機(jī)號(hào)碼輸入框中輸入了符合正常手機(jī)號(hào)碼格式的手機(jī)號(hào)時(shí)，發(fā)送驗(yàn)證碼的按鈕處于可以點(diǎn)擊的狀態(tài)（顏色由灰變藍(lán)）。

圖6-1 登錄頁(yè)面手機(jī)號(hào)碼校驗(yàn)示意圖1

對(duì)照?qǐng)D6-2看看第二種情況。在手機(jī)號(hào)碼輸入框內(nèi)輸入了12位數(shù)字時(shí)，發(fā)送驗(yàn)證碼的按鈕再次處于置灰狀態(tài)。將輸入的數(shù)字調(diào)整為11位，并將首位數(shù)字改為2，即調(diào)整為不符合正常手機(jī)號(hào)碼格式的情況，發(fā)送驗(yàn)證碼的按鈕也處于置灰狀態(tài)。

圖6-2 登錄頁(yè)面手機(jī)號(hào)校驗(yàn)示意圖2

總結(jié)一下上面兩種情況。在無(wú)網(wǎng)絡(luò)情況下，App會(huì)對(duì)手機(jī)號(hào)碼進(jìn)行是否符合格式要求的校驗(yàn)。

那么如何校驗(yàn)?zāi)兀恳话憧梢酝ㄟ^(guò)正則表達(dá)式。比如在上面的案例中，只要是1開(kāi)頭的11位數(shù)字就是符合要求的，可用正則表達(dá)式表示為 /^1[0-9]{10}$/。

二、怎么實(shí)現(xiàn)記住密碼功能

為了方便用戶下次登錄，常見(jiàn)做法就是在用戶第一次登錄時(shí)，引導(dǎo)用戶勾選類似記住密碼的選項(xiàng)，當(dāng)用戶下次打開(kāi)App時(shí)就可以直接登錄App，如圖6-3所示。

圖6-3 登錄時(shí)的記住密碼功能

但登錄時(shí)用戶長(zhǎng)期無(wú)須輸入密碼也存在一定的安全風(fēng)險(xiǎn)，部分平臺(tái)在方便與安全之間做出了權(quán)衡，提供了多少天內(nèi)免登錄的選項(xiàng)。超出限制時(shí)間后，用戶再打開(kāi)App時(shí)依然需要輸入密碼。

在如圖6-4所示的案例中，登錄印象筆記網(wǎng)頁(yè)版時(shí)，勾選了“30天內(nèi)記住我”復(fù)選框，這樣用戶30天內(nèi)均可自動(dòng)登錄印象筆記網(wǎng)頁(yè)版，超出時(shí)間后才需要重新手動(dòng)登錄。

圖6-4 登錄時(shí)的“30天內(nèi)記住我”功能

上述案例的核心技術(shù)原理分為兩個(gè)方面，一個(gè)方面是如何記住密碼，另一個(gè)方面是如何設(shè)置賬號(hào)、密碼的有效期。

1. 如何記住密碼

賬號(hào)和密碼可以記錄在本地。打開(kāi)產(chǎn)品時(shí)，便將預(yù)先保存在本地的賬號(hào)和密碼取出，與服務(wù)器進(jìn)行校驗(yàn)。這里的“本地”，對(duì)于Web產(chǎn)品來(lái)說(shuō)就是在瀏覽器中，對(duì)于App來(lái)說(shuō)則是在手機(jī)中。

常見(jiàn)的技術(shù)解決方案有哪些呢？

首先，是基于Cookie的方案。

Cookie是客戶端向服務(wù)器發(fā)起請(qǐng)求后，服務(wù)器返回給客戶端的信息之一，客戶端會(huì)將Cookie保存下來(lái)并在后續(xù)接口中帶上該信息，使服務(wù)器可以判斷是哪個(gè)客戶端發(fā)起的請(qǐng)求。

在自動(dòng)登錄場(chǎng)景下，用戶首次登錄后，賬號(hào)和密碼會(huì)被記錄在Cookie中，后續(xù)登錄時(shí)，客戶端便從本地取出Cookie中的賬號(hào)和密碼發(fā)送給服務(wù)器驗(yàn)證，通過(guò)后登錄成功，省去了用戶手動(dòng)重復(fù)輸入賬號(hào)和密碼的過(guò)程。

在Web類型的產(chǎn)品中，則是利用localStorage來(lái)實(shí)現(xiàn)記住密碼功能的。localStorage是HTML5標(biāo)準(zhǔn)中新加入的一種技術(shù)，該技術(shù)用于解決Cookie存儲(chǔ)空間比較小的問(wèn)題。與每條Cookie僅4Kb的容量大小相比，localStorage的容量大小一般會(huì)達(dá)到5Mb，具體容量大小在不同的瀏覽器中會(huì)存在差異。并且，保存在localStorage中的數(shù)據(jù)是永不過(guò)期的，除非進(jìn)行了主動(dòng)清空操作。

但把賬號(hào)和密碼信息保存在本地，存在賬號(hào)密碼被泄露及偽造的風(fēng)險(xiǎn)。所以，基于Token的方案便應(yīng)運(yùn)而生。大致過(guò)程與基于Cookie的方案類似，只是Token中無(wú)須保存賬號(hào)和密碼信息，從而提高了安全性。

2. 如何設(shè)置賬號(hào)、密碼的有效期

首先，依然是借助Cookie方案。在客戶端向服務(wù)器發(fā)起請(qǐng)求之后，服務(wù)器給客戶端返回Cookie時(shí)，直接設(shè)置好過(guò)期時(shí)間，一旦過(guò)期，客戶端的Cookie信息就會(huì)被清除，后續(xù)登錄則需要重新驗(yàn)證。

另外，就是借助Token方案。Token類似于Cookie，也可以設(shè)置過(guò)期時(shí)間。設(shè)定過(guò)程如下：首次登錄時(shí)，客戶端將賬號(hào)和密碼發(fā)送給服務(wù)器，服務(wù)器創(chuàng)建refresh token和token兩個(gè)參數(shù)，將它們綁定，并設(shè)置不同的過(guò)期時(shí)間（一般可將token參數(shù)的過(guò)期時(shí)間設(shè)定得更早），后續(xù)登錄只需帶著Token即可校驗(yàn)。Token過(guò)期了以后，客戶端就會(huì)向服務(wù)器重新申請(qǐng)Token，此時(shí)會(huì)先比對(duì)之前的refresh token，匹配后便生成新的token替換掉之前refresh token綁定的token，并將新的token返回給客戶端，后續(xù)客戶端發(fā)送請(qǐng)求時(shí)，帶上新的token即可，于是用戶的登錄狀態(tài)便是一直可用的，直到token和refresh token參數(shù)都過(guò)期后，用戶才需要重新輸入賬號(hào)和密碼。

三、單點(diǎn)登錄

公司的產(chǎn)品數(shù)量不多時(shí)，用戶注冊(cè)賬號(hào)登錄，并結(jié)合記住密碼功能，便可滿足用戶短期內(nèi)均無(wú)須再次輸入賬號(hào)和密碼的需求。

但公司產(chǎn)品數(shù)量增加后，依然會(huì)讓用戶感受到注冊(cè)登錄過(guò)程的煩瑣。比如，騰訊、阿里這類大型公司旗下有眾多產(chǎn)品，產(chǎn)品之間往往會(huì)產(chǎn)生關(guān)聯(lián)，如果用戶在使用其中某款產(chǎn)品時(shí)需要跳轉(zhuǎn)到其他產(chǎn)品進(jìn)行登錄認(rèn)證，一定會(huì)感到十分不便。對(duì)于產(chǎn)品設(shè)計(jì)者，也需要設(shè)計(jì)重復(fù)的登錄認(rèn)證邏輯。

解決這類問(wèn)題的技術(shù)方案叫單點(diǎn)登錄，英文全稱是Single Sign On，縮寫是SSO。這里有一個(gè)誤區(qū)，因?yàn)楹芏喈a(chǎn)品經(jīng)理一直以為，同一時(shí)間只允許一個(gè)賬號(hào)在一臺(tái)設(shè)備上登錄的需求就是單點(diǎn)登錄，但實(shí)際上單點(diǎn)登錄是指產(chǎn)品中存在多套不同的系統(tǒng)，并且這些系統(tǒng)之間彼此是可信任的，只需讓用戶登錄一次，后續(xù)便可直接登錄產(chǎn)品中的任一系統(tǒng)。

目前市面上最主流的單點(diǎn)登錄方案實(shí)現(xiàn)思路，要么是基于Cookie和Session自己搭建，要么是借助現(xiàn)成框架實(shí)現(xiàn)。

1. 直接基于Cookie與Session實(shí)現(xiàn)單點(diǎn)登錄

一般公司的不同產(chǎn)品均位于同一個(gè)根域名下，但也不排除有些公司一條業(yè)務(wù)線或一個(gè)產(chǎn)品就占用一個(gè)單獨(dú)的域名。舉例說(shuō)明，如果公司服務(wù)器域名為example.com，且存在兩個(gè)系統(tǒng)對(duì)應(yīng)的子域名為big.example.com及huge.example.com，在提供了登錄功能的情況下，用戶如果要打開(kāi)這兩個(gè)域名對(duì)應(yīng)的系統(tǒng)頁(yè)面，是需要分別登錄的。那么怎樣才能讓用戶在登錄了其中一個(gè)系統(tǒng)后，打開(kāi)另一個(gè)域名對(duì)應(yīng)的系統(tǒng)時(shí)無(wú)須重復(fù)登錄呢？

借助前面講解過(guò)的Cookie知識(shí)，如果用戶登錄其中一個(gè)系統(tǒng)，在客戶端本地記錄下用戶登錄的Cookie信息，下次用戶依然在同一端打開(kāi)另一個(gè)系統(tǒng)登錄，是不是可以將之前用戶本地保存的Cookie信息拿過(guò)來(lái)直接用呢？遺憾的是，Cookie的使用不支持跨域，即不能直接拿Cookie中關(guān)于big.example.com域名的賬號(hào)信息直接登錄huge.example.com。那么，如何解決這個(gè)問(wèn)題呢？好在設(shè)置Cookie時(shí)，除了可以設(shè)置當(dāng)前域的信息，還可以設(shè)置對(duì)應(yīng)的頂級(jí)域名，即example.com，在子域中又可以訪問(wèn)頂級(jí)域中的Cookie信息。

拿到登錄賬號(hào)信息還沒(méi)完，還需要驗(yàn)證賬號(hào)是否依然處于登錄狀態(tài)，此時(shí)就要借助Session來(lái)完成了。

用戶在某個(gè)子域名登錄后，服務(wù)器可在數(shù)據(jù)庫(kù)中保存Session信息，其中就記錄了登錄狀態(tài)。只要登錄狀態(tài)尚未結(jié)束，便可根據(jù)Cookie找到Session，保持之前的登錄狀態(tài)。具體如何根據(jù)Cookie找到Session呢？例如，用戶在子域名big.example.com登錄后，保存的是cookie1并生成對(duì)應(yīng)的session1，然后在子域名huge.example.com登錄，保存的是cookie2并生成對(duì)應(yīng)的session2，兩個(gè)獨(dú)立的Session是無(wú)法知道彼此的登錄狀態(tài)的。為了解決這個(gè)問(wèn)題，就需要借助Session共享技術(shù)。簡(jiǎn)單來(lái)講，就是可將第一個(gè)子域名對(duì)應(yīng)的系統(tǒng)與服務(wù)器會(huì)話時(shí)生成的Session共享給同一個(gè)根域名下的其他子域名使用，這樣就可以解決有登錄的Cookie信息，但沒(méi)法確定登錄狀態(tài)，從而實(shí)現(xiàn)用戶的免密登錄。

2. 基于CAS方案實(shí)現(xiàn)單點(diǎn)登錄

上面的方案已經(jīng)能夠解決不同產(chǎn)品歸屬同一頂級(jí)域名下情況的登錄問(wèn)題，但如果各個(gè)業(yè)務(wù)線域名都是獨(dú)立的，那怎樣實(shí)現(xiàn)單點(diǎn)登錄呢？下面介紹市面上比較成熟的開(kāi)源解決方案CAS。

在實(shí)現(xiàn)CAS這套方案時(shí)，除了需要提供正常的業(yè)務(wù)系統(tǒng)，還需要一個(gè)專門負(fù)責(zé)認(rèn)證用戶的系統(tǒng)，用于存儲(chǔ)登錄用戶的標(biāo)識(shí)。用戶在登錄其他系統(tǒng)時(shí)，借助已存儲(chǔ)的標(biāo)識(shí)進(jìn)行驗(yàn)證，這時(shí)用戶無(wú)須再次登錄。在整套CAS方案中，認(rèn)證系統(tǒng)被稱為CAS Server，業(yè)務(wù)系統(tǒng)被稱為CAS Client。

實(shí)現(xiàn)過(guò)程大致可以分為兩個(gè)環(huán)節(jié)，一是初次登錄，二是后續(xù)登錄。

下面通過(guò)案例進(jìn)行說(shuō)明。假定某個(gè)集團(tuán)公司叫小風(fēng)科技集團(tuán)，旗下的子公司分別叫中風(fēng)科技發(fā)展有限公司和大風(fēng)科技發(fā)展有限公司。中風(fēng)科技發(fā)展有限公司主營(yíng)業(yè)務(wù)是線上社交類電商，大風(fēng)科技發(fā)展有限公司主營(yíng)業(yè)務(wù)是線上醫(yī)療。兩家公司原本獨(dú)立運(yùn)營(yíng)，產(chǎn)品研發(fā)分離，域名也是獨(dú)立申請(qǐng)的。因?yàn)閼?zhàn)略方向上的調(diào)整，兩家子公司的業(yè)務(wù)需要產(chǎn)生關(guān)聯(lián)，需要進(jìn)行產(chǎn)品整合，整合任務(wù)之一就是實(shí)現(xiàn)系統(tǒng)的單點(diǎn)登錄。

先說(shuō)初次登錄。用戶在使用子公司中風(fēng)科技發(fā)展有限公司的產(chǎn)品時(shí)，之前登錄時(shí)會(huì)直接請(qǐng)求服務(wù)器，改造為CAS模式后，則會(huì)變成先去請(qǐng)求CAS Server，若無(wú)法找到Cookie信息，則判定為初次登錄，然后提示用戶輸入賬號(hào)和密碼進(jìn)行登錄。完成后，CAS Server便將登錄信息（包括登錄狀態(tài)）一并寫入服務(wù)器Session中，并記錄下登錄的Cookie信息。此外，它還會(huì)在登錄成功后，生成一個(gè)叫作ST（Service Ticket）的內(nèi)容，ST會(huì)在CAS Server和業(yè)務(wù)系統(tǒng)之間做來(lái)回的雙向驗(yàn)證，雙方確認(rèn)無(wú)誤后，首次登錄就成功了。

再說(shuō)后續(xù)登錄。用戶想要訪問(wèn)其他業(yè)務(wù)系統(tǒng)時(shí)，也會(huì)先將登錄信息提交給CAS Server，待找到匹配的Cookie和Session信息，并經(jīng)歷ST的雙向驗(yàn)證通過(guò)，就可以實(shí)現(xiàn)后續(xù)用戶登錄其他業(yè)務(wù)系統(tǒng)時(shí)，無(wú)須再次輸入賬號(hào)和密碼便能直接登錄的需求。

3. 基于OAuth方案實(shí)現(xiàn)單點(diǎn)登錄

OAuth實(shí)際上是一種開(kāi)放協(xié)議。通過(guò)這種協(xié)議，可以讓第三方應(yīng)用獲取到用戶在某一個(gè)平臺(tái)存儲(chǔ)的與個(gè)人信息相關(guān)的資源，并且在獲取這些信息時(shí)，不需要用戶提供賬號(hào)和密碼。

在講解怎么樣借助OAuth方案實(shí)現(xiàn)單點(diǎn)登錄前，先講講OAuth協(xié)議的授權(quán)。

如圖6-5所示，登錄京東網(wǎng)頁(yè)版時(shí)，選擇使用微信等第三方賬號(hào)授權(quán)登錄，會(huì)展示讓微信用戶授權(quán)的二維碼，在用戶掃碼同意授權(quán)以后，微信開(kāi)放平臺(tái)便會(huì)驗(yàn)證用戶身份是否正確，如果正確，會(huì)生成一個(gè)臨時(shí)的憑證給用戶，用戶再拿著這個(gè)臨時(shí)憑證去微信開(kāi)放平臺(tái)換取access_token（注意這里的access_token是OAuth 2.0協(xié)議中客戶端訪問(wèn)資源服務(wù)器時(shí)需要帶上的令牌，有了這個(gè)令牌說(shuō)明用戶已經(jīng)同意授權(quán)了）。到這一步后，基本上就已經(jīng)完成了授權(quán)登錄的過(guò)程。當(dāng)然，后面還需要通過(guò)從微信獲取到的用戶信息來(lái)生成會(huì)話。

圖6-5 京東網(wǎng)頁(yè)版登錄功能

在整個(gè)交互流程上，OAuth協(xié)議中涉及4個(gè)不同的角色，分別是resource owner（資源擁有者）、resource server（資源服務(wù)器）、client（客戶端）、authorization server（授權(quán)服務(wù)器），不同的角色會(huì)起到不同的作用。資源擁有者代表用戶信息歸屬于誰(shuí)，在上面的案例中資源擁有者就是微信用戶。資源服務(wù)器是存儲(chǔ)授權(quán)后訪問(wèn)網(wǎng)頁(yè)的用戶信息的服務(wù)器，比如微信服務(wù)器?？蛻舳思窗l(fā)起訪問(wèn)的客戶端。授權(quán)服務(wù)器則是專門用于處理認(rèn)證授權(quán)的服務(wù)器，在上面的案例中微信開(kāi)放平臺(tái)提供的認(rèn)證服務(wù)器便充當(dāng)了這個(gè)角色。上面的角色還可以繼續(xù)簡(jiǎn)化，但至少需要保留客戶端和授權(quán)服務(wù)器。

四、多終端設(shè)備的用戶互踢

同一時(shí)間只允許一個(gè)賬號(hào)在一臺(tái)設(shè)備上登錄，很多產(chǎn)品這樣做是為了避免出現(xiàn)賬號(hào)被他人使用但用戶無(wú)法察覺(jué)的情況。針對(duì)這類需求，由于終端的差異，因此存在著不同的實(shí)現(xiàn)方式。

下面先來(lái)梳理場(chǎng)景。既然是端對(duì)端的訪問(wèn)過(guò)程，假定用戶小風(fēng)使用A賬號(hào)在某個(gè)瀏覽器或App中登錄，此時(shí)向服務(wù)器發(fā)起請(qǐng)求，服務(wù)器就會(huì)創(chuàng)建一個(gè)Session用于保持與客戶端之間的會(huì)話狀態(tài)。與此同時(shí)，服務(wù)器會(huì)基于客戶端傳來(lái)的一些參數(shù)（比如UUID、MAC地址等設(shè)備唯一標(biāo)識(shí)）來(lái)生成Token，并將該Token與賬號(hào)綁定，保存在服務(wù)器。另一個(gè)用戶大風(fēng)，這時(shí)也使用同樣的賬號(hào)A在不同的設(shè)備中登錄，也同樣會(huì)向服務(wù)器發(fā)起請(qǐng)求，服務(wù)器則會(huì)根據(jù)客戶端提交的賬號(hào)進(jìn)行查詢，發(fā)現(xiàn)Token已經(jīng)存在，說(shuō)明該賬號(hào)還處于登錄狀態(tài)，但由于大風(fēng)也向服務(wù)器發(fā)起了請(qǐng)求，所以為了確保大風(fēng)能正常登錄，便會(huì)生成一個(gè)新Token并將之前的Token信息刪除。

在用戶登錄后，服務(wù)器還需要通知前面登錄的用戶被擠出登錄的事實(shí)。

結(jié)合前面所學(xué)的網(wǎng)絡(luò)請(qǐng)求相關(guān)知識(shí)，無(wú)論是移動(dòng)端還是Web端，在與服務(wù)器交互的過(guò)程中，均為客戶端發(fā)起請(qǐng)求，服務(wù)器響應(yīng)并返回信息給客戶端。采用這種方式意味著，雖然前面登錄的用戶明明已經(jīng)被后面登錄的用戶“擠”了下去，但還是得通過(guò)某個(gè)特定的操作，向服務(wù)器發(fā)起請(qǐng)求，服務(wù)器查詢到新用戶使用同一個(gè)賬號(hào)登錄，才會(huì)為前面的用戶注銷登錄。于是，就會(huì)出現(xiàn)在一段時(shí)間內(nèi)，存在兩個(gè)用戶同時(shí)登錄的狀態(tài)。

因此，服務(wù)器如果能主動(dòng)向客戶端推送消息，就可以解決上面的問(wèn)題，下面介紹兩類解決方案。

1. 輪詢與長(zhǎng)輪詢

輪詢，可以被理解為在客戶端，通過(guò)定時(shí)任務(wù)，定時(shí)向服務(wù)器發(fā)起請(qǐng)求，服務(wù)器收到請(qǐng)求后根據(jù)請(qǐng)求的信息進(jìn)行響應(yīng)。采用這種方式，有利有弊，優(yōu)點(diǎn)是技術(shù)實(shí)現(xiàn)方便，缺點(diǎn)是會(huì)產(chǎn)生大量無(wú)效請(qǐng)求，加重網(wǎng)絡(luò)負(fù)載，甚至還會(huì)造成服務(wù)器性能的浪費(fèi)。

為了減少不必要的請(qǐng)求，便出現(xiàn)了長(zhǎng)輪詢。長(zhǎng)輪詢與輪詢的不同之處在于，輪詢時(shí)服務(wù)器收到客戶端的請(qǐng)求后會(huì)立即響應(yīng)，長(zhǎng)輪詢時(shí)服務(wù)器收到客戶端的請(qǐng)求后不立即響應(yīng)，而是會(huì)暫時(shí)保持發(fā)起請(qǐng)求后的連接狀態(tài)，直到服務(wù)器得到客戶端想要的結(jié)果后才通知客戶端，從而減少向服務(wù)器發(fā)起請(qǐng)求的次數(shù)。

2. WebSocket

無(wú)論是輪詢還是長(zhǎng)輪詢，都基于HTTP協(xié)議，該協(xié)議最大的缺點(diǎn)是無(wú)法做到服務(wù)器向客戶端主動(dòng)推送消息。為了克服這一缺點(diǎn)，下面將引出WebSocket方案。

WebSocket也是一種網(wǎng)絡(luò)通信協(xié)議，但WebSocket協(xié)議與HTTP協(xié)議不同，其服務(wù)器與客戶端之間可以雙向互推消息。它最常見(jiàn)的應(yīng)用場(chǎng)景便是即時(shí)通信、視頻網(wǎng)站彈幕、在線協(xié)同文檔等。

WebSocket方案的實(shí)現(xiàn)原理大致如下：客戶端發(fā)起HTTP協(xié)議請(qǐng)求到服務(wù)器，并在請(qǐng)求頭中附加Upgrade: WebSocket信息來(lái)表明將協(xié)議升級(jí)為WebSocket，服務(wù)器收到請(qǐng)求后返回允許客戶端切換協(xié)議的響應(yīng)信息 switching，此時(shí)雙方便以WebSocket方式開(kāi)啟了通信管道，直到任意一方?jīng)Q定主動(dòng)關(guān)閉。

五、離線登錄是怎么一回事

離線登錄指沒(méi)有網(wǎng)絡(luò)或服務(wù)器出現(xiàn)故障時(shí)，用戶依然可以正常登錄并使用產(chǎn)品。比如，對(duì)于隨手記記賬產(chǎn)品，用戶在注冊(cè)登錄后，可記錄自己的消費(fèi)情況，進(jìn)而形成好的理財(cái)習(xí)慣。為了兼顧用戶體驗(yàn)及技術(shù)實(shí)現(xiàn)，一般會(huì)設(shè)計(jì)為在無(wú)網(wǎng)情況下，用戶可以通過(guò)離線模式將數(shù)據(jù)記錄在本地，待網(wǎng)絡(luò)恢復(fù)后，再將數(shù)據(jù)上傳至服務(wù)器。

想要實(shí)現(xiàn)離線登錄，最好用戶曾經(jīng)采用聯(lián)網(wǎng)的方式登錄過(guò)產(chǎn)品，確?？蛻舳吮镜乇４媪擞脩舻腃ookie信息，甚至還可以緩存一部分軟件使用過(guò)程中的數(shù)據(jù)（比如剛才的記賬信息），也就是通過(guò)本地?cái)?shù)據(jù)持久化的方式進(jìn)行實(shí)現(xiàn)，Cookie信息便是其中一種數(shù)據(jù)持久化方式。除此之外，將賬號(hào)信息加密后以文件方式保存在本地也是可行的。

本文節(jié)選自作者新書《產(chǎn)品經(jīng)理技術(shù)手冊(cè)》，本書定位于讓不懂技術(shù)的產(chǎn)品經(jīng)理從產(chǎn)品經(jīng)理的工作和思考方式切入了解應(yīng)該掌握的技術(shù)原理。