计算机网络 自顶向下方法笔记3

第三章 运输层

该层为运行在不同主机上的应用进程提供直接的通信服务。

• 运输层与网络层的关系：运输层的第一关键功能是将网络层的两个端系统之间的交付服务扩展到运行在两个不同端系统上的应用层进程之间的交付服务。UDP
• 可靠传输技术及如何体现在TCP中
• 第二个问题是拥塞控制问题及TCP应对拥塞控制的方法

3.1概述及运输层服务

运输层为进程之间提供了逻辑通信（无须考虑物理基础设施的细节，是透明的，底层提供）。

运输层协议在端系统中实现，将应用层传过来的报文进行处理变成运输层报文段。

因特网有两种运输层协议：TCP、UDP

3.1.1运输层和网络层之间的关系

• 网络层提供主机间的通信服务，运输层提供进程之间的通信服务
• 位于网络层之上，只工作在端系统中，网络层不会处理运输层报文段
• 不同运输层协议提供不同服务
• 依赖于网络层的服务
• 可能对网络层的服务进行增强，如保密性、可靠性

3.1.2因特网运输层概述

UDP(用户数据报协议)：不可靠、无连接  TCP（传输控制协议）：可靠、面向连接

TCP\UDP的分组统称为报文段，网络层报文称为数据报

网络层前提知识：因特网网络协议有一个叫IP协议(网际协议)，服务模型是尽力而为交付服务，不可靠服务。每个主机至少有一个网络层地址叫做IP地址

UDP、TCP的基本责任是主机间交付扩展到进程间的交付（运输层的多路复用及多路分解），加上差错检查就是运输层最低限度的服务（也就是UDP仅有的两种服务）

TCP的附加服务：可靠数据传输（正确的、按序的）、拥塞控制（可调节流量，而UDP不能调节）

3.2多路复用和多路分解 

• 运输层中，报文段交付给套接字，而非直接交付给进程
• 套接字具有唯一标识符
• 多路分解：
• 多路复用
• 多路复用要求：①套接字有唯一标识符②报文段有特殊字段来指示套接字
• 这个特殊字段就是源/目的端口号字段 16bit 0~1023周知端口号
• UDP的多路分解过程，TCP更复杂

3.2.1无连接的多路复用和多路分解

运输层报文段中包含源端口号和目的端口号

UDP套接字由二元组标识（目的IP地址和目的端口号）

源端口号作为返回地址的一部分，用于回发报文

3.2.2面向连接的多路复用与多路分解

TCP套接字是由四元组标识（源IP、源端口号、目的IP地址、目的端口号）

两个具有不同源IP地址或源端口号（不同进程）的TCP报文段会被定向到两个不同的套接字（但目的端口号相同）（相反，UDP会定向到相同的目的套接字）。除非TCP报文段携带的是初始创建连接的请求（欢迎套接字12000）   因为TCP面向连接，一对一进程

服务器主机可以支持很多并行的TCP套接字

端口扫描器能够确定哪个应用程序在监听哪些端口，nmap

两个不同主机可以使用相同端口号，因为IP地址不同，所以无所谓

3.2.3web服务器和TCP

Web服务器中，连接套接字与进程之间并非总是一一对应。

如今高性能Web服务器通常只用一个进程，而为每个连接创建一个具有新连接套接字的新线程

3.3无连接运输UDP

UDP只做了运输层能做到最少工作，除了复用分解和少量差错检测外，几乎没有对IP增加别的东西。

UDP从应用程序得到报文，附加上源目的端口号字段和两个其他小字段，就将形成的报文段交给了网络层。

交付报文段之前，运输层实体之间没有握手，所以无连接

选择UDP而非TCP的原因：无需拥塞控制、可靠传输

TCP拥塞控制有时有助于整体网络的状态，但有时不利于应用程序的使用

使用UDP的应用实现可靠性传输可以通过在应用程序（应用层协议）中建立可靠性机制来实现

3.3.1UDP报文段结构（首部8Byte）

3.3.2UDP检验和

发送方对UDP报文段中所有16bit字的和进行反码运算存入检验和字段中。

接收方：原始字+检验和=全1，则无差错，只能检验1bit差错 

UDP提供检验和的原因 
无法恢复差错，只能提供差错检测。

3.4可靠数据传输原理

可靠数据传输不仅在运输层出现，还会在链路层以及应用层实现

可靠数据传输为上层提供的服务抽象成用一条可靠信道进行传输。实现这种服务的抽象是可靠数据传输协议。两个可靠通信端点的下层可能是一条物理链路（链路层）或全球互联网络（运输级）。所以，可将较低层直接视为不可靠的点对点信道。

也就是可靠数据传输协议的本层视作可靠信道，低层视作不可靠的点对点信道

设计可靠数据传输协议的发送方一侧和接收方一侧

仅考虑单向数据传输，但实际也需要在两个方向传输分组

3.4.1构造可靠数据传输协议 

发送方重传是万金油

• 比特差错信道：rdt2.0（停等协议）肯定和否定分组、检验和
• rdt2.1序号
• rdt2.2无NAK ACK报文具备分组序号
• 具有比特差错的丢包信道：rdt3.0倒计数定时器

停止-等待协议属于自动请求重传（Automatic Repeat reQuest，ARQ）协议。即重传的请求是发送方自动进行的，而不是接收方请求发送方重传某个误码的数据分组。 

3.4.2流水线可靠数据传输协议 

停等协议的发送方（信道）利用率很低。

发送方利用率=发送方推入比特时间/发送总时间

故应该不以停等方式运行，允许发送方发送多个分组而无需等待确认

 差错恢复的基本方法有两种：回退N步、选择重传

3.4.3回退N步GBN

采用累计确认，能避免ACK丢失导致重传已到达的数据 

 基于事件的编程

3.4.3选择重传SR

许多分组根本不需要重传，所以发送方仅重传那些它怀疑在接收方出错的分组而避免不必要的重传。

窗口长度必须小于等于序号空间大小的一半

分组重新排序的解决思路：估计分组的最大存活时间

接收方和发送方信息不对称，仿佛中间有帘子

以上的ACK序号为接收方成功接收y及y之前的所有分组，而TCP的确认号为期望收到的字节序号

3.5面向连接的运输TCP

依赖于前一节的许多基本原理

3.5.1TCP连接

该连接是一条逻辑连接，其共同状态（状态变量）仅保留在两个通信端系统的TCP程序中

TCP协议只在端系统中运行，而不在中间的网络元素（路由器和链路层交换机）中运行，所以中间的网络元素不会维持TCP连接状态

全双工服务、点对点（一对一，与之对立的是多播：一对多）

三次握手：创建连接，两个主机间发送了3个报文段

发送报文段的具体过程：发送缓存、接收缓存

最长报文段长度MSS（报文段里应用层数据的最大长度），根据MTU来设置（最大传输单元，最大链路层帧长度）

客户数据配上一个TCP首部就形成了多个TCP报文段

TCP连接的组成：主机中的缓存、套接字、变量

3.5.2TCP报文段结构 

发送大文件时TCP会划分数据块（长度为MSS）

首部字段：

1.序号和确认号：序号是报文段首字节的字节流编号（数据字段），确认号是主机A期望收到的下一字节的序号。TCP只确认该流中至第一个丢失字节为止的字节，编号在y之前的所有字节都已被收到，这个ACK确认了多个TCP报文段，也就是累计确认。
收到失序报文段：丢弃或保存，并等待缺失的字节。
初始序号设为随机选取。有利于防止之前发送的报文段被误以为是当前传输的报文段。

2.telnet：序号和确认号的学习案例

序号是报文段数据字段首字节的序号，确认号是等待收到该序号。

捎带确认：对客户到服务器数据的确认被装载在承载服务器到客户的数据的报文段中

3.5.3 往返时间的估计和超时

sampleRTT在某一时刻做一次测量，仅为传输一次的报文段测量

1.估计往返时间：SampleRTT均值、SampleRTT偏差

2.设置和管理重传超时间隔：ERTT+4*DevRTT，出现超时则加倍，以免即将被确认的后继报文段过早超时重传。然而，只要收到报文段并更新ERTT，就用公式重新计算timeout interval

实践原则：与3.4节所学的方法很像，TCP使用肯定确认（不使用否定确认NAK）和定时器，发送方重传有疑问的报文段（隐式NAK机制：收到三个冗余ACK，那么直接重传而无需等待超时）。TCP发送方也使用流水线，可以增加会话的吞吐量，发送方具有的发送窗口大小（未被确认报文段的具体数量）由拥塞控制和流量控制机制决定。

3.5.4可靠数据传输

利用3.4节学习的可靠数据传输技术，TCP在IP不可靠的尽力而为服务之上创建了可靠数据传输服务。确保了进程从接收缓存中读出的数据流是可靠的。

在这里仅使用单一的重传定时器，发送方只用超时来恢复报文段的丢失，并且发送方使用流水线（窗口内有数据就发出去）

TCP发送方有三个与发送重传有关的主要事件。见教材。

1. 一些有趣的情况：确认丢失而重传、第一个ACK报文丢失超时并只重传报文1，只要报文ACK2在新计时器的时间内到达则不重传报文2、累积确认避免了报文1的重传
2. 超时间隔加倍：每次重传，下一次的超时间隔设为先前值的两倍。指数型增长。在另两个事件会重新用公式计算。提供了形式受限的拥塞控制
3. 快速重传：超时周期太长会增加端到端时延。通过失序报文段到达，接收方产生冗余ACK，（一个初始ACK和其后的三个冗余ACK）说明确认三次的报文段之后的报文段已丢失，执行快速重传
4. GBN风格。类似接收窗口大小=1，但能缓存失序报文段
   重传也只传最小序号的报文段（至多1个，而GBN把窗口内所有报文段重传）
   选择确认允许接收方有选择地确认失序报文段，而不是累积的确认最后一个正确接收的有序报文段。当选择确认和选择重传结合时，看起来就很像SR协议。所以是SR协议和GBN的混合体

3.5.5流量控制

问题：应用程序读取数据缓慢，而发送方发送太快太多，发送的数据在该连接的接收缓存中溢出。

TCP提供流量控制服务。控制发送方发送速率（拥塞控制：TCP发送方因为IP网络的拥塞而被限制）

发送方维护一个变量叫接收窗口rwnd=RcvBuffer-[lastByteRcvd-LastByteRead].也就是接收缓存的可用空间。当发送方未被确认的发送数据量在rwnd以内，则不会使接收缓存溢出

当接收缓存已满rwnd=0，发送方需要发送一个一字节数据的报文。等到接收方清空缓存时，接收方发送一个确认报文（包含新rwnd），防止发送方被阻塞

UDP不提供流量控制，接收缓存会溢出。

3.5.6TCP连接管理 

建立连接

释放连接

TCP状态

若目的端口不接受连接，则目的主机向源发送一个特殊重置报文段（RST标志位=1），当UDP分组的目的端口和UDP套接字不匹配，则目的主机发送一个特殊的ICMP数据报

3.6拥塞控制原理 

前面都在分析面临分组丢失时的可靠服务原理和TCP机制，分组丢失一般是由网络阻塞（路由器缓存溢出）引起的。分组重传作为网络拥塞的征兆 ，而这里将集中于网络拥塞的原因，是太多源想以高速率发送数据。

3.6.1拥塞原因和代价

随着主机增加其发送速率并使网络变得更加拥塞，会发生什么情况。

1. 无穷大缓存的路由器：接收方每秒接受的字节数（每连接吞吐量）处于理想状况，但总时延趋于无穷，不理想。所以代价①：即使在理想状况下，到达速率接近链路容量时，排队时延还是很高。
2. 有限缓存的路由器：供给载荷（初始数据+重传数据）代价②发送方必须重传丢失的重传数据代价③发送方会进行不必要的重传。
3. 多跳路径（路径上含有多个路由器）：代价④当分组在路径上被丢弃，上游的路由器就做了无用功。

 3.6.2拥塞控制方法

• 端到端拥塞控制：网络层没有为运输层拥塞控制提供显式支持。TCP采用
• 网络辅助的拥塞控制：路由器向发送方提供关于网络中拥塞状态的显式反馈信息
  拥塞信息从网络反馈到发送方有两种方式：直接网络反馈、经由接收方的网络反馈

3.7TCP拥塞控制 

TCP使用端到端拥塞控制，因为IP不提供显式的网络拥塞反馈。

TCP采用让每个发送方感知到的网络拥塞程度来阻遏其他连接发送流量的速率。

1. 如何阻遏发送流量的速率：TCP拥塞控制机制跟踪变量拥塞窗口cwnd，限制发送方未被确认的数据量
2. 如何感知拥塞：如果发生TCP丢包事件（超时、3个冗余ACK），则认为路径出现拥塞。如果确认到达，则一切正常。TCP是自计时的，利用确认来触发增大拥塞窗口
3. 感知到阻塞采用什么算法来改变发送速率（既不会发生拥塞、又能充分利用网络带宽）： 指导性原则（TCP指示隐含指示控制速率） 

• 慢启动（指数增长，时间很短）、拥塞避免、快速恢复（1/2窗口）：状态机图
• “锯齿行为”：探测是否还有另外的可用带宽，因为网络带宽不断变化，需要不断试探出最大发送速率（拥塞窗口）
• TCP吞吐量，高带宽路径的TCP

TCP分岔：

3.7.1公平性 

理想化情况TCP趋于平等分享瓶颈链路带宽。

1. UDP的传输速率不像TCP那样被遏制。UDP不与其他连接合作，所以不公平，还会压制TCP流量
2. 并行TCP连接会不公平地分到更多带宽

3.7.2明确拥塞通告：网络辅助拥塞控制 

在网络层的IP数据报首部有两个比特用于ECN信号，TCP发送方可作出反应

DCCP数据包拥塞控制协议提供类似UDP不可靠服务，利用了网络层的ECN

3.8总结

网络边缘已讨论完毕，包含了端系统的所有事情。接下来探寻网络核心。