互联网体系结构的理解

  ①  实体：每一层中的活动元素，可以是任何可发送或接收信息的硬件或软件进程，许多情况下，实体就是一个特定的软件模块。 

  ②  对等实体：位于不同机器上同一层中的的实体。  

  ③  服务提供者：n层（下层）是 n+1层（上层）的服务提供者。

  ④  服务用户：n+1层（上层）是n层（下层）的服务用户。

  ⑤  服务访问点(SAP)：服务提供的地点，也即接口上相邻两层实体交换信息之处。

  ⑥  服务和协议的关系：服务是垂直的，协议是水平的。n层的服务用户只能看见n层的服务而无法看见n层的协议，在n层协议控制下两个对等实体间的通信使得n层能够向n+1层提供服务，要实现n层协议，需要使用n-1层提供的服务。

                         
                                                    网络分层模型图

 

      互联网两大网络模型（OSI模型和TCP/IP模型）都是基于分层原理实现的。通过网络分层，可以获得好处有：各层之间相互独立，相邻层间交互只通过接口， 使整个问题复杂度下降。结构上可分割开，各层都可以采用最合适的技术来实现。每一层功能简单，易于实现和维护。某一层改动时，只要不改变接口服务的关系， 其他层则不受影响，灵活性好。分层有利于促进网络协议的标准化。

 

 

     网络架构设计中的核心目标，那就是“effective（有效）”，但是却没有说明有效互联具体要达成什么样的目标。下面列表中设定了网络架构设计的详细目标：

 

     1) 面临故障时的通信生存能力；

     2) 支持多种类型的通信服务；
     3) 支持不同类型网络的接入；
     4) 支持资源的分布式管理；
     5) 要考虑成本效益因素；
     6) 主机接入互联网的代价要低；
     7) 支持网络资源的计费统计。

     这些具体目标看起来是网络系统需求的一个完整列表。 可重要的是我们需要理解这些目标先后顺序的重要性。 如果顺序发生改变， 将会导致完全不同的网络架构。 例如， 对于军用网络， 意味着在传输数据时可能遭到敌方破坏的复杂情况， 那么通信生存能力就会成为首要目标， 而计费管理能力则是排在最后的目标。 在战争期间， 我们更关心如何尽快地将收集到的信息可靠地传递到目的地，而不考虑通信费用。 所以最初大家并不关心资源的计费管理，而对于商用网络架构的设计， 资源的计费管理应该放在首要位置。同理， 成本效益因素也是我们的目标， 但是排在资源的分布式管理和支持不同类型网络接入之后。 一些流行的商用网络会专门针对特定的传输介质做优化， 比如基于长途电话线实现的存储转发网络可以在很低的成本下通信良好， 但对于其他类型网络的支持可能却很差，因为商用网络架构设计会更多考虑成本效益问题。

     互联网最重要的目标是具有较强的生存能力或者说是自我恢复的能力。 如果两个实体通过互联网进行通信的过程中出现故障使得通信临时中断，它能够重新配置网络恢复通信服务， 然后实体间的通信可以继续， 而不用重新建立更高层的会话。 传输层协议并不总向客户端报告网络临时中断故障， 它总是假定故障可以很快恢复， 反复尝试后确定网络无法恢复时才向客户端报告。互联网架构选择的方案是把状态信息收集起来保存在 网络通信的两端 。这种方式称为“fate-sharing（生死与共）”。 它的意思是通信的一端消失了， 那么另一端也同时将自己保存的状态信息丢掉。传输层的状态信息保存在主机中， 主机连接到整个网络并且使用整个网络上的服务。“fate-sharing” 模式比“复制” 模式有两大优势：

 

         第一，能够不受任何网络中间节点故障的影响；

         第二，工程实现更容易。

 

    “fate-sharing” 模式意味着两点：

 

 

         第一， 中间分组交换节点或网关都不保存当前通信会话的状态信息， 换句话说， 它们是无状态的分组交换。 因此这种网络架构常常被称为数据报网络。

         第二， 在这种架构中主机的作用更重要， 因为它不像有些网络本身提供可靠的数据传输服务， 而它利用主机端的传输层算法保证了数据被有序传输、 丢包重传和确认等， 而主机上的应用程序不必关心数据传输上的细节问题。

 

 

     互联网架构的另一个核心目标是可以支持多种类型的通信服务。 不同类型的通信服务在传输速度、 延迟、 可靠性等方面差别很大。传输服务中最传统的类型是一种双向可靠的数据传输服务。 这种服务又被称为“虚电路” 服务， 适用于远程登陆和文件传输这类应用， 这是在使用 TCP 的互联网架构中首要提供的服务。很早人们就认识到即使是传统的“虚电路”服务也无法满足多样性的需求。 比如其中的远程登陆和文件传输， 前者要求服务延迟不能太大，但对带宽并没有过高要求； 而对于文件传输，更关心的是数据的吞吐量而不是传输延时。 此前， TCP 尝试同时提供这两种服务，结果并不理想。最初 TCP 的设计目标是让它足够通用，但是由于网络环境的多样性，使得使用一个协议来承载不太可能。所以更好的做法是，建立一种服务，能够处理每个通过网络的数据，而不必要求每个字节都可靠地按序交付。

 

     TCP 不适用的服务是实时通信传输，电话会议和电视直播就用到了这一服务。 实时通信传输服务的首要要求是， 在传输数据包时， 有更小和更平滑的延时， 而并不要求很高的可靠性。 也就是说在电话会议中传输过来的语音及时且连续就行， 不需要每个音节都很清晰准确。 大致过程是应用层将模拟语音数字化， 并打包这些二进制数据， 然后按序通过网络发送。 这些数据包必须有序才能保证还原成正确的语音信号。 如果一些数据包未按预期到达，那就不能及时的再现语音了。 在使用 TCP 的情况下做了一系列的研究对传输延时进行控制，最后惊讶地发现， 传输的可靠性才是导致延时的主要原因。 这是因为典型的可靠传输协议发现丢包时会发送一个重传请求， 并会推迟后续数据包的传输， 直到丢包重传成功了才会滑动发送窗口传输后续数据包。这种情况一旦发生会造成数倍的额外延时， 也可能会完全中断。导致最终得到的语音数据是完整的， 但却只能听到断断续续无法识别的声音。 这显然是不合适的， 事实上， 对于丢包的处理可以非常简单。 那就是当遇到丢包时使用一段空语音（没声音）替代，因为在大部分情况下这对听者分辨语音内容没有影响，然后继续传输后续数据。即使产生影响了， 要么可以使用高级纠错， 要么听者让对方重复一遍就行了。

 
      互联网架构中对于多种服务的支持不应该由下层网络来提供， 否则会背离互联网架构设计的目标。 因而， 我们希望由主机和网关来提供算法， 将各种服务从基本的数据报服务（IP数据报） 中抽象出来。 

 

      TCP/IP 协议已经在各个领域广泛应用并且衍生出了很多相似的架构。数据报很好地达成了大多数重要的设计目标，但是当我们试图完成后续一些目标的时候， 发现计费统计资源管理很难在基于数据报的环境下实现。 多数数据报是从源端到目的端传送的一系列数据包的一部分， 无法区分应用层次上独立的单元。 然而， 这一系列数据包对网关是透明的， 因为网关独立处理每个数据包。 因此， 必须对每个数据包独立进行计费统计资源管理， 由于丢包重传等对网关透明无法对应用实际传输的数据量进行准确统计。 在网络层利用数据报模型使得网络层丧失了重要的信息源， 也就很难达成计费统计资源管理等这些目标。这说明在下一代网络架构中可能有比数据报更好的抽象封装方式。 不论采用任何特定的服务类型， 它都可以标识从源端发送到目的端的一系列数据包， 可以用“流” 来描述这种抽象封装方式。 这种方式需要记住通过网络的数据流的特征属性， 但这却挑战了网络中间设备不记录通信状态信息的架构原则。 同时如前文所述， 网关的分布式管理控制与互联网协议越来越臃肿复杂的现状， 让我们开始考虑集中管理控制方式， 以及基于“流” 的抽象封装方式，这从根本上挑战了互联网架构。这么理解的话， SDN 和 OpenFlow 似乎在互联网架构变革的路上， 数据面和控制面分离的方法也为基于“流” 的抽象封装方式提供了技术支撑； 部分地颠覆分布式原则的集中管理控制（网络局部） 策略又为记录基于“流” 的通信状态信息带来了方便， 因为基于云计算的数据中心可以高效快速地存储和处理流状态信息， 从而使得网络更加智能。

 

附：

(1)TCP/IP模型   http://zh.wikipedia.org/wiki/TCP/IP或者百度一下 

(2)数据报意义  参考：互联网架构的设计哲学v1.0

(3)OSI模型   http://blog.csdn.net/yaopeng_2005/article/details/7064869