Gateway:数据报文走出局域网的必经之路

本文涉及的产品
公网NAT网关,每月750个小时 15CU
简介: 最近没事在看极客时间上刘超老师的《趣谈网络协议》那门课程,其中有一篇讲得非常有意思,也有些难以理解,我以我的角度来谈谈。

MAC 头和 IP 头细节

想要跨网段访问的话,有一关是必须要过的:网关( Gateway )

配置好 IP 地址和网关之后,就能够自由访问上网了,想访问哪儿网站就访问哪儿个网站,各种浪。但是在进行跨网访问的时候,会牵扯到 MAC 地址和 IP 地址的变化,所以咱们先来知道一下 MAC 头和 IP 头的细节。

MAC 头和 IP 头的细节(画的不是太好哈):57.jpg

简单来说一下内容:

目标 MAC 地址和源 MAC 地址应该不需要说明什么了,协议类型是为了说明里面是 IP 协议

版本( Version ):占 4 位,用来表明 IP 协议实现的版本号,目前来说主流还是 IPV4

服务类型 TOS ( Type of Service ):占 8 位,其中前 3 位比特为优先权字段,第 8 位保留未用,第 4 至 7 位分别代表延迟,吞吐量,可靠性和花费。

总长度:占 16 位,说明整个数据报的长度(以字节为单位),最大长度为 65535 字节

标识:占 16 位,用来唯一标识主机发送的每一份数据报,通常每发一份报文,它的值会加 1

标志:占 3 位,标志一份数据报是否要求分段

片偏移:占 13 位,如果一份数据报要求分段的话,该字段指明该段偏移距原始数据报开始的位置

生存期 TTL ( Time to Live ):占 8 位,用来设置数据报最多可以经过的路由器数,由发送数据的源主机设置,通常为 32,64,128 等。没经过一个路由器,它的值减 1,直到 0 时该数据报被丢弃。

协议:占 8 位,用来说明 IP 层所封装的上层协议类型,如 ICMP( 1 ), IGMP( 2 ), TCP( 6 ), UDP( 17 )等。首部校验和:占 16 位,根据 IP 头部计算得到的校验和码。

源 IP 地址,目标 IP 地址:各占 32 位,用来标明发送 IP 数据报文的源主机地址和接收 IP 报文的目标主机地址。

在任何一台机器上,如果想要访问另一个 IP 地址时,都会先判断,要访问的目标 IP 地址,与当前机器 IP 地址是否在同一个网段内。

如果是同一个网段,这就好说了,直接将源地址和目标地址放入到 IP 头中,然后通过 ARP 得到 MAC 地址,将源 MAC 和目标 MAC 放入 MAC 头中,发出去就 OK 了。

但是如果不是同一个网段呢,这就需要发往默认网关 Gateway 了。Gateway 的地址一定是和源 IP 地址是同一个网段的,如果不是第一个,就是第二个。比如, 192.168.1.0/24 这个网段,Gateway 一般就是 192.168.1.1/24 或者 192.168.1.2/24 。因为网关和源 IP 地址在同一个网段内,所以发给 Gateway 的过程和上面同一个网段的过程是一样的。网关接收到之后,接下来怎么处理就是它自己的事情了。

做了上面那么多的铺垫,终于来到了今天想要说的主要内容:网关是怎么将数据跨网段发送出去的。因为在这里面涉及到了 IP 地址和 MAC 地址的变化。

MAC 地址是在一个局域网内才有效的地址,所以 MAC 地址只要经过网关,就一定会改变,因为经过网关就意味着换了局域网。主要在于 IP 地址是否改变。如果 IP 地址不改变,那我们就将网关称为转发网关;如果 IP 地址改变,则将网关称为 NAT 网关。

转发网关

先来说一下转发网关:

58.jpg

如图,我们能够看到,服务器 A 的 IP 地址为 192.168.1.101/24 ,服务器 B 的 IP 地址为 192.168.4.101/24 ,现在服务器 A 想要访问服务器 B,不在同一个网段内,怎么办呢?肯定要经过网关的,对吧(因为 IP 头和 MAC 头里面的内容太多了,在这里主要写出 MAC 和 IP 内容)

此时,服务器 A 会给路由器 A 发送这样的内容:

源 MAC :服务器 A 的 MAC
目标 MAC : 路由器 A 的 MAC
源 IP : 192.168.1.101 (即服务器 A 的 IP )
目标 IP : 192.168.4.101 (即服务器 B 的 IP )

路由器 A 接收到内容之后,发现是想访问 192.168.4.0/24 的,根据配置的路由规则,将要发送的内容通过 192.168.2.1 这个口发送出去,发送给路由器 B 的内容是这样的:

源 MAC :路由器 A 的 MAC
目标 MAC : 路由器 B 的 MAC
源 IP : 192.168.1.101 (即服务器 A 的 IP )
目标 IP : 192.168.4.101 (即服务器 B 的 IP )

路由器 B 接收到了来自路由器 A 的内容,它发现是想访问 192.168.4.0 这个地址,根据配置的路由规则,需要从 192.168.4.1 这个口出去,这样就能发给服务器 B,此时路由器 B 发送的包是这样的:

源 MAC :路由器 B 的 MAC
目标 MAC : 服务器 B 的 MAC
源 IP : 192.168.1.101 (即服务器 A 的 IP )
目标 IP : 192.168.4.101 (即服务器 B 的 IP )

至此,服务器 A 发送的内容就到达了服务器 B 。

咱们来总结一下以上内容:在转发网关下,我不 care 其他的,我只知道我要发给哪儿个 IP ,所以在整个过程中,源 IP 和目标 IP 都没有发生改变。

NAT 网关

接下来咱们来说说 NAT 网关。照例,上个图:

59.jpg

有没有发现一个问题,服务器 A 的 IP 地址是 192.168.1.101 ,要访问的服务器 B 的地址也是 192.168.1.101 ,如果只是看 IP 地址的话,是不是饶了一圈发现,这不就是自己访问自己嘛?惊不惊喜。

但是实际上服务器 A 在北京,服务器 B 在上海,两个地方有一个相同的 IP 地址罢了。问题就来了,服务器 A 怎么就可以访问到服务器 B 了呢?

就像上海人说上海话,北京人说北京话,一个区域内大家都听得懂,但是如果北京人跑到上海去,想要交流怎么办呢?说普通话呗,对不对。在网络中也可以这样做。既然这两个局域网之间没有商量过,各自使用各自的,内部使用的话这都没事儿,但是如果想要在外面也走的开,就需要制定规则。也就是说,路由器 A 和 B 在外网上需要有一个大家都公认的身份。

在图中我们能够看到路由器 A 在公网上的身份是 192.168.2.1/24 ,路由器 B 在公网上的身份是 192.168.2.2/24 。有了公认的身份之后,来看看接下来发送的内容:

服务器 A 发送给路由器 A 的内容:

源 MAC :服务器 A 的 MAC
目标 MAC : 路由器 A 的 MAC
源 IP : 192.168.1.101 (即服务器 A 的 IP )
目标 IP : 192.168.2.2 (即路由器 B 的公网 IP )

路由器 A 接收到内容之后,根据配置的路由规则,通过 192.168.2.1/24 发送给路由器 B ,此时发送的内容为:

源 MAC :路由器 A 的 MAC
目标 MAC : 路由器 B 的 MAC
源 IP : 192.168.2.1 (即路由器 A 的公网 IP )
目标 IP : 192.168.2.2 (即路由器 B 的公网 IP )

内容到达路由器 B 之后,根据它的配置规则,发现是想要发送给服务器 B 的,此时:

源 MAC :路由器 B 的 MAC
目标 MAC : 服务器 B 的 MAC
源 IP : 192.168.2.1 (即路由器 A 的公网 IP )
目标 IP : 192.168.1.101 (即服务器 B 的公网 IP )

至此,服务器 A 发送的内容就到达了服务器 B 。

咱们来总结一下以上内容:在 NAT 网关下, MAC 地址和 IP 地址都是会改变的。MAC 地址还好理解一些,要发送给谁,那么目标 MAC 地址就是要发送的机器 MAC 地址即可。但是 IP 地址如果是跨网段访问,则都需要通过公网 IP 来进行才可以。

以上就是想要分享的内容,感谢您的阅读~

参考:

极客时间:《趣谈网络协议》

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
相关文章
|
NoSQL Java 关系型数据库
Spring Cloud Gateway 源码剖析之Route数据模型
Spring Cloud Gateway 源码剖析之Route数据模型
299 0
|
缓存 JSON Java
【Java】SpringCloud Gateway自定义过滤器中获取ServerHttpRequest的body中的数据为NULL的问题
【Java】SpringCloud Gateway自定义过滤器中获取ServerHttpRequest的body中的数据为NULL的问题
581 0
|
前端开发 数据安全/隐私保护
SpringCloud GateWay 网关 在GlobalFilter 拿出返回数据response
SpringCloud GateWay 网关 在GlobalFilter 拿出返回数据response
1546 0
SpringCloud GateWay 网关 在GlobalFilter 拿出返回数据response
|
JSON 网络协议 开发工具
基于声网的音视频SDK和FreeSWITCH开发WebRTC2SIP Gateway 报文设计 (二)
基于声网的音视频SDK和FreeSWITCH开发WebRTC2SIP Gateway 报文设计
600 0
基于声网的音视频SDK和FreeSWITCH开发WebRTC2SIP Gateway 报文设计 (二)
|
2月前
|
负载均衡 Java Nacos
SpringCloud基础2——Nacos配置、Feign、Gateway
nacos配置管理、Feign远程调用、Gateway服务网关
SpringCloud基础2——Nacos配置、Feign、Gateway
|
2月前
|
Java 开发者 Spring
Spring Cloud Gateway 中,过滤器的分类有哪些?
Spring Cloud Gateway 中,过滤器的分类有哪些?
63 3
|
2月前
|
负载均衡 Java 网络架构
实现微服务网关:Zuul与Spring Cloud Gateway的比较分析
实现微服务网关:Zuul与Spring Cloud Gateway的比较分析
117 5
|
1月前
|
负载均衡 Java API
【Spring Cloud生态】Spring Cloud Gateway基本配置
【Spring Cloud生态】Spring Cloud Gateway基本配置
39 0
|
2月前
|
安全 Java 开发者
强大!Spring Cloud Gateway新特性及高级开发技巧
在微服务架构日益盛行的今天,网关作为微服务架构中的关键组件,承担着路由、安全、监控、限流等多重职责。Spring Cloud Gateway作为新一代的微服务网关,凭借其基于Spring Framework 5、Project Reactor和Spring Boot 2.0的强大技术栈,正逐步成为业界的主流选择。本文将深入探讨Spring Cloud Gateway的新特性及高级开发技巧,助力开发者更好地掌握这一强大的网关工具。
243 6