浅谈OSI七层模型（三）

浅谈OSI七层模型（三）

前文介绍了物理层、数据链路层、网络层，接着上文继续。
传输层：实现端到端的可靠传输。
传输单位：报
本层涉及的协议：1.TCP：传输控制协议，面向连接的可靠协议；
2.UDP：用户数据报协议，无连接的不可靠协议。

Internet 在传输层有两种主要的协议：一种是面向连接的协议 TCP ，一种是无连接的协议 UDP 。由于 UDP 基本上是在 IP
的基础上增加一个短的报头而得到的，比较简单，因此本章将先介绍 UDP ，然后再重点介绍 TCP 。
在TCP/IP 协议簇中， IP 提供在主机之间传送数据报的能力，每个数据报根据其目的主机的 IP 地址进行在 Internet
中的路由选择。传输层协议为应用层提供的是进程之间的通信服务。为了在给定的主机上能识别多个目的地址，同时允许多个应用程序在同一台主机上工作并能独立地进行数据报的发送和接收，
TCP/UDP 提供了应用程序之间传送数据报的基本机制，它们提供的协议端口能够区分一台机器上运行的多个程序。
也就是说， TCP/UDP 使用 IP 地址标识网上主机，使用端口号来标识应用进程，即 TCP/UDP 用主机 IP
地址和为应用进程分配的端口号来标识应用进程。端口号是 16 位的无符号整数， TCP 的端口号和 UDP 的端口号是两个独立的序列。尽管相互独立，如果 TCP
和 UDP 同时提供某种知名服务，两个协议通常选择相同的端口号。这纯粹是为了使用方便，而不是协议本身的要求。利用端口号，一台主机上多个进程可以同时使用
TCP/UDP 提供的传输服务，并且这种通信是端到端的，它的数据由 IP 传递，但与 IP
数据报的传递路径无关。网络通信中用一个三元组可以在全局唯一标志一个应用进程：
（协议，本地地址，本地端口号）
这样一个三元组，叫做一个半相关（ half-association
），它指定连接的每半部分。一个完整的网间进程通信需要由两个进程组成，并且只能使用同一种高层协议。也就是说，不可能通信的一端用 TCP 协议，而另一端用 UDP
协议。因此一个完整的网间通信需要一个五元组来标识：
（协议，本地地址，本地端口号，远地地址，远地端口号）
这样一个五元组，叫做一个相关（ association ），即两个协议相同的半相关才能组合成一个合适的相关，或完全指定组成一连接。

端口号的分配是一个重要问题。有两种基本分配方式：第一种叫全局分配，这是一种集中控制方式，由一个公认的中央机构根据用户需要进行统一分配，并将结果公布于众。第二种是本地分配，又称动态连接，即进程需要访问传输层服务时，向本地操作系统提出申请，操作系统返回一个本地唯一的端口号，进程再通过合适的系统调用将自己与该端口号联系起来（绑扎）。
TCP/UDP 端口号的分配中综合了上述两种方式。 TCP/UDP
将端口号分为两部分，少量的作为保留端口，以全局方式分配给服务进程。因此，每一个标准服务器都拥有一个全局公认的端口（即周知口， well-known port
），即使在不同机器上，其端口号也相同。剩余的为自由端口，以本地方式进行分配。在《常用端口号详解》这篇博文中列出了常用的 TCP/UDP 周知端口号。详见http://shuangyang.blog.51cto.com/540829/115564 TCP 是一种有连接的传输服务，它提供可靠的传输，是大部分 Internet 应用的基础。 UDP
提供的是一种无连接服务，每个数据包独立传输，在传统的应用中因为不能像 TCP
那样保证数据的可靠传输而应用较少。但是对于新的实时视频、音频数据的传输来说，因为不能容忍 TCP 重传带来的时延，常常建立在 UDP 之上。 UDP
为互联网上实时视频、音频服务提供了极好的实验环境。
用户数据报协议 UDP
UDP(User Datagram Protocol) 是一个简单的面向数据报的传输层协议，进程的每个输出操作都正好产生一个 UDP
数据报，并组装成一份待发送的 IP 数据报。 UDP 不提供可靠性，它把应用程序传给 IP 层的数据发送出去，但是并不保证它们能到达目的地。应用程序必须关心
IP 数据报的长度。如果它超过网络的 MTU ，那么就要对 IP 数据报进行分片。 RFC 768 [Postel 1980] 是 UDP 的正式规范。
UDP报文格式： 每个 UDP 报文成为一个用户数据报，分 UDP 报头和 UDP 数据区两部分。报头由四个 16
位长的字段组成，分别说明该报文的源端口、目的端口、报文长度以及校验和。 UDP 报文格式如下图所示：


UDP 源端口字段和目的端口字段包含了 16 位的 UDP 协议端口号，表示发送进程和接收进程。 UDP 长度字段指的是 UDP 报头和 UDP
数据的字节长度，该字段的最小值为 8 字节（发送一份 0 字节的 UDP 数据报是可以的）。 UDP 检验和覆盖 UDP 报头和 UDP 数据。 UDP 和
TCP 在报头中都有覆盖它们报头和数据的检验和。 UDP 的检验和是可选的，如果该字段值为 0 表明不进行校验。一般来说，使用校验和字段是必要的。
传输控制协议 TCP
TCP(Transfer Control Protocol) 是专门设计用于在不可靠的 Internet 上提供可靠的、端到端的字节流通信的协议。
Internet 不同于一个单独的网络，不同部分可能具有不同的拓扑结构、带宽、延迟、分组大小以及其它特性。 TCP 被设计成能动态满足 Internet
的要求，并且足以健壮地面对多种出错。 RFC 793 [Postel 1981] 是 TCP 的正式规范。
UDP
提供的服务是不可靠的数据传送服务，当传送过程中出现差错、网络软件发生故障或网络负载太重时，分组可能会丢失，数据可能被破坏。这就需要应用程序负责进行差错检测和恢复工作，对传输数据量很大的应用来说，采用这种不可靠的数据传输是不合适的。因此需要有一种可靠的数据流传输方法，这就是
TCP。
TCP 提供的可靠传输服务有如下五个特征：面向数据流：当两个应用程序传输大量数据时，将这些数据当作一个可划分为字节的比特流。在传输时，在接收方收到的字节流与发送方发出的完全一样。虚电路连接：在传输开始之前，接收应用程序和发送应用程序都要与操作系统进行交互，双方操作系统的协议软件模块通过在互联网络上传送报文来进行通信，进行数据传输的准备与建立连接。通常用“虚电路”这个术语来描述这种连接，因为对应用程序来说这种连接好像是一条专用线路，而实际上是由数据流传输服务提供的可靠的虚拟连接。有缓冲的传输：使用虚电路服务来发送数据流的应用程序不断地向协议软件提交以字节为单位的数据，并放在缓冲区中。当累积到足够多的数据时，将它们组成大小合理的数据报，再发送到互联网上传输。这样可提高传输效率，减少网络流量。当应用程序传送特别大的数据块时，协议软件将它们划分为适合于传输的较小的数据块，并且保证在接收端收到的数据流与发送的顺序完全相同。无结构的数据流： TCP/IP 协议并未区分结构化的数据流。使用数据流服务的应用程序必须在传输数据前就了解数据流的内容，并对其格式进行协商。全双工连接： TCP/IP
流服务提供的连接功能是双向的，这种连接叫做全双工连接。对一个应用程序而言，全双工连接包括了两个独立的、流向相反的数据流，而且这两个数据流之间不进行显式的交互。全双工连接的优点在于底层协议软件能够在与送来数据流方向相反方向的数据流中传输控制信息，这种捎带的方式降低了网络流量。
TCP 采用一种名为“带重传功能的肯定确认”的技术作为提供可靠数据传输服务的基础。这项技术要求接收方收到数据之后向源站回送确认信息 ACK
。发送方对发出的每个分组都保存一份记录，在发送下一个分组之前等待确认信息。发送方还在送出分组的同时启动一个定时器，并在定时器的定时期满而确认信息还没有到达的情况下，重发刚才发出的分组。图 2 表示带重传功能的肯定确认协议传输数据的情况，图 3 表示分组丢失引起超时和重传。为了避免由于网络延迟引起迟到的确认和重复的确认，协议规定在确认信息中稍带一个分组的序号，使接收方能正确将分组与确认关联起来。


滑动窗口概念
从图 2 可以看出，虽然网络具有同时进行双向通信的能力，但由于在接到前一个分组的确认信息之前必须推迟下一个分组的发送，简单的肯定确认协议浪费了大量宝贵的网络带宽。为此，
TCP 使用滑动窗口的机制来提高网络吞吐量，同时解决端到端的流量控制。
滑动窗口技术是简单的带重传的肯定确认机制的一个更复杂的变形，它允许发送方在等待一个确认信息之前可以发送多个分组。

如图 4
所示，发送方要发送一个分组序列，滑动窗口协议在分组序列中放置一个固定长度的窗口，然后将窗口内的所有分组都发送出去；当发送方收到对窗口内第一个分组的确认信息时，它可以向后滑动并发送下一个分组；随着确认的不断到达，窗口也在不断的向后滑动。滑动窗口协议的效率与窗口大小和网络接收分组的速度有关。

图 5 表示了一个窗口大小为 3
的的滑动窗口协议软件的动作示意图。发送方在收到确认之前就发出了三个分组，在收到第一个分组的确认 ACK1 后，又发送了第四个分组。比较图 5 和图 2
，就可以看出使用滑动窗口后网络吞吐量的提高。实际上，当窗口大小等于 1
时，滑动窗口协议就等同于简单的肯定确认协议。通过增加窗口大小，可以完全消除网络的空闲状态。在稳定的情况下，发送方能以网络传输分组的最快能力来发送分组。TCP 连接建立与关闭
TCP 是一个面向连接的协议，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。本节将详细讨论一个TCP
连接是如何建立的以及通信结束后是如何终止的。
建立一个 TCP 连接 TCP使用三次握手 （ three-way handshake ） 协议来建立连接，图 6 描述了三次握手的报文序列。

这三次握手为：1.请求端（通常称为客户）发送一个 SYN 报文段（ SYN 为 1 ）指明客户打算连接的服务器的端口，以及初始顺序号（ ISN ）。2.服务器发回包含服务器的初始顺序号的 SYN 报文段（ SYN 为 1 ）作为应答。同时，将确认号设置为客户的 ISN 加 1 以对客户的 SYN
报文段进行确认（ ACK 也为 1 ）。3.客户必须将确认号设置为服务器的 ISN 加 1 以对服务器的 SYN 报文段进行确认（ ACK 为 1 ），该报文通知目的主机双方已完成连接建立。

发送第一个 SYN 的一端将执行主动打开，接收这个 SYN 并发回下一个 SYN 的另一端执行被动打开。另外， TCP 的握手协议被精心设计为可以处理同时打开，对于同时打开它仅建立一条连接而不是两条连接。因此，连接可以由任一方或双方发起，一旦连接建立，数据就可以双向对等地流动，而没有所谓的主从关系。
三次握手协议是连接两端正确同步的充要条件。因为 TCP
建立在不可靠的分组传输服务之上，报文可能丢失、延迟、重复和乱序，因此协议必须使用超时和重传机制。如果重传的连接请求和原先的连接请求在连接正在建立时到达，或者当一个连接已经建立、使用和结束之后，某个延迟的连接请求才到达，就会出现问题。采用三次握手协议（加上这样的规则：在连接建立之后
TCP 就不再理睬又一次的连接请求）就可以解决这些问题。

三次握手协议可以完成两个重要功能：它确保连接双方做好传输准备，并使双方统一了初始顺序号。初始顺序号是在握手期间传输顺序号并获得确认：当一端为建立连接而发送它的
SYN 时，它为连接选择一个初始顺序号；每个报文段都包括了顺序号字段和确认号字段，这使得两台机器仅仅使用三个握手报文就能协商好各自的数据流的顺序号。一般来说，
ISN 随时间而变化，因此每个连接都将具有不同的 ISN 。 关闭一个 TCP 连接TCP 连接建立起来后，就可以在两个方向传送数据流。当 TCP 的应用进程再没有数据需要发送时，就发关闭命令。 TCP 通过发送控制位 FIN=1
的数据片来关闭本方数据流，但还可以继续接收数据，直到对方关闭那个方向的数据流，连接就关闭。
TCP 协议使用修改的三次握手协议来关闭连接，

如图 7 所示，即终止一个连接要经过 4 次握手。这是因为 TCP 的半关闭造成的。由于一个 TCP 连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。关闭的原则就是当一方完成它的数据发送任务后就能发送一个
FIN 来终止这个方向连接。当一端收到一个 FIN ，它必须通知应用层另一端已经终止了那个方向的数据传送。发送 FIN 通常是应用层进行关闭的结果。本文出自 “冰泉” 博客，请务必保留此出处http://shuangyang.blog.51cto.com/540829/118315