相比于 UDP 来说,TCP 的主要特性是三个:有连接、可靠、面向数据流。所谓的“有连接”指的是 TCP 中的连接管理机制,也就是著名的三次握手和四次挥手,就像打电话一样,想要正常的交流,必须先和对方建立起连接,这就是所谓的“有连接”,而面向数据流的机制咱们以后再讲,我们今天要讨论的主题是:TCP 是如何保证可靠性的?
TCP 之所以能保证可靠性,主要是通过以下 6 个手段:
接下来,我们详细来看这几种手段的具体实现。
TCP 协议的数据格式如下图所示:
(图片来源:许许如生xxrs)
从上图可以看出“校验和”是保存在 TCP 首部中的一个数据,TCP 的发送端和接收端会采用相同的算法,根据发送的数据计算出一个 16 位的校验和,并且校验和会连同数据一起发送给接收端。
接收端在得到数据之后,会根据接收的数据生成一个新的校验和,然后用新的校验和与传递过来的校验和做对比,如果校验和相同,那么说明数据在传递过程中没有发生任何改变,是一个有效的数据,反之则为无效数据,舍弃即可。
TCP/UDP/IP 等协议的校验和算法都是相同的,采用的都是将数据流视为 16 位整数流进行重复叠加计算。为了计算检验和,首先把检验和字段置为 0,然后,对有效数据范围内中每个 16 位进行二进制反码求和,结果存在检验和字段中,如果数据长度为奇数则补一字节 0。当收到数据后,同样对有效数据范围中每个 16 位数进行二进制反码的求和。由于接收方在计算过程中包含了发送方存在首部中的检验和,因此,如果首部在传输过程中没有发生任何差错,那么接收方计算的结果应该为全 0 或全 1(具体看实现了,本质一样) 。如果结果不是全 0 或全 1,那么表示数据错误。
确认应答机制是保证消息传递可靠性的关键手段,也是几乎所有消息中间件(MQ)中,最常用的技术之一,比如主流的消息中间件 RabbitMQ、Kafka、RocketMQ 中都有确认应答机制,也就是我们常说的 ACK(ACKnowledge Character,确认字符)。
确认应答机制是 TCP 中,保证消息可靠性的核心机制。怎么才能确认你发的消息对方一定收到了呢?最有效的手段无疑是对方告诉你,它已经收到了,这就是确认应答。
确认应答的流程如下图所示:
消息在确认应答的过程中可能会出现两个问题:第一,消息在发送的时候丢失了,第二,消息在确认应答时丢失了,如下图所示:
显然,即使有了确认应答机制也保证不了消息不丢失,那怎么办呢?
消息丢了没关系,发送端在确认了消息丢失之后,再补偿一个同样的消息给接收端不就解决了?这就是超时重传机制。
TCP 的超时重传机制在设计上也非常巧妙,它为了保证消息在任何环境中,都能高效的通讯,所以 TCP 采用的是“动态时间”的超时重传机制。
比如第一次如果消息丢了,那么发送端会在 500ms 之后再发送一个消息,如果发送的第二个消息也丢了,那么发送端会在 1000ms 之后再发送一个消息,如果第三个消息也丢了,那么它会在 2000ms 之后再发送一个消息,如果累计了一定的次数,消息还没有成功的发送,那么 TCP 会认为对方主机存在异常,会强制关闭连接,这就是 TCP 超时重传的主要执行流程。
接收端处理数据的速度是有限的,如果发送端发的太快,那么就会导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继而引起丢包重传等等一系列连锁反应。
因此 TCP 会根据接收端的处理情况,动态调整发送数据的大小,这个机制就叫流量控制(Flow Control)。
拥塞控制指的是 TCP 会根据当前网络的情况,动态的控制发送数据的多少,以适合的速度来传递数据。
想象一下,如果 TCP 在不清楚网络情况的环境下,贸然的发送大量的数据给接收端,这样就会导致更多的丢包及超时重传,从而引起一系列的连锁反应,导致数据传递变慢。
而 TCP 采取的是“慢启动”机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据,这就是拥塞控制机制。
如果传递的数据多了,出现了大量的丢包,那么 TCP 会将发送的数据量调小,然后再尝试慢慢的增加发送的数据量,通过这种动态发送数据包的形式,来实现适合当前网速的数据传递,这就是 TCP 拥塞控制的具体实现。
通过前面的知识我们知道,在确认应答时,由于确认应答消息的丢失,那么接收方可能会收到发送方的重复数据,如下图所示:
而此时对于业务方来说,只需要一个数据就可以了,所以 TCP 还有一个机制,丢弃重复数据的机制,这样就能保证业务方接收到的数据是正确的了。
TCP 会给每一个发送的包上加上一个编号,如果接收到了编号相同的数据包,那么就说明接收端得到了重复的包,丢弃即可。
TCP 保证可靠性的主要手段有 6 个:校验和、确认应答、超时重传、流量控制、拥塞控制、丢弃重复数据。其中流量控制和拥塞控制很容易搞混,我们要清楚的知道,流量控制是针对接收端接收能力的控制机制,而拥塞控制是针对当前网络的控制机制,所以千万不要搞混了。
blog.csdn.net/namelcx/article/details/6866720
是非审之于己,毁誉听之于人,得失安之于数。
公众号:Java面试真题解析
面试合集: https://gitee.com/mydb/interview
来自:https://www.cnblogs.com/vipstone/p/16538313.html
先说一下网络的层级:由下往上分为 物理层、数据链路层、网络层、传输层、会话层、表示层和应用层,TCP:是面向连接的一种传输控制协议。属于传输层协议。UDP:是面向非连接的用户数据报协议。HTTP是基于TCP协议的应用的超文本传输协议,属于应用层的协议。
node.js中net模块为我们提供了TCP服务器和客户端通信的各种接口。创建服务器并监听端口,net.Socket是一个socket端口对象,是一个全双工的可读可写流,创建一个tcp客户端
在http早期,每个http请求都要求打开一个tpc socket连接,并且使用一次之后就断开这个tcp连接。使用keep-alive可以改善这种状态,即在一次TCP连接中可以持续发送多份数据而不会断开连接
HTTP是应用层协议。TCP是传输层协议。HTTP是建立在TCP协议之上。在http1.0阶段,完成一次http请求之后,就会断开http连接,同时TCP连接也会断开。所以每次HTTP请求都会先建立TCP连接,然后建立HTTP连接。
TCP报文段中的窗口这16位字段部分,这里窗口的作用就是为了实现流量的控制,为什么会有流量的控制的引入???它是这样来的:若是发送方发送数据的速度大于了接收方应用程序取数据的速度(假设数据传输过程不拥塞)
没有永远不出错误的通信,这句话表明着不管外部条件多么完备,永远都会有出错的可能。所以,在 TCP 的正常通信过程中,也会出现错误,这种错误可能是由于数据包丢失引起的,也可能是由于数据包重复引起的,甚至可能是由于数据包失序 引起的。
下面的表格中列举了包括在红帽企业 Linux 中的服务、守护进程、和程序所使用的最常见的通信端口。该列表还可以在 /etc/services 文件中找到
TCP 是一个面向连接的、可靠的、基于字节流的传输层协议。而 UDP 是一个面向无连接的传输层协议。(就这么简单,其它 TCP 的特性也就没有了)。具体来分析,和 UDP 相比,TCP 有三大核心特性:
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!