2018 June 25 计算机网络

第六章 传输层(一)

回顾：网络层作用就是把一个数据包从一台机器成功的发送到另一台机器
引言： 经过网络层的作用之后，下面需要知道:

  1. 怎样实现应用进程之间的通信，网络只是机器之间的通信
  2. 通信的最终服务点不是某台机器，而是某台机器上面的某个应用进程
  3. 怎样实现应用进程之间的传输呢? 这就是传输层的任务

本章要素

  1. 传输服务
  2. 传输协议的要素
  3. Internet的传输协议

一、传输服务

传输层的功能及在协议层中的作用

  1. 传输层在OSI模型中的位置
    图1

    1. 资源子网和通信子网的划分是以传输层作为界限，传输层以上为资源子网（这些协议只有主机上才有），传输层以下为通信子网（在路由器上必须包含这些协议）
    2. 介于通信子网和资源子网之间，对高层用户屏蔽了通信的细节
      1. 传输层对用户提供了一组接口
      2. 当一个应用进程需要发数据给另外一个应用进程时，调用接口即可
    3. 弥补了通信子网所提供服务的差异和不足，提供端到端之间的无差错保证
    4. 传输层工作的简繁取决于通信子网提供服务的类型
      1. 如果下层的网络层比较给力，那么传输层就工作少，反之，工作多

  2. 传输层与上下层之间的关系

    图1

    1. 传输层使高层用户看见的好象就在两个传输层实体之间有一条端到端的、可靠的、全双工的通信通道（即数字管道）
      1. 可靠的： 1.发送的数据不会丢失 2. 发送的顺序不会乱
      2. 传输层的传输实体要为很多应用进程来服务，为了确定是哪个应用的实体，因此对每一个应用进程到传输层都有一个标识，这个标识就叫做传输层的地址（端口号）
      3. 同样每一个主机都有一个网络地址（IP地址）

传输层提供的服务

  1. 面向连接的服务：通信可靠，对数据有校验和重发，如TCP/IP模型中应用层协议FTP、Telnet等（可靠）
    1. 保证数据的不流失： 通过校验检查数据是否丢失，丢失则重发，让上层感觉数据不会丢失
    2. 发送接收顺序不乱： 通过传输层的缓冲实现，排好顺序后给上层
  2. 面向非连接的服务：对数据无校验和重发，通信速率高   如TCP/IP模型中应用层协议SNMP、DNS等（不可靠）

传输服务原语

  1. 传输层要对接的上层是应用层或者应用进程，那么就需要知道如何调用传输层，归根究底就是一组接口，即一组函数调用
  2. 因此设计传输层的时候要设计用户怎样来调用，用户调用的这些接口就叫做传输服务原语
  3. 传输服务原语是应用程序和传输服务之间的接口
  4. 一个典型的面相连接的服务原语如下： 图1 1. 场景： 众多服务器就相当于街上的一个一个商店，买什么东西到什么商店，对商店来讲： 1.开门，让营业员一个一个准备好，如果客户要买东西救护进来沟通，然后服务，服务好了继续等待 2. listen: 打开店门，营业员等待客户上门 3. connect: 客户打招呼 4. send: 营业员服务 5. receive： 营业员服务 6. disconnect： 服务完毕，客户离开
  5. 伯克利套接字（Berkeley Sockets）
    1. 在TCP/IP协议当中用的最多的服务原语就是伯克利套接字
    2. 这个服务原语跟上面的相比只是把它划分的更详细 图1
      1. socket： 创建一个新的通信端点，每一个应用进程都要创建一个套接字标志，两个应用进程之间通信就通过两个对应的套接字之间通信
      2. bind： 把这台机器的标识（本机地址）加入到这个应用进程的socket中去
      3. listen： 宣布可以连接
      4. accept： 等待别人给我一个连接的请求
      5. 。。。
  6. 典型的套接字应用过程
    1. 套接字的使用与文件的使用类似 图1

二、传输协议的要素

  1. 上面展示了传输层需要实现的哪些功能展示了，实现这些功能要考虑哪些问题呢？
  2. 传输层与数据链路层的比较
    1. 相同点：可靠的数据传输
    2. 不同点：
      1. 数据链路层通过物理通道（线路）直接通信，而在传输层，其面对的传输通道是一个网络
      2. 数据链路层的连接建立很简单，而传输层要复杂得多
      3. 数据链路层的通信是点对点的，每条输出线对应了唯一的一个设备，而传输层则需要给出目的端地址
      4. 在数据链路层无中间存储环节，而在传输层，每一途  经的路由器都必须存储、寻径、转发，而寻径到转发  的时间随路由器本身的性能和路由算法而定
      5. 数据链路层通常使用一对发送缓冲区和接收缓冲区，  而在传输层，对每个连接都必须分配一定的缓冲区，  其缓冲区的管理将复杂得多
  3. 综上所述，要建立一个传输层的实体，必须考虑一下问题
    1. 寻址
    2. 连接建立
    3. 释放连接
    4. 流量控制和缓冲策略
    5. 多路复用
    6. 崩溃的恢复       

寻址

  1. 传输服务访问点TSAP （Transport Service Access Point ）
    1. 两个程序要建立连接时，必须指明对方是哪一个应用程序，这个标记称为传输层地址，也称为传输服务访问点（TSAP）
      1. 在TCP协议中传输层地址即TCP的端口号，不同的应用进程有不同的端口号
      2. 网络层地址称为网络服务访问点NSAP（Network Service Access Point），NSAP在IP协议中即IP地址
    2. 连接方案举例
      1. 有了传输服务访问点之后两个应用进程就可以传输服务了
      2. 网络中的服务器就是一个应用进程，不是一个机器
      3. 访问一个时间服务器 图1
        1. 主机2上的时间服务进程将自己连到1522号TSAP上，等待即将到来的请求，例如，可以用LISTEN调用
        2. 主机1上的一个应用进程想找出当天的时间，便发出一个CONNECT请求，将1208号TSAP设定为源地址，将1522号TSAP设定为目的地址
        3. 主机1上的应用进程发送一个时间请求
        4. 主机2上的服务器进程以当前的时间作为应答
        5. 传输连接释放
    3. 如何知道对方的TSAP
      1. vwell-known TSAP
        1. 每个服务都有自己固定的TSAP，所有网络用户都知道（就相当于110、119、120一样，大家都知道的）
      2. 采用名字服务器（name server）或目录服务器（directory server），名字服务器是一well-known tsap
        1. 用户与名字服务器建立连接，向服务器发送一个报文，指明服务的名称，服务器将该服务对应的TSAP返回给用户，类似于114查号
      3. 服务器方将分配的TSAP通知主机 （人工告知）

连接建立（这是常常问的问题！！！）

  1. 连接建立的问题：
    1. 通信子网的不可靠性
    2. 通信子网中存在着延时和分组的丢失，以及由于延时和丢失而带来的重复分组
    3. 由于通信子网的尽力而为的传输原则，一个早已超时的分组最终还是到达了目的端，所以有必要将分组的生命周期限制在一个适当的范围内
    4. 连接建立时，如何处理过期分组，保证连接的唯一性是连接建立过程中首要考虑的问题
    5. 常用的方法是： 三次握手法

连接建立过程

  1. 正常的三次握手过程
  2. 非正常的连接建立过程
    1. 由延迟而重复的TPDU的连接过程
    2. 同时出现作废的CR和ACC的情况

正常的连接建立过程

  1. 正常连接的三次握手过程
    图1
    1. 主机1发出的连接请求序号为x(seq=x)
    2. 主机2应答接受主机1的连接请求，并声明自己的序列号为y(seq=y,ACK=x)
      1. 传输层提供的通信都是全双工的（即双向的连接）
      2. 因此，主机1给主机2发送一个连接请求，那么主机2也要给主机1发送一个应答请求，这样，主机1知道2同意了，主机2告诉主机1同意了
      3. 而实际上有2个连接是并在一起的，即：主机1发送一个连接请求（se q = x），主机2同意发出应答请求（A CK= x）并且同时也发送一个连接请求se q = y）给主机1，这时候主机1就知道主机2同意给我建立连接，同时也发给我了一个请求连接
    3. 主机1收到确认后发送第一个数据TPDU并确认主机2的序列号(seq=x,ACK=y)
      1. 通常主机1发送的应答请求（A CK= y），会与主机1要发送的数据连接请求（se q = x）一块发送给主机2
    4. 至此，主机1知道自己的连接请求主机2同意了，主机2也制动自己的而连接请求主机1同意了，整个连接建立过程正常结束，数据传输已正式开始

非正常的连接建立过程

  1. 出现延迟的重复TPDU时三次握手的工作过程
  2. 情况： 主机1发送给主机2一个连接请求，但是很长时间主机1没有收到主机2的应答，主机1就会认为这一个连接请求丢失了，于是主机1重发，然后重发的这个消息主机2收到了，经过3次握手把连接建立起来了，然后他们开始通信，但过了一会呢，其实第一次的连接请求并没有丢失，而是在某一个节点排队，排了很长时间终于到达主机2了，这时候会不会建立连接呢？在3次握手的时候就不会了，原因:
    1. 当这个连接请求到达主机2时，主机2并不知道主机1已经重发了，主机2正常发送给主机1，主机1收到主机2的应答跟请求时，主机1认为我没发送这个请求，因此主机1就不会给主机2一个应答，而是给主机2一个reject（拒绝），此时，主机2就会知道主机1并不想给我建立连接。因此就不会建立这个连接

    图1

    1. 简述： 来自一个已经释放连接的主机1的延时重复的连接请求，该TPDU在主机1毫不知晓的情况下到达主机2，主机2通过向主机1发送一个接受连接请求的TPDU来响应该TPDU，并声明自己的序号为y(seq=y,ACK=x)，主机1收到这个确认后感到莫名其妙并当即拒绝，主机2收到了主机1 的拒绝才意识到自己受到了延时的重复TPDU的欺骗并放弃该连接，据此，延时的重复请求将不会产生不良后果
  3. 子网中同时有作废的CR和ACC的情况
    图1
    1. 情况：主机1第一次发送了一个网络请求，然后淹没在网上了，然后他重发，正常连接，已经在发送数据了，在发送数据的过程中呢，有一个数据包请求又淹没在网上了，此时，第一次淹没的那个请求应答回来了，那么主机1会不会把这个应答请求误认为是数据包的应答而建立链接呢？ 不会的
    2. 因为要建立连接发送方发送的请求要选择一个序号（上面的X），这个序号就是告诉对方我以后发数据给你的时候他的开始的序号是多少，那么同样主机2给1一个应答的同时发送一个请求，那个请求也会选择一个序号（上面的Y）
    3. 在传输层建立连接的时候对序号的选择很有特点，建立2次连接选择的序号是不会相同的
    4. 上面的图片中看出，主机2第一次应答悬着的序号为y，第二次应答选择的信号为z，因此主机1不会搞错主机2应答的数据包。
    5. 总结： 与上例一样，主机2收到了一个延时的CR并做了确认应答，在这里，关键是要认识到主机2已经声明使用y作为从主机2到主机1进行数据传输的初始序号，因此主机2十分清楚在正常情况下，主机1的数据传输应捎带对y确认的TPDU，于是，当第二个延时的TPDU到达主机2时，主机2根据它确认的是序号z而不是y知道这也是一个过时的重复TPDU，因此也不会无故建立无人要求的连接

释放连接

  1. 非对称释放
    1. 一方中止连接，则连接即告中断
    2. 缺陷：可能导致数据丢失
  2. 对称释放
    1. A提出中止请求，B同意即中止
    2. 问题：B如何知道A 收到了它的确认

 非对称释放

  1. 特点： 一方中止连接，则连接即告中断 图1
    1. 当连接建立后，主机1发送了一个数据TPDU并正确抵达主机2，接着，主机1发送了第二个数据TPDU（这次就不会再次3次握手了，直接发数据），然而，主机2在收到第二个TPDU之前先突然发出了释放连接请求 DISCONNECT，结果是连接立即被释放，数据被丢失
    2. 一般在网络当中是用的对称释放的方式

对称释放

  1. 特点: A提出中止请求，B同意即中止
    1. 对称释放方式适用于每个用户进程有固定数量的数据需要发送，而且清楚地知道何时发送完毕的情况
    2. 其他情况下，决定所有工作是否已经完成，连接是否应该释放，可能是没有把握的
    3. 可以假想一种完美的协议：
      1. A说：“  我发送完了，你呢?”
      2. 如果B响应：“   我也发送完了，再见，”
      3. A收到了B的确认，连接便可以被安全释放
    4. 这些问题如何确定这个释放是否是可靠的释放呢？

对称释放的几种情况

  1. 三次握手的正常情况
  2. 最后的确认TPDU丢失
  3. 应答丢失
  4. 应答丢失以及后续的DR丢失
三次握手的正常情况

图1

  1. 主机1在结束数据传输后决定释放连接，于是发送DR并启动计时器，主机2在收到主机1 的DR后同意释放连接，也发送DR并启动计时器，主机1 在计时器没有超时前收到主机2 的DR，便正式释放连接并发送ACK，主机2也在计时器没有超时前收到主机1 的ACK，于是也释放了连接，至此整个数据传输过程，包括建立连接、传输数据和释放连接的过程正常结束
最后的确认TPDU丢失

图1

  1. 主机1在结束数据传输后决定释放连接，于是发送DR并启动计时器，主机2在收到主机1 的DR后同意释放连接，也发送DR并启动计时器，然而，紧接着的一段时间内，线路遇到了灾难性的干扰，无论是哪一方的超时重发的TPDU都不能到达对方，最终，接收方计时器的超时而也释放连接，发送方经过n次重发和超时后只能无奈地放弃努力并释放连接
  2. 注意： 主机1上的计时器为重发计时器；主机2上的计时器为超时计时器；
应答丢失

图1

  1. 主机1在结束数据传输后决定释放连接，于是发送DR并启动计时器，主机2在收到主机1 的DR后同意释放连接，也发送DR并启动计时器，然而，主机1 在计时器超时后还未收到主机2 的DR，于是又重新发送DR并启动计时器，下面便是一个正常的三次握手，并最后正常释放连接，即整个数据传输过程正常结束
  2. 注意： 主机1上的释放请求允许重发N次，不是无限的重发。
应答丢失以及后续的DR丢失

图1

  1. 主机1在结束数据传输后决定释放连接，于是发送DR并启动计时器，主机2在收到主机1 的DR后同意释放连接，也发送DR并启动计时器，然而，紧接着的一段时间内，线路遇到了灾难性的干扰，无论是哪一方的超时重发的TPDU都不能到达对方，最终，接收方计时器的超时而也释放连接，发送方经过n次重发和超时后只能无奈地放弃努力并释放连接

流量控制和缓冲策略

  1. 流量控制是发送方和接收方之间的传输速率上的匹配，为使没有得到确认的PDU在超时后的重发，通常必须在缓冲区中暂存
    1. 在数据链路层，实现的是点对点的通信，双方缓冲区的大小根据滑动窗口协议而定
    2. 而传输层实现的是端到端的通信，某一时刻，一台主机可能同时与多台主机建立了连接，多个连接必须有多组缓冲区，所以缓冲区的动态分配和管理策略与数据链路层相比较要复杂得多

多路复用

  1. 向上多路复用
    1. 多个传输层的连接共用一个网络层的连接，将提高网络层连接的利用率
  2. 向下多路复用
    1. 一个传输层的连接合用多个网络层的连接来发送，可增加其有效带宽，以提高传输速率

崩溃的恢复

  1. 网络崩溃的恢复（网络出现故障）
    1. 数据报子网：如果传输层对丢失的TPDU留有副本，可以通过重发来解决 
    2. 虚电路子网：必须重新建立连接，并询问远端的传输实体哪些TPDU已经收到，没有收到的则必须重发
  2. 主机崩溃的恢复（主机出现故障）
    1. 客户端主机崩溃，恢复将较为简单
    2. 服务器崩溃，如能及时重新起动，则如何恢复与原客户主机的数据传输  ，问题比较严重，重新连接后，客户端可能处于两种状态之一：
      1. S1—有一个未被确认的TPDU
      2. S0—没有未被确认的TPDU
    3. 在一般情况下，远端服务器的传输实体在接收到一个客户端的TPDU后，先发送一个确认，再对应用进程执行一个写操作（如存盘或交上层）。发送一个确认和执行一个写操作，是两个不同的而又不可分的事件，但两者不能同时进行
  3. 确认和写操作的问题
    1. 先发送确认，然后再执行写操作，中间发生崩
      1. 此时客户端将收到这个确认，当崩溃恢复声明到达时它处于状态S0，客户端将因此不再重发，因为它错以为那个TPDU已经到达服务器端，客户端的这种决定会导致丢失一个TPDU
    2. 先执行写操作，然后再发送确认
      1. 中间发生崩溃，设想已经完成了写操作但在确认发出前系统发生了崩溃，此时客户端将处于状态S1并因此重传数据，从而会导致在服务器应用进程的输出流上出现一个无法检测的重复的TPDU
    3. 无论怎样对发送方和接收方的协议进行编程，总是存在协议不能正确地从故障中恢复的情况，传输层无法彻底解决该问题，将由高一层协议处理，由应用进程来解决。

 

All content is licensed under CC BY-NC-SA

Buit with Jekyll and 3-Jekyll theme • Hosted on Github

Table of Contents