網(wǎng)絡(luò)分層結(jié)構(gòu)

計(jì)算機(jī)網(wǎng)絡(luò)體系大致分為三種，OSI七層模型、TCP/IP四層模型和五層模型。一般面試的時(shí)候考察比較多的是五層模型。最全面的Java面試網(wǎng)站

五層模型：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層。

• 應(yīng)用層：為應(yīng)用程序提供交互服務(wù)。在互聯(lián)網(wǎng)中的應(yīng)用層協(xié)議很多，如域名系統(tǒng)DNS、HTTP協(xié)議、SMTP協(xié)議等。
• 傳輸層：負(fù)責(zé)向兩臺(tái)主機(jī)進(jìn)程之間的通信提供數(shù)據(jù)傳輸服務(wù)。傳輸層的協(xié)議主要有傳輸控制協(xié)議TCP和用戶數(shù)據(jù)協(xié)議UDP。
• 網(wǎng)絡(luò)層：選擇合適的路由和交換結(jié)點(diǎn)，確保數(shù)據(jù)及時(shí)傳送。主要包括IP協(xié)議。
• 數(shù)據(jù)鏈路層：在兩個(gè)相鄰節(jié)點(diǎn)之間傳送數(shù)據(jù)時(shí)，數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來的 IP 數(shù)據(jù)報(bào)組裝成幀，在兩個(gè)相鄰節(jié)點(diǎn)間的鏈路上傳送幀。
• 物理層：實(shí)現(xiàn)相鄰節(jié)點(diǎn)間比特流的透明傳輸，盡可能屏蔽傳輸介質(zhì)和物理設(shè)備的差異。

本文已經(jīng)收錄到Github倉(cāng)庫(kù)，該倉(cāng)庫(kù)包含計(jì)算機(jī)基礎(chǔ)、Java基礎(chǔ)、多線程、JVM、數(shù)據(jù)庫(kù)、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服務(wù)、設(shè)計(jì)模式、架構(gòu)、校招社招分享等核心知識(shí)點(diǎn)，歡迎star~

Github地址

如果訪問不了Github，可以訪問gitee地址。

gitee地址

ISO七層模型是國(guó)際標(biāo)準(zhǔn)化組織（International Organization for Standardization）制定的一個(gè)用于計(jì)算機(jī)或通信系統(tǒng)間互聯(lián)的標(biāo)準(zhǔn)體系。

• 應(yīng)用層：網(wǎng)絡(luò)服務(wù)與最終用戶的一個(gè)接口，常見的協(xié)議有：HTTP FTP SMTP SNMP DNS.
• 表示層：數(shù)據(jù)的表示、安全、壓縮。，確保一個(gè)系統(tǒng)的應(yīng)用層所發(fā)送的信息可以被另一個(gè)系統(tǒng)的應(yīng)用層讀取。
• 會(huì)話層：建立、管理、終止會(huì)話,對(duì)應(yīng)主機(jī)進(jìn)程，指本地主機(jī)與遠(yuǎn)程主機(jī)正在進(jìn)行的會(huì)話.
• 傳輸層：定義傳輸數(shù)據(jù)的協(xié)議端口號(hào)，以及流控和差錯(cuò)校驗(yàn),協(xié)議有TCP UDP.
• 網(wǎng)絡(luò)層：進(jìn)行邏輯地址尋址，實(shí)現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇,協(xié)議有ICMP IGMP IP等.
• 數(shù)據(jù)鏈路層：在物理層提供比特流服務(wù)的基礎(chǔ)上，建立相鄰結(jié)點(diǎn)之間的數(shù)據(jù)鏈路。
• 物理層：建立、維護(hù)、斷開物理連接。

TCP/IP 四層模型

• 應(yīng)用層：對(duì)應(yīng)于OSI參考模型的（應(yīng)用層、表示層、會(huì)話層）。
• 傳輸層: 對(duì)應(yīng)OSI的傳輸層，為應(yīng)用層實(shí)體提供端到端的通信功能，保證了數(shù)據(jù)包的順序傳送及數(shù)據(jù)的完整性。
• 網(wǎng)際層：對(duì)應(yīng)于OSI參考模型的網(wǎng)絡(luò)層，主要解決主機(jī)到主機(jī)的通信問題。
• 網(wǎng)絡(luò)接口層：與OSI參考模型的數(shù)據(jù)鏈路層、物理層對(duì)應(yīng)。

三次握手

假設(shè)發(fā)送端為客戶端，接收端為服務(wù)端。開始時(shí)客戶端和服務(wù)端的狀態(tài)都是CLOSED。

1. 第一次握手：客戶端向服務(wù)端發(fā)起建立連接請(qǐng)求，客戶端會(huì)隨機(jī)生成一個(gè)起始序列號(hào)x，客戶端向服務(wù)端發(fā)送的字段中包含標(biāo)志位SYN=1，序列號(hào)seq=x。第一次握手前客戶端的狀態(tài)為CLOSE，第一次握手后客戶端的狀態(tài)為SYN-SENT。此時(shí)服務(wù)端的狀態(tài)為LISTEN。
2. 第二次握手：服務(wù)端在收到客戶端發(fā)來的報(bào)文后，會(huì)隨機(jī)生成一個(gè)服務(wù)端的起始序列號(hào)y，然后給客戶端回復(fù)一段報(bào)文，其中包括標(biāo)志位SYN=1，ACK=1，序列號(hào)seq=y，確認(rèn)號(hào)ack=x+1。第二次握手前服務(wù)端的狀態(tài)為LISTEN，第二次握手后服務(wù)端的狀態(tài)為SYN-RCVD，此時(shí)客戶端的狀態(tài)為SYN-SENT。（其中SYN=1表示要和客戶端建立一個(gè)連接，ACK=1表示確認(rèn)序號(hào)有效）
3. 第三次握手：客戶端收到服務(wù)端發(fā)來的報(bào)文后，會(huì)再向服務(wù)端發(fā)送報(bào)文，其中包含標(biāo)志位ACK=1，序列號(hào)seq=x+1，確認(rèn)號(hào)ack=y+1。第三次握手前客戶端的狀態(tài)為SYN-SENT，第三次握手后客戶端和服務(wù)端的狀態(tài)都為ESTABLISHED。此時(shí)連接建立完成。

兩次握手可以嗎？

之所以需要第三次握手，主要為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳輸?shù)搅朔?wù)端，導(dǎo)致產(chǎn)生問題。

• 比如客戶端A發(fā)出連接請(qǐng)求，可能因?yàn)榫W(wǎng)絡(luò)阻塞原因，A沒有收到確認(rèn)報(bào)文，于是A再重傳一次連接請(qǐng)求。
• 然后連接成功，等待數(shù)據(jù)傳輸完畢后，就釋放了連接。
• 然后A發(fā)出的第一個(gè)連接請(qǐng)求等到連接釋放以后的某個(gè)時(shí)間才到達(dá)服務(wù)端B，此時(shí)B誤認(rèn)為A又發(fā)出一次新的連接請(qǐng)求，于是就向A發(fā)出確認(rèn)報(bào)文段。
• 如果不采用三次握手，只要B發(fā)出確認(rèn)，就建立新的連接了，此時(shí)A不會(huì)響應(yīng)B的確認(rèn)且不發(fā)送數(shù)據(jù)，則B一直等待A發(fā)送數(shù)據(jù)，浪費(fèi)資源。

四次揮手

1. A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放報(bào)文段（FIN=1，seq=u），并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉TCP連接，進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)，等待B的確認(rèn)。
2. B收到連接釋放報(bào)文段后即發(fā)出確認(rèn)報(bào)文段（ACK=1，ack=u+1，seq=v），B進(jìn)入CLOSE-WAIT（關(guān)閉等待）狀態(tài)，此時(shí)的TCP處于半關(guān)閉狀態(tài)，A到B的連接釋放。
3. A收到B的確認(rèn)后，進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待B發(fā)出的連接釋放報(bào)文段。
4. B發(fā)送完數(shù)據(jù)，就會(huì)發(fā)出連接釋放報(bào)文段（FIN=1，ACK=1，seq=w，ack=u+1），B進(jìn)入LAST-ACK（最后確認(rèn)）狀態(tài)，等待A的確認(rèn)。
5. A收到B的連接釋放報(bào)文段后，對(duì)此發(fā)出確認(rèn)報(bào)文段（ACK=1，seq=u+1，ack=w+1），A進(jìn)入TIME-WAIT（時(shí)間等待）狀態(tài)。此時(shí)TCP未釋放掉，需要經(jīng)過時(shí)間等待計(jì)時(shí)器設(shè)置的時(shí)間2MSL（最大報(bào)文段生存時(shí)間）后，A才進(jìn)入CLOSED狀態(tài)。B收到A發(fā)出的確認(rèn)報(bào)文段后關(guān)閉連接，若沒收到A發(fā)出的確認(rèn)報(bào)文段，B就會(huì)重傳連接釋放報(bào)文段。

第四次揮手為什么要等待2MSL？

• 保證A發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)B。這個(gè)ACK報(bào)文段有可能丟失，B收不到這個(gè)確認(rèn)報(bào)文，就會(huì)超時(shí)重傳連接釋放報(bào)文段，然后A可以在2MSL時(shí)間內(nèi)收到這個(gè)重傳的連接釋放報(bào)文段，接著A重傳一次確認(rèn)，重新啟動(dòng)2MSL計(jì)時(shí)器，最后A和B都進(jìn)入到CLOSED狀態(tài)，若A在TIME-WAIT狀態(tài)不等待一段時(shí)間，而是發(fā)送完ACK報(bào)文段后立即釋放連接，則無法收到B重傳的連接釋放報(bào)文段，所以不會(huì)再發(fā)送一次確認(rèn)報(bào)文段，B就無法正常進(jìn)入到CLOSED狀態(tài)。
• 防止已失效的連接請(qǐng)求報(bào)文段出現(xiàn)在本連接中。A在發(fā)送完最后一個(gè)ACK報(bào)文段后，再經(jīng)過2MSL，就可以使這個(gè)連接所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失，使下一個(gè)新的連接中不會(huì)出現(xiàn)舊的連接請(qǐng)求報(bào)文段。

最后給大家分享一個(gè)Github倉(cāng)庫(kù)，上面有大彬整理的300多本經(jīng)典的計(jì)算機(jī)書籍PDF，包括C語(yǔ)言、C++、Java、Python、前端、數(shù)據(jù)庫(kù)、操作系統(tǒng)、計(jì)算機(jī)網(wǎng)絡(luò)、數(shù)據(jù)結(jié)構(gòu)和算法、機(jī)器學(xué)習(xí)、編程人生等，可以star一下，下次找書直接在上面搜索，倉(cāng)庫(kù)持續(xù)更新中~

Github地址

為什么是四次揮手？

因?yàn)楫?dāng)Server端收到Client端的SYN連接請(qǐng)求報(bào)文后，可以直接發(fā)送SYN+ACK報(bào)文。但是在關(guān)閉連接時(shí)，當(dāng)Server端收到Client端發(fā)出的連接釋放報(bào)文時(shí)，很可能并不會(huì)立即關(guān)閉SOCKET，所以Server端先回復(fù)一個(gè)ACK報(bào)文，告訴Client端我收到你的連接釋放報(bào)文了。只有等到Server端所有的報(bào)文都發(fā)送完了，這時(shí)Server端才能發(fā)送連接釋放報(bào)文，之后兩邊才會(huì)真正的斷開連接。故需要四次揮手。

說說TCP報(bào)文首部有哪些字段，其作用又分別是什么？

• 16位端口號(hào)：源端口號(hào)，主機(jī)該報(bào)文段是來自哪里；目標(biāo)端口號(hào)，要傳給哪個(gè)上層協(xié)議或應(yīng)用程序
• 32位序號(hào)：一次TCP通信（從TCP連接建立到斷開）過程中某一個(gè)傳輸方向上的字節(jié)流的每個(gè)字節(jié)的編號(hào)。
• 32位確認(rèn)號(hào)：用作對(duì)另一方發(fā)送的tcp報(bào)文段的響應(yīng)。其值是收到的TCP報(bào)文段的序號(hào)值加1。
• 4位頭部長(zhǎng)度：表示tcp頭部有多少個(gè)32bit字（4字節(jié)）。因?yàn)?位最大能標(biāo)識(shí)15，所以TCP頭部最長(zhǎng)是60字節(jié)。
• 6位標(biāo)志位：URG(緊急指針是否有效)，ACk（表示確認(rèn)號(hào)是否有效），PSH（緩沖區(qū)尚未填滿），RST（表示要求對(duì)方重新建立連接），SYN（建立連接消息標(biāo)志接），F(xiàn)IN（表示告知對(duì)方本端要關(guān)閉連接了）
• 16位窗口大小：是TCP流量控制的一個(gè)手段。這里說的窗口，指的是接收通告窗口。它告訴對(duì)方本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對(duì)方就可以控制發(fā)送數(shù)據(jù)的速度。
• 16位校驗(yàn)和：由發(fā)送端填充，接收端對(duì)TCP報(bào)文段執(zhí)行CRC算法以檢驗(yàn)TCP報(bào)文段在傳輸過程中是否損壞。注意，這個(gè)校驗(yàn)不僅包括TCP頭部，也包括數(shù)據(jù)部分。這也是TCP可靠傳輸?shù)囊粋€(gè)重要保障。
• 16位緊急指針：一個(gè)正的偏移量。它和序號(hào)字段的值相加表示最后一個(gè)緊急數(shù)據(jù)的下一字節(jié)的序號(hào)。因此，確切地說，這個(gè)字段是緊急指針相對(duì)當(dāng)前序號(hào)的偏移，不妨稱之為緊急偏移。TCP的緊急指針是發(fā)送端向接收端發(fā)送緊急數(shù)據(jù)的方法。

TCP有哪些特點(diǎn)？

• TCP是面向連接的運(yùn)輸層協(xié)議。
• 點(diǎn)對(duì)點(diǎn)，每一條TCP連接只能有兩個(gè)端點(diǎn)。
• TCP提供可靠交付的服務(wù)。
• TCP提供全雙工通信。
• 面向字節(jié)流。

TCP的粘包和拆包

TCP是面向流，沒有界限的一串?dāng)?shù)據(jù)。TCP底層并不了解上層業(yè)務(wù)數(shù)據(jù)的具體含義，它會(huì)根據(jù)TCP緩沖區(qū)的實(shí)際情況進(jìn)行包的劃分，所以在業(yè)務(wù)上認(rèn)為，一個(gè)完整的包可能會(huì)被TCP拆分成多個(gè)包進(jìn)行發(fā)送，也有可能把多個(gè)小的包封裝成一個(gè)大的數(shù)據(jù)包發(fā)送，這就是所謂的TCP粘包和拆包問題。

為什么會(huì)產(chǎn)生粘包和拆包呢?

• 要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小，TCP將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會(huì)發(fā)生粘包；
• 接收數(shù)據(jù)端的應(yīng)用層沒有及時(shí)讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包；
• 要發(fā)送的數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)剩余空間大小，將會(huì)發(fā)生拆包；
• 待發(fā)送數(shù)據(jù)大于MSS（最大報(bào)文長(zhǎng)度），TCP在傳輸前將進(jìn)行拆包。即TCP報(bào)文長(zhǎng)度-TCP頭部長(zhǎng)度>MSS。

解決方案：

• 發(fā)送端將每個(gè)數(shù)據(jù)包封裝為固定長(zhǎng)度
• 在數(shù)據(jù)尾部增加特殊字符進(jìn)行分割
• 將數(shù)據(jù)分為兩部分，一部分是頭部，一部分是內(nèi)容體；其中頭部結(jié)構(gòu)大小固定，且有一個(gè)字段聲明內(nèi)容體的大小。

TCP和UDP的區(qū)別？

1. TCP面向連接；UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
2. TCP提供可靠的服務(wù)；UDP不保證可靠交付。
3. TCP面向字節(jié)流，把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流；UDP是面向報(bào)文的。
4. TCP有擁塞控制；UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低（對(duì)實(shí)時(shí)應(yīng)用很有用，如實(shí)時(shí)視頻會(huì)議等）。
5. 每一條TCP連接只能是點(diǎn)到點(diǎn)的；UDP支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的通信方式。
6. TCP首部開銷20字節(jié)；UDP的首部開銷小，只有8個(gè)字節(jié)。

TCP 和 UDP 分別對(duì)應(yīng)的常見應(yīng)用層協(xié)議有哪些？

基于TCP的應(yīng)用層協(xié)議有：HTTP、FTP、SMTP、TELNET、SSH

• HTTP：HyperText Transfer Protocol（超文本傳輸協(xié)議），默認(rèn)端口80
• FTP: File Transfer Protocol (文件傳輸協(xié)議), 默認(rèn)端口(20用于傳輸數(shù)據(jù)，21用于傳輸控制信息)
• SMTP: Simple Mail Transfer Protocol (簡(jiǎn)單郵件傳輸協(xié)議) ,默認(rèn)端口25
• TELNET: Teletype over the Network (網(wǎng)絡(luò)電傳), 默認(rèn)端口23
• SSH：Secure Shell（安全外殼協(xié)議），默認(rèn)端口 22

基于UDP的應(yīng)用層協(xié)議：DNS、TFTP、SNMP

• DNS : Domain Name Service (域名服務(wù)),默認(rèn)端口 53
• TFTP: Trivial File Transfer Protocol (簡(jiǎn)單文件傳輸協(xié)議)，默認(rèn)端口69
• SNMP：Simple Network Management Protocol（簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議），通過UDP端口161接收，只有Trap信息采用UDP端口162。

說說TCP是如何確保可靠性的呢？

• 首先，TCP的連接是基于三次握手，而斷開則是基于四次揮手。確保連接和斷開的可靠性。
• 其次，TCP的可靠性，還體現(xiàn)在有狀態(tài);TCP會(huì)記錄哪些數(shù)據(jù)發(fā)送了，哪些數(shù)據(jù)被接收了，哪些沒有被接受，并且保證數(shù)據(jù)包按序到達(dá)，保證數(shù)據(jù)傳輸不出差錯(cuò)。
• 再次，TCP的可靠性，還體現(xiàn)在可控制。它有數(shù)據(jù)包校驗(yàn)、ACK應(yīng)答、超時(shí)重傳(發(fā)送方)、失序數(shù)據(jù)重傳（接收方）、丟棄重復(fù)數(shù)據(jù)、流量控制（滑動(dòng)窗口）和擁塞控制等機(jī)制。

說下TCP的滑動(dòng)窗口機(jī)制

TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。 TCP會(huì)話的雙方都各自維護(hù)一個(gè)發(fā)送窗口和一個(gè)接收窗口。接收窗口大小取決于應(yīng)用、系統(tǒng)、硬件的限制。發(fā)送窗口則取決于對(duì)端通告的接收窗口。接收方發(fā)送的確認(rèn)報(bào)文中的window字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將接收方的確認(rèn)報(bào)文window字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

TCP頭包含window字段，16bit位，它代表的是窗口的字節(jié)容量，最大為65535。這個(gè)字段是接收端告訴發(fā)送端自己還有多少緩沖區(qū)可以接收數(shù)據(jù)。于是發(fā)送端就可以根據(jù)這個(gè)接收端的處理能力來發(fā)送數(shù)據(jù)，而不會(huì)導(dǎo)致接收端處理不過來。接收窗口的大小是約等于發(fā)送窗口的大小。

詳細(xì)講一下?lián)砣刂疲?/h2>

防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中。 幾種擁塞控制方法：慢開始( slow-start )、擁塞避免( congestion avoidance )、快重傳( fast retransmit )和快恢復(fù)( fast recovery )。

慢開始

把擁塞窗口 cwnd 設(shè)置為一個(gè)最大報(bào)文段MSS的數(shù)值。而在每收到一個(gè)對(duì)新的報(bào)文段的確認(rèn)后，把擁塞窗口增加至多一個(gè)MSS的數(shù)值。每經(jīng)過一個(gè)傳輸輪次，擁塞窗口 cwnd 就加倍。 為了防止擁塞窗口cwnd增長(zhǎng)過大引起網(wǎng)絡(luò)擁塞，還需要設(shè)置一個(gè)慢開始門限ssthresh狀態(tài)變量。

當(dāng) cwnd < ssthresh 時(shí)，使用慢開始算法。

當(dāng) cwnd > ssthresh 時(shí)，停止使用慢開始算法而改用擁塞避免算法。

當(dāng) cwnd = ssthresh 時(shí)，既可使用慢開始算法，也可使用擁塞控制避免算法。

擁塞避免

讓擁塞窗口cwnd緩慢地增大，每經(jīng)過一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規(guī)律緩慢增長(zhǎng)。

無論在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有收到確認(rèn)），就要把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送 方窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd重新設(shè)置為1，執(zhí)行慢開始算法。這樣做的目的就是要迅速減少主機(jī)發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生 擁塞的路由器有足夠時(shí)間把隊(duì)列中積壓的分組處理完畢。

快重傳

有時(shí)個(gè)別報(bào)文段會(huì)在網(wǎng)絡(luò)中丟失，但實(shí)際上網(wǎng)絡(luò)并未發(fā)生擁塞。如果發(fā)送方遲遲收不到確認(rèn)，就會(huì)產(chǎn)生超時(shí)，就會(huì)誤認(rèn)為網(wǎng)絡(luò)發(fā)生了擁塞。這就導(dǎo)致發(fā)送方錯(cuò)誤地啟動(dòng)慢開始，把擁塞窗口cwnd又設(shè)置為1，因而降低了傳輸效率。

快重傳算法可以避免這個(gè)問題?？熘貍魉惴ㄊ紫纫蠼邮辗矫渴盏揭粋€(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)，使發(fā)送方及早知道有報(bào)文段沒有到達(dá)對(duì)方。

發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段，而不必繼續(xù)等待重傳計(jì)時(shí)器到期。由于發(fā)送方盡早重傳未被確認(rèn)的報(bào)文段，因此采用快重傳后可以使整個(gè)網(wǎng)絡(luò)吞吐量提高約20%。

快恢復(fù)

當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)，就會(huì)把慢開始門限ssthresh減半，接著把cwnd值設(shè)置為慢開始門限ssthresh減半后的數(shù)值，然后開始執(zhí)行擁塞避免算法，使擁塞窗口緩慢地線性增大。

在采用快恢復(fù)算法時(shí)，慢開始算法只是在TCP連接建立時(shí)和網(wǎng)絡(luò)出現(xiàn)超時(shí)時(shí)才使用。 采用這樣的擁塞控制方法使得TCP的性能有明顯的改進(jìn)。

HTTP協(xié)議的特點(diǎn)？

1. HTTP允許傳輸任意類型的數(shù)據(jù)。傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。
2. 無狀態(tài)。對(duì)于客戶端每次發(fā)送的請(qǐng)求，服務(wù)器都認(rèn)為是一個(gè)新的請(qǐng)求，上一次會(huì)話和下一次會(huì)話之間沒有聯(lián)系。
3. 支持客戶端/服務(wù)器模式。

HTTP報(bào)文格式

HTTP請(qǐng)求由請(qǐng)求行、請(qǐng)求頭部、空行和請(qǐng)求體四個(gè)部分組成。

• 請(qǐng)求行：包括請(qǐng)求方法，訪問的資源URL，使用的HTTP版本。GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。
• 請(qǐng)求頭：格式為“屬性名:屬性值”，服務(wù)端根據(jù)請(qǐng)求頭獲取客戶端的信息，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。
• 請(qǐng)求體：用戶的請(qǐng)求數(shù)據(jù)如用戶名，密碼等。

請(qǐng)求報(bào)文示例：

POST /xxx HTTP/1.1 請(qǐng)求行
Accept:image/gif.image/jpeg, 請(qǐng)求頭部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=dabin 請(qǐng)求體

HTTP響應(yīng)也由四個(gè)部分組成，分別是：狀態(tài)行、響應(yīng)頭、空行和響應(yīng)體。

• 狀態(tài)行：協(xié)議版本，狀態(tài)碼及狀態(tài)描述。
• 響應(yīng)頭：響應(yīng)頭字段主要有connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires。
• 響應(yīng)體：服務(wù)器返回給客戶端的內(nèi)容。

響應(yīng)報(bào)文示例：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <body>響應(yīng)體</body>
</html>

HTTP狀態(tài)碼有哪些？

HTTP 狀態(tài)碼是服務(wù)器端返回給客戶端的響應(yīng)狀態(tài)碼，根據(jù)狀態(tài)碼我們就能知道服務(wù)器端想要給客戶端表達(dá)的具體含義，比如 200 就表示請(qǐng)求訪問成功，500 就表示服務(wù)器端程序出錯(cuò)等。HTTP 狀態(tài)碼可分為 5 大類：

1. 1XX：消息狀態(tài)碼。
2. 2XX：成功狀態(tài)碼。
3. 3XX：重定向狀態(tài)碼。
4. 4XX：客戶端錯(cuò)誤狀態(tài)碼。
5. 5XX：服務(wù)端錯(cuò)誤狀態(tài)碼。

這 5 大類中又包含了很多具體的狀態(tài)碼。

1XX為消息狀態(tài)碼，其中：

• 100：Continue 繼續(xù)?？蛻舳藨?yīng)繼續(xù)其請(qǐng)求。
• 101：Switching Protocols 切換協(xié)議。服務(wù)器根據(jù)客戶端的請(qǐng)求切換協(xié)議。只能切換到更高級(jí)的協(xié)議，例如，切換到 HTTP 的新版本協(xié)議。

2XX為成功狀態(tài)碼，其中：

• 200：OK 請(qǐng)求成功。一般用于 GET 與 POST 請(qǐng)求。
• 201：Created 已創(chuàng)建。成功請(qǐng)求并創(chuàng)建了新的資源。
• 202：Accepted 已接受。已經(jīng)接受請(qǐng)求，但未處理完成。
• 203：Non-Authoritative Information 非授權(quán)信息。請(qǐng)求成功。但返回的 meta 信息不在原始的服務(wù)器，而是一個(gè)副本。
• 204：No Content 無內(nèi)容。服務(wù)器成功處理，但未返回內(nèi)容。在未更新網(wǎng)頁(yè)的情況下，可確保瀏覽器繼續(xù)顯示當(dāng)前文檔。
• 205：Reset Content 重置內(nèi)容。服務(wù)器處理成功，用戶終端（例如：瀏覽器）應(yīng)重置文檔視圖?？赏ㄟ^此返回碼清除瀏覽器的表單域。
• 206：Partial Content 部分內(nèi)容。服務(wù)器成功處理了部分 GET 請(qǐng)求。

3XX為重定向狀態(tài)碼，其中：

• 300：Multiple Choices 多種選擇。請(qǐng)求的資源可包括多個(gè)位置，相應(yīng)可返回一個(gè)資源特征與地址的列表用于用戶終端（例如：瀏覽器）選擇。
• 301：Moved Permanently 永久移動(dòng)。請(qǐng)求的資源已被永久的移動(dòng)到新 URI，返回信息會(huì)包括新的 URI，瀏覽器會(huì)自動(dòng)定向到新 URI。今后任何新的請(qǐng)求都應(yīng)使用新的 URI 代替。
• 302：Found 臨時(shí)移動(dòng)，與 301 類似。但資源只是臨時(shí)被移動(dòng)?？蛻舳藨?yīng)繼續(xù)使用原有URI。
• 303：See Other 查看其它地址。與 301 類似。使用 GET 和 POST 請(qǐng)求查看。
• 304：Not Modified 未修改。所請(qǐng)求的資源未修改，服務(wù)器返回此狀態(tài)碼時(shí)，不會(huì)返回任何資源?？蛻舳送ǔ?huì)緩存訪問過的資源，通過提供一個(gè)頭信息指出客戶端希望只返回在指定日期之后修改的資源。
• 305：Use Proxy 使用代理。所請(qǐng)求的資源必須通過代理訪問。
• 306：Unused 已經(jīng)被廢棄的 HTTP 狀態(tài)碼。
• 307：Temporary Redirect 臨時(shí)重定向。與 302 類似。使用 GET 請(qǐng)求重定向。

4XX為客戶端錯(cuò)誤狀態(tài)碼，其中：

• 400：Bad Request 客戶端請(qǐng)求的語(yǔ)法錯(cuò)誤，服務(wù)器無法理解。
• 401：Unauthorized 請(qǐng)求要求用戶的身份認(rèn)證。
• 402：Payment Required 保留，將來使用。
• 403：Forbidden 服務(wù)器理解請(qǐng)求客戶端的請(qǐng)求，但是拒絕執(zhí)行此請(qǐng)求。
• 404：Not Found 服務(wù)器無法根據(jù)客戶端的請(qǐng)求找到資源（網(wǎng)頁(yè)）。通過此代碼，網(wǎng)站設(shè)計(jì)人員可設(shè)置"您所請(qǐng)求的資源無法找到"的個(gè)性頁(yè)面。
• 405：Method Not Allowed 客戶端請(qǐng)求中的方法被禁止。
• 406：Not Acceptable 服務(wù)器無法根據(jù)客戶端請(qǐng)求的內(nèi)容特性完成請(qǐng)求。
• 407：Proxy Authentication Required 請(qǐng)求要求代理的身份認(rèn)證，與 401 類似，但請(qǐng)求者應(yīng)當(dāng)使用代理進(jìn)行授權(quán)。
• 408：Request Time-out 服務(wù)器等待客戶端發(fā)送的請(qǐng)求時(shí)間過長(zhǎng)，超時(shí)。
• 409：Conflict 服務(wù)器完成客戶端的 PUT 請(qǐng)求時(shí)可能返回此代碼，服務(wù)器處理請(qǐng)求時(shí)發(fā)生了沖突。
• 410：Gone 客戶端請(qǐng)求的資源已經(jīng)不存在。410 不同于 404，如果資源以前有現(xiàn)在被永久刪除了可使用 410 代碼，網(wǎng)站設(shè)計(jì)人員可通過 301 代碼指定資源的新位置。
• 411：Length Required 服務(wù)器無法處理客戶端發(fā)送的不帶 Content-Length 的請(qǐng)求信息。
• 412：Precondition Failed 客戶端請(qǐng)求信息的先決條件錯(cuò)誤。
• 413：Request Entity Too Large 由于請(qǐng)求的實(shí)體過大，服務(wù)器無法處理，因此拒絕請(qǐng)求。為防止客戶端的連續(xù)請(qǐng)求，服務(wù)器可能會(huì)關(guān)閉連接。如果只是服務(wù)器暫時(shí)無法處理，則會(huì)包含一個(gè) Retry-After 的響應(yīng)信息。
• 414：Request-URI Too Large 請(qǐng)求的 URI 過長(zhǎng)（URI通常為網(wǎng)址），服務(wù)器無法處理。
• 415：Unsupported Media Type 服務(wù)器無法處理請(qǐng)求附帶的媒體格式。
• 416：Requested range not satisfiable 客戶端請(qǐng)求的范圍無效。
• 417：Expectation Failed 服務(wù)器無法滿足 Expect 的請(qǐng)求頭信息。

5XX為服務(wù)端錯(cuò)誤狀態(tài)碼，其中：

• 500：Internal Server Error 服務(wù)器內(nèi)部錯(cuò)誤，無法完成請(qǐng)求。
• 501：Not Implemented 服務(wù)器不支持請(qǐng)求的功能，無法完成請(qǐng)求。
• 502：Bad Gateway 作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)，從遠(yuǎn)程服務(wù)器接收到了一個(gè)無效的響應(yīng)。
• 503：Service Unavailable 由于超載或系統(tǒng)維護(hù)，服務(wù)器暫時(shí)的無法處理客戶端的請(qǐng)求。延時(shí)的長(zhǎng)度可包含在服務(wù)器的Retry-After頭信息中。
• 504：Gateway Time-out 充當(dāng)網(wǎng)關(guān)或代理的服務(wù)器，未及時(shí)從遠(yuǎn)端服務(wù)器獲取請(qǐng)求。
• 505：HTTP Version not supported 服務(wù)器不支持請(qǐng)求的HTTP協(xié)議的版本，無法完成處理。

總結(jié)一下：

HTTP 狀態(tài)碼分為 5 大類：1XX：表示消息狀態(tài)碼；2XX：表示成功狀態(tài)碼；3XX：表示重定向狀態(tài)碼；4XX：表示客戶端錯(cuò)誤狀態(tài)碼；5XX：表示服務(wù)端錯(cuò)誤狀態(tài)碼。其中常見的具體狀態(tài)碼有：200：請(qǐng)求成功；301：永久重定向；302：臨時(shí)重定向；404：無法找到此頁(yè)面；405：請(qǐng)求的方法類型不支持；500：服務(wù)器內(nèi)部出錯(cuò)。

HTTP 協(xié)議包括哪些請(qǐng)求？

HTTP協(xié)議中共定義了八種方法來表示對(duì)Request-URI指定的資源的不同操作方式，具體如下：

• GET：向特定的資源發(fā)出請(qǐng)求。
• POST：向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的創(chuàng)建和/或已有資源的修改。
• OPTIONS：返回服務(wù)器針對(duì)特定資源所支持的HTTP請(qǐng)求方法。也可以利用向Web服務(wù)器發(fā)送'*'的請(qǐng)求來測(cè)試服務(wù)器的功能性。
• HEAD：向服務(wù)器索要與GET請(qǐng)求相一致的響應(yīng)，只不過響應(yīng)體將不會(huì)被返回。這一方法可以在不必傳輸整個(gè)響應(yīng)內(nèi)容的情況下，就可以獲取包含在響應(yīng)消息頭中的元信息。
• PUT：向指定資源位置上傳其最新內(nèi)容。
• DELETE：請(qǐng)求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源。
• TRACE：回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。
• CONNECT：HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。

HTTP狀態(tài)碼301和302的區(qū)別？

• 301：（永久性轉(zhuǎn)移）請(qǐng)求的網(wǎng)頁(yè)已被永久移動(dòng)到新位置。服務(wù)器返回此響應(yīng)時(shí)，會(huì)自動(dòng)將請(qǐng)求者轉(zhuǎn)到新位置。
• 302：（暫時(shí)性轉(zhuǎn)移）服務(wù)器目前正從不同位置的網(wǎng)頁(yè)響應(yīng)請(qǐng)求，但請(qǐng)求者應(yīng)繼續(xù)使用原有位置來進(jìn)行以后的請(qǐng)求。此代碼與響應(yīng)GET和HEAD請(qǐng)求的301代碼類似，會(huì)自動(dòng)將請(qǐng)求者轉(zhuǎn)到不同的位置。

舉個(gè)形象的例子：當(dāng)一個(gè)網(wǎng)站或者網(wǎng)頁(yè)24—48小時(shí)內(nèi)臨時(shí)移動(dòng)到一個(gè)新的位置，這時(shí)候就要進(jìn)行302跳轉(zhuǎn)，打個(gè)比方說，我有一套房子，但是最近走親戚去親戚家住了，過兩天我還回來的。而使用301跳轉(zhuǎn)的場(chǎng)景就是之前的網(wǎng)站因?yàn)槟撤N原因需要移除掉，然后要到新的地址訪問，是永久性的，就比如你的那套房子其實(shí)是租的，現(xiàn)在租期到了，你又在另一個(gè)地方找到了房子，之前租的房子不住了。

POST和GET的區(qū)別？

• GET 和 POST 最本質(zhì)的區(qū)別是規(guī)范上的區(qū)別，在規(guī)范中，定義 GET 請(qǐng)求是用來獲取資源的，也就是進(jìn)行查詢操作的，而 POST 請(qǐng)求是用來傳輸實(shí)體對(duì)象的，因此會(huì)使用 POST 來進(jìn)行添加、修改和刪除等操作。
• GET請(qǐng)求參數(shù)通過URL傳遞，POST的參數(shù)放在請(qǐng)求體中。
• GET 請(qǐng)求可以直接進(jìn)行回退和刷新，不會(huì)對(duì)用戶和程序產(chǎn)生任何影響；而 POST 請(qǐng)求如果直接回滾和刷新將會(huì)把數(shù)據(jù)再次提交。
• GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包；POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包。對(duì)于GET方式的請(qǐng)求，瀏覽器會(huì)把請(qǐng)求頭和請(qǐng)求體一并發(fā)送出去；而對(duì)于POST，瀏覽器先發(fā)送請(qǐng)求頭，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送請(qǐng)求體。
• GET 請(qǐng)求一般會(huì)被緩存，比如常見的 CSS、JS、HTML 請(qǐng)求等都會(huì)被緩存；而 POST 請(qǐng)求默認(rèn)是不進(jìn)行緩存的。
• GET請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會(huì)被保留。

URI和URL的區(qū)別

• URI，全稱是Uniform Resource Identifier)，中文翻譯是統(tǒng)一資源標(biāo)志符，主要作用是唯一標(biāo)識(shí)一個(gè)資源。
• URL，全稱是Uniform Resource Location)，中文翻譯是統(tǒng)一資源定位符，主要作用是提供資源的路徑。打個(gè)經(jīng)典比喻吧，URI像是身份證，可以唯一標(biāo)識(shí)一個(gè)人，而URL更像一個(gè)住址，可以通過URL找到這個(gè)人。

如何理解HTTP協(xié)議是無狀態(tài)的

當(dāng)瀏覽器第一次發(fā)送請(qǐng)求給服務(wù)器時(shí)，服務(wù)器響應(yīng)了；如果同個(gè)瀏覽器發(fā)起第二次請(qǐng)求給服務(wù)器時(shí)，它還是會(huì)響應(yīng)，但是呢，服務(wù)器不知道你就是剛才的那個(gè)瀏覽器。簡(jiǎn)言之，服務(wù)器不會(huì)去記住你是誰(shuí)，所以是無狀態(tài)協(xié)議。

HTTP長(zhǎng)連接和短連接？

HTTP短連接：瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。HTTP1.0默認(rèn)使用的是短連接。

HTTP長(zhǎng)連接：指的是復(fù)用TCP連接。多個(gè)HTTP請(qǐng)求可以復(fù)用同一個(gè)TCP連接，這就節(jié)省了TCP連接建立和斷開的消耗。

HTTP/1.1起，默認(rèn)使用長(zhǎng)連接。要使用長(zhǎng)連接，客戶端和服務(wù)器的HTTP首部的Connection都要設(shè)置為keep-alive，才能支持長(zhǎng)連接。

HTTP 如何實(shí)現(xiàn)長(zhǎng)連接？

HTTP分為長(zhǎng)連接和短連接，本質(zhì)上說的是TCP的長(zhǎng)短連接。TCP連接是一個(gè)雙向的通道，它是可以保持一段時(shí)間不關(guān)閉的，因此TCP連接才具有真正的長(zhǎng)連接和短連接這一說法哈。

TCP長(zhǎng)連接可以復(fù)用一個(gè)TCP連接，來發(fā)起多次的HTTP請(qǐng)求，這樣就可以減少資源消耗，比如一次請(qǐng)求HTML，如果是短連接的話，可能還需要請(qǐng)求后續(xù)的JS/CSS。

如何設(shè)置長(zhǎng)連接？

通過在頭部（請(qǐng)求和響應(yīng)頭）設(shè)置Connection字段指定為keep-alive，HTTP/1.0協(xié)議支持，但是是默認(rèn)關(guān)閉的，從HTTP/1.1以后，連接默認(rèn)都是長(zhǎng)連接。

HTTP長(zhǎng)連接在什么時(shí)候會(huì)超時(shí)？

HTTP一般會(huì)有httpd守護(hù)進(jìn)程，里面可以設(shè)置keep-alive timeout，當(dāng)tcp連接閑置超過這個(gè)時(shí)間就會(huì)關(guān)閉，也可以在HTTP的header里面設(shè)置超時(shí)時(shí)間。

TCP 的keep-alive包含三個(gè)參數(shù)，支持在系統(tǒng)內(nèi)核的net.ipv4里面設(shè)置；當(dāng) TCP 連接之后，閑置了tcp_keepalive_time，則會(huì)發(fā)生偵測(cè)包，如果沒有收到對(duì)方的ACK，那么會(huì)每隔 tcp_keepalive_intvl再發(fā)一次，直到發(fā)送了tcp_keepalive_probes，就會(huì)丟棄該連接。

HTTP1.1和 HTTP2.0的區(qū)別？

HTTP2.0相比HTTP1.1支持的特性：

• 新的二進(jìn)制格式：HTTP1.1 基于文本格式傳輸數(shù)據(jù)；HTTP2.0采用二進(jìn)制格式傳輸數(shù)據(jù)，解析更高效。

• 多路復(fù)用：在一個(gè)連接里，允許同時(shí)發(fā)送多個(gè)請(qǐng)求或響應(yīng)，并且這些請(qǐng)求或響應(yīng)能夠并行的傳輸而不被阻塞，避免 HTTP1.1 出現(xiàn)的”隊(duì)頭堵塞”問題。

• 頭部壓縮，HTTP1.1的header帶有大量信息，而且每次都要重復(fù)發(fā)送；HTTP2.0 把header從數(shù)據(jù)中分離，并封裝成頭幀和數(shù)據(jù)幀，使用特定算法壓縮頭幀，有效減少頭信息大小。并且HTTP2.0在客戶端和服務(wù)器端記錄了之前發(fā)送的鍵值對(duì)，對(duì)于相同的數(shù)據(jù)，不會(huì)重復(fù)發(fā)送。比如請(qǐng)求a發(fā)送了所有的頭信息字段，請(qǐng)求b則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開銷。

• 服務(wù)端推送：HTTP2.0允許服務(wù)器向客戶端推送資源，無需客戶端發(fā)送請(qǐng)求到服務(wù)器獲取。

HTTPS與HTTP的區(qū)別？

1. HTTP是超文本傳輸協(xié)議，信息是明文傳輸；HTTPS則是具有安全性的ssl加密傳輸協(xié)議。
2. HTTP和HTTPS用的端口不一樣，HTTP端口是80，HTTPS是443。
3. HTTPS協(xié)議需要到CA機(jī)構(gòu)申請(qǐng)證書，一般需要一定的費(fèi)用。
4. HTTP運(yùn)行在TCP協(xié)議之上；HTTPS運(yùn)行在SSL協(xié)議之上，SSL運(yùn)行在TCP協(xié)議之上。

什么是數(shù)字證書？

服務(wù)端可以向證書頒發(fā)機(jī)構(gòu)CA申請(qǐng)證書，以避免中間人攻擊（防止證書被篡改）。證書包含三部分內(nèi)容：證書內(nèi)容、證書簽名算法和簽名，簽名是為了驗(yàn)證身份。

服務(wù)端把證書傳輸給瀏覽器，瀏覽器從證書里取公鑰。證書可以證明該公鑰對(duì)應(yīng)本網(wǎng)站。

數(shù)字簽名的制作過程：

1. CA使用證書簽名算法對(duì)證書內(nèi)容進(jìn)行hash運(yùn)算。
2. 對(duì)hash后的值用CA的私鑰加密，得到數(shù)字簽名。

瀏覽器驗(yàn)證過程：

1. 獲取證書，得到證書內(nèi)容、證書簽名算法和數(shù)字簽名。
2. 用CA機(jī)構(gòu)的公鑰對(duì)數(shù)字簽名解密（由于是瀏覽器信任的機(jī)構(gòu)，所以瀏覽器會(huì)保存它的公鑰）。
3. 用證書里的簽名算法對(duì)證書內(nèi)容進(jìn)行hash運(yùn)算。
4. 比較解密后的數(shù)字簽名和對(duì)證書內(nèi)容做hash運(yùn)算后得到的哈希值，相等則表明證書可信。

HTTPS原理

首先是TCP三次握手，然后客戶端發(fā)起一個(gè)HTTPS連接建立請(qǐng)求，客戶端先發(fā)一個(gè)Client Hello的包，然后服務(wù)端響應(yīng)Server Hello，接著再給客戶端發(fā)送它的證書，然后雙方經(jīng)過密鑰交換，最后使用交換的密鑰加解密數(shù)據(jù)。

1. 協(xié)商加密算法 。在Client Hello里面客戶端會(huì)告知服務(wù)端自己當(dāng)前的一些信息，包括客戶端要使用的TLS版本，支持的加密算法，要訪問的域名，給服務(wù)端生成的一個(gè)隨機(jī)數(shù)（Nonce）等。需要提前告知服務(wù)器想要訪問的域名以便服務(wù)器發(fā)送相應(yīng)的域名的證書過來。

2. 服務(wù)端響應(yīng)Server Hello，告訴客戶端服務(wù)端選中的加密算法。

3. 接著服務(wù)端給客戶端發(fā)來了2個(gè)證書。第二個(gè)證書是第一個(gè)證書的簽發(fā)機(jī)構(gòu)（CA）的證書。

4. 客戶端使用證書的認(rèn)證機(jī)構(gòu)CA公開發(fā)布的RSA公鑰對(duì)該證書進(jìn)行驗(yàn)證，下圖表明證書認(rèn)證成功。

5. 驗(yàn)證通過之后，瀏覽器和服務(wù)器通過密鑰交換算法產(chǎn)生共享的對(duì)稱密鑰。

6. 開始傳輸數(shù)據(jù)，使用同一個(gè)對(duì)稱密鑰來加解密。

DNS 的解析過程？

1. 瀏覽器搜索自己的DNS緩存
2. 若沒有，則搜索操作系統(tǒng)中的DNS緩存和hosts文件
3. 若沒有，則操作系統(tǒng)將域名發(fā)送至本地域名服務(wù)器，本地域名服務(wù)器查詢自己的DNS緩存，查找成功則返回結(jié)果，否則依次向根域名服務(wù)器、頂級(jí)域名服務(wù)器、權(quán)限域名服務(wù)器發(fā)起查詢請(qǐng)求，最終返回IP地址給本地域名服務(wù)器
4. 本地域名服務(wù)器將得到的IP地址返回給操作系統(tǒng)，同時(shí)自己也將IP地址緩存起來
5. 操作系統(tǒng)將 IP 地址返回給瀏覽器，同時(shí)自己也將IP地址緩存起來
6. 瀏覽器得到域名對(duì)應(yīng)的IP地址

瀏覽器中輸入U(xiǎn)RL返回頁(yè)面過程？

1. 解析域名，找到主機(jī) IP。
2. 瀏覽器利用 IP 直接與網(wǎng)站主機(jī)通信，三次握手，建立 TCP 連接。瀏覽器會(huì)以一個(gè)隨機(jī)端口向服務(wù)端的 web 程序 80 端口發(fā)起 TCP 的連接。
3. 建立 TCP 連接后，瀏覽器向主機(jī)發(fā)起一個(gè)HTTP請(qǐng)求。
4. 參數(shù)從客戶端傳遞到服務(wù)器端。
5. 服務(wù)器端得到客戶端參數(shù)之后，進(jìn)行相應(yīng)的業(yè)務(wù)處理，再將結(jié)果封裝成 HTTP 包，返回給客戶端。
6. 服務(wù)器端和客戶端的交互完成，斷開 TCP 連接（4 次揮手）。
7. 瀏覽器解析響應(yīng)內(nèi)容，進(jìn)行渲染，呈現(xiàn)給用戶。

DNS 域名解析的過程

在網(wǎng)絡(luò)中定位是依靠 IP 進(jìn)行身份定位的，所以 URL 訪問的第一步便是先要得到服務(wù)器端的 IP 地址。而得到服務(wù)器的 IP 地址需要使用 DNS（Domain Name System，域名系統(tǒng)）域名解析，DNS 域名解析就是通過 URL 找到與之相對(duì)應(yīng)的 IP 地址。

DNS 域名解析的大致流程如下：

1. 先檢查瀏覽器中的 DNS 緩存，如果瀏覽器中有對(duì)應(yīng)的記錄會(huì)直接使用，并完成解析；
2. 如果瀏覽器沒有緩存，那就去查詢操作系統(tǒng)的緩存，如果查詢到記錄就可以直接返回 IP 地址，完成解析；
3. 如果操作系統(tǒng)沒有 DNS 緩存，就會(huì)去查看本地 host 文件，Windows 操作系統(tǒng)下，host 文件一般位于 "C:\Windows\System32\drivers\etc\hosts"，如果 host 文件有記錄則直接使用；
4. 如果本地 host 文件沒有相應(yīng)的記錄，會(huì)請(qǐng)求本地 DNS 服務(wù)器，本地 DNS 服務(wù)器一般是由本地網(wǎng)絡(luò)服務(wù)商如移動(dòng)、聯(lián)通等提供。通常情況下可通過 DHCP 自動(dòng)分配，當(dāng)然也可以自己手動(dòng)配置。目前用的比較多的是谷歌提供的公用 DNS 是 8.8.8.8 和國(guó)內(nèi)的公用 DNS 是 114.114.114.114。
5. 如果本地 DNS 服務(wù)器沒有相應(yīng)的記錄，就會(huì)去根域名服務(wù)器查詢了。為了能更高效完成全球所有域名的解析請(qǐng)求，根域名服務(wù)器本身并不會(huì)直接去解析域名，而是會(huì)把不同的解析請(qǐng)求分配給下面的其他服務(wù)器去完成。

圖片來源于網(wǎng)絡(luò)

什么是cookie和session？

由于HTTP協(xié)議是無狀態(tài)的協(xié)議，需要用某種機(jī)制來識(shí)具體的用戶身份，用來跟蹤用戶的整個(gè)會(huì)話。常用的會(huì)話跟蹤技術(shù)是cookie與session。

cookie就是由服務(wù)器發(fā)給客戶端的特殊信息，而這些信息以文本文件的方式存放在客戶端，然后客戶端每次向服務(wù)器發(fā)送請(qǐng)求的時(shí)候都會(huì)帶上這些特殊的信息。說得更具體一些：當(dāng)用戶使用瀏覽器訪問一個(gè)支持cookie的網(wǎng)站的時(shí)候，用戶會(huì)提供包括用戶名在內(nèi)的個(gè)人信息并且提交至服務(wù)器；接著，服務(wù)器在向客戶端回傳相應(yīng)的超文本的同時(shí)也會(huì)發(fā)回這些個(gè)人信息，當(dāng)然這些信息并不是存放在HTTP響應(yīng)體中的，而是存放于HTTP響應(yīng)頭；當(dāng)客戶端瀏覽器接收到來自服務(wù)器的響應(yīng)之后，瀏覽器會(huì)將這些信息存放在一個(gè)統(tǒng)一的位置。 自此，客戶端再向服務(wù)器發(fā)送請(qǐng)求的時(shí)候，都會(huì)把相應(yīng)的cookie存放在HTTP請(qǐng)求頭再次發(fā)回至服務(wù)器。服務(wù)器在接收到來自客戶端瀏覽器的請(qǐng)求之后，就能夠通過分析存放于請(qǐng)求頭的cookie得到客戶端特有的信息，從而動(dòng)態(tài)生成與該客戶端相對(duì)應(yīng)的內(nèi)容。網(wǎng)站的登錄界面中“請(qǐng)記住我”這樣的選項(xiàng)，就是通過cookie實(shí)現(xiàn)的。

cookie工作流程：

1. servlet創(chuàng)建cookie，保存少量數(shù)據(jù)，發(fā)送給瀏覽器。
2. 瀏覽器獲得服務(wù)器發(fā)送的cookie數(shù)據(jù)，將自動(dòng)的保存到瀏覽器端。
3. 下次訪問時(shí)，瀏覽器將自動(dòng)攜帶cookie數(shù)據(jù)發(fā)送給服務(wù)器。

session原理：首先瀏覽器請(qǐng)求服務(wù)器訪問web站點(diǎn)時(shí)，服務(wù)器首先會(huì)檢查這個(gè)客戶端請(qǐng)求是否已經(jīng)包含了一個(gè)session標(biāo)識(shí)、稱為SESSIONID，如果已經(jīng)包含了一個(gè)sessionid則說明以前已經(jīng)為此客戶端創(chuàng)建過session，服務(wù)器就按照sessionid把這個(gè)session檢索出來使用，如果客戶端請(qǐng)求不包含session id，則服務(wù)器為此客戶端創(chuàng)建一個(gè)session，并且生成一個(gè)與此session相關(guān)聯(lián)的獨(dú)一無二的sessionid存放到cookie中，這個(gè)sessionid將在本次響應(yīng)中返回到客戶端保存，這樣在交互的過程中，瀏覽器端每次請(qǐng)求時(shí)，都會(huì)帶著這個(gè)sessionid，服務(wù)器根據(jù)這個(gè)sessionid就可以找得到對(duì)應(yīng)的session。以此來達(dá)到共享數(shù)據(jù)的目的。 這里需要注意的是，session不會(huì)隨著瀏覽器的關(guān)閉而死亡，而是等待超時(shí)時(shí)間。

cookie和session的區(qū)別？

• 作用范圍不同，Cookie 保存在客戶端，Session 保存在服務(wù)器端。
• 有效期不同，Cookie 可設(shè)置為長(zhǎng)時(shí)間保持，比如我們經(jīng)常使用的默認(rèn)登錄功能，Session 一般失效時(shí)間較短，客戶端關(guān)閉或者 Session 超時(shí)都會(huì)失效。
• 隱私策略不同，Cookie 存儲(chǔ)在客戶端，容易被竊??；Session 存儲(chǔ)在服務(wù)端，安全性相對(duì) Cookie 要好一些。
• 存儲(chǔ)大小不同， 單個(gè) Cookie 保存的數(shù)據(jù)不能超過 4K；對(duì)于 Session 來說存儲(chǔ)沒有上限，但出于對(duì)服務(wù)器的性能考慮，Session 內(nèi)不要存放過多的數(shù)據(jù)，并且需要設(shè)置 Session 刪除機(jī)制。

什么是對(duì)稱加密和非對(duì)稱加密？

對(duì)稱加密：通信雙方使用相同的密鑰進(jìn)行加密。特點(diǎn)是加密速度快，但是缺點(diǎn)是密鑰泄露會(huì)導(dǎo)致密文數(shù)據(jù)被破解。常見的對(duì)稱加密有AES和DES算法。

非對(duì)稱加密：它需要生成兩個(gè)密鑰，公鑰和私鑰。公鑰是公開的，任何人都可以獲得，而私鑰是私人保管的。公鑰負(fù)責(zé)加密，私鑰負(fù)責(zé)解密；或者私鑰負(fù)責(zé)加密，公鑰負(fù)責(zé)解密。這種加密算法安全性更高，但是計(jì)算量相比對(duì)稱加密大很多，加密和解密都很慢。常見的非對(duì)稱算法有RSA和DSA。

說說 WebSocket與socket的區(qū)別

Socket是一套標(biāo)準(zhǔn)，它完成了對(duì)TCP/IP的高度封裝，屏蔽網(wǎng)絡(luò)細(xì)節(jié)，以方便開發(fā)者更好地進(jìn)行網(wǎng)絡(luò)編程。Socket其實(shí)就是等于IP地址 + 端口 + 協(xié)議。

WebSocket是一個(gè)持久化的協(xié)議，它是伴隨H5而出的協(xié)議，用來解決http不支持持久化連接的問題。

Socket一個(gè)是網(wǎng)編編程的標(biāo)準(zhǔn)接口，而WebSocket則是應(yīng)用層通信協(xié)議。

ARP協(xié)議的工作過程？

ARP解決了同一個(gè)局域網(wǎng)上的主機(jī)和路由器IP和MAC地址的解析。

• 每臺(tái)主機(jī)都會(huì)在自己的ARP緩沖區(qū)中建立一個(gè)ARP列表，以表示IP地址和MAC地址的對(duì)應(yīng)關(guān)系。
• 當(dāng)源主機(jī)需要將一個(gè)數(shù)據(jù)包要發(fā)送到目的主機(jī)時(shí)，會(huì)首先檢查自己 ARP列表中是否存在該 IP地址對(duì)應(yīng)的MAC地址，如果有，就直接將數(shù)據(jù)包發(fā)送到這個(gè)MAC地址；如果沒有，就向本地網(wǎng)段發(fā)起一個(gè)ARP請(qǐng)求的廣播包，查詢此目的主機(jī)對(duì)應(yīng)的MAC地址。此ARP請(qǐng)求數(shù)據(jù)包里包括源主機(jī)的IP地址、硬件地址、以及目的主機(jī)的IP地址。
• 網(wǎng)絡(luò)中所有的主機(jī)收到這個(gè)ARP請(qǐng)求后，會(huì)檢查數(shù)據(jù)包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此數(shù)據(jù)包；如果相同，該主機(jī)首先將發(fā)送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已經(jīng)存在該IP的信息，則將其覆蓋，然后給源主機(jī)發(fā)送一個(gè) ARP響應(yīng)數(shù)據(jù)包，告訴對(duì)方自己是它需要查找的MAC地址。
• 源主機(jī)收到這個(gè)ARP響應(yīng)數(shù)據(jù)包后，將得到的目的主機(jī)的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息開始數(shù)據(jù)的傳輸。
• 如果源主機(jī)一直沒有收到ARP響應(yīng)數(shù)據(jù)包，表示ARP查詢失敗。

ICMP協(xié)議的功能

ICMP,Internet Control Message Protocol ,Internet控制消息協(xié)議。

• ICMP協(xié)議是一種面向無連接的協(xié)議，用于傳輸出錯(cuò)報(bào)告控制信息。
• 它是一個(gè)非常重要的協(xié)議，它對(duì)于網(wǎng)絡(luò)安全具有極其重要的意義。它屬于網(wǎng)絡(luò)層協(xié)議，主要用于在主機(jī)與路由器之間傳遞控制信息，包括報(bào)告錯(cuò)誤、交換受限控制和狀態(tài)信息等。
• 當(dāng)遇到IP數(shù)據(jù)無法訪問目標(biāo)、IP路由器無法按當(dāng)前的傳輸速率轉(zhuǎn)發(fā)數(shù)據(jù)包等情況時(shí)，會(huì)自動(dòng)發(fā)送ICMP消息。

比如我們?nèi)粘Ｊ褂玫帽容^多的ping，就是基于ICMP的。

什么是DoS、DDoS、DRDoS攻擊？

• DOS: (Denial of Service),翻譯過來就是拒絕服務(wù),一切能引起DOS行為的攻擊都被稱為DOS攻擊。最常見的DoS攻擊就有計(jì)算機(jī)網(wǎng)絡(luò)寬帶攻擊、連通性攻擊。
• DDoS: (Distributed Denial of Service),翻譯過來是分布式拒絕服務(wù)。是指處于不同位置的多個(gè)攻擊者同時(shí)向一個(gè)或幾個(gè)目標(biāo)發(fā)動(dòng)攻擊，或者一個(gè)攻擊者控制了位于不同位置的多臺(tái)機(jī)器并利用這些機(jī)器對(duì)受害者同時(shí)實(shí)施攻擊。常見的DDos有SYN Flood、Ping of Death、ACK Flood、UDP Flood等。
• DRDoS: (Distributed Reflection Denial of Service)，中文是分布式反射拒絕服務(wù)，該方式靠的是發(fā)送大量帶有被害者IP地址的數(shù)據(jù)包給攻擊主機(jī)，然后攻擊主機(jī)對(duì)IP地址源做出大量回應(yīng)，從而形成拒絕服務(wù)攻擊。

什么是CSRF攻擊，如何避免

CSRF，跨站請(qǐng)求偽造（英文全稱是Cross-site request forgery），是一種挾制用戶在當(dāng)前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。

怎么解決CSRF攻擊呢？

• 檢查Referer字段。
• 添加校驗(yàn)token。

什么是XSS攻擊？

XSS，跨站腳本攻擊（Cross-Site Scripting）。它指的是惡意攻擊者往Web頁(yè)面里插入惡意html代碼，當(dāng)用戶瀏覽該頁(yè)之時(shí)，嵌入其中Web里面的html代碼會(huì)被執(zhí)行，從而達(dá)到惡意攻擊用戶的特殊目的。XSS攻擊一般分三種類型：存儲(chǔ)型 、反射型 、DOM型XSS

如何解決XSS攻擊問題？

• 對(duì)輸入進(jìn)行過濾，過濾標(biāo)簽等，只允許合法值。
• HTML轉(zhuǎn)義
• 對(duì)于鏈接跳轉(zhuǎn)，如<a href="xxx" 等，要校驗(yàn)內(nèi)容，禁止以script開頭的非法鏈接。
• 限制輸入長(zhǎng)度

防盜鏈

盜鏈是指服務(wù)提供商自己不提供服務(wù)的內(nèi)容，通過技術(shù)手段（可以理解成爬蟲）去獲取其他網(wǎng)站的資源展示在自己的網(wǎng)站上。常見的盜鏈有以下幾種：圖片盜鏈、音頻盜鏈、視頻盜鏈等。

網(wǎng)站盜鏈會(huì)大量消耗被盜鏈網(wǎng)站的帶寬，而真正的點(diǎn)擊率也許會(huì)很小，嚴(yán)重?fù)p害了被盜鏈網(wǎng)站的利益。

被盜網(wǎng)站就自然會(huì)防盜鏈，可以通過經(jīng)常更換圖片名，也可以通過檢測(cè)referer。因?yàn)檎Ｓ脩粼L問一張圖片一定是從自己的網(wǎng)站點(diǎn)擊鏈接進(jìn)去的，如果一個(gè)請(qǐng)求的referer是其他網(wǎng)站，就說明這是一個(gè)爬蟲。

什么是 Referer？

這里的 Referer 指的是 HTTP 頭部的一個(gè)字段，也稱為 HTTP 來源地址（HTTP Referer），用來表示從哪兒鏈接到目前的網(wǎng)頁(yè)，采用的格式是 URL。換句話說，借著 HTTP Referer 頭部網(wǎng)頁(yè)可以檢查訪客從哪里而來，這也常被用來對(duì)付偽造的跨網(wǎng)站請(qǐng)求。

盜鏈網(wǎng)站會(huì)針對(duì)性進(jìn)行反盜鏈，可以通過在請(qǐng)求的headers中設(shè)置referer來繞過防盜鏈，我們現(xiàn)在使用爬蟲抓取別人的網(wǎng)站也是這樣。

什么是空 Referer，什么時(shí)候會(huì)出現(xiàn)空 Referer？

首先，我們對(duì)空 Referer 的定義為，Referer 頭部的內(nèi)容為空，或者，一個(gè) HTTP 請(qǐng)求中根本不包含 Referer 頭部。

那么什么時(shí)候 HTTP 請(qǐng)求會(huì)不包含 Referer 字段呢？根據(jù) Referer 的定義，它的作用是指示一個(gè)請(qǐng)求是從哪里鏈接過來，那么當(dāng)一個(gè)請(qǐng)求并不是由鏈接觸發(fā)產(chǎn)生的，那么自然也就不需要指定這個(gè)請(qǐng)求的鏈接來源。

比如，直接在瀏覽器的地址欄中輸入一個(gè)資源的 URL 地址，那么這種請(qǐng)求是不會(huì)包含 Referer 字段的，因?yàn)檫@是一個(gè) “憑空產(chǎn)生” 的 HTTP 請(qǐng)求，并不是從一個(gè)地方鏈接過去的。

說下ping的原理

ping，Packet Internet Groper，是一種因特網(wǎng)包探索器，用于測(cè)試網(wǎng)絡(luò)連接量的程序。Ping是工作在TCP/IP網(wǎng)絡(luò)體系結(jié)構(gòu)中應(yīng)用層的一個(gè)服務(wù)命令， 主要是向特定的目的主機(jī)發(fā)送ICMP（Internet Control Message Protocol 因特網(wǎng)報(bào)文控制協(xié)議） 請(qǐng)求報(bào)文，測(cè)試目的站是否可達(dá)及了解其有關(guān)狀態(tài)。

一般來說，ping可以用來檢測(cè)網(wǎng)絡(luò)通不通。它是基于ICMP協(xié)議工作的。假設(shè)機(jī)器A ping機(jī)器B，工作過程如下：文章來源地址http://www.zghlxwxcb.cn/news/detail-418127.html

1. ping通知系統(tǒng)，新建一個(gè)固定格式的ICMP請(qǐng)求數(shù)據(jù)包
2. ICMP協(xié)議，將該數(shù)據(jù)包和目標(biāo)機(jī)器B的IP地址打包，一起轉(zhuǎn)交給IP協(xié)議層
3. IP層協(xié)議將本機(jī)IP地址為源地址，機(jī)器B的IP地址為目標(biāo)地址，加上一些其他的控制信息，構(gòu)建一個(gè)IP數(shù)據(jù)包
4. 先獲取目標(biāo)機(jī)器B的MAC地址。
5. 數(shù)據(jù)鏈路層構(gòu)建一個(gè)數(shù)據(jù)幀，目的地址是IP層傳過來的MAC地址，源地址是本機(jī)的MAC地址
6. 機(jī)器B收到后，對(duì)比目標(biāo)地址，和自己本機(jī)的MAC地址是否一致，符合就處理返回，不符合就丟棄。
7. 根據(jù)目的主機(jī)返回的ICMP回送回答報(bào)文中的時(shí)間戳，從而計(jì)算出往返時(shí)間
8. 最終顯示結(jié)果有這幾項(xiàng)：發(fā)送到目的主機(jī)的IP地址、發(fā)送 & 收到 & 丟失的分組數(shù)、往返時(shí)間的最小、最大& 平均值

到了這里，關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)高頻面試八股文的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！