tcp的可靠性(tcp的可靠性采用的策略是)

前文： 网络协议一、协议1、HTTP协议:基于TCP连接的，主要解决如何包装数据，对应于应用层;2、TCP/UDP协议:主要解决数据如何在网络中传输，对应于传输层;3、IP协议:对应于网络层;· 在传输数据时，可以只使用传输层（TCP/IP），但是那样的话，由于没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用应用层协议，应用层协议很多，有HTTP、FTP、TELNET等等，也可以自己定义应用层协议。· web使用HTTP作传输层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发送到网络上。· TCP/IP:传输层协议，主要解决数据如何在网络中传输。TCP（TransmissionControl Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。UDP是User Datagram Protocol，一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。可靠性由上层应用实现，所以要实现udp可靠性传输，必须通过应用层来实现和控制。确认机制、重传机制、滑动窗口。1．应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据长度将保持不变。由TCP传递给IP的信息单位称为报文段或段（segment）。2．当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当TCP收到发自TCP连接另一端的数据，它将发送一个确认。TCP有延迟确认的功能，在此功能没有打开，则是立即确认。功能打开，则由定时器触发确认时间点。3．TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。4．既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。5．既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。[2]6．TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。TCP协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重传，如果在重传超时前收到确认(Acknowlegement)就关闭该重传，如果重传超时前没有收到确认，则重传该数据段。在选择重发时间的过程中，TCP必须具有自适应性。它需要根据互联网当时的通信情况，给出合适的重发时间。这种重传策略的关键是对定时器初值的设定。采用较多的 算法 是Jacobson于1988年提出的一种不断调整超时时间间隔的动态算法。其工作原理是：对每条连接TCP都保持一个变量RTT（Round Trip Time），用于存放当前到目的端往返所需要时间最接近的估计值。当发送一个数据段时，同时启动连接的定时器，如果在定时器超时前确认到达，则记录所需要的时间（M），并修正[2]RTT的值，如果定时器超时前没有收到确认，则将RTT的值增加1倍。通过测量一系列的RTT（往返时间）值，TCP协议可以估算数据包重发前需要等待的时间。在估计该连接所需的当前延迟时通常利用一些统计学的原理和算法（如Karn算法），从而得到TCP重发之前需要等待的时间值。TCP的一项功能就是确保每个数据段都能到达目的地。位于目的主机的TCP服务对接受到的数据进行确认，并向源应用程序发送确认信息。使用数据报头序列号以及确认号来确认已收到包含在数据段的相关的数据字节。TCP在发回源设备的数据段中使用确认号，指示接收设备期待接收的下一字节。这个过程称为期待确认。源主机在收到确认消息之前可以传输的数据的大小称为窗口大小。用于管理丢失数据和流量控制。UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。实现确认机制、重传机制、窗口确认机制。如果你不利用 Linux 协议栈以及上层socket机制，自己通过抓包和发包的方式去实现可靠性传输，那么必须实现如下功能：发送：包的分片、包确认、包的重发接收：包的调序、包的序号确认目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。RUDP 提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等，从而在包丢失和网络拥塞的情况下， RTP 客户机（实时位置）面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时，可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为。实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么 RTP 可以使用该组播表传输数据到多个目的地。RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于底层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。基于UDP的数据传输协议（UDP-basedData Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。本文来自地址：https://blog.csdn.net/gettogetto/article/details/76736365

1、检验和 TCP检验和的计算与UDP一样，在计算时要加上12byte的伪首部，检验范围包括TCP首部及数据部分，但是UDP的检验和字段为可选的，而TCP中是必须有的。2、序列号TCP将每个字节的数据都进行了编号，这就是序列号。序列号的作用：数据传输过程中的确认应答处理、重发控制以及重复控制等功能都可以通过序列号来实现。TCP在发送数据时，并不是按顺序发送的，发送出去的数据包也不能保证按序到达（网络的不确定性）。接收端接收到数据之后，按序号排序，如果中间某个数据报丢失了，之后的数据报还是会被接收，但是不会对发送端返回之后的确认，而是会重复发送对丢失出之前的数据确认，保证发送端会对丢失的数据段进行重发。保证数据的按序组装TCP规定，在确认报文里，若确认号=N，意思是告诉发送者，到序号N-1为止的所有数据都已经正确的收到，下次你从N开始发送建立连接时，双方发送的SYN报文和ACK报文段都是不携带数据的，但是会消耗一个序号，这个序号通常是随机值TCP规定，首部中序号字段的值是本报文段发送数据的第一个字节的序号。3、确认应答机制（ACK）TCP通过确认应答机制实现可靠的数据传输。在TCP的首部中有一个标志位——ACK，此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认，当标志位ACK=1时确认首部的确认字段有效。进行确认时，确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文，则继续传输下一部分数据；而如果等待了一定时间还没有收到确认报文就会启动重传机制。正常情况下的应答机制：4、超时重传机制当报文发出后在一定的时间内未收到接收方的确认，发送方就会进行重传（通常是在发出报文段后设定一个定时器，到点了还没有收到应答则进行重传），其基本过程如下：当然，未收到确认不一定就是发送的数据包丢了，还可能是确认的ACK丢了：当接收方接收到重复的数据时就将其丢掉，重新发送ACK。而要识别出重复的数据，就要用到前面提到的序列号了，利用序列号很容易就可以做到去重的效果。重传时间的确定：报文段发出到收到应答中间有一个报文段的往返时间RTT，显然超时重传时间RTO会略大于这个RTT，TCP会根据网络情况动态的计算RTT，即RTO是不断变化的。在Linux中，超时以500ms为单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。其规律为：如果重发一次仍得不到应答，就等待2500ms后再进行重传，如果仍然得不到应答就等待4500ms后重传，依次类推，以指数形式递增，重传次数累计到一定次数后，TCP认为网络或对端主机出现异常，就会强行关闭连接。超时重传的过程：放置片段到重传队列中，启动计时器：TCP在发送包含数据的片段后，片段都会被复制一份并放在重传队列中，然后启动计时器。确认处理：如果在计时器超时之前收到确认信息，就把该片段从重传队列中移除超时重传：如果在计时器超时之前没有收到确认信息，则相应片段被重新发送给对方，即重传机制，但是TCP也不能保证重传报文的可靠性，所以该报文依然会处于重传队列中，并重新计时，如果还是超时，则重复这一动作，而且超时时间会设置的较之前长，但是TCP只会重传一定数量的次数，因此当超过这个次数时，TCP会检查故障并断开连接这个等待的时间被称为RTO，RTO也是根据RTT（传输往返时间）来确定的，也和当时网络的状态有关系，需要通过具体算法实现，不是确定值如果超时时间设置的太长，会影响整体的重传效率如果超时时间设置的太短，会频繁发送很多重复的包去重：当主机B的确认报文丢失时，主机A没有收到相应的确认报文，就会重传，主机B会收到重复的报文，TCP会根据报文中的序列号来移除重复收到的报文。5、连接管理机制连接管理机制即TCP建立连接时的三次握手和断开连接时的四次挥手。 首先三次握手：

TCP的可靠性是通过以下几个规则来实现的。 首先，为了防止数据在传输的过程中被损坏，每个信息包都包含一个校验码，这个校验码头就是一个用来保证信息包在传输过程中没有被更改的代码，当信息到达目的地的时候，接收方会对比较验码和收到的信息中的数据，如果校验码不对，则被信息包将被省略。第二，为了防止信息包丢失，TCP会要求接收方每收到一个信息包都反馈一下，如果接收方没有提供反馈，发送方会自动重发一次，一直到接收方收到为止，或者它会判断网络链接断开了，就会在程序中返回一个错误的提示。 第三，为了防止信息包重复或顺序错误，TCP每传送一个信息包都会传送一个序号，接收方会检查这个序号，确保收到该信息包，并把全部信息包按顺序重新合并，同时，如果接收方看到一个已接收了的序号，则这个信息包就会被丢弃。
TCP通过下列方式来提供可靠性： •应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据报长度将保持不变。由TCP传递给IP的信息单位称为报文段或段（segment）TCP如何确定报文段的长度。•当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。在第21章我们将了解TCP协议中自适应的超时及重传策略。•当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒•TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。•既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。•既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。•TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。两个应用程序通过TCP连接交换8bit字节构成的字节流。TCP不在字节流中插入记录标识符。我们将这称为字节流服务（bytestreamservice）。如果一方的应用程序先传10字节，又传20字节，再传50字节，连接的另一方将无法了解发方每次发送了多少字节。收方可以分4次接收这80个字节，每次接收20字节。一端将字节流放到TCP连接上，同样的字节流将出现在TCP连接的另一端。另外，TCP对字节流的内容不作任何解释。TCP不知道传输的数据字节流是二进制数据，还是ASCII字符、EBCDIC字符或者其他类型数据。对字节流的解释由TCP连接双方的应用层解释。 这种对字节流的处理方式与Unix操作系统对文件的处理方式很相似。Unix的内核对一个应用读或写的内容不作任何解释，而是交给应用程序处理。对Unix的内核来说，它无法区分一个二进制文件与一个文本文件。

数据到达接收方，接收方需要发出一个确认应答，表示已经收到该数据段，并且确认序号会说明它下一次需要接受的数据序列号。 如果发送方迟迟未收到应答，那么可能是发送的数据丢失，也可能是确认应答丢失，这时发送方在等待一定时间后会进行重传，这个时间一般是2*RTT（报文往返时间）+一个偏差值。TCP会利用窗口控制来提高传输速度，意思是在一个窗口大小内，不用一定要等到应答才能发送下一段数据，窗口大小就是无需等待确认而可以继续发送的数据的最大值。如果不适用窗口控制，每一个未收到确认应答的数据都要重发。使用窗口控制，如果数据段1001-2000丢失，后面数据每次传输，确认应答都会不停地发送序号为1001的应答，表示我要接受1001开始的数据，发送端如果收到3次相同应答，就会立刻进行重发。但还有种情况可能是数据都收到了，但是有的应答丢失了，这种情况不会进行重发，因为发送端知道，如果数据段丢失，接收端不会放过它的，会疯狂向它提醒。如果把窗口定的很大，发送端连续发送大量的数据，可能会造成网络的拥堵，甚至造成网络的瘫痪。TCP为了防止这种情况而进行了拥塞控制。1.慢启动：定义拥塞窗口，一开始将该窗口的大小设为1，之后每次收到确认应答（经过一个RTT），将拥塞窗口大小*2.2.拥塞避免：设置慢启动阈值，一般开始都设为65536。拥塞避免是指当拥塞窗口大小达到这个阈值，拥塞窗口的值不再指数上升，而是加法增加(每次确认应答/每个RTT，拥塞窗口大小+1），一次来避免拥塞。将报文段的超时重传看作拥塞，则一旦发生超时重传，我们需要先将阈值设为当前窗口大小的一般，并且将窗口大小设为初值1，然后重新进入慢启动过程。3.快速重传：在遇到3次重复确认应答（告诉重发控制）时，代表收到了3个报文段，但是这之前的1个段丢失了，便对它进行立即重传。然后，先将阈值设为当前窗口大小的一般，然后将拥塞窗口大小设为慢启动阈值+3的大小。 这样可以达到：在TCP通信时，网络吞吐量呈现逐渐的上升，并且随着拥堵来降低吞吐量， 再进入慢慢上升的过程，网络不会轻易的发生瘫痪。

TCP提供一种面向连接的、可靠的字节流服务。面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据包之前必须先建立一个TCP连接。这一过程与打电话很相似，先拨号振铃，等待对方摘机说“喂”，然后才说明是谁。在一个TCP连接中，仅有两方进行彼此通信。广播和多播不能用于TCP。TCP通过下列方式来提供可靠性：1．应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据长度将保持不变。由TCP传递给IP的信息单位称为报文段或段（segment）。2．当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当TCP收到发自TCP连接另一端的数据，它将发送一个确认。TCP有延迟确认的功能，在此功能没有打开，则是立即确认。功能打开，则由定时器触发确认时间点。3．TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。4．既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。5．既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。6．TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。两个应用程序通过TCP连接交换8bit字节构成的字节流。TCP不在字节流中插入记录标识符。我们将这称为字节流服务（bytestreamservice）。如果一方的应用程序先传10字节，又传20字节，再传50字节，连接的另一方将无法了解发方每次发送了多少字节。只要自己的接收缓存没有塞满，TCP 接收方将有多少就收多少。一端将字节流放到TCP连接上，同样的字节流将出现在TCP连接的另一端。另外，TCP对字节流的内容不作任何解释。TCP不知道传输的数据字节流是二进制数据，还是ASCⅡ字符、EBCDIC字符或者其他类型数据。对字节流的解释由TCP连接双方的应用层解释。这种对字节流的处理方式与Unix操作系统对文件的处理方式很相似。Unix的内核对一个应用读或写的内容不作任何解释，而是交给应用程序处理。对Unix的内核来说，它无法区分一个二进制文件与一个文本文件。 TCP协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重传，如果在重传超时前收到确认(Acknowlegement)就关闭该重传，如 果重传超时前没有收到确认，则重传该数据段。在选择重发时间的过程中，TCP必须具有自适应性。它需要根据互联网当时的通信情况，给出合适的重发时间。这种重传策略的关键是对定时器初值的设定。采用较多的算法是Jacobson于1988年提出的一种不断调整超时时间间隔的动态算法。其工作原理是：对每条连接TCP都保持一个 变量RTT（Round Trip Time），用于存放当前到目的端往返所需要时间最接近的估计值。当发送一个数据段时，同时启动连接的定时器，如果在定时器超时前确认到达，则记录所需要的时间（M），并修正 RTT的值，如果定时器超时前没有收到确认，则将RTT的值增加1倍。通过测量一系列的RTT（往返时间）值，TCP协议可以估算数据包重发前需要等待的时间。在估计该连接所需的当前延迟时通常利用一些统计学的原理和算法（如Karn算法），从而得到TCP重发之前需要等待的时间值。 TCP的一项功能就是确保每个数据段都能到达目的地。位于目的主机的TCP服务对接受到的数据进行确认，并向源应用程序发送确认信息。使用数据报头序列号以及确认号来确认已收到包含在数据段的相关的数据字节。TCP在发回源设备的数据段中使用确认号，指示接收设备期待接收的下一字节。这个过程称为期待确认。源主机在收到确认消息之前可以传输的数据的大小称为窗口大小。用于管理丢失数据和流量控制。这些变化如右图所示。修改建立TCP连接的超时时间建立TCP连接需要经过三次握手：主动端先发送SYN报文，被动放回应SYN+ACK报文，然后主动端再回应ACK。l在主动端发送SYN后，如果被动端一直不回应SYN+ACK报文，主动端会不断的重传SYN报文直到超过一定的重传次数或超时时间。l在主动端发送SYN后，被动端回应SYN+ACK报文，但主动端不再回复ACK，被动端也会一直重传直到超过一定的重传次数或超时时间。（SYN报文攻击会出现这种情况）可以通过以下命令配置SYN报文的超时时间（发送SYN报文到三次握手成功的最大时间），也就是建立TCP连接的超时时间。命令作用R(config)#ip tcp syntime-out seconds修改建立TCP连接的超时时间。单位秒，取值范围5-300，缺省值20使用no ip tcp syntime-out命令恢复参数缺省值。修改缓冲区大小TCP的接收缓冲区是用来缓存从对端接收到的数据，这些数据后续会被应用程序读取。一般情况下，TCP报文的窗口值反映接收缓冲区的空闲空间的大小。对于带宽比较大、有大批量数据的连接，增大接收缓冲区的大小可以显著提供TCP传输性能。TCP的发送缓冲区是用来缓存应 用程序的数据，发送缓冲区的每个字节都有序列号，被应答确认的序列号对应的数据会从发送缓冲区删除掉。增大发送缓冲区可以提高TCP跟应用程序的交互能力，也因此会提高性能。但是增大接收和发送缓冲区会导致TCP占用比较多的内存。命令作用R (config)#ip tcp window-size size修改TCP连接的接收和发送缓冲区大小。单位字节，取值范围0-65535，缺省值4096。使用no ip tcp window-size命令恢复接收和发送缓冲区大小为缺省值。禁止端口不可达时的重置报文TCP模块在分发TCP报文时，如果找不到该报文所属的TCP连接会主动回复一个reset报文以终止对端的TCP连接。攻击者可能利用大量的端口不可达 的TCP报文对设备进行攻击。可以使用以下命令禁止/恢复在收到端口不可达的TCP报文时发送reset报文。命令作用R (config)#ip tcp not-send-rst禁止在接收到端口不可达的TCP报文时发送reset报文。使用no ip tcp not-send-rst命令恢复发送reset报文。限制TCP连接的MSS的最大值MSS是最大传输段大小的缩写，指一个TCP报文的数据载荷的最大长度，不包括TCP选项。在TCP建立连接的三次握手中，有一种很重要的工作那就是进行MSS协商。连接的双方都在SYN报文中增加MSS选项，其选项值表示本端 最大能接收的段大小，即对端最大能发送的段大小。连接的双方取本端发送的MSS值和接收对端的MSS值的较小者作为本连接最大传输段大小。发送SYN报文时的MSS选项值的计算方法如下。l非直连网络中：mss = 默认值 536。l直连网络中：mss = 对端ip地址对应的出口的MTU - 20字节ip头 - 20字节tcp头。　　一般来说如果出口配置的某些应用影响了接口的mtu，那么该应用会相应的设置mtu，如隧道口，vpn口等。到这里得到的rmss值就是要发送的syn报文mss选项的值 。举例：一般情况下在直连网络中建立bgp邻居，那么该连接的发送的mss为1500 – 20 – 20 – 20 = 1440。ip tcp mss命令的作用是限制即将建立的TCP连接的MSS的最大值。任何新建立的连接协商的MSS值不能超过配置的值。命令作用R (config)#ip tcp mss max-segment-size限制TCP连接的MSS的最大值。单位为字节，取值范围68-10000。使用no ip tcp mss命令取消此限制。启用PMTU发现功能TCP的路径最大传输单元（PMTU）发现功能是按RF C1191实现的，这个功能可以提高网络带宽的利用率。当用户使用TCP来批量传输大块数据时，该功能可以使传输性能得到明显提升。命令作用R(config)#ip tcp path-mtu-discovery [ age-timer minutes| age-timer infinite ]启用PMTU发现功能。age-timer minutes：TCP在发现PMTU后，重新进行探测的时间间隔。单位分钟，取值范围10-30。缺省值10。age-timer infinite：TCP在发现PMTU后，不重新探测。按RFC1191的描述，TCP在发现PMTU后，隔一段时间可以使用更大的MSS来探测新的PMTU。这个时间间隔就是使用参数age-timer来指定。当设备发现的PMTU比TCP连接两端协商出来的MSS小时，设备就会按上述配置时间间隔，去尝试发现更大的PMTU。直到PMTU达到MS S的值，或者用户停止这个定时器，这个探测过程才会停止。停止这个定时器，使用age-timer infinite参数。使用no ip tcp path-mtu-discovery命令关闭PMTU发现功能。设置接口收发SYN报文的MSS选项值当客户端发起一个TCP连接时，它通过TCP SYN报文中的MSS选项字段协商TCP报文数据载荷的最大值，客户端SYN报文的MSS值表示后续服务器端发送TCP报文数据载荷的最大值，反之同理。如右图的拓扑，PC用http访问服务器可能会出现无法访问的情况。因为PC与服务器端建立的连接MSS协商的都会是1460，但1460的MSS无法通过R1和R2，R1和R2用隧道相连，MTU小于1500。这时可以通过在R2的（1）口和（2）口上配置如下命令，修改SYN报文中的MSS选项值。从而修改经过（1）口和（2）口的TCP连接协商的MSS值。命令作用R (config-if)# ip tcp adjust-mssmax-segment-size设置接口收发SYN报文的MSS选项值。单位为字节，取值范围500-1460。使用no ip tcp adjust-mss命令取消此项设置，则接口收发SYN报文时，不会修改报文的MSS选项值。在接口上配置本命令会使得该接口接收或发送SYN报文的MSS选项都被改为接口上配置的MSS值。建议出口和入口配置相同的值。如果SYN报文的入口和出口配置了不同的MSS值，经过该设备后，SYN报文的MSS选项被改为这两个口配置值的较小者。