文章目录
- 计算机网络的层次结构
- 应用层
- DNS
- HTTP协议
- HTTP请求响应过程
- 运输层
- TCP协议
- TCP协议面向连接实现
- TCP的三次握手连接
- TCP的四次挥手断开连接
- TCP协议可靠性实现
- TCP的流量控制
- TCP的拥塞控制
- TCP的重传机制
- UDP协议
- 网际层
- IP协议(主机与主机)
- IP地址的分类
- IP地址和路由控制
- 公有IP地址
- 私有IP地址
- 路由控制
- IP分片与重组
- DHCP协议
- NAT协议
- 数据链路层
- MAC地址
- ARP协议
- 物理层
- 计算机网络综合
计算机网络的层次结构
我们用一个很简单的例子总体宏观的讲述一下计算机网络的体系:
应用层(Application Layer):
- 类比: 你的出行目的和服务需求。
- 作用: 应用层就像是你的出行目的和需要的服务,例如选择旅游目的地、规划行程、订票、导航等。它关注的是最终用户的需求和应用服务。
运输层(Transport Layer):
- 类比: 货物运输和物流服务。
- 作用: 运输层就像是确保货物在运输过程中安全、有序地到达目的地,管理货物的流量、错误处理和重新发送。它负责端到端的通信服务。
网际层(Network Layer):
- 类比: 导航系统和路由选择。
- 作用: 网际层就像是车辆选择正确的道路和路径,通过交汇处和路口,到达目的地。它关注的是整体的路线规划和节点之间的通信。
数据链路层(Data Link Layer):
- 类比: 交通规则和道路标志。
- 作用: 数据链路层就像是确保车辆在道路上按照规则行驶,遵守交通标志和信号,防止碰撞和混乱。这一层负责直接相邻车辆(节点)之间的通信。
物理层(Physical Layer):
- 类比: 公路的基础设施和道路条件。
- 作用: 物理层就像是确保高速公路的质量良好、平整,没有坑洼或障碍物的部分。它关注的是实际的道路和交通的物理特性。
应用层
DNS
DNS解析过程如下图所示:
我们可以举一个形象的例子来说明DNS域名解析的过程:
想象一下你正在图书馆寻找一本特定的书籍,而图书馆的书架上没有详细的书名和作者信息。在这个场景中,你需要问图书管理员找到你需要的书。
-
你的需求(用户输入域名): 你想要一本特定的书,但是你不知道它在哪个书架上。
-
图书管理员(本地域名解析器): 你向图书管理员询问,她知道图书馆内部的布局,并告诉你去哪个区域找书。
- 对应DNS:本地域名解析器向本地域名服务器发起查询。
-
分层查询(图书管理员询问其他领域专员): 如果图书管理员也不知道具体位置,她可能会向馆内的专门领域人员咨询。这个过程可能需要几轮的询问,每次都在更高层次的领域中寻找答案。
- 对应DNS:本地域名服务器向根域名服务器发起查询,再迭代向下询问TLD服务器和 authoritative name server。
-
最终定位(找到书籍位置): 最终,通过递归和迭代的过程,你找到了这本书的具体位置。
- 对应DNS:最终 authoritative name server 返回域名对应的IP地址给本地域名服务器。
-
记忆(下次更容易找到): 下次你再需要同一本书时,你可能记得它的具体位置,不再需要问图书管理员。
- 对应DNS:本地域名解析器将解析结果返回给用户,同时将结果存储在本地缓存中,以便下次查询时直接使用。
这个图书馆的例子类比了DNS的递归查询和迭代查询过程,以及分布式的信息咨询。就像在DNS中,如果某个层次的服务器不知道答案,它会向更高层次的服务器询问,直到找到最终答案。这个过程同时也突显了DNS中缓存的作用,就像你在图书馆里找到书的位置后,可以记住它以便将来更容易找到。
HTTP协议
HTTP是应用层协议,用于在客户端和服务器之间传输超文本数据。它是Web应用中最常用的协议之一,负责在Web浏览器和Web服务器之间传递信息。
HTTP报文格式如下图所示:
HTTP请求响应过程
HTTP请求响应过程如下所示:
-
DNS解析:在发起HTTP请求之前,如果请求的域名不在本地缓存中,需要进行DNS解析。本地域名解析器向DNS服务器发起查询,获取域名对应的IP地址。
-
建立TCP连接:使用获取到的目标服务器的IP地址,客户端与服务器建立TCP连接。这通常涉及到三次握手,确保连接的可靠性。
-
发送HTTP请求:客户端通过建立的TCP连接向服务器发送HTTP请求。请求的内容包括请求行、请求头部、空行(CRLF),以及可选的请求体(对于POST等有请求体的请求)。
-
服务器处理请求:服务器收到HTTP请求后,根据请求行中的方法和URI等信息,进行相应的处理。这可能涉及到查询数据库、执行应用程序逻辑等操作。
-
服务器发送HTTP响应:服务器生成HTTP响应报文,包括响应状态行、响应头部、空行(CRLF),以及可选的响应体。响应状态行包含了HTTP协议版本和状态码,响应头部包含了服务器信息、响应的内容类型等信息。
-
传输响应数据:服务器通过已建立的TCP连接向客户端发送HTTP响应。响应的内容根据响应体的内容类型(Content-Type)而异,可能是HTML页面、JSON数据、图片等。
-
客户端接收响应:客户端接收到服务器的HTTP响应后,根据响应状态码判断请求的成功或失败。同时,客户端解析响应头部,获取服务器传递的信息。
-
关闭连接:根据需要,连接可以保持开放以便进行其他请求,或者在一定时间后关闭。HTTP/1.1默认使用持久连接,允许在同一连接上发送多个请求和接收多个响应。
-
浏览器渲染(对于Web页面请求):如果是Web页面请求,浏览器将解析HTML内容,并加载其中的资源(如CSS、JavaScript、图片等),最终渲染出用户可见的页面。
让我们以订购咖啡的过程来形象地说明HTTP请求和响应的流程。
- 客户需求(订购咖啡):客户想要订购一杯咖啡,但不知道具体的咖啡店位置。
- 导航(DNS解析):客户首先需要导航到咖啡店,这就好比进行DNS解析,将咖啡店域名转换为实际IP地址。
- 到达咖啡店(建立TCP连接):客户到达咖啡店后,与店员建立联系。这个过程相当于通过TCP连接与服务器建立通信。
- 点咖啡(发送HTTP请求):客户告诉店员他要什么咖啡,这就像发送HTTP请求,其中包括了请求行和头部信息。
- 处理订单(服务器处理请求):店员接到客户的订单后,制作咖啡。这类似于服务器处理HTTP请求,执行相应的操作。
- 告知取货位置(发送HTTP响应):店员告诉客户咖啡已经准备好,取货的位置在哪。这就像服务器发送HTTP响应,包含了响应行和头部信息。
- 取咖啡(接收HTTP响应):客户按照店员的指示去取咖啡,这类似于浏览器接收到HTTP响应后,根据响应的内容来进行相应的操作。
- 完成订购,离开咖啡店(关闭连接):
客户选择离开咖啡店。这类似于在HTTP中,连接可以保持开放以便进行其他请求,或者在一定时间后关闭。HTTP/1.1默认使用持久连接,但在特定情况下可能会关闭连接。 - 品尝咖啡(浏览器渲染):客户喝上一口咖啡,享受美好的味道。这就好比浏览器解析HTML内容,并加载其中的资源,最终渲染出用户可见的页面。
运输层
TCP协议
TCP是一种面向连接的(一对一)、可靠的、基于字节流的传输层协议。它在计算机网络中负责提供可靠的、有序的数据传输。
TCP报文格式如下所示:
TCP标记字段如下所示:
TCP协议面向连接实现
TCP的三次握手连接
TCP三次握手连接示意图如下所示:
让我们用邮寄信件的场景来解释两次、三次和四次握手的区别以及可能出现的问题:
两次握手的场景:
-
寄信(第一次握手): 你写好信件并将信封寄出,表达了寄信的愿望。
-
送信员确认(第二次握手): 送信员收到信并回信说:“我已收到你的信件。”表示确认寄信的请求。
问题: 在这个场景中,你寄信后就得到了确认,看似连接已经建立。然而,问题在于你并不知道信是否已经被正确投递,因为送信员可能还没来得及将信递交给收信人。
三次握手的场景:
-
寄信(第一次握手): 你写好信件并将信封寄出,表达了寄信的愿望。
-
送信员确认(第二次握手): 送信员收到信并回信说:“我已收到你的信件,并准备将其递交给收信人。”表示确认寄信的请求。
-
信成功递交(第三次握手): 送信员将信成功递交给收信人,并回信给你说:“我已将信成功递交给收信人。”表示确认信已成功投递。
优势: 通过第三次握手,你知道信已经被成功递交,建立了更为可靠的连接。
四次握手的场景:
-
寄信(第一次握手): 你写好信件并将信封寄出,表达了寄信的愿望。
-
送信员确认(第二次握手): 送信员收到信并回信说:“我已收到你的信件,并准备将其递交给收信人。”表示确认寄信的请求。
-
信成功递交(第三次握手): 送信员将信成功递交给收信人,并回信给你说:“我已将信成功递交给收信人。”表示确认信已成功投递。
-
信被接收(第四次握手): 收信人接收到信并回信给你说:“我已成功收到你的信。”表示确认信已被接收。
问题: 通过第四次握手,虽然确保了对方成功接收并阅读了信,但在一些情况下,这可能导致了资源的浪费。每一次握手或挥手都需要经过一定的网络传输和处理时间,因此四次挥手相比三次握手在关闭连接时会增加一定的时延,占用更多系统资源,并增加了复杂性。
总结:
- 两次握手可能存在的问题在于确认建立连接后,双方并不一定了解对方的真实状态。
- 三次握手通过增加一次确认,提高了连接的可靠性,确保信息的双向确认。
- 四次挥手相较于三次握手,在关闭连接时可能导致资源的浪费,包括时延增加、占用更多系统资源以及增加了复杂性。
TCP的四次挥手断开连接
TCP四次挥手断开连接示意图如下所示:
当我们使用关灯睡觉的场景来解释TCP四次挥手时,可以更加形象地理解:
-
关灯前的准备(第一次挥手): 你决定要睡觉了,于是关掉了房间的灯,表示你希望结束一天的活动。
-
房间感知灯光消失(第二次挥手): 房间内的感应器检测到灯光的消失,开始准备关机,表示它已经接收到了结束的请求。
-
关机完成(第三次挥手): 房间内的设备完成了关机的准备工作,发送一个信号给你,表示已经做好了关闭的准备,可以完全进入休眠状态。
-
休眠确认(第四次挥手): 你感觉到房间已经完全安静,确认灯光已经熄灭,表示房间已经完全进入休眠状态,双方都确认关闭完成。
这个例子中,第四次挥手是你对房间关闭请求的最终确认。在TCP连接中,四次挥手确保双方都明确了终止连接的意愿,并最终确认连接的完全关闭。这可以防止在连接关闭后可能出现的数据传输中的滞留或错误。
如果我们在关灯睡觉的场景中省略一次挥手,即使用三次挥手,可能会导致一些问题:
-
关灯前的准备(第一次挥手): 你决定要睡觉了,于是关掉了房间的灯,表示你希望结束一天的活动。
-
房间感知灯光消失(第二次挥手): 房间内的感应器检测到灯光的消失,开始准备关机,表示它已经接收到了结束的请求。
-
关机完成(第三次挥手): 房间内的设备直接完成了关机的准备工作,并没有发送额外的信号给你,因为省略了一次挥手。
在这种情况下,可能会出现以下问题:
-
状态不确定: 你关掉灯后,并没有得到房间已经完全进入休眠状态的确认。因为省略了一次挥手,你无法确保房间内的设备已经完全准备好关闭。
-
潜在滞留: 由于没有最终的确认,可能会导致房间内的设备在关闭过程中出现滞留,例如未完成的任务或数据未保存。
在TCP连接中,省略挥手可能导致类似的问题。为了确保连接的可靠关闭,TCP使用四次挥手来进行最终的确认,避免可能出现的状态不确定和数据滞留。
TCP协议可靠性实现
TCP的流量控制
TCP协议中的流量控制是一种机制,用于管理数据的传输速率,确保发送方和接收方之间的通信保持稳定,防止因为接收方处理不及时而导致的数据丢失或拥塞。
流量控制的核心目标是协调发送方和接收方之间的数据传输速率,以避免网络拥塞、数据丢失或过度等待。主要通过以下两个机制来实现:
-
滑动窗口(Sliding Window): 滑动窗口是TCP流量控制的关键概念之一。发送方和接收方都有一个窗口大小的缓冲区,通过滑动窗口的方式来动态调整可发送的数据量。接收方通过通告窗口大小告知发送方,发送方根据窗口大小调整发送的数据量,以确保不会超过接收方的处理能力。
-
TCP窗口大小的动态调整: 接收方可以通过TCP报文中的窗口字段来通告其当前的可接收窗口大小。发送方根据这个信息来动态调整发送的数据量。如果接收方处理能力较强,窗口大小可能会增大,允许发送方发送更多的数据。如果接收方处理能力较弱,窗口大小可能减小,限制发送方发送的数据量。
流量控制的工作流程如下:
-
建立连接: 在TCP连接建立阶段,双方会协商初始的窗口大小。
-
数据传输: 发送方根据接收方通告的窗口大小来动态调整发送的数据量。发送的数据不能超过接收方的窗口大小。
-
动态调整: 窗口大小可以根据网络和接收方的状况进行动态调整。如果接收方处理能力较强,窗口可能增大;反之,窗口可能减小。
-
连接终止: 在TCP连接终止阶段,双方仍然可以进行流量控制,确保最后的数据传输完整。
通过流量控制,TCP协议能够适应不同网络和主机之间的传输速率差异,保证可靠的数据传输,同时避免了拥塞和数据丢失的问题。
让我们通过指挥交通的例子来更详细地解释TCP流量控制的工作流程:
场景: 想象你是一名交警(发送方),负责指挥交叉路口的车辆流动。交叉路口上的车辆就是要传输的数据,而你的指挥动作就是发送的数据。
-
车辆通过的速度(发送方的发送速率): 你向交叉路口中的车辆发出指挥信号的速度是你的发送速率。这表示你有多快能够指挥车辆通过。
-
路口的通行能力(接收方的处理速率): 交叉路口有一个固定的通行能力,即每分钟能够容纳多少车辆通过。这代表了接收方的处理速率。
-
指挥手势的数量(发送方的窗口大小): 你一次发出的指挥手势数量就像是窗口大小,表示你能够一次性发送的指挥动作数量。如果你一次挥动手臂能够指挥3辆车通过,那么你的窗口大小就是3。
-
路口通行能力的通告(接收方的通告窗口大小): 你向交叉路口的管理中心通告每分钟可以指挥多少车辆通过。这就是接收方通告窗口大小的概念。
-
动态调整指挥手势的数量(动态调整窗口大小): 如果交叉路口的通行能力提高,你可以逐渐增大一次性发出的指挥手势数量,以便更多车辆可以同时通过。
-
通告新的通行能力: 如果交叉路口的通行能力发生变化,你会向管理中心通告新的每分钟通行车辆数量,以便及时调整你的指挥手势数量。
这个指挥交通的例子中,你通过动态调整指挥手势的数量(窗口大小),根据路口的通行能力(通告窗口大小)来协调车辆的流动,以确保交通顺畅而不会因为车辆过多而堵塞。这种动态的流量控制机制使得指挥者和路口之间能够更好地协作,避免了交通混乱。
TCP的拥塞控制
TCP协议中的拥塞控制是一种机制,用于在网络中有效地管理拥塞,防止网络过载,以确保数据传输的可靠性和效率。拥塞控制的目标是避免网络拥塞,即网络中的流量过大,导致丢包、延迟增加和网络性能下降。
拥塞控制的主要机制包括:
-
拥塞窗口(Congestion Window): 发送方维护一个拥塞窗口的大小,该窗口限制了在任何时刻可以发送到网络中的数据量。拥塞窗口的大小是动态调整的,根据网络的拥塞状况进行调整。
-
慢启动(Slow Start): 在连接刚开始时,发送方先以一个较小的拥塞窗口开始发送数据,然后随着时间的推移逐渐增大窗口的大小,直到达到一个阈值。这有助于避免在网络开始时发送大量数据导致拥塞。
-
拥塞避免(Congestion Avoidance): 一旦拥塞窗口达到了阈值,发送方进入拥塞避免阶段。在这个阶段,拥塞窗口的增长变得更为缓慢,以避免快速增大窗口导致拥塞。
-
快速重传和快速恢复: 如果发送方检测到网络中有数据包丢失,它会采取快速重传和快速恢复的机制,尽快重传丢失的数据并降低拥塞窗口的大小。
-
超时重传: 如果发送方在一定时间内没有收到确认,它会认为数据包可能丢失,并触发超时重传,同时减小拥塞窗口的大小。
让我们继续使用指挥交通的例子,来解释TCP拥塞控制的主要机制:
-
拥塞窗口(Congestion Window):
- 类比为: 你手中的指挥棒和手势。
- 解释: 你手中的指挥棒和手势代表了你一次性能够指挥通过的车辆数量,即拥塞窗口的大小。这个窗口限制了在任何时刻可以通过路口的车辆数量。
-
慢启动(Slow Start):
- 类比为: 刚开始时逐渐增加指挥棒的幅度。
- 解释: 在慢启动阶段,你开始时只允许少量车辆通过,就像逐渐增加指挥棒的幅度。这有助于避免在路口刚开始时就引发拥塞。
-
拥塞避免(Congestion Avoidance):
- 类比为: 控制指挥棒的幅度,确保逐渐增加。
- 解释: 一旦路口的流量逐渐增多,你不再采用慢启动,而是控制指挥棒的幅度,确保逐渐增加车辆通过的数量,以避免引发拥塞。
-
快速重传:
- 类比为: 交通警察在发现车辆违规或发生事故时,立即通过手势示意进行纠正。
- 解释: 在TCP中,当发送方检测到数据包丢失时,通过快速重传机制,立即重发丢失的数据包,避免等待超时,从而及时纠正错误,提高传输效率。
-
快速恢复:
- 类比为: 交通警察在解决交通阻塞后,逐步放行车辆,恢复正常的交通流。
- 解释: TCP的快速恢复机制允许在发生快速重传后,通过逐步增加拥塞窗口来恢复数据传输速率,类似于逐步恢复正常交通流,以避免再次引发拥塞。
-
超时重传:
- 类比为: 如果车辆长时间没有动静,采取超时措施。
- 解释: 如果一些车辆在路口停滞时间过长,你可能采取超时措施,例如通过手势提示司机等待更长时间或寻找其他路径,就像TCP中的超时重传机制。
-
动态调整拥塞窗口:
- 类比为: 根据路口状况动态调整指挥手势的幅度。
- 解释: 你不断观察路口状况,根据需要调整手势的幅度,以确保路口不会再次拥塞。这类似于TCP动态调整拥塞窗口大小以适应网络状况。
通过这个指挥交通的例子,可以更具体地理解TCP拥塞控制的主要机制,以及这些机制是如何通过模拟交通流量来确保网络顺畅、避免拥塞的。
拥塞控制的工作流程如下:
-
初始阶段: 在连接刚建立时,拥塞窗口设置为一个较小的值,例如1或2。
-
慢启动: 发送方以指数级增长拥塞窗口,快速向网络发送数据。
-
拥塞避免: 一旦拥塞窗口达到了一个阈值,发送方切换到拥塞避免阶段,拥塞窗口以线性增长。
-
数据丢失检测: 发送方通过接收到的确认和超时检测是否有数据包丢失。
-
快速重传和快速恢复: 如果检测到数据包丢失,采取快速重传和快速恢复机制,尽快重传数据。
-
动态调整拥塞窗口: 根据网络状况,动态调整拥塞窗口的大小,确保在网络容量允许的范围内进行数据传输。
拥塞控制通过这些机制有效地管理网络流量,避免了拥塞的发生,从而提高了TCP协议在不同网络环境下的性能和可靠性。
让我们通过指挥交通的例子来形象地解释TCP拥塞控制的工作流程:
假设场景: 你是一个交通警察(发送方),负责在一个繁忙的十字路口指挥交通。车辆流量大致代表了网络中的数据流量。
-
初始阶段(拥塞窗口小): 当你开始指挥交通时,初始阶段你只允许几辆车通过,这相当于刚开始连接时的拥塞窗口设置为一个小值。
-
慢启动(拥塞窗口指数增长): 随着交通的逐渐流畅,你决定逐渐增加过路车辆的数量,就像慢启动阶段拥塞窗口指数增长一样。
-
拥塞避免(拥塞窗口线性增长): 一旦路口流量逐渐增多,你意识到不能一直按照指数增长的方式增加车辆通过,于是你改变策略,以较为线性的方式增加过路车辆,就像拥塞避免阶段的拥塞窗口线性增长。
-
检测交通堵塞: 在某一时刻,你可能会观察到路口有些拥堵,车辆排队较长,就像TCP检测到网络拥塞一样。
-
采取措施(快速重传和快速恢复): 你决定立即采取措施,例如,让部分车辆优先通过,以解决拥堵问题,就像TCP中的快速重传和快速恢复机制,尽快恢复正常流程。
-
动态调整交通流量(动态调整拥塞窗口): 为了更好地管理交通,你决定根据交通状况动态调整每次放行的车辆数,确保路口不会再次拥堵,就像TCP动态调整拥塞窗口大小以适应网络状况。
-
保持交通流畅: 在整个过程中,你不断观察路口的状况,采取适当的措施,以确保交通持续流畅。这类似于TCP通过拥塞控制机制不断调整拥塞窗口,以保持网络的稳定和高效。
通过这个指挥交通的例子,你可以形象地理解TCP拥塞控制的工作流程,通过动态调整发送速率,避免网络拥塞,确保数据传输的顺畅和可靠性。
TCP的重传机制
TCP协议的重传机制是为了确保可靠的数据传输,即当发送方发送的数据包未能在合理的时间内收到确认时,会触发重传。这样可以应对网络中可能发生的丢包、延迟或乱序等问题。
TCP的重传机制主要包括以下步骤:
-
发送数据包: 发送方通过TCP协议发送数据包给接收方。
-
等待确认: 发送方等待接收方发送确认(ACK)信号。在这个等待期间,如果发送方没有及时收到确认,就会认为数据包可能丢失了。
-
超时检测: 如果在一定的时间内(超时时间内)没有收到确认,发送方会认为数据包丢失,触发超时检测。
-
触发重传: 一旦触发了超时检测,发送方会重新发送未收到确认的数据包。这是TCP的基本的超时重传机制。
-
快速重传: 为了更快地应对丢失的情况,TCP还引入了快速重传机制。如果发送方在一次收到三个重复的确认(接收方多次确认相同的数据)时,就会立即重传对应的丢失的数据包,而不必等待超时。
这样的重传机制确保了数据的可靠性。通过在适当的时候重传数据包,TCP可以应对网络中的不确定性,提高了数据传输的成功率。然而,过度的重传可能会导致网络资源浪费,因此TCP的实现通常会采用一些策略来优化重传机制,例如指数退避等。
让我们通过寄信的比喻来解释TCP的重传机制:
-
寄信过程: 假设你寄了一封重要的信给你的朋友,但邮递员在送信的过程中可能会遇到一些问题,比如邮件可能会丢失、被延迟送达,或者顺序混乱。
-
等待回执: 你寄信后等待朋友的回执,表示他已经收到了信。在网络通信中,这类似于TCP发送数据包后等待接收方的确认。
-
未收到回执: 如果一段时间内没有收到朋友的回执,你会怀疑邮件可能遗失了。在TCP中,如果发送方未能在合理的时间内收到确认,就会怀疑数据包可能丢失。
-
超时重传: 为了确保信件的可靠送达,你会决定重新寄一封相同的信。在TCP中,这相当于超时重传机制,即发送方在等待确认的过程中,如果超过了设定的时间,就会重新发送相同的数据包。
-
确认收到: 如果朋友最终收到了两封相同的信,他会回执一份确认,表明他已经收到了信。在TCP中,接收方收到数据后发送确认,告知发送方数据已成功接收。
-
快速重传: 如果你的朋友连续三次回执同一封信,你可能会怀疑邮递员只是在一段路程上反复走动。在TCP中,如果发送方在短时间内接收到相同的确认三次,就会立即重传未确认的数据包,这就是快速重传机制。
通过这个寄信的例子,可以更形象地理解TCP的重传机制,它通过重新发送未得到确认的数据包,以确保数据在网络中的可靠传输。
UDP协议
UDP是一种面向无连接的传输层协议,与TCP相比,UDP更加轻量,不提供可靠性和有序性。它被设计用于那些对实时性要求较高、能够容忍一些数据丢失的应用场景。
以下是UDP协议的主要特点和用途:
-
无连接性: UDP是无连接的,不需要在发送数据之前建立连接。每个UDP数据包都是相互独立的,不受之前或之后数据包的影响。
-
不可靠性: UDP不提供数据可靠性的保证,因此无法确保数据包的到达或按顺序到达。如果某个数据包在传输过程中丢失,UDP不会进行重传。
-
轻量和高效: 由于不需要建立连接、不提供可靠性,UDP协议的头部开销相对较小,使其成为一种轻量、高效的协议。
-
实时性要求高: UDP适用于对实时性要求较高的应用,如音频和视频流传输,实时游戏等。在这些场景下,轻微的数据丢失可以被接受,但重要的是能够及时地传输数据。
-
广播和多播支持: UDP支持广播和多播,允许将数据一次性发送给多个接收方。这对于一些实时通信或流媒体应用非常有用。
-
应用场景: UDP适用于一些简单的通信场景,如DNS查询、SNMP、DHCP等。它还常用于语音通话、视频会议等实时应用,以及在线游戏等需要快速响应的场景。
UDP的简单性和高效性使其在特定的应用场景中得到广泛应用。然而,由于它的不可靠性,对于那些要求数据完整性和有序性的应用,通常会选择使用TCP。UDP和TCP是两种互补的协议,根据应用的需求选择合适的协议是很重要的。
UDP协议报文格式如下图所示:
网际层
IP协议(主机与主机)
IP协议是一种主要用于互联网的网络层协议,它定义了在网络上进行数据通信的规则。IP协议的主要功能是为数据包提供寻址和路由,使其能够在网络中正确地传递。
IP协议报文格式如下图所示:
IP地址的分类
IP地址根据其分配和管理方式,可以分为不同的类别。在过去,IP地址分为五个主要的类别:A、B、C、D、E。每个类别都有不同的地址范围,用于满足不同规模的网络需求。然而,随着互联网的发展,CIDR的引入使得IP地址的分配更加灵活,不再严格按照类别进行。
以下是过去的IP地址分类:
-
类A地址:
- 范围:1.0.0.0 到 126.255.255.255
- 特点:第一位是0,剩余31位可用。适用于大型网络,可容纳最多的主机数。
-
类B地址:
- 范围:128.0.0.0 到 191.255.255.255
- 特点:前两位是10,剩余30位可用。适用于中等规模的网络,可以容纳中等数量的主机。
-
类C地址:
- 范围:192.0.0.0 到 223.255.255.255
- 特点:前三位是110,剩余29位可用。适用于小型网络,容纳较少数量的主机。
-
类D地址:
- 范围:224.0.0.0 到 239.255.255.255
- 特点:前四位是1110,用于多播(Multicast)通信。
-
类E地址:
- 范围:240.0.0.0 到 255.255.255.255
- 特点:前四位是1111,保留用途,用于实验和研究。
在CIDR引入后,IP地址的分配更加灵活,不再受到固定的类别划分。CIDR使用前缀长度表示地址的网络前缀,例如,192.168.1.0/24,其中“/24”表示前缀有24位。这种方式允许更精细地控制地址的分配和路由。
我们如何划分主机号和网络号?
划分主机号和网络号的过程使用子网掩码,按照以下步骤进行:
-
选择IP地址: 选择一个IP地址作为划分子网的起点。
-
确定子网掩码: 根据网络规模和需要划分的子网数量,确定子网掩码的位数。这些位用于表示网络号,剩余的是主机号。
-
应用子网掩码: 将子网掩码与选定的IP地址进行逻辑与运算,得到网络号和主机号。
-
确定每个子网的可用范围: 每个子网都有一个网络号和广播地址,确定每个子网的可用IP范围。
-
重复: 如果需要进一步划分子网,可以重复上述步骤。
例子:
11000000.10101000.00000001.00001010 (192.168.1.10)
11111111.11111111.11111111.00000000 (255.255.255.0)
-----------------------------------
11000000.10101000.00000001.00000000 (192.168.1.0,网络号)
IP地址和路由控制
公有IP地址
公有IP地址是指在全球范围内唯一分配给互联网上的设备的IP地址。这些IP地址是由互联网寻址与分配机构(如亚太网络信息中心、美国互联网数字地址分配机构等)进行分配和管理的,确保在全球范围内不发生冲突。
以下是公有IP地址的特点:
-
全球唯一性: 公有IP地址在全球范围内是唯一的,每个公有IP地址只能分配给一个设备。这确保了在互联网上的设备能够被唯一标识,避免了冲突。
-
直接可路由: 公有IP地址是可以直接被互联网路由器识别和传递的。互联网上的设备使用公有IP地址可以直接进行端到端的通信,无需经过网络地址转换(NAT)等中间步骤。
-
用于服务器和对外服务: 公有IP地址通常被分配给服务器、网络设备和需要直接与互联网通信的设备。这些设备需要在互联网上提供服务,如网站、邮件服务器等。
-
限制和稀缺性: 公有IP地址的数量是有限的,尤其是在IPv4协议下。由于互联网的快速发展,公有IPv4地址的供应变得紧张,IPv6的推广正在逐渐解决这一问题。
-
可追踪性: 公有IP地址的唯一性和全球性可追踪设备在互联网上的活动。这在一些安全和监管方面具有重要作用,但也引发了隐私和安全方面的一些关切。
-
成本较高: 获取公有IP地址通常需要额外的费用,特别是在IPv4地址稀缺的情况下。一些企业和服务提供商可能需要支付较高的费用以获得足够的公有IP地址来支持其业务需求。
私有IP地址
私有IP地址是指在局域网(LAN)内部使用的、不直接暴露在互联网上的IP地址。这些地址被保留在特定的地址范围内,用于内部网络通信,而不用于全球互联网路由。私有IP地址的使用有助于提高网络安全性和地址分配的灵活性。
以下是私有IP地址的主要特点:
-
非全球唯一性:
- 私有IP地址在全球范围内不唯一,可以在不同的局域网中重复使用。这是因为私有IP地址是为了内部网络通信而保留的,不直接参与全球互联网的路由。
-
局限于特定范围: 私有IP地址的范围是在IPv4中的三个区域:
- 类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
这些地址范围被专门保留,不会出现在全球互联网路由表中。
-
用于内部网络通信: 私有IP地址主要用于内部网络中,如家庭网络、企业内部网络或组织内的局域网。设备在这些网络中使用私有IP地址进行局域网通信。
-
NAT技术使用: 为了使私有IP地址的设备能够访问互联网,通常会使用网络地址转换(NAT)技术。NAT允许多个内部设备共享单一的公有IP地址,通过修改IP地址信息来实现局域网和互联网之间的通信。
-
安全性增强: 使用私有IP地址有助于增强网络的安全性,因为内部设备不直接在互联网上可见。只有通过NAT的设备才能与互联网进行通信,提高了网络的隐蔽性。
-
IP地址冲突的防止: 不同的内部网络可以使用相同的私有IP地址,而不会发生全球互联网上的IP地址冲突。这为局域网提供了一定的灵活性,而不必考虑全球唯一性。
路由控制
计算机网络进行路由控制的过程涉及多个步骤和组件,以下是详细说明:
-
数据包生成: 通信的起点是应用程序生成数据,形成数据包。数据包包含源和目标设备的IP地址、端口信息以及要传输的数据。
-
传输到网络层: 数据包从应用层经过传输层,进入网络层。在这一层,数据包被封装为IP数据包,添加了源和目标IP地址等信息。
-
源主机路由表查找: 源主机查找自己的路由表,以确定数据包的下一跳路径。路由表中的信息可能是通过动态路由协议学习到的,也可能是手动配置的静态路由。
-
查找下一跳路由器: 如果目标设备不在同一子网内,源主机需要查找下一跳路由器的IP地址,通常是源主机所在子网的网关。这个过程可能涉及ARP请求,以获取下一跳路由器的MAC地址。
-
封装数据包: 源主机将数据包封装成数据帧,添加目标MAC地址、源MAC地址等信息。数据帧是链路层的表示形式。
-
数据包通过链路层: 封装后的数据包通过链路层传输到下一跳路由器。链路层负责将数据包从一个设备传输到另一个设备。
-
下一跳路由器的路由控制: 下一跳路由器收到数据包后,进行类似的路由控制过程。它查找自己的路由表,决定如何将数据包传递到下一个路由器或目标设备。
-
数据包传输到目标主机: 经过一系列路由器的传递,数据包最终到达目标主机。目标主机根据自己的路由表,确定如何将数据包交付给目标应用程序。
-
目标主机解封装: 目标主机解封装数据包,提取应用层的信息,并将数据交给目标应用程序。
整个过程是复杂而协调的,需要路由器之间的密切合作,确保数据包能够按照正确的路径传递。路由表的更新、路由器的决策以及链路层的传输是实现路由控制的关键步骤。
路由控制如下图所示:
我们用一个例子来解释路由控制,假设你的计算机网络就像一座城市,每个计算机就像城市中的一个建筑物,而路由器就像城市中的交叉路口和导航系统。现在,我们使用一个城市交通的例子来生动形象地解释计算机网络是如何进行路由控制的:
-
建筑物和地址: 想象一座大城市,每座建筑物都有一个唯一的地址,就像计算机在网络中有唯一的IP地址。
-
交叉路口和道路: 假设城市中有许多交叉路口,这些交叉路口就像网络中的路由器。这些路由器通过一条条道路(网络链路)相互连接。
-
导航系统和路由表: 每辆车都有一个导航系统,就像每个计算机都有一个路由表。导航系统知道如何从一座建筑物到另一座建筑物,路由表知道如何从一个IP地址到达另一个IP地址。
-
车辆和数据包: 想象城市中的车辆就像网络中的数据包。车辆需要从一个地方到达另一个地方,就像数据包需要从源计算机到达目标计算机。
-
交叉路口的决策: 当车辆到达一个交叉路口时,它需要根据导航系统的指示选择正确的方向。同样,当数据包到达一个路由器时,路由器会根据路由表的信息选择下一个跳的路径。
-
道路上的拓扑变化: 如果城市中的一条道路发生了封闭或施工,车辆需要根据导航系统的提示选择另一条路径。在计算机网络中,如果某个链路发生故障,路由器会选择备用路径。
-
导航系统的更新: 导航系统会定期更新地图,以确保它了解最新的道路和交叉路口信息。在计算机网络中,路由表也会根据动态路由协议的更新而改变,以适应网络拓扑的变化。
通过这个城市交通的例子,可以形象地理解计算机网络是如何进行路由控制的。每个路由器就像一个交叉路口,而数据包就像城市中的车辆,通过选择正确的路径,确保数据在网络中快速、可靠地传递。
IP分片与重组
IP分片和重组是IPv4协议中的两个重要概念,用于处理网络中传输的大数据包。当一个数据包在网络中传输时,如果经过的链路不支持这个数据包的大小,就会进行IP分片。接收端在接收到这些分片后,通过IP重组将它们还原为原始的数据包。
DHCP协议
动态主机配置协议(DHCP)是一种网络协议,用于自动分配和管理IP地址、子网掩码、默认网关、DNS等网络配置信息,以简化网络管理员对网络设备的配置工作。
下图是DHCP协议动态获取IP的过程:
NAT协议
网络地址转换(NAT)是一种用于在私有网络和公共网络之间映射IP地址的协议。NAT主要用于解决IPv4地址短缺的问题,并提供了一种将多个设备共享单个公共IP地址的方法。
下图是NAT协议如何从私有IP地址网络转化到公有IP地址网络:
下面通过一个生动形象的例子解释NAT如何将私有IP地址网络转化到公有IP地址网络:
假设你身处一个度假村,每个度假屋都有一个内部电话,但度假村只有一个公共电话总机(公有IP地址)。这里的度假屋可以看作是私有网络中的设备,而公共电话总机是公有IP地址。
-
度假屋拨号(设备请求): 当度假屋的居民想要拨号(访问互联网)时,他们拨打的是度假村内部的号码(私有IP地址)。每个度假屋有一个唯一的号码,但这些号码只在度假村内部有效。
-
总机接通(NAT设备): 公共电话总机接听了拨号请求,这里的总机可以看作是NAT设备。NAT设备负责处理度假屋的拨号请求。
-
度假屋号码翻译(私有IP地址转换): 当度假屋的拨号请求到达总机时,总机会将拨号请求中的度假屋号码(私有IP地址)翻译为总机的公共号码(公有IP地址)。这样,外部网络(互联网)就能够识别和回应这个请求。
-
请求发送到目标(请求转发): 总机将翻译后的请求发送到外部网络(互联网),就好比公共电话总机代表度假屋拨打了外部号码。
-
外部网络回应(响应返回): 当外部网络(互联网)收到请求后,它会将响应返回到总机的公共号码。这时,总机会根据之前的翻译记录,将响应翻译为度假屋的内部号码,然后传递给请求的度假屋。
其中NAT充当了度假屋和外部网络之间的桥梁,实现了私有IP地址到公有IP地址的转换,让私有网络中的多个设备能够通过共享一个公有IP地址访问互联网。这种转换过程保护了内部设备的隐私,并有效利用了有限的公有IP地址资源。
数据链路层
主要负责在直连的两个节点之间提供可靠的数据传输。数据链路层通常涉及的是相邻节点之间的通信,而不是全局网络通信。它将网络层提供的数据报转换为适合物理层传输的帧,同时处理差错检测和纠正。
下图是数据链路层封装成帧的格式:
MAC地址
MAC地址,又称物理地址,是数据链路层(Data Link Layer)中用于识别网络设备的唯一硬件地址。每个网络设备(如网卡、交换机)都被分配一个独特的MAC地址,通常由设备的制造商在生产过程中固定编码到设备的网络接口卡中。
以下是MAC地址的特点:
-
唯一性: 每个网络设备的MAC地址是唯一的,确保了全球范围内的设备标识的唯一性。这是通过设备制造商的标识码和设备的唯一序列号组合而成的。
-
48位地址: MAC地址通常是一个由48位二进制数字组成的地址。这些位被分为两个部分:前24位是由IEEE分配给设备制造商的唯一标识码,后24位是设备的唯一序列号。
-
十六进制表示: 为了方便人类阅读和书写,MAC地址通常以十六进制表示。例如,一个MAC地址可能是类似于
00:1A:2B:3C:4D:5E
的形式。 -
固定在网络接口卡上: MAC地址是固定在设备的网络接口卡上的,通常不会被修改。这使得MAC地址成为设备在网络中唯一标识的一种可靠方式。
以下是MAC地址的作用:
-
唯一标识设备: MAC地址用于唯一标识网络中的设备。在局域网(LAN)中,设备使用MAC地址进行通信。
-
地址解析协议(ARP): 在IPv4网络中,ARP协议用于将IP地址映射到MAC地址。每个设备通过ARP协议来查询网络中其他设备的MAC地址,以便进行通信。
-
网络交换: 在交换机等网络设备中,MAC地址用于构建交换表,从而决定将数据帧从哪个端口发送到目的设备。
-
防止冲突: MAC地址的唯一性确保了在同一网络中没有两个设备具有相同的MAC地址,从而防止网络中的冲突和混淆。
总的来说,MAC地址在数据链路层扮演着重要的角色,是设备在局域网中唯一标识的关键。由于其独特性和固定性,MAC地址成为网络通信中重要的硬件地址。
以下是MAC地址的结构:
ARP协议
ARP是一种网络协议,用于将网络层的IP地址映射到数据链路层的MAC地址。ARP协议允许设备在同一局域网中查找目标设备的MAC地址,以便建立通信。下面是ARP协议的详细说明:
ARP的工作原理:
-
设备发送ARP请求: 当一个设备想要与局域网上的另一个设备通信,但只知道目标设备的IP地址时,它会发送一个ARP请求广播到局域网上。该请求包含了目标设备的IP地址。
-
局域网上的设备响应: 局域网上的所有设备都会接收到这个ARP请求,但只有目标设备会响应。目标设备会将自己的MAC地址封装在ARP响应中,并发送给请求设备。
-
ARP响应包含MAC地址: ARP响应包含了目标设备的MAC地址,这样请求设备就知道了目标设备的IP地址与MAC地址的映射关系。
-
缓存ARP表: 请求设备会将收到的ARP响应中的IP地址与MAC地址的映射关系存储在本地的ARP缓存表中。这样,在以后的通信中,就不需要再发送ARP请求,而是直接使用ARP缓存表中的映射关系。
ARP消息格式:
-
ARP请求消息:
- 硬件类型: 表示使用的硬件地址类型,通常为Ethernet。
- 协议类型: 表示网络层协议类型,通常为IPv4。
- 硬件地址长度: 表示硬件地址的长度,对于Ethernet是6字节。
- 协议地址长度: 表示协议地址的长度,对于IPv4是4字节。
- 操作码: 表示ARP请求(1)或ARP响应(2)。
- 发送方硬件地址: 发送ARP请求的设备的MAC地址。
- 发送方协议地址: 发送ARP请求的设备的IP地址。
- 目标硬件地址: 在ARP请求中通常为0,因为此时目标MAC地址未知。
- 目标协议地址: 目标设备的IP地址。
-
ARP响应消息: 与ARP请求消息相似,不同之处在于操作码是ARP响应(2),目标硬件地址是目标设备的MAC地址。
ARP的应用:
-
解析IP地址到MAC地址: ARP主要用于解析目标设备的IP地址到其对应的MAC地址,以便直接通信。
-
ARP缓存: 设备在收到ARP响应后,会将IP地址与MAC地址的映射关系缓存起来,以便后续通信时直接使用,提高效率。
-
局域网通信: ARP主要用于局域网中,当设备需要与同一局域网上的其他设备通信时使用。
ARP协议是IPv4网络中的一个重要组成部分,它帮助设备在局域网中解析目标设备的MAC地址,从而实现直接的通信。
物理层
物理层是OSI模型中的第一层,它主要负责在网络设备之间传输原始比特流,通过物理媒体将数据从一个点传输到另一个点。物理层的主要功能和用处包括:
-
比特编码和调制: 物理层负责将数字数据转换为比特流,并进行调制,以适应特定的物理传输介质。这可能涉及到将数字信号转换为模拟信号,或者采用不同的编码方式。
-
传输介质的选择: 物理层决定了数据的传输媒体,可以是铜线、光纤、无线电波等。选择合适的传输介质取决于通信需求、距离和成本等因素。
-
数据传输速率: 确定数据传输速率,即比特率。物理层定义了在单位时间内传输的比特数,例如以每秒比特数(bps)为单位。
-
物理拓扑: 确定网络的物理拓扑结构,即设备之间的连接方式。常见的物理拓扑包括星型、总线型、环型等。
-
信道复用: 控制在物理媒体上传输的数据流,以确保多个设备能够共享同一物理通道。信道复用技术包括时分复用(TDM)、频分复用(FDM)等。
-
时钟同步: 提供时钟同步,确保发送和接收设备在传输过程中保持相同的时钟频率,以便正确解释比特的时序。
-
物理层设备: 包括传输介质和物理层设备,如中继器、集线器等。这些设备用于放大信号、衰减和整形信号,以确保它们能够在物理媒体上传输。
-
媒体访问控制(MAC): 在一些网络中,物理层也可能涉及到媒体访问控制,即控制在共享媒体上访问的方式,如以太网中的CSMA/CD(Carrier Sense Multiple Access with Collision Detection)。
物理层在网络通信中扮演着将数字数据转换为物理信号,并通过物理媒体进行传输的重要角色。物理层的设计和实施直接影响到网络的性能和可靠性。
计算机网络综合
让我们使用OSI模型的各层来解释从输入网址到浏览器显示的过程:
-
应用层: 用户在浏览器中输入网址,触发了应用层。浏览器会使用HTTP或HTTPS协议创建一个HTTP请求。
-
运输层: HTTP请求被传递到运输层,通常使用TCP协议。在这一层,建立了一个TCP连接,确保数据的可靠传输。
-
网际层: 在运输层之上,数据包被封装并添加了源和目标的IP地址。这是通过DNS解析得到的目标服务器的IP地址。
-
数据链路层: 数据包在网际层上传输时,会被封装成帧,并添加源和目标的MAC地址。这一层确保了数据在局域网中的传输。
-
物理层: 最底层是物理层,负责实际的比特传输,将帧转换为电信号或光信号,并通过物理介质(例如电缆、光纤)传输。
在服务器端,相反的过程也会发生:
-
物理层: 接收到比特流后,物理层将其转换为帧。
-
数据链路层: 帧被解封装,提取出数据包。
-
网际层: 从数据包中提取出目标IP地址,路由决定如何将数据包传递到目标服务器。
-
运输层: 数据包传递到运输层,TCP协议解封装数据包,将其传递到应用层。
-
应用层: 在应用层,服务器的Web服务器软件处理HTTP请求,生成HTTP响应。
最终,HTTP响应沿着相反的路径通过物理、数据链路、网际、运输和应用层,到达用户的浏览器。浏览器将HTTP响应解析并渲染成用户可以浏览的网页。整个过程遵循OSI模型,每一层负责不同的功能,确保了网络通信的顺利进行。
我们用一个例子来更形象的表示此过程,想象一下你是一位旅行者,正在规划一次前往一个新城市的旅程。这个城市的名字就是你在浏览器中输入的网址。现在,我们将这个旅程与计算机网络的通信过程进行对比:
-
应用层 - 旅行计划: 你开始规划旅行,类似于在浏览器中输入网址。这相当于应用层,你的旅行计划就像HTTP请求。
-
运输层 - 交通规划: 为了到达目的地,你需要选择适当的交通工具,例如汽车或火车。在网络中,运输层就像是交通规划,选择TCP协议作为主要交通工具,确保安全可靠的到达。
-
网际层 - 导航系统: 使用导航系统(相当于DNS解析),你输入目的地的城市名称,导航系统将其转换为具体的地理坐标,帮助你找到正确的路线。
-
数据链路层 - 行车路径: 你沿着道路行驶,道路上有标识和指示牌,确保你沿着正确的路径前进。在计算机网络中,数据链路层就像是行车路径,通过MAC地址确保数据在局域网中正确传输。
-
物理层 - 实际道路: 最终,你驾驶着汽车或坐着火车,通过实际的道路或铁路网络到达目的地。在网络中,物理层就是实际的电缆、光纤等物理介质,确保比特数据能够物理传输。
在目的地城市,整个过程相反地发生,就像服务器响应你的旅行请求一样。这个生动的旅行比喻帮助理解了计算机网络中不同层次的功能及其相互协作。