这一份最全的TCP总结,请务必收下
点击下方公众号「关注」和「星标」
回复“1024”获取独家整理的学习资料!
网络分层结构
考虑最简单的情况:两台主机之间的通信。这个时候只需要一条网线把两者连起来,规定好彼此的硬件接口,如都用USB、电压10v、频率2.4GHz等,这一层就是物理层,这些规定就是物理层协议。
我们当然不满足于只有两台电脑连接,因此我们可以使用交换机把多个电脑连接起来,如下图:
这样连接起来的网络,称为局域网,也可以称为以太网(以太网是局域网的一种)。在这个网络中,我们需要标识每个机器,这样才可以指定要和哪个机器通信。这个标识就是硬件地址MAC。
硬件地址随机器的生产就被确定,永久性唯一。在局域网中,我们需要和另外的机器通信时,只需要知道他的硬件地址,交换机就会把我们的消息发送到对应的机器。
这里我们可以不管底层的网线接口如何发送,把物理层抽离,在他之上创建一个新的层次,这就是数据链路层。
我们依然不满足于局域网的规模,需要把所有的局域网联系起来,这个时候就需要用到路由器来连接两个局域网:
但是如果我们还是使用硬件地址来作为通信对象的唯一标识,那么当网络规模越来越大,需要记住所有机器的硬件地址是不现实的;
同时,一个网络对象可能会频繁更换设备,这个时候硬件地址表维护起来更加复杂。这里使用了一个新的地址来标记一个网络对象:IP地址。
通过一个简单的寄信例子来理解IP地址。
我住在北京市,我朋友A住在上海市,我要给朋友A写信:
写完信,我会在信上写好我朋友A的地址,并放到北京市邮局(给信息附加目标IP地址,并发送给路由器) 邮局会帮我把信运输到上海市当地邮局(信息会经过路由传递到目标IP局域网的路由器) 上海市当地路由器会帮我把信交给朋友A(局域网内通信)
因此,这里IP地址就是一个网络接入地址(朋友A的住址),我只需要知道目标IP地址,路由器就可以把消息给我带到。在局域网中,就可以动态维护一个MAC地址与IP地址的映射关系,根据目的IP地址就可以寻找到机器的MAC地址进行发送。
这样我们不需管理底层如何去选择机器,我们只需要知道IP地址,就可以和我们的目标进行通信。这一层就是网络层。网络层的核心作用就是提供主机之间的逻辑通信。
这样,在网络中的所有主机,在逻辑上都连接起来了,上层只需要提供目标IP地址和数据,网络层就可以把消息发送到对应的主机。
一个主机有多个进程,进程之间进行不同的网络通信,如边和朋友开黑边和女朋友聊微信。我的手机同时和两个不同机器进行通信。
那么当我的手机收到数据时,如何区分是微信的数据,还是王者的数据?那么就必须在网络层之上再添加一层:运输层:
运输层通过socket(套接字),将网络信息进行进一步的拆分,不同的应用进程可以独立进行网络请求,互不干扰。
这就是运输层的最本质特点:提供进程之间的逻辑通信。这里的进程可以是主机之间,也可以是同个主机,所以在android中,socket通信也是进程通信的一种方式。
现在不同的机器上的应用进程之间可以独立通信了,那么我们就可以在计算机网络上开发出形形式式的应用:如web网页的http,文件传输ftp等等。这一层称为应用层。
应用层还可以进一步拆分出表示层、会话层,但他们的本质特点都没有改变:完成具体的业务需求 。和下面的四层相比,他们并不是必须的,可以归属到应用层中。
最后对计网分层进行小结:
最底层物理层,负责两个机器之间通过硬件的直接通信; 数据链路层使用硬件地址在局域网中进行寻址,实现局域网通信; 网络层通过抽象IP地址实现主机之间的逻辑通信; 运输层在网络层的基础上,对数据进行拆分,实现应用进程的独立网络通信; 应用层在运输层的基础上,根据具体的需求开发形形式式的功能。
这里需要注意的是,分层并不是在物理上的分层,而是逻辑上的分层。通过对底层逻辑的封装,使得上层的开发可以直接依赖底层的功能而无需理会具体的实现,简便了开发。
这种分层的思路,也就是责任链设计模式,通过层层封装,把不同的职责独立起来,更加方便开发、维护等等。
TCP面向字节流特性
TCP并不是把应用层传输过来的数据直接加上首部然后发送给目标,而是把数据看成一个字节 流,给他们标上序号之后分部分发送。这就是TCP的面向字节流特性:
TCP会以流的形式从应用层读取数据并存放在自己的发送缓存区中,同时为这些字节标上序号 TCP会从发送方缓冲区选择适量的字节组成TCP报文,通过网络层发送给目标 目标会读取字节并存放在自己的接收方缓冲区中,并在合适的时候交付给应用层
面向字节流的好处是无需一次存储过大的数据占用太多内存,坏处是无法知道这些字节代表的意义,例如应用层发送一个音频文件和一个文本文件,对于TCP来说就是一串字节流,没有意义可言,这会导致粘包以及拆包问题,后面讲。
可靠传输原理
前面讲到,TCP是可靠传输协议,也就是,一个数据交给他,他肯定可以完整无误地发送到目标地址,除非网络炸了。他实现的网络模型如下:
对于应用层来说,他就是一个可靠传输的底层支持服务;而运输层底层采用了网络层的不可靠传输。虽然在网络层甚至数据链路层就可以使用协议来保证数据传输的可靠性,但这样网络的设计会更加复杂、效率会随之降低。把数据传输的可靠性保证放在运输层,会更加合适。
可靠传输原理的重点总结一下有:滑动窗口、超时重传、累积确认、选择确认、连续ARQ。
停止等待协议
要实现可靠传输,最简便的方法就是:我发送一个数据包给你,然后你跟我回复收到,我继续发送下一个数据包。传输模型如下:
这种“一来一去”的方法来保证传输可靠就是停止等待协议(stop-and-wait)。不知道还记不记得前面TCP首部有一个ack字段,当他设置为1的时候,表示这个报文是一个确认收到报文。
然后再来考虑另一种情况:丢包。网络环境不可靠,导致每一次发送的数据包可能会丢失,如果机器A发送了数据包丢失了,那么机器B永远接收不到数据,机器A永远在等待。
解决这个问题的方法是:超时重传。当机器A发出一个数据包时便开始计时,时间到还没收到确认回复,就可以认为是发生了丢包,便再次发送,也就是重传。
但重传会导致另一种问题:如果原先的数据包并没有丢失,只是在网络中待的时间比较久,这个时候机器B会受到两个数据包,那么机器B是如何辨别这两个数据包是属于同一份数据还是不同的数据?
这就需要前面讲过的方法:给数据字节进行编号。这样接收方就可以根据数据的字节编号,得出这些数据是接下来的数据,还是重传的数据。
在TCP首部有两个字段:序号和确认号,他们表示发送方数据第一个字节的编号,和接收方期待的下一份数据的第一个字节的编号。
连续ARQ协议
停止等待协议已经可以满足可靠传输了,但有一个致命缺点:效率太低。发送方发送一个数据包之后便进入等待,这个期间并没有干任何事,浪费了资源。解决的方法是:连续发送数据包。模型如下:
和停止等待最大的不同就是,他会源源不断地发送,接收方源源不断收到数据之后,逐一进行确认回复。这样便极大地提高了效率。但同样,带来了一些额外的问题:
发送是否可以无限发送直到把缓冲区所有数据发送完?不可以。因为需要考虑接收方缓冲区以及读取数据的能力。如果发送太快导致接收方无法接受,那么只是会频繁进行重传,浪费了网络资源。所以发送方发送数据的范围,需要考虑到接收方缓冲区的情况。这就是TCP的流量控制。
解决方法是:滑动窗口。基本模型如下:
发送方需要根据接收方的缓冲区大小,设置自己的可发送窗口大小,处于窗口内的数据表示可发送,之外的数据不可发送。 当窗口内的数据接收到确认回复时,整个窗口会往前移动,直到发送完成所有的数据
在TCP的首部有一个窗口大小字段,他表示接收方的剩余缓冲区大小,让发送方可以调整自己的发送窗口大小。通过滑动窗口,就可以实现TCP的流量控制,不至于发送太快,导致太多的数据丢失。
连续ARQ带来的第二个问题是:网络中充斥着和发送数据包一样数据量的确认回复报文,因为每一个发送数据包,必须得有一个确认回复。提高网络效率的方法是:累积确认。
接收方不需要逐个进行回复,而是累积到一定量的数据包之后,告诉发送方,在此数据包之前的数据全都收到。例如,收到 1234,接收方只需要告诉发送方我收到4了,那么发送方就知道1234都收到了。
第三个问题是:如何处理丢包情况。在停止等待协议中很简单,直接一个超时重传就解决了。但,连续ARQ中不太一样。
例如:接收方收到了 123 567,六个字节,编号为4的字节丢失了。按照累积确认的思路,只能发送3的确认回复,567都必须丢掉,因为发送方会进行重传。这就是GBN(go-back-n) 思路。
但是我们会发现,只需要重传4即可,这样不是很浪费资源,所以就有了:选择确认SACK 。在TCP报文的选项字段,可以设置已经收到的报文段,每一个报文段需要两个边界来进行确定。这样发送方,就可以根据这个选项字段只重传丢失的数据了。
可靠传输小结
到这里关于TCP的可靠传输原理就已经介绍得差不多。最后进行一个小结:
通过连续ARQ协议与发送-确认回复模式来保证每一个数据包都到达接收方 通过给字节编号的方法,来标记每一个数据是属于重传还是新的数据 通过超时重传的方式,来解决数据包在网络中丢失的问题 通过滑动窗口来实现流量控制 通过累积确认+选择确认的方法来提高确认回复与重传的效率
当然,这只是可靠传输的冰山一角,感兴趣可以再深入去研究。
来源:https://www.toutiao.com/i6954183620600906277/
这篇 ElasticSearch 详细使用教程,内部分享时被老大表扬了