看完TCP/IP传输层完了之后,感觉对传输层的认识还是比较零散,现在就将这块的内容进行比较系统的总结.
传输层协议具有代表性的是TCP协议和UDP协议,TCP是一种可靠的,安全的,进行数据通信之前必须建立连接,才能实现数据传送的传输层协议,时效性弱.UDP是一种不可靠,通信之前不需建立连接就可传输数据的传输协议,时效性强.对于两种协议在网络数据传输中各占春秋,没有谁优谁劣区分.
- 传输层
ISO协议图
传输层是ISO协议的第四层协议,实现端对端(
即发送端主机应用对接收端主机应用)的数据传输.对IP层(不可靠,无连接的一个层)传来的数据进行整理,按照其上一层期望的格式整理好后根据指定的端口,发送给应用.传输层要实现数据传输需要两端的主机设置的协议号相同;两端主机的IP用来确定计算机的网络地址;两端主机进行通信的应用端口号,能确定发收端计算机上进行通信的具体应用程序.我们可以用送快递这个例子来模拟网络上的数据传输:
邮递员
IP根据收件人地址(目的IP)向目的地(目标计算机)投递包裹(数据信息),包裹到达目的地以后,由对方(传输层协议)根据包裹信息(目的端口号)确定最终的收件人(接收端的应用).
- TCP协议和UDP协议
- TCP是面向连接的可靠的传输控制流协议,只有进行三次握手建立连接后,才能进行数据的通信,四次挥手释放连接.TCP为提供可靠的传输,实行"顺序控制"和"重发控制"机制,还有"流量控制",“拥塞控制”,提高网络利用率等功能,只能实现一对一的通信.
- UDP是不具有可靠性的数据报协议.不建立连接,数据到达对端传输层后一些细微的处理他会交给应用层去完成,传输层只是单纯实现了传输数据的功能而已,因为它没有像TCP那样对数据不仅实现传输还要做额外的各种处理工作,所以比较高速.他能实现一对一传输也可以实现一对多的数据传输.
- 对于以上这两者的用途我们要按需使用,TCP确实可靠,但是在一些应用场景下对可靠传输的要求不高的情况下,UDP协议具有更好的实时性,工作效率要比TCP高.同时,UDP的段结构要比TCP的段结构简单,能降低网络开销.
- 端口号
数据链路中的Mac地址和IP地址分别确定不同的计算机和TCP/IP网络中互连的主机和路由器.在传输层中也有类似的地址概念,就是端口号,用来识别同一台计算机中进行通信的不同应用程序,也可以认为是程序地址.
一台计算机中有很多的应用程序,像QQ,微信,web浏览器等,就像是QQ上向对方计算机发的消息不会在对方微信中提醒一样(假设对方微信和QQ都在运行),因为在传输层已经进行了端口识别这一步,才能使消息准确到达对端指定进程中.
总的来说,计算机之间的数据通信,就是建立在IP地址,端口号,协议号上进行的.
- TCP的特点及目的
TCP通过校验和,序列号,确认应答,重发控制,连接管理以及窗口控制等实现可靠性传输.
- TCP校验和是一个端到端的校验和，由发送端计算，然后由接收端验证。其目的是为了发现TCP首部和数据在发送端到接收端之间发生的任何改动。如果接收方检测到校验和有差错，则TCP段会被直接丢弃。
- 通过序列号和确认应答提高可靠性
- 数据重发超时控制:在重发数据之前,等待确认应答到来的那段时间间隔.如果超过了那个时间,发送端将对数据进行重新发送.当被发送之后,还是收不到应答就再次被发送,等待确认应答的时间也会相对于上一次以2的指数次方倍延长,即就是第二次相对于第一次等待时间是2倍,第三次相对于第二次是4倍,之后以此类推.当然不会被无限制的重发,达到一定次数之后还收不到确认应答就会被判断为对端主机或网络发生异常,前置关闭连接.并通知应用程序强行终止此连接.
- 连接管理:
即建立连接的三次握手
1.客户端向服务端发送SYN请求建立连接,2.服务端对于客户的请求做了ACK确认应答,以及服务端的SYN建立连接请求,3.客户端对服务端的ACK回应,这三部曲缺一不可,否则建立连接失败,无法传送数据.
断开连接的四次挥手
1.A端断开连接的FINAL请求 -> B端,2.B端对于这一请求的ACK回应 -> A端,3.B端再发FINAL断开连接请求 -> A端,4.A端ACK确认应答 -> B端- TCP以段为单位发送数据,在建立连接时,经过三次握手的过程中也确定了通信两端能接受的"最大消息长度"(
MSS),即在此过程中互相告知对方自己能够适应的MSS值,最终在两者中选最小的作为传输数据的MSS,最理想的最大消息长度是IP不能分片处理的最大数据长度.
传输层上层传的数据长度大于MSS值,则以MSS为单位进行数据分段传送,重发也是以MSS为单位进行分段重发.- 窗口控制
以上了解到TCP以段为单位发送数据,每发送一个段,必须等到接收方返回确认后再发送下一段否则就重发.这样要是往返时间见较长显然不是很高效,所以TCP提供滑动窗口来解决这一缺陷.
窗口大小就是无需等待确认应答而可以继续发送数据的最大值.这个有点抽象,我们就下图而言,滑动窗口大小是500,MSS值是100,即在不收到确认消息的情况下每次最大发送5个段的信息,发送端先发送第一段100字节的数据,对端没返回确认信息,还可以继续发第二段100字节,直到发送到第五段100字节的信息,如果一个确认信息都没收到,那么表明达到了滑动窗口的最大值,发送端会对已经发送的500字节数据进行重发.要是收到一个段的确认信息,就将窗口往后移动一个段的长度,同时该段被从缓冲区中清除,已经发送却没收到确认的数据超时的话,继续被重发.如果重发超时的数据长度超出滑动窗口允许的长度,那就表明网络或者连接发生了异常.
可能说的不是很清楚,所以再画添一张图,滑动窗口为3,MSS值为100:
观察上述过程,就不难理解其中的梗了.
这一机制实现了使用大量的缓冲区,通过对多个段同时进行确认应答的功能.
收到确认的情况下,将窗口滑动到确认应答中的序列号的位置,这样可以顺序的将多个段同时发送并提高通信性能.
以上已经介绍了滑动窗口的一点点知识,现在我们就这个话题继续进行深入的思考.
- 在网上看到滑动窗口和套接字缓冲区的关系这个问题?
我是这样理解的,二者其实没有什么关系,要是真要个答案的话,根据滑动窗口上面介绍的概念,他是发送端无需等待应答确认而可以继续发送数据的最大值,单位是段(MSS).我把套接字缓冲区假想作滑动窗口进行流量控制的对象,缓冲区中已发送且已收到确认的数据(即就是滑动窗口划过的数据区)将被清出缓冲区,怎么想的呢?还是这个图:
我们都能看出滑动窗口是图中的虚线大矩形部分,而滑动窗口就在最小的矩形构成的数据数据段组成的数据链(即就是套接字缓冲区)上滑动.
- 窗口控制和重发控制
- 在使用窗口控制的情况下,出现数据丢失怎么处理?
确认应答未能返回或者丢失的情况下,数据已经达到了对端,是不需要重发的,在没有使用窗口控制的情况下,没有收到确认应答的数据都会被重发.使用了窗口控制即使确认应答丢失,也无需重发.
当发送段连续接收到同一个确认应答时,就会将其对应数据段进行重发.这就是高速重发控制.- 流控制:TCP提供一种由接收端决定每次可以接收数据的大小,根据这个大小发送端每次发送过的没收到确认的数据不能超过这个大小,即就是以上所说的窗口大小,重点在后面,当接收端缓冲区溢出时,接收端会将窗口大小调整为更小的值通知给发送端,引起发送端对发送数据流量的控制,这就是TCP的流量控制机制.不难想出,发送端在发送数据期间会时不时检测窗口的变化来得知接收端改变窗口大小的信息.
- 拥塞控制
因为网络是一个所有计算机共享的空间,所以有可能因为其他主机之间的通信导致网络拥堵,因为可能会有多个主机共享一个路由器这种情况,路由器的内存是有限的.这时网络上出现拥堵时,即路由器未处理的数据达到内存限度时,不能再容纳发送方的发来的数据了,这时要是不加以控制,再发送一个比较大的数据,那可能就会导致整个网络的瘫痪.
为了在发送端调节所要发送数据的量,定义了一个叫做拥塞窗口的概念,TCP通过慢启动来调整拥塞窗口的大小,在刚开始将拥塞窗口设置为1MSS,在之后每收到一个确认,窗口就加1,在发送数据包时,对拥塞窗口和接收端的通知的窗口大小进行比较,选最小的窗口发送数据.这样通过接收端的通知和拥塞窗口的调整,就减少了网络拥堵发生的可能.
随着包的每次往返,拥塞窗口会以2的指数增加,这样剧烈的增长速度也可能导致网络拥堵的发生,为了调整增长速率,设置了阀值,只要拥塞窗口超出了这个阀值,之后每收到一次确认应答,窗口的大小就会按照下面的比例放大拥塞窗口:1个数据段的字节数的平方/拥塞窗口(字节)拥塞窗口越大,通信的吞吐量变大,再出现网络拥堵时,拥塞窗口快速缩小,吞吐量急剧减小,又再次从低往高的涨,拥塞控制实现了TCP的慢启动,快恢复.使得网络上的数据发送接收能合理的动态变化.
对于网络传输层的系统总结内容就这么多了,里面要是有些地方说的有漏洞或者不足之处,欢迎读者指出.