计算机网络——运输层

  我认为应该带着问题进入运输层。做了通信的最高层,运输层和网络层有什么区别呢?都说运输层实现了可靠传输,那可靠传输是如何实现的呢?当信道中发生拥塞的时候,在运输层是怎么进行处理的呢?

  运输层和网络层的区别:

  网络层提供的主机与主机之间的通信,而运输层具体到了不同主机中进程和进程之间的通信。另外在网络层及以下传输的可靠性无法保证,但运输层实现了可靠传输。

  可靠传输是如何实现的?

  可靠传输的实现是依靠的确认机制,确认机制在稍后介绍的停等协议中都有所体现。同时为了提高效率,也慢慢开发出了连续的AQR等协议。

  运输层是如何处理阻塞的?

  阻塞发生的原因的是处理速度赶不上发送速度,导致接受窗口慢载甚至溢出丢失。通常处理速度无法更改,更为普遍的方法是更改发送速度。
  下面进行知识点的梳理,相信读完之后能够更深刻的理解这几个问题。
  运输层的功能是为应用层提供服务。从运输层的角度看,通信的真正端点是进程而不是主机。这个进程就是指应用进程。还有提运输层的时候总说上端口这个词。那什么是端口呢?端口其实分两种:软件端口和硬件端口(路由器或者交换机上的)。软件端口指在协议栈层间的抽象的协议端口。而硬件端口是不同硬件设备进行交互的接口。暂时不提硬件,软件端口和进程有什么关系呢?软件端口是找到具体进程的方法
  运输层主要包含了两类协议:UDP和TCP,下面对这两者进行介绍:

  用户数据报协议UDP(User Datagram Protocol)

  首先说明UDP是面向无连接的,也就是说明UDP是不可靠的。虽然UDP是不可靠的但它仍是一种有效地工作方式。那不可靠的UDP和网络层相比有什么区别呢?
  UDP提供了额外的一些功能:复用和分用,差错检测
  复用和分用:主机间相互交流的时候有可能不止一个进程,为每一个进程通信建立一个通信过程不太现实。于是使用复用技术把所有进程都统一在一起进行传输,等到接收端的运输层再使用分用技术将各个进程分开分别进行交付。
  差错检测:记得网络层也进行了差错检测,那UDP的差错检测和网络层的有什么不同吗?其实网络层的差错检测只是检查了数据报的头部,而没有查具体的数据。但运输层实现了数据部分的差错检测。而且UDP对于错误数据的处理方式就是直接扔。
  UDP还有这么几个特点:
    1) UDP是面向报文的:啥叫面向报文呢?可以理解成不管报文长短,来了就发送。只要应用层给过来数据,不管大小,加上首部后就会给到应用层。
    2) UDP没有拥塞控制:
没有拥塞控制就代表UDP的发送方不管信道中什么样子,发送速率保持恒定。这有好有坏。后面会介绍基于此特性的应用。
    3) UDP支持一对一,一对多。多对一和多对多的交互通信:
    4) UDP的首部开销小:这个因为UDP的首部固定8个字节,而TCP是20个字节。
  那UDP有什么应用呢?
  流媒体视频播放:UDP提供不可靠传输,丢包不可避免。但在视频文件传输过程中丢失部分包也不要紧。只要保证流畅就可以,而UDP正好满足时延小这个特性。
  QQ:我是真的没想到QQ是用UDP来实现的,准确来说是UDP为主,TCP为辅。不过腾讯也怕聊天丢包,也在上层做了一些处理。但QQ用的人实在太多,并发量太大只有UDP的才满足条件。感兴趣的可以看看:https://blog.csdn.net/qq_42514453/article/details/85574949

  传输控制协议TCP(Translation Control Protocol)

  其实TCP没有什么太多东西可以说的,特点就是可靠传输,会在后面介绍。但TCP是面向字节流的:什么叫面向字节流的呢?可以这么理解:TCP会根据应用层传下来的数据大小做一个决策。如果太大会将数据切分,如果太小会暂放缓存区,等下次的数据一起到达一定规模后发送。
  TCP还有一个点是套接字,又叫socket。Socket是一个二元组。通过socket可以实现通信,我们的课程设计就是使用socket完成一个聊天室(用的语言是python),我把github代码链接放在这里有需要的可以去看看:(https://github.com/Max-luo-song/Chat-room)。Socket总体分为两部分服务器端和用户端,之间建立连接的过程可以用这张图来表示:
计算机网络——运输层_第1张图片

  可靠的传输原理

  传输层的主要内容还是在这里,按照教材介绍两种:停等协议和连续ARQ协议

  停等协议

  停等协议的思想是发送方将数据发送出去,接受方接受后进行确认,确认无误后反发送一个确认信息。发送方一直等着,直到收到确认信息,认为这是一次成功的发送。于是接着按照上面的思路发送后面的数据。
  停等协议有三种情况,这里用图表示特别清楚,我就用图表示了:
  1) 无差错情况:
计算机网络——运输层_第2张图片
  2) 出现差错:
计算机网络——运输层_第3张图片
  这个解释一下,当接收方确认发送的数据有错误时,不做任何处理,丢弃报文。而发送方有一个超时重传的计时器,如果超过计时器时间,仍没有接受到确认信息。认为发送失败,再次发送同样的数据,直至成功。这种计时器的思想在可靠传输中多次得到应用。
  3) 确认丢失和确认迟到:
计算机网络——运输层_第4张图片
  其实确认丢失和发送错误对于发送方来说是一样的,都是没有收到确认信息,按时重传。但接收方在确认丢失的时候已经收到了一份数据,对于再次重传的相同数据选择直接丢失。确认迟到是轮到发送方对确认数据进行丢弃。
  从上面的描述应该基本了解了停等协议了吧,但它有个缺点太明显了:慢,太慢了,效率太低了,一个一个的,啥时候能够完事儿?效率低换个专业点儿的名词就是信道利用率太低。对此进行改进:流水线模式
  流水线模式就是同时发送n组,n组分别确认。这样大大的提高了信道利用率了。但思考下流水线模式有没有什么问题?如果一口气不停的发送,也不管是否接收到是否会出现发了第100个,但第一个还没确定的情况。为了对其进行规范化,提出了连续ARQ协议。

  连续ARQ协议:

  连续ARQ协议结合停等协议和流水线思路,但做了一点儿限制。限制发送窗口的大小,只有接收到窗口末端的数据确认时才能向前移动。有没有觉得一个包一次确认有点麻烦?在连续ARQ协议中对这个进行了一个优化:累计确认。累计确认指对按序到达的最后一个分组发送确认。累计确认优点是容易实现,确认丢失也不必重传。缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。在累计确认的背景下,接收方是按序接受,乱序到达也丢弃。这样一种情况,发了五个,但只收到第二个确认信息,发送方应当从第三个开始重发,此时窗口已经移动就需要回退,这个动作就叫Go-back-N。所以通信质量不好的时候,连续发送回退,连续ARQ会有负面影响的
  再想一下,这个连续ARQ还有什么地方可以改善的吗?还按照上面的例子,如果第一遍第四个正常收到。但Go-back-N后,第四个又要再发一遍。这是一种浪费啊!于是提出选择确认SACK,作用就是防止发送方重复发送已成功接受的,给发送方信息,那些成功到达。肯定是方便,但实现起来要在接收方加入缓存,也算多加了硬件条件。
  最开始停等协议里有一个超时重传时间,那这个时间具体是怎么确定的呢?这个实在是不懂了,有需要的教材P225页会给你答案的。
  TCP有两种控制:流量控制和拥塞控制。课上的时候重点的介绍了拥塞控制。对于流量控制我简单的说说为啥要进行流量控制:当大量数据包涌入网络时,路由器的处理速度有限,来不及处理的要放到缓存中排队(排队方式是FIFO)。缓存也是有限的,满了就要丢弃数据包,这是不希望看到的(如果对传输质量质量要求比较高的地方)。所以控制发送速率成了一种手段,也就是流量控制。所以流量控制的核心是控制接收方
  拥塞控制
  有的地方其实不是特别区分流量控制和拥塞控制这两个概念。它们的目的是共同的:为了网络传输的顺利进行。如果非要区分可以这样,有两点不同:
  流量控制的核心控制接收方,拥塞控制的核心是控制发送方
  流量控制是局部的,拥塞控制是全局的。(稍后解释,为什么这么说)。
  拥塞控制包括四个过程(就是ADMI算法(Additive Increase Multiplicative Decrease)):
  1) 慢开始:开始的时候不知道具体窗口,起点设置的比较低。但增长速率比较快,每轮倍数增长。
  2) 拥塞避免:已经发现一些问题,猜测有拥塞的可能。开始线性增长,每轮加1.
  3) 快重传:当发现数据丢失时,立即重传。(更像是一种思想)
  4) 快恢复:针对于丢失后的重复确认(累计确认思想),达到三次认为出现拥塞,调整发送窗口及上限值。
整个拥塞控制过程可以用这样两张图来表示:
计算机网络——运输层_第5张图片
计算机网络——运输层_第6张图片
  Ssthresh代表门阀值(进入拥塞避免阶段的临界值),cwnd代表发送窗口的当前大小。、
说了这么多,那判断网络拥塞的具体标志是什么呢?超时就是发生了网络拥塞
  下面解释上面的问题,为什么流量控制是局部的,拥塞控制是全局的
  流量控制中的局部指的是端到到端的,比如上面我们举得例子都是在一个发送过程中进行的。至于拥塞控制是全局的获取可以这样解读:拥塞控制本身面对的就是全网络的负荷,本身就是一个全局变量。这个里面给了一个相对清晰的解释:http://wenda.tianya.cn/question/0cbf85dd193d4aedlink

  TCP运输连接管理

  前面说到TCP是面向连接的,那么自然有建立连接和释放连接两个过程了。不过和普通的两报文握手连接不同,TCP建立连接使用三次报文握手,释放连接使用四次报文握手。为什么?
  先解释下握手:即TCP发送数据报文进行通信的过程(单向)

  TCP三次报文握手建立连接

  首先看看三次报文都是那三次,看个图吧:
计算机网络——运输层_第7张图片
  其次,为什么要三次握手呢,A在一次交互后为什么要再发送一次呢?
  这个主要是为了防止失效的连接请求再次占据B的资源。如果A第一次发送请求,B没有收到,那么A超时后会再次发送请求,这次B收到了并回复。但第一次A发送的并没有丢,而是迟到了。B收到了,以为A又请求一次,那又要分配资源给这次的连接。通过在最后加上第三次握手,如果这种情况发生,B收到第一次发送的第一条报文,但迟迟收不到第三条,就了解情况啦,及时进行释放~

  TCP四次报文握手释放连接

  先看看哪四次握手释放连接
计算机网络——运输层_第8张图片
  其次,为什么要四次握手呢?
  释放连接的四次各有作用:A主动进行关闭,发送提示信息给B(第一次握手)。B收到信息后回复(第二次握手)。但B回复的时候数据可能还没发送完,有的A发的B还没收到,需要等待一个FIN-WAIT-2时间。等到B收到全部数据后,发送信息给A(第三次握手),告诉收集全了。最后A在对B最后的信息进行确认(第四次握手),等待2MSL的原因就是确保B收到了第四次握手的信息(否则B会主动发送没收到第四次握手,如果在2MSL时间段内监听到,则再次发送第四次信息),其次也可以等待信道中所有有关于本次通信的信息全部消失,以免影响后续的通信。

你可能感兴趣的:(计算机网络)