常州建站价格,机加工外贸网站,购物网站成功案例,wordpress 1h 1g运输层协议概述从通信和信息处理的角度看#xff0c;运输层向它上面的应用层提供通信服务#xff0c;它属于面向通信部分的最高层#xff0c;同时也是用户功能中的最低层。当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时#xff0c;只有位于网络…运输层协议概述从通信和信息处理的角度看运输层向它上面的应用层提供通信服务它属于面向通信部分的最高层同时也是用户功能中的最低层。当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时只有位于网络边缘部分的主机的协议栈才有运输层而网络核心部分中的路由器在转发分组时都只用到下三层的功能。应用进程之间的通信在IP层看来通信的两端是两个主机IP数据报的首部明确的标志了这两个主机的IP地址。但是两个主机之间的通信这种说法还不够清楚这是因为真正进行通信的实体是在主机中的进程是两个进程之间在交换数据。从而引出了运输层从运输层的角度看来通信的真正端点并不是主机而是主机中的进程(端到端的通信)。在一个主机中经常有多个应用进程同时分别和另一个主机的多个应用进程通信。这就表明了运输层有一个很重要的功能复用和分用应用层不同进程的报文通过不同的端口向下交到运输层再往下就共用网络层提供的服务。复用指的是发送方不同的应用进程都可以使用同一个运输层协议传输数据(当然要加上适当的首部)分用指的是接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程“运输层提供应用进程间的逻辑通信”。“逻辑通信”的意思是运输层之间的通信好像是沿水平方向传送数据。但事实上这两个运输层之间并没有一条水平方向的物理连接。运输层的主要功能运输层为应用进程之间提供端到端的逻辑通信(但网络层是为主机之间提供逻辑通信)运输层还要对收到的报文进行差错检测。运输层需要有两种不同的运输协议即面向连接的 TCP 和无连接的 UDP两种不同的运输协议运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等)它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道。当运输层采用面向连接的 TCP 协议时尽管下面的网络是不可靠的(只提供尽最大努力服务)但这种逻辑通信信道就相当于一条全双工的可靠信道。当运输层采用无连接的 UDP 协议时这种逻辑通信信道是一条不可靠信道。运输层的两个主要协议TCP/IP 的运输层有两个不同的协议用户数据报协议 UDP(User Datagram Protocol)传输控制协议 TCP(Transmission Control Protocol)TCP与UDP两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元TPDU (Transport Protocol Data Unit)。TCP 传送的数据单位协议是 TCP 报文段(segment)UDP 传送的数据单位协议是 ** UDP 报文或用户数据报**。区别UDP 在传送数据之前不需要先建立连接。对方的运输层在收到 UDP 报文后不需要给出任何确认。虽然 UDP 不提供可靠交付但在某些情况下 UDP 是一种最有效的工作方式。TCP 则提供面向连接的服务。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的、面向连接的运输服务因此不可避免地增加了许多的开销。这不仅使协议数据单元的首部增大很多还要占用许多的处理机资源。还要强调两点运输层的 UDP 用户数据报与网际层的IP数据报有很大区别。IP 数据报要经过互连网中许多路由器的存储转发但 UDP 用户数据报是在运输层的端到端抽象的逻辑信道中传送的。TCP 报文段是在运输层抽象的端到端逻辑信道中传送这种信道是可靠的全双工信道。但这样的信道却不知道究竟经过了哪些路由器而这些路由器也根本不知道上面的运输层是否建立了 TCP 连接。TCP/IP体系中的运输层协议TCP/IP体系中的运输层协议.png运输层的端口运行在计算机中的进程是用进程标识符来标志的。运行在应用层的各种应用进程却不应当让计算机操作系统指派它的进程标识符。这是因为在因特网上使用的计算机的操作系统种类很多而不同的操作系统又使用不同格式的进程标识符。为了使运行不同操作系统的计算机的应用进程能够互相通信就必须用统一的方法对 TCP/IP 体系的应用进程进行标志。需要解决的问题由于进程的创建和撤销都是动态的发送方几乎无法识别其他机器上的进程。有时我们会改换接收报文的进程但并不需要通知所有发送方。我们往往需要利用目的主机提供的功能来识别终点而不需要知道实现这个功能的进程。端口号(protocol port number)简称为端口(port)解决这个问题的方法就是在运输层使用协议端口号(protocol port number)或通常简称为端口(port)。虽然通信的终点是应用进程但我们可以把端口想象是通信的终点因为我们只要把要传送的报文交到目的主机的某一个合适的目的端口剩下的工作(即最后交付目的进程)就由 TCP 来完成。软件端口与硬件端口在协议栈层间的抽象的协议端口是软件端口。路由器或交换机上的端口是硬件端口。硬件端口是不同硬件设备进行交互的接口而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。TCP的端口端口用一个 16 位端口号进行标志(可允许有65535个不同的端口号)。端口号只具有本地意义即端口号只是为了标志本计算机应用层中的各进程。在因特网中不同计算机的相同端口号是没有联系的。由此可见两个计算机中的进程要相互通信不仅要知道对方的IP地址还要知道对方的端口号。三类端口熟知端口(系统端口)数值一般为 0 -1023例如 http 80ftp 21登记端口号数值为1024 - 49151为没有熟知端口号的应用程序使用的。使用这个范围的端口号必须在 IANA 登记以防止重复。客户端口号或短暂端口号数值为49152 - 65535留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时就知道了客户进程所使用的动态端口号。通信结束后这个端口号可供其他客户进程以后使用。用户数据报UDPUDP概述UDP 只在 IP 的数据报服务之上增加了很少一点的功能即端口的功能和差错检测的功能。虽然 UDP 用户数据报只能提供不可靠的交付但 UDP 在某些方面有其特殊的优点。UDP的主要特点UDP 是无连接的即发送数据之前不需要建立连接。UDP 使用尽最大努力交付即不保证可靠交付同时也不使用拥塞控制。UDP 是面向报文的。UDP 没有拥塞控制很适合多媒体通信的要求。无拥塞控制就说明网络出现的拥塞不会使主机发送的速率降低。这对某些实时应用是很重要的(IP电话实时视频会议等)UDP 支持一对一、一对多、多对一和多对多的交互通信。UDP 的首部开销小只有 8 个字节。面向报文的UDP发送方 UDP 对应用程序交下来的报文在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文既不合并也不拆分而是保留这些报文的边界。应用层交给 UDP 多长的报文UDP 就照样发送即一次发送一个报文。接收方 UDP 对 IP 层交上来的 UDP 用户数据报在去除首部后就原封不动地交付上层的应用进程一次交付一个完整的报文。应用程序必须选择合适大小的报文。面向报文的UDP.pngUDP的首部格式UDP的首部格式.png源端口 在需要对方回信时选用不需要时可全用0目的端口长度 UDP用户数据报的长度最小值为8(只由首部)检验和 检验UDP用户数据报在传输中是否有差错有错就丢弃UDP基于端口分用UDP基于端口分用.pngUDP差错检验如果接收方UDP发现收到的报文中的目的端口号不正确(即不存在对应于该端口的号的应用进程)就丢弃该报文并由网际控制报文协议ICMP发送端口不可达差错报文给发送方。在计算检验和时临时把“伪首部”和 UDP 用户数据报连接在一起得到一个临时的数据报它不向下传递也不向上递交。伪首部仅仅是为了计算检验和。UDP计算检验和的方法和IP数据报首部检验和方法相类似。但不同的是IP数据报的检验和只检验IP数据报的首部但UDP的检验和是把首部和数据部分一起检验计算UDP检验和的例子UDP检验和的例子.png在发送方先把全0放入检验和字段再把伪首部以及UDP用户数据报看成是许多16位的字串接起来。若UDP用户报的数据部分不是偶数个字节则要填入一个全零字节(先不发送)。然后按照二进制反码计算出这些16位字的和。将此和的二进制反码写入检验和字段后就发送这样的UDP数据报。在接收方把收到的UDP数据报连通伪首部(以及可能填充全零字节)一起按二进制反码求这些16位字的和。当无差错时其结果应为全1(原本的检验和为0封装成数据报后再次相加的时候就多个检验和反码相加所以无差错时结果为1)。传输控制协议TCP概述TCP最主要的特点TCP 是面向连接的运输层协议建立与释放连接每一条 TCP 连接只能有两个端点(endpoint)每一条 TCP 连接只能是点对点的(一对一)TCP 提供可靠交付的服务。无差错、不重复、不丢失、并且按序到达TCP 提供全双工通信TCP在两端设置了发送和接收缓存面向字节流这里的流指的是流入到进程或从进程流出的字节序列面向字节流的含义是虽然应用程序和TCP的交互是一次一个数据块(大小不等)但TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。TCP并不知道所传输的字节流的含义。TCP并不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应的大小关系(发送发交给发送方TCP10个数据块但接收方的TPC用了4个数据块就把收到的字节流交付上层的应用程序)。但接收方应用程序收到的字节流必须和发送方应用程序发送的字节流完全一样。TCP面向流的概念TCP面向流的概念.png应当注意TCP 连接是一条虚连接而不是一条真正的物理连接。TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的。TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP 发送的报文长度是应用进程给出的)。TCP 可把太长的数据块划分短一些再传送。TCP 也可等待积累有足够多的字节后再构成报文段发送出去。TCP的连接TCP 把连接作为最基本的抽象每一条 TCP 连接有两个端点TCP 连接的端点不是主机不是主机的IP 地址不是应用进程也不是运输层的协议端口。TCP 连接的端点叫做套接字(socket)或插口端口号拼接到(contatenated with) IP 地址即构成了套接字套接字(socket)套接字.png每一条TCP连接唯一地被通信两端的两个端点(即两个套接字)所确定即TCP连接.png同一个名词socket有多种不同的意思应用编程接口 API 称为 socket API, 简称为 socket。socket API 中使用的一个函数名也叫作 socket。调用 socket 函数的端点称为 socket。调用 socket 函数时其返回值称为 socket 描述符可简称为 socket。在操作系统内核中连网协议的 Berkeley 实现称为 socket 实现。可靠传输的工作原理TCP发送的报文段是交给IP层传输的。但IP层只提供尽最大努力服务也就是说TCP下面的网络所提供的是不可靠传输因此TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。可靠传输有以下两个特点传输信道不产生差错不管发送方以多快的速度发送数据接收方总是来得及处理收到的数据在这样的理想传输条件下不需要采取任何措施就能够实现可靠传输。然而实际的网络都不具备以上两个理想的条件。但我们可以使用一些可靠传输协议当出现差错时让发送方重传出现差错的数据同时在接收方来不及处理收到的数据时及时告诉发送方适当的降低发送数据的速度这样一来本来是不可靠的传输信道就能够实现可靠传输。停止等待协议停止等待协议.png在发送完一个分组后必须暂时保留已发送的分组的副本为发生超时重传而使用只有收到相应的确认报文时才能清除暂时保存的副本分组和确认分组都必须进行编号这样才能明确是哪一个发送出去的分组收到了确认而哪一个分组还没收到确认超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些确认丢失和确认迟到确认丢失和确认迟到.png可靠通信的实现使用上述的确认和重传机制我们就可以在不可靠的传输网络上实现可靠的通信这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest)ARQ 表明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组信道利用率停止等待协议的优点是简单但缺点是信道利用率太低。假定AB之间有一条直通的信道来传送分组信道利用率.png这里的TD是A发送分组所需要的时间(显然TD 分组长度 / 数据速率)再假定TA是B发送确认分组所需要的时间(A和B处理分组的时间都忽略不计)那么A在经过TDRTTTA时间后才能发送下一个分组这里的RTT是往返时间因为只有TD是采用来传输有用的数据(这个数据包括了分组首部如果可以知道传输更精确的数据的时间可以计算的更精确)所有信道利用率为信道利用率公式.png为了提高传输效率发送方可以不使用低效率的停止等待协议而是采用流水线传输就是发送方可以连续的发送多个分组不必每发完一个分组就停下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然这种传输方式可以获得很高的信道利用率流水线传输.png当时使用流水线传输时就要使用下面介绍的连续ARQ协议和滑动窗口协议连续ARQ协议滑动窗口协议比较复杂是TCP协议的精髓所在在这里先给出ARQ协议最基本的概念但不涉及到许多细节问题。连续ARQ协议.png位于发送窗口的分组都可以连续的发送出去而不需要等待对方的确认发送方每收到一个确认就把发送窗口向前滑动一个分组的位置。详细可以见P201累计确认接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认而是对按序到达的最后一个分组发送确认这样就表示到这个分组为止的所有分组都已正确收到了。累积确认有的优点是容易实现即使确认丢失也不必重传。缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。Go - back - N(回退N)如果发送方发送了前 5 个分组而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落而只好把后面的三个分组都再重传一次。这就叫做 Go-back-N(回退 N)表示需要再退回来重传已发送过的 N 个分组。可见当通信线路质量不好时连续 ARQ 协议会带来负面的影响。TCP可靠通信的具体实现TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。TCP 的可靠传输机制用字节的序号进行控制。TCP 所有的确认都是基于序号而不是基于报文段。TCP 两端的四个窗口经常处于动态变化之中。TCP连接的往返时间 RTT 也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。TCP报文段的首部格式TCP虽然是面向字节流的但是TCP传送的数据单元却是报文段(可以看上述TCP面向流的概念)而且TCP的全部功能都体现在它的首部中各个字段。TCP报文段的首部格式.png源端口和目的端口字段——各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。(如果不理解可以看P202)确认号字段——占 4 字节是期望收到对方的下一个报文段的数据的第一个字节的序号。例如B正确收到了A发送过来的一个报文段其序号字段值是501而数据长度是200字节(序号501 - 700)这表明B正确收到了A发送的到序号700为止的数据因此B期望收到A的下一个数据序号为701于是B在发送给A的确认报文段中把确认号置位701。总之若确认号为N则表明到N-1为止的所有数据都已正确收到。数据偏移(即首部长度)——占 4 位它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字(以 4 字节为计算单位)。保留字段——占 6 位保留为今后使用但目前应置为 0紧急 URG —— 当 URG 1 时表明紧急指针字段有效。它告诉系统此报文段中有紧急数据应尽快传送(相当于高优先级的数据)确认 ACK —— 只有当 ACK 1 时确认号字段才有效。当 ACK 0 时确认号无效。TCP规定在建立连接后所有传送的报文段都必须把ACK置1推送 PSH (PuSH) —— 接收 TCP 收到 PSH 1 的报文段就尽快地交付接收应用进程而不再等到整个缓存都填满了后再向上交付。复位 RST (ReSeT) —— 当 RST 1 时表明 TCP 连接中出现严重差错(如由于主机崩溃或其他原因)必须释放连接然后再重新建立运输连接。同步 SYN —— 在连接建立时用来同步序号当SYN 1而ACK 0时表明这是一个连接请求报文。对方若同意建立连接则应在响应的报文段中使SYN 1和ACK 1。所以SYN 1 表示这是一个连接请求或连接接受报文。终止 FIN (FINis) —— 用来释放一个连接。FIN 1 表明此报文段的发送端的数据已发送完毕并要求释放运输连接。窗口字段 —— 占 2 字节窗口值是[0,2^16 -1]之间的整数。窗口指的是发送本报文段的一方的接收窗口(而不是自己的发送窗口)。窗口值告诉对方从本报文段首部中的确认号算起接收方目前允许对方发送的数据量。之所以要有这个限制是因为接收方的数据缓存空间是有限的。总之窗口值作为接收方让发送方设置其发送窗口的依据。例如。设确认号是701窗口字段是1000.这就表明从701号算起发送此报文段的一方还有接收1000个字节数据(字节序号701-1700)的接收缓存空间。总之窗口字段指出了现在允许对方发送的数据量。窗口值是经常在动态变化着检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。与UDP一样在计算检验和时要在 TCP 报文段的前面加上 12 字节的伪首部。不同点可以见P204紧急指针字段 —— 占 16 位仅在URG 1时才有意义它指出在本报文段中紧急数据共有多少个字节(紧急数据放在本报文段数据的最前面因此紧急指针指出了紧急数据的末尾在报文段中的位置)。选项字段 —— 长度可变。TCP 最初只规定了一种选项即最大报文段长度 MSS。MSS 告诉对方 TCP“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。” MSS (Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。其他选项窗口扩大选项 ——占 3 字节其中有一个字节表示移位值 S。新的窗口值等于TCP 首部中的窗口位数增大到(16 S)相当于把窗口值向左移动 S 位后获得实际的窗口大小。时间戳选项——占10 字节其中最主要的字段时间戳值字段(4 字节)和时间戳回送回答字段(4 字节)。选择确认选项选项详解请见P205填充字段 —— 这是为了使整个首部长度是** 4 字节**的整数倍。TCP可靠传输的实现以字节为单位的滑动窗口详解请见P206注意图中的后沿前沿以字节为单位的滑动窗口01.png从下图可以看出来要描述一个发送窗口的状态需要三个指针P1P2P3以字节为单位的滑动窗口02.png以字节为单位的滑动窗口03.png以字节为单位的滑动窗口04.png有很多信息见P208这里不赘述发送/接收缓存发送方的应用进程把字节流写入TCP的发送缓存接收方的应用进程从TCP的接收缓存中读取字节流。下面进一步讨论前面讲的窗口和缓存的关系发送缓存发送缓存.png接收缓存接收缓存.png发送与接收缓存的作用发送缓存用来暂时存放发送应用程序传送给发送方 TCP 准备发送的数据TCP 已发送出但尚未收到确认的数据。发送窗口通常只是发送缓存的一部分已被确认的数据应当从发送缓存中删除因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节就是还保留在发送缓存中被写入的字节。发送应用程序必须控制写入缓存的速率不能太快 否则发送缓存就会没有存放数据的空间。接收缓存用来暂时存放按序到达的、但尚未被接收应用程序读取的数据不按序到达的数据。如果收到的分组被检测出有差错则要丢弃。如果接收应用程序来不及读取收到的数据接收缓存最终就会被填满使接收窗口减少到零。反之如果接收应用程序能够及时从接收缓存中读取收到的数据接收窗口就可以增大但最大不能超过接收缓存的大小。需要强调三点A 的发送窗口并不总是和 B 的接收窗口一样大(因为有一定的时间滞后)。TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中等到字节流中所缺少的字节收到后再按序交付上层的应用进程。TCP 要求接收方必须有累积确认的功能这样可以减小传输开销。超时重传时间的选择重传机制是 TCP 中最重要和最复杂的问题之一。TCP 每发送一个报文段就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认就要重传这一报文段。往返时延的方差很大由于 TCP 的下层是一个互联网环境IP 数据报所选择的路由变化很大。因而运输层的往返时间的方差也很大。往返时延的方差很大.png加权平均往返时间RTTTCP才用了一种自适应算法它记录一个报文段发出的时间以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。TCP 保留了 RTT 的一个加权平均往返时间 RTTs(这又称为平滑(smooth)的往返时间因为是加权平均所以是平滑的)。第一次测量到 RTT 样本时RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本就按下式重新计算一次 RTTS加权平均公式.png式中0RFC 2988 推荐的 a 值为 1/8即 0.125。超时重传时间RTO显然RTO 应略大于上面得出的加权平均往返时间 RTTsRFC 2988 建议使用下式计算 RTORTO.pngRTTD 是 RTT 的偏差的加权平均值他与RTTs和新的RTT样本之差有关。RFC 2988 建议这样计算 RTTD。第一次测量时RTTD 值取为测量到的 RTT 样本值的一半。在以后的测量中则使用下式计算加权平均的 RTTDRTTD .pngβ是个小于 1 的系数其推荐值是 1/4即 0.25。往返时间的测量相当复杂TCP 报文段 1 没有收到确认。重传(即报文段 2)后收到了确认报文段 ACK。如何判定此确认报文段是对原来的报文段 1 的确认还是对重传的报文段 2 的确认往返时间的测量相当复杂.pngKarn算法为了解决上面那个问题Karn提出了一个算法在计算平均往返时间 RTT 时只要**报文段重传了就不采用其往返时间样本。这样得出的加权平均平均往返时间 RTTS 和超时重传时间 RTO 就较准确。 **但是这又有了新的问题、设想出现这样的情况报文段的时延突然增大了很多。因此在原来得出的重传时间内不会收到确认报文段。于是就重传报文段。但根据Karn算法不考虑重传的报文段的往返时间样本。这样超时重传时间就无法更新。修正的Karn算法报文段每重传一次就把 RTO 增大一些修正的Karn算法.png系数 γ 的典型值是 2 。当不再发生报文段的重传时才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值。实践证明这种策略较为合理。选择确认SACK(selective ACK)接收方收到了和前面的字节流不连续*的两个字节块(只是未按序号它是无差错的)如果这些字节的序号都在接收窗口之内那么接收方就先收下这些数据但要把这些信息准确地告诉发送方使发送方不要再重复发送这些已收到的数据。接收到不连续的字节流.png和前后字节不连续的每一个字节块都有两个边界左边界和右边界。图中用四个指针标记这些边界。第一个字节块的左边界 L1 1501但右边界 R1 3001。左边界指出字节块的第一个字节的序号但右边界减 1 才是字节块中的最后一个序号。第二个字节块的左边界 L2 3501而右边界 R2 4501。RFC 2018的规定TCP首部并没有哪个字段能提供上述这些字节块的边界信息。如果要使用选择确认那么在建立 TCP 连接时就要在 TCP 首部的选项中加上“允许 SACK”的选项而双方必须都事先商定好。如果使用选择确认那么原来首部中的“确认号字段”的用法仍然不变。只是以后在 TCP 报文段的首部中都增加了 SACK 选项以便报告收到的不连续的字节块的边界。由于首部选项的长度最多只有 40 字节而指明一个边界就要用掉 4 字节因此在选项中最多只能指明 4 个字节块的边界信息。详见P211TCP流量控制利用滑动窗口实现流量控制一般说来我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快接收方就可能来不及接收这就会造成数据的丢失。流量控制(flow control)就是让发送方的发送速率不要太快既要让接收方来得及接收也不要使网络发生拥塞。利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。流量控制举例A 向 B 发送数据。在连接建立时B 告诉 A“我的接收窗口 rwnd 400(字节)”。看下TCP首部窗口字段的用处流量控制举例.png接收方的主机B一共进行了3次流量控制(蓝线)考虑一种情况B向A发送了零窗口的报文段后不久B的接收缓存又有了一些存储空间。于是B向A发送了rwnd 400的报文段然而这个报文段在传输过程中丢失了。A一直等收到B发送非零窗口的通知B也一直等A发送数据来就形成了死锁。下面的持续计时器就是为了打破死锁僵局的持续计时器(persistence timer)TCP 为每一个连接设有一个持续计时器只要 TCP 连接的一方收到对方的零窗口通知就启动持续计时器。若持续计时器设置的时间到期就发送一个零窗口探测报文段(仅携带 1 字节的数据)而对方就在确认这个探测报文段时给出了现在的窗口值。若窗口仍然是零则收到这个报文段的一方就重新设置持续计时器。若窗口不是零则死锁的僵局就可以打破了。必须考虑传输效率应用进程把数据传送到TCP发送缓存后剩下的发送任务就由TCP来控制了。可以用不同的机制来控制 TCP 报文段的发送时机:第一种机制是 TCP 维持一个变量它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时就组装成一个 TCP 报文段发送出去。第二种机制是由发送方的应用进程指明要求发送报文段即 TCP 支持的推送(push)操作。第三种机制是发送方的一个计时器期限到了这时就把当前已有的缓存数据装入报文段(但长度不能超过 MSS)发送出去。至于如何控制发送的 时机 详见P213TCP的拥塞控制拥塞控制的一般原理在某段时间若对网络中某资源的需求超过了该资源所能提供的可用部分网络的性能就要变坏——产生拥塞(congestion)出现资源拥塞的条件 对资源需求的总和 可用资源若网络中有许多资源同时产生拥塞网络的性能就要明显变坏整个网络的吞吐量将随输入负荷的增大而下降。解决拥塞的要点是平衡要让整个系统的性能想匹配(P214)。拥塞控制与流量控制关系密切拥塞控制所要做的都有一个前提就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程涉及到所有的主机、所有的路由器以及与降低网络传输性能有关的所有因素。流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制。流量控制所要做的就是抑制发送端发送数据的速率以便使接收端来得及接收。拥塞控制所起的作用横坐标为提供的负载代表单位时间内输入给网络的分组的数目(也叫作输入负载或网络负载)纵坐标是吞吐量代表单位时间内从网络输出的分组数目。拥塞控制所起的作用.png拥塞控制的一般原理拥塞控制是很难设计的因为它是一个动态的(而不是静态的)问题。当前网络正朝着高速化的方向发展这很容易出现缓存不够大而造成分组的丢失。但分组的丢失是网络发生拥塞的征兆而不是原因。在许多情况下甚至正是拥塞控制本身成为引起网络性能恶化甚至发生死锁的原因。这点应特别引起重视。开环和闭环控制开环控制方法就是在设计网络时事先将有关发生拥塞的因素考虑周到力求网络在工作时不产生拥塞但是系统运行起来就不再中途更正了。闭环控制是基于反馈环路的概念。属于闭环控制的有以下几种措施监测网络系统以便检测到拥塞在何时、何处发生。将拥塞发生的信息传送到可采取行动的地方。调整网络系统的运行以解决出现的问题。检测拥塞的指标由于缺少缓存空间而被丢弃的分组的百分数平均队列长度超时重传的分组数平均分组时延分组时延的标准差等这些指标的上升都标志着拥塞的增长。几种拥塞控制方法慢开始和拥塞避免发送方维持一个叫做拥塞窗口 cwnd (congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。如再考虑到接收方的接收能力则发送窗口还可能小于拥塞窗口。发送方控制拥塞窗口的原则是只要网络没有出现拥塞拥塞窗口就再增大一些以便把更多的分组发送出去。但只要网络出现拥塞拥塞窗口就减小一些以减少注入到网络中的分组数。慢开始算法的原理方便起见我们用报文段的个数作为窗口大小的单位在主机刚刚开始发送报文段时可先设置拥塞窗口 cwnd 1即设置为一个最大报文段 MSS 的数值。在每收到一个对新的报文段的确认后将拥塞窗口加 1即增加一个 MSS 的数值。用这样的方法逐步增大发送端的拥塞窗口 cwnd可以使分组注入到网络的速率更加合理。传播轮次(transmission round)使用慢开始算法后每经过一个传输轮次拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间 RTT。“传输轮次”更加强调把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去并收到了对已发送的最后一个字节的确认。例如拥塞窗口 cwnd 4这时的往返时间 RTT 就是发送方连续发送 4 个报文段并收到这 4 个报文段的确认总共经历的时间。慢开始算法.png设置慢开始门限状态变量 ssthresh慢开始门限 ssthresh 的用法如下当 cwnd ssthresh 时使用慢开始算法。当 cwnd ssthresh 时停止使用慢开始算法而改用拥塞避免算法。当 cwnd ssthresh 时既可使用慢开始算法也可使用拥塞避免算法。拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1而不是加倍使拥塞窗口 cwnd 按线性规律缓慢增长比慢开始算法的拥塞窗口增长速率缓慢很多。网络出现拥塞时无论在慢开始阶段还是在拥塞避免阶段只要发送方判断网络出现拥塞(其根据就是没有按时收到确认)就要把慢开始门限 ssthresh 设置为出现拥塞时的发送方窗口值的一半(但不能小于2)。然后把拥塞窗口 cwnd 重新设置为 1执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。慢开始和拥塞避免算法的实现举例当 TCP 连接进行初始化时将拥塞窗口置为 1。图中的窗口单位不使用字节而使用报文段。慢开始门限的初始值设置为 16 个报文段即 ssthresh 16。发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大因此现在发送窗口的数值等于拥塞窗口的数值。慢开始和拥塞避免算法的实现举例.png下面的执行步骤就是按照折现上的点的顺序在执行慢开始算法时拥塞窗口 cwnd 的初始值为 1发送第一个报文段 M0。发送端每收到一个确认 就把 cwnd 加 1。于是发送端可以接着发送 M1 和 M2 两个报文段。接收端共发回两个确认。发送端每收到一个对新报文段的确认就把发送端的 cwnd 加 1。现在 cwnd 从 2 增大到 4并可接着发送后面的 4 个报文段。发送端每收到一个对新报文段的确认就把发送端的拥塞窗口加 1因此拥塞窗口 cwnd 随着传输轮次按指数规律增长。当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时(即当 cwnd 16 时)就改为执行拥塞避免算法拥塞窗口按线性规律增长。假定拥塞窗口的数值增长到 24 时网络出现超时表明网络拥塞了。更新后的 ssthresh 值变为 12(即发送窗口数值 24 的一半)拥塞窗口再重新设置为 1并执行慢开始算法。当 cwnd 12 时改为执行拥塞避免算法拥塞窗口按按线性规律增长每经过一个往返时延就增加一个 MSS 的大小。乘法减小(multiplicative decrease)“乘法减小“是指不论在慢开始阶段还是拥塞避免阶段只要出现一次超时(即出现一次网络拥塞)就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5。当网络频繁出现拥塞时ssthresh 值就下降得很快以大大减少注入到网络中的分组数。加法增大(addictive increase)“加法增大”是指执行拥塞避免算法后在收到对所有报文段的确认后(即经过一个往返时间)就把拥塞窗口 cwnd增加一个 MSS 大小使拥塞窗口缓慢增大以防止网络过早出现拥塞。要指出“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。“拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长使网络比较不容易出现拥塞。快重传和快恢复快重传快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认。这样做可以让发送方及早知道有报文段没有到达接收方。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段。不难看出快重传并非取消重传计时器而是在某些情况下可更早地重传丢失的报文段。快重传举例.png对上图的解释请见P220快恢复算法与快重传配合使用的还有快恢复算法当发送端收到连续三个重复的确认时就执行“乘法减小”算法把慢开始门限 ssthresh 减半。但接下去不执行慢开始算法。由于发送方现在认为网络很可能没有发生拥塞因此现在不执行慢开始算法即拥塞窗口 cwnd 现在不设置为 1而是设置为慢开始门限 ssthresh 减半后的数值然后开始执行拥塞避免算法(“加法增大”)使拥塞窗口缓慢地线性增大。从连续收到三个重复的确认传入拥塞避免(下图)从连续收到三个重复的确认传入拥塞避免.png发送窗口的上限值发送方的发送窗口的上限值应当取为接收方窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个即应按以下公式确定发送窗口的上限值.png当 rwnd cwnd 时是接收方的接收能力限制发送窗口的最大值。当 cwnd rwnd 时则是网络的拥塞限制发送窗口的最大值。随机早期检测RED(Random Early Detection)背景见P221使路由器的队列维持两个参数即队列长度最小门限 THmin 和最大门限 THmax。RED 对每一个到达的数据报都先计算平均队列长度 LAV。若平均队列长度小于最小门限 THmin则将新到达的数据报放入队列进行排队。若平均队列长度超过最大门限 THmax则将新到达的数据报丢弃。若平均队列长度在最小门限 THmin 和最大门限THmax 之间则按照某一概率 p 将新到达的数据报丢弃。随机早期检测RED.png随机早期检测的随机就提现在3中也就说RED不是等到已经发生网络拥塞后才把所有在队列尾部的分组全部丢弃而是在检测到网络拥塞的早期征兆时(即路由器的平均队列长度超过一定的门限值时)就先以概率p随机丢弃个别的分组让拥塞控制只在个别的TCP连接上进行因而避免发生全局性的拥塞控制。最小门限应该足够大以保证连接路由器的输出链路有较高的利用率。而最大门限和最小门限的差也应该足够大使得在一个TCP往返时间RTT中队列的正常增长仍在最大门限之内。经验证明最大门限等于最小门限的两倍是合适的丢弃概率 p 与 THmin 和 Thmax 的关系当 LAV Thmin 时丢弃概率 p 0。当 LAV Thmax 时丢弃概率 p 1。当 THmin LAV THmax时 0 p 1 。例如按线性规律变化从 0 变到 pmax丢弃概率 p 与 THmin 和 Thmax 的关系 .png为什么要用平均队列长度我们知道计算机数据具有突发性的特点因此路由器中的队列长度经常会出现很快的起伏变化。如果丢弃概率p按照瞬时队列长度来计算那就可能会出现一些不合理的现象。例如很短的突发数据不大可能使队列溢出因此对于这种数据如果仅因为瞬时队列长度超过了门限值THmin就将其丢弃就会产生不必要的拥塞控制下图也说明了这一点平均队列长度和瞬时队列长度的区别.png平均队列长度以及p的计算见P223TCP运输连接管理运输连接的三个阶段运输连接就有三个阶段即连接建立、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常地进行。连接建立过程中要解决以下三个问题要使每一方能够确知对方的存在。要允许双方协商一些参数(如最大报文段长度最大窗口大小服务质量等)。能够对运输实体资源(如缓存大小连接表中的项目等)进行分配。客户 - 服务器方式TCP连接的建立都是采用客户端服务器的方式主动发起连接建立的应用进程叫做客户(client)被动等待连接建立的应用进程叫做服务器(server)TCP的连接建立(三次握手)三次握手.png本节在P225B的TCP服务器进程先创建传输控制块TCB(transmission control block存储了每一个连接中的一些重要信息TCP连接表到发送和接收缓存的指针到重传队列的指针当前的发送和接收序号等等)准备接受客户进程的连接请求。然后服务器进程就处于LISTEN(收听)状态等待客户的连接请求。如果有就作出响应A的TCP客户进程也是首先创建传输控制块TCB然后A 的 TCP 向 B 发出连接请求报文段其首部中的同步位 SYN 1并选择序号 seq x表明传送数据时的第一个数据字节的序号是 x。B 的 TCP 收到连接请求报文段后如同意则发回确认。B 在确认报文段中应使 SYN 1使 ACK 1其确认号ack x 1自己选择的序号 seq y。A 收到此报文段后向 B 给出确认其 ACK 1确认号 ack y 1。A 的 TCP 通知上层应用进程连接已经建立。B 的 TCP 收到主机 A 的确认后也通知其上层应用进程TCP 连接已经建立。三次握手建立TCP连接的各状态三次握手建立TCP连接的各状态.png“三次”握手的原因为什么A还要再发送一次数据呢主要是为了防止已失效的连接请求报文段突然又传送到了B因而产生错误。所谓的“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。A发送了连接请求但是因为连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认建立了连接。数据传输完毕后就释放了连接。A共发送了两个连接请求报文段其中第一个丢失第二个到达了B。没有“已失效的连接请求报文段 ”现假定出现一种异常情况即A发出的第一个连接请求报文段并没有丢失而是在某些网络结点长时间滞留了以至延误到连接释放后才到达B。本来这是一个早已经失效的报文段。但B收到此失效的连接请求报文后就误认为是A又发来一次新的连接请求。于是就向A发送确认报文同意建立连接。假定不采用三次握手那么只要B发出确认新的连接就建成了。由于现在A并没有建立连接的请求因此并不会理睬B的确认也不会向B发送数据但是B却以为连接已经建立并一直等待A发送数据B的许多资源就这样白白浪费了。采用三次握手就可以防止上述现象的发生。例如在刚才的情况下A不会向B的确认发出确认B由于收不到第三次握手就知道A并没有要求建立连接。TCP连接的释放(四次握手)TCP连接的释放.png数据传输结束后通信的双方都可释放连接。现在 A 的应用进程先向其 TCP 发出连接释放报文段并停止再发送数据主动关闭 TCP连接。A 把连接释放报文段首部的 FIN 1其序号seq u(等于A前面传输的最后一个字节号1)等待 B 的确认。B 发出确认确认号 ack u 1而这个报文段自己的序号 seq v(等于B前面传输的最后一个字节号1)。TCP 服务器进程通知高层应用进程。从 A 到 B 这个方向的连接就释放了TCP 连接处于半关闭状态。B 若发送数据A 仍要接收。若 B 已经没有要向 A 发送的数据其应用进程就通知 TCP 释放连接序号为seq w(在半关闭状态可能又发送了一些数据) ack u1(B还必须记录上次已发送的确认号)。A 收到连接释放报文段后必须发出确认。在确认报文段中 ACK 1确认号 ack w 1自己的序号 seq u 1。TCP 连接必须经过时间 2MSL (最长报文寿命)后才真正释放掉。A必须等待2MSL的时间第一为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个报文段有可能丢失因为使得处于LAST-ACK状态的B收不到对已发送的FINACK报文段的确认。B会超时重传这个FINACK报文段而A就能在这2MSL时间内收到这个重传的FINACK报文段接着A重传一次确认重新启动2MSL计时器直到双方都关闭。第二防止 “已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后再经过时间 2MSL就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。除时间等待计时器外TCP还设有一个保活计时器设想有这样的情况客户已主动与服务器建立了TCP连接。但后来客户端的主机出现了故障。显然服务器以后就不再收到客户发来的数据因此应当有措施使得服务器不会白白等下去。这就是使用保活器时间设置通常为两小时服务器每收到一次客户的数据就重新设置保活器。若两小时每收到客户的数据服务器就发送一个嗅探报文段以后则每隔75分钟发送一次若一连发送10个嗅探报文后客户端仍无响应服务器就认定客户端发送故障就关闭这个连接。TCP有限状态机TCP 有限状态机的图中每一个方框都是 TCP 可能具有的状态。每个方框中的大写英文字符串是 TCP 标准所使用的 TCP 连接状态名。状态之间的箭头表示可能发生的状态变迁。箭头旁边的字表明引起这种变迁的原因或表明发生状态变迁后又出现什么动作。图中有三种不同的箭头。粗实线箭头表示对客户进程的正常变迁。粗虚线箭头表示对服务器进程的正常变迁。另一种细线箭头表示异常变迁。TCP有限状态机.png
