运输层协议为运行在不同主机上的应用程序之间提供逻辑通信logic communication的功能。运输层协议是在端系统中，而不是网络路由器中实现。运输层接收来自应用程序的报文，转换为报文段segment。运输层为不同主机之间的进程提供了逻辑通信，而网络层为不同主机提供了逻辑通信。

即使底层网络协议在网络层不提供相应服务，运输层协议也能提供服务。如网络层协议可能会使分组丢失，错乱和重复，但运输层仍能会应用程序提供可靠的传输服务。

TCP传输控制协议Transmission Control Protocol，为应用程序提供可靠的，面向连接的服务，UDP用户数据报协议User Datagram Protocoal，为程序提供不可靠，无连接的服务。网络层的IP协议提供的是不可靠服务。UDP和TCP的基本任务是将两个端系统间IP的交付服务扩展为运行在两个端系统进程间的交付服务delivery service。称为运输层的多路复用transport-layer multiplexing和多路分解Demultiplexing。UDP和tCP可以通过在报文首部添加差错检测字段error-detection field，来提供完整性检测integrity checking。UDP中只有两种服务，进程间数据交付data delivery和差错检测。TCP中还提供了可靠数据传输，拥塞控制。

在接收端，运输层检测报文段首部信息，并标识出接收套接字，然后将报文定向给该套接字。运输层将报文段中的数据交付给正确的套接字的工作称为多路分解demultiplexing。

从源主机的不同套接字收集数据块，并为每个数据库封装上首部信息，从而生成报文段，然后将报文段传递给网络层的工作称为多路复用multiplexing。

运输层多路复用的要求：套接字有唯一的标识符，每个报文段有特殊的字段来指示其所要交付的套接字。而这些字段为源端口号字段source port number field和目的端口号字段destination port number field。端口号为16比特的数字，大小为0-65535，其中0-1023范围的端口号称为周知端口号well-known port number，是受严格限制的，它们保留给诸如HTTP(端口号80）和FTP（端口号21）等总所周知的应用层协议的。每个套接字被分配一个端口号。在报文段中，在一个32bit中保存着源端口号和目的端口号，返回时进行反转inversion。

UDP中的套接字有一个2元组来标识，目的IP地址和目的端口号。而TCP中的套接字由一个4元组来标志，源IP地址，源端口号，目的IP地址，目的端口号。对于UDP由于其是无连接的服务，所以，任何IP地址和目的端口号相同的报文段都被定向到一个套接字。而对于面向连接的TCP，当建立一个连接后，对于后续到达的报文段，其4个值必须匹配，即保证报文段来自一个连接，才能被分配到连接另一端的套接字。

一般web服务器只有一个进程，但是进程与连接套接字并不是一一对应的关系。当一个新的客户机创建一个新连接时，会在服务器中建立一个对应的新线程。

UDP没有进行握手，是无连接的connectionless。

DNS使用的是UDP。当一台主机的DNS应用程序想要进行查询，发送报文，然后等待回复，但在这个过程中，数据可能会丢失，而客户机不会得到响应。

使用UDP的原因：应用层能更好的控制发送的数据和发送时间，可以为实时程序real-time application提供更快的发送速率；无需连接建立，UDP没有建立连接的时延；无连接状态，TCP中为在端系统中维护连接状态，需要接收和发送一些信息；分组首部开销小，每个TCP报文段首部有20个字节，而UDP只有8个字节。

UDP中没有拥塞控制。当每个人都使用流式高比特率视频而没有拥塞控制时，会导致路由器中大量分组溢出，使几乎没有分组能通过。

使用UDP的应用是可以实现可靠数据传输的，通过在应用程序中建立可靠性机制，如增加确认和重传机制。

UDP的报文格式：UDP的首部只有4格字段，每个字段由两个字节组成。依次为源端口号，目的端口号，长度，检验和checksum。检验和来检测报文中是否有差错。

检验和的计算：先对所有16比特字求和，求和过程中如果溢出overflow进行回卷wrapped around，回卷是指将溢出的1加在最低位上。然后对和进行反码运算1s complement就是取反~操作。在接收方，将所有的16比特字包括检验和相加，如果分组无差错，结果为1111111111111111，不是则肯定出错。

UDP在端到端基础上在运输层提供差错检测，而在较低层次设置检测显然是冗余的。这是端到端原作end-end principle，即某种功能必须基于端到端实现。

可靠数据传输的原理：

可靠数据传输协议reliable data transfer protocol ，但其下层协议也许是不可靠的，如TCP使用的是不可靠的网络层协议IP。则一般认为较低层为不可靠的点对点通道。

由于双向数据传输bidirectional data transfer，与单向数据传输unidirectional data transfer类似，所以，只考虑单向时候的情况。

有限状态机finite-state machine FSM。

基于重传机制的可靠数据传输协议称为自动重传请求Automatic Repeat reQuest ARQ协议。协议进行肯定确认positive acknowledge和否定确认negative acknowledge。确认时返回信息，对于否定确认时，需要重传数据。ARQ协议中还需要另外三种协议来处理比特差错。差错检测：ARQ需要使用差错检测来检测出比特错误。接收方反馈：接收方需要提供明确的反馈给发送方，ACK或NAK。重传：接收方接收差错分组，发送方需要重传该分组。

停等stop-and-wait协议：发送方在发送分组后，要等待接收方返回的反应才能离开状态，进行之后的数据传输。

但是ACK和NAK分组可能受损。可能想到的解决方法中的一种是对不明确的ACK或NAK分组，重发当前分组，这样在信道channel中引入了冗余分组duplicate packet。而为了使接收方知道重发的分组是重发还是一个新的分组，采取的方法是：在数据分组中添加一个新字段，让发送方对其数据分组编号，即将分组的序号放在字段中，这样接收方就可以知道接收的分组是否是重传。

当接收方收到对同一个分组的两个ACK，即接收冗余ACK，duplicate ACK，就认为接收方没有正确收到此冗余ACK对应分组之后的分组。

底层信道还会丢包。对于丢包后的操作，可以通过序号和重传来重传所需丢包的分组，而对于丢包的检测，则需要一种新的协议机制。

对于发送方发送的分组丢包，接收方返回的ACK或是NAK的分组的丢包，都是发送方没有收到接收方的反应，则只需要设置一个时间，超过时间则判断发生丢包。则即使没有发生丢包，而发送方发送的冗余数据分组也不会影响传输，因为有分组序号的限制。

为了实现基于时间的重传机制，需要一个 倒计数计时器countdown timer，在一个给定的时间过期后，可中断发送方。发送方需做到：每次发送一个分组就启动一个定时器；响应定时器中断；终止定时器。

rdt3.0即包含以上几种对可靠数据传输所需协议的协议，称为比特交替协议alternative-bit protocol。

流水线可靠数据传输协议 pipelined  reliable data transfer protocols。

之前的rdt3.0为停等协议，性能较低。定义发送方或信道的利用率utilization 为：发送方忙着将发送比特送进信道的时间与发送时间之比。RTT时间为首个分组完全发送后，到接收方返回的确认分组到达发送方，之间的这段时间。

解决这个问题的简单方法是：不使用停等方式运行，允许发送方发送多个分组而无需等待确认。称为流水线pipelining。而使用流水线会对可靠数据传输造成一下影响：必须增加序号范围，每个分组不包括重传的分组都有唯一的序号，而在停等中只要01一个比特就可以实现；协议的发送方和接收方也许必须缓存多个分组，如发送方至少缓存已发送但未确认的分组；所需序号的范围和对缓冲的要求取决于数据传输协议处理丢失损坏及过度延时分组的方式。解决流水线的差错恢复有两种基本的方法：后退N步GO-Back-N GBN，和选择重传selective repeat SR。

回退N步：进行限制，流水线中未确认的分组数不能超过某个最大允许数N。在序号范围内，称最早的未确认分组的序号为基序号base；最小的未使用序号为下一个序号nextsequnum。而从base到base+N-1这个N格序号可看作为一个长度为N的窗口，窗口在序号空间内向前滑动，其中N为窗口的长度window size。GBN协议也被称为滑动窗口协议sliding-window protocol。GBN发送方响应三类事件：

上层的调用invocation from above：如果窗口已满，则将数据返回上层，隐式的通知上层窗口已满，或者是缓存这些数据，或者采用一些同步机制，使上层只有在窗口未满是才能调用rdt_send().。

收到ACK：对序号为n的分组确认采取累积确认cumulative acknowledgment。表示接收方已正确接收到到序号n之前的所有分组。

超时事件timeout event：GBN中仅使用一个定时器，如果超时，则重传所有已发送但未被确认的分组。当没有已发送但未确认的分组时，定时器被终止。

在GBN中，接收方按序将数据交付给上层，则接收方丢弃所有失序分组。虽然丢失已正确传输的分组有点浪费，但这样做可以不用缓存任何失序分组。

当GBN中的窗口长度较大时，一个单独分组的差错就需要重传大量分组。这样效率较低。

选择重传：让发送方仅重传那些怀疑在接收方出错的分组而避免不必要的重传。接收方逐个的确认正确接收的分组。同时用窗口长度n来限制流水线中未被确认和未完成的分组数。

SR中发送方的动作：1.从上层收到数据：同GBN中类似，检测序号，如果在窗口内，则发送，否则缓存或返回上层；2.超时：使用定时器来防止丢失分组，每个分组必须有自己的逻辑定时器，使用一个定时器来模拟多个逻辑定时器的操作。3：收到ACK：收到ACK，将这些分组标记为已接收，如果序号等于send_base，则窗口基序号向前移动到具有最小序号的未确认分组处。如果窗口中有未发送分组，则发送。

接收方确认一个正确分组而不管其是否按序。失序的分组将被缓存到所有失序分组都被收到，其中失序分组必定是比失序分组序号小的分组，而当这些分组到达时，就组成了一批序号正确的分组交付给上层。而接收方中也有一个接收方的接收窗口。

接收方的动作：1.序号在接收窗口内的分组被正确接收。此时，一个ACK分组被回送给发送方，如果该分组是没被收到的分组，则缓存。如果该分组序号等于接收窗口的基序号，则将该分组与以前缓存的序号连续的分组一起交付给上层。然后窗口响应前移交付分组的数量。2.序号在base-N 到 base -1 的分组，也返回一个ACK分组。3.其他情况，忽略分组。

对于第二种情况的ACK返回是为了返回的ACK丢失或出错的情况，来保证发送方中的窗口也能正确进行移动。而在SR中，接收方和发送方的窗口并不总是一致。

窗口的长度必须小于或等于序号空间大小的一半。因为长度较大时，由于超过一半，会使窗口中出现重复的序号，而这样，就无法分辨到底是哪个分组了。

面向连接的运输：TCP：

TCP进行可靠传输，依靠之前所讨论的差错检测，重传，累积确认cumulative acknowledgment，定时器，用于序号和确认号的首部字段。

TCP是面向连接的connection-oriented，两个进程之间发送数据之前，要进行握手handshake，即互相发送某些预备报文段，以建立确保数据传输所需的参数，初始化与TCP连接相关的许多TCP状态变量。TCP连接不是电路交换网络中实际的连接circuit，也不是一条虚电路virtual circuit，因为其连接状态完全保留在两个端系统中。TCP协议只在端系统中，中间路由器只能看到数据报。

TCP连接提供的服务是全双工服务full-duplex service：如果一台主机上的进程A与另一台主机上的进程B存在一条TCP连接，那么应用层数据既可以由A流向B，也可以由B流向A。

TCP连接是点对点的point-to-point ，即只存在单个发送方和单个接收方的之间的连接。多播multicasting对TCP是不可能的。

连接建立过程的三次握手three-way handshake：客户机发送一个特殊的TCP报文段，服务器用另一个特殊的报文段响应，然后客户机用第三个特殊报文段作为响应。前两个报文段不承载有效载荷payload，即不包含应用层数据，而第三个报文段可以承载有效载荷。

TCP将经过套接字传递来的数据放在该连接的发送缓存send buffer中。TCP从缓存中取出并放入报文段中的数据量受限于最大报文段长度maximum segment size MSS。MSS通常是根据最初设置的链路层最大帧长度来设置的。最大长度的帧被称为最大传输单元maximum transmission union，MTU。MTU一般为整个链路上可发送的最大链路层帧。MSS是指的报文段中应用层数据的最大长度，而不包含TCP报文段的首部。

TCP报文段的结构：由首部字段head field和数据字段data field组成。当TCP发送一个大文件时，TCP通常将文件划分为长度为MSS的若干块，最后一块长度大小不大于MSS。然后分别加上首部，按序发送。TCP的首部一般是20字节，其中以32比特为一个字，而其中具体储存数据依次是：2个字节的源端口号，2个字节的目标端口号；32比特的序号字段sequence number field，32个变态的确认号字段acknowledgment number field；4比特的首部长度字段，以32比特为字为单位的首部长度，TCP的首部长度是可变的；6比特的未使用的字段；6比特的标志字段flag field，依次是URG比特表示实体为紧急的数据（紧急数据的首部的最后一个字节为16比特的紧急数据指针字段urgent data pointer field），ACK比特用于指示确认字段中的值是有效的，PSH比特表示接收方应立即将数据交给上层，RST、SYN和FIN比特用于连接的建立和拆除；16比特的接收窗口字段，用于流量控制；16比特的检验和字段checksum；紧急数据指针字段；可选与变长的选择字段options field，该字段用与发送方与接收方协商最大报文段长度MSS，或在高速网络环境下用作窗口调节因子使用。

TCP报文段首部最重要的两个重要字段是序号字段和确认号字段。TCP把数据看作是无结构的unstructured但是有序ordered的字节流stream of bytes。报文段序号sequence number for a segment，序号不是报文段的序列，而是报文段首字节的字节流编号。TCP是全双工的full-duplex，主机A填充进报文段的确认号是主机A期望从主机B收到的下一个字节的序号。TCP只确认数据流中至第一个丢失字节为止的字节，即对失序的字节直接无视或者放在缓存中等待重新有序再一起交付给上层，则TCP提供累积确认。

序号是整个进程过程中产生的所有字节流的序号。

Telnet中：客户机将字符发送到远程主机，而远程主机收到后复制相同的字符返回客户机，并显示在Telnet用户的屏幕上，称为回显echo back，用来确保发送的数据已经被远程主机接收并处理。

服务器对接收到的客户机的数据的确认被装载到一个承载一个从服务器到客户机的数据的报文段中，称为 捎带piggybacked 在服务器到客户机的数据报文段中。

第三次握手时，发送的序号为第二次握手时接收方发来报文中的确认号，虽然并没有填充数据，而只是对服务器发送一个消息表示确认已从服务器接收到的数据。而确认号也为相应的计算得到的序号，虽然并不从接收方请求数据。

TCP使用超时重传机制来处理报文段的丢失问题。超时间隔长度的设置： 超时间隔必须大于RTT，TCP中估计发送方与接收方之间的往返时延的做法：在某个时刻做一次样本RTT Samle RTT的测量，即计算从某个报文段被发出即交给IP 到该报文段的确认被收到 的时间量。由于路由器中的拥塞和端系统负载的变化，报文段的Sample RTT也会随之波动，而为了得到一个典型的RTT，对Sample RTT做取平均值操作，得到Sample RTT的均值Estimated RTT ： 

EstimatedRTT  = (1 - a ) * EstimatedRTT + a * SampleRTT

其中a参考值为 a = 0.125。这种加权平均称为指数加权移动平均Exponential Weighted Moving Average ,EWMA。 还定义了RTT偏差DevRTT，用来估算SampleRTT 一般会偏离EstimatedRTT的程度：

DevRTT = (1 - b ) * DevRTT + b * | SampleRTT - EstimatedRTT|   其中b推荐值为0.25。

当超时间隔小于EstimatedRTT时，会造成不必要的重传，而如果较大则效率低，传输慢，则应该要选取一个合适的值。为：

TimeoutIntervel = EstimatedRTT + 4 * DevRTT

TCP中的可靠数据传输：IP是不可靠的，出错可能有三种：丢失，乱序和受损get corrupted。TCP的可靠数据传输服务确保进程从接收缓存中读出非损坏的uncorrupted，无间隔的without gap，非冗余的without duplication，和按序的in sequence数据流。

这里当依次发送多个报文段时，如果返回的确认报文段都超时了，则发送方依次重传第一个报文段，并重启定时器，如果在超时之前之后的确认报文段未到达，则依次重发下一条，如果到达，则不进行重发，即不是同时将所有超时的报文段全部重发，而是依次重发并等待。当前一个报文段的确认丢失，但后一个报文段的确认到达时，由于在接收方进行了有序的检测，则肯定认为之前的所有报文段已被正确接收。

加倍时间间隔：每次TCP重传会将下一次超时 时间 间隔 设为先前值的两倍，而不是有EstimatedRTT和DevRTT计算获得。这是一个简单的拥塞控制，由于超时可能是由拥塞引起，则每次定时更长，更慢的传输数据，这样尽量减少拥塞。

冗余ACK duplicate ACK，由于TCP中无否定确认，则使用冗余确认来作为一个隐式的否定确认。接收方发送ACK的策略：

当所期望序号的报文段按序到达，当之前的数据都已被确认且一个报文段单独到达时：延迟发送ACK，等待500ms，如果没有新的报文段到达，则发送ACk。

当所期望序号的报文段按序到达，另一个报文段也按序到达，新到达之前的报文段前有一些未确认的报文段，这些报文段是之前的失序报文段：则立即发送单个累积ACK cumulative ACK，即之后的报文的ACK。

比期望序号大的失序报文段到达：立即发送冗余ACk

能填充接收数据间隔的报文段到达：若报文位于间隔的低端，则立即发送ACK。

如果接收方接收到对相同数据的3个冗余ACK，则TCP执行快速重传fast restransmit，即在该报文段的定时器过期expire之前重传丢失的报文段。

TCP的确认是累积式的，正确接收但失序的 报文段是不会被接收方逐个确认的，即对于失序的报文段不返回ACK。TCP既不是GBN也不是SR。选择确认selective acknowledgment，TCP接收方有选择的确认失序报文段，而不是累积确认最后一个正确接收的有序报文段。

流量控制：

TCP为应用程序提供流量控制服务flow-control service，以消除发送方使接收方缓存溢出的可能性。流量控制是一个速度匹配服务，即将发送方的发送速率与接收方应用程序的读速率相匹配。发送方因为IP网络拥塞而被遏制， 称为 拥塞控制congestion control。

TCP通过让发送方维护一个称为接收窗口的receive window 的变量来提供流量控制。由于TCP是全双工通信，则在两端都有一个接收窗口。TCP中接收方为此维护的一些变量

RcvBuffer ：表示接收缓存的大小。

LastByteRead：主机应用从接收缓存中读出的数据流的最后一个字节的编号。

LastByteRcvd：从网络中到达，并且已经放入主机接收缓存中的数据流中最后一个字节的编号。

则LastByteRcvd - LastByteRead < = RcvBuffer。

而接收窗口为RcvWindow = RcvBuffer - ( LastByteRcvd - LastByteRead）。开始时，接收方设定RcvWindow = RcvBuffer。

接收方将RcvWindow值放入发给发送方的报文段中的接收窗口字段中。来通知发送方该连接的缓存中还有多少可用空间。

发送方维护两个变量LastByteSend和LastByteAcked。两者之差为发送方发送到连接中但未被确认的数据量，使其

LastByteSent - LastByteAcked <= RcvWindow。保证不会溢出。

当接收方缓存都填满时，返回的最后一个报文段中的RcvWindow值为0，则完全阻塞blocked，即使缓存后来被应用程序读取清空，但不会有消息告知发送则窗口已改变。

则在TCP中有：当主机的接收窗口为0时，发送方继续发送只有一个字节数据的报文段。这些报文段将被接收方确认，当缓存清空时，则返回报文段就会有非0的RcvWindow。

TCP连接管理：建立TCP连接的3次握手：

1.客户机端的TCP首先向服务器端的TCP发送一个特殊的TCP报文段。该报文段不包含应用层数据，但首部的SYN比特被设为1。则这个特殊报文段被称为SYN报文段。其中客户机会选择一个初始序号client_isn来设置SYN报文段中的序号字段。

2.当包含SYN报文段的IP数据报到达服务器端，服务器从数据报中提取SYN报文段，并为该TCP连接分配TCP缓存和变量。并想客户机TCP发送允许连接的报文段。允许连接的connection-granted报文段也不包含应用层数据。其中包含3格重要信息：SYN比特也被设为1，首部的确认号字段被设为client_isn + 1， 其首部的序号字段被设置为自己的初始序号server_isn。也被称为SYNACK报文段

3.收到SYNACK报文段后，客户机也为连接分配缓存和变量，客户机主机还会向服务器发送另外一个报文段，该报文段也对SYNACK进行确认，即将确认字段设为server_isn + 1，但此时连接已经建立，则该SYN比特为0，之后也全部为0，其序号字段为client_isn + 1，不包含应用层数据。

3次握手后，TCP建立连接，客户机和服务器主机就可以互相发送含有数据的报文段。

连接的终止，进行4次握手，1.客户机TCP发送一个特殊的TCP报文段，其FIN比特被设置为1；2.服务器接收到后会送一个确认报文段，FIN比特为0，只是对接收到客户机的信息进行确认；3.发送终止报文段shutdown segment，其FIN为1；4.最后客户机在对服务器发来的确认报文段回送确认ACK。连接正式关闭，所有资源被释放。

TCP的生命周期中有各种TCP状态state，一开始处于CLOSED，然后客户机发送SYN后进入SYN_SENT状态，客户机接收到服务器的SYNACK和发送ACK后，TCP连接建立起来，处于ESTABLISHED状态。客户机选择关闭连接，发送一个TCP报文段，进入FIN_WAIT_1状态，等待服务器的ACK信息，而ACK信息到后进入FIN_WAIT_2状态，等待服务器的终止报文段，等到后客户机发送确认报文段，进入TIME_WAIT状态，这个状态使TCP有时间处理ACK的重传，即以防最后的ACK丢失的情况。经过等待后，资源就被释放。

当客户机向服务器发送SYN报文段，但服务器段对应端口没有进程在运行，即报文段中的端口号或源IP地址与该主机上进行的套接字都不匹配时，服务器返回一个特殊重置报文段，报文段的RST标志位为1。

则在nmap中，对特定主机发送一个SYN报文段，如果源主机收到TCP SYNACK报文段，则表示目标主机上一个应用程序在使用TCP端口。如果从目标主机收到TCP RST报文段，则表示目标主机的目标端口没有应用程序在运行，且源主机和目标主机之间没有任何防火墙。源主机什么也没有收到，则表示SYN报文段可能被中间的防火墙阻挡。

拥塞控制的原理：

异步传输模式asynchronous transfer mode ATM； 可用比特率available bit-rate ABR

在两个发送方，两个接收方，一个路由器组成的简单情况的分析，一个路由器称为一跳，则这里是共享单跳sharing a single hop的情况：当路由器缓存无限大时，而链路的容量为R字节/秒，当发送方的发送速率达到R/2的过程中，链路逐渐饱和，其接收方的吞吐量会达到最大值R，但是源与目的地之间的平均时延会越来越大，书上这样说，其实是指链路两端的速率不同，即路由器的输出速率或者路由器到接收方的链路的容量 较小于 路由器的输入速率或者路由器到发送方的链路的容量。

如果路由器的缓存是有限的：运输层向网络中发送报文段的速率用λ‘in 字节/秒 表示，称为对网络的供给载荷offered load。而λ in为应用程序将初始数据发给套接字的速率。如果不考虑重传，两者相等，忽略添加的首部的数据量？而由于拥塞而重传发送的分组同时增加了拥塞的程度。还有一种网络拥塞的开销是由于大时延导致的不必要的重传。

多跳的情况下：如果一个路由器的上游还有其他路由器，则在路由器之间的链路上接收大量的主句的供给载荷时，会导致上游的分组几乎无法到达此路由器。

端到端拥塞控制：在端到端中，网络层没有为运输层拥塞控制提供显示支持。即运输层必须在自己的能力范围能去判断拥塞和处理拥塞。即运输层通过判断分组的丢失 （超时或3次冗余确认）来认为网络是拥塞的。TCP会相应的减小其窗口长度等等。
网络辅助的拥塞控制：网络层组件即路由器向发送方提供关于网络中拥塞的显示反馈信息。
拥塞信息从网络反馈到发送方有两种方式：直接反馈信息，采用一种 阻塞分组choke packet，直接由网络路由器发送给发送方；另一种通知是路由器标记或更新从发送方流向接收方的分组中的字段来指示拥塞，而接收方接收具有拥塞标记的分组后会告知发送方网络发生拥塞，则至少要一个完整的往返时间。
ATM ABR 拥塞控制：ATM采用一种面向虚电路VC 的方法来处理分组交换。TCP中的连接不是电路也不是虚电路，虚电路在源到目的地路径上的每台交换机都维护有关源到目的地的连接的状态。在ATM ABR服务中使用交换机switch而不是路由器，使用术语信元cell而不是分组。在数据信元中夹杂这 资源管理信元resource-management cell RM cell。RM信元用来在主机和交换机之间传递 与拥塞相关的信息。ATM ABR的拥塞控制是基于速率，即发送方明确的计算出它能发送的最大速率，然后进行调整。有三种机制用于从交换机到接收方发送与拥塞相关的信息：1.EFCI比特，数据信元中包含一比特的显示转发拥塞指示Explicit Forward Congestion Indication EFCI比特。设为1表示网络已阻塞。如果一个RM信元到达目的地，而之间来的数据信元中的EFCI比特都为1，则目的地将RM信元中的EFCI比特设为1，并将此RM信元发送给发送方。2.RM信元中还有拥塞指示congestion indication CI和无增长no increase NI 比特。RM信元夹杂在数据信元中，夹杂比率是可变的，默认为32个数据信元中有一个RM信元。轻微拥塞时，NI为1，严重拥塞时CI为1。3.ER 显示速率Explicit Rate 字段的设置。RM信元中还包含一个两字节的ER字段。一个拥塞的交换机会降低ER中的值，而ER字段将被设置为所有交换机中的最小可支持速率。


TCP中的拥塞控制：
TCP中使用的是端到端拥塞控制，因为IP不给TCP显示的拥塞反馈。TCP让每个发送方根据所感知的网络拥塞的程度来设置其向连接发送流量的速率：如果没拥塞，则发送方增加发送速率，如果感觉到拥塞，则降低自己的发送速率。
TCP拥塞控制机制让连接的每一端记录一个额外的变量，为拥塞窗口congestion window，表示为CongWin。它来限制发送速率，使发送方 未被确认的数据量满足：
LastByteSent - LastByteAcked <= min{CongWin,RcvWindow}
发生数据丢失 超时或收到三个冗余ACK 就认为拥塞。TCP接收到对以前未确认报文的确认，认为网络是正常的，则增加拥塞窗口的长度，即增加发送速率。如果确认以较慢的速度到达，则拥塞窗口以较慢的速率增加，如果ACK返回速率高，则拥塞窗口更迅速增大。TCP是使用确认来触发它的拥塞窗口的增大，则称为是自计时的self-clocking。
而感知拥塞时，调节发送速率采用 TCP拥塞控制算法TCP congestion control algorithm。这个算法包含3个主要部分：
1.加性增additive-increase 乘性减multiplicative-decrease：降低发送速率时，让拥塞窗口减半，但最小不能低于一个MSS。增大发送速率的原理是没有检测拥塞，就认为有可用的带宽可被TCP连接使用。则缓慢的增加拥塞窗口的长度，防止拥塞。每次在一个往返时延RTT内CongWin增加一个MSS。这种拥塞控制协议中的线性增长阶段被称为避免拥塞congestion adoidance。使TCP连接的CongWin呈锯齿形状saw-toothed pattern。这种拥塞控制算法称为AIMD算法。
2.慢启动slow start：当TCP连接开始时，CongWin的值初始为一个MSS,这使得初始发送速率为MSS/RTT（当忽略丢包以及传输时延时，传输速率为 CongWin/RTT或RcvWindow/RTT)。但这样使速度达到一个可观的级别将经历很长的时间。所以TCP发送方在初始阶段不是线性的增加发送速率，而是以指数的速度增加，即每过一个RTT就将CongWin的值翻倍，直到发生了一个丢包事件为止，才开始线性增长。虽然叫慢启动，只是说其初始发送速率慢，并不是启动即加速度慢。
3.对超时事件做出反应：收到三个冗余ACK与检测出超时事件，TCP做出的反应是不同的，前者是将拥塞窗口减半，而后者，当超时事件发生后，TCP再次慢启动，将拥塞窗口设置为1个MSS，但是这里如果没有出现丢失的话，会持续到之前窗口值的一半，然后进行线性增长。TCP中维护一个称为阈值Threshold的变量来管理这个过程，用来保存这里使用的之前窗口值的一半。其初始化是为一个较大的值65KB。
为什么对超时事件直接慢启动：因为收到三个冗余ACK表示某些报文段已经被接收方接收并处理，而超时则可能有大量的数据丢失，说明拥塞相当严重，所以直接将窗口设为MSS，极大的减轻拥塞。而在接收到3个冗余ACK后取消慢启动的行为称为快速恢复fast recovery。但是，这破书上有说大多数TCP实现采用的是Reno算法，即如同三个ACK一样进行减半，然后线性增加，没有慢启动。


对TCP吞吐量的宏观描述：这里忽略丢包，忽略传输时延，忽略慢启动过程，不考虑流量控制等等。对于一个稳态的TCP，其往返时延为RTT，拥塞窗口为W,其速率线性增加到W/RTT，然后降到一般W/2RTT，然后在继续增加，往复。则这样一个稳态的TCP连接的吞吐量为 0.75*W/RTT。
关于吞吐量，丢包率的公式：吞吐量 = 1.22 * MSS /RTT /( √L),L为丢包率。


公平性fairness：
瓶颈链路bottleneck link：指对于每条连接，沿着连接路径上的其他所有链路段都不拥塞，而只有瓶颈链路容量小，发生拥塞。如果K条连接，都经过一段传输速率为R bps的瓶颈链路，其每条连接的平均传输速率接近R/K,则认为其是公平的。假设仅有TCP连接通过瓶颈链路，且所有连接拥有相同的RTT值，则可以得出多条TCP连接接近等额范围波动，可以认为这种情况是公平的，但是其平均值并不是R/K，因为对于一个TCP连接其平均值又不是R,而是0.75R。但实际上具有较小RTT的连接能够在链路空闲时更快的抢到可用带宽，从而获得更大的吞吐量。
UDP不是公平的，当TCP由于拥塞而降低速率时，UDP仍然大量的占用TCP的流量。
多条并行连接也是不公平的：一个应用只使用一个TCP连接时，多个应用是公平的，但当一个应用并行使用多条TCP连接时，则这些应用之间就显得不公平。