iOS http https udp tcp dns cookie/session講解
http幾個(gè)請(qǐng)求方式
請(qǐng)求方式：
1. GET
2. POST
3. DELETE
4. PUT
5. HEAD
6. OPTIONS
我們最常用的請(qǐng)求方式就是get和post，那么兩者有什么區(qū)別呢？
get 請(qǐng)求參數(shù)一般以？拼接到 URL 后面，post請(qǐng)求參數(shù)放在body體里面
get 參數(shù)長(zhǎng)度限制2048個(gè)字符，post 一般沒(méi)有限制
get相對(duì)post是不安全的
GET 一般是用來(lái)獲取資源的，是安全的可緩存的冪等的
post 一般是用來(lái)處理資源的
安全性：不應(yīng)該引起server端的任何狀態(tài)變化,GET HEAD,OPTIONS
冪等性：同一個(gè)請(qǐng)求方法執(zhí)行多次和執(zhí)行一次效果完全相同，PUT，DELETE，比如get獲取一次和N次是一樣嗯嗯
可緩存性：請(qǐng)求是否可以被緩存，一般會(huì)有代理服務(wù)器緩存，多次請(qǐng)求可能獲取的是緩存
http常見(jiàn)錯(cuò)誤碼含義
2xx:一般表示成功
3xx:發(fā)生網(wǎng)絡(luò)重定向
4xx:客戶(hù)端發(fā)生的請(qǐng)求有問(wèn)題
5xx:server本身有異常
http 特點(diǎn)
- 無(wú)連接，建立連接和釋放連接，引出http 持久連接
- 無(wú)狀態(tài)，server是不知道是同一個(gè)用戶(hù)的，引出cookie、session
非持久連接：每次都需要建立連接和釋放連接，每次都需要三次握手四次揮手
持久連接，在一定時(shí)間之內(nèi)都是用這條通道，一段時(shí)間之后關(guān)閉這條連接通道，
持久連接頭部字段：
connection：keep-alive,采用持久連接
time:20,20s之內(nèi)不會(huì)斷開(kāi)連接，不會(huì)進(jìn)行四次揮手，可以復(fù)用。
max :10，這條連接最多可以發(fā)起多少請(qǐng)求
怎樣判斷一個(gè)持久連接是否結(jié)束？：
content-length:1024,響應(yīng)報(bào)文頭部，客戶(hù)端可以根據(jù)接收數(shù)據(jù)大小是否到達(dá)這個(gè)大小來(lái)判斷
chunked：http相應(yīng)報(bào)文，最后會(huì)有一個(gè)空的chunked
Charles 的抓包原理是什么呢？：
利用http中間人攻擊來(lái)實(shí)現(xiàn)的
正常：client和server直接交互的，中間人攻擊，是有個(gè)中間人，當(dāng)我們發(fā)起一個(gè)請(qǐng)求的時(shí)候，會(huì)有一個(gè)中間人，通過(guò)中間人發(fā)起請(qǐng)求給server，然后server把數(shù)據(jù)返回給中間人中間人返回給客戶(hù)端，這樣其實(shí)我們的中間人是可以篡改數(shù)據(jù)的。
三次握手四次揮手
- 客戶(hù)端發(fā)起連接，需要發(fā)送 syn 同步報(bào)文
- 當(dāng)server端收到之后，server會(huì)返回一個(gè)同步ack的，syn同步報(bào)文
- 客戶(hù)端會(huì)返回一個(gè)確認(rèn)ack報(bào)文，三次握手
- http請(qǐng)求報(bào)文
- server 返回http響應(yīng)報(bào)文,請(qǐng)求結(jié)束開(kāi)始四次揮手
- 客戶(hù)端發(fā)送 fin 終止報(bào)文,四次揮手開(kāi)始
- server返回確認(rèn)ack報(bào)文，客戶(hù)端到server端鏈接斷開(kāi)
- 客戶(hù)端到server端的鏈接斷開(kāi)，但是server到客戶(hù)端的不一定斷開(kāi)，可能還會(huì)傳遞數(shù)據(jù)，在某一時(shí)機(jī)，server像客戶(hù)端發(fā)送fin，ack報(bào)文
- 客戶(hù)端回應(yīng)確認(rèn)ack報(bào)文，這樣就完成了server到客戶(hù)端的斷開(kāi)，完成了四次揮手
為什么三次握手,不是兩次
1.當(dāng)我們發(fā)送的syn超時(shí)的情況下，我們的客戶(hù)端會(huì)通過(guò)超時(shí)重傳的邏輯,重新發(fā)送一個(gè)syn同步報(bào)文，這時(shí)候server端會(huì)返回給客戶(hù)端一個(gè)確認(rèn)syn,ack同步確認(rèn)報(bào)文，如果只有兩次握手，那么連接已經(jīng)建立，如果這時(shí)候我們之前的超時(shí)syn報(bào)文發(fā)送出去了，server端認(rèn)為，客戶(hù)端又要建立連接，認(rèn)為是第二次連接，又返回給客戶(hù)端一個(gè)ack確認(rèn)報(bào)文,其實(shí)第一個(gè)報(bào)文是超時(shí)。通過(guò)三次握手就可以解決，當(dāng)我們的超時(shí)syn報(bào)文發(fā)送成功之后，server返回同步確認(rèn)報(bào)文，只收客戶(hù)端進(jìn)行第三次握手，返回給server一個(gè)ack確認(rèn)報(bào)文，就代表建立了連接，當(dāng)我們的超時(shí)syn報(bào)文再次發(fā)送給server端的時(shí)候雖然server端會(huì)返回一個(gè)syn同步報(bào)文，但是server端發(fā)現(xiàn)，一段時(shí)間之后，客戶(hù)端并沒(méi)有發(fā)送ack確認(rèn)報(bào)文，那么請(qǐng)求就沒(méi)有建立。
所以三次握手解決了這種超時(shí)重傳的邏輯
為什么四次揮手？進(jìn)行兩次斷開(kāi)
四次揮手是，客戶(hù)端向server端發(fā)送fin終止報(bào)文，然后server回復(fù)客戶(hù)端一個(gè)確認(rèn)ack報(bào)文，這時(shí)候完成了版關(guān)閉狀態(tài)，如果這時(shí)候server仍然有數(shù)據(jù)向客戶(hù)端發(fā)送是可以的，但是翻過(guò)來(lái)不可以，就需要server斷開(kāi)，server想客戶(hù)端發(fā)送fin終止報(bào)文，然后客戶(hù)端回復(fù)ack確認(rèn)報(bào)文。
客戶(hù)端和server建立的tcp連接為全雙工的，互相可以給互相發(fā)送，所以就需要雙向斷開(kāi)，四次揮手
https
https = http + ssl/tls
那么他的協(xié)議棧是什么樣子呢？
http SSL/TLS > 應(yīng)用層,或者說(shuō)應(yīng)用層之下，傳輸層之上
tcp > 傳輸層
IP > 網(wǎng)絡(luò)層
https 連接建立流程
首先客戶(hù)端向server端發(fā)送一個(gè)報(bào)文，包含TLS版本號(hào)和所支持的加密算法和一個(gè)隨機(jī)數(shù) C，三個(gè)重要信息到server端，當(dāng)server端收到之后，返回選定的加密算法和server證書(shū)和一個(gè)隨機(jī)數(shù)S，當(dāng)客戶(hù)端收到之后，先驗(yàn)證server證書(shū)是否合法，然后通過(guò)隨機(jī)數(shù)C，隨機(jī)數(shù)S，和預(yù)主秘鑰組裝一個(gè)會(huì)話秘鑰，然后通過(guò)server端的公鑰對(duì)預(yù)主秘鑰進(jìn)行加密傳輸，server端收到之后，通過(guò)私鑰解密得到預(yù)主秘鑰，然后通過(guò)隨機(jī)數(shù)C，S，和預(yù)主秘鑰，組裝會(huì)話秘鑰。
然后客戶(hù)端向server端發(fā)送加密的握手消息，server端向客戶(hù)端返回加密的握手消息，這樣就建立了連接。
會(huì)話秘鑰：
會(huì)話秘鑰 = 隨機(jī)數(shù) S + 隨機(jī)數(shù) C + 預(yù)主秘鑰，使用的是對(duì)稱(chēng)加密
https 使用了哪些加密手段，原因是什么？
連接過(guò)程中使用非對(duì)稱(chēng)加密，非對(duì)稱(chēng)加密是非常耗時(shí)的
后續(xù)的通信過(guò)程使用的是對(duì)稱(chēng)加密
非對(duì)稱(chēng)加密：
非對(duì)稱(chēng)加密的兩個(gè)非常重要的概念就是公鑰和私鑰，加密用公鑰，解密用私鑰，比如當(dāng)發(fā)送方向接受方發(fā)送 hello word ，首先客戶(hù)端會(huì)使用公鑰對(duì)其進(jìn)行加密，然后將加密后的內(nèi)容發(fā)送出去，當(dāng)接收方收到之后，使用私鑰進(jìn)行解密。
對(duì)稱(chēng)秘鑰：
加密和解密是同一把秘鑰，流程一樣,對(duì)稱(chēng)秘鑰在傳輸過(guò)程中，容易被劫持，那樣就不安全了，而非對(duì)稱(chēng)加密只有公鑰傳輸，私鑰是自己保存的，所以相對(duì)安全一些。
tcp/udp
udp 用戶(hù)數(shù)據(jù)報(bào)協(xié)議
特點(diǎn)：
1. 無(wú)連接：無(wú)需建立連接和釋放連接
2. 不保證可靠傳輸，但盡力傳輸
3. 面向報(bào)文，既不合并也不拆分
面向報(bào)文：
面向報(bào)文的意思是，既不合并也不拆分，意思就是說(shuō)，
1. 應(yīng)用層：應(yīng)用層產(chǎn)生一個(gè)報(bào)文，這個(gè)報(bào)文可能很小，也可能很大，當(dāng)很小的時(shí)候，不做合并，很大的時(shí)候也不做拆分，而是原封不動(dòng)的傳輸。
2. 傳輸層：當(dāng)把應(yīng)用數(shù)據(jù)報(bào)發(fā)到傳輸層之后會(huì)將應(yīng)用層的完整數(shù)據(jù)當(dāng)做傳輸層的數(shù)據(jù)部分，然后加上UDP頭部，發(fā)送到網(wǎng)絡(luò)層
3. 網(wǎng)絡(luò)層：當(dāng)收到傳輸層的數(shù)據(jù)后，將數(shù)據(jù)作為IP數(shù)據(jù)報(bào)的數(shù)據(jù)部分，然后加上IP首部
功能：
1. 復(fù)用
2. 分用
3. 差錯(cuò)檢測(cè)
復(fù)用：傳輸過(guò)程中是IP:端口號(hào)，復(fù)用值得就是多個(gè)端口號(hào)復(fù)用傳輸層UDP協(xié)議然后到IP層，復(fù)用
分用：指得是，從IP層收到數(shù)據(jù)之后，然后傳到UDP傳輸層，然后根據(jù)目標(biāo)端口進(jìn)行分發(fā)，分發(fā)到不同的端口。
差錯(cuò)檢測(cè)：檢驗(yàn)和
tcp
特點(diǎn)
1. 面向連接
2. 可靠傳輸
3. 面向字節(jié)流
4. 流量控制
5. 擁塞控制
1.面向連接：
數(shù)據(jù)傳輸開(kāi)始之前要建立連接，也就是三次握手，數(shù)據(jù)傳輸結(jié)束之后，需要釋放連接，也就是四次揮手
2.可靠傳輸：
1. 無(wú)差錯(cuò)
2. 不丟失
3. 不重復(fù)
4. 按序到達(dá)
可靠傳輸是通過(guò)停止等待協(xié)議實(shí)現(xiàn)的
1. 無(wú)差錯(cuò)情況
2. 超時(shí)重傳
3. 確認(rèn)丟失
4. 確認(rèn)遲到
無(wú)差錯(cuò)情況:
客戶(hù)端發(fā)送M1到server，server回復(fù)確認(rèn)M1 ，發(fā)送M2 ，M3，server都會(huì)回復(fù)相應(yīng)的確認(rèn)報(bào)文
超時(shí)重傳：
客戶(hù)端發(fā)送M1分組報(bào)文，?？赡苣承┰蜻@個(gè)報(bào)文被篡改了，那么server端會(huì)判定為由差錯(cuò)的報(bào)文直接丟棄，或者發(fā)送M1超時(shí)，server收不到，那么客戶(hù)端在一定時(shí)間內(nèi)就收不到server端的確認(rèn)報(bào)文，這時(shí)候客戶(hù)端會(huì)進(jìn)行超時(shí)重傳M1，當(dāng)server收到之后會(huì)返回確認(rèn)報(bào)文。
確認(rèn)丟失：
當(dāng)客戶(hù)端給server端發(fā)送M1的時(shí)候，server端需要給客戶(hù)端回確認(rèn)報(bào)文，當(dāng)這個(gè)確認(rèn)報(bào)文丟失的時(shí)候，客戶(hù)端仍然可以通過(guò)超時(shí)后重傳的邏輯，重新發(fā)送M1，這時(shí)候server會(huì)丟棄重傳的M1，然后重傳給客戶(hù)端一個(gè)確認(rèn)M1報(bào)文
確認(rèn)遲到:
當(dāng)客戶(hù)端想server端發(fā)送M1報(bào)文的時(shí)候，需要server端回確認(rèn)報(bào)文，一段時(shí)間 之后，客戶(hù)端沒(méi)有收到，會(huì)觸發(fā)超時(shí)重傳的邏輯，然后server端回丟失這個(gè)超時(shí)重傳的M1，然后重傳確認(rèn)M1報(bào)文，但是一段時(shí)間之后，前面的server端返回的超時(shí)確認(rèn)M1 報(bào)文，送達(dá)到了客戶(hù)端，這時(shí)候客戶(hù)端收到之后，什么事也不做，只是收到了.
3.面向字節(jié)流
當(dāng)我們發(fā)送方向接收方發(fā)送數(shù)據(jù)的時(shí)候，比如發(fā)送方發(fā)送了20個(gè)字節(jié)，那么tcp并不一定是一次性發(fā)送者20個(gè)字節(jié)，可能是先發(fā)送10個(gè)再發(fā)送10個(gè)，是有tcp自己決定的。
4.流量控制
滑動(dòng)窗口協(xié)議：
發(fā)送窗口：
我們通過(guò)應(yīng)用程序提交給tcp發(fā)送緩存中的數(shù)據(jù)是由字節(jié)編號(hào)的，從小到大，我們發(fā)送的數(shù)據(jù)都是需要server端確認(rèn)的，比如我們現(xiàn)在有一塊發(fā)送緩存,是有字節(jié)編號(hào)，假如有一小塊發(fā)送出去了，那么這塊已發(fā)送出去的緩存的開(kāi)始位置，就是最后被確認(rèn)的字節(jié)，在已發(fā)送的右側(cè)是最后發(fā)送的字節(jié)，我們的發(fā)送窗口要比這個(gè)緩存要小一點(diǎn)，比發(fā)送的數(shù)據(jù)要大一點(diǎn)，我們把已發(fā)送數(shù)據(jù)的左側(cè)稱(chēng)為發(fā)送窗口的前檐，右側(cè)稱(chēng)之為發(fā)送窗口的右檐或者后檐。
我們發(fā)送窗口的大小一方面由發(fā)送緩存決定，另一方面也是有接收方來(lái)確定的，如果我們接收方處理數(shù)據(jù)能力比較弱或者網(wǎng)絡(luò)不好，接受速率慢，如果我們發(fā)送的快，那么會(huì)導(dǎo)致接收方緩存大量緩存甚至溢出，所以接收方也會(huì)決定發(fā)送方的發(fā)送窗口大小，告訴發(fā)送方還可以發(fā)送多少字節(jié)，發(fā)送窗口和接受窗口為位于tcp首部的兩個(gè)字段的，通過(guò)調(diào)整發(fā)送窗口的大小，進(jìn)而調(diào)整發(fā)送速率，從而調(diào)整流量控制。
接收窗口：
接收方也是有緩存的,我們想向應(yīng)用程序提交數(shù)據(jù)的時(shí)候，必須是有序的,我們應(yīng)用程序能讀取的字節(jié)，就是前面按序到達(dá)的數(shù)據(jù)，對(duì)于接收窗口來(lái)說(shuō)，有大小限制的，取決于接受緩存，可以根據(jù)接受窗口的大小,通過(guò)tcp的首部值，反向制約發(fā)送方的發(fā)送窗口大小，來(lái)保證不溢出，按序到達(dá)可以通過(guò)字節(jié)順序來(lái)控制。
5.擁塞控制
1. 慢開(kāi)始，擁塞避免
2. 快恢復(fù)，快重傳
慢開(kāi)始，擁塞避免：
慢開(kāi)始：比如一開(kāi)始我們可以發(fā)送一個(gè)報(bào)文，如果沒(méi)有擁塞，下次發(fā)送兩個(gè)報(bào)文，如果還沒(méi)有，下次四個(gè)，八個(gè)，成指數(shù)形式增長(zhǎng)，也就是慢開(kāi)始方法。
當(dāng)增長(zhǎng)到我們的窗口值16的時(shí)候，會(huì)通過(guò)擁塞控制的手段，進(jìn)行增長(zhǎng)，比如17，18，呈線性增長(zhǎng)，當(dāng)我們發(fā)送的報(bào)文數(shù)，達(dá)到24的時(shí)候，可能發(fā)送擁塞，比如我們連續(xù)三個(gè)ack都沒(méi)有收到，我們就認(rèn)為網(wǎng)絡(luò)擁塞了，此時(shí)就采用擁塞避免的乘法減小的策略，只發(fā)送一個(gè)，來(lái)減小擁塞，再重新進(jìn)行慢開(kāi)始，并把擁塞窗口值，降到一半，比如以前24，現(xiàn)在12，在我們沒(méi)有達(dá)到窗口值得時(shí)候采用指數(shù)增長(zhǎng)，當(dāng)達(dá)到了之后，采用擁塞避免的方法進(jìn)行加法增大，這個(gè)過(guò)程就構(gòu)成了擁塞控制的方案。
快恢復(fù)，快重傳：
是基于慢開(kāi)始產(chǎn)生的，當(dāng)我們達(dá)到擁塞窗口閾值之后，回到一個(gè)新的閾值，然后進(jìn)行慢開(kāi)始，擁塞避免
DNS
DNS 解析其實(shí)是域名到IP的映射，DNS 請(qǐng)求采用 UDP 數(shù)據(jù)報(bào)，是明文的
客戶(hù)端向DNS服務(wù)器發(fā)送一個(gè)請(qǐng)求，然后DNS服務(wù)器返回給客戶(hù)端一堆IP，然后客戶(hù)端拿著這個(gè)IP，向IP服務(wù)器發(fā)起請(qǐng)求
遞歸查詢(xún)：
詢(xún)問(wèn)的方式
client-本地DNS-根域DNS-頂級(jí)DNS-權(quán)威DNS
注意上面是雙向的，意思就是說(shuō)，我們發(fā)起一個(gè)DNS解析的時(shí)候，首先會(huì)問(wèn)本地DNS是否有，如果沒(méi)有向根域DNS發(fā)起請(qǐng)求，如果還沒(méi)有，向頂級(jí)DNS發(fā)起請(qǐng)求，如果還沒(méi)有就去問(wèn)權(quán)威DNS，然后依次回答，一直到客戶(hù)端。
迭代查詢(xún)：
原則是誰(shuí)可能知道。
比如我們客戶(hù)端發(fā)起一個(gè)域名解析，客戶(hù)端向本地DNS發(fā)起一個(gè)請(qǐng)求，本地DNS去請(qǐng)求頂級(jí)DNS，頂級(jí)DNS查詢(xún)不到，然后告訴本地DNS，根域DNS知道，然后本地DNS就像根域DNS發(fā)起請(qǐng)求，這時(shí)候根域DNS也不知道，就告訴本地DNS，權(quán)威DNS知道，然后本地DNS就像權(quán)威DNS發(fā)起請(qǐng)求，然后權(quán)限D(zhuǎn)NS就告訴本地DNS，本地DNS告訴客戶(hù)端。
DNS 解析可能出現(xiàn)的問(wèn)題
1. DNS 劫持
2. DNS 解析轉(zhuǎn)發(fā)問(wèn)題
DNS 劫持：
比如我們客戶(hù)端向DNS服務(wù)器發(fā)起一個(gè)請(qǐng)求，來(lái)獲取域名對(duì)應(yīng)的IP，由于我們的DNS解析過(guò)程是UDP數(shù)據(jù)報(bào)明文傳輸，就有可能被竊聽(tīng)，這時(shí)候有個(gè)釣魚(yú)的DNS服務(wù)器，劫持了我們的請(qǐng)求，然后返回給我們一個(gè)錯(cuò)誤的IP，這時(shí)候我們就回去訪問(wèn)一個(gè)錯(cuò)誤的服務(wù)器
DNS 劫持和http有關(guān)系嗎？他們是沒(méi)有關(guān)系：
DNS 解析是發(fā)生在http建立連接之前的
DNS 解析請(qǐng)求使用udp 數(shù)據(jù)報(bào)，訪問(wèn)53端口號(hào)
DNS 解析轉(zhuǎn)發(fā)
比如我們現(xiàn)在客戶(hù)端要去解析一個(gè)域名，想本地DNS服務(wù)器發(fā)起請(qǐng)求，我們可能是移動(dòng)運(yùn)營(yíng)商，這時(shí)候移動(dòng)可能會(huì)把這個(gè)請(qǐng)求轉(zhuǎn)發(fā)給電信DNS服務(wù)器，然后電信DNS服務(wù)器會(huì)根據(jù)不同的請(qǐng)求解析出不同的IP，此時(shí)電信的DNS服務(wù)器可能解析出，移動(dòng)的IP為：2.2.2.2，電信的IP為：3.3.3.3，然后把電信的IP返回回去了，這時(shí)候我們客戶(hù)端連接的就是電信運(yùn)營(yíng)商,會(huì)出現(xiàn)跨運(yùn)營(yíng)商訪問(wèn)的問(wèn)題，就會(huì)出現(xiàn)連接緩慢等問(wèn)題.
怎樣解決 DNS 劫持
1. HTTPDNS
2. 長(zhǎng)連接
DNS 解析兩種方式第一種是通過(guò)DNS協(xié)議想DNS服務(wù)器發(fā)起53端口的請(qǐng)求，而HTTPDNS是通過(guò)http協(xié)議向DNS服務(wù)器的80協(xié)議進(jìn)行請(qǐng)求
解決方案：
我們的HTTPDNS解析是通過(guò)IP直連的方式進(jìn)行的，http://119.29.29.29/dn=xxx.xxx.xxx,&ip=,這是一個(gè)狠強(qiáng)大的DNSserver，當(dāng)我們請(qǐng)求了這個(gè)服務(wù)器之后，會(huì)返回給我們響應(yīng)的IP地址，然后我們?cè)L問(wèn)就可以了。
長(zhǎng)連接方案：
為了避免公網(wǎng)DNS劫持的問(wèn)題，我們可以和在和我們的APIserver進(jìn)行交互的時(shí)候，在中間和一個(gè)長(zhǎng)連server進(jìn)行交互，我們和長(zhǎng)連server進(jìn)行一個(gè)tcp長(zhǎng)連通道,然后通過(guò)長(zhǎng)連server通過(guò)內(nèi)網(wǎng)專(zhuān)線，向我們的APIserver發(fā)起請(qǐng)求就可以了.
Session/Cookie
session/cookie 是對(duì)http無(wú)狀態(tài)特點(diǎn)的補(bǔ)償
比如我們現(xiàn)在進(jìn)行網(wǎng)絡(luò)請(qǐng)求，我們多次進(jìn)行網(wǎng)絡(luò)請(qǐng)求，server是不知道是不是同一個(gè)用戶(hù)的，比如我們進(jìn)行購(gòu)買(mǎi)一個(gè)商品，我們?cè)俅卧L問(wèn)購(gòu)買(mǎi)一個(gè)商品，由于http無(wú)狀態(tài)的特點(diǎn)，server不知道是不是之前的某一個(gè)用戶(hù)
cookie
cookie 主要是用來(lái)記錄用戶(hù)狀態(tài)的，區(qū)分用戶(hù)，狀態(tài)是保存在客戶(hù)端的
但我們客戶(hù)端進(jìn)行http請(qǐng)求的時(shí)候，server會(huì)生成一個(gè)cookie，會(huì)通過(guò)http響應(yīng)報(bào)文，在報(bào)文頭部添加一個(gè)字段，然后把cookie傳給客戶(hù)端，客戶(hù)端將這個(gè)cookie保存下來(lái)，客戶(hù)端在后續(xù)的http請(qǐng)求，把之前的cookie添加到http的請(qǐng)求報(bào)文的頭部添加cookie字段，傳給server就可以了
客戶(hù)端發(fā)送的Cookie在http請(qǐng)求報(bào)文的Cookie首部字段中
服務(wù)端設(shè)置http響應(yīng)報(bào)文的Set-Cookie首部字段返回給客戶(hù)端
怎樣修改cookie？
- 通過(guò)新 Cookie 覆蓋舊的，覆蓋原則，name,path,domain等需要和遠(yuǎn)cookie保持一致才可以覆蓋，字段要一致
怎樣刪除 Cookie：
也是通過(guò)覆蓋
- 新 Cookie 覆蓋舊的Cookie
- 覆蓋規(guī)則，字段要和原來(lái)保持一致
- 設(shè)置 Cookie 的 expires=過(guò)去的一個(gè)時(shí)間點(diǎn)或者maxAge=0
怎樣保證cookie安全？
1. 對(duì) cookie 進(jìn)行加密處理
2. 只在 https 上攜帶 cookies
3. 設(shè)置 cookie 為 httpOnly，防止跨站腳本攻擊
session
session也是用來(lái)記錄用戶(hù)狀態(tài)，區(qū)別用戶(hù)的，狀態(tài)存放在服務(wù)端的
關(guān)系：
session 需要依賴(lài) cookie 的機(jī)制來(lái)實(shí)現(xiàn)
session 工作流程：
當(dāng)客戶(hù)端向server端發(fā)送請(qǐng)求的，server會(huì)根據(jù)這個(gè)用戶(hù)生成一個(gè)sessionID，然后當(dāng)給客戶(hù)端返回給客戶(hù)端相應(yīng)報(bào)文的時(shí)候嗎，會(huì)通過(guò)http相應(yīng)頭部的Set-Cookie,將sessionID同步給客戶(hù)端，然后客戶(hù)端下次請(qǐng)求的時(shí)候，將這個(gè)sessionID放到http請(qǐng)求頭的Cookie字段，給server，那么server就知道是哪個(gè)用戶(hù)了。
