26. 聊聊 TCP 的滑動窗口
TCP 發送一個數據,需要收到確認應答,才會發送下一個數據。這樣有個缺點,就是效率會比較低。
這就好像我們面對面聊天,你說完一句,我應答后,你才會說下一句。那么,如果我在忙其他事情,沒有能夠及時回復你。你說完一句后,要等到我忙完回復你,你才說下句,這顯然很不現實。
為了解決這個問題,TCP 引入了窗口,它是操作系統開辟的一個緩存空間。窗口大小值表示無需等待確認應答,而可以繼續發送數據的最大值。
TCP 頭部有個字段叫 win,也即那個 16 位的窗口大小,它告訴對方本端的 TCP 接收緩沖區還能容納多少字節的數據,這樣對方就可以控制發送數據的速度,從而達到流量控制的目的。
通俗點講,就是接受方每次收到數據包,在發送確認報文的時候,同時告訴發送方,自己的緩存區還有多少空余空間,緩沖區的空余空間,我們就稱之為接受窗口大小。這就是 win。
TCP 滑動窗口分為兩種:發送窗口和接收窗口。發送端的滑動窗口包含四大部分,如下:
-
已發送且已收到 ACK 確認
-
已發送但未收到 ACK 確認
-
未發送但可以發送
-
未發送也不可以發送
-
虛線矩形框,就是發送窗口。
-
SND.WND: 表示發送窗口的大小,上圖虛線框的格子數就是 14 個。
-
SND.UNA: 一個絕對指針,它指向的是已發送但未確認的第一個字節的序列號。
-
SND.NXT:下一個發送的位置,它指向未發送但可以發送的第一個字節的序列號。
接收方的滑動窗口包含三大部分,如下:
-
已成功接收並確認
-
未收到數據但可以接收
-
未收到數據並不可以接收的數據
-
虛線矩形框,就是接收窗口。
-
REV.WND: 表示接收窗口的大小,上圖虛線框的格子就是 9 個。
-
REV.NXT: 下一個接收的位置,它指向未收到但可以接收的第一個字節的序列號。
27. 聊聊五層計算機網絡體系結構中,每一層對應的網絡協議有哪些?
28. 聊聊 TCP 的流量控制
TCP 三次握手,發送端和接收端進入到 ESTABLISHED 狀態,它們即可以愉快地傳輸數據啦。
但是發送端不能瘋狂地向接收端發送數據,因為接收端接收不過來的話,接收方只能把處理不過來的數據存在緩存區里。如果緩存區都滿了,發送方還在瘋狂發送數據的話,接收方只能把收到的數據包丟掉,這就浪費了網絡資源啦。
TCP 提供一種機制可以讓發送端根據接收端的實際接收能力控制發送的數據量,這就是流量控制。
TCP 通過滑動窗口來控制流量,我們看下流量控制的簡要流程吧:
首先雙方三次握手,初始化各自的窗口大小,均為 400 個字節。
-
假如當前發送方給接收方發送了 200 個字節,那么,發送方的 SND.NXT 會右移 200 個字節,也就是說當前的可用窗口減少了 200 個字節。
-
接受方收到后,放到緩沖隊列里面,REV.WND =400-200=200 字節,所以 win=200 字節返回給發送方。接收方會在 ACK 的報文首部帶上縮小后的滑動窗口 200 字節
-
發送方又發送 200 字節過來,200 字節到達,繼續放到緩沖隊列。不過這時候,由於大量負載的原因,接受方處理不了這么多字節,只能處理 100 字節,剩余的 100 字節繼續放到緩沖隊列。這時候,REV.WND = 400-200-100=100 字節,即 win=100 返回發送方。
-
發送方繼續干活,發送 100 字節過來,這時候,接受窗口 win 變為 0。
-
發送方停止發送,開啟一個定時任務,每隔一段時間,就去詢問接受方,直到 win 大於 0,才繼續開始發送。
29. 說下 ARP 協議的工作原理?
ARP 協議協議,即 Address Resolution Protocol,地址解析協議,用於實現 IP 地址到 MAC 地址的映射。
-
首先,每台主機都會在自己的 ARP 緩沖區中建立一個 ARP 列表,以表示 IP 地址和 MAC 地址的對應關系。
-
當源主機需要將一個數據包要發送到目的主機時,會首先檢查自己的 ARP 列表,是否存在該 IP 地址對應的 MAC 地址;如果存在﹐就直接將數據包發送到這個 MAC 地址;如果不存在,就向本地網段發起一個 ARP 請求的廣播包,查詢此目的主機對應的 MAC 地址。此 ARP 請求的數據包里,包括源主機的 IP 地址、硬件地址、以及目的主機的 IP 地址。
-
網絡中所有的主機收到這個 ARP 請求后,會檢查數據包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此數據包;如果相同,該主機首先將發送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中,如果 ARP 表中已經存在該 IP 的信息,則將其覆蓋,然后給源主機發送一個 ARP 響應數據包,告訴對方自己是它需要查找的 MAC 地址。
-
源主機收到這個 ARP 響應數據包后,將得到的目的主機的 IP 地址和 MAC 地址添加到自己的 ARP 列表中,並利用此信息開始數據的傳輸。如果源主機一直沒有收到 ARP 響應數據包,表示 ARP 查詢失敗。
30. 說下 TCP 的擁塞控制
擁塞控制是作用於網絡的,防止過多的數據包注入到網絡中,避免出現網絡負載過大的情況。它的目標主要是最大化利用網絡上瓶頸鏈路的帶寬。它跟流量控制又有什么區別呢?流量控制是作用於接收者的,根據接收端的實際接收能力控制發送速度,防止分組丟失的。
我們可以把網絡鏈路比喻成一根水管,如果我們想最大化利用網絡來傳輸數據,那就是盡快讓水管達到最佳充滿狀態。
發送方維護一個擁塞窗口 cwnd(congestion window) 的變量,用來估算在一段時間內這條鏈路(水管)可以承載和運輸的數據(水)的數量。它大小代表着網絡的擁塞程度,並且是動態變化的,但是為了達到最大的傳輸效率,我們該如何知道這條水管的運送效率是多少呢?
一個比較簡單的方法就是不斷增加傳輸的水量,直到水管快要爆裂為止(對應到網絡上就是發生丟包),用 TCP 的描述就是:
只要網絡中沒有出現擁塞,擁塞窗口的值就可以再增大一些,以便把更多的數據包發送出去,但只要網絡出現擁塞,擁塞窗口的值就應該減小一些,以減少注入到網絡中的數據包數。
實際上,擁塞控制主要有這幾種常用算法
-
慢啟動
-
擁塞避免
-
擁塞發生
-
快速恢復
慢啟動算法
慢啟動算法,表面意思就是,別急慢慢來。它表示 TCP 建立連接完成后,一開始不要發送大量的數據,而是先探測一下網絡的擁塞程度。由小到大逐漸增加擁塞窗口的大小,如果沒有出現丟包,每收到一個 ACK,就將擁塞窗口 cwnd 大小就加 1(單位是 MSS)。每輪次發送窗口增加一倍,呈指數增長,如果出現丟包,擁塞窗口就減半,進入擁塞避免階段。
-
TCP 連接完成,初始化 cwnd = 1,表明可以傳一個 MSS 單位大小的數據。
-
每當收到一個 ACK,cwnd 就加一;
-
每當過了一個 RTT,cwnd 就增加一倍;呈指數讓升
為了防止 cwnd 增長過大引起網絡擁塞,還需設置一個慢啟動閥值 ssthresh(slow start threshold)狀態變量。當 cwnd 到達該閥值后,就好像水管被關小了水龍頭一樣,減少擁塞狀態。即當 cwnd >ssthresh 時,進入了擁塞避免算法。
擁塞避免算法
一般來說,慢啟動閥值 ssthresh 是 65535 字節,cwnd 到達慢啟動閥值后
-
每收到一個 ACK 時,cwnd = cwnd + 1/cwnd
-
當每過一個 RTT 時,cwnd = cwnd + 1
顯然這是一個線性上升的算法,避免過快導致網絡擁塞問題。
擁塞發生
當網絡擁塞發生丟包時,會有兩種情況:
-
RTO 超時重傳
-
快速重傳
如果是發生了 RTO 超時重傳,就會使用擁塞發生算法
-
慢啟動閥值 sshthresh = cwnd /2
-
cwnd 重置為 1
-
進入新的慢啟動過程
這真的是辛辛苦苦幾十年,一朝回到解放前。其實還有更好的處理方式,就是快速重傳。發送方收到 3 個連續重復的 ACK 時,就會快速地重傳,不必等待 RTO 超時再重傳。
慢啟動閥值 ssthresh 和 cwnd 變化如下:
-
擁塞窗口大小 cwnd = cwnd/2
-
慢啟動閥值 ssthresh = cwnd
-
進入快速恢復算法
快速恢復
快速重傳和快速恢復算法一般同時使用。快速恢復算法認為,還有 3 個重復 ACK 收到,說明網絡也沒那么糟糕,所以沒有必要像 RTO 超時那么強烈。
正如前面所說,進入快速恢復之前,cwnd 和 sshthresh 已被更新:
- cwnd = cwnd /2
- sshthresh = cwnd
然后,真正的快速算法如下:
-
cwnd = sshthresh + 3
-
重傳重復的那幾個 ACK(即丟失的那幾個數據包)
-
如果再收到重復的 ACK,那么 cwnd = cwnd +1
-
如果收到新數據的 ACK 后,cwnd = sshthresh。因為收到新數據的 ACK,表明恢復過程已經結束,可以再次進入了擁塞避免的算法了。
31. TCP 和 UDP 分別對應的常見應用層協議有哪些?
基於 TCP 的應用層協議有:HTTP、FTP、SMTP、TELNET、SSH
-
HTTP:HyperText Transfer Protocol(超文本傳輸協議),默認端口 80
-
FTP: File Transfer Protocol (文件傳輸協議), 默認端口 (20 用於傳輸數據,21 用於傳輸控制信息)
-
SMTP: Simple Mail Transfer Protocol (簡單郵件傳輸協議) , 默認端口 25
-
TELNET: Teletype over the Network (網絡電傳), 默認端口 23
-
SSH:Secure Shell(安全外殼協議),默認端口 22
基於 UDP 的應用層協議:DNS、TFTP、SNMP
-
DNS : Domain Name Service (域名服務), 默認端口 53
-
TFTP: Trivial File Transfer Protocol (簡單文件傳輸協議),默認端口 69
-
SNMP:Simple Network Management Protocol(簡單網絡管理協議),通過 UDP 端口 161 接收,只有 Trap 信息采用 UDP 端口 162。
32. 半連接隊列和 SYN Flood 攻擊的關系
TCP 進入三次握手前,服務端會從 CLOSED 狀態變為 LISTEN 狀態,同時在內部創建了兩個隊列:半連接隊列(SYN 隊列)和全連接隊列(ACCEPT 隊列)。
什么是半連接隊列(SYN 隊列) 呢?什么是全連接隊列(ACCEPT 隊列) 呢?回憶下 TCP 三次握手的圖:
-
TCP 三次握手時,客戶端發送 SYN 到服務端,服務端收到之后,便回復 ACK 和 SYN,狀態由 LISTEN 變為 SYN_RCVD,此時這個連接就被推入了 SYN 隊列,即半連接隊列。
-
當客戶端回復 ACK, 服務端接收后,三次握手就完成了。這時連接會等待被具體的應用取走,在被取走之前,它被推入 ACCEPT 隊列,即全連接隊列。
SYN Flood 是一種典型的 DoS (Denial of Service,拒絕服務) 攻擊,它在短時間內,偽造不存在的 IP 地址 , 向服務器大量發起 SYN 報文。當服務器回復 SYN+ACK 報文后,不會收到 ACK 回應報文,導致服務器上建立大量的半連接半連接隊列滿了,這就無法處理正常的 TCP 請求啦。
主要有 syn cookie 和 SYN Proxy 防火牆等方案應對。
-
syn cookie:在收到 SYN 包后,服務器根據一定的方法,以數據包的源地址、端口等信息為參數計算出一個 cookie 值作為自己的 SYNACK 包的序列號,回復 SYN+ACK 后,服務器並不立即分配資源進行處理,等收到發送方的 ACK 包后,重新根據數據包的源地址、端口計算該包中的確認序列號是否正確,如果正確則建立連接,否則丟棄該包。
-
SYN Proxy 防火牆:服務器防火牆會對收到的每一個 SYN 報文進行代理和回應,並保持半連接。等發送方將 ACK 包返回后,再重新構造 SYN 包發到服務器,建立真正的 TCP 連接。
33. 有了 IP 地址,為什么還要用 MAC 地址?
-
簡而言之,標識網絡中的一台計算機,比較常用的就是 IP 地址和 MAC 地址,但計算機的 IP 地址可由用戶自行更改,管理起來就相對困難,而 MAC 地址不可更改,所以一般會把 IP 地址和 MAC 地址組合起來使用。
-
那只使用 MAC 地址不用 IP 地址行不行呢?不行的!因為最早就是 MAC 地址先出現的,並且當時並不用 IP 地址,只用 MAC 地址,后來隨着網絡中的設備越來越多,整個路由過程越來越復雜,便出現了子網的概念。對於目的地址在其他子網的數據包,路由只需要將數據包送到那個子網即可。
-
那為什么要用 IP 地址呢?是因為 IP 地址是和地域相關的,對於同一個子網上的設備,IP 地址的前綴都是一樣的,這樣路由器通過 IP 地址的前綴就知道設備在在哪個子網上了,而只用 MAC 地址的話,路由器則需要記住每個 MAC 地址在哪個子網,這需要路由器有極大的存儲空間,是無法實現的。
-
IP 地址可以比作為地址,MAC 地址為收件人,在一次通信過程中,兩者是缺一不可的。
34. 聊聊保活計時器的作用
除時間等待計時器外,TCP 還有一個保活計時器(keepalive timer)。設想這樣的場景:客戶已主動與服務器建立了 TCP 連接。但后來客戶端的主機突然發生故障。顯然,服務器以后就不能再收到客戶端發來的數據。因此,應當有措施使服務器不要再白白等待下去。這就需要使用保活計時器了。
服務器每收到一次客戶的數據,就重新設置保活計時器,時間的設置通常是兩個小時。若兩個小時都沒有收到客戶端的數據,服務端就發送一個探測報文段,以后則每隔 75 秒鍾發送一次。若連續發送 10 個探測報文段后仍然無客戶端的響應,服務端就認為客戶端出了故障,接着就關閉這個連接。
35. 聊聊 ARP 協議
ARP 協議,地址解析協議,是一個由 IP 地址獲取 MAC 物理地址的 TCP/IP 協議。
什么是 IP 地址,什么是 MAC 地址?
-
IP 地址:是互聯網協議地址,它是 IP 協議提供的一種統一的地址格式,它為互聯網上的每一個網絡和每一台主機分配一個邏輯地址,以此來屏蔽物理地址的差異。
-
MAC 地址:以太網地址或物理地址,它是一個用來確認網絡設備位置的位址。
為什么需要 ARP 協議呢?
-
在網絡訪問層中,同一局域網中的一台主機要和另一台主機進行通信,需要通過 MAC 地址進行定位,然后才能進行數據包的發送。
-
而在網絡層和傳輸層中,計算機之間是通過 IP 地址定位目標主機,對應的數據報文只包含目標主機的 IP 地址,而沒有 MAC 地址。
-
因此,在發送之前需要根據 IP 地址獲取 MAC 地址,然后才能將數據包發送到正確的目標主機,而這個獲取過程是通過 ARP 協議完成的。
ARP 的工作流程
當主機 A 與主機 B 要通信時,工作流程如下:
-
查詢本地 ARP 緩存表,看是否有 IP 地址及其對應的 MAC 地址。
-
如果沒匹配到主機 B 的 MAC 地址,主機 A 會在局域網內廣播發送一個 ARP 請求分組,局域網內所有主機都會收到該請求分組。
-
主機 B 收到請求分組報文,發現報文中的 IP 與自己匹配,就 A 的 IP 和 MAC 地址添加到本地 ARP 緩存表中。
-
主機 B 向主機 A 響應一個含自身 MAC 地址的報文。
-
主機 A 收到報文后,將 B 的 IP 和 MAC 地址添加至 ARP 緩存表中。
36. TCP 的粘包和拆包
TCP 是面向流,沒有界限的一串數據。TCP 底層並不了解上層業務數據的具體含義,它會根據 TCP 緩沖區的實際情況進行包的划分,所以在業務上認為,一個完整的包可能會被 TCP 拆分成多個包進行發送,也有可能把多個小的包封裝成一個大的數據包發送,這就是所謂的 TCP 粘包和拆包問題。
為什么會產生粘包和拆包呢?
-
要發送的數據小於 TCP 發送緩沖區的大小,TCP 將多次寫入緩沖區的數據一次發送出去,將會發生粘包;
-
接收數據端的應用層沒有及時讀取接收緩沖區中的數據,將發生粘包;
-
要發送的數據大於 TCP 發送緩沖區剩余空間大小,將會發生拆包;
-
待發送數據大於 MSS(最大報文長度),TCP 在傳輸前將進行拆包。即 TCP 報文長度 - TCP 頭部長度 > MSS。
解決方案:
-
發送端將每個數據包封裝為固定長度
-
在數據尾部增加特殊字符進行分割
-
將數據分為兩部分,一部分是頭部,一部分是內容體;其中頭部結構大小固定,且有一個字段聲明內容體的大小。
37. forward 和 redirect 的區別?
-
直接轉發方式(Forward) ,客戶端和瀏覽器只發出一次請求,Servlet、HTML、JSP 或其它信息資源,由第二個信息資源響應該請求,在請求對象 request 中,保存的對象對於每個信息資源是共享的。
-
間接轉發方式(Redirect) 實際是兩次 HTTP 請求,服務器端在響應第一次請求的時候,讓瀏覽器再向另外一個 URL 發出請求,從而達到轉發的目的。
舉個通俗的例子:
-
直接轉發就相當於:“A 找 B 借錢,B 說沒有,B 去找 C 借,借到借不到都會把消息傳遞給 A”;
-
間接轉發就相當於:”A 找 B 借錢,B 說沒有,讓 A 去找 C 借”。**
看這兩個圖,可以更容易理解一些:
Redirect 的工作原理:
forward 的工作原理
38. Nagle 算法與延遲確認
Nagle 算法
如果發送端瘋狂地向接收端發送很小的包,比如就 1 個字節,那么親愛的小伙伴,你們覺得會有什么問題呢?
TCP/IP 協議中,無論發送多少數據,總是要在數據前面加上協議頭,同時,對方接收到數據,也需要發送 ACK 表示確認。為了盡可能的利用網絡帶寬,TCP 總是希望盡可能的發送足夠大的數據。Nagle 算法就是為了盡可能發送大塊數據,避免網絡中充斥着許多小數據塊。
Nagle 算法的基本定義是:任意時刻,最多只能有一個未被確認的小段。所謂 “小段”,指的是小於 MSS 尺寸的數據塊,所謂 “未被確認”,是指一個數據塊發送出去后,沒有收到對方發送的 ACK 確認該數據已收到。
Nagle 算法的實現規則:
-
如果包長度達到 MSS,則允許發送;
-
如果該包含有 FIN,則允許發送;
-
設置了 TCP_NODELAY 選項,則允許發送;
-
未設置 TCP_CORK 選項時,若所有發出去的小數據包(包長度小於 MSS)均被確認,則允許發送;
-
上述條件都未滿足,但發生了超時(一般為 200ms),則立即發送。
延遲確認
如果接受方剛接收到發送方的數據包,在很短很短的時間內,又接收到第二個包。那么請問接收方是一個一個地回復好點,還是合並一起回復好呢?
接收方收到數據包后,如果暫時沒有數據要發給對端,它可以等一段時再確認(Linux 上默認是 40ms)。如果這段時間剛好有數據要傳給對端,ACK 就隨着數據傳輸,而不需要單獨發送一次 ACK。如果超過時間還沒有數據要發送,也發送 ACK,避免對端以為丟包。
但是有些場景不能延遲確認,比如發現了亂序包、接收到了大於一個 frame 的報文,且需要調整窗口大小等。
一般情況下,Nagle 算法和延遲確認不能一起使用,Nagle 算法意味着延遲發,延遲確認意味着延遲接收,醬紫就會造成更大的延遲,會產生性能問題。
39. URI 和 URL 的區別
-
URI,全稱是 Uniform Resource Identifier),中文翻譯是統一資源標志符,主要作用是唯一標識一個資源。
-
URL,全稱是 Uniform Resource Location),中文翻譯是統一資源定位符,主要作用是提供資源的路徑。
打個經典比喻吧,URI 像是身份證,可以唯一標識一個人,而 URL 更像一個住址,可以通過 URL 找到這個人。
40. 什么是數字簽名?什么是數字證書?
了解過 Https 原理的小伙伴,都知道數字證書這玩意。為了避免公鑰被篡改,引入了數字證書,如下:
數字證書構成
-
公鑰和個人信息,經過 Hash 算法加密,形成消息摘要;將消息摘要拿到擁有公信力的認證中心(CA),用它的私鑰對消息摘要加密,形成數字簽名.
-
公鑰和個人信息、數字簽名共同構成數字證書。
41. 什么是 SQL 注入?舉個例子?
SQL 注入是一種代碼注入技術,一般被應用於攻擊 web 應用程序。它通過在 web 應用接口傳入一些特殊參數字符,來欺騙應用服務器,執行惡意的 SQL 命令,以達到非法獲取系統信息的目的。它目前是黑客對數據庫進行攻擊的最常用手段之一。
SQL 注入是如何攻擊的?
舉個常見的業務場景:在 web 表單搜索框輸入員工名字,然后后台查詢出對應名字的員工。
這種場景下,一般都是前端頁面把一個名字參數 name 傳到后台,然后后台通過 SQL 把結果查詢出來
name = "碼農編程進階筆記"; //前端傳過來的
SQL= "select * from staff where name=" + name; //根據前端傳過來的name參數,查詢數據庫員工表staff
因為 SQL 是直接拼接的,如果我們完全信任前端傳的參數的話。假如前端傳這么一個參數時'' or '1'='1',SQL 就變成醬紫的啦。
select * from staff where name='' or '1'='1';
這個 SQL 會把所有的員工信息全都查出來了,醬紫就請求用戶已經越權啦。請求者可以獲取所有員工的信息,信息已經暴露了啦。
如何預防 SQL 注入問題
1). 使用 #{} 而不是 ${}
在 MyBatis 中,使用#{} 而不是 ${},可以很大程度防止 sql 注入。
-
因為#{} 是一個參數占位符,對於字符串類型,會自動加上””,其他類型不加。由於 Mybatis 采用預編譯,其后的參數不會再進行 SQL 編譯,所以一定程度上防止 SQL 注入。
-
${} 是一個簡單的字符串替換,字符串是什么,就會解析成什么,存在 SQL 注入風險
2). 不要暴露一些不必要的日志或者安全信息,比如避免直接響應一些 sql 異常信息。
如果 SQL 發生異常了,不要把這些信息暴露響應給用戶,可以自定義異常進行響應
3). 不相信任何外部輸入參數,過濾參數中含有的一些數據庫關鍵詞關鍵詞
可以加個參數校驗過濾的方法,過濾 union,or 等數據庫關鍵詞
4). 適當的權限控制
在你查詢信息時,先校驗下當前用戶是否有這個權限。比如說,實現代碼的時候,可以讓用戶多傳一個企業 Id 什么的,或者獲取當前用戶的 session 信息等,在查詢前,先校驗一下當前用戶是否是這個企業下的等等,是的話才有這個查詢員工的權限。
42. 什么是 DoS、DDoS、DRDoS 攻擊?
-
DOS: (Denial of Service), 中文名稱是拒絕服務,一切能引起 DOS 行為的攻擊都被稱為 DOS 攻擊。最常見的 DoS 攻擊有計算機網絡寬帶攻擊和連通性攻擊。
-
DDoS: (Distributed Denial of Service), 中文名稱是分布式拒絕服務。是指處於不同位置的多個攻擊者同時向一個或數個目標發動攻擊,或者一個攻擊者控制了位於不同位置的多台機器並利用這些機器對受害者同時實施攻擊。常見的 DDos 有 SYN Flood、Ping of Death、ACK Flood、UDP Flood 等。
-
DRDoS: (Distributed Reflection Denial of Service),中文名稱是分布式反射拒絕服務,該方式靠的是發送大量帶有被害者 IP 地址的數據包給攻擊主機,然后攻擊主機對 IP 地址源做出大量回應,形成拒絕服務攻擊。
43. WebSocket 與 socket 的區別
-
Socket = IP 地址 + 端口 + 協議。
具體來說,Socket 是一套標准,它完成了對 TCP/IP 的高度封裝,屏蔽網絡細節以方便開發者更好地進行網絡編程。
-
WebSocket 是一個持久化的協議,它是伴隨 HTTP5 而出的協議,用來解決 http 不支持持久化連接的問題。
-
Socket 一個是網編編程的標准接口,而 WebSocket 是應用層通信協議。
44. ICMP 協議的功能
ICMP,Internet Control Message Protocol ,Internet 控制消息協議。
-
ICMP 協議是一種面向無連接的協議,用於傳輸出錯報告控制信息。
-
它是一個非常重要的協議,它對於網絡安全具有極其重要的意義。它屬於網絡層協議,主要用於在主機與路由器之間傳遞控制信息,包括報告錯誤、交換受限控制和狀態信息等。
-
當遇到 IP 數據無法訪問目標、IP 路由器無法按當前的傳輸速率轉發數據包等情況時,會自動發送 ICMP 消息。
比如我們日常使用得比較多的 ping,就是基於 ICMP 的。
45. Http 請求的過程與原理
HTTP 是一個基於 TCP/IP 協議來傳遞數據的超文本傳輸協議,傳輸的數據類型有 HTML 文件,、圖片文件等。以訪問百度有例子,看下一次 Http 的請求過程
-
客戶端進行 DNS 域名解析,得到對應的 IP 地址
-
根據這個 IP,找到對應的服務器建立連接(三次握手)
-
建立 TCP 連接后發起 HTTP 請求(一個完整的 http 請求報文)
-
服務器響應 HTTP 請求,客戶端得到 html 代碼
-
客戶端解析 html 代碼,用 html 代碼中的資源 (如 js,css, 圖片等等) 渲染頁面。
-
服務器關閉 TCP 連接(四次揮手)
46. 說下 ping 的原理
ping,Packet Internet Groper,是一種因特網包探索器,用於測試網絡連接量的程序。Ping 是工作在 TCP/IP 網絡體系結構中應用層的一個服務命令, 主要是向特定的目的主機發送 ICMP(Internet Control Message Protocol 因特網報文控制協議) 請求報文,測試目的站是否可達及了解其有關狀態
一般來說,ping 可以用來檢測網絡通不通。它是基於 ICMP 協議工作的。假設機器 A ping 機器 B,工作過程如下:
-
ping 通知系統,新建一個固定格式的 ICMP 請求數據包
-
ICMP 協議,將該數據包和目標機器 B 的 IP 地址打包,一起轉交給 IP 協議層
-
IP 層協議將本機 IP 地址為源地址,機器 B 的 IP 地址為目標地址,加上一些其他的控制信息,構建一個 IP 數據包
-
先獲取目標機器 B 的 MAC 地址。
-
數據鏈路層構建一個數據幀,目的地址是 IP 層傳過來的 MAC 地址,源地址是本機的 MAC 地址
-
機器 B 收到后,對比目標地址,和自己本機的 MAC 地址是否一致,符合就處理返回,不符合就丟棄。
-
根據目的主機返回的 ICMP 回送回答報文中的時間戳,從而計算出往返時間
-
最終顯示結果有這幾項:發送到目的主機的 IP 地址、發送 & 收到 & 丟失的分組數、往返時間的最小、最大 & 平均值
47. 如果服務器出現了大量 CLOSE_WAIT 狀態如何解決。
我們先來回憶下 TCP 的四次揮手
-
服務器端收到客戶端發送的 FIN 后,TCP 協議棧就會自動發送 ACK,接着進入 CLOSE_WAIT 狀態。
-
但是如果服務器端不執行 socket 的 close () 操作,那么就沒法進入 LAST_ACK, 導致大量連接處於 CLOSE_WAIT 狀態
-
所以,如果服務器出現了大量 CLOSE_WAIT 狀態,一般是程序 Bug,或者關閉 socket 不及時。
48. 什么是 CSRF 攻擊,如何避免
什么是 CSRF 攻擊?
CSRF,跨站請求偽造(英語:Cross-site request forgery),簡單點說就是,攻擊者盜用了你的身份,以你的名義發送惡意請求。跟跨網站腳本(XSS)相比,XSS 利用的是用戶對指定網站的信任,CSRF 利用的是網站對用戶網頁瀏覽器的信任。
CSRF 是如何攻擊的呢?
我們來看下這個例子哈(來自百度百科)
-
Tom 登陸銀行,沒有退出,瀏覽器包含了 Tom 在銀行的身份認證信息。
-
黑客 Jerry 將偽造的轉賬請求,包含在在帖子
-
Tom 在銀行網站保持登陸的情況下,瀏覽帖子
-
將偽造的轉賬請求連同身份認證信息,發送到銀行網站
-
銀行網站看到身份認證信息,以為就是 Tom 的合法操作,最后造成 Tom 資金損失。
如何解決 CSRF 攻擊
-
檢查 Referer 字段。HTTP 頭中有一個 Referer 字段,這個字段用以標明請求來源於哪個地址。
-
添加校驗 token。
49. RARP 協議的工作原理?
-
ARP (地址解析協議) , 是設備通過自己知道的 IP 地址來獲得自己不知道的物理地址的協議。
-
RARP (反向地址轉換協議) 以與 ARP 相反的方式工作。RARP 發出要反向解析的物理地址並希望返回其對應的 IP 地址,應答包括由能夠提供所需信息的 RARP 服務器發出的 IP 地址。(應用於無盤機)
RARP 工作原理如下:
-
發送主機發送一個本地的 RARP 廣播,在此廣播包中,聲明自己的 MAC 地址並且請求任何收到此請求的 RARP 服務器分配一個 IP 地址;
-
本地網段上的 RARP 服務器收到此請求后,檢查其 RARP 列表,查找該 MAC 地址對應的 IP 地址;
-
如果存在,RARP 服務器就給源主機發送一個響應數據包並將此 IP 地址提供給對方主機使用;
-
如果不存在,RARP 服務器對此不做任何的響應;
-
源主機收到從 RARP 服務器的響應信息,就利用得到的 IP 地址進行通訊;如果一直沒有收到 RARP 服務器的響應信息,表示初始化失敗。
50. 了解下 DNS,解析過程?
DNS,domain name system,域名解析系統,是因特網上作為域名和 IP 地址相互映射的一個分布式數據庫。它的作用非常簡單,就是可以根據域名查出對應的 IP 地址。
解析過程如下:
-
首先,檢查瀏覽器緩存中,查找對應的 IP 地址,找到就直接返回;否則下一步。
-
將請求發送給本地 DNS 服務器,在本地 DNS 服務器緩存中查詢,如果查找到就直接返回,否則下一步;
-
本地 DNS 服務器向根域名服務器發送請求,根域名服務器會告訴本地 DNS 服務器去查詢哪個頂級域名服務器。
-
本地域名服務器向頂級域名服務器發起查詢請求,頂級域名服務器會告訴本地 DNS 服務器,去查找哪個權限域名服務器。
-
本地域名服務器向權限域名服務器發起查詢請求,權限域名服務器告訴本地域名服務器請求域名所對應的 IP 地址。
-
最后,本地域名服務器告訴主機請求域名所對應的 IP 地址。
比如要查詢 www.baidu.com 的 IP 地址:
-
首先會在瀏覽器的緩存中,是否查找到 www.baidu.com 的對應的 IP,找到就直接返回;否則下一步。
-
將請求發送給本地 DNS 服務器,在本地 DNS 服務器緩存中查詢,如果查找到就直接返回,否則下一步;
-
本地 DNS 服務器向根域名服務器發送請求,根域名服務器返回負責.com 的頂級域名服務器的 IP 地址的列表。
-
本地 DNS 服務器再向其中一個負責 .com 的頂級域名服務器發送一個請求,返回負責 .baidu 的權威域名服務器的 IP 地址列表。
-
本地 DNS 服務器再向其中一個權威域名服務器發送一個請求,返回 www.baidu.com 所對應的 IP 地址。
來源:https://learnku.com/articles/59484