本文为阅读总结个人认为书里概念性的、对本人有帮助的内容，仅供参考。
运输层位于应用层和网络层之间，是分层的网络体系结构的重要组成部分。该层为运行在不同主机上的应用程序提供直接的通信服务起着至关重要的作用。
运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信功能。
应用进程使用运输层提供的逻辑通信功能彼此发送报文，而无需考虑承载这些报文的物理基础设施的细节。
运输层协议是在端系统中而不是在路由器中实现的。
网络路由器仅作用于该数据报的网络层字段；即它们不检查封装在该数据报的运输层报文段的字段。
网络应用程序可以使用多种的运输层协议。每种协议都能为调用的应用程序提供一组不同的运输层服务。
网络层提供了主机之间的逻辑通信，而运输层为运行在不同主机上的进程之间提供了逻辑通信。
运输协议能够提供的服务常常受制于底层网络层协议的服务模型。
因特网网络层协议有一个名字叫IP，即国际协议。IP为主机之间提供了逻辑通信。IP的服务模型是尽力而为交付服务，这意味着IP尽它“最大的努力”在通信的主机之间交付报文段，但它并不做任何确保。
UDP和TCP最基本的责任是，将两个端系统间IP的交付服务扩展为运行在端系统上的两个进程之间的交付服务。
将主机间交付扩展到进程间交付被称为运输层的多路复用与多路分解。
进程到进程的数据交付和差错检查是两种最低限度的运输层服务，即UDP所能提供的仅有的两种服务。
TCP为应用程序提供了集中附加服务：1、可靠数据传输（通过使用流量控制、序号、确认和定时器，TCP确保正确地、按序地将数据从发送进程交付给接收进程）；2、拥塞控制。
多路复用与多路分解服务是所有计算机网络都需要的。
将运输层报文段中的数据交付到正确的套接字的工作称为多路分解。
在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段，然后将报文段传递到网络层，所有这些工作称为多路复用。
运输层多路复用要求：1、套接字有唯一标识符；2、每个报文段有特殊字段来指示该报文段所要交付到的套接字。这些特殊字段是源端口号字段和目的端口好字段。
端口号是一个16比特的数，其大小在0-65535之间。0-1023范围的端口号称为周知端口号，是受限制的，这是至它们保留给诸如HTTP（80）和FTP（21）之类的周知应用层协议来使用的。
一个UDP套接字是由一个二元组来全面标识的，该二元组包含一个目的IP地址和一个目的端口号。
如果两个UDP报文段有不同的源IP地址和/或源端口号，但具有相同的目的IP地址和目的端口号，那么这两个报文段将通过相同的目的套接字被定向到相同的目的进程。
TCP套接字是由一个四元组（源IP地址、源端口号、目的IP地址、目的端口号）来标识的。
与UDP不同的是，两个具有不同源IP地址或源端口号的到达TCP报文段将被定向到两个不同的套接字，除非TCP报文段携带了初始创建连接的请求。
连接套接字与进程之间并非总是有着一一对应的关系。事实上，当今的高性能Web服务器通常只使用一个进程，但是为每个新的客户连接创建一个具有新连接套接字的新线程。（线程可被看作是一个轻量级的子进程）
由[RFC 768]定义的UDP只是做了运输协议能够做的最少工作。除了复用/分解功能及少量的差错检测外，它几乎没有对IP增加别的东西。
UDP从应用进程得到数据，附加上用于多路复用/分解服务的源和目的端口号字段，以及两个其他的小字段，然后将形成的报文段交给网络层，网络从将该运输层报文段封装到一个IP数据报中，然后尽力而为地尝试将此报文段交付给接收主机。
DNS是一个通常使用UDP的应用层协议的例子。
TCP提供了可靠数据传输服务，而UDP不能提供，但是TCP不总是首选，因为由许多应用更适合用UDP，原因：
- 关于何时发送、发送什么数据的应用层控制更为精细。实时应用通常要求最小的发送速率，不希望过分地延迟报文段的传送且能容忍一些数据丢失。
- 无需连接建立。TCP在开始数据传输之前要经过三次握手。UDP却不需要任何准备即可进行数据传输。因此UDP不会引入建立连接的时延。
- 无连接状态。TCP需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数以及序号与确认号的参数。另一方面，UDP不维护连接状态，也不跟踪这些参数。因此某些专门用于某种特定应用的服务器当应用程序运行在UDP之上而不是运行在TCP上时，一般都能支持更多的活跃客户。
- 分组首部开销小。每个TCP报文段都有20字节的首部开销，而UDP仅有8字节的开销。
UDP被用于RIP路由选择表的更新。因为这些更新被周期性地发送，更新的丢失能被最近的更新所替代，因此丢包、过期的更新是无用的。
UDP也用于承载网络管理数据。在这种场合下，UDP要优于TCP，因为网络管理应用程序通常必须在该网络处于重压状态时运行，而正是在这个时候可靠的、拥塞受控的数据传输难以实现。
| 应用 | 应用层协议 | 下面的运输协议 |
| 电子邮件 | SMTP | TCP |
| 远程终端访问 | Telnet | TCP |
| Web | HTTP | TCP |
| 文件传输 | FTP | TCP |
| 远程文件服务器 | NFS | 通常UDP |
| 流式多媒体 | 通常专用 | UDP或TCP |
| 因特网电话 | 通常专用 | UDP或TCP |
| 网络管理 | SNMP | 通常UDP |
| 路由选择协议 | RIP | 通常UDP |
| 名字转换 | DNS | 通常UDP |
由无控制的UDP发送方引入的高丢包率将引起TCP发送方大大地减小它们的速率。
UDP中缺乏拥塞控制能够导致UDP发送方和接受方之间的高丢包率，并挤垮了TCP会话，这是一个潜在的严重问题。
使用UDP的应用是可以实现可靠数据传输的。这可通过在应用程序自身中建立可靠性机制来完成。
UDP检验和提供了差错检测功能。
发送方的UDP对报文段中的所有16比特字的和进行反码运算，求和时遇到的任何溢出都被回卷。得到的结果被放在UDP报文段中的检验和字段。在接收方，报文段中的所有16比特字的和与检验和相加，如该分组中没有引入差错，则显然在接收方处该和将会是1111111111111111，如果任一比特为0，则说明该分组中已经出现了差错。
虽然UDP提供差错检测，但它对差错恢复无能为力。UDP的某种实现只是丢弃受损的报文段；其他实现时将受损的报文段交给应用程序并给出警告。
可靠数据传输为上层实体提供的服务抽象是：数据可以通过一条可靠的信道进行传输，借助于可靠信道，传输数据比特就不会受到损坏或丢失，而且所有数据都是按照其发送顺序进行交付。实现这种服务抽象是可靠数据传输协议的责任。
发送方和接收方的有限状态机（Finite-State Machine，FSM）。发送方和接收方有各自的FSM。
在分组的传输、传播或缓存的过程中，比特差错通常会出现在网络的物理部件中。
基于重传机制（出现错误的分组重新传输）的可靠数据传输协议称为自动重传请求（Automatic Repeat reQuest，ARQ）协议。
基本上，ARQ协议中还需要另外三种协议功能来处理存在比特差错的情况：
- 差错检测。差错检测和纠错技术要求有额外的比特（除待发送的初始数据比特之外的比特）从发送方发送到接收方，这些比特将被汇集到数据分组的分组检测和字段中。
- 接收方反馈。
- 重传。接收方受到有差错的分组时，发送方将重传该分组文。
当发送方处于等待肯定确认（ACK）或否定确认（NAK）状态时，它不能从上层获得更多的数据。因此，发送方将不会发送一块新的数据。除非发送方确信接收方已正确接收当前分组。由于这种行为，这样的协议被称为停等协议。
使用停等方式运行，发送方（或信道）的利用率将会非常低。解决该问题的一个简单方法是：不使用停等方式运行，允许发送方发送多个分组而无需等待确认。该方法被称为流水线（pipeline）。
流水线技术对可靠数据传输协议可带来如下影响：
- 必须增加序号范围，因为每个输送中的分组（不计算重传）必须有一个唯一的序号，而且也许有多个在输送中未确认的报文。
- 协议的发送方和接收方两端也许必须缓存多个分组。发送方最低限度应当能缓存那些已发送但没有确认的分组。接收方或许也需要环迅那么已正确接收的分组。
- 所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏和延时过大的分组。解决流水线的差错恢复有两种基本方法是：回退N步（Go-Back-N，GBN）和选择重传（Selective Repeat，SR）。
在回退N步（GBN）协议中，允许发送方发送多个分组而不需要等待确认，但它也受限于在流水线中未确认的分组数不能超过某个数最大允许N。
GBN协议也常被称为滑动窗口协议。
基于ACK、无NAK的GBN协议的发送发和接收方这两端的FSM称为扩展FSM。
GBN发送方必须响应三种类型的事件：
- 上层的调用。
- 收到一个ACK。
- 超时事件。
在GBN协议中，接收方丢弃所有失序分组。这种方法的优点是接收缓存简单，即接收方不需要缓存任何失序分组。
选择重传（SR）协议通过让发送方仅重传那些它怀疑在接收方出错（即丢失或受损）的分组而避免了不必要的重传。这种个别的、按需的重传要求接收方逐个地确认正确接收的分组。
SR接收方将确认一个正确接收的分组而不管其是否按序。失序的分组将被缓存直到所有丢失分组（即序号更小的分组）皆被接收到为止，这时才可以将一批分组按序交付给上层。
对于哪些分组已经被正确接收，哪些没有，发送方和接收方并不总是能看到相同的结果。对SR协议而言，这就意味着发送方和接收方的窗口并不总是一致。
对于SR协议而言，窗口长度比必须小于或等于序号空间大小的一半。
| 机制 | 用途和说明 |
| 检验和 | 用于检测在一个传输分组中的比特错误 |
| 定时器 | 用于超时/重传一个分组，可能因为该分组（或其ACK）在信道中丢失了。由于当一个分组延时但未丢失 （过早超时），或当一个分组已被接收方受到但接收方到发送方的ACK丢失时，可能产生超时事件， 所以接收方可能会收到一个分组的多个冗余副本。 |
| 序号 | 用于为发送方流向接收方的数据分组按顺序编号。所接收分组的序号间的空隙可使可使接收方检测出 丢失的分组。具有相同序号的分组可使接收方检测出一个分组的多个冗余副本。 |
| 确认 | 接收方用于告诉发送方一个分组或一组分组已被正确接收到了。确认报文通常携带着被确认的分组或多 个分组的序号。确认可以是逐个的或累积的，着取决于协议。 |
| 否定确认 | 接收方用于告诉发送方某个分组未被正确地接收。否定确认报文通常携带着未被正确接收的分组的序号。 |
| 窗口、流水线 | 发送方也许被限制仅发送那些序号落在一个指定范围内的分组。通过允许一次发送多个分组但未被确认，发送方的利用 率可在停等操作模式的基础上得到增加。我们很快将会看到，窗口长度可根据接收方接收和缓存报文的能力、网络中的 拥塞程度或两者情况来进行设置。 |
通过假定一个分组在网络中的“存活”时间不会超过某个固定最大时间量来做到这一点（信道中存在某分组的冗余分组）。
TCP是因特网运输层的面向连接的可靠的运输协议。为了而提供可靠数据传输，TCP依赖于差错检测、重传、累积确认、定时器以及用于序号和确认号的首部字段。
TCP被称为是面向连接的，这是因为在一个应用进程可以开始向另一个应用进程发送数据之前，着两个进程必须先互相“握手”，即它们必须相互发送某些预备报文段，以建立确保数据传输的参数。
TCP连接状态完全完全保留在两个端系统中。由于TCP协议只在端系统中运行，而不在中间的网络元素（里尤其和链路层交换机）中运行，所以中间的网络元素不会维持TCP连接状态。
TCP连接提供的是全双工服务：如果一台主机上的进程A与另一台主机上的进程B存在一条TCP连接，那么应用层数据就可在从进程B流向进程A的同时，也从进程A流向进程B。
TCP连接也总是点对点的，即在单个发送方与单个接收方之间的连接。
TCP可以从缓存中取出并放入报文段中的数据数量受限于最大报文段长度（Maximum Segment Size，MSS）。
最大传输单元（Maximum Transmission Unit，MTU）
TCP连接的每一端都有各自的发送缓存和接收缓存。
TCP报文段首部包含：源端口号、目的端口号、16比特的检验和、32比特的序号字段、32比特的确认号字段、16比特的接收窗口字段、4比特的首部长度字段、可选与变长的选项字段、6比特的标志字段。
TCP报文段首部中两个最重要的字段是序号字段和确认字段。这两个字段是TCP可靠传输服务的关键部分。
TCP把数据看成一个无结构的、有序的字节流。
当主机在一条TCP连接中收到失序报文段时，TCP RFC并没有为此明确规定任何规则，而是把这一问题留给实现TCP的编程人员去处理。他们有两个基本的选择：1、接收方立即丢弃失序报文段；2、接收方保留失序的字节，并等待缺少的字节以填补该间隔。显然后一种选择对网络带宽而言更为有效，是实践中采用的方法。
Telnet由RFC 854定义，它现在是一个用于远程登陆的流行应用层协议。它运行在TCP之上，被设计成可在任意一对主机之间工作。
超时间隔长度必须大于该连接的往返时间（RTT），即从一个报文段发出到它被确认的时间。
因特网的网络层服务（IP）是不可靠的。IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性。
TCP在IP不可靠的尽力而为服务之上创建了一种可靠数据传输服务。TCP的可靠数据传输服务确保一个进程从其接收缓存中读出的数据流是无损坏、无间隔、非冗余和按序的数据流。
TCP为它的应用程序提供了流量控制服务以消除发送方使接收方缓存溢出的可能性。流量控制因此使一个速度匹配服务，即发送方的发送速率与接收方应用程序的读取速率相匹配。
UDP并不提供流量控制。
nmap是一个功能强大的工具，该工具不仅能“侦察”打开的的TCP端口，也能“侦察”打开的UDP端口，还能“侦察”防火墙及其配置。甚至能“侦察”应用程序的版本和操作系统。
异步传递方式（ATM）；可用比特率（ABR）。
网络拥塞的代价：1、当分组的到达速率接近链路容量时，分组经历巨大的排队时延。2、发送方必须执行重传以补偿因为缓存溢出而丢弃（丢失）的分组。3、发送方遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本。4、当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了。
我们可根据网络层是否为运输层拥塞控制提供了显式帮助来区分拥塞控制方法：1、端到端拥塞控制；（网络层没有为运输层拥塞控制提供显式支持）2、网络辅助的拥塞控制。（网络层构件，即路由器，向发送发提供关于网络中拥塞状态的显式反馈信息）
对于网络辅助的拥塞控制，拥塞信息从网络反馈到发送方通常由两种方式：1、直接反馈信息可以由网络路由器发给发送方，这种方式的通知通常采用了一种阻塞分组的形式；2、路由器标记或更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生，一旦收到一个标记的分组后，接收方就会向发送方通知该网络拥塞指示。第2种形式的通知至少要经过一个完整的往返时间。
ATM ABR拥塞控制是一种采用网络辅助方法解决拥塞控制的协议。
ATM ABR拥塞控制是一种基于速率的方法。
TCP必须使用端到端拥塞控制而不是网络辅助的拥塞控制，因为IP层不向端系统提供显式的网络拥塞反馈。
TCP发送发的“丢包事件”定义为：要么出现超时，要么收到来自接收方的3个冗余ACK。
TCP发送方显式地协作，或存在一种分布式方法使TCP发送方能够仅基于本地信息设置他们的发送速率：
- 一个丢失的报文段表意味着拥塞，因此当丢失报文段时应当降低TCP发送方的速率。
- 一个确认报文段指示该网络正在向接收方交付发送方的报文段，因此，当对先前未确认报文段的确认到达时，能够增加发送方的速率。
- 带宽探测。
TCP拥塞控制算法包括3个主要部分：1、慢启动；2、拥塞避免；3、快速恢复。慢启动和拥塞避免是TCP的强制部分，两者的差异在于对收到的ACK作出反应时增加cwnd（发送窗口）长度的方式。慢启动比拥塞避免能更快地增加cwnd的长度。快速恢复是推荐部分，对TCP发送方并非是必需的。
在慢启动状态，cwnd的值以1个MSS（最大报文段长度）开始并且每当传输的报文段首次被确认就增加1个MSS。因此，TCP发送速率起始慢，但是慢启动阶段以指数增长。
如果存在一个由超时指示的丢包事件（即拥塞），TCP发送方将cwnd设置为1并重新开始慢启动过程。他还将状态变量值ssthresh（“慢启动阈值”的速记）设置为cwnd/2。
当cwnd的值等于ssthresh时，结束慢启动并且TCP转移到拥塞避免模式。
如果检测到3个冗余ACK，这时TCP执行一种快速重传并进入快速恢复状态。
拥塞避免的一种通用的方法是对于TCP发送方无论何时到达一个新的确认，就将cwnd增加一个MSS字节。
当丢包发生时，拥塞避免模式下TCP将cwnd的值减半，并且当收到3个冗余的ACK，将ssthresh的值记录为cwnd的值的一半。接下来进入快速恢复状态。
在快速恢复种，对于引起TCP进入快速恢复状态的缺失报文段，对收到的每个冗余的ACK，cwnd的值增加一个MSS。最终，当对丢失报文段的一个ACK到达时，TCP在降低cwnd后进入拥塞避免状态。
如果出现超时事件，快速恢复在执行如同慢启动和拥塞避免种相同的动作后，迁移到慢启动状态；当丢包事件出现时，cwnd的值被设置为1个MSS，并且ssthresh的值设置为cwnd值的一半。
TCP拥塞控制常常被称为加性增、乘性减（Additive-Increase，Multiplicative-Decrease，AIMD）拥塞控制方式。
TCP拥塞控制已经演化了多年并仍在继续演化。
TCP继续演化的需求能通过考虑网格和云计算应用所需要的高速TCP连接加以阐述。
当多条链路共享一个共同的瓶颈链路时，那些具有较小RTT的连接能够在链路空闲时更快地抢到可用带宽，因而将比那些具有较大RTT的连接享用更高的吞吐量。
运输层协议能够提供的服务经常受到下面网络层协议服务模型的限制。
在链路层、网络层、运输层或应用层协议层都可以提供可靠的数据传送。该协议栈中上面4层的任意一层都可以实现确认、定时器、重传以及序号，能够向其上层提供可靠数据传送。
数据报拥塞控制协议（Datagram Congestion Control Protocol，DCCP）提供了一种低开销、面向报文、类似于UDP的不可靠服务，但是具有应用程序可选择的拥塞控制形式，该机制与TCP相兼容。
DCCP被设想用于诸如流媒体等应用程序中，DCCP能够利用数据交付的预定时间和可靠性之间的折中，但是要对网络拥塞作出响应。
流控制传输协议（Stream Control Transmission Protocol，SCTP）是一种可靠的、面向报文的协议，该协议允许几个不同的应用层次的“流”复用到单个SCTP连接上（一种称之为“多流”的方法）。
SCTP的流控制和拥塞控制算法基本上与TCP中的相同。
TCP友好速率控制（TCP-Friendly Rate Control，TFRC）协议是一种拥塞控制协议而不是一种功能齐全的运输层协议。
TFRC的目标是平滑在TCP拥塞控制中的“锯齿”行为，同时维护一种长期的发送速率，该速率“合理地”接近TCP速率。
733
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
