在開始今天的影片教學之前，我要感謝所有為我的課程在 YouTube 上受歡迎做出貢獻的人。 當我大約 8 個月前開始時，我並沒有想到會取得如此成功 - 今天我的課程已被 312724 人觀看，我有 11208 名訂閱者。 我做夢也沒想到，這個卑微的開始會達到如此的高度。 但我們不要浪費時間，直接進入今天的課程。 今天我們將填補過去 7 節影片課程中出現的空白。 雖然今天只是第六天，但第三天被分成了6節視頻課，所以今天你實際上將觀看第八節視頻課。
今天我們將討論 3 個重要主題：DHCP、TCP 傳輸和最常見的連接埠號碼。 我們已經討論過 IP 位址，而 IP 位址配置中最重要的因素之一就是 DHCP。
DHCP 代表動態主機配置協議，它是一種幫助為主機動態配置 IP 位址的協定。 所以我們都看過這個視窗。 當您按一下「自動取得 IP 位址」選項時，電腦會尋找在相同子網路上設定的 DHCP 伺服器，並傳送各種封包和 IP 位址請求。 DHCP 協定有 6 則訊息，其中 4 則對於分配 IP 位址至關重要。
第一個訊息是 DHCP DISCOVERY 訊息。 DHCP 發現訊息類似於問候訊息。 當新設備加入網路時，它會詢問網路上是否有 DHCP 伺服器。
您在幻燈片中看到的內容看起來像廣播請求，其中設備聯繫網路上的所有設備來尋找 DHCP 伺服器。 正如我所說，這是一個廣播請求，因此網路上的所有設備都可以聽到它。
如果網路上有 DHCP 伺服器，它會傳送封包 - DHCP OFFER 報價。 提議是指 DHCP 伺服器回應發現請求，向客戶端發送配置，要求客戶端接受特定的 IP 位址。
DHCP 伺服器保留一個 IP 位址（在本例中為 192.168.1.2），但並未提供該位址，而是為裝置保留該位址。 同時，offer包包含了自己的DHCP伺服器IP位址。
如果該網路上有多個 DHCP 伺服器，另一台 DHCP 伺服器在收到用戶端的廣播請求後也會為其提供 IP 位址，例如 192.168.1.50。 在同一網路上設定兩個不同的 DHCP 伺服器的情況並不常見，但有時確實會發生。 因此，當向客戶端發送 DHCP 提議時，它會收到 2 個 DHCP 提議，現在必須決定要接受哪個 DHCP 提議。
我們假設客戶接受第一個申請。 這表示客戶端發送 DHCP REQUEST 請求，字面意思是「我接受 DHCP 伺服器 192.168.1.2 提供的 IP 位址 192.168.1.1」。
收到請求後，192.168.1.1 DHCP 伺服器會回應“好吧，我承認”，即確認該請求並將此 DHCP ACK 發送給客戶端。 但我們記得另一台 DHCP 伺服器為客戶端保留了 IP 位址 1.50。 一旦它收到客戶端的廣播請求，它就會知道失敗，並將該 IP 位址放回池中，以便在收到另一個請求時可以將其指派給另一個客戶端。
這是 DHCP 在分配 IP 位址時交換的 4 個關鍵訊息。 接下來，DHCP 還有 2 個資訊訊息。 如果用戶端需要的資訊多於第二步驟中 DHCP OFFER 子句中收到的訊息，則用戶端會發出訊息訊息。 如果伺服器未在 DHCP Offer 中提供足夠的信息，或者用戶端所需的資訊多於 Offer 封包中包含的信息，則會要求其他 DHCP 資訊。 客戶端也會向伺服器發送訊息 - 這就是 DHCP RELEASE。 它通知您客戶端想要釋放其現有的 IP 位址。
然而，最常發生的情況是，在客戶端有時間向伺服器發送 DHCP RELEASE 之前，使用者就中斷了與網路的連線。 當您關閉電腦時就會發生這種情況，我們就是這麼做的。 在這種情況下，網路用戶端或電腦根本沒有時間通知伺服器釋放所使用的位址，因此 DHCP RELEASE 不是必要的步驟。 取得IP位址所需的步驟為：DHCP發現、DHCP提供、DHCP請求和DHCP握手。
在下一課中，我將告訴您在建立 DNCP 池時如何設定 DHCP 伺服器。 所謂池化，是指您告訴伺服器分配 192.168.1.1 到 192.168.1.254 範圍內的 IP 位址。 因此，DHCP 伺服器將建立一個池，在其中放置 254 個 IP 位址，並且只能從該池中向網路上的用戶端分配位址。 因此，這類似於用戶可以執行的管理設定。
現在我們來看看TCP傳輸。 不知道大家是否熟悉圖中的“電話”，小時候我們經常用這些用繩子連接起來的錫罐來互相通話。
不幸的是，今天的一代人無法承受這樣的「奢侈」。 我的意思是，今天的孩子們從一歲起就在電視機前，他們玩PSP，也許這是有爭議的，但我認為我們有最好的童年，我們實際上到外面玩遊戲，今天的孩子們不能從沙發上拉開。
我的兒子只有一歲，我已經可以看出他對iPad上癮了，我的意思是他還很小，但我認為今天的孩子已經出生就知道如何使用電子產品。 所以，我想說，小時候，當我們玩耍時，我們會在錫罐上打洞，然後用繩子把它們綁起來，並對一個罐子說些什麼，然後另一端的人就能聽到我們在說什麼。對他來說，只需將罐子放在耳邊即可。 所以它與網路連線非常相似。
如今，即使是 TCP 傳輸也必須有一個連接，該連接必須在實際資料傳輸開始之前建立。 正如我們在前面的課程中討論的，TCP是面向連接的傳輸，而UDP是面向連接的傳輸。 你可以說UDP就是我丟球的地方，你能不能接住它就看你的狀況了。 你願意不願意做這件事不是我的問題，我只是要離開他。
TCP 更像是你和一個人說話並提前警告他你要扔一個球，這樣你們就形成了一種聯繫，然後你扔球，這樣你的伙伴就更有可能準備好接球。 所以 TCP 實際上建立了連接，然後開始進行實際的傳輸。
讓我們看看它是如何創建這樣的連接的。 該協定使用 3 次握手來創建連接。 這不是一個技術性很強的術語，但它長期以來一直用於描述 TCP 連線。 3 次握手由發送裝置發起，客戶端向伺服器發送帶有 SYN 標誌的資料包。
假設前台能看到臉的女孩是設備 A，後台看不到臉的女孩是設備 B。女孩 A 向女孩 B 發送了一個 SYN 數據包，她說： “太好了，誰——那他想跟我交流啊。 所以，我需要回答說我已經準備好溝通了！” 怎麼做？ 人們可以簡單地發回另一個 SYN 封包，然後發送一個 ACK 來指示收到原始 SYN 封包。 但伺服器不是單獨發送 ACK，而是形成一個包含 SYN 和 ACK 的公共資料包，並透過網路傳輸。
此時，裝置 A 已傳送 SYN 封包並收到回 SYN/ACK 封包。 現在設備 A 必須向設備 B 發送 ACK 封包，即確認已收到設備 B 的同意建立通訊。 這樣，兩個裝置都收到了 SYN 和 ACK 封包，現在我們可以說連線已經建立，即使用 TCP 協定完成了 3 階段握手。
接下來我們來看看TCP Windowing技術。 簡單來說，它是 TCP/IP 中用於協商發送方和接收方能力的一種方法。
假設在 Windows 中，我們嘗試將一個大檔案（例如 2 GB 大小）從一個磁碟機傳輸到另一個磁碟機。 傳輸一開始，系統會告知我們檔案傳輸大約需要1年時間。 但幾秒鐘後，系統會自我糾正並說：“哦，等一下，我認為大約需要 6 個月，而不是一年。” 再過一段時間，Windows 會說：“我想我可以在 1 個月內傳輸文件。” 隨後將顯示訊息「1 天」、「6 小時」、「3 小時」、「1 小時」、「20 分鐘」、「10 分鐘」、「3 分鐘」。 事實上，整個文件傳輸過程只需要3分鐘。 這怎麼發生的？ 最初，當您的裝置嘗試與另一台裝置通訊時，它會發送資料包並等待確認。 如果設備等待確認的時間很長，它會想：“如果我必須以這個速度傳輸 2 GB 的數據，大約需要 2 年。” 一段時間後，你的裝置收到一個 ACK 並想：「好吧，我發送了一個資料包並收到了一個 ACK，因此接收者可以收到 1 個資料包。 現在我會嘗試給他寄 10 個數據包，而不是一個。” 發送方發送 10 個資料包，並在一段時間後收到來自接收裝置的 ACK 確認，這表示接收方正在等待下一個，即第 11 個資料包。 發送者想：“太好了，既然接收者一次處理了 10 個數據包，現在我會嘗試向他發送 100 個數據包，而不是 100 個。” 他發送了 101 個資料包，接收者回應說他收到了這些資料包，現在正在等待 XNUMX 個資料包。 因此，隨著時間的推移，傳輸的資料包數量會增加。
這就是為什麼您會看到文件複製時間與最初所述相比迅速減少 - 這是由於傳輸大量資料的能力增強了。 然而，到了某個階段，傳輸量的進一步增加就變得不可能了。 假設您發送了10000 個資料包，但接收方的裝置緩衝區只能接受9000 個資料包。在這種情況下，接收方會發送一個ACK，其中包含以下訊息：「我已收到9000個數據包，現在準備接收9001 個數據包。” 由此，發送方得出結論，接收設備的緩衝區容量只有9000，這意味著從現在開始我一次發送的資料包不會超過9000個。 在這種情況下，發送方快速計算出以 9000 個資料包為一組傳輸剩餘資料量所需的時間，並給出 3 分鐘。 這三分鐘是實際的傳輸時間。 這就是 TCP 窗口化的作用。
這是發送設備最終了解實際網路容量的流量限制機制之一。 您可能想知道為什麼他們不能提前就接收設備的容量達成一致？ 事實上，這在技術上是不可能的，因為網路上有不同類型的設備。 假設您有一台 iPad，它的資料傳輸/接收速度與 iPhone 不同，您可能有不同類型的手機，或者您可能有一台非常舊的電腦。 因此，每個人的網路頻寬都是不同的。
這就是開發 TCP 視窗技術的原因，當資料傳輸以低速開始或以最小數量的資料包傳輸時，逐漸增加流量「視窗」。 您發送5 個資料包、10 個資料包、1000 個資料包、10000 個資料包、XNUMX 個資料包，然後慢慢地越來越大地打開該窗口，直到「打開」達到在特定時間段內發送的最大可能流量。 因此，視窗化的概念是TCP協定操作的一部分。
接下來我們將看看最常見的連接埠號碼。 典型的情況是當您有 1 個主伺服器（可能是一個資料中心）時。 它包括檔案伺服器、Web伺服器、郵件伺服器和DHCP伺服器。 現在，如果其中一台客戶端電腦聯繫位於圖片中間的資料中心，它將開始向客戶端裝置發送檔案伺服器流量。 此流量顯示為紅色，並將在特定伺服器的特定應用程式的特定連接埠上傳輸。
伺服器如何知道某些流量應該流向何處？ 他從目標埠號得知這一點。 如果您查看該幀，您會發現在每次資料傳輸中都會提到目標連接埠號碼和來源連接埠號碼。 您可以看到藍色和紅色流量，藍色流量是 Web 伺服器流量，兩者都流向同一台實體伺服器，該伺服器安裝了不同的伺服器。 如果這是一個資料中心，那麼它使用虛擬伺服器。 那麼他們如何知道紅色流量應該會回到具有該 IP 位址的左側筆記型電腦呢？ 他們透過連接埠號知道這一點。 如果您參考維基百科文章“TCP 和 UDP 連接埠清單”，您會看到它列出了所有標準連接埠號碼。
如果您向下捲動此頁面，您可以看到此列表有多大。 它包含大約 61 個號碼。 000 到 1 之間的連接埠號碼稱為最常見的連接埠號碼。 例如，連接埠1024/TCP用於發送ftp命令，連接埠21用於ssh，連接埠22用於Telnet，即用於發送未加密的訊息。 非常流行的連接埠 23 透過 HTTP 承載數據，而連接埠 80 透過 HTTPS 承載加密數據，這與 HTTP 的安全版本類似。
有些連接埠專用於 TCP 和 UDP，有些連接埠會根據連線是 TCP 還是 UDP 執行不同的任務。 因此，正式的 TCP 連接埠 80 用於 HTTP，非正式的 UDP 連接埠 80 用於 HTTP，但使用不同的 HTTP 協定 - QUIC。
因此，TCP 中的連接埠號碼並不總是具有與 UDP 中相同的作用。 您不需要記住這個列表，記住它是不可能的，但是您需要知道一些流行和最常見的連接埠號碼。 正如我所說，其中一些端口具有官方用途（在標準中進行了描述），而另一些則具有非官方用途，如 Chromium 的情況。
因此，此表列出了所有常見連接埠號，這些連接埠號碼用於在使用特定應用程式時發送和接收流量。
現在讓我們根據我們所知的少量資訊來看看資料如何在網路中移動。 假設計算機 10.1.1.10 想要聯絡位址為 30.1.1.10 的這台電腦或這台伺服器。 每個設備的 IP 位址下面是其 MAC 位址。 我給的範例是僅包含最後 4 個字元的 MAC 位址，但實際上它是一個包含 48 個字元的 12 位十六進位數字。 由於每個數字都由 4 位組成，因此 12 個十六進位數字代表一個 48 位數字。
我們知道，如果這個設備想要聯絡這個伺服器，必須先完成3次握手的第一步，也就是發送SYN封包。 發出此要求時，電腦 10.1.1.10 將指定 Windows 動態建立的來源連接埠號碼。 Windows 隨機選擇 1 到 65,000 之間的連接埠號碼。 但由於 1 到 1024 範圍內的起始數字眾所周知，在這種情況下，系統將考慮大於 25000 的數字並創建一個隨機源端口，例如數字 25113。
接下來，系統將向資料包添加目標端口，在本例中為端口 21，因為嘗試連接到該 FTP 伺服器的應用程式知道它應該發送 FTP 流量。
接下來，我們的計算機說：“好的，我的 IP 位址是 10.1.1.10，我需要聯絡 IP 位址 30.1.1.10。” 這兩個位址也包含在封包中以形成 SYN 請求，而這個封包直到連線結束才會改變。
我希望您透過該影片了解資料如何在網路中移動。 當發送請求的電腦看到來源 IP 位址和目標 IP 位址時，它就會知道目標位址不在該本機網路上。 我忘了說這些都是 /24 IP 位址。 因此，如果您查看 /24 IP 位址，您會發現電腦 10.1.1.10 和 30.1.1.10 不在同一網路上。 因此，發送請求的電腦知道，為了離開該網絡，它必須聯繫在路由器介面之一上配置的 10.1.1.1 網關。 它知道自己應該存取 10.1.1.1，並且知道自己的 MAC 位址 1111，但不知道網關 10.1.1.1 的 MAC 位址。 他在做什麼？ 它會傳送一個廣播 ARP 請求，網路上的所有裝置都會收到，但只有 IP 位址為 10.1.1.1 的路由器才會回應它。
路由器將以其 AAAA MAC 位址進行回應，來源 MAC 位址和目標 MAC 位址也將放置在此訊框中。 一旦幀準備好，在離開網路之前將執行 CRC 資料完整性檢查，這是一種用於查找校驗和以檢測錯誤的演算法。
循環冗餘 CRC 意味著從 SYN 到最後一個 MAC 位址的整個幀都透過哈希演算法（例如 MD5）運行，從而產生哈希值。 然後將雜湊值或 MD5 校驗和放置在幀的開頭。
我將其標記為 FCS/CRC，因為 FCS 是幀校驗序列，是一個四位元組的 CRC 值。 有些人使用名稱 FCS，有些人使用名稱 CRC，所以我只包含這兩個名稱。 但基本上它只是一個哈希值。 需要確保透過網路接收的所有資料不包含錯誤。 因此，當該訊框到達路由器時，路由器要做的第一件事就是計算校驗和本身，並將其與接收到的訊框包含的 FCS 或 CRC 值進行比較。 這樣他就可以檢查透過網路接收的資料是否包含錯誤，然後從訊框中刪除校驗和。
接下來，路由器將查看 MAC 位址並說：“好吧，MAC 位址 AAAA 意味著該訊框是發給我的”，然後刪除訊框中包含 MAC 位址的部分。
查看目標 IP 位址 30.1.1.10，他就會明白該封包不是發給他的，必須進一步通過路由器。
現在路由器「認為」它需要查看位址為 30.1.1.10 的網路所在的位置。 我們還沒有涵蓋路由的完整概念，但我們知道路由器有一個路由表。 該表有一個位址為 30.1.1.0 的網路條目。 您還記得，這不是主機 IP 位址，而是網路識別碼。 路由器會「認為」它可以透過路由器 30.1.1.0 到達位址 24/20.1.1.2。
你可能會問，他怎麼知道這些？ 請記住，如果您作為管理員配置了靜態路由，那麼它會從路由協定或您的設定中知道這一點。 但無論如何，該路由器的路由表包含正確的條目，因此它知道應該將此封包傳送到 20.1.1.2。 假設路由器已經知道目標 MAC 位址，我們將繼續轉送封包。 如果他不知道這個位址，他會再次啟動ARP，接收路由器的MAC位址20.1.1.2，發送訊框的過程將再次繼續。
因此，我們假設它已經知道 MAC 位址，那麼我們將獲得 BBB 來源 MAC 位址和 CCC 目標 MAC 位址。 路由器再次計算 FCS/CRC 並將其放置在訊框的開頭。
然後，它透過網路發送該幀，該幀到達路由器 20.1.12，檢查校驗和，確保資料未損壞，並刪除 FCS/CRC。 然後，它「截斷」MAC 位址，查看目標並發現它是 30.1.1.10。 他知道這個位址連接到他的介面。 重複相同的幀形成過程，路由器會新增來源和目標 MAC 位址值，進行雜湊，將雜湊附加到幀並將其透過網路發送。
我們的伺服器最終收到發送給它的 SYN 請求後，會檢查雜湊校驗和，如果封包不包含錯誤，則會刪除雜湊。 然後，他刪除 MAC 位址，查看 IP 位址，並意識到該封包是發給他的。
之後，它會截斷與 OSI 模型第三層相關的 IP 位址並查看連接埠號碼。
他看到連接埠 21，這意味著 FTP 流量，看到 SYN，因此知道有人正在嘗試與他通訊。
現在，根據我們對握手的了解，伺服器 30.1.1.10 將建立一個 SYN/ACK 封包並將其發送回電腦 10.1.1.10。 裝置 10.1.1.10 收到此資料包後，將建立 ACK，並以與 SYN 資料包相同的方式將其透過網路傳遞，伺服器收到 ACK 後將建立連線。
您應該知道的一件事是，這一切都發生在不到一秒鐘的時間內。 這是一個非常非常快的過程，我試著放慢速度，以便讓您清楚一切。
我希望您發現本教程中學到的內容很有用。 如果您有任何疑問，請寫信給我： [電子郵件保護] 或在此影片下留下問題。
從下一課開始，我將從 YouTube 中選擇 3 個最有趣的問題，我將在每個影片的末尾回顧這些問題。 從現在開始，我將有一個“熱門問題”部分，因此我將發布一個問題以及您的名字並即時回答。 我認為這將是有益的。
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， 在我們為您發明的獨特的入門級服務器模擬上，Habr 用戶可享受 30% 的折扣： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
VPS (KVM) E5-2650 v4（6 核）104GB DDR240 1GB SSD XNUMXGbps 免費至夏季 支付六個月的費用時，您可以訂購 .
戴爾R730xd便宜2倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com