網絡安全面試題

本文來自轉載自睶先森

本文面試題彙總:
防範常見的 Web 攻擊
重要協議分佈層
arp協議的工作原理
rip協議是什麼?rip的工作原理
什麼是RARP?工作原理
OSPF協議?OSPF的工作原理
TCP與UDP區別總結
什麼是三次握手四次揮手?
tcp爲什麼要三次握手?
dns是什麼?dns的工作原理
一次完整的HTTP請求過程
Cookies和session區別
GET 和 POST 的區別
HTTPS和HTTP的區別
session 的工作原理?
http長連接和短連接的區別
OSI 的七層模型都有哪些?
session 的工作原理?什麼是TCP粘包/拆包?發生原因?解決方案
TCP如何保證可靠傳輸?
URI和URL的區別
什麼是SSL ?
https是如何保證數據傳輸的安全(SSL是怎麼工作保證安全的)
TCP對應的應用層協議,UDP對應的應用層協議
常見的狀態碼有哪些?


防範常見的 Web 攻擊
什麼是SQL注入攻擊
攻擊者在HTTP請求中注入惡意的SQL代碼,服務器使用參數構建數據庫SQL命令時,惡意SQL被一起構造,並在數據庫中執行。
用戶登錄,輸入用戶名 lianggzone,密碼 ‘ or ‘1’=’1 ,如果此時使用參數構造的方式,就會出現
select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’
不管用戶名和密碼是什麼內容,使查詢出來的用戶列表不爲空。如何防範SQL注入攻擊使用預編譯的PrepareStatement是必須的,但是一般我們會從兩個方面同時入手。
Web端
1)有效性檢驗。
2)限制字符串輸入的長度。
服務端
1)不用拼接SQL字符串。
2)使用預編譯的PrepareStatement。
3)有效性檢驗。(爲什麼服務端還要做有效性檢驗?第一準則,外部都是不可信的,防止攻擊者繞過Web端請求)
4)過濾SQL需要的參數中的特殊字符。比如單引號、雙引號。

什麼是XSS攻擊
跨站點腳本攻擊,指攻擊者通過篡改網頁,嵌入惡意腳本程序,在用戶瀏覽網頁時,控制用戶瀏覽器進行惡意操作的一種攻擊方式。如何防範XSS攻擊
1)前端,服務端,同時需要字符串輸入的長度限制。
2)前端,服務端,同時需要對HTML轉義處理。將其中的”<”,”>”等特殊字符進行轉義編碼。
防 XSS 的核心是必須對輸入的數據做過濾處理。

什麼是CSRF攻擊
跨站點請求僞造,指攻擊者通過跨站請求,以合法的用戶的身份進行非法操作。可以這麼理解CSRF攻擊:攻擊者盜用你的身份,以你的名義向第三方網站發送惡意請求。CRSF能做的事情包括利用你的身份發郵件,發短信,進行交易轉賬,甚至盜取賬號信息。如何防範CSRF攻擊
安全框架,例如Spring Security。
token機制。在HTTP請求中進行token驗證,如果請求中沒有token或者token內容不正確,則認爲CSRF攻擊而拒絕該請求。
驗證碼。通常情況下,驗證碼能夠很好的遏制CSRF攻擊,但是很多情況下,出於用戶體驗考慮,驗證碼只能作爲一種輔助手段,而不是最主要的解決方案。
referer識別。在HTTP Header中有一個字段Referer,它記錄了HTTP請求的來源地址。如果Referer是其他網站,就有可能是CSRF攻擊,則拒絕該請求。但是,服務器並非都能取到Referer。很多用戶出於隱私保護的考慮,限制了Referer的發送。在某些情況下,瀏覽器也不會發送Referer,例如HTTPS跳轉到HTTP。
1)驗證請求來源地址;
2)關鍵操作添加驗證碼;
3)在請求地址添加 token 並驗證。

什麼是文件上傳漏洞
文件上傳漏洞,指的是用戶上傳一個可執行的腳本文件,並通過此腳本文件獲得了執行服務端命令的能力。
許多第三方框架、服務,都曾經被爆出文件上傳漏洞,比如很早之前的Struts2,以及富文本編輯器等等,可被攻擊者上傳惡意代碼,有可能服務端就被人黑了。如何防範文件上傳漏洞
文件上傳的目錄設置爲不可執行。
1)判斷文件類型。在判斷文件類型的時候,可以結合使用MIME Type,後綴檢查等方式。因爲對於上傳文件,不能簡單地通過後綴名稱來判斷文件的類型,因爲攻擊者可以將可執行文件的後綴名稱改爲圖片或其他後綴類型,誘導用戶執行。
2)對上傳的文件類型進行白名單校驗,只允許上傳可靠類型。
3)上傳的文件需要進行重新命名,使攻擊者無法猜想上傳文件的訪問路徑,將極大地增加攻擊成本,同時向shell.php.rar.ara這種文件,因爲重命名而無法成功實施攻擊。
4)限制上傳文件的大小。
5)單獨設置文件服務器的域名。

DDos 攻擊
客戶端向服務端發送請求鏈接數據包,服務端向客戶端發送確認數據包,客戶端不向服務端發送確認數據包,服務器一直等待來自客戶端的確認
沒有徹底根治的辦法,除非不使用TCP
DDos 預防:
1)限制同時打開SYN半鏈接的數目
2)縮短SYN半鏈接的Time out 時間
3)關閉不必要的服務

重要協議分佈圖
在這裏插入圖片描述

arp協議的工作原理
地址解析協議,即ARP(Address Resolution Protocol),是根據IP地址獲取物理地址的一個TCP/IP協議。
1.發送ARP請求的以太網數據幀 廣播 到以太網上的每個主機,ARP請求幀中包含了目的主機的IP地址。
2.目的主機收到了該ARP請求之後,會發送一個ARP應答,裏面包含了目的主機的MAC地址。
ARP協議工作原理:
每個主機都會在自己的 ARP 緩衝區中建立一個 ARP 列表,以表示 IP 地址和 MAC 地址之間的對應關係。
主機(網絡接口)新加入網絡時(也可能只是mac地址發生變化,接口重啓等), 會發送免費ARP報文把自己IP地址與Mac地址的映射關係廣播給其他主機。
網絡上的主機接收到免費ARP報文時,會更新自己的ARP緩衝區。將新的映射關係更新到自己的ARP表中。
某個主機需要發送報文時,首先檢查 ARP 列表中是否有對應 IP 地址的目的主機的 MAC 地址,如果有,則直接發送數據,如果沒有,就向本網段的所有主機發送 ARP 數據包,該數據包包括的內容有:源主機 IP 地址,源主機 MAC 地址,目的主機的 IP 地址等。
當本網絡的所有主機收到該 ARP 數據包時:
(A)首先檢查數據包中的 IP 地址是否是自己的 IP 地址,如果不是,則忽略該數據包。
(B)如果是,則首先從數據包中取出源主機的 IP 和 MAC 地址寫入到 ARP 列表中,如果已經存在,則覆蓋。
(C) 然後將自己的 MAC 地址寫入 ARP 響應包中,告訴源主機自己是它想要找的 MAC 地址。
6.源主機收到 ARP 響應包後。將目的主機的 IP 和 MAC 地址寫入 ARP 列表,並利用此信息發送數據。如果源主機一直沒有收到 ARP 響應數據包,表示 ARP 查詢失敗。ARP高速緩存(即ARP表)是 ARP地址解析協議能夠高效運行的關鍵

什麼是RARP?工作原理
概括: 反向地址轉換協議,網絡層協議,RARP與ARP工作方式相反。 RARP使只知道自己硬件地址的主機能夠知道其IP地址。RARP發出要反向解釋的物理地址並希望返回其IP地址,應答包括能夠提供所需信息的RARP服務器發出的IP地址。
原理:
(1)網絡上的每臺設備都會有一個獨一無二的硬件地址,通常是由設備廠商分配的MAC地址。主機從網卡上讀取MAC地址,然後在網絡上發送一個RARP請求的廣播數據包,請求RARP服務器回覆該主機的IP地址。

(2)RARP服務器收到了RARP請求數據包,爲其分配IP地址,並將RARP迴應發送給主機。

(3)PC1收到RARP迴應後,就使用得到的IP地址進行通訊。

dns是什麼?dns的工作原理
將主機域名轉換爲ip地址,屬於應用層協議,使用UDP傳輸。(應用層協議)
在這裏插入圖片描述

過程:
總結: 瀏覽器緩存,系統緩存,路由器緩存,IPS服務器緩存,根域名服務器緩存,頂級域名服務器緩存,主域名服務器緩存。
一、主機向本地域名服務器的查詢一般都是採用遞歸查詢。
二、本地域名服務器向根域名服務器的查詢的迭代查詢。
1)當用戶輸入域名時,瀏覽器先檢查自己的緩存中是否 這個域名映射的ip地址,有解析結束。
2)若沒命中,則檢查操作系統緩存(如Windows的hosts)中有沒有解析過的結果,有解析結束。
3)若無命中,則請求本地域名服務器解析( LDNS)。
4)若LDNS沒有命中就直接跳到根域名服務器請求解析。根域名服務器返回給LDNS一個 主域名服務器地址。
5) 此時LDNS再發送請求給上一步返回的gTLD( 通用頂級域), 接受請求的gTLD查找並返回這個域名對應的Name Server的地址
6) Name Server根據映射關係表找到目標ip,返回給LDNS
7) LDNS緩存這個域名和對應的ip, 把解析的結果返回給用戶,用戶根據TTL值緩存到本地系統緩存中,域名解析過程至此結束
dns解析

rip協議是什麼?rip的工作原理
RIP動態路由選擇協議(網絡層協議)
RIP是一種基於距離矢量(Distance-Vector)算法的協議,它使用跳數(Hop Count)作爲度量來衡量到達目的網絡的路由距離。RIP通過UDP報文進行路由信息的交換,使用的端口號爲520。

工作原理:
RIP路由協議用“更新(UNPDATES)”和“請求(REQUESTS)”這兩種分組來傳輸信息的。每個具有RIP協議功能的路由器每隔30秒用UDP520端口給與之直接相連的機器廣播更新信息。並且在( 用“路程段數”(即“跳數”)作爲網絡距離的尺度。每個路由器在)給相鄰路由器發出路由信息時,都會給每個路徑加上內部距離。
路由器的收斂機制:
任何距離向量路由選擇協議(如RIP)都有一個問題,路由器不知道網絡的全局情況,路由器必須依靠相鄰路由器來獲取網絡的可達信息。由於路由選擇更新信息在網絡上傳播慢,距離向量路由選擇算法有一個慢收斂問題,這個問題將導致不一致性產生。
RIP較少路由收斂機制帶來的問題:
1)記數到無窮大機制: RIP協議允許最大跳數爲15。大於15的目的地被認爲是不可達。 當路徑的跳數超過15,這條路徑才從路由表中刪除。
2) 水平分割法: 路由器不向路徑到來的方向回傳此路徑。當打開路由器接口後,路由器記錄路徑是從哪個接口來的,並且不向此接口回傳此路徑。
3) 破壞逆轉的水平分割法: 忽略在更新過程中從一個路由器獲取的路徑又傳回該路由器
4)保持定時器法: 防止路由器在路徑從路由表中刪除後一定的時間內(通常爲180秒)接受新的路由信息。 保證每個路由器都收到了路徑不可達信息
5) 觸發更新法: 當某個路徑的跳數改變了,路由器立即發出更新信息,不管路由器是否到達常規信息更新時間都發出更新信息。

RIP的缺點
1、由於15跳爲最大值,RIP只能應用於小規模網絡;2、收斂速度慢;3、根據跳數選擇的路由,不一定是最優路由。

OSPF協議?OSPF的工作原理
OSPF(Open Shortest Pass First,開放最短路徑優先協議),是一個最常用的內部網管協議,是一個鏈路狀態協議。(網絡層協議,)
原理:
OSPF組播的方式在所有開啓OSPF的接口發送Hello包,用來確定是否有OSPF鄰居,若發現了,則建立OSPF鄰居關係,形成鄰居表,之後互相發送LSA(鏈路狀態通告)相互通告路由,形成LSDB(鏈路狀態數據庫)。再通過SPF算法,計算最佳路徑(cost最小)後放入路由表。

TCP與UDP區別總結?
1.TCP面向連接(如打電話要先撥號建立連接)提供可靠的服務;UDP是無連接的,即發送數據之前不需要建立連接,;UDP盡最大努力交付,即不保證可靠交付
2.UDP具有較好的實時性,工作效率比TCP高,適用於對高速傳輸和實時性有較高的通信或廣播通信。
3. 每一條TCP連接只能是點到點的;UDP支持一對一,一對多,多對一和多對多的交互通信
4 TCP對系統資源要求比UDP較多,TCP首部開銷20字節;UDP的首部開銷小,只有8個字節。
5. TCP面向字節流,實際上是TCP把數據看成一連串無結構的字節流;UDP是面向報文的。

什麼是三次握手四次揮手?tcp爲什麼要三次握手?
爲了防止已失效的連接請求報文段突然又傳送到了服務端,因而產生錯誤

第一次握手:建立連接時,客戶端發送syn包(syn=j)到服務器,並進入SYN_SEND狀態,等待服務器確認;
第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也發送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入SYN_RECV狀態;
第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手。
完成三次握手,客戶端與服務器開始傳送數據
在這裏插入圖片描述

1、客戶端先發送FIN,進入FIN_WAIT1狀態,用來關閉Client到Server的數據傳送
2、服務端收到FIN,發送ACK,進入CLOSE_WAIT狀態,客戶端收到這個ACK,進入FIN_WAIT2狀態
3、服務端發送FIN,進入LAST_ACK狀態,用來關閉Server到Client的數據傳送
4、客戶端收到FIN,發送ACK,進入TIME_WAIT狀態,服務端收到ACK,進入CLOSE狀態(等待2MSL時間,約4分鐘。主要是防止最後一個ACK丟失。)

四次揮手
第一次揮手:主動關閉方發送一個FIN,用來關閉主動方到被動關閉方的數據傳送,也就是主動關閉方告訴被動關閉方:我已經不 會再給你發數據了(當然,在fin包之前發送出去的數據,如果沒有收到對應的ack確認報文,主動關閉方依然會重發這些數據),但是,此時主動關閉方還可 以接受數據。
第二次揮手:被動關閉方收到FIN包後,發送一個ACK給對方,確認序號爲收到序號+1(與SYN相同,一個FIN佔用一個序號)。
第三次揮手:被動關閉方發送一個FIN,用來關閉被動關閉方到主動關閉方的數據傳送,也就是告訴主動關閉方,我的數據也發送完了,不會再給你發數據了。
第四次揮手:主動關閉方收到FIN後,發送一個ACK給被動關閉方,確認序號爲收到序號+1,至此,完成四次揮手。
在這裏插入圖片描述

GET 和 POST 的區別
get是獲取數據,post是修改數據
get把請求的數據放在url上, 以?分割URL和傳輸數據,參數之間以&相連,所以get不太安全。而post把數據放在HTTP的包體內(requrest body)
get提交的數據最大是2k( 限制實際上取決於瀏覽器), post理論上沒有限制。
GET產生一個TCP數據包,瀏覽器會把http header和data一併發送出去,服務器響應200(返回數據); POST產生兩個TCP數據包,瀏覽器先發送header,服務器響應100 continue,瀏覽器再發送data,服務器響應200 ok(返回數據)。
GET請求會被瀏覽器主動緩存,而POST不會,除非手動設置。
GET是冪等的,而POST不是冪等的
Cookies和session區別
Cookie和Session都是客戶端與服務器之間保持狀態的解決方案
1,存儲的位置不同,cookie:存放在客戶端,session:存放在服務端。Session存儲的數據比較安全
2,存儲的數據類型不同
兩者都是key-value的結構,但針對value的類型是有差異的
cookie:value只能是字符串類型,session:value是Object類型
3,存儲的數據大小限制不同
cookie:大小受瀏覽器的限制,很多是是4K的大小, session:理論上受當前內存的限制,
4,生命週期的控制
cookie的生命週期當瀏覽器關閉的時候,就消亡了
(1)cookie的生命週期是累計的,從創建時,就開始計時,20分鐘後,cookie生命週期結束,
(2)session的生命週期是間隔的,從創建時,開始計時如在20分鐘,沒有訪問session,那麼session生命週期被銷燬

session 的工作原理?
session 的工作原理是客戶端登錄完成之後,服務器會創建對應的 session,session 創建完之後,會把 session 的 id 發送給客戶端,客戶端再存儲到瀏覽器中。這樣客戶端每次訪問服務器時,都會帶着 sessionid,服務器拿到 sessionid 之後,在內存找到與之對應的 session 這樣就可以正常工作了。

一次完整的HTTP請求過程
域名解析 --> 發起TCP的3次握手 --> 建立TCP連接後發起http請求 --> 服務器響應http請求,瀏覽器得到html代碼 --> 瀏覽器解析html代碼,並請求html代碼中的資源(如js、css、圖片等) --> 瀏覽器對頁面進行渲染呈現給用戶。

HTTPS和HTTP的區別
1.HTTP協議傳輸的數據都是未加密的,也就是明文的,因此使用HTTP協議傳輸隱私信息非常不安全, HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,要比http協議安全。
2. https協議需要到ca申請證書,一般免費證書較少,因而需要一定費用。
3、http和https使用的是完全不同的連接方式,用的端口也不一樣,前者是80,後者是443。
https://www.cnblogs.com/wqhwe/p/5407468.html

OSI 的七層模型都有哪些?
物理層:利用傳輸介質爲數據鏈路層提供物理連接,實現比特流的透明傳輸。
數據鏈路層:接收來自物理層的位流形式的數據,並封裝成幀,傳送到上一層
網絡層:將網絡地址翻譯成對應的物理地址,並通過路由選擇算法爲分組通過通信子網選擇最適當的路徑。
傳輸層:在源端與目的端之間提供可靠的透明數據傳輸
會話層:負責在網絡中的兩節點之間建立、維持和終止通信
表示層:處理用戶信息的表示問題,數據的編碼,壓縮和解壓縮,數據的加密和解密
應用層:爲用戶的應用進程提供網絡通信服務

http長連接和短連接的區別
在HTTP/1.0中默認使用短連接。也就是說,客戶端和服務器每進行一次HTTP操作,就建立一次連接,任務結束就中斷連接。而從HTTP/1.1起,默認使用長連接,用以保持連接特性。什麼是TCP粘包/拆包?發生原因?解決方案 一個完整的業務可能會被TCP拆分成多個包進行發送,也有可能把多個小的包封裝成一個大的數據包發送,這個就是TCP的拆包和粘包問題。原因:1. 應用程序寫入數據的字節大小大於套接字發送緩衝區的大小.2. 進行MSS大小的TCP分段。( MSS=TCP報文段長度-TCP首部長度)3. 以太網的payload大於MTU進行IP分片。( MTU指:一種通信協議的某一層上面所能通過的最大數據包大小。)解決方案:1. 消息定長。2. 在包尾部增加回車或者空格符等特殊字符進行分割3. 將消息分爲消息頭和消息尾。4. 使用其它複雜的協議,如RTMP協議等。

TCP如何保證可靠傳輸?

  1. 三次握手。
  2. 將數據截斷爲合理的長度。應用數據被分割成 TCP 認爲最適合發送的數據塊(按字節編號,合理分片)
  3. 超時重發。當 TCP 發出一個段後,它啓動一個定時器,如果不能及時收到一個確認就重發
  4. 確認應答:對於收到的請求,給出確認響應
  5. 校驗和:校驗出包有錯,丟棄報文段,不給出響應
  6. 序列號:對失序數據進行重新排序,然後才交給應用層
  7. 丟棄重複數據:對於重複數據 , 能夠丟棄重複數據
  8. 流量控制。TCP 連接的每一方都有固定大小的緩衝空間。TCP 的接收端只允許另一端發送接收端緩衝區所能接納的數據。這將防止較快主機致使較慢主機的緩衝區溢出。
  9. 擁塞控制。當網絡擁塞時,減少數據的發送。
  10. 三次握手。
  11. 將數據截斷爲合理的長度。應用數據被分割成 TCP 認爲最適合發送的數據塊(按字節編號,合理分片)
  12. 超時重發。當 TCP 發出一個段後,它啓動一個定時器,如果不能及時收到一個確認就重發
  13. 確認應答:對於收到的請求,給出確認響應
  14. 校驗和:校驗出包有錯,丟棄報文段,不給出響應
  15. 序列號:對失序數據進行重新排序,然後才交給應用層
  16. 丟棄重複數據:對於重複數據 , 能夠丟棄重複數據
  17. 流量控制。TCP 連接的每一方都有固定大小的緩衝空間。TCP 的接收端只允許另一端發送接收端緩衝區所能接納的數據。這將防止較快主機致使較慢主機的緩衝區溢出。
  18. 擁塞控制。當網絡擁塞時,減少數據的發送。

常見的狀態碼有哪些?
200 OK //客戶端請求成功403 Forbidden //服務器收到請求,但是拒絕提供服務
404 Not Found //請求資源不存在,eg:輸入了錯誤的URL
500 Internal Server Error //服務器發生不可預期的錯誤URI和URL的區別URI,統一資源標識符,用來唯一的標識一個資源。URL可以用來標識一個資源,而且還指明瞭如何定位這個資源。

什麼是SSL ?https是如何保證數據傳輸的安全(SSL是怎麼工作保證安全的)
SSL代表安全套接字層。它是一種用於加密和驗證應用程序(如瀏覽器)和Web服務器之間發送的數據的協議。 身份驗證 , 加密Https的加密機制是一種共享密鑰加密和公開密鑰加密並用的混合加密機制。SSL/TLS協議作用:認證用戶和服務,加密數據,維護數據的完整性的應用層協議加密和解密需要兩個不同的密鑰,故被稱爲非對稱加密;加密和解密都使用同一個密鑰的 對稱加密。 優點在於加密、解密效率通常比較高HTTPS 是基於非對稱加密的, 公鑰是公開的,
(1)客戶端向服務器端發起SSL連接請求;
(2) 服務器把公鑰發送給客戶端,並且服務器端保存着唯一的私鑰
(3)客戶端用公鑰對雙方通信的對稱祕鑰進行加密,併發送給服務器端
(4)服務器利用自己唯一的私鑰對客戶端發來的對稱祕鑰進行解密,
(5)進行數據傳輸,服務器和客戶端雙方用公有的相同的對稱祕鑰對數據進行加密解密,可以保證在數據收發過程中的安全,即是第三方獲得數據包,也無法對其進行加密,解密和篡改。
因爲數字簽名、摘要是證書防僞非常關鍵的武器。 “摘要”就是對傳輸的內容,通過hash算法計算出一段固定長度的串。然後,在通過CA的私鑰對這段摘要進行加密,加密後得到的結果就是“數字簽名”

SSL/TLS協議的基本思路是採用公鑰加密法,也就是說,客戶端先向服務器端索要公鑰,然後用公鑰加密信息,服務器收到密文後,用自己的私鑰解密。
如何保證公鑰不被篡改?
將公鑰放在數字證書中。只要證書是可信的,公鑰就是可信的。
公鑰加密計算量太大,如何減少耗用的時間?
每一次對話(session),客戶端和服務器端都生成一個"對話密鑰"(session key),用它來加密信息。由於"對話密鑰"是對稱加密,所以運算速度非常快,而服務器公鑰只用於加密"對話密鑰"本身,這樣就減少了加密運算的消耗時間。
(1) 客戶端向服務器端索要並驗證公鑰。
(2) 雙方協商生成"對話密鑰"。
(3) 雙方採用"對話密鑰"進行加密通信。上面過程的前兩步,又稱爲"握手階段"(handshake)。

《計算機網絡》書本:
SSL工作過程,A:客戶端,B:服務器端
1.協商加密算法:A向B發送SSL版本號和可選加密算法,B選擇自己支持的算法並告知A
2.服務器鑑別:B向A發送包含公鑰的數字證書,A使用CA公開發布的公鑰對證書進行驗證
3.會話密鑰計算:A產生一個隨機祕密數,用B的公鑰進行加密後發送給B,B根據協商的算法產生共享的對稱會話密鑰併發送給A.
4.安全數據傳輸:雙方用會話密鑰加密和解密它們之間傳送的數據並驗證其完整性

TCP對應的應用層協議
FTP:定義了文件傳輸協議,使用21端口.
Telnet:它是一種用於遠程登陸的端口,23端口
SMTP:定義了簡單郵件傳送協議,服務器開放的是25號端口。
POP3:它是和SMTP對應,POP3用於接收郵件。
HTTP
UDP對應的應用層協議
DNS:用於域名解析服務,用的是53號端口
SNMP:簡單網絡管理協議,使用161號端口
TFTP(Trival File Transfer Protocal):簡單文件傳輸協議,69
在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章