在开始今天的视频教程之前,我要感谢所有为我的课程在 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% 的折扣:
VPS (KVM) E5-2650 v4(6 核)104GB DDR240 1GB SSD XNUMXGbps 免费至夏季 支付六个月的费用时,您可以订购
戴尔R730xd便宜2倍? 只有这里
来源: habr.com