计算机网络自顶向下方法第3章-传输层 (Transport Layer).1

3.1 概述和运输层服务

　　运输层协议为运行在不一样主机上的应用进程之间提供了逻辑通讯(logic communication)功能。

　　3.1.1 运输层和网络层的关系

　　网络层提供了主机之间的逻辑通讯，而运输层为运行在不一样的主机上的进程提供了逻辑通讯。

　　3.1.2 因特网运输层概述

　　Internet上提供TCP(传输控制协议) 和 UDP(用户数据报协议)两种

 3.2 多路复用和多路分解

　　 一个进程有一个或多个套接字（socket），它至关于从网络向进程传递数据和从进程向网络传递数据的门户。

• 接收端将运输层报文段中的数据交付到正确的套接字（即不一样的进程）的工做称为多路分解（demultiplexing）。
• 而在源主机中从不一样套接字中收集数据块，并为每一个数据块封装上头部信息从而生成报文段，而后将报文段传递到网络层，全部这些工做称为多路复用（multiplexing）。

　　1.无链接的多路复用与多路分解

　　在运输层，无链接的网络传输是经过UDP来实现的，一个UDP套接字是由一个含有目的IP地址和目的端口号的一个二元组来全面标识的。

　　主机收到UDP段后检查段中的目的端口号，并将UDP段导向绑定在该端口号的Socket，所以若是两个UDP报文段有不一样的源IP地址/端口号，却有相同的目的端口号，那么两个报文段将经过相同的目的套接字被定向到相同的目的进程。

　　2.面向链接的多路复用与多路分解

　　在运输层中面向链接的网络传输多使用TCP，而TCP套接字和UDP套接字之间有一个细微的差异，TCP套接字是由一个四元组（源IP地址、源端口号，目的IP地址，目的端口号）来标识的。当一个TCP报文段从网络到达一台主机时，主机会使用所有4个值来将报文段定向，即多路分解到相应的套接字。

　　与UDP不一样的是，两个具备不一样源IP或源端口号的到达的TCP报文段将被重定向到两个不一样的套接字。

 

　　 3.Web服务器与TCP

 

　　当今的高性能Web服务器一般只使用一个进程，可是为每一个新的客户链接建立一个具备新链接套接字的新线程。

 

3.3 无链接运输 : UDP

　　UDP的优点

•  应用层能更好发控制要发送的数据和发送时间。
•  无须创建链接。
•  无链接状态。
•  分组首部开销小。

　　3.3.1 UDP报文段结构

　　

　　UDP报文段结构由RFC 768定义，UDP首部只有4个字段，每一个字段由两个字节组成。　　

• 源端口号： 本机（客户端）的应用程序的套接字所对应的端口号，服务器端可利用此端口号向客户端发送数据。
• 目的端口号： 服务端上的应用进程的套接字所对应的端口号，例如HTTP服务器的80端口。
• 长度：指明了首部和数据部分的UDP报文段的总长度，单位为字节，即首部+数据。
• 检验和： 提供了差错检测功能，即检验和用于肯定当UDP报文段从源到达目的时，其中的比特是否发生了改变。

 　　3.3.2 UDP 检验和

• 发送方
  • 将段的内容视为16-bit整数
  • 校验和计算：计算全部整数的和，进位加在和的后面，将获得的值按位求反，获得校验和
  • 发送方将校验和放入校验和字段
• 接收方
  • 计算所获得段的检验和，并将其他检验和字段进行比较。
  • 若是不相等，则检验出错误，但若相等也可能有错误。

3.4 可靠数据传输原理

　　3.4.1 构造可靠数据传输协议

　　1.经彻底可靠信道的可靠数据传输 :rdt 1.0

　　有限状态机(FSM) 能够表示有限个状态及在这些状态之间的转移和动做等行为的数学模型，下图即表示发送方和接收方的有限状态机，底层信道是彻底可靠的，发送方和接收方有各自的FSM，每一个FSM都只有一个状态。

　　（图解：FSM描述中的箭头指示了协议从一个状态变迁到另外一个状态。引发变迁的事件显示在横线的上方，事件发生时所采用的运动显示在横线的下方。FSM的初始状态用虚线表示。）

　　

• 由于信道可靠，接收方也不须要提供任何反馈信息给发送方
• 假定了接收方接收数据的速率可以与发送方发送数据的速率同样快，因此接收方也没有必要请求发送方慢一点发送。

　　2.经具备比特差错信道的可靠数据传输: rdt2.0

　　下图为rdt 2.0 的有限状态机描述图，该数据传输协议（自动重传请求协议）采用了差错检测、确定确认与否认确认。

　　

• 在发送端左边的初始状态中，发送端协议正等待来自较高层传下来的数据。当触发 rdt_send(data) 事件时：
  • 经过 sndpkt = make_pkt(data, checksum) 产生一个包含待发送数据且带有校验和的分组
  • 而后将该分组经过 udt_send(sndpkt) 发送到信道中
• 执行完上述的两个动做后，发送端的状态变迁为“等待接收接收端的 ACK 或 NAK 分组”。即转变为右侧状态，接下来根据接收端的响应不一样会有不一样的变迁方案：
  • 若是收到了一个 ACK 分组（rdt_rcv(rcvpkt) && isACK(rcvpkt)），那么发送方知道最近一个分组已经被正确接收，所以协议返回左边状态，继续等待下一次由较高层传下来的数据发送请求
  • 若是收到了一个 NAK 分组（rdt_rcv(rcvpkt) && isNAK(rcvpkt)），那么发送端知道接收端接收到的分组是受损的，因此调用 udt_send(sndpkt) 从新发送该分组，而后状态不变，继续等待接收接收端的 ACK 或 NAK 分组。

　　在上述协议中，当发送方处于等待ACK或NAK状态时，它不能从上层得到更多数据。这样子的协议被称为停等协议 (stop-and-wait)。

• rdt 2.0 的接收端仍然只有一个状态。状态变迁取决于收到的分组是否受损，有两种方式：
  • 若是收到的分组受损，即 rdt_rcv(rcvpkt) && corrupt(rcvpkt)，则返回 NAK 分组
  • 若是收到的分组无缺，即 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)，则返回 ACK 分组
• 处理完后仍然返回自身这个状态，继续等待下一次从底层接收分组并处理。

　　3.经具备比特差错的丢包信道的可靠数据传输 rdt 3.0

　　在现实的网络环境中，除了比特受损外，底层信道还会丢包；有不少可能的方法能够解决丢包问题，这里咱们让发送方负责检测和恢复丢包工做。

　　假定发送端传输一个数据分组，该分组发生丢失 或者 接收端对该分组的 ACK 发生了丢失。在这两种状况下，发送端都收不到应当到来的接收端的响应。因此，若是发送端愿意等待足够长的时间以肯定该分组缺失已丢失，则它只须要重传该数据分组便可。

　　从发送端的观点来看，重传是一个万能灵药。为了实现基于时间的重传机制，须要一个倒数计时器 (countdown timer)，在一个给定的时间量过时以后，可中断发送方。发送方须要作到：1）每次发送一个分组（包括第一次分组和重传分组）时，就启动一个定时器；2）相应定时器中断；3）终止定时器。

　　下图是rdt 3.0的发送方FSM，该协议运行在可能发生出错和丢失的信道上。

 

 

　　rdt 2.2 协议中的接收端有限状态机描述图仍然适用于 rdt 3.0 协议，下面我仍然用文字来简要描述一下上图中的发送端发送分组流程：

• 首先由较高层触发 rdt_send(data) 事件，经过 sndpkt = make_pkt(0, data, checksum) 产生一个序号为 0，包含待发送数据且带有校验和的分组，接着经过 udt_send(sndpkt) 将其发送到信道中并启动定时器，而后状态变迁为“等待接收接收端的 ACK 0”
• 当发送端在“等待接收接收端的 ACK 0”的时候：
  • 若是收到了受损的分组（即 corrupt(rcvpkt)）或者收到了 ACK 1（即 isACK(rcvpkt, 1)，也就是收到了本身发送的上一个分组的 ACK），则直接忽略
  • 若是定时器时间到，则由 udt_send(sndpkt) 从新发送该分组并从新启动定时器
  • 若是收到了无缺的分组且 ACK 为 0，那么发送端知道接收端已经成功接收了刚才发送的序号为 0 的分组，直接中止定时器，此时发送端状态变迁到等待较高层传下来的数据发送请求
• 注意在继续等待从较高层传下来的数据发送请求的过程当中，若是收到了任何分组数据包，都直接忽略，由于它们必定是冗余的

　　3.4.2 流水线可靠数据传输协议

　　停等协议可能会限制底层网络硬件所提供的能力

　　解决方法是：不使用中止等待方式，运行发送方发送多个分组而无需等待确认。因为许多从发送方向接收方输送的分组能够被当作是填充到一条流水线中，所以这种技术被称为流水线 (pipelining)。固然，流水线会增长协议的复杂度：

• 　必须增长序号范围

　　由于信道中的分组要有一个惟一的序号，会有多个分组在信道中未被确认。

• 协议的发送方和接收方必须缓存多个分组

　　发送方至少应该缓存已经发送却尚未被确认的分组。接受方也许应该缓存已经正确接收的分组。

• 所需的序号范围和对缓存大小的要求取决于协议如何处理丢失、损坏及延时大的分组

　　解决流水线差错错误的两种基本思路：回退N步和选择重传。

　　3.4.3 回退N步

  　　GBN 协议被称为滑动窗口协议 (silding-window protocol)

　　3.4.4 选择重传

 　　选择重传协议让发送方仅重传那些它怀疑在接收方出错的分组，避免了不须要的重传。

 

参考:

http://www.javashuo.com/article/p-yuhpatdu-gx.html

http://www.javashuo.com/article/p-paehuxac-kw.html

https://www.cnblogs.com/huahuahu/p/liu-shui-xian-ke-kao-shu-ju-chuan-shu-xie-yi.html