計算機網絡面試題(精心整理100家互聯(lián)網企業(yè)面試題,史上最全面試題,面試必
時間:2023-06-18 22:09:01 | 來源:網站運營
時間:2023-06-18 22:09:01 來源:網站運營
計算機網絡面試題(精心整理100家互聯(lián)網企業(yè)面試題,史上最全面試題,面試必過):
面試題 | 鏈接 |
---|
java基礎面試題 | https://zhuanlan.zhihu.com/p/531534545 |
Java集合容器面試題 | https://zhuanlan.zhihu.com/p/531774337 |
并發(fā)編程面試題 | https://zhuanlan.zhihu.com/p/531803030 |
Jvm面試題 | https://zhuanlan.zhihu.com/p/531817308 |
計算機網絡面試題 | https://zhuanlan.zhihu.com/p/531820908 |
操作系統(tǒng)面試題 | https://zhuanlan.zhihu.com/p/531830711 |
數(shù)據(jù)結構面試題 | https://zhuanlan.zhihu.com/p/531832879 |
Spring、Spring MVC、Spring boot、Spring Cloud面試題 | https://zhuanlan.zhihu.com/p/531877424 |
mysql面試題 | https://zhuanlan.zhihu.com/p/531891910 |
redis面試題 | https://zhuanlan.zhihu.com/p/531896369 |
MyBatis面試題 | https://zhuanlan.zhihu.com/p/531899933 |
Linux 面試題 | https://zhuanlan.zhihu.com/p/531903527 |
MongoDB面試題 | https://zhuanlan.zhihu.com/p/531905712 |
MQ、RabbitMQ面試題 | https://zhuanlan.zhihu.com/p/531907670 |
設計模式面試題 | https://zhuanlan.zhihu.com/p/531834565 |
計算機網絡面試題
7層模型詳解
2021010409370574什么是網絡協(xié)議,為什么要對網絡協(xié)議分層
網絡協(xié)議是計算機在通信過程中要遵循的一些約定好的規(guī)則。
網絡分層的原因:
- 易于實現(xiàn)和維護,因為各層之間是獨立的,層與層之間不會收到影響。
- 有利于標準化的制定
OSI,TCP/IP,五層協(xié)議的體系結構,以及各層協(xié)議
答:OSI分層 (7層):物理層、數(shù)據(jù)鏈路層、網絡層、傳輸層、會話層、表示層、應用層。 TCP/IP分層(4層):網絡接口層、 網際層、運輸層、 應用層。 五層協(xié)議 (5層):物理層、數(shù)據(jù)鏈路層、網絡層、運輸層、 應用層。 每一層的協(xié)議如下:物理層:RJ45、CLOCK、IEEE802.3 (中繼器,集線器) 數(shù)據(jù)鏈路:PPP、FR、HDLC、VLAN、MAC (網橋,交換機) 網絡層:IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 (路由器) 傳輸層:TCP、UDP、SPX 會話層:NFS、SQL、NETBIOS、RPC 表示層:JPEG、MPEG、ASII 應用層:FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS 每一層的作用如下:物理層:通過媒介傳輸比特,確定機械及電氣規(guī)范(比特Bit) 數(shù)據(jù)鏈路層:將比特組裝成幀和點到點的傳遞(幀F(xiàn)rame) 網絡層:負責數(shù)據(jù)包從源到宿的傳遞和網際互連(包PackeT) 傳輸層:提供端到端的可靠報文傳遞和錯誤恢復(段Segment) 會話層:建立、管理和終止會話(會話協(xié)議數(shù)據(jù)單元SPDU) 表示層:對數(shù)據(jù)進行翻譯、加密和壓縮(表示協(xié)議數(shù)據(jù)單元PPDU) 應用層:允許訪問OSI環(huán)境的手段(應用協(xié)議數(shù)據(jù)單元APDU)
計算機網絡的各層協(xié)議及作用
計算機網絡體系可以大致分為一下三種,七層模型、五層模型和TCP/IP四層模型,一般面試能流暢回答出五層模型就可以了,表示層和會話層被問到的不多。
在這里插入圖片描述應用層的任務是通過應用進程之間的交互來完成特定的網絡作用,常見的應用層協(xié)議有域名系統(tǒng)DNS,HTTP協(xié)議等。
表示層的主要作用是數(shù)據(jù)的表示、安全、壓縮??纱_保一個系統(tǒng)的應用層所發(fā)送的信息可以被另一個系統(tǒng)的應用層讀取。
會話層的主要作用是建立通信鏈接,保持會話過程通信鏈接的暢通,同步兩個節(jié)點之間的對話,決定通信是否被中斷以及通信中斷時決定從何處重新發(fā)送。。
傳輸層的主要作用是負責向兩臺主機進程之間的通信提供數(shù)據(jù)傳輸服務。傳輸層的協(xié)議主要有傳輸控制協(xié)議TCP和用戶數(shù)據(jù)協(xié)議UDP。
網絡層的主要作用是選擇合適的網間路由和交換結點,確保數(shù)據(jù)及時送達。常見的協(xié)議有IP協(xié)議。
數(shù)據(jù)鏈路層的作用是在物理層提供比特流服務的基礎上,建立相鄰結點之間的數(shù)據(jù)鏈路,通過差錯控制提供數(shù)據(jù)幀(Frame)在信道上無差錯的傳輸,并進行各電路上的動作系列。 常見的協(xié)議有SDLC、HDLC、PPP等。
物理層的主要作用是實現(xiàn)相鄰計算機結點之間比特流的透明傳輸,并盡量屏蔽掉具體傳輸介質和物理設備的差異。
了解交換機、路由器、網關的概念,并知道各自的用途
1)
交換機在計算機網絡系統(tǒng)中,交換機是針對共享工作模式的弱點而推出的。交換機擁有一條高帶寬的背部總線和內部交換矩陣。交換機的所有的端口都掛接在這條背 部總線上,當控制電路收到數(shù)據(jù)包以后,處理端口會查找內存中的地址對照表以確定目的MAC(網卡的硬件地址)的NIC(網卡)掛接在哪個端口上,通過內部 交換矩陣迅速將數(shù)據(jù)包傳送到目的端口。目的MAC若不存在,交換機才廣播到所有的端口,接收端口回應后交換機會“學習”新的地址,并把它添加入內部地址表 中。
交換機工作于OSI參考模型的第二層,即數(shù)據(jù)鏈路層。交換機內部的CPU會在每個端口成功連接時,通過ARP協(xié)議學習它的MAC地址,保存成一張 ARP表。在今后的通訊中,發(fā)往該MAC地址的數(shù)據(jù)包將僅送往其對應的端口,而不是所有的端口。因此,交換機可用于劃分數(shù)據(jù)鏈路層廣播,即沖突域;但它不 能劃分網絡層廣播,即廣播域。
交換機被廣泛應用于二層網絡交換,俗稱“二層交換機”。
交換機的種類有:二層交換機、三層交換機、四層交換機、七層交換機分別工作在OSI七層模型中的第二層、第三層、第四層盒第七層,并因此而得名。
2)
路由器路由器(Router)是一種計算機網絡設備,提供了路由與轉送兩種重要機制,可以決定數(shù)據(jù)包從來源端到目的端所經過 的路由路徑(host到host之間的傳輸路徑),這個過程稱為路由;將路由器輸入端的數(shù)據(jù)包移送至適當?shù)穆酚善鬏敵龆?在路由器內部進行),這稱為轉 送。路由工作在OSI模型的第三層——即網絡層,例如網際協(xié)議。
路由器的一個作用是連通不同的網絡,另一個作用是選擇信息傳送的線路。 路由器與交換器的差別,路由器是屬于OSI第三層的產品,交換器是OSI第二層的產品(這里特指二層交換機)。
3)
網關網關(Gateway),網關顧名思義就是連接兩個網絡的設備,區(qū)別于路由器(由于歷史的原因,許多有關TCP/IP 的文獻曾經把網絡層使用的路由器(Router)稱為網關,在今天很多局域網采用都是路由來接入網絡,因此現(xiàn)在通常指的網關就是路由器的IP),經常在家 庭中或者小型企業(yè)網絡中使用,用于連接局域網和Internet。
談談你對域名緩存的了解?
為了提高 DNS 查詢效率,并減輕服務器的負荷和減少因特網上的 DNS 查詢報文數(shù)量,在域名服務器中廣泛使用了高速緩存,用來存放最近查詢過的域名以及從何處獲得域名映射信息的記錄。
由于名字到地址的綁定并不經常改變,為保持高速緩存中的內容正確,域名服務器應為每項內容設置計時器并處理超過合理時間的項(例如:每個項目兩天)。當域名服務器已從緩存中刪去某項信息后又被請求查詢該項信息,就必須重新到授權管理該項的域名服務器綁定信息。當權限服務器回答一個查詢請求時,在響應中都指明綁定有效存在的時間值。增加此時間值可減少網絡開銷,而減少此時間值可提高域名解析的正確性。
不僅在本地域名服務器中需要高速緩存,在主機中也需要。許多主機在啟動時從本地服務器下載名字和地址的全部數(shù)據(jù)庫,維護存放自己最近使用的域名的高速緩存,并且只在從緩存中找不到名字時才使用域名服務器。維護本地域名服務器數(shù)據(jù)庫的主機應當定期地檢查域名服務器以獲取新的映射信息,而且主機必須從緩存中刪除無效的項。由于域名改動并不頻繁,大多數(shù)網點不需花精力就能維護數(shù)據(jù)庫的一致性。
URI和URL的區(qū)別
- URI(Uniform Resource Identifier):中文全稱為統(tǒng)一資源標志符,主要作用是唯一標識一個資源。
- URL(Uniform Resource Location):中文全稱為統(tǒng)一資源定位符,主要作用是提供資源的路徑。
有個經典的比喻是URI像是身份證,可以唯一標識一個人,而URL更像一個住址,可以通過URL找到這個人。
DNS的工作流程
DNS的定義:DNS的全稱是domain name system,即域名系統(tǒng)。DNS是因特網上作為域名和IP地址相互映射的一個分布式數(shù)據(jù)庫,能夠使用戶更方便的去訪問互聯(lián)網而不用去記住能夠被機器直接讀取的IP地址。比如大家訪問百度,更多地肯定是訪問
http://www.baidu.com,而不是訪問112.80.248.74,因為這幾乎無規(guī)則的IP地址實在太難記了。DNS要做的就是將
http://www.baidu.com解析成112.80.248.74。
DNS是集群式的工作方式還是 單點式的,為什么?答案是集群式的,很容易想到的一個方案就是只用一個DNS服務器,包含了所有域名和IP地址的映射。盡管這種設計方式看起來很簡單,但是缺點顯而易見,如果這個唯一的DNS服務器出了故障,那么就全完了,因特網就幾乎崩了。為了避免這種情況出現(xiàn),DNS系統(tǒng)采用的是分布式的層次數(shù)據(jù)數(shù)據(jù)庫模式,還有緩存的機制也能解決這種問題。
DNS的工作流程 主機向本地域名服務器的查詢一般是采用遞歸查詢,而本地域名服務器向根域名的查詢一般是采用迭代查詢。
遞歸查詢主機向本地域名發(fā)送查詢請求報文,而本地域名服務器不知道該域名對應的IP地址時,本地域名會繼續(xù)向根域名發(fā)送查詢請求報文,不是通知主機自己向根域名發(fā)送查詢請求報文。迭代查詢是,本地域名服務器向根域名發(fā)出查詢請求報文后,根域名不會繼續(xù)向頂級域名服務器發(fā)送查詢請求報文,而是通知本地域名服務器向頂級域名發(fā)送查詢請求報文。
簡單來說,遞歸查詢就是,小明問了小紅一個問題,小紅不知道,但小紅是個熱心腸,小紅就去問小王了,小王把答案告訴小紅后,小紅又去把答案告訴了小明。迭代查詢就是,小明問了小紅一個問題,小紅也不知道,然后小紅讓小明去問小王,小明又去問小王了,小王把答案告訴了小明。
- 在瀏覽器中輸入http://www.baidu.com域名,操作系統(tǒng)會先檢查自己本地的hosts文件是否有這個域名的映射關系,如果有,就先調用這個IP地址映射,完成域名解析。
- 如果hosts文件中沒有,則查詢本地DNS解析器緩存,如果有,則完成地址解析。
- 如果本地DNS解析器緩存中沒有,則去查找本地DNS服務器,如果查到,完成解析。
- 如果沒有,則本地服務器會向根域名服務器發(fā)起查詢請求。根域名服務器會告訴本地域名服務器去查詢哪個頂級域名服務器。
- 本地域名服務器向頂級域名服務器發(fā)起查詢請求,頂級域名服務器會告訴本地域名服務器去查找哪個權限域名服務器。
- 本地域名服務器向權限域名服務器發(fā)起查詢請求,權限域名服務器告訴本地域名服務器http://www.baidu.com所對應的IP地址。
- 本地域名服務器告訴主機http://www.baidu.com所對應的IP地址。
了解ARP協(xié)議嗎?
ARP協(xié)議屬于網絡層的協(xié)議,主要作用是實現(xiàn)從IP地址轉換為MAC地址。在每個主機或者路由器中都建有一個ARP緩存表,表中有IP地址及IP地址對應的MAC地址。先來看一下什么時IP地址和MAC地址。
- IP地址:IP地址是指互聯(lián)網協(xié)議地址,IP地址是IP協(xié)議提供的一種統(tǒng)一的地址格式,它為互聯(lián)網上的每一個網絡和每一臺主機分配一個邏輯地址,以此來屏蔽物理地址的差異。
- MAC地址:MAC地址又稱物理地址,由網絡設備制造商生產時寫在硬件內部,不可更改,并且每個以太網設備的MAC地址都是唯一的。
數(shù)據(jù)在傳輸過程中,會先從高層傳到底層,然后在通信鏈路上傳輸。從下圖可以看到TCP報文在網絡層會被封裝成IP數(shù)據(jù)報,在數(shù)據(jù)鏈路層被封裝成MAC幀,然后在通信鏈路中傳輸。在網絡層使用的是IP地址,在數(shù)據(jù)據(jù)鏈路層使用的是MAC地址。MAC幀在傳送時的源地址和目的地址使用的都是MAC地址,在通信鏈路上的主機或路由器也都是根據(jù)MAC幀首部的MAC地址接收MAC幀。并且在數(shù)據(jù)鏈路層是看不到IP地址的,只有當數(shù)據(jù)傳到網絡層時去掉MAC幀的首部和尾部時才能在IP數(shù)據(jù)報的首部中找到源IP地址和目的地址。
在這里插入圖片描述網絡層實現(xiàn)的是主機之間的通信,而鏈路層實現(xiàn)的是鏈路之間的通信,所以從下圖可以看出,在數(shù)據(jù)傳輸過程中,IP數(shù)據(jù)報的源地址(IP1)和目的地址(IP2)是一直不變的,而MAC地址(硬件地址)卻一直隨著鏈路的改變而改變。
在這里插入圖片描述ARP的工作流程(面試時問ARP協(xié)議主要說這個就可以了):
- 在局域網內,主機A要向主機B發(fā)送IP數(shù)據(jù)報時,首先會在主機A的ARP緩存表中查找是否有IP地址及其對應的MAC地址,如果有,則將MAC地址寫入到MAC幀的首部,并通過局域網將該MAC幀發(fā)送到MAC地址所在的主機B。
- 如果主機A的ARP緩存表中沒有主機B的IP地址及所對應的MAC地址,主機A會在局域網內廣播發(fā)送一個ARP請求分組。局域網內的所有主機都會收到這個ARP請求分組。
- 主機B在看到主機A發(fā)送的ARP請求分組中有自己的IP地址,會像主機A以單播的方式發(fā)送一個帶有自己MAC地址的響應分組。
- 主機A收到主機B的ARP響應分組后,會在ARP緩存表中寫入主機B的IP地址及其IP地址對應的MAC地址。
- 如果主機A和主機B不在同一個局域網內,即使知道主機B的MAC地址也是不能直接通信的,必須通過路由器轉發(fā)到主機B的局域網才可以通過主機B的MAC地址找到主機B。并且主機A和主機B已經可以通信的情況下,主機A的ARP緩存表中寸的并不是主機B的IP地址及主機B的MAC地址,而是主機B的IP地址及該通信鏈路上的下一跳路由器的MAC地址。這就是上圖中的源IP地址和目的IP地址一直不變,而MAC地址卻隨著鏈路的不同而改變。
- 如果主機A和主機B不在同一個局域網,參考上圖中的主機H1和主機H2,這時主機H1需要先廣播找到路由器R1的MAC地址,再由R1廣播找到路由器R2的MAC地址,最后R2廣播找到主機H2的MAC地址,建立起通信鏈路。
各種協(xié)議的介紹
ICMP協(xié)議: 因特網控制報文協(xié)議。它是TCP/IP協(xié)議族的一個子協(xié)議,用于在IP主機、路由器之間傳遞控制消息。
TFTP協(xié)議: 是TCP/IP協(xié)議族中的一個用來在客戶機與服務器之間進行簡單文件傳輸?shù)膮f(xié)議,提供不復雜、開銷不大的文件傳輸服務。
HTTP協(xié)議: 超文本傳輸協(xié)議,是一個屬于應用層的面向對象的協(xié)議,由于其簡捷、快速的方式,適用于分布式超媒體信息系統(tǒng)。
DHCP協(xié)議: 動態(tài)主機配置協(xié)議,是一種讓系統(tǒng)得以連接到網絡上,并獲取所需要的配置參數(shù)手段。
NAT協(xié)議:網絡地址轉換屬接入廣域網(WAN)技術,是一種將私有(保留)地址轉化為合法IP地址的轉換技術,
DHCP協(xié)議:一個局域網的網絡協(xié)議,使用UDP協(xié)議工作,用途:給內部網絡或網絡服務供應商自動分配IP地址,給用戶或者內部網絡管理員作為對所有計算機作中央管理的手段。
有了IP地址,為什么還要用MAC地址?
簡單來說,標識網絡中的一臺計算機,比較常用的就是IP地址和MAC地址,但計算機的IP地址可由用戶自行更改,管理起來相對困難,而MAC地址不可更改,所以一般會把IP地址和MAC地址組合起來使用。具體是如何組合使用的在上面的ARP協(xié)議中已經講的很清楚了。
那只用MAC地址不用IP地址可不可以呢?其實也是不行的,因為在最早就是MAC地址先出現(xiàn)的,并且當時并不用IP地址,只用MAC地址,后來隨著網絡中的設備越來越多,整個路由過程越來越復雜,便出現(xiàn)了子網的概念。對于目的地址在其他子網的數(shù)據(jù)包,路由只需要將數(shù)據(jù)包送到那個子網即可,這個過程就是上面說的ARP協(xié)議。
那為什么要用IP地址呢?是因為IP地址是和地域相關的,對于同一個子網上的設備,IP地址的前綴都是一樣的,這樣路由器通過IP地址的前綴就知道設備在在哪個子網上了,而只用MAC地址的話,路由器則需要記住每個MAC地址在哪個子網,這需要路由器有極大的存儲空間,是無法實現(xiàn)的。
IP地址可以比作為地址,MAC地址為收件人,在一次通信過程中,兩者是缺一不可的。
說一下ping的過程
ping是ICMP(網際控制報文協(xié)議)中的一個重要應用,ICMP是網絡層的協(xié)議。ping的作用是測試兩個主機的連通性。
ping的工作過程:
- 向目的主機發(fā)送多個ICMP回送請求報文
- 根據(jù)目的主機返回的回送報文的時間和成功響應的次數(shù)估算出數(shù)據(jù)包往返時間及丟包率。
路由器和交換機的區(qū)別?
| 所屬網絡模型的層級 | 功能 |
---|
路由器 | 網絡層 | 識別IP地址并根據(jù)IP地址轉發(fā)數(shù)據(jù)包,維護數(shù)據(jù)表并基于數(shù)據(jù)表進行最佳路徑選擇 |
交換機 | 數(shù)據(jù)鏈庫層 | 識別MAC地址并根據(jù)MAC地址轉發(fā)數(shù)據(jù)幀 |
TCP與UDP有什么區(qū)別
| 是否面向連接 | 可靠性 | 傳輸形式 | 傳輸效率 | 消耗資源 | 應用場景 | 首部字節(jié) |
---|
TCP | 面向連接 | 可靠 | 字節(jié)流 | 慢 | 多 | 文件/郵件傳輸 | 20~60 |
UDP | 無連接 | 不可靠 | 數(shù)據(jù)報文段 | 快 | 少 | 視頻/語音傳輸 | 8 |
有時候面試還會問到TCP的首部都包含什么
前20個字節(jié)是固定的,后面有4n個字節(jié)是根據(jù)需而增加的選項,所以TCP首部最小長度為20字節(jié)。
在這里插入圖片描述UDP的首部只有8個字節(jié),源端口號、目的端口號、長度和校驗和各兩個字節(jié)。
在這里插入圖片描述TCP協(xié)議如何保證可靠傳輸
主要有校驗和、序列號、超時重傳、流量控制及擁塞避免等幾種方法。
- 校驗和:在發(fā)送算和接收端分別計算數(shù)據(jù)的校驗和,如果兩者不一致,則說明數(shù)據(jù)在傳輸過程中出現(xiàn)了差錯,TCP將丟棄和不確認此報文段。
- 序列號:TCP會對每一個發(fā)送的字節(jié)進行編號,接收方接到數(shù)據(jù)后,會對發(fā)送方發(fā)送確認應答(ACK報文),并且這個ACK報文中帶有相應的確認編號,告訴發(fā)送方,下一次發(fā)送的數(shù)據(jù)從編號多少開始發(fā)。如果發(fā)送方發(fā)送相同的數(shù)據(jù),接收端也可以通過序列號判斷出,直接將數(shù)據(jù)丟棄。如果
在這里插入圖片描述- 超時重傳:在上面說了序列號的作用,但如果發(fā)送方在發(fā)送數(shù)據(jù)后一段時間內(可以設置重傳計時器規(guī)定這段時間)沒有收到確認序號ACK,那么發(fā)送方就會重新發(fā)送數(shù)據(jù)。
這里發(fā)送方沒有收到ACK可以分兩種情況,如果是發(fā)送方發(fā)送的數(shù)據(jù)包丟失了,接收方收到發(fā)送方重新發(fā)送的數(shù)據(jù)包后會馬上給發(fā)送方發(fā)送ACK;如果是接收方之前接收到了發(fā)送方發(fā)送的數(shù)據(jù)包,而返回給發(fā)送方的ACK丟失了,這種情況,發(fā)送方重傳后,接收方會直接丟棄發(fā)送方沖重傳的數(shù)據(jù)包,然后再次發(fā)送ACK響應報文。
如果數(shù)據(jù)被重發(fā)之后還是沒有收到接收方的確認應答,則進行再次發(fā)送。此時,等待確認應答的時間將會以2倍、4倍的指數(shù)函數(shù)延長,直到最后關閉連接。
- 流量控制:如果發(fā)送端發(fā)送的數(shù)據(jù)太快,接收端來不及接收就會出現(xiàn)丟包問題。為了解決這個問題,TCP協(xié)議利用了滑動窗口進行了流量控制。在TCP首部有一個16位字段大小的窗口,窗口的大小就是接收端接收數(shù)據(jù)緩沖區(qū)的剩余大小。接收端會在收到數(shù)據(jù)包后發(fā)送ACK報文時,將自己的窗口大小填入ACK中,發(fā)送方會根據(jù)ACK報文中的窗口大小進而控制發(fā)送速度。如果窗口大小為零,發(fā)送方會停止發(fā)送數(shù)據(jù)。
- 擁塞控制:如果網絡出現(xiàn)擁塞,則會產生丟包等問題,這時發(fā)送方會將丟失的數(shù)據(jù)包繼續(xù)重傳,網絡擁塞會更加嚴重,所以在網絡出現(xiàn)擁塞時應注意控制發(fā)送方的發(fā)送數(shù)據(jù),降低整個網絡的擁塞程度。擁塞控制主要有四部分組成:慢開始、擁塞避免、快重傳、快恢復,如下圖(圖片來源于網絡)。
在這里插入圖片描述這里的發(fā)送方會維護一個擁塞窗口的狀態(tài)變量,它和流量控制的滑動窗口是不一樣的,滑動窗口是根據(jù)接收方數(shù)據(jù)緩沖區(qū)大小確定的,而擁塞窗口是根據(jù)網絡的擁塞情況動態(tài)確定的,一般來說發(fā)送方真實的發(fā)送窗口為滑動窗口和擁塞窗口中的最小值。
- 慢開始:為了避免一開始發(fā)送大量的數(shù)據(jù)而產生網絡阻塞,會先初始化cwnd為1,當收到ACK后到下一個傳輸輪次,cwnd為2,以此類推成指數(shù)形式增長。
- 擁塞避免:因為cwnd的數(shù)量在慢開始是指數(shù)增長的,為了防止cwnd數(shù)量過大而導致網絡阻塞,會設置一個慢開始的門限值ssthresh,當cwnd>=ssthresh時,進入到擁塞避免階段,cwnd每個傳輸輪次加1。但網絡出現(xiàn)超時,會將門限值ssthresh變?yōu)槌霈F(xiàn)超時cwnd數(shù)值的一半,cwnd重新設置為1,如上圖,在第12輪出現(xiàn)超時后,cwnd變?yōu)?,ssthresh變?yōu)?2。
- 快重傳:在網絡中如果出現(xiàn)超時或者阻塞,則按慢開始和擁塞避免算法進行調整。但如果只是丟失某一個報文段,如下圖(圖片來源于網絡),則使用快重傳算法。
在這里插入圖片描述從上圖可知,接收方正確地接收到M1和M2,而M3丟失,由于沒有接收到M3,在接收方收到M5、M6和M7時,并不會進行確認,也就是不會發(fā)送ACK。這時根據(jù)前面說的保證TCP可靠性傳輸中的序列號的作用,接收方這時不會接收M5,M6,M7,接收方可以什么都不會,因為發(fā)送方長時間未收到M3的確認報文,會對M3進行重傳。除了這樣,接收方也可以重復發(fā)送M2的確認報文,這樣發(fā)送端長時間未收到M3的確認報文也會繼續(xù)發(fā)送M3報文。
**但是根據(jù)快重傳算法,要求在這種情況下,需要快速向發(fā)送端發(fā)送M2的確認報文,在發(fā)送方收到三個M2的確認報文后,無需等待重傳計時器所設置的時間,可直接進行M3的重傳,這就是快重傳。**(面試時說這一句就夠了,前面是幫助理解)
- 快恢復:從上上圖圈4可以看到,當發(fā)送收到三個重復的ACK,會進行快重傳和快恢復。快恢復是指將ssthresh設置為發(fā)生快重傳時的cwnd數(shù)量的一半,而cwnd不是設置為1而是設置為為門限值ssthresh,并開始擁塞避免階段。
IP(網絡之間互連的協(xié)議)
互聯(lián)網協(xié)議地址(英語:Internet Protocol Address,又譯為
網際協(xié)議地址),縮寫為
IP地址(英語:IP Address),是分配給用戶上網使用的網際協(xié)議(英語:Internet Protocol, IP)的設備的數(shù)字標簽。常見的IP地址分為IPv4與IPv6兩大類,但是也有其他不常用的小分類。
v2-867b5f3d9e240b2bc2a2f8412d864a76_1440w- 版本 : 有 4(IPv4)和 6(IPv6)兩個值;
- 首部長度 : 占 4 位,因此最大值為 15。值為 1 表示的是 1 個 32 位字的長度,也就是 4 字節(jié)。因為首部固定長度為 20 字節(jié),因此該值最小為 5。如果可選字段的長度不是 4 字節(jié)的整數(shù)倍,就用尾部的填充部分來填充。
- 區(qū)分服務 : 用來獲得更好的服務,一般情況下不使用。
- 總長度 : 包括首部長度和數(shù)據(jù)部分長度。
- 生存時間 :TTL,它的存在是為了防止無法交付的數(shù)據(jù)報在互聯(lián)網中不斷兜圈子。以路由器跳數(shù)為單位,當 TTL 為 0 時就丟棄數(shù)據(jù)報。
- 協(xié)議 :指出攜帶的數(shù)據(jù)應該上交給哪個協(xié)議進行處理,例如 ICMP、TCP、UDP 等。
- 首部檢驗和 :因為數(shù)據(jù)報每經過一個路由器,都要重新計算檢驗和,因此檢驗和不包含數(shù)據(jù)部分可以減少計算的工作量。
- 標識 : 在數(shù)據(jù)報長度過長從而發(fā)生分片的情況下,相同數(shù)據(jù)報的不同分片具有相同的標識符。
- 片偏移 : 和標識符一起,用于發(fā)生分片的情況。片偏移的單位為 8 字節(jié)
TCP的三次握手及四次揮手
必考題
在介紹三次握手和四次揮手之前,先介紹一下TCP頭部的一些常用字段。
- 序號:seq,占32位,用來標識從發(fā)送端到接收端發(fā)送的字節(jié)流。
- 確認號:ack,占32位,只有ACK標志位為1時,確認序號字段才有效,ack=seq+1。
- 標志位:
- SYN:發(fā)起一個新連接。
- FIN:釋放一個連接。
- ACK:確認序號有效。
三次握手
三次握手的本質就是確定發(fā)送端和接收端具備收發(fā)信息的能力,在能流暢描述三次握手的流程及其中的字段含義作用的同時還需要記住每次握手時接收端和發(fā)送端的狀態(tài)。這個比較容易忽略。
先看一張很經典的圖(圖片來源于網絡),發(fā)送端有CLOSED、SYN-SENT、ESTABLISHED三種狀態(tài),接收端有CLOSED、LISTEN、SYN-RCVD、ESTABLISHED四種狀態(tài)。
在這里插入圖片描述假設發(fā)送端為客戶端,接收端為服務端。開始時客戶端和服務端的狀態(tài)都是CLOSE。
- 第一次握手:客戶端向服務端發(fā)起建立連接請求,客戶端會隨機生成一個起始序列號x,客戶端向服務端發(fā)送的字段中包含標志位SYN=1,序列號seq=100。第一次握手前客戶端的狀態(tài)為CLOSE,第一次握手后客戶端的狀態(tài)為SYN-SENT。此時服務端的狀態(tài)為LISTEN
- 第二次握手:服務端在收到客戶端發(fā)來的報文后,會隨機生成一個服務端的起始序列號y,然后給客戶端回復一段報文,其中包括標志位SYN=1,ACK=1,序列號seq=y,確認號ack=x+1。第二次握手前服務端的狀態(tài)為LISTEN,第二次握手后服務端的狀態(tài)為SYN-RCVD,此時客戶端的狀態(tài)為SYN-SENT。(其中SYN=1表示要和客戶端建立一個連接,ACK=1表示確認序號有效)
- 第三次握手:客戶端收到服務端發(fā)來的報文后,會再向服務端發(fā)送報文,其中包含標志位ACK=1,序列號seq=x+1,確認號ack=y+1。第三次握手前客戶端的狀態(tài)為SYN-SENT,第三次握手后客戶端和服務端的狀態(tài)都為ESTABLISHED。
需要注意的一點是,第一次握手,客戶端向服務端發(fā)起建立連接報文,會占一個序列號。但是第三次握手,同樣是客戶端向服務端發(fā)送報文,這次卻不占序列號,所以建立連接后,客戶端向服務端發(fā)送的第一個數(shù)據(jù)的序列號為x+1。
四次揮手
和三次握手一樣,先看一張非常經典的圖(圖片來源于網絡),客戶端在四次揮手過程中有ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、TIME-WAIT、CLOSED等五個狀態(tài),服務端有ESTABLISHED、CLOSE-WAIT、LAST-ACK、CLOSED等四種狀態(tài)。最好記住每次揮手時服務端和客戶端的狀態(tài)。 假設客戶端首先發(fā)起的斷開連接請求
在這里插入圖片描述- 第一次揮手:客戶端向服務端發(fā)送的數(shù)據(jù)完成后,向服務端發(fā)起釋放連接報文,報文包含標志位FIN=1,序列號seq=u。此時客戶端只能接收數(shù)據(jù),不能向服務端發(fā)送數(shù)據(jù)。
- 第二次揮手:服務端收到客戶端的釋放連接報文后,向客戶端發(fā)送確認報文,包含標志位ACK=1,序列號seq=v,確認號ack=u+1。此時客戶端到服務端的連接已經釋放掉,客戶端不能像服務端發(fā)送數(shù)據(jù),服務端也不能向客戶端發(fā)送數(shù)據(jù)。但服務端到客戶端的單向連接還能正常傳輸數(shù)據(jù)。
- 第三次揮手:服務端發(fā)送完數(shù)據(jù)后向客戶端發(fā)出連接釋放報文,報文包含標志位FIN=1,標志位ACK=1,序列號seq=w,確認號ack=u+1。
- 第四次揮手:客戶端收到服務端發(fā)送的釋放連接請求,向服務端發(fā)送確認報文,包含標志位ACK=1,序列號seq=u+1,確認號ack=w+1。
為什么TCP連接的時候是3次?兩次是否可以?
不可以,主要從以下兩方面考慮(假設客戶端是首先發(fā)起連接請求):
- 假設建立TCP連接僅需要兩次握手,那么如果第二次握手時,服務端返回給客戶端的確認報文丟失了,客戶端這邊認為服務端沒有和他建立連接,而服務端卻以為已經和客戶端建立了連接,并且可能向服務端已經開始向客戶端發(fā)送數(shù)據(jù),但客戶端并不會接收這些數(shù)據(jù),浪費了資源。如果是三次握手,不會出現(xiàn)雙方連接還未完全建立成功就開始發(fā)送數(shù)據(jù)的情況。
- 如果服務端接收到了一個早已失效的來自客戶端的連接請求報文,會向客戶端發(fā)送確認報文同意建立TCP連接。但因為客戶端并不需要向服務端發(fā)送數(shù)據(jù),所以此次TCP連接沒有意義并且浪費了資源。
為什么TCP連接的時候是3次,關閉的時候卻是4次?
因為需要確保通信雙方都能通知對方釋放連接,假設客服端發(fā)送完數(shù)據(jù)向服務端發(fā)送釋放連接請求,當客服端并不知道,服務端是否已經發(fā)送完數(shù)據(jù),所以此次斷開的是客服端到服務端的單向連接,服務端返回給客戶端確認報文后,服務端還能繼續(xù)單向給客戶端發(fā)送數(shù)據(jù)。當服務端發(fā)送完數(shù)據(jù)后還需要向客戶端發(fā)送釋放連接請求,客戶端返回確認報文,TCP連接徹底關閉。所以斷開TCP連接需要客戶端和服務端分別通知對方并分別收到確認報文,一共需要四次。
TCP 是如何保證可靠性的
- 首先,TCP 的連接是基于三次握手,而斷開則是四次揮手。確保連接和斷開的可靠性。
- 其次,TCP 的可靠性,還體現(xiàn)在有狀態(tài);TCP 會記錄哪些數(shù)據(jù)發(fā)送了,哪些數(shù)據(jù)被接受了,哪些沒有被接受,并且保證數(shù)據(jù)包按序到達,保證數(shù)據(jù)傳輸不出差錯。
- 再次,TCP 的可靠性,還體現(xiàn)在可控制。它有數(shù)據(jù)包校驗、ACK 應答、超時重傳(發(fā)送方)、失序數(shù)據(jù)重傳(接收方)、丟棄重復數(shù)據(jù)、流量控制(滑動窗口)和擁塞控制等機制。
TIME_WAIT和CLOSE_WAIT的區(qū)別在哪?
默認客戶端首先發(fā)起斷開連接請求
- 從上圖可以看出,CLOSE_WAIT是被動關閉形成的,當客戶端發(fā)送FIN報文,服務端返回ACK報文后進入CLOSE_WAIT。
- TIME_WAIT是主動關閉形成的,當?shù)谒拇螕]手完成后,客戶端進入TIME_WAIT狀態(tài)。
為什么客戶端發(fā)出第四次揮手的確認報文后要等2MSL的時間才能釋放TCP連接?
MSL的意思是報文的最長壽命,可以從兩方面考慮:
- 客戶端發(fā)送第四次揮手中的報文后,再經過2MSL,可使本次TCP連接中的所有報文全部消失,不會出現(xiàn)在下一個TCP連接中。
- 考慮丟包問題,如果第四揮手發(fā)送的報文在傳輸過程中丟失了,那么服務端沒收到確認ack報文就會重發(fā)第三次揮手的報文。如果客戶端發(fā)送完第四次揮手的確認報文后直接關閉,而這次報文又恰好丟失,則會造成服務端無法正常關閉。
如果已經建立了連接,但是客戶端突然出現(xiàn)故障了怎么辦?
如果TCP連接已經建立,在通信過程中,客戶端突然故障,那么服務端不會一直等下去,過一段時間就關閉連接了。具體原理是TCP有一個?;顧C制,主要用在服務器端,用于檢測已建立TCP鏈接的客戶端的狀態(tài),防止因客戶端崩潰或者客戶端網絡不可達,而服務器端一直保持該TCP鏈接,占用服務器端的大量資源(因為Linux系統(tǒng)中可以創(chuàng)建的總TCP鏈接數(shù)是有限制的)。
?;顧C制原理:設置TCP?;顧C制的?;顣r間keepIdle,即在TCP鏈接超過該時間沒有任何數(shù)據(jù)交互時,發(fā)送?;钐綔y報文;設置?;钐綔y報文的發(fā)送時間間隔keepInterval;設置?;钐綔y報文的總發(fā)送次數(shù)keepCount。如果在keepCount次的?;钐綔y報文均沒有收到客戶端的回應,則服務器端即關閉與客戶端的TCP鏈接。
具體細節(jié)請看這篇博客TCP通信過程中異常情況整理。
HTTP 與 HTTPS 的區(qū)別
| HTTP | HTTPS |
---|
端口 | 80 | 443 |
安全性 | 無加密,安全性較差 | 有加密機制,安全性較高 |
資源消耗 | 較少 | 由于加密處理,資源消耗更多 |
是否需要證書 | 不需要 | 需要 |
協(xié)議 | 運行在TCP協(xié)議之上 | 運行在SSL協(xié)議之上,SSL運行在TCP協(xié)議之上 |
Https 流程是怎樣的?
HTTPS = HTTP + SSL/TLS,即用 SSL/TLS 對數(shù)據(jù)進行加密和解密,Http 進行傳輸。 SSL,即 Secure Sockets Layer(安全套接層協(xié)議),是網絡通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。 TLS,即 Transport Layer Security(安全傳輸層協(xié)議),它是 SSL 3.0 的后續(xù)版本。 用戶在瀏覽器里輸入一個 https 網址,然后連接到 server 的 443 端口。 服務器必須要有一套數(shù)字證書,可以自己制作,也可以向組織申請,區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過。這套證書其實就是一對公鑰和私鑰。 服務器將自己的數(shù)字證書(含有公鑰)發(fā)送給客戶端。 客戶端收到服務器端的數(shù)字證書之后,會對其進行檢查,如果不通過,則彈出警告框。如果證書沒問題,則生成一個密鑰(對稱加密),用證書的公鑰對它加密。 客戶端會發(fā)起 HTTPS 中的第二個 HTTP 請求,將加密之后的客戶端密鑰發(fā)送給服務器。 服務器接收到客戶端發(fā)來的密文之后,會用自己的私鑰對其進行非對稱解密,解密之后得到客戶端密鑰,然后用客戶端密鑰對返回數(shù)據(jù)進行對稱加密,這樣數(shù)據(jù)就變成了密文。 服務器將加密后的密文返回給客戶端。 客戶端收到服務器發(fā)返回的密文,用自己的密鑰(客戶端密鑰)對其進行對稱解密,得到服務器返回的數(shù)
WebSocket與socket的區(qū)別
- Socket = IP地址 + 端口 + 協(xié)議。
具體來說,Socket是一套標準,它完成了對TCP/IP的高度封裝,屏蔽網絡細節(jié)以方便開發(fā)者更好地進行網絡編程。
- WebSocket是一個持久化的協(xié)議,它是伴隨HTTP5而出的協(xié)議,用來解決http不支持持久化連接的問題。
- Socket一個是網編編程的標準接口,而WebSocket是應用層通信協(xié)議。
什么是對稱加密與非對稱加密
對稱加密指加密和解密使用同一密鑰,優(yōu)點是運算速度快,缺點是如何安全將密鑰傳輸給另一方。常見的對稱加密算法有DES、AES等等。
非對稱加密指的是加密和解密使用不同的密鑰,一把公開的公鑰,一把私有的私鑰。公鑰加密的信息只有私鑰才能解密,私鑰加密的信息只有公鑰才能解密。優(yōu)點解決了對稱加密中存在的問題。缺點是運算速度較慢。常見的非對稱加密算法有RSA、DSA、ECC等等。
非對稱加密的工作流程:A生成一對非堆成密鑰,將公鑰向所有人公開,B拿到A的公鑰后使用A的公鑰對信息加密后發(fā)送給A,經過加密的信息只有A手中的私鑰能解密。這樣B可以通過這種方式將自己的公鑰加密后發(fā)送給A,兩方建立起通信,可以通過對方的公鑰加密要發(fā)送的信息,接收方用自己的私鑰解密信息。
為什么會產生粘包和拆包呢?
- 要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小,TCP將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去,將會發(fā)生粘包;
- 接收數(shù)據(jù)端的應用層沒有及時讀取接收緩沖區(qū)中的數(shù)據(jù),將發(fā)生粘包;
- 要發(fā)送的數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)剩余空間大小,將會發(fā)生拆包;
- 待發(fā)送數(shù)據(jù)大于MSS(最大報文長度),TCP在傳輸前將進行拆包。即TCP報文長度-TCP頭部長度>MSS。
解決方案:
- 發(fā)送端將每個數(shù)據(jù)包封裝為固定長度
- 在數(shù)據(jù)尾部增加特殊字符進行分割
- 將數(shù)據(jù)分為兩部分,一部分是頭部,一部分是內容體;其中頭部結構大小固定,且有一個字段聲明內容體的大小。
HTTPS的加密過程
上面已經介紹了對稱加密和非對稱加密的優(yōu)缺點,HTTPS是將兩者結合起來,使用的對稱加密和非對稱加密的混合加密算法。具體做法就是使用非對稱加密來傳輸對稱密鑰來保證安全性,使用對稱加密來保證通信的效率。
簡化的工作流程:服務端生成一對非對稱密鑰,將公鑰發(fā)給客戶端。客戶端生成對稱密鑰,用服務端發(fā)來的公鑰進行加密,加密后發(fā)給服務端。服務端收到后用私鑰進行解密,得到客戶端發(fā)送的對稱密鑰。通信雙方就可以通過對稱密鑰進行高效地通信了。
但是仔細想想這其中存在一個很大地問題,就是客戶端最開始如何判斷收到的這個公鑰就是來自服務端而不是其他人冒充的?
這就需要證書上場了,服務端會向一個權威機構申請一個證書來證明自己的身份,到時候將證書(證書中包含了公鑰)發(fā)給客戶端就可以了,客戶端收到證書后既證明了服務端的身份又拿到了公鑰就可以進行下一步操作了。
HTTPS的加密過程:
- 客戶端向服務端發(fā)起第一次握手請求,告訴服務端客戶端所支持的SSL的指定版本、加密算法及密鑰長度等信息。
- 服務端將自己的公鑰發(fā)給數(shù)字證書認證機構,數(shù)字證書認證機構利用自己的私鑰對服務器的公鑰進行數(shù)字簽名,并給服務器頒發(fā)公鑰證書。
- 服務端將證書發(fā)給客服端。
- 客服端利用數(shù)字認證機構的公鑰,向數(shù)字證書認證機構驗證公鑰證書上的數(shù)字簽名,確認服務器公開密鑰的真實性。
- 客服端使用服務端的公開密鑰加密自己生成的對稱密鑰,發(fā)給服務端。
- 服務端收到后利用私鑰解密信息,獲得客戶端發(fā)來的對稱密鑰。
- 通信雙方可用對稱密鑰來加密解密信息。
上述流程存在的一個問題是客戶端哪里來的數(shù)字認證機構的公鑰,其實,在很多瀏覽器開發(fā)時,會內置常用數(shù)字證書認證機構的公鑰。
流程圖如下:
在這里插入圖片描述常用HTTP狀態(tài)碼
這也是一個面試經常問的題目,背下來就行了.
狀態(tài)碼 | 類別 |
---|
1XX | 信息性狀態(tài)碼 |
2XX | 成功狀態(tài)碼 |
3XX | 重定向狀態(tài)碼 |
4XX | 客戶端錯誤狀態(tài)碼 |
5XX | 服務端錯誤狀態(tài)碼 |
常見的HTTP狀態(tài)碼
1XX
- 100 Continue:表示正常,客戶端可以繼續(xù)發(fā)送請求
- 101 Switching Protocols:切換協(xié)議,服務器根據(jù)客戶端的請求切換協(xié)議。
2XX
- 200 OK:請求成功
- 201 Created:已創(chuàng)建,表示成功請求并創(chuàng)建了新的資源
- 202 Accepted:已接受,已接受請求,但未處理完成。
- 204 No Content:無內容,服務器成功處理,但未返回內容。
- 205 Reset Content:重置內容,服務器處理成功,客戶端應重置文檔視圖。
- 206 Partial Content:表示客戶端進行了范圍請求,響應報文應包含Content-Range指定范圍的實體內容
3XX
- 301 Moved Permanently:永久性重定向
- 302 Found:臨時重定向
- 303 See Other:和301功能類似,但要求客戶端采用get方法獲取資源
- 304 Not Modified:所請求的資源未修改,服務器返回此狀態(tài)碼時,不會返回任何資源。
- 305 Use Proxy:所請求的資源必須通過代理訪問
- 307 Temporary Redirect: 臨時重定向,與302類似,要求使用get請求重定向。
4XX
- 400 Bad Request:客戶端請求的語法錯誤,服務器無法理解。
- 401 Unauthorized:表示發(fā)送的請求需要有認證信息。
- 403 Forbidden:服務器理解用戶的請求,但是拒絕執(zhí)行該請求
- 404 Not Found:服務器無法根據(jù)客戶端的請求找到資源。
- 405 Method Not Allowed:客戶端請求中的方法被禁止
- 406 Not Acceptable:服務器無法根據(jù)客戶端請求的內容特性完成請求
- 408 Request Time-out:服務器等待客戶端發(fā)送的請求時間過長,超時
5XX
- 500 Internal Server Error:服務器內部錯誤,無法完成請求
- 501 Not Implemented:服務器不支持請求的功能,無法完成請求
常見的HTTP方法
方法 | 作用 |
---|
GET | 獲取資源 |
POST | 傳輸實體主體 |
PUT | 上傳文件 |
DELETE | 刪除文件 |
HEAD | 和GET方法類似,但只返回報文首部,不返回報文實體主體部分 |
PATCH | 對資源進行部分修改 |
OPTIONS | 查詢指定的URL支持的方法 |
CONNECT | 要求用隧道協(xié)議連接代理 |
TRACE | 服務器會將通信路徑返回給客戶端 |
為了方便記憶,可以將PUT、DELETE、POST、GET理解為客戶端對服務端的增刪改查。
- PUT:上傳文件,向服務器添加數(shù)據(jù),可以看作增
- DELETE:刪除文件
- POST:傳輸數(shù)據(jù),向服務器提交數(shù)據(jù),對服務器數(shù)據(jù)進行更新。
- GET:獲取資源,查詢服務器資源
POST和GET有哪些區(qū)別?
- 請求參數(shù):GET 把參數(shù)包含在 URL 中,用&連接起來;POST 通過 request body 傳遞參數(shù)。
- 請求緩存:GET請求會被主動Cache,而POST請求不會,除非手動設置。
- 收藏為書簽:GET請求支持收藏為書簽,POST請求不支持。
- 安全性:POST比GET安全,GET請求在瀏覽器回退時是無害的,而POST會再次請求。
- 歷史記錄:GET請求參數(shù)會被完整保留在瀏覽歷史記錄里,而POST中的參數(shù)不會被保留。
- 編碼方式:GET請求只能進行url編碼,而POST支持多種編碼方式。
- 參數(shù)數(shù)據(jù)類型:GET只接受ASCII字符,而POST沒有限制數(shù)據(jù)類型。
- 數(shù)據(jù)包: GET產生一個TCP數(shù)據(jù)包;POST可能產生兩個TCP數(shù)據(jù)包。
HTTP 1.0、HTTP 1.1及HTTP 2.0的主要區(qū)別是什么
HTTP 1.0和HTTP 1.1的區(qū)別
HTTP 1.1支持長連接和請求的流水線操作。長連接是指不在需要每次請求都重新建立一次連接,HTTP 1.0默認使用短連接,每次請求都要重新建立一次TCP連接,資源消耗較大。請求的流水線操作是指客戶端在收到HTTP的響應報文之前可以先發(fā)送新的請求報文,不支持請求的流水線操作需要等到收到HTTP的響應報文后才能繼續(xù)發(fā)送新的請求報文。
在HTTP 1.0中主要使用header中的If-Modified-Since,Expires作為緩存判斷的標準,HTTP 1.1引入了Entity tag,If-Unmodified-Since, If-Match等更多可供選擇的緩存頭來控制緩存策略。
在HTTP 1.1新增了24個錯誤狀態(tài)響應碼
在HTTP 1.0 中認為每臺服務器都會綁定唯一的IP地址,所以,請求中的URL并沒有傳遞主機名。但后來一臺服務器上可能存在多個虛擬機,它們共享一個IP地址,所以HTTP 1.1中請求消息和響應消息都應該支持Host域。
在HTTP 1.0中會存在浪費帶寬的現(xiàn)象,主要是因為不支持斷點續(xù)傳功能,客戶端只是需要某個對象的一部分,服務端卻將整個對象都傳了過來。在HTTP 1.1中請求頭引入了range頭域,它支持只請求資源的某個部分,返回的狀態(tài)碼為206。
HTTP 2.0的新特性
- 新的二進制格式:HTTP 1.x的解析是基于文本,HTTP 2.0的解析采用二進制,實現(xiàn)方便,健壯性更好。
- 多路復用:每一個request對應一個id,一個連接上可以有多個request,每個連接的request可以隨機混在一起,這樣接收方可以根據(jù)request的id將request歸屬到各自不同的服務端請求里。
- header壓縮:在HTTP 1.x中,header攜帶大量信息,并且每次都需要重新發(fā)送,HTTP 2.0采用編碼的方式減小了header的大小,同時通信雙方各自緩存一份header fields表,避免了header的重復傳輸。
- 服務端推送:客戶端在請求一個資源時,會把相關資源一起發(fā)給客戶端,這樣客戶端就不需要再次發(fā)起請求。
Session、Cookie和Token的主要區(qū)別
HTTP協(xié)議是無狀態(tài)的,即服務器無法判斷用戶身份。Session和Cookie可以用來進行身份辨認。
Cookie是保存在客戶端一個小數(shù)據(jù)塊,其中包含了用戶信息。當客戶端向服務端發(fā)起請求,服務端會像客戶端瀏覽器發(fā)送一個Cookie,客戶端會把Cookie存起來,當下次客戶端再次請求服務端時,會攜帶上這個Cookie,服務端會通過這個Cookie來確定身份。
Session是通過Cookie實現(xiàn)的,和Cookie不同的是,Session是存在服務端的。當客戶端瀏覽器第一次訪問服務器時,服務器會為瀏覽器創(chuàng)建一個sessionid,將sessionid放到Cookie中,存在客戶端瀏覽器。比如瀏覽器訪問的是購物網站,將一本《圖解HTTP》放到了購物車,當瀏覽器再次訪問服務器時,服務器會取出Cookie中的sessionid,并根據(jù)sessionid獲取會話中的存儲的信息,確認瀏覽器的身份是上次將《圖解HTTP》放入到購物車那個用戶。
客戶端在瀏覽器第一次訪問服務端時,服務端生成的一串字符串作為Token發(fā)給客戶端瀏覽器,下次瀏覽器在訪問服務端時攜帶token即可無需驗證用戶名和密碼,省下來大量的資源開銷??吹竭@里很多人感覺這不是和sessionid作用一樣嗎?其實是不一樣的,但是本文章主要針對面試,知識點很多,篇幅有限,幾句話也解釋不清楚,大家可以看看這篇文章,我覺得說的非常清楚了。cookie、session與token的真正區(qū)別
下面為了方便記憶,做了一個表格進行對比。
| 存放位置 | 占用空間 | 安全性 | 應用場景 |
---|
Cookie | 客戶端瀏覽器 | 小 | 較低 | 一般存放配置信息 |
Session | 服務端 | 多 | 較高 | 存放較為重要的信息 |
如果客戶端禁止 cookie 能實現(xiàn) session 還能用嗎?
可以,Session的作用是在服務端來保持狀態(tài),通過sessionid來進行確認身份,但sessionid一般是通過Cookie來進行傳遞的。如果Cooike被禁用了,可以通過在URL中傳遞sessionid。
forward 和 redirect 的區(qū)別?
- 直接轉發(fā)方式(Forward) ,客戶端和瀏覽器只發(fā)出一次請求,Servlet、HTML、JSP或其它信息資源,由第二個信息資源響應該請求,在請求對象request中,保存的對象對于每個信息資源是共享的。
- 間接轉發(fā)方式(Redirect) 實際是兩次HTTP請求,服務器端在響應第一次請求的時候,讓瀏覽器再向另外一個URL發(fā)出請求,從而達到轉發(fā)的目的。
舉個通俗的例子:
- 直接轉發(fā)就相當于:“A找B借錢,B說沒有,B去找C借,借到借不到都會把消息傳遞給A”;
- 間接轉發(fā)就相當于:"A找B借錢,B說沒有,讓A去找C借"。
在瀏覽器中輸?url地址到顯示主?的過程
面試超高頻的一道題,一般能說清楚流程就可以。
- 對輸入到瀏覽器的url進行DNS解析,將域名轉換為IP地址。
- 和目的服務器建立TCP連接
- 向目的服務器發(fā)送HTTP請求
- 服務器處理請求并返回HTTP報文
- 瀏覽器解析并渲染頁面
DNS域名系統(tǒng),簡單描述其工作原理。
當DNS客戶機需要在程序中使用名稱時,它會查詢DNS服務器來解析該名稱??蛻魴C發(fā)送的每條查詢信息包括三條信息:包括:指定的DNS域名,指定的查詢類型,DNS域名的指定類別?;赨DP服務,端口53. 該應用一般不直接為用戶使用,而是為其他應用服務,如HTTP,SMTP等在其中需要完成主機名到IP地址的轉換。
對稱加密與非對稱加密
對稱密鑰加密,又稱私鑰加密,即信息的發(fā)送方和接收方用同一個密鑰去加密和解密數(shù)據(jù)。
- 它的最大優(yōu)勢是加/解密速度快,適合于對大數(shù)據(jù)量進行加密,但密鑰管理困難且較為不安全。
- 進行一對一的雙向保密通信。
- 常見的對稱加密算法:DES,AES等。
img非對稱密鑰加密,又稱公鑰加密,它需要使用一對密鑰來分別完成加密和解密操作,一個公開發(fā)布,即公開密鑰,另一個由用戶自己秘密保存,即私用密鑰。信息發(fā)送者用公開密鑰去加密,而信息接收者則用私用密鑰去解密。
- 從功能角度而言非對稱加密比對稱加密功能強大且較為安全,但加密和解密速度卻比對稱密鑰加密慢得多。
- 多對一的單向保密通信。
- 最常用的非對稱加密算法:RSA
由于非對稱加密的方式不需要發(fā)送用來解密的私鑰,所以可以保證安全性;但是和對稱加密比起來,它非常的慢,所以我們還是要用對稱加密來傳送消息,但對稱加密所使用的密鑰我們可以通過非對稱加密的方式發(fā)送出去。
img數(shù)字簽名數(shù)字簽名必須保證實現(xiàn)以下三點功能:
- 報文鑒別。即接受者能夠核實發(fā)送者對報文的簽名。
- 報文的完整性。即接受者確信所收到的數(shù)據(jù)和發(fā)送者發(fā)送的完全一樣而沒有被篡改過。
- 不可否認。發(fā)送者事后不能抵賴對報文的簽名。
數(shù)字簽名圖解:
img該圖只是進行了數(shù)字簽名并沒有對報文進行加密。
數(shù)字簽名過程:A用私鑰SKA對明文X進行D運算簽名成為密文DSKA,B用A的公鑰PKA對密文DSKA進行E運算還原出明文X。
那么這個過程是如何滿足報文鑒別、報文的完整性、不可否認三個特點的呢?- 只有A擁有私鑰SKA,只有他能生成密文DSKA,所以只要B用A的公鑰能成功還原出可讀的明文X就說明密文DSKA一定是A發(fā)來的。這里體現(xiàn)出報文的鑒別的特點。
- 同理如果中途密文DSKA被篡改,那么篡改者沒有A的私鑰SKA來對篡改過后的報文進行加密,那么B對被篡改過的報文進行解密時就會得到不可讀的明文,就知道收到的報文被修改過了。這里體現(xiàn)了報文的完整性的特點。
- 若A抵賴曾發(fā)過該報文給B,B可把X和密文DSKA出示給進行公證的第三者,第三者很容易用PKA去證實A確實發(fā)送了X給B。這里體現(xiàn)了不可否認的特點。
具有保密性的數(shù)字簽名圖解:img什么是XSS攻擊,如何避免?
XSS 攻擊,全稱
跨站腳本攻擊(Cross-Site Scripting),這會與層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆,因此有人將跨站腳本攻擊縮寫為XSS。它指的是惡意攻擊者往Web頁面里插入惡意html代碼,當用戶瀏覽該頁之時,嵌入其中Web里面的html代碼會被執(zhí)行,從而達到惡意攻擊用戶的特殊目的。XSS攻擊一般分三種類型:
存儲型 、反射型 、DOM型XSS如何預防SQL注入問題
1). 使用#{}而不是${}在MyBatis中,使用
#{}
而不是
${}
,可以很大程度防止sql注入。
- 因為
#{}
是一個參數(shù)占位符,對于字符串類型,會自動加上"",其他類型不加。由于Mybatis采用預編譯,其后的參數(shù)不會再進行SQL編譯,所以一定程度上防止SQL注入。 ${}
是一個簡單的字符串替換,字符串是什么,就會解析成什么,存在SQL注入風險
2). 不要暴露一些不必要的日志或者安全信息,比如避免直接響應一些sql異常信息。如果SQL發(fā)生異常了,不要把這些信息暴露響應給用戶,可以自定義異常進行響應
3). 不相信任何外部輸入參數(shù),過濾參數(shù)中含有的一些數(shù)據(jù)庫關鍵詞關鍵詞可以加個參數(shù)校驗過濾的方法,過濾
union,or
等數(shù)據(jù)庫關鍵詞
4). 適當?shù)臋嘞蘅刂?/b>
在你查詢信息時,先校驗下當前用戶是否有這個權限。比如說,實現(xiàn)代碼的時候,可以讓用戶多傳一個企業(yè)Id什么的,或者獲取當前用戶的session信息等,在查詢前,先校驗一下當前用戶是否是這個企業(yè)下的等等,是的話才有這個查詢員工的權限。
什么是DoS、DDoS、DRDoS攻擊?
- DOS: (Denial of Service),中文名稱是拒絕服務,一切能引起DOS行為的攻擊都被稱為DOS攻擊。最常見的DoS攻擊有計算機網絡寬帶攻擊和連通性攻擊。
- DDoS: (Distributed Denial of Service),中文名稱是分布式拒絕服務。是指處于不同位置的多個攻擊者同時向一個或數(shù)個目標發(fā)動攻擊,或者一個攻擊者控制了位于不同位置的多臺機器并利用這些機器對受害者同時實施攻擊。常見的DDos有SYN Flood、Ping of Death、ACK Flood、UDP Flood等。
- DRDoS: (Distributed Reflection Denial of Service),中文名稱是分布式反射拒絕服務,該方式靠的是發(fā)送大量帶有被害者IP地址的數(shù)據(jù)包給攻擊主機,然后攻擊主機對IP地址源做出大量回應,形成拒絕服務攻擊。
面向連接和非面向連接的服務的特點是什么?
面向連接的服務,通信雙方在進行通信之前,要先在雙方建立起一個完整的可以彼此溝通的通道,在通信過程中,整個連接的情況一直可以被實時地監(jiān)控和管理。非面向連接的服務,不需要預先建立一個聯(lián)絡兩個通信節(jié)點的連接,需要通信的時候,發(fā)送節(jié)點就可以往網絡上發(fā)送信息,讓信息自主地在網絡上去傳,一般在傳輸?shù)倪^程中不再加以監(jiān)控。
Servlet是線程安全的嗎
Servlet不是線程安全的,多線程的讀寫會導致數(shù)據(jù)不同步的問題。
什么是CSRF攻擊,如何避免
什么是CSRF 攻擊?
CSRF,跨站請求偽造(英語:Cross-site request forgery),簡單點說就是,攻擊者盜用了你的身份,以你的名義發(fā)送惡意請求。跟跨網站腳本(XSS)相比,XSS 利用的是用戶對指定網站的信任,CSRF 利用的是網站對用戶網頁瀏覽器的信任。
CSRF是如何攻擊的呢?
- Tom 登陸銀行,沒有退出,瀏覽器包含了Tom在銀行的身份認證信息。
- 黑客Jerry將偽造的轉賬請求,包含在在帖子
- Tom在銀行網站保持登陸的情況下,瀏覽帖子
- 將偽造的轉賬請求連同身份認證信息,發(fā)送到銀行網站
- 銀行網站看到身份認證信息,以為就是Tom的合法操作,最后造成Tom資金損失。
如何解決CSRF攻擊
- 檢查Referer字段。HTTP頭中有一個Referer字段,這個字段用以標明請求來源于哪個地址。
- 添加校驗token。
關鍵詞:試題,企業(yè),精心,網絡,整理,計算機