专栏首页开发与安全浅谈网络数据包传递过程中涉及的话题

浅谈网络数据包传递过程中涉及的话题

概括来说:首先我们在浏览器地址栏敲下域名地址,浏览器发出get请求,接下来进行dns域名解析(后面再详谈),此时浏览器已经得知目标IP,此时还得知道默认网关的mac地址,如果此前主机没有进行arp缓存,主机会进行arp广播,网关得知广播的ip的自己的,便回复自己的mac地址(A端口)给主机。(关于arp与mac后面再详谈)为了方便说明我用一个图来演示(大家不要纠结于packet tracer中红色不通,那是因为我没有设置ip,也没有打开路由器端口的问题,本文不是来介绍软件用法的,大家请忽略)

    应用层添加第四层(tcp/ip模型)报头,用于标志应用和数据类型,数据流流向第三层的传输层,又添加自己的控制信息,主要需要注意的是添加了端口号,一般来说目的端口为80,而源端口是主机上随机开启的一个端口,一般大于1024.接着到了第二层互联层(即osi模型中的网络层),此时添加目的ip,源ip地址等信息,最后到达主机-网络层(osi模型中的物理层和数据链路层),此时添加源mac地址(主机的)和目的mac地址(在这里指的是默认网关A端口的mac),在这里需要指出的是,一个数据包在传输过程中,目的IP和源IP是永远不变的,一直是主机和服务器的IP,而目的mac和源mac却是一直变化的,这也是arp协议存在的一个理由吧。并将电脉冲信号编码(如曼彻斯特编码)成二进制数据流在介质(这里指铜缆)上传播(使用CSMA/CD来控制将数据放到介质上传输)。

注:在存在nat 的情况下,目的ip 和源 ip 可能被修改。nat 是一种在IP 数据包通过路由器或防火墙时重写来源IP 地址或目的IP 地址的技术。在一个具

有NAT 功能的路由器下的主机并没有创建真正的IP地址,并且不能参与一些因特网协议。一些需要初始化从外部网络创建的TCP 连接和无状态协议

(比如 UDP)无法实现。除非NAT路由器管理者预先设置了规则,否则送来的数据包将不能到达正确的目的地址。比如处在 nat 路由器后面的客户端

想与外网的 ftp 主机传输文件,则需要设置为 被动模式,即由客户端主动连接 ftp 主机,建立数据传输通道。

      数据包进入router0的A端口后,进行的是一个拆包和封包的过程,路由器是三层设备,数据还是会从最底层走向最高层,每层把数据包进行拆解,得到自己想到的东西,走到最高层后又从最高层走向最底层并从B口流出,这时数据包的目的mac将变成router1的C端口mac(当然跟前面一样router0没有arp缓存则进行arp解析),而源mac则为B端口的mac.同样地数据包流到C端口后又进行像router0一样的拆包封包过程,接着从D端口流出,当然此时的目的mac为服务器的mac地址,源mac为D端口mac地址。

     其实服务器也是主机,也会进行拆包的过程,数据从底层一直到最高层只剩下应用数据,此时服务器就知道对方浏览器请求什么了,一般是返回html代码原路返回,当然这又是个拆包封包的过程,浏览器利用得到的html代码进行解析,用户就看到相要的界面了。在这里补充一下,其实手机浏览器的工作原理差不多,不过中间多了手机浏览器服务商自己的服务器集群,用户想要浏览的html先是返回到服务商的云存储然后进行压缩后才回传给用户,这时可以达到省流量,拦截广告等的作用。

    当然上述只是简化了的描述过程,真正的还是很复杂的,比如路由寻址,路由协议等,在这里只是普及下常识,那些不在本文讨论之列。

   没错,也许第一个数据包只是tcp三次握手的第一个数据包传输,直到连接建立才会有真正的数据传输,可想而知,第二个数据包一般是不用再进行arp解析的了,因为此时都会有arp缓存表在内存中。每个数据包都有个重要的seq number,这是tcp数据包进行分段(下面会有解释)成多个数据包进行传输,每个数据包打上的序号标签,用于在目的地进行数据包重组,这不就是通信网中的报文分组交换,分组交换方式有两种,一种是数据报,一种是虚电路,需要注意的是IP协议是使用数据报的方式传包的,而上层的TCP,UDP协议分别是面向连接和面向无连接的,但如TCP所谓的虚连接跟OSI网络层的虚电路完全是不同的概念!顺便提一下,通信还有一种重要的传输方式为电路交换,像PSTN公共电话交换网,CDMA,GSM等都是使用电路交换的方式(CDMA和GSM中的语音通话使用的是空中接口的电路交换,GPRS,CDMA 1X等上网技术使用的是空中接口的分组交换),扯远了。而有关tcp协议传输过程中的滑动窗口,拥塞控制等内容又是一大堆,这里就不说了,我也还没弄得很清楚。

下面就一些重要且有些混淆的概念解释一下。

DNS:一般来说,我们访问资源,首先出来做事的是local dns服务器,比如在一个局域网使用dhcp分配ip,则你的local dns也是分配的,当然你也可以手动设置。如果没有在缓存中,则跑到root dns,没记错的话全球共有13个根dns服务器ip,root dns顺着二级三级dns服务器找到域名授权服务器,即你所要访问的网站服务器所设置的对自己的域名进行解析的服务器,怎么感觉有点绕额,不过应该也能想明白吧。最后域名授权服务器就会把网站的ip返回给本地主机进行访问。如果,我是说如果,你访问的是大型门户网站,比如新浪网,那么一般来说域名授权服务器还会跳到智能调度DNS服务器,进行dns视图智能解析,通俗来说,他们为一个域名配备了多个IP,这样可以达到均衡负载的目的,又扯远了,这方面我了解也不多,不敢献丑。

arp :对交换机来说没有arp的概念,就像在一个不跟外界通信的局域网,使用二层交换机足以,利用交换机的mac列表就可以跟局域网内的主机进行通信。而一旦两个不同的子网主机要通信,或者局域网的主机想连入广域网,或者不同vlan的主机要互相通信,此时就要为两个不同的网络配备中间的网关,一般来说可以使用路由器或者三层交换机达到此种目的,但需要知道的是三层交换机不能互联局域网和广域网,原因无他,因为三层交换机没有那么多类型的端口,虽然端口数量比路由器多得多,三层交换机跟路由器的区别也是一个点,想了解的自己去查资料。回到主题,不同网络需要通信,网络1的主机首先会进行arp解析,将默认网关的mac地址得到,然后再传输数据,同理,网关要将数据传给网络2的主机时,也需要进行arp解析得到这个主机的mac地址再进行传输。arp协议有安全漏洞,即arp欺骗,原理很简单,arp解析是基于某个网段进行广播的,如果有人假冒然后进行了应答就会改变数据包的流向。

mac:mac地址即通俗所说的网卡地址,一般是固写的,不可更改的。但大家知道使用软件可以更改,其实这只是在操作系统层面上改动,使传出去的数据包带着的mac地址变换了,本来mac地址应该是唯一的,而更改后可能会跟其他的重复,那会发生冲突吗?我们知道每一跳mac地址都在改变,所以我觉得只要相邻两跳之间的mac地址不一样,就不会发生冲突,就像广州某个主机的mac地址跟北京主机的mac地址一样会发生冲突吗?且不说不处在一个网络,即使是同个子网,当进行arp解析时,两台主机的ip不同则不会发生同时响应的情况,除非上面所说的arp欺骗了。当然mac地址在应用层面上还有其他作用的,比如一个商业软件的序列号只能用在一个mac地址上,两个同样mac地址的主机用了估计就会发生冲突。这里需要注意:一个ip不可拥有两个mac,因为那时数据包都不知道要把数据发到哪个端口,也许你会说那笔记本不是有无线网卡,不就有两个mac啊,但不要忘了,笔记本连线上网与无线上网得到的ip是不同的,即一个ip对应一个mac啊。在这里提一下交换机的mac地址列表是每个端口与端口所连接设备的mac映射,也会有安全隐患,比如说有个端口设备不断变更自己的mac,则mac地址表会很快存满了,此时其他主机间想要通信时mac地址表已经不可用了,只能使用广播方式,这样这个端口设备就达到偷听消息的目的了。

tcp分段 ip分片:理论上来说,IP包最大为65535B(包括IP首部和IP层payload),传输层的实际数据(payload)最大不超过 65525-20-20=65495B,但如果IP包大于以太网最大MTU1500B,此时还需要进行IP包分片传输。需要特别指出的是每个数据包的报头都会有目的端口,源端口和自己的序列号(为了数据包重组成原始数据);但再进行IP分片后,只有第一片含有TCP/UDP表头,其他片没有,但所有片都会有IP层的表头,如源IP和目的IP,以及分片偏移量(为了重组成一个原始数据包)等。

实际上在tcp首部有选项字段,最常用的如mss(maximum segment size),默认是536B,因为internet 上标准的MTU(最小)是576B,即536+20+20 = 576;假设现在对方共有10KB数据需要传输(一次性send() / sendto() / write() ),我们可以设置mss=512B,则分成20个数据段(TCP段)进行传输,因为512 +  20 + 20 <576,故无需在ip层分片。我们根据接收到的20个数据块的seq number(32位) 进行数据的重组,这20个数据块可以走不同的路由,即下图中的数据报传输方式。

电路交换&分组交换&面向连接&面向无连接:

电路交换如PSTN,属于同步时分复用,属于面向连接。

分组交换属于统计时分复用(异步时分复用),包括数据报和虚电路两种方式,数据报属于无连接方式,无连接的协议有TCP/IP协议组的IP部分,NetWare的SPX/IPX协议的IPX部分和OSI的无连接网络协议(CLNP)。这些协议在与OSI协议模型相当的网络层中。如IP网,广播电视网都是属于面向无连接的网络。

而虚电路属于面向连接方式,如X.25分组网,ATM网,帧中继网都是属于这种类型。

 TCP的虚连接与网络层的虚电路: 

TCP所谓的面向连接的特性以及建立虚连接,与网络层虚电路服务有着本质的区别,网络层的带有虚电路的服务的协议典型的有曾经应用在广域网的X.25和帧中继,这两个协议在建立连接时要建立所谓的虚电路号,在传输的数据单元中有已经填好的虚电路号,数据单元沿着既定的虚电路沿着既定的方向(一定的路由器序列)到接收端,这样能够保证数据单元到达接收端是有序地,而且也能很好的保障可靠传输。

而TCP的面向连接服务在建立连接时只是进行了三次握手,具体主机到主机的传输以来网络层,也就是IP层提供的路由服务,而IP层在发送以及转发分组是无序的,举个简单的例子,如果IP协议和X.25协议(假设这两个协议应用在同一个案例中)在建立连接时指定了一段A到B的链路,如果A到B的链路在某个时刻出现拥塞,IP协议可能会让分组到达A以后选择另外一条路由,而X.25就只能利用一些流量控制等措施来控制发送端的发送速度,但是不会选择A到B以外的路径,所以TCP所谓的虚连接和网络层的虚电路服务这样理解的话完全不是一个概念。

网络层的虚电路服务时真正指明了一条链路序列,数据只能在这个指明的链路中有序地发送到接收端,而TCP的虚电路只是依靠他的拥塞控制,流量控制和差错控制来令收到的报文段看起来是有序地(在滑动窗口机制里可能出现后面的字节流先到或者字节丢失的情况,所以可以看出来TCP不能保证真正的传输的可靠性,只是依靠差错控制来保证能可靠地收到正确的数据流),而TCP的报文段实际在网络中传输时是不可靠且无需在IP层达到可靠性的。

注:上述内容是本人为了理清一些概念和过程,而自己进行知识总结推理得出的结论,很可能是不正确的不完善的,希望大家斧正,定当虚心受教。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • linux网络编程之TCP/IP基础(三):IP数据报格式和IP地址路由

    一、IP数据报格式 IP数据报格式如下: ? 注:需要注意的是网络数据包以大端字节序传输,当然头部也得是大端字节序,也就是说: The most signifi...

    s1mba
  • 从零开始学C++之类与对象:类声明、类作用域、前向声明、this指针、嵌套类、PIMPL 技法 等

    一、类声明 //类是一种用户自定义类型,声明形式: class 类名称 {    public:              公有成员(外部接口)   ...

    s1mba
  • linux系统编程之进程(三):exec系列函数和system函数

    一、exec替换进程映象 在进程的创建上Unix采用了一个独特的方法,它将进程创建与加载一个新进程映象分离。这样的好处是有更多的余地对两种操作进行管理。当我们创...

    s1mba
  • 记一次Redis连接超限排查

    .example_responsive_1 { width: 200px; height: 50px; } @media(min-width: 290px)...

    草堂笺
  • 1.2.3.1 ISO/OSI参考模型

    国际化标准组织(ISO)提出的网络体系结构模型,称为开发系统互联参考模型(OSI/RM),通常简称为OSI参考模型。OSI有七层,自下而上依次为物理层、数据链路...

    week
  • 看阿里大牛深入浅出Java 线程池原理分析与使用

    Java架构
  • 为什么今天的企业研发中心要设在城市

    本文发表在哈佛商业评论上 亚特兰大中城区已经发生了很大变化。乔治亚科技城周边的校园已经成为美国企业研发中心的圣地。在过去十年中,科技广场,这个位于中城区的区域...

    点滴科技资讯
  • 微软发布TX(LINQ To Logs And Traces)

    微软开源技术公司于发布了Tx,这是一个Apache 2协议的开源项目,可以使用日志/跟踪文件辅助调试,以及创建实时监控和告警系统。 下面是几个引人关注的功能——...

    张善友
  • Debatching(Splitting) XML Message in Orchestration using DefaultPipeline - BizTalk 2010

    Debatching(Splitting) XML Message in Orchestration using DefaultPipeline - BizTa...

    阿新
  • Tomcat 启动异常记录

    JavaEdge

扫码关注云+社区

领取腾讯云代金券