tcp协议和udp协议

tcp协议和udp协议内容摘要：

度是指总长度，包括 kind 字节和 len 字节。 设置无操作选项的原因是在于允许发方填充字段为 4 字节的倍数。 其它 kind 值为 6 和 7 的四个选项称为 ACK 及回显选项。 由于回显选项已经被时间戳选项取代，而目前定义的选择 ACK 选项仍未定论，而且并未包括在 RFC1323 中。 （主动关闭） FIN_WAIT_1 （主动关闭） FIN_WAIT_1 CLOSING TIME_WAIT CLOSING TIME_WAIT FIN J FIN K ack K+1 ack J+1 图 28 同时关闭时的报文段交换 选项表结束： kind=0 1 字节 TCP 的性能 TCP 已经在从 1200b/s 的拨号 SLIP 链路到以太数据链路上运行了许多年。 在 80 年代和90 年代初期，以太网是运行 TCP/IP 最主要的数据链路方式。 尽管 TCP 在比以太网速率高的环境（如 T2 电话线、 FDDI 等）下也能够正常运行，但在这些高速网络环境下， TCP 的某些限制就会暴露出来。 下面介绍关于 TCP 的一些修改建议，这些建议可以使 TCP 在高速率网络环境下获得最大的吞吐量。 路 径 MTU 发现 每个网络中的数据链路层对数据单元的长度都有一个限制，例如对于以太网，它的最大值是 1518 字节。 链路层的这个特性称为最大传输单元（ MTU），不同类型的网络大多数都有一个上限。 当在同一个网络上的两台主机互相进行通信时，该网络的 MTU 是十分重要的。 如果两台主机的通信要通过多个网络，那么每个网络的链路层可能有不同的 MTU。 在这里，重要的不是两台主机所在网络的 MTU 值，而是两台通信主机路径中的最小 MTU，它被称为路径 MTU。 路径 MTU 是决定主机之间通信性能的重要因素。 两台主机之间的路径 MTU 不一定 是一个常数，它取决于当时路由算法所选择的路由。 而选路不一定是对称的（从节点 A 到节点 B 的路由可能与节点 B 到节点 A 的路由不同），因此路径 MTU 在通信两个方向上不一定是相同的。 RFC1191 文件描述了路径 MTU 的发现机制，即在任何时候确定路径 MTU 的方法。 这是在两个主机之间的路径上任何网络上的最小 MTU。 路径 MTU 发现在 IP 首部中继承并设置“不要分片（ DF）”比特，来发现当前路径上的路由器是否需要对正在发送的 IP 数据报进行分片。 如果一个待转发的 IP数据报被设置 DF比特，而其长度又超过了 MTU，那么路由器将返回 ICMP 不可达的差错。 目前的操作系统只有少数支持路径 MTU 发现，例如 Solaris 支持路径 MTU 发现，将来会有越来越多的操作系统支持这个功能。 TCP 的路径 MTU 发现按如下方式进行：在建立 TCP 连接时， TCP 使用输出接口或对端声明的 MSS 中的最小 MTU 作为起始的报文段大小。 路径 MTU 的发现不允许 TCP 超过对端声明的MSS。 如果对端没有指定一个 MSS，则默认值为 536。 一旦选定了起始的报文段大小，在该连接上的所有被 TCP 发送的 IP 数据报都将被设置无操作： Kind=1 1 字节 kind=2 最大报文段长度： len=4 最大报文段长度 1 字节 1 字节 2 字节 窗口扩大因子： kind=3 len=3 移位数 1 字节 1 字节 1 字节 时间戳： kind=8 len=10 时间戳值 时间戳回显应答 1 字节 1 字节 4 字节 4 字节 图 29 TCP 新选项 DF 比特。 如果某个中间路由器需要对一个设置了 DF 标志 的数据报进行分片，它就丢弃这个数据报，并产生一个 ICMP 的“不能分片”差错。 如果收到一个“不能分片”的 ICMP 差错， TCP 就减少段大小并进行重传。 如果路由器产生的是一个较新的该类 ICMP 差错，则报文段大小设置为下一跳的 MTU 减去 IP和 TCP 的首部长度。 如果是一个较旧的该类 ICMP 差错，则必须尝试下一个可能的最小 MTU。 当由这个ICMP 差错引起的重传发生时，拥塞窗口不需要变化，但要启动慢启动。 由于路由经常动态变化，因此在最后一次减少路径 MTU 的一段时间以后，可以尝试使用一个较大的值（直到等于对端声明的 MSS 或输出接口 MTU 的最小值）。 RFC1191 推荐这个时间间隔为 10 分钟，操作系统 Solaris 使用的时间间隔是 30 分钟。 在对非本地目的地。 默认的 MSS 通常是 536 字节，路径 MTU 发现可以避免在通过 MTU 小于 576（这非常罕见）的中间链路时进行分片。 对于本地目的主机，也可以避免在中间链路（如以太网）的 MTU 小于端点网络（如令牌环）的情况下进行分片。 但为了能使路径 MTU 更加有用和充分利用 MTU 大于 576 的广域网，一个实现必须停止使用为非本地目的制定的 536的 MTU默认值。 MSS的一个较好的选择是输出接 口的 MTU（当然要减去 IP 和 TCP的首部大小），大多数系统的实现都允许系统管理员改变这个默认的 MSS 值。 假定分组的大小不足以引起分片，常规知识告诉我们传输较大的分组的性能比较好，因为发送较少的大分组比发送较多的小分组开销要少。 这些开销的减少与网络（分组首部负荷）、路由器（选路的决定）和主机（协议处理和设备中断）等诸多因素有关。 长肥管道 通常，一个 TCP 连接的容量表示为： capacity(b)=bandwidth(b/s)*roundtrip times(s) 这个公式称为带宽时 延乘积，也称它为两端的管道大小，它的单位是字节，可以用这个值来测量每一端的缓存大小和窗口大小。 这个值依赖于网络速度和两端的 RTT（ roundtrip times），可以有很大的变动范围。 当这个乘积变得越来越大时， TCP 的某些局限性就会暴露出来。 表 22 列出了一些典型网络的某些数值。 表 22 典型网络的带宽时延乘积 网络 带宽（ b/s） RTT(ms) 带宽时延乘积（字节） 以太局域网 10000000 3 3750 横跨大陆的 T1 电话线 1544000 60 11580 卫星 T1 电话线 1544000 500 96500 横跨大陆的 T3 电话线 45000000 60 337500 横跨大陆的 gigabit 线路 1000000000 60 7500000 具有大的带宽时延乘积的网络称为长肥网络（ Long Fat Network，即 LFN），而一个运行在 LFN 上的 TCP 连接称为长肥管道，这种管道可以被水平拉长（一个长的 RTT），或被垂直拉高（较高的带宽），或向两个方向拉伸。 使用长肥管道会遇到多种问题，主要有：  TCP 首部中窗口大小为 16bit，从而将窗口限制在 65535 个字节范围内，但是从 表122 最后一列可以看到，现有的网络需要一个更大的窗口来提供最大的吞吐量。 这个问题使用窗口扩大选项可以解决。  在一个长肥网络 LFN 内的分组丢失会使网络吞吐量急剧减少。 如果只有一个报文段丢失，可以使用快速重传和快速恢复算法来使管道避免耗尽。 但是，即使使用这些算法，在一个窗口内发生的多个分组丢失也会使管道耗尽（如果管道耗尽了，慢启动会使它渐渐填满，但这个过程将需要多个 RTT）。 在 RFC1072 中建议使用有选择的确认（ SACK）来处理在一个窗口发生的多个分组丢失。  许多 TCP 实现对每个窗口的 RTT 仅进行一次测量。 它们并不对每个报文段进行 RTT测量。 在一个长肥网络 LFN 上需要更好的 RTT 测量机制。 通常使用时间戳选项来解决这个问题，它允许更多的报文段被计时。  TCP 对每个字节数据使用一个 32bit 无符号的序号进行标识。 如果在网络中有一个被延迟一段时间的报文段，它所在的连接已经释放，而一个新的连接在这两个主机之间又建立了，这种情形将产生报文段的再次出现问题。 解决这个问题的主要方法是使用 TCP 时间戳选项的 PAWS（ Protection Against Wrapped Sequence numbers）算法（保护回绕的序号 ）。 窗口扩大选项 窗口扩大选项使 TCP 的窗口定义从 16bit 增加为 32bit。 这种扩展不是通过修改 TCP 首部来实现的， TCP 的首部仍然使用 16bit，而是通过定义一个选项实现对 16bit 的扩大操作（ Scaling Operation）来完成的。 这样 TCP 在内部将实际的窗口大小维持为 32bit 的值。 这个选项只能出现在一个 SYN 报文段中，因此当 TCP 连接建立起来后，在每个方向的扩大因子是固定的。 为了使用窗口扩大选项，通信双方必须在它们的 SYN 报文段中发送这个选项。 TCP 连接的发起方在其 SYN 报文中发送这个选项，但是 TCP 连接的接收方只能够在收到带有这个选项的 SYN 之后才可以发送这个选项。 每个方向的扩大因子可以不同。 如果 TCP 连接的发起方发送一个非零的扩大因子，但是没有从连接的另一端收到一个窗口扩大选项，它就将发送和接收的移位计数器置为 0。 这样就允许新的系统能够与较旧的、不理解新选项的系统进行互操作。 假定正在使用窗口扩大选项，发送移位计数为 S，而接收移位计数为 R。 这样，从另一端收到的每一个 16bit 的通告窗口将被左移 R 位以获得实际的通告窗口大小。 每次当向对方发送一个窗口通告的时候，将实际 的 32bit 窗口大小右移 S 比特，然后用它来替换 TCP 首部中的 16bit 的值。 TCP 根据接收缓存的大小自动选择移位计数。 缓存的大小由系统设置，但是通常向应用进程提供了修改途径。 时间戳选项 时间戳选项使发送方在每个报文段中放置一个时间戳值。 接收方在确认中返回这个数值，从而允许发送方为每一个收到的 ACK 计算 RTT（ TCP 通常使用一个 ACK 来确认多个报文段）。 目前许多 TCP 实现为每一个窗口只计算一个 RTT，对于包含 8 个报文段的窗口这是正确的。 然而，较大的窗口大小需要进行更好的 RTT 计算。 时间戳是一个单调递增的值。 由于接收方只需要回显收到的内容，因此不需要关注时间戳单元是什么。 这个选项不需要在两个主机之间进行任何形式的时钟同步。 RFC1323 中推荐在 1 毫秒和 1 秒之间将时间戳的值加 1。 系统在启动时将时间戳的值设置为 0，然后每隔 500 毫秒将时间戳值加 1。 在 TCP 连接建立阶段，对这个选项的规定与窗口扩大选项类似。 TCP 连接的发起方在它的 SYN 报文中指定选项。 只有在它从另一方的 SYN 报文中收到了这个选项之后，该选项才会在以后的报文段中进行设置。 接收方 TCP 通常不需要对每个包含数据的报 文段进行确认，许多 TCP 实现每两个报文段发送一个 ACK。 为了减少连接双方所维持的状态变量，对于每个连接只维持一个时间戳的数值。 选择何时更新这个数值的算法非常简单： 1． TCP 跟踪下一个 ACK 中将要发送的时间戳的值（一个名为 tsrecent 的变量）以及最后发送的 ACK 中的确认序号（一个名为 lastack 的变量）。 这个序号就是接收方期望的序号。 2． 当一个包含有字节号 lastack 的报文段到达时，则该报文段中的时间戳被保存在 tsrecent 中。 3． 无论何时发送一个时间戳选项， tsrecent 就作为时间戳回显应答字段被发 送，而序号字段被保存在 lastack 中。 T/TCP：为事务用的 TCP扩展 TCP 提供的是一种虚电路方式的传输服务。 一个连接的生存时间包括三个不同的阶段：建立连接、数据传输和释放连接。 这种虚电路服务非常适合诸如文件传输之类的应用。 但是，还有其他的网络应用进程被设计成使用事务（ transaction）服务。 一个事务就是符合下面这些特征的一个客户请求及其随后的服务员响应。 1． 应该避免连接建立和连接释放的开销，在可能的时候，发送一个请求分组并接收一个应答分组。 2． 等待时间应当减少到等于 RTT（ RoundTrip Time）与 SPT（ Server Processing Time）之和。 3． 服务员应当能够检测出重复的请求，并且当收到一个重复的请求时不重新处理事务。 使用这种类型服务的典型例子是域名系统（ DNS），尽管域名系统与服务员重新处理重复的请求无关。 TCP 提供了过多的事务特征，而 UDP 则不够。 通常应用程序为了避免 TCP 连接的开销而使用 UDP 来构造，而许多必要的特征（如拥挤避免等）被放置在应用层实现，从而导致了这些特征的重新设计和实现。 一个较好的解决方法是提供一个能够提供足够多的事务处理功 能的传输层。 T/TCP 协议就是这种方法的一个实现， RFC1379 文档对它进行了介绍。 TCP 为处理事务而需要进行的两个改动是为了避免三次握手和缩。