计算机网络复习——第三章：传输层

一、运输服务和协议

※运输层的传输单位：报文段


TCP（传输控制协议）：为应用程序提供一种可靠的、面向连接的服务。
UDP（用户数据报协议）：为应用程序提供一种不可靠、无连接的服务。
TCP还提供了几种附加服务：可靠数据传输、拥塞控制

1、运输层分组：称为报文段！UDP、TCP中的分组统称为报文段

※：将主机间交付扩展到进程间交付被称为运输层的多路复用与多路分解
说明：
即：将由网络层提供的主机到主机交付服务延申到为运行在主机上的应用程序提供进程到进程的交付服务

一个进程有一个或多个套接字（socket），它相当于从网络向进程传递数据和从进程向网络传递数据的门户。

※：每个套接字都有唯一的标识符，标识符的格式取决于它是UDP还是TCP套接字

2、（复用和分用）
多路分用： 将运输层报文段中的数据交付到正确的套接字的工作
即：分发给不同的套接字
多路复用： 在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息（这将在以后用于分解）从而生成报文段，然后将报文段传递到网络层，所有的这些工作
即：从不同套接字处收集数据库

3、网络环境中的进程标识




4、分用如何工作？


运输层分组：称为 报文段 ！
UDP、TCP中的分组统称为报文段

说明：
1、如果两个UDP报文段有不同的源IP地址和/或源端口号，但具有相同的目的IP地址和目的端口号，那么这两个报文段将通过相同的目的套接字被定向（分用）到相同的目的进程，即只要目的地相同，就会通过相同的套接字进行分用
2、源端口号的用途：在A到B的报文段中，源端口号用作“返回地址”的一部分，即若B需要回发一个报文段给A时，B到A的报文段中的目的端口号便从A到B的报文段中的源端口号中取值。（完整的返回地址是A的IP地址和源端口号）
说明：
与UDP不同的是：两个具有不同源IP地址或源端口号的到达TCP报文段将被定向到两个不同的套接字，尽管它们的目的IP地址或目的端口号相同！

5、Web服务器与TCP
一台Web服务器的主机，在端口80上运行，当客户（浏览器）向该服务器发送报文段时，所有报文段的目的端口都将为80
特别是：初始连接建立报文段和承载HTTP请求的报文段都有80的目的端口！

※：连接套接字与进程之间并非总是有着一一对应的关系！
当今高性能Web服务器通常只有一个进程，但为每个新的客户连接创建一个具有新连接套接字的新线程！

二、无连接运输：UDP

1、
说明：
1、UDP只做了运输协议能够做的最少工作，除了复用、分用功能，及少量的差错检测外，它几乎没有对IP增加别的东西。应用程序差不多就是直接和IP打交道。
2、使用UDP，在运输层的发送方和接收方实体之间没有握手，因此UDP被称为无连接的。
3、DNS使用UDP的应用层协议：DNS应用程序想要进行一次查询时，它构造一个DNS查询报文并将其交给UDP。
4、UDP协议只在端系统中运行！

2、
大致过程： UDP从应用进程得到数据，附加上多路复用/分用的源和目的端口号字段，以及其他的小字段，然后将形成的报文段交给网络层。网络层将该报文段封装到一个IP数据报中，然后尽力而为地尝试将此报文段交付给接收主机。如果该报文段到达接收主机，UDP使用目的端口号将报文段中的数据交付给正确的应用进程（套接字）。

选用UDP的原因：
①采用UDP时，只要应用进程将数据传递给UDP，它就会把此数据打包进UDP报文段并立即将其传递给网络层。
②无须连接建立，UDP不需要任何准备即可进行数据传输，因此UDP不会引入建立连接的时延，这也是DNS选用UDP的原因，速度快！
③无连接状态，TCP需要在端系统中维护连接状态（接收、发送缓存、拥塞控制参数以及序号与确认号的参数），UDP不需要！
④分组首部开销小。 每个TCP报文段都有20字节的首部开销，但UDP仅有8字节的开销。

UDP用于承载网络管理数据（后面第五章会讲）

3、UDP检验和：提供差错检测功能，用于确定当UDP报文段从源到达目的地移动时，其中的比特是否发生了改变。

易错：有回卷时该如何处理！最后结果要取反码才是检验和！

说明：
1、如果端到端数据传输服务要提供差错检测，UDP就必须在端到端基础上在运输层提供差错检测！， 即：端到端原则
2、虽然UDP提供差错检测，但它对差错恢复无能为力！

三、可靠数据传输原理

借助于可靠信道，传输数据比特就不会受到损坏（由0变为1或相反）或丢失，而且所有数据都是按照其发送顺序进行交付。这恰好就是TCP向调用它的因特网应用所提供的服务模型。

※：我们仅考虑单项数据传输（udt）的情况！：即数据传输时是从发送端到接收端的！
说明：
1、rdt_send()：上层（应用层调用rdt_send）可以调用数据传输协议的发送方，它将发送的数据交付给位于接收方的较高层
_send()：指示哪个的发送端正在被调用，udt_send()即：单项数据传输的发送端正在被调用。
2、rdt_rcv()：在接收端，当分组从信道的接收端到达时将调用rdt_rcv()。
3、deliver_data()：rdt协议（接收方）想向较高层交付数据时，将通过调用deliver_data()来完成。

可靠数据传输协议（rdt）：实现这种服务抽象
▲：可靠数据传输协议的下层协议也许是不可靠的！（例如：TCP是在不可靠的（IP）端到端网络层之上实现的可靠数据传输协议）

1、经完全可靠信道的可靠数据传输：rdt1.0

即：先考虑最简单的情况，即底层信道是完全可靠的！

2、经具有比特差错信道的可靠数据传输：rdt2.0

说明：
1、类比于：口述协议中的肯定确认（OK），否定确认（请重复一遍）
也被称为自动重传请求协议（ARQ）
2、ARQ协议需要另外三种协议功能来处理存在的比特差错的情况：

• 差错检测：接收方可以检测到何时出现了比特差错，例如：UDP校验和（第五章还有）
• 接收方反馈：让接收方提供明确的反馈信息给发送方，ACK（肯定确认）、NAK（否定确认）
• 重传：接收方收到有差错的分组时，发送方将重传该分组文

make_pkt(data)：（发送端）产生一个包含该数据的分组
extract(packet,data)：（接收端）从分组中取出数据

说明：
1、发送方将不会发送一块新数据，除非发送方确信接收方已正确接收当前分组，这种行为被称为：停等协议
2、rdt1.0 rdt2.0，接收方的FSM仍然只有单一状态，当分组到达时，接收方要么回答一个ACK要么回答一个NAK，这取决于收到的分组是否受损！

rdt2.0协议的致命缺陷：没有考虑到ACK或NAK分组受损的可能性！

说明：
1、不断重复：困难重重
2、增加校验：增加足够多的检验和比特，使发送方可以检测差错，还能回复差错
3、在发送方到接收方的信道中引入冗余分组，即当发送方收到含糊不清的ACK或NAK分组时，只需重传当前数据分组。困难在于：接收方不知道它上次所发送的ACK或NAK是否被发送方正确地收到 ，因此它无法事先知道接收到的分组是新的还是一次重传！

---

解决方法：
在数据分组中添加一新字段，让发送方对其数据分组编号，即将发送数据分组的序号放在该字段。于是！接收方只需检查序号即可确定收到的分组是否为一次重传。此时仍采用停等协议。

3、经具有比特差错的丢包信道的可靠数据传输：rdt3.0

发送方需要等待多久才能确定已丢失了某些东西呢？
解决方法：
发送方明智地选择一个时间值，以判定可能发生了丢包（尽管不能确保），如果在这个时间内没有收到ACK则重传该分组。

注意：如果一个分组经历了一个特别大的时延，发送方可能会重传该分组，即使该数据分组及其ACK都没有丢失，这就在发送方到接收方的信道中引入了冗余数据分组的可能性。

说明：
从发送方的观点来看，重传是一种万能灵药，发送方不知道是一个数据分组丢失、还是一个ACK丢失、或者只是该分组或ACK过度延时，在这些情况下，动作是同样的：重传！

为了实现基于时间的重传机制，需要一个倒计数定时器，在一个给定的时间量过期后，可中断发送方。

发送方：①：每次发送一个分组（包括第一次和重传分组）时，便启动一个定时器 ②：响应定时器中断（采取适当的动作） ③：终止定时器

4、流水线可靠数据传输协议

因为RDT3.0采用的是停等协议，会增加时延，所以将不以停等方式运行，允许发送方发送多个分组而无需等待确认！

因为许多从发送方 向 接收方输送的分组可以被看成是填充到一条流水线中，故这种技术被称为流水线技术

解决流水线差错恢复的方法：GBN与SR！！！！！

1）回退N帧法：GBN

随着协议的运行，该窗口在序号空间向前滑动，因此GBN协议也称为滑动窗口协议
说明：
GBN发送方必须响应三种类型的事件：
1、上层的调用。 当上层调用rdt_send()时，即需要发送方发数据了，发送方先检查发送窗口是否已满，若未满，则产生一个分组并将其发送；若已满，发送方把数据返回给上层，让上层过会再试，更可能缓存（并不立刻发送）这些数据，或是使用同步机制（信号量）允许上层在仅当窗口不满时才调用rdt_send()。

2、收到一个ACK。 对序号为n的分组的确认采用 累计确认（累计ACK） 的方式，表明接收方已正确接收到序号为n的以前且包括n以内的所有分组。

3、超时事件。定时器将再次用于恢复数据或确认分组的丢失。如果出现超时：发送方重传所有已发送但还未被确认过的分组
仅使用一个定时器，被当作是最早的已发送但未被确认的分组所使用的定时器

GBN接收方动作：
1、一个序号为n的分组被正确且按序接收到，则接收方为分组n发送一个ACK，并将该分组中的数据部分交付到上层。在所有其他情况下，接收方丢弃该分组，并为最近按序接收的分组重新发送ACK。
注意到：如果分组k已接收并交付，则所有序号比k小的分组也已经交付
2、接收方丢弃所有失序分组！！！：不缓存，没有接收缓冲区！！！

2）选择性重传：发送方仅重传那些它怀疑在接收方出错（丢失或受损）的分组而避免了不必要的重传。

说明：
1、
SR中失序的分组将被缓存直到所有丢失分组（即序号更小的分组）皆被收到为止（要一直等着丢失分组到达才行），这时可以将一批分组按序交付给上层。（超时重传）
2、
SR中接收方确认一个正确接受的分组而不管它是否按序，但是！在交付给上层时还是按序的！

不同：
1、GBN接收方需要正确接收分组且按序，但SR接收方不管其是否按序，失序的分组将被缓存直到所有丢失分组皆被收到为止。这时才可以将一批分组按序交付给上层。
2、GBN中只有一个计时器，SR中每个分组一个。
3、GBN直接抛弃失序分组，SR则将他们缓存下来。
4、GBN中只有发送方有滑动窗口，而SR中发送方、接收方都有滑动窗口，接收方和发送方的窗口并不总是一致。

GBN SR 区别！

在GBN中确认值(ACK) 是累计的，它定义了下一个希望接收的分组序号，同时也证实了此前所有的分组都已经被完好的接收了。在SR中,确认号(ACK)只定义完好接收的那一个分组的序号，并不反馈任何其他分组的信息。

即所谓：GBN累计确认，所有有很多冗余ACK，SR选择重传，每次只选择怀疑是有损坏的重传，不是累计的！

对SR而言：

四、面向连接的传输：TCP

1、面向连接： 一个应用程序可以开始向另一个应用程序发送数据之前，这两个进程必须先互相 “握手”，即它们必须互相发送某些预备报文段，以建立确保数据传输的参数。

2、TCP连接是一条逻辑链接，其共同状态仅保留在两个通信端系统的TCP程序中，TCP协议只在端系统中运行，而不在中间的网络元素（路由器和链路层交换机）中运行，所以中间的网络元素不会维持TCP连接状态。中间路由器看到的是数据报，而不是连接。

3、TCP是因特网运输层的面向连接的可靠的运输协议，它依赖于上面讲的许多基本原理，包括：差错检测、重传、累积确认、定时器、以及用于序号和确认号的首部字段。

注意：别忘了套接字（socke）的作用！第二章应用层-套接字编程

说明：
1、点对点：在进程A、B之间建立一条TCP连接，那么应用层数据可以从进程B流向进程A，同时，也从进程A流向进程B。即：在单个发送方与单个接收方之间的连接。（两台主机是一对）
2、全双工数据：即双向数据流，在发送数据的同时，还同时接收数据。

TCP连接的建立：
1、发起连接的这个进程被称为客户进程，而另一个进程被称为服务器进程，客户应用进程要先通知客户运输层，它想与服务器上的一个进程建立一条连接。
2、客户首先发送一个特殊的TCP报文段，服务器用一个特殊的TCP报文段来响应，最后，客户再用第三个特殊报文段作为响应，前两个报文段不承载“有效载荷”，即不包含应用层数据，第三个报文段可以承载有效载荷。由于两台主机之间发送了三个报文段，所以这种建立也叫三次握手。
3、建立TCP连接后，两个应用进程之间就可以相互发送数据了。客户进程通过套接字（该进程之门）传递数据流，数据一旦通过该门，它就由客户中运行的TCP控制了，TCP将这些数据引导到该连接的发送缓存里。之后TCP就会不时从发送缓存里取出一块数据，并将数据传递给网络层。
4、TCP可以从缓存中取出并放入报文段中的数据数量受限于最大报文段长度（MSS），MSS由本地发送主机发送的最大链路层帧长度，即（最大传输单元（MTU）） 来设置。
※：MSS是指报文段里应用层数据的最大长度，不是包括首部的TCP报文段！
5、TCP为每块客户数据配上一个TCP首部，从而形成多个TCP报文段（TCP segment），这些报文段被下传给网络层，网络层将其分别封装在网络层IP数据报中。然后这些IP数据报被发送到网络中。
6、接收到一个报文段后，该报文段的数据就被放入该TCP连接的接收缓存。

TCP报文段

答案：
1、主机A为了重新构建主机B的数据流，仍在等待字节536（和其后的字节），因此，A到B的下一个报文段将在确认号字段中包含536，因为TCP只确认该流中至第一个丢失字节为止的字节，所以TCP被称为提供：累积确认（累积ACK）。
2、处理失序报文： TCP自己没有明确规定，需要TCP编程人员去处理。有两个基本选择：①接收方立即丢弃失序报文段②接收方保留失序的字节，并等待缺少的字节以填补该间隔。（方法二是实践中采用的方法）

说明： 一条TCP连接的双方均可随机地选择初始序号。

说明： TCP首部的长度是可变的！

说明：
1、报文段的序号： 该报文段数据字段首字节的序号。
2、报文段的确认号： 该主机正在等待的数据的下一个字节序号。
图中：
主机A：（客户）发送的第一个报文段的序号为42，确认号为79，即期待（等待）服务器发送给客户字节79。
主机B：（服务器）
有两个目的：
1）首先为该服务器收到的数据提供一个确认：在确认号中填入43（42+1），服务器告诉客户：它已经成功地接收到字节42及以前的所有字节，现在正等待字节43的出现。
2）回显字符C，然后发送给主机A：报文段序号为79，因为主机A期待收到它。
注意： 对客户到服务器的数据的确认被装载在一个承载服务器到客户的数据的报文段中，这种确认被称为是捎带在服务器到客户的数据报文段中的。（就是被数据报文段顺便带过去的）

允许报文段里没有数据，但仍有序号，这是因为TCP存在序号字段，报文段需要填入某个序号。

1、TCP如何实现可靠数据传输：

IP服务是不可靠的，IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性。对于IP服务，数据报能够溢出路由器缓存而永远不能到达目的地，数据报也可能是乱序到达，而且数据报中的比特可能损坏（由0变为1或者相反）。
由于运输层报文段是被IP数据报携带着在网络中传输的，所以运输层的报文段也会遇到这些问题。

TCP在IP不可靠的尽力而为服务上创建了一种可靠数据传输服务，确保一个进程从其接收缓存中读出的数据流是无损坏、无间隙、非冗余和按序的数据流。即：该字节流与连接的另一方端系统发送出的字节流是完全相同的。

说明：
1、仅使用单一的重传定时器，即使有多个已发送但还未被确认的报文段。
2、TCP发送方有3个与发送和重传有关的主要事件：从上层应用程序接收数据、定时器超时、收到ACK。

• 第一个事件：TCP从应用程序接收数据，将数据封装在一个报文段中，并把该报文段交给IP。（每一个报文段都包含一个序号：该报文段第一个数据字节的字节流编号），如果定时器还是空闲的，TCP就启动该定时器。
• 第二个事件：超时，TCP重传引起超时的报文段，然后重启定时器。
• 第三个事件：TCP采用累计确认。
  
  
  
  ※：超时重传存在的问题：超时周期可能相对较长，当一个报文段丢失时，这种长超时周期迫使发送方延迟重传丢失的分组，因而增加了端到端时延。
  
  快速重传：采用冗余ACK，而不是累计ACK！
  
  
  
  
  
  

2、是回退N步还是选择重传？

下面来讨论一下TCP差错恢复机制：
TCP使用选择确认，它允许TCP接收方有选择地确认失序报文段，而不是累积地确认最后一个正确接收的有序报文段。是GBN、SR协议的混合体。

TCP既有累计确认 又有选择确认！

3、流量控制：

TCP为它的应用程序提供了 流量控制服务(flow-control service)以消除发送方使接收方缓存溢出的可能性。 流量控制因此是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读取速率相匹配。

TCP发送方也可能因为IP网络的拥塞而被遏制；这种形式的发送方的控制被称为拥塞控制(congestion control) （将在后面进行讲解）


TCP通过让发送方维护一个称为接收窗口(receive window)的变量来提供流量控制。通俗地说，接收窗口用于给发送方一个指示——该接收方还有多少可用的缓存空间。因为TCP是全双工通信，在连接两端的发送方都各自维护一个接收窗口。

• LastByteRead： 主机B上的应用进程从缓存读出的数据流的最后一个字节的编号。
• LastByteRcvd： 从网络中到达的并且已放入主机B接收缓存中的数据流的最后一个 字节的编号。

主机A轮流跟踪两个变量，LastByteSent和LastByteAcked,这两个变量的意义很明显。注意到这两个变量之间的 差LastByteSent - LastByteAcked,就是主机A发送到连接中但未被确认的数据量。 通过将未确认的数据量控制在值rwnd以内，就可以保证主机A不会使 主机B的接收缓存溢出。

说明：流量控制通过（接收）窗口实现，由发送方维护！两边各有一个接收窗口，因为它们既可以是接收方又可以变为发送方！

4、TCP连接管理：

我们更为仔细地观察如何建立和拆除一条TCP连接 ！

TCP的连接步骤：

• 第一步：客户端的TCP首先向服务器端的TCP发送一个特殊的TCP报文段。该报文段中不包含应用层数据。但是在报文段的首部中的一个标志位（即SYN比特）被置为1。因此，这个特殊报文段被称为SYN报文段。另外，客户会随机地选择一个初始序号（client_isn）,并将此编号放置于该起始的TCP SYN 报文段的序号字段中。该报文段会被封装在一个IP数据报中，并发送给服务器。
• 第二步：一旦包含TCP SYN报文段的IP数据报到达服务器主机（假定它的确到达了！），服务器会从该数据报中提取出TCP SYN报文段，为该TCP连接分配TCP缓存和变量，并向该客户TCP发送允许连接的报文段。这个允许连接的报文段也不包含应用层数据。但是，在报文段的首部却包含3个重要的信息。首先，SYN比特被置为1。其次，该TCP报文段首部的确认号字段被置为client_isn + 1（代表服务器已经收到了client_isn及之前序号的数据，现在期望收到client_isn+1的数据）。最后，服务器选择自己的初始序号 （server_isn）,并将其放置到TCP报文段首部的序号字段中。这个允许连接的报文段实际上表明了：“我收到了你发起建立连接的SYN分组，该分组带有初始序号 client_isn，我同意建立该连接。我自己的初始序号是server_isn， 该允许连接的报文段被称为SYNACK报文段（SYNACK segment）。
• 第三步：在收到SYNACK报文段后，客户也要给该连接分配缓存和变量。客户主机则向服务器发送另外一个报文段；这最后一个报文段对服务器的允许连接的报文段进行了确认（该客户通过将值server_isn + 1放置到TCP报文段首部的确认字段中来完成此项工作）。因为连接已经建立了，所以该SYN比特被置为0。该三次握手的第三个阶段可以在报文段负载中携带客户到服务器的数据。
  
  
  
  
  三次握手！

说明：既有冗余ACK，也有累计ack（确认号）

当连接结束后，主机中的“资源”（即缓存和变量）将被释放。

关闭连接的步骤：

客户应用进程发出一个关闭连接命令。这会引起客户TCP向服务器进程发送一个特殊的TCP报文段。这个特殊的报文段让其首部中的一个标志位即FIN比特被设置为1。当服务器接收到该报文段后，就向发送方回送一个确认报文段。然后，服务器发送它自己的终止报文段，其FIN比特被置为1。最后，该客户对这个服务器的终止报文段进行确认。此时，在两台主机上用于该连接的所有资源都被释放了。

5、拥塞控制的原理：

流量控制和拥塞控制不一样！

开环控制：在设计网络时，事先把有关拥塞的因素考虑周到。
闭环控制：即运行的同时检测拥塞，如果遇到了拥塞就丢到一个地方处理。

6、TCP拥塞控制：

拥塞控制的方法！

说明：流量控制是发送方控制一个接收窗口，这里是发送方维持一个拥塞窗口！




注意：快重传与快恢复，快恢复时不一定发生了拥塞，所以不执行满开始，cwnd也不设置为1，而是慢开始门限的一半，然后执行拥塞避免算法（加性增）

慢启动与快恢复！什么时候用？

先是慢启动，cwnd到达ssthresh后，采用拥塞避免算法（加性增），
如果发生了丢包：cwnd置1，ssthresh减半，重新开始慢启动（没有发生丢包就继续采用拥塞避免）；
如果发生了3个冗余ACK（不一定产生拥塞）：cwnd=ssthresh/2，ssthresh减半，采用快恢复（此时cwnd=ssthresh，继续采用拥塞避免）。
说明：为什么cwnd>=ssthresh了，还是要采用拥塞避免呢？
因为超过了不代表发生了拥塞，只有当真正发生了拥塞时才做处理 （发生拥塞和发生冗余ACK处理方式不同！）