整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
參考回答：
https 的 SSL 加密是在傳輸層實(shí)現(xiàn)的。
(1)http 和 https 的基本概念
http: 超文本傳輸協(xié)議， 是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議， 是一個(gè)客戶端和服 務(wù)器端請(qǐng)求和應(yīng)答的標(biāo)準(zhǔn) (TCP) ， 用于從 WWW 服務(wù)器傳輸超文本到本地瀏覽器的傳 輸協(xié)議， 它可以使瀏覽器更加高效， 使網(wǎng)絡(luò)傳輸減少。
https: 是以安全為目標(biāo)的 HTTP 通道， 簡(jiǎn)單講是 HTTP 的安全版， 即 HTTP 下加入 SSL 層， HTTPS 的安全基礎(chǔ)是 SSL， 因此加密的詳細(xì)內(nèi)容就需要 SSL。
https 協(xié)議的主要作用是：建立一個(gè)信息安全通道，來(lái)確保數(shù)組的傳輸，確保網(wǎng)站的真實(shí) 性。
(2)http 和 https 的區(qū)別？
http 傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的， 網(wǎng)景公司設(shè)置了 SSL 協(xié)議來(lái)對(duì) http 協(xié)議 傳輸?shù)臄?shù)據(jù)進(jìn)行加密處理，簡(jiǎn)單來(lái)說(shuō) https 協(xié)議是由 http 和 ssl 協(xié)議構(gòu)建的可進(jìn)行加密傳 輸和身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 比 http 協(xié)議的安全性更高。
主要的區(qū)別如下：
Https 協(xié)議需要 ca 證書， 費(fèi)用較高。
http 是超文本傳輸協(xié)議， 信息是明文傳輸， https 則是具有安全性的 ssl 加密傳輸協(xié)議。 使用不同的鏈接方式， 端口也不同， 一般而言， http 協(xié)議的端口為 80， https 的端口為443。
http 的連接很簡(jiǎn)單，是無(wú)狀態(tài)的；HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳 輸 、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 比 http 協(xié)議安全。
(3)https 協(xié)議的工作原理
客戶端在使用 HTTPS 方式與 Web 服務(wù)器通信時(shí)有以下幾個(gè)步驟， 如圖所示。 客戶使用 https url 訪問(wèn)服務(wù)器， 則要求web 服務(wù)器建立 ssl 鏈接。
web 服務(wù)器接收到客戶端的請(qǐng)求之后， 會(huì)將網(wǎng)站的證書 (證書中包含了公鑰) ， 返回或 者說(shuō)傳輸給客戶端。
客戶端和 web 服務(wù)器端開(kāi)始協(xié)商 SSL 鏈接的安全等級(jí)， 也就是加密等級(jí)。
客戶端瀏覽器通過(guò)雙方協(xié)商一致的安全等級(jí)，建立會(huì)話密鑰，然后通過(guò)網(wǎng)站的公鑰來(lái)加 密會(huì)話密鑰， 并傳送給網(wǎng)站。
web 服務(wù)器通過(guò)自己的私鑰解密出會(huì)話密鑰。
web 服務(wù)器通過(guò)會(huì)話密鑰加密與客戶端之間的通信。
(4)https 協(xié)議的優(yōu)點(diǎn)
使用HTTPS 協(xié)議可認(rèn)證用戶和服務(wù)器， 確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；
HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸 、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 要比 http 協(xié)議安全， 可防止數(shù)據(jù)在傳輸過(guò)程中不被竊取 、改變， 確保數(shù)據(jù)的完整性 。 HTTPS 是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對(duì)安全，但它大幅增加了中間人攻 擊的成本。
谷歌曾在 2014 年 8 月份調(diào)整搜索引擎算法， 并稱“比起同等 HTTP 網(wǎng)站， 采用 HTTPS 加密的網(wǎng)站在搜索結(jié)果中的排名將會(huì)更高”。
(5)https 協(xié)議的缺點(diǎn)
https 握手階段比較費(fèi)時(shí)， 會(huì)使頁(yè)面加載時(shí)間延長(zhǎng) 50%， 增加 10%~20%的耗電。
https 緩存不如 http 高效， 會(huì)增加數(shù)據(jù)開(kāi)銷。
SSL 證書也需要錢， 功能越強(qiáng)大的證書費(fèi)用越高。
SSL 證書需要綁定 IP， 不能再同一個(gè) ip 上綁定多個(gè)域名， ipv4 資源支持不了這種消耗。
參考回答：
客戶端和服務(wù)端都需要直到各自可收發(fā)， 因此需要三次握手。
簡(jiǎn)化三次握手：
<img width="487" alt="2018-07-10 3 42 11" src="https://user-images.githubusercontent.com/ 17233651/42496289-1c6d668a-8458-11e8-98b3-65db50f64d48.png">從圖片可以得到三次握手可以簡(jiǎn)化為：C 發(fā)起請(qǐng)求連接 S 確認(rèn)，也發(fā)起連接 C 確認(rèn)我們 再看看每次握手的作用： 第一次握手： S 只可以確認(rèn) 自己可以接受 C 發(fā)送的報(bào)文段第 二次握手： C 可以確認(rèn) S 收到了自己發(fā)送的報(bào)文段， 并且可以確認(rèn) 自己可以接受 S 發(fā) 送的報(bào)文段第三次握手： S 可以確認(rèn) C 收到了自己發(fā)送的報(bào)文段。
參考回答：
( 1) TCP 是面向連接的， udp 是無(wú)連接的即發(fā)送數(shù)據(jù)前不需要先建立鏈接。
( 2) TCP 提供可靠的服務(wù) 。也就是說(shuō)， 通過(guò) TCP 連接傳送的數(shù)據(jù)， 無(wú)差錯(cuò)， 不丟失， 不重復(fù)， 且按序到達(dá);UDP 盡最大努力交付， 即不保證可靠交付 。 并且因?yàn)?tcp 可靠， 面向連接， 不會(huì)丟失數(shù)據(jù)因此適合大數(shù)據(jù)量的交換。
( 3) TCP 是面向字節(jié)流，UDP 面向報(bào)文，并且網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使得發(fā)送速率降低 (因 此會(huì)出現(xiàn)丟包， 對(duì)實(shí)時(shí)的應(yīng)用比如 IP 電話和視頻會(huì)議等) 。
( 4) TCP 只能是 1 對(duì) 1 的， UDP 支持 1 對(duì) 1,1 對(duì)多。
( 5) TCP 的首部較大為 20 字節(jié)， 而 UDP 只有 8 字節(jié)。
( 6) TCP 是面向連接的可靠性傳輸， 而 UDP 是不可靠的。
參考回答：
(1)什么是 WebSocket?
WebSocket 是 HTML5 中的協(xié)議， 支持持久連續(xù)， http 協(xié)議不支持持久性連接 。Http1.0 和 HTTP1.1 都不支持持久性的鏈接， HTTP1.1 中的 keep-alive， 將多個(gè) http 請(qǐng)求合并為 1 個(gè)
(2)WebSocket 是什么樣的協(xié)議， 具體有什么優(yōu)點(diǎn)？
HTTP 的生命周期通過(guò) Request 來(lái)界定， 也就是 Request 一個(gè) Response， 那么在 Http1.0 協(xié)議中， 這次 Http 請(qǐng)求就結(jié)束了 。在 Http1.1 中進(jìn)行了改進(jìn)， 是的有一個(gè) connection： Keep-alive，也就是說(shuō)，在一個(gè) Http 連接中，可以發(fā)送多個(gè) Request，接收多個(gè) Response。 但是必須記住， 在 Http 中一個(gè) Request 只能對(duì)應(yīng)有一個(gè) Response， 而且這個(gè) Response 是被動(dòng)的， 不能主動(dòng)發(fā)起。
WebSocket 是基于 Http 協(xié)議的，或者說(shuō)借用了 Http 協(xié)議來(lái)完成一部分握手，在握手階段 與 Http 是相同的。我們來(lái)看一個(gè) websocket 握手協(xié)議的實(shí)現(xiàn)，基本是 2 個(gè)屬性，upgrade， connection。
基本請(qǐng)求如下：
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
多了下面 2 個(gè)屬性：
Upgrade:webSocket
Connection:Upgrade告訴服務(wù)器發(fā)送的是websocket
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13參考回答：
head： 類似于 get 請(qǐng)求， 只不過(guò)返回的響應(yīng)中沒(méi)有具體的內(nèi)容， 用戶獲取報(bào)頭 options： 允許客戶端查看服務(wù)器的性能， 比如說(shuō)服務(wù)器支持的請(qǐng)求方式等等。
參考回答：
請(qǐng)求的返回頭里面， 用于瀏覽器解析的重要參數(shù)就是 OSS 的 API 文檔里面的返回http 頭， 決定用戶下載行為的參數(shù)。
下載的情況下：
x-oss-object-type: Normal
x-oss-request-id: 598D5ED34F29D01FE2925F41
x-oss-storage-class: Standard參考回答：
能夠被殘障人士使用的網(wǎng)站才能稱得上一個(gè)易用的 (易訪問(wèn)的) 網(wǎng)站。 殘障人士指的是那些帶有殘疾或者身體不健康的用戶。
使用 alt 屬性：
<img src="person.jpg" alt="this is a person"/>有時(shí)候?yàn)g覽器會(huì)無(wú)法顯示圖像 。具體的原因有：
用戶關(guān)閉了圖像顯示
瀏覽器是不支持圖形顯示的迷你瀏覽器
瀏覽器是語(yǔ)音瀏覽器 (供盲人和弱視人群使用)
如果您使用了alt 屬性， 那么瀏覽器至少可以顯示或讀出有關(guān)圖像的描述。
參考回答：
什么是 Bom? Bom 是瀏覽器對(duì)象 。有哪些常用的 Bom 屬性呢？
(1)location 對(duì)象
location.href-- 返回或設(shè)置當(dāng)前文檔的 URL
location.search -- 返回 URL 中的查詢字符串部分 。 例
如 http://www.dreamdu.com/dreamdu.php?id=5&name=dreamdu 返回包括(?)后面的內(nèi) 容?id=5&name=dreamdu
location.hash -- 返回 URL#后面的內(nèi)容， 如果沒(méi)有#， 返回空
location.host -- 返回 URL 中的域名部分， 例如 www.dreamdu.com
location.hostname -- 返回 URL 中的主域名部分， 例如 dreamdu.com
location.pathname -- 返回 URL 的域名后的部分 。例如 http://www.dreamdu.com/xhtml/ 返 回/xhtml/
location.port -- 返回 URL 中的端口部分 。 例如 http://www.dreamdu.com:8080/xhtml/ 返回8080
location.protocol -- 返回 URL 中的協(xié)議部分。例如 http://www.dreamdu.com:8080/xhtml/ 返 回(//)前面的內(nèi)容 http:
location.assign -- 設(shè)置當(dāng)前文檔的 URL
location.replace() -- 設(shè)置當(dāng)前文檔的 URL， 并且在 history 對(duì)象的地址列表中移除這個(gè) URL location.replace(url);
location.reload() -- 重載當(dāng)前頁(yè)面
(2)history 對(duì)象
history.go() -- 前進(jìn)或后退指定的頁(yè)面數(shù) history.go(num);
history.back() -- 后退一頁(yè)
history.forward() -- 前進(jìn)一頁(yè)
(3)Navigator 對(duì)象
navigator.userAgent -- 返回用戶代理頭的字符串表示(就是包括瀏覽器版本信息等的字 符串)。
navigator.cookieEnabled -- 返回瀏覽器是否支持(啟用)cookie。
參考回答：
dragstart： 事件主體是被拖放元素， 在開(kāi)始拖放被拖放元素時(shí)觸發(fā)， 。
darg： 事件主體是被拖放元素， 在正在拖放被拖放元素時(shí)觸發(fā)。
dragenter： 事件主體是目標(biāo)元素， 在被拖放元素進(jìn)入某元素時(shí)觸發(fā)。
dragover： 事件主體是目標(biāo)元素， 在被拖放在某元素內(nèi)移動(dòng)時(shí)觸發(fā)。
dragleave： 事件主體是目標(biāo)元素， 在被拖放元素移出目標(biāo)元素是觸發(fā)。
drop： 事件主體是目標(biāo)元素， 在目標(biāo)元素完全接受被拖放元素時(shí)觸發(fā)。
dragend： 事件主體是被拖放元素， 在整個(gè)拖放操作結(jié)束時(shí)觸發(fā)。
參考回答：
首先補(bǔ)充一下， http 和 https 的區(qū)別， 相比于 http,https 是基于 ssl 加密的 http 協(xié)議
簡(jiǎn)要概括： http2.0 是基于 1999 年發(fā)布的 http1.0 之后的首次更新。
提升訪問(wèn)速度 (可以對(duì)于， 請(qǐng)求資源所需時(shí)間更少， 訪問(wèn)速度更快， 相比 http1.0)
允許多路復(fù)用：多路復(fù)用允許同時(shí)通過(guò)單一的 HTTP/2 連接發(fā)送多重請(qǐng)求-響應(yīng)信息。改 善了： 在 http1.1 中， 瀏覽器客戶端在同一時(shí)間， 針對(duì)同一域名下的請(qǐng)求有一定數(shù)量限 制 (連接數(shù)量) ， 超過(guò)限制會(huì)被阻塞。
二進(jìn)制分幀：HTTP2.0 會(huì)將所有的傳輸信息分割為更小的信息或者幀，并對(duì)他們進(jìn)行二 進(jìn)制編碼、首部壓縮、服務(wù)器端推送。
參考回答：
(1)400 狀態(tài)碼： 請(qǐng)求無(wú)效
產(chǎn)生原因：
前端提交數(shù)據(jù)的字段名稱和字段類型與后臺(tái)的實(shí)體沒(méi)有保持一致。
前端提交到后臺(tái)的數(shù)據(jù)應(yīng)該是 json 字符串類型， 但是前端沒(méi)有將對(duì)象 JSON.stringify 轉(zhuǎn)化成字符串。
解決方法：
對(duì)照字段的名稱， 保持一致性，將 obj 對(duì)象通過(guò) JSON.stringify 實(shí)現(xiàn)序列化。
(2)401 狀態(tài)碼： 當(dāng)前請(qǐng)求需要用戶驗(yàn)證
(3)403 狀態(tài)碼： 服務(wù)器已經(jīng)得到請(qǐng)求， 但是拒絕執(zhí)行
參考回答：
fetch 發(fā)送 post 請(qǐng)求的時(shí)候， 總是發(fā)送 2 次， 第一次狀態(tài)碼是 204， 第二次才成功？
原因很簡(jiǎn)單， 因?yàn)槟阌?fetch 的 post 請(qǐng)求的時(shí)候， 導(dǎo)致 fetch 第一次發(fā)送了一個(gè) Options 請(qǐng)求，詢問(wèn)服務(wù)器是否支持修改的請(qǐng)求頭，如果服務(wù)器支持，則在第二次中發(fā)送真正的 請(qǐng)求。
參考回答：
在 HTML 頁(yè)面中，如果在執(zhí)行腳本時(shí)，頁(yè)面的狀態(tài)是不可相應(yīng)的，直到腳本執(zhí)行完成后， 頁(yè)面才變成可相應(yīng) 。web worker 是運(yùn)行在后臺(tái)的 js， 獨(dú)立于其他腳本， 不會(huì)影響頁(yè)面你 的性能 。并且通過(guò) postMessage 將結(jié)果回傳到主線程 。這樣在進(jìn)行復(fù)雜操作的時(shí)候， 就 不會(huì)阻塞主線程了。
如何創(chuàng)建 web worker：
檢測(cè)瀏覽器對(duì)于 web worker 的支持性
創(chuàng)建 web worker 文件 (js， 回傳函數(shù)等)
創(chuàng)建 web worker 對(duì)象
參考回答：
HTML5 語(yǔ)義化標(biāo)簽是指正確的標(biāo)簽包含了正確的內(nèi)容，結(jié)構(gòu)良好，便于閱讀， 比如nav 表示導(dǎo)航條， 類似的還有 article 、header 、footer 等等標(biāo)簽。
參考回答：
定義： iframe 元素會(huì)創(chuàng)建包含另一個(gè)文檔的內(nèi)聯(lián)框架
提示： 可以將提示文字放在<iframe></iframe>之間， 來(lái)提示某些不支持 iframe 的瀏覽器 缺點(diǎn)： 會(huì)阻塞主頁(yè)面的 onload 事件 搜索引擎無(wú)法解讀這種頁(yè)面， 不利于 SEO iframe 和主頁(yè)面共享連接池， 而瀏覽器對(duì)相同區(qū)域有限制所以會(huì)影響性能。
參考回答：
Doctype 聲明于文檔最前面， 告訴瀏覽器以何種方式來(lái)渲染頁(yè)面， 這里有兩種模式， 嚴(yán) 格模式和混雜模式。
嚴(yán)格模式的排版和 JS 運(yùn)作模式是 以該瀏覽器支持的最高標(biāo)準(zhǔn)運(yùn)行。
混雜模式， 向后兼容， 模擬老式瀏覽器， 防止瀏覽器無(wú)法兼容頁(yè)面。
參考回答：
XSS (跨站腳本攻擊) 是指攻擊者在返回的 HTML 中嵌入 javascript 腳本，為了減輕這些 攻擊， 需要在 HTTP 頭部配上， set-cookie：
httponly-這個(gè)屬性可以防止 XSS,它會(huì)禁止 javascript 腳本來(lái)訪問(wèn) cookie。
secure - 這個(gè)屬性告訴瀏覽器僅在請(qǐng)求為 https 的時(shí)候發(fā)送 cookie。
結(jié)果應(yīng)該是這樣的： Set-Cookie=<cookie-value>.....
參考回答：
就是用URL 定位資源， 用 HTTP 描述操作。
參考回答：
可以參考這篇文章：
響應(yīng)式布局的常用解決方案對(duì)比(媒體查詢、百分比、rem 和 vw/vh)
參考回答：
(1)粗暴型， 禁用縮放
<meta name="viewport" content="width=device-width, user-scalable=no">(2)利用 FastClick， 其原理是：
檢測(cè)到 touchend 事件后， 立刻出發(fā)模擬 click 事件， 并且把瀏覽器 300 毫秒之后真正出 發(fā)的事件給阻斷掉。
參考回答：
addEventListener(event, function, useCapture)其中， event 指定事件名； function 指定要事件觸發(fā)時(shí)執(zhí)行的函數(shù)； useCapture 指定事件 是否在捕獲或冒泡階段執(zhí)行。
參考回答：
100 Continue 繼續(xù) 。客戶端應(yīng)繼續(xù)其請(qǐng)求。
101 Switching Protocols 切換協(xié)議。服務(wù)器根據(jù)客戶端的請(qǐng)求切換協(xié)議。只能切換到更 高級(jí)的協(xié)議， 例如， 切換到HTTP 的新版本協(xié)議。
200 OK 請(qǐng)求成功 。一般用于 GET 與 POST 請(qǐng)求。
201 Created 已創(chuàng)建 。成功請(qǐng)求并創(chuàng)建了新的資源。
202 Accepted 已接受 。 已經(jīng)接受請(qǐng)求， 但未處理完成。
203 Non-Authoritative Information 非授權(quán)信息。請(qǐng)求成功。但返回的 meta 信息不在原 始的服務(wù)器， 而是一個(gè)副本。
204 No Content 無(wú)內(nèi)容 。服務(wù)器成功處理， 但未返回內(nèi)容 。在未更新網(wǎng)頁(yè)的情況下， 可確保瀏覽器繼續(xù)顯示當(dāng)前文檔。
205 Reset Content 重置內(nèi)容。服務(wù)器處理成功， 用戶終端 (例如： 瀏覽器) 應(yīng)重置文 檔視圖 。可通過(guò)此返回碼清除瀏覽器的表單域。
206 Partial Content 部分內(nèi)容 。服務(wù)器成功處理了部分 GET 請(qǐng)求。
300 Multiple Choices 多種選擇。請(qǐng)求的資源可包括多個(gè)位置，相應(yīng)可返回一個(gè)資源特 征與地址的列表用于用戶終端 (例如： 瀏覽器) 選擇。
301 Moved Permanently 永久移動(dòng)。請(qǐng)求的資源已被永久的移動(dòng)到新 URI，返回信息會(huì) 包括新的 URI，瀏覽器會(huì)自動(dòng)定向到新 URI。今后任何新的請(qǐng)求都應(yīng)使用新的 URI 代替。
302 Found 臨時(shí)移動(dòng)。與 301 類似。但資源只是臨時(shí)被移動(dòng)。客戶端應(yīng)繼續(xù)使用原有 URI。
303 See Other 查看其它地址 。與 301 類似 。使用 GET 和 POST 請(qǐng)求查看。
304 Not Modified 未修改 。所請(qǐng)求的資源未修改， 服務(wù)器返回此狀態(tài)碼時(shí)， 不會(huì)返回 任何資源。客戶端通常會(huì)緩存訪問(wèn)過(guò)的資源，通過(guò)提供一個(gè)頭信息指出客戶端希望只返 回在指定日期之后修改的資源。
305 Use Proxy 使用代理 。所請(qǐng)求的資源必須通過(guò)代理訪問(wèn)。
306 Unused 已經(jīng)被廢棄的 HTTP 狀態(tài)碼。
307 Temporary Redirect 臨時(shí)重定向 。與 302 類似 。使用 GET 請(qǐng)求重定向。
400 Bad Request 客戶端請(qǐng)求的語(yǔ)法錯(cuò)誤， 服務(wù)器無(wú)法理解。
401 Unauthorized 請(qǐng)求要求用戶的身份認(rèn)證。
402 Payment Required 保留， 將來(lái)使用。
403 Forbidden 服務(wù)器理解請(qǐng)求客戶端的請(qǐng)求， 但是拒絕執(zhí)行此請(qǐng)求。
404 Not Found 服務(wù)器無(wú)法根據(jù)客戶端的請(qǐng)求找到資源 (網(wǎng)頁(yè)) 。通過(guò)此代碼， 網(wǎng)站 設(shè)計(jì)人員可設(shè)置"您所請(qǐng)求的資源無(wú)法找到"的個(gè)性頁(yè)面。
405 Method Not Allowed 客戶端請(qǐng)求中的方法被禁止。
406 Not Acceptable 服務(wù)器無(wú)法根據(jù)客戶端請(qǐng)求的內(nèi)容特性完成請(qǐng)求。
407 Proxy Authentication Required 請(qǐng)求要求代理的身份認(rèn)證， 與 401 類似， 但請(qǐng)求者 應(yīng)當(dāng)使用代理進(jìn)行授權(quán)。
408 Request Time-out 服務(wù)器等待客戶端發(fā)送的請(qǐng)求時(shí)間過(guò)長(zhǎng)， 超時(shí)。
409 Conflict 服務(wù)器完成客戶端的 PUT 請(qǐng)求是可能返回此代碼，服務(wù)器處理請(qǐng)求時(shí)發(fā) 生了沖突。
410 Gone 客戶端請(qǐng)求的資源已經(jīng)不存在。410 不同于 404，如果資源以前有現(xiàn)在被永 久刪除了可使用410 代碼， 網(wǎng)站設(shè)計(jì)人員可通過(guò) 301 代碼指定資源的新位置。
411 Length Required 服務(wù)器無(wú)法處理客戶端發(fā)送的不帶 Content-Length 的請(qǐng)求信息。
412 Precondition Failed 客戶端請(qǐng)求信息的先決條件錯(cuò)誤。
413 Request Entity Too Large 由于請(qǐng)求的實(shí)體過(guò)大，服務(wù)器無(wú)法處理， 因此拒絕請(qǐng)求。 為防止客戶端的連續(xù)請(qǐng)求，服務(wù)器可能會(huì)關(guān)閉連接。如果只是服務(wù)器暫時(shí)無(wú)法處理，則 會(huì)包含一個(gè) Retry-After 的響應(yīng)信息。
414 Request-URI Too Large 請(qǐng)求的 URI 過(guò)長(zhǎng) ( URI 通常為網(wǎng)址) ， 服務(wù)器無(wú)法處理。
415 Unsupported Media Type 服務(wù)器無(wú)法處理請(qǐng)求附帶的媒體格式。
416 Requested range not satisfiable 客戶端請(qǐng)求的范圍無(wú)效。
417 Expectation Failed 服務(wù)器無(wú)法滿足 Expect 的請(qǐng)求頭信息。
500 Internal Server Error 服務(wù)器內(nèi)部錯(cuò)誤， 無(wú)法完成請(qǐng)求。
501 Not Implemented 服務(wù)器不支持請(qǐng)求的功能， 無(wú)法完成請(qǐng)求。
502 Bad Gateway 作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)， 從遠(yuǎn)程服務(wù)器接 收到了一個(gè)無(wú)效的響應(yīng)。
503 Service Unavailable 由于超載或系統(tǒng)維護(hù)，服務(wù)器暫時(shí)的無(wú)法處理客戶端的請(qǐng)求。 延時(shí)的長(zhǎng)度可包含在服務(wù)器的 Retry-After 頭信息中。
504 Gateway Time-out 充當(dāng)網(wǎng)關(guān)或代理的服務(wù)器， 未及時(shí)從遠(yuǎn)端服務(wù)器獲取請(qǐng)求。
505 HTTP Version not supported 服務(wù)器不支持請(qǐng)求的 HTTP 協(xié)議的版本， 無(wú)法完成處 理。
參考回答：
協(xié)議頭 | 說(shuō)明 |
Accept | 可接受的響應(yīng)內(nèi)容類型 (Content-Types) 。 |
Accept-Charset | 可接受的字符集。 |
Accept-Encoding | 可接受的響應(yīng)內(nèi)容的編碼方式。 |
Accept-Language | 可接受的響應(yīng)內(nèi)容語(yǔ)言列表。 |
Accept-Datetime | 可接受的按照時(shí)間來(lái)表示的響應(yīng)內(nèi)容版本。 |
Authorization | 用于表示 HTTP 協(xié)議中需要認(rèn)證資源的認(rèn)證信息。 |
Cache-Control | 用來(lái)指定當(dāng)前的請(qǐng)求/回復(fù)中的， 是否使用緩存機(jī)制。 |
Connection | 客戶端 (瀏覽器) 想要優(yōu)先使用的連接類型。 |
Cookie | 由之前服務(wù)器通過(guò) Set-Cookie(見(jiàn)下文)設(shè)置的一個(gè) HTTP 協(xié)議 Cookie。 |
Content-Length | 以 8 進(jìn)制表示的請(qǐng)求體的長(zhǎng)度。 |
Content-MD5 | 請(qǐng)求體的內(nèi)容的二進(jìn)制 MD5 散列值 (數(shù)字簽名) ， 以 Base64 編碼的結(jié)果。 |
Content-Type | 請(qǐng)求體的 MIME 類型 (用于 POST 和 PUT 請(qǐng)求中)。 |
Date | 發(fā)送該消息的日期和時(shí)間 (以RFC 7231中定義的"HTTP 日期"格式 來(lái)發(fā)送)。 |
Expect | 表示客戶端要求服務(wù)器做出特定的行為。 |
From | 發(fā)起此請(qǐng)求的用戶的郵件地址。 |
Host | 表示服務(wù)器的域名以及服務(wù)器所監(jiān)聽(tīng)的端口號(hào) 。如果所請(qǐng)求的端口 是對(duì)應(yīng)的服務(wù)的標(biāo)準(zhǔn)端口 ( 80) ， 則端口號(hào)可以省略。 |
If-Match | 僅當(dāng)客戶端提供的實(shí)體與服務(wù)器上對(duì)應(yīng)的實(shí)體相匹配時(shí)， 才進(jìn)行對(duì)應(yīng)的操作 。主要用于像 PUT 這樣的方法中， 僅當(dāng)從用戶上次更新 某個(gè)資源后， 該資源未被修改的情況下， 才更新該資源。 |
If-Modified-Since | 允許在對(duì)應(yīng)的資源未被修改的情況下返回304 未修改 |
If-None-Match | 允許在對(duì)應(yīng)的內(nèi)容未被修改的情況下返回304 未修改 ( 304 Not Modified ) ， 參考 超文本傳輸協(xié)議 的實(shí)體標(biāo)記 |
If-Range | 如果該實(shí)體未被修改過(guò)， 則向返回所缺少的那一個(gè)或多個(gè)部分 。否 則， 返回整個(gè)新的實(shí)體。 |
If-Unmodified-Since | 僅當(dāng)該實(shí)體自某個(gè)特定時(shí)間以來(lái)未被修改的情況下， 才發(fā)送回應(yīng)。 |
Max-Forwards | 限制該消息可被代理及網(wǎng)關(guān)轉(zhuǎn)發(fā)的次數(shù)。 |
Origin | 發(fā)起一個(gè)針對(duì)跨域資源共享的請(qǐng)求 (該請(qǐng)求要求服務(wù)器在響應(yīng)中加入一個(gè) Access-Control-Allow-Origin 的消息頭，表示訪問(wèn)控制所允許 的來(lái)源) 。 |
Pragma | 與具體的實(shí)現(xiàn)相關(guān)， 這些字段可能在請(qǐng)求/回應(yīng)鏈中的任何時(shí)候產(chǎn) 生。 |
Proxy-Authorization | 用于向代理進(jìn)行認(rèn)證的認(rèn)證信息。 |
Range | 表示請(qǐng)求某個(gè)實(shí)體的一部分， 字節(jié)偏移以 0 開(kāi)始。 |
Referer | 表示瀏覽器所訪問(wèn)的前一個(gè)頁(yè)面， 可以認(rèn)為是之前訪問(wèn)頁(yè)面的鏈接將瀏覽器帶到了當(dāng)前頁(yè)面。Referer 其實(shí)是 Referrer 這個(gè)單詞，但 RFC 制作標(biāo)準(zhǔn)時(shí)給拼錯(cuò)了， 后來(lái)也就將錯(cuò)就錯(cuò)使用 Referer 了。 |
TE | 瀏覽器預(yù)期接受的傳輸時(shí)的編碼方式： 可使用回應(yīng)協(xié)議頭 Transfer-Encoding 中的值 (還可以使用"trailers"表示數(shù)據(jù)傳輸時(shí)的分 塊方式) 用來(lái)表示瀏覽器希望在最后一個(gè)大小為 0 的塊之后還接收到一些額外的字段。 |
User-Agent | 瀏覽器的身份標(biāo)識(shí)字符串。 |
Upgrade | 要求服務(wù)器升級(jí)到一個(gè)高版本協(xié)議。 |
Via | 告訴服務(wù)器， 這個(gè)請(qǐng)求是由哪些代理發(fā)出的。 |
Warning | 一個(gè)一般性的警告， 表示在實(shí)體內(nèi)容體中可能存在錯(cuò)誤。 |
參考回答：
緩存分為兩種： 強(qiáng)緩存和協(xié)商緩存， 根據(jù)響應(yīng)的header 內(nèi)容來(lái)決定。
獲取資源形式 | 狀態(tài)碼 | 發(fā)送請(qǐng)求到服務(wù)器 | |
強(qiáng)緩存 | 從緩存取 | 200 (from cache) | 否， 直接從緩存取 |
協(xié)商緩存 | 從緩存取 | 304 (not modified) | 是，通過(guò)服務(wù)器來(lái)告知緩存是否可 用 |
強(qiáng)緩存相關(guān)字段有 expires， cache-control 。如果 cache-control 與 expires 同時(shí)存在的話， cache-control 的優(yōu)先級(jí)高于 expires。
協(xié)商緩存相關(guān)字段有 Last-Modified/If-Modified-Since， Etag/If-None-Match。
參考回答：
304：如果客戶端發(fā)送了一個(gè)帶條件的 GET 請(qǐng)求且該請(qǐng)求已被允許，而文檔的內(nèi)容 (自 上次訪問(wèn)以來(lái)或者根據(jù)請(qǐng)求的條件) 并沒(méi)有改變， 則服務(wù)器應(yīng)當(dāng)返回這個(gè) 304 狀態(tài)碼。
參考回答：
因?yàn)榉?wù)器上的資源不是一直固定不變的，大多數(shù)情況下它會(huì)更新，這個(gè)時(shí)候如果我們 還訪問(wèn)本地緩存，那么對(duì)用戶來(lái)說(shuō)，那就相當(dāng)于資源沒(méi)有更新，用戶看到的還是舊的資 源；所以我們希望服務(wù)器上的資源更新了瀏覽器就請(qǐng)求新的資源，沒(méi)有更新就使用本地 的緩存， 以最大程度的減少因網(wǎng)絡(luò)請(qǐng)求而產(chǎn)生的資源浪費(fèi)。
參考 https://segmentfault.com/a/1190000008956069
參考回答：
降低請(qǐng)求量： 合并資源， 減少 HTTP 請(qǐng)求數(shù)， minify / gzip 壓縮， webP， lazyLoad。
加快請(qǐng)求速度： 預(yù)解析 DNS， 減少域名數(shù)， 并行加載， CDN 分發(fā)。
緩存： HTTP 協(xié)議緩存請(qǐng)求， 離線緩存 manifest， 離線數(shù)據(jù)緩存 localStorage。
渲染： JS/CSS 優(yōu)化， 加載順序， 服務(wù)端渲染， pipeline。
TML 中使用 <input> 元素表示單行輸入框和 <textarea> 元素表示多行文本框。
HTML中使用的 <input> 元素在 JavaScript 中對(duì)應(yīng)的是 HTMLInputElement 類型。HTMLInputElement 繼承自 HTMLElement 接口：
interface HTMLInputElement extends HTMLElement {
...
}HTMLInputElement 類型有一些獨(dú)有的屬性和方法：
而在上述介紹 HTMLInputElement 類型中的屬性時(shí)，type 屬性要特別關(guān)注一下，因?yàn)楦鶕?jù) type 屬性的改變，可以改變<input>的屬性。
類型 | 描述 |
text | 文本輸入 |
password | 密碼輸入 |
submit | 表單數(shù)據(jù)提交 |
button | 按鈕 |
radio | 單選框 |
checkbox | 復(fù)選框 |
file | 文件 |
hidden | 隱藏的字段 |
image | 定義圖像作為提交按鈕 |
reset | 重置按鈕 |
省略 type 屬性與 type="text"效果一樣， <input> 元素顯示為文本框。
當(dāng) type 的值為text/password/number/時(shí)，會(huì)有以下屬性對(duì) <input> 元素有效。
屬性 | 類型 | 描述 |
autocomplete | string | 字符串on或off，表示<input>元素的輸入內(nèi)容可以被瀏覽器自動(dòng)補(bǔ)全。 |
maxLength | long | 指定<input>元素允許的最多字符數(shù)。 |
size | unsigned long | 表示<input>元素的寬度，這個(gè)寬度是以字符數(shù)來(lái)計(jì)量的。 |
pattern | string | 表示<input>元素的值應(yīng)該滿足的正則表達(dá)式 |
placeholder | string | 表示<input>元素的占位符，作為對(duì)元素的提示。 |
readOnly | boolean | 表示用戶是否可以修改<input>的值。 |
min | string | 表示<input>元素的最小數(shù)值或日期。 |
max | string | 表示<input>元素的最大數(shù)值或日期。 |
selectionStart | unsigned long | 表示選中文本的起始位置。如果沒(méi)有選中文本，返回光標(biāo)在<input>元素內(nèi)部的位置。 |
selectionEnd | unsigned long | 表示選中文本的結(jié)束位置。如果沒(méi)有選中文本，返回光標(biāo)在<input>元素內(nèi)部的位置。 |
selectionDirection | string | 表示選中文本的方向。可能的值包括forward、backward、none。 |
下面創(chuàng)建一個(gè) type="text" ，一次顯示 25 個(gè)字符，但最多允許顯示 50 個(gè)字符的文本框：
<input type="text" size="25" maxlength="50" value="initial value">HTML 使用的 <textarea> 元素在 JavaScript 中對(duì)應(yīng)的是 HTMLTextAreaElement 類型。HTMLTextAreaElement類型繼承自 HTMLElement 接口：
interface HTMLTextAreaElement extends HTMLElement {
...
}HTMLTextAreaElement 類型有一些獨(dú)有的屬性和方法：
下面創(chuàng)建一個(gè)高度為 25，寬度為 5 的 <textarea> 多行文本框。它與 <input> 不同的是，初始值顯示在 <textarea>...</textarea> 之間：
<textarea rows="25" cols="5">initial value</textarea>注意：處理文本框值的時(shí)候最好不要使用 DOM 方法，而應(yīng)該使用 value 屬性。
<input> 與 <textarea> 都支持 select() 方法，該方法用于選中文本框中的所有內(nèi)容。該方法的語(yǔ)法為：
select(): void下面看一個(gè)示例：
let textbox = document.forms[0].elements["input-box"];
textbox.select();也可以在文本框獲得焦點(diǎn)時(shí)，選中文本框的內(nèi)容：
textbox.addEventListener("focus", (event) => {
event.target.select();
});當(dāng)選中文本框中的文本或使用 select() 方法時(shí)，會(huì)觸發(fā) select 事件。
let textbox = document.forms[0].elements["textbox1"];
textbox.addEventListener("select", (event) => {
console.log(`Text selected: ${textbox.value}`);
});HTML5 對(duì) select 事件進(jìn)行了擴(kuò)展，通過(guò) selectionStart 和 selectionEnd 屬性獲取文本選區(qū)的起點(diǎn)偏移量和終點(diǎn)偏移量。如下所示：
function getSelectedText(textbox){
return textbox.value.substring(textbox.selectionStart,
textbox.selectionEnd);
}注意：在 IE8 及更早版本不支持這兩個(gè)屬性。
HTML5 提供了 setSelectionRange() 方法用于選中部分文本：
setSelectionRange(start, end, direction): void;下面看一個(gè)例子：
<input type="text" id="text-sample" size="20" value="Hello World!">
<button onclick="selectText()">選中部分文本</button>
<script>
function selectText() {
let input = document.getElementById("text-sample");
input.focus();
input.setSelectionRange(4, 8); // o Wo
}
</script>如果想要看到選中效果，必須讓文本框獲得焦點(diǎn)。
不同文本框經(jīng)常需要保證輸入特定類型或格式的數(shù)據(jù)，或許數(shù)據(jù)需要包含特定字符或必須匹配某個(gè)特定模式。而文本框并未提供驗(yàn)證功能，因此要配合 JavaScript 腳本實(shí)現(xiàn)輸入過(guò)濾功能。
有些輸入框需要出現(xiàn)或不出現(xiàn)特定字符。如果想要將輸入框變成只讀的，只需要使用 preventDefault()方法將按鍵都屏蔽：
input.addEventListener("keypress", (event) => {
event.preventDefault();
});而要屏蔽特定字符，就需要檢查事件的 charCode 屬性。如下所示，使用正則表達(dá)式實(shí)現(xiàn)只允許輸入數(shù)字的輸入框：
input.addEventListener("keypress", (event) => {
if (!/\d/.test(event.key)) {
event.preventDefault();
}
});還有一個(gè)問(wèn)題需要處理：復(fù)制、粘貼及涉及Ctrl 鍵的其他功能。在除IE 外的所有瀏覽器中，前面代碼會(huì)屏蔽快捷鍵Ctrl+C、Ctrl+V 及其他使用Ctrl 的組合鍵。因此，最后一項(xiàng)檢測(cè)是確保沒(méi)有按下Ctrl鍵，如下面的例子所示：
textbox.addEventListener("keypress", (event) => {
if (!/\d/.test(String.fromCharCode(event.charCode)) &&
event.charCode > 9 &&
!event.ctrlKey){
event.preventDefault();
}
});最后這個(gè)改動(dòng)可以確保所有默認(rèn)的文本框行為不受影響。這個(gè)技術(shù)可以用來(lái)自定義是否允許在文本框中輸入某些字符。
IE 是第一個(gè)實(shí)現(xiàn)了剪切板相關(guān)的事件以及通過(guò)JavaScript訪問(wèn)剪切板數(shù)據(jù)的瀏覽器，其它瀏覽器在后來(lái)也都支持了相同的事件和剪切板的訪問(wèn)，后來(lái) HTML5 將其納入了規(guī)范。以下是與剪切板相關(guān)的 6 個(gè)事件：
剪切板事件的行為及相關(guān)對(duì)象會(huì)因?yàn)g覽器而異。在 Safari、Chrome 和 Firefox 中，beforecopy、beforecut 和 beforepaste 事件只會(huì)在顯示文本框的上下文菜單時(shí)觸發(fā)，但 IE 不僅在這種情況下觸發(fā)，也會(huì)在 copy、cut 和 paste 事件在所有瀏覽器中都會(huì)按預(yù)期觸發(fā)。
在實(shí)際的事件發(fā)生之前，通過(guò)beforecopy、beforecut 和 beforepaste 事件可以在向剪貼板發(fā)送或從中檢索數(shù)據(jù)前修改數(shù)據(jù)。不過(guò)，取消這些事件并不會(huì)取消剪貼板操作。要阻止實(shí)際的剪貼板操作，必須取消 copy、cut和 paste 事件。
剪貼板的數(shù)據(jù)通過(guò) clipboardData 對(duì)象來(lái)獲取，且clipboardData 對(duì)象提供 3 個(gè)操作數(shù)據(jù)的方法：
而 clipboardData 對(duì)象在 IE 中使用 window 獲取，在 Firefox、Safari 和 Chrome 中使用 event 獲取。為防止未經(jīng)授權(quán)訪問(wèn)剪貼板，只能在剪貼板事件期間訪問(wèn) clipboardData 對(duì)象；IE 會(huì)在任何時(shí)候都暴露 clipboardData 對(duì)象。因此，要兼容兩者，最好在剪貼板事件期間使用該對(duì)象。
function getClipboardText(event){
var clipboardData = (event.clipboardData || window.clipboardData);
return clipboardData.getData("text");
}
function setClipboardText (event, value){
if (event.clipboardData){
return event.clipboardData.setData("text/plain", value);
} else if (window.clipboardData){
return window.clipboardData.setData("text", value);
}
}如果文本框只有數(shù)字，那剪貼時(shí)，就需要使用paste事件檢查剪貼板上的文本是否無(wú)效。如果無(wú)效，可以取消默認(rèn)行為：
input.addEventListener("paste", (event) => {
let text = getClipboardText(event);
if (!/^\d*$/.test(text)){
event.preventDefault();
}
});注意：Firefox、Safari和Chrome只允許在onpaste事件中訪問(wèn)getData()方法。
在 JavaScript 中，可以用在當(dāng)前字段完成時(shí)自動(dòng)切換到下一個(gè)字段的方式來(lái)增強(qiáng)表單字段的易用性。比如，常用手機(jī)號(hào)分為國(guó)家好加手機(jī)號(hào)。因此，我們?cè)O(shè)置 2 個(gè)文本框：
<form>
<input type="text" name="phone1" id="phone-id-1" maxlength="4">
<input type="text" name="phone2" id="phone-id-2" maxlength="11">
</form>當(dāng)文本框輸入到最大允許字符數(shù)后，就把焦點(diǎn)移到下一個(gè)文本框，這樣可以增加表單的易用性并加速數(shù)據(jù)輸入。如下所示：
<script>
function tabForward(event){
let target = event.target;
if (target.value.length == target.maxLength){
let form = target.form;
for (let i = 0, len = form.elements.length; i < len; i++) {
if (form.elements[i] == target) {
if (form.elements[i+1]) {
form.elements[i+1].focus();
}
return;
}
}
}
}
let inputIds = ["phone-id-1", "phone-id-2"];
for (let id of inputIds) {
let textbox = document.getElementById(id);
textbox.addEventListener("keyup", tabForward);
}
</script>這里，tabForward() 函數(shù)通過(guò)比較用戶輸入文本的長(zhǎng)度與 maxLength 屬性的值來(lái)檢測(cè)輸入是否達(dá)到了最大長(zhǎng)度。如果兩者相等，就通過(guò)循環(huán)表中的元素集合找到當(dāng)前文本框，并把焦點(diǎn)設(shè)置到下一個(gè)元素。
注意：上面的代碼只適用于之前既定的標(biāo)記，沒(méi)有考慮可能存在的隱藏字段。
HTML5 新增了一些表單提交前，瀏覽器會(huì)基于指定的規(guī)則進(jìn)行驗(yàn)證，并在出錯(cuò)時(shí)顯示適當(dāng)?shù)腻e(cuò)誤信息。而驗(yàn)證會(huì)基于某些條件應(yīng)用到表單字段中。
表單字段中添加 required 屬性，用于標(biāo)注該字段是必填項(xiàng)，不填則無(wú)法提交。該屬性適用于<input>、<textarea>和<select>。如下所示：
<input type="text" name="account" required>也可以通過(guò) JavaScript 檢測(cè)對(duì)應(yīng)元素的 required 屬性來(lái)判斷表單字段是否為必填項(xiàng)：
let isRequired = document.forms[0].elements["account"].required;也可以檢測(cè)瀏覽器是否支持 required 屬性：
let isRequiredSupported = "required" in document.createElement("input");注意：不同瀏覽器處理必填字段的機(jī)制不同。Firefox、Chrome、IE 和Opera 會(huì)阻止表單提交并在相應(yīng)字段下面顯示有幫助信息的彈框，而Safari 什么也不做，也不會(huì)阻止提交表單。
HTML5 為 <input> 元素增加了幾個(gè)新的 type 值。如下所示：
類型 | 描述 |
number | 數(shù)字值的輸入 |
date | 日期輸入 |
color | 顏色輸入 |
range | 一定范圍內(nèi)的值的輸入 |
month | 允許用戶選擇月份和年份 |
week | 允許用戶選擇周和年份 |
time | 允許用戶選擇時(shí)間（無(wú)時(shí)區(qū)） |
datetime | 允許用戶選擇日期和時(shí)間（有時(shí)區(qū)） |
datetime-local | 允許用戶選擇日期和時(shí)間（無(wú)時(shí)區(qū)） |
電子郵件地址的輸入 | |
search | 搜索（表現(xiàn)類似常規(guī)文本） |
tel | 電話號(hào)碼的輸入 |
url | URL地址的輸入 |
這些輸入表名字段應(yīng)該輸入的數(shù)據(jù)類型，并且提供了默認(rèn)驗(yàn)證。如下所示：
<input type="email" name="email">
<input type="url" name="homepage">要檢測(cè)瀏覽器是否支持新類型，可以在 JavaScript 中創(chuàng)建 <input> 并設(shè)置 type 屬性，之后讀取它即可。老版本中會(huì)將我只類型設(shè)置為 text，而支持的會(huì)返回正確的值。如下所示：
let input = document.createElement("input");
input.type = "email";
let isEmailSupported = (input.type == "email");而上面介紹的幾個(gè)如 number/range/datetime/datetime-local/date/month/week/time 幾個(gè)填寫數(shù)字的類型，都可以指定 min/max/step 等幾個(gè)與數(shù)值有關(guān)的屬性。step 屬性用于規(guī)定合法數(shù)字間隔，如 step="2"，則合法數(shù)字應(yīng)該為 0、2、4、6，依次類推。如下所示：
<input type="number" min="0" max="100" step="5" name="count">上面的例子是<input>中只能輸入從 0 到 100 中 5 的倍數(shù)。
也可以使用 stepUp() 和 stepDown() 方法對(duì) <input> 元素中的值進(jìn)行加減，它倆會(huì)接收一個(gè)可選參數(shù)，用于表示加減的數(shù)值。如下所示：
input.stepUp(); // 加1
input.stepUp(5); // 加5
input.stepDown(); // 減1
input.stepDown(10); // 減10HTML5 還為文本添加了 pattern 屬性，用于指定一個(gè)正則表達(dá)式。這樣就可以自己設(shè)置 <input> 元素的輸入模式了。如下所示：
<input type="text" pattern="\d+" name="count">注意模式的開(kāi)頭和末尾分別假設(shè)有^和$。這意味著輸入內(nèi)容必須從頭到尾都嚴(yán)格與模式匹配。
與新增的輸入類型一樣，指定 pattern 屬性也不會(huì)阻止用戶輸入無(wú)效內(nèi)容。模式會(huì)應(yīng)用到值，然后瀏覽器會(huì)知道值是否有效。通過(guò)訪問(wèn) pattern 屬性可以讀取模式：
let pattern = document.forms[0].elements["count"].pattern;使用如下代碼可以檢測(cè)瀏覽器是否支持pattern 屬性：
let isPatternSupported = "pattern" in document.createElement("input");HTML5 新增了 checkValidity() 方法，用來(lái)檢測(cè)表單中任意給定字段是否有效。而判斷的條件是約束條件，因此必填字段如果沒(méi)有值會(huì)被視為無(wú)效，字段值不匹配 pattern 屬性也會(huì)被視為無(wú)效。如下所示：
if (document.forms[0].elements[0].checkValidity()){
// 字段有效，繼續(xù)
} else {
// 字段無(wú)效
}要檢查整個(gè)表單是否有效，可以直接在表單上調(diào)用checkValidity()方法。這個(gè)方法會(huì)在所有字段都有效時(shí)返回true，有一個(gè)字段無(wú)效就會(huì)返回false：
if(document.forms[0].checkValidity()){
// 表單有效，繼續(xù)
} else {
// 表單無(wú)效
}validity 屬性會(huì)返回一個(gè)ValidityState 對(duì)象，表示 <input> 元素的校驗(yàn)狀態(tài)。返回的對(duì)象包含一些列的布爾值的屬性：
因此，通過(guò) validity 屬性可以檢查表單字段的有效性，從而獲取更具體的信息，如下所示：
if (input.validity && !input.validity.valid){
if (input.validity.valueMissing){
console.log("請(qǐng)指定值.")
} else if (input.validity.typeMismatch){
console.log("請(qǐng)指定電子郵件地址.");
} else {
console.log("值無(wú)效.");
}
}通過(guò)指定 novalidate 屬性可以禁止對(duì)表單進(jìn)行任何驗(yàn)證：
<form method="post" action="/signup" novalidate>
<!-- 表單元素 -->
</form>也可以在 JavaScript 通過(guò) noValidate 屬性設(shè)置，為 true 表示屬性存在，為 false 表示屬性不存在：
document.forms[0].noValidate = true; // 關(guān)閉驗(yàn)證如果一個(gè)表單中有多個(gè)提交按鈕，那么可以給特定的提交按鈕添加formnovalidate 屬性，指定通過(guò)該按鈕無(wú)需驗(yàn)證即可提交表單：
<form method="post" action="/foo">
<!-- 表單元素 -->
<input type="submit" value="注冊(cè)提交">
<input type="submit" formnovalidate name="btnNoValidate"
value="沒(méi)有驗(yàn)證的提交按鈕">
</form>也可以使用 JavaScript 設(shè)置 formNoValidate 屬性：
// 關(guān)閉驗(yàn)證
document.forms[0].elements["btnNoValidate"].formNoValidate = true;以上總結(jié)了 <input> 和 <textarea> 兩個(gè)元素的一些功能，主要是 <input> 元素可以通過(guò)設(shè)置 type 屬性獲取不同類型的輸入框，可以通過(guò)監(jiān)聽(tīng)鍵盤事件并檢測(cè)要插入的字符來(lái)控制文本框的內(nèi)容。
還有一些與剪貼板相關(guān)的事件，并對(duì)剪貼的內(nèi)容進(jìn)行檢測(cè)。還介紹了一些 HTML5 新增的屬性和方法和新增的更多的 <input> 元素的類型，和一些與驗(yàn)證相關(guān)的屬性和方法。
源：計(jì)算機(jī)世界
前幾天一則“微軟允許員工永久在家辦公”的消息刷爆朋友圈，無(wú)獨(dú)有偶，F(xiàn)acebook正在將數(shù)萬(wàn)個(gè)工作崗位轉(zhuǎn)移到遠(yuǎn)程工作上。由于新冠疫情的影響，線上會(huì)議、線上辦公已經(jīng)成為了部分企業(yè)的常態(tài)。根據(jù)Akamai智能邊緣平臺(tái)的監(jiān)測(cè)，疫情期間網(wǎng)絡(luò)流量出現(xiàn)大幅增長(zhǎng)，平均增幅達(dá)30%左右，而往年這一數(shù)據(jù)僅有3%。
與此同時(shí)，網(wǎng)絡(luò)攻擊風(fēng)險(xiǎn)也隨之增加。社交、視頻、聊天及游戲行業(yè)的流量激增情況較為突出，惡意攻擊流量約有4倍的增幅。那么，企業(yè)如何利用智能邊緣保證業(yè)務(wù)和數(shù)據(jù)的安全性？
疫情期間網(wǎng)絡(luò)攻擊頻發(fā)
6月初，Akamai平臺(tái)監(jiān)測(cè)到一起超大規(guī)模的DDoS攻擊，攻擊流量高達(dá)1.44 Tbps，這是Akamai平臺(tái)監(jiān)測(cè)到的自2018年GitHub遭受1.3 Tbps流量攻擊以來(lái)的又一次歷史新高。該起攻擊發(fā)生后不久，Akamai平臺(tái)再次監(jiān)測(cè)到一起每秒高達(dá)8.09億個(gè)數(shù)據(jù)包的DDoS攻擊。
此外，Akamai還監(jiān)測(cè)到一起針對(duì)金融服務(wù)行業(yè)的DDoS攻擊，攻擊者通過(guò)給攻擊目標(biāo)發(fā)郵件，去勒索比特幣。所幸，該攻擊被Akamai智能邊緣平臺(tái)監(jiān)測(cè)到并成功化解。目前，該種攻擊正慢慢向金融服務(wù)行業(yè)以外的游戲、媒體等其他行業(yè)發(fā)展。
從DDoS整個(gè)發(fā)展趨勢(shì)而言，Akamai發(fā)現(xiàn)其規(guī)模越來(lái)越大，且形式越發(fā)復(fù)雜。于UDP Flood、SYN Flood這種單一的攻擊模式目前越來(lái)越少，而比如網(wǎng)絡(luò)層攻擊、應(yīng)用層攻擊、反射性攻擊以及分片式攻擊等組合攻擊方式卻層出不窮。
Web應(yīng)用層攻擊的增長(zhǎng)也非常迅速。隨著數(shù)字化轉(zhuǎn)型的推進(jìn)，應(yīng)用層的應(yīng)用數(shù)量通常超100個(gè)。這種情況之下，不同的應(yīng)用使用的組件和技術(shù)會(huì)越發(fā)復(fù)雜。結(jié)果就是，使用開(kāi)源代碼、第三方腳本、下一代HTML語(yǔ)言或API接口等方式，都使得網(wǎng)站越來(lái)越脆弱，暴露的受攻擊點(diǎn)越來(lái)越多。
撞庫(kù)攻擊方也在發(fā)生變化。據(jù)Akamai監(jiān)測(cè)，在2020年第一季度，針對(duì)歐洲視頻服務(wù)提供商和廣播公司的惡意登錄嘗試大幅增加。在眾多隔離措施開(kāi)始施行后，3月下旬的一起針對(duì)單一服務(wù)提供商的攻擊在24小時(shí)內(nèi)共發(fā)起了近3.5億次登錄嘗試。很多犯罪分子會(huì)將相同帳戶與不同應(yīng)用的憑證信息進(jìn)行合并，合并后形成一個(gè)憑證集合，隨后進(jìn)行深度訓(xùn)練，從而獲取更多客戶的憑證信息，最終得到一個(gè)整體的客戶畫像、在黑產(chǎn)市場(chǎng)獲取更大利潤(rùn)。Akamai的研究人員觀察到，在整個(gè)第一季度中，被盜帳戶憑據(jù)一開(kāi)始的交易價(jià)格約為1到5美元，涵蓋多種服務(wù)的套餐交易價(jià)格為10到45美元。
如何利用邊緣網(wǎng)絡(luò)守住安全防線？
萬(wàn)物互聯(lián)（IoE）和人工智能等技術(shù)的發(fā)展已將數(shù)據(jù)和計(jì)算的重心從核心轉(zhuǎn)移到邊緣。在邊緣側(cè)進(jìn)行數(shù)據(jù)分析，可以改善企業(yè)整體的敏捷性，以及戰(zhàn)略和運(yùn)營(yíng)決策。由于海量數(shù)據(jù)是在傳統(tǒng)的數(shù)據(jù)中心之外創(chuàng)建，因此云將延伸至邊緣。未來(lái)不是云與邊緣的對(duì)抗，而是云和邊緣的共生，原有的架構(gòu)也會(huì)發(fā)生變化。
隨著多云環(huán)境、混合云環(huán)境的使用，云端的安全策略很難統(tǒng)一。當(dāng)企業(yè)隨云遷移的時(shí)候，安全策略是不是可以遷移？安全防護(hù)是不是可以遷移？現(xiàn)在很多應(yīng)用在云端可以彈性化拓展，這也要求安全服務(wù)能夠有彈性擴(kuò)展防護(hù)能力。
Gartner預(yù)計(jì)2025年至少有約一半的企業(yè)采用邊緣化的安全架構(gòu)。
Akamai的邊緣安全是數(shù)字化轉(zhuǎn)型中的保護(hù)傘，它很好地利用了自身網(wǎng)絡(luò)邊緣以及流量邊緣的優(yōu)勢(shì)，在網(wǎng)絡(luò)邊緣處對(duì)各種各樣的攻擊流量進(jìn)行識(shí)別。Akamai采用分層的安全防護(hù)體系，目前，該防護(hù)體系包括DDoS防護(hù)、爬蟲(chóng)攻擊的檢測(cè)和防護(hù)以及API防護(hù)等，企業(yè)可以緩解各種類型和規(guī)模的攻擊流量。除分層的邊緣安全防護(hù)體系外，Akamai還具備基于用戶身份識(shí)別和管理的服務(wù)、基于零信任的遠(yuǎn)程訪問(wèn)，以及網(wǎng)關(guān)類檢測(cè)等防護(hù)功能。
對(duì)于Akamai的邊緣安全領(lǐng)域的差異化優(yōu)勢(shì)，Akamai區(qū)域副總裁暨大中華區(qū)總經(jīng)理李昇說(shuō)：“首先，從邊緣的特點(diǎn)來(lái)說(shuō)，Akamai高度分布的架構(gòu)是最大的差異化優(yōu)勢(shì)。另外，Akamai的優(yōu)勢(shì)還在于安全，這并不局限于技術(shù)范疇，還有疊加信息的豐富性。Akamai有原生優(yōu)勢(shì)，因?yàn)槲覀兂休d了互聯(lián)網(wǎng)很大部分流量，對(duì)于攻擊行為有豐富的洞見(jiàn)。基于豐富的洞見(jiàn)，Akamai把知識(shí)圖譜輸入到產(chǎn)品的設(shè)計(jì)和功能中。”
Akamai區(qū)域副總裁暨大中華區(qū)總經(jīng)理李昇
如今，大家對(duì)邊緣化能力的提升有了越來(lái)越高的期待，一些大的云計(jì)算廠商也在推廣這一個(gè)概念，使得他們擴(kuò)充和彌補(bǔ)自己在分布式節(jié)點(diǎn)上的能力。
Akamai則是從另外一個(gè)方向來(lái)滿足企業(yè)在這方面的期待。李昇表示，除了傳統(tǒng)的CDN分發(fā)，Akamai還將在物聯(lián)網(wǎng)等層面不停地疊加邊緣邏輯處理能力。在提升業(yè)務(wù)處理能力的同時(shí)，做好邊緣安全防護(hù)。
去年，Akamai委托Forrester進(jìn)行了一項(xiàng)總體經(jīng)濟(jì)影響（Total Economic Impact）研究，以了解企業(yè)通過(guò)部署Akamai邊緣安全產(chǎn)品可能獲得的收益。“在使用Akamai邊緣安全產(chǎn)品之前，受訪客戶的挑戰(zhàn)通常是如何縮短受到惡意攻擊時(shí)的宕機(jī)時(shí)間、如何避免數(shù)據(jù)泄露和賬戶被盜等風(fēng)險(xiǎn)，對(duì)有效的安全方案保護(hù)收入和品牌信譽(yù)以及簡(jiǎn)化、高性價(jià)比的IT安全環(huán)境提出要求。在應(yīng)用了Akamai邊緣安全產(chǎn)品以后，客戶的主要成果就是在于成本是否降低，收入是否有提升。“Akamai大中華區(qū)產(chǎn)品市場(chǎng)經(jīng)理劉炅說(shuō)。
Akamai大中華區(qū)產(chǎn)品市場(chǎng)經(jīng)理劉炅
根據(jù)報(bào)告，除了上述量化收益，受訪客戶還談到了使用Akamai邊緣安全產(chǎn)品獲得的非量化收益，包括：網(wǎng)站受到攻擊時(shí)的表現(xiàn)得以改善。部署Akamai產(chǎn)品前后，網(wǎng)站受到攻擊時(shí)的預(yù)計(jì)加載時(shí)間分別為101.7毫秒和70毫秒；客戶流失率降低了5.88%，而跳出率下降了11.8%；點(diǎn)擊率有所提高，轉(zhuǎn)化率提高了6.3%，客戶滿意度也得以提升。
最后就是靈活性的分析。受訪客戶表示他們可以從多個(gè)公共云提供商中進(jìn)行選擇，而不必局限于一家云提供商。他們可以在前端部署Akamai邊緣安全產(chǎn)品，通過(guò)一種獨(dú)立于云服務(wù)商的方式提供安全服務(wù)。選擇云提供商的能力提高了定價(jià)和服務(wù)的靈活性。
總計(jì)而言，疫情之下，企業(yè)對(duì)邊緣安全的需求更加迫切。Akamai的邊緣安全產(chǎn)品以期節(jié)點(diǎn)廣、層次多、靈活性高的優(yōu)勢(shì)可以保證企業(yè)整體的安全策略以及防護(hù)的統(tǒng)一性。
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
