[前端]前端面試題第二波~[http/tcp/網絡篇]

時間 2019-11-18

標籤前端端面試題第二 http tcp 網絡欄目 HTTP/TCP 简体版

原文原文鏈接

目錄:javascript

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與數據庫中，到時只驗證用戶名與登陸時間戳就能夠了。

這幾種方案驗證帳號時都要查詢數據庫。

參考: Cookie/Session機制詳解

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）當協商緩存也沒有命中的時候，瀏覽器直接從服務器加載資源數據。

關於強緩存:
1. 當瀏覽器對某個資源的請求命中了強緩存時，返回的http狀態爲200，在chrome的開發者工具的network裏面size會顯示爲from cache
2. 強緩存是利用Expires或者Cache-Control這兩個http response header實現的，它們都用來表示資源在客戶端緩存的有效期。
3. Expires: 是http1.0提出的一個表示資源過時時間的header，它描述的是一個絕對時間，由服務器返回，用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，它的緩存原理是：
  1. 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Expires的header
  2. 瀏覽器在接收到這個資源後，會把這個資源連同全部response header一塊兒緩存下來（因此緩存命中的請求返回的header並非來自服務器，而是來自以前緩存的header）；
  3. 瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源後，拿出它的Expires跟當前的請求時間比較，若是請求時間在Expires指定的時間以前，就能命中緩存，不然就不行。
  4. 若是緩存沒有命中，瀏覽器直接從服務器加載資源時，Expires Header在從新加載的時候會被更新。
4. Cache-Control: Expires是較老的強緩存管理header，因爲它是服務器返回的一個絕對時間，在服務器時間與客戶端時間相差較大時，緩存管理容易出現問題，好比隨意修改下客戶端時間，就能影響緩存命中的結果。因此在http1.1的時候，提出了一個新的header，就是Cache-Control，這是一個相對時間，在配置緩存的時候，以秒爲單位，用數值表示，如：Cache-Control:max-age=315360000，它的緩存原理是：
  1. 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Cache-Control的header
  2. 瀏覽器在接收到這個資源後，會把這個資源連同全部response header一塊兒緩存下來；
  3. 瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源後，根據它第一次的請求時間和Cache-Control設定的有效期，計算出一個資源過時時間，再拿這個過時時間跟當前的請求時間比較，若是請求時間在過時時間以前，就能命中緩存，不然就不行。
  4. 若是緩存沒有命中，瀏覽器直接從服務器加載資源時，Cache-Control Header在從新加載的時候會被更新。
5. Cache-Control描述的是一個相對時間，在進行緩存命中的時候，都是利用客戶端時間進行判斷，因此相比較Expires，Cache-Control的緩存管理更有效，安全一些。
6. 這兩個header能夠只啓用一個，也能夠同時啓用，當response header中，Expires和Cache-Control同時存在時，Cache-Control優先級高於Expires
關於協商緩存
1. 當瀏覽器對某個資源的請求沒有命中強緩存，就會發一個請求到服務器，驗證協商緩存是否命中，若是協商緩存命中，請求響應返回的http狀態爲304而且會顯示一個Not Modified的字符串
2. 協商緩存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】這兩對Header來管理的。
3. 【Last-Modified，If-Modified-Since】的控制緩存的原理是：
  1. 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Last-Modified的header，這個header表示這個資源在服務器上的最後修改時間
  2. 瀏覽器再次跟服務器請求這個資源時，在request的header上加上If-Modified-Since的header，這個header的值就是上一次請求時返回的Last-Modified的值：
  3. 服務器再次收到資源請求時，根據瀏覽器傳過來If-Modified-Since和資源在服務器上的最後修改時間判斷資源是否有變化，若是沒有變化則返回304 Not Modified，可是不會返回資源內容；若是有變化，就正常返回資源內容。當服務器返回304 Not Modified的響應時，response header中不會再添加Last-Modified的header，由於既然資源沒有變化，那麼Last-Modified也就不會改變，這是服務器返回304時的response header：
  4. 瀏覽器收到304的響應後，就會從緩存中加載資源。
  5. 若是協商緩存沒有命中，瀏覽器直接從服務器加載資源時，Last-Modified Header在從新加載的時候會被更新，下次請求時，If-Modified-Since會啓用上次返回的Last-Modified值。
4. 【ETag、If-None-Match】: 【Last-Modified，If-Modified-Since】都是根據服務器時間返回的header，通常來講，在沒有調整服務器時間和篡改客戶端緩存的狀況下，這兩個header配合起來管理協商緩存是很是可靠的，可是有時候也會服務器上資源其實有變化，可是最後修改時間卻沒有變化的狀況，而這種問題又很不容易被定位出來，而當這種狀況出現的時候，就會影響協商緩存的可靠性。因此就有了另一對header來管理協商緩存，這對header就是【ETag、If-None-Match】。它們的緩存管理的方式是：
  1. 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上ETag的header，這個header是服務器根據當前請求的資源生成的一個惟一標識，這個惟一標識是一個字符串，只要資源有變化這個串就不一樣，跟最後修改時間沒有關係，因此能很好的補充Last-Modified的問題：
  2. 瀏覽器再次跟服務器請求這個資源時，在request的header上加上If-None-Match的header，這個header的值就是上一次請求時返回的ETag的值：
  3. 服務器再次收到資源請求時，根據瀏覽器傳過來If-None-Match和而後再根據資源生成一個新的ETag，若是這兩個值相同就說明資源沒有變化，不然就是有變化；若是沒有變化則返回304 Not Modified，可是不會返回資源內容；若是有變化，就正常返回資源內容。與Last-Modified不同的是，當服務器返回304 Not Modified的響應時，因爲ETag從新生成過，response header中還會把這個ETag返回，即便這個ETag跟以前的沒有變化
  4. 瀏覽器收到304的響應後，就會從緩存中加載資源。
瀏覽器行爲對緩存的影響
1. 若是資源已經被瀏覽器緩存下來，在緩存失效以前，再次請求時，默認會先檢查是否命中強緩存，若是強緩存命中則直接讀取緩存，若是強緩存沒有命中則發請求到服務器檢查是否命中協商緩存，若是協商緩存命中，則告訴瀏覽器仍是能夠從緩存讀取，不然才從服務器返回最新的資源。這是默認的處理方式
2. 如下行爲可能改變緩存的默認處理方式
  1. 當ctrl+f5強制刷新網頁時，直接從服務器加載，跳過強緩存和協商緩存；
  2. 當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頭字段

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個狀態響應碼

參考: HTTP/1.1 與 HTTP/1.0的區別

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文件後會對已經渲染的頁面從新渲染，加入它們應有的樣式，圖片文件加載完馬上顯示在相應位置。在這一過程當中可能會觸發頁面的重繪或重排。

　　參考：從輸入URL到瀏覽器顯示頁面發生了什麼

　　其餘：瀏覽器中輸入網址後到頁面展示的過程

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)
1. 渲染樹和DOM樹有區別, DOM樹徹底與html標籤一一對應, 可是渲染樹會忽略掉不須要渲染的元素, 好比head, display: none的元素等
2. 一大段文本中的每一行在渲染樹中都是一個獨立的節點
3. 渲染樹的每個節點都存儲有對應的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時會發送哪幾個部分?

 
        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控制UL LI 的樣式詳解(推薦)

CSS

1. CSS實現動畫效果

2. Animation還有哪些其餘屬性?

3. CSS實現三列布局

4. CSS實現保持長寬比1:1

參考:

純 CSS 實現高度與寬度成比例的效果

使用css保持必定寬高比例

5. CSS實現兩個自適應等寬元素中間空10個像素

6. 浮動的原理以及如何清除浮動

=============================================================

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.實現頁面的局部刷新

二、手寫鏈表倒數第K個查找

四、垂直居中，多行文本垂直居中

五、原型鏈的解釋

六、對閉包的理解，實現一個暴露內部變量，並且外部能夠訪問修改的函數（get和set，閉包實現）

七、{}=={}? []==[]? null==undefined?

八、基本的數據類型

九、基本的兩列自適應佈局

十、unix中經常使用的命令行

十二、網站性能優化

1三、解釋平衡二叉樹，以及在數據結構中的應用（紅黑樹）

1四、快排的時間複雜度和空間複雜度。

一面問的基礎知識不少，可是基本都答出來了，面完後有些蒙逼。

二面是一位女面試官，給的壓力很大，人比較嚴肅，不苟言笑，後來據說二面是壓力面，二面問了50分鐘。

一、手寫一個jQuery插件

二、在jquery方法和原型上面添加方法的區別和實現（$.extend,$.fn.extend），以及jquery對象的實現（return new jQuery.fn.init）

三、手寫一個遞歸函數（考察arguments.callee，以及arguments的解釋）

四、對前端路由的理解？先後端路由的區別？

五、介紹一下webpack和gulp，以及項目中具體的使用

六、你對es6的瞭解

七、解釋一下vue和react，以及異同點

八、關於平衡二叉樹

九、先後端分離的意義以及對前端工程化的理解

十、使用css實現一個三角形（盒模型border和css旋轉，主要考察css3旋轉）

十一、用promise手寫ajax

十二、手寫一個繼承，並解釋一下

1三、解釋一下call函數和apply函數的做用，以及用法

二面面完後我很虛，感受本身答的不是很好，有可能掛了，可是沒想到當天下午就收到了三面的通知。

三面也是一位哥哥，過程還算輕鬆，也面了50多分鐘，不知道結果如何

一、介紹一下本身

二、你說本身抗壓能力強，具體表如今哪裏？

三、對前端前景的展望，之後前端會怎麼發展

四、手寫第一次面試沒有寫出來的鏈表問題，要求用es6寫

五、平時是怎麼學技術的？

六、平時大學裏面時間是怎麼規劃的？

七、接下來有什麼計劃？這個學期和下個學期的計劃是？

八、項目中遇到的難點，或者你學習路上的難點

九、你是經過什麼方法和途徑來學習前端的

十、手寫一個簡單遍歷算法

十一、解釋一下react和vue，以及區別

1三、對java的理解

1四、介紹node.js，而且介紹你用它作的項目

一、介紹本身

二、手寫一個js的深克隆

三、for函數裏面setTimeout異步問題

四、手寫歸併排序

五、介紹本身的項目

面試我一開始我就想離開了，由於面試官態度太差了，我當時就想說怪不得連百度都要把外賣賣給美團，這面試官的素質。

原本以爲本身掛了，可是過兩天收到了二面的通知。

二面是一位人很好的哥哥，問的也挺難的，也讓我對外賣改觀了。

一、實現兩個數組的排序合併，我一開始先合併再排序，他不樂意，而後我用了相似插入排序的方法。

三、手寫一個promise版的ajax

四、手寫實現一個promise（不會）

五、手寫實現requireJS模塊實現（想了半天才想到createElement("script"），配合異步來加載，閉包導出）

六、手寫實現jquery裏面的insertAfter（結合nextSibling和insertBefore來實現）

七、react和vue的介紹以及異同

八、AMD和CMD，commonJS的區別

題目參考:

互聯網前端面試面經（網易/騰訊等）by 丟三落四的松鼠

百度前端三面面經+百度外賣一二面面經（武漢）by 驗證碼有誤

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。