網(wǎng)絡(luò)
OSI 七層模型？追問：Socket 在哪一層？WebSocket 有沒有用過？
互聯(lián)網(wǎng)協(xié)議按照功能不同分為osi七層和tcp/ip五層或tcp/ip四層，如下圖：
套接字是工作在傳輸層和應(yīng)用層之間的一個(gè)接口，將復(fù)雜的tcp/udp協(xié)議隱藏在了socket接口后面
并沒有用過，做以下了解：
WebSocket 是 HTML5 一種新的協(xié)議。它實(shí)現(xiàn)了瀏覽器與服務(wù)器全雙工通信，能更好的節(jié)省服務(wù)器資源和帶寬并達(dá)到實(shí)時(shí)通訊，它建立在 TCP 之上，同 HTTP 一樣通過 TCP 來傳輸數(shù)據(jù)，但是它和 HTTP 最大不同是：WebSocket 是一種雙向通信協(xié)議.
你怎么理解分層和協(xié)議？
A. 如何理解分層
分層的理由:
-
獨(dú)立性
通過分層，每一層值接受下一層提供的特定服務(wù)，并且負(fù)責(zé)為上一層提供特定服務(wù)，上下層之間進(jìn)行交互所遵循的約定叫“接口”，同一層之間的交互所遵循的約定叫做“協(xié)議”。每一層可以獨(dú)立使用，及時(shí)系統(tǒng)中某些層次發(fā)生變化，也不會(huì)波及系統(tǒng)。 -
靈活性好
對(duì)于任何一層的改動(dòng)，只要上下層接口不變，都不會(huì)造成系統(tǒng)的問題，有利于每一層功能的擴(kuò)展和變動(dòng)。 -
易于實(shí)現(xiàn)和維護(hù)
將大問題簡(jiǎn)化為小問題，大系統(tǒng)簡(jiǎn)化為小層次。比如將網(wǎng)絡(luò)的通信過程劃分為小一些、簡(jiǎn)單一些的部件,因此有助于各個(gè)部件的開發(fā)、設(shè)計(jì)和故障排除。 -
能促進(jìn)標(biāo)準(zhǔn)化工作
通過分層，定義在模型的每一層實(shí)現(xiàn)什么功能,有利于鼓勵(lì)產(chǎn)業(yè)的標(biāo)準(zhǔn)化，同時(shí)允許多個(gè)供應(yīng)商進(jìn)行開發(fā)。
分層的原則：
- 各個(gè)層之間有清晰的邊界,便于理解;
- 每個(gè)層實(shí)現(xiàn)特定的功能;
- 層次的劃分有利于國(guó)際標(biāo)準(zhǔn)協(xié)議的制定;
- 層的數(shù)目應(yīng)該足夠多，以避免各個(gè)層功能重復(fù)
B. 如何理解協(xié)議
協(xié)議實(shí)際上是一種通信雙方共同遵守的規(guī)范。比如我需要把性別和年齡傳遞給另外一臺(tái)主機(jī)，那么我可以定義一個(gè)"A 協(xié)議"，協(xié)議規(guī)定數(shù)據(jù)的前 4 個(gè)字節(jié)表示性別，后四個(gè)字節(jié)表示年齡。這樣對(duì)方主機(jī)接收時(shí)就知道前 4 個(gè)字節(jié)是性別，而不會(huì)錯(cuò)把它當(dāng)成年齡來處理。
協(xié)議的規(guī)范和共同遵守，有利于各個(gè)分層之間的交流和處理，也有利于促進(jìn)協(xié)議的標(biāo)準(zhǔn)化過程。
路由器和交換機(jī)的工作原理大概是什么，他們分別用到什么協(xié)議，位于哪一層
交換機(jī):
二層交換機(jī):
二層交換機(jī)是一種在數(shù)據(jù)鏈路層工作的網(wǎng)絡(luò)設(shè)備，一般要求支持802.1q（就是劃VLAN）、SNMP、限速、廣播風(fēng)暴控制、ACL、組播這些常見的功能；它有多個(gè)端口，可以連接不同的設(shè)備。交換機(jī)根據(jù)每個(gè)幀中的目標(biāo) MAC 地址決定向哪個(gè)端口發(fā)送數(shù)據(jù)，此時(shí)它需要參考“轉(zhuǎn)發(fā)表”
轉(zhuǎn)發(fā)表并非手動(dòng)設(shè)置，而是交換機(jī)自動(dòng)學(xué)習(xí)得到的。當(dāng)某個(gè)設(shè)備向交換機(jī)發(fā)送幀時(shí)，交換機(jī)將幀的源 MAC 地址和接口對(duì)應(yīng)起來，作為一條記錄添加到轉(zhuǎn)發(fā)表中。
下圖描述了交換機(jī)自學(xué)過程的原理：
三層交換機(jī)
三層交換機(jī)具有路由器功能，工作在網(wǎng)絡(luò)層，在二層的基礎(chǔ)上支持如靜態(tài)路由、RIP(矢量路由選擇協(xié)議)、OSPF(鏈路狀態(tài)路由選擇協(xié)議)、BGP(邊界網(wǎng)關(guān)協(xié)議)、ISIS(分級(jí)的鏈接狀態(tài)路由協(xié)議)等路由協(xié)議，有時(shí)候會(huì)要求支持MPLS(多協(xié)議標(biāo)簽交換)、GRE(通用路由封裝協(xié)議)、L2TP(工業(yè)標(biāo)準(zhǔn)的Internet隧道協(xié)議)、IPSec(Internet 協(xié)議安全性)等隧道協(xié)議。三層交換機(jī)上能夠?qū)Ψ纸M報(bào)文根據(jù)IP地址進(jìn)行轉(zhuǎn)發(fā)。
四到七層交換機(jī)
負(fù)責(zé)處理OSI模型中從傳輸層至應(yīng)用層的數(shù)據(jù)。如果用TCP/IP分層模型來表述，4-7層交換機(jī)就是以傳輸層及其上面的應(yīng)用層為基礎(chǔ)，進(jìn)行分析數(shù)據(jù)，并對(duì)其進(jìn)行特定的處理。
例如：對(duì)于并發(fā)訪問量非常大的一個(gè)企業(yè)級(jí)Web站點(diǎn)，使用一臺(tái)服務(wù)器不足以滿足前端的訪問需要，這時(shí)通常會(huì)通過多臺(tái)服務(wù)器來分擔(dān)，這些服務(wù)器前端訪問的入口地址通常只有一個(gè)（企業(yè)為了使用者的方便，只會(huì)向最終的用戶開放一個(gè)統(tǒng)一的訪問URL）。為了能通過同一個(gè)URL將前端訪問分發(fā)到后臺(tái)多個(gè)服務(wù)器上，可以在這些服務(wù)器的前端加一個(gè)負(fù)載均衡器。這種負(fù)載均衡器就是4-7層交換機(jī)的一種。
此外，實(shí)際通信當(dāng)中，人們希望在網(wǎng)絡(luò)比較擁堵的時(shí)候，優(yōu)先處理像語音這類對(duì)及時(shí)性要求較高的通信請(qǐng)求，放緩處理像郵件或數(shù)據(jù)轉(zhuǎn)發(fā)等稍有延遲也并無大礙的通信請(qǐng)求，這種處理被稱為寬帶控制，也是4-7層交換機(jī)的重要功能，還有其他很多功能，例如廣域網(wǎng)加速器，特殊應(yīng)用訪問加速以及防火墻等。
路由器
路由器工作在網(wǎng)絡(luò)層，完成通過路由控制將分組數(shù)據(jù)發(fā)送到目標(biāo)地址的功能。支持如靜態(tài)路由、RIP(矢量路由選擇協(xié)議)、OSPF(鏈路狀態(tài)路由選擇協(xié)議)、BGP(邊界網(wǎng)關(guān)協(xié)議)、EGP(外部網(wǎng)關(guān)協(xié)議)、ISIS(分級(jí)的鏈接狀態(tài)路由協(xié)議)等路由協(xié)議。
路由器中保存著路由控制表，它在路由控制表中查找目標(biāo)IP地址對(duì)應(yīng)的下一個(gè)路由器地址。下圖描述了這一過程：
主機(jī)A的地址是10.1.1.30,要把數(shù)據(jù)發(fā)往地址為10.1.2.10的主機(jī)。在主機(jī)A的路由表中，保存了兩個(gè)字段，由于目標(biāo)地址10.1.2.10與10.1.1.0/24段不匹配，所以它被發(fā)往默認(rèn)路由10.1.1.1也就是圖中路由器1的左側(cè)網(wǎng)卡的IP地址。
路由器1繼續(xù)在它自己的路由控制表中查找目標(biāo)地址10.1.2.10，它發(fā)現(xiàn)目標(biāo)地址屬于10.1.2.0/24這一段，因此將數(shù)據(jù)轉(zhuǎn)發(fā)至下一個(gè)路由器10.1.0.2，也就是路由器2的左側(cè)網(wǎng)卡的地址。
路由器2在自己的路由控制表中查找目標(biāo)地址10.1.2.10，根據(jù)表中記錄將數(shù)據(jù)發(fā)往10.1.2.1接口，也就是自己的右側(cè)網(wǎng)卡的IP地址。主機(jī)B檢查目標(biāo)IP地址和自己相同，于是接收數(shù)據(jù)。
[網(wǎng)絡(luò)面試問題]](http://www.itdecent.cn/p/5553ada4a881)
簡(jiǎn)介 TCP 和 UDP 區(qū)別，他們位于哪一層？
TCP 和 UDP 位于OSI 七層模型的第四層：傳輸層，區(qū)別如下：
1、連接性:
TCP 面向連接（如打電話要先撥號(hào)建立連接）;
UDP 是面向無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接
2、可靠性：
TCP 提供可靠的服務(wù)。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯(cuò)，不丟失，不重復(fù)，且按序到達(dá);
UDP盡最大努力交付，即不保證可靠交付
3、傳輸內(nèi)容：
TCP面向字節(jié)流，實(shí)際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;
UDP是面向報(bào)文的，UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低（對(duì)實(shí)時(shí)應(yīng)用很有用，如IP電話，實(shí)時(shí)視頻會(huì)議等）
4、服務(wù)性質(zhì)：
TCP連接只能是點(diǎn)到點(diǎn)的;
UDP支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信
5、開銷：
TCP首部開銷20字節(jié);
UDP的首部開銷小，只有8個(gè)字節(jié)
6、信道
TCP的邏輯通信信道是全雙工的可靠信道
UDP則是不可靠信道
描述TCP 協(xié)議三次握手，四次釋放的過程？
TCP 三次握手
第一次握手:
客戶端將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個(gè)序列值seq = x，并將該數(shù)據(jù)包發(fā)送給服務(wù)端,客戶端進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)端確認(rèn)。第二次握手:
服務(wù)端·收到數(shù)據(jù)包后由標(biāo)志位SYN=1，知道客戶端請(qǐng)求建立連接，服務(wù)端將標(biāo)志位SYN和ACK都置為1，ack = x + 1，隨機(jī)產(chǎn)生一個(gè)值seq = y, 并將該數(shù)據(jù)包發(fā)送給客戶端以確認(rèn)連接請(qǐng)求，服務(wù)端進(jìn)入SYN_RCVD狀態(tài)。-
第三次握手:
客戶端收到確認(rèn)后，檢查ack是否為x+1，ACK是否為1，如果正確將標(biāo)志位ACK置為1，ack = y + 1, 并將該數(shù)據(jù)包發(fā)送給服務(wù)端,服務(wù)端檢查ack是否為y+1，ACK是否為1，如果都正確則連接建立成功，客戶端和服務(wù)端進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，隨后客戶端與服務(wù)端之間開始進(jìn)行數(shù)據(jù)傳輸。
TCP 四次揮手
-
第一次揮手:
客戶端發(fā)出連接釋放報(bào)文，并且停止發(fā)送數(shù)據(jù)。將釋放數(shù)據(jù)報(bào)文首部的FIN置為1，序列號(hào)seq置為u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1），此時(shí)，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)。TCP規(guī)定，FIN報(bào)文段即使不攜帶數(shù)據(jù)，也要消耗一個(gè)序號(hào)。 -
第二次揮手:
服務(wù)端收到報(bào)文后，檢查到首部的FIN為1，知道客戶端請(qǐng)求釋放連接，服務(wù)端發(fā)出確認(rèn)報(bào)文，并將報(bào)文首部的ACK置為1，ack置為u + 1,并且?guī)献约旱?code>序列號(hào)v,此時(shí)服務(wù)端進(jìn)入CLOSE-WAIT(關(guān)閉等待狀態(tài))。客戶端收到服務(wù)端的確認(rèn)報(bào)文后，檢查ACK是否為1，ack是否為u+1,如果都正確，客戶端進(jìn)入FIN-WAIT-2(終止等待2)狀態(tài)。等待服務(wù)端發(fā)送連接釋放報(bào)文。 -
第三次揮手:
服務(wù)端將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報(bào)文，FIN=1,ack = u+1,序列號(hào)為seq = w(因?yàn)樵诎腙P(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時(shí)的序列號(hào)為seq=w)，此時(shí)服務(wù)端進(jìn)入LASK-ACK(最后確認(rèn))狀態(tài)，等待客戶端確認(rèn)。 -
第四次揮手:
客戶端接收服務(wù)器的報(bào)文后，檢查FIN為1，知道服務(wù)端請(qǐng)求釋放連接，發(fā)出確認(rèn)報(bào)文，ACK = 1，ack = w + 1,seq = u + 1, 此時(shí)客戶端進(jìn)入TIME-WAIT(時(shí)間等待)狀態(tài)。注意此時(shí)TCP連接還沒有釋放，必須經(jīng)過2?MSL（最長(zhǎng)報(bào)文段壽命）的時(shí)間后，當(dāng)客戶端撤銷相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。服務(wù)端只要收到客戶端發(fā)出的確認(rèn)報(bào)文，檢查ACK是否為1，ack是否為w + 1, 如果都正確，立即進(jìn)入CLOSE狀態(tài)。
TCP 三次握手過程？
結(jié)合TCP報(bào)文結(jié)構(gòu)來看會(huì)比較清晰：
1、TCP服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊TCB，時(shí)刻準(zhǔn)備接受客戶進(jìn)程的連接請(qǐng)求，此時(shí)服務(wù)器就進(jìn)入了LISTEN（監(jiān)聽）狀態(tài)；
2、TCP客戶進(jìn)程也是先創(chuàng)建傳輸控制塊TCB，然后向服務(wù)器發(fā)出連接請(qǐng)求報(bào)文，這是報(bào)文首部中的同部位SYN=1，同時(shí)選擇一個(gè)初始序列號(hào) seq=x ，此時(shí)，TCP客戶端進(jìn)程進(jìn)入了SYN-SENT（同步已發(fā)送狀態(tài)）狀態(tài)。TCP規(guī)定，SYN報(bào)文段（SYN=1的報(bào)文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個(gè)序號(hào)。
3、TCP服務(wù)器收到請(qǐng)求報(bào)文后，如果同意連接，則發(fā)出確認(rèn)報(bào)文。確認(rèn)報(bào)文中應(yīng)該 ACK=1，SYN=1，確認(rèn)號(hào)是ack=x+1，同時(shí)也要為自己初始化一個(gè)序列號(hào) seq=y，此時(shí)，TCP服務(wù)器進(jìn)程進(jìn)入了SYN-RCVD（同步收到）狀態(tài)。這個(gè)報(bào)文也不能攜帶數(shù)據(jù)，但是同樣要消耗一個(gè)序號(hào)。
4、TCP客戶進(jìn)程收到確認(rèn)后，還要向服務(wù)器給出確認(rèn)。確認(rèn)報(bào)文的ACK=1，ack=y+1，自己的序列號(hào)seq=x+1，此時(shí)，TCP連接建立，客戶端進(jìn)入ESTABLISHED（已建立連接）狀態(tài)。TCP規(guī)定，ACK報(bào)文段可以攜帶數(shù)據(jù)，但是如果不攜帶數(shù)據(jù)則不消耗序號(hào)。
5、當(dāng)服務(wù)器收到客戶端的確認(rèn)后也進(jìn)入ESTABLISHED狀態(tài)，此后雙方就可以開始通信了。
參考：
TCP 四次揮手過程？
1、客戶端進(jìn)程發(fā)出連接釋放報(bào)文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報(bào)文首部，F(xiàn)IN=1，其序列號(hào)為seq=u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1），此時(shí)，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)。TCP規(guī)定，F(xiàn)IN報(bào)文段即使不攜帶數(shù)據(jù)，也要消耗一個(gè)序號(hào)。
2、服務(wù)器收到連接釋放報(bào)文，發(fā)出確認(rèn)報(bào)文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑?hào)seq=v，此時(shí)，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器通知高層的應(yīng)用進(jìn)程，客戶端向服務(wù)器的方向就釋放了，這時(shí)候處于半關(guān)閉狀態(tài)，即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個(gè)狀態(tài)還要持續(xù)一段時(shí)間，也就是整個(gè)CLOSE-WAIT狀態(tài)持續(xù)的時(shí)間。
3、客戶端收到服務(wù)器的確認(rèn)請(qǐng)求后，此時(shí)，客戶端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報(bào)文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。
4、服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報(bào)文，F(xiàn)IN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時(shí)的序列號(hào)為seq=w，此時(shí)，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)。
5、客戶端收到服務(wù)器的連接釋放報(bào)文后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號(hào)是seq=u+1，此時(shí)，客戶端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)。注意此時(shí)TCP連接還沒有釋放，必須經(jīng)過2?MSL（最長(zhǎng)報(bào)文段壽命）的時(shí)間后，當(dāng)客戶端撤銷相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。
6、服務(wù)器只要收到了客戶端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。同樣，撤銷TCB后，就結(jié)束了這次的TCP連接。可以看到，服務(wù)器結(jié)束TCP連接的時(shí)間要比客戶端早一些。
參考：
如何改進(jìn)TCP
采取一塊確認(rèn)的機(jī)制
UDP是全雙工嗎？
所謂全雙工，半雙工，單工是指面向連接時(shí)才有的說法，如果不是面向連接的，沒有一個(gè)確定的連接的話，怎么會(huì)出現(xiàn)半雙工這種只準(zhǔn)一個(gè)來或者一個(gè)去的說法呢？
UDP支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信。如果一定要涉及到全雙工的話，大概理解為不僅提供全雙工，甚至提供全多工服務(wù)，只是UDP是不可靠的服務(wù)而已。
為什么要等待2MSL？
MSL（Maximum Segment Lifetime），TCP允許不同的實(shí)現(xiàn)可以設(shè)置不同的MSL值。
一、保證客戶端發(fā)送的最后一個(gè)ACK報(bào)文能夠到達(dá)服務(wù)器
因?yàn)檫@個(gè)ACK報(bào)文可能丟失，站在服務(wù)器的角度看來，我已經(jīng)發(fā)送了FIN+ACK報(bào)文請(qǐng)求斷開了，客戶端還沒有給我回應(yīng)，應(yīng)該是我發(fā)送的請(qǐng)求斷開報(bào)文它沒有收到，于是服務(wù)器又會(huì)重新發(fā)送一次，而客戶端就能在這個(gè)2MSL時(shí)間段內(nèi)收到這個(gè)重傳的報(bào)文，接著給出回應(yīng)報(bào)文，并且會(huì)重啟2MSL計(jì)時(shí)器。
二、防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請(qǐng)求報(bào)文段”出現(xiàn)在本連接中。
客戶端發(fā)送完最后一個(gè)確認(rèn)報(bào)文后，在這個(gè)2MSL時(shí)間中，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣新的連接中不會(huì)出現(xiàn)舊連接的請(qǐng)求報(bào)文。
為什么建立連接時(shí)是三次握手，兩次行不行？如果第三次握手失敗了怎么處理
A. 為什么是三次握手:
- 為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤。
- 因?yàn)樵诰W(wǎng)絡(luò)請(qǐng)求中，我們應(yīng)該時(shí)刻記?。骸熬W(wǎng)絡(luò)是不可靠的，數(shù)據(jù)包是可能丟失的”。
- 假設(shè)沒有第三次確認(rèn)，
客戶端向服務(wù)端發(fā)送了SYN，請(qǐng)求建立連接。由于延遲，服務(wù)端沒有及時(shí)收到這個(gè)包。于是客戶端重新發(fā)送一個(gè)SYN包?；貞浺幌陆榻BTCP 首部時(shí)提到的序列號(hào)，這兩個(gè)包的序列號(hào)顯然是相同的。 - 假設(shè)服務(wù)端接收到了
第二個(gè) SYN 包，建立了通信，一段時(shí)間后通信結(jié)束，連接被關(guān)閉。這時(shí)候最初被發(fā)送的SYN 包剛剛抵達(dá)服務(wù)端，服務(wù)端又會(huì)發(fā)送一次ACK確認(rèn)。由于兩次握手就建立了連接，此時(shí)的服務(wù)端就會(huì)建立一個(gè)新的連接，然而客戶端覺得自己并沒有請(qǐng)求建立連接，所以就不會(huì)向服務(wù)端發(fā)送數(shù)據(jù)。從而導(dǎo)致服務(wù)端建立了一個(gè)空的連接，白白浪費(fèi)資源。 - 在三次握手的情況下，
服務(wù)端直到收到客戶端的應(yīng)答后才會(huì)建立連接。因此在上述情況下，客戶端會(huì)接受到一個(gè)相同的ACK 包，這時(shí)候它會(huì)拋棄這個(gè)數(shù)據(jù)包，不會(huì)和服務(wù)端進(jìn)行第三次握手，因此避免了服務(wù)端建立空的連接。
B. 第三次握手失敗了怎么處理
- 按照
TCP 協(xié)議處理丟包的一般方法，服務(wù)端會(huì)重新向客戶端發(fā)送數(shù)據(jù)包，直至收到ACK 確認(rèn)為止。但實(shí)際上這種做法有可能遭到SYN 泛洪攻擊。所謂的泛洪攻擊，是指發(fā)送方偽造多個(gè) IP 地址，模擬三次握手的過程。當(dāng)服務(wù)器返回ACK后，攻擊方故意不確認(rèn)，從而使得服務(wù)器不斷重發(fā)ACK。由于服務(wù)器長(zhǎng)時(shí)間處于半連接狀態(tài)，最后消耗過多的CPU和內(nèi)存資源導(dǎo)致死機(jī)。 - 正確處理方法是
服務(wù)端發(fā)送RST 報(bào)文，進(jìn)入CLOSE狀態(tài)。這個(gè)RST數(shù)據(jù)包的TCP首部中，控制位中的RST 位被設(shè)置為1。這表示連接信息全部被初始化，原有的TCP通信不能繼續(xù)進(jìn)行?？蛻舳巳绻€想重新建立TCP連接，就必須重新開始第一次握手。
關(guān)閉連接時(shí)，第四次握手失敗怎么處理？
實(shí)際上，在第三步中，客戶端收到FIN 包時(shí)，它會(huì)設(shè)置一個(gè)計(jì)時(shí)器，等待相當(dāng)長(zhǎng)的一段時(shí)間。如果客戶端返回的ACK 丟失，那么服務(wù)端還會(huì)重發(fā)FIN并重置計(jì)時(shí)器。假設(shè)在計(jì)時(shí)器失效前服務(wù)器重發(fā)的 FIN 包沒有到達(dá)客戶端，客戶端就會(huì)進(jìn)入 CLOSE狀態(tài)，從而導(dǎo)致服務(wù)端永遠(yuǎn)無法收到 ACK 確認(rèn)，也就無法關(guān)閉連接。
示意圖如下：
為什么TCP握手是三次，揮手卻是四次？（假設(shè)客戶端主動(dòng)，服務(wù)器端被動(dòng)）
在TCP三次握手中，服務(wù)器端的SYN和ACK是放在一個(gè)TCP報(bào)文段中向客戶端發(fā)送的，而在斷開連接的過程中，服務(wù)器端向客戶端發(fā)送的ACK和FIN是是分別在兩個(gè)不同的TCP報(bào)文段中。這是因?yàn)樵?code>服務(wù)器端接收到客戶端的FIN后，服務(wù)器端可能還有數(shù)據(jù)要傳輸，所以先發(fā)送ACK，服務(wù)器端把數(shù)據(jù)發(fā)完之后就可以發(fā)送FIN斷開連接了。
為什需要三次握手？
《計(jì)算機(jī)網(wǎng)絡(luò)》第四版中講“三次握手”的目的是“為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤”
書中的例子是這樣的，“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。
假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒有要求建立連接?！薄Ｖ饕康姆乐箂erver端一直等待，浪費(fèi)資源。
參考：
從輸入U(xiǎn)RL到頁(yè)面展示，到底發(fā)生了什么
TCP如何保證可靠傳輸
數(shù)據(jù)包校驗(yàn)
超時(shí)重傳機(jī)制
應(yīng)答機(jī)制
對(duì)失序數(shù)據(jù)包重排序
TCP還能提供流量控制
TCP 協(xié)議是如何進(jìn)行流量控制，擁塞控制的？
A. 如何進(jìn)行流量控制:
-
流量控制以動(dòng)態(tài)調(diào)整發(fā)送空間大小(滑動(dòng)窗口)的形式來反映接收端接收消息的能力，反饋給發(fā)送端以調(diào)整發(fā)送速度，避免發(fā)送速度過快導(dǎo)致的丟包或者過慢降低整體性能。 - 這里采用
滑動(dòng)窗口機(jī)制，一是不用每次發(fā)送完成都需要等待收到確認(rèn)消息才能繼續(xù)發(fā)送，二是參考接收端的接收能力，限制發(fā)送數(shù)據(jù)段大小，避免丟失現(xiàn)象。
B. 如何進(jìn)行擁塞控制：
- 連接建立的初期，如果
窗口比較大，發(fā)送方可能會(huì)突然發(fā)送大量數(shù)據(jù)，導(dǎo)致網(wǎng)絡(luò)癱瘓。因此，在通信一開始時(shí)，TCP會(huì)通過慢啟動(dòng)算法得出窗口的大小，對(duì)發(fā)送數(shù)據(jù)量進(jìn)行控制。
流量控制是由發(fā)送方和接收方共同控制的。剛剛我們介紹了接收方會(huì)把自己能夠承受的最大窗口長(zhǎng)度寫在TCP 首部中，實(shí)際上在發(fā)送方這里，也存在流量控制，它叫擁塞窗口。TCP 協(xié)議中的窗口是指發(fā)送方窗口和接收方窗口的較小值。
慢啟動(dòng)過程如下：
- 通信開始時(shí)，
發(fā)送方的擁塞窗口大小為1。每收到一個(gè)ACK確認(rèn)后，擁塞窗口翻倍。 - 由于
指數(shù)級(jí)增長(zhǎng)非?？?，很快地，就會(huì)出現(xiàn)確認(rèn)包超時(shí)。(超時(shí)是因?yàn)閿?shù)據(jù)量大導(dǎo)致網(wǎng)絡(luò)擁塞) - 此時(shí)設(shè)置一個(gè)
“慢啟動(dòng)閾值”，它的值是當(dāng)前擁塞窗口大小的一半。 - 同時(shí)將
擁塞窗口大小設(shè)置為1，重新進(jìn)入慢啟動(dòng)過程。 - 由于現(xiàn)在
“慢啟動(dòng)閾值”已經(jīng)存在，當(dāng)擁塞窗口大小達(dá)到閾值時(shí)，不再翻倍，而是線性增加。 - 隨著
窗口大小不斷增加，可能收到三次重復(fù)確認(rèn)應(yīng)答，進(jìn)入“快速重發(fā)”階段。
(快速重發(fā): 當(dāng)發(fā)送端連續(xù)收到三個(gè)重復(fù)的ack時(shí)，表示該數(shù)據(jù)段已經(jīng)丟失，需要重發(fā)。當(dāng)收到三個(gè)表示同一個(gè)數(shù)據(jù)段的ack時(shí)，不需要等待計(jì)時(shí)器超時(shí)，即重新發(fā)送數(shù)據(jù)段（當(dāng)時(shí)這三個(gè)ack要在超時(shí)之前到達(dá)發(fā)送端），因?yàn)槟軌蚴盏?code>接收端的ack確認(rèn)信息，所以數(shù)據(jù)段只是單純的丟失，而不是因?yàn)?code>網(wǎng)絡(luò)擁塞導(dǎo)致，) - 這時(shí)候，
TCP將“慢啟動(dòng)閾值”設(shè)置為當(dāng)前擁塞窗口大小的一半，再將擁塞窗口大小設(shè)置成閾值大小（也有說加 3）。 -
擁塞窗口又會(huì)線性增加，直至下一次出現(xiàn)三次重復(fù)確認(rèn)應(yīng)答或超時(shí)。
以上過程可以用下圖概括：
常見的 HTTP 狀態(tài)碼？
**1xx ：信息性狀態(tài)碼 ** 表示服務(wù)器已接收了客戶端請(qǐng)求，客戶端可以繼續(xù)發(fā)送請(qǐng)求
- 100 Continue 初始的請(qǐng)求已經(jīng)接受，客戶應(yīng)當(dāng)繼續(xù)發(fā)送請(qǐng)求的其余部分
- 101 Switching Protocols 服務(wù)器將遵從客戶的請(qǐng)求轉(zhuǎn)換到另外一種協(xié)議
2xx ：成功狀態(tài)碼 表示服務(wù)器已成功接收到請(qǐng)求并進(jìn)行處理
- 200 OK 表示客戶端請(qǐng)求成功
- 204 No Content 成功，但不返回任何實(shí)體的主體部分
- 206 Partial Content 成功執(zhí)行了一個(gè)范圍（Range）請(qǐng)求
3xx ：重定向狀態(tài)碼 表示服務(wù)器要求客戶端重定向
- 301 Moved Permanently 永久性重定向，響應(yīng)報(bào)文的Location首部應(yīng)該有該資源的新URL
- 302 Found 臨時(shí)性重定向，響應(yīng)報(bào)文的Location首部給出的URL用來臨時(shí)定位資源
- 303 See Other 請(qǐng)求的資源存在著另一個(gè)URI，客戶端應(yīng)使用GET方法定向獲取請(qǐng)求的資源
- 304 Not Modified 服務(wù)器內(nèi)容沒有更新，可以直接讀取瀏覽器緩存
- 307 Temporary Redirect 臨時(shí)重定向。與302 Found含義一樣。302禁止POST變換為GET，但實(shí)際使用時(shí)并不一定，307則更多瀏覽器可能會(huì)遵循這一標(biāo)準(zhǔn)，但也依賴于瀏覽器具體實(shí)現(xiàn)
4xx ：客戶端錯(cuò)誤狀態(tài)碼 表示客戶端的請(qǐng)求有非法內(nèi)容
- 400 Bad Request 表示客戶端請(qǐng)求有語法錯(cuò)誤，不能被服務(wù)器所理解
- 401 表示請(qǐng)求未經(jīng)授權(quán)，該狀態(tài)代碼必須與 WWW-Authenticate 報(bào)頭域一起使用
- 403 表示服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)，通常會(huì)在響應(yīng)正文中給出不提供服務(wù)的原因
- 404 Not Found 請(qǐng)求的資源不存在，例如，輸入了錯(cuò)誤的URL
5xx ：服務(wù)器錯(cuò)誤狀態(tài)碼 表示服務(wù)器未能正常處理客戶端的請(qǐng)求而出現(xiàn)意外錯(cuò)誤
- 500 Internel Server Error 表示服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤，導(dǎo)致無法完成客戶端的請(qǐng)求
- 503 表示服務(wù)器當(dāng)前不能夠處理客戶端的請(qǐng)求，在一段時(shí)間之后，服務(wù)器可能會(huì)恢復(fù)正常
參考：
常見的HTTP狀態(tài)碼（HTTP Status Code）說明
從輸入U(xiǎn)RL到頁(yè)面展示，你想知道些什么？
從輸入U(xiǎn)RL到頁(yè)面展示，到底發(fā)生了什么？
過程為：
- URL 輸入
- DNS 解析
- TCP 連接
- 發(fā)送 HTTP請(qǐng)求
- 服務(wù)器處理請(qǐng)求
- 服務(wù)器響應(yīng)請(qǐng)求
- 瀏覽器解析，渲染頁(yè)面
- 鏈接結(jié)束
參考
從輸入U(xiǎn)RL到頁(yè)面展示，到底發(fā)生了什么
從輸入U(xiǎn)RL到頁(yè)面展示，你想知道些什么？
另一個(gè)答案：
? 查詢DNS，獲取域名對(duì)應(yīng)的IP地址
瀏覽器搜索自身的DNS緩存
搜索操作系統(tǒng)的DNS緩存
讀取本地的HOST文件
發(fā)起一個(gè)DNS的系統(tǒng)調(diào)用
? 寬帶運(yùn)營(yíng)服務(wù)器查看本身緩存
? 運(yùn)營(yíng)商服務(wù)器發(fā)起一個(gè)迭代DNS解析請(qǐng)求
? 瀏覽器獲得域名對(duì)應(yīng)的IP地址后，發(fā)起HTTP三次握手
? TCP/IP連接建立起來后，瀏覽器就可以向服務(wù)器發(fā)送HTTP請(qǐng)求了
? 服務(wù)器接受到這個(gè)請(qǐng)求，根據(jù)路徑參數(shù)，經(jīng)過后端的一些處理生成HTML頁(yè)面代碼返回給瀏覽器
? 瀏覽器拿到完整的HTML頁(yè)面代碼開始解析和渲染，如果遇到引用的外部JS，CSS,圖片等靜態(tài)資源，它們同樣也是一個(gè)個(gè)的HTTP請(qǐng)求，都需要經(jīng)過上面的步驟
? 瀏覽器根據(jù)拿到的資源對(duì)頁(yè)面進(jìn)行渲染，最終把一個(gè)完整的頁(yè)面呈現(xiàn)給用戶
對(duì) Cookie 的認(rèn)識(shí) ？
HTTP 協(xié)議對(duì)于發(fā)送的請(qǐng)求和響應(yīng)不做持久化處理。這時(shí)候引入了 Cookie 技術(shù)用于狀態(tài)管理。Cookie 對(duì)用與登錄的狀態(tài)管理，沒有 Cookie 這個(gè)技術(shù)的話，因?yàn)?HTTP 不保存狀態(tài)，每次打開新網(wǎng)頁(yè)都必須再次登錄。
Cookie 會(huì)根據(jù)響應(yīng)報(bào)文中的 Set-Cookie 字段來通知客戶端自動(dòng)保存 Cookie。下次請(qǐng)求時(shí)會(huì)自動(dòng)發(fā)送 Cookie，服務(wù)器會(huì)比對(duì)數(shù)據(jù)得到狀態(tài)結(jié)果。
Session 和 Cookie 的作用和工作原理？
Cookie（復(fù)數(shù)形態(tài)：Cookies）：是指某些網(wǎng)站為了辨別用戶身份、進(jìn)行session跟蹤而儲(chǔ)存在用戶本地終端上的數(shù)據(jù)（通常經(jīng)過加密）。
作用：因?yàn)镠TTP協(xié)議是無狀態(tài)的，即服務(wù)器不知道用戶上一次做了什么，這嚴(yán)重阻礙了交互式Web應(yīng)用程序的實(shí)現(xiàn)。在典型的網(wǎng)上購(gòu)物場(chǎng)景中，用戶瀏覽了幾個(gè)頁(yè)面，買了一盒餅干和兩飲料。最后結(jié)帳時(shí)，由于HTTP的無狀態(tài)性，不通過額外的手段，服務(wù)器并不知道用戶到底買了什么。為了做到這點(diǎn)，就需要使用到Cookie了。服務(wù)器可以設(shè)置或讀取Cookies中包含信息，借此維護(hù)用戶跟服務(wù)器會(huì)話中的狀態(tài)。
Cookie的根本作用就是在客戶端存儲(chǔ)用戶訪問網(wǎng)站的一些信息。典型的應(yīng)用有
1、記住密碼，下次自動(dòng)登錄
2、購(gòu)物車功能
3、記錄用戶瀏覽數(shù)據(jù)，進(jìn)行商品（廣告）推薦
工作原理：
1.創(chuàng)建 Cookie
? 當(dāng)用戶第一次瀏覽某個(gè)使用Cookie的網(wǎng)站時(shí)，該網(wǎng)站的服務(wù)器就進(jìn)行如下工作
? 1.1 該用戶生成一個(gè)唯一的識(shí)別碼（Cookie id），創(chuàng)建一個(gè)Cookie對(duì)象
? 1.2 默認(rèn)情況下它是一個(gè)會(huì)話級(jí)別的cookie，存儲(chǔ)在瀏覽器的內(nèi)存中，用戶退出瀏覽器之后被刪除。如果網(wǎng)站希望瀏覽器將該Cookie存儲(chǔ)在磁盤上，則需要設(shè)置最大時(shí)效（maxAge），并給出一個(gè)以秒為單位的時(shí)間（將最大時(shí)效設(shè)為0則是命令瀏覽器刪除該Cookie）
? 1.3 將Cookie放入到HTTP響應(yīng)報(bào)頭，將Cookie插入到一個(gè) Set-Cookie HTTP請(qǐng)求報(bào)頭中
? 1.4 發(fā)送該HTTP響應(yīng)報(bào)文
2.設(shè)置存儲(chǔ) Cookie
? 瀏覽器收到該響應(yīng)報(bào)文之后，根據(jù)報(bào)文頭里的Set-Cookied特殊的指示，生成相應(yīng)的Cookie，保存在客戶端。該Cookie里面記錄著用戶當(dāng)前的信息。
3.發(fā)送Cookie
? 當(dāng)用戶再次訪問該網(wǎng)站時(shí)，瀏覽器首先檢查所有存儲(chǔ)的Cookies，如果某個(gè)存在該網(wǎng)站的Cookie（即該Cookie所聲明的作用范圍大于等于將要請(qǐng)求的資源），則把該cookie附在請(qǐng)求資源的HTTP請(qǐng)求頭上發(fā)送給服務(wù)器
4.讀取Cookie
? 服務(wù)器接收到用戶的HTTP請(qǐng)求報(bào)文之后，從報(bào)文頭獲取到該用戶的Cookie，從里面找到所需要的東西
Session:代表服務(wù)器與瀏覽器的一次會(huì)話過程，這個(gè)過程是連續(xù)的，也可以時(shí)斷時(shí)續(xù)的。Session是一種服務(wù)器端的機(jī)制，Session 對(duì)象用來存儲(chǔ)特定用戶會(huì)話所需的信息
工作原理：創(chuàng)建session、使用session，具體看參考url
作用：Session的根本作用就是在服務(wù)端存儲(chǔ)用戶和服務(wù)器會(huì)話的一些信息
1、判斷用戶是否登錄
2、購(gòu)物車功能
參考：
談對(duì) 5G技術(shù)的認(rèn)識(shí)？
簡(jiǎn)單說，5G就是第五代通信技術(shù)，主要特點(diǎn)是波長(zhǎng)為毫米級(jí)，超寬帶，超高速度，超低延時(shí)。
5G如果要實(shí)現(xiàn)端到端的高速率，重點(diǎn)是突破無線這部分的瓶頸。
光速 = 波長(zhǎng) * 頻率
為了實(shí)現(xiàn)更高效的傳輸速率必須使用更短的波，5G采用毫米波（1~10 mm）
電磁波的顯著特點(diǎn)：頻率越高，波長(zhǎng)越短，越趨近于直線傳播（繞射和穿墻能力越差）。****頻率越高，在傳播介質(zhì)中的衰減也越大。
所以，5G需要非常多的微基站。對(duì)人體是有益的，減小了輻射。
如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？
TCP還設(shè)有一個(gè)?；钣?jì)時(shí)器，顯然，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費(fèi)資源。服務(wù)器每收到一次客戶端的請(qǐng)求后都會(huì)重新復(fù)位這個(gè)計(jì)時(shí)器，時(shí)間通常是設(shè)置為2小時(shí)，若兩小時(shí)還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會(huì)發(fā)送一個(gè)探測(cè)報(bào)文段，以后每隔75分鐘發(fā)送一次。若一連發(fā)送10個(gè)探測(cè)報(bào)文仍然沒反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接。
Http 和 Https的區(qū)別？
1. 安全性：
http是HTTP協(xié)議運(yùn)行在TCP之上。所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗(yàn)證對(duì)方的身份。
https是HTTP運(yùn)行在SSL/TLS之上，SSL/TLS運(yùn)行在TCP之上。所有傳輸?shù)膬?nèi)容都經(jīng)過加密，加密采用對(duì)稱加密，但對(duì)稱加密的密鑰用服務(wù)器方的證書進(jìn)行了非對(duì)稱加密。此外客戶端可以驗(yàn)證服務(wù)器端的身份，如果配置了客戶 端驗(yàn)證，服務(wù)器方也可以驗(yàn)證客戶端的身份。
2. 證書
https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書很少，需要交費(fèi)。
3. 傳輸協(xié)議
http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議
4. 端口
http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。
HTTPS 原理?
HTTPS其實(shí)是有兩部分組成：HTTP + SSL / TLS，也就是在HTTP上又加了一層處理加密信息的模塊。服務(wù)端和客戶端的信息傳輸都會(huì)通過TLS進(jìn)行加密，所以傳輸?shù)臄?shù)據(jù)都是加密后的數(shù)據(jù)。
HTTPS 是 HTTP 建立在 SSL/TLS 安全協(xié)議上的。
在 iOS 中，客戶端本地會(huì)存放著 CA 證書，在HTTPS 請(qǐng)求時(shí)，會(huì)首先像服務(wù)器索要公鑰，獲得公鑰后會(huì)使用本地 CA 證書驗(yàn)證公鑰的正確性，然后通過正確的公鑰加密信息發(fā)送給服務(wù)器，服務(wù)器會(huì)使用私鑰解密信息。
HTTPS 相對(duì)于 HTTP 性能上差點(diǎn)，因?yàn)槎嗔?SSL/TLS 的幾次握手和加密解密的運(yùn)算處理，但是加密解密的運(yùn)算處理已經(jīng)可以通過特有的硬件來加速處理。
1. 客戶端發(fā)起HTTPS請(qǐng)求
這個(gè)沒什么好說的，就是用戶在瀏覽器里輸入一個(gè)https網(wǎng)址，然后連接到server的443端口。
2. 服務(wù)端的配置
采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請(qǐng)。
區(qū)別就是自己頒發(fā)的證書需要客戶端驗(yàn)證通過，才可以繼續(xù)訪問，而使用受信任的公司申請(qǐng)的證書則不會(huì)彈出提示頁(yè)面(startssl就是個(gè)不錯(cuò)的選擇，有1年的免費(fèi)服務(wù))。
這套證書其實(shí)就是一對(duì)公鑰和私鑰。如果對(duì)公鑰和私鑰不太理解，可以想象成一把鑰匙和一個(gè)鎖頭，只是全世界只有你一個(gè)人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個(gè)鎖把重要的東西鎖起來，然后發(fā)給你，因?yàn)橹挥心阋粋€(gè)人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。
3. 傳送證書
這個(gè)證書其實(shí)就是公鑰，只是包含了很多信息，如證書的頒發(fā)機(jī)構(gòu)，過期時(shí)間等等。
4. 客戶端解析證書
這部分工作是有客戶端的TLS來完成的，首先會(huì)驗(yàn)證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)，過期時(shí)間等等，如果發(fā)現(xiàn)異常，則會(huì)彈出一個(gè)警告框，提示證書存在問題。
如果證書沒有問題，那么就生成一個(gè)隨即值。然后用證書對(duì)該隨機(jī)值進(jìn)行加密。就好像上面說的，把隨機(jī)值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。
5. 傳送加密信息
這部分傳送的是用證書加密后的隨機(jī)值，目的就是讓服務(wù)端得到這個(gè)隨機(jī)值，以后客戶端和服務(wù)端的通信就可以通過這個(gè)隨機(jī)值來進(jìn)行加密解密了。
6. 服務(wù)段解密信息
服務(wù)端用私鑰解密后，得到了客戶端傳過來的隨機(jī)值(私鑰)，然后把內(nèi)容通過該值進(jìn)行對(duì)稱加密。
所謂對(duì)稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內(nèi)容，而正好客戶端和服務(wù)端都知道這個(gè)私鑰，所以只要加密算法夠彪悍，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全。
7. 傳輸加密后的信息
這部分信息是服務(wù)段用私鑰加密后的信息，可以在客戶端被還原
8. 客戶端解密信息
客戶端用之前生成的私鑰解密服務(wù)段傳過來的信息，于是獲取了解密后的內(nèi)容。整個(gè)過程第三方即使監(jiān)聽到了數(shù)據(jù)，也束手無策。
經(jīng)典面試題21 - HTTPS 和 SSL證書原理
HTTP 請(qǐng)求中的 get 和 post 的區(qū)別?
- GET使用URL或Cookie傳參，而POST將數(shù)據(jù)放在BODY中，這個(gè)是因?yàn)镠TTP協(xié)議用法的約定。并非它們的本身區(qū)別。
- GET方式提交的數(shù)據(jù)有長(zhǎng)度限制，則POST的數(shù)據(jù)則可以非常大，這個(gè)是因?yàn)樗鼈兪褂玫牟僮飨到y(tǒng)和瀏覽器設(shè)置的不同引起的區(qū)別。也不是GET和POST本身的區(qū)別。
- POST比GET安全，因?yàn)閿?shù)據(jù)在地址欄上不可見，這個(gè)說法沒毛病，但依然不是GET和POST本身的區(qū)別。
- 最大的區(qū)別主要是GET請(qǐng)求是冪等性的，POST請(qǐng)求不是
HTTP｜GET 和 POST 區(qū)別？網(wǎng)上多數(shù)答案都是錯(cuò)的！
另一個(gè)答案：
? GET 被強(qiáng)制服務(wù)器支持
? 瀏覽器對(duì)URL的長(zhǎng)度有限制，所以GET請(qǐng)求不能代替POST請(qǐng)求發(fā)送大量數(shù)據(jù)
? GET請(qǐng)求發(fā)送數(shù)據(jù)更小
? GET請(qǐng)求是不安全的
? GET請(qǐng)求是冪等的
? POST請(qǐng)求不能被緩存
? POST請(qǐng)求相對(duì)GET請(qǐng)求是「安全」的
? 在以下情況中，請(qǐng)使用 POST 請(qǐng)求:
1. 無法使用緩存文件(更新服務(wù)器上的文件或數(shù)據(jù)庫(kù))
2. 向服務(wù)器發(fā)送大量數(shù)據(jù)(POST 沒有數(shù)據(jù)量限制)
3. 發(fā)送包含未知字符的用戶輸入時(shí)，POST 比 GET 更穩(wěn)定也更可靠
4. post比Get安全性更高
Session 和 Cookie 的區(qū)別?
HTTP 是一種無狀態(tài)的連接，客戶端每次讀取web 頁(yè)面時(shí)，服務(wù)器都會(huì)認(rèn)為這是一次新的會(huì)話。但有時(shí)候我們又需要持久保持某些信息，比如登錄時(shí)的用戶名、密碼，用戶上一次連接時(shí)的信息等。這些信息就由 Cookie 和Session 保存。
這兩者的根本性區(qū)別在于，cookie保存在客戶端上，而 session 則保存在服務(wù)器中。由此我們還可以拓展出以下結(jié)論：
-
cookie相對(duì)來說不安全，瀏覽器可以分析本地的cookie進(jìn)行cookie欺騙。 -
session可以設(shè)置超時(shí)時(shí)間，超過這個(gè)時(shí)間后就失效，以免長(zhǎng)期占用服務(wù)端內(nèi)存。 - 單個(gè)
cookie的大小有限制（4 Kb），每個(gè)站點(diǎn)的cookie數(shù)量一般也有限制（20個(gè)）。 -
客戶端每次都會(huì)把cookie發(fā)送到服務(wù)端，因此服務(wù)端可以知道cookie，但是客戶端不知道session。
當(dāng)服務(wù)器接收到cookie 后，會(huì)根據(jù)cookie 中的 SessionID 來找到這個(gè)客戶的 session。如果沒有，則會(huì)生成一個(gè)新的 SessionID發(fā)送給客戶端。
談?wù)勀銓?duì) HTTP 1.1，2.0 和 HTTPS 的理解?
一、HTTP
HTTP（超文本傳輸協(xié)議，HyperText Transfer Protocol)是應(yīng)用層的協(xié)議，目前在互聯(lián)網(wǎng)中應(yīng)用廣泛。
它被設(shè)計(jì)用于Web瀏覽器和Web服務(wù)器之間的通信，但它也可以用于其他目的。 HTTP遵循經(jīng)典的客戶端-服務(wù)端模型，客戶端打開一個(gè)連接以發(fā)出請(qǐng)求，然后等待它收到服務(wù)器端響應(yīng)。HTTP是
無狀態(tài)協(xié)議，意味著服務(wù)器不會(huì)在兩個(gè)請(qǐng)求之間保留任何數(shù)據(jù)（狀態(tài)）。
二、HTTP1.0 ——構(gòu)建可擴(kuò)展性
HTTP 1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即斷開TCP連接，服務(wù)器不跟蹤每個(gè)客戶也不記錄過去的請(qǐng)求。
三、HTTP1.1 ——標(biāo)準(zhǔn)化的協(xié)議
HTTP/1.0的多種不同的實(shí)現(xiàn)運(yùn)用起來有些混亂，HTTP1.1是第一個(gè)標(biāo)準(zhǔn)化版本，重點(diǎn)關(guān)注的是校正HTTP1.0設(shè)計(jì)中的結(jié)構(gòu)性缺陷：
- 連接可以重復(fù)使用，節(jié)省了多次打開它的時(shí)間，以顯示嵌入到單個(gè)原始文檔中的資源。
- 增加流水線操作，允許在第一個(gè)應(yīng)答被完全發(fā)送之前發(fā)送第二個(gè)請(qǐng)求，以降低通信的延遲。
- 支持響應(yīng)分塊。
- 引入額外的緩存控制機(jī)制。
- 引入內(nèi)容協(xié)商，包括語言，編碼，或類型，并允許客戶端和服務(wù)器約定以最適當(dāng)?shù)膬?nèi)容進(jìn)行交換。
- 添加Host 頭，能夠使不同的域名配置在同一個(gè)IP地址的服務(wù)器。
- 安全性得到了提高
在http1.1中，client和server都是默認(rèn)對(duì)方支持長(zhǎng)鏈接的， 如果不希望使用長(zhǎng)鏈接，則需要在header中指明connection:close；
四、HTTP2.0——為了更優(yōu)異的表現(xiàn)
HTTP/2.0在HTTP/1.1有幾處基本的不同:
-
HTTP2是二進(jìn)制協(xié)議而不是文本協(xié)議。不再可讀和無障礙的手動(dòng)創(chuàng)建，改善的優(yōu)化技術(shù)現(xiàn)在可被實(shí)施。 - 這是一個(gè)復(fù)用協(xié)議。并行的請(qǐng)求能在同一個(gè)鏈接中處理，移除了HTTP/1.x中順序和阻塞的約束。
- 壓縮了headers。因?yàn)閔eaders在一系列請(qǐng)求中常常是相似的，其移除了重復(fù)和傳輸重復(fù)數(shù)據(jù)的成本。
- 其允許服務(wù)器在客戶端緩存中填充數(shù)據(jù)，通過一個(gè)叫服務(wù)器推送的機(jī)制來提前請(qǐng)求。
五、HTTPS
我們知道HTTP 協(xié)議直接使用了TCP 協(xié)議進(jìn)行數(shù)據(jù)傳輸。由于數(shù)據(jù)沒有加密，都是直接明文傳輸，所以存在以下三個(gè)風(fēng)險(xiǎn)：
- 竊聽風(fēng)險(xiǎn)：第三方節(jié)點(diǎn)可以獲知通信內(nèi)容。
- 篡改風(fēng)險(xiǎn)：第三方節(jié)點(diǎn)可以修改通信內(nèi)容。
- 冒充風(fēng)險(xiǎn)：第三方節(jié)點(diǎn)可以冒充他人身份參與通信。
比如你在手機(jī)上打開應(yīng)用內(nèi)的網(wǎng)頁(yè)時(shí)，有時(shí)會(huì)看到網(wǎng)頁(yè)底部彈出了廣告，這實(shí)際上就說明你的HTTP 內(nèi)容被竊聽、并篡改了。
HTTPS 協(xié)議旨在解決以上三個(gè)風(fēng)險(xiǎn)，因此它可以：
- 保證所有信息加密傳輸，無法被第三方竊取。
- 為信息添加校驗(yàn)機(jī)制，如果被第三方惡意破壞，可以檢測(cè)出來。
- 配備身份證書，防止第三方偽裝參與通信。
HTTPS 的結(jié)構(gòu)如圖所示：
可見它僅僅是在 HTTP 和TCP 之間新增了一個(gè)TLS/SSL 加密層，這也印證了一句名言：“一切計(jì)算機(jī)問題都可以通過添加中間層解決”。
使用HTTPS 時(shí)，服務(wù)端會(huì)將自己的證書發(fā)送給客戶端，其中包含了服務(wù)端的公鑰?；?code>非對(duì)稱加密的傳輸過程如下：
- 客戶端使用公鑰將信息加密，密文發(fā)送給服務(wù)端
- 服務(wù)端用自己的私鑰解密，再將返回?cái)?shù)據(jù)用私鑰加密發(fā)回客戶端
- 客戶端用公鑰解密
這里的證書是服務(wù)器證明自己身份的工具，它由權(quán)威的證書頒發(fā)機(jī)構(gòu)（CA）發(fā)給申請(qǐng)者。如果證書是虛假的，或者是自己給自己頒發(fā)的證書，服務(wù)器就會(huì)不認(rèn)可這個(gè)證書并發(fā)出警告：
總結(jié)一下 HTTPS 協(xié)議是如何避免前文所說的三大風(fēng)險(xiǎn)的：
- 先用
非對(duì)稱加密傳輸密碼，然后用這個(gè)密碼對(duì)稱加密數(shù)據(jù)，使得第三方無法獲得通信內(nèi)容 -
發(fā)送方將數(shù)據(jù)的哈希結(jié)果寫到數(shù)據(jù)中，接收方解密后對(duì)比數(shù)據(jù)的哈希結(jié)果，如果不一致則說明被修改。由于傳輸數(shù)據(jù)加密，第三方無法修改哈希結(jié)果。 - 由
權(quán)威機(jī)構(gòu)頒發(fā)證書，再加上證書校驗(yàn)機(jī)制，避免第三方偽裝參與通信.
為什么建立連接是三次握手，而關(guān)閉連接卻是四次揮手呢？
這是因?yàn)榉?wù)端在LISTEN狀態(tài)下，收到建立連接請(qǐng)求的SYN報(bào)文后，把ACK和SYN放在一個(gè)報(bào)文里發(fā)送給客戶端。而關(guān)閉連接時(shí)，當(dāng)收到對(duì)方的FIN報(bào)文時(shí)，僅僅表示對(duì)方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，己方也未必全部數(shù)據(jù)都發(fā)送給對(duì)方了，所以己方可以立即close，也可以發(fā)送一些數(shù)據(jù)給對(duì)方后，再發(fā)送FIN報(bào)文給對(duì)方來表示同意現(xiàn)在關(guān)閉連接，因此，己方ACK和FIN一般都會(huì)分開發(fā)送。
參考：
