計算機網路複習筆記 - IT人

文章推薦指數: 80 %
投票人數:10人

這個就像作業系統會提供標準的程式設計介面,比如win32程式設計介面一樣,TCP/IP也要提供可供程式設計師做網路開發所用的介面,這就是Socket程式設計介面 ... Togglenavigation IT人 IT人 計算機網路複習筆記 AlexEz發表於 2021-03-02 計算機網路 Author:AlexEz Mail:[email protected] 若發現錯誤和遺漏請指正 原創,禁止轉載 目錄 目錄目錄1計算機網路概述1.1網路概念1.2資料交換方式1.3網路分類1.4網路的效能指標1.5網路體系結構1.概念2.OSI參考模型1物理層2資料鏈路層3網路層4傳輸層5會話層6表示層7應用層通訊過程資料封裝網路排錯3.TCP/IP參考模型4.5層參考模型5層結構資料封裝2.應用層2.1體系結構1.客戶機/伺服器結構(Client/Server)2.P2P結構(peer-to-peer)3.混合結構2.2程式間通訊1.Socket2.定址3.應用層協議2.3Web應用1.HTTP協議2.Cookie3.Web快取/代理伺服器技術2.4Email應用1.郵件客戶端(useragent)2.郵件伺服器(mailserver)3.SMTP協議(SimpleMailTransferProtocol)4.郵件訪問協議2.5DNS應用1.DNS服務2.分散式層次式資料庫4.DNS記錄和訊息格式1.DNS記錄2.DNS協議與訊息2.6P2P應用1.BitTorrent2.索引設計2.7Socket程式設計1.SocketAPI2.API呼叫流程2.8CDN3.傳輸層3.1傳輸層服務1.多路複用/分用2.可靠資料傳輸機制RDT版本流水線協議滑動視窗協議TCP可靠資料傳輸3.流量控制機制4.擁塞控制機制3.2Internet傳輸層協議1.UDP特點:應用:可靠性保證報文格式:2.TCP特點:報文格式:連線管理三次握手四次揮手4.網路層4.1網路層服務1.轉發2.路由3.連線建立4.網路層服務模型4.2虛電路網路4.3資料包網路4.4IPv4協議1.IP資料包格式2.IP分片3.IP編址(addressing)4.CIDR5.路由聚合4.5DHCP協議4.6NAT4.7ICMP協議4.8IPv6協議4.9路由演算法4.10Internet路由1.RIP協議2.OSPF3.BGP協議4.11SDN控制平面4.12網路管理與SNMP5.資料鏈路層5.1差錯檢測和糾正位元1.奇偶校驗碼2.Internet校驗和3.迴圈冗餘校驗碼5.2多路訪問控制(MAC)協議1.通道劃分(channelpartitioning)MAC協議2.隨機訪問(randomaccess)MAC協議3.輪轉(takingturns)MAC協議5.3ARP協議1.MAC地址2.地址解析協議5.4乙太網乙太網幀結構交換機VLANs 1計算機網路概述 介面與協議的區別 介面規定了執行在一個端系統上的程式請求因特網基礎設施向執行在另一個端系統上的特定目的地程式交付資料的方式 協議定義了在兩個或多個通訊實體之間交換的報文的格式和順序,以及報文傳送/或接收一條報文或其他事件所採取的動作。

TCP/IP只是一個協議棧,就像作業系統的執行機制一樣,必須要具體實現,同時還要提供對外的操作介面。

這個就像作業系統會提供標準的程式設計介面,比如win32程式設計介面一樣,TCP/IP也要提供可供程式設計師做網路開發所用的介面,這就是Socket程式設計介面。

1.1網路概念 網路:許多計算機連在一起 網際網路:internet許多網路連在一起 因特網:Internet全求最大的網際網路 1.2資料交換方式 電路交換(CircuitSwitching)實時性、建立專用路線 報文交換(MessageSwitching)報文一般比分組長、報文交換的時延較長 分組交換(PacketSwitching)高效、迅速時延高 路由器儲存轉發功能 1.3網路分類 按作用範圍分: 新的理解,不單單從網路覆蓋的範圍來區分廣域網、區域網 使用了廣域網技術即廣域網 使用了區域網技術即區域網 區域網:自己花錢購買裝置、自己維護、頻寬固定(100M,1000M),距離一般在100m以內 廣域網:花錢買服務、花錢買頻寬 1.4網路的效能指標 速率:數字通道上傳送資料位數的速率 頻寬:數字通道能傳送的最高速率(b/s) 吞吐量(Throughput):傳送端與接收端之間傳送資料速率(b/s)瓶頸鍊路 時延: 傳送(傳輸)時延(transmissiondelay)=\(分組長度(bit)/鏈路頻寬(bit/s)\) 傳播時延(propagationdelay)=\(物理鏈路長度(m)/訊號在通道上的傳播速率(m/s)\) 處理時延:差錯檢測、確定輸出鏈路,一般建立tcp協議三次握手過程-->客戶端發出訪問網站相應頁面請求(發出http協議請求報文)-->服務端發出相應訪問頁面的響應資訊(發出http響應報文)-->斷開tcp協議四次揮手過程 DNS查詢順序:Hosts表-->本地DNS快取-->上層DNS(迭代、泛洪) 在本機與目標伺服器之間的路由過程,包括IP協議、ARP協議、OSPF協議、BGP協議 拿到響應訊息了還需要瀏覽器進行解析渲染 2.Cookie 記錄使用者狀態,有隱私問題 響應訊息cookie頭部行 請求訊息cookie頭部行 儲存在客戶端主機上的cookie檔案,由瀏覽器管理 Web伺服器後臺資料庫 3.Web快取/代理伺服器技術 一般由ISP架設 在不訪問伺服器的前提下滿足客戶端的HTTP請求 縮短客戶請求的響應時間 減少機構/組織的流量 在大範圍內實現有效的內容分發(CDN) 條件性GET方法更新快取的資料,解決一致性問題 2.4Email應用 1.郵件客戶端(useragent) 2.郵件伺服器(mailserver) 郵箱:儲存發給該使用者的Email 訊息佇列(messagequeue):儲存等待傳送的Email 3.SMTP協議(SimpleMailTransferProtocol) 客戶端:傳送訊息的伺服器 服務端:接受訊息的伺服器 使用TCP進行Email訊息的可靠傳輸 埠25 傳輸三個階段 握手 訊息傳輸 關閉 命令/響應互動模式 命令command:ASCII文字 響應response:狀態程式碼和語句 //先去qq郵箱開啟smtp,獲取授權碼 //輸入需要進行base64加密 c:telnetsmtp.qq.com25 s:220xxx.qq.com c:helohost//打招呼 s:250xxx.qq.com c:AUTHLOGIN//登入認證 s:334VXNbWU6//輸入賬號 c:MTA3MxcS5jb20= s:334UGFc3d6//輸入授權碼 c:dWdwaXF5Y3ZzraWhQ== s:235Authenticationsuccessful c:mailfrom://來自 s:250OK c:rcptto://發往 s:250OK c:data s:354Enddatawith.. c:hereiswhatiwanttosend c:. s:250OK:queuedas. c:quit s:221bye MIME:多媒體郵件擴充套件,在頭部行增加擴充套件 4.郵件訪問協議 用於從伺服器獲取郵件 POP:PostOfficeProtocol 較簡單,認證授權和下載 無狀態 IMAP:InternetMailAccessProtocol 更多功能,更復雜 有狀態 HTTP 2.5DNS應用 1.DNS服務 DomainNameSystem 解決Internet上主機/路由器的識別問題 域名向IP地址的翻譯 主機別名 郵件伺服器別名 負載均衡:Web伺服器 多個IP地址對應一個名字 2.分散式層次式資料庫 解決的問題: 單點失敗問題 流量問題 距離問題 維護性問題 根域名伺服器 不知道對映訪問權威域名伺服器 全球13個 頂級域名伺服器(TLD,top-leveldomain) com,org,net,edu等 權威域名伺服器(Authoritative) 組織的域名解析伺服器 本地域名解析伺服器 不嚴格屬於層級體系發 每個ISP有一個 主機進行查詢傳送給本地進行代理 迭代查詢:代理進行多次詢問 遞迴查詢:代理詢問一次讓其他伺服器去找 4.DNS記錄和訊息格式 1.DNS記錄 資源記錄(RR,resourcerecords) format:(name,value,type,ttl) 2.DNS協議與訊息 查詢(query)和回覆(relpy)訊息 訊息格式相同 同時使用TCP(區域傳輸時)和UDP(域名解析時) 2.6P2P應用 檔案分發比C/S架構快 1.BitTorrent 檔案分為chunk 獲取:稀缺優先、定期查詢鄰居持有的chunk列表 傳送:tit-for-tat 節點可自由加入和離開 Q:為什麼運營商會封BT? A:很簡單,影響網路運營商超賣頻寬了。

ISP尤其是國內ISP最大的問題是,給使用者提供網路接入服務,但從不保證服務質量。

宣傳上的“100M頻寬光纖入戶”從來不意味著你真的能用上100M頻寬。

甚至ISP從主觀上,會用各種手段限制你,不讓你用滿這100M頻寬。

拋開遠端伺服器和整體網路鏈路的因素以外,跑不滿100M最主要原因在於ISP超賣,他們手裡總共有1000M頻寬,就敢給20家住戶每家賣100M頻寬,然後祈禱這20家不要同時把100M頻寬跑滿。

只要你用任何技術手段,不管是BTCT還是ET,只要大部分使用者能這個技術穩定跑滿頻寬,ISP就會對這個技術恨得牙癢癢,恨不得封殺了之~除此以外的理由都是藉口。

連結:https://www.zhihu.com/question/310343843/answer/618352530 2.索引設計 集中式索引:增設中央伺服器 單點失效問題 效能瓶頸 版權問題 洪泛式查詢:queryflooding 覆蓋網路(overlaynetwork):Graph 有很大的網路負擔 查詢訊息通過已有TCP連線傳送 節點轉發查詢訊息 查詢命中反向路經返回 層次式覆蓋網路 介於集中與洪泛之間 節點和超級節點間維持TCP連線:集中 某些超級節點之間維持TCP連線:洪泛 如:skype 2.7Socket程式設計 1.SocketAPI 標識通訊端點(對外):IP地址+埠號 作業系統/程式管理(對內):套接字描述符(socketdescriptor) 型別: SOCK_STREAM:TCP協議 SOCK_DGRAM:UDP協議 SOCK_RAW:面向網路層 函式: WSAStartup()使用之前呼叫,初始化socket動態連結庫 WSACleanup()使用之後呼叫 socket()建立套接字 closesocket()關閉套接字,引用為0關閉 bind()為套接字設定本地端點地址, 客戶程式一般不必呼叫 服務端使用地址萬用字元INADDR_ANY listen()僅服務端,TCP連線,置伺服器端的流套接字處於監聽狀態,設定連線請求佇列大小 connect()僅客戶端,客戶端呼叫使其與特定計算機的特定埠的套接字進行連線 accept()伺服器端,用於TCP連線,建立一個新的套接字與客戶通訊,因為TCP連線是點對點的,實現併發的TCP伺服器 send()有連線的方式TCP(客戶與伺服器),或呼叫了connect函式的UDP(客戶)套接字 sendto()無連線方式UDP(伺服器),或未呼叫connect函式的UDP客戶端套接字 recv()同上 recvfrom()同上 2.API呼叫流程 網路位元組順序:實現本地位元組順序與網路位元組順序進行轉換 基本服務型別: 迴圈無連線 迴圈面向連線 併發無連線:建立子程式處理 併發面向連線 2.8CDN 內容分發網路 DASH(DynamicAdaptiveStreamingoverHTTP)經HTTP的動態適應流 可以壓縮生成相同視訊的多個版本,每個版本有不同的質量等級。

CDN管理分佈在多個地理位置上的伺服器,在它的伺服器中儲存視訊(或其他資源)的副本,並且所有試圖將每個使用者請求定向到一個將提供最好的使用者體驗的CDN位置 3.傳輸層 傳輸層協議為執行在不同Host上的應用程式提供了一種邏輯通訊機制 位於網路層之上 依賴於網路層的服務 對網路層服務進行增強 3.1傳輸層服務 1.多路複用/分用 此處的複用和分用是邏輯上的概念 傳送端多路複用:處理來自多個套接字的資料,新增傳輸頭 Q:I/O多路複用技術(multiplexing)是什麼? A: 常見的IO操作,如read和write,通常是阻塞IO,也就是說當你呼叫read時,如果沒有資料收到,那麼執行緒或者程式就會被掛起,直到收到資料。

這樣在處理大量連線時可能需要很多執行緒,比如4個核要跑1000個執行緒,那麼每個執行緒的時間槽非常短,而執行緒切換非常頻繁,大量時間花費在上下文切換。

此時引入非阻塞IO的概念,通過fcntl(POSIX)或ioctl(Unix)設為非阻塞模式,這時,當你呼叫read時,如果有資料收到,就返回資料,如果沒有資料收到,就立刻返回一個錯誤,如EWOULDBLOCK。

這樣是不會阻塞執行緒了,但是你還是要不斷的輪詢來讀取或寫入。

於是,我們需要引入IO多路複用的概念。

多路複用是指使用一個執行緒來檢查多個檔案描述符(Socket)的就緒狀態,比如呼叫select和poll函式,傳入多個檔案描述符,如果有一個檔案描述符就緒,則返回,否則阻塞直到超時。

得到就緒狀態後進行真正的操作可以在同一個執行緒裡執行,也可以啟動執行緒執行(比如使用執行緒池)。

這樣在處理1000個連線時,只需要1個執行緒監控就緒狀態,對就緒的每個連線開一個執行緒處理就可以了,這樣需要的執行緒數大大減少,減少了記憶體開銷和上下文切換的CPU開銷。

接收端多路分解:使用傳輸頭資訊交付接收到的段到正確的套接字 注意:服務端一個程式有多個執行緒,一個執行緒有多個套接字 UDP的socket用二元組標識 TCP的socket用四元組標識 2.可靠資料傳輸機制 Q:什麼是可靠(reliable)? A:不錯、不丟、不亂 通道的不可靠特性決定了可靠資料傳輸協議(RDT)的複雜性 介面的結構: RDT版本 ReliableDataTransfer Rdt1.0:可靠通道 Rdt2.0:產生位錯誤的通道 利用校驗和檢測位錯誤 確認機制(Acknowledgments,ACK):正確接收 NAK:告知分組有錯,重傳分組 基於這種重傳機制的rdt協議稱為ARQ(AutomaticRepeatreQuest)協議 FSM(FinitStateMachine)規約 Rdt2.1:應對ACK/NAK破壞 傳送方為每個分組增加序列號 兩個序列號(0,1)就夠用了,因為只用記住當前的序列號 接收方判斷分組是否重複 傳送方 接收方 Rdt2.2:無NAK訊息協議 接收方通過ACK告知最後一個被正確接受的分組 傳送方接收到重複ACK之後,重傳當前分組 FSM(相比2.1有較大簡化) Rdt3.0:通道既可能傳送錯誤,也可能丟失分組 傳送方等待“合理”時間,如果沒有收到ACK,重傳 新增定時器 時延有影響 效能很差 網路協議可能影響物理資源的利用 流水線協議 流水線機制提高資源利用率 需要更大的序列號範圍 需要更大的儲存空間以快取分組 滑動視窗協議 Sliding-windowprotocol 視窗 允許使用的序列號範圍 視窗尺寸為N:最多有N個等待確認的訊息 滑動視窗 隨著協議的執行,視窗在序列號空間內向前滑動 Go-Back-N(GBN)協議 傳送方: 設定一個計時器 ACK(n):確認到序列號n(包含n)的分組均已被正確接收 超時Timeout(n)事件:重傳序列號大於等於n,還未收到ACK的所有分組 接收方: ACK機制:傳送擁有最高序列號的、已被正確接收的分組的ACK 可能產生重複的ACK 只需要記住唯一的expectedseqnum 亂序到達的分組 直接丟棄->沒有快取 重新確認序列號最大的、按序到達的分組 SelectiveRepeat(SR)協議 傳送方 只重傳沒有接收到ACK的分組 N個連續的序列號 用單個硬體定時器模擬多個邏輯定時器 接收方 對每個分組單獨進行確認 設定快取機制,快取亂序到達可以 序列號空間大小與視窗尺寸應滿足的關係: \(傳送方視窗尺寸+接收方視窗尺寸\le可用序列號個數(2^k,k為序列號使用位數)\) TCP可靠資料傳輸 累計確認,返回期望收到的 使用單一重傳定時器 定時器時間設定: \(TimeoutInterval=EstimatedRTT+4*DevRTT\) 即EstimatedRTT+“安全邊界” \(EstimatedRTT=(1-\alpha)\cdotEstimatedRTT+\alpha\cdotSampleRTT(typically,\alpha=0.125)\) \(DevRTT=(1-\beta)\cdotDevRTT+\beta\cdot|SampleRTT-EstimatedRTT|(typically,\beta=0.25)\) 快速重傳機制 如果sender收到對同一資料的3個ACK,則假定該資料之後的段已經丟失,在定時器超時之前立即重傳。

Q:為什麼是三次冗餘ACK? A:假定通訊雙方A和B傳送4個TCPSegment TCPsegment亂序有2/5=40%的概率會造成A收到三次duplicatedACK(N); 而如果N丟了,則A有100%概率會收到三次duplicatedACK(N); 基於以上的統計,當A接收到三次duplicatedACK(N)啟動FastRetransmit演算法是合理的,即立馬retransmitN,可以起到FastRecovery的功效,快速修復一個丟包對TCP管道的惡劣影響 而如果A接收到二次duplicatedACK(N),則一定說明是亂序造成的,即然是亂序,說明資料都到達了B,B的TCP負責重新排序而已,沒有必要A再來啟動FastRetransmit演算法 3.流量控制機制 消除傳送發使接受方快取溢位的可能,是一種速度匹配服務,傳送發傳送速率與接收方的讀取速率匹配。

TCP流量控制: Receiver通過在Segment的頭部欄位將RcvWindow告訴Sender \(rwnd=RcvBuffer-(LastByteRcvd-LastByteRead)\) Sender限制自己已經傳送的但還未收到ACK的資料不超過接收方的空閒RcvWindow大小 \(LastByteSent-LastByteAcked\lerwnd\) 4.擁塞控制機制 傳送方維持一個叫做擁塞視窗cwnd(congestionwindow)的狀態變數。

擁塞視窗的大小取決於網路的擁塞程度,並且動態地在變化。

傳送方讓自己的傳送視窗等於擁塞視窗,另外考慮到接受方的接收能力,傳送視窗可能小於擁塞視窗。

MSS(maximunsegmentsize)最大報文段大小,不包括TCP/IP首部的長度,典型值為1460位元組 代價: 當分組到達速率接近鏈路容量時,分組將經歷較長的排隊時延。

傳送方必須執行重傳以補償因為快取溢位而丟棄(丟失)的分組。

在多跳網路中,當分組被drop時,任何用於該分組的”上游“傳輸能力全都被浪費掉 控制方法: 端到端擁塞控制:在端到端擁塞控制方法中,網路層沒有為傳輸層擁塞控制提供顯式支援。

即使在網路中存在擁塞,端系統也必須通過對網路行為的觀察(如分組丟失與時延)來推斷擁塞的發生。

TCP必須通過端到端的方法處理擁塞控制,因為lP層不會向端系統提供有關網路擁塞的反饋資訊。

TCP報文段的丟失(通過超時或3次冗餘確認而得知)被認為是網路擁塞的一個跡象,TCP會相應地減小其傳送視窗長度。

具有公平性。

\(LastByteSent-LastByteAcked\leCongWin\) \(rate\approx\frac{CongWin}{RTT}Bytes/sec\) 加性增-乘性減(AIMD) AdditiveIncrease:每個RTT將CongWin增大一個MSS--擁塞避免 MultiplicativeDecrease:發生loss後將CongWin減半 鋸齒狀 慢啟動 cwnd的值以一個MSS開始,並且每當收到一個傳輸報文段的確認時就增加1MSS(相當於變為2倍) 擁塞避免 也就是每個傳輸輪次,擁塞視窗cwnd只能線性加一,而不是像慢開始演算法時,每個傳輸輪次,擁塞視窗cwnd按指數增長。

發生超時重傳,判斷網路可能出現擁塞: 將ssthresh的值更新為發生擁塞時的cwnd的一半 將cwnd的值減小為1,並重新開始執行慢啟動演算法 快速恢復 傳送方一旦收到3個重複確認,就知道現在只是丟失了個別的報文段。

於是不啟動慢開始演算法,而執行快恢復演算法 傳送方將慢開始ssthresh的值和擁塞視窗cwnd值調整為當前視窗的一半,開始執行擁塞避免演算法 也有的快恢復實現是把快恢復開始時的擁塞視窗cwnd值再增大一些,即等於新的ssthresh+3 既然傳送方收到3個重複的確認,就表明有3個資料包文段已經離開了網路; 這3個報文段不再消耗網路資源而是停留在接收方的接收快取中; 可見現在網路中不是堆積了報文段而是減少了3個報文段。

因此可以適當把擁塞視窗擴大些。

Q:何時將指數增長切換為線性增長: A:當CongWin達到Loss事件前值的1/2時,即到達Threshold 新增變數Threshold,發生loss時將其設定為CongWin達到Loss事件前值的1/2 發生Timeout時,Threshold設定為1/2CongWin,直接將CongWin設為1MSS, 網路輔助的擁塞控制:在網路輔助的擁塞控制中,網路層裝置件(即路由器)向傳送方提供關於網路中擁塞狀態的顯式反饋資訊。

這種反饋可以通過資料包中的某個欄位來指示鏈路中的擁塞情況。

這種方法在早期的IBMSNA和ATM等體系結構中採用。

對於網路輔助的擁塞控制,擁塞資訊從網路反饋到傳送方通常有兩種方式,直接反饋資訊可以由網路路由器發給傳送方。

另一種形式是,路由器標記或更新從傳送方流向接收方的分組中的某個欄位來指示擁塞的產生(可以理解為對經過一個擁塞路由器的資料包做記號)。

一旦接收方收到這個有擁塞標記的分組,就會通知傳送方網路發生了擁塞。

3.2Internet傳輸層協議 1.UDP UserDatagramProtocol 為什麼存在? 無需建立連線 實現簡單:無需維護連線狀態 頭部開銷少 沒有擁塞控制:應用可更好的控制傳送時間和速率 特點: 基於InternetIP協議 複用/分用 簡單的錯誤校驗 “Besteffort”服務 可能丟失 可能非按序到達 在應用層增加可靠性機制 無連線 傳送方和接受方不需要握手 每個UDP段的處理獨立於其他段 應用: 流媒體(容許錯誤、速率敏感) DNS SNMP 可靠性保證 在應用層新增可靠性保證 與具體應用相關的錯誤恢復 在http3.0中使用 http3.0withgooglequick 報文格式: 分解示意圖: UDP長度欄位包含首部長度 單位:位元組 校驗和(checksum):檢測UDP段在傳輸中是否發生錯誤(如位翻轉) 2.TCP TransmissionControlProtocol 特點: 點對點 可靠的、按序的位元組流 流水線機制 傳送方/接收方快取 全雙工 面向連線 流量控制機制 報文格式: 連線管理 三次握手 三次握手(Three-wayHandshake)其實就是指建立一個TCP連線時,需要客戶端和伺服器總共傳送3個包。

進行三次握手的主要作用就是為了確認雙方的接收能力和傳送能力是否正常、指定自己的初始化序列號為後面的可靠性傳送做準備。

實質上其實就是連線伺服器指定埠,建立TCP連線,並同步連線雙方的序列號和確認號,交換TCP視窗大小資訊。

握手過程: 剛開始客戶端處於Closed的狀態,服務端處於Listen狀態。

第一次握手:客戶端給服務端發一個SYN(同步)報文,並指明客戶端的初始化序列號ISN(Initialsequencenumber)。

此時客戶端處於SYN_SEND狀態。

首部的同步位SYN=1,初始序號seq=x,SYN=1的報文段不能攜帶資料,但要消耗掉一個序號。

服務端得出結論:客戶端的傳送能力、服務端的接收能力是正常的。

第二次握手:伺服器收到客戶端的SYN報文之後,進行資源分配(可能受到SYNFlood攻擊,可以使用SYNcookie進行防禦),以自己的SYN報文作為應答,並且也是指定了自己的初始化序列號ISN。

同時會把客戶端的ISN+1作為ack(確認號)的值,表示自己已經收到了客戶端的SYN,此時伺服器處於SYN_REVD的狀態。

在確認報文段中SYN=1,ACK=1,確認號ack=x+1,初始序號seq=y。

客戶端得出結論:服務端的接收、傳送能力,客戶端的接收、傳送能力是正常的。

不過此時伺服器並不能確認客戶端的接收能力是否正常。

第三次握手:客戶端收到SYN報文之後,會傳送一個ACK報文,當然,也是一樣把伺服器的ISN+1作為ack的值,表示已經收到了服務端的SYN報文,此時客戶端處於ESTABLISHED狀態。

伺服器收到ACK報文之後,也處於ESTABLISHED狀態,此時,雙方已建立起了連線。

確認報文段SYN=0,ACK=1,確認號ack=y+1,序號seq=x+1(初始為seq=x,第二個報文段所以要+1),ACK報文段可以攜帶資料,不攜帶資料則不消耗序號。

服務端得出結論:客戶端的接收、傳送能力正常,伺服器自己的傳送、接收能力也正常。

傳送第一個SYN的一端將執行主動開啟(activeopen),接收這個SYN併發回下一個SYN的另一端執行被動開啟(passiveopen)。

在socket程式設計中,客戶端執行connect()時,將觸發三次握手。

Q:為什麼要進行3次握手,不是2次或更多? A:假設採用2次握手。

如客戶端發出連線請求,但因連線請求報文丟失而未收到確認,於是客戶端再重傳一次連線請求。

後來收到了確認,建立了連線。

資料傳輸完畢後,就釋放了連線,客戶端共發出了兩個連線請求報文段,其中第一個丟失,第二個到達了服務端,但是第一個丟失的報文段只是在某些網路結點長時間滯留了,延誤到連線釋放以後的某個時間才到達服務端,此時服務端誤認為客戶端又發出一次新的連線請求,於是就向客戶端發出確認報文段,同意建立連線,不採用三次握手,只要服務端發出確認,就建立新的連線了,此時客戶端忽略服務端發來的確認,也不傳送資料,則服務端一致等待客戶端傳送資料,浪費資源。

四次揮手 TCP的連線的拆除需要傳送四個包,因此稱為四次揮手(Four-wayhandshake),客戶端或伺服器均可主動發起揮手動作。

剛開始雙方都處於ESTABLISHED狀態,假如是客戶端先發起關閉請求。

四次揮手的過程如下: 第一次揮手:客戶端傳送一個FIN報文,報文中會指定一個序列號。

此時客戶端處於FIN_WAIT1狀態。

即發出連線釋放報文段(FIN=1,序號seq=u),並停止再傳送資料,主動關閉TCP連線,進入FIN_WAIT1(終止等待1)狀態,等待服務端的確認。

第二次揮手:服務端收到FIN之後,會傳送ACK報文,且把客戶端的序列號值+1作為ACK報文的序列號值,表明已經收到客戶端的報文了,此時服務端處於CLOSE_WAIT狀態。

即服務端收到連線釋放報文段後即發出確認報文段(ACK=1,確認號ack=u+1,序號seq=v),服務端進入CLOSE_WAIT(關閉等待)狀態,此時的TCP處於半關閉狀態,客戶端到服務端的連線釋放。

客戶端收到服務端的確認後,進入FIN_WAIT2(終止等待2)狀態,等待服務端發出的連線釋放報文段。

第三次揮手:如果服務端也想斷開連線了,和客戶端的第一次揮手一樣,發給FIN報文,且指定一個序列號。

此時服務端處於LAST_ACK的狀態。

即服務端沒有要向客戶端發出的資料,服務端發出連線釋放報文段(FIN=1,ACK=1,序號seq=w,確認號ack=u+1),服務端進入LAST_ACK(最後確認)狀態,等待客戶端的確認。

第四次揮手:客戶端收到FIN之後,一樣傳送一個ACK報文作為應答,且把服務端的序列號值+1作為自己ACK報文的序列號值,此時客戶端處於TIME_WAIT狀態。

需要過一陣子以確保服務端收到自己的ACK報文之後才會進入CLOSED狀態,服務端收到ACK報文之後,就處於關閉連線了,處於CLOSED狀態。

即客戶端收到服務端的連線釋放報文段後,對此發出確認報文段(ACK=1,seq=u+1,ack=w+1),客戶端進入TIME_WAIT(時間等待)狀態。

此時TCP未釋放掉,需要經過時間等待計時器設定的時間2MSL後,客戶端才進入CLOSED狀態。

收到一個FIN只意味著在這一方向上沒有資料流動。

客戶端執行主動關閉並進入TIME_WAIT是正常的,服務端通常執行被動關閉,不會進入TIME_WAIT狀態。

在socket程式設計中,任何一方執行close()操作即可產生揮手操作。

Q:揮手為什麼需要四次? A:因為當服務端收到客戶端的SYN連線請求報文後,可以直接傳送SYN+ACK報文。

其中ACK報文是用來應答的,SYN報文是用來同步的。

但是關閉連線時,當服務端收到FIN報文時,很可能並不會立即關閉SOCKET,所以只能先回復一個ACK報文,告訴客戶端,“你發的FIN報文我收到了”。

只有等到我服務端所有的報文都傳送完了,我才能傳送FIN報文,因此不能一起傳送(伺服器的兩次傳送不能合併)。

故需要四次揮手。

Q:釋放連線時,等待2MSL的意義? A:MSL是MaximumSegmentLifetime的英文縮寫,可譯為“最長報文段壽命”,它是任何報文在網路上存在的最長時間,超過這個時間報文將被丟棄。

保證客戶端傳送的最後一個ACK報文段能夠到達服務端。

因為這個ACK有可能丟失,從而導致處在LAST-ACK狀態的伺服器收不到對FIN-ACK的確認報文。

伺服器會超時重傳這個FIN-ACK,接著客戶端再重傳一次確認,重新啟動時間等待計時器。

最後客戶端和伺服器都能正常的關閉。

假設客戶端不等待2MSL,而是在傳送完ACK之後直接釋放關閉,一但這個ACK丟失的話,伺服器就無法正常的進入關閉連線狀態。

防止“已失效的連線請求報文段”出現在本連線中。

客戶端在傳送完最後一個ACK報文段後,再經過2MSL,就可以使本連線持續的時間內所產生的所有報文段都從網路中消失,使下一個新的連線中不會出現這種舊的連線請求報文段。

進一步解釋: 主動斷開的一側為A,被動斷開的一側為B。

第一個訊息:A發FIN 第二個訊息:B回覆ACK 第三個訊息:B發出FIN 此時此刻:B單方面認為自己與A達成了共識,即雙方都同意關閉連線。

此時,B能釋放這個TCP連線佔用的記憶體資源嗎?不能,B一定要確保A收到自己的ACK、FIN。

所以B需要靜靜地等待A的第四個訊息的到來: 第四個訊息:A發出ACK,用於確認收到B的FIN 當B接收到此訊息,即認為雙方達成了同步:雙方都知道連線可以釋放了,此時B可以安全地釋放此TCP連線所佔用的記憶體資源、埠號。

所以被動關閉的B無需任何waittime,直接釋放資源。

但,A並不知道B是否接到自己的ACK,A是這麼想的: 1)如果B沒有收到自己的ACK,會超時重傳FIN 那麼A再次接到重傳的FIN,會再次傳送ACK,重新計時 2)如果B收到自己的ACK,也不會再發任何訊息,包括ACK 無論是1還是2,A都需要等待,要取這兩種情況等待時間的最大值,以應對最壞的情況發生,這個最壞情況是: ACK從A到B最多經過1MSL,超過這個時間B會重發FIN B重發的FIN最多經過1MSL到達A 去向ACK訊息最大存活時間(MSL)+來向FIN訊息的最大存活時間(MSL)。

這恰恰就是2MSL(MaximumSegmentLife)。

等待2MSL時間,A就可以放心地釋放TCP佔用的資源、埠號,此時可以使用該埠號連線任何伺服器。

TCP的四種計時器 重傳計時器(RetransmissionTimer) 目的:為了控制丟失的報文段或者丟棄的報文段。

這段時間為對報文段的等待確認時間。

建立時間:在TCP傳送報文段時,會建立對次特定報文段的重傳計時器。

可能發生的兩種情況:在截止時間(通常為60秒)到之前,已經收到了對此特定報文段的確認,則撤銷計時器;在截止時間到了,但為收到對此特定報文段的確認,則重傳報文段,並且將計時器復位。

重傳時間:2*RTT(RoundTripTime,為往返時間) 堅持計時器(PersistentTimer) 目的:主要解決零視窗大小通知可能導致的死鎖問題 死鎖問題的產生:當接收端的視窗大小為0時,接收端向傳送端傳送一個零視窗報文段,傳送端即停止向對端傳送資料。

此後,如果接收端快取區有空間則會重新給傳送端傳送一個視窗大小,即視窗更新。

但接收端傳送的這個確認報文段有可能會丟失,而此時接收端不知道已經丟失並認為自己已經傳送成功,則一直處於等待資料的狀態;而傳送端由於沒有收到該確認報文段,就會一直等待對方發來新的視窗大小,這樣一來,雙方都處在等待對方的狀態,這樣就形成了一種死鎖問題。

如果沒有應對措施,這種局面是不會被打破的。

為了解決這種問題,TCP為每一個連線設定了堅持計時器。

工作原理:當傳送端TCP收到接收端發來的零視窗通知時,就會啟動堅持計時器。

當計時器的期限到達時,傳送端就會主動傳送一個特殊的報文段告訴對方確認已經丟失,必須重新傳送。

【這個特殊的報文段就稱為探測報文段,探測報文段只有1個位元組的大小,裡邊只有一個序號,該序號不需要被確認,甚至在計算其他部分資料的確認時該序號會被忽略。

】 截止期的設定:設定為重傳時間的值。

但如果沒有收到接收端的響應,則會傳送另一個探測報文段,並將計時器的值加倍並復位,直到大於門限值(一般為60秒)。

在此之後,傳送端會每隔60秒傳送一個探測報文段,直到視窗重新開啟。

保活計時器(KeepliveTimer) 目的:主要是為了防止兩個TCP連線出現長時間的空閒。

當客戶端與伺服器端建立TCP連線後,很長時間內客戶端都沒有向伺服器端傳送資料,此時很有可能是客戶端出現故障,而伺服器端會一直處於等待狀態。

保活計時器就是解決這種問題而生的。

工作原理:每當伺服器端收到客戶端的資料時,都將保活計時器重新設定(通常設定為2小時)。

過了2小時後,伺服器端如果沒有收到客戶端的資料,會傳送探測報文段給客戶端,並且每隔75秒傳送一個,當連續傳送10次以後,仍沒有收到對端的來信,則伺服器端認為客戶端出現故障,並會終止連線。

時間等待計時器(Time_WaitTimer) 時間等待計時器是在連線終止期間使用的。

當TCP關閉連線時並不是立即關閉的,在等待期間,連線還處於過渡狀態。

這樣就可以使重複的FIN報文段在到達終點之後被丟棄。

時間設定:一般為報文段壽命期望值的2倍。

原文連結:https://blog.csdn.net/qq_33951180/java/article/details/60468267 遊戲伺服器協議選擇 那麼到底是用UDP還是TCP呢? 如果是由客戶端間歇性的發起無狀態的查詢,並且偶爾發生延遲是可以容忍,那麼使用HTTP/HTTPS吧。

如果客戶端和伺服器都可以獨立發包,但是偶爾發生延遲可以容忍(比如:線上的紙牌遊戲,許多MMO類的遊戲),那麼使用TCP長連線吧。

如果客戶端和伺服器都可以獨立發包,而且無法忍受延遲(比如:大多數的多人動作類遊戲,一些MMO類遊戲),那麼使用UDP吧。

這些也應該考慮在內:你的MMO客戶端也許首先使用HTTP去獲取上一次的更新內容,然後使用UDP跟遊戲伺服器進行連線。

永遠不要害怕去使用最佳的工具來解決問題。

連結:https://www.jianshu.com/p/08af0f7d335b 王者榮耀 4.網路層 4.1網路層服務 1.轉發 forwarding:將分組從路由器的輸入埠轉移到合適的輸出埠 轉發表確定在本路由器如何轉發分組 2.路由 routing:確定分組從源到目的經過的路徑 路由演算法(協議)確定通過網路的端到端路徑 路由器結構 輸入輸出埠 交換機構內,基於目的的轉發,使用最長字首匹配原則 輸出埠側,當資料包從交換機構中以高於傳輸速率的速度到達時需要緩衝,可按照一定的排程策略進行分發 分組排程策略 先來先服務 優先權排隊 迴圈和加權公平排隊 3.連線建立 某些網路的功能 注意:網路層連線是兩個主機之間(路徑上的路由器等網路裝置參與其中) 傳輸層連線:兩個應用程式之間(對中間網路裝置透明) 4.網路層服務模型 無連線服務(connection-lessservice):資料包網路 連線服務(connectionservice):虛電路網路 4.2虛電路網路 ATM網路 虛電路(VIrtualcircuits):一條從源主機到目的主機,類似於電路的路徑 每個分組的傳輸利用鏈路的全部頻寬 每個分組攜帶虛電路標識(VCID),沿路每段鏈路一個編號 虛電路經過的每個網路裝置維護每條經過它的虛電路的連線狀態 簡化邊緣、複雜網路 虛電路信令協議(signalingprotocols) 建立和拆除電路 4.3資料包網路 Internet網路 網路層不連線 每個分組攜帶目的地址 資料包轉發表(按地址範圍劃分) 最長字首匹配優先 簡化網路、複雜邊緣 4.4IPv4協議 1.IP資料包格式 首部長度以4位元組為單位,即一位代表一行 首部校驗和:只對IP首部進行校驗 總長度欄位(首部+資料),資料最大長度\(2^{16}-20=65515B\) TTL(TimeToLive):IP分組在網路中可以通過的路由器數(跳數),每轉發一次減一,為零丟棄分組 協議:指示IP分組封裝的是哪個協議的資料包,實現複用/分用 2.IP分片 最大傳輸單元(MTU) 不同鏈路的MTU不同 分片(fregmented) 重組(reassembled) 標識欄位:IP協議利用一個計數器,每產生一個IP分組計數器加1,作為IP分組的標識(結合源目的地址唯一標識) 標誌位:3位:|保留|DF(DontFragment)|MF(MoreFragment)| DF=1:禁止分片 DF=0:允許分片 MF=1:非最後一片,有更多分片 MF=0:最後一片(或未分片) 片偏移:13位,以8位元組為單位:一個IP分組分片封裝原IP分組資料的相對偏移量 區分最後一片還是未分片 分片過程: 3.IP編址(addressing) 點分十進位制IP地址 網路號(NetID)-高位位元 主機號(HostID)-低位位元 相同網路號構成IP子網(Subnets) 不跨越路由器 有類劃分 IP地址根據網路號和主機號來分,分為A、B、C三類及特殊地址D、E。

全0和全1的都保留不用。

A類:(1.0.0.0-126.0.0.0)(預設子網掩碼:255.0.0.0或0xFF000000)第一個位元組為網路號,後三個位元組為主機號。

該類IP地址的最前面為“0”,所以地址的網路號取值於1~126之間。

一般用於大型網路。

B類:(128.0.0.0-191.255.0.0)(預設子網掩碼:255.255.0.0或0xFFFF0000)前兩個位元組為網路號,後兩個位元組為主機號。

該類IP地址的最前面為“10”,所以地址的網路號取值於128~191之間。

一般用於中等規模網路。

C類:(192.0.0.0-223.255.255.0)(子網掩碼:255.255.255.0或0xFFFFFF00)前三個位元組為網路號,最後一個位元組為主機號。

該類IP地址的最前面為“110”,所以地址的網路號取值於192~223之間。

一般用於小型網路。

D類:是多播地址。

該類IP地址的最前面為“1110”,所以地址的網路號取值於224~239之間。

一般用於多路廣播使用者。

E類:是保留地址。

該類IP地址的最前面為“1111”,所以地址的網路號取值於240~255之間。

在IP地址3種主要型別裡,各保留了3個區域作為私有地址,其地址範圍如下: A類地址:10.0.0.0~10.255.255.255 B類地址:172.16.0.0~172.31.255.255 C類地址:192.168.0.0~192.168.255.255 ​ 私有地址:不向特定的使用者分配,被IANA(TheInternetAssignedNumbersAuthority,網際網路數字分配機構)作為私有地址保留。

這些地址可以在任何組織或企業內部使用,和其他Internet地址的區別就是,僅能在內部使用,不能作為全球路由地址。

這就是說,出了組織的管理範圍這些地址就不再有意義,無論是作為源地址,還是目的地址。

對於一個封閉的組織,如果其網路不連線到Internet,就可以使用這些地址而不用向IANA提出申請,而在內部的路由管理和報文傳遞方式與其他網路沒有差異。

回送地址:127.0.0.1。

也是本機地址,等效於localhost或本機IP。

一般用於測試使用。

例如:ping127.0.0.1來測試本機TCP/IP是否正常。

子網劃分: 網路號(NetID)-高位位元 子網號(SubID)-原網路主機號部分位元 主機號(HostID)-低位位元 子網掩碼 形如IP地址 NetID、SubID位全取1 HostID位全取0 A類網路預設子網掩碼:255.0.0.0 B類網路預設子網掩碼:255.255.0.0 C類網路預設子網掩碼:255.255.255.0僅能容納254個主機 將IP分組的目的IP地址與子網掩碼按位與運算,提取子網地址 4.CIDR 無類別域間路由(ClasslessInterDomainRouting) 消除傳統的A、B、C類地址界限 無類地址格式:a.b.c.d/x,其中x為字首長度 提升IPv4地址空間分配效率 5.路由聚合 routeaggregation 路由聚集的目的 簡化路由轉發表的規則,提升路由定址效率 如何進行路由聚集 取消有類地址劃分,NetID+SubID不定長度 需要聚合的子網地址按位取相同的字首作為新的子網地址(超網) 轉發表合併這些子網的轉發規則為新的子網規則,同時保證為非合併前子網地址但滿足條件的地址增加更長的字首匹配規則 什麼情況下可以路由聚集 當多個子網均通過其中某個子網地址來轉發時 總結: 劃分子網的意義 提升IP地址的利用效率 按規則分配IP地址,提升IP地址的辨識度,便於定址,IP地址形成自上而下層次鮮明的結構 對不同地區不同型別的網路裝置加以區分 如何劃分子網 IP地址邏輯上分為NetID+SubID+HostID,NetID+SubID作為網路地址,HostID作為主機號 按有類地址的NetID,SubID從HostID的高bit進行借位(借n位可劃分2^n個等長的子網),組合成網路地址 通過子網掩碼宣告網路地址的bit寬度 定長子網劃分 劃分後的幾個子網,子網掩碼相同 變長子網劃分 根據實際情況,選擇不同長度的網路地址,子網掩碼不一定相同 如何描述子網 子網閘道器描述子網的首地址 子網掩碼描述子網的大小 4.5DHCP協議 動態主機配置協議-DHCP:DynamicHostConfigurationProtocol 特點: 從伺服器動態獲取: IP地址 子網掩碼 預設閘道器 DNS伺服器名稱與IP地址 即插即用 允許地址重用 支援在用地址續租 支援移動使用者加入網路 工作過程 DHCP協議在應用層實現 請求報文封裝到UDP資料包中 IP廣播 鏈路層廣播 DHCP伺服器內建於路由器中 4.6NAT NetworkAddressTranslation網路地址轉換 我們利用埠號的唯一性實現了公網ip轉換為私網ip的這一步。

PAT(NAT過載)能夠使用傳輸層埠號來標識主機,因此,從理論上說,最多可讓大約65000臺主機共用一個公有IP地址 NAT路由器必須: 輸出資料包:將每個輸出資料包的(源IP地址,埠號)替換為(NATIP地址,新埠號) 遠端客戶端/伺服器使用(NATIP地址,新埠號)作為目標地址進行響應 記錄(在NAT轉換表中)每一(源IP地址,埠號)到(NATIP地址,新埠號)轉換配對 輸入資料包:將每個輸入資料包目標欄位中的(NATIP地址,新埠號)替換為儲存在NAT轉換表中相應的(源IP地址,埠號) Q:為什麼需要? A: 只需從ISP申請一個IP地址,有地址耗盡問題 本地網路裝置IP地址的變更,無需通告外界網路 變更ISP時,無需修改內部網路裝置IP地址 內部網路裝置對外界網路不可見,即不可直接定址 引發爭議: 路由器應該只處理第3層功能 違背端到端通訊原則,應用開發人眼要考慮到NAT的存在,例如p2p應用 地址短缺問題應該由IPv6來解決 NAT在實現上將多個內部主機發出的連線複用到一個IP上,這就使依賴IP進行主機跟蹤的機制都失效了。

NAT穿透:如果客戶端想要連線到NAT後的伺服器? 靜態配置NAT(IP地址是一對一的,是一直不變的) 使用UPnP(UniversalPlugandPlay)網際網路閘道器協議(IGD-InternetGatewayDevice)自動配置 中繼 4.7ICMP協議 網際網路控制報文協議-ICMP(InternetControlMessageProtocol) 兩類ICMP報文: 差錯報告報文 目的不可達 源抑制(SourceQuench) 超時/超期,TTL=0 引數問題 重定向(Redirect) 網路探詢報文 回聲Echo請求/應答報文Reply 時間戳請求與應答報文 報文格式 差錯報告報文資料封裝 4.8IPv6協議 動機: 32位地址空間很快將被分配完 資料包格式: 定長40位元組首部 不允許資料包分片 無校驗和(加快路由器的處理,因為TTL的改變而每跳需重新計算) 4.9路由演算法 典型的路由選擇方式有兩種:靜態路由和動態路由。

靜態路由是在路由器中設定的固定的路由表。

除非網路管理員干預,否則靜態路由不會發生變化。

靜態路由不能對網路的改變作出反映. 動態路由是網路中的路由器之間相互通訊,傳遞路由資訊,利用收到的路由資訊更新路由器表的過程。

它能實時地適應網路結構的變化。

如果路由更新資訊表明發生了網路變化,路由選擇軟體就會重新計算路由,併發出新的路由更新資訊。

這些資訊通過各個網路,引起各路由器重新啟動其路由演算法,並更新各自的路由表以動態地反映網路拓撲變化。

動態路由適用於網路規模大、網路拓撲復雜的網路。

當然,各種動態路由協議會不同程度地佔用網路頻寬和CPU資源。

靜態路由和動態路由有各自的特點和適用範圍,因此在網路中動態路由通常作為靜態路由的補充。

當一個分組在路由器中進行尋徑時,路由器首先查詢靜態路由,如果查到則根據相應的靜態路由轉發分組;否則再查詢動態路由。

根據是否在一個自治域內部使用,動態路由協議分為內部閘道器協議(IGP)和外部閘道器協議(EGP)。

這裡的自治域指一個具有統一管理機構、統一路由策略的網路。

自治域內部採用的路由選擇協議稱為內部閘道器協議,常用的有RIP、OSPF;外部閘道器協議主要用於多個自治域之間的路由選擇,常用的是BGP和BGP- 鏈路狀態(LinkState)演算法: Dijkstra演算法 可能有震盪(oscillations) Initailization: N'={u} forallnodesv: ifvadjacenttou thenD(v)=c(u,v) elseD(v)=INF Loop: //可以使用堆來進行加速,在對數時間中找到最小值 findwnotinN'suchthatD(w)isaminimum addwtoN' updateD(v)forallvadjacenttowandnotinN': //此時更新父節點可以構建最短路徑樹 D(v)=min(D(v),D(w)+c(w,v)) untilallnodesinN' 距離向量(DistanceVector)演算法 Bellman-Ford方程動態規劃 當節點x發現他的直接相連的鏈路開銷變化或從某個鄰居收到一個距離向量的更新時,他就更新其距離向量估計值 結點獲得最短路徑的下一跳,該資訊用於轉發表中 好訊息傳播快 壞訊息傳播慢 可能出現無窮計數問題(counttoinfinity):路由選擇環路(routingloop),y即為了到達x,通過z路由,z又通過y路由到達x(因為此時距離最短) 使用毒性逆轉(poisonedreverse)/反向下毒:如果一個節點到達目的的最小費用路徑是通過某個鄰居,則通告給該鄰居到達該目的的距離為無窮大,直到路徑不通過該鄰居 注意:涉及3個或更多節點,而不是兩個直接相連的鄰居節點的環路將無法用毒性逆轉技術檢測到 定義最大度量 4.10Internet路由 AS(Autonomoussystem):自治系統,指在一個(有時是多個)組織管轄下的所有IP網路和路由器的全體,它們對網際網路執行共同的路由策略。

也就是說,對於網際網路來說,一個AS是一個獨立的整體網路。

而BGP實現的網路自治也是指各個AS自治。

每個AS有自己唯一的編號。

在相同AS中的路由器都執行相同的路由選擇演算法並且有彼此的資訊。

在一個自治系統內執行的路由選擇演算法叫做自治系統內部路由選擇協議 IGP(InteriorGatewayProtocol):內部閘道器協議,在一個AS內部所使用的一種路由協議。

一個AS內部也可以有多個路由器管理多個網路。

各個路由器之間需要路由資訊以知道子網路的可達資訊。

IGP就是用來管理這些路由。

代表的實現有RIP(RoutingInformationProtocol)、OSPF(OpenShortestPathFirst)、IGRP(內部閘道器路由協議)。

EGP(ExteriorGatewayProtocol):外部閘道器協議,在多個AS之間使用的一種路由協議,現在已經淘汰,被BGP取而代之。

1.RIP協議 路由資訊協議(RoutingInformationProtocol) 2.OSPF OpenShortestPathFirst 安全 採用鏈路狀態演算法-Dijkstra 允許使用多條相同費用的路徑(RIP只能選一條) 對於每條鏈路,可以針對不同的TOS(Termsofservice)設定多個不同的費用度量 整合單播路由與多播路由 OSPF比RIP強大的地方是,OSPF對整網的拓撲結構瞭如指掌,一旦某一條路徑斷了,可以及時選擇備份鏈路,對通訊的影響小。

RIP是基於謠言,對整網的拓撲結構沒有概念,只知道有幾個鄰居,至於更遠的鄰居是什麼樣子,對不起,不知道! IS-IS(intermediatesystemtointermediatesystem)與OSPF近乎相同[IS-IS為第二層協議,OSPF為第三層協議] 3.BGP協議 BorderGatewayProtocol:事實上的域間路由協議 在BGP中,分組並不是路由到一個特定的目的地址,相反是路由到CIDR化的字首,其中每一個字首表示一個子網或子網的集合,一臺路由器的轉發表將具有形式為(x,I)的表項,其中x是一個字首(例如138.16.68/22),I是該路由器的介面之一的介面號 eBGP:從鄰居AS獲取子網可達性資訊 iBGP:將可達性資訊傳播給所有AS內部路由器 每條BGP路由包含3個元件:NEXT-HOP;ASPATH;目的字首 熱土豆演算法:對於路由器,儘可能快的將分組送出其AS(更明確地說,用可能的最低開銷),而不擔心其AS外部到目的地的餘下部分的開銷,是一種自私的演算法 路由選擇策略(由上至下執行): 路由被指定一個本地偏好值作為其屬性之一 從餘下路由中選擇有最短AS-PATH的路由 從餘下路由中用熱土豆路由選擇 最後使用BGP識別符號選擇 ISP遵循的經驗法則:任何穿越某ISP主幹網的流量必須是其源或目的(或兩者)位於該ISP的某個客戶網路中 4.11SDN控制平面 softwaredefinenetwork 遠端控制器計算和分發轉發表以供每臺路由器使用,因為計算轉發表並與路由器互動的控制器是用軟體實現的,故網路是“軟體定義”的 強化控制平面:可靠、可信、效能可擴充套件、安全的分散式系統 故障魯棒性:控制平面的可靠分佈系統的強壯理論發揮的作用 4.12網路管理與SNMP SNMP(SimpleNetworkManagementProtocol) PDU(ProtocolDataUnit) 5.資料鏈路層 鏈路層的豬蹄部分是在網路介面卡Networkadapter中實現的,也被稱為網路介面卡(NetworkInterfaceCard,NIC)。

位於網路介面卡核心的是鏈路層控制器,該控制器通常是一個實現了許多鏈路層服務(成幀、鏈路接入、差錯檢測等) 概述: 主機和路由器:結點(nodes) 連線相鄰結點的通訊通道:鏈路(links) 資料分組:幀(frame) 提供服務: 成幀 鏈路接入 可靠交付 差錯檢測和糾正 5.1差錯檢測和糾正位元 Error-Detectionand-Correction,EDC 漢明距離:兩個等長字串之間的漢明距離是兩個字串對應位置的不同字元的個數 檢錯碼與糾錯碼: 1.奇偶校驗碼 paritycheck 採用何種校驗是事先規定好的。

通常專門設定一個奇偶校驗位,用它使這組程式碼中“1”的個數為奇數或偶數。

若用奇校驗,則當接收端收到這組程式碼時,校驗“1”的個數是否為奇數,從而確定傳輸程式碼的正確性;偶校驗則檢測是否為偶數。

1位元校驗位 檢測奇數位差錯 二維奇偶校驗 檢測奇數位差錯、部分偶數位差錯 糾正同一行/列的奇數位數 2.Internet校驗和 計算checksum 3.迴圈冗餘校驗碼 CyclicRedundancyCheck,CRC 有限代數理論(Galois域) 考慮d位元的資料D,傳送節點要將它傳送給接收節點。

傳送方和接受方首先必須協商一個r+1位元模式,稱為生成多項式G,要求G的最高有效位的位元為1.對於一個給定的資料段D,傳送發要選擇r個附加位元R,並將它們附加到D上,使得得到的d+r位元模式用模2算數恰好能被G整除。

接受方用G去除收到的d+r位元。

【說明】“模2除法”與“算術除法”類似,但它既不向上位借位,也不比較除數和被除數的相同位數值的大小,只要以相同位數進行相除即可。

模2加法運算為:1+1=0,0+1=1,0+0=0,無進位,也無借位;模2減法運算為:1-1=0,0-1=1,1-0=1,0-0=0,也無進位,無借位。

相當於二進位制中的邏輯異或運算。

也就是比較後,兩者對應位相同則結果為“0”,不同則結果為“1”。

如100101除以1110,結果得到商為11,餘數為1,如11×11=101 編碼簡單、效能優良 5.2多路訪問控制(MAC)協議 MultipleAccessControlProtocol 採用分散式演算法決定結點如何共享通道,即決策結點何時可以傳輸資料 MAC協議分類: 通道劃分 將通道劃分為小的“片段” 將片段分配給節點獨佔使用 隨機接入 不分割通道,允許衝突/碰撞 衝突後恢復 輪流 節點輪流傳送,但傳送多的節點可以輪流傳送更長的時間 1.通道劃分(channelpartitioning)MAC協議 多路複用技術 TDMA:timedivisionmultipleaccess分時多重進接 FDMA:frequencydivisionmultipleaccess分頻多工 CDMA:codedivisionmultipleaccess分碼多重進接 WDMA 2.隨機訪問(randomaccess)MAC協議 通道不劃分,允許衝突 採用衝突、恢復機制 有碰撞時,涉及碰撞的每個節點反覆地重發它的幀,直到該幀無障礙通過 時隙(sloted)ALOHA 時鐘同步 碰撞時以概率p選擇是否重傳 效率極限為37% ALOHA協議 無時鐘同步,純分散協議 比時隙ALOHA協議更差(為其一半),更簡單 CSMA載波監聽多路訪問協議(carriersensemultipleaccess) 傳送幀之前,監聽通道 由於訊號傳播延遲,可能仍有衝突 繼續傳送衝突幀,浪費通道資源 CSMA/CD(withCollisionDetection)協議 短時間內可以檢測到衝突 衝突後傳輸中止,減少通道浪費 中止後進入二進(指數)退避 $L_{min}/R=2d_{max}/V$網路頻寬R資料幀長度L訊號傳播速度V兩個站點之間的距離d 效能遠由於ALOHA協議 乙太網 3.輪轉(takingturns)MAC協議 結點輪流使用通道 藍芽 輪詢(polling) 主結點輪流邀請從屬結點傳送資料 令牌傳遞(tokenpassing) 控制令牌一次從一個結點傳遞到下一個結點 令牌-特殊幀 5.3ARP協議 AddressResolutionProtocol 1.MAC地址 或稱LAN地址,實體地址,乙太網地址 48位MAC地址,固化在網路卡的ROM中,有時也可以軟體設定 e.g:1A-2B-3C-34-AD-00 由IEEE統一管理與分配 2.地址解析協議 ARP表:LAN中的每個IP結點(主機、路由器)維護一個表 一臺路由器對它的每個介面都有一個IP地址。

對路由器的每個介面,也有一個ARP模組和一個介面卡。

查詢ARP報文是在廣播幀中傳送的,而響應ARP報文在一個標準幀中傳送 儲存某些LAN結點的IP/MAC地址對映關係: 5.4乙太網 物理拓撲 匯流排(bus) 所有結點在同一衝突域(collisiondomain) 星形(star) CSMA/CD演算法 檢測到衝突後進入二進位制指數退避 連續衝突次數越多,平均等待時間越長 乙太網幀結構 交換機 自學習、泛洪構建轉發表,依據MAC地址 過濾:決定轉發一個幀還是丟棄該幀 轉發:決定一個幀被導向哪個介面 特點: 消除碰撞 異質的鏈路,不同鏈路有不同速率且執行在不同媒體上 管理 交換機與路由器的區別: 交換機是二層的分組交換機,即插即用,有較高的分組過濾和轉發速率 路由器是三層的分組交換機,使用路由演算法和IP地址註冊轉發表 VLANs virtuallocalareanetwork 流量隔離(trafficisolation) 動態成員 在VLAN中轉發:通過路由(就像在獨立的交換機之間) 幹線埠-擴充套件乙太網幀格式802.1Q 多協議標籤交換 MultiprotocolLabelSwitching,MPLS 固定長度標籤 相關文章 計算機網路基礎知識總結 2020-12-27 計算機網路 關於計算機網路的Wireshark實驗 2020-12-26 計算機網路 計算機網路實驗報告:【Wirshark實驗】 2020-12-26 計算機網路 計算機網路實驗三——CiscoPacketTracer實驗 2020-12-26 計算機網路 計算機網路實驗二 2020-12-26 計算機網路 計算機網路實驗三 2020-12-26 計算機網路 計算機網路的CiscoPacketTracer實驗 2020-12-26 計算機網路 計算機網路實驗:【CiscoPacketTracer實驗】 2020-12-26 計算機網路 計算機網路整理筆記01 2020-12-28 計算機網路 程式設計必備基礎計算機組成原理+作業系統+計算機網路,計算機基礎——更適合程式設計師的程式設計必備基礎知識 2020-12-29 計算機網路程式設計師 關於VMware:“無法將網路更改為橋接狀態:沒有未橋接的主機網路介面卡”的問題 2020-12-31 計算機網路考點整理 2021-01-02 計算機網路 計算機網路-應用層筆記 2021-01-02 計算機網路 [計算機網路期末複習_例題]有限頻寬、有熱噪聲通道的最大資料傳輸速率(夏農定理) 2021-01-03 計算機網路 我畫了40張圖就是為了讓你搞懂計算機網路層 2021-01-04 計算機網路 計算機網路由哪些硬體裝置組成? 2021-01-05 計算機網路 計算機網路的七層結構、五層結構和四層結構 2021-02-11 計算機網路 計算機網路自學指南,簡直太全了! 2021-02-19 計算機網路 小白計算機網路學習筆記(更新中) 2021-02-22 計算機網路 最新文章 C/C++大型工程工具鏈搭建 一張證書引發的噱案 屹立於技術之巔的4門語言創造者—AndersHejlsberg bdtf蘋果145元拋光布補貨,已再次開放購買 ieyb日產汽車在福島開展運用AI技術為電動車充電的試驗 vsjb餓了麼計劃今年在全國覆蓋十萬頂智慧頭盔 rsvo鵬博士釋出雲端計算戰略2.0,推出融合雲平臺 pmeu騰訊入股深度智控,後者提供深度節能與物聯智控解決方案 gcdn京東服務+啟動“春節不打烊”,用好服務陪你過好年 二進位制部署1.23.4版本k8s叢集-2-安裝DNS服務 tep完整教程幫你突破pytest 搜尋排序技術簡介



請為這篇文章評分?