TCP 协议 self-opinion

未尽余火

已于 2022-02-18 16:13:57 修改

阅读量687

点赞数 11

分类专栏：学习笔记文章标签： tcp/ip 网络网络协议

于 2021-12-22 16:41:23 首次发布

本文链接：https://blog.csdn.net/m0_51262652/article/details/122083512

版权

学习笔记专栏收录该内容

51 篇文章 0 订阅

订阅专栏

我对TCP 协议的理解

基本常识 :
1.确认应答（ACK）机制
2.超时重传机制
连接管理机制（三次握手，四次挥手）
- - 三次握手建立连接解释：
  - 四次挥手解释
滑动窗口
流量控制
拥塞控制
延迟应答
捎带应答
面向字节流
粘包问题
保活机制

基本常识 :

ip ：用于确定网络中的一台设备；
网卡：计算机上用于网络信息交换的的I/O设备；
Socket ：java 对网卡的抽象；
端口：为了数据准确的在进程之间传输，为需要网络资源的进程配置专门的端口；//可以理解成快递发送到了你的小区（ip），但要到达你的手上要知道你家住那个房子（端口）。
进程：在计算机中运行着的程序，一个进程可以对应多个端口，但一个端口最多对应一个进程；

网卡的（逻辑：我认为的）结构

一块内存，（主要）用于数据缓冲；
一个接口，同进程之间数据交互；
一个程序，用于校验数据的完整性，正确性；
一个控制器，管理网卡的资源；

TCP 是啥：

TCP 是一个由大佬们规定的网络传输的协议；
是网络中数据传输的规范；
TCP 是面向字节流的网络数据传输协议；

TCP 的特点：

谈论TCP 的特性，需要介绍一下另外一个传输协议；
UDP ：面向数据包的传输协议，特点是，无连接（类似与早期村口的广播，收到了就是收到了，收不到也不会再次重传，不要求连接）、不可靠（可能丢包，丢包就丢了，不会重新发的）、面向数据报（类似与肥料运输，一包一包的传输）；

相对与UDP ,TCP 具有：

稳定; （10个机制导致）
可靠； (10个机制导致 )
面向字节流；

TCP 协议格式:

在这里插入图片描述
解释：

源/目的端口号 : (源) 数据出自那个进程，（目的）数据要去哪个进程；
32 位序号/32位确认序号：TCP 将每个字节的数据都进行了编号，即为序列号；接受端收到数据报会创建一个新的TCP数据报，并将其ACK 位置 1 ，并写入确认序号（表示之前的数据已经收到，下一次发送数据从那个序列号开始发送），再将这个TCP 数据报发送到发送端。通常我们称这个数据报的名字叫 ACK ；
4位TCP 报头长度：表示改TCP头部有多少个32 位bit（多少个int）；所以TCP 头部最大长度是2^4 * 4 个字节的长度;
6 个标志位：根据标志位有效性可以确定TCP 传输的是什么类型的数据报；
- （1）URG ：紧急指针是否有效（有效当前位为 1）；
- （2）ACK ：确认号是否有效；
- （3）PSH ：提示接收端应用程序立刻从TCP缓冲区将数据读走（类似生产者消费者模式）；
- （4）RST ：对方要求重新建立连接；把携带RST标识的数据报文称为“复位报文段”；
- （5）SYN ：请求建立连接；把写下SYN标识的数据报称为“同步报文段”；
- （6）FIN ：本端关闭通知标识，通知对方本端准备要关闭了；把携带FIN标识的数据报称“结束报文段”；
16 位窗口大小：流量控制机制的信息。（在流量控制机制详细解释）；
16 位校验和：由发送端写入，用于校验数据报的正确性（包括TCP 头部以及数据），当校验结果与发送端写入的校验和不同，则说明数据损坏；
16 位紧急指针：标识那部分数据是紧急数据；
40 字节头部选项：（暂时还没学习到，待到学习到了补充~ 这里放一个定时器~）；

TCP 的机制

1.确认应答（ACK）机制

由于 TCP 每个数据报都将其每一个字都编号了，也就是说当发送端将 TCP数据报发送到接受端，如果接受端成功收到这个数据报，则会给发送端给以回应，即发送一个ACK 并在确认序号中写入下一次希望发送的数据是从那个序列号开始；

2.超时重传机制

在主机之间发送数据时，有可能出现一些网络问题，导致主机 A 给主机B 发送的数据丢了，主机B 没接收到主机A 发来的数据，因为应答机制的原因主机A 没有接受到主机B 的回应，于是主机A 会等待一段时间如果主机B 还是没有回应，那么主机A就会重新发送数据；

连接管理机制（三次握手，四次挥手）

正常情况下 TCP 要经过三次握手建立连接，四次挥手断开连接；

三次握手建立连接解释：

例如主机 A 与主机B 要建立连接，在建立连接之前首先（两台主机）要确定建立连接的双方有无数据发送和接收的能力，此时主机A 向主机B 发送 SYN （建立连接的数据报即，这个数据报中没有主要的数据只有一个SYN 位置为1），只有当主机B 有接收TCP 报文能力的情况下才可能接收到主机A 发送的SYN ，（如果确认主机B 的接收能力没有问题，但可能是网络原因没有收到，就会由 超时重传机制保证接受的可能），当主机B 接收到了主机A 的 SYN 则，主机B 可以知道，主机·A的发送能力没有问题主机B 自己的接收能力没有问题，接下来由于应答机制 主机B 向主机A 发送 SYN + ACK ，如果主机B 的发送能力没有问题，且主机A 的接收能力没有问题，则由 超时重传机制 保证成功接收，当主机A 接收到了主机B 的SYN + ACK 时主机A 已经确认双方的通信正常，但主机B 此时并不知道自己的发送能力和主机A 的接收能力是否ok，所以，主机A 会发送 ACK 给主机 B,当主机 B 收到主机A 发送的 ACK ，主机B 也确认双方发送和接收能力ok ，双方算是建立了连接，接下来就可以数据交互了；

四次挥手解释

当主机A与主机B之间完成了数据交互，双方需要进行连接的断开操作;
此时主机 A（此时主机A 在 FIN_WAIT1 状态）会向主机 B 发送 FIN （断开连接的亲求），当主机B 收到主机A 发送的 FIN 由于 应答机制主机B 发送给主机A 一个 ACK （表示我知道了）,当主机A 收到主机B 的 ACK 会处于FIN_WAIT2 （准备断开等待状态），此时主机 A 已经确认双方可以关闭，当主机B 处理完数据缓冲区的内容，向主机A 发送 FIN ，并等待主机A回复 ACK,当主机B 接收到主机A 发来的ACK 双方连接断开;

滑动窗口

目的在稳定性的前提下，要尽可能的提高效率；
方式：发送数据报时，一次性发送多组数据报，并建立相应的ACK 响应窗口，一但窗口中的序列号被响应了，则可以向后滑动窗口；
当发送途中出现了数据丢包或响应丢包，发送端会根据响应端的响应消息，决定下次发送那个数据报，以及超时重发，由于每个网卡都有缓冲区域（我的物理模型），并且发送的所有数据字节都有序列号，因此，TCP 有良好的去重能力，即发送的数据包被重复接收没有啥影响，并且能准确的解决 先发后至问题，对于中间丢包也能完美的要求重发；

流量控制

考虑到接收端的对接收数据的处理能力有限,如果发送端不停的发送,导致接收端的缓冲区被用完,这个时候如果继续发送,很大概率会丢包以及一系列问题!
因此TCP 协议支持,根据接收端的处理能力来决定发送端的发送速度(滑动窗口的大小) 这个机制就叫做流量控制!(类似于生产者消费者模式!)
接收端可以将自己接收的缓冲区大小放入TCP 首部的窗口大小字段,通过ACK端通知发送端;
窗口大小由网络和缓冲区决定,取二者中小的那个;
接收端会根据自己缓冲区剩余大小发送ACK通知发送端发送端接收到这个ACK 会调节窗口大小并更改发送速度!
如果接收端的缓冲区满了,接到 ACK 的发送端就将窗口大小赋值为0 不会再向接收端发送数据,但会定期发送探测包,询问何时可以继续发送!

拥塞控制

因为网络环境千变万化,有时十分拥堵,有时很顺畅,就像大城市的公路一样,上下班十分拥堵,中间不是特别拥堵,为了适应网络环境TCP 连接建立后,不直接把大量数据发送,而是发送少量数据报,根据响应情况,确定网络环境,当网络环境好的时候,也就是网络很快的时候,增大滑动窗口的大小;(当然滑动窗口的大小主要依靠流量控制和拥塞控制取二者的最小值!);

延迟应答

为了保证稳定的同时提高传输效率,即想要让滑动窗口尽可能的大,
控制滑动窗口大小一个可控的就是,尽量让接收端的缓冲区尽可能的大,当数据在缓冲区未被进程取走,缓冲区会被占用,当进程取走数据,缓冲区就会恢复一定大小,为了让滑动窗口尽量大,即等一会应答,等进程将数据取走后,再应答,返回较大的缓冲区大小,从而影响滑动窗口的大小!