传输层
传输层
只有主机才有的层次传输层的功能，为应用层提供通信服务使用网络层的服务
功能
- 传输层提供进程和进程之间的逻辑通信。
- 复用和分用
- 传输层对收到的报文进行差错检测。
传输层基本概念
-
端口号: TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。
-
端口号使用16比特表示，取值范围0~65535;
-
熟知端口号: 0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议，例如:FTP使用21/20，HTTP使用80，DNS使用53。
-
登记端口号: 1024~49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复。例如:Microsoft RDP微软远程桌面使用的端口是3389。
-
短暂端口号: 49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的。
-
-
-
复用和分用: 发送方的复用和接收方的分用。
理解复用和分用：
一般来说，应用层会有比较多的进程同时在运行，同时和外部网络有数据的交互，就好比一条道路有多个车道有车辆在行驶，可是在底层，数据传输是串行的，也就是单车道，多车道的车要经过单车道，采取的方法是在单车道入口设立卡子，每个车道的车在卡子前排队，依次通过卡子进入单车道。排队的过程就是复用，反之就是分用或者叫解复用。
-
UDP复用： 发送方的某些应用进程所发送的不同应用报文,在运输层使用UDP协议进行封装，这称为UDP复用。
-
TCP复用： 在传输层使用TCP协谀进行封装，这称为TCP复用。
-
IP复用： 传输层用端口号来区分不同的应用进程。不管是使用传输层的UDP协议封装成的UDP用户数据报，还是用TCP协议封装成的TCP报文段，在网络层都需要使用IP协议封装成IP数据报，这称为IP复用。
-
TCP/IP体系的应用层常用协议所使用的运输层熟知端口号
协议:
-
TCP协议：面向连接的传输控制协议
传送数据之前必须建立连接，数据传送结束后要释放连接。不提供广播或多播服务。由于TCP要提供可靠的面向连接的传输服务，因此不可避免增加了许多开销:确认、流量控制、计时器及连接管理等。可靠，面向连接，时延大，适用于大文件。
-
UDP协议：无连接的用户数据报协议
传送数据之前不需要建立连接,收到UDP报文后也不需要给出任何确认。不可靠，无连接，时延小，适用于小文件。
TCP、UDP协议对比：
| UDP | TCP |
|---|---|
| 无连接 | 面向连接 |
| 支持一对一，一对多，多对一和多对多交互通信。 | 每一条TCP连接只能有两个端点EP，只能是一对一通信。 |
| 对应用层交付的报文直接打包 | 面向字节流 |
| 尽最大努力交付，也就是不可靠;不使用流量控制和拥塞控制。 | 可靠传输，使用流量控制和拥塞控制。 |
| 首部开销小，仅8字节 | 首部最小20字节，最大60字节 |
TCP报文段的首部格式
- 源端口: 占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程。
- 目的端口: 占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程。
- 序号seq: 占32比特，取值范围[0，232 -1]，序号增加到最后一个后，下一个序号就又回到0。
- 确认号ack: 占32比特，取值范围[0，232 -1]，确认号增加到最后一个后，下一个确认号就又回到0。
指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据。 - 数据偏移: 占4比特，并以4字节为单位。用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。
- 保留: 占6比特，保留为今后使用，但目前应置为0。
- 确认标志位ACK:取值为1时确认号字段才有效;取值为0时确认号字段无效。TCP规定,在连接建立后所有传送的TCP报文段都必须把ACK置1。
- 同步标志位SYN: 在TCP连接建立时用来同步序号,为1时，表示这是个连接建立的报文。
- 终止标志位FIN: 用来释放TCP连接，为1时，表示这是个释放连接的报文。
- 复位标志位RST: 用来复位TCP连接。当RST=1时,表明TCP连接出现了异常,必须释放连接，然后再重新建立连接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接。
- 紧急标志位URG: 取值为1时紧急指针字段有效;取值为0时紧急指针字段无效。
- 紧急指针: 占16比特，以字节为单位，用来指明紧急数据的长度。 当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。
- 推送标志位PSH: 接收方的TCP收到该标志位为1的报文段会尽快上交应用进程，而不必等到接收缓存都填满后再向上交付。
- 窗口: 占16比特，以字节为单位。指出发送本报文段的一方的接收窗口。窗口值作为接收方让发送方设置其发送窗口的依据。这是以接收方的接收能力来控制发送方的发送能力,称为流量控制。
- 校验和: 占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。
- 选项： 扩展首部的功能。
- 最大报文段长度MSS选项: TCP报文段数据载荷部分的最大长度。
- 窗口扩大选项: 为了扩大窗口(提高吞吐率)。
- 时间戳选项:
- 用来计算往返时间RTT
- 用于处理序号超范围的情况，又称为防止序号绕回PAWS。
- 选择确认选项： 用来实现选择确认功能。
- 填充: 由于选项的长度可变，因此使用填充来确保报文段首部能被4整除(因为数据偏移字段，也就是首部长度字段，是以4字节为单位的)。
TCP的运输连接管理
TCP的连接建立
TCP的连接建立要解决以下三个问题:
- 使TCP双方能够确知对方的存在;
- 使TCP双方能够协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)
- 使TCP双方能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配
过程图示
通过如下问题理解TCP连接建立过程：
- SYN=1 表示这为一个报文(请求)
TCP的连接释放
过程图示
- FIN=1时，表示这是个释放连接的报文。
场景描述：
- 一个TCP连接建立后，客户端发起了一个下载文件的请求，如上图数据传输(绿色文字)过程。
- 紧接着客户端面没有发送数据的需求了，它就可以立即发起一个连接关闭请求，收到服务器确认后此时TCP连接为半关闭状态。
- 但是此时需要下载的文件还没有传输完成，所以中间还有一个数据传输(紫色文字)过程。（这不是断开连接的过程，而是属于正常数据传输过程）
- 服务器数据传输完成后，发起断开连接报文，接收到客户端响应后，服务器TCP连接断开。
- 客户端在等待2MSL后，TCP连接断开。
问题：为什么客户端要等待2MSL
如上：如果客户端直接关闭，但是服务器没有收到断开连接的确认报文，此时服务器就会一起超时重发，导致一直无法断开连接。
保活计时器
- TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器（2小时定时)。
- 若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒评友送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障,接着就关闭这个连接。
TCP流量控制
一般来说，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。所谓流量控制（flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文。
过程演示
-
前4步中主机A，
- 发送1~100号字节数据，还能发送300字节
- 发送101~200号字节数据，还能发送200字节
- 发送201~300号字节数据，但丢失了! 还能发送100字节
- 接收到了主机B的确认报文 ACK=1 ack=201 rwnd=300
-
接收到确认报文后主机A：
- 通过确认报文段中的rwnd=300修改自己的窗口大小为300
- 还能发送201~500号共300字节数据
- 发送301~400号字节数据，还能发送100字节
- 发送401~500号字节数据，不能再发送新数据了
- 超时重传旧的数据，但不能发送新的数据
- 接收到了主机B的确认报文 ACK=1 ack=501 rwnd=100
- 接收到再交确认报文后主机A：
- 通过确认报文段中的rwnd=100修改自己的窗口大小为100
- 还能发送501~600号共100字节数据
- 发送501~600号字节数据，不能再发送新数据了
- 接收到了主机B的确认报文 ACK=1 ack=601 rwnd=0
- 接收到再交确认报文后主机A：
- 通过确认报文段中的rwnd=0修改自己的窗口大小为0
- 不能再发送了，发送窗口被调控为0了
- 主机B 接收缓存又有了一些存储空间，将接收窗口调整为300,并通告主机A，等待A发来数据，但该通告丢失了!
- 主机A一直等待主机B发送的非零窗口的通知，主机B也一直等待主机A发送的数据，如果不采取措施，这种互相等待而形成的死锁局面将一直持续下去!
- 窗口大小0时就会启动持续计时器，如果超时就会发送探测报文段。如此即使主机B的报文丢失了也不会造成死锁。
TCP拥塞控制
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况就叫做拥塞(congestion)。
在计算机网络中的链路容量（即带宽)、交换结点中的缓存和处理机等，都是网络的资源。若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。
拥塞控制算法
- 慢开始(slow-start)
- 拥塞避免(congestion avoidance)
- 快重传(fast retransmit)
- 快恢复(fast recovery)
假定条件
下面介绍这四种拥塞控制算法的基本原理，假定条件如下:
- 数据是单方向传送，而另一个方向只传送确认。
- 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。
- 以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位。
- 发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。
- **拥塞窗口cwnd的维护原则: ** 只要网络没有出现拥塞，拥塞窗口就再增大一些;但只要网络出现拥塞，拥塞窗口就减少一些。
- 判断出现网络拥塞的依据: 没有按时收到应当到达的确认报文（即发生超时重传)。
- 发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd。
- 维护一个慢开始门限ssthresh状态变量:
- 当cwnd < ssthresh时，使用慢开始算法;
- 当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法;
- 当cwnd = ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。
慢开始(slow-start)和拥塞避免(congestion avoidance)
初始时：设置慢开始门限 ssthresh=16 ，拥塞窗口 cwnd=1
数据发送过程：
- 发送方发送一个0号数据报文段，接收到确认报文后 cwnd=1+1=2
- 再发送1-2号数据报文段，接收到确认报文后 cwnd=2+2=4
- 再发送3-6号数据报文段，接收到确认报文后 cwnd=4+4=8
- 再发送7-14号数据报文段，接收到确认报文后 cwnd=8+8=16
- 此时慢开始门限ssthresh=拥塞窗口cwnd，需要改用拥塞控制算法。
- 再发送15-30号数据报文段，接收到确认报文后 cwnd=16+1=17
- 再发送31-47号数据报文段，接收到确认报文后 cwnd=17+1=18
- 一些轮次后，cwnd已经增长到24，此时发送31-47号数据报文段，此时一些数据报丢失，没有接收到确认报文。
- 发送方触发超时重传机制，此时发送方会判断网络出现了拥塞，进行以下工作：
- 将ssthresh值更新为发生拥塞时 **cwnd=24 **值的一半; ssthresh = 24/2 = 12
- 将cwnd值减少为1,并重新开始执行慢开始算法。
整个过程如下图：
-
- “慢开始”是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢;
- “拥塞避免”并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞;
快重传(fast retransmit)和快恢复(fast recovery)
慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法(TCP Tahoe版本)。1990年又增加了两个新的拥塞控制算法(改进TCP的性能)，这就是快重传和快恢复(TCP Reno版本)。
- 有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。
- 这将导致发送方超时重传，并误认为网络发生了拥塞;
- 发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率。
- 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。
- 所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
- 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认;
- 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
- 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
- 对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞（进而降低拥塞窗口cwnd为1)。使用快重传可以使整个网络的吞吐量提高约20%。
快重传 数据发送过程：
- 发送方发送窗口内的1号报文段M1
- 发送方发送窗口内的2号报文段M2
- 发送方接收到1号报文段确认报文确认M1
- 发送方发送窗口内的3号报文段M3，但是3号报文丢失。
- 发送方接收到2号报文段确认报文确认M2
- 发送方发送窗口内的4号报文段M4
- 发送方接收到2号报文段重复确认报文重复确认M2
- 发送方发送窗口内的5号报文段M5
- 发送方接收到2号报文段重复确认报文重复确认M2
- 发送方发送窗口内的6号报文段M6
- 发送方接收到2号报文段重复确认报文重复确认M2，下一步立即重传M3
- 发送方重传M3报文段M3
- 接收方接收到重传的M3后，返回确认报文M6
过程图示：
快恢复算法
- 发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法;
- 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半;开始执行拥塞避免算法。
- 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh + 3。
- 既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络;
- 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中
- 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。
小结
TCP超时重传时间的选择
两种超时时间的设置
1、超时重传时间RTO<RTT
2、超时重传时间RTO>RTT
超时重传时间RTO应略大于往返时间RTT
计算加权平均往返时间RTTs
RFC6298建议超时重传时间RTO:
往返时间RTT的测量比较复杂
解决RTT测量的方法
- 针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法:在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。也就是出现重传时，不重新计算RTTs，进而超时重传时间RTO也不会重新计算。
- 这又引起了新的问题。设想出现这样的情况:报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。
- 因此，要对Karn算法进行修正。方法是:报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍。即出现超时重传时，就不使用上述公式计算RTO，而是直接把RTO扩大一倍。
TCP可靠传输的实现
- TCP基于以字节为单位的滑动窗口来实现可靠传输。
- 发送方在未收到接收方的确认时，可将发送窗口内还未发送的数据全部发送出去;
- 接收方只接收序号落入发送窗口内的数据;
- 虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。
- 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
- 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。
- 对于不按序到达的数据应如何处理，TCP并无明确规定。
- 如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。
- TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
- TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
- 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。
- TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]。
- 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。
- TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。
