运输层

运输层概述

• 实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。
• 如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。

• 运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等），它使应用进程看见的就好像是两个运输层实体之间有一条端到端的逻辑通信信道。

• 根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP。

  运输层端口号、复用与分用的概念

• 运行在计算机上的进程使用进程标识符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按照规定的手续登记，以防止重复，例如：Microsoft RDP微软远程桌面使用的端口是3389.
    • 短暂端口号：49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
  • 端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的。

UDP和TCP的对比

用户数据报协议UDP

这是某个局域网上的、使用UDP协议进行通信的四台主机。其中任何一台主机都可向其他三台主机发送广播；也可以向某个多播组发送多播；还可向某台主机发送单播，也就是UDP支持单播，多播还有广播。支持一对一，一对多，一对全的通信。

发送方的应用进程将应用层报文交付给运输层的UDP。UDP直接给应用层报文添加一个UDP首部，使之成为UDP用户数据报。然后进行发送。接收方的UDP收到该UDP用户数据报后，去掉UDP首部，将应用层报文交付给应用进程。也就是说UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界。

传输控制协议TCP

使用TCP协议的通信双方，在进行数据传输之前必须使用“三报文握手”来建立TCP连接。TCP连接建立成功后，通信双方之间就好像有一条可靠的通信信道，通信双方使用这条基于TCP连接的可靠信道进行通信。TCP仅支持单播。

发送方的TCP把应用进程交付下来的数据块仅仅看作是一连串的、无结构的字节流。TCP并不知道这些待传送的字节流的含义，仅将他们编号并存储在自己的发送缓存中。TCP根据发送策略，从发送缓存中提取一定数量的字节，构建TCP报文段并发送。接收方的TCP，一方面从所接收到的TCP报文段中，取出数据载荷部分并存储在接收缓存中；一方面将接收缓存中的一些字节交付给应用进程。TCP不保证接收方应用进程所收到的数据块与发送方应用进程所发出的数据块具有对应大小的关系。

UDP和TCP对比

TCP的流量控制

• 所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
• 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。

• 如果零窗口探测报文段丢失了，会出现怎样的问题？还能否打破死锁的局面？

肯定的，因为零窗口探测报文段也有重传计时器。当重传计时器超时后，零窗口探测报文段会被重传。

TCP拥塞控制

• 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况就叫做拥塞。
  • 在计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。
• 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增长而下降。

拥塞控制算法

假定如下条件：

1. 数据是单方向传送，而另一个方向只传送确认。
2. 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。
3. 以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位。

慢开始

传输伦次：发送方给接收方发送数据报文段后，接收方给发送方发回相应的确认报文段。一个传输伦次所经历的时间其实就是往返时间。

达到慢开始门限值，之后将改用拥塞避免算法。也就是每个传输伦次结束后，拥塞窗口值只能线性加1。

拥塞避免

快重传

• 采用快重传算法可以让发送方尽早知道发生了个别报文的丢失。
• 所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
  • 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认；
  • 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
  • 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
  • 对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞（进而降低拥塞窗口cwnd为1）.使用快重传可以使整个网络的吞吐量提高约20%。

快恢复

• 发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而是执行快恢复算法；
  • 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半；开始执行拥塞避免算法。
  • 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh+3。
    • 既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络；
    • 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中；
    • 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。

TCP超时重传的选择

• 不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO。
• 利用每次测量得到的RTT样本，计算加权平均往返时间RTTs（又称为平滑的往返时间）。

• 用这种方法得出的加权平均往返时间RTTs就比测量出的RTT值更加平滑。
• 显然，超时重传时间RTO应略大于加权平均往返时间RTTs

TCP可靠传输的实现

rwnd：窗口字段的值，也就是接收方表明自己的接收窗口的尺寸为多少字节。
ack：确认字段的值，这表明接收方希望收到下一个数据的序号是多少。

• 虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。
  • 网络传递窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
  • 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。
• 对于不按序到达的数据应如何处理，TCP并无明确规定。
  • 如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。
  • TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
• TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把信息顺便捎带上。
  • 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。
  • 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

• TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。

  TCP的运输连接管理

  TCP的连接建立

• TCP是面向连接的协议，它基于运输连接来传送TCP报文段。

• TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。
• TCP运输连接有以下三个阶段：
  • 建立TCP连接
  • 数据传送
  • 释放TCP连接
• TCP的运输连接管理就是使运输连接的建立和释放都能正常地进行。

• 为什么TCP客户进程最后还要发送一个普通的TCP确认报文段？这是否多余（能否使用“两报文握手”建立连接）

并不多余，不能简化为两报文握手。
情况：TCP客户进程发出一个TCP连接请求报文段。但该报文段在某些网络结点长时间滞留了。这必然会造成该报文段的超时重传，假设重传的报文段被TCP服务器进程正常接收。TCP服务器进程给TCP客户进程发送一个TCP连接请求确认报文段，并进入连接已建立状态。由于已经改为“两报文握手”，因此TCP服务器进程发送完TCP连接请求确认报文段后，进入的是连接已建立状态，而不像“三报文握手”那样进入同步已接收状态，并等待TCP客户进程发来针对TCP连接请求确认报文段的普通确认报文段。TCP客户进程收到TCP连接请求确认报文段后，进入TCP连接已建立状态。但不会给TCP服务器进程发送针对该报文段的普通确认报文段。现在，TCP双方都处于连接已建立状态。他们可以相互传输数据。之后可以通过“四报文挥手释放连接”。TCP双方都进入了关闭状态。一段时间后，之前滞留在网络中的那个失效的TCP连接请求报文段到达了TCP服务器进程。TCP服务器进程会误认为这是TCP客户进程又发起了一个新的TCP连接请求。于是给TCP客户进程发送TCP连接请求确认报文段，并进入连接已建立状态。该报文段到达TCP客户进程，由于TCP客户进程并没有发起新的TCP连接请求，并且处于关闭状态，因此不会理会该报文段，但TCP服务器进程已进入连接已建立状态，它认为新的TCP连接已建立好了，并一直等待TCP客户进程发来数据。

综上所述：是为了防止已失效的连接请求报文段突然又传送到了TCP服务器进程，因而导致错误。

TCP的连接释放

• 为什么不直接进入关闭状态，而是要进入时间等待状态，2MSL后才进入关闭状态，这是否有必要？

情况：TCP服务器进程发送TCP连接释放报文段后进入最后确认状态。TCP客户进程收到该报文段后，发送普通的TCP确认报文段，并进入关闭状态而不是时间等待状态。然而，TCP确认报文段丢失了。这必然会造成TCP服务器进程对之前发送的TCP连接释放报文段的超时重传，并仍处于最后确认状态。重传的TCP连接释放报文段到达TCP客户进程。由于TCP客户进程属于关闭状态，因此不理睬该报文段，这必然会造成TCP服务器进程反复重传TCP连接释放报文段，并一直处于最后确认状态而无法进入关闭状态。因此，时间等待状态以及处于该状态2MSL时长，可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态。另外TCP客户进程在发送完最后一个TCP确认报文段后，再经过2MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的TCP连接中，不会出现旧连接中的报文段。


简明理解三次握手和四次挥手

TCP报文段的首部格式

源端口：占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程。
目的端口：占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程。
序号：占32比特，取值范围[0,232-1]，序号增加到最后一个后，下一个序号九又回到0。指出本TCP报文段数据载荷的第一个字节的序号。

确认号：占32比特，取值范围[0,232-1]，确认号增加到最后一个后，下一个确认号就又回到0。
指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。
若确认号=n，则表明到序号n-1为止的所有数据都已正常接收，期望接收序号为n的数据。
确认标志位ACK：取值为1时确认号字段才有效；取值为0时确认号字段无效。
TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1。

数据偏移：占4比特，并以4字节为单位。
用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。
这个字段实际上是指出了TCP报文段的首部长度。
首部固定长度为20字节，因此数据偏移字段的最小值为(0101)2
首部最大长度为60字节，因此数据偏移字段的最大值为(1111)2

保留：占6比特，保留为今后使用，但目前应置为0。
窗口：占16比特，以字节为单位。指出发送本报文段的一方的接收窗口。
窗口值作为接收方让发送方设置其发送窗口的依据。
这是以接收方的接收能力来控制发送方的发送能力，称为流量控制。
校验和：占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。
在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。
同步标志位SYN：在TCP连接建立时用来同步序号。

终止标志位FIN：用来释放TCP连接。

复位标志位RST：用来复位TCP连接。 当RST=1时,表明TCP连接出现了异常，必须释放连接，然后再重新建立连 接。
RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接。
推送标志位PSH：接收方的TCP收到该标志位为1的报文段会尽快上交应用进程， 而不必等到接收缓存都填满后再向上交付。
紧急标志位URG：取值为1时紧急指针字段有效;取值为0时紧急指针字段无效。
紧急指针：占16比特，以字节为单位，用来指明紧急数据的长度。
当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面。并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。

填充：由于选项的长度可变，因此使用填充来确保报文段首部能被4整除 (因为数据偏移字段，也就是首部长度字段，是以4字节为单位的)。