目錄:
http和ajax等:
1. Cookie 是否會被覆蓋，localStorage是否會被覆蓋?
答: Cookie是可以覆蓋的，如果重復寫入同名的Cookie，那么將會覆蓋之前的Cookie
如果要刪除某個Cookie，只需要新建一個同名的Cookie，並將maxAge設置為0，並添加到response中覆蓋原來的Cookie。注意是0而不是負數。負數代表其他的意義。
localStorage存儲在一個對象中. 有鍵值對
2. 如何保持登陸狀態?
答: 把登錄信息如賬號、密碼等保存在Cookie中，並控制Cookie的有效期，下次訪問時再驗證Cookie中的登錄信息即可。
保存登錄信息有多種方案。最直接的是把用戶名與密碼都保持到Cookie中，下次訪問時檢查Cookie中的用戶名與密碼，與數據庫比較。這是一種比較危險的選擇，一般不把密碼等重要信息保存到Cookie中。
還有一種方案是把密碼加密后保存到Cookie中，下次訪問時解密並與數據庫比較。這種方案略微安全一些。如果不希望保存密碼，還可以把登錄的時間戳保存到Cookie與數據庫中，到時只驗證用戶名與登錄時間戳就可以了。
這幾種方案驗證賬號時都要查詢數據庫。
3. Ajax原生
//**********第一步, 獲得一個xhr對象************* var xmlHttpReq = null; //聲明一個空對象用來裝入XMLHttpRequest if (window.ActiveXObject){//IE5 IE6是以ActiveXObject的方式引入XMLHttpRequest的 xmlHttpReq = new ActiveXObject("Microsoft.XMLHTTP"); } else if (window.XMLHttpRequest){//除IE5 IE6 以外的瀏覽器XMLHttpRequest是window的子對象 xmlHttpReq = new XMLHttpRequest();//實例化一個XMLHttpRequest } if(xhr != null){ //如果對象實例化成功 //設置回調函數 xhr.onreadystatechange = function(){ if(xhr.readyState == 4){ //確定響應已經成功返回 //200可作為成功標志, 304表示請求資源沒有修改, 可直接使用瀏覽器緩存 if ((xhr.status>=200 && xhr.status < 300 ) || xhr.status == 304){ alert(xhr.responseText); } else { alert( " Request was unsuccessful: " + xhr.status); } } } //************第二步: 啟動請求.****************** //open方法接收三個參數: 要發送的請求類型(get,post等), 請求的url和是否異步發送請求的布爾值 xhr.open("get","test.php",true); //調用open()方法並采用異步方式. 如果第三個參數是false, 同步執行, 則js代碼會等到服務器響應之后再繼續執行 //*************第三步: 發送數據******************* //send方法接收一個參數,即要作為請求主體發送的數據. 如果不需要通過請求主體發送數據, 則必須傳入null. 因為這個參數對有些瀏覽器是必須的 xhr.send(null); //因為使用get方式提交，所以可以使用null參調用 // 如果要設置請求頭部信息,必須在調用open()方法之后且調用send()方法之前調用setRequestHeader()
- readyStatus的五個階段
- 0：未初始化。尚未調用open()方法
- 1：啟動。已經調用open()方法，尚未調用send()方法
- 2：發送。已經調用send()方法，尚未接收到響應
- 3：接收。已經接收部分響應數據。
- 4：完成。已經接收到全部響應數據，而且已經可以在客戶端使用了。【一般只需檢查這個階段】
- 獲得的數據在responseText或responseXML屬性中, 后者需要XML解析
參考:《JavaScript》高級程序設計第21章：Ajax和Comet，jsonp
4. Jsonp的原理。怎么去讀取一個script里面的數據。
答: 動態添加一個<script>標簽，而script標簽的src屬性是沒有跨域的限制的。
首先在客戶端注冊一個callback, 然后把callback的名字傳遞給服務器. 服務端得到請求的數據后, 要用callback把要輸出返回的內容包起來, 這樣, 服務器生成的json數據就能被客戶端正確接收了.
然后以js語法的方式,生成一個function, function的名字就是傳遞上來的參數callback方法的名字
最后將json數據直接以入參的方式, 放置到function中, 這樣就生成了一段js語法的文檔, 返回給客戶端.
客戶端瀏覽器, 解析script標簽,. 並執行返回的js文檔, 此時js文檔數據作為參數, 傳遞到了客戶端預先定義好的callback函數里.
參考: JSONP跨域的原理解析
舉個栗子:
<script type="text/javascript"> function jsonpCallback(result) { alert(result.msg); } </script> <script type="text/javascript" src="http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback"></script>
其中jsonCallback是客戶端注冊的，獲取跨域服務器上的JSON數據后，回調的函數。http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback 這個url是跨域服務器取JSON數據的接口，參數為回調函數的名字，返回的格式為： jsonpCallback({msg:'this is json data'}) 。如此就生成了一段js語法的文檔, 傳回客戶端就可以調用jsonpCallBack函數了.
所以這里也可以看到, 回調函數應當是定義在全局的?
5. 如果頁面初始載入的時候把ajax請求返回的數據存在localStorage里面，然后每次調用的時候去localStorage里面取數，是否可行。
（直接說了不能保證數據的實時性，請求和實時性必然會有一方有所犧牲）
6. 304是什么意思？
答: 304表示請求資源沒有修改, 可以直接使用瀏覽器緩存.
7. 強緩存和協商緩存的命中和管理
答:
- 1）瀏覽器在加載資源時，先根據這個資源的一些http header判斷它是否命中強緩存，強緩存如果命中，瀏覽器直接從自己的緩存中讀取資源，不會發請求到服務器。比如某個css文件，如果瀏覽器在加載它所在的網頁時，這個css文件的緩存配置命中了強緩存，瀏覽器就直接從緩存中加載這個css，連請求都不會發送到網頁所在服務器；
- 2）當強緩存沒有命中的時候，瀏覽器一定會發送一個請求到服務器，通過服務器端依據資源的另外一些http header驗證這個資源是否命中協商緩存，如果協商緩存命中，服務器會將這個請求返回，但是不會返回這個資源的數據，而是告訴客戶端可以直接從緩存中加載這個資源，於是瀏覽器就又會從自己的緩存中去加載這個資源；
- 3）強緩存與協商緩存的共同點是：如果命中，都是從客戶端緩存中加載資源，而不是從服務器加載資源數據；區別是：強緩存不發請求到服務器，協商緩存會發請求到服務器。
- 4）當協商緩存也沒有命中的時候，瀏覽器直接從服務器加載資源數據。
-
關於強緩存:
- 當瀏覽器對某個資源的請求命中了強緩存時，返回的http狀態為200，在chrome的開發者工具的network里面size會顯示為from cache
- 強緩存是利用Expires或者Cache-Control這兩個http response header實現的，它們都用來表示資源在客戶端緩存的有效期。
- Expires: 是http1.0提出的一個表示資源過期時間的header，它描述的是一個絕對時間，由服務器返回，用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，它的緩存原理是：
- 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Expires的header
- 瀏覽器在接收到這個資源后，會把這個資源連同所有response header一起緩存下來（所以緩存命中的請求返回的header並不是來自服務器，而是來自之前緩存的header）；
- 瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源后，拿出它的Expires跟當前的請求時間比較，如果請求時間在Expires指定的時間之前，就能命中緩存，否則就不行。
- 如果緩存沒有命中，瀏覽器直接從服務器加載資源時，Expires Header在重新加載的時候會被更新。
- Cache-Control: Expires是較老的強緩存管理header，由於它是服務器返回的一個絕對時間，在服務器時間與客戶端時間相差較大時，緩存管理容易出現問題，比如隨意修改下客戶端時間，就能影響緩存命中的結果。所以在http1.1的時候，提出了一個新的header，就是Cache-Control，這是一個相對時間，在配置緩存的時候，以秒為單位，用數值表示，如：Cache-Control:max-age=315360000，它的緩存原理是：
- 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Cache-Control的header
- 瀏覽器在接收到這個資源后，會把這個資源連同所有response header一起緩存下來；
- 瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源后，根據它第一次的請求時間和Cache-Control設定的有效期，計算出一個資源過期時間，再拿這個過期時間跟當前的請求時間比較，如果請求時間在過期時間之前，就能命中緩存，否則就不行。
- 如果緩存沒有命中，瀏覽器直接從服務器加載資源時，Cache-Control Header在重新加載的時候會被更新。
- Cache-Control描述的是一個相對時間，在進行緩存命中的時候，都是利用客戶端時間進行判斷，所以相比較Expires，Cache-Control的緩存管理更有效，安全一些。
- 這兩個header可以只啟用一個，也可以同時啟用，當response header中，Expires和Cache-Control同時存在時，Cache-Control優先級高於Expires
-
關於協商緩存
- 當瀏覽器對某個資源的請求沒有命中強緩存，就會發一個請求到服務器，驗證協商緩存是否命中，如果協商緩存命中，請求響應返回的http狀態為304並且會顯示一個Not Modified的字符串
- 協商緩存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】這兩對Header來管理的。
-
【Last-Modified，If-Modified-Since】的控制緩存的原理是：
-
瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Last-Modified的header，這個header表示這個資源在服務器上的最后修改時間
-
瀏覽器再次跟服務器請求這個資源時，在request的header上加上If-Modified-Since的header，這個header的值就是上一次請求時返回的Last-Modified的值：
-
服務器再次收到資源請求時，根據瀏覽器傳過來If-Modified-Since和資源在服務器上的最后修改時間判斷資源是否有變化，如果沒有變化則返回304 Not Modified，但是不會返回資源內容；如果有變化，就正常返回資源內容。當服務器返回304 Not Modified的響應時，response header中不會再添加Last-Modified的header，因為既然資源沒有變化，那么Last-Modified也就不會改變，這是服務器返回304時的response header：
-
瀏覽器收到304的響應后，就會從緩存中加載資源。
-
如果協商緩存沒有命中，瀏覽器直接從服務器加載資源時，Last-Modified Header在重新加載的時候會被更新，下次請求時，If-Modified-Since會啟用上次返回的Last-Modified值。
-
-
【ETag、If-None-Match】: 【Last-Modified，If-Modified-Since】都是根據服務器時間返回的header，一般來說，在沒有調整服務器時間和篡改客戶端緩存的情況下，這兩個header配合起來管理協商緩存是非常可靠的，但是有時候也會服務器上資源其實有變化，但是最后修改時間卻沒有變化的情況，而這種問題又很不容易被定位出來，而當這種情況出現的時候，就會影響協商緩存的可靠性。所以就有了另外一對header來管理協商緩存，這對header就是【ETag、If-None-Match】。它們的緩存管理的方式是：
-
瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上ETag的header，這個header是服務器根據當前請求的資源生成的一個唯一標識，這個唯一標識是一個字符串，只要資源有變化這個串就不同，跟最后修改時間沒有關系，所以能很好的補充Last-Modified的問題：
-
瀏覽器再次跟服務器請求這個資源時，在request的header上加上If-None-Match的header，這個header的值就是上一次請求時返回的ETag的值：
-
服務器再次收到資源請求時，根據瀏覽器傳過來If-None-Match和然后再根據資源生成一個新的ETag，如果這兩個值相同就說明資源沒有變化，否則就是有變化；如果沒有變化則返回304 Not Modified，但是不會返回資源內容；如果有變化，就正常返回資源內容。與Last-Modified不一樣的是，當服務器返回304 Not Modified的響應時，由於ETag重新生成過，response header中還會把這個ETag返回，即使這個ETag跟之前的沒有變化
- 瀏覽器收到304的響應后，就會從緩存中加載資源。
-
-
瀏覽器行為對緩存的影響
-
如果資源已經被瀏覽器緩存下來，在緩存失效之前，再次請求時，默認會先檢查是否命中強緩存，如果強緩存命中則直接讀取緩存，如果強緩存沒有命中則發請求到服務器檢查是否命中協商緩存，如果協商緩存命中，則告訴瀏覽器還是可以從緩存讀取，否則才從服務器返回最新的資源。這是默認的處理方式
-
以下行為可能改變緩存的默認處理方式
-
當ctrl+f5強制刷新網頁時，直接從服務器加載，跳過強緩存和協商緩存；
-
當f5刷新網頁時，跳過強緩存，但是會檢查協商緩存；
-
-
參考: 瀏覽器緩存知識小結及應用by 流雲諸葛
8. http請求和響應的消息結構:
答:
- 請求消息結構
- 一個請求行, 若干消息頭, 以及實體內容.
- 當中的一些消息頭和實體內容都是可選的, 消息頭和實體內容之間要用空行隔開.
- 響應消息結構
- 一個狀態行, 若干消息頭, 以及實體內容
- 當中的一些消息頭和實體內容都是可選的, 消息頭和實體內容之間要用空行隔開.
- 兩者區別: 請求消息有請求行, 響應消息有狀態行
實例見下一題.
url在請求行, cookie在請求頭
參考: HTTP請求報文解剖
9. http請求頭有哪些字段
答:
http請求和http響應都使用頭發送有關http消息的信息. 頭由一系列行組成, 每行都包含名稱, 然后依次是冒號, 空格, 值. 字段可按任何順序排列. 某些頭字段既可以用於請求頭也可以用於響應頭, 而另一些字段只能使用其中之一.
許多請求字段都允許客戶端在值部分指定多個可接收的選項, 有時甚至可以對這些選項的首選項進行排名. 多個項以逗號分隔. 例如, 客戶端可以發送包含"Content-Encoding: gzip, compress"的請求頭, 表示可以接受各種壓縮類型. 如果服務器的響應正文使用gzip編碼,其響應頭中將包含"Content-Encoding: gzip".
有些字段可以在單個頭中出現多次, 例如, 頭可以有多個"Warning"字段.
下表列出了http1.1頭字段. 注意, 有些頭字段是mime字段. mime字段在ietf文檔rfc2045中進行了定義, 但也可用於http1.1協議.
一般頭字段: 一般頭字段可用於請求消息和響應消息
| Cache-Control | 指定請求和響應遵循的緩存機制. 請求消息或響應消息中設置Cache-Control並不會修改另一個消息處理過程只能怪的緩存處理過程 | "max-age=10" or "no-cache" or "no-store" |
| Connection | 處理完這次請求后是否斷開連接還是繼續保持連接 | "close" or "Keep-Alive" |
| Date | 表示消息發送的時間. 時間的描述格式由rfc822定義 | "Tue, 11 Jul 2000 18:23:51 GMT" |
| Pragma | 用來包含實現特殊的指令 知道"no-cache"值表示服務器必須返回一個刷新后的文檔, 即使它是代理服務器而且已經有了頁面的本地拷貝 |
"no-cache"(與設置Cache-Control: no-cache相同) |
| Trailer | "Date" | |
| Transfer-Encoding | "chuncked" | |
| Upgrade | 向服務器指定某種傳輸協議以便服務器進行轉換(如果支持) | "SHTTP/1.3" |
| Via | 通知中間網關或代理服務器地址, 通信協議 | "HTTP/1.1 Proxy1, HTTP/1.1 Proxy2" |
| Warning | 關於實體消息的警告細心 | "112 Disconnected Operation" |
請求字段頭:
請求消息的第一行格式為:
Method SP Request-URI SP HTTP-Version CRLF
- Method表示對Request-URI完成的方法, 這個字段是大小寫敏感的, 包括 OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE
- GET方法取回Request-URI標識的信息,
- HEAD方法也是取回由Request-URI標識的信息, 只是可以在響應時不返回消息體,
- POST方法可以請求服務器接收包含在請求中的實體消息, 可以用於提交表單, 向新聞組, BBS, 郵件群組和數據庫發送消息.
- SP表示空格
- Request-URI遵循URI格式,在此字段為*時, 說明請求並不用於某個特定的資源地址, 而是用於服務器本身.
- HTTP-Version表示支持的http版本, 例如HTTP/1.1
- CRLF表示換行符
請求頭域: 允許客戶端向服務器傳遞關於請求或者關於客戶機的附加信息.
| Accept | 瀏覽器能夠處理的內容類型. | "text/html, iamge/*" |
| Accept-Charset | 告訴服務器, 客戶端采用的編碼格式/字符集 | "iso8859-5" |
| Accept-Encoding | 告訴服務器, 客戶機支持的數據壓縮格式 | "gzip, compress" |
| Accept-Language | 客戶機的語言環境 | "en, fr" |
| Authorization | 授權信息., 通常出現在對服務器發送的WWW-Authenticate頭的應答中 | [credentials] |
| Content-Encoding | "gzip" | |
| Expect | "100-continue" | |
| From | 請求發送者的email地址, 由一些特殊的web客戶程序使用, 瀏覽器不會用到 | "user@microsoft.com" |
| Host | 客戶機想訪問的主機名. 即指定資源的internet主機和端口號. 必須表示請求url的原始服務器或網關的位置, http/1.1 請求必須包含主機頭域, 否則系統會以400狀態碼返回 | "www.microsoft.com" |
| If-Match | "entity_tag001" | |
| If-Modified-Since | 資源的緩存時間. 只有當所請求的內容在指定的日期之后又經過修改才返回它, 否則返回304 "Not Modified" 應答 | "Tue, 11 Jul 2000 18:12:12 GMT" |
| If-None=Match | "entity_tag001" | |
| If-Range | "entity_tag001" or "Tue, 11 Jul 2000 18:12:12 GMT" | |
| If-Unmodified-Since | "Tue, 11 Jul 2000 18:12:12 GMT" | |
| Max-Forwards | "3" | |
| Proxy-Authorization | [credentials] | |
| Range | 請求實體的一個或者多個子范圍. 如示例即表示請求100-599個字節. 但是服務器可以忽略此請求頭, 如果無條件get包含range請求頭, 響應會以狀態碼206返回而不是200 |
"bytes=100-599" |
| Referer | 告訴服務器, 客戶端是從哪個資源來訪問服務器的(防盜鏈) | "http://www.microsoft.com/resources.asp" |
| TE | 客戶端願意接受的傳輸編碼, 並通知服務器接受接受尾加頭信息 | "trailers" |
| User-Agent | 客戶機的軟件環境, 瀏覽器類型 | "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)" |
響應頭字段:
響應消息的第一行為下面的格式
HTTP-Version SP Status-Code SP Reason-Phrase CRLF
| Accecpt-Ranges | 表面服務器是否支持指定范圍請求及哪種類型的分段請求 | "none" |
| Age | 從原始服務器到代理緩存形成的估算時間(以秒記, 非負) | "2147483645(2^31)" |
| ETag | 緩存相關的頭 | "b38b9-17dd-367c5dcd" |
| Last-Modified | 請求資源的最后修改時間 | "Tue, 11 Jul 2000 18:23:51 GMT" |
| Location | 配合302狀態碼使用, 用於告訴客戶找誰 | "http://localhost/redirecttarget.asp" |
| Proxy-Authenticate | 指出認證方案和可應用到代理的該url上的參數 | [challenge] Proxy-Authenticate: Basic |
| Retry-After | "Tue, 11 Jul 2000 18:23:51 GMT" or "60" | |
| Server | 服務器通過這個告訴瀏覽器數據的服務器的類型 | "Microsoft-IIS/5.0" |
| Vary | "Date" | |
| WWW-Authenticate | [challenge] |
實體頭字段
請求消息和響應消息都可以包含實體信息. 實體信息一般是由實體頭域和實體組成. 實體頭域包含關於實體的原信息.實體可以是一個經過編碼的字節流. 其編碼方式由Content-Encoding和content-Type定義. 長度由Content-Length或Content-Range定義.
實體頭字段:實體頭字段可以用於請求消息或響應消息. 實體頭字段中包含消息實體正文的有關信息, 如使用的編碼格式
| Allow | "GET, HEAD" | |
| Content-Encoding | 數據的壓縮格式 | "gzip" |
| Content-Language | "en" | |
| Content-Length | 請求消息正文的長度 | "8445" |
| Content-Location | "http://localhost/page.asp" | |
| Content-MD5 | [md5-digest] | |
| Content-Range | 用於指定整個實體中的一部分的插入位置, 也指示了整個實體的長度. 在服務器向客戶返回一個部分響應,它必須描述響應覆蓋的范圍和整個實體長度 | "bytes 2543-4532/7898" |
| Content-Type | 數據的類型. 指定head方法送到接收方的實體介質類型, 或get方法發送的請求介質類型Content-Range實體頭 | "text/html" |
| Expires | 告訴瀏覽器把回送的資源緩存多長時間 -1或0則是不緩存. 即應該在什么時候認為文檔已經過期, 從而不再緩存它 |
"Tue, 11 Jul 2000 18:12:12 GMT" |
| Last-Modified | 當前資源的最后緩存時間. 即服務器上保存內容的最后修訂時間. 客戶可以通過If-Modified-Since請求頭提供一個日期, 該請求將被視為一個條件get, 只有改動時間遲於指定時間的文檔才會返回, 否則返回一個304(Not Modified)狀態 | "Tue, 11 Jul 2000 18:12:12 GMT" |
實體內容:
代表服務器向客戶端回送的數據
請求頭實例:
GET /articles/news/today.asp HTTP/1.1
Accept: */*
Accept-Language: en-us
Connection: Keep-Alive
Host: localhost
Referer: http://localhost/links.asp
User-Agent: Mozilla/4.0 (compatible; MSIE 3.5; Windows NT 5.0)
Accept-Encoding: gzip, deflate
該請求具有請求行, 其中包括方法(GET), 資源路徑(/articles/news/today.asp)和http版本(http/1.1). 由於該請求沒有正文, 故所有請求行后面的內容都是頭的一部分. 緊接着頭之后是一個空行, 表示頭已結束.
響應頭實例
Web服務器可以通過多種方式響應前一個請求, 假設文件是可以訪問的, 並且用戶具有查看該文件的權限, 則響應類似於:
HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Thu, 13 Jul 2000 05:34:32 GMT Content-Length: 2291 Content-Type: text/html Set-Cookie: ASPSESSIONIDQQGGGNCG=LKLDFFKCINFLDMFHCBCBMFLJ; path=/ Cache-control: private <HTML> <BODY> ...
響應的第一行稱為狀態行. 它包含響應所用的http版本, 狀態編碼(200)和原因短語. 示例中包含一個頭, 其中具有五個字段, 接着是一個空行(回車和換行符), 然后是響應正文的頭兩行.
參考: HTTP頭參考 HTTP協議---HTTP請求中的常用請求字段和HTTP的響應狀態碼及響應頭 HTTP頭字段
10. http響應常見狀態碼
- 100-199 : 表示成功接收請求, 要求客戶端繼續提交下一次請求才能完成整個處理過程
- 200-299: 表示成果接收請求並已完成整個處理過程. 常用200
- 300-399: 為完成請求, 客戶需進一步細化需求: 例如: 請求的資源已經移動一個新地址, 常用302(重定向), 307和304(拿緩存)
- 400-499: 客戶端的請求有錯誤, 包含語法錯誤或者不能正確執行. 常用404(請求的資源在web服務器中沒有) 403(服務器拒絕訪問, 權限不夠)
- 500-599: 服務器端出現錯誤
常用:
- 200 正常 表示一切正常, 返回的是正常請求結果
- 302/307 臨時重定向 指出請求的文檔已被臨時移動到別處, 此文檔的新的url在location響應頭中給出
- 304 未修改 表示客戶機緩存的版本是最新的, 客戶機應該繼續使用它
- 403 禁止 服務器理解客戶端請求, 但拒絕處理它, 通常用於服務器上文件或目錄的權限設置所致
- 404 找不到 服務器上不存在客戶機所請求的資源
- 500 服務器內部錯誤 服務器端的cgi, asp, jsp等程序發生錯誤
11. 簡述http 1.1 與 http 1.0的區別
答:
- http 1.0 對於每個連接都得建立一次連接, 一次只能傳送一個請求和響應, 請求就會關閉, http1.0沒有Host字段
- 而http1.1 在同一個連接中可以傳送多個請求和響應, 多個請求可以重疊和同時進行, http1.1必須有host字段
- http1.1中引入了ETag頭, 它的值entity tag可以用來唯一的描述一個資源. 請求消息中可以使用If-None-Match頭域來匹配資源的entitytag是否有變化
- http1.1 新增了Cache-Control頭域(消息請求和響應請求都可以使用), 它支持一個可擴展的指令子集
- http1.0中只定義了16個狀態響應碼, 對錯誤或警告的提示不夠具體. http1.1引入了一個Warning頭域, 增加對錯誤或警告信息的描述. 且新增了24個狀態響應碼
12. 請列舉三種禁止瀏覽器緩存的頭字段, 並寫出相應的設置值
答:
- Expires: 告訴瀏覽器把回送的資源緩存多長時間 -1或0則是不緩存
- Cache-Control: no-cache
- Pragma: no-cache
13. 和客戶端瀏覽器緩存相關的http頭
-
Expires: +過期時間
- 表示在指定時間后瀏覽器緩存失效
- 這里的過期時間必須是http格式的日期時間, 其他都會被解析成當前時間"之前", 緩存會馬上過期. http的日期時間必須是格林威治時間(GMT), 而不是本地時間
- e.g. Fri, 30 Oct 2009 13:13:13
- 使用Expires過期必須要求服務器的時間是正確的,否則發送的http頭就會出問題, 在windows服務下可以設置時間服務器來同步時間
-
Cache-control: 緩存控制
- 控制緩存
- 值分為:
- max-age=[秒]: 執行緩存被認為是最新的最長時間. 類似於過期時間, 這個參數是基於請求時間的相對時間間隔, 而不是絕對過期時間, [秒]是一個數組, 單位是秒: 從請求時間到過期時間之間的秒數
- s-maxage=[秒]: 類似於max-age屬性, 除了他應用於共享(如: 代理服務器)換粗
- public: 僅體現在響應頭. 通知瀏覽器可以無條件地緩存該響應. 標記認證內容也可以被緩存. 一般來說, 經過http認證才能訪問的內容, 輸出是自動不可以緩存的
- private: 僅體現在響應頭, 通知瀏覽器只針對單個用戶緩存響應, 且可以具體指定某個字段, 如private-"username"
- no-cache: 強制每次請求之間發送給源服務器, 而不經過本地緩存版本的校驗. 這對於需要確認認證應用很有用(可以和public結合使用), 或者嚴格要求使用最新數據的應用(不惜犧牲使用緩存的所有好處)
- 請求頭中: 告訴瀏覽器回去服務器取數據, 並驗證你的緩存(如果有的話)
- 響應頭中: 告訴瀏覽器, 一定要回服務器校驗, 不管有沒有緩存數據. 如果確定沒有修改, 可以使用緩存中的數據
- no-store: 告訴瀏覽器任何情況下都不要被緩存
- must-revalidate: 告訴瀏覽器必須遵循所有你給予副本的新鮮度的, http允許緩存在某些特定情況下返回過期數據, 指定了這個屬性, 你告訴緩存, 你希望嚴格的遵循你的規則
- proxy-revalidate: 和must0revalidate類似, 除了他只對緩存代理服務器起作用
- e.g. Cache-Control: max-age=3600, must-revalidate
-
Last-Modifield / If-Modified-Since(/If-Unmodified-Since)
- 一對
- Last-Modified表示某個地址的最近更新時間, 是服務器端響應給客戶端的
- If-(Un)Modified-Since是客戶端瀏覽器發送給服務器的, 告訴web服務器客戶端有一個最后更改時間為什么時間的緩存, 服務器接收到If-Modified-Since頭后則判斷客戶端緩存的這份url地址的緩存是否是最新的, 如果是最新的則服務器直接給客戶端返回HttpStatus 304, 如果服務器發現url的最后更新時間比If-Modified-Since的值要新, 則會輸出新的內容
- 一對
-
ETag/If-None-Match
- ETag和Last-Modified類似, 不過他發送的是一個字符串來標識url的版本, 如果url變了則此標識也跟着變化, 在瀏覽器發送If\-Modified-Match時告訴瀏覽器內容已經變了, 或者沒變可以使用緩存
- list會自動給靜態文件加上Etag, 在文件發生改變時重新生成一個ETag, 這樣對於一個網站中的n多個靜態文件, 如樣式表, 小圖片等, 客戶端只需要下載一次就夠了, 可以減輕負載
-
Pragma: no-cache
- 是http1.0中的常規頭, 作用同http1.1的Cache-Control: no-cache
關於以上緩存機制的優先級:
Cache-Control > Expires : 前者設置更詳細
Cache-Control/Expires > Last-Modified/ETag : 本地副本根據Cache-Control/Expires還在有效期內, 則不會在此發送請求去服務器詢問修改時間或實體標識了
即最前面的最重要, 前面的生效后, 后面的基本就失效了
ETag默認是需要要源網站確認的, 因為要確認是否匹配. 而Last-Modified默認是不向源服務器確認的
在大型多web集群時, 使用ETag有問題. 因為多服務器時INode不一樣, 所以不同的服務器生成的ETag不一樣, 所以用戶有可能重復下載(這時ETag就會不准).
如果服務器端同時設置了ETag和Expires時, ETag原理同樣, 即與Last-Modified/ETag對應的HttpRequest Header: If-Modified-Since和If-None-Match. 則在完全匹配If-Modified-Since和If-None-Match即檢查完修改時間和ETag后, 服務器才能返回304;
如果服務器又設置了Cache-Control:max-age和Expires時, 也是同時使用.(到底是同時使用還是如上所述前者大於后者?)
一般情況下, 使用Cache-Control/ Expires 會配合Last-Modified/ETag一起使用, 因為即使在服務器設置緩存時間, 當用戶點擊"刷新"按鈕時, 瀏覽器會忽略緩存繼續向服務器發送請求, 這是后者就可以很好利用304, 從而減少響應開銷
ETag是服務器自動生成或者或者由開發者生成的對應資源在服務器端的唯一標識符, 能夠更加准確的控制緩存. Last-Modified和ETag是可以一起使用的, 服務器會優先驗證ETag, 一致的情況下, 才會繼續比對Last-Modified, 最后才決定返回304.
用戶操作和緩存的關系
| 用戶操作 | Cache-Control/Expires | Last-Modified/ETag |
| 地址欄回車 | 有效 | 有效 |
| 頁面鏈接調整 | 有效 | 有效 |
| 新開窗口 | 有效 | 有效 |
| 前進后退 | 有效 | 有效 |
| F5刷新 | 無效 | 有效 |
| Ctrl+F5 | 無效 | 無效 |
參考: 有關客戶端瀏覽器緩存的Http頭介紹 HTTP緩存相關的概念 http請求頭信息 http響應頭信息 expires與etag控制頁面緩存的優先級
14. Cookie跨域請求能不能帶上
15. js異步的方法（promise，generator，async）
答:
js語言的執行環境是單線程, 一次只能完成一個任務, 如果有多個任務則需要排隊. 於是, js將任務的執行模式分為兩種: 同步(Sychronous)和異步(Asynchronous).同步就是后一段等前一個任務執行結束再執行, 異步模式則是: 每一個任務有一個回調函數, 前一個任務結束后, 不是執行后一個任務,而是執行回調函數, 后一個任務則是不等前一個任務執行完畢就執行, 所以程序的執行順序與任務的排序順序是不一致的, 異步的.
異步的方法:
- 回調函數
- 事件監聽: 采用事件驅動模式, 任務的執行不取決於代碼的順序, 而取決於某個事件是否發生.
- 觀察者模式
- promise對象: 每一個異步任務返回一個promise對象, 該對象有一個then方法, 允許指定回調函數,
16. Get和post的區別
答:
- get請求一般用於向服務器查詢某些信息, post請求通常用於向服務器發送應該被保存的數據. 即: get是從服務器上獲取數據，post是向服務器傳送數據
- get請求可以將查詢字符串參數追加到url的末尾; post請求應該把數據作為請求的主體提交. 其請求主體可以包含非常多的數據, 而且格式不限
- 因為get請求提交的數據直接加載url末尾,所以其大小有限制; 理論來講, post是沒有大小限制的.
- post安全性比get要高
- 對於get方式, 服務器端用Request.QueryString獲取變量的值, 對於post方式, 服務器端用Request.Form獲取提交的數據
- get是把參數數據隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個字段一一對應，在URL中可以看到。post是通過HTTP post機制，將表單內各個字段與其內容放置在HTML HEADER內一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程
- get形式的url對搜索引擎更加友好，可以提高搜索引擎排名。Post使用的url有時候會阻止爬蟲和搜索引擎的訪問。其他網站和用戶可以鏈接到get形式的url，無論用戶的訪問，還是搜索引擎的收錄而相應提高了頁面排名，能夠直接或間接提高網站瀏覽。同時，get形式的url這種表示法是可以緩存的，顯著提升了客戶端和服務端的性能。
- 而不安全操作，如確定訂購、下訂單、達成協議和刪除頁面等，應該通過post執行，避免沒有顯式用戶請求和同一的情況下發生意外的操作。例如搜索引擎刪除整個頁面，只因為抓取了一個鏈接。很多不希望用戶瀏覽器遵循頁面鏈接的各種完整，這些情況下，應該要求用戶登錄並且足夠的權限才能執行某些危險操作。
- 若符合下列任一情況，則用POST方法：
- * 請求的結果有持續性的副作用，例如，數據庫內添加新的數據行。
- * 若使用GET方法，則表單上收集的數據可能讓URL過長。
- * 要傳送的數據不是采用7位的ASCII編碼。
- 若符合下列任一情況，則用GET方法：
- * 請求是為了查找資源，HTML表單數據僅用來幫助搜索。
- * 請求結果無持續性的副作用。
- * 收集的數據及HTML表單內的輸入字段名稱的總長不超過1024個字符。
17. Post一個file的時候file放在哪的？
答: 應該是請求實體吧
18. 三次握手
答: 建立TCP連接需要三次握手, 而斷開連接需要執行四次揮手.
- 三次握手: 首先Client端發送連接請求報文，Server段接受連接后回復ACK報文，並為這次連接分配資源。Client端接收到ACK報文后也向Server段發生ACK報文，並分配資源，這樣TCP連接就建立了。
- 第一步: 客戶機的TCP先向服務器的TCP發送一個連接請求報文. 這個特殊的報文中不含應用層數據, 其首部中的SYN標志位被置1. 另外, 客戶機會隨機選擇一個起始序號seq=x(連接請求報文不攜帶數據,但要消耗掉一個序號)
- 第二步: 服務器端的TCP收到連接請求報文后, 若同意建立連接, 就向客戶機發送請求, 並為該TCP連接分配TCP緩存和變量. 在確認報文中,SYN和ACK位都被置為1, 確認號字段的值為x+1, 並且服務器隨機產生起始序號seq=y(確認報文不攜帶數據, 但也要消耗掉一個序號). 確認報文同樣不包含應用層數據.
- 第三步: 當客戶機收到確認報文后, 還要向服務器給出確認, 並且也要給該連接分配緩存和變量. 這個報文的ACK標志位被置為1, 序號字段為x+1, 確認號字段為y+1
- 四次揮手
- 第一步: 客戶機打算關閉連接,就向其TCP發送一個連接釋放報文,並停止再發送數據,主動關閉TCP連接, 該報文的FIN標志位被置1, seq=u, 它等於前面已經傳送過的數據的最后一個字節的序號加1(FIN報文即使不攜帶數據,也要消耗掉一個序號)
- 第二步: 服務器接收連接釋放報文后即發出確認, 確認號是ack=u+1, 這個報文自己的序號是v, 等於它前面已傳送過的數據的最后一個自己的序號加1. 此時, 從客戶機到服務器這個方向的連接就釋放了, TCP連接處於半關閉狀態. 但服務器若發送數據, 客戶機仍要接收, 即從服務器到客戶機的連接仍未關閉.
- 第三步: 若服務器已經沒有了要向客戶機發送的數據, 就通知TCP釋放連接, 此時其發出FIN=1的連接釋放報文
- 第四步: 客戶機收到連接釋放報文后, 必須發出確認. 在確認報文中, ACK字段被置為1, 確認號ack=w+1, 序號seq=u+1. 此時, TCP連接還沒有釋放掉, 必須經過等待計時器設置的時間2MSL后, A才進入到連接關閉狀態.
19. tcp/ip／http對應哪一層 七層模型
- TCP/IP 四層協議: 應用層、傳輸層、網絡互連層和主機到網絡層. http對應應用層
- ISO 七層模型: 物理層, 數據鏈路層, 網絡層, 傳輸層, 會話層, 表示層, 應用層. http對應應用層
20. 瀏覽器中輸入網址后到頁面展現的過程
1）用戶輸入網址
2）瀏覽器通過DNS獲取網站的IP地址。客戶端先檢查本地是否有對應的IP地址，若找到則返回響應的IP地址。若沒找到則請求上級DNS服務器，直至找到或到根節點。
DNS查找IP地址的順序: 瀏覽器緩存、系統緩存、互聯網服務提供商（ISP）的DNS緩存、遞歸搜索（從瀏覽器緩存開始，如果沒找到就繼續往下一個找。）找到后，瀏覽器會獲得一個IP地址。
3）瀏覽器客戶端發送http請求
HTTP請求包括請求報頭和請求主體兩個部分，其中請求報頭包含了至關重要的信息，包括請求的方法（GET / POST）、目標url、遵循的協議（http / https / ftp…），返回的信息是否需要緩存，以及客戶端是否發送cookie等。
4）傳輸層TCP傳輸報文。TCP協議通過“三次握手”等方法保證傳輸的安全可靠。
5）網絡層IP協議查詢MAC地址
IP協議的作用是把TCP分割好的各種數據包傳送給接收方。而要保證確實能傳到接收方還需要接收方的MAC地址，也就是物理地址。IP地址和MAC地址是一一對應的關系，一個網絡設備的IP地址可以更換，但是MAC地址一般是固定不變的。ARP協議可以將IP地址解析成對應的MAC地址。當通信的雙方不在同一個局域網時，需要多次中轉才能到達最終的目標，在中轉的過程中需要通過下一個中轉站的MAC地址來搜索下一個中轉目標。
7）數據到達數據鏈路層
在找到對方的MAC地址后，就將數據發送到數據鏈路層傳輸。這時，客戶端發送請求的階段結束
8）服務器接收數據
接收端的服務器在鏈路層接收到數據包，再層層向上直到應用層。這過程中包括在運輸層通過TCP協議將分段的數據包重新組成原來的HTTP請求報文。
9）服務器響應請求
服務接收到客戶端發送的HTTP請求后，查找客戶端請求的資源，並返回響應報文，響應報文中包括一個重要的信息——狀態碼。狀態碼由三位數字組成，其中比較常見的是200 OK表示請求成功。301表示永久重定向，即請求的資源已經永久轉移到新的位置。在返回301狀態碼的同時，響應報文也會附帶重定向的url，客戶端接收到后將http請求的url做相應的改變再重新發送。404 not found 表示客戶端請求的資源找不到。
10）服務器返回響應文件
請求成功后，服務器會返回相應的HTML文件。接下來就到了頁面的渲染階段了。
11） 頁面渲染： 解析HTML以構建DOM樹 –> 構建渲染樹 –> 布局渲染樹 –> 繪制渲染樹。
關於頁面渲染過程：
1）解析HTML代碼，生成一棵DOM樹
2）解析CSS文件
3）生成渲染樹（受樣式影響，包含不可見元素）
4）渲染樹中的節點
DOM樹是由HTML文件中的標簽排列組成，渲染樹是在DOM樹中加入CSS或HTML中的style樣式而形成。渲染樹只包含需要顯示在頁面中的DOM元素，像<head>元素或display屬性值為none的元素都不在渲染樹中。
在瀏覽器還沒接收到完整的HTML文件時，它就開始渲染頁面了，在遇到外部鏈入的腳本標簽或樣式標簽或圖片時，會再次發送HTTP請求重復上述的步驟。在收到CSS文件后會對已經渲染的頁面重新渲染，加入它們應有的樣式，圖片文件加載完立刻顯示在相應位置。在這一過程中可能會觸發頁面的重繪或重排。
21. 瀏覽器是如何進行加載, 解析, 渲染的呢? 重點說一下瀏覽器渲染頁面的過程?
答:
- 用戶訪問網頁, DNS服務器(域名解析系統)會根據用戶提供的域名查找對應的IP地址, 找到后, 系統會向對應IP地址的網絡服務器發送一個http請求
- 網絡服務器解析請求, 並發送數據給數據庫服務器
- 數據庫服務器將請求的資源返回給網絡服務器, 網絡服務器解析數據, 並生成html文件, 放入http response中, 返回給服務器.
- 瀏覽器解析http response
- 瀏覽器解析http response后, 需要下載html文件, 以及html文件內包含的外部引用文件, 及文件內涉及的圖片或者多媒體文件
關於加載順序:
- 當瀏覽器獲得一個html文件, 會"自上而下"加載, 並在加載過程中進行解析渲染. 下載和渲染是同時進行的
- 在渲染到頁面的某一部分時, 其上面到所有部分都已經下載完成(並不是說所有關聯元素都已經下載完)
- 如果加載過程中遇到外部css文件, 瀏覽器會發出一個請求, 來獲取css文件.
- 樣式表在下載完成后, 將和以前下載的所有樣式表一起進行解析, 解析完成后, 將對此前所有元素(含以前已經渲染的)重新進行渲染
- 遇到圖片資源, 瀏覽器會發出請求獲取圖片資源. 這是異步請求, 並不會影響html文檔進行加載,
- 當文檔加載過程中遇到js文件, html文檔會掛起渲染(加載解析渲染同步)的線程, 不僅要等待文檔中js文件加載完畢, 還要等待解析執行完畢, 才可以恢復html文檔的渲染線程. 即js的加載不能並行下載和解析
- 原因: js有可能會修改DOM, 比如document.write. 這意味着, 在js執行完成前, 后續所有資源的下載可能是沒有必要的, 這是js阻塞后續資源下載的根本原因.
- 所以一般將外部引用的js文件放在</body>前
- 雖然css文件的加載不影響js文件的加載,但是卻影響js文件的執行, 即使js文件內只有一行代碼, 也會造成阻塞
- 原因: 可能會有: var width = $('#id').width(). 這意味着, 在js代碼執行前, 瀏覽器必須保證css文件已下載和解析完成。這也是css阻塞后續js的根本原因。
- 辦法：當js文件不需要依賴css文件時，可以將js文件放在頭部css的前面。
- 當然除了，
<link href="" />這種形式，內部<style></style>這種樣式定義，在考慮阻塞時也要考慮
- js,css中如果有重定義, 后定義函數將覆蓋前定義函數
主要解析過程:
- 瀏覽器解析html源碼, 創建一棵DOM樹
- 瀏覽器解析CSS代碼, 計算出最終的樣式數據
- js解析因為文件在加載的同時也進行解析
- 構建DOM樹, 並且計算出樣式數據后, 下一步就是構建一棵渲染樹(rendering tree)
- 渲染樹和DOM樹有區別, DOM樹完全與html標簽一一對應, 但是渲染樹會忽略掉不需要渲染的元素, 比如head, display: none的元素等
- 一大段文本中的每一行在渲染樹中都是一個獨立的節點
- 渲染樹的每一個節點都存儲有對應的css屬性
- 渲染樹創建好, 瀏覽器就可以根據渲染樹直接把頁面繪制到屏幕上
- 1.用戶輸入網址（假設是個html頁面，並且是第一次訪問），瀏覽器向服務器發出請求，服務器返回html文件；
- 2.瀏覽器開始載入html代碼，發現＜head＞標簽內有一個＜link＞標簽引用外部CSS文件；
- 3.瀏覽器又發出CSS文件的請求，服務器返回這個CSS文件；
- 4.瀏覽器繼續載入html中＜body＞部分的代碼，並且CSS文件已經拿到手了，可以開始渲染頁面了；
- 5.瀏覽器在代碼中發現一個＜img＞標簽引用了一張圖片，向服務器發出請求。此時瀏覽器不會等到圖片下載完，而是繼續渲染后面的代碼；
- 6.服務器返回圖片文件，由於圖片占用了一定面積，影響了后面段落的排布，因此瀏覽器需要回過頭來重新渲染這部分代碼；
- 7.瀏覽器發現了一個包含一行Javascript代碼的＜script＞標簽，趕快運行它；
- 8.Javascript腳本執行了這條語句，它命令瀏覽器隱藏掉代碼中的某個＜div＞ （style.display=”none”）。杯具啊，突然就少了這么一個元素，瀏覽器不得不重新渲染這部分代碼；
- 9.終於等到了＜/html＞的到來，瀏覽器淚流滿面……
- 10.等等，還沒完，用戶點了一下界面中的“換膚”按鈕，Javascript讓瀏覽器換了一下＜link＞標簽的CSS路徑；
- 11.瀏覽器召集了在座的各位＜div＞＜span＞＜ul＞＜li＞們，“大伙兒收拾收拾行李，咱得重新來過……”，瀏覽器向服務器請求了新的CSS文件，重新渲染頁面。
參考: 瀏覽器~加載, 解析, 渲染 瀏覽器加載和渲染html的順序
22. cookie和session的區別:
-
cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
-
cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session。
-
session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能
考慮到減輕服務器性能方面，應當使用COOKIE。
-
單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
-
所以建議是：
將登陸信息等重要信息存放為SESSION
其他信息如果需要保留，可以放在COOKIE中
23. 同步和異步的區別?
同步：腳本會停留並等待服務器發送回復然后再繼續。提交請求->等待服務器處理->處理完畢返回，這個期間客戶端瀏覽器不能干任何事。
異步：腳本允許頁面繼續其進程並處理可能的回復。請求通過事件觸發->服務器處理（這是瀏覽器仍然可以作其他事情）->處理完畢
若要在使用ajax請求后處理發送請求返回的結果，最好使用同步請求。
24. 瀏覽器發送cookie時會發送哪幾個部分?
|
1
2
3
|
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value; expires=失效時間; domain=域名
|
25. cookie由哪幾部分組成?
Cookie由變量名和值組成, 其屬性中既有標准的Cookie變量, 也有用戶自己創建的變量,屬性中變量是用"變量=值"形式來保存
Cookie格式如下:
Set－Cookie: NAME=VALUE；Expires=DATE；Path=PATH；Domain=DOMAIN_NAME；SECURE
Set－Cookie: NAME=VALUE；
Expires=DATE[有效終止日期]；
Path=PATH[Path屬性定義了Web服務器上哪些路徑下的頁面可獲取服務器設置的Cookie]；
Domain=DOMAIN_NAME；
SECURE[在Cookie中標記該變量，表明只有當瀏覽器和Web Server之間的通信協議為加密認證協議時，瀏覽器才向服務器提交相應的Cookie。當前這種協議只有一種，即為HTTPS]
參考: Cookie的組成
26. 請描述一下 cookies，sessionStorage 和 localStorage 的區別？
答:
- cookie:
- cookie是網站為了標示用戶身份而儲存在用戶本地終端（Client Side）上的數據（通常經過加密）。
- cookie數據始終在同源的http請求中攜帶（即使不需要），記會在瀏覽器和服務器間來回傳遞。
- sessionStorage和localStorage不會自動把數據發給服務器，僅在本地保存。
- 存儲大小：
- cookie數據大小不能超過4k。
- sessionStorage和localStorage 雖然也有存儲大小的限制，但比cookie大得多，可以達到5M或更大。
- 有期時間：
- localStorage 存儲持久數據，瀏覽器關閉后數據不丟失除非主動刪除數據；
- sessionStorage 數據在當前瀏覽器窗口關閉后自動刪除。
- cookie 設置的cookie過期時間之前一直有效，即使窗口或瀏覽器關閉
- 作用域不同:
- sessionStorage不在不同的瀏覽器窗口中共享，即使是同一個頁面；
- localStorage 在所有同源窗口中都是共享的；cookie也是在所有同源窗口中都是共享的。
- Web Storage 支持事件通知機制，可以將數據更新的通知發送給監聽者。
- Web Storage 的 api 接口使用更方便。
sessionStorage 和 localStorage 是HTML5 Web Storage API 提供的，這兩種方式都允許開發者使用js設置的鍵值對進行操作，在在重新加載不同的頁面的時候讀出它們。這一點與cookie類似。可以方便的在web請求之間保存數據。有了本地數據，就可以避免數據在瀏覽器和服務器間不必要地來回傳遞。
sessionStorage、localStorage、cookie都是在瀏覽器端存儲的數據， 其中sessionStorage的概念很特別，引入了一個“瀏覽器窗口”的概念。
sessionStorage是在同源的同窗口（或tab）中，始終存在的數據。也就是說只要這個瀏覽器窗口沒有關閉，即使刷新頁面或進入同源另一頁面，數據仍然存在。關閉窗口后，sessionStorage即被銷毀。同時“獨立”打開的不同窗口，即使是同一頁面，sessionStorage對象也是不同的。
Web Storage 數據完全存儲在客戶端, 不需要通過瀏覽器的請求將數據傳給服務器, 因此比cookies能夠存儲更多的數據,大概5M左右
Web Storage帶來的好處：
使用 local storage和session storage主要通過在js中操作這兩個對象來實現，分別為window.localStorage和window.sessionStorage. 這兩個對象均是Storage類的兩個實例，自然也具有Storage類的屬性和方法。
減少網絡流量：一旦數據保存在本地后，就可以避免再向服務器請求數據，因此減少不必要的數據請求，減少數據在瀏覽器和服務器間不必要地來回傳遞。
快速顯示數據：性能好，從本地讀數據比通過網絡從服務器獲得數據快得多，本地數據可以即時獲得。再加上網頁本身也可以有緩存，因此整個頁面和數據都在本地的話，可以立即顯示。
臨時存儲：很多時候數據只需要在用戶瀏覽一組頁面期間使用，關閉窗口后數據就可以丟棄了，這種情況使用sessionStorage非常方便。
27. 瀏覽器本地存儲與服務器端存儲之間的區別
- 其實數據既可以在瀏覽器本地存儲，也可以在服務器端存儲。
- 瀏覽器端可以保存一些數據，需要的時候直接從本地獲取，sessionStorage、localStorage和cookie都由瀏覽器存儲在本地的數據。
- 服務器端也可以保存所有用戶的所有數據，但需要的時候瀏覽器要向服務器請求數據。
- 1.服務器端可以保存用戶的持久數據，如數據庫和雲存儲將用戶的大量數據保存在服務器端。
- 2.服務器端也可以保存用戶的臨時會話數據。服務器端的session機制，如jsp的 session 對象，數據保存在服務器上。實現上，服務器和瀏覽器之間僅需傳遞session id即可，服務器根據session id找到對應用戶的session對象。會話數據僅在一段時間內有效，這個時間就是server端設置的session有效期。
- 服務器端保存所有的用戶的數據，所以服務器端的開銷較大，而瀏覽器端保存則把不同用戶需要的數據分布保存在用戶各自的瀏覽器中。
- 瀏覽器端一般只用來存儲小數據，而服務器可以存儲大數據或小數據。
- 服務器存儲數據安全一些，瀏覽器只適合存儲一般數據。
28. sessionStorage和頁面js數據對象的區別
答:
- 頁面中一般的 js 對象或數據的生存期是僅在當前頁面有效，因此刷新頁面或轉到另一頁面這樣的重新加載頁面的情況，數據就不存在了。
- 而sessionStorage 只要同源的同窗口（或tab）中，刷新頁面或進入同源的不同頁面，數據始終存在。也就是說只要這個瀏覽器窗口沒有關閉，加載新頁面或重新加載，數據仍然存在。
29. js實現跨域
js跨域是因為同源策略導致的。解決方法有：
- 圖像Ping：使用<img>標簽，因為網頁可以從任何網頁中加載圖片，而不用擔心跨域。請求數據通過字符串形式發送，而響應可以是任何內容。這種方法，1）只能發送get請求。2）瀏覽器無法獲取響應數據。3）只適用於瀏覽器與服務器之間的單向通信
- JSONP：通過動態<script>元素使用，使用時為src指定一個跨域url。有兩部分：1）回調函數：響應到來時在頁面中使用；2）數據：傳入回調函數中的JSON數據
- 后台代理方法：將后台作為代理，每次對其它域的請求轉交給本域的后台，本域的后台通過模擬http請求去訪問其它域，再將返回的結果返回給前台
- 設置document.domain：只適用於主域相同子域不同
- 使用window.name：+iframe。應用頁面創建iframe，src指向數據頁面；數據頁面把數據附加到window.name上；應用界面監聽iframe的onload事件，在此事件中設置這個iframe的src指向本地域的代理文件；獲取數據后銷毀iframe
- 使用html5新方法：window.postMessage(message, targetOrigin)
js:
1. 原生js添加class怎么添加，如果本身已經有class了，會不會覆蓋，怎么保留？
參考:
原生JS實現addClass,removeClass,toggleClass
2. 事件代理js實現
3. requireJS的原理是什么
4. 數組去除一個函數。用arr.splice。又問splice返回了什么？應該返回的是去除的元素。
5. commonJS和AMD。
6. 對象中key-value的value怎么再放一個對象。（直接放也可以，轉成json字符串存數，讀取再解析）
CSS
1. CSS實現動畫效果
2. Animation還有哪些其他屬性?
3. CSS實現三列布局
4. CSS實現保持長寬比1:1
參考:
5. CSS實現兩個自適應等寬元素中間空10個像素
6. 浮動的原理以及如何清除浮動
7.
=============================================================
1.css 盒模型
2.css 布局，左邊定寬右邊自適應。兩種方法，NEC上的用負邊距消除寬度，用彈性布局。然后問我有沒有第三種。。。
3.冒泡和捕獲，事件流哪三個階段？除了冒泡和捕獲，還有目標階段。他們的先后順序，先捕獲，到了目標，再冒泡。（不要只記概念，要了解是干么用的）
4.實現事件代理。用jquery寫了。要求寫原生。子元素傳遞上來的應該是event.target或者e.srcElement。這個強調下IE和W3C的區別，建議寫一個封裝。
5.原型鏈。繼承的兩種方法。原型鏈繼承和類繼承。然后類繼承只繼承了實例屬性，沒有原型屬性。原型鏈繼承可以繼承所有。然后用apply和call怎么繼承原型鏈上的共享屬性？通過空函數傳值。新建一個空函數C。C實例化后C的實例屬性就是空，然后用B的apply/call去繼承C，相當於繼承了C的實例屬性。
7，閉包。簡單說一個閉包的應用。然后閉包的主要作用是什么：封裝！
二面：
1.css:兩個塊狀元素上下的margin-top和margin-bottom會重疊。啥原因？怎么解決？（應該給父類元素添加BFC）
2.js：寫一個遞歸。就是每隔5秒調用一個自身，一共100次。
=============================================================
挖財 面 9.10（2輪技術面，1個多小時，沒有HR面，沒有offer。）
一面：
你對組件的理解
組件的html怎么進行管理
less和sass用過么
nodejs用過么
js的異步加載，promise的三種狀態，ES7中的async用過么
js原型鏈的繼承
靜態屬性怎么繼承
jquery和zepto有什么區別
angular的雙向綁定原理
angular和react的認識（挖財用這個兩個框架，后來問了）
MVVM是什么
二面：
適配有去考慮么，retina屏幕啊？
rem是什么？em是什么？如果上一層就是根root了，em和rem等價么？
二面面試官給我的感覺很差，那我面的也很消極，然后跪了順理成章。
1.怎么得到一個頁面的a標簽（就說了getElementByTagName和選擇器）
2.怎么在頁面里放置一個很簡單的圖標，不能用img和background-img
（說了canvas，或者一些庫有icon庫，data-icon).
3.正則表達式判斷url（只寫了判斷是否是http或者https開頭）
4.怎么去除字符串前后的空格（正則匹配^\s和\s$並且替代，Jquery的$.trim，string.trim()）
5.實現頁面的局部刷新
題目參考: