常見協議埠號對應 + 重要協議詳解

常見協議以及對應埠

協議	埠
FTP協議：檔案傳輸協議，使用者使用FTP客戶端通過FTP協議訪問FTP伺服器上的檔案資源	20/21
SSH協議：安全外殼協議，專為遠端登入會話和其他網路服務提供的安全性協議。能夠避免中間人攻擊，DNS欺騙，IP欺騙等	22
Telnet協議：Internet遠端登陸服務的標準協議和主要方式	23
SMTP協議：簡單郵件傳輸協議，提供可靠且有效的電子郵件傳輸的協議，是建立在FTP檔案傳輸服務上的一種郵件服務	25
whois協議：查詢域名或者IP所有者資訊的傳輸協議	63
DNS：域名解析協議，是將域名和IP地址相互對映的一個分散式資料庫	53
DHCP：動態主機配置協議，用來給區域網客戶機分配IP地址與子網掩碼	67/68
HTTP協議：超文字傳輸協議，請求-響應協議	80
POP3：郵局協議版本3，於支援使用客戶端遠端管理在伺服器上的電子郵件	110
HTTPS協議：	443
IMAP協議：互動郵件訪問協議，郵件客戶端通過它從郵件伺服器上獲取或下載郵件
SNMP:簡單網路管理協議	161
遠端桌面連線	3389
MSQLL：資料庫伺服器，用於建立，使用和維護資料庫	1433
MYSQL：關係型資料庫管理系統	3306
Oracle資料庫：關聯式資料庫管理系統	1521

HTTP協議與HTTPS協議的區別

HTTP是明文傳輸的，如果黑客在傳輸過程中進行網路嗅探，中間人攻擊來修改客戶端與服務端之間的資料或者是在傳輸資料中惡意插入程式碼給其植入木馬等，極度不安全。

HTTPS 協議是由 HTTP 加上 TLS/SSL協議構建的可進行加密傳輸、身份認證的網路協議，主要通過數字證書、加密演算法、非對稱金鑰等技術完成網際網路資料傳輸加密，實現網際網路傳輸安全保護。通過傳輸加密和身份認證保證了傳輸過程的安全性。

對稱加密：

通過加密演算法使用金鑰對資料進行加密，同樣的也通過與之相對應的解密演算法使用相同的金鑰對資料進行解密。
然而，由於使用者數量的不確定性，對稱加密中的金鑰是唯一的，即任何一個使用者都可獲取當然也包括黑客，可見此加密方法不可靠。

非對稱加密：

同樣是通過金鑰對資料進行加密與解密，改變的是存在兩種金鑰，公鑰與私鑰，公鑰加密則對應私鑰解密，私鑰加密則對應公鑰解密，任何客戶端均可獲取公鑰，而私鑰只有服務端擁有。

過程：客戶端首先向服務端索要公鑰，獲取後就通過公鑰將其要傳輸的資料進行加密，到達服務端後，服務端使用私鑰對其進行解密獲取資料。由於黑客無法獲取私鑰於是其無法獲得客戶端向服務端傳送的資料。

但問題又來了，此時服務端應該向客戶端返回資料了，那麼使用什麼對返回的資料進行加密呢？
如果使用公鑰，由於客戶端沒有私鑰，無法獲取，而如果使用私鑰，雖然客戶端能夠使用公鑰進行解密，但同樣的黑客也擁有公鑰同樣可以獲取資料。
可見此加密方法只有當客戶端向服務端傳送資料時是安全的，而當服務端向客戶端傳送資料時仍存在被黑客侵入的可能。

對稱加密+非對稱加密：

改進：客戶端與服務端共同商議將開始客戶端向服務端傳送的經過公鑰加密的資料作為之後傳輸資料時的“私鑰”，這樣黑客由於並未參與其中的資料傳輸則不會得知此“私鑰”，於是不能侵入。
即開始時使用非對稱加密，此後為對此加密。

問題又來了：黑客可以直接截斷開始時客戶端向服務端索要公鑰的過程，即充當一箇中間人，對客戶端，黑客冒充自己的公鑰為服務端的公鑰發給客戶端；而自己又冒充客戶端與服務端進行資料傳輸；於是黑客能夠獲取所有客戶端以及服務端之間的所有資料並且可以任意更改，即中間人攻擊。
怎麼解決呢？你開始截斷，那我就堵你開始這個門。

對稱加密+非對稱加密+CA證書

在CA內部，也存在著公鑰以及私鑰，其通過一定的演算法使用去的私鑰對服務端本身將要發給客戶端的公鑰進行加密，生成一個license。之後客戶端向服務端索要的不再是服務端本身的公鑰而是這個license，之後的過程與上面一樣。不同的是，當黑客想充當中間人時，此時的license就是不安全的，客戶端也會檢測到，給予提醒與警告，從而推測出可能有黑客搞鬼。

—————————————————————————————

DHCP 動態主機配置協議

為網路內主機提供動態地址分配服務。
當一個DHCP客戶機想要一個IP地址時，就會以廣播的形式向DHCP伺服器傳送“我想要一個IP地址”，於是就會有許多DHCP伺服器向此客戶機提供給可用的IP，DHCP客戶機經過選擇之後就拿到了一個IP地址，最後再經過DHCP伺服器確認即可。

DNS 域名解析協議

域名只是為了便於人們記憶而起的一個名字，網路通訊大部分是基於TCP/IP的，而TCP/IP是基於IP地址的，在報文中，首部的源地址與目的地址均是IP地址，所以計算機在網路上進行通訊時只能識別IP地址，而不能認識域名。於是就需要進行域名解析。

當訪問一個域名時，首先會在自己本機的DNS快取上檢視是否有此域名的IP，如果沒有，進一步在系統配置的DNS伺服器上檢視，如果還沒有，再進一步在通過根DNS伺服器查詢此域名的IP存在於哪臺DNS伺服器上，確定後，即可獲知此域名的IP地址。

PS：DNS不光是能夠將域名解析為IP，其也可以進行域名與域名，域名與URL等的解析。這裡不再深究。

ARP 地址解析協議

是根據IP地址獲取實體地址的一個協議，每個主機都設有一個ARP快取記憶體，其中包含一個從IP地址到實體地址的一張對映表，且該表會實時動態更新

前面我們說過，IP地址是一個抽象地址，只有MAC地址才能夠在通訊中傳輸，於是就需要ARP協議來幫助我們獲取MAC地址。

在同一個區域網中，當1號主機想向2號機傳送資料時，首先會在自己的ARP快取中檢視2號機的Mac 地址，然後將其寫入Mac幀，然後把該Mac幀發往2號機。

如果1號機與2號機不屬於同一區域網，則該表中就沒有2號機IP與其Mac 地址的對映，那麼就需要通過路由器傳送到目的地。

—————————————————————————————

TCP 協議 - 三次握手 四次揮手

以訪問百度為例：

三次握手：建立連線
先由客戶端的核心傳輸控制層產生的一個資料包（syn),均是雙方核心在溝通，百度收到syn資料包，會給客戶端返回一個syn+ack的確認包；之後客戶端的傳輸控制層再次給百度返回一個ack確認包，即完成了三次握手。；

三次握手之後，雙方就會 開闢資源，進行 資料互動

四次揮手：釋放連線
客戶端向服務端傳送fin包，服務端返回fin+ack包（表明知道了訊息，但並未同意），同意後返回一個fin包，等待客戶端再返回一個ack包給服務端端之後，即完成了四次分手，目的是不要讓對方的資源隨意釋放。

本質上來講，就是 確認機制

TCP 傳輸控制協議 與 UDP 使用者資料包協議

TCP與UDP是傳輸層的兩種傳輸協議

UDP 在傳送資料之前不需要先建立連線，傳送資料結束後也不需要釋放連線，無確認機制，其提供的是無連線的服務，不可靠的，網路開銷小，速度快；
TCP 在傳送資料之前必須先建立連線，並且資料傳送結束後還要釋放連線，它提供的是面向連線的服務；提供可靠交付；提供全雙工通訊；面向位元組流;

今天的內容就到這裡啦！感謝觀看