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

概括来说:首先我们在浏览器地址栏敲下域名地址,浏览器发出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 条评论
登录 后参与评论

相关文章

来自专栏前端黑板报

软件工程师需要了解的网络知识:从铜线到HTTP(四)—— TCP 和路由器

JohnLui:程序员,Swift Contributor,正在写《iOS 可视化编程与 Auto Layout》 基础梳理 截至目前,我们已经得到了三个首部:...

2786
来自专栏xingoo, 一个梦想做发明家的程序员

计算机网络基础回顾

对于程序员来说,计算机网络的知识是很重要也很基础的。尤其是做web开发就要对http或者https很熟。有的时候涉及到域名,还会碰到跨域问题。这些其实都是计算...

18010
来自专栏take time, save time

三十天学不会TCP,UDP/IP网络编程 - 绅士的开始

经过了过年的忙碌和年初的懈怠一切的日子,我又开始重新更新了~这是最新的一篇~完整版可以去gitbook(https://www.gitbook.com/@rog...

34810
来自专栏TechBox

图解TCP/IP协议前言图解TCP/IP协议传输数据

1292
来自专栏Golang语言社区

linux服务器开发三(网络编程) --一

网络基础协议的概念什么是协议 从应用的角度出发,协议可理解为“规则”,是数据传输和数据的解释的规则。 假设,A、B双方欲传输文件。规定: 第一次,传输文件名,接...

36712
来自专栏Java3y

网络层【第一篇】

在当今我们是使用无连接的方式的。网络提供数据报服务,无连接的、尽最大努力交付的数据报服务。网络层不提供服务质量的承诺。即所传送的分组可能出错、丢失、重复和失序(...

811
来自专栏梧雨北辰的开发录

计算机网络基础知识

计算机网络的知识与我们的生活息息相关,对于每一个开发者来说更是十分重要,深入理解它,将有助于我们在实际工作中迅速解决相关问题。本篇就计算机网络的基本知识进行概要...

1353
来自专栏Java面试通关手册

搞定计算机网络面试,看这篇就够了

OSI的七层体系结构概念清楚,理论也很完整,但是它比较复杂而且不实用。在这里顺带提一下之前一直被一些大公司甚至一些国家政府支持的OSI失败的原因:

1310
来自专栏运维小白

1-2 CCNA

物理介质:网线、光纤、网卡接口 ---- 568B:橙白、橙、绿白、蓝、蓝白、绿、棕白、棕 一般网线中,只有1236传输数据 ---- 交叉线:连接同类型设备 ...

2938
来自专栏desperate633

TCP/IP之网络层服务网络层服务虚电路网络数据报网络数据报网络与虚电路网络的对比

网络层提供的服务是,主机与主机的数据传输。发送主机向接收主机发送数据段( segment)。首先,发送主机将来自传输层的数据段封装到数据报中,然后传输给接收主机...

631

扫码关注云+社区