首页 > 系统相关 >【Linux】TCP全解析：构建可靠的网络通信桥梁

【Linux】TCP全解析：构建可靠的网络通信桥梁

时间：2024-08-04 14:52:47浏览次数：16  
标签：网络通信 UDP 窗口 应答 TCP 发送 Linux 报文

文章目录

前言

在计算机网络中，传输层协议扮演着至关重要的角色，它们负责在网络中的主机之间可靠地传输数据。其中，TCP（传输控制协议）和UDP（用户数据报协议）是最常见的两种传输层协议。TCP以其可靠性、有序性和流量控制等特性，成为了许多关键应用的首选协议，如文件传输、电子邮件、Web 服务等。然而，TCP的复杂性和性能开销也使得它在某些场景下不如UDP灵活和高效。本文将深入探讨TCP协议的各个方面，从其基本机制到高级特性，再到与UDP的对比，帮助读者全面理解TCP的工作原理和应用场景。

1. TCP 协议概述

TCP 全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;

2. TCP报头结构

在这里插入图片描述
在这里插入图片描述

一眼看去, TCP协议确实比UDP要复杂的多, TCP协议的报头并不是定长的, 你可能会发现它除了选项和数据的长度是定长的20字节。但是它的选项的长度是不定的. 在前20字节中有一个叫4位首部长度的字段。它代表了报头一共有多大， 范围是: 20~60字节

TCP报头的其他字段数据, 比如: 序号, 确认序号, 窗口大小, 6位标志位等. 就是TCP用来保证它的效率和可靠性时需要使用到的字段

3. 如何理解封装和解包呢？

  1. OS内可不可以同时存在很多个收到的报文，这个报文还没来得及处理，甚至拷贝到传输层的接收缓冲区，甚至没有交给传输层而在网络层和链路层。
  2. OS内一定会收到大量还没来得及处理的报文，OS要不要对大量的暂未处理，但以及接收到的报文进行管理呢？要！（先描述，再组织）

添加报头只需要将head指针向左移动（封装的过程就是指针移动+填写报头）
解包就是将head指针强转，再提取他的字段，之后将head指针向又移动。
在这里插入图片描述

  • 封装和解包，在内核中，只需要进行指针移动即可！

4. TCP的可靠性机制

4.1 TCP的确认应答机制

TCP 保证可靠性！
确认应答保证历史消息被收到了，可靠性是对历史消息的可靠性的一种保证！
确认应答机制：
在这里插入图片描述

  • 比如主机A给主机B发送了1000字节的数据, 那么这个TCP包中的序号就为1000. 当B主机收到TCP包后, 会给A主机发送确认应答, 并且会将确认序号设置为1001, 代表1001以前的数据我都收到了. 可以从1001个字节开始给我发数据了。
  • 同理,要是B主机没有给A发送1001确认序号,而是直接发送了2001. 证明2001以前的数据都收到了, 包括1~1000的

  • tcp 发送消息的模式 ——version0
    发送数据和发送应答，一般是是 双方OS自动完成的！（通信细节OS自动解决了！）

  • tcp 发送消息的模式 ——version1
    根据发送报文的顺序进行排序，根据序号，进行tcp的按序到达！
    在这里插入图片描述

  • 32位的确认序号：收到的序号 + 1 （该确认序号之前的数据，我已经全部收到了，下次发送，请从确认序号开始！）

在这里插入图片描述

既想做确认应答，又想发数据！这种方式叫做捎带应答！（既是应答，又携带了数据！）

  • 序号存在的意义：按序到达，应答和确认应答
  • 确认序号&&序号：同时向双方发送数据的同时，也同时在做应答
  • 为什么tcp报头中要有标志位？标志位存在的意义？
    答：需要区分不同的报文请求！即区分不同的报文类型！
    我们的server一定在通信的过程中，会同时收到各种各样的报文！（即TCP报文是需要类型的！）

在这里插入图片描述

为什么发SYN其实只是SYN被置1了，发送不同的请求只需要将不同的标记位置1即可！
其中三次握手由OS自动完成！ 用户只用使用connect进行发起。
如何进行连接？管理，先描述，再组织！（内核数据结构，内存空间和时间）
维护连接是有成本的！时空成本

在这里插入图片描述

断开链接时，双方各自向对方提出断开的要求，然后再断开链接 close(fd) (四次挥手)

在这里插入图片描述

确认应答（ACK）机制，是报证可靠性的最基础也是最重要的一种机制！

在这里插入图片描述

4.2 超时重传机制

没有收到应答呢？
需要去等，等多长时间呢？
约定，对方没有收到报文，在一个时间端内，没有收到应答

数据丢包:
在这里插入图片描述
应答丢包:
在这里插入图片描述
在这里插入图片描述

5. TCP链接管理机制

正常的情况下，TCP要经过三次握手建立连接，四次挥手断开连接
在这里插入图片描述

像SYN、ACK这些是标记位，我们发送过去的是完整的TCP报头，并不是只是这些标志位！
connect(fd,服务器地址端口) 发起了三次握手，accept返回不参与三次握手！
三次握手与四次挥手都是操作系统自己完成的！

  • **三次握手：**不是能100%建立好链接，而是经历三次握手，c/s都是认为连接建立好了

  • RST（reset）：重置！
    所谓的链接重置，就是让两方，重新进行三次握手！
    解决的问题就是连接出现异常的问题！

5.1 经典面试题：为什么建立连接是三次握手？

为什么不进行一次或两次连接，因为这样有明显漏洞，客户端不用应答就可以不停的去连接，这样只用一台客户端就可以对服务器工具（SYN洪水），而三次握手呢，客户端也需要建立连接，这样就不会受到单机的攻击！

三次握手
理由一：需要保重信道（网络）是健康的
三次握手，CS双方，都会有确定的一次收发，CS确认全双工

理由二：确保双方OS（TCP）是健康且愿意通信的（建立了通信的共识）。
服务端回应的时候进行捎带应答，表达了服务器急切的情绪！
三次握手的本质就是四次握手，只不过中间两次被捎带应答了！

5.2 经典面试题：为什么要进行四次挥手？

在思想上三次握手和四次挥手没有区别。

CLOSE_WAIT, TIME_WAIT
如果我们发现我们的服务器上有大量的close_wait状态的时候，这意味着，大概率我们的服务器有bug，主要是没有close_fd

  • TIME_WAIT: 等待一定的时长

  • 为什么要等？

1.保证历史的报文有足够的时间进行消散，保证一来一回的时间。
2. 在我们四次挥手的过程中，看起来最后一个ACK没有应答，但其实这个ACK是有应答的，因为它还会发送FIN，如果最后一个客户端没有收到，服务器不可能走到LAST_ACK,等的时候同样会响应FIN，如果等待的时间内ACK没丢那么响应的这么长时间内那么就不会收到另一个FIN了！TIME_WAIT保证了对方的ACK也能顺利完成！（还有重传的机会）

  • 时长是多长呢？

等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态

6. 流量控制

在这里插入图片描述

主机A发的太快了，主机B来不及接收
主机B可以向主机A通告自己的接收能力
什么叫主机B的接收能力？我的接收缓冲区中剩余空间的大小！
怎么通告？主机B有确认应答机制（在自己的ACK报文中，填写自己的16位窗口大小）

  • 具体流量控制
    接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应.
    因此 TCP 支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);
  • 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过 ACK 端通知发送端;
  • 窗口大小字段越大, 说明网络的吞吐量越高;
  • 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
  • 发送端接受到这个窗口之后, 就会减慢自己的发送速度;
  • 如果接收端缓冲区满了, 就会将窗口置为 0; 这时发送方不再发送数据, 但是需
  • 要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端.

在这里插入图片描述
设置PSH标志位，催促B主机快点发送窗口大小
UGR：紧急指针，让B主机优先处理

7. 滑动窗口机制

解决主机之间发送效率低下的问题，实现并行发送！
在这里插入图片描述
滑动窗口的大小：不考虑网络的情况，滑动窗口大小一般是：对方缓冲区中剩余空间的大小（暂时）

滑动窗口是发送缓冲区的一部分
报头中的窗口大小描述的是接收方的发送能力，滑动窗口的大小表示的是发送方的发送能力的问题

在这里插入图片描述

  1. 超时重传？

对发送的报文，并且没有收到的应答的报文进行保存（在滑动窗口中），方便我们经行重传！

  1. 如何理解这个滑动窗口呢？

a.只能向右滑动吗？ 只能向右滑动
b.可以变大吗？可以变小吗？ 可以
c.可以为0吗？可以

  1. 理解它？

滑动窗口的本质其实就是两个整型变量维护的一段数组空间

在这里插入图片描述
收到ACK报文，应答报头中的窗口大小，表面对方的接收能力 win
变更滑动窗口
在这里插入图片描述
- 确认序号的意义：确认序号之前的报文全部收到了！

丢包:
快重传策略：必须收到3个同样的确认应答则进行重发。

  1. 最左侧丢包：滑动窗口不能进行右移！（我们不担心最左侧报文丢失，会对丢失的报文进行快重传与超时重传策略）
  2. 中间报文丢失：右滑转换为最左侧丢包问题
  3. 最右侧报文丢包：右划转换为最左侧丢包问题
    在滑动窗口内，所有的问题全部会转换成为最左侧丢包问题！

流量控制是如何做到的？

滑动窗口在滑动的过程中既可以变大也可以变小，也可以为0，滑动窗口的大小要和对方的接收窗口吻合，滑动窗口的大小暂时等于对方的接收能力。这样保证了既可以保证以最高的速率全力发送，又可以防止对方的数据进行溢出多发，即保证发送速率又保证接收能力。
滑动窗口是流量控制的具体实现，是重传策略的具体实现。

缓冲区是一个类似于环状队列所以不用担心数据的溢出

8. 拥塞控制

虽然 TCP 有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题.因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据, 是很有可能引起雪上加霜的.
TCP 引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

网络出现大面积丢包，说明网络拥塞了！
在这里插入图片描述

一但发生网络拥塞，识别到的网络拥塞主机全部要进行拥塞控制。

滑动窗口 == min(接收方的窗口（接收能力），拥塞窗口)

2^n -> 慢启动，拥塞控制的核心算法？
在这里插入图片描述
探测网络的健康状态：
在这里插入图片描述

  • ssthresh值：阈值，记录上一次拥塞窗口值(32位)的一半，作为下一次窗口变化的临界值，指数增长变为线性增长！

9. 面向字节流的特性

创建一个 TCP 的 socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;

  • 调用 write 时, 数据会先写入发送缓冲区中;
  • 如果发送的字节数太长, 会被拆分成多个 TCP 的数据包发出;
  • 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
  • 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
  • 然后应用程序可以调用 read 从接收缓冲区拿数据;
  • 另一方面, TCP 的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

由于缓冲区的存在, TCP 程序的读和写不需要一一匹配, 例如：

  • 写 100 个字节数据时, 可以调用一次 write 写 100 个字节, 也可以调用 100 次write, 每次写一个字节;
  • 读 100 个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100 个字节, 也可以一次 read 一个字节, 重复 100 次；

10. 粘包问题及解决方案

  • 先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.
  • 在 TCP 的协议头中, 没有如同 UDP 一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.
  • 站在传输层的角度, TCP 是一个一个报文过来的. 按照序号排好序放在缓冲区中.
  • 站在应用层的角度, 看到的只是一串连续的字节数据.
  • 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.

那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界.

  • 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的 Request 结构, 是固定大小的, 那么就从缓冲区从头开始按 sizeof(Request)依次读取即可;
  • 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
  • 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可);

思考: 对于 UDP 协议来说, 是否也存在 “粘包问题” 呢?

  • 对于 UDP, 如果还没有上层交付数据, UDP 的报文长度仍然在. 同时, UDP 是一个一个把数据交付给应用层. 就有很明确的数据边界.
  • 站在应用层的站在应用层的角度, 使用 UDP 的时候, 要么收到完整的 UDP 报文, 要么不收. 不会出现"半个"的情况

11. TCP异常情况处理

进程终止: 进程终止会释放文件描述符, 仍然可以发送 FIN. 和正常关闭没有什么区别.
机器重启: 和进程终止的情况相同.
机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行 reset. 即使没有写入操作, TCP 自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.
另外, 应用层的某些协议, 也有一些这样的检测机制. 例如 HTTP 长连接中,

12. TCP 小结

为什么 TCP 这么复杂? 因为要保证可靠性, 同时又尽可能的提高性能！
可靠性：

  • 校验和
  • 序列号(按序到达)
  • 确认应答
  • 超时重发
  • 连接管理
  • 流量控制
  • 拥塞控制

提高性能:

  • 滑动窗口
  • 快速重传
  • 延迟应答
  • 捎带应答

其他:

  • 定时器(超时重传定时器, 保活定时器, TIME_WAIT 定时器等）

基于 TCP 应用层

  • HTTP
  • HTTPS
  • SSH
  • Telnet
  • FTP
  • SMTP

当然, 也包括你自己写 TCP 程序时自定义的应用层协

13. TCP与UDP的对比

我们说了 TCP 是可靠连接, 那么是不是 TCP 一定就优于 UDP 呢? TCP 和 UDP 之间的优点和缺点, 不能简单, 绝对的进行比较

  • TCP 用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景;
  • UDP 用于对高速传输和实时性要求较高的通信领域, 例如, 早期的 QQ, 视频传输等. 另外 UDP 可以用于广播

归根结底, TCP 和 UDP 都是程序员的工具, 什么时机用, 具体怎么用, 还是要根据具体的需求场景去判定.

14. 用 UDP 实现可靠传输(经典面试题）

参考 TCP 的可靠性机制, 在应用层实现类似的逻辑;

例如:

  • 引入序列号, 保证数据顺序;
  • 引入确认应答, 确保对端收到了数据;
  • 引入超时重传, 如果隔一段时间没有应答, 就重发数据;
  • …

总结

经过对TCP协议的全面分析，我们可以得出以下结论：

  1. 可靠性：TCP通过序列号、确认应答、超时重传、连接管理、流量控制和拥塞控制等机制，确保数据的可靠传输。这些机制虽然增加了协议的复杂性，但也大大提高了数据传输的可靠性。

  2. 性能：尽管TCP的可靠性机制带来了一定的性能开销，但通过滑动窗口、快速重传、延迟应答和捎带应答等技术，TCP能够在保证可靠性的同时，尽可能地提高传输效率。

  3. 应用场景：TCP适用于需要可靠传输的应用，如文件传输、电子邮件、Web 服务等。而UDP则适用于对实时性和传输速度要求较高的应用，如视频传输、在线游戏等。

  4. 与UDP的对比：TCP和UDP各有优缺点，选择哪种协议取决于具体的应用需求。TCP提供了更可靠的传输保障，但可能会牺牲一些性能；UDP则在传输速度和实时性方面表现更优，但传输的可靠性较低。

  5. 实现可靠传输：即使在UDP这样的不可靠协议上，也可以通过应用层的逻辑实现类似TCP的可靠性机制，如序列号、确认应答和超时重传等。

通过本文的学习，读者应该能够更深入地理解TCP协议的工作原理，掌握其关键特性，并能够根据实际需求选择合适的传输层协议。希望本文能够为读者在网络编程和应用开发中提供有价值的参考。

标签：网络通信,UDP,窗口,应答,TCP,发送,Linux,报文
From： https://blog.csdn.net/Colorful___/article/details/140721139

相关文章

  • 【Linux】网络架构探秘：网络层功能、IP协议详解及路由过程指南
    文章目录前言：1.网络层是干什么的？2.IP协议2.1理论铺垫2.2IP协议的头格式2.3网段划分（重点）2.3.1分类划分法：2.3.2子网掩码：2.3.3为什么要经行子网划分?2.4特殊的IP地址2.5IP地址的数量限制2.6私有IP地址和公网IP地址3.路由过程总结：前言：在当今数字化时代......
  • Linux设置定时任务命令crontab详解教程
    一、crontab命令介绍crontab是一个在Linux系统中用于设置周期性被执行的任务的工具，‌即可以执行定时任务，它可以帮助用户实现定时间运行程序或脚本的需求。‌/var/spool/cron/目录下存放的是每个用户包括root的crontab任务，每个任务以创建者的名字命名/etc/crontab这个文......
  • Linux--shell脚本语言—/—＜2＞
    一、shell基本语法1、shell字符串        字符串（String）就是一系列字符的组合。字符串是Shell编程中最常用的数据类型之一（除了数字和字符串，也没有其他类型了）字符串可以由单引号''包围，也可以由双引号""包围，也可以不用引号。它们之间是有区别的。 1) 字符串举......
  • Linux--shell脚本语言—/—＜1＞
    一、shell简介        Shell是一种程序设计语言。作为命令语言，它交互式解释和执行用户输入的命令或者自动地解释和执行预先设定好的一连串的命令；作为程序设计语言，它定义了各种变量和参数，并提供了许多在高级语言中才具有的控制结构，包括循环和分支        Shel......
  • linux下时间时区详解
    首先我们要明白，“时间”和“时区”是两个东西。时间是指从某个时间点开始到另一个时间点经过的“长度”，是“纵向”距离，一般在linux系统内有两个主要的时间，一是始于1970年（unix元年）至今的距离，二是系统启动后至今的距离。前者一般是由不断电的硬件维护（RTC）或者其他专门服务器......
  • 基于OpenCV C++的网络实时视频流传输——Windows下使用TCP/IP编程原理
    1.TCP/IP编程1.1概念IP是英文InternetProtocol（网络之间互连的协议）的缩写，也就是为计算机网络相互连接进行通信而设计的协议。任一系统，只要遵守IP协议就可以与因特网互连互通。所谓IP地址就是给每个遵循tcp/ip协议连接在Internet上的主机分配的一个32bit地址。按照TC......
  • 【002】Linux配置静态ip地址
    一、环境虚拟机版本：VMwareLinux镜像文件：CentOS-7-x86_64-Minimal-2207-02.iso主机系统：Windows11家庭中文版主机系统类型：64位操作系统,基于x64的处理器远程连接工具：宝塔远程工具二、配置静态ip1、将虚拟机的网络模式设置为NAT模式2、设置VMware的网络模式选择VM......
  • Linux下安装OpenCV
    安装先安装依赖库：sudoapt-getinstallbuild-essentiallibgtk2.0-devlibgtk-3-devlibavcodec-devlibavformat-devlibjpeg-devlibswscale-devlibtiff5-dev根据官网教程进行安装：OpenCVGetStartedOperatingSystem:LinuxBuildingFromSource:YesLanguage:C++O......
  • 问题记录：解决Linux登录故障，/etc/passwd配置受损该怎么操作
    问题记录：解决Linux登录故障，/etc/passwd配置受损该怎么操作引言在维护Linux系统的过程中，可能会遇到各种紧急情况，其中/etc/passwd文件的损坏是运维人员特别需要准备应对的一种情形。该文件作为Linux用户账户信息的核心存储，一旦遭到破坏，会直接导致用户无法登录，甚至系统服务失......
  • Nexpose v6.6.263 for Linux & Windows - 漏洞扫描
    Nexposev6.6.263forLinux&Windows-漏洞扫描Rapid7VulnerabilityManagement,releaseJul31,2024请访问原文链接：https://sysin.org/blog/nexpose-6/，查看最新版。原创作品，转载请保留出处。您的本地漏洞扫描程序搜集通过实时覆盖整个网络，随时了解您的风险。......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99