阿偉在學完了《計算機網絡:自頂向下的辦法》以及《TCP/IP詳解:卷一協議(原書第二版)》感覺學的還不是特別好,感覺做題的時候,我簡直人都傻了,寫個文章、用表格的形式、做題目的形式對計算機網絡比較常見的一些知識點進行總結,希望在****自己成長的同時,可以幫助到有需要的人。
該文章是看了超級多的知乎專欄、CSDN文章等做的總結。題目來源以及題目後面所附代的參考文章的具體網址,會放在另外一個文章裏面,以此來節省篇幅。
以上兩本書私聊可以給電子書。
計算機網絡知識點總結
- 1. OSI體系結構(七層)、TCP/IP體系結構(四層)、五層協議的體系結構,以及各層協議意義
- 2. 計算機網絡系統
- 3. 計算機網絡的拓撲(tuò pū)結構
- 4. 單工、半雙工以及全雙工之間的區別
- 5. 中繼器、集線器、網橋、交換機、路由器、網關
- 6. 各種亂七八糟的網絡
- 7. 常見端口以及服務
- 8. IP數據包頭部結構
- 9. IPv4地址分類
- 10. 組播、單播、任播、廣播
- 11.通過IP地址和子網掩碼計算網絡號(這個是重點,這裏介紹一個簡便的計算方法)
- 12. 爲了TCP/IP協議正常使用的工具人協議
- 12.1 IPv4中的地址解析協議(ARP,Address Resolution Protocol)以及IPv6的NDP(鄰居發現協議)
- 12.2 IPv6中的鄰居發現協議——鄰居發現協議(Neighbor Discovery Protocol,**NDP**)
- 12.3 反向地址轉換協議(RARP,Reverse Address Resolution Protocol)
- 12.4 Internet控制報文協議(Intemet Control Message Protocol, ICMP)
- 12.5 DHCP協議詳解——TCP/IP協議的配置信息
- 12.6 組織對不起,90年的事我瞞不住了——NAT(網絡地址轉換)
- 12.7 DNS協議(wireshark進行分析,圖示遞歸查詢及迭代查詢)
- 12.8 TFTP(Trivial File Transfer Protocol,簡單文件傳輸協議)
- 12.9 HTTP協議——具體講解第二個真的很nice,建議去看一下
- 12.10 總結
- 13. UDP協議解釋、TCP和UDP之間的區別
- 14. TCP首部報文結構
- 15. TCP的三次握手以及四次揮手
- 15.1 爲什麼客戶端最後還要等待2MSL?(CSDN博主 小書go)
- 15.2 如果已經建立了連接,但是客戶端突然出現故障了怎麼辦?(CSDN博主 小書go)
- 15.3 爲什麼不能用兩次握手進行連接?(CSDN博主 青柚_)
- 15.4 如果已經建立了連接,但是客戶端突然出現故障了怎麼辦?(CSDN博主 青柚_)
- 15.5 爲什麼關閉連接要設計成四次?(低端叫獸)
- 15.6 服務端運行一段時間後,套接字出現了大量的Close_Wait狀態,最有可能是什麼原因導致的?(低端叫獸)
- 15.7 爲什麼基於TCP的程序往往都有個應用層的心跳檢測機制?(低端叫獸)
- 15.8 服務端的Time_Wait狀態再哪個階段出現?持續多久?爲什麼要設計這麼一個狀態?(低端叫獸)
- 16. TCP滑動窗口與擁塞機制
- 17 比較nice的題目收集,內附答案,侵權立刪
- 17.1 請簡述TCP\UDP的區別(知乎:路人甲)
- 17.2 請簡單說一下你瞭解的端口及對應的服務?
- 17.3 說一說TCP的三次握手
- 17.4 說一說TCP的四次揮手
- 17.5 有哪些私有(保留)地址?
- 17.6 IP地址分爲哪幾類?簡單說一下各個分類
- 17.7 在瀏覽器中輸入網址之後執行會發生什麼?
- 17.8 簡單解釋一些ARP協議的工作過程
- 17.9 說一說OSI七層模型
- 17.10 說一說TCP/IP四層模型
- 17.11 HTTP 協議包括哪些請求?
- 17.12 簡述HTTP中GET和POST的區別
- 17.13 TCP/UDP裏面什麼是面向連接,什麼是面向無連接?([Object object])
- 17.14 TCP 爲什麼是可靠連接
- 17.15 (TCP三次握手)爲什麼客戶端最後還要等待2MSL?(CSDN博主 小書go)
- 17.16(TCP三次握手) 如果已經建立了連接,但是客戶端突然出現故障了怎麼辦?
- 17.17(TCP三次握手) 爲什麼不能用兩次握手進行連接?(CSDN博主 青柚_)
- 17.18 (TCP三次握手) 如果已經建立了連接,但是客戶端突然出現故障了怎麼辦?
- 17.19 (TCP三次握手)爲什麼關閉連接要設計成四次?(低端叫獸)
- 17.20 (TCP三次握手) 服務端運行一段時間後,套接字出現了大量的Close_Wait狀態,最有可能是什麼原因導致的?
- 17.21 (TCP三次握手) 爲什麼基於TCP的程序往往都有個應用層的心跳檢測機制?
- 17.22 (TCP三次握手) 服務端的Time_Wait狀態再哪個階段出現?持續多久?爲什麼要設計這麼一個狀態?
- 17.23 (C類子網劃分子網劃分的計算)(逃離地球的小小呆)題目一
- 17.24 子網劃分的題目 2
- 17.25 子網劃分的題目 3
- 17.26 子網劃分的題目 4
- 17.27 子網劃分的題目 5
- 17.28 已知IP地址和子網掩碼求子網劃分 1
- 17.29 已知IP地址和子網掩碼求子網劃分 2
- 17.30 已知IP地址和子網掩碼求子網劃分 3
- 17.31B類地址 已知網絡地址和子網掩碼求子網劃分 1
- 17.32 已知網絡地址和子網掩碼求子網劃分 2
- 17.33 已知ip地址和子網掩碼求子網劃分
- 17.34 A類子網劃分實例 已知網絡地址和子網掩碼求子網劃分 1
- 17.35 已知ip地址和子網掩碼求子網劃分
- 17.36 (sHuXnHs)TCP的擁塞控制機制是什麼?請簡單說說。
- 17.37 (知乎:何柄融)題目 一
- 17.38 試從多個方面比較電路交換、報文交換和分組交換的主要優缺點。
- 17.39 協議與服務有何區別?有何關係?
- 17.40 假定某信道受奈氏準則限制的最高碼元速率爲20000碼元/秒。如果採用振幅調製,把碼元的振幅劃分爲16個不同等級來傳送,那麼可以獲得多高的數據率(b/s)?
- 17.41 試說明IP地址與硬件地址的區別,爲什麼要使用這兩種不同的地址?
- 17.42 某單位分配到一個B類IP地址,其net-id爲129.250.0.0.該單位有4000臺機器,分佈在16個不同的地點。如選用子網掩碼爲255.255.255.0,試給每一個地點分配一個子網掩碼號,並算出每個地點主機號碼的最小值和最大值
- 17.43 設TCP的ssthresh的初始值爲8(單位爲報文段)。當擁塞窗口上升到12時網絡發生了超時,TCP使用慢開始和擁塞避免。試分別求出第1次到第15次傳輸的各擁塞窗口大小。你能說明擁塞控制窗口每一次變化的原因嗎?
- 17.44 我也想在搞多一個問題,但是差不多就算了,在多就買本考研試題吧
- 18. 參考資料:
1. OSI體系結構(七層)、TCP/IP體系結構(四層)、五層協議的體系結構,以及各層協議意義
其實常用的還是TCP/IP協議
層的名字 | 層的協議 | 層的作用 |
---|---|---|
物理層 | RJ45、CLOCK、IEEE802.3 (中繼器,集線器,網關) | 通過媒介傳輸比特,確定機械及電氣規範(比特Bi) |
數據鏈路層 | PPP、FR、HDLC、VLAN、MAC (網橋,交換機) | 將比特組裝成幀和點到點的傳遞(幀Frame) |
網絡層 | IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 (路由器)) | 負責數據包從源到宿的傳遞和網際互連(包PackeT) |
傳輸層 | TCP、UDP、SPX | 提供端到端的可靠報文傳遞和錯誤恢復(段Segment) |
會話層 | NFS、SQL、NETBIOS、RPC | 建立、管理和終止會話(會話協議數據單元SPDU) |
表示層 | JPEG、MPEG、ASII | 對數據進行翻譯、加密和壓縮(表示協議數據單元PPDU) |
應用層 | FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS | 允許訪問OSI環境的手段(應用協議數據單元APDU) |
2. 計算機網絡系統
計算機網絡的定義:計算機網絡系統就是利用通信設備和線路將地理位置不同、功能獨立的多個計算機系統互聯起來,以功能完善的網絡軟件實現網絡中資源共享和信息傳遞的系統。通過計算機的互聯,實現計算機之間的通信,從而實現計算機系統之間的信息、軟件和設備資源的共享以及協同工作等功能,其本質特徵在於提供計算機之間的各類資源的高度共享,實現便捷地交流信息和交換思想。
題目:
1、在計算機網絡的定義中,一個計算機網絡包含多臺具有_自主_____功能的計算機;把衆多計算機有機連接起來要遵循規定的約定和規則,即_通信協議______;計算機網絡的最基本特徵是__資源共享_______。
3. 計算機網絡的拓撲(tuò pū)結構
具體講解:
CSDN博主翟羽嚄的《網絡拓撲結構》,網址:https://blog.csdn.net/mao_hui_fei/article/details/82928163
結構名稱 | 連接方式 | 優點 | 缺點 |
---|---|---|---|
總線型拓撲結構 | 所有的結點共享一條數據通道 | 連接形式簡單,易於實現,所用線纜最短,增加或者移除結點比較靈活,個別結點發生故障時,不影響網絡中其他結點的正常工作 | 網絡傳輸能力低,安全性低,總線發生故障時,會導致全網癱瘓。結點數量的增多會影響網絡性能。 |
星形拓撲結構(應用最普遍) | 以一個結點爲中心的處理系統 | 結構簡單,建網容易,控制簡單,維護容易,網絡傳輸速度快。 | 屬於集中控制。主機負載過重,可靠性低,通信線路利用率低。安全隱患大。 |
環形拓撲結構 | 通信線路連接成一個閉合的環 | 一次通信的最大傳輸延遲是固定的,每個網上結點只與其他二個結點有物理鏈路直接互連。傳輸控制機制簡單,實時性強。 | 一個結點發生故障時,可能導致全網癱瘓,可靠性差。維護困難,擴展性能差 |
混合型拓撲結構 | 由星形結構和總線型結構結合的網絡結構。 | 解決了星形網絡在傳輸距離上的侷限,同時又解決了總線型網絡在連接用戶數量上的限制。 |
4. 單工、半雙工以及全雙工之間的區別
- 單工數據傳輸只支持數據在一個方向上傳輸;在同一時間只有一方能接受或發送信息,不能實現雙向通信,舉例:電視,廣播。
- 半雙工數據傳輸允許數據在兩個方向上傳輸,但是,在某一時刻,只允許數據在一個方向上傳輸,它實際上是一種切換方向的單工通信;在同一時間只可以有一方接受或發送信息,可以實現雙向通信。舉例:對講機。
- 全雙工數據通信允許數據同時在兩個方向上傳輸,因此,全雙工通信是兩個單工通信方式的結合,它要求發送設備和接收設備都有獨立的接收和發送能力;在同一時間可以同時接受和發送信息,實現雙向通信,舉例:電話通信。
參考了:
CSDN博主一隻笨鳥的裝載文章《單工、半雙工及全雙工之間的區別》,網址:https://blog.csdn.net/komtao520/article/details/88084984?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1
5. 中繼器、集線器、網橋、交換機、路由器、網關
計算機網絡的物理設備,這幾個東西我感覺都可以在水多一萬字。
來源於:超級課程表哥
具體講解:
CSDN博主超級課程表哥的《中繼器、集線器、網橋、交換機、路由器、網關的超全總結》,網址:https://blog.csdn.net/qq_25606103/article/details/51288459?utm_medium=distribute.pc_relevant.none-task-blog-OPENSEARCH-9&depth_1-utm_source=distribute.pc_relevant.none-task-blog-OPENSEARCH-9
設備名稱 | 作用 |
---|---|
中繼器(Repeater) | 簡單的信號放大器,信號在傳輸的過程中是要衰減的,中繼器的作用就是將信號放大,使信號能傳的更遠。 |
集線器(Hub) | 差不多就是個多端口的中繼器,把每個輸入端口的信號放大再發到別的端口去,集線器可以實現多臺計算機之間的互聯,因爲它有很多的端口,每個口都能連計算機。 |
網橋(Bridge) | 網橋工作在數據鏈路層,將兩個LAN連起來,根據MAC地址來轉發幀,可以看作一個“低層的路由器”。 |
交換機(Swich) | 可以理解爲高級的網橋,他有網橋的功能,但性能比網橋強。交換機和網橋的細微差別就在於:交換機常常用來連接獨立的計算機,而網橋連接的目標是LAN,所以交換機的端口較網橋多。 |
路由器(Router) | 爲經過路由器的每個IP數據包尋找一條最佳傳輸路徑,並將該數據有效地傳送到目的站點。 路由器的基本功能是,把數據(IP報文)傳送到正確的網絡。 |
網關(Gateway) | 通過字面意思解釋就是網絡的關口。從技術角度來解釋,就是連接兩個不同網絡的接口,比如局域網的共享上網服務器就是局域網和廣域網的接口。 |
6. 各種亂七八糟的網絡
以太網、互聯網、萬維網、因特網、城域網/廣域網/局域網,👴在三個月前寫過(現在2020.5.03)所以不想重複多寫,可以看我的這個文章。
《以太網、互聯網、萬維網、因特網、城域網/廣域網/局域網的區別》,網址:https://blog.csdn.net/qq_45877524/article/details/104938347
7. 常見端口以及服務
應用程序 | 默認端口號 |
---|---|
HTTP | 80/8080/3128/8081/9098 |
SOCKS | 1080 |
FTP(文件傳輸)協議 | 21 |
Telnet(遠程登錄) | 21 |
HTTP服務器 | 80/tcp(木馬Executor開放此端口) |
HTTPS(securely transferring web pages)服務器 | 443/tcp 443/udp |
Telnet(不安全的文本傳送) | 23/tcp(木馬Tiny Telnet Server所開放的端口) |
TFTP(Trivial File Transfer Protocol) | 69/udp |
FTP | 21/tcp(木馬Doly Trojan、Fore、Invisible FTP、WebEx、WinCrash和Blade Runner所開放的端口) |
SSH(安全登錄)、SCP(文件傳輸)、端口號重定向 | 22/tcp |
SMTP Simple Mail Transfer Protocol(E-mail) | 25/tcp(木馬Antigen、Email Password Sender、Haebu Coceda、Shtrilitz Stealth、WinPC、WinSpy都開放這個端口) |
POP3 Post Office Protocol(E-mail) | 110/tcp |
Webshpere應用程序 | 9080 |
webshpere管理工具 | 9090 |
JBOSS | 8080 |
TOMCAT | 8080 (這裏沒有出錯,建議百度一下) |
WIN2003遠程登錄 | 3389 |
Symantec AV/Filter for MSE | 8081 |
Oracle 數據庫 | 1521 |
ORACLE EMCTL | 1158 |
Oracle XDB(XML 數據庫) | 8080 |
Oracle XDB FTP服務 | 2100 |
MS SQL*SERVER數據庫server | 1433/tcp 1433/udp |
MS SQL*SERVER數據庫monitor | 1434/tcp 1434/udp |
8. IP數據包頭部結構
具體講解可以看我的文章:《IPv4和IPv6的數據報結構頭部詳解》,網址:https://blog.csdn.net/qq_45877524/article/details/105003498
9. IPv4地址分類
在這裏我吐槽一下,都要進入IPv6時代了,還一直瘋狂考着IPv4即將淘汰的東西。
列出一個表格方便記憶每一個類
類 | 地址範圍 | 高序位 | 用途 | 百分比 |
---|---|---|---|---|
A | 0.0.0.0 - 127.255.255.255 | 0 | 單播/特殊 | 1/2 |
B | 128.0.0.0 - 191.255.255.255 | 10 | 單播/特殊 | 1/4 |
C | 192.0.0.0 - 223.255.255.255 | 110 | 單播/特殊 | 1/4 |
D | 224.0.0.0 - 239.255.255.255 | 1110 | 組播 | 1/16 |
E | 240.0.0.0 - 255.255.255.255 | 1111 | 保留 | 1/16 |
這個百分比我算過等於一不用算的啊。
非常非常具體的講解可以看這個文章:CSDN博主Yngz_Miao的博文《【TCP/IP】IP地址分類和特殊IP地址》,網址:https://blog.csdn.net/qq_38410730/article/details/80980749
10. 組播、單播、任播、廣播
其實這個知識點的回顧,應該是要放在前面一點的,但是考慮到IPv4地址分類那裏開了個頭,就順着回顧下去吧。
具體講解可以看我的裝載!!!!文章:《多播(組播)、單播、任播和廣播》,網址:https://blog.csdn.net/qq_45877524/article/details/105481577
這四個播都是數據封包在計算機網絡的傳輸方式,這裏大概的講一下方式。
名稱 | 傳輸方式 | 話糙理不糙的比方 |
---|---|---|
單播 | 每次只有兩個實體相互通信,發送端和接收端都是唯一確定的 | 對抗路孤兒路,兩個孤兒一對一單挑 |
組播 | 將數據在同一時間以高效的方式發往處於TCP/IP網絡上的多個接收者 | 葉師傅:我要一個打十個 |
廣播 | 主機之間一對所有的通訊模式 | 不是我針對誰,而是在座的各位都是垃圾 |
任播 | 每一個位址對應一羣接收節點,但在任何給定時間,只有其中之一可以接收到傳送端來的資訊 | 一打五時,敵方葫蘆娃救爺爺 |
這裏不太嚴謹,具體還是看我裝載的文章,我轉載文章是將三個人的內容結合在一起,原文是有一些問題的,我改正了,並且加以說明。
11.通過IP地址和子網掩碼計算網絡號(這個是重點,這裏介紹一個簡便的計算方法)
這個東西,我之前確實想寫一篇文章來詳細講一下的,但是準備要上學了,所以就沒有動筆,我列出之前收集到的文章鏈接(加粗的是非常nice的可以說是一下子就能夠看懂的):
- CSDN博主here962464的《已知IP地址,如何計算其子網掩碼,默認網關地址,網絡地址等》,網址:https://blog.csdn.net/here962464/article/details/78940056?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task
- CSDN博主小宇飛刀的《通過IP地址和子網掩碼,如何計算出網絡地址、廣播地址和主機數?》,網址:
https://blog.csdn.net/xieyunc/article/details/84866414?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task - CSDN博主Mr_Faker的《子網掩碼詳解》,網址:
https://blog.csdn.net/faker_wang/article/details/80747407 - CSDN博主逃離地球的小小呆的《子網劃分詳解與子網劃分實例精析》,網址:https://blog.csdn.net/gui951753/article/details/79412524
- 知乎用戶 阿卡 對問題《子網劃分總是學不會怎麼辦?》
的回答,網址:https://www.zhihu.com/question/53456814/answer/135058621 - 知乎用戶 MissCatty 的《IP地址、子網掩碼和網絡號的計算》,網址:https://zhuanlan.zhihu.com/p/32361762
11.1 比較傳統的靠譜的計算方法——十進制轉二進制在轉爲十進制
這種計算方法是比較傳統的計算方法,也是教科書上的方法比較慢,但是很實在。這也是CSDN博主小宇飛刀重點講述的方法。
11.2 知乎上看到的簡化方法——比較取巧
這個東西親測有效,但是不知道會不會出現特殊的情況導致這種方法出現錯誤,歡迎在評論區提出,順帶讓我學習一下
11.3 子網掩碼的訓練
我聽說很多計算機專業的計算機網絡期末考試都會考一道子網掩碼的大題,我建議通過這個文章進行訓練。(我化工專業的)。
CSDN博主逃離地球的小小呆的《子網劃分詳解與子網劃分實例精析》,網址:https://blog.csdn.net/gui951753/article/details/79412524
大佬nb
12. 爲了TCP/IP協議正常使用的工具人協議
這八個協議就是一幫工具人協議,簡直就是中路法師——王者大舞臺,缺錢你就來
Internet控制報文協議(Intemet Control Message Protocol, ICMP)、網絡地址轉換協議(Network Addresss Translation、NAT)、動態主機配置協議(Dynamic Host Configuration Protocol、DHCP)、地址解析協議(Address Resolution Protocol、ARP)、反向地址轉換協議(RARP:Reverse Address Resolution Protocol) 、TFTP(Trivial File Transfer Protocol,簡單文件傳輸協議)、HTTP協議(HyperText Transfer Protocol,超文本傳輸協議)、DNS協議(Domain Name System,地址解析協議)、鄰居發現協議(Neighbor Discovery Protocol,NDP)
這些協議都是非常煩的東西,我感覺就靠這些協議我都可以水多五十個文章,所以這裏只是比較水的說一下,具體講解可以看我附帶的鏈接。
網絡上大多數關於計算機網絡的複習資料裏面都會有這段話,但是我在書上並沒有找到最下面那個DHCP協議的具體講解,同時網上也沒有找到,所以我這裏懷疑不知道是哪裏的源頭出錯了,應該是和上面的那個DHCP協議——動態主機配置協議(Dynamic Host Configuration Protocol、DHCP),進行了重複,我提出意見。
歡迎大佬指出。
12.1 IPv4中的地址解析協議(ARP,Address Resolution Protocol)以及IPv6的NDP(鄰居發現協議)
非常具體的講解,可以看這兩個人的文章:
- CSDN博主HankingHu的《計算機網絡–ARP地址解析協議詳解》,網址:https://blog.csdn.net/u013309870/article/details/77427112
- CSDN博主gffsky1990的《地址解析協議(ARP)的學習(通過wireshark抓包分析)》,網址:https://blog.csdn.net/u010442328/article/details/45419019?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-14&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-14
地址解析協議(Address Resolution Protocol),其基本功能爲透過目標設備的IP地址,查詢目標設備的MAC地址,以保證通信的順利進行。它是IPv4中網絡層必不可少的協議,不過在IPv6中已不再適用,並被鄰居發現協議(NDP)所替代。
來源:CSDN博主HankingHu
主要工作原理:
- 首先,每個主機都會在自己的ARP緩衝區中建立一個ARP列表,以表示IP地址和MAC地址之間的對應關係。
- 當源主機要發送數據時,首先檢查ARP列表中是否有對應IP地址的目的主機的MAC地址,如果有,則直接發送數據,如果沒有,就向本網段的所有主機發送ARP數據包,該數據包包括的內容有:源主機 IP地址,源主機MAC地址,目的主機的IP 地址。
- 當本網絡的所有主機收到該ARP數據包時,首先檢查數據包中的IP地址是否是自己的IP地址,如果不是,則忽略該數據包,如果是,則首先從數據包中取出源主機的IP和MAC地址寫入到ARP列表中,如果已經存在,則覆蓋,然後將自己的MAC地址寫入ARP響應包中,告訴源主機自己是它想要找的MAC地址。
- 源主機收到ARP響應包後。將目的主機的IP和MAC地址寫入ARP列表,並利用此信息發送數據。如果源主機一直沒有收到ARP響應數據包,表示ARP查詢失敗。
廣播發送ARP請求,單播發送ARP響應
12.2 IPv6中的鄰居發現協議——鄰居發現協議(Neighbor Discovery Protocol,NDP)
鄰居發現協議NDP(Neighbor Discovery Protocol)是TCP/IP協議棧的一部分,主要與IPv6共同使用。它工作在網絡層,負責在鏈路上發現其他節點和相應的地址,並確定可用路由和維護關於可用路徑和其他活動節點的信息可達性。
具體講解:
- CSDN博主曹世宏的博客的《IPv6鄰居發現協議》,網址:https://blog.csdn.net/qq_38265137/article/details/80466128?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1
- CSDN博主santt的《IPV6 鄰居發現協議(NDP)》,網址:https://blog.csdn.net/santtde/article/details/84028248
12.3 反向地址轉換協議(RARP,Reverse Address Resolution Protocol)
講真,我發現這個協議講的最清晰的居然是360百科,這波操作我人都傻了。
反向地址轉換協議(RARP:Reverse Address Resolution Protocol) 允許局域網的物理機器從網關服務器的 ARP 表或者緩存上請求其 IP 地址。
具體講解:
- CSDN博主santt的《IPV6 鄰居發現協議(NDP)》,網址:https://blog.csdn.net/santtde/article/details/84028248
- 360百科《rarap》,網址:https://baike.so.com/doc/6746820-6961366.html
12.4 Internet控制報文協議(Intemet Control Message Protocol, ICMP)
Internet控制報文協議(Intemet Control Message Protocol, ICMP)是IP協議的一種補充,它與IP協議結合使用,以便提供與IP協議層配置和IP數據包處理相關的診斷和控制信息(IP協議本身並沒有爲終端系統提供直接的方法來發現那些發往目的地址失敗的IP數據包,也沒有提供直接的方式來獲取診斷信息。)
ICMP通常被認爲是IP層的一部分,它需要在所有IP實現中存在。它使用IP協議進行傳輸。因此,確切地說,它既不是一個網絡層協議,也不是一個傳輸層協議,而是位於兩者之間。(這一點和大多數CSDN博主的不太一樣,但我看TCP/IP協議上是這樣寫的,我決定按照書上的來)
具體講解:
我自己的博客《ICMP詳解——Internet控制協議》,網址:https://blog.csdn.net/qq_45877524/article/details/105380742
12.5 DHCP協議詳解——TCP/IP協議的配置信息
爲了使用TCP/IP協議族,每臺主機和路由器需要一定的配置信息。配置信息用於爲系統指定本地名稱,以及爲接日指定標識符(例如IP地址)。多年來,已有很多方法可提供和獲得這種信息,但基本上採用3種方法:手工獲得信息,通過一個系統獲得使用的網絡服務,或使用某種算法自動確定。
具體講解:
我的文章《DHCP協議詳解——TCP/IP協議的配置信息》,網址:https://blog.csdn.net/qq_45877524/article/details/105113751
12.6 組織對不起,90年的事我瞞不住了——NAT(網絡地址轉換)
NAT(Network Addresss Translation),網絡地址轉換,本質上是一種允許在互聯網的不同地方重複使用相同的IP地址集的機制,同時作爲公網IP地址和私網IP地址的過渡環節,同時也具有了一定的防禦功能——過濾數據包。NAT作爲IPv4和IPv6的過渡方案,它的出現緩解了20世紀90年代初的IPv4地址數量不足的問題。,但也在一定程度上阻撓了IPv6的發展。
具體講解:
我的文章《NAT技術詳解(網絡地址轉換)》,網址:https://blog.csdn.net/qq_45877524/article/details/105237657
12.7 DNS協議(wireshark進行分析,圖示遞歸查詢及迭代查詢)
DNS協議(Domain Name System)就是將IPv4地址和IPv6地址一大串鬼都看不懂的數字符號,變成人能看懂的符號。DNS服務於IP地址到域名之間的映射轉換。
具體講解:
我的博客《DNS協議(wireshark進行分析,圖示遞歸查詢及迭代查詢)》,網址:https://blog.csdn.net/qq_45877524/article/details/105552129
12.8 TFTP(Trivial File Transfer Protocol,簡單文件傳輸協議)
是TCP/IP協議族中的一個用來在客戶機與服務器之間進行簡單文件傳輸的協議,提供不復雜、開銷不大的文件傳輸服務。
具體講解:
CSDN博主mjLlm的裝載文章《TFTP協議》,網址:https://blog.csdn.net/mjLlm/article/details/82950639
360百科《tftp》,網址:https://baike.so.com/doc/2176104-2302634.html
12.9 HTTP協議——具體講解第二個真的很nice,建議去看一下
超文本傳輸協議(HTTP,HyperText Transfer Protocol)是互聯網上應用最爲廣泛的一種網絡協議。所有的WWW文件都必須遵守這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。1960年美國人Ted Nelson構思了一種通過計算機處理文本信息的方法,並稱之爲超文本(hypertext),這成爲了HTTP超文本傳輸協議標準架構的發展根基。Ted Nelson組織協調萬維網協會(World Wide Web Consortium)和互聯網工程工作小組(Internet Engineering Task Force )共同合作研究,最終發佈了一系列的RFC,其中著名的RFC 2616定義了HTTP 1.1。
來源CSDN博主有抱負的小獅子
具體講解:
- CSDN博主有抱負的小獅子的《Http協議詳解(深入理解)》,網址:https://blog.csdn.net/weixin_38087538/article/details/82838762?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2
- CSDN博主Tyler_Zx的《Http和Https的區別(面試常考題)》,網址:https://blog.csdn.net/qq_38289815/article/details/80969419?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-11&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-11
說一下,具體講解第二個真的很nice,建議去看一下
12.10 總結
協議名稱 | 協議作用 |
---|---|
地址解析協議 | 其基本功能爲透過目標設備的IP地址,查詢目標設備的MAC地址,以保證通信的順利進行。 |
鄰居發現協議NDP(Neighbor Discovery Protocol) | 是TCP/IP協議棧的一部分,主要與IPv6共同使用。它工作在網絡層,負責在鏈路上發現其他節點和相應的地址,並確定可用路由和維護關於可用路徑和其他活動節點的信息可達性。 |
反向地址轉換協議(RARP,Reverse Address Resolution Protocol) | 反向地址轉換協議(RARP:Reverse Address Resolution Protocol) 允許局域網的物理機器從網關服務器的 ARP 表或者緩存上請求其 IP 地址。 |
Internet控制報文協議(Intemet Control Message Protocol, ICMP) | Internet控制報文協議(Intemet Control Message Protocol, ICMP)是IP協議的一種補充,它與IP協議結合使用,以便提供與IP協議層配置和IP數據包處理相關的診斷和控制信息(IP協議本身並沒有爲終端系統提供直接的方法來發現那些發往目的地址失敗的IP數據包,也沒有提供直接的方式來獲取診斷信息。) |
DHCP協議詳解——TCP/IP協議的配置信息 | DHCP(Dynamic Host Configuration Protocol)動態主機配置協議,是一種流行的客戶機/服務器協議,它用於爲主機(有時也爲路由器)指定配置信息。 |
NAT(Network Addresss Translation) | NAT(Network Addresss Translation),網絡地址轉換,本質上是一種允許在互聯網的不同地方重複使用相同的IP地址集的機制,同時作爲公網IP地址和私網IP地址的過渡環節,同時也具有了一定的防禦功能——過濾數據包。 |
DNS協議(Domain Name System) | DNS協議(Domain Name System)就是將IPv4地址和IPv6地址一大串鬼都看不懂的數字符號,變成人能看懂的符號。 |
TFTP(Trivial File Transfer Protocol,簡單文件傳輸協議) | 是TCP/IP協議族中的一個用來在客戶機與服務器之間進行簡單文件傳輸的協議,提供不復雜、開銷不大的文件傳輸服務。 |
HTTP,HyperText Transfer Protocol | 超文本傳輸協議(HTTP,HyperText Transfer Protocol)是互聯網上應用最爲廣泛的一種網絡協議。所有的WWW文件都必須遵守這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法 |
13. UDP協議解釋、TCP和UDP之間的區別
UDP這個屬於非常底層的東西,基本上都已經很少用到了,基本上題目更加多問的是TCP與UDP之間的區別,以此考察TCP。
UDP是User Datagram Protocol的簡稱,中文名是用戶數據報協議,是OSI參考模型中的傳輸層協議,它是一種無連接的傳輸層協議,提供面向事務的簡單不可靠信息傳送服務。
UDP的正式規範是IETF RFC768。UDP在IP報文的協議號是17。
老規矩,UDP不過多介紹,具體講解可以看下面幾個文章:
- CSDN博主[Object object]的《TCP 和 UDP 的區別》,網址:https://blog.csdn.net/zhang6223284/article/details/81414149?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2
- CSDN博主李大壩超歐的的《UDP協議的詳細解析》,網址:https://blog.csdn.net/aa1928992772/article/details/85240358
- CSDN博主china_jeffery的《網絡協議 – UDP協議(1)介紹》,網址:https://blog.csdn.net/china_jeffery/article/details/78923428
- CSDN博主彪悍的男人的《玩轉wireshark系列第三篇-抓取udp包》,網址:https://blog.csdn.net/u011416247/article/details/80868133?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1
- CSDN博主一日思考的《UDP協議學習》,網址:https://blog.csdn.net/s_lisheng/article/details/73538229?depth_1-utm_source=distribute.pc_relevant_right.none-task-blog-BlogCommendFromMachineLearnPai2-3&utm_source=distribute.pc_relevant_right.none-task-blog-BlogCommendFromMachineLearnPai2-3
第一個比較詳細,第三個比較簡略但是足夠了。
特徵點 | TCP | UDP |
---|---|---|
是否連接 | 面向連接 | 面向非連接 |
傳輸可靠性 | 可靠 | 會丟包,不可靠 |
應用場景 | 傳輸數據量大 | 傳輸量小 |
速度 | 慢 | 快 |
參考了: CSDN博主china_jeffery
14. TCP首部報文結構
我感覺這個東西不是特別重要,重要的是IPv4之類的這裏就水一波。
具體講解:博客園博主 zzfx的《TCP報文格式詳解》,網址:https://www.cnblogs.com/feng9exe/p/8058891.html
15. TCP的三次握手以及四次揮手
哇,這年頭如果面試還回答不出來TCP的三次握手和四次揮手是個什麼東西,那估計可以被直接擡走了,那簡直就是直接在面試官的嘴裏面塞個電飯煲。
整個好活,提一下神
B站up主比劃比劃鬼畜網的視頻《黑人擡棺原版視頻》,網址:https://www.bilibili.com/video/BV1NZ4y1j7nw?from=search&seid=12079556593468117240
言歸正傳,這個東西真的很重要,確實也是非常非常基礎。最好還是搞個十分正經的文章去複習一下,可以看我的裝載文章:
《動畫解決TCP 三次握手與四次揮手(附十道面試題)(裝載)》,網址:https://blog.csdn.net/qq_45877524/article/details/105723587
最主要是找了一些題目比較方便理解。
有部分內容裝載至CSDN博主 青柚_的《TCP的三次握手與四次揮手理解及面試題(很全面)》,網址:https://blog.csdn.net/qq_38950316/article/details/81087809
有部分內容裝載至知乎用戶低端叫獸在的回答《關於三次握手和四次揮手,面試官想聽到怎樣的回答?》,網址:https://www.zhihu.com/question/271701044
15.1 爲什麼客戶端最後還要等待2MSL?(CSDN博主 小書go)
MSL(Maximum Segment Lifetime),TCP允許不同的實現可以設置不同的MSL值。
第一,保證客戶端發送的最後一個ACK報文能夠到達服務器,因爲這個ACK報文可能丟失,站在服務器的角度看來,我已經發送了FIN+ACK報文請求斷開了,客戶端還沒有給我回應,應該是我發送的請求斷開報文它沒有收到,於是服務器又會重新發送一次,而客戶端就能在這個2MSL時間段內收到這個重傳的報文,接着給出迴應報文,並且會重啓2MSL計時器。
第二,防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最後一個確認報文後,在這個2MSL時間中,就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。
–
15.2 如果已經建立了連接,但是客戶端突然出現故障了怎麼辦?(CSDN博主 小書go)
TCP還設有一個保活計時器,顯然,客戶端如果出現故障,服務器不能一直等下去,白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器,時間通常是設置爲2小時,若兩小時還沒有收到客戶端的任何數據,服務器就會發送一個探測報文段,以後每隔75秒發送一次。若一連發送10個探測報文仍然沒反應,服務器就認爲客戶端出了故障,接着就關閉連接。
15.3 爲什麼不能用兩次握手進行連接?(CSDN博主 青柚_)
3次握手完成兩個重要的功能,既要雙方做好發送數據的準備工作(雙方都知道彼此已準備好),也要允許雙方就初始序列號進行協商,這個序列號在握手過程中被髮送和確認。
現在把三次握手改成僅需要兩次握手,死鎖是可能發生的。作爲例子,考慮計算機S和C之間的通信,假定C給S發送一個連接請求分組,S收到了這個分組,併發 送了確認應答分組。按照兩次握手的協定,S認爲連接已經成功地建立了,可以開始發送數據分組。可是,C在S的應答分組在傳輸中被丟失的情況下,將不知道S 是否已準備好,不知道S建立什麼樣的序列號,C甚至懷疑S是否收到自己的連接請求分組。在這種情況下,C認爲連接還未建立成功,將忽略S發來的任何數據分 組,只等待連接確認應答分組。而S在發出的分組超時後,重複發送同樣的分組。這樣就形成了死鎖。
15.4 如果已經建立了連接,但是客戶端突然出現故障了怎麼辦?(CSDN博主 青柚_)
TCP還設有一個保活計時器,顯然,客戶端如果出現故障,服務器不能一直等下去,白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器,時間通常是設置爲2小時,若兩小時還沒有收到客戶端的任何數據,服務器就會發送一個探測報文段,以後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應,服務器就認爲客戶端出了故障,接着就關閉連接。
15.5 爲什麼關閉連接要設計成四次?(低端叫獸)
因爲關閉連接時,server端收到客戶端的fin報文,並不會立即關閉socket,只能先回復一個ack告訴client我已經收到你的關閉請求了,同時可能server還有數據沒傳輸完,只有等server端數據傳輸完成了 才能發送fin報文,所以這個地方要分兩次發送,這樣就有了四次揮手.
15.6 服務端運行一段時間後,套接字出現了大量的Close_Wait狀態,最有可能是什麼原因導致的?(低端叫獸)
close-wait狀態是因爲client已經發出釋放連接信號了 已經沒有數據傳輸過來,但是server端還有數據未發送完,這個時候就有close-wait狀態了!
15.7 爲什麼基於TCP的程序往往都有個應用層的心跳檢測機制?(低端叫獸)
是爲了預防建立好的連接突然客戶端故障了,服務器不能一直等待下去,需要一個計時器和探測包來檢測.
15.8 服務端的Time_Wait狀態再哪個階段出現?持續多久?爲什麼要設計這麼一個狀態?(低端叫獸)
timewait階段是最後階段發送確認收到server端的fin報文釋放連接請求後回覆給server端ack報文,之後client端就進入time_wait階段.
持續多久即是問爲什麼不馬上關閉直接進入closed階段,主要是考慮到網絡的不可靠,假如client最後階段發送給server端端ack報文由於網絡原因丟失了server沒收到呢,server端會重新發送fin報文過來,這個時候client端就要等.
等多久?等一個計時器時間2MSL,如果該時間段內再次收到server的fin報文 那client就必須回覆. 如果沒有收到,client就認爲server端已經接收到了最後的ack報文.
16. TCP滑動窗口與擁塞機制
這個東西的重要性比不上三次握手、四次揮手,但是考題中也會遇到。
16.1 TCP滑動窗口
b站上有一個視頻比較nice的可視化了滑動窗口的機制。
tcp滑動窗口的完美解釋
來自於up主 今天單詞背了嗎O_o 的tcp滑動窗口的完美解釋,網址:https://www.bilibili.com/video/BV1FE411C7dk?from=search&seid=6007213953266071805
這裏可以看我的裝載文章:
《TCP之滑動窗口協議(動畫演示)(裝載)》,網址:https://blog.csdn.net/qq_45877524/article/details/105854591
16.2 TCP擁塞機制
自我檢討這個東西確實不熟,回首掏的時候補上。
還是貼出幾個文章鏈接吧:
- CSDN博主sHuXnHs的 《TCP擁塞控制機制(附面試題)》,網址:https://blog.csdn.net/shuxnhs/article/details/80644531
- CSDN博主lt_李木子的《TCP的擁塞控制(詳解)》,網址:https://blog.csdn.net/qq_41431406/article/details/97926927?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1
- CSDN博主sicofield的《TCP的擁塞控制》,網址:https://blog.csdn.net/sicofield/article/details/9708383?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3
第一個的騰訊題目很nice,但是講的地方會有部分錯誤,第二個沒什麼問題沒有題目熟悉
17 比較nice的題目收集,內附答案,侵權立刪
- 知乎用戶路人甲的文章《常見面試題整理–計算機網絡篇(每位開發者必備)》,網址:https://zhuanlan.zhihu.com/p/24001696
- CSDN博主[Object object]的《TCP 和 UDP 的區別》,網址:https://blog.csdn.net/zhang6223284/article/details/81414149?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2
- 至CSDN博主 青柚_的《TCP的三次握手與四次揮手理解及面試題(很全面)》,網址:https://blog.csdn.net/qq_38950316/article/details/81087809
- 知乎用戶低端叫獸在的回答《關於三次握手和四次揮手,面試官想聽到怎樣的回答?》,網址:https://www.zhihu.com/question/271701044
- CSDN博主逃離地球的小小呆的《子網劃分詳解與子網劃分實例精析》,網址:https://blog.csdn.net/gui951753/article/details/79412524
- CSDN博主sHuXnHs的 《TCP擁塞控制機制(附面試題)》,網址:https://blog.csdn.net/shuxnhs/article/details/80644531
- 知乎用戶 何柄融 的《通過計算機網絡的一些題目加深理解》,網址:https://zhuanlan.zhihu.com/p/38223259
後面沒有名字代表和前面題目一樣
知識點可能比較亂,將就一下。
17.1 請簡述TCP\UDP的區別(知乎:路人甲)
- TCP面向連接,UDP面向非連接即發送數據前不需要建立鏈接
- TCP提供可靠的服務(數據傳輸),UDP無法保證
- TCP面向字節流,UDP面向報文
- TCP數據傳輸慢,UDP數據傳輸快
17.2 請簡單說一下你瞭解的端口及對應的服務?
17.3 說一說TCP的三次握手
17.4 說一說TCP的四次揮手
數據傳輸完畢後,雙方都可釋放連接。最開始的時候,客戶端和服務器都是處於ESTABLISHED狀態,然後客戶端主動關閉,服務器被動關閉。
- 客戶端進程發出連接釋放報文,並且停止發送數據。釋放數據報文首部,FIN=1,其序列號爲seq=u(等於前面已經傳送過來的數據的最後一個字節的序號加1),此時,客戶端進入FIN-WAIT-1(終止等待1)狀態。 TCP規定,FIN報文段即使不攜帶數據,也要消耗一個序號。
- 服務器收到連接釋放報文,發出確認報文,ACK=1,ack=u+1,並且帶上自己的序列號seq=v,此時,服務端就進入了CLOSE-WAIT(關閉等待)狀態。TCP服務器通知高層的應用進程,客戶端向服務器的方向就釋放了,這時候處於半關閉狀態,即客戶端已經沒有數據要發送了,但是服務器若發送數據,客戶端依然要接受。這個狀態還要持續一段時間,也就是整個CLOSE-WAIT狀態持續的時間。
- 客戶端收到服務器的確認請求後,此時,客戶端就進入FIN-WAIT-2(終止等待2)狀態,等待服務器發送連接釋放報文(在這之前還需要接受服務器發送的最後的數據)。
- 服務器將最後的數據發送完畢後,就向客戶端發送連接釋放報文,FIN=1,ack=u+1,由於在半關閉狀態,服務器很可能又發送了一些數據,假定此時的序列號爲seq=w,此時,服務器就進入了LAST-ACK(最後確認)狀態,等待客戶端的確認。
- 客戶端收到服務器的連接釋放報文後,必須發出確認,ACK=1,ack=w+1,而自己的序列號是seq=u+1,此時,客戶端就進入了TIME-WAIT(時間等待)狀態。注意此時TCP連接還沒有釋放,必須經過2∗*∗MSL(最長報文段壽命)的時間後,當客戶端撤銷相應的TCB後,才進入CLOSED狀態。
- 服務器只要收到了客戶端發出的確認,立即進入CLOSED狀態。同樣,撤銷TCB後,就結束了這次的TCP連接。可以看到,服務器結束TCP連接的時間要比客戶端早一些。
17.5 有哪些私有(保留)地址?
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
17.6 IP地址分爲哪幾類?簡單說一下各個分類
類 | 地址範圍 | 高序位 | 用途 | 百分比 |
---|---|---|---|---|
A | 0.0.0.0 - 127.255.255.255 | 0 | 單播/特殊 | 1/2 |
B | 128.0.0.0 - 191.255.255.255 | 10 | 單播/特殊 | 1/4 |
C | 192.0.0.0 - 223.255.255.255 | 110 | 單播/特殊 | 1/4 |
D | 224.0.0.0 - 239.255.255.255 | 1110 | 組播 | 1/16 |
E | 240.0.0.0 - 255.255.255.255 | 1111 | 保留 | 1/16 |
17.7 在瀏覽器中輸入網址之後執行會發生什麼?
- 查找域名對應的IP地址。這一步會依次查找瀏覽器緩存,系統緩存,路由器緩存,ISPNDS緩存,根域名服務器
- 瀏覽器向IP對應的web服務器發送一個HTTP請求
- 服務器響應請求,發回網頁內容
- 瀏覽器解析網頁內容
17.8 簡單解釋一些ARP協議的工作過程
17.9 說一說OSI七層模型
17.10 說一說TCP/IP四層模型
前面有一張圖非常詳細。
17.11 HTTP 協議包括哪些請求?
- GET:對服務器資源的簡單請求
- POST:用於發送包含用戶提交數據的請求
- HEAD:類似於GET請求,不過返回的響應中沒有具體內容,用於獲取報頭
- PUT:傳說中請求文檔的一個版本
- DELETE:發出一個刪除指定文檔的請求
- TRACE:發送一個請求副本,以跟蹤其處理進程
- OPTIONS:返回所有可用的方法,檢查服務器支持哪些方法
- CONNECT:用於ssl隧道的基於代理的請求
17.12 簡述HTTP中GET和POST的區別
從原理性看:
- 根據HTTP規範,GET用於信息獲取,而且應該是安全和冪等的
- 根據HTTP規範,POST請求表示可能修改服務器上資源的請求
從表面上看:
- GET請求的數據會附在URL後面,POST的數據放在HTTP包體
- POST安全性比GET安全性高
17.13 TCP/UDP裏面什麼是面向連接,什麼是面向無連接?([Object object])
在互通之前,面向連接的協議會先建立連接,如 TCP 有三次握手,而 UDP 不會
17.14 TCP 爲什麼是可靠連接
- 通過 TCP 連接傳輸的數據無差錯,不丟失,不重複,且按順序到達。
- TCP 報文頭裏面的序號能使 TCP 的數據按序到達
- 報文頭裏面的確認序號能保證不丟包,累計確認及超時重傳機制
- TCP 擁有流量控制及擁塞控制的機制
17.15 (TCP三次握手)爲什麼客戶端最後還要等待2MSL?(CSDN博主 小書go)
MSL(Maximum Segment Lifetime),TCP允許不同的實現可以設置不同的MSL值。
第一,保證客戶端發送的最後一個ACK報文能夠到達服務器,因爲這個ACK報文可能丟失,站在服務器的角度看來,我已經發送了FIN+ACK報文請求斷開了,客戶端還沒有給我回應,應該是我發送的請求斷開報文它沒有收到,於是服務器又會重新發送一次,而客戶端就能在這個2MSL時間段內收到這個重傳的報文,接着給出迴應報文,並且會重啓2MSL計時器。
第二,防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最後一個確認報文後,在這個2MSL時間中,就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。
–
17.16(TCP三次握手) 如果已經建立了連接,但是客戶端突然出現故障了怎麼辦?
TCP還設有一個保活計時器,顯然,客戶端如果出現故障,服務器不能一直等下去,白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器,時間通常是設置爲2小時,若兩小時還沒有收到客戶端的任何數據,服務器就會發送一個探測報文段,以後每隔75秒發送一次。若一連發送10個探測報文仍然沒反應,服務器就認爲客戶端出了故障,接着就關閉連接。
17.17(TCP三次握手) 爲什麼不能用兩次握手進行連接?(CSDN博主 青柚_)
3次握手完成兩個重要的功能,既要雙方做好發送數據的準備工作(雙方都知道彼此已準備好),也要允許雙方就初始序列號進行協商,這個序列號在握手過程中被髮送和確認。
現在把三次握手改成僅需要兩次握手,死鎖是可能發生的。作爲例子,考慮計算機S和C之間的通信,假定C給S發送一個連接請求分組,S收到了這個分組,併發 送了確認應答分組。按照兩次握手的協定,S認爲連接已經成功地建立了,可以開始發送數據分組。可是,C在S的應答分組在傳輸中被丟失的情況下,將不知道S 是否已準備好,不知道S建立什麼樣的序列號,C甚至懷疑S是否收到自己的連接請求分組。在這種情況下,C認爲連接還未建立成功,將忽略S發來的任何數據分 組,只等待連接確認應答分組。而S在發出的分組超時後,重複發送同樣的分組。這樣就形成了死鎖。
17.18 (TCP三次握手) 如果已經建立了連接,但是客戶端突然出現故障了怎麼辦?
TCP還設有一個保活計時器,顯然,客戶端如果出現故障,服務器不能一直等下去,白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器,時間通常是設置爲2小時,若兩小時還沒有收到客戶端的任何數據,服務器就會發送一個探測報文段,以後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應,服務器就認爲客戶端出了故障,接着就關閉連接。
17.19 (TCP三次握手)爲什麼關閉連接要設計成四次?(低端叫獸)
因爲關閉連接時,server端收到客戶端的fin報文,並不會立即關閉socket,只能先回復一個ack告訴client我已經收到你的關閉請求了,同時可能server還有數據沒傳輸完,只有等server端數據傳輸完成了 才能發送fin報文,所以這個地方要分兩次發送,這樣就有了四次揮手.
17.20 (TCP三次握手) 服務端運行一段時間後,套接字出現了大量的Close_Wait狀態,最有可能是什麼原因導致的?
close-wait狀態是因爲client已經發出釋放連接信號了 已經沒有數據傳輸過來,但是server端還有數據未發送完,這個時候就有close-wait狀態了!
17.21 (TCP三次握手) 爲什麼基於TCP的程序往往都有個應用層的心跳檢測機制?
是爲了預防建立好的連接突然客戶端故障了,服務器不能一直等待下去,需要一個計時器和探測包來檢測.
17.22 (TCP三次握手) 服務端的Time_Wait狀態再哪個階段出現?持續多久?爲什麼要設計這麼一個狀態?
timewait階段是最後階段發送確認收到server端的fin報文釋放連接請求後回覆給server端ack報文,之後client端就進入time_wait階段.
持續多久即是問爲什麼不馬上關閉直接進入closed階段,主要是考慮到網絡的不可靠,假如client最後階段發送給server端端ack報文由於網絡原因丟失了server沒收到呢,server端會重新發送fin報文過來,這個時候client端就要等.
等多久?等一個計時器時間2MSL,如果該時間段內再次收到server的fin報文 那client就必須回覆. 如果沒有收到,client就認爲server端已經接收到了最後的ack報文.
17.23 (C類子網劃分子網劃分的計算)(逃離地球的小小呆)題目一
255.255.255.128 (/25)
128的二進制表示爲10000000,只有1位用於定義子網,餘下7位用於定義主機。這裏將對C類網絡192.168.10.0進行子網劃分。
網絡地址=192.168.10.0
子網掩碼=255.255.255.128
回答五大問題:
-
多少個子網?
在128( 10000000 )中,取值爲1的位數爲1,借用了一位主機位,因此答案爲2^1=2。 -
每個子網多少臺主機?
有7個主機位取值爲o( 10000000),還剩下7位主機位,因此答案是2^7-2= 126臺主機。 -
有哪些合法的子網?
256 -128 = 128。也就是子網的增量是128.因此子網爲0和128 -
每個子網的廣播地址是什麼?
在下一個子網之前的數字中,所有主機位的取值都爲1,是當前子網的廣播地址。對於子網0,下一個子網爲128,因此其廣播地址爲127 -
每個子網包含哪些合法的主機地址?
合法的主機地址爲子網地址和廣播地址之間的數字。要確定主機地址,最簡單的方法是寫出子網地址和廣播地址,這樣合法的主機地址就顯而易見了。
小小呆的這幾個問題比較詳細的講解都可以看它的這個文章:
CSDN博主逃離地球的小小呆的《子網劃分詳解與子網劃分實例精析》,網址:https://blog.csdn.net/gui951753/article/details/79412524
17.24 子網劃分的題目 2
255.255.255.192 (/26)
在第二個示例中,我們將使用子網掩碼255.255.255.192對網絡192.168.10.0進行子網劃分。
網絡地址=192.168.10.0
子網掩碼=255.255.255.192
下面來回答五大問題
- 多少個子網?
在192(11000000)中,取值爲1的位數爲2,因此答案爲2^2=4個子網。 - 每個子網多少臺主機?有6個主機位的取值爲o(11000000),因此答案是2^6-2=62臺主機。
- 有哪些合法的子網?
256 -192 = 64。所以子網的步長[增量]爲64,因此子網爲0、64、128和192 - 每個子網的廣播地址是什麼?
在下一個子網之前的數字中,所有主機位的取值都爲1,是當前子網的廣播地址。對於子網0,下一個子網爲64,因此其廣播地址爲63。以此類推。 - 合法的主機地址有哪些?
合法的主機地址爲子網地址和廣播地址之間的數字。要確定主機地址,最簡單的方法是寫出子網地址和廣播地址,這樣合法的主機地址就顯而易見了。
17.25 子網劃分的題目 3
從這個案例開始,我不再一一回答這五大問題,大部分的思考是重複的,我只給出問題和圖表類型的答案。
255.255.255.224 (/27)
這次我們將使用子網掩碼255.255.255.224對網絡192.168.10.0進行子網劃分。
網絡地址=192.168.10.0
子網掩碼=255.255.255.224
17.26 子網劃分的題目 4
255.255.255.240 (/28)
再來看一個示例:
網絡地址=192.168.10.0
子網掩碼=255.255.255.240
17.27 子網劃分的題目 5
255.255.255.248 (/29)
繼續練習:
網絡地址=192.168.10.0
子網掩碼=255.255.255.248
17.28 已知IP地址和子網掩碼求子網劃分 1
已知ip地址=192.168.10.33 ,子網掩碼=255.255.255.224,求該網絡的子網劃分。
- 求出子網增量:
由於子網掩碼是224,所以子網步長爲256-224=32 - 求有哪些合法子網:
由上文知道,子網的步長爲32.因此子網爲0、32、64等等 - 求出該Ip地址對應的子網號。
因爲主機地址33位於子網32和64之間,因此屬於子網192.168.10.32 - 求該子網對應的廣播地址:
下一個子網爲64,因此子網32的廣播地址爲63(廣播地址總是下一個子網之前的數字)。 - 求合法的主機地址範圍:
33~62(子網和廣播地址之間的數字)。
17.29 已知IP地址和子網掩碼求子網劃分 2
ip地址=192.168.10.174
子網掩碼=255.255.255.240.合法的主機地址範圍是多少呢?
解答:子網掩碼爲240,因此將256減去240,結果爲16,這是子網增量。要確定所屬的子網,只需從零開始不斷增加16,並在超過主機地址174後停止:0、16、32、48、64、80、96、112、128、144、160、176等。主機地址174位於160和176之間,因此所屬的子網爲160。廣播地址爲175,合法的主機地址範圍爲161~174。
17.30 已知IP地址和子網掩碼求子網劃分 3
ip地址=192.168.10.17
子網掩碼=255.255.255.252 該IP地址屬於哪個子網?該子網的廣播地址是什麼?
256 -252= 4,因此子網爲0、4、8、12、16、20等(除非專門指出,否則總是從0開始)。主機地址17位於子網16和20之間,因此屬於子網192.168.10.16,而該子網的廣播地址爲19,合法的主機地址範圍爲17-18。
17.31B類地址 已知網絡地址和子網掩碼求子網劃分 1
在B類地址中,有16位可用於主機地址。這意昧着最多可將其中的14位用於子網劃分,因爲至少需要保留2位用於主機編址。使用/16意味着不對B類網絡進行子網劃分,但它是一個可使用的子網掩碼。
255.255.128.0 (/17)
網絡地址=172.16.0.0
子網掩碼=255.255.128.0
- 多少個子網?
2^1 =2 (與C類網絡相同)借用了一位主機位。 - 每個子網多少臺主機?
2^15 -2 = 32766 (主機位一共15位,第三個字節7位,第四個字節8位)。 - 有哪些合法的子網?
256 -128 = 128,因此子網爲0和128。鑑於子網劃分是在第三個字節中進行的,因此子網號實際上爲0.0和128.0 - 每個子網的廣播地址是什麼?(跟C類相同,廣播地址總是下一個子網前面的數)
合法的主機地址是什麼?(子網號與廣播地址之間的地址就是合法的主機地址)
17.32 已知網絡地址和子網掩碼求子網劃分 2
255.255.255.128 (/25)
這是一個非常難但是卻十分適合生產環境的子網劃分組合
網絡地址=172.16.0.0
子網掩碼=255.255.255.128
- 多少個子網?
2^9=512。一共借用了9個主機位 - 每個子網多少臺主機?
2^7-2 = 126。 還有16-9=7位主機位 - 有哪些合法的子網?
這是比較棘手的部分。這個地方的子網增量應該是 256-255=1,因此第三個字節的可能取值爲0、1 、2、3…255;但別忘了,第四個字節還有一個子網位。還記得前面如何在C類網絡中處理只有一個子網位的情況嗎?這裏的處理方式相同。也就是說第三個字節的每個取值都有0和128這兩種情況。例如,如果第三個字節的取值爲3,則對應的兩個子網爲3.0和3.128。因此總共有512個子網。 - 每個子網的廣播地址是什麼?(下一個子網地址的前一位)
合法的主機地址是什麼?(介於子網地址和該子網的廣播地址之間的就是主機地址)
下面用圖表列出這個例子的子網劃分結果:
17.33 已知ip地址和子網掩碼求子網劃分
當使用cidr表示子網劃分,網絡位的位數>24時,比如/25,/27.我們只需要考慮第四個字節。<=24時,我們只需要考慮第三個字節,因爲第四個字節的主機位並沒有被借用,並沒有參與到子網劃分。
問題:172.16.10.33/27屬於哪個子網?該子網的廣播地址是多少?
答案:這裏只需考慮第四個字節。256-224=32,故第四個字節的變化爲0、32、64…。33位於32和64之間,但子網號還有一部分位於第三個字節,因此
答案是該地址位於子網10.32中。由於下一個子網爲10.64,該子網的廣播地址爲172.16.10.63
17.34 A類子網劃分實例 已知網絡地址和子網掩碼求子網劃分 1
A類網絡的子網劃分與B類和C類網絡沒有什麼不同,但需要處理的是24位,而B類和C類網絡中需處理的分別是16位和8位。
可用於A類的所有子網掩碼:
255.255.240.0(/20)
網絡地址=10.0.0.0
子網掩碼=255.255.240.0(/20)時,12位用於子網劃分,餘下12位用於主機編址。
-
多少個子網?
2^12=4096。 -
每個子網的主機數?
2^12-2=4094 -
有哪些合法的子網?
需要考慮哪些字節?借用的主機號來自於第二和第三個字節,因此要考慮第二個和第三個字節,在第二個字節中,子網號的間隔爲1;在第三個字節中,子網號爲0、16、32等,因爲256-240=160 -
每個子網的廣播地址是什麼?
-
合法的主機地址是什麼?
具體劃分如表中所示:
17.35 已知ip地址和子網掩碼求子網劃分
ip地址=10.1.3.65/23
求該ip地址對應的子網以及該子網合法的主機地址和廣播地址:
**回答:**首先,如果不知道/23對應的子網掩碼,你就回答不了這個問題。它對應的子網掩碼爲255.255.254.0。這裏需要注意的字節爲第三個。256-254=2,因此第三個字節的子網號爲0、2、4、6等。在這個問題中,主機位於子網2.0中,而下一個子網爲4.0,因此該子網的廣播地址爲3.255。10.1.2.1~10.1.3.254中的任何地址都是該子網中合法的主機地址。
17.36 (sHuXnHs)TCP的擁塞控制機制是什麼?請簡單說說。
我們知道TCP通過一個定時器(timer)採樣了RTT並計算RTO,但是,如果網絡上的延時突然增加,那麼,TCP對這個事做出的應對只有重傳數據,然而重傳會導致網絡的負擔更重,於是會導致更大的延遲以及更多的丟包,這就導致了惡性循環,最終形成“網絡風暴” —— TCP的擁塞控制機制就是用於應對這種情況。
首先需要了解一個概念,爲了在發送端調節所要發送的數據量,定義了一個“擁塞窗口”(Congestion Window),在發送數據時,將擁塞窗口的大小與接收端ack的窗口大小做比較,取較小者作爲發送數據量的上限。
擁塞控制主要是四個算法:
1.慢啓動:意思是剛剛加入網絡的連接,一點一點地提速,不要一上來就把路佔滿。
連接建好的開始先初始化cwnd = 1,表明可以傳一個MSS大小的數據。
每當收到一個ACK,cwnd++; 呈線性上升
每當過了一個RTT,cwnd = cwnd*2; 呈指數讓升
閾值ssthresh(slow start threshold),是一個上限,當cwnd >= ssthresh時,就會進入“擁塞避免算法”
2.擁塞避免:當擁塞窗口 cwnd 達到一個閾值時,窗口大小不再呈指數上升,而是以線性上升,避免增長過快導致網絡擁塞。
每當收到一個ACK,cwnd = cwnd + 1/cwnd
每當過了一個RTT,cwnd = cwnd + 1
擁塞發生:當發生丟包進行數據包重傳時,表示網絡已經擁塞。分兩種情況進行處理:
等到RTO超時,重傳數據包
sshthresh = cwnd /2
cwnd 重置爲 1
3.進入慢啓動過程
在收到3個duplicate ACK時就開啓重傳,而不用等到RTO超時
sshthresh = cwnd = cwnd /2
進入快速恢復算法——Fast Recovery
4.快速恢復:至少收到了3個Duplicated Acks,說明網絡也不那麼糟糕,可以快速恢復。
cwnd = sshthresh + 3 * MSS (3的意思是確認有3個數據包被收到了)
重傳Duplicated ACKs指定的數據包
如果再收到 duplicated Acks,那麼cwnd = cwnd +1
如果收到了新的Ack,那麼,cwnd = sshthresh ,然後就進入了擁塞避免的算法了。
17.37 (知乎:何柄融)題目 一
長度爲100字節的應用層數據交給傳輸層傳送,需加上20字節的TCP首部。再交給網絡層傳送,需加上20字節的IP首部。最後交給數據鏈路層的以太網傳送,加上首部和尾部工18字節。試求數據的傳輸效率。數據的傳輸效率是指發送的應用層數據除以所發送的總數據(即應用數據加上各種首部和尾部的額外開銷)。若應用層數據長度爲1000字節,數據的傳輸效率是多少?
-
100/(100+20+20+18)=63.3%
-
1000/(1000+20+20+18)=94.5%
通過這道題目對傳輸效率有一定的認識,然後對數據包的底層進一步加深理解。
17.38 試從多個方面比較電路交換、報文交換和分組交換的主要優缺點。
(1)電路交換:端對端通信質量因約定了通信資源獲得可靠保障,對連續傳送大量數據效率高。(2)報文交換:無須預約傳輸帶寬,動態逐段利用傳輸帶寬對突發式數據通信效率高,通信迅速。(3)分組交換:具有報文交換之高效、迅速的要點,且各分組小,路由靈活,網絡生存性能好。
這到題目需要先理解三種交換方式的原理所在,電路交換就像打電話一樣,先建立連接,然後再進行通信。報文交換和分組交換的原理差不多,只不過報文交換是把全部數據都一次性存儲轉發,而分組交換則分成了多次。
17.39 協議與服務有何區別?有何關係?
網絡協議:爲進行網絡中的數據交換而建立的規則、標準或約定。由以下三個要素組成:
(1)語法:即數據與控制信息的結構或格式。
(2)語義:即需要發出何種控制信息,完成何種動作以及做出何種響應。
(3)同步:即事件實現順序的詳細說明。協議是控制兩個對等實體進行通信的規則的集合。在協議的控制下,兩個對等實體間的通信使得本層能夠向上一層提供服務,而要實現本層協議,還需要使用下面一層提供服務。
協議和服務的概念的區分: 1、協議的實現保證了能夠向上一層提供服務。本層的服務用戶只能看見服務而無法看見下面的協議。下面的協議對上面的服務用戶是透明的。2、協議是“水平的”,即協議是控制兩個對等實體進行通信的規則。但服務是“垂直的”,即服務是由下層通過層間接口向上層提供的。上層使用所提供的服務必須與下層交換一些命令,這些命令在OSI中稱爲服務原語。
17.40 假定某信道受奈氏準則限制的最高碼元速率爲20000碼元/秒。如果採用振幅調製,把碼元的振幅劃分爲16個不同等級來傳送,那麼可以獲得多高的數據率(b/s)?
C=RLog2(16)=20000b/s4=80000b/s
這題考查的是奈奎斯特公式:C = 2B * log2 N ( bps )
這裏B是物理帶寬,而2B爲最高碼元傳輸速率=20000碼元/秒.
N=16.因爲也表示16個等級.即16個信號離散等級。
所以答案=20000log2 16=200004=8000b/s.
17.41 試說明IP地址與硬件地址的區別,爲什麼要使用這兩種不同的地址?
IP 地址就是給每個連接在因特網上的主機(或路由器)分配一個在全世界範圍是唯一的 32 位的標識符。從而把整個因特網看成爲一個單一的、抽象的網絡在實際網絡的鏈路上傳送數據幀時,最終還是必須使用硬件地址。
MAC地址在一定程度上與硬件一致,基於物理、能夠標識具體的鏈路通信對象、IP地址給予邏輯域的劃分、不受硬件限制。
17.42 某單位分配到一個B類IP地址,其net-id爲129.250.0.0.該單位有4000臺機器,分佈在16個不同的地點。如選用子網掩碼爲255.255.255.0,試給每一個地點分配一個子網掩碼號,並算出每個地點主機號碼的最小值和最大值
4000/16=250,平均每個地點250臺機器。 B類IP地址,而子網掩碼爲255.255.255.0,則說明後面16位中的8位也是網絡地址,所以主機數只有8位。
子網號(subnet-id) 子網網絡號 主機IP的最小值和最大值
1: 00000001 129.250.1.0 129.250.1.1—129.250.1.254
2: 00000010 129.250.2.0 129.250.2.1—129.250.2.254
3: 00000011 129.250.3.0 129.250.3.1—129.250.3.254
4: 00000100 129.250.4.0 129.250.4.1—129.250.4.254
5: 00000101 129.250.5.0 129.250.5.1—129.250.5.254
6: 00000110 129.250.6.0 129.250.6.1—129.250.6.254
7: 00000111 129.250.7.0 129.250.7.1—129.250.7.254
8: 00001000 129.250.8.0 129.250.8.1—129.250.8.254
9: 00001001 129.250.9.0 129.250.9.1—129.250.9.254
10: 00001010 129.250.10.0 129.250.10.1—129.250.10.254
11: 00001011 129.250.11.0 129.250.11.1—129.250.11.254
12: 00001100 129.250.12.0 129.250.12.1—129.250.12.254
13: 00001101 129.250.13.0 129.250.13.1—129.250.13.254
14: 00001110 129.250.14.0 129.250.14.1—129.250.14.254
15: 00001111 129.250.15.0 129.250.15.1—129.250.15.254
16: 00010000 129.250.16.0 129.250.16.1—129.250.16.254
17.43 設TCP的ssthresh的初始值爲8(單位爲報文段)。當擁塞窗口上升到12時網絡發生了超時,TCP使用慢開始和擁塞避免。試分別求出第1次到第15次傳輸的各擁塞窗口大小。你能說明擁塞控制窗口每一次變化的原因嗎?
擁塞窗口大小分別爲:1,2,4,8,9,10,11,12,1,2,4,6,7,8,9.
首先是慢開始1,2,4,8。然後此後大於ssthresh,改用擁塞避免算法8,9,10,11,12。但是由於到12時發生超時,所以此後從又從1開始,設ssthresh爲1/2 *12=6。所以1,2,4,6.然後到了又開始擁塞算法,6,7,8,9 所以,最後就是上面的排序。
17.44 我也想在搞多一個問題,但是差不多就算了,在多就買本考研試題吧
18. 參考資料:
《整個文章中用到的參考資料,網址:https://blog.csdn.net/qq_45877524/article/details/105886501)》