• 进程之间的通信

• 运输层的两个主要协议

• 运输层的主要功能

• 运输层的端口

  • TCP的端口

• UDP的主要特点

• TCP主要特点

• 套接字

• 可靠通信的实现

  • 停止等待协议

  • 信道利用率

  • 连续ARQ协议

• TCP可靠通信的工作原理

• TCP可靠传输的实现

  • 以字节为单位的滑动窗口

  • 超时重传的选择

  • TCP的流量控制

  • TCP的拥塞控制

  • TCP的拥塞控制方法

  • 主动队列管理AQM

• TCP的运输连接管理

  • TCP连接的建立

  • 为什么TCP要进行第三次握手？

  • TCP的连接释放

  • 时间等待计时器的原因

  • TCP的有限状态机

本章重点内容

1. 运输层为相互通信的应用提供逻辑通信
2. 端口和套接字的意义
3. 无连接的UDP的特点
4. 面向连接的TCP的特点
5. 在不可靠的网络上实现可靠传输的工作原理，停止等待协议和ARQ协议
6. TCP的滑动窗口、流量控制、拥塞控制和连接管理

运输层协议概述

进程之间的通信

从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它术语面向通信部分的最高层，同时也是用户功能中的最底层。只有位于网络边缘部分的主机的协议栈才有运输层

两个主机进行通信实际上就是两个主机中的应用进程互相通信，又称为端到端的通信

运输层提供应用进程间的逻辑通信，即运输层逻辑上是直接通信的，但实际上是通过下层来实现的。

运输层的两个主要协议

TCP/IP运输层的两个主要协议都是互联网的正式标准，即：

1. 用户数据报协议UDP
2. 传输控制协议TCP

运输层的主要功能

• 运输层为应用进程之间提供端到端的逻辑通信
• 运输层还要对收到的报文进行差错检测
• 运输层需要有两种不同的运输协议，即面向连接的TCP和无连接的UDP

运输层的端口

运输层使用协议端口号，或通常简称为端口。运输层拥有复用和分用的功能。应用层所有的应用进程都可以通过运输层再传到IP层，这就是复用。运输层从IP层收到发送给各应用进程的数据后，必须分别交付指明的各应用进程，这就是分用。给应用进程一个明确的标志是至关重要的。这个标志就是端口。

TCP的端口

端口用一个16位端口号进行标志。端口号只具有本地意义，即端口号只为了标志本计算机应用层的各进程。

三类端口

• 熟知端口，一般为0~1023
• 登记端口号，数值为1024~49151。为没有熟知端口号的应用程式使用，使用这个范围的端口号必须在IANA登记，以免重复
• 客户端口号或短暂端口号，数值为49153~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号，使用结束后，这个端口号可供其他客户进程以后使用。

用户数据报协议UDP

UDP只在IP的数据报服务之上增加了很少一点的功能，即端口的功能和差错检测的功能

UDP的主要特点

• UDP是无连接的，即发送数据之前不需要建立连接
• UDP使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制。
• UDP是面向报文的。UDP没有-拥塞控制，适合多媒体通信的要求
• UDP支持一对一、一对多、多对一和多对多的交互通信
• UDP的首部开销小，只有8个字节

UDP的首部格式

伪首部用来计算检验和，将伪首部UDP用户数据报一起计算。不向下传送也不向上递交。

传输控制协议TCP概述

TCP主要特点

• TCP是面向连接的运输层协议
• 每一条TCP连接只能有两个端点
• TCP提供可靠交付的服务
• TCP提供全双工通信
• 面向字节流

TCP连接是一条虚连接，而不是一条真正的物理连接。TCP报文段先要传送到IP层，加上IP首部后，在传送到数据链路层。再加上数据链路层的首部和尾部才离开主机发送到物理链路。

TCP和UDP在发送报文时所采用的方式完全不同，TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度决定一个报文段应包含多少个字节。UDP发送的报文长度是应用进程给出的。如果应用程序传送到的TCP缓存的数据块太长，TCP就可以把它划分短一些再传送。

套接字

套接字 socket = (IP地址: 端口号)

每一条TCP连接唯一地被通信两端的两个端点(即套接字)所确定。即：

TCP 连接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}

可靠通信的实现

TCP下面的网络所提供的是不可靠的传输，因此TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。

理想的传输条件有以下两个特点

1. 传输信道不产生差错
2. 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

实际的网络都不具备以上两个理想条件，但我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，并且在来不及处理收到的数据的时候及时告诉发送方适当降低发送数据的速度。

在不可靠的传输网络中，可以通过确认和重传机制实现可靠的通信。可靠的传输协议常称为自动重传请求ARQ。ARQ表名重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组，即发送方在没有受到确认报文会自动重传。

下面将从最简单的停止等待协议讲起。

停止等待协议

停止等待协议非常简单，发送一个数据报，发送完就暂停发送，等待B的确认。B收到了就向A发送确认。A在收到了对M1的确认报文之后，就再发送下一个分组M2。当出现差错的情况，接收端就丢弃报文，其他什么也不做(不通知发送端)。发送端一段时间后没有收到确认报文就认为刚刚的分组丢了，重新发送一份，这称为超时重传。

除此之外，还有确认丢失和确认迟到的情况，见下图：

信道利用率

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

连续ARQ协议

连续ARQ协议是TCP协议精髓——滑动窗口协议的最基本的概念，见下图

连续ARQ协议会发送连续的n个窗口。接收方对按序到达的最后一个报文进行确认，表示这个分组之前的所有报文都正确送达，发送方收到确认报文之后就把发送窗口向前滑动。

累计确认有优点也有缺点，优点是容易实现，即时确认丢失也不必重传。但缺点是不能像发送方反映出正确收到的所有分组信息，例如发送了前五个分组，第三个分组丢了，正确收到的第4、5个分组因为发送方不知道是否正确收到而要一起重传。

TCP可靠通信的工作原理

• TCP连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口
• TCP的可靠传输机制用字节的序号进行控制，TCP所有的确认都是基于序号而不是基于报文段。
• TCP两端的四个窗口经常处于动态变化之中
• TCP连接的往返时间RTT也不是固定不变的，需要使用特定的算法估算较为合理的重传时间。

这里重点说明一下六个标志位：

• 紧急URG。当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送，而不要按原来的排队顺序来传送。例如用户的中断指令。
• 确认ACK。当ACK=1时有效，在连接建立后所有传送的报文都必须将ACK置1。
• 推送PSH。当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立刻就能收到对方的响应，在这种情况下，TCP就可以使用推送操作，表示希望尽快地交付，而不再等到整个缓存都填满了再向上交付。
• 复位RST。当RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立运输链接
• 同步SYN。在建立连接时用来的同步序号
• 终止FIN。用来释放一个连接

窗口是指发送本报文段的一方的接收窗口。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量，窗口值作为接收方让发送方设置其发送窗口的依据。

TCP可靠传输的实现

以字节为单位的滑动窗口

先讨论发送方A的发送窗口，发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去，凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

当发送窗口没有收到确认报文的时候，滑动窗口不会向前滑动，A在一段时候后(由超时计时器控制)就重传这部分数据，直到收到确认为止。

需要明确的两点

1. 缓存空间和序号空间都是有限的，并且都是循环使用的，最好是把它们画成圆环状的。
2. 实际上缓存或窗口中的字节数是非常之大的

发送缓存暂时存放

1. 应用程序准备发送的数据
2. TCP已发出但尚未收到确认的数据

接收缓存暂时存放

1. 按序到达、但尚未被接收应用程序读取的数据
2. 未按序到达的数据

需要注意的三点：

1. 虽然A的发送窗口根据B的接收窗口设置的，但是同一时刻A的发送窗口并不一定和B的接收窗口一样大。因为网络的滞后性，并且发送方A也会根据网络当时的拥塞情况适当减小自己的发送窗口数值。
2. 对不按序到达的数据该如何处理，TCP标准并无明确规定，TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后再按序交付上层的应用进程
3. TCP要求接收方必须有累计确认的功能，用以减少传输开销**。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上**。不过要求接收方不应过分推迟发送确认，TCP标准规定确认推迟的时间不应超过0.5s。

超时重传的选择

超时计时器的超时重传时间究竟应设置为多大呢？

TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应确认报文的时间。这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间RTT~s~。之后每测量到一个新的RTT样本就按下式重新计算一次RTT~s~：

当接近0的时候表示新的RTT~s~和旧的RTT~s~相比变化不大(变化更慢)，反之收新的RTT影响大

超时重传时间RTO应略大于上面的加权平均往返时间RTT~s~。

是RTT的偏差的加权平均值，它与和新的RTT样本之差有关。

这里的是一个小于1的系数，推荐值是0.25.

这里还有一个问题——当报文重传的时候，如何确定当前确认报文是对先一个的报文的确认，还是对重传的报文的确认？这对计算RTO影响非常大。

现在常用的算法是：报文段每重传一次，不再使用上面的公式，而是把超时重传时间增大一些，典型的做法是增大两倍。

TCP的流量控制

所谓流量控制就是让发送方的发送速率不要太快，要让对方来得及接收。

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

为了解决确认报文丢失导致死锁的僵局，TCP设置了一个持续计时器的机制。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到了，就询问对方现在的窗口是否依旧是0窗口。

TCP的拥塞控制

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

相反流量控制往往是指点对点通行量的控制，是个端到端的问题。

由于计算机网络是一个很复杂的系统，因此可以从控制理论的角度来看拥塞控制这个问题。从大的方向看，可以分为开环控制和闭环控制两种方法。开环控制就是在设计的时候在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。

闭环控制是基于反馈环路的概念，主要有以下几种措施：

1. 检测网络系统以便检测到拥塞在何时、何处发生
2. 把拥塞发生的信息传送到可采取行动的地方
3. 调整网络系统的运行以解决出现的问题

检测网络的一些指标：

1. 缺少缓存空间而被丢弃的分组的百分数
2. 平均队列长度
3. 超时重传的分组数
4. 平均分组时延
5. 分组时延的标准差

TCP的拥塞控制方法

TCP进行拥塞控制的算法有四种：慢开始、拥塞避免、快重传、快恢复

现在的拥塞控制方法是基于窗口。发送方维持一个叫做拥塞窗口cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程序，发送方让自己的发送窗口等于拥塞窗口。

慢开始

在开始传输数据时，先探测以下，然后从小到大逐渐增大发送窗口。也就是由小到大逐渐增大拥塞窗口数值

拥塞避免

慢开始的cwnd到后面增长会非常迅速，所以设置一个慢开始门限ssthresh，当超过了门限之后就采用拥塞避免算法。

拥塞避免算法是让拥塞窗口cwnd缓慢增大，每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是成倍增长。

快重传

当个别报文段丢失，但网络并未阻塞，如果发送方误认为阻塞而启动慢开始，就降低了传输效率

快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是立即发送确认，即收到了失序的报文段要立即发出对已收到的报文段的重复确认。如果收到了3个连续的重复确认报文，说明重复报文下一个报文已丢失，故接收方要立即重传丢失的报文。这样也不会出现超时而误认为出现网络拥塞。

快恢复

快恢复是指当发送方直到只是丢失了个别的报文段，于是不启动慢开始，而是调整门限值为ssthresh=cwnd/2，然后开始拥塞避免算法。

主动队列管理AQM

主动队列管理是指不要等待路由器的队列长度以及达到最大值而不得不丢弃后面到达的分组，而是当使用队列，当队列长度达到一定值时发出预警。

实现：当队列长度达到一定时，对到达的分组按照一定的丢弃概率p丢弃，后面的发送方会根据已丢失的报文降低cwnd。即根据早期征兆实现负反馈

TCP的运输连接管理

运输连接有三个阶段，即：连接建立、数据传送和连接释放。

在TCP连接建立过程中要解决以下三个问题：

1. 使每一方能够确知对方的存在
2. 要允许对方协商一些参数(如最大窗口值、能否使用窗口扩大选项和时间戳选项以及服务质量等)
3. 能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配

TCP连接的建立

假定主机A运行的是TCP客户程序，而B运行的是TCP服务器程序。一开始都处于CLOSED(关闭状态)。

准备阶段

B的TCP服务器进程先创建传输控制块TCB。准备接受客户进程的连接请求。然后服务器进程就处于LISTEN(收听状态)。

第一次握手:

A的TCP客户进程也是创建传输控制模块TCB。然后建立TCP连接时，向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号(因为需要收到服务端ack=x+1的确认报文)。这时TCP客户进程进入SYS-SENT(同步已发送)状态。

第二次握手

B收到连接请求报文之后，如同意建立连接，则向A发送确认，在确认报文段中应把SYN和ACK位都置1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y。同样这个报文段也不能携带数据，但同样要消耗掉一个序号。这时TCP服务器进程进入SYN-RCVD(同步收到)状态。

第三次握手

TCP客户进程收到B的确认之后，还要向B发出确认。确认报文段的ACK置1，确认号ack=y+1。而自己的序号seq=x+1。TCP规定，这个报文段可以携带数据，但如果不携带数据则不消耗序号(不需要对应的确认号)。这时，TCP连接以及建立，A进入ESTABLISHED(已建立连接)状态

当B收到A的确认之后，也进入ESTABLESHED状态

消不消耗序号是根据是否需要对应的TCP确认报文来的。TCP的确认是依据不重复的序号。

为什么TCP要进行第三次握手？

主要是为了防止已失效的连接请求报文段突然又传送到了B发生错误。

 考虑下面情况：

当A传了一次连接请求，出现网络拥塞、报文丢失等情况而长时间留滞。一段时间之后重新到达了B，倘若A不发送确认报文，就会出现B单方面认为已经建立连接，并一直等待A发来数据。这样B的许多资源就被浪费了。

采用三报文握手就可以防止上述现象的发生。

TCP的连接释放

数据传输结束后，通信的双方都可释放连接。现在A和B都处于ESTABLISHED状态。

第一次挥手

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

第二次挥手

B收到连接释放报文段后即发出确认，确认号是ack=u+1，而这个报文段自己的序号是v，等于B前面传送的数据的最后一个字节的序号+1。然后B就进入CLOSE-WAIT(关闭等待状态)。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了。这时TCP的连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。

A接收到B的确认之后，就进入FIN-WAIT-2状态，等待B发出的连接释放报文段

第三次回收

若B没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文使FIN=1。假定B的序号位w。**B必须重复上次已发送过的确认号ack=u+1**。这时B就进入LAST-ACK(最后确认)状态，等待A的确认。

第四次回收

A在收到B的连接释放报文段之后，必须对此发出确认，在确认报文段中把ACK置1，确认号w+1，而自己的序号是seq=u+1。然后进入到TIME-WAIT(时间等待)状态。现在TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命。一般建议为两分钟。

B只要接收A发出的确认就进入CLOSED状态。

时间等待计时器的原因

1. 为了保证A发送的最后一个ACK能够到达B，防止报文段丢失
2. 防止出现上文已失效的连接请求报文段出现在本报文中，2MSL可以让本连接持续时间内所产生的所有报文狗从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

除此之外，TCP还有一个保活计时器来处理客户端突然断开连接的特殊情况。例如，两小时后没有收到客户的数据就每隔75秒发送一次检测报文，连续10次没有响应就判断客户端故障。

TCP的有限状态机