传输层概述

本文将一些运输层的知识要点整合，以便回顾

运输层概述

作用：运输层实现端到端的通信（主机进程之间的通信）

功能：

• 复用：
  指发送方不同的应用进程都可以使用同一个运输层协议传送数据
• 分用：
  指接收方在剥去报文的首部后能够把这些数据正确交付目的应用进程

与网络层的区别：

网络层为主机之间提供逻辑通信

运输层为应用进程之间提供端到端的逻辑通信

协议端口号（端口）：

运输层用一个16位的端口号来标志一个端口
//注意：端口号只具有本地意义

16位的端口号允许有65535个不同的端口号

分类：

1.服务器端使用的端口号：

• 熟知端口号（系统端口号）0-1023                 //HTTP 80
• 登记端口号 1024-49151

2.客户端使用的端口号：

49152-65535

由于这类端口号仅在客户进程运行时才动态选择，因此又叫做短暂端口号

运输层的两个主要协议

1. 用户数据报协议UDP（UDP用户数据报）
2. 传输控制协议TCP（TCP报文段）

用户数据报协议UDP：

UDP：

1. 无连接                       //即发送数据之前不需要建立连接
2. 尽最大努力交付
3. 面向报文                   //UDP对应用层交下来的报文既不合并，也不拆分，而是保留这些报文的边界。也就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送（交付）一个报文。因此应用程序必须选择合适大小的报文。
4. 没有拥塞控制            //因此网络出现的拥塞不会使源主机的发送速率降低
5. 支持一对一、一对多、多对一多对多的交互通信
6. 首部开销小               //8字节

UDP首部格式：

首部字段只有 8 个字节，包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和临时添加的。

1. 源端口                //源端口号，需要对方回信时使用。不需要时可全为0
2. 目的端口             //目的端口号，在终点交付报文时必须使用
3. 长度                    //UDP用户数据报的长度，其最小值是8（仅有首部）
4. 校验码                //检测UDP用户数据报在传输中是否有错。有错就丢弃

如果接收方UDP发现收到的报文中的目的端口号不正确，就丢弃该报文，并由 ICMP 发送“端口不可达”差错报文给发送方。

之前我们在网络层概述所讲的tracert时，就是让发送的UDP故意使用一个非法的UDP端口，结果ICMP就返回“端口不可达”差错报文，从而达到了测试的目的

虽然在UDP之间的通信要用到其端口号，但由于UDP通信是无连接的，因此不需要使用套接字来建立连接（TCP之间的通信必须要在两个套接字之间建立连接）

传输控制协议TCP：

TCP：

1. 面向连接               //应用程序在使用TCP协议前，必须建立TCP连接。在传送数据完毕后，必须释放已经建立的TCP连接
2. 每一条TCP连接只能有两个端点（套接字socket）,并且是点对点的
3. 可靠交付
4. 双全工通信           //TCP允许通信双方的应用进程在任何时候都能够发送数据，TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据
5. 面向字节流

TCP首部格式：

• 序号 ：在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号
• 确认号 ：期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。
• 数据偏移 ：指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。
• 确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
• 同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
• 终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
• 窗口 ：窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。

套接字socket:

套接字socket ::= {IP地址：端口号}

TCP连接 ::={socket1,socket2}

停止等待协议、连续ARQ协议（了解，TCP未使用）


TCP可靠传输的实现：


滑动窗口（以字节为单位）

TCP的通信是双全工通信，通信中的每一方都有自己的发送窗口和接收窗口
接收端必须有累计确认的功能


发送窗口：发送端可以连续把窗口内的数据都发送出去，凡是已经发送过的数据，在未收到确认之前都必须暂时保留（保存在发送缓存中），以便超时重传时使用

P1：后沿
P3：前沿

P3-P1：发送窗口
P2-P1：已经发送但未收到确认的字节数
P3-P2：允许发送但尚未发送的字节数（又称为可用窗口或有效窗口），可用窗口为0时，必须停止发送。



接收窗口：未按序收到的字节，暂存（保存在接收缓存中）在接收窗口中，接收端只能对按序收到的数据中的最高序号给出确认（即确认号依然是31）

//注意：发送端的发送窗口一定不能超过接收端的接收端口数值（发送窗口大小还受网络拥塞程度的制约）


过程：

1. 发送端连续把窗口内的数据都发送出去
2. 接收端将收到的连续字节交付给应用程序后，将删除这些数据，接着把接收窗口向前滑动，同时给发送端发送确认
3. 确认号落在发送端的发送窗口内，就可以把发送窗口向前滑动，并发送确认号之后的数据（包括确认号） | 若没收到确认，超时重传

发送缓存/接收缓存

需要注意：缓存空间和序号空间都是有限的，并且都是循环使用的

发送缓存：

用来暂时存放：

1. 发送应用程序传送给发送方TCP准备发送的数据
2. TCP已经发出但尚未收到确认的数据

发送窗口常常是发送缓存的一部分

发送缓存和发送窗口的后沿是重合的（因为已被确认的数据应当从发送缓存中删除，同时华发送窗口向前滑动）

接收缓存：

用来暂时存放：

1. 按序到达的、但尚未被应用程序读取的数据
2. 未按序到达的数据

接收窗口常常是接收缓存的一部分

接收缓存=按序到达的、但尚未被应用程序读取的数据+接收窗口

推出：接收窗口的大小取决于接收缓存 和 按序到达的、但尚未被应用程序读取的数据



选择确认SACK

实现：  发送端只传送缺少的数据，而不重传已经正确到达接收方的数据

原理 P227；