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被

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