計(jì)算機(jī)網(wǎng)絡(luò)高頻面試題（2022最新版）
網(wǎng)絡(luò)分層結(jié)構(gòu)
計(jì)算機(jī)網(wǎng)絡(luò)體系大致分為三種，OSI七層模型、TCP/IP四層模型和五層模型。一般面試的時(shí)候考察比較多的是五層模型。
五層模型：應(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é)議等。
傳輸層
網(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è)備的差異。
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。
第一次握手：客戶端向服務(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。第二次握手：服務(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)有效）第三次握手：客戶端收到服務(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)資源。
四次揮手
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)。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的連接釋放。A收到B的確認(rèn)后，進(jìn)入
FIN-WAIT-2（終止等待2）狀態(tài)，等待B發(fā)出的連接釋放報(bào)文段。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)。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)文段。
為什么是四次揮手？
因?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有哪些特點(diǎn)？
TCP是面向連接的運(yùn)輸層協(xié)議。
點(diǎn)對(duì)點(diǎn)，每一條TCP連接只能有兩個(gè)端點(diǎn)。
TCP提供可靠交付的服務(wù)。
TCP提供全雙工通信。
面向字節(jié)流。
說說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和UDP的區(qū)別？
TCP面向連接；UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
TCP提供可靠的服務(wù)；UDP不保證可靠交付。
TCP面向字節(jié)流，把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流；UDP是面向報(bào)文的。
TCP有擁塞控制；UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低（對(duì)實(shí)時(shí)應(yīng)用很有用，如實(shí)時(shí)視頻會(huì)議等）。
每一條TCP連接只能是點(diǎn)到點(diǎn)的；UDP支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的通信方式。
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是面向流，沒有界限的一串?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是如何確保可靠性的呢？
首先，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)砣刂疲?/h1>
防止過多的數(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)？
HTTP允許傳輸任意類型的數(shù)據(jù)。傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。
無狀態(tài)。對(duì)于客戶端每次發(fā)送的請(qǐng)求，服務(wù)器都認(rèn)為是一個(gè)新的請(qǐng)求，上一次會(huì)話和下一次會(huì)話之間沒有聯(lián)系。
支持客戶端/服務(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 協(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)頁已被永久移動(dòng)到新位置。服務(wù)器返回此響應(yīng)時(shí)，會(huì)自動(dòng)將請(qǐng)求者轉(zhuǎn)到新位置。
302：（暫時(shí)性轉(zhuǎn)移）服務(wù)器目前正從不同位置的網(wǎng)頁響應(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)頁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è)地方找到了房子，之前租的房子不住了。
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è)人。
POST和GET的區(qū)別？
GET請(qǐng)求參數(shù)通過URL傳遞，POST的參數(shù)放在請(qǐng)求體中。
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ì)被瀏覽器主動(dòng)緩存，而POST不會(huì)，除非手動(dòng)設(shè)置。
GET請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會(huì)被保留。
如何理解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ì)去記住你是誰，所以是無狀態(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ū)別？
HTTP是超文本傳輸協(xié)議，信息是明文傳輸；HTTPS則是具有安全性的ssl加密傳輸協(xié)議。
HTTP和HTTPS用的端口不一樣，HTTP端口是80，HTTPS是443。
HTTPS協(xié)議需要到CA機(jī)構(gòu)申請(qǐng)證書，一般需要一定的費(fèi)用。
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ù)字簽名的制作過程：
CA使用證書簽名算法對(duì)證書內(nèi)容進(jìn)行hash運(yùn)算。
對(duì)hash后的值用CA的私鑰加密，得到數(shù)字簽名。
瀏覽器驗(yàn)證過程：
獲取證書，得到證書內(nèi)容、證書簽名算法和數(shù)字簽名。
用CA機(jī)構(gòu)的公鑰對(duì)數(shù)字簽名解密（由于是瀏覽器信任的機(jī)構(gòu)，所以瀏覽器會(huì)保存它的公鑰）。
用證書里的簽名算法對(duì)證書內(nèi)容進(jìn)行hash運(yùn)算。
比較解密后的數(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ù)。
協(xié)商加密算法 。在
Client Hello里面客戶端會(huì)告知服務(wù)端自己當(dāng)前的一些信息，包括客戶端要使用的TLS版本，支持的加密算法，要訪問的域名，給服務(wù)端生成的一個(gè)隨機(jī)數(shù)（Nonce）等。需要提前告知服務(wù)器想要訪問的域名以便服務(wù)器發(fā)送相應(yīng)的域名的證書過來。
服務(wù)端響應(yīng)
Server Hello，告訴客戶端服務(wù)端選中的加密算法。
接著服務(wù)端給客戶端發(fā)來了2個(gè)證書。第二個(gè)證書是第一個(gè)證書的簽發(fā)機(jī)構(gòu)（CA）的證書。
客戶端使用證書的認(rèn)證機(jī)構(gòu)CA公開發(fā)布的RSA公鑰對(duì)該證書進(jìn)行驗(yàn)證，下圖表明證書認(rèn)證成功。
驗(yàn)證通過之后，瀏覽器和服務(wù)器通過密鑰交換算法產(chǎn)生共享的對(duì)稱密鑰。
開始傳輸數(shù)據(jù)，使用同一個(gè)對(duì)稱密鑰來加解密。
DNS 的解析過程？
瀏覽器搜索自己的DNS緩存
若沒有，則搜索操作系統(tǒng)中的DNS緩存和hosts文件
若沒有，則操作系統(tǒng)將域名發(fā)送至本地域名服務(wù)器，本地域名服務(wù)器查詢自己的DNS緩存，查找成功則返回結(jié)果，否則依次向根域名服務(wù)器、頂級(jí)域名服務(wù)器、權(quán)限域名服務(wù)器發(fā)起查詢請(qǐng)求，最終返回IP地址給本地域名服務(wù)器
本地域名服務(wù)器將得到的IP地址返回給操作系統(tǒng)，同時(shí)自己也將IP地址緩存起來
操作系統(tǒng)將 IP 地址返回給瀏覽器，同時(shí)自己也將IP地址緩存起來
瀏覽器得到域名對(duì)應(yīng)的IP地址
瀏覽器中輸入U(xiǎn)RL返回頁面過程？
解析域名，找到主機(jī) IP。
瀏覽器利用 IP 直接與網(wǎng)站主機(jī)通信，三次握手，建立 TCP 連接。瀏覽器會(huì)以一個(gè)隨機(jī)端口向服務(wù)端的 web 程序 80 端口發(fā)起 TCP 的連接。
建立 TCP 連接后，瀏覽器向主機(jī)發(fā)起一個(gè)HTTP請(qǐng)求。
服務(wù)器響應(yīng)請(qǐng)求，返回響應(yīng)數(shù)據(jù)。
瀏覽器解析響應(yīng)內(nèi)容，進(jìn)行渲染，呈現(xiàn)給用戶。
什么是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工作流程：
servlet創(chuàng)建cookie，保存少量數(shù)據(jù)，發(fā)送給瀏覽器。
瀏覽器獲得服務(wù)器發(fā)送的cookie數(shù)據(jù)，將自動(dòng)的保存到瀏覽器端。
下次訪問時(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頁面里插入惡意html代碼，當(dāng)用戶瀏覽該頁之時(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)頁，采用的格式是 URL。換句話說，借著 HTTP Referer 頭部網(wǎng)頁可以檢查訪客從哪里而來，這也常被用來對(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，工作過程如下：
ping通知系統(tǒng)，新建一個(gè)固定格式的ICMP請(qǐng)求數(shù)據(jù)包
ICMP協(xié)議，將該數(shù)據(jù)包和目標(biāo)機(jī)器B的IP地址打包，一起轉(zhuǎn)交給IP協(xié)議層
IP層協(xié)議將本機(jī)IP地址為源地址，機(jī)器B的IP地址為目標(biāo)地址，加上一些其他的控制信息，構(gòu)建一個(gè)IP數(shù)據(jù)包
先獲取目標(biāo)機(jī)器B的MAC地址。
數(shù)據(jù)鏈路層構(gòu)建一個(gè)數(shù)據(jù)幀，目的地址是IP層傳過來的MAC地址，源地址是本機(jī)的MAC地址
機(jī)器B收到后，對(duì)比目標(biāo)地址，和自己本機(jī)的MAC地址是否一致，符合就處理返回，不符合就丟棄。
根據(jù)目的主機(jī)返回的ICMP回送回答報(bào)文中的時(shí)間戳，從而計(jì)算出往返時(shí)間
最終顯示結(jié)果有這幾項(xiàng)：發(fā)送到目的主機(jī)的IP地址、發(fā)送 & 收到 & 丟失的分組數(shù)、往返時(shí)間的最小、最大& 平均值
