【网络基础2】深入理解TCP协议:协议段、可靠性、各种机制 |
您所在的位置:网站首页 › udp使用什么协议提供可靠性 › 【网络基础2】深入理解TCP协议:协议段、可靠性、各种机制 |
文章目录
1. TCP协议段格式1.1. 如何解包 / 向上交付1.1.1. 交付1.1.2. 解包
1.2. 如何理解可靠性1.2.1. 确认应答机制(ACK)1.2.2. 序号 与 确认序号
2. TCP做到全双工的原因2.1. 16位窗口大小2.2. 6个标记位
3. 如何理解连接3.1 连接管理机制3.1.1. 三次握手3.1.2. 四次挥手什么是 TIME_WAIT / CLOSE_WAIT
4. TCP实现可靠性的方式4.1. 发送缓冲区4.2. 超时重传机制4.3. 流量控制
5. TCP 提高性能的方式5.1. 滑动窗口5.1.1. 作用 与 本质5.1.2. 完善理解 - 模型5.1.3. 滑动窗口的部分问题
5.2. 快重传(高速重发机制)5.3. 拥塞窗口(tmp)5.4. 延迟应答5.5. 捎带应答
6. 如何理解 TCP面向字节流?6.1. 粘包问题6.2. TCP异常情况 状态
7. TCP总结8. 基于TCP的应用层协议9. TCP / UDP 对比10. TCP相关实验 - listen的第二个参数理解
1. TCP协议段格式
下图为TCP协议段格式: TCP的报头前两项和UDP一样(交付过程也类似UDP),根据16位目的端口号(源端口号),可以将数据向上交付给进行(进程绑定了端口号)。 1.1.2. 解包 首先根据TCP协议端格式,了解到TCP报头标准长度为20字节。在这20字节中存在名为 4位首部长度 的内容, 4位首部长度的范围即 0000 ~ 1111 转十进制即 0 ~ 15,而该字段的单位为4字节,得到TCP报头的长度范围为[20, 60]下面分析解包的过程: 提取20字节(标准长度)根据标准报头,提取4位首部长度 * 4,如果等于20,解包结束,否则继续读取(4位首部长度 * 4 - 20)字节数据,即“选项”内容此时报头读完,剩余的为有效载荷根据上面的内容,引出一个疑问,我们知道UDP是面向数据报的,协议段中有整个报文的大小,那么对于TCP面向字节流,协议段中有没有整个报文或是有效载荷的大小呢 1.2. 如何理解可靠性我们知道TCP是可靠的,而UDP是不可靠的,可靠就是好,不可靠就是坏吗? 网络通信中,可靠性指的是数据传输的确保性和完整性:。即两台主机/进程通信时,双方能完整正确的获得对方通信的内容。举个例子:![]() ![]() 那么存不存在 100%可靠性的协议呢? —— 不存在! 再次举一个例子: 我们知道,TCP是全双工 的:通信双方可以同时进行接收和发送数据。 在通信的过程中,客户端向服务端发送了数个消息,服务端都一一应答,如何保证客户端接收到的消息能正确匹配呢?(如果不能正确顺序接收,会发生乱序,也是不可靠的一种)![]() ![]() 对于 序号 与 确认序号: 两台主机通信的时候,显然 发送方 应确保数据的发送不能过快 / 过慢,如何保证发送放发送数据的速度适中呢? 接收方始终给发送方同步自己的接收能力:我们知道TCP通信时,实际是将数据传输到缓冲区中,自然接收能力与接收缓冲区相关:接收能力由TCP协议段中的 16位窗口大小决定:16位窗口大小 即:接收缓冲区的剩余空间大小通信双方同时向对方发送自身的接收能力,也是构成全双工的一点。 2.2. 6个标记位标记位:1bit表示的某种含义 如上图所示,实际的连接过程中,会有大量的client连接server,自然服务器端会有大量的连接,操作系统如何管理? 先描述,再组织 。连接的本质:本质是内核的一种数据结构类型,建立连接成功时,在内存中建立相应的连接对象,再对多个连接对象进行某种数据结构组织。 3.1 连接管理机制连接管理机制主要包括 三次握手和四次挥手、以及客户端与服务端的状态变化。 3.1.1. 三次握手三次握手的过程可以由下图解释: 而TCP所采用的三次握手的机制较好的解决了这一问题: 第一次握手:客户端发送连接请求给服务器,表明客户端想要建立连接。第二次握手:服务器接受连接请求,并发送确认给客户端,同时表明服务器也愿意建立连接。第三次握手:客户端收到服务器的确认,并向服务器发送确认,表明客户端也愿意建立连接。显然TCP的三次握手: server端嫁接相同的成本给client端验证了全双工而在保证了客户端服务器通信功能完善的情况下,采用四次握手自然会造成: 额外的通信开销:四次握手需要额外的一轮通信,相比于三次握手,会增加一定的通信开销和时间延迟。 复杂性增加:四次握手会增加协议的复杂性,使得实现和管理起来更加繁琐,容易引入错误。 性能影响:每增加一轮握手,都会增加连接建立的时间延迟,可能对某些应用场景的性能产生影响。 且TCP的三次握手在大多数情况下已经被证明是足够可靠和安全的。 3.1.2. 四次挥手下图为四次挥手的过程: TIME_WAIT和CLOSE_WAIT分别表示连接已关闭但仍在等待一段时间以确保任何延迟数据包到达或确认。 TIME_WAIT: 在TCP连接正常关闭后,主动关闭连接的一方(通常是客户端)会进入TIME_WAIT状态。在TIME_WAIT状态下,该端口将等待一段时间(通常是2倍的MSL,最长生存时间,保证历史数据从网络中消散),确保在网络中所有的数据包都已经到达目的地,而对端已经收到并确认了最后一个ACK。这个等待时间段的主要目的是确保之前的连接中的所有数据包都已经在网络中被处理完毕,避免新连接中混入旧连接的数据包。TIME_WAIT状态的连接不能再接收新的数据包,但仍然能够发送和接收一些控制报文(如RST报文)。CLOSE_WAIT: 当一端关闭连接,但另一端仍然发送数据时,后者(通常是服务器端)会进入CLOSE_WAIT状态。CLOSE_WAIT状态表示本地端已经收到远程端发送的FIN报文,并关闭了连接,但仍然需要等待本地应用程序处理完所有的数据后才能关闭套接字。如果在CLOSE_WAIT状态持续过长时间,可能会导致资源泄漏或连接耗尽的问题。 4. TCP实现可靠性的方式 4.1. 发送缓冲区如何理解TCP的发送缓冲区,可以将其看作一个char sendbuffer[NUM] 的数组 所以对于TCP,收到了重复报文,可以通过序号进行去重。 4.2. 超时重传机制我们来看下图: 对于上面的情况,当主机A发送给主机B数据,且在特定的时间间隔未收到确认应答(网络拥堵、丢包等),就会重传数据。 实际上,未收到确认应答,也可能是由于ACK(应答)丢失:
流量控制(Flow Control)用于确保发送端发送的数据不会超过接收端的处理能力,从而避免数据丢失、拥塞和重传等问题。 TCP的流量控制机制主要通过 滑动窗口 实现。 接收端会在TCP报文的ACK中通知发送端自己的接收窗口大小,即可接收的数据量。发送端根据这个接收窗口大小来控制发送数据的速度,确保不会发送超出接收端处理能力的数据量。首先我们介绍流量控制的相关事项和步骤,后面对滑动窗口进行深度了解: 接收端 将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;窗口大小字段越大, 说明网络的吞吐量越高;接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;发送端接受到这个窗口之后, 就会减慢自己的发送速度;如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端首先通过下图理解滑动窗口的作用:将发送缓冲区分成三部分。 滑动窗口的本质是什么? 滑动窗口内的大小意味着:发送方可以一次性向对方推送的数据上限滑动窗口也应有上限:上限由对端的接受能力决定 5.1.2. 完善理解 - 模型滑动窗口是什么结构?内部结构是什么样的?来看下图: 我们知道,两台主机通信过程中,丢失了中间的ACK问题不大,只要有后面的确认应答(ACK)即可,但丢失了数据包(报文)该怎么办呢?:
通过上面的内容我们知道,有了滑动窗口,TCP可以效可靠的发送大量的数据. 但是如果在通信开始阶段就发送大量的数据, 仍然可能引发问题. 两台主机在通信时,传输效率以及可靠性,需要考虑主机自身的各种因素,而网络更是不可忽略的一大因素: 从宏观角度看,网络并非只有我们考虑的两台主机使用,网络上有很多的计算机,可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能使网络状况更加糟糕的。 TCP引入 慢启动 机制, 先发少量的数据探路, 了解了当前的网络拥堵状态后, 再决定按照多大的速度传输数据。 发送开始的时候, 定义拥塞窗口大小为1;每次收到一个ACK应答, 拥塞窗口加1;每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口![]()
少量的丢包, 仅仅触发超时重传,大量的丢包,我们就认为网络拥塞。 当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降; 拥塞控制, 实际是TCP协议尽量快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案。 5.4. 延迟应答我们知道:滑动窗口的大小与拥塞窗口和对方的接收能力有关,如果每次接收端收到报文后就立刻发送ACK,此时发送端接收到的窗口就比较小: 延迟应答的步骤: 假设接收端缓冲区为1M. 一次收到了1000K的数据; 如果立刻应答, 返回的窗口大小就是1000K;但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;如果接收端等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;这种方法可以更好的提升效率,减少网络拥塞延迟方式 窗口越大,传输效率就越高,我们的目的是在网络不拥堵的前提下提高效率,有两种延迟的方式: 数量限制:每隔N个包就应答一次时间限制:超过最大限制时间就应答一次具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;我们知道:TCP是全双工的 双方通信的过程中,主机B接收消息的同时也会向主机A发送消息,即接收到消息的同时将ACK和待发送的消息捆绑一起发送给主机A。这个概念是比较好理解的,根据文字理解就好。 6. 如何理解 TCP面向字节流?当我们 创建一个TCP的socket, 同时会在内核中创建一个 发送缓冲区 和一个 接收缓冲区 当调用write写入数据时时, 数据会先写入发送缓冲区中;如果发送的字节数太长,会被拆分成多个TCP的数据包发出;如果发送的字节数太短, 就会先在缓冲区里等待,在缓冲区长度合适 或 其他合适的时机发送出去;接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据;由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如: 写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;即当把字节数据发送给对方时,如何提取数据完全由对端的上层决定,发送端不考虑也不在乎,即面向字节流,可以整段提取,或者分段提取,应用层的角度看:TCP按照报文序号传送数据,这些数据被看作字节数据(即字节流) 6.1. 粘包问题 粘包问题中的 “包” , 是指的应用层的数据包我们知道:在TCP的协议头中, 没有像 UDP协议段的 “报文长度” 字段, 但是有“序号”字段;传输层的角度:TCP传输数据通过一个个报文,按照序号排序后放在缓冲区中;站在应用层的角度:传输的数据只是一串连续的字节数据从上面面向字节流我们知道:接收方如何提取数据完全由自己的上层决定,应用程序看到的只是一连串的字节数据, 不知道从哪里分段, 是一个完整的应用层数据包,比如:如果选择接收1000字节的数据,提取到的是350+350+300:此时就将一个数据包的内容给截断了。这种情况就叫做粘包问题![]() 那么如何避免粘包问题?—— 明确两个包的界限 如果接收端看到的只是一个完整的数据报,自然无从下手,只要有了明确的包与包的界限,就很容易提取数据了 对于定长的包:保证每次都按固定大小读取; 例如上图, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;对于变长的包: 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置。对于变长的包: 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序员自己定的, 只要保证分隔符不和正文冲突即可)思考:UDP会不会出现粘包问题? 当然不!UDP是面向数据报的UDP一个个将数据交付给应用层,有很明显的界限以应用层的角度分析:UDP传输要么接收完,要么不接收,不会出现接收一半的截断状况 6.2. TCP异常情况 状态 进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别。 机器重启: 与进程终止的情况相同。 机器掉电 / 网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset。 即使没有写入操作, TCP自身也内置了一个保活定时器,会定期询问对方是否还在,如果对方不在, 就把连接释放。应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接文章上面都介绍了哪些内容?可以看看下面TCP的总结,顺便思考自己是否理清了其内容。 7. TCP总结可靠性 校验和序列号(按序到达)确认应答超时重发连接管理流量控制拥塞控制提高性能 滑动窗口快速重传延迟应答捎带应答其他 定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等) 8. 基于TCP的应用层协议许多 基于TCP的应用层协议 被广泛用于各种网络应用中。这些协议利用TCP的可靠性和连接性来实现各种功能。 HTTP(超文本传输协议):用于在Web服务器和客户端之间传输超文本文档,支持可靠的数据传输和连接性。 SMTP(简单邮件传输协议):用于在邮件服务器之间或邮件客户端与服务器之间传输电子邮件消息。 POP3(邮局协议版本3):用于从邮件服务器上获取电子邮件消息。 IMAP(互联网消息访问协议):类似于POP3,也是用于从邮件服务器上获取电子邮件消息,但提供了更丰富的功能,如在服务器上管理邮件的状态。 FTP(文件传输协议):用于在客户端和服务器之间传输文件。 Telnet(远程终端协议):允许用户通过网络连接到远程主机并执行命令。 SSH(安全外壳协议):用于通过加密的方式在网络上安全地连接到远程主机。 DNS(域名系统):用于将域名解析为IP地址,以便在网络上定位主机和服务。 9. TCP / UDP 对比首先提出一个问题: 我们知道 TCP是可靠连接,而TCP是不可靠连接,但可靠与否并非直接决定好坏,什么时候使用哪一种连接方式是要分情况讨论的: TCP用于可靠传输和顺序交付的情形, 应用于文件传输, 重要状态更新等场景; 适用于需要确保数据完整性和可靠性的应用,因为TCP提供了重传、排序和确认等机制。对延迟要求不是特别敏感的应用,因为TCP的流量控制和拥塞控制机制可能会引入一定的延迟。适用于数据量较大的传输,因为TCP的滑动窗口机制可以有效地处理大量数据的传输。UDP用于对高速传输和实时性要求较高,可靠性要求不那么高 的通信领域, 如 音频、视频传输; 适用于广播和多播场景,因为UDP支持多播和广播传输。适用于短小的数据包传输,因为UDP不提供重传和确认机制,因此对于大量数据或需要可靠传输的数据不太适用。适用于需要较少的网络开销和较小的头部开销的场景,因为UDP的头部开销较小,没有TCP的连接建立和维护开销。 10. TCP相关实验 - listen的第二个参数理解根据以上的内容,我们进行一个思考,在我们编写TCP编程的相关代码时, 使用accept函数时,accept会不会参与到三次握手的过程? 答: 不需要参与,先建立好连接后,accept直接获取建立好的连接。 根据上面的分析,可以得到结论: 不需要调用accept就可以建立连接 如果上层来不及调用accept,且对端来了大量连接,怎么办 提前建立好连接? 答:服务器本身要维护一个连接队列,用于存储客户端的连接请求,其中与listen的第二个参数有关。 我们首先通过代码验证上面的结论: “不需要调用accept就可以建立连接” 写一个简单的套接字代码: Sock.hpp #pragma once #include #include #include #include #include #include #include #include #include #include #include #include using std::string; class Sock { private: // 将listen的第二个参数设为1 const static int gbacklog = 1; // 监听队列的最大数量 public: Sock() {} ~Sock() {} int Socket() // 创建监听socket { int listenSock = socket(AF_INET, SOCK_STREAM, 0); if(listenSock |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |