传输层协议详解-优快云博客

本文链接：https://blog.youkuaiyun.com/HWQlet/article/details/106751357

如果说网络层处理的是主机与主机之间的通信的话，那么传输层处理的是进程与进程之间的通信。

运输层提供应用进程之间的逻辑通信：从应用层的角度来看，只要把应用层报文交给下面的运输层，运输层就可以把这报文传送到对方的运输层。好像这种通信就是沿水平方向直接传送数据，但事实上这两个运输层hi之间并没有一条水平方向的物理连接。数据传输方向是：从上---->下层------>上

运输层有两种主要的运输协议：TCP和UDP

使用UDP和TCP协议的各种应用和应用层协议

应用	应用层协议	运输层协议
名字转换	DNS域名系统	UDP
文件传送	TFTP（简单文件传送协议）	UDP
路由选择协议	RIP（路由信息协议）	UDP
IP地址配置	DHCP（动态主机配置协议）	UDP
网络管理	SNMP（简单网络管理协议）	UDP
远程文件服务器	NFS（网络文件系统）	UDP
IP电话	专用协议	UDP
流式多媒体通信	专用协议	UDP
多播	IDMP（网际组管理协议）	UDP
电子邮件	SMTP（简单邮件传送协议）	TCP
远程终端接入	TELNET（远程终端协议）	TCP
万维网	HTTP（超文本传输协议）	TCP
文件传送	FTP（文件传送协议）	TCP

解决区分协议就是用协议端口号，简称端口，是一个16位的，也就是最多有65536个端口，端口指具有本地意义

端口号的区别：
- 服务器使用的端口号
  - 熟知端口号（系统端口号）：0-1023
  - 登记端口号：1024-49151
- 客户端使用的端口号（短暂端口号）：491152-65535

用户数据报协议UDP

UDP传送数据之前不需要事先建立连接
UDP只在IP的数据包服务之上增加了很少的功能，复用，分用，差错检测
UDP是无连接的，也就是说发送数据之前不需要建立连接，减少了开销以及发送数据之前的时延
UDP使用尽最大努力交付，主机不需要维持复杂的链接状态表
UDP是面向报文的，对应用层交下来的报文，既不合并也不拆分，保留这些报文的边界。若报文太长，可能交给IP层后，IP层可能会进行分片
UDP没有拥塞控制。因此网络出现的拥塞不会使源主机的发送速率降低，这一特点对某些实时应用很重要，比如直播，IP电话

传输控制协议TCP

TCP提供面向连接的服务，不提供广播或多播服务
TCP是面向连接的运输层协议。应用程序在使用TCP之前，必须先建立TCP连接，数据传送完毕后，必须释放TCP连接
每一条TCP连接只能有两个端点，每一条TCP连接只能点对点的
TCP提供可靠交付的服务。可靠性需要：无差错，不丢失，不重复，按序到达
TCP提供全双工通信，全双工即：允许通信双方的应用进程在任何时候都能发送接收数据
面向字节流。TCP把应用程序交下来的数据看成是一连串的无结构的字节流
可靠传输的实现：
- 滑动窗口，滑动窗口是不断向前移动的，有可能窗口会缩小（因为接收方的通知），即使时缩小窗口也是后沿往前面移动（后沿在左边，前沿在右边，整体向右移动）
- 一个滑动窗口有三个指针，假设为P1，P2，P3
  - 发送窗口：P3-P1
  - 已发送但未收到确认的字节数（面向字节流）：P2-P1
  - 可用窗口（有效窗口）：P3-P2
- 但是滑动窗口需要按序到达，如果没有按序到达呢？这时候为了保证可靠传输，发送方只能认为接收方没有收到报文，在超时计时器的控制下，就重传这部分数据，并且重新设置超时计时器，直到A收到这部分数据的确认。才会向前移动滑动窗口
- 发送缓存，发送窗口，接收缓存，接收窗口：缓存和序号都是循环使用的，所以应该是圆环状的缓冲区
  - 发送方的发送窗口是根据接收方的接收窗口来设置的，还有可能根据网络拥塞程度来调整
  - 对于不按序到达的数据，一般是先临时存放在接收窗口中，等到缺少的字节接收到后，再按序交付上层的应用程序
  - TCP要求接收方必须有累积确认，可以减少传输开销，也可以在自己有数据要发送时把确认信息顺便捎带上
TCP的流量控制：就是让发送方的发送速率不要太快，要让接收方来得及接收
- 发送方的发送窗口不能超过接收方给出的接收窗口的数值，TCP窗口的单位是字节，不是报文段
- 考虑一种特殊情况：接收方向发送方发送了零窗口的报文段，接收方的接收缓存又有了一些存储空间，于是接收方向发送方发送了窗口值为400的报文段，但是这个报文段丢失了。那这样岂不是就死锁了。解决方式就是为每一个连接设置一个持续计时器，发送一个零窗口探测报文段（仅携带一字节的数据）。另一个问题就是糊涂窗口综合征，就是接收方每次仅腾出一个字节，然后发送确认给发送方，然后他们之间的交互就是一字节一字节的交互，TCP首部都至少20字节效率极低，需要接收方等待一段时间在发送确认
TCP的拥塞控制：慢开始，拥塞避免，快重传，快恢复
为什么需要三报文握手：
- 四报文可以将B的确认收到和B的SYN作为一个报文发送，效果是一样的，三报文效率更高
- 因为如果采用两报文握手，若A发送的第一次请求在网络中迷路，此时A已经又传送过请求给B了，B给这个请求服务，A被服务完了，结束连接，这时候第一个迷路的请求又到达了B，B以为A又要服务，于是发送确认等待A发送数据，但A觉得自己已经被服务过了，就没有搭理B的这个报文，于是B的资源就一直卡在这，造成浪费
为什么需要四报文挥手：
- 因为分别表示两个方向数据传输的结束
- 最后为什么还要等2MSL：防止出现最后服务方B又出现资源被占用的不释放的情况

可靠传输的工作原理

TCP发送的报文段是交给IP层传送的，但是IP层只能提供尽最大努力服务，因此TCP必须采取适当的措施才能使得两个运输层之间的通信变得可靠（运输层的协议数据单元：报文段；IP层的协议数据单元：IP数据报）

理想的传输条件：传输信道不产生差错；不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据

停止等待协议：简单来说就是每发送完一个分组就停止发送，等待对方的确认。实际上这样效率很低（信道利用率低）

数据在传输过程不出现差错是很难的，所以我们要做好出现差错的处理措施：
- 超时重传：每发送完一个分组要设置一个超时计时器，发送方必须暂时保留已发送的分组副本，超时计时器的重传时间应该比数据在分组传输的平均往返时间更长一些
确认丢失和确认迟到：
- 有的时候已经过了超时计时器才收到确认，只需要把这个确认丢弃即可