唯快不破:tcp/ip模型背后的内涵(一)

2023-10-24 10:11

本文主要是介绍唯快不破:tcp/ip模型背后的内涵(一),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

20世纪最激动人心的东西太多了,我最喜欢的相对论算一个,然而在工程界,我觉得最伟大的发明就是TCP/IP,没有之一!它从单台的计算机互联,到承载着如今爆炸式的互联网以及今后的物联网过程中,一直都很优秀,并且最激动人心的是,它几乎还是保持着它刚出生的样子,如此的稳定!不变性本身就是美,就是永恒!再次读到大师的 《The design philosophy of the DARPA internet protocols》,感觉有写点东西的必要了。
        读史使人明智,确实如此,想了解一个事件或者一种技术的深邃内涵,一定要历史地看!因为所有事物都是稍瞬即逝,要想彻底把握它,必须要了解它的前身和后世,如果你不了解太阳巨石文化和罗马帝国和美索不达米亚,你就很难理解今天西方国家的政策和行为...如果你理解了商周文化和先秦地缘政治学,你就会知道,其实汉字并非人们想象的那样博大精深!对待技术也一样,了解技术历史虽然不能让你写出规范的代码,但它可以让你有可能创造出一个从来没有的东西,而这正是最激动人心的,否则,你掌握的仅仅是一门匠艺,最终会被新的更多的匠艺所淹没。

一.TCP/IP的进化历史概述

-1.最初,TCP/IP是这个样子:



注意,TCP/IP在最初并不是这么拼写的,也没有分层结构,它只是为了解决计算机互联而被设计出来的,今后的发展围绕着原始需求逐渐加入了设计哲学这个手柄,正如Dave Clark说的那样。

IP的分离:这是一桩大事件,IP协议从TCP中分离出来,成了TCP/IP,或者TCP over IP。至于为何分离,设计哲学给出了答案,具体的分析下面详述。IP仅仅是一个报文分组交换的复用层,为了提供IP尽力而为(下文将反复强调,它并没有尽力)的语义,UDP被作为一个端到端的复用层被设计出来,其实UDP就是端系统的IP,而IP则贯穿端系统节点和中间节点。我们从IP报文的分组交换出发,审视TCP/IP这幅美丽的画卷:

0.IP报文交换

IP报文交换是核心中的核心,既然IP从TCP中分离以后就成了一个最大公因子,那么它的职责就是负责传输报文,这也是分组交换的核心思想,由此衍生出来的原则就是IP不能处理任何和服务类别相关的控制功能,比如丢包重传,按序交付等等(流量工程,SDN之类的属于外延的控制,不是IP内在的秉性)。我们可以反过来来理解这个核心中的核心,如果IP实现了丢包重传,按序交付,那么那些不需要该功能的服务的效率会被拖累,也正是因为这样,IP才从TCP中分离开!由此自然而然的得到了上述第一个结论,那就是和服务类型相关的控制功能必须是端到端的行为实现!我们得到一个推论:

1.端到端的传输控制

IP协议自分离以来就是尽力交付的,事实上也真的看不出它“尽力”,它只是逐跳地例行公事罢了!那么对于那些原本的需要丢包重传,按序交付的服务怎么办,这就是留下来的TCP的功能,事实上,现在的TCP把包交换的功能分给IP了,自己仅仅留下了一个控制功能,履行端到端的传输控制。端到端的传输控制思想源头之一是为了减轻中间节点实现传输控制的复杂性,由此可见,阻力有时候也能带来创新,人穷则思变。于是TCP/IP变成了下面的样子:




之所以把IP和TCP分离的另一个原因是需要支持无需重传,无需按序交付的服务,既然现在IP已经纯粹变成了一个包交换传输协议,那么就可以创造一种和和TCP并列的UDP协议同样使用IP的服务,只是刨去TCP的传输控制功能了,印证一句名言:加一个层!于是TCP/IP成了下面的这个样子:




于是,分层模型就出来了,这直接影响了后面几十年!于是一个自然而然的推论就出来了:

2.应用层的高度的可扩展性

分层模型之后,百花齐放的时代到了,既然TCP和UDP都能复用IP,那么TCP之上,UDP之上的多种服用同样也能复用TCP和UDP。看看下面的这个图即可:



仅仅说明一点,应用程序之所以可以爆炸式增长,得益于端到端的传输控制以及分层模型,我们还是反过来考虑这个问题,如果没有端到端的控制,那么每实现或者优化一种传输控制功能,都需要修改中间节点的实现,而想让节点的实现者们为了支持一种协议达成共识是不可能的。如果没有分层模型,中间节点就会显得不像现在这么标准化(封闭),任何的应用创新都可能波及到中间节点,以至于应用创新几乎不可能!(如今的SDN可能或多或少的改变了)


但是,实际的协议栈是一个沙漏而不是一个倒立的锥子!因为我们一直都忽略了实际的物理链路网络!实际上是这个样子:




因此,事情远不像Internet的设计者开始想的那么完美,事实上,在这些链路层以及物理层被设计出来的时候,分层架构还远没有深入人心,并且也借鉴了电话交换网的一些现有思想和技术,所以才造成了很多重复设计,比如X.25的链路级别的重传和TCP的端到端的重传,然而不管怎样,下层的传输控制都是链路级别的,其设计不会影响到整个Internet全局,比如TCP重传会导致一个重传报文穿越整个端到端的所有链路,进而会引发更多的不可控的事件,比如TCP封装TCP时的重传叠加等。

       说起TCP封装TCP,TCP/IP的分层架构可以使分层递归化,一个TCP/IP分层实际上带表了一个逻辑网络,真实的网络可以将任意的层作为任意层的payload,进而使VPN的实现成为可能,VPN就是典型的一种物理网络上的逻辑网络!总之,分层模式允许任意层面的封装,TCP/IP于是是下面的样子:




仅仅考虑TCP/IP,我们看到IP是一个逻辑意义上最底层的传输协议,然而数据需要跨越物理链路传输,IP层面以下就是物理链路的最上层了,因此我们有了下面的推论:

3.以往的传输网络退化成了IP的下层

分层模型提出后,各大标准争相靠拢,当时IP并未取得统治地位,可以说ATM,X.25等网络完全实现了分层模型,它们并非一定要使用IP协议,它们本身就是类似IP协议的技术,只是实现更加复杂,对上层和下层提出了很多假设,它们和TCP/IP栈是平行的。最终TCP/IP的IP完胜,鉴于以往的投资以及上述广域网技术的成熟,它们统统退化成了一种链路层技术,这个退化直接得益于分层模式的递归特性,该特性允许逻辑意义的任意封装和再封装!

附:端到端传输控制与路由快速恢复

话说TCP/IP协议栈采用了美丽的端到端控制,IP仅仅保留了分组交换的功能,这个设计出了衍生出了大量的应用之外,还有一个重中之重,那就是使得路由可以快速恢复,怎么说呢?如果和服务应用相关的传输控制特性在IP中实现,那么整个中间节点加上端系统都要支持诸如状态(N元组)的初始化,复制,处理,销毁等操作,以现今的路由协议为例,如果一条链路出现故障,路由协议将不能简单地将IP报文重路由到另外一条路径,此处的复杂性包含但不限于和所有相关端系统的状态的复制操作,即使复制操作得以实现,如果复制的时机和端系统的状态机没有正确对应,会出现意想不到的错误,而这个错误可能是无法恢复的,直接的后果就是端到端通信的中断,这将违背IP协议对应用的透明性原则。(可以参见《 再次深入到ip_conntrack的conntrack full问题 》)
       不管怎样,确实是端到端的传输控制直接导致路由的简单性,很多路由协议和TCP/IP栈是低度耦合的,比如IS-IS协议。最终,路由的工作就是简单根据IP报头来寻找下一跳,没有任何附加的复杂性,在这个原则之上,开发出了很多的动态路由协议用来支持IP网络故障的自动恢复而不用让端系统感知到这种故障!虽然说策略路由和QoS很大程度上被归为IP协议的范畴,导致了IP的复杂性,然而我认为那只是控制平面的一些有针对性的增强和优化,并没有改变IP简单的秉性!简单就是一切,简单可以应付进化和突变,找个领域的另一个例子是以太网,还有一个终极一点的例子,那就是DNA,再终极一点,就是阴和阳了!

附:简单的IP衍生复杂的控制

IP报文的交换甚至都不是尽力而为,它确实是转发后就不管了,然而它却能保证端到端通信在任意中间节点失效时的快速恢复。如果你说IP的无状态特征使管理和统计很困难的话,那是因为没有考虑控制平面,IP报头的简单性和规整性使得控制平面的实现者可以高效方便的解析协议首部从而将一个数据报文和一个N元组关联起来,进而定义一个流,然后对该流实施任意的控制,目前而言,NAT,状态防火墙,深度解析,入侵检测,VPN等系统都是上述控制平面的实例,将来,SDN将这一切统一起来!
       一个协议如此简陋的出身,注定将来大展宏图,所谓英雄不问出处!IP协议和Linux很像,从超级计算机到嵌入式设备,都有它的身影,其背后的原则正是:简单的内秉可以衍生任意的外延!

二.问题以及解决

起初的设计被认为是一个开放式的设计,最终进化成了如今的基于TCP/IP的Internet,可是问题逐渐显现,如果在框架内解决不了,那就说明起初的设计还不够开放和可扩展,事实上最终我们发现IP协议设计得如此精妙,以至于可以设计出任意的控制平面施加于它而得不到它的任何抱怨!

1.问题:端到端的传输控制真的没有问题吗?

过去,网络节点不多,大家满足于分组交换这个简单又实用的网络,所有的复杂性全部由端系统实现,中间节点只负责逐跳将分组交换到目的地端系统,导致了中间节点对应用和服务完全不知情,它无法辨别一个报文是原始报文还是重传报文,当这个越来越严重的时候,便在中间节点引入了越来越多的复杂功能,比如流量工程等,这在某种层面上违背了IP的原始设计理念,然而却是必要的,因为IP协议从一开始就缺乏一个有效且足够复杂的控制层或者说控制平面,IP的设计理念应该是:提供足够简单且灵活的分组转发逻辑。这个理念背后的含义应该是:足够简单且灵活的转发逻辑可以衍生出任意复杂的控制逻辑!我们知道,IP真正的做到了简单和灵活,从一开始就是,不管是IP报头,还是路由器的行为,都足够简单,然而Internet上缺乏控制逻辑,其实控制逻辑早就可以构建出来,SDN迟到的原因并不是说技术上的原因,而是原有的架构工作得还足够好!

2.问题:IP报文交换和端到端的割裂

这个问题其实是问题的延伸,然而是另一个层面的探讨。正如发展经济时提倡买车,经济发达时抑制拥堵一样,Internet也经历了类似的过程!诸如不让人家买车-限制新应用开发,单双号限行-低级的调度策略,不让外牌上高架-资源独占,沪C不让进内环内-粗粒度包分类阻止,这些方式都是一些狗屁方式,最终都会遇到自己给自己制造的瓶颈!最根本的方式除了加快基础设施的建设以外,那就是提供高超的调度策略,提供一种端到端的跟踪体系。SDN真实而不是形式上做到了这一点,它可以让人通过编码而不是“买设备-求支持-写配置”的方式来定义网络行为。
       记住,这只是一种控制平面的拓展,没有在任何层面增加IP的复杂度。再次重申,IP的简单,灵活(包括行为定义以及报文头)允许任意复杂的控制平面施加于其上!

3.问题:QoS到底由谁来提供

总览TCP/IP,我们发现它是完全逻辑意义上的,没有对底层的物理设施提出任何的假设,虽然有很多的所谓针对不同物理设施的优化算法,但是这种算法也是可插拔的,比如TCP对于高有损链路的拥塞控制优化。实际上,QoS面对的很多问题都是物理意义上的,比如光纤就是比10BASE-T好,因此,首先底层要提供一个QoS保证的最小集,然后让上层的控制平面来对数据包进行调度分拣(比如根据N元组来识别不同的流量),而不是直接在协议层面植入QoS特性,因此我认为IP报头中保存QoS相关的字段并不适合!正如,你首先要有一条宽阔平整的马路,然后才能在上面划分出各种专用车道和路肩。

4.问题:TCP真的很复杂吗

总有人说TCP很复杂,文档太多且杂,然而其核心却是十分简单的!所谓的那些复杂的东西都是一些可插拔的针对特定场景的优化!最原始的TCP是没有延迟确认和捎带确认的,而引入这些机制是为了优化网络行为和提高吞吐量,可是却影响了延迟,为了干掉糊涂窗口,又引入很多优化,正是这些让协议变得复杂起来,如果读一下理论方面的书,单帧的停等协议就是TCP协议的核心!








http://blog.csdn.net/yusiguyuan/article/details/39025163

这篇关于唯快不破:tcp/ip模型背后的内涵(一)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/274449

相关文章

SpringBoot实现基于URL和IP的访问频率限制

《SpringBoot实现基于URL和IP的访问频率限制》在现代Web应用中,接口被恶意刷新或暴力请求是一种常见的攻击手段,为了保护系统资源,需要对接口的访问频率进行限制,下面我们就来看看如何使用... 目录1. 引言2. 项目依赖3. 配置 Redis4. 创建拦截器5. 注册拦截器6. 创建控制器8.

Python基于火山引擎豆包大模型搭建QQ机器人详细教程(2024年最新)

《Python基于火山引擎豆包大模型搭建QQ机器人详细教程(2024年最新)》:本文主要介绍Python基于火山引擎豆包大模型搭建QQ机器人详细的相关资料,包括开通模型、配置APIKEY鉴权和SD... 目录豆包大模型概述开通模型付费安装 SDK 环境配置 API KEY 鉴权Ark 模型接口Prompt

Linux限制ip访问的解决方案

《Linux限制ip访问的解决方案》为了修复安全扫描中发现的漏洞,我们需要对某些服务设置访问限制,具体来说,就是要确保只有指定的内部IP地址能够访问这些服务,所以本文给大家介绍了Linux限制ip访问... 目录背景:解决方案:使用Firewalld防火墙规则验证方法深度了解防火墙逻辑应用场景与扩展背景:

QT实现TCP客户端自动连接

《QT实现TCP客户端自动连接》这篇文章主要为大家详细介绍了QT中一个TCP客户端自动连接的测试模型,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录版本 1:没有取消按钮 测试效果测试代码版本 2:有取消按钮测试效果测试代码版本 1:没有取消按钮 测试效果缺陷:无法手动停

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

Andrej Karpathy最新采访:认知核心模型10亿参数就够了,AI会打破教育不公的僵局

夕小瑶科技说 原创  作者 | 海野 AI圈子的红人,AI大神Andrej Karpathy,曾是OpenAI联合创始人之一,特斯拉AI总监。上一次的动态是官宣创办一家名为 Eureka Labs 的人工智能+教育公司 ,宣布将长期致力于AI原生教育。 近日,Andrej Karpathy接受了No Priors(投资博客)的采访,与硅谷知名投资人 Sara Guo 和 Elad G

Retrieval-based-Voice-Conversion-WebUI模型构建指南

一、模型介绍 Retrieval-based-Voice-Conversion-WebUI(简称 RVC)模型是一个基于 VITS(Variational Inference with adversarial learning for end-to-end Text-to-Speech)的简单易用的语音转换框架。 具有以下特点 简单易用:RVC 模型通过简单易用的网页界面,使得用户无需深入了

透彻!驯服大型语言模型(LLMs)的五种方法,及具体方法选择思路

引言 随着时间的发展,大型语言模型不再停留在演示阶段而是逐步面向生产系统的应用,随着人们期望的不断增加,目标也发生了巨大的变化。在短短的几个月的时间里,人们对大模型的认识已经从对其zero-shot能力感到惊讶,转变为考虑改进模型质量、提高模型可用性。 「大语言模型(LLMs)其实就是利用高容量的模型架构(例如Transformer)对海量的、多种多样的数据分布进行建模得到,它包含了大量的先验

图神经网络模型介绍(1)

我们将图神经网络分为基于谱域的模型和基于空域的模型,并按照发展顺序详解每个类别中的重要模型。 1.1基于谱域的图神经网络         谱域上的图卷积在图学习迈向深度学习的发展历程中起到了关键的作用。本节主要介绍三个具有代表性的谱域图神经网络:谱图卷积网络、切比雪夫网络和图卷积网络。 (1)谱图卷积网络 卷积定理:函数卷积的傅里叶变换是函数傅里叶变换的乘积,即F{f*g}

秋招最新大模型算法面试,熬夜都要肝完它

💥大家在面试大模型LLM这个板块的时候,不知道面试完会不会复盘、总结,做笔记的习惯,这份大模型算法岗面试八股笔记也帮助不少人拿到过offer ✨对于面试大模型算法工程师会有一定的帮助,都附有完整答案,熬夜也要看完,祝大家一臂之力 这份《大模型算法工程师面试题》已经上传CSDN,还有完整版的大模型 AI 学习资料,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费