HTML面試（二）

時間  2019-11-18
標籤 html 面試 欄目 HTML 简体版
原文   原文鏈接

一、html5有哪些新特性、移除了那些元素？如何處理HTML5新標籤的瀏覽器兼容問題？如何區分 HTML 和HTML5？

HTML5 如今已經不是 SGML 的子集，主要是關於圖像，位置，存儲，多任務等功能的增長。javascript

  • 新特性
    • 繪畫 canvas
    • 用於媒介回放的 video 和 audio 元素
    • 本地離線存儲 localStorage 長期存儲數據，瀏覽器關閉後數據不丟失；
    • sessionStorage 的數據在瀏覽器關閉後自動刪除
    • 語意化更好的內容元素，好比 article、footer、header、nav、section
      表單控件，calendar、date、time、email、url、search
    • 新的技術webworker, websockt, Geolocation
  • 移除的元素
    • 純表現的元素：basefont，big，center，font, s，strike，tt，u；
    • 對可用性產生負面影響的元素：frame，frameset，noframes；
  • 如何支持HTML5新標籤：
    • IE8/IE7/IE6支持經過document.createElement方法產生的標籤，能夠利用這一特性讓這些瀏覽器支持HTML5新標籤，
    • 瀏覽器支持新標籤後，還須要添加標籤默認的樣式：
    • 固然最好的方式是直接使用成熟的框架、使用最多的是html5shim框架
      <!--[if lt IE 9]>
      <script> src="http://html5shim.googlecode.com/svn/trunk/html5.js"</script>
      <![endif]-->
  • 如何區分：
    • DOCTYPE聲明\新增的結構元素\功能元素

 二、HTML5的form如何關閉自動完成功能

給不想要提示的 form 或下某個input 設置爲 autocomplete=off。css

三、如何實現瀏覽器內多個標籤頁之間的通訊? 

調用localstorge、cookies等本地存儲方式html

四、iframe有那些缺點？

*iframe會阻塞主頁面的Onload事件； html5

*iframe和主頁面共享鏈接池，而瀏覽器對相同域的鏈接有限制，因此會影響頁面的並行加載。 使用iframe以前須要考慮這兩個缺點。若是須要使用iframe，最好是經過javascript 動態給iframe添加src屬性值，這樣能夠能夠繞開以上兩個問題。java

iframes 提供了一個簡單的方式把一個網站的內容嵌入到另外一個網站中。但咱們須要慎重的使用iframe。iframe的建立比其它包括scripts和css的 DOM 元素的建立慢了 1-2 個數量級。node

主要問題是：onload 事件以及鏈接池(connection pool)。web

  • 阻塞頁面加載
    • onload 事件告訴用戶當前網頁已經加載完畢。當 onload 事件加載延遲後，它給用戶的感受就是這個網頁很是慢。window 的 onload 事件須要在全部 iframe 加載完畢後(包含裏面的元素)纔會觸發。
    • 解決方案：在 Safari 和 Chrome 裏，經過 JavaScript 動態設置 iframe 的 SRC 能夠避免這種阻塞狀況。
  • 惟一的鏈接池
    • 瀏覽器只能開少許的鏈接到web服務器。比較老的瀏覽器，包含 Internet Explorer 6 & 7 和 Firefox 2，只能對一個域名(hostname)同時打開兩個鏈接。這個數量的限制在新版本的瀏覽器中有所提升。Safari 3+ 和 Opera 9+ 可同時對一個域名打開 4 個鏈接，Chrome 1+, IE 8 以及 Firefox 3 能夠同時打開 6 個（具體數據見瀏覽器能夠並行下載多少個資源）。
    • 絕大部分瀏覽器，主頁面和其中的 iframe 是共享這些鏈接的。這意味着 iframe 在加載資源時可能用光了全部的可用鏈接，從而阻塞了主頁面資源的加載。若是 iframe 中的內容比主頁面的內容更重要，這固然是很好的。但一般狀況下，iframe 裏的內容是沒有主頁面的內容重要的。這時 iframe 中用光了可用的鏈接就是不值得的了。
    • 一種解決辦法是，在主頁面上重要的元素加載完畢後，再動態設置 iframe 的 SRC。

 美國前 10 大網站都使用了 iframe。大部分狀況下，他們用它來加載廣告。ajax

http://www.williamlong.info/archives/3136.htmlcanvas

五、瀏覽器能夠並行下載多少個資源

 瀏覽器的併發請求數目限制是針對同一域名的。
意即，同一時間針對同一域名下的請求有必定數量限制。超過限制數目的請求會被阻塞瀏覽器

 具體不一樣瀏覽器這個限制的數目

 六、webSocket

 Websocket實際上是一個新協議，跟HTTP協議基本沒有關係，只是爲了兼容現有瀏覽器的握手規範而已，也就是說它是HTTP協議上的一種補充,有交集，可是並非所有。

6.1 Websocket是一個持久化的協議，相對於HTTP這種非持久的協議來講。

HTTP的生命週期經過Request來界定，也就是一個Request 一個Response，那麼在HTTP1.0中，此次HTTP請求就結束了。在HTTP1.1中進行了改進，使得有一個keep-alive，也就是說，在一個HTTP鏈接中，能夠發送多個Request，接收多個Response。可是請記住 Request = Response ， 在HTTP中永遠是這樣，也就是說一個request只能有一個response。並且這個response也是被動的，不能主動發起。

Websocket是基於HTTP協議的，或者說借用了HTTP的協議來完成一部分握手。在握手階段是同樣的。咱們來看個典型的Websocket握手

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade  // update connection告訴服務器我要發起websocket協議，是websocket的核心
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==   // sec-websocket-key是一個base64 encode的值，是瀏覽器隨機生成的，告訴服務器我要驗證是否是真的websocket助理
Sec-WebSocket-Protocol: chat, superchat  // 用戶定義的字符串，用來區分同URL下，不一樣的服務所須要的協議
Sec-WebSocket-Version: 13  // 告訴服務器所使用的websocket draft協議版本
Origin: http://example.com
而後服務器會返回下列東西，表示已經接受到請求， 成功創建Websocket啦！ 
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

 至此，HTTP已經完成它全部工做了，接下來就是徹底按照Websocket協議進行了。

6.2 long poll和ajax輪詢

在講Websocket以前，我就順帶着講下 long poll 和 ajax輪詢 的原理。
 6.2.1 ajax輪詢
首先是 ajax輪詢 ，ajax輪詢 的原理很是簡單，讓瀏覽器隔個幾秒就發送一次請求，詢問服務器是否有新信息。
場景再現：
客戶端：啦啦啦，有沒有新信息(Request)
服務端：沒有（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務端：沒有。。（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務端：你好煩啊，沒有啊。。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務端：好啦好啦，有啦給你。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務端：。。。。。沒。。。。沒。。。沒有（Response） ---- loop
6.2.2long poll
long poll 其實原理跟 ajax輪詢 差很少，都是採用輪詢的方式，不過採起的是阻塞模型（一直打電話，沒收到就不掛電話），也就是說，客戶端發起鏈接後，若是沒消息，就一直不返回Response給客戶端。直到有消息才返回，返回完以後，客戶端再次創建鏈接，周而復始。
場景再現
客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request）
服務端：額。。 等待到有消息的時候。。來 給你（Response）
客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request） -loop
6.2.3 小結

從上面能夠看出其實這兩種方式，都是在不斷地創建HTTP鏈接，而後等待服務端處理，能夠體現HTTP協議的另一個特色，被動性。何爲被動性呢，其實就是，服務端不能主動聯繫客戶端，只能有客戶端發起。簡單地說就是，服務器是一個很懶的冰箱（不會、不能主動發起鏈接），可是上司有命令，若是有客戶來，無論多麼累都要好好接待。

從上面很容易看出來，無論怎麼樣，上面這兩種都是很是消耗資源的。
ajax輪詢 須要服務器有很快的處理速度和資源。（速度）
long poll 須要有很高的併發，也就是說同時接待客戶的能力。（場地大小）
因此ajax輪詢 和long poll 都有可能發生這種狀況。

6.3 websocket

經過上面這個例子，咱們能夠看出，這兩種方式都不是最好的方式，須要不少資源。一種須要更快的速度，一種須要更多的'電話'。這兩種都會致使'電話'的需求愈來愈高。

HTTP仍是一個無狀態協議。通俗的說就是，服務器由於天天要接待太多客戶了，是個健忘鬼，你一掛電話，他就把你的東西全忘光了，把你的東西全丟掉了。你第二次還得再告訴服務器一遍。

因此在這種狀況下出現了，Websocket出現了。
他解決了HTTP的這幾個難題。
首先， 被動性，當服務器完成協議升級後（HTTP->Websocket），服務端就能夠主動推送信息給客戶端啦。
因此上面的情景能夠作以下修改。
客戶端：啦啦啦，我要創建Websocket協議，須要的服務：chat，Websocket協議版本：17（HTTP Request）
服務端：ok，確認，已升級爲Websocket協議（HTTP Protocols Switched）
客戶端：麻煩你有信息的時候推送給我噢。。
服務端：ok，有的時候會告訴你的。
服務端：balabalabalabala
服務端：balabalabalabala
服務端：哈哈哈哈哈啊哈哈哈哈
服務端：笑死我了哈哈哈哈哈哈哈

就變成了這樣，只須要通過 一次HTTP請求，就能夠作到源源不斷的信息傳送了。（在程序設計中，這種設計叫作回調，即：你有信息了再來通知我，而不是我傻乎乎的每次跑來問你）
這樣的協議解決了上面同步有延遲，並且還很是消耗資源的這種狀況。
 
那麼爲何他會解決服務器上消耗資源的問題呢？
其實咱們所用的程序是要通過兩層代理的，即 HTTP協議在Nginx等服務器的解析下，而後再傳送給相應的 Handler（PHP等）來處理。簡單地說，咱們有一個很是快速的接 線員（Nginx），他負責把問題轉交給相應的 客服（Handler）。自己 接線員基本上速度是足夠的，可是每次都卡在 客服（Handler）了，老有 客服處理速度太慢。，致使客服不夠。Websocket就解決了這樣一個難題，創建後，能夠直接跟接線員創建持 久鏈接，有信息的時候客服想辦法通知接線員，而後 接線員在統一轉交給客戶。這樣就能夠解決客服處理速度過慢的問題了。
 
同時，在傳統的方式上，要不斷的創建，關閉HTTP協議，因爲HTTP是非狀態性的，每次都要 從新傳輸identity info（鑑別信息），來告訴服務端你是誰。雖然接線員很快速，可是每次都要聽這麼一堆，效率也會有所降低的，同時還得不斷把這些信息轉交給客服，不但浪費客服的 處理時間，並且還會在網路傳輸中消耗 過多的流量/時間。可是Websocket只須要 一次HTTP握手，因此說整個通信過程是創建在一次鏈接/狀態中，也就避免了HTTP的非狀態性，服務端會一直知道你的信息，直到你關閉請求，這樣就解決了接線員要反覆解析HTTP協議，還要查看identity info的信息。同時由 客戶主動詢問，轉換爲 服務器（推送）有信息的時候就發送（固然客戶端仍是等主動發送信息過來的。。），沒有信息的時候就交給接線員（Nginx），不須要佔用自己速度就慢的 客服（Handler）了
--------------------
至於怎麼在不支持Websocket的客戶端上使用Websocket。。答案是： 不能
可是能夠經過上面說的 long poll 和 ajax 輪詢來 模擬出相似的效果
轉自： http://www.zhihu.com/question/20215561

6.4 使用方法

 1）在瀏覽器上使用websocket 以前要先判斷下瀏覽器是否支持websocket。

window.WebSocket = window.WebSocket || window.MozWebSocket;
if (!window.WebSocket){
    alert("WebSocket not supported by this browser");
    return;
}

 2) 接着就能夠建立一個Socket實例

var mySocket = new WebSocket(URL, [protocols]);

URL有兩種格式「ws://」與加密的「 wss://」，protocols是可選的子協議

var websocket = new WebSocket("ws://127.0.0.1:8080/alarm/alarmServer"); 

3) WebSocket事件 onopen, onmessage, onclose, onerror

鏈接打開時，回調onopen方法，接收到後臺消息時會觸發到onmessage事件，後臺關閉時調用onclose，出現鏈接異常時可在onerror中捕獲 
websocket.onmessage = function(evt){
    var data = evt.data;
}

 4) 方法 – send/close
發送消息 – WebSocket#send(data)
關閉鏈接 – WebSocket#close(optional code, optional reason)

websocket.send(JSON.stringify({action: "node.remove", id: "001"}));

 七、HTTP狀態碼

 狀態碼分爲5類：

100-199 用於指定客戶端相應的某些動做。 
200-299 用於表示請求成功。 
300-399 用於已經移動的文件而且常被包含在定位頭信息中指定新的地址信息。 
400-499 用於指出客戶端的錯誤。 
500-599 用於支持服務器錯誤。 

--------------------------------------------------

200 (OK/正常)
200 (SC_OK)的意思是一切正常。通常用於相應GET和POST請求。這個狀態碼對servlet是缺省的；若是沒有調用setStatus方法的話，就會獲得200。

202 (Accepted/接受)
202 (SC_ACCEPTED)告訴客戶端請求正在被執行，但尚未處理完。 

-------------------------------------------------

300 (Multiple Choices/多重選擇)
300 (SC_MULTIPLE_CHOICES)表示被請求的文檔能夠在多個地方找到，並將在返回的文檔中列出來。若是服務器有首選設置，首選項將會被列於定位響應頭信息中。 

301 (Moved Permanently永久移除)
301 (SC_MOVED_PERMANENTLY)請求的URL已移走。Response中應該包含一個Location URL, 說明資源如今所處的位置

302 (Found/找到)
與狀態碼301相似。但這裏的移除是臨時的。 客戶端會使用Location中給出的URL，從新發送新的HTTP request

304 Not Modified（未修改）客戶的緩存資源是最新的， 要客戶端使用緩存 

---------------------------------------------------

400（壞請求）

告訴客戶端，它發送了一個錯誤的請求。

401（未受權）

須要客戶端對本身認證

403（禁止）

請求被服務器拒絕了

404 Not Found 未找到資源

------------------------------------------------------

500（內部服務器錯誤）

501 Internal Server Error服務器遇到一個錯誤，使其沒法對請求提供服務

502（網關故障）

代理使用的服務器遇到了上游的無效響應

 http://kb.cnblogs.com/page/168720/

 

八、TCP的「三次握手」和「四次揮手」

「三次握手」：爲了準確無誤地把數據送達目標處，TCP協議採用了三次握手策略。用TCP協議把數據包送出去後，TCP不會對傳送 後的狀況置之不理，它必定會向對方確認是否成功送達。握手過程當中使用了TCP的標誌：SYN和ACK。

發送端首先發送一個帶SYN標誌的數據包給對方。接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。 最後，發送端再回傳一個帶ACK標誌的數據包，表明「握手」結束。 若在握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包。

 「四次揮手」：

  • 第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不 會再給你發數據了(固然，在fin包以前發送出去的數據，若是沒有收到對應的ack確認報文，主動關閉方依然會重發這些數據)，可是，此時主動關閉方還可 以接受數據。

  • 第二次揮手：被動關閉方收到FIN包後，發送一個ACK給對方，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號）。

  • 第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，個人數據也發送完了，不會再給你發數據了。

  • 第四次揮手：主動關閉方收到FIN後，發送一個ACK給被動關閉方，確認序號爲收到序號+1，至此，完成四次揮手。

 

九、TCP和UDP的區別

TCP（Transmission Control Protocol，傳輸控制協議）是基於鏈接的協議，也就是說，在正式收發數據前，必須和對方創建可靠的鏈接。一個TCP鏈接必需要通過三次「對話」才能創建起來

UDP（User Data Protocol，用戶數據報協議）是與TCP相對應的協議。它是面向非鏈接的協議，它不與對方創建鏈接，而是直接就把數據包發送過去！ UDP適用於一次只傳送少許數據、對可靠性要求不高的應用環境。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程