网络是怎样连接的-Socket收发数据|集线器|路由器

网络是怎样连接的-Socket收发数据|集线器|路由器

Android小彩虹2021-07-07 23:27:5990A+A-

收发数据

发送数据规则

在链接成功后,应用程序调用write方法来发送数据。应用程序会告诉协议栈发送数据的大小,协议栈在收到数据后并不会马上发出去,会等到了一定大小的数据才会发出去。这个是为了避免有大量的小包产生。

要累计多少数据才发送每个系统不一样,会有一些规则:

第一个判断要素是每个网络包能容纳的数据长度,协议栈会根据一个叫作MTU的参数来进行判断。MTU表示一个网络包的最大长度,在以太网中一般是1500字节。MTU是包含头部的总长度,因此需要从MTU减去头部的长度,然后得到的长度就是一个网络包中所能容纳的最大数据长度,这一长度叫作MSS

MTU:一个网络包的最大长度,以太网中一般为1500字节。MSS:除去头部之后,一个网络包所能容纳的TCP数据的最大长度。

1622725475698.jpg

1622725475695.jpg

另一个判断要素是时间。当应用程序发送数据的频率不高的时候,如果每次都等到长度接近MSS时再发送,可能会因为等待时间太长而造成发送延迟,这种情况下,即便缓冲区中的数据长度没有达到MSS,也应该果断发送出去。为此,协议栈的内部有一个计时器,当经过一定时间之后,就会把网络包发送出去。

实际如何判断是由协议栈的开发者来决定的

如果仅靠协议栈来判断发送的时机可能会带来一些问题,因此协议栈也给应用程序保留了控制发送时机的余地。应用程序在发送数据时可以指定一些选项,比如如果指定“不等待填满缓冲区直接发送”,则协议栈就会按照要求直接发送数据。像浏览器这种会话型的应用程序在向服务器发送数据时,等待填满缓冲区导致延迟会产生很大影响,因此一般会使用直接发送的选项。

当发送数据很大的时候,发送缓冲区中的数据就会超过MSS的长度,这时我们当然不需要继续等待后面的数据了。发送缓冲区中的数据会被以MSS长度为单位进行拆分,拆分出来的每块数据会被放进单独的网络包中。

确认发送的数据

在发送网络包之后,接下来还需要进行确认操作。

TCP模块在拆分数据时,会先算好每一块数据相当于从头开始的第几个字节,接下来在发送这一块数据时,将算好的字节数写在TCP头部中,“序号”字段就是派在这个用场上的

发送数据的长度也需要告知接收方,不过这个并不是放在TCP头部里面的,因为用整个网络包的长度减去头部的长度就可以得到数据的长度,所以接收方可以用这种方法来进行计算。

把长度加起来,计算出一共已经收到了多少个字节,然后将这个数值写入TCP头部的ACK号中发送给发送方。

在实际的通信中,确认ack序号并不是从1开始的,而是需要用随机数计算出一个初始值,

因此需要在开始收发数据之前将初始值告知通信对象

大家应该还记得在我们刚才讲过的连接过程中,有一个将SYN控制位设为1并发送给服务器的操作,就是在这一步将序号的初始值告知对方的。实际上,在将SYN设为1的同时,还需要同时设置序号字段的值,而这里的值就代表序号的初始值

1622725475691.jpg

在得到对方确认之前,发送过的包都会保存在发送缓冲区中。如果对方没有返回某些包对应的ACK号,那么就重新发送这些包。

有了这一机制,我们就不需要在其他地方对错误进行补救了。因此,网卡、集线器、路由器都没有错误补偿机制,一旦检测到错误就直接丢弃相应的包。应用程序也是一样,因为采用TCP传输,即便发生一些错误对方最终也能够收到正确的数据,所以应用程序只管自顾自地发送这些数据就好了。不过,如果发生网络中断、服务器宕机等问题,那么无论TCP怎样重传都不管用。

TCP会在发送数据的过程中持续测量ACK号的返回时间,如果ACK号返回变慢,则相应延长等待时间;相对地,如果ACK号马上就能返回,则相应缩短等待时间

每发送一个包就等待一个ACK号的方式是最简单也最容易理解的,但在等待ACK号的这段时间中,如果什么都不做那实在太浪费了。为了减少这样的浪费,TCP采用滑动窗口方式来管理数据发送和ACK号的操作。所谓滑动窗口,就是在发送一个包之后,不等待ACK号返回,而是直接发送后续的一系列包。这样一来,等待ACK号的这段时间就被有效利用起来了。

1622725475684.jpg

但如果不等返回ACK号就连续发送包,就有可能会出现发送包的频率超过接收方处理能力的情况。

如果数据到达的速率比处理这些数据并传递给应用程序的速率还要快,那么接收缓冲区中的数据就会越堆越多,最后就会溢出

缓冲区溢出之后,后面的数据就进不来了,因此接收方就收不到后面的包了,这就和中途出错的结果是一样的,也就意味着超出了接收方处理能力。

解决办法,首先,接收方需要告诉发送方自己最多能接收多少数据,然后发送方根据这个值对数据发送操作进行控制,这就是滑动窗口方式的基本思路。

更新窗口大小的时机应该是接收方从缓冲区中取出数据传递给应用程序的时候。这个操作是接收方应用程序发出请求时才会进行的,而发送方不知道什么时候会进行这样的操作,因此当接收方将数据传递给应用程序,导致接收缓冲区剩余容量增加时,就需要告知发送方

1622725475682.jpg

那么ACK号又是什么情况呢?当接收方收到数据时,如果确认内容没有问题,就应该向发送方返回ACK号,因此我们可以认为收到数据之后马上就应该进行这一操作。

1622725475693.jpg

但如果根据这样的设计来实现,每收到一个包,就需要向发送方分别发送ACK号和窗口更新这两个单独的包。这样一来,接收方发给发送方的包就太多了,导致网络效率下降。

接收方在发送ACK号和窗口更新时,并不会马上把包发送出去,而是会等待一段时间,在这个过程中很有可能会出现其他的通知操作,这样就可以把两种通知合并在一个包里面发送了

浏览器在委托协议栈发送请求消息之后,会调用read程序来获取响应消息。然后,控制流程会通过read转移到协议栈,然后协议栈会执行接下来的操作。

1622725475689.jpg

断开Socket

收发数据结束的时间点应该是应用程序判断所有数据都已经发送完毕的时候。这时,数据发送完毕的一方会发起断开过程,但不同的应用程序会选择不同的断开时机。

1622725475680.jpg

首先,服务器一方的应用程序会调用Socket库的close程序。然后,服务器的协议栈会生成包含断开信息的TCP头部,具体来说就是将控制位中的FIN比特设为1。接下来,协议栈会委托IP模块向客户端发送数据。同时,服务器的套接字中也会记录下断开操作的相关信息。

当收到服务器发来的FIN为1的TCP头部时,客户端的协议栈会将自己的套接字标记为进入断开操作状态。然后,为了告知服务器已收到FIN为1的包,客户端会向服务器返回一个ACK号(图2.12②)。这些操作完成后,协议栈就可以等待应用程序来取数据了。

根据规则,服务器返回请求之后,Web通信操作就全部结束了,因此只要收到服务器返回的所有数据,客户端的操作也就随之结束了。因此,客户端应用程序会调用close来结束数据收发操作,这时客户端的协议栈也会和服务器一样,生成一个FIN比特为1的TCP包,然后委托IP模块发送给服务器。一段时间之后,服务器就会返回ACK号。到这里,客户端和服务器的通信就全部结束了。

和服务器的通信结束之后,用来通信的套接字也就不会再使用了,这时我们就可以删除这个套接字了。不过,套接字并不会立即被删除,而是会等待一段时间之后再被删除

至于具体等待多长时间,这和包重传的操作方式有关。网络包丢失之后会进行重传,这个操作通常要持续几分钟。如果重传了几分钟之后依然无效,则停止重传。在这段时间内,网络中可能存在重传的包,也就有可能发生前面讲到的这种误操作,因此需要等待到重传完全结束。协议中对于这个等待时间没有明确的规定,一般来说会等待几分钟之后再删除套接字。

整个流程:

1622725475678.jpg

集线器|路由器

实际上,集线器是按照以太网规则传输包的设备,而路由器是按照IP规则传输包的设备

(1)IP协议根据目标地址判断下一个IP转发设备的位置(2)子网中的以太网协议将包传输到下一个转发设备

TCP/IP包包含如下两个头部。(a)MAC头部(用于以太网协议)(b)IP头部(用于IP协议)

1622725475675.jpg

1622725475665.jpg

网络包在传输过程中会经过集线器,集线器是根据以太网协议工作的设备。为了判断包接下来应该向什么地方传输,集线器里有一张表(用于以太网协议的表),可根据以太网头部中记录的目的地信息查出相应的传输方向。这张图中只有一个集线器,当存在多个集线器时,网络包会按顺序逐一通过这些集线器进行传输。接下来,包会到达下一个路由器。

1622728147381.jpg

接下来,包会到达下一个路由器。路由器中有一张IP协议的表,可根据这张表以及IP头部中记录的目的地信息查出接下来应该发往哪个路由器。为了将包发到下一个路由器,我们还需要查出下一个路由器的MAC地址,并记录到MAC头部中,大家可以理解为改写了MAC头部。这样,网络包就又被发往下一个节点了。

1622728147380.jpg

1622725475673.jpg

1622725475670.jpg

前面讲了IP和以太网的分工,其中以太网的部分也可以替换成其他的东西,例如无线局域网、ADSL、FTTH等,它们都可以替代以太网的角色帮助IP协议来传输网络包

实际上将包从发送方传输到接收方的工作是由集线器、路由器等网络设备来完成的,因此IP模块仅仅是整个包传输过程的入口

IP模块会添加IP头部和MAC头部这两种头部。IP头部中包含IP协议规定的、根据IP地址将包发往目的地所需的控制信息;MAC头部包含通过以太网的局域网将包传输至最近的路由器所需的控制信息

接下来,封装好的包会被交给网络硬件,例如以太网、无线局域网等

传递给网卡的网络包是由一连串0和1组成的数字信息,网卡会将这些数字信息转换为电信号或光信号,并通过网线(或光纤)发送出去,然后这些信号就会到达集线器、路由器等转发设备,再由转发设备一步一步地送达接收方。

1622725475668.jpg

接收的过程和发送的过程是相反的,信息先以电信号的形式从网线传输进来,然后由网卡将其转换为数字信息并传递给IP模块。接下来,IP模块会将MAC头部和IP头部后面的内容,也就是TCP头部加上数据块,传递给TCP模块。接下来的操作就是我们之前讲过的TCP模块负责的部分了。

总之,IP的职责就是将委托的东西打包送到对方手里,或者是将对方送来的包接收下来,仅此而已

IP不会自行判断包的目的地,而是将包发往应用程序指定的接收方,即便应用程序指定了错误的IP地址,IP模块也只能照做

生成了IP头部之后,接下来IP模块还需要在IP头部的前面加上MAC头部

以太网在判断网络包目的地时和TCP/IP的方式不同,因此必须采用相匹配的方式才能在以太网中将包发往目的地,而MAC头部就是干这个用的

MAC头部是以太网使用的头部,它包含了接收方和发送方的MAC地址等信息。

首先是“以太类型”,这里填写表示IP协议的值0800(十六进制)。

这里填写网卡本身的MAC地址。MAC地址是在网卡生产时写入ROM里的,只要将这个值读取出来写入MAC头部就可以了

ARP

既然已经知道了包应该发给谁,那么只要将对方的MAC地址填上去就好了,但到这里为止根本没有出现对方的MAC地址,也就是说我们现在根本不知道对方的MAC地址是什么。因此,我们还需要执行根据IP地址查询MAC地址的操作。

1622728147375.jpg

这里我们需要使用ARP

在以太网中,有一种叫作广播的方法,可以把包发给连接在同一以太网中的所有设备。ARP就是利用广播对所有设备提问:“××这个IP地址是谁的?请把你的MAC地址告诉我。”然后就会有人回答:“这个IP地址是我的,我的MAC地址是×××

1622728147378.jpg

如果对方和自己处于同一个子网中,那么通过上面的操作就可以得到对方的MAC地址。然后,我们将这个MAC地址写入MAC头部,MAC头部就完成了。

如果每次发送包都要这样查询一次,网络中就会增加很多ARP包,因此我们会将查询结果放到一块叫作ARP缓存的内存空间中留着以后用。也就是说,在发送包时,先查询一下ARP缓存,如果其中已经保存了对方的MAC地址,就不需要发送ARP查询,直接使用ARP缓存中的地址,而当ARP缓存中不存在对方MAC地址时,则发送ARP查询。

1622728147377.jpg

例如当IP地址发生变化时,ARP缓存的内容就会和现实发生差异。为了防止这种问题的发生,ARP缓存中的值在经过一段时间后会被删除,一般这个时间在几分钟左右。这个删除的操作非常简单粗暴,不管ARP缓存中的内容是否有效,只要经过几分钟就全部删掉,这样就不会出问题了。当地址从ARP缓存中删除后,只要重新执行一次ARP查询就可以再次获得地址了。

上面这个策略能够在几分钟后消除缓存和现实的差异,但IP地址刚刚发生改变的时候,ARP缓存中依然会保留老的地址,这时就会发生通信的异常

将MAC头部加在IP头部的前面,整个包就完成了。到这里为止,整个打包的工作是由IP模块负责的

点击这里复制本文地址 以上内容由权冠洲的博客整理呈现,请务必在转载分享时注明本文地址!如对内容有疑问,请联系我们,谢谢!

支持Ctrl+Enter提交

联系我们| 本站介绍| 留言建议 | 交换友链 | 域名展示
本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除

权冠洲的博客 © All Rights Reserved.  Copyright quanguanzhou.top All Rights Reserved
苏公网安备 32030302000848号   苏ICP备20033101号-1

联系我们