TCP/IP 问答

转自奔流杂志其中几个期刊中的《TCP/IP》问答，感觉总结的比较好，这里做一个归并.

问：处于 syn-received 状态中再收到 syn 报文时该如何处理？

答：为确保可能发生的客户机SYN 重传，各种实现及实验环境下处理机制各不相同，基本流程思路如下：

1. syn-received 状态的服务器在 SYN+ACK 重传定时未超时并未收到客户机 ACK时，再收到 syn 如与之前 syn序列号不同，则重置连接后，重新回复 syn+ack。

2. 如 syn 序列号相同，则认为是重传，直接忽略。

最后扩展下，在三次握手完成后，在同一 TCP 连接中又收到 SYN，这个 RFC793有明确规定，则情况如下：

1. 收到的 syn 的序列号在已建连接的窗口中。则认为为一次错误，原来的连接被重置，并发送 RST。

2. 收到的 syn 序列号不在窗口内。则回复 ACK（ACK 序列号按之前，与syn 无关）。其他不做操作。

实际连接建立后，再收到 syn 是可能会对连接产生影响的，需要各位注意。

 

 

问：TCP 在广域网络中的影响主要有哪些？ 

 答：从应用体验上来说，广域网问题主要有以下几方面：  

1. 时延，长距离传输、多跳转发、网络拥塞等问题导致。  

2. 带宽，广域网带宽小。  

3. 应用程序交互过多导致的响应时间长。  

4. 以上结合 TCP 的自身特性问题，导致问题放大。如丢包率导致的性能下降、  传输限制、安全问题等。  

接下来我们来讨论下广域网内的 TCP 问题：  

时延变化与丢包 

 在广域网环境下，瞬态时延可能是秒级的。在 RFC1122 中要求的 RT0（重传  超时时间）不小于 1s 不大于 2MSL 时间（最大段存活时间,一般为 30s、60s 或 120s）  （实际应用中部分情况可能没有遵循，如单边加速，会设置小于 1s 的 RTO）。   对于广域网的高时延变化，即使没有发生实际丢包的情况下，也会发生 RTO

超时，TCP 会误判为发生丢包。这时在 TCP 的积极重传和SACK 机  制下，TCP 会将所有已经发送但未收到 ACK 确认并 SACK未确认的  段全部重发，直到收到相应段 ACK 确认。这个无疑大大降低了 TCP  效率。理论上来说 1%的丢包可能导致 80%的性能损耗。  

网络拥塞  

TCP 自身拥有拥塞控制机制，会对于网络拥塞做出调整。但  SACK 引入后，由于对网络拥塞影响的降低，TCP 的拥塞机制在众  多实际应用中不再开启。但当发生网络拥塞导致的丢包时，TCP 对  于丢包依然只会反复的重传，这样实际上只会加重拥塞。  

安全问题  

如常见的 DoS/DDoS 攻击，用的最多的就是基于TCP Syn 的攻  击，很多网络攻击都以TCP 为依据。RFC 有规定三次握手后收到窗  口内序列号的 Syn，是需要重置连接并发送RST 标志位重置对方连  接的。另外攻击往往发送Syn 后不回复对端的 Syn+ACK，使对端处  于Syn-recevied，来达到消耗服务器资源的目的。Syn Cookie 和 Delay  Binding（延迟绑定）技术是可以用来解决这个问题。但广域网的安  全问题依然不可避免。

 

 

问：带 SACK 后 TCP 实际重传的序列号是什么？  

答：这个问题我们可以不考虑段的封装。假设发送方发送了序列号为1-10000 的字节。  收到的ACK=5000，sack1=7500-8000，sack2=9000-10000。   则 ACK 表示标志 1-4999 的字节都已经收到。SACK 值表示 7500-8000,9000-10000 已  经收到。则发送方应该重传的数据为序列号为 5000-7500,8001-9000 的数据。    

 

 问：TCP 窗口与 MSS 的关系是什么？ 

 

 答：TCP 的接收窗口与 MSS 没有直接关系。   接收窗口是 TCP 在一个 RTT（往返时间）内所能接收的最大数据量，取决于上层应  用的需求、性能或限制。接收方的应用可以通过调整接收窗口来完成对发送方发送速率  的控制。

MSS 是 TCP 发送段的最大长度（只算 TCP 的 payload）。它应该  保证段在最大的传输效率下尽量不发生 IP 层封装分割。通常情况  下在以太网 MTU 为 1500，去掉 20 个字节标准 IP 头，20 个字节的  标准 TCP 头，MSS 一般为 1460。与应用无关。     

 

问：应用不需要启用 TCP 窗口扩大因子，是否在SYN 时选项中就 不发送窗口扩大因子？  

答：在支持窗口扩大因子的情况下，即使不需要启用也应该发送  扩大因子选项，并把扩大因子置为 0。表示支持扩大因子，但本身  的接收窗口不使用。   如果不在选项中发送窗口扩大因子，则表示不支持扩大因子，  在整个 TCP 会话中双方都不会启用。这样可能会影响对方对于窗口  扩大因子的支持。

 

问：TCP 的握手是 OSI 模型的那一层发起的？也就是 SYN SEND 这些包是哪一层发起的？  

答：TCP 是属于 OSI 的第四层，传输层。SYN、FIN 等都是 TCP 段中的特征字符，都属于  OSI 的传输层。

 

问：在网络中设备发生拥塞时，TCP 可以使用滑动窗口技术很好的解决流量控制问题（）

A. Ture B. False

 

答：这个答案应该是 False。TCP 的滑动窗口的流控可以达到流控的目的，乍看下应该可以解决网络拥塞问题。但实际上并非如此，TCP 的发送窗口由对端的接收窗口控制，而对端的接收窗口只受限于对端的应用，与网络无关。不含 TCP 拥塞机制是，应用程序通过本段 TCP 协议栈根据自身需求通告对端窗口大小，在网络拥塞时一样可能通告较大窗口，导致 TCP 性能下降（重传过多）。 即使包含拥塞处理机制，TCP 对于拥塞的认知是靠发现重传超时。那么 TCP 被

通告大窗口并在拥塞的网络中传输时，很容易丢包，于是启动慢启动，恢复后重复。这样会有间歇性的速率下降，会大大降低传输效率。并依然会间歇性的导致网络拥塞加重。