1.概述
1.1 網路協議劃分
1.2 各協議位於哪層
網路層:IP、ICMP、ARP、RARP、BOOTP、TCP/IP
傳輸層:TCP、UDP
應用層:FTP、HTTP、DNS、TELNET、SMTP
1.3 5層模型功能描述
1.應用層
準備資料
2.傳輸層
對資料進行分塊,識別並將資料包正確交付相應的應用程式,識別資料包屬於哪個應用程式的方法為看埠;
3.網路層
對分好塊的資料加IP地址
4.資料鏈路層
對加完IP地址的資料加MAC地址
5.應用層
轉化為二進位制進行傳輸
應用層:解決透過應用程序的互動來實現特定網路應用的問題
傳輸層:解決程序之間基於網路的通訊問題
網路層:解決分組在多個網路上傳輸(路由)的問題
資料鏈路層:結局分組在一個網路(或一段鏈路)上傳輸的問題
物理層:解決使用何種訊號來傳輸位元的問題
TCP是面向位元組流的
TCP流量控制
TCP擁塞控制
TCP基於以位元組為單位的視窗滑動來實現可靠傳輸
TCP三次握手原因:防止已經失效的TCP請求報文段突然又傳到了TCP伺服器,因而導致錯誤
保活計時器
TCP規定,在建立連線後,所有的TCP報文段都必須把ACK置為1
動態主機配置協議DHCP:提供了即插即用聯網的機制
使用CS機制提供服務,基於UDP協議
DHCP客戶在為獲取到IP地址時使用地址0.0.0.0
DNS採用分散式系統、UDP協議進行封裝
域名分為:頂級域名、一級域名、二級域名。。。。。
FTP採用CS方式
2.物理層
根據資訊在傳輸線上的傳輸方式,分為三種:
1.單工通訊:單向傳輸
2.半雙工通訊:雙向交替通訊
3.全雙工通訊:雙向同時通訊
3.鏈路層
1.封裝成幀:將網路層傳下來的資料新增首部和尾部,用於標記幀的開始和結束。
透明傳輸:
幀使用首部和尾部進行界定,如果資料部分含有和首部和尾部相同的內容,為了防止錯誤判定,需要在那個相同資料前面新增跳脫字元,如果資料部分出現跳脫字元,需要在跳脫字元前面再新增跳脫字元。使用者察覺不出來跳脫字元的存在
通道分類
1.廣播通道:一對多通訊,一個節點傳送的資料能被廣播通道所有節點接收,需要方式協調。主要有兩種,通道複用技術或CSMA/CD協議
2.點對點通道:一對一通訊,沒有碰撞,比較簡單,使用PPP協議控制。
通道複用技術
1.分頻多工:所有主機在相同時間佔用不用的頻率頻寬資源
2.分時多工:在不同的時間佔用相同的頻率頻寬資源
上面兩種對通道的利用率都不高
3.統計分時多工:不固定使用者在分時多工幀中的位置,只要有資料就集中起來,組成幀傳送
4.波長分波多工
5.碼分複用
MAC地址
是鏈路層地址,長度為6位元組(48位),用於唯一表示網路介面卡(網路卡)
一臺機器有幾個網路卡,就有幾個MAC地址。比如筆記本有一個有線網路卡和一個無線網路卡
區域網
是一種典型的廣播通道,主要特線是網路為一個單位所擁有,且地理範圍和站點數目都有限
主要有乙太網、令牌環網、FDDI 和 ATM 等區域網技術,目前乙太網佔領著有線區域網市場
乙太網
乙太網是一種星型拓撲結構區域網。早期使用集線器進行連線,目前乙太網使用交換機替代了集線器,交換機是一種鏈路層裝置,它不會發生碰撞,能根據 MAC 地址進行儲存轉發。
4.網路層
網路層是整個網際網路的核心,使用IP協議把異構的物理網路連線起來,與IP協議配套使用的還有三個協議:
地址解析協議 ARP(Address Resolution Protocol)
網際控制報文協議 ICMP(Internet Control Message Protocol)
網際組管理協議 IGMP(Internet Group Management Protocol)
IP資料包格式
版本:有IPV4和IPV6兩個值
IP地址編址方式
三個歷史階段
1.分類:A類、B類。。。。E類
2.子網劃分
3.無分類
網際控制報文協議ICMP
是為了更有效的轉發IP資料包和提高交付成功的機會,它會封裝在IP資料包中,但是不屬於高階協議
ping是ICMP協議的一個重要應用
原理是向目標主機傳送ICMP echo請求報文,收到之後會傳送Echo報文回答,Ping會根據時間和成功相應次數計算時間和丟包率
虛擬專用網VPN
網路地址轉換NAT
5.傳輸層
網路層只把分組傳送到目的主機,但是真正進行通訊的不是主機而是主機中的程序,傳輸層提供了程序間的邏輯通訊,傳輸層向高層使用者遮蔽了下面網路層的核心細節,使應用程式看起來像是兩個傳輸層實體之間有一條端到端的邏輯通訊通道
5.1 UPD和TCP的特點
UDP:是無連線的,支援一對一,一對多,多對一,多對多互動通訊
TCP:面向連線的,面向位元組流,沒條TCP連線只能是一對一的
5.2 TCP報文段首部格式
-
序號 :用於對位元組流進行編號,例如序號為 301,表示第一個位元組的編號為 301,如果攜帶的資料長度為 100 位元組,那麼下一個報文段的序號應為 401。
-
確認號(ack):期望收到的下一個報文段的序號。例如 B 正確收到 A 傳送來的一個報文段,序號為 501,攜帶的資料長度為 200 位元組,因此 B 期望下一個報文段的序號為 701,B 傳送給 A 的確認報文段中確認號就為 701。
-
資料偏移 :指的是資料部分距離報文段起始處的偏移量,實際上指的是首部的長度。
-
確認 ACK :當 ACK=1 時確認號欄位有效,否則無效。TCP 規定,在連線建立後所有傳送的報文段都必須把 ACK 置 1。
-
同步 SYN :在連線建立時用來同步序號。當 SYN=1,ACK=0 時表示這是一個連線請求報文段。若對方同意建立連線,則響應報文中 SYN=1,ACK=1。
-
終止 FIN :用來釋放一個連線,當 FIN=1 時,表示此報文段的傳送方的資料已傳送完畢,並要求釋放連線。
-
視窗 :視窗值作為接收方讓傳送方設定其傳送視窗的依據。之所以要有這個限制,是因為接收方的資料快取空間是有限的。
5.3 TCP三次握手
假設 A 為客戶端,B 為伺服器端。
首先 B 處於 LISTEN(監聽)狀態,等待客戶的連線請求。
A 向 B 傳送連線請求報文,SYN=1,ACK=0,選擇一個初始的序號 x。
B 收到連線請求報文,如果同意建立連線,則向 A 傳送連線確認報文,SYN=1,ACK=1,確認號為 x+1,同時也選擇一個初始的序號 y。
A 收到 B 的連線確認報文後,還要向 B 發出確認,確認號為 y+1,序號為 x+1。
B 收到 A 的確認後,連線建立。
三次握手的原因:
第三次握手是為了防止失效的連線請求到達伺服器,讓伺服器錯誤開啟連線。
客戶端傳送的連線請求如果在網路中滯留,那麼就會隔很長一段時間才能收到伺服器端發回的連線確認。客戶端等待一個超時重傳時間之後,就會重新請求連線。但是這個滯留的連線請求最後還是會到達伺服器,如果不進行三次握手,那麼伺服器就會開啟兩個連線。如果有第三次握手,客戶端會忽略伺服器之後傳送的對滯留連線請求的連線確認,不進行第三次握手,因此就不會再次開啟連線。
ACK和ack的區別:
1.ACK出現在TCP報文的標誌位中,表示確認標誌位。ack出現在TCP報文的確認號欄位中,表示確認號
2.ACK在TCP建連和傳輸資料中,接收方收到資料後,會將ACK置為1,表示成功接收資料,並返回確認報文。ack在TCP建連和傳輸資料中,接收方返回確認報文時,會在ack中填寫期望收到的下一個位元組序號,告知傳送方從哪裡開始繼續傳送資料
5.4 TCP的四次揮手
以下描述不討論序號和確認號,因為序號和確認號的規則比較簡單。並且不討論 ACK,因為 ACK 在連線建立之後都為 1。
A 傳送連線釋放報文,FIN=1。
B 收到之後發出確認,此時 TCP 屬於半關閉狀態,B 能向 A 傳送資料但是 A 不能向 B 傳送資料。
當 B 不再需要連線時,傳送連線釋放報文,FIN=1。
A 收到後發出確認,進入 TIME-WAIT 狀態,等待 2 MSL(最大報文存活時間)後釋放連線。
B 收到 A 的確認後釋放連線。
四次揮手的原因:
客戶端傳送了 FIN 連線釋放報文之後,伺服器收到了這個報文,就進入了 CLOSE-WAIT 狀態。這個狀態是為了讓伺服器端傳送還未傳送完畢的資料,傳送完畢之後,伺服器會傳送 FIN 連線釋放報文。
TIME_WAIT:
客戶端接收到伺服器端的 FIN 報文後進入此狀態,此時並不是直接進入 CLOSED 狀態,還需要等待一個時間計時器設定的時間 2MSL。這麼做有兩個理由:
1.確保最後一個確認報文能夠到達。如果 B 沒收到 A 傳送來的確認報文,那麼就會重新傳送連線釋放請求報文,A 等待一段時間就是為了處理這種情況的發生。
2.等待一段時間是為了讓本連線持續時間內所產生的所有報文都從網路中消失,使得下一個新的連線不會出現舊的連線請求報文。
------------------------------------------------------------------------------------------------------------
TIME_WAIT狀態是TCP連線結束後的一個必要階段,主要作用是確保TCP全雙工連線的可靠終止。在這個階段中,主動關閉連線的一方會等待2倍MSL(報文的最大生存時間),通常是4分鐘,以確保網路上的所有重複分組都被清除且連線已經穩定關閉。
然而,TIME_WAIT狀態確實會對伺服器產生一定影響。首先,TIME_WAIT狀態下的TCP連線佔用的埠在這段時間內無法被再次使用,而TCP埠的數量上限是63。這意味著,如果有大量的短連線,可能會耗盡可用的埠資源,降低伺服器的處理能力。其次,對於高併發場景,短暫的業務處理和傳輸資料的時間遠遠小於TIME_WAIT超時的時間,這會導致用過的埠會停留在TIME_WAIT狀態幾分鐘,期間其他HTTP請求無法佔用此埠,降低了伺服器的併發處理能力。
但是值得注意的是,TIME_WAIT狀態不會永久存在,當MSL時間到達後,系統會自動回收並清理這些資源。此外,為了解決因TIME_WAIT狀態過多而導致的埠資源不足問題,可以採用一些解決方案,如修改系統引數以縮短TIME_WAIT狀態的持續時間或最佳化網路架構等。
5.5 埠的狀態
埠狀態主要包括LISTENING、ESTABLISHED、TIME_WAIT、SYN_SENT、CLOSE_WAIT、LAST_ACK、CLOSED等。這些狀態反映了TCP連線從建立到關閉過程中的不同階段,以下是對這些埠狀態的詳細解釋:
- LISTENING:表示埠正在監聽來自遠端主機的連線請求,這是伺服器端在等待客戶端發起連線時的狀態。當防火牆設定禁止某個埠時,該埠的狀態也可能顯示為LISTENING,但這表示攔截資料,不允許訪問。
- ESTABLISHED:表示兩臺機器之間已經建立了連線,並且正在通訊交換資料。這是TCP連線成功建立後的狀態。
- TIME_WAIT:表示結束了這次連線,說明某個埠曾經有過訪問,但訪問已經結束,正在等待足夠的時間以確保遠端TCP接收到連線中斷請求的確認。這個狀態的存在是為了防止舊的重複連線初始化新的連線。
- SYN_SENT:表示請求連線。當你要訪問其他計算機的服務時,首先要發個同步訊號給該埠,此時狀態為SYN_SENT。如果連線成功,則變為ESTABLISHED狀態。SYN_SENT狀態非常短暫,但如果發現大量SYN_SENT狀態且在向不同的機器發出,可能意味著機器中了病毒或正在進行網路掃描。
- CLOSE_WAIT:表示被動關閉。等待從本地使用者發來的連線中斷請求,被動關閉端TCP接到FIN後,就發出ACK以回應FIN請求(它的接收也作為檔案結束符傳遞給上層應用程式),並進入CLOSE_WAIT狀態。
- LAST_ACK:表示被動關閉連線過程中的狀態。等待原來的發向遠端TCP的連線中斷請求的確認,被動關閉端一段時間後,接收到檔案結束符的應用程式將呼叫CLOSE關閉連線,TCP也傳送一個FIN,等待對方的ACK,進入LAST-ACK狀態。
- CLOSED:表示連線結束,沒有任何連線狀態。被動關閉端在接受到ACK包後,就進入了CLOSED狀態,連線結束
6.應用層
域名系統DNS
DNS 是一個分散式資料庫,提供了主機名和 IP 地址之間相互轉換的服務。這裡的分散式資料庫是指,每個站點只保留它自己的那部分資料。
域名具有層次結構,從上到下依次為:根域名、頂級域名、二級域名。
DNS 可以使用 UDP 或者 TCP 進行傳輸,使用的埠號都為 53。大多數情況下 DNS 使用 UDP 進行傳輸,這就要求域名解析器和域名伺服器都必須自己處理超時和重傳從而保證可靠性。在兩種情況下會使用 TCP 進行傳輸:
如果返回的響應超過的 512 位元組(UDP 最大隻支援 512 位元組的資料)。
區域傳送(區域傳送是主域名伺服器向輔助域名伺服器傳送變化的那部分資料)。
檔案傳送協議
FTP 使用 TCP 進行連線,它需要兩個連線來傳送一個檔案:
控制連線:伺服器開啟埠號 21 等待客戶端的連線,客戶端主動建立連線後,使用這個連線將客戶端的命令傳送給伺服器,並傳回伺服器的應答。
資料連線:用來傳送一個檔案資料。
根據資料連線是否是伺服器端主動建立,FTP 有主動和被動兩種模式:
主動模式:伺服器端主動建立資料連線,其中伺服器端的埠號為 20,客戶端的埠號隨機,但是必須大於 1024,因為 0~1023 是熟知埠號。
被動模式:客戶端主動建立資料連線,其中客戶端的埠號由客戶端自己指定,伺服器端的埠號隨機。
主動模式要求客戶端開放埠號給伺服器端,需要去配置客戶端的防火牆。被動模式只需要伺服器端開放埠號即可,無需客戶端配置防火牆。但是被動模式會導致伺服器端的安全性減弱,因為開放了過多的埠號。
動態主機配置協議DHCP
DHCP (Dynamic Host Configuration Protocol) 提供了即插即用的連網方式,使用者不再需要手動配置 IP 地址等資訊。
DHCP 配置的內容不僅是 IP 地址,還包括子網掩碼、閘道器 IP 地址。
遠端登陸協議TELNET
TELNET 用於登入到遠端主機上,並且遠端主機上的輸出也會返回。
TELNET 可以適應許多計算機和作業系統的差異,例如不同作業系統系統的換行符定義。
電子郵件協議
一個電子郵件系統由三部分組成:使用者代理、郵件伺服器以及郵件協議。
郵件協議包含傳送協議和讀取協議,傳送協議常用 SMTP,讀取協議常用 POP3 和 IMAP。
Web頁面請求過程
1. DHCP 配置主機資訊
假設主機最開始沒有 IP 地址以及其它資訊,那麼就需要先使用 DHCP 來獲取。
主機生成一個 DHCP 請求報文,並將這個報文放入具有目的埠 67 和源埠 68 的 UDP 報文段中。
該報文段則被放入在一個具有廣播 IP 目的地址(255.255.255.255) 和源 IP 地址(0.0.0.0)的 IP 資料包中。
該資料包則被放置在 MAC 幀中,該幀具有目的地址 FF:<zero-width space>FF:<zero-width space>FF:<zero-width space>FF:<zero-width space>FF:FF,將廣播到與交換機連線的所有裝置。
連線在交換機的 DHCP 伺服器收到廣播幀之後,不斷地向上分解得到 IP 資料包、UDP 報文段、DHCP 請求報文,之後生成 DHCP ACK 報文,該報文包含以下資訊:IP 地址、DNS 伺服器的 IP 地址、預設閘道器路由器的 IP 地址和子網掩碼。該報文被放入 UDP 報文段中,UDP 報文段有被放入 IP 資料包中,最後放入 MAC 幀中。
該幀的目的地址是請求主機的 MAC 地址,因為交換機具有自學習能力,之前主機傳送了廣播幀之後就記錄了 MAC 地址到其轉發介面的交換表項,因此現在交換機就可以直接知道應該向哪個介面傳送該幀。
主機收到該幀後,不斷分解得到 DHCP 報文。之後就配置它的 IP 地址、子網掩碼和 DNS 伺服器的 IP 地址,並在其 IP 轉發表中安裝預設閘道器。
2. ARP 解析 MAC 地址
主機透過瀏覽器生成一個 TCP 套接字,套接字向 HTTP 伺服器傳送 HTTP 請求。為了生成該套接字,主機需要知道網站的域名對應的 IP 地址。
主機生成一個 DNS 查詢報文,該報文具有 53 號埠,因為 DNS 伺服器的埠號是 53。
該 DNS 查詢報文被放入目的地址為 DNS 伺服器 IP 地址的 IP 資料包中。
該 IP 資料包被放入一個乙太網幀中,該幀將傳送到閘道器路由器。
DHCP 過程只知道閘道器路由器的 IP 地址,為了獲取閘道器路由器的 MAC 地址,需要使用 ARP 協議。
主機生成一個包含目的地址為閘道器路由器 IP 地址的 ARP 查詢報文,將該 ARP 查詢報文放入一個具有廣播目的地址(FF:<zero-width space>FF:<zero-width space>FF:<zero-width space>FF:<zero-width space>FF:FF)的乙太網幀中,並向交換機傳送該乙太網幀,交換機將該幀轉發給所有的連線裝置,包括閘道器路由器。
閘道器路由器接收到該幀後,不斷向上分解得到 ARP 報文,發現其中的 IP 地址與其介面的 IP 地址匹配,因此就傳送一個 ARP 回答報文,包含了它的 MAC 地址,發回給主機。
3. DNS 解析域名
知道了閘道器路由器的 MAC 地址之後,就可以繼續 DNS 的解析過程了。
閘道器路由器接收到包含 DNS 查詢報文的乙太網幀後,抽取出 IP 資料包,並根據轉發表決定該 IP 資料包應該轉發的路由器。
因為路由器具有內部閘道器協議(RIP、OSPF)和外部閘道器協議(BGP)這兩種路由選擇協議,因此路由表中已經配置了閘道器路由器到達 DNS 伺服器的路由表項。
到達 DNS 伺服器之後,DNS 伺服器抽取出 DNS 查詢報文,並在 DNS 資料庫中查詢待解析的域名。
找到 DNS 記錄之後,傳送 DNS 回答報文,將該回答報文放入 UDP 報文段中,然後放入 IP 資料包中,透過路由器反向轉發回閘道器路由器,並經過乙太網交換機到達主機。
4. HTTP 請求頁面
有了 HTTP 伺服器的 IP 地址之後,主機就能夠生成 TCP 套接字,該套接字將用於向 Web 伺服器傳送 HTTP GET 報文。
在生成 TCP 套接字之前,必須先與 HTTP 伺服器進行三次握手來建立連線。生成一個具有目的埠 80 的 TCP SYN 報文段,並向 HTTP 伺服器傳送該報文段。
HTTP 伺服器收到該報文段之後,生成 TCP SYN ACK 報文段,發回給主機。
連線建立之後,瀏覽器生成 HTTP GET 報文,並交付給 HTTP 伺服器。
HTTP 伺服器從 TCP 套接字讀取 HTTP GET 報文,生成一個 HTTP 響應報文,將 Web 頁面內容放入報文主體中,發回給主機。
瀏覽器收到 HTTP 響應報文後,抽取出 Web 頁面內容,之後進行渲染,顯示 Web 頁面。
常見問題
客戶端透過new Socket()方法建立通訊的Socket物件
伺服器端透過new ServerSocket()建立TCP連線物件 accept接納客戶端請求
參考文章:
https://blog.csdn.net/SHENMEGUI_32/article/details/73824152
https://blog.csdn.net/huanglei305/article/details/99712771