輸入域名到顯示網(wǎng)頁的網(wǎng)絡(luò)過程
5層網(wǎng)絡(luò)模型介紹
低三層
物理層主要作用是定義物理設(shè)備如何傳輸數(shù)據(jù)
數(shù)據(jù)鏈路層在通信的實體間建立數(shù)據(jù)鏈路連接
網(wǎng)絡(luò)層為數(shù)據(jù)在結(jié)點之間傳輸創(chuàng)建邏輯鏈路
傳輸層：
兩個協(xié)議 TCPIP 和 UDP 光坝，向用戶提供可靠的端到端(End-to-End)服務(wù)。
建立起了自己電腦到百度服務(wù)器(舉例)的鏈接匹中，它們兩端如何去傳輸數(shù)據(jù)，它的傳輸數(shù)據(jù)的方式 俺夕，都是在這層定義促王。
傳輸層向高層屏蔽了下層數(shù)據(jù)通信的細(xì)節(jié)瞒大。
應(yīng)用層：
為應(yīng)用軟件提供了服務(wù) http / ftp 是構(gòu)建于TCP 協(xié)議之上，屏蔽網(wǎng)絡(luò)傳輸相關(guān)細(xì)節(jié)俊性。
HTTP協(xié)議的發(fā)展歷史
1略步、弄清楚一個概念，HTTP請求與TCP請求不是一個概念定页，在同一個TCP請求可以發(fā)送多個HTTP請求趟薄，以前的協(xié)議版本不能這么做，但是現(xiàn)在HTTP1.1.1里面可以這么做典徊，而且在HTTP2里面是會更大的去優(yōu)化相關(guān)的一些東西杭煎，來提高HTTP傳輸效率以及服務(wù)器的性能。
2卒落、TCP連接對應(yīng)多個HTTP請求羡铲，而一個HTTP請求肯定在某一個TCP連接里面去定義發(fā)送的。
第一個版本 HTTP / 0.9
只有一個命令 GET
沒有HEADER 等描述數(shù)據(jù)的信息
服務(wù)器發(fā)送完畢就關(guān)閉
第二個版本 HTTP / 1.0
增加了很多命令
增加了status code 和 header
多字符集支持儡毕、多部分發(fā)送也切、權(quán)限、緩存 等等
第三個版本 HTTP / 1.1
持久鏈接
pipleine
增加了 host 和其他一些命令 （在同一個物理服務(wù)器可以同時跑很多服務(wù)）
第四個版本 HTTP / 2.0
所以數(shù)據(jù)都是以二進(jìn)制傳輸
同一個鏈接里面發(fā)送多個請求不在需要按照順序來
頭信息壓縮以及推送等提高效率的功能
HTTP2
1、所有數(shù)據(jù)以二進(jìn)制傳輸
同一個連接里面發(fā)送多個請求不再需要按照順序來（可以同時返回數(shù)據(jù)）
頭信息壓縮以及推送等提高效率的功能：
頭信息壓縮：在HTTP1發(fā)送和返回請求雷恃，http頭都是必須完整發(fā)送并返回疆股，帶寬量大。
2倒槐、推送：http請求只能是發(fā)送然后響應(yīng)返回內(nèi)容旬痹，客戶端永遠(yuǎn)是主動方，服務(wù)端是被動方讨越。http2有了推送唱凯，服務(wù)端可以主動發(fā)起數(shù)據(jù)傳輸。
如：web頁面里面有css,img,js等文件谎痢，它們都是連接的形式,這里就有順序的問題，解析文本之后才能發(fā)送對應(yīng)的鏈接請求卷雕，http2有了推送功能节猿，在請求的同時，可以主動把這個頁面的css,img,js等文件推送到客戶端漫雕，這樣發(fā)送順序是并行的滨嘱，不是串行的，性能高出許多浸间。
HTTPS
安全版本的HTTP太雨。
HTTP的三次握手
在客戶端和服務(wù)器端之間進(jìn)行http請求的發(fā)送和返回的過程當(dāng)中，需要創(chuàng)建TCP connection魁蒜，因為http不存在連接這樣的概念囊扳，它只有請求和響應(yīng)，里面都是數(shù)據(jù)包兜看，需要經(jīng)過傳輸?shù)耐ǖ雷断蹋@個通道就在TCP里面創(chuàng)建了從客戶端發(fā)起到客戶端接收的這樣的一個連接，這個連接可以一直保持细移，http請求就是在這個連接的基礎(chǔ)上發(fā)送的搏予。
在TCP上面可以發(fā)送多個http請求，在不同http版本里弧轧，這個模式是不一樣的雪侥。
http1.0:TCP連接是在一個http請求創(chuàng)建的時候，就去創(chuàng)建這個TCP鏈接精绎，鏈接創(chuàng)建完了之后速缨，請求發(fā)送過去，服務(wù)器響應(yīng)了之后捺典，這個TCP連接就關(guān)閉了鸟廓。
http1.1:TCP鏈接可以通過某種方式去聲明鏈接一直保持，就是在第一個請求發(fā)送之后，TCP鏈接沒有關(guān)閉引谜，第二個請求來了之后牍陌，還可以在這個沒有關(guān)閉的鏈接上進(jìn)行發(fā)送。
http2：的TCP鏈接上面的http請求時可以并發(fā)的员咽，如果同一個用戶對同一個服務(wù)器發(fā)起一個網(wǎng)頁請求的時候毒涧，只需要一個TCP連接。
長鏈接好處：
- TCP鏈接在創(chuàng)建的過程中要經(jīng)歷三次握手這么一個消耗贝室，代表著有三次網(wǎng)絡(luò)傳輸：客戶端發(fā)送-服務(wù)端返回-客戶端再發(fā)送-創(chuàng)建TCP鏈接契讲，這個時候才可以發(fā)送HTTP請求，所以如果我們把TCP鏈接保持滑频，那么第二個http請求就沒有三次握手的開銷捡偏。
TCP三次握手
TCP握手過程
1.客戶端發(fā)起一個我要連接的數(shù)據(jù)包請求給服務(wù)器，里面會有一個SYN的標(biāo)志位峡迷，標(biāo)志這是一個創(chuàng)建請求的數(shù)據(jù)包
2.服務(wù)端接收到數(shù)據(jù)包后知道有一個客戶要和它建立鏈接了银伟，然后會開啟一個TCP socket 端口，開啟之后返回數(shù)據(jù)給客戶端绘搞，數(shù)據(jù)包含 SYN標(biāo)志位彤避，ACK= X+1，Seq=Y
3.客戶端拿到數(shù)據(jù)包后意味著服務(wù)器端允許創(chuàng)建TCP連接夯辖，然后發(fā)送數(shù)據(jù)包 ACK = Y+1琉预，Seq=Z
為什么要三次握手創(chuàng)建TCP連接?
為了防止服務(wù)端開始無用的鏈接，網(wǎng)絡(luò)傳輸是有延時的蒿褂，傳輸過程中防止丟包圆米，造成重復(fù)創(chuàng)建鏈接，資源浪費贮缅，所以設(shè)置三次握手榨咐。為了規(guī)避網(wǎng)絡(luò)傳輸延時。
三次握手確認(rèn)客戶端發(fā)起到服務(wù)器返回的過程谴供，就是為了規(guī)避這些在網(wǎng)絡(luò)傳輸過程中延時導(dǎo)致的一些服務(wù)器開銷的問題块茁。
URI-URL和URN
user:pass@ 代表訪問資源的身份使用用戶名和密碼
host.com 用來定位資源的服務(wù)器在互聯(lián)網(wǎng)中的位置(可以是IP 也可以是 域名)
:80 端口，每臺物理服務(wù)器可以跑很多軟件的web服務(wù)桂肌，端口就是監(jiān)聽物理服務(wù)器上面某個具體的web服務(wù)
/path 路由数焊，web 服務(wù)器里面的內(nèi)容可以通過路由進(jìn)行定位
?query=string 搜索參數(shù)
hash 查找文檔的某個片段
HTTP報文格式
method ：
GET:獲取數(shù)據(jù)
POST：創(chuàng)建數(shù)據(jù)
PUT：更新數(shù)據(jù)
DELETE ： 刪除數(shù)據(jù)
http方法：用來定義對于資源的操作
http code ：定義服務(wù)器對請求的處理結(jié)果
100-199代表操作要持續(xù)進(jìn)行
200-299代表成功
300-399需要重定向
400-499代表請求有問題
500-599服務(wù)器錯誤
CORS跨域請求的限制與解決
請求已經(jīng)發(fā)送了，內(nèi)容也已經(jīng)返回了崎场，只不過瀏覽器在解析了內(nèi)容之后佩耳，發(fā)現(xiàn)這是不允許的，所以幫你攔截了谭跨，這其實是瀏覽器提供的功能干厚。
跨域 ： 在這個網(wǎng)頁發(fā)送一個請求李滴，如ajax請求，都必須在同域的蛮瞄，如果跨域所坯，需要服務(wù)器同意，才能夠接收到返回內(nèi)容挂捅。
jsonp到底做了什么芹助？
建立script標(biāo)簽，src放置請求地址闲先，即可状土。因為瀏覽器允許link,img,script標(biāo)簽上的路徑加載內(nèi)容，并不在乎服務(wù)器是否設(shè)置了跨域的頭伺糠，jsonp的原理其實就是在script上加載了一個連接蒙谓，這個連接去訪問了服務(wù)器的某一個請求并返回內(nèi)容。
設(shè)置請求頭：
response.writeHead(200,{
'Access-Control-Allow-Origin':'*'
})
'Access-Control-Allow-Origin'的值：
'Access-Control-Allow-Origin':'*
- '*' ： 任何服務(wù)训桶，任何域名都可以訪問服務(wù)器彼乌。的做法 ：
更安全'Access-Control-Allow-Origin':'http://baidu.com',只允許指定的域名請求。
緩存頭Cache-Control的含義和使用
自定義的頭在跨域請求時不被允許的
fetch('http://localhost:8887/',{
method:'POST',
headers:{
// 自定義頭
'X-Test-Cors':'123'
}
})
CORS預(yù)請求限制
跨域時默認(rèn)允許的方法（不需要預(yù)請求） ：
- GET
- HEAD
- POST
除了以上三種渊迁，都會先發(fā)送預(yù)請求
允許Content-Type - text/plain
- multipart/form-data
- application/x-www-form-urlendoded
其他限制
- 請求頭限制
- XMLHttpRequestUpload對象均沒有注冊任何事件監(jiān)聽器
- 請求中沒有使用ReadableStream對象
什么是預(yù)請求
瀏覽器根據(jù)Response Headers判斷請求是否允許
解決：設(shè)置允許訪問的自定義請求頭
http.createServer(function(request,response){
console.log('request come',request.url)
response.writeHead(200,{
'Access-Control-Allow-Origin':'*',
// 設(shè)置允許訪問的自定義請求頭
'Access-Control-Allow-Headers':'X-Test-Cor'
})
response.end('123')
}).listen(8887)
瀏覽器跨域請求之預(yù)請求操作：Request Method:OPTIONS，首先發(fā)送這個請求灶挟，服務(wù)端可以根據(jù)不同的method進(jìn)行不同的操作琉朽，允許接下來實際發(fā)送的請求。通過這個OPTION來獲得服務(wù)端允許的任何請求稚铣，然后再實際發(fā)送設(shè)置的請求箱叁。
做跨域文件上傳的時候，瀏覽器會自動發(fā)起一個 OPTIONS 方法到服務(wù)器惕医。普通的 ajax 請求耕漱，也不會發(fā)起這個請求，只有當(dāng) ajax 請求綁定了 upload 的事件并且跨域的時候抬伺，就會自動發(fā)起這個請求螟够。用于探測后續(xù)真正需要發(fā)起的跨域 POST 請求對于服務(wù)器來說是否是安全可接受的，因為跨域提交數(shù)據(jù)對于服務(wù)器來說可能存在很大的安全問題峡钓。
概括：允許跨域的請求 ： get , post,options
發(fā)送的請求跨域了妓笙，瀏覽器會自動發(fā)送一個options預(yù)請求，詢問后端支持的跨域請求方法能岩。后端需要設(shè)置允許請求的方法寞宫。
router.options('/upload', function* (){
this.set('Access-Control-Allow-Method', 'POST');
this.set('Access-Control-Allow-Origin', 'http://xxx.com');
this.status = 204;
});
204 :告知客戶端表示該響應(yīng)成功了，但是該響應(yīng)并沒有返回任何響應(yīng)體,options預(yù)響應(yīng)拉鹃。如果狀態(tài)碼為 200辈赋，還得攜帶多余的響應(yīng)體鲫忍，在這種場景下是完全多余的，只會浪費流量钥屈。
瀏覽器為什么設(shè)置請求限制悟民？
因為瀏覽器希望在網(wǎng)頁進(jìn)行跨域請求操作的時候是保證服務(wù)端的安全的，不允許任何隨便進(jìn)行跨域焕蹄，不允許隨便的方法進(jìn)行跨域逾雄，以防數(shù)據(jù)被惡意篡改。所以提供這些限制之后腻脏，就可以進(jìn)行一些非常有利的判斷鸦泳。
http.createServer(function(request,response){
console.log('request come',request.url)
response.writeHead(200,{
// 設(shè)置允許跨域的訪問地址
'Access-Control-Allow-Origin':'*',
// 設(shè)置允許訪問的自定義請求頭
'Access-Control-Allow-Headers':'X-Test-Cors',
// 設(shè)置允許跨域的methods
'Access-Control-Allow-Methods':'POST,Put,Delete',
// 允許以上三個方式進(jìn)行跨域的最長時間，1000秒內(nèi)不需要發(fā)送預(yù)請求驗證了
'Access-Control-Max-Age':'1000'
})
response.end('123')
}).listen(8887)
Redirect
通過url去訪問一個路徑的時候永品，這個資源可能已經(jīng)不在這個url指定的位置了做鹰，服務(wù)器要告訴瀏覽器這個資源具體的位置，然后瀏覽器再去重新請求這個指定的位置鼎姐。所以如果資源換了位置钾麸，不應(yīng)該馬上廢棄url，應(yīng)該告知客戶端資源正確的位置炕桨。
CORS跨域限制以及預(yù)請求驗證
自定義的頭在跨域請求時不被允許的
fetch('http://localhost:8887/',{
method:'POST',
headers:{
// 自定義頭
'X-Test-Cors':'123'
}
})
CORS預(yù)請求限制
跨域時默認(rèn)允許的方法 ：
- GET
- HEAD
- POST
允許Content-Type
- text/plain
- multipart/form-data
- application/x-www-form-urlendoded
其他限制
- 請求頭限制
- XMLHttpRequestUpload對象均沒有注冊任何事件監(jiān)聽器
- 請求中沒有使用ReadableStream對象
什么是預(yù)請求
瀏覽器根據(jù)Response Headers判斷請求是否允許
解決：設(shè)置允許訪問的自定義請求頭
http.createServer(function(request,response){
console.log('request come',request.url)
response.writeHead(200,{
'Access-Control-Allow-Origin':'*',
// 設(shè)置允許訪問的自定義請求頭
'Access-Control-Allow-Headers':'X-Test-Cor'
})
response.end('123')
}).listen(8887)
瀏覽器跨域請求之預(yù)請求操作：Request Method:OPTIONS饭尝，首先發(fā)送這個請求，服務(wù)端可以根據(jù)不同的method進(jìn)行不同的操作献宫，允許接下來實際發(fā)送的請求钥平。通過這個OPTION來獲得服務(wù)端允許的任何請求，然后再實際發(fā)送設(shè)置的請求姊途。
瀏覽器為什么設(shè)置請求限制涉瘾？
因為瀏覽器希望在網(wǎng)頁進(jìn)行跨域請求操作的時候是保證服務(wù)端的安全的，不允許任何隨便進(jìn)行跨域捷兰，不允許隨便的方法進(jìn)行跨域立叛，以防數(shù)據(jù)被惡意篡改。所以提供這些限制之后贡茅，就可以進(jìn)行一些非常有利的判斷秘蛇。
http.createServer(function(request,response){
console.log('request come',request.url)
response.writeHead(200,{
// 設(shè)置允許跨域的訪問地址
'Access-Control-Allow-Origin':'*',
// 設(shè)置允許訪問的自定義請求頭
'Access-Control-Allow-Headers':'X-Test-Cors',
// 設(shè)置允許跨域的methods
'Access-Control-Allow-Methods':'POST,Put,Delete',
// 允許以上三個方式進(jìn)行跨域的最長時間，1000秒內(nèi)不需要發(fā)送預(yù)請求驗證了
'Access-Control-Max-Age':'1000'
})
response.end('123')
}).listen(8887)
緩存頭Cache-Control的含義和使用
特性：
以下這些頭只是限制性的顶考，聲明性的作用彤叉，沒有強(qiáng)制約束力。只是為代理服務(wù)器設(shè)置了這些頭村怪，要求按照規(guī)范去做秽浇，但是完全可以不按照這個規(guī)范做。
可緩存性
- public
在http請求返回的過程當(dāng)中甚负，在Cache-Control設(shè)置了public值柬焕，代表這個http請求返回的內(nèi)容所經(jīng)過的任何路徑當(dāng)中审残，包括一些中間的http代理服務(wù)器以及我們發(fā)出請求的客戶端瀏覽器，都可以進(jìn)行對返回內(nèi)容的緩存操作：就是把這份數(shù)據(jù)存在本地斑举，下次直接讀這個緩存搅轿，不需要到返回這個內(nèi)容的服務(wù)器上面重新進(jìn)行操作返回內(nèi)容「荤瑁可緩存性是指哪些地方可以執(zhí)行這些緩存璧坟。 - private
只要發(fā)起請求的瀏覽器才可以緩存 - no-cache
任何節(jié)點都不可以緩存∈昱常可以在本地服務(wù)器緩存雀鹃，每次發(fā)起請求都需要去服務(wù)器驗證，如果服務(wù)器說可以使用緩存励两，才能使用緩存黎茎。也就是說需要經(jīng)過服務(wù)器驗證的。
到期
- max-age=<seconds>
緩存有效期 - s-maxage=<seconds>
代替上面的max-age当悔，但是只有在代理服務(wù)器里面才會生效 - max-stale=<seconds>
max-stale：瀏覽器用不到傅瞻，瀏覽器并不會主動去設(shè)置這個頭，只有在發(fā)起端設(shè)置是有用的盲憎，服務(wù)端返回的內(nèi)容中設(shè)置沒有用嗅骄。發(fā)起請求方，主動帶的頭饼疙，在max-age過期之后掸读，如果我們返回的資源中有這個max-stale設(shè)置，還可以使用過期的緩存宏多，而不需要去服務(wù)器請求新的內(nèi)容。
重新驗證
- must-revalidate
設(shè)置了max-age澡罚，如果緩存已經(jīng)過期了伸但，必須去原服務(wù)端發(fā)送這個請求，重新獲取數(shù)據(jù)留搔，來驗證內(nèi)容是否真的過期了更胖，而不能直接使用本地緩存。 - proxy-revalidate
用在指定緩存服務(wù)器隔显，在過期的時候必須去原服務(wù)器重新請求一遍却妨，而不能直接使用本地緩存。
其他
- no-store
本地和代理服務(wù)器不可以存儲這個緩存括眠，永遠(yuǎn)要去服務(wù)器拿新的body的內(nèi)容彪标。 - no-transform
不允許代理服務(wù)器不要改動返回的內(nèi)容
瀏覽器中用到的
可緩存性 ：
- public
- private
- no-cahe
到期
- max-age=<seconds>
- s-maxage=<seconds>
- max-stale=<seconds>
重新驗證
- must-revalidate
- 設(shè)置請求文件緩存時間
'Cache-Control': 'max-age=20'
http.createServer(function (request, response) {
console.log('request come', request.url)
if (request.url === '/') {
const html = fs.readFileSync('test.html', 'utf8')
response.writeHead(200, {
'Content-Type': 'text/html'
})
response.end(html)
}
if (request.url === '/script.js') {
response.writeHead(200, {
'Content-Type': 'text/javascript',
// 設(shè)置到期時間
'Cache-Control': 'max-age=20'
})
response.end('console.log("script loaded")')
}
}).listen(8888)
問題 ： 這時如果改變了服務(wù)器返回的結(jié)果，刷新掷豺，發(fā)現(xiàn)返回的還是之前的結(jié)果捞烟，并不是最新的薄声。這是因為服務(wù)器端更新了之后，客戶端還是請求的緩存的資源题画，這樣想要更新一個應(yīng)用的時候默辨，客戶端根本觸及不到了，一般max-ag可能會設(shè)置一年苍息。
解決：在構(gòu)建流程的時候缩幸，把打包完成的JS文件名根據(jù)內(nèi)容的hash結(jié)果，加上一串hash碼竞思，這串hash碼是因為根據(jù)打包完成的js以及其他靜態(tài)資源的文件內(nèi)容進(jìn)行性的hash計算表谊，所以如果這些靜態(tài)文件內(nèi)容沒有變，hash碼就不變衙四，反應(yīng)到web頁面上就是url沒有變铃肯，那么就可以使用靜態(tài)緩存；而如果你的內(nèi)容有變传蹈，hash碼就會變化押逼，嵌入在html的url路徑就有變化，有了變化之后發(fā)起的請求就是一個新的靜態(tài)資源請求而不是之前緩存的請求惦界。這樣就可以達(dá)到緩存的目的挑格。
緩存驗證:Last-Modified和Etag的使用
資源驗證
如果catche-Ctrol設(shè)置了no-cache（任何節(jié)點都不可以緩存≌赐幔可以在本地服務(wù)器緩存漂彤，每次發(fā)起請求都需要去服務(wù)器驗證，如果服務(wù)器說可以使用緩存灾搏，才能使用緩存挫望。也就是說需要經(jīng)過服務(wù)器驗證的。）
設(shè)置了Catche-Ctrol的請求過程如下：
數(shù)據(jù)如何驗證？
1、驗證頭
-
Last-Modified
上次修改時間玉掸。給資源設(shè)置了上一次是什么時候被修改的亿柑。
配合If-Modified-Since或者If-Unmodified-Since使用。
驗證是否可以使用緩存的過程：如果我們請求了一個資源，如果返回的head里面有以上兩個頭信息，指定了時間，下次在請求的時候就會帶上這兩個傳過來的值到服務(wù)器奕纫，通常瀏覽器都是用If-Modified-Since，服務(wù)器就可以通過讀取head里面的If-Modified-Since的值烫沙，然后對比資源存在的地方匹层，對比上次修改時間，如果發(fā)現(xiàn)這兩個時間是一樣的锌蓄，代表這個資源還沒有被修改又固，服務(wù)器就告訴瀏覽器直接使用緩存仲器。對比上次修改時間以驗證資源是否需要更新。 -
Etag
一個更加嚴(yán)格的驗證仰冠。- 數(shù)據(jù)簽名
一個資源對它的內(nèi)容會產(chǎn)生一個唯一的簽名乏冀，如果這個資源進(jìn)行了修改，這個簽名就會變成新的洋只，這樣前后的簽名就不一樣辆沦。
典型做法：對內(nèi)容進(jìn)行hash計算（就像打包文件一樣，對內(nèi)容計算就會得到一個唯一值）识虚。用來標(biāo)記這個資源肢扯。 - 配合if-Match或者If-Non-Macth使用
下次請求就會帶上這兩個值，就是服務(wù)端返回的Etag值担锤。 - 對比資源的簽名判斷是否使用緩存
- 數(shù)據(jù)簽名
if (request.url === '/script.js') {
response.writeHead(200, {
'Content-Type': 'text/javascript',
// 設(shè)置到期時間 , 每次發(fā)起請求都需要去服務(wù)器驗證
'Cache-Control': 'max-age=20000000000,no-cache',
//Last-Modified
'Last-Modified' : '123',
// Etag
'Etag' : 777
})
這個時候依舊返回了內(nèi)容蔚晨，因為內(nèi)容并沒有修改，所以不需要服務(wù)器返回response肛循，做法如下：對比Etag
// 如果兩次結(jié)果相同铭腕，返回緩存結(jié)果為空
const etag = request.headers['if-none-match']
if(etag === '777'){
response.writeHead(304, {
'Content-Type': 'text/javascript',
'Cache-Control': 'max-age=20000000000,no-cache',
'Last-Modified' : '123',
'Etag' : 777
})
// 設(shè)置請求結(jié)果為空
response.end('')
}else{
response.writeHead(200, {
'Content-Type': 'text/javascript',
'Cache-Control': 'max-age=20000000000,no-cache',
'Last-Modified' : '123',
'Etag' : 777
})
// 否則就是內(nèi)容修改了，返回最新結(jié)果
response.end('console.log("script loaded twice")')
}
cookie&&session
什么是cookie?
通過服務(wù)器返回數(shù)據(jù)后多糠，通過：Set-Cookie設(shè)置保存在瀏覽器里的內(nèi)容累舷。瀏覽器在保存了這個內(nèi)容之后，下一次在同域里的請求當(dāng)中帶上這個Cookie夹孔。這樣就可以實現(xiàn)在這次訪問網(wǎng)站的會話中被盈，可以通過Cookie一直在傳輸?shù)膬?nèi)容來保證我們返回的數(shù)據(jù)是這個用戶的。
8189D6AA-FF8D-4BEB-9656-17FEC7F5F57C.png
cookie屬性
- max-age 和 expires 設(shè)置過期時間
- Secure 只在https的時候發(fā)送
- httpOnly無法通過js訪問,瀏覽器中還是有的搭伤。
安全性只怎，比如csrs攻擊，會通過在網(wǎng)頁注入腳本怜俐，或通過url來引導(dǎo)用戶去給攻擊者的服務(wù)器發(fā)送用戶自己的身堡，這樣他就能拿到這個這個cookie,從而訪問我們網(wǎng)站中保存的用戶的數(shù)據(jù)。禁止重要的數(shù)據(jù)通過JS訪問佑菩，是保護(hù)用戶數(shù)據(jù)安全重要的一步。
cookie時效
- 如果沒有設(shè)置時間裁赠，瀏覽器關(guān)閉失效殿漠。
- 'Set-cookie': ['id=123; max-age=30', 'name=lin'] : id=123->
30s后失效
設(shè)置test.com以及test.com的所有二級域名享受到cookie
![]()
5b2bb4300001195019201080-156-88.jpg
session:
Cookie保存session,經(jīng)常做的就是把用戶登錄之后的ID，或者session的key設(shè)置到cookie里面佩捞。能夠保證定位到用戶绞幌，就是session實現(xiàn)的方案。
HTTP長連接
http請求時在TCP的連接上發(fā)送的一忱，TCP的連接分為長鏈接和短連接莲蜘。
長鏈接： HTTP請求在發(fā)送的時候谭确，要先去創(chuàng)建一個TCP連接，然后在這個連接上把http請求發(fā)送并且接收完返回票渠。這個時候逐哈，因為一次http請求已經(jīng)結(jié)束了，瀏覽器和服務(wù)端就會商量问顷，是否要把TCP連接關(guān)閉昂秃，如果不關(guān)閉，這個TCP連接會一直開著杜窄，一直消耗肠骆，但是如果下次再有請求塞耕，可以直接在TCP連接上發(fā)送，那么就不需要經(jīng)過三次握手了莉钙。如果直接關(guān)閉，就意味著下次請求又要重新創(chuàng)建一個連接畏浆，這個時候就會有網(wǎng)絡(luò)延遲的開銷。
請求之后就關(guān)閉的好處 ： 減少客戶端和服務(wù)端高并發(fā)的連接數(shù)刻获。實際中網(wǎng)站并發(fā)量會比較大，如果一直重新創(chuàng)建鏈接蝎毡，會導(dǎo)致這個創(chuàng)建過程過多厚柳。
數(shù)據(jù)協(xié)商
客戶端發(fā)送請求到服務(wù)端的時候沐兵，客戶端會聲明需要拿到的數(shù)據(jù)格式以及數(shù)據(jù)相關(guān)的限制，服務(wù)端會根據(jù)這些判斷碳想，可能會有不同類型的數(shù)據(jù)的返回毁靶。服務(wù)端會根據(jù)客戶端發(fā)送過來的這些頭信息來確定到底要返回什么樣的數(shù)據(jù)。
分類
- 請求
Accept:聲明想要的數(shù)據(jù)- Accept:指定數(shù)據(jù)類型
- Accept-Encoding : 代表數(shù)據(jù)是以什么編碼方式來進(jìn)行傳輸龙填，主要用來限制服務(wù)端如何進(jìn)行數(shù)據(jù)壓縮岩遗。
- Accept-Language : 世界語言不通，不同地方期望展示的不同案铺。
- User-Agent : 判斷返回的是PC還是M端頁面
- 返回
Content- Content-Type
- Content-Encoding
- Content-Language
csp
xss : 通過某些方法在網(wǎng)站里注入一些腳本红且，導(dǎo)致頁面出現(xiàn)問題涤姊，甚至竊取用戶信息思喊。很可能就是通過網(wǎng)站提供的富文本編輯器之類的工具，插入script內(nèi)容舆乔。
限制方法：在服務(wù)器返回的頭里面寫入'Content-Security-Policy'剂公。
- 只能通過http: https加載纲辽，不能直接寫在html
- 如果通過外鏈加載的JS文件，指定域名可以加載鳞上，只能本域名下的JS文件可以加載
//限制default-src吊档，只能通過http: https加載怠硼，不能直接寫在html
'Content-Security-Policy':'default-src http: https'
可以寫在meta標(biāo)簽
<meta http-equiv="Content-Security-Policy" content="script-src 'self'; form-action 'self';">
http明文傳輸：
互聯(lián)網(wǎng)中的每一層，如果有人攔截雁佳，解析數(shù)據(jù)包并讀取就可以獲取相關(guān)信息糖权。
https：
私鑰：解密公鑰加密過的內(nèi)容炸站，中間截取的人無法解密
公鑰：放在互聯(lián)網(wǎng)上旱易，所有人都可以拿到的加密字符串
兩者的主要區(qū)別就在于握手階段。
