- 本篇文章是对 湖科大计算机网络微课堂 中运输层的笔记总结，希望对大家有所帮助。
5.1运输层概述
在计算机网络中进行通信的真正实体是通信主机中的进程。
运输层的任务是为运行在不同主机的进程之间提供直接的通信服务，运输层协议又称为端到端协议。
根据应用需求不同，运输层为应用层提供两种不同的运输协议，即 面向连接的TCP 和 无连接的UDP。
5.2运输层端口号、复用与分用的概念
1.端口号
运行在计算机的进程使用 进程标识符PID 来标志的。
然而，因特网上的计算机并不是使用统一的操作系统，不同的操作系统（windows，linux，Mac OS）使用不同格式的进程标识符。
为了使运行不同操作系统的计算机的应用进程之间能够进行通信，就必须使用统一的方法对TCP/IP体系中的应用进程进行标识。
TCP/IP体系的运输层使用端口号来区分不同的应用进程。
- 端口号使用16比特表示，取值范围为0-65535，分为以下三种：
- 熟知端口号：0-1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议，如：FTP使用21和20号端口，HTTP使用80号端口，DNS使用53端口号。
- 登记端口号：1024-49151，为没有熟知端口号的应用进程使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复，例如微软远程桌面RDP使用的端口号为3389。
- 短暂端口号：49152-65535，留给客户进程暂时使用。通信结束后，这个端口号可供其他客户进程使用。
- 端口号只具有本地意义，即端口号只是为了标识本计算机中各进程，不同计算机可能有相同的端口号，但是并没有任何关系。
2.发送方的复用和接收方的分用
3.应用层常用协议使用的端口号
TCP/IP体系的 应用层常用协议 所使用的 运输层熟知端口号 ：
4.举例说明端口号的作用
应用场景：用户通过输入网址查询网页内容。
当用户使用浏览器访问Web服务器时，用户PC中的DNS客户端进程会发送一个DNS查询请求报文，其内容为 “域名为www.porttest.com"的IP地址是什么” 。
DNS查询请求报文 被 运输层的UDP协议封装成UDP用户数据报，数据报首部的源端口字段值在短暂端口号49151-65535中挑选一个未被使用过的，目的端口字段的值设置为53，这是DNS服务器端进程所使用的熟知端口号。
然后封装成IP数据报发送。
- DNS服务器收到IP数据报后，从中解封出UDP用户数据报，数据报中目的端口号为53表明应将UDP用户数据报的数据载荷部分（也就是DNS查询请求报文）上交给DNS服务器端进程。
- DNS服务器端进程 解析 DNS查询请求报文的内容，然后查找对应的IP地址，并发送DNS查询响应报文，其内容为*“域名为www.porttest.com"的IP地址是192.168.0.3”*。
- DNS响应报文被封装成UDP用户数据报，数据报首部的源端口号为53，目的端口号为49152。
- 然后封装成IP数据报进行发送。
- 用户PC收到IP数据报后，进行解封出UDP用户数据报，数据报中的目的端口号为49152表明应将UDP用户数据报的数据载荷部分（也就是DNS响应报文）上交给DNS客户端进程。
- DNS客户端进程 解析 DNS响应报文中的内容，知道之前请求的域名对应的IP地址。
- 现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文了。
- HTTP请求报文内容为*“首页内容是什么？”*，接着被运输层的TCP协议封装成TCP报文段，其首部的源端口值在短暂端口号49151-65535中挑选一个未被使用过的，目的端口号为80，这是HTTP服务器端进程所使用的熟知端口号。
- 然后封装成IP数据报进行发送。
剩余的流程和上面类似，于是这里不再赘述啦。
5.3 UDP和TCP的对比
UDP 和 TCP 是TCP/IP体系结构运输层中的两个重要协议。
以下是从几个方面对两者的比较：
- UDP可以随时发送数据，也就是无连接的。
- TCP发送数据之前需要先建立连接，也就是面向连接的。
- 在局域网中，UDP可以发送单播，多播，广播数据
- 而TCP只能发送单播数据。
对应用报文的处理方式不同：
- UDP对应用层的应用层报文直接添加一个首部，然后直接进行发送。接收方接收数据报后去掉首部，上交给上层应用层。
- TCP把应用层交付下来的数据块仅仅看作是一连串的，无结构的字节流，并将它们进行编号，存储在自己的发送缓存中，TCP根据发送策略，从发送缓存中提取一定数量的字节，构建成TCP报文段进行发送。接收方一方面从所接受的TCP报文段中取出数据载荷部分并存储在接收缓存中，一方面将接收缓存的一些字节交付给应用进程。
- UDP协议向其上层提供的是无连接不可靠传输服务，数据报发生误码仅仅丢弃，并不会采取其他措施。
- TCP协议向其上层提供的是面向连接的可靠服务。
- UDP由于不提供可靠传输服务，首部比较简单。
- TCP由于要实现可靠传输，流量控制，拥塞控制等服务，其首部比较复杂。
小结：
5.4 TCP的流量控制
流量控制：让发送方不要发送得太快，要让接收方来得及接受。
TCP协议中使用 滑动窗口 机制来实现流量控制。
举例说明：
假设主机A发送的每个TCP报文段可携带100字节数据。
在主机A和主机B建立TCP连接时，B告诉A：我的接收窗口为400，因此主机A将自己的发送窗口也设置为400。
主机A将发送窗口中1到100的数据封装成一个报文段发送出去，此时发送窗口还有300字节可以发送。
接着主机A将发送窗口中101到200的数据封装成一个TCP报文段发送出去，此时发送窗口还有200字节可以发送。
接着主机A将发送窗口中201到300的数据封装成TCP报文段发送出去，但该报文段在传输过程中丢失了，此时发送窗口还有100字节可以发送。
主机B对200之前的数据进行了确认，并在该确认中将窗口值调整为300（B根据自身情况进行调整的），对主机A进行第一次流量控制。
- 主机A收到该确认后，将发送窗口向前滑动，使那些已经发送并且收到确认的数据移出发送窗口，同时将自己的发送窗口调整为300。
- 主机A现在可将发送缓存中1到200的字节删除了，因为已经收到主机B对它们的累积确认了。
- 主机A将301到400的字节封装成报文段发送出去，发送窗口此时还有100个字节可以发送。
- 接着主机A将400到500的字节封装成TCP报文段发送出去，此时发送窗口没有数据可以发送了。
- 发送窗口内201到300这100个字节的重传计时器超时了，主机A重新封装并发送。
- 主机B对201到500的字节数据进行确认，并在累积确认中将窗口字段值改为100，这是主机B对主机A进行的第二次流量控制。
接下来的过程类似，这里仅通过图片描述，不再进行文字赘述。详细过程可看这个视频
注意：这里可能出现死锁，解决办法：启动持续计时器，超时后发送零窗口探测报文。
TCP为每一个连接设有一个持续计时器，只要一方收到对方的零窗口通知，就启动持续计时器，当计时器超时，就发送一个零窗口探测报文，仅携带一字节的数据， 接收方接受后给出自己的窗口值，如果还是零，持续计时器重新启动。
零窗口探测报文也可能丢失，解决办法：再来个重传计时器，超时重传。
练习题：
5.5 TCP的拥塞控制
1.基本概念
拥塞：对网络中某一资源的需求超过了该资源所能提供的，网络资源就要变坏。
网络资源：链路容量（即带宽），交换节点中的缓存和处理机等。
出现拥塞而不进行控制，整个网络的吞吐量将会随着输入负荷的增大而下降。
理想的拥塞控制、实际的拥塞控制，无拥塞控制的曲线如下图所示：
2.拥塞控制算法
TCP的四种拥塞控制算法：
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
为了更好地介绍这几种算法，假定以下条件：
- 数据是单方向发送的，另一方向仅发送确认
- 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。
- 以最大报文段的个数为讨论问题的单位，而不是以字节为单位。
真正的发送窗口值 = Min (接收方窗口值，拥塞窗口值)
（1）拥塞窗口和慢开始门限
发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。
- 拥塞窗口cwnd的维护原则：网络没有出现拥塞，拥塞窗口就大一些，网络出现拥塞，拥塞窗口就减少一些。
- 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生了超时重传）
前面我们假定条件接收方有足够的缓存可以接受，所以这里发送方将拥塞窗口作为发送窗口swnd，即swnd=cwnd。
发送方还要维护一个慢开始门限ssthresh的状态变量：
- 当cwnd < ssthresh 时，使用慢开始算法。
- 当cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
- 当cwnd = ssthresh 时，即可使用慢开始算法，也可使用拥塞避免算法。
（2）慢开始算法
慢开始算法：每经过一个传输轮次，拥塞窗口就加倍。
传输轮次：发送方发送完报文段并且接收方进行确认，也就是一个往返时间。
下面通过举例来进行介绍：
在刚建立连接时，拥塞窗口值被设置为1，本例慢开始门限值为16。
由于拥塞窗口值为1，发送方只能发送一个报文段。
发送方收到确认报文段后，将拥塞窗口值加1增大到2。此时发送方可以发送两个报文段。
发送方收到确认报文段后，将拥塞窗口值加2增大到4。此时发送方可以发送四个报文段。
发送方收到确认报文段后，将拥塞窗口值加4增大到8。此时发送方可以发送8个报文段。
发送方收到确认报文段后，将拥塞窗口值加8增大到16，此时拥塞窗口值等于慢开始门限值，之后，改用拥塞控制算法，也就是拥塞窗口值只能线性加1。
发送方收到确认报文段后，将拥塞窗口值加1增大到17。此时发送方可以发送17个报文段。
随着传输轮次的增加，拥塞窗口值每轮次都线性加1。假设现在拥塞窗口值为24，发送方可以发送24个报文段，但是在传输过程中丢失了几个，这会导致发送方对这些报文段的超时重传，发送方以此判断网络很可能出现了拥塞，需要进行以下工作：
- 将慢开始门限值更新为发生拥塞时拥塞窗口的一半
- 将拥塞窗口值减少为1，并重新执行慢开始算法
然后继续循环上述过程
（3）拥塞避免算法
拥塞避免算法：每经过一个传输轮次，拥塞窗口 cwnd = cwnd + 1。
（4）快重传
有时候，个别报文段的丢失，并不是因为网络的拥塞，可能是目的地址不存在或者其他情况。
但这将会导致超时重传，发送方误认为是网络发生了拥塞，发送方会将拥塞窗口值设置为1，并错误地启动慢开始算法，降低了传输效率。
于是出现了快重传算法和快恢复算法。
采用快重传能使发送方尽早知道发生了个别报文段的丢失，并尽快进行重传，而不是等超时重传计时器超时再重传，这样发送方就不会误认为是网络拥塞了。
实现快重传：
- 要求接收方不要等到自己发送数据时才捎带确认，而是要立即发送确认。
- 即使收到了失序的报文段也要立即对已收到报文段的重复确认。
- 发送方一旦收到3个连续的重复确认后，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
举例说明：
（5）快恢复算法
发送方一旦收到3个重复确认，就知道现在只是丢失了个别报文段，于是不启动慢开始算法，而执行快恢复算法。
发送方将慢开始门限值和拥塞窗口值调整为当前窗口的一半，开始执行拥塞避免算法。
也有的快恢复是把拥塞窗口值再增大一些，即等于新的慢开始门限值+3。理由是：既然发送方已经收到了3个重复确认，说明有3个报文段离开网络到达接收方了，那么就不会消耗网络资源了，所以可以适当把拥塞窗口值扩大些。
举例：
