传输层

目录

传输层

传输层有两个协议

  • TCP （Transmission Control Protocol)，传输控制协议
  • UDP(User Datagram Protocol)，用户数据报协议

TCP和UDP对比

UDP

数据格式

  • UDP是无连接的，减少了建立和释放连接的开销

  • UDP尽最大能力交付，不保证可靠交付

    • 因此不需要维护一些复杂的参数，首部只有8个字节（TCP首部至少20个字节）
      UDP首部.png

  • UDP长度（Length）

    • 占16位，首部长度+数据长度

检验和 （Checksum）

检验和的计算内容：伪首部 + 首部 + 数据
伪首部：仅在计算检验和时起作用，并不会传递给网络层
检验和

端口 (Port)

  • UDP 首部中端口是占用2字节

    • 可以推测出端口号的取值范围是：0 ~ 65535

  • 客户端的源端口是临时开启的随机端口

  • 防火墙可以设置开启/关闭某些端口来提高安全性

  • 常用命令行（windows）

    • netstat -an : 查看被占用的端口
    • netstat -anb : 查看被占用的端口、占用端口的应用程序
    • telnet 主机 端口：查看是否可以访问主机的某个端口
      • 安装telnet：控制面板 - 程序 - 启用或关闭Windows功能 - 勾选 Telnet Client - 确定
        协议对应的默认端口号

TCP

数据格式

TCP首部

  • 数据偏移
    • 占 4位，取值范围0x0101 ~ 0x1111
    • 乘以4：首部长度(Header Length)
    • 首部长度是20~60字节
  • 保留
    • 占6位，目前全为0

小细节

TCP首部

一个小细节

一个小细节

检验和

检验和

标志位

标志位1
标志位2

序号、确认号、窗口

序号、确认号、窗口

TCP的几个要点

  • 可靠传输
  • 流量控制
  • 拥塞控制
  • 连接管理
    • 建立连接
    • 释放连接

可靠传输

停止等待ARQ协议

ARQ1

ARQ2
疑问

连续ARQ协议+滑动窗口协议（针对停止等待ARQ协议的优化）

连续ARQ协议+滑动窗口协议
连续ARQ协议+滑动窗口协议1

整体的流程图如下：
TCP01_序号_确认号.png

SACK（选择性确认）

SACK1

SACK2

思考

思考
思考1

流量控制 (点对点的控制)

  • 如果接收方的缓存区慢了，发送方还在疯狂的发送数据
    • 接收方只能把收到的数据包丢掉，大量的丢包会极大的浪费网络资源
    • 所以要进行流量控制
  • 什么是流量控制
    • 让发送方的发送速率不要太快，让接收方来得及接受处理
  • 原理
    • 通过确认报文中窗口字段来控制发送方的发送速率
    • 发送方的发送窗口大小不能超过接收方给出的窗口大小
    • 当发送方收到接受窗口的大小为0时，发送方就会停止发送数据

特殊情况

  • 有一种特殊情况
    • 一开始，接收方给发送方发送了0窗口的报文段
    • 后面，接收方又有了一些存储空间，给发送方发送的非0窗口的报文段丢失了
    • 发送方的发送窗口一直为零，双方陷入僵局
  • 解决情况
    • 当发送方收到0窗口通知时，这是发送方停止发送报文
    • 并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小
    • 如果接收的窗口大小还是为0，则发送方再次刷新启动定时器

拥塞控制

  • 拥塞控制
    • 防止过多的数据注入到网络中
    • 避免网络中的路由器或链路过载
  • 拥塞控制是一个全局性的过程
    • 涉及到所有的主机、路由器
    • 以及与降低网络传输性能有关的所有因素
    • 是大家共同努力的结果
  • 相比而言，流量控制是点对点通信的控制

拥塞控制的方法

  • 慢开始 （slow start，慢启动）
  • 拥塞避免 （congestion avoidance）
  • 快速重传 (fast retransmit)
  • 快速恢复 （fast recovery）

几个缩写

  • MSS （Maximum Segment Size）：每个段最大的数据部分，大小在建立连接时确定
  • cwnd（congestion window）：拥塞窗口
  • rwnd（receive window）：接收窗口
  • swnd（send window）：发送窗口
    * swnd = min（cwnd，rwnd）

发送窗口的最大值 ：swnd = min（cwnd，rwnd）

  • 当rwnd < cwnd 时，是接收方的接收能力限制发送窗口的最大值
  • 当rwnd > cwnd 时，则是网络的拥塞限制发送窗口的最大值
1. 慢开始

慢开始1
慢开始2

cwnd的初始值比较小，然后随着数据包被接收方确认（收到一个ACK），cwnd就成倍增长（指数级）

2. 拥塞避免

拥塞避免

  • ssthrest（slow start threshold）: 慢开始阈值，cwnd达到阈值后，以线性方式增加
  • 拥塞避免（加法增大）：拥塞窗口缓慢增大，以防止网络过早出现拥塞
  • 乘法减小：只要网络出现拥塞，把ssthresh减为拥塞峰值的一半，同时执行慢开始算法（cwnd又恢复到初始值）
  • 当网络出现频繁拥塞时，ssthresh值就下降的很快
3.快重传
  • 接收方
    • 每收到一个失序的分组后就立即发出重复确认， 使发送方及时知道有分组没有到达， 而不要等待自己发送数据时，才进行确认
  • 发送方
    *只要连续收到三个重复确认（总共4个相同的确认），就应该立即重传对方尚未收到的报文段，而不必继续等待重传计时器到期后再重传
    快重传
4.快恢复
  • 当发送方连续收到三个重复确认，说明网络出现拥塞，就执行乘法减小算法，把ssthresh减为拥塞峰值的一半
  • 与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值，而是把cwnd值设置为新的ssthresh值（减小后的值），然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢的线性增大

快恢复

建立连接

序号、确认号

序号、确认号1
序号、确认号2
序号、确认号3
序号、确认号4
序号、确认号5
序号、确认号6

在收到sever的几次传输数据之后，client会sever给一个反馈，len == 0

序号、确认号7

TCP04_序号确认号01_相对.png

TCP05_序号确认号02_原生.png

TCP06_序号确认号03.png

三次握手

三次握手1

状态解读

CLOSED :client处于关闭状态
LISTEN: sever 处于监听状态，等待client连接
SYN-RCVD表示server接收到了SYN报文，当收到client的ACK报文后，它会进入到ESTABLISHED状态
ESTABLISHED: 表示连接已经建立

前2次握手的特点
  • SYN都设置为1
  • 数据部分的长度都是0（其实第三次握手数据部分长度也是0）
  • TCP头部的长度一般是32字节 （一般情况）
    • 固定头部：20字节
    • 选项部分：12字节
  • 双方会通过头部的选项部分交换确认一些信息
    • 比如MSS、是否支持SACK、Window scale （窗口缩放系数）等
    • 这些数据都放在了TCP头部的选项部分中（12字节）
      三次握手2
疑问

三次握手疑问

三次握手疑问1

  • 如果第三次握手失败了，会怎么处理
    • 此时server的状态为SYN-RCVD，若等不到client的ACK，server会重新发送SYN+ACK包
    • 如果server多次重发SYN+ACK都等不到client的ACK，就会发送RST包，强制关闭连接

断开连接

四次挥手

状态

四次挥手
FIN-WAIT-1 : 表示想要主动关闭连接，向对方发送FIN报文，此时进入到FIN-WAIT-1状态

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

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

CLOSING:一种比较罕见的例外状态，表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也受到了对方的FIN报文。如果双方几乎在同时准备关闭连接的话，那么久出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都在关闭连接

LAST-ACK：被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，即可进入到CLOSED状态了

TIME-WAIT：表示受到了对方的FIN报文，并发送出了ACK报文,就等2MSL后即可进入到CLOSED状态了，如果FIN-WAIT-1状态下，受到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME-WAIT状态，而无需经过FIN-WAIT-2状态（将2、3次挥手合并）

CLOSED:关闭状态

由于有些状态的时间比较短债，所以很难用netstat命令看到,比如SYN-RCVD,FIN-WAIT-1等

细节

TCP/IP 协议栈在设计上，允许任何一方先发起断开请求。这里演示的是client主动要求断开

client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，才真正关闭连接

  • 一般是等待2倍的MSL（Maximum Segment Lifetime,最大分段生存期）
    • MSL是TCP报文在internet上的最长生存时间
    • 每个具体的TCP实现都必须选择一个确定的MSL值，RFC_1122建议是2分钟
    • 可以防止本次连接中产生的数据包误传到下一次连接中(因为本次连接中的数据包都会在2MSL时间内消失了)

如果client发送ACK后马上释放了，然后又因为网络原因，server没有收到client的ACK，server就会重发FIN

  • 这时可能出现的情况是
    • client没有任何响应，服务器那边会干等，甚至多次重发FIN，浪费资源
    • client有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来它可能是想跟server建立连接的

问题一：为什么释放连接的时候，要进行4次挥手？

  • TCP 是全双工模式
  • 第一次挥手：当主机1发出FIN报文段时，表示主机1告诉主机2，主机1已经没有数据要发送了，但是，此时主机1还是可以接受来自主机2的数据
  • 第二次挥手：当主机2返回ACK报文段时，表示主机2已经知道主机1没有数据要发送了，但是主机2还是可以发送数据到主机1的
  • 第三次挥手：当主机2也发送了FIN报文段时，表示主机2告诉主机1，主机2已经没有数据要发送了
  • 第四次挥手：当主机1返回ACK报文时，表示主机1已经知道主机2没有数据发送了。随行正式断开了整体TCP连接

问题二：有时候在使用抓包工具的时候，有可能只会看到3次挥手

  • 这其实是将第2、3次挥手合并了

  • 当server接收到client的FIN时，如果server后面也没有数据要发送给client了，这时server就可以将第2、3次挥手合并，同时告诉client两件事

    • 已经知道client没有数据要发
    • sever已经没有数据要发了
posted @ 2021-01-26 16:43  康王驾到  阅读(183)  评论(0)    收藏  举报
Language: HTML