计算机网络——运输层

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

  运输层和网络层的区别：

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

  可靠传输是如何实现的？

  可靠传输的实现是依靠的确认机制，确认机制在稍后介绍的停等协议中都有所体现。同时为了提高效率，也慢慢开发出了连续的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是一个二元组<IP地址，端口号>。通过socket可以实现通信，我们的课程设计就是使用socket完成一个聊天室（用的语言是python），我把github代码链接放在这里有需要的可以去看看：（https://github.com/Max-luo-song/Chat-room）。Socket总体分为两部分服务器端和用户端，之间建立连接的过程可以用这张图来表示：

  可靠的传输原理

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

  停等协议

  停等协议的思想是发送方将数据发送出去，接受方接受后进行确认，确认无误后反发送一个确认信息。发送方一直等着，直到收到确认信息，认为这是一次成功的发送。于是接着按照上面的思路发送后面的数据。
  停等协议有三种情况，这里用图表示特别清楚，我就用图表示了：
  1） 无差错情况：

  2） 出现差错：

  这个解释一下，当接收方确认发送的数据有错误时，不做任何处理，丢弃报文。而发送方有一个超时重传的计时器，如果超过计时器时间，仍没有接受到确认信息。认为发送失败，再次发送同样的数据，直至成功。这种计时器的思想在可靠传输中多次得到应用。
  3） 确认丢失和确认迟到：

  其实确认丢失和发送错误对于发送方来说是一样的，都是没有收到确认信息，按时重传。但接收方在确认丢失的时候已经收到了一份数据，对于再次重传的相同数据选择直接丢失。确认迟到是轮到发送方对确认数据进行丢弃。
  从上面的描述应该基本了解了停等协议了吧，但它有个缺点太明显了：慢，太慢了，效率太低了，一个一个的，啥时候能够完事儿？效率低换个专业点儿的名词就是信道利用率太低。对此进行改进：流水线模式。
  流水线模式就是同时发送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） 快恢复：针对于丢失后的重复确认（累计确认思想），达到三次认为出现拥塞，调整发送窗口及上限值。
整个拥塞控制过程可以用这样两张图来表示：


  Ssthresh代表门阀值（进入拥塞避免阶段的临界值），cwnd代表发送窗口的当前大小。、
说了这么多，那判断网络拥塞的具体标志是什么呢？超时就是发生了网络拥塞。
  下面解释上面的问题，为什么流量控制是局部的，拥塞控制是全局的？
  流量控制中的局部指的是端到到端的，比如上面我们举得例子都是在一个发送过程中进行的。至于拥塞控制是全局的获取可以这样解读：拥塞控制本身面对的就是全网络的负荷，本身就是一个全局变量。这个里面给了一个相对清晰的解释：http://wenda.tianya.cn/question/0cbf85dd193d4aedlink

  TCP运输连接管理

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

  TCP三次报文握手建立连接

  首先看看三次报文都是那三次，看个图吧：

  其次，为什么要三次握手呢，A在一次交互后为什么要再发送一次呢？
  这个主要是为了防止失效的连接请求再次占据B的资源。如果A第一次发送请求，B没有收到，那么A超时后会再次发送请求，这次B收到了并回复。但第一次A发送的并没有丢，而是迟到了。B收到了，以为A又请求一次，那又要分配资源给这次的连接。通过在最后加上第三次握手，如果这种情况发生，B收到第一次发送的第一条报文，但迟迟收不到第三条，就了解情况啦，及时进行释放~

  TCP四次报文握手释放连接

  先看看哪四次握手释放连接

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