传输层 transport TCP UDP

传输层 transport

一、简介

传输层有两个协议：TCP、UDP

TCP: 传输控制协议

UDP: 用户数据报协议

二、TCP UDP的区别

TCP UDP
连接性 面向连接 无连接
可靠性 可靠传输，不丢包 不可靠传输，尽最大努力交付，可能丢包
首部占用空间 大 小
传输速率 慢 快
资源消耗 大 小
应用场景 浏览器、文件传输、邮件发送 音视频通话、直播
应用层协议 HTTP、HTTPS、FTP、SMTP、DNS DNS

区别的文字描述

1、是否建立连接：TCP需要建立连接。UDP不需要
2、是否可靠 ：由于TCP建立的传输通道，不会丢包，所以是可靠传输，而UDP不是，可能丢包
3、传输速率：TCP需要建立连接，所以传输速度较慢吗，，UDP较快
4、应用场景不同：由于以上特性，TCP通常用在浏览器、文件传输、邮件发送等场景，UDP通常在音视频通话、直播等场景应用。
5、对应的应用层协议也不同：TCP对应 HTTP、HTTPS、FTP、SMTP、DNS。UDP对应DNS协议。

三、UDP 用户数据报协议

1、数据格式

  • UDP首部为固定8个字节

2、介绍UDP首部

  • 源端口号/目标端口号：端口号，客户端的源端口号是随机端口，服务器端口号比如8080、8888 等
  • UDP长度： 首部的长度 + 数据的长度
  • UDP检验和： 伪首部 + 首部 + 数据
UDP伪首部：是计算 UDP检验和 需要的，由 （源IP地址+目的IP地址+0+17（代表UDP协议）+UDP长度） 组成，他只是计算用，并不在UDP里面，不会传递给网络层

四、TCP 传输控制协议

1、数据格式

  • TCP首部为至少20个字节（20字节 - 60字节）

2、介绍TCP首部

  • 源端口号/目标端口号：端口号，客户端的源端口号是随机端口，服务器端口号比如8080、8888 等

  • 序号：这次传给对方的TCP数据部分的第一个字节的编号，在传输过程的每一个字节都会有一个编号

  • 确认号：期望对方下一次传过来的TCP数据部分的第一个字节的编号

  • 数据偏移：数据偏移 * 4 等于首部的长度（首部的长度为20字节 - 60字节）

  • 标志位：
    URG:当URG=1时，紧急指针字段生效，表明当前报文字段中有紧急数据，应优先尽快传送，传送的是紧急指针指向的数据。
    ACK:当ACK=1时，确认号字段生效。
    PSH: 不重要。
    RST(reset)：当RST=1时，连接中出现严重差错。需要重新建立连接。
    SYN:当SYN=1、ACK=0，标识是建立连接的请求，若对方同意建立连接，则回复SYN=1、ACK=1。
    FIN(finish):表明数据报已发送完毕，要求释放连接。

  • 窗口（window）：告知对方下一次允许发送的数据大小，所以有流量控制功能

  • 检验和：和UDP一样， = 伪首部 + 首部 + 数据 不会传递给网络层

TCP伪首部：是计算 UDP检验和 需要的，由 （源IP地址+目的IP地址+0+6（代表tcp协议）+tcp长度） 组成，他只是计算用，并不在UDP里面，不会传递给网络层
  • 思考：为什么TCP的首部比UDP的首部复杂很多？
  • 答：因为TCP要保证可靠传输，流量控制，拥塞控制等。

五、TCP 可靠传输

一 简介

TCP可靠传输： 就是保证不会丢包，丢包是会重传。

二 重传的几种方式

1、超时重传：停止等待ARQ协议

2、连续ARQ协议 + 滑动窗口协议 + SACK(选择性确认)

和停止等待ARQ协议不同的是，滑动窗口会知道每次可以传送最多多少数据，发送方会一次传送多个包，然后停止发送，等待确认，若接收到确认包，滑动窗口滑动到下个数据报继续传送，若中间有丢包情况，例如：1、2、3、4中的3丢了，接收方给发送方的确认包是2，那发送方会冲床3、4，由于4其实已经成功传过去了，为提高性能，有了SACK(选择性确认)技术，配置支持SACK(选择性确认)技术，这种情况，发送方就只会重传3.

三 SACK(选择性确认)

SACK 信息会放在TCP首部的选项部分

kind：值为5代表是SACK选项
Length：代表SACK选项一共占多少字节
Left Edge:左边界
Right Edge:右边界
SACK选项最多携带4个边界信息，因为TCP首部的选项部分最多40字节，一对边界信息占8字节，加上kind，length。SACK最多字节数= 4 * 8 + 2 = 34

上图的意思，发送方给 接收方 发了1 - 1000 的10个包，其中棕色的包代表传过去了，白色的包代表丢失了，此时开启了SACK选项的话，接收方 给 发送方确认收到M2包， TCP首部中可选部分会记录，收到了
Letf Edge = 301,Right Edge = 401,
Letf Edge = 501,Right Edge = 601,
Letf Edge = 701,Right Edge = 801,
Letf Edge = 901,Right Edge = 1001,
发送方收到之后就知道M3,M5,M7,M9包修饰，就会重传这几个包

  • 思考：若有个包重传了N次还是失败，会一直持续重传到成功为止么？

  • 答：这个取决于系统设置，有的系统设置重传5次还未成功就会发生eset报文（RST）断开连接

  • 思考：为什么选择在传输层将数据分成多段，而不是网络层或者数据链路层？

  • 答：因为可以提高重传性能。
    因为可靠传输是在传输层进行控制的
    如果在传输层不分段，若丢包，整个传输层的数据都需要重传
    如果在传输层分段， 若丢包，只重传丢包的一段数据即可

六、TCP 流量控制

  • 简介
    TCP流量控制：点对点 接收方有缓存的概念，接收方通过确认报文中的窗口字段来控制发送方的发送速率，最大只能给我发送这么多，超过就会丢包，要重传。

  • 思考：极端情况，一开始，接收方给发送方发送了0窗口的报文段，后面，接收方有了缓存空间，给发送方发送的非0窗口报文丢失，发送方一直以为的0，此时怎么办？

  • 答：当发送方收到0窗口通知时，会停止发送报文，并启动一个定时器，隔一段时间就发个测试报文询问最新的窗口大小，如果接受的窗口还是0，则发送方会再次刷新定时器

七、 TCP 拥塞控制

一 简介

TCP拥塞控制：避免网络中的路由器或者链路过载，防止过多数据输入到网络中的一个规则

二 方法

  • 慢开始
  • 拥塞避免
  • 快速重传
  • 快速恢复
1、 慢开始

cwnd（拥塞窗口）:是由发送方估计链路的拥塞程度计算出来的
cwnd的初始值比较小，然后随着数据包被接收方确认，收到ACK，cwnd就会指数级增长（例如2，4，8，16…..）

2、拥塞避免

ssthresh（slow start threshold）：慢开始阈值
拥塞避免：当cwnd滑动窗口到达阈值后，cwnd会以线性方式增大，加法增大
乘法减小：只有网络出现拥塞（丢包），会把ssthresh减为拥塞峰值的一半，同时执行慢开始，cwnd恢复为初始值

拥塞避免作用：防止网络过早出现拥塞
3、快重传

快重传：要求接收方每收到一个失序的报文段就立即发出重复确认（使发送方及早的知道有报文段没有收到）而不要等到自己发送数据时才捎带确认。

快重传算法规定，发送方只要一连收到三个重复确认（总共4个相同的确认）就应当立即重传对方尚未收到的报文段，而不必继续等待为其设置的重传计时器到期再重传。

4、快恢复

快恢复：当发送方连续收到三个重复确认时，说明网络出现拥塞，就执行“乘法减小”算法，把ssthresh减为峰值一半，但不执行慢开始算法，cwnd不恢复到初始值，而是cwnd设置为新的ssthresh值，然后开始执行拥塞避免算法（加法增大）。

快重传 + 快恢复

  • 注释：发送窗口 = min（拥塞窗口，接受窗口）

八、TCP 建立连接 3次握手

解释状态
客户端：

closed ： client（客户端）处于关闭状态
SYN-sent：表示client已经发送SYN报文，等待server的第二次握手
established：表示已经建立连接

服务器端

listen：server（服务器）处于监听状态，等待client连接
SYN-RCVD: received，表示server接收到了SYN报文，当收到client的ACK报文后，会进入established状态
established：表示已经建立连接

解释报文

SYN:同步建立连接请求
ACK：建立请求的反馈
seq：序号，本次发送的数据的第一个数据的编号
ack：确认号，反馈给对方我希望你下一次数据从这个编号开始发送

注释：
  • seq 和 ack 在TCP建立连接时基本没有作用，是在建立连接之后传输数据时起主要作用
  • 在TCP建立连接时，双方会交换确认一些信息，比如是否支持SACK,Window scale（窗口缩放系数）等，这些数据放在TCP头部的选项部分中
思考：为什么TCP建立连接需要3次握手，而不是2次？
  • 答：主要目的是防止server端的一直等待，浪费资源
    比如场景：
    如果建立连接只需要2次握手，可能会出现的情况：
    假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放一会的某个时间才到达server
    本来这是一个早已经失效的连接请求，但server收到此失效的请求后，误认为client再次发送一个新的连接请求
    于是server就向client发出确认报文段，同意建立连接
    如果不采用“3次握手”，那么只有server发出确认，新的连接就建立了
    由于现在client并没有真正想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据
    但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费了

因此，采用“3次握手”可以防止上述现象发生。

思考：TCP建立连接过程中，第三次握手失败了，会怎么处理？
  • 答：此时server端处于SYN-RCVD状态，若等不到client的ACK，server会重新发送SYN+ACK包，如果server多次（发送几次是由不同系统决定的）发送SYN+AVK都等不到client的ACK，就会发送RST包，强制关闭连接。

九、TCP 释放连接 4次挥手

解释状态
客户端：

FIN-wait-1：表示想主动关闭连接
向对方发送了FIN报文，此时进入到FIN-wait-1状态

FIN-wait-2:只有对方发送ACK确认后，主动方就会处于FIN-wait-2状态，然后等待对方发送FIN报文

Time-wait：表示收到了对方的FIN报文，并发出ACK报文，等2MSL后进入closed状态（MSL：最大分段生存周期，规定，这个可以保证FIN,ACK报文会失效，不会发生重新发送报文，自己收到不，导致资源浪费的状态）

closed：关闭状态

服务器端

close-wait：表示在等待关闭
当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到close-wait状态
在此状态下，要考虑自己是否还有数据要发送给对方，如果没有，则发送FIN报文给对方

Last-ACK:被动方在发送FIN报文后，等待对方的ACK报文是处于last-ack状态，收到对方的ACK报文后，会进入closed状态

closed：关闭状态

两端

Closing：一种比较罕见的状态，表示双方等正在关闭
表示你发送FIN报文之后，没有收到对方的 ACK报文，而是收到了对方的FIN报文，比如如果双方几乎同时给对方发送FIN报文，这时会出现closing状态

注释：
  • TCP/IP协议允许任何一端先发起断开，例子是以客户端先发起断开
思考：为什么要4次挥手？
  • 答：因为TCP是双工模式。
    主动方想断开之后，被动方仍然可以发送数据给对方，当被动方没有数据发送，需要断开连接时，再发送报文，并主动方告知接收到，
    最后的如果不等主动方回馈的ACK报文，有可能网络不好时，被动方发出的FIN报文，主动方没有收到，导致资源浪费

十、总结

posted @ 2021-08-18 11:30  喵喵yy  阅读(454)  评论(0)  编辑  收藏  举报