· 概述和传输层服务：
· · 传输服务：
· · 传输层在两个远程进程之间进行报文段的逻辑通信。
· · · 传输层协议运行在端系统：
· · · 发送方：将应用层的报文分为报文段，然后传给网络层。
· · · 接收方：将报文段重组成报文，然后传递给应用层。
· · · 可选协议：
· · · Internet：TCP和UDP
· · 传输层与网络层的工作对比：
· · 网络层服务：主机之间的逻辑通信。
· · 传输层服务：进程之间的逻辑通信。
· · · 传输层依赖于网络层提供的服务：
· · · 由于网络层提供的数据段可能会丢失、延时、乱序等，所以网络层传输是不可靠的，由传输层协议加强其中某些特性。
· · · 传输层加强特性有：数据丢失、顺序混乱、加密等。
· · · 不能加强特性有：延迟、带宽等。
· · Internet传输层协议：
· · · TCP：
· · · 多路复用、解复用；拥塞控制；流量控制；建立连接；可靠的、保序的。
· · · UDP：
· · · 不可靠、不保序的；多路复用、解复用；没有为IP服务添加更多的其它服务。
· · TCP、UDP都不提供延时保证、带宽保证。
· 多路复用、解复用：
· 在发送方主机进行多路复用，从多个套接字接收来自多个进程的报文，根据套接字对应的IP地址和端口号等信息对报文段用头部加以封装（该头部信息用于解复用）。
· · 发送方主机在进行封装时，运输层TCP/UDP协议会将报文拆分为报文段，然后在每个报文段前面加上对应进程的源端口号与目的端口号，再将封装好的报文段、源IP地址和目的IP地址传给网络层，由网络层IP协议进行进一步的封装并发送。
· 在接收方主机进行多路解复用，根据报文段的头部信息中的IP地址和端口号将接收到的报文段发给正确的套接字（和对应的应用进程）。
· · 在接收方网络层接收到IP数据报时，将源IP地址、目的IP地址和报文段（包含源端口和目的端口） 传输给运输层，运输层根据源、目的端口号和源、目的IP地址将报文段传给不同的进程（套接字）。
· · 多路解复用原理
· · 主机接收到IP数据报。
· · 每个数据报有源IP地址和目的IP地址。
· · 每个数据报都承载一个传输层报文段。
· · 每个报文段有一个源端口号和目的端口号（对于特定的应用有著名的端口号）。
· · 主机联合使用IP地址和端口号将报文段发送给合适的套接字。
· 无连接传输：UDP（User Datagram Protocol）
· UDP发送端与接收端之间没有握手
· 每个UDP报文段都被独立地处理。
· 无拥塞控制、流量控制。
· 报文段的头部很小，开销很小。
· · UDP数据报的格式：
· · UDP校验和（EDC）：
· · 用来检测在被传输报文段中的差错（如bit反转）。
· · 在发送方中，将报文段的内容视为一个个16bit的整数；将报文段中的一个个整数相加即得到校验和（1的补运算）；发送方将校验和放在UDP的校验和字段。
· · 在接收方中，计算接收到的报文段的校验和，并与校验和字段中的内容是否相等：如果不相等，那就检测到了错误；如果相等，没有检测到差错，但也许存在残留差错（莫名其妙的错误）。
· · · 例：
· · · 当数字相加时，当最高位要进位时，将最高位放于最低位（即再加到结果上，称为进位回卷）。
· · · 在接收端，将校验和（校验和字段的值）与校验范围和（是接收端的数字相加所得数的反码）相加，如果bit全为1，则证明校验成功。
· 可靠数据传输（RDT）的原理：
· 信道：数据传输通道，具有不可靠性，体现出可靠数据传输协议（RDT）的复杂性。
· · 函数定义：
· · rdt_send(): 被上层（如应用层）调用，以将数据交付给下方的发送实体。
· · udt_send(): 被RDT调用，用以将分组放到不可靠的信道上传输到接收方。
· · deliver_data(): 被RDT调用，将数据交付给应用层。
· · udt_rcv(): 当分组通过信道到达接收方时被调用。
· · rdt_rcv()：被接收方的RDT调用，表示接收报文段的事件。
· · extract()：表示将报文段进行解封，提取出传输给应用层的数据。
· · corrupt()：表示传输过来的数据报出现了差错。
· · notcorrupt()：表示传输过来的数据报没有出现差错。
· · has_seq0()：表示此时接收到的分组的序列号必须是0。
· · 使用有限状态机（FSM）来描述发送方和接收方：一个状态只能由一个事件确定。
· · RDT 1.0：在可靠信道上的可靠数据传输
· · 假设对于下层的信道完全是可靠的，不会出现bit出错、分组丢失的情况。
· · 发送方将数据发送到下层信道，接收方从下层信道接收数据。
· · FSM描述为：
data为应用传输的数据；
packet = make_pkt(date)为将数据封装为报文段
· · RDT 2.0：具有bit差错的信道：
· · 下层信道可能会出错，将分组中的bit反转等。但我们可以用校验和来检测bit差错。
· · · 出错时的解决方案：
· · · 确认（ACK）： 接收方显示地告诉发送方分组已被正确的接收。
· · · 否认（NAK）： 接收方显示地告诉发送方分组发生了差错，需要发送方重新发送分组。
· · · RDT2.0中的新机制： 采用差错控制编码进行差错检测；发送方进行差错控制编码、缓存；接收方使用编码检查差错；然后接收方进行反馈：发送控制报文（ACK，NAK）到接收方；然后发送方收到反馈并进行相应的动作。
· · · FSM描述：
· · · 当没有出现差错时的操作为：1 -> 4 -> 5
· · · 当出现差错时的操作为：1 -> 2 -> 3 -> 4 -> 5
· · · 这里的差错指的是发送的数据出现差错，从而导致操作2发生。
· · · RDT2.0版本的致命缺陷：
· · · 前面讲的差错是传输的数据出现差错，但如果返回的ACK/NAK出现差错，可能会导致重复发送、死锁等现象。
· · · 所以引入新的机制——序号 。
· · · RDT 2.1：处理重复、死锁等现象。
· · · 发送方在发送的每个分组中加入序号。
· · · 如果ACK/NAK出错（这里的出错是指接收到的不是ACK就代表出错），发送方重传当前分组。
· · · 如果接收方接收到重复的分组，丢弃重复的分组。
· · · 这里有个等停协议：当发送方发送一个分组时，随后等待接收方的应答。
· · · · 发送方处理出错的ACK/NAK的FSM描述：
· · · · 接收方处理出错的ACK/NAK：
· · · · 对上述错误进行分析：
· · · · 发送方：
必须在分组中加入序列号；
序列号只用0,1便足够了；
一次只发送一个未经确认的分组；
必须检查ACK/NAK是否出现错误（用EDC）；
状态数会变为两倍，且必须记住当前分组的序列号为0还是1。
· · · · 接收方：
必须检测接收到的分组是否是重复的；
状态会指示希望接收到的分组序号是0还是1；
接收方并不知道发送方是否正确的接收到了ACK/NAK；
· · · · RDT 2.1的运行：
· · · · 当反馈的ACK出现错误，发送方会当做NAK来处理，并重复发送上一个分组。注意0/1只是序列号，并不是分组的唯一标识，只是用来表明两个分组的先后关系。
· · · RDT 2.2：无NAK的协议：
· · · 功能和RDT 2.1没有区别，但是回馈控制报文只使用了ACK。
· · · 接收方对最后一次正确接收的分组（也就是当前接收分组的上一个分组） 发送相应序列号的ACK，以替代NAK；接收方必须显式地包含被正确接收分组的序号。
· · · 当收到重复的ACK（如：再次收到ack0）时，发送方与收到NAK时采取相同的动作：重传当前分组。
· · · 这种优化为后面的一次发送多个数据单位做一个准备：
一次能够发送多个；
每一个的应答都有：ACK，NCK比较麻烦；
使用对前一个数据分组的ACK，代替本数据单位的NAK；
确认信息减少一半，协议处理简单。
· · · · RDT 2.2的运行：
· · RDT 3.0：具有bit差错和分组丢失的信道
· · 对于下层信道可能会丢失分组（数据或ACK），从而导致死锁等情况。
· · 发送方等待ACK一段合理的时间（timeout时间，需要一个倒计数定时器），链路层的timeout时间是确定的，而传输层timeout时间是适应性的（动态的）。
· · 当发送端没有收到ACK并且超时，就会重新传输该分组。
· · 重传会导致数据重复，但可以利用序列号处理此问题，接收方必须指明被正确接收的序列号。
· · · RDT 3.0发送方的FSM描述：
· · · RDT 3 .0运行：
· · · 过早的超时也能正常工作，但是效率会较低，一半的分组和确认是重复的。所以得设置一个合适的超时时间。
· · · RDT 3.0的性能：
· · · RDT3.0可以工作，但链路容量比较大的情况下，性能很差。链路容量比较大，一次发一个PDU 的不能够充分利用链路的传输能力。
· · RDT的流水线：提高链路利用效率：
· · 允许发送方在为得到对方确认的情况下一次发送多个分组。
· · · 必须增加序列号的范围：用多个bit表示分组的序号；
· · · 在发送方/接收方要有缓冲区；
发送方缓冲：未得到确认，可能需要重传；
接收方缓存：上层用户取用数据的速率≠接收到的数据速率；
接收到的数据可能乱序，所以需要排序交付（体现了可靠性）
· · 有两种通用的流水线协议：回退N步（GBN）和选择重传（SR）。
· · · 滑动窗口（Slide Window）协议：
· · · · 发送缓冲区：
· · · · 内存中的一个区域，落入缓冲区的分组可以发送；用于存放已发送、但没有得到确认的分组；被用在需要重发时。
· · · · 发送缓冲区的大小：一次最多可以发送多少个未经确认的分组数。
停止等待协议中的发送缓冲区=1；
流水线协议的发送缓冲区>1（不能很大）。
· · · · 发送缓冲区中的分组有：未发送的（存入缓冲区的分组，可以连续发送出去）、已发送的、但等待对方确认的分组（发送缓冲区的分组只有得到确认才能删除）。
· · · · 发送窗口：
· · · · 发送缓冲区内容的一个范围，由那些已发送但是未确认分组的序号构成的空间。
· · · · 发送窗口的最大值<=发送缓冲区的值。
· · · · 在最初状态，没有发送任何一个分组，发送窗口的前沿和后沿（相当于头与尾）相等，之间的发送窗口尺寸=0。
· · · · · 前、后沿移动：
· · · · · 前沿移动代表：发送分组；
· · · · · 后沿移动代表：收到老分组的确认，发送缓冲区罩住新的分组，来了分组可以发送（不能够超过前沿）。
其中绿色范围表示发送缓冲区的最大值，红色数字代表此分组已经确认被接收方接收。
· · · · 如图：数字为黑色表示分组还未被发送；数字变红表示分组已被发送、但未确认接收；数字变蓝绿色表示分组已被确认接收。
· · · · 接收窗口：
· · · · 接收窗口（Receiving Window）=接收缓冲区。
· · · · 接收窗口用于控制哪些分组可以接收；
只有收到的分组序号落入接收窗口内才允许接收；
若序号在接收窗口之外，则丢弃；
· · · · 接收窗口尺寸Wr=1，则只能顺序接收（GBN（go back N）采取的方法）；
· · · · 接收窗口尺寸Wr>1 ，则可以乱序接收；但要按序提交给上层的分组（SR（selective repeat）采取的方法）。
· · · · 接收窗口的滑动和发送确认：
· · · · 滑动：若低序号的分组到来，接收窗口移动；若高序号分组乱序到达，缓存但不向应用层交付（因为要实现rdt，不允许乱序），不滑动。
· · · · 发送确认：若接收窗口尺寸=1 ，则发送连续收到的最大的分组确认（累计确认）；若接收窗口尺寸>1 ，则收到分组时，发送那个分组的确认（非累计确认）。
· · · · 例：
接收窗口尺寸=1时如下：
Wr＝1，在0的位置；只有0号分组可以接收；
若接收到0号分组，则向前滑动一个，罩在1的位置；
如果在等待1号分组的时候，收到了2号分组，则丢弃2号分组；
接收窗口尺寸>1时
(1)按序接收到0、1分组
（2）乱序接收到1、2分组（还未接收到0号分组）：
· · · · 正常的发送窗口与接收窗口之间的互动：
· · · · 首先，有新的分组落入发送缓冲区范围，发送分组并且将前沿滑动。
· · · · 收到分组，落入到接收窗口范围内，如果是低序号 ，发送确认给对方。
· · · · 来了老的低序号分组的确认，然后将后沿向前滑动，使新的分组可以落入发送缓冲区的范围。
· · · · 异常情况下GBN的窗口互动：
· · · · 新分组落入发送缓冲区范围，发送并使前沿滑动。
· · · · 接收缓冲区收到的是乱序分组，没有落入到接收窗口范围内，丢弃该分组并（重复）发送老分组的确认，累计确认；
· · · · 发送缓冲区接收到了老分组的重复确认，使后沿不向前滑动，新的分组无法落入发送缓冲区的范围（此时如果发送缓冲区有新的分组可以发送）。
· · · · 超时重发机制让发送端将发送窗口中的所有分组发送出去。
· · · · 异常情况下SR的窗口互动：
· · · · 新分组落入发送缓冲区范围，发送该分组并使前沿滑动。
· · · · 接收缓冲区收到乱序分组，落入到接收窗口范围内，接收该分组并发送该分组的确认；
· · · · 发送缓冲区接收到了乱序分组的确认，后沿不向前滑动，新的分组无法落入发送缓冲区的范围（此时如果发送缓冲区有新的分组任然可以发送）；
· · · · 发送缓冲区的超时重发机制让发送端将超时的分组重新发送出去（单个分组）；
· · · GBN（go back N）：
· · · 发送方的FSM：
· · · 接收方的FSM：
· · · 运行的GBN演示：
· · · SR（选择重传，selective repeat）：
· · · 接收方对每个正确接收分组，分别发送ACKn（非累积确认）。
· · · 发送方只对那些没有收到ACK的分组进行重发（选择性重发，发送方为每个未确认的分组设定一个定时器）。
· · · 发送窗口的最大值（发送缓冲区）限制发送未确认分组的个数。
· · · · 发送方：
· · · · 从上层接收数据，如果下一个可用于该分组的序号可在发送窗口中，则发送；
· · · · 当一个分组的等待超时时，重新发送分组n，重新设定定时器；
· · · · 当接受到ACKn时，将分组n标记为已接收，如n为最小未确认的分组序号，则将后沿移到下一个未确认序号。
· · · · 接收方：
· · · · 接收一个分组，并发送该分组的ACKn，如果是乱序的分组，则放在缓冲区中等待，如果是有序的分组，则将该分组及以前缓存的
序号连续的分组交付给上层，然后将窗口移到下一个仍未被接收的分组。
· · · · SR的运行：
· · · GBN协议和SR协议的异同：
· · · 相同之处：发送窗口>1；一次能够可发送多个未经确认的分组。
· · · 不同之处：
GBN :
? 接收窗口尺寸=1；
? 接收端：只能顺序接收；
? 发送端：从表现来看，一旦一个分组没有
发成功，如：0,1,2,3,4; 假如1未成功，234
都发送出去了，发送端需要返回1再发送1234。
? 发送端拥有对最老的未确认分组的定时器，
只需设置一个定时器，当定时器到时时，重传
所有未确认分组。
SR:
? 接收窗口尺寸>1；
? 接收端：可以乱序接收；
? 发送端：发送0,1,2,3,4，一旦1未成功，
0234已发送，无需重发，选择性发送1。
? 发送方为每个未确认的分组保持一个定时器，
当超时定时器到时，只重发到时的未确认分组。
· · · · GBN与SR的对比：
· TCP（Transmission Control Protocol）面向连接的传输协议：
· · 特性：
· · 点对点的（一个接收方、一个发送方）；
· · 可靠的、按顺序的字节流（没有报文边界）；
· · 管道化（流水线）；TCP拥塞控制和流量控制去设置窗口大小；
· · 拥有发送和接收缓存；
· · 在同一连接中数据流双向流动；
· · MSS（Maximum Segment Size）：最大报文段大小，保证一个TCP报文段适合单个链路层帧，这里指的是应用层数据的最大长度，而不是指包括TCP首部的TCP报文段的最大长度；
· · 在数据交换之前，通过握手（交换控制报文） 初始化发送方、接收方的状态变量。
· · TCP报文段结构：
· ·由一个首部字段和一个数据字段组成。
· · 序号：报文段中数据部分的首字节在传送的字节流（报文）中的偏移量（起始序号不为0，由建立连接时所确认）。
如图，对第一个报文段分配序号0，第二个报文段分配序号1000……
· · 确认号：期望从另一方收到的下一字节的序号（也就是接收方想要向发送方发送的报文段序号，这是累积确认的，是ACK序号）。
一条TCP连接的双方均可随机地选择初始化序号，这样做可以减少将那些仍在网络中存在的来自两台主机之间先前已终止的连接的报文段，被误认为是后来这两台主机之间新建立连接所产生的有效报文段。（碰巧与旧链接使用了相同的端口号）
· · 可选与可变的选项字段，该字段用于发送方与接收方协商最大报文段长度（MSS）时，或在高速网络环境下用作窗口调节因子时使用等。
· · ACK比特用于指示确认字段中的值是有效的，即该报文段包括一个对已被成功接收报文段的确认。
· · RST、SYN、FIN比特被用于连接的建立和拆除。
· · PSH比特被设置的时候，被指示接收方应立即将数据交给上层。
· · URG比特用来指示报文段里存在着被发送端的上层实体置为“紧急”的数据。
· · 紧急数据的最后一个字节由16bit的紧急数据指针字段指出，当紧急数据存在并给出了指向紧急数据尾的指针时，TCP必须通知接收端的上层实体。
· · 例如：
其中，Seq=42，ACK=79，data=‘C’，表示，主机A发送的报文段序号为42，期望主机B返回的报文端序号从79开始传输，数据部分为‘C’；Seq=79，ACK=43，data=‘C’，表示，主机B发送的报文段序号为79，期待主机A返回的报文段序号从43开始传输，数据部分为‘C’……
· · TCP往返延时（RTT）和超时设置：
· · 报文段的样本RTT（SampleRTT）从某个报文段被发出到对该报文段的确认被收到之间的时间量。
· · 大多数TCP仅在某个时刻做一次RTT的测量，而不是为每个发送的报文段测量一个SampleRTT。
· · 超时设置比RTT要长；但RTT是变化的，所以如果超时太短：太早超时，造成不必要的重传，如果超时太长：对报文段丢失，造成反应太慢。
· · 定期测量RTT，并测量RTT的平均值和方差，可以将超时设置为RTT平均值+方差*4。
· · 一旦报文收到并更新EstimatedRTT后，TimeoutInterval就会重新计算。
· · 可靠数据传输：
· · · 三个主要事件：
· · · 是GBN和SR的结合，具有累计确认，具有单一重传定时器（最老的分组），当定时器还没有为其它报文段而运行时，则当下一个报文段被传给IP时，TCP就启动该定时器。
· · · 当超时时，只会重发最早的未确认的报文段并重启定时器；
· · · 当接受到重复的确认时也会重发（快速重发），当接受到三个关于最早确认的ACK时，就会启动快速重传机制，在未收到三个ACK（都是关于最早未确认的报文段）时，会等待定时器超时，然后再重发。
· · · TCP发送方（简化版）：
· · · 从应用层接收数据：用nextseq创建报文段；序号nextseq为报文段首字节的字节流编号，如果定时器还没有运行，则启动定时器，定时器与最早未确认的报文段关联。
· · · 超时：重传后沿最老的报文段并重新启动定时器。
· · · 收到确认：如果是对尚未确认的报文段确认，更新已被确认的报文序号，如果当前还有未被确认的报文段，重新启动定时器。
· · · 伪代码：
· · · 快速重传：
· · · 超时周期太长，在重传丢失报文段之前的延时太长。
· · · 如果发送方收到同一数据的3个冗余ACK，重传最小序号的段，冗余ACK指再次接收到同一报文段的ACK确认。
· · · 快速重传：在定时器过时之前重发报文段并重启定时器。
· · · 它假设跟在被确认的数据后面的数据丢失了，第一个ACK是正常的；收到第二个该段的ACK，表示接收方收到一个该段后的乱序段；收到第3，4个该段的ACK，表示接收方收到该段之后的2个 ，3个乱序段，段丢失的可能性非常大，所以发送方必须进行快速重传。
· · · 样例：
· · · 产生TCP ACK的建议：
· · · 当接收方接收到一个有间隔的报文序，这个间隔可能是由于在网络中报文段丢失或重新排序造成的，此时接收方不能向发送方返回一个显示的否定确认，相反，它只是对已经接收到的最后一个按序字节数据进行重复确认，即发送一个冗余ACK。
· · · 重传样例：
· · · TCP的选择确认：
· · · TCP发送方仅需维护一个已发送但未被确认的字节的最小序号和下一个要发送的序号（类似GBN）。
· · · TCP接收方会将正确接收但失序的报文段缓存起来，当接收到失序的报文段时，TCP会将顺序的报文段交付给应用层（类似SR）。
· · · 在发送方接收到一个报文段的三个冗余ACK之前，只要超时器还未超时，发送方会等待超时器到时再重发发送此报文段或者接收到了该报文段下一个报文段的ACK确认，那么发送方会立即发送下一个报文段，并启动超时器。
· · 流量控制：
· · TCP为它的应用程序提供了流量控制服务以消除发送方使接收方缓存溢出的可能性。流量控制是一个速度匹配服务，即发送方的发送速率与接受方应用程序的读取速率相匹配。
· · TCP还存在流量控制，指在链路中传输的数据发生拥塞的情况。
· · · 流量控制实现机制：
· · · 定义术语：
LastByteRead：接收主机上的应用进程
从缓存读取的数据流的最后一个字节的编号；
LastByteRcvd：从网络中到达的并且已
放入接收主机接收缓存中的数据流的最后一个
字节编号。
RcvBuffer：用于表示接收主机为TCP连接
提供的接收缓存的大小，由socket选项设置。
rwnd：发送方维护的一个接收窗口的变量
来提供流量控制。接收窗口用于给发送方一个
指示——该接收方还有多少可用的缓存空间。
TCP不允许已分配的缓存溢出，所以下式
必须成立：LastByteRcvd - LastByteRead <= RcvBuffer
接收窗口用根据缓存可用该空间的数量来
设置：rwnd = RcvBuffer - [LastByteRcvd - LastByteRead]
· · · 假设有两个主机A、B，主机B通过把当前的rwnd值放入它发给主机A的报文段接收窗口字段中，从通知了主机A它在该连接的缓存中还有多少可用空间。
· · · 最初，主机B设定rwnd=RcvBuffer；在持续连接阶段，主机B必须维护与连接有关的变量。
· · · 主机A必须轮流追踪LastByteSent和LastByteAcked这两个变量，两者这差为主机A发送到连接中但未被确认的数据量。主机A通过将未确认的数据量控制在rwnd内，就可以保证主机A不会使主机B的接收缓存溢出。
· · · 主机A在该连接的整个生命周期需保证：LastByteSent - LastByteAcked <=rwnd。
· · · TCP仅当在它由数据或有确认（ACK）要发送时，才会发送报文段给其它主机。
· · · TCP规范要求：当主机B的接收窗口为0时，主机A继续发送只有一个字节数据的报文段。
· · TCP连接管理
· · · 三次握手步骤：
· · · 第一步，客户端的TCP首先向服务器端的TCP发起一个特殊的TCP报文段（不含应用层数据，但SYN段置为1，称为SYN报文段）。另外，客户端会随机地选择一个初始序号（client_isn），并将此序号放在SYN包报文段中的序号字段。
· · · 第二步，一旦包含TCP SYN报文段的IP数据到达服务器主机，服务器会从该数据中提取出TCP SYN报文段，为该TCP连接分配TCP缓存和变量，并向客户端发送允许连接的SYN报文段，并将该报文段的确认号置为client_isn+1，最后选择自己的初始序号（server_isn）放于报文段首部的序号字段。该报文段有时被称为SYNACK报文段。
· · · 第三步，当客户端收到SYNACK后，客户也要给该连接分配缓存和变量。则再向服务器发送一个报文段，进行对服务器的允许连接的报文段进行了确认（将server_isn+1放于确认号字段，将SYN置为0），此报文段负载可以携带应用数据。
· · · 图示：
· · · 连接关闭：
· · · 如果客户端想要关闭连接，首先发出一个关闭连接命令，这会引起客户TCP向服务器进程发起一个特殊的TCP报文段（将FIN字段置为1），当服务端收到该报文段后，向发送方返回一个确认报文，然后服务器发送它自己的终止报文段（FIN置为1），最后该客户对这个服务器的终止报文进行确认。这时，两台主机用于该连接的所有资源会被释放。
· · · 图示：
· · · 正常情况下客户端的TCP状态变迁：
· · · 正常情况下服务器的TCP状态变迁：
· · · 返回RST报文段的情况：
· · · 假如一台主机接受了具有目的端口80的一个TCP SYN分组，但该主机在端口80不接受连接（即报文段的端口号或源IP地址与该主机上进行中的套接字都不匹配），则该主机会向源主机发送一个特殊重置报文段（RST标志位置为1），以此表示接收到的报文段中的套接字不存在。
· · 拥塞控制原理：
· · 当网络变得拥塞时由于路由器缓存溢出，从而导致丢包现象。
· · · 拥塞原因：
· · · · 两台发送方和一台具有无穷大缓存的路由器
· · · · 两台主机各自有一条连接，这两条连接共享一台路由器，共享链路的容量为R，则A与B分别占据R/2的带宽。
发送速率如下图：
当发送速率在0~R/2之间时，接收方的吞吐量等于发送方的发送速率；存在吞吐上限R/2，这个吞吐上限是由两条连接之间共享链路容量造成的，链路完全不能以超过R/2的稳定状态速率向接收方交付分组。
· · · 平均延时如下图：
当发送速率超过R/2时，路由器的平均排队分组数就会无限增长，源与目的地之间的平均延时也会变成无穷大。
· · · · 所以在这种情况下，网络拥塞的代价是分组经历了巨大的排队延时，特别是当分组的到达速率接近链路容量时。
· · · · 两个发送方和一台具有有限缓存的路由器。
· · · · 假设，分组到达一个已满的缓存时会被丢弃，每条链路都是可靠的，一个包含有运输层报文的分组在路由器中被丢弃，那么它最终会被发送方重发。
· · · · 仅当缓存空闲时才会发送分组，此时发送速率相等。当分组被重传时，初始数据占一部分传输速率，重传的数据占一部分速率，导致数据被交付给接收方的速率降低（为初始数据传输速率）。所以这种情况下网路拥塞的代价是，发送方必须执行重传以补偿因为缓存溢出而丢失的分组。
· · · · 还有一种情况是，发送方也许会提前发生超时并重传在队列中已被推迟但还未丢失的分组。所以这种情况下，路由器会接收到还未传输的副本，导致可用数据的传输速率下降。这种情况的代价是发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本。
· · · · 四个发送方和具有有限缓存的多台路由器及多跳路径
· · · · 假设每台主机都采用超时重传机制实现可靠数据传输服务。
这种情况下的路由器缓存溢出很少见，吞吐量大致接近供给载荷。因为A-C流量和B-D流量在路由器R2上必须为有限缓存空间而竞争，所以当来自B-D连接的供给载荷越来越大时，A-C连接上成功通过R2（即由于缓存溢出而未被丢失）的流量会越来越小。在极限情况下，当供给载荷趋近于无穷大时，R2的空间缓存会立即被B-D连接的分组占满，因而A-C连接在R2上的吞吐量趋近于0。
· · · · 这种情况下的代价是，当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终会被浪费。
· · · 拥塞控制方法：
· · · 端到端拥塞控制：
在这种控制方式中，网络层没有为运输层拥塞控制提供显示的支持，端系统通过对网络行为（分组丢失和延时）的观察来判断（TCP使用这种方法）。如：TCP报文段的丢失（超时或3次冗余确认而得知）被认为是网络拥塞的现象，TCP会相应地减少其窗口长度。
· · · 网络辅助的拥塞控制：
· · · 这种方法下，网络层构件（路由器）向发送方提供有关网络中拥塞状态的显示反馈信息。如ATM ABR拥塞控制形式中，允许路由器显示地通知发送方，告知路由器能在输出链路上支持的传输速率。
· · · 网络辅助的拥塞控制有两种方法，一种是阻塞分组，由路由器发送给发送方，表示拥塞状态，另一种是路由器标记或更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生。一旦收到一个标记的分组后，接收方就会向发送方通知该网络拥塞指示。
· · · ATM ABR例子:
· · · ATM用信元表示分组，交换机表示路由器。
· · · 对于ATM ABR服务，数据信元从源主机经一系列分组交换机传输到目的主机。这些数据信元中有资源管理信元（RM信元），这些RM信元可被用来在主机和交换机之间传递与拥塞相关的信息。当一个RM信元到达目的地时，它被调转方向并向发送机发送（可能在目的地修改了内容）。
· · · ABR提供三种机制用于从交换机向接收方发送与拥塞相关的信令信息。
· · · · EFCI比特：
· · · · 每个数据信元都包含1bit的显示转发拥塞指示（Explicit Forward Congestion Indication，EFCI）比特。拥塞的网络交换机可以把一个数据信元中的EFCI比特设置为1来向目的主机发送网络已经拥塞的指令。当一个RM信元到达目的地并且目的地最近收到了多个EFCI被置为1的数据信元时，目的地就会将RM信元的拥塞指示比特（CI比特）置为1，并将RM信元返回给发送方。这时，发送方便能在网络交换机拥塞时得到通知。
· · · · CI、NI比特：
· · · · 默认每32个数据信元中有一个RM信元。这些RM信元中有一个拥塞指示比特（CI）和无增长比特（No Increase，NI），这两个比特可以被一台拥塞的交换机设置，当轻微拥塞时，RM信元中的NI比特置为1，在严重拥塞时把CI比特置为1。当主机收到一个RM信元时，它会返回该RM信元给发送方（保持CI、NI不变）。
· · · · ER的设置：
· · · · 每一个RM信元还包括一个两字节的显示速率（Explicit Rate）字段，一个拥塞的交换机也许会降低经过的RM信元中的ER字段所包含的值，以这种方式，ER字段将会被设置为在源目的地的路径上所有交换机最小可支持速率。
· · · 一个ATM ABR源以返回RM信元中的CI、NI、ER值为函数，来调整发送信元的速率。
· · TCP拥塞控制：
· · TCP使用的是端到端拥塞控制，因为IP层不向端系统提供显示的网络拥塞反馈。所以TCP发送方需要感知网络拥塞程度去限制连接发送流量的速率。
· · · TCP是如何限制发送流量的。
· · · 运行在发送方的TCP拥塞机制跟踪一个额外的变量——拥塞窗口（cwnd），它对一个TCP发送方能向网络中发送流量的速率进行了限制。每个发送方的发送速率大概是cwnd/RTT 字节/秒。
· · · TCP是如何感知它与目的地之间的路径出现了拥塞的。
· · · 由于是端到端的拥塞控制，不能接受来自路由器的信元报文，所以我们将一个TCP的丢包事件定义为：要么出现超时，要么收到来自接收方的3个冗余ACK。
· · · 因为当路由器的缓存溢出时，会导致一个数据报被丢弃，丢弃的数据报会引起发送方的丢包事件，这时发送方便会认为在发送方到接收方的路径上出现了拥塞的指示。
· · · 在没有出现丢包事件时，TCP会使用确认来增加窗口的长度（即传输速率）。如果确认是以相当慢的速率到达时，拥塞窗口会以想当慢的速率增加；如果确认以高速率到达时，则该拥塞窗口将迅速地增大。因此TCP使用确认来触发增大它的拥塞窗口长度，TCP被认为是自计时的。
· · · TCP发送方怎么确认它应当发送的速率。
· · · TCP根据一些指导性原则来判断拥塞状态。
· · · 一个丢失的报文段（超时或者收到三个冗余ACK）代表拥塞，此时应当降低TCP发送方的速率（减少它的拥塞窗口长度）。
· · · 一个确认报文段指示该网络正在向接收方交付发送方的报文段（也就是说此时网络还没有拥塞），此时当先前未确认报文段的确认到达时，能够增加发送方的速率（增加拥塞窗口长度）。
· · · 带宽检测：由于ACK和丢包事件充当了隐式信号，每个TCP发送方根据异步于其他TCP发送方的本地信息而行动。TCP调节其传输速率的策略是增加其速率响应到达的ACK（一定是确认ACK），当出现丢包事件，减少传输速率。
· · · TCP拥塞控制算法：
· · · 主要包括：慢启动、拥塞避免、快速恢复。慢启动和拥塞避免是TCP的强制部分，差异在于对收到的ACK做出反应时增加cwnd长度的方式（慢启动能更快的增加cwnd长度），快速恢复对于TCP是非必需的。
· · · · 慢启动：
· · · · 当一条TCP连接初次建立时，cwnd被赋予一个MSS的较小值，此时的发送速率为MSS/RTT。
· · · · 在慢启动状态，每一个传输的报文被首次确认时就增加一个MSS。所以当第一次发送出去报文段后并收到确认后，TCP发送方会将cwnd增加到2个MSS长度，然后在发送两个报文段并收到确认后，cwnd会增加到4个MSS长度……因此，TCP发送速率虽然起始慢，但在慢启动阶段以指数增长。
· · · · 结束慢启动状态的条件：
1.如果存在一个由超时引起的丢包事件，TCP
发送方会将cwnd设置为1并重新开始慢启动过程，
除此之外，TCP发送方还会将第二个状态变量的
值ssthresh置为拥塞窗口的一半，ssthresh与
慢启动的第二种结束方式、进入拥塞避免状态有关。
2.当检测到拥塞时ssthresh设为cwnd的值的
一半，并当到达或超过ssthresh时，此时会结束
慢启动并进入拥塞避免模式。
3.当检查到3个冗余ACK的丢包事件时，TCP会
执行快速重传，并进入快速恢复状态。
· · · · 拥塞避免：
1.一旦进入拥塞避免状态，那么TCP将在每经历
一个RTT，就将cwnd的值增加一个MSS。实现这种
思路的通用方法是TCP无论何时到达的一个新确
认，就将cwnd增加一个MSS/cwnd的字节。
2.如何结束拥塞避免的线性增长（每RTT 1MSS），
当出现超时引起的丢包事件时，cwnd被置位1个
MSS，ssthresh的值被更新为cwnd值的一半，进
入慢启动状态。如果丢包事件由三个冗余的ACK
引起（说明拥塞不是很严重），TCP会将ssthresh
记录为cwnd值的一半，将cwnd的值置为ssthresh+3
（为了测量更精确，根据已收到的三个冗余ACK
也会加上三个MSS），然后进入快速恢复状态。
· · · · 快速恢复：
· · · · 在这种状态下，对于引起TCP进入快速恢复状态的缺失报文段，对于收到的每个冗余的ACK，cwnd的值增加一个MSS。最终，当缺失报文段的ACK到达时，TCP在降低cwnd后进入拥塞避免状态。如果出现超时事件，TCP会采取与慢启动中超时相同的动作，然后进入慢启动；当丢包事件出现时，cwnd的值被设置为1个MSS，并且ssthresh的值设置为cwnd值的一半。
· · · · TCP拥塞控制常常称为加性增、乘性减（Additive-Increase，Multiplicative-Decrease，AIMD）拥塞控制方式：
· · · · AIMD拥塞控制常常表现如锯齿形状的传输速率。
· · · · 公平性：
· · · · 假设每条连接都在传输一个大文件，而且无UDP流量通过该段瓶颈链路，每条连接的平均传输速率接近于R/K（K条连接，R为瓶颈链路的带宽），即每条连接都得到相同份额的链路带宽，则认为该拥塞机制是公平的。
· · · · 首先TCP拥塞机制是公平的，我们举下面这个例子：两条TCP连接共享一段传输速率为R的链路，两条连接具有相同的条件（拥塞窗口长度、MSS、RTT），忽略两条连接的慢启动状态，并假设一直按照AIMD模式运行，则最终两条链路的传输速率一定会维持在R/2。如图：
假设最初A，连接1的吞吐量大于R/2，连接2的吞吐量小于R/2，随着时间的推移，两条连接都会经历拥塞、空闲、再拥塞……的状态，因为两条连接都忽略了慢启动状态，直接进入拥塞避免状态，所以在经历第一次拥塞时，位于状态B（呈线性增长），这时会降低传输速率，就会降落到C点，为什么是C点呢？因为当TCP连接感知到了链路拥塞时，会将各自的拥塞窗口值cwnd降为一半，再重新慢慢增长，在B点降为一半，也就是横坐标和纵坐标都降为一半，那么就是C点了，经过多次这样的拥塞状态，最终一定会到达平等宽带共享状态，也就是两条传输速率都到达R/2。
· 其他协议
· · 数据报拥塞控制协议（Datagram Congestion Control Protocol，DCCP）
· · 提供了一种低开销、面向报文、类似于UDP的不可靠服务，但是具有应用程序可选择的拥塞控制形式，与TCP相兼容。
· · 流控制传输协议（Stream Control Transmission Protocol，SCTP）
· · 是一种可靠的、面向报文的协议，该协议允许几个不同的应用层次的‘流’复用到单个SCTP连接上。不同流之间的丢失不影响其他流。
· · TCP友好速率控制（TCP-Friendly Rate Control，TFRC）协议
· · 是一种拥塞控制协议而不是一种功能齐全的运输层协议，定义了一种拥塞控制机制，该机制能被用于DCCP等其他运输层协议，TFRC的目标是平滑在TCP拥塞控制中的“锯齿”行为，同时维护一种长期的发送速率，此速率合理地接近TCP的速率。