1、說說你對http的理解

1）首先用戶端與服務(wù)器需要建立連接据块。

2）建立連接后，用戶端發(fā)送一個(gè)請求給服務(wù)器

3）服務(wù)器接到請求后折剃，給予相應(yīng)的響應(yīng)信息另假，

4）用戶端接收服務(wù)器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然后用戶端與服務(wù)器斷開連接怕犁。

HTTP是一個(gè)應(yīng)用層協(xié)議边篮，由請求和響應(yīng)構(gòu)成，是一個(gè)標(biāo)準(zhǔn)的客戶端服務(wù)器模型奏甫。HTTP是一個(gè)無狀態(tài)的協(xié)議

2戈轿、說說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é)議安全。

HTTP的請求：

HTTP請求方法

根據(jù)HTTP標(biāo)準(zhǔn)谱俭，HTTP請求可以使用多種請求方法奉件。

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。

HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法昆著。

GET? ? 請求指定的頁面信息县貌，并返回實(shí)體主體。

HEAD? ? 類似于get請求凑懂，只不過返回的響應(yīng)中沒有具體的內(nèi)容煤痕，用于獲取報(bào)頭

POST? ? 向指定資源提交數(shù)據(jù)進(jìn)行處理請求。POST請求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改。

PUT? ? 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容摆碉。

DELETE? ? ? 請求服務(wù)器刪除指定的頁面祟敛。

CONNECT? ? HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。

OPTIONS? ? 允許客戶端查看服務(wù)器的性能兆解。

TRACE? ? 回顯服務(wù)器收到的請求，主要用于測試或診斷跑揉。

響應(yīng)：

HTTP之狀態(tài)碼

狀態(tài)代碼有三位數(shù)字組成锅睛，第一個(gè)數(shù)字定義了響應(yīng)的類別，共分五種類別:

1xx：指示信息--表示請求已接收历谍，繼續(xù)處理

2xx：成功--表示請求已被成功接收现拒、理解、接受

3xx：重定向--要完成請求必須進(jìn)行更進(jìn)一步的操作

4xx：客戶端錯(cuò)誤--請求有語法錯(cuò)誤或請求無法實(shí)現(xiàn)

5xx：服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請求

常見狀態(tài)碼：

200 OK? ? ? ? ? ? ? ? ? ? ? ? //客戶端請求成功

301? Moved Permanently? //永久移動(dòng)望侈。請求的資源已被永久的移動(dòng)到新URI印蔬，返回信息會(huì)包括新的URI，瀏覽器會(huì)自動(dòng)定向到新URI脱衙。今后任何新的請求都應(yīng)使用新的URI代替

302? Found? ? ? ? ? ? ? ? ? ? ? // 臨時(shí)移動(dòng)侥猬。與301類似。但資源只是臨時(shí)被移動(dòng)捐韩⊥诉耄客戶端應(yīng)繼續(xù)使用原有URI 303? See Other? ? ? ? ? ? ? ? //查看其它地址。與301類似荤胁。使用GET和POST請求查看? ? ? ? ? 304? Not Modified? ? ? ? //未修改瞧预。所請求的資源未修改，服務(wù)器返回此狀態(tài)碼時(shí)仅政，不會(huì)返回任何資源垢油。客戶端通常緩存訪問過的資源圆丹，通過提供一個(gè)頭信息指出客戶端希望只返回在指定日期之后修改的資源 305? Use Proxy? ? ? ? ? ? ? ? //使用代理滩愁。所請求的資源必須通過代理訪問? ? ? ? ? ? ? ? ? ? ?

400 Bad Request? ? ? ? ? ? ? //客戶端請求有語法錯(cuò)誤，不能被服務(wù)器所理解

401 Unauthorized? ? ? ? ? ? ? //請求未經(jīng)授權(quán)辫封，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用

403 Forbidden? ? ? ? ? ? ? ? ? //服務(wù)器收到請求惊楼，但是拒絕提供服務(wù)

404 Not Found? ? ? ? ? ? ? ? //請求資源不存在，eg：輸入了錯(cuò)誤的URL

500 Internal Server Error? ? //服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤

一個(gè)頁面從url敲如地址到頁面顯示的全過程

1秸讹、瀏覽器地址欄輸入url

2檀咙、瀏覽器會(huì)先查看瀏覽器緩存--系統(tǒng)緩存--路由緩存，如有存在緩存璃诀，就直接顯示弧可。如果沒有，接著第三步

3劣欢、域名解析（DNS）獲取相應(yīng)的ip

4棕诵、瀏覽器向服務(wù)器發(fā)起tcp連接裁良，與瀏覽器建立tcp三次握手

5、握手成功校套，瀏覽器向服務(wù)器發(fā)送http請求价脾，請求數(shù)據(jù)包

6、服務(wù)器請求數(shù)據(jù)笛匙，將數(shù)據(jù)返回到瀏覽器

7侨把、瀏覽器接收響應(yīng)，讀取頁面內(nèi)容妹孙，解析html源碼秋柄，生成DOm樹

8、解析css樣式蠢正、瀏覽器渲染骇笔，js交互

9谆焊、請求頁面中需要的js腳本和圖片或者樣式表

前端的安全CSRF穷遂，XSS昼牛，sql注入

CSRF

CSRF概念：CSRF跨站請求偽造(Cross—Site Request Forgery)怨绣，存在巨大的危害性汹来，你可以這樣來理解：?? ? ? 攻擊者盜用了你的身份摔握，以你的名義發(fā)送惡意請求盖彭，對服務(wù)器來說這個(gè)請求是完全合法的不见，但是卻完成了攻擊者所期望的一個(gè)操作葱跋，比如以你的名義發(fā)送郵件持寄、發(fā)消息，盜取你的賬號娱俺，添加系統(tǒng)管理員稍味，甚至于購買商品、虛擬貨幣轉(zhuǎn)賬等荠卷。 如下：其中Web A為存在CSRF漏洞的網(wǎng)站模庐，Web B為攻擊者構(gòu)建的惡意網(wǎng)站，User C為Web A網(wǎng)站的合法用戶油宜。

CSRF攻擊攻擊原理及過程如下：

用戶C打開瀏覽器掂碱，訪問受信任網(wǎng)站A，輸入用戶名和密碼請求登錄網(wǎng)站A慎冤；

在用戶信息通過驗(yàn)證后疼燥，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時(shí)用戶登錄網(wǎng)站A成功蚁堤，可以正常發(fā)送請求到網(wǎng)站A醉者；

用戶未退出網(wǎng)站A之前，在同一瀏覽器中，打開一個(gè)TAB頁訪問網(wǎng)站B撬即；

網(wǎng)站B接收到用戶請求后立磁，返回一些攻擊性代碼，并發(fā)出一個(gè)請求要求訪問第三方站點(diǎn)A剥槐；

瀏覽器在接收到這些攻擊性代碼后唱歧，根據(jù)網(wǎng)站B的請求，在用戶不知情的情況下攜帶Cookie信息粒竖，向網(wǎng)站A發(fā)出請求颅崩。網(wǎng)站A并不知道該請求其實(shí)是由B發(fā)起的，所以會(huì)根據(jù)用戶C的Cookie信息以C的權(quán)限處理該請求温圆，導(dǎo)致來自網(wǎng)站B的惡意代碼被執(zhí)行。? ? ? ?

防御CSRF攻擊：

? ? ? 目前防御 CSRF 攻擊主要有2種策略：驗(yàn)證 HTTP 請求的Referer 字段孩革；在請求地址中添加 token 并驗(yàn)證

XSS

XSS, 即為（Cross Site Scripting）, 中文名為跨站腳本, 是發(fā)生在目標(biāo)用戶的瀏覽器層面上的岁歉，當(dāng)渲染DOM樹的過程成發(fā)生了不在預(yù)期內(nèi)XSS（Cross Site Scripting），跨站腳本攻擊膝蜈，是一種允許攻擊者在另外一個(gè)用戶的瀏覽器中執(zhí)行惡意代碼腳本的腳本注入式攻擊锅移。本來縮小應(yīng)該是CSS，但為了和層疊樣式（Cascading Style Sheet,CSS）有所區(qū)分饱搏，故稱XSS執(zhí)行的JS代碼時(shí)非剃，就發(fā)生了XSS攻擊。

1推沸、持續(xù)型XSS攻擊：惡意腳本來源于網(wǎng)站的數(shù)據(jù)庫

1备绽、攻擊者通過評論表單提交將<script\>alert(‘a(chǎn)aa’)</script\>提交到網(wǎng)站

2、網(wǎng)站后端對提交的評論數(shù)據(jù)不做任何操作鬓催，直接存儲到數(shù)據(jù)庫中

3肺素、其他用戶訪問正常訪問網(wǎng)站，并且需要請求網(wǎng)站的評論數(shù)據(jù)

4宇驾、網(wǎng)站后端會(huì)從數(shù)據(jù)庫中取出數(shù)據(jù)倍靡，直接返回給用戶

5、用戶得到頁面后课舍，直接運(yùn)行攻擊者提交的代碼<script>alert(‘a(chǎn)aa’)</script>`塌西，所有用戶都會(huì)在網(wǎng)頁中彈出aaa的彈窗

2、反射型XSS攻擊：惡意腳本來源于受害者的請求

在一個(gè)反射型XSS攻擊中筝尾，惡意文本屬于受害者發(fā)送給網(wǎng)站的請求中的一部分捡需。隨后網(wǎng)站又把惡意文本包含進(jìn)用于響應(yīng)用戶的返回頁面中，發(fā)還給用戶筹淫。

1栖忠、用戶誤點(diǎn)開了帶攻擊的url :http://xxx?keyword=<script\>alert('aaa')</script\>

2、網(wǎng)站給受害者的返回中包含了來自URL的的惡意文本

3、用戶的瀏覽器收到文本后執(zhí)行頁面庵寞，會(huì)在網(wǎng)頁中彈窗aaa

3狸相、基于DOM的XSS攻擊

基于DOM的XSS攻擊是反射型攻擊的變種。服務(wù)器返回的頁面是正常的捐川，只是我們在頁面執(zhí)行js的過程中脓鹃，會(huì)把攻擊代碼植入到頁面中

1、用戶誤點(diǎn)開了帶攻擊的url :http://xxx?name=<script\>alert('aaa')</script\>

2古沥、網(wǎng)站給受害者的返回中正常的網(wǎng)頁

3瘸右、用戶的瀏覽器收到文本后執(zhí)行頁面合法腳本，這時(shí)候頁面惡意腳本會(huì)被執(zhí)行岩齿，會(huì)在網(wǎng)頁中彈窗aaa

如何防止攻擊

XSS攻擊其實(shí)就是代碼的注入太颤。用戶的輸入被編譯成惡意的程序代碼。所以盹沈，為了防范這一類代碼的注入龄章，需要確保用戶輸入的安全性。對于攻擊驗(yàn)證乞封，我們可以采用以下兩種措施：

1做裙、編碼，就是轉(zhuǎn)義用戶的輸入肃晚，把用戶的輸入解讀為數(shù)據(jù)而不是代碼

2锚贱、校驗(yàn)，對用戶的輸入及請求都進(jìn)行過濾檢查关串，如對特殊字符進(jìn)行過濾拧廊，設(shè)置輸入域的匹配規(guī)則等。

SQL注入

SQL注入就是一種通過操作輸入來修改后臺SQL語句達(dá)到代碼執(zhí)行進(jìn)行攻擊目的的技術(shù)晋修。

cookie卦绣、sessionStorage、localStorage的區(qū)別

1飞蚓、cookie數(shù)據(jù)始終在同源的http請求中攜帶（即使不需要）滤港，即cookie在瀏覽器和服務(wù)器間來回傳遞，而 sessionStorage和localStorage不會(huì)自動(dòng)把數(shù)據(jù)發(fā)送給服務(wù)器趴拧，僅在本地保存溅漾。

2、存儲大小限制也不同著榴，cookie數(shù)據(jù)不能超過4K添履，同時(shí)因?yàn)槊看蝖ttp請求都會(huì)攜帶cookie、所以cookie 只適合保存很小的數(shù)據(jù)脑又。sessionStorage和localStorage雖然也有存儲大小的限制暮胧，但比 cookie大得多锐借，可以達(dá)到5M或更大

3、數(shù)據(jù)有效期不同往衷，sessionStorage僅僅在當(dāng)前瀏覽器窗口關(guān)閉之前有效钞翔；localStorage始終有效，窗口或 者瀏覽器關(guān)閉之后也一直保存席舍，因此作用持久數(shù)據(jù)布轿；cookie，只在設(shè)置cookie過期時(shí)間之前有效来颤，即使窗口關(guān)閉或者瀏覽器關(guān)閉汰扭。

Ajax 是什么，ajax請求方式有幾種

是異步JavaScript和XML技術(shù)福铅， 可以在不必刷新頁面的情況下發(fā)送以及接收各種格式的信息萝毛；一種創(chuàng)建交互 式網(wǎng)頁應(yīng)用的網(wǎng)頁開發(fā)技術(shù)

跨域

1、jsonp跨域(優(yōu)點(diǎn):簡單方便,缺點(diǎn):只能使用get請求,不支持post請求)11

2滑黔、nginx的反向代理(少用)? apach? tomact?

3笆包、window.name(少用)

4、axios反向代理,

5拷沸、cors(跨域資源共享)修改服務(wù)器端修改包的頭部信息,

6色查、iframe跨子域(不常用）

VUE項(xiàng)目中怎么跨域

使用http-proxy-middleware 代理解決（項(xiàng)目使用vue-cli腳手架搭建）

例如請求的url:“http://aa.com/demo.json“

1薯演、打開config/index.js,在proxyTable中添寫如下代碼：

proxyTable: {

'/api': {//使用"/api"來代替"http://aa.com"

target:'http://aa.com',//源地址

changeOrigin:true,//改變源

secure:false// 是否使用https

pathRewrite: {

'^/api':'/api'//路徑重寫

? ?? }

? }

}

2撞芍、使用axios請求數(shù)據(jù)時(shí)直接使用“/api”

getData() {

axios.get('/api/demo.json',function(res) {

console.log(res)

})

以上配置只是在開發(fā)環(huán)境（dev）中解決跨域。要解決生產(chǎn)環(huán)境的跨域問題,則在config/dev.env.js和config/prod.env.js里也就是開發(fā)/生產(chǎn)環(huán)境下分別配置一下請求的地址API_HOST跨扮，開發(fā)環(huán)境中我們用上面配置的代理地址api序无，生產(chǎn)環(huán)境下用正常的接口地址

module.exports=merge(prodEnv, {

? ? NODE_ENV:'"development"',

? ? API_HOST:"/api/"

})

'use strict'

module.exports={

? ? NODE_ENV:'"production"',

? ? API_HOST:"http://aa.com"

}

前后端數(shù)據(jù)交互安全

加密：

hash加密：md5? sha256

對稱加密：? AES ，DES

非對稱加密：生成一對鑰匙衡创，公鑰帝嗡，私鑰。 公鑰是由私鑰生成的

無限上拉加載

下拉刷新