資訊專欄INFORMATION COLUMN
摘要：為了解決協(xié)議的這一缺陷，需要使用另一種協(xié)議安全套接字層超文本傳輸協(xié)議，為了數(shù)據(jù)傳輸?shù)陌踩?，在的基礎(chǔ)上加入了協(xié)議，依靠證書來驗證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的通信加密。是超文本傳輸協(xié)議，信息是明文傳輸，則是具有安全性的加密傳輸協(xié)議。
1、請說說從用戶輸入url到呈現(xiàn)網(wǎng)頁，這中間都發(fā)生了什么 ？
1、域名解析
域名解析的過程：
1）.查詢?yōu)g覽器自身DNS緩存
2）.若上面沒有查找到，則搜索操作系統(tǒng)自身的dns緩存
3）.若上面沒有找到，則嘗試讀取hosts文件
4）.若上面沒有找到，向本地配置的首選DNS服務(wù)器發(fā)送請求
5）.win系統(tǒng) 如果上面沒有找到，操作系統(tǒng)查找NetBIOS name cache
6）.win系統(tǒng) 如果上面沒有找到，查詢wins服務(wù)器
7）.win系統(tǒng) 如果上面沒有找到，廣播查找
8）.win系統(tǒng) 如果上面沒有找到，讀取LMHOSTS文件
若以上多沒有找到，解析失敗
2、 TCP三次握手
a. 為什么需要三次握手
下面解釋明明兩次就可以建立連接的為什么還要加第三次的確認(rèn)。
如果發(fā)送兩次就可以建立連接話，那么只要客戶端發(fā)送一個連接請求，服務(wù)端接收到并發(fā)送了確認(rèn)，就會建立一個連接。
可能出現(xiàn)的問題：如果一個連接請求在網(wǎng)絡(luò)中跑的慢，超時了，這時客戶端會從發(fā)請求，但是這個跑的慢的請求最后還是跑到了，然后服務(wù)端就接收了兩個連接請求，然后全部回應(yīng)就會創(chuàng)建兩個連接，浪費(fèi)資源！
如果加了第三次客戶端確認(rèn)，客戶端在接受到一個服務(wù)端連接確認(rèn)請求后，后面再接收到的連接確認(rèn)請求就可以拋棄不管了。
b. 為什么需要四次分手
TCP是雙向的，所以需要在兩個方向分別關(guān)閉，每個方向的關(guān)閉又需要請求和確認(rèn)，所以一共就4次。
3、瀏覽器向服務(wù)器發(fā)送http請求
一旦建立了TCP連接，Web瀏覽器就會向Web服務(wù)器發(fā)送請求命令。例如：GET/sample/hello.jsp HTTP/1.1。
4、瀏覽器發(fā)送請求頭信息
瀏覽器發(fā)送其請求命令之后，還要以頭信息的形式向Web服務(wù)器發(fā)送一些別的信息，之后瀏覽器發(fā)送了一空白行來通知服務(wù)器，它已經(jīng)結(jié)束了該頭信息的發(fā)送。
5、服務(wù)器處理請求
服務(wù)器軟件收到http請求，確定執(zhí)行什么(ASP.net PHP RUBY JAVA等)來處理他。讀取參數(shù)并進(jìn)行邏輯操作后，生成指定的數(shù)據(jù)。
6、服務(wù)器做出應(yīng)答
客戶機(jī)向服務(wù)器發(fā)出請求后，服務(wù)器會客戶機(jī)回送應(yīng)答，HTTP/1.1 200 OK ，應(yīng)答的第一部分是協(xié)議的版本號和應(yīng)答狀態(tài)嗎
7、服務(wù)器發(fā)送應(yīng)答頭信息
正如客戶端會隨同請求發(fā)送關(guān)于自身的信息一樣，服務(wù)器也會隨同應(yīng)答向用戶發(fā)送關(guān)于它自己的數(shù)據(jù)及被請求的文檔。
8、服務(wù)器發(fā)送數(shù)據(jù)
Web服務(wù)器向瀏覽器發(fā)送頭信息后，它會發(fā)送一個空白行來表示頭信息的發(fā)送到此為結(jié)束，接著，它就以Content-Type應(yīng)答頭信息所描述的格式發(fā)送用戶所請求的實際數(shù)據(jù)。
9、tcp連接關(guān)閉
一般情況下，一旦Web服務(wù)器向瀏覽器發(fā)送了請求數(shù)據(jù)，它就要關(guān)閉TCP連接，然后如果瀏覽器或者服務(wù)器在其頭信息加入了這行代碼：
Connection:keep-alive
TCP連接在發(fā)送后將仍然保持打開狀態(tài)，于是，瀏覽器可以繼續(xù)通過相同的連接發(fā)送請求。保持連接節(jié)省了為每個請求建立新連接所需的時間，還節(jié)約了網(wǎng)絡(luò)帶寬
2、請說說瀏覽器渲染頁面的過程 ？
分析：這道題的考察點重點在于瀏覽器渲染頁面的機(jī)制上面，只有充分理解渲染機(jī)制以后才能去更好的優(yōu)化咱們的頁面，比如css為什么放到head里面，js為什么放到body后面，重繪重排概念 參考回答: 瀏覽器渲染頁面是一個從上至下的過程，當(dāng)拿到html以后首先會生成dom樹，加載解析css構(gòu)建cssom樹，解析css的時候不會阻塞進(jìn)程，我們通常會把首屏樣式放到head里面，然后加載執(zhí)行js，在js里面可能會有動態(tài)創(chuàng)建修改dom的邏輯，瀏覽器為了優(yōu)化整個渲染過程，會在解析到j(luò)s的時候阻塞整個進(jìn)程，我們通常把js放到body后面來優(yōu)化首屏的加載速度，當(dāng)dom以及cssom都構(gòu)建完成后會生成渲染樹，再根據(jù)渲染樹將dom樹上的節(jié)點布局到屏幕上的正確位置，最后遍歷繪制的所有節(jié)點，為其添加對應(yīng)的樣式 延伸理解 重繪：改變dom的外觀屬性，如背景色，outline等 重排: 改變dom的結(jié)構(gòu)，幾何屬性等 為了減少瀏覽器的重排重繪，我們應(yīng)該將多次改變樣式的操作合并成一次操作3、說說http，https的區(qū)別，他們的優(yōu)缺點是什么？
超文本傳輸協(xié)議HTTP協(xié)議被用于在Web瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息，HTTP協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報文，就可以直接讀懂其中的信息，因此，HTTP協(xié)議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。 為了解決HTTP協(xié)議的這一缺陷，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議HTTPS，為了數(shù)據(jù)傳輸?shù)陌踩?，HTTPS在HTTP的基礎(chǔ)上加入了SSL協(xié)議，SSL依靠證書來驗證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的通信加密。 一、HTTP和HTTPS的基本概念 HTTP：是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，是一個客戶端和服務(wù)器端請求和應(yīng)答的標(biāo)準(zhǔn)（TCP），用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。 HTTPS：是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。 HTTPS協(xié)議的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?；另一種就是確認(rèn)網(wǎng)站的真實性。 二、HTTP與HTTPS有什么區(qū)別？ HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網(wǎng)景公司設(shè)計了SSL（Secure Sockets Layer）協(xié)議用于對HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密，從而就誕生了HTTPS。 簡單來說，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全。 HTTPS和HTTP的區(qū)別主要如下： 1、https協(xié)議需要到ca申請證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。 2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。 3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。 4、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。 三、HTTPS的工作原理 我們都知道HTTPS能夠加密信息，以免敏感信息被第三方獲取，所以很多銀行網(wǎng)站或電子郵箱等等安全級別較高的服務(wù)都會采用HTTPS協(xié)議。 1、客戶端發(fā)起HTTPS請求 這個沒什么好說的，就是用戶在瀏覽器里輸入一個https網(wǎng)址，然后連接到server的443端口。 2、服務(wù)端的配置 采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請，區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費(fèi)服務(wù))。 這套證書其實就是一對公鑰和私鑰，如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然后發(fā)給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。 3、傳送證書 這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發(fā)機(jī)構(gòu)，過期時間等等。 4、客戶端解析證書 這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。 如果證書沒有問題，那么就生成一個隨機(jī)值，然后用證書對該隨機(jī)值進(jìn)行加密，就好像上面說的，把隨機(jī)值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。 5、傳送加密信息 這部分傳送的是用證書加密后的隨機(jī)值，目的就是讓服務(wù)端得到這個隨機(jī)值，以后客戶端和服務(wù)端的通信就可以通過這個隨機(jī)值來進(jìn)行加密解密了。 6、服務(wù)段解密信息 服務(wù)端用私鑰解密后，得到了客戶端傳過來的隨機(jī)值(私鑰)，然后把內(nèi)容通過該值進(jìn)行對稱加密，所謂對稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內(nèi)容，而正好客戶端和服務(wù)端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全。 7、傳輸加密后的信息 這部分信息是服務(wù)段用私鑰加密后的信息，可以在客戶端被還原。 8、客戶端解密信息 客戶端用之前生成的私鑰解密服務(wù)段傳過來的信息，于是獲取了解密后的內(nèi)容，整個過程第三方即使監(jiān)聽到了數(shù)據(jù)，也束手無策。 六、HTTPS的優(yōu)點 正是由于HTTPS非常的安全，攻擊者無法從中找到下手的地方，從站長的角度來說，HTTPS的優(yōu)點有以下2點： 1、SEO方面 谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS加密的網(wǎng)站在搜索結(jié)果中的排名將會更高”。 2、安全性 盡管HTTPS并非絕對安全，掌握根證書的機(jī)構(gòu)、掌握加密算法的組織同樣可以進(jìn)行中間人形式的攻擊，但HTTPS仍是現(xiàn)行架構(gòu)下最安全的解決方案，主要有以下幾個好處： （1）、使用HTTPS協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器； （2）、HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。 （3）、HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。 七、HTTPS的缺點 雖然說HTTPS有很大的優(yōu)勢，但其相對來說，還是有些不足之處的，具體來說，有以下2點： 1、SEO方面 據(jù)ACM CoNEXT數(shù)據(jù)顯示，使用HTTPS協(xié)議會使頁面的加載時間延長近50%，增加10%到20%的耗電，此外，HTTPS協(xié)議還會影響緩存，增加數(shù)據(jù)開銷和功耗，甚至已有安全措施也會受到影響也會因此而受到影響。 而且HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。 最關(guān)鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。 2、經(jīng)濟(jì)方面 （1）、SSL證書需要錢，功能越強(qiáng)大的證書費(fèi)用越高，個人網(wǎng)站、小網(wǎng)站沒有必要一般不會用。 （2）、SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴(kuò)展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、操作系統(tǒng)支持，Windows XP就不支持這個擴(kuò)展，考慮到XP的裝機(jī)量，這個特性幾乎沒用）。 （3）、HTTPS連接緩存不如HTTP高效，大流量網(wǎng)站如非必要也不會采用，流量成本太高。 （4）、HTTPS連接服務(wù)器端資源占用高很多，支持訪客稍多的網(wǎng)站需要投入更大的成本，如果全部采用HTTPS，基于大部分計算資源閑置的假設(shè)的VPS的平均成本會上去。 （5）、HTTPS協(xié)議握手階段比較費(fèi)時，對網(wǎng)站的相應(yīng)速度有負(fù)面影響，如非必要，沒有理由犧牲用戶體驗。4、請說說js里的this的指向
參考回答: js中this的指向總是指向一個對象，而具體指向哪個對象是在運(yùn)行時基于函數(shù)的執(zhí)行環(huán)境動態(tài)綁定的， 而非函數(shù)被聲明時的環(huán)境 具體到實際應(yīng)用中，this 的指向大致可以分為以下幾種 * 作為對象的方法調(diào)用指向當(dāng)前對象 * 作為普通函數(shù)調(diào)用指向全局window * 構(gòu)造函數(shù)調(diào)用指向返回的對象 * call,apply 調(diào)用指向其第一個參數(shù)5、怎么理解js中的原型鏈？如何實現(xiàn)繼承？
參考回答: 每個構(gòu)造函數(shù)都有一個原型對象 每個原型對象都包含一個指向構(gòu)造函數(shù)的指針 每個實例都包含一個指向原型對象的指針 查找方式是一層層向上查找直至頂層Object.prototype 實現(xiàn)繼承的方式常用的有: 原型鏈繼承 借用構(gòu)造函數(shù)(call,apply) 組合繼承(原型鏈＋構(gòu)造函數(shù)) 原型式繼承 寄生式組合式繼承 延伸理解: 優(yōu)缺點? 每一種繼承的方式都有自己的優(yōu)缺點 組合繼承的特點是會調(diào)用構(gòu)造函數(shù)兩次, 都是將多種繼承方式組合到一起相輔相成. new 運(yùn)算符具體干了什么? 創(chuàng)建一個空的對象 將空的對象的__proto__成員指向構(gòu)造函數(shù)的prototype成員對象 調(diào)用構(gòu)造函數(shù)將this指向前面創(chuàng)建的對象6、Js中的內(nèi)存泄露怎么理解？
參考回答: 內(nèi)存泄漏的定義為當(dāng)程序不再需要的內(nèi)存，由于某種原因其不會返回到操作系統(tǒng)或可用內(nèi)存池，內(nèi)存泄漏會導(dǎo)致一系列問題，比如: 運(yùn)行緩慢，崩潰，高延遲等 js中常見的內(nèi)存泄露: 意外的全局變量 遺忘的計時器或回調(diào)函數(shù) 脫離文檔的DOM引用 閉包7、如何理解瀏覽器的跨域問題？常用的解決方式有哪些？
參考回答: 瀏覽器的同源策略會導(dǎo)致跨域，這里同源策略又分為以下兩種 ： DOM同源策略：禁止對不同源頁面DOM進(jìn)行操作。這里主要場景是iframe跨域的情況，不同域名的iframe是限制互相訪問的。 XmlHttpRequest同源策略：禁止使用XHR對象向不同源的服務(wù)器地址發(fā)起HTTP請求。只要協(xié)議、域名、端口有任何一個不同，都被當(dāng)作是不同的域，之間的請求就是跨域操作 注：協(xié)議、域名、端口有任何一個不同，都視為不同的域 常用的解決方式: 1.CORS(Cross-origin resource sharing) 跨域資源共享 注: 這種方式如果想要攜帶cookie需要xhr設(shè)置withCredentials為true, 服務(wù)端 Access-Control-Allow-Credentials:true 2.jsonp實現(xiàn)跨域(動態(tài)創(chuàng)建script,利用src屬性進(jìn)行跨域) 3.服務(wù)器代理(瀏覽器有跨域限制，服務(wù)端沒有) 4.document.domain 5.window.name 6.hash傳值 7.possMessage8、函數(shù)防抖，函數(shù)節(jié)流的基本概念以及工作中實際使用到的場景？實現(xiàn)的思路是？
函數(shù)防抖，函數(shù)節(jié)流的基本概念以及工作中實際使用到的場景？實現(xiàn)的思路是？
參考回答:
函數(shù)防抖(debounce)
基本概念: 在事件被觸發(fā)n秒后再執(zhí)行回調(diào)，如果在這n秒內(nèi)又被觸發(fā)，則重新計時。
舉例理解: 我們用手指一直按住一個彈簧，它將不會馬上彈起直到你松手為止
使用場景:
按鈕重復(fù)點擊
輸入框連續(xù)輸入
判斷scroll是否滑到底部
簡單實現(xiàn):
const debounce = (fn,delay) => {
let timer = null
return () => {
let ctx = this, args = arguments
clearTimeout(timer)
timer = setTimeout( ()=> {
fn.apply(ctx,args)
}, delay)
}
}
函數(shù)節(jié)流(throttle)
基本概念: 在規(guī)定的時間范圍內(nèi)相同的操作觸發(fā)多次只執(zhí)行一次
DOM拖拽
Canvas畫筆
窗口resize
簡單實現(xiàn):
const throttle = (fn,gapTime = 100) => {
let timer = null
let start_time = new Date().getTime()
return () => {
let ctx = this, args = arguments,
current_time = new Date().getTime()
clearTimeout(timer)
if(curr_time - start_time >= gapTime()){
fn.apply(ctx,args)
start_time = current_time
}else{
timer = setTimeout( ()=> {
fn.apply(ctx,args)
}, gapTime)
}
}
}
9、說說js中的eventloop機(jī)制？
參考回答:
首先javascript是單線程機(jī)制，就是指當(dāng)我們在執(zhí)行一個任務(wù)的時候，其它的事情都得等待他執(zhí)行完畢
在js中所有任務(wù)分為兩種, 同步任務(wù)及異步任務(wù)
執(zhí)行棧執(zhí)行主線程任務(wù)，當(dāng)有操作dom，ajax交互，使用定時器異步操作的時候，這些任務(wù)會被移入到 callback queue 任務(wù)隊列中 當(dāng)主線程任務(wù)執(zhí)行完畢為空時，會讀取callback queue隊列中的函數(shù)，進(jìn)入主線程執(zhí)行 上述過程會不斷重復(fù)，也就是常說的Event Loop(事件循環(huán))
在一個事件循環(huán)中,異步任務(wù)返回結(jié)果后會被扔進(jìn)一個任務(wù)列隊中，根據(jù)異步事件上的類型，這個事件會被放到對應(yīng)的宏任務(wù)或者微任務(wù)列隊中去， 當(dāng)執(zhí)行棧為空的時候，主線程會先查看微任務(wù)中的事件列隊，如果微任務(wù)不是空先依次執(zhí)行微任務(wù)，如果是空的再去宏任務(wù)列隊中取出一個事件并把對應(yīng)的回調(diào)加入到當(dāng)前執(zhí)行棧，如此反復(fù)，進(jìn)入循環(huán)
下面用一道題來加深印象
setTimeout(function () {
console.log(1);
});
new Promise( (resolve,reject) => {
console.log(2)
}).then( (val) => {
console.log(val);
})
輸出的結(jié)果是2,1
10、web安全攻擊手段有哪些？以及如何防范
常見的有xss, csrf, sql注入 xss(cross site scripting) 跨站腳本攻擊 定義: 指攻擊者在網(wǎng)頁嵌入腳本，用戶瀏覽網(wǎng)頁觸發(fā)惡意腳本執(zhí)行 XSS攻擊分為3類：存儲型（持久型）、反射型（非持久型）、基于DOM 如何防范: 設(shè)置HttpOnly以避免cookie劫持的危險 過濾，對諸如