TCP协议疑难杂症全景解析
|
前面我们描述的拥塞控制方式都是试探性的检测，然后拥塞窗口被动的进行乘性减，这样在接收端窗口很大的情况下(一般都是这样，网络拥堵，分段就不会轻易到达接收端，导致接收端的窗口大量空置)就可能出现锯齿形状的“时间-窗口”图，类似在一个拥堵的北京X环上开车，发送机发动，车开动，停止，等待，发动机发动，车开动...听声音也能听出来。 虽然TCP看不到下面的IP网络，然而它还是可以通过检测RTT的变化以及拥塞窗口的变化推算出IP网络的拥堵情况的。就比方说北京东四环一家快递公司要持续送快递到西四环，当发件人发现货到时间越来越慢的时候，他会意识到“下班高峰期快到了”... 可以通过持续观测RTT的方式来主动调整拥塞窗口的大小而不是一味的加性增。然而还有更猛的算法，那就是计算两个差值的乘积： (当前拥塞窗口-上一次拥塞窗口)x(当前的RTT-上一次的RTT) 如果结果是正数，则拥塞窗口减少1/8，若结果是负数或者0，则窗口增加一个MSS。注意，这回不再是乘性减了，可以看出，减的幅度比乘性减幅度小，这是因为这种拥塞控制是主动的，而不是之前的那种被动的试探方式。在试探方式中，乘性减以一种惩罚的方式实现了公平性，而在这里的主动方式中，当意识到要拥塞的时候，TCP发送者主动的减少了拥塞窗口，为了对这种自首行为进行鼓励，采用了小幅减少拥塞窗口的方式。需要注意的是，在拥塞窗口减小的过程中，乘积的前一个差值是负数，如果后一个差值也是负数，那么结果就是继续缩减窗口，直到拥塞缓解或者窗口减少到了一定程度，使得后一个差值成了正数或者0，这种情况下，其实后一个差值只能变为0。 疑难杂症21：路由器和TCP的互动 虽然有了5.2.4节介绍的主动的拥塞检测，那么路由器能不能做点什么帮助检测拥塞呢？这种对路由器的扩展是必要的，要知道，每天有无数的TCP要通过路由器，虽然路由器不管TCP协议的任何事(当然排除连接跟踪之类的，这里所说的是标准的IP路由器)，但是它却能以一种很简单的方式告诉TCP的两端IP网络发生了拥堵，这种方式就是当路由器检测到自己发生轻微拥堵的时候随机的丢包，随机丢包而不是连续丢包对于TCP而言是有重大意义的，随机丢包会使TCP发现丢弃了个别的分段而后续的分段仍然会到达接收端，这样TCP发送端就会接收到3个冗余ACK，然后进入快速重传/快速恢复而不是慢启动。 这就是路由器能帮TCP做的事。 6.其它 疑难杂症22：如何学习TCP 很多人发帖问TCP相关的内容，接下来稀里哗啦的就是让看《TCP/IP详解》和《Unix网络编程》里面的特定章节，我觉得这种回答很不负责任。因为我并不认为这两本书有多大的帮助，写得确实很不错，然而可以看出Richard Stevens是一个实用主义者，他喜欢用实例来解释一切，《详解》通篇都是用tcpdump的输出来讲述的，这种方式只是适合于已经对TCP很理解的人，然而大多数的人是看不明白的。 如果想从设计的角度来说，这两本书都很烂。我觉得应该先看点入门的，比如Wiki之类的，然后看RFC文档,793，896，1122等)，这样你就明白TCP为何这么设计了，而这些你永远都不能在Richard Stevens的书中得到。最后，如果你想，那么就看一点Richard Stevens的书，最重要的还是写点代码或者敲点命令，然后抓包自己去分析。 疑难杂症23：Linux，Windows和网络编程 我觉得在Linux上写点TCP的代码是很不错的，如果有BSD那就更好了。不推荐用Winsock学习TCP。虽然微软声称自己的API都是为了让事情更简单，但实际上事情却更复杂了，如果你用Winsock学习，你就要花大量的时候去掌握一些和网络编程无关但是windows平台上却少不了的东西 6.1.总结 TCP协议是一个端到端的协议，虽然话说它是一个带流量控制，拥塞控制的协议，然而正是因为这些所谓的控制才导致了TCP变得复杂。同时这些特性是互相杂糅的，流量控制带来了很多问题，解决这些问题的方案最终又带来了新的问题，这些问题在解决的时候都只考虑了端到端的意义，但实际上TCP需要尽力而为的IP提供的网络，因此拥塞成了最终的结症，拥塞控制算法的改进也成了一个单独的领域。 在学习TCP的过程中，切忌一锅粥一盘棋的方式，一定要分清楚每一个算法到底是解决什么问题的，每一个问题和其他问题到底有什么关联，这些问题的解决方案之间有什么关联，另外TCP的发展历史也最好了解一下，这些都搞明白了，TCP协议就彻底被你掌控了。接下来你就可以学习Socket API了，然后高效的TCP程序出自你手！ 【编辑推荐】
点赞 0 （编辑：开发网_开封站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330459号