计算机网络（5）：运输层

这一章应该是整个计算机网络对我们来说最重要的，也是用的最多的一部分。

运输层协议

进程之间的通信

从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。
当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。

两个主机进行通信就是两个主机中的应用进程互相通信。
从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之间的通信。在一个主机中经常有多个应用进程同时分别和另一个主机中的多个应用进程通信。

运输层提供应用进程间的逻辑通信。
逻辑通信的意思是：运输层之间的通信好像是沿水平方向传送数据。但事实上这两个运输层之间并没有一条水平方向的物理连接。要传送的数据是沿着图中的虚线方向（经过多个层次）传送的。

网络层是为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。

运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等)，它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道，但这条逻辑通信信道对上层的表现却因运输层使用的不同协议而有很大的差别。
当运输层采用面向连接的TCP协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务)，但这种逻辑通信信道就相当于一条全双工的可靠信道。
但当运输层采用无连接的UDP协议时，这种逻辑通信信道仍然是一条不可靠信道。

运输层的两个主要协议

TCP/IP运输层的两个主要协议都是因特网的正式标准，即：
(1)用户数据报协议 UDP (User Datagram Protocol)；
(2)传输控制协议 TCP (Transmission Control Protocol)。

按照 OSI 的术语，两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元TPDU(Transport Protocol Data Unit)。但在TCP/IP体系中，则根据所使用的协议是TCP或UDP，分别称之为TCP报文段(segment)或UDP用户数据报。

UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到 UDP 报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下UDP却是一种最有效的工作方式。

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务。由于TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源。

运输层的端口

运输层的复用和分用功能也是类似的。
应用层所有的应用进程都可以通过运输层再传送到 IP 层，这就是复用。
运输层从 IP 层收到数据后必须交付给指明的应用进程。这就是分用。

协议端口号是在计算机网络中，用于标识不同网络服务或应用程序的逻辑通信端点。这些端口号通常与运输层协议（如TCP、UDP）关联，确保网络中的数据能够准确传递到特定的应用程序或服务。

这种在协议栈层间的抽象的协议端口是软件端口，和路由器或交换机上的硬件端口是完全不同 的。
硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。不同的系统具体实现端口的方法可以是不同的（取决于系统使用的操作系统)。

两个计算机中的进程要互相通信，不仅必须知道对方的地址（找到对方的计算机)，而且还要知道对方的端口号（找到对方计算机中的应用进程)。

运输层的端口号共分为两大类：
(1)服务器端使用的端口号
又分为两类，最重要的一类叫做熟知端口号(well-known port number)或系统端口号，数值为0~1023。这些数值可在网址www.iana.org 查到。IANA把这些端口号指派给了 TCP/IP 最重要的一些应用程序，让所有的用户都知道。当一种新的应用程序出现后，IANA必须为它指派一个熟知端口，否则因特网上的其他应用进程就无法和它进行通信。

另一类叫做登记端口号，数值为1024~49151。这类端口号是为没有熟知端口号的应用程序使用的。使用这类端口号必须在 IANA 按照规定的手续登记，以防止重复。

(2)客户端使用的端口号
数值为49152~65535。由于这类端口号仅在客户进程运行时才动态选择，因此又叫做短暂端口号。这类端口号是留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的端口号，因而可以把数据发送给客户进程。通信结束后，刚才已使用过的客户端口号就不复存在。这个端口号就可以供其他客户进程以后使用。

用户数据报协议 UDP

用户数据报协议 UDP 只在 IP 的数据报服务之上增加了复用和分用的功能以及差错检测的功能。
UDP的主要特点是：
(1)UDP是无连接的，即发送数据之前不需要建立连接（当然发送数据结束时也没有连接可释放)，因此减少了开销和发送数据之前的时延。
(2)UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表（这里面有许多参数)。
(3)UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给 IP 层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。

在接收方的UDP，对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付给上层的应用进程。也就是说，UDP一次交付一个完整的报文。因此，应用程序必须选择合适大小的报文。若报文太长，UDP 把它交给 IP 层后，IP层在传送时可能要进行分片，这会降低 IP 层的效率。反之，若报文太短，UDP 把它交给 IP 层后，会使IP数据报的首部的相对长度太大，这也降低了 IP 层的效率。

(1)UDP没有拥塞控制 ，因此网络出现的拥塞不会使源主机的发送速率降低。允许在网络发生拥塞时丢失一些数据，但却不允许数据有太大的时延。但是，不使用拥塞控制功能的 UD P有时可能会引起网络产生严重的拥塞问题。
(2)UDP支持一对一、一对多、多对一和多对多的交互通信。
(3)UDP的首部开销小 ，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

UDP 的首部格式

用户数据报 UDP 有两个字段：数据字段和首部字段。

首部字段很简单，只有8个字节，由四个字段组成，每个字段的长度都是两个字节。
各字段意义如下:
(1)源端口：源端口号。在需要对方回信时选用。不需要时可用全 0。
(2)目的端口：目的端口号。这在终点交付报文时必须要使用到。
(3)长度：UDP用户数据报的长度，其最小值是8（仅有首部)。
(4)检验和：检测UDP用户数据报在传输中是否有错。有错就丢弃。

当运输层从 IP 层收到 UDP 数据报时，就根据首部中的目的端口，把 UDP 数据报通过相应的端口，上交最后的应用进程。
如果接收方 UDP 发现收到的报文中的目的端口号不正确（即不存在对应于该端口号的应用进程)，就丢弃该报文，并由 ICMP 发送端口不可达差错报文给发送方。

UDP 用户数据报首部在计算检验和时，要在 UDP 用户数据报之前增加 12个 字节的伪首部。
所谓伪首部是因为这种伪首部并不是 UDP 用户数据报真正的首部。只是在计算检验和时，临时添加在 UDP 用户数据报前面，得到一个临时的 UDP 用户数据报。检验和就是按照这个临时的 UDP 用户数据报来计算的。伪首部既不向下传送也不向上递交，而仅仅是为了计算检验和。

UDP 计算检验和的方法和计算 IP 数据报首部检验和的方法相似，不同地方的是：IP 数据报的检验和只检验 IP 数据报的首部，但 UDP 的检验和是把首部和数据部分一起都检验。

在发送方，首先是先把全零放入检验和字段。再把伪首部以及 UDP 用户数据报看成是由许多 16 位的字串接起来。若 UDP 用户数据报的数据部分不是偶数个字节，则要填入一个全零字节（但此字节不发送)。然后按二进制反码计算出这些 16 位字的和。将此和的二进制反码写入检验和字段后，就发送这样的 UDP 用户数据报。在接收方，把收到的 UD P用户数据报连同伪首部（以及可能的填充全零字节）一起，按二进制反码求这些16 位字的和。当无差错时其结果应为全 1。否则就表明有差错出现，接收方就应丢弃这个UDP用户数据报（也可以上交给应用层，但附上出现了差错的警告)。（不重要，了解就好。。）
这种简单的差错检验方法的检错能力并不强，但它的好处是简单，处理起来较快。

伪首部的第 3 字段是全零，第4个字段是 IP 首部中的协议字段的值。对于 UDP，此协议字段值为 17。第 5 字段是 UDP 用户数据报的长度。因此，这样的检验和，既检查了 UDP 用户数据报的源端口号和目的端口号以及UDP用户数据报的数据部分，又检查了 IP 数据报的源 IP 地址和目的地址。

传输控制协议 TCP

TCP最主要的特点

(1)TCP是面向连接的运输层协议。 这就是说，应用程序在使用 TCP 协议之前，必须先建立 TCP 连接。在传送数据完毕后，必须释放已经建立的TCP连接。
(2)每一条 TCP 连接只能有两个端点(endpoint)，每一条TCP连接只能是点对点的（一对一)。
(3)TCP提供可靠交付的服务。也就是说，通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达。
(4)TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序在把数据传送给 TCP 的缓存后，就可以做自己的事，而 TCP 在合适的时候把数据发送出去。在接收时，TCP把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
(5)面向字节流。 TCP中的流(stream)指的是流入到进程或从进程流出的字节序列。
面向字节流的含义是：虽然应用程序和TCP的交互是一次一个数据块(大小不等)，但 TCP 把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义。TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系（例如，发送方应用程序交给发送方的TCP 共10个数据块，但接收方的TCP可能只用了4个数据块就把收到的字节流交付给了上层的应用程序)。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。当然，接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。

TCP 和 UDP 在发送报文时所采用的方式完全不同。
TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP发送的报文长度是应用进程给出的)。如果应用进程传送到 TCP 缓存的数据块太长，TCP就可以把它划分短一些再传送。如果应用进程一次只发来一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

TCP 的连接

TCP 把连接作为最基本的抽象。
TCP 连接的端点不是主机，不是主机的 IP 地址，不是应用进程，也不是运输层的协议端口。
TCP 连接的端点叫做套接字(socket)或插口。根据 RFC 793 的定义：端口号拼接到(contatenated with) IP地址即构成了套接字。因此套接字的表示方法是在点分十进制的IP地址后面写上端口号，中间用冒号或逗号隔开。
$$套接字\text{socket}=(\text{IP}地址：端口号)$$

每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定。即;
TCP连接： = { socket 1 ， socket 2 } = { ( IP 1 : port 1 ) , ( IP 2 : port 2 ) } \text{TCP} 连接：= \{ \text{socket}_1， \text{socket}_2\} = \{(\text{IP}_1 : \text{port}_1),(\text{IP}_2: \text{port}_2)\} TCP连接：={socket1?，socket2?}={(IP1?:port1?),(IP2?:port2?)}

这里 $I{P}_1$ 和 $I{P}_2$ 分别是两个端点主机的 IP 地址，而 $por{t}_1$ 和 $por{t}_2$ 分别是两个端点主机中的端口号。TCP连接的两个套接字就是 $socke{t}_1$ 和 $socke{t}_2$ 。

TCP连接就是由协议软件所提供的一种抽象。
TCP 连接的端点是套接字，即（IP地址：端口号)。并且同一个 IP 地址可以有多个不同的 TCP 连接，而同一个端口号也可以出现在多个不同的 TCP 连接中。

可靠传输的工作原理

TCP 发送的报文段是交给 IP 层传送的。但 IP 层只能提供尽最大努力服务，也就是说，TCP 下面的网络所提供的是不可靠的传输。因此，TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。
理想的传输条件有两个特点：
(1)传输信道不产生差错。
(2)不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

停止等待协议

全双工通信的双方既是发送方也是接收方。为了讨论问题的方便，仅考虑 A 发送数据而 B 接收数据并发送确认。因此 A 叫做发送方，而 B 叫做接收方。
停止等待就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

1.无差错情况
A发送分组 M1，发完就暂停发送，等待 B 的确认。B 收到了M1就向 A 发送确认。A 在收到了对 M1 的确认后，就再发送下一个分组M2。同样，在收到 B 对 M2的确认后，再发送 M3。。。

2.出现差错
B 接收 M1 时检测出了差错，就丢弃M1，其他什么也不做（不通知A收到有差错的分组)。也可能是 M1 在传输过程中丢失了，这时 B 什么都不知道。在这两种情况下，B 都不会发送任何信息。
可靠传输协议：A 只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这叫做超时重传。要实现超时重传，就要在每发送完一个分组设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。A 为每一个已发送的分组都设置了一个超时计时器。但 A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器。

需要注意的一些点：
1.A 在发送完一个分组后，必须暂时保留已发送的分组的副本（为发生超时重传时使用)。只有在收到相应的确认后才能清除暂时保留的分组副本。
2.分组 和 确认分组 都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。
3.超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些（减少网络拥塞状况的影响）。

3.确认丢失和确认收到
B所发送的对 M 的确认丢失了。A 在设定的超时重传时间内没有收到确认，但并无法知道是自己发送的分组出错、丢失，或者是B发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M。
现在应注意 B 的动作。假定 B 又收到了重传的分组M。这时应采取两个行动。
1）丢弃这个重复的分组 M，不向上层交付。
2）向 A 发送确认。不能认为已经发送过确认就不再发送，因为 A 之所以重传 M 就表示 A 没有收到对 M的确认。

4.信道利用率
信止等待协议的优点是简单，但缺点是信道利用率太低。

信道的利用率 $U$ 可用下式计算：
$$U=\frac{T_D}{T_D+RTT+T_A}$$

A 发送分组需要的时间是 $T_p$。显然，$T_p$ 等于分组长度除以数据率。再假定分组正确到达 B 后，B处理分组的时间可以忽略不计，同时立即发回确认。假定 B 发送确认分组需要时间 $T_A$。如果 A 处理确认分组的时间也可以忽略不计，那么 $A$ 在经过时间 $(T_D+RTT+T_A)$ 后就可以再发送下一个分组，这里的RTT是往返时间。因为仅仅是在时间 $T_p$ 内才用来传送有用的数据（包括分组的首部）。

连续 ARQ 协议

滑动窗口协议比较复杂，是 TCP 协议的精髓所在。

(a)表示发送方维持的发送窗口，它的意义是：位于发送窗口内的 5 个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。
接收方一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。

有好处，有坏处，自己细品吧，通信领域没有绝对好的策略。

TCP 报文段的首部格式

TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段。
一个 TCP 报文段分为首部和数据两部分，而** TCP 的全部功能都体现在它首部中各字段的作用**。
TCP 报文段首部的前20个字节是固定的，后面有 4N 字节是根据需要而增加的选项(N是整数)。因此 TCP 首部的最小长度是 20 字节。

首部固部分各字段的意义如下:
(1)源端口和目的端口
各占 2 个字节，分别写入源端口号和目的端口号，TCP的分用功能也是通过端口实现的。
(2)序号
占 4 字节。序号范围是 $[0,2^{32}?1]$，共 $2^{32}$ (即 4 284 967 296）个序号。序号增加到 $2^{32}?1$ 后，下一个序号就又回到 0。也就是说，序号使用 mod$2^{32}$ 运算。
TCP是面向字节流的。在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。
(3)确认号
占 4 字节，是期望收到对方下一个报文段的第一个数据字节的序号。
若确认号=N，则表明:到序号 N-1为止的所有数据都已正确收到。
(4)数据偏移
占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。实际上是指出 TCP 报文段的首部长度。
由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。数据偏移的单位是 32 位字(即以 4 字节长的字为计算单位)。由于 4 位二进制数能够表示的最大十进制数字是 15，因此数据偏移的最大值是 60 字节，这也是 TCP 首部的最大长度（即选项长度不能超过40字节)。
(5)保留
占 6 位，保留为今后使用，但目前应置为0。
(6)紧急URG(URGent)
当 URG = 1 时，表明紧急指针字段有效。告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)，而不要按原来的排队顺序来传送。
当URG置 1 时，发送应用进程就告诉发送方的 TCP 有紧急数据要传送。于是发送方 TCP 就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据。这时要与首部中紧急指针(Urgent Pointer)字段配合使用。
(7)确认ACK(ACKnowlegment)
仅当 ACK =1 时确认号字段才有效。当 ACK=0 时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
(8)推送 PSH (PuSH)
当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下，TCP就可以使用推送(push)操作。这时，发送方TCP把 PSH 置1，并立即创建一个报文段发送出去。接收方TCP收到 PSH= 1 的报文段，就尽快地（即“推送”向前）交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。
(9)复位RST (ReSeT)
当 RST = 1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因)，必须释放连接，然后再重新建立运输连接。RST 置 1 还用来拒绝一个非法的报文段或拒绝打开一个连接。RST 也可称为重建位或重置位。
(10)同步 SYN (SYNchronization)
在连接建立时用来同步序号。当 SYN= 1 而 ACK=0 时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN= 1和 ACK= 1。因此，SYN置为 1 就表示这是一个连接请求或连接接受报文。
(11)终止FIN
用来释放一个连接。当 FIN= 1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。
(12)窗口
占2字节。窗口值是 $[0,2^{16}?1]$ 之间的整数。窗口指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口）。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。总之，窗口值作为接收方让发送方设置其发送窗口的依据。
窗口字段明确指出了现在允许对方发送的数据量。窗口值是经常在动态变化着。
(13)检验和
占2字节。检验和字段检验的范围包括首部和数据这两部分。和 UDP 用户数据报一样，在计算检验和时，要在TCP报文段的前面加上 12 字节的伪首部。伪首部的格式与UDP用户数据报的伪首部一样。但应把伪首部第4个字段中的17改为 6(TCP的协议号是6)，把第5字段中的UDP长度改为TCP长度。接收方收到此报文段后，仍要加上这个伪首部来计算检验和。若使用IPv6，则相应的伪首部也要改变。
(14)紧急指针
占2字节。紧急指针仅在 URG = 1 时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据)。因此紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时，TCP就告诉应用程序恢复到正常操作。即使窗口为零时也可发送紧急数据。
(15)选项
长度可变，最长可达40字节。当没有使用选项时，TCP 的首部长度是20字节。
TCP 最初只规定了一种选项，即 最大报文段长度MSS (Maximum Segment Size)。MSS 是每一个TCP 报文段中的数据字段的最大长度。

最大报文段大小（MSS）： 用于指定TCP连接的最大报文段大小。这个选项通常在TCP的三次握手过程中使用，以便通信的两端可以协商适当的数据段大小。
窗口扩大因子（Window Scale）：用于在窗口大小字段中扩大的倍数。通过使用窗口扩大因子，TCP可以支持更大的窗口大小，提高了数据传输的效率。
选择确认（Selective Acknowledgment, SACK）：允许在TCP连接中选择性地确认接收到的数据块。当网络发生丢包时，SACK选项可以帮助恢复丢失的数据。
时间戳（Timestamps）：包含发送和确认报文的时间戳，用于计算往返时间（RTT）和估计时钟漂移，以调整数据传输的时序。

选项这里不好搞。。。有时间再看吧。
选项字段的长度是可变的，因此它的长度字段可以指示选项的具体长度。选项字段的总长度必须是32位字的倍数，因此需要填充字段。选项和填充字段的总长度由首部的数据偏移字段指示。选项和填充字段的存在使TCP的首部更加灵活，能够适应各种不同的网络和应用场景。

TCP 可靠连接的实现

假定数据传输只在一个方向进行，即 A 发送数据，B 给出确认。

以字节为单位的滑动窗口

TCP 的滑动窗口是以字节为单位的。
假定 A 收到了 B 发来的确认报文段，其中窗口是20（字节)，而确认号是31（这表明B期望收到的下一个序号是 31，而序号 30 为止的数据已经收到了)。根据这两个数据，A就构造出自己的发送窗口，其位置如图。

发送窗口表示： 在没有收到 B 的确认的情况下，A 可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。但接收方必须来得及处理这些收到的数据。
发送窗口后沿的后面部分表示已发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。
发送窗口前沿也有可能向后收缩。这发生在对方通知的窗口缩小了。但 TCP 的标准强烈不赞成这样做。因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据，现在又要收缩窗口，不让发送这些数据，这样就会产生一些错误。

现在假定 A 发送了序号为 31 ～41 的数据。这时，发送窗口位置并未改变，但发送窗口内靠后面有 11 个字节（灰色小方框表示）表示已发送但未收到确认。而发送窗口内靠前面的 9 个字节( 42~50）是允许发送但尚未发送的。

从以上所述可以看出，要描述一个发送窗口的状态需要三个指针：P1，P2 和 P3。指针都指向字节的序号。三个指针指向的几个部分的意义如下：
小于 P1 的是已发送并已收到确认的部分，而大于 P3 的是不允许发送的部分。
P3 - P1 = A 的发送窗口（又称为通知窗口)
P2 - P1 = 已发送但尚未收到确认的字节数
P3 - P2 = 允许发送但尚未发送的字节数（又称为可用窗口或有效窗口）

B 的接收窗口大小是 20。在接收窗口外面，到 30 号为止的数据是已经发送过确认，并且已经交付给主机了。因此在 B 可以不再保留这些数据。接收窗口内的序号（31 ~50）是允许接收的。在图中，B收到了序号为 32 和 33 的数据。这些数据没有按序到达，因为序号为 31 的数据没有收到（也许丢失了，也许滞留在网络中的某处)。请注意，B 只能对按序收到的数据中的最高序号给出确认，因此 B 发送的确认报文段中的确认号仍然是31（即期望收到的序号)，而不能是 32 或 33 。

现在假定 B 收到了序号为 31 的数据，并把序号为 31～33 的数据交付给主机，然后 B 删除这些数据。接着把接收窗口向前移动 3 个序号，同时给 A 发送确认，其中窗口值仍为 20，但确认号是34。

这表明 B 已经收到了到序号 33 为止的数据。在图中，B 还收到了序号为 37，38 和 40 的数据，但这些都没有按序到达，只能先暂存在接收窗口中。A 收到 B 的确认后，就可以把发送窗口向前滑动 3 个序号，但指针 P2 不动。可以看出，现在 A 的可用窗口增大了，可发送的序号范围是 42~53。

A 在继续发送完序号 42~53 的数据后，指针 P2 向前移动和 P3 重合。发送窗口内的序号都已用完，但还没有再收到确认。如下图：

由于 A 的发送窗口已满，可用窗口己减小到零，因此必须停止发送。
为了可靠传输，A 在经过一段时间后（由超时计时器控制）就重传这部分数据，重新设置超时计时器，直到收到 B 的确认为止。
如果 A 收到确认号落在发送窗口内，那么 A 就可以使发送窗口继续向前滑动，并发送新的数据。

发送方的应用进程把字节流写入 TCP 的发送缓存，接收方的应用进程从TCP 的接收缓存中读取字节流。

发送缓存用来暂时存放:
(1)发送应用程序传送给发送方TCP准备发送的数据；
(2)TCP已发送出但尚未收到确认的数据。
发送窗口通常只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中的被写入的字节数。发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。

接收缓存用来暂时存放:
(1)按序到达的、但尚未被接收应用程序读取的数据；
(2)未按序到达的数据。
如果收到的分组被检测出有差错，则要丢弃。如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减小到零。反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收缓存的大小。

超时重传时间的选择

如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大；
如果把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。

。。。具体算法用时再了解吧

选择确认 SACK

Selective Acknowledgement，选择性确认

TCP 收到乱序数据后，会将其放入乱序队列中，然后发送重复 ACK 给对端。对端如果收到多个重复的ACK，认为发生丢包，TCP 会重传最后确认的包开始的后续包。这样原先已经正确传输的包可能会重复发送，降低了TCP性能。
使用 SACK 选项可以告知发包方收到了哪些数据，发包方收到这些信息后就会知道哪些数据丢失，然后立即重传丢失的部分。

需要注意的是只有收到失序的分组时才会可能会发送 SACK，TCP 的 ACK 还是建立在累积确认的基础上的。也就是说如果收到的报文段与期望收到的报文段的序号相同就会发送累积的 ACK，SACK 只是针对失序到达的报文段的。

TCP 的流量控制

利用滑动窗口实现流量控制
一般说来，总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。所谓流量控制(flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。

利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。

设 A 向 B 发送数据。在连接建立时，B 告诉了 A：我的接收窗口 rwnd = 400(这里 rwnd 表示 receiver window)。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP 的窗口单位是字节，不是报文段。

如果报文段在传送过程中丢失了。A 一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。
为了解决这个问题，TCP为每一个连接设有一个持续计时器(persistence timer)。只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
如果窗口仍然是零，那么收到这个报文段的一方就重新设置持续计时器。
如果窗口不是零，那么死锁的僵局就可以打破了。

应用进程把数据传送到 TCP 的发送缓存后，剩下的发送任务就由 TCP 来控制了。可以用不同的机制来控制 TCP 报文段的发送时机。
第一种机制是 TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去。
第二种机制是由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送(push)操作。
第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过MSS）发送出去。

控制TCP发送报文段的时机仍然是一个较为复杂的问题。
暂时先不解决了，有需要去看。。

TCP 的拥塞控制

拥塞控制的一般原理

在计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等，都是网络的资源。
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞(congestion)。
可以把出现网络拥塞的条件写成如下的关系式：
$$\sum 对资源的需求>可用资源$$

网络拥塞往往是由许多因素引：
1.当某个结点缓存的容量太小时，到达该结点的分组因无存储空间暂存而不得不被丢弃。
设想将该结点缓存的容量扩展到非常大。于是凡到达该结点的分组均可在结点的缓存队列中排队，不受任何限制。由于输出链路的容量和处理机的速度并未提高，因此在这队列中的绝大多数分组的排队等待时间将会大大增加，结果上层软件只好把它们进行重传(因为早就超时了)。由此可见，简单地扩大缓存的存储空间同样会造成网络资源的严重浪费，因而解决不了网络拥塞的问题。
2.处理机处理的速率太慢可能引起网络的拥塞。

拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
拥塞控制的前提：网络能够承受现有的网络负荷。

流量控制往往指点对点通信量的控制，是个端到端的问题(接收端控制发送端)。
流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制和流量控制常常被弄混：因为某些拥塞控制算法是向发送端发送控制报文，并告诉发送端，网络已出现麻烦，必须放慢发送速率。这点和流量控制是很相似的。

进行拥塞控制需要付出代价。首先需要获得网络内部流量分布的信息。在实施拥塞控制时，还需要在结点之间交换信息和各种命令，以便选择控制的策略和实施控制。这样就产生了额外开销。拥塞控制有时需要将一些资源（如缓存、带宽等）分配给个别用户（或一些类别的用户）单独使用，这样就使得网络资源不能更好地实现共享。因此，在设计拥塞控制策略时，必须全面衡量得失。

横坐标是提供的负载(offered load)，代表单位时间内输入给网络的分组数目。因此提供的负载也称为输入负载或网络负载。
纵标是吞吐量(throughput)，代表单位时间内从网络输出的分组数目。
具有理想拥塞控制的网络，在吞吐量饱和之前，网络吞吐量应等于提供的负载，故吞吐量曲线是 45°的斜线。但当提供的负载超过某一限度时，由于网络资源受限，吞吐量不再增长而保持为水平线，即吞吐量达到饱和。这就表明提供的负载中有一部分损失掉了 (例如，输入到网络的某些分组被某个结点丢弃了)。虽然如此，在这种理想的拥塞控制作用下，网络的吞吐量仍然维持在其所能达到的最大值。
实际网络的情况随着提供的负载的增大，网络吞吐量的增长速率逐渐减小。也就是说，在网络吞吐量还未达到饱和时，就已经有一部分的输入分组被丢弃了。当网络的吞吐量明显地小于理想的吞吐量时，网络就进入了轻度拥塞的状态。更值得注意的是，当提供的负载达到某一数值时，网络的吞吐量反而随提供的负载的增大而下降，这时网络就进入了拥赛状态。当提供的负载继续增大到某一数值时，网络的吞吐量就下降到零，网络已无法工作。这就是所谓的死锁(deadlock)。

几种拥塞控制的方法

发送方维持一个叫做**拥塞窗口 cwnd (congestion window)**的状态变量。
拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。如果再考虑到接收方的接收能力，那么发送窗口还可能小于拥塞窗口。

1.慢启动（Slow Start）：
慢开始算法的思路：当主机开始发送数据时，如果立即把大量数据字节注到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段 MSS 的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个 MSS 的值。用这样的方法逐步增大发送方的拥塞窗口 cwnd，可以使分组注入到网络的速率更合理。使用开始算法后，每经过一个传输轮次(transmission round)，拥塞窗口 cwnd 就加倍。

在连接刚开始时，发送方通过以指数方式增加拥塞窗口大小来迅速占用网络带宽。
慢启动阶段的拥塞窗口大小以指数方式增加，直到达到一个阈值（慢启动阈值）。

2.拥塞避免（Congestion Avoidance）：
为了防止拥塞窗口 cwnd 增长过大引起网络拥塞，还需要设置一个慢开始门限 ssthresh 状态变量。慢开始门限 ssthresh 的用法如下：
当cwnd < ssthresh 时，使用上述的慢开始算法。
当cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法

一旦拥塞窗口大小达到慢启动阈值，发送方切换到拥塞避免阶段。

拥塞避免算法的思路：让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍。这样，拥塞窗口 cwnd 按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

在拥塞避免阶段，拥塞窗口大小线性增加，而非指数增加。

3.快速重传（Fast Retransmit）：
当发送方连续收到相同的确认时，它认为某个数据包丢失。
发送方可以快速重传丢失的数据包而无需等待超时。

4.快速恢复（Fast Recovery）：
与快速重传结合使用，快速恢复机制允许发送方在收到第一个重复确认时将拥塞窗口减半，而不是将其设置为1。

5.超时重传（Timeout Retransmission）：
如果在一定时间内未收到确认，发送方将假定数据包丢失，并进行超时重传。

6.TCP Reno 和 TCP NewReno：
TCP Reno引入了快速恢复机制，但在快速重传时仍然将拥塞窗口减半。
TCP NewReno通过在快速重传期间维持窗口大小，以提高性能。

实际情况下，接收方的缓存空间总是有限的。接收方根据自己的接收能力设定了接收窗口 rwnd，并把这个窗口值写入 TCP 首部中的窗口字段，传送给发送方。因此，接收窗口又称为通知窗口(advertised window)。因此，从接收方对发送方的流量控制的角度考虑，发送方的发送窗口一定不能超过对方给出的接收窗口值 rwnd。

发送方的窗口的上限值应当取为接收方窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个：
$$发送方窗口的上限值=\min [\text{rwnd,cwnd}]$$

随机早期检测

RED（Random Early Detection）是一种用于拥塞控制的主动队列管理算法。它旨在在网络中的路由器或交换机中进行流量管理，以避免拥塞的发生。
RED算法的基本思想是在队列积累到一定程度之前，开始随机丢弃部分数据包，以向发送方发出拥塞信号。

RED算法的主要特点和原理：

随机性：
RED引入了随机性，以避免在网络中产生同步拥塞。
数据包在队列长度达到配置的最小阈值之前，有一定概率被随机丢弃。

最小和最大阈值：
RED算法定义了两个阈值，即最小阈值（Min Threshold）和最大阈值（Max Threshold）。
当队列长度小于最小阈值时，不进行丢包。
当队列长度超过最大阈值时，所有数据包都被丢弃。
在最小和最大阈值之间，以一定的概率丢弃数据包。

平滑因子：
RED使用平滑因子（Weight）来确定在最小和最大阈值之间丢弃数据包的概率。
平滑因子越大，丢弃的概率越低，反之亦然。

可调参数：
RED算法的关键参数是最小阈值、最大阈值和平滑因子，这些参数可以根据网络的特性进行调整。

优势：
RED相对于传统的丢包策略，如Tail Drop（当队列满时直接丢弃所有数据包），具有更好的性能。
通过在队列开始填满之前开始随机丢包，RED 能够更早地向发送方发出拥塞信号，避免了突发拥塞的发生。

应用场景：
RED通常用于网络中的路由器或交换机，特别是在连接较慢和较快网络之间的瓶颈处。
它可以在网络中帮助进行主动的拥塞控制，提高整体的网络性能。

随即早期检测，用到时候查就好。。。

TCP 的运输连接管理

TCP是面向连接的协议。运输连接是用来传送 TCP 报文的。
运输连接就有三个阶段，即：连接数据、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常接建立、地进行。

在TCP 连接建立过程中要解决的三个问题：
(1)要使每一方能够确知对的存在。
(2)要允许双方协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)。
(3)能够对运输实体资源(如缓存大小连接表中的项等)进行分配。

TCP 连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户(client)，而被动等待连接建立的应用进程叫做服务器(server)。

TCP 连接的建立

假定主机A 运行的是 TCP 客户程序，而 B 运行TCP 服务器程序。最初两端的 TCP 进程都处于 CLOSED(关闭)。 状态图中在主机下面的方框分别是 TCP 进程所处的状态。A 主动打开连接，而 B 被动打开连接。

建立连接的过程：
1）B 的 TCP 服务器进程先创建传输控制块 TCB ，准备接受客户进程的连接请求。然后服务器进程就处于 LISTEN(收听) 状态，等待客户的连接请求。如有，即作出响应。
2）A 的TCP 客户进程也是首先创建 传输控制模块 TCB ，然后向 B 发出连接请求报文段，这时首部中的同步位 SYN = 1，同时选择一个初始序号 seq = x。TCP 规定，SYN 报文段(即 SYN = 1的报文段不能携带数据，但要消耗掉一个序号。这时，TCP 客户进程进入SYN-SENT(同步已发送) 状态。
3）B 收到连接请求报文段后，如同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack =x + 1，同时也为自己选择一个初始序号 seq =y。这个报文段也不能携带数据，但同样要消耗掉一个序号。这时 TCP 服务器进程进入SYN-RCVD(同步收到) 状态。
4）TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置1，确认号 ack =y +1，而自己的序号 seq =x + 1。TCP 的标准规定，ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq =x + 1。这时，TCP 连接已经建立，A 进入 **ESTABLISHED (已建立连接)**状态。
5）当 B 收到 A 的确认后，也进入 ESTABLISHED 状态

总结 三次握手建立连接：
1.客户端向服务器发送 SYN：
客户端发起连接请求，发送一个TCP报文段，其中包含SYN（同步）标志，并选择一个初始序列号。
这个报文段不包含数据，但在TCP首部中有SYN标志位。
2.服务器收到SYN并发送ACK + SYN：
服务器收到客户端的SYN后，回应一个确认（ACK）标志，确认收到了客户端的请求，同时也发送一个SYN标志。
服务器选择一个自己的初始序列号。
3.客户端收到ACK + SYN：
客户端收到服务器的确认和SYN后，回应一个ACK标志，确认收到服务器的响应。
从此时开始，数据传输的双向连接建立完成，可以开始进行数据传输。

A 还要发送一次确认的原因：为了防止已失效的连接请求报文段突然又传送到了 B，因而产生错误。

TCP 连接的释放

释放过程：
1）A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的 FIN 置 1，其序号 seq = u，它等于前面已传送过的数据的最后一个字节的序号加 1。这时 A 进入 FIN-WAIT-1(终止等待1) 状态，等待B的确认。TCP 规定，FIN 报文段即使不携带数据，它也消耗掉一个序号。

2）B 收到连接释放报文段后即发出确认，确认号是 ack =u +1，而这个报文段自己的序号是 v，等于 B 前面已传送过的数据的最后一个字节的序号加 1。然后 B 就进入 CLOSEWAIT(关闭等待)状态 。TCP 服务器进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于 半关闭(half-close) 状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收 。也就是说，从 B 到 A 这个方向的连接并未关闭。这个状态可能会持续一些时间。
3）A 收到来自 B 的确认后，就进入 FIN-WAIT-2(终止等待 2)状态 ，等待 B 发出的连接释放报文段。
4）若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。现假定 B 的序号为 w(在半关闭状态 B 可能又发送了一些数据)。B 还必须重复上次已发送过的确认号 ack = u +1。这时 B 就进入 LAST-ACK (最后确认)状态 ，等待 A 的确认。
5）A 在收到 B 的连接释报文段后，必须对此发确认。在确认报文中把 ACK 置1确认号 ack = w + 1，而自己的序号是 seq = u + 1(根据TCP 标准，前面发送过的 FIN 报文段要消耗一个序号)。然后进入到 TIME-WAIT (时间等待)状态 。要注意的是，现在 TCP 连接还没有释放掉。必须经过时间等待计时器(TIME-WAIT timer)设置的时间 2 MSL 后，A才进入到CLOSED状态 。时间 MSL叫做 最长报文段寿命(Maximum Segment Lifetime) ，RFC 793 建议设为 2 分钟，即 MSL = 2。当 A 撤销相应的传输控制块TCB 后，就结束了这次的TCP 连接。

总结四次挥手终止连接：
1.客户端发送FIN：
客户端希望终止连接时，发送一个带有FIN标志的TCP报文段。
2.服务器收到FIN并发送ACK：
服务器收到客户端的FIN后，回应一个ACK标志，表示确认收到FIN。
3.服务器发送FIN：
服务器也可能在之后希望终止连接，发送一个带有FIN标志的TCP报文段。
4.客户端收到FIN并发送ACK：
客户端收到服务器的FIN后，回应一个ACK标志，表示确认收到FIN。
至此，连接终止

A 在 TIME-WAIT 状态必须等待 2MSL 的时间的原因：
1)保证A发送的最后一个 ACK 报文能够到达B。万一 ACK 丢失，超时重传还有时间。
2)可以使本连接持续的时间内所产生的所有报文段都从网络中消失。使下一个新的连接中不会出现这种旧的连接请求报文段。

TCP 的有限状态机

Current State	Event/Action	Next State
CLOSED	Active OPEN	SYN_SENT
SYN_SENT	SYN/ACK	ESTABLISHED
ESTABLISHED	FIN	FIN_WAIT_1
FIN_WAIT_1	ACK	FIN_WAIT_2
FIN_WAIT_2	FIN/ACK	TIME_WAIT
TIME_WAIT	Timeout	CLOSED

谢希仁第五版《计算机网络》学习笔记