传输层

一、传输层概述

运输层（传输层），解决的是计算机程序到计算机程序之间的通信问题，即所谓的“端”到“端”的通信（网络层解决的是主机到主机之间的通信）。
引入传输层的原因：
增加复用和分用的功能、 消除网络层的不可靠性、 提供从源端主机到目的端主机的可靠的、与实际使用的网络无关的信息传输。运输层的最终目标是为传送服务用户提供有效、可靠和价格合理的运输服务，而传送服务的用户即会话层实体。
运输层一个重要功能——复用和分用。复用是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据，分用是指接收方的运输层在剥去报文首部后能够把这些数据正确交付目的应用进程。
运输层还要对收到的报文进行差错检测。在网络层，IP数据包首部中的检验和字段只检验首部是否出现差错而不检验数据部分。
运输层向高层屏蔽了下面网络核心的细节，他使应用进程看见的就是好像两个运输层之间有一条端对端的逻辑通道。

image.png

传输层寻址通道和端口：

image.png

---

二、用户数据报协议 UDP

UDP只是在IP数据包服务上增加了很少的功能，即复用分用和差错检测功能。
UDP的特性
①UDP是面向无连接的，减小开销和发送数据之前的时延，传输数据前不用建立连接，收到UDP报文后不用给出确认。
②UDP使用最大努力交付，即不保证可靠交付
③UDP是面向报文的，即一次交付一个完整的报文
④UDP无拥塞控制，时延小，适合实时通信
⑤UDP首部开销小，只有8字节，TCP首部固定部分为20字节
⑥UDP支持一对一、一对多、多对多的交互通信

image.png

伪首部：并不是真正的首部，只在UDP检验时出现，与IP首部相同，不向下传递也不想上提供；

UDP报文格式：
由8字节组成，分为四个部分，每个部分占用2字节
源端口、目的端口、长度、检验和

UDP检验和

image.png

在发送端：
①添加伪首部（源IP地址+目的IP地址+全0+17+15）
②全0添加校验和字段
③全0填充数据字段（用0补全）
④伪首部+首部+数据部分采用二进制反码求和
⑤将上述的和求反码填入检验和字段
⑥去掉伪首部，发送

在接收端：
①填上伪首部
②伪首部+首部+数据部分 采用二进制反码求和
③结果全为1则说明无差错。反之丢弃或者交给应用层并附上出错警告

---

三、传输控制协议 TCP

①TCP是面向连接的，传输数据前必须建立连接，数据传输完成后释放连接；

②TCP不提供广播和多播服务，只能一对一传输；

③TCP提供可靠交付的服务；

④TCP提供全双工通信；

⑤面向字节流，TCP把应用程序交下来的数据看成一连串的无结构的字节流（流入到进程或从进程流出的字节序列）；

6.1TCP连接

每一条TCP连接唯一的被通信的两个端点（即两个套接字）所确定。套接字socket=（IP地址：端口号），例如192.168.1.1：80。

6.2TCP可靠传输

ARQ (Automatic Repeat reQuest)
6.2.1工作原理
TCP报文是交给IP层传送的，但是IP曾只能提供尽最大努力服务（不可靠传输）。因此TCP必须采取适当的措施才能使得传输可靠。停止等待ARQ协议和连续ARQ协议都属于自动重传请求协议ARQ（数据链路层的错误纠正协议之一）的一部分。
6.2.2停止等待ARQ协议
停止等待就是每发送完一个分组就停止发送，等待对方的确认。在收到确认之后再发送下一个分组。在传输过程中会出现无差错情况（正常）、出现差错（重传）、确认丢失（接收方返回的确认消息丢失，发送方到固定时间重传，接收方会丢弃第二次的数据并且返回新的确认）和确认迟到（发送方返回的确认信息丢失，则接收方接收到延时的确认信息时直接丢弃，接收方收到重复的数据时也直接丢弃）四种情况。停止等待协议简单但是信道利用率低。
6.2.3连续ARQ协议
可提高信道利用率，发送方维持一个发送窗口。凡是位于发送窗口的分组可以连续的发送出去，而不需要等待对方的确认。接收方一般采用累计确认，对按序列到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。
6.2.4 TCP可靠传输的实现
1.数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
2.对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；
3.丢弃重复数据：对于重复数据，能够丢弃重复数据；
4.应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
5.超时重传:当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
6.流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

6.3TCP报文结构

首部+数据
首部：固定部分20字节+可变长部分

image.png

源端口和目的端口字段——各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。
序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。
确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。
数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）。
保留字段——占 6 位，保留为今后使用，但目前应置为 0。
**紧急 URG —— 当 URG = 1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。
**确认 ACK —— **只有当 ACK = 1 时确认号字段才有效。当 ACK = 0 时，确认号无效。
推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。
**复位 RST (ReSeT) —— **当 RST  1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
**同步 SYN —— **同步 SYN = 1 表示这是一个连接请求或连接接受报文。
**终止 FIN (FINis) —— **用来释放一个连接。FIN  1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。
窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。
**检验和 —— **占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。
**紧急指针字段 —— **占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。
**选项字段 —— **长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”
**填充字段 —— **这是为了使整个首部长度是 4 字节的整数倍。

6.4TCP建立连接（三次握手）

image.png

最初客户端和服务端都处于 CLOSED(关闭) 状态。本例中 A（Client） 主动打开连接，B（Server） 被动打开连接。
　　一开始，B 的 TCP 服务器进程首先创建传输控制块TCB，准备接受客户端进程的连接请求。然后服务端进程就处于 LISTEN(监听) 状态，等待客户端的连接请求。如有，立即作出响应。

第一次握手：A 的 TCP 客户端进程也是首先创建传输控制块 TCB。然后，在打算建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN=1，同时选择一个初始序号 seq = x。TCP 规定，SYN 报文段（即 SYN = 1 的报文段）不能携带数据，但要消耗掉一个序号。这时，TCP 客户进程进入 SYN-SENT（同步已发送）状态。

第二次握手：B 收到连接请求报文后，如果同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时 TCP 服务端进程进入 SYN-RCVD（同步收到）状态。

第三次握手：TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。这时 ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态。

相关面试题：
①为什么两次握手不可以呢？
为了防止已经失效的连接请求报文段突然又传送到了 B，因而产生错误。比如下面这种情况：A 发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达 B。本来这是一个早已失效的报文段。但是 B 收到此失效的链接请求报文段后，就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。

对于上面这种情况，如果不进行第三次握手，B 发出确认后就认为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。如果采用了三次握手，由于 A 实际上并没有发出建立连接请求，所以不会理睬 B 的确认，也不会向 B 发送数据。B 由于收不到确认，就知道 A 并没有要求建立连接。
②为什么不需要四次握手呢？
有人可能会说 A 发出第三次握手的信息后在没有接收到 B 的请求就已经进入了连接状态，那如果 A 的这个确认包丢失或者滞留了怎么办？我们需要明白一点，完全可靠的通信协议是不存在的。在经过三次握手之后，客户端和服务端已经可以确认之前的通信状况，都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠，所以是没有必要的。
③Server 端收到 Client 端的 SYN 后，为什么还要传回 SYN？
接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。
SYN 是 TCP / IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement[汉译：确认字符，在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误]）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。
④传了 SYN，为什么还要传 ACK？
双方通信无误必须是两者互相发送信息都无误。传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。

6.5TCP释放连接（四次挥手）

image.png

第一次挥手：A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u（等于前面已传送过的数据的最后一个字节的序号加 1），这时 A 进入 FIN-WAIT-1（终止等待1）状态，等待 B 的确认。请注意：TCP 规定，FIN 报文段即使不携带数据，也将消耗掉一个序号。
第二次挥手：B 收到连接释放报文段后立即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v（等于 B 前面已经传送过的数据的最后一个字节的序号加1），然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务端进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。A 收到来自 B 的确认后，就进入 FIN-WAIT-2(终止等待2)状态，等待 B 发出的连接释放报文段。
第三次挥手：若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。假定 B 的序号为 w（在半关闭状态，B 可能又发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态，等待 A 的确认。
第四次挥手：A 在收到 B 的连接释放报文后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号 seq = u + 1（前面发送的 FIN 报文段要消耗一个序号）。然后进入 TIME-WAIT(时间等待) 状态。请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，A 才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果 B 一收到 A 的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，B 结束 TCP 连接的时间要早于 A。
相关面试题
①为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢？
a. 为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失，因而使处在 LAST-ACK 状态的 B 收不到对已发送的 FIN + ACK 报文段的确认。B 会超时重传这个 FIN+ACK 报文段，而 A 就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。接着 A 重传一次确认，重新启动 2MSL 计时器。最后，A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间，而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN + ACK 报文段，因而也不会再发送一次确认报文段，这样，B 就无法按照正常步骤进入 CLOSED 状态。
b. 防止已失效的连接请求报文段出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。
②为什么第二次跟第三次不能合并, 第二次和第三次之间的等待是什么?
当服务器执行第二次挥手之后, 此时证明客户端不会再向服务端请求任何数据, 但是服务端可能还正在给客户端发送数据（可能是客户端上一次请求的资源还没有发送完毕），所以此时服务端会等待把之前未传输完的数据传输完毕之后再发送关闭请求。

6.6TCP流量控制

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

6.7TCP拥塞控制

拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。
拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致于过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP 的拥塞控制采用了四种算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。

• 慢开始：慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。

• 拥塞避免：拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1
  举例
  |

  image.png |
  |-|
  当 TCP 连接进行初始化时，将拥塞窗口置为 1。图中的窗口单位不使用字节而使用报文段。
  慢开始门限的初始值设置为 16 个报文段，
  即 ssthresh = 16。
  发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。
  在执行慢开始算法时，拥塞窗口 cwnd 的初始值为 1，发送第一个报文段 M0。
  发送端每收到一个确认 ，就把 cwnd 加 1。于是发送端可以接着发送 M1 和 M2 两个报文段。
  接收端共发回两个确认。发送端每收到一个对新报文段的确认，就把发送端的 cwnd 加 1。现在 cwnd 从 2 增大到 4，并可接着发送后面的 4 个报文段。
  当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时（即当 cwnd = 16 时），就改为执行拥塞避免算法，拥塞窗口按线性规律增长。
  假定拥塞窗口的数值增长到 24 时，网络出现超时，表明网络拥塞了。
  更新后的 ssthresh 值变为 12（即发送窗口数值 24 的一半），拥塞窗口再重新设置为 1，并执行慢开始算法。
  当 cwnd = 12 时改为执行拥塞避免算法，拥塞窗口按按线性规律增长，每经过一个往返时延就增加一个 MSS 的大小。

• 快重传：在 TCP/IP 中，快速重传和快恢复（FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。
  快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认。这样做可以让发送方及早知道有报文段没有到达接收方。
  发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段。
  快重传举例
  |

  image.png |
  |-|

• 快恢复算法：当发送端收到连续三个重复的确认时，就执行“乘法减小”算法，把慢开始门限 ssthresh 减半。但接下去不执行慢开始算法。由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，即拥塞窗口 cwnd 现在不设置为 1，而是设置为慢开始门限 ssthresh 减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。
  |

  image.png |
  |-|