传输层
一.概述
首先明确数据链路层所在网络层次的位置:
在OSI七层模型中处于自底向上第四层,在网络层上面;在TCP/IP四层模型中处于自底向上第三层。
从信息处理角度看,传输层主要为应用层提供服务。既是用户通信的最底层,也是面向用户通信的最高层。
重要功能:管理端到端的通信连接。
计算机与计算机之间如何识别进程呢?
答:使用端口(Port) 来标记不同的网络进程,端口(Port)使用16比特位表示(0~65535)。
FTP | HTTP | HTTPS | DNS | TELNET |
---|---|---|---|---|
21 | 80 | 443 | 53 | 23 |
二.UDP协议详解
2.1 什么是UDP数据
用户数据报协议(UDP)是一个非常简单的协议。
UDP数据报的数据:是应用层传来的完整数据。
UDP协议对数据报的数据不会进行任何处理,不会合并也不会拆分。因此数据报的长度取决于应用层传来的数据的长度。
UDP协议由两部分组成:UDP首部和UDP数据报的数据,其中UDP数据报的数据就是应用层数据。数据报整体就是IP数据报的数据。
2.2 UDP首部
由四个部分组成:
- 16位源端口号:源机器使用的网络进程
- 16位目的端口号:目的机器正在使用的网络进程
- 16位UDP长度:UDP数据报的长度(最短8个字节,即没有数据只有UDP首部)
- 16位UDP校验和:检测UDP数据报的数据传输中是否出错
2.3 UDP的特点
- UDP是无连接协议
- UDP 不能保证可靠 的交付数据
因为UDP协议不建立连接,想发就发,无法保证数据在网络中是否丢失。 - UDP是面向报文传输的(即不进行处理)
- UDP没有拥塞控制
- UDP首部开销很小
三.TCP协议详解
传输控制协议(TCP)是计算机网络中非常复杂的一个协议。
结构与UDP相似,都是首部+数据报的数据。
3.1TCP的特点
- TCP是面向连接的协议
- TCP的一个连接有两端(点对点通信)
- TCP提供可靠的传输服务
- TCP协议提供全双工的通信
相互通信的计算机之间可以同时发送/接受数据。 - TCP是面向字节流的协议
字节流:流入/流出进程的字节序列。TCP不把应用传下来的数据当作一块完整的数据,而是看作一串字节流。TCP处理字节而非数据,所以可能拆分/合并应用层传下来的数据。
3.2 TCP首部
- 16位源端口
- 16位目的端口
- 32位序号:表示范围0~232-1,标记传输数据(字节流)的首字节,一个字节有一个对应的序号
- 32位确认号:期待收到的数据的首字节序号
确认号为N:则表示N-1序号的数据都已经收到 - 4位数据偏移:表范围0~15,单位:32位字(4字节),因TCP首部除了20字节的固定长度,首部整体长度是不固定(≥20),数据偏移就表示数据距离首部的距离
- 保留字段
- 6位TCP标记:
- 16位窗口:指明允许对方发送给我的数据量
- 16位校验和
- 16位紧急执政:URG=1时,才会启用,指定紧急数据在报文中的位置
- TCP选项(可选):最多40字节
- 填充
3.3 可靠传输
3.3.1 可靠传输的基本原理
3.3.1 停止等待协议
停止等待就是每发送完一个分组就停止发送,等待对方的确认。在收到确认后再发送下一个分组。
停止等待协议是最简单的可靠传输协议,但是停止等待协议对信道的利用效率不高。
数据传输可能出现三种情况的差错:发送的消息在路上丢失了、确认的消息在路上丢失了、确认的消息很久才收到。停止等待协议就会依靠超时重传来保证可靠传输。
所以,没发送一个消息,都需要设置一个定时器,命名为超时定时器。
3.3.2 连续ARQ协议
ARQ:自动重传请求
既然单个发送和确认效率低,可不可以批量发送和确认?
滑动窗口算法
累计确认:比如按顺序接收到第4个消息的确认信息,就认为前四个消息对方都接收到了
TCP的可靠传输基于连续ARQ协议(滑动窗口以字节为单位)。
3.3.2 选择重传
如果收到第三个和第五个窗口的确认消息,那么不是按顺序的,就不能累计确认。要从第一个窗口重新传输,所以效率不高。引进选择重传。
- 选择重传需要指定需要重传的字节
- 每一个字节都有唯一的32位序号
- 选择重传存储在TCP选项中,存储的是一段丢失的字节流的边界
3.4 流量控制
流量控制指让发送方发送速率不要太快,流量控制是使用滑动窗口来实现的。
接收方通过窗口大小控制对方发送速率。
如果接收方回复的窗口大小恢复的消息丢失,发送方会一直以为接收方窗口已满而且不在发送消息,而接受方也一直接收不到消息,这就形成了死锁。为解决这一问题,引进坚持定时器。
当接收到窗口为0的消息,则启动坚持定时器,坚持定时器每隔一段时间向对方发送一个窗口探测报文,询问窗口是否增大。
3.5 拥塞控制
为什么会拥塞?
一条数据链路经过非常多的设备,数据链路中各个部分都有可能成为网路传输的瓶颈,比如:网络中各种路由器性能可能不一样、传输导体的传输速率不一样,都会导致瓶颈。一言以蔽之,可用的资源无法满足网络对硬件设备的性能要求就会造成拥塞。
3.5.1 拥塞控制和流量控制的区别
虽然二者都是控制流量,但是有区别:
- 流量控制考虑点对点的通信量的控制
- 拥塞控制考虑整个网络,是全局性的考虑
3.5.2 判断拥塞的方法
报文传送超时则可认为拥塞
3.5.3 拥塞控制算法
3.5.3.1 慢启动算法
- 由小到大逐渐增加发送数据量
- 每收到一个报文确认,就加一(指数增长:eg:1、2、4、8……)
- 指数增长是很快的,所以会设定一个慢启动阈值,达到阈值就不会增长了
3.5.3.2 拥塞避免算法
达到慢启动阈值就会进行此算法。
- 维护一个拥塞窗口的变量(大于慢启动阈值)
- 只要网络不拥塞(即报文不超时),就试探着拥塞窗口调大(加一,比如阈值是16,下次就17、18……)
3.6 TCP连接的建立(三次握手)
先复习一下前面TCP首部中的TCP标记中的三个:
- ACK:Acknowledgement:确认位,ACK=1,确认号才生效
- SYN:Synchronization:同步位,SYN=1 表示连接请求报文
- FIN:Finish:终止位,FIN=1 表示释放连接
由上图可以看出发送方和接受方建立连接不是同步的。发送方在第二次握手的时候就建立连接;接收方在第三次握手时建立连接。当双方都建立连接后就可进行数据传输了。
为什么发送方要发出第三个确认报文呢?
当已经失效的连接请求报文传送到对方时, 两次握手引起错误。
3.7 TCP连接的释放(四次挥手)
上图接收方再确认完成后就会进入关闭状态;发送方在等待计时器结束后就会进入关闭状态。
等待计时器等待2MSL。
MSL(Max Segment Lifetime): 最长报文段寿命。MSL一般设置为2分钟。
为什么需要等待2MSL?
- 最后一个报文没有确认
- 确保发送方的ACK可以到达接收方
- 2MSL时间内没有收到,则接收方会重发
- 确保当前连接的所有报文都已经过期