一、TCP协议
TCP是面向连接的、可靠的、基于字节流的传输协议。
- 面向连接:一定是“一对一”才能连接,TCP协议无法实现一个主机向多个主机发送消息,即一对多是无法实现的
- 可靠的:无论网络链路中出现怎样的链路变化,TCP都能保证一个保文一定能到达接收端。
- 字节流:(1)当使用TCP协议进行传输时,数据传输可能会被操作系统分组成多个TCP保文,如果接收方不知道数据的边界,是无法读取出一个有效的数据的。(2)同时TCP的报文是有序的,当接收方先接收到了后一个报文,前一个报文没有收到时,那么也不能交给应用层去处理(3)当TCP接收到重复的TCP报文时,会自动丢弃重复的报文,只保留一个
1.1 TCP协议段
- 源端口号和目标端口号:表示进程从哪里来到哪里去
- 序列号:在建立连接时由计算机生成的随机数作为其初始值,通过 SYN 包传给接收端主机,每发送一次数据,就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。
- 确认应答号:发送端向接收端发送数据报文后,发送端期待接收到数据的序列号,发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题
- 6位标志位: - URG:紧急指针是否有效 ACK:确认号是否有效 PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走 RST:对方要求重新建立连接;我们把携带RST标识的称为复位报文段****SYN:请求建立连接;我们把携带SYN标识的称为**同步报文段 *FIN:通知对方,本端要关闭了,我们称携带FIN标识的为*结束报文段 **
1.2 TCP的原理
1.2.1 确认应答机制(安全机制)
确认应答机制是发送端发送数据给接收端,接收端收到数据后给发送端发送一个应答报文,此时发送端便知道接收端已经接收哪些序号的数据,下一次便知道从哪些数据开始发。
** 每一个确认应答ACK都带有对应的确认序列号,意思是告诉发送端,我已经收到了哪些数据,下一次你从哪里开始发**
![](https://img-blog.csdnimg.cn/07842cea9c034ef1ac39a431b03f5568.png)
1.2.2 超时重传机制(安全机制)
网络发送数据时,总是会出现各种错综复杂的情况,不一定都会出现确认应答机制那样传输数据,总会出现数据包丢失的情况,因此便有了超时重传机制。
超时重传机制使用在以下场景:
(1)数据包丢失
(2)确认应答ACK丢失
讨论:当确认应答ACK丢失后,过了一段时间,TCP进行超时重传,此时主机B已经收到了两段重复数据包,TCP会根据序列号对重复数据进行去重,只会保留一个相同的数据包。
超时时间的间隔是由 TCP为了保证在任何环境下都能进行高效通信传输,会动态的计算超时间隔时间。
如果一次超时重传失败,仍然得不到确认应答,此时会进行第二次重传,依次类推,以指数级递增,累计到一定次数重传失败,TCP认为网络或者对端主机出现严重问题,会强制断开连接。
1.2.3 TCP是如何实现可靠性传输?
答案:TCP的可靠性传输是由**确认应答机制**和**超时重传机制**来实现的
1.2.4 连接管理机制(安全机制)
** **在正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接。因此TCP在传输数据前必须要先进行三次握手连接,结束传输后进行四次挥手断开连接。
三次握手和四次挥手的经典面试题见文章【计算机网络之TCP/UDP篇】TCP的三次握手四次挥手
1.2.5 滑动窗口机制(效率机制)
正常情况下,对每一个发送的数据段,都要给一个ACK确认应答。收到ACK后再发送 下一个数据段。这样做有一个比较大的缺点,就是性能较差,尤其是数据往返的时间较长的时候。
因此就可以使用滑动窗口机制,那么我们一次发送多条数据,就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。
下图就是使用滑动窗口进行传输数据,同时将四个段的数据进行发送。
![](https://img-blog.csdnimg.cn/1fabfd7315e54d13a2618dd5a7068aa7.png)
1、窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000
个字节(四个段)。
2、发送前四个段的时候,不需要等待任何ACK,直接发送
3、收到第一个ACK后,滑动窗口向后移动,继续发送第五个段的数据;依次类推;
4、操作系统内核为了维护这个滑动窗口,需要开辟 **发送缓冲区 **来记录当前还有哪些数据没有应
答;只有确认应答过的数据,才能从缓冲区删掉;
5、窗口越大,则网络的吞吐率就越高;
1.2.6 流量控制机制
接收端接收处理的数据是有限的,当发送端发送的数据超过接收端处理数据的极限时,就会造成丢包,继而引起丢包重传等等一系列连锁反应。
因此TCP协议就根据接收端处理数据的能力来决定发送端发送数据的速度,这就是TCP的流量控制机制。
1、接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段,通过ACK端通知发送端;
2、窗口大小字段越大,说明网络的吞吐量越高;
3、接收端一旦发现自己的缓冲区快满了,就将窗口大小设置成一个更小的值通知给发送端;
4、发送端接受到这个窗口之后,就会减慢自己的发送速度;
5、如果接收端缓冲区满了,就会将窗口置为0;这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端。
1.2.7 **拥塞控制(安全机制) **
虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题。
因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的。TCP引入 **慢启动 **机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据;
** **** **
** 此处引入一个概念程为拥塞窗口 ,发送开始的时候,定义拥塞窗口大小为1; 每次收到一个ACK应答,拥塞窗口加1;每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小做比较,取较小的值作为实际发送的窗口;**
- 当TCP开始启动的时候,慢启动阈值等于窗口最大值;
- 在每次超时重发的时候,慢启动阈值会变成原来的一半,同时拥塞窗口置回1;
- 少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络拥塞;
- 当TCP通信开始后,网络吞吐量会逐渐上升;随着网络发生拥堵,吞吐量会立刻下降;
- 拥塞控制,归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大压力的折中方案。
1.2.8 **延迟应答(效率机制) **
如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小
- 假设接收端缓冲区为1M。一次收到了500K的数据;如果立刻应答,返回的窗口就是500K; 实际上可能处理端处理的速度很快,10ms内就把500K数据从缓冲区消费了;
- 在这种情况下,接收端处理还远没有达到自己的极限,即使窗口再放大一些,也能处理过来;
- 如果接收端稍微等一会再应答,比如等待200ms再应答,那么这个时候返回的窗口大小就是1M;
一定要记得,**窗口越大,网络吞吐量就越大,传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率; **
1.2.9 **捎带应答(效率机制) **
在延迟应答的基础上,我们发现,很多情况下,客户端服务器在应用层也是 "一发一收" 的。意味着客户端给服务器说了 "How are you",服务器也会给客户端回一个 "Fine, thank you";
那么这个时候ACK就可以搭顺风车,和服务器回应的 "Fine,thank you" 一起回给客户端
1.3 TCP总结
TCP是面向连接的、可靠性的和基于字节流的,因此TCP协议不仅为了保证数据的可靠性传输,还要提高数据传输的效率性,于是在传输数据时是十分复杂的。
TCP的可靠性机制
校验和
序列号(按序到达)
确认应答
超时重发
连接管理
流量控制
拥塞控制
TCP提高性能
滑动窗口
快速重传
延迟应答
捎带应答
二、UDP协议
UDP协议是**无连接的**、**不可靠的**、**面向数据报**的传输协议
无连接
知道对端的IP和端口号就直接进行传输,不需要建立连接;
不可靠的
没有任何安全机制,即使UDP发送的数据报在网络阻塞中丢失了,也不会给应用层发送任何信息,因此应用层也无法接收到任何消息
面向数据报
应用层交给UDP多长的报文,UDP原样发送,既不会拆分,也不会合并;
举例:用UDP传输100个字节的数据:如果发送端发送100个字节,那接收端也必须接收100个字节,而不能循环接收10次
UDP的socket既能读,也能写,这个概念叫做 全双工
经典面试题:
UDP本身是无连接,不可靠,面向数据报的协议,如果要基于传输层UDP协议,来实现一个可靠传输,应该如何设计?
UDP大小是受限的,如果要基于传输层UDP协议,传输超过64K的数据,应该如何设计?
两个问题答案类似,都可以参考**TCP****的可靠性机制**在**应用层**实现类似的逻辑:
(1)引入序列号,保证数据顺序;
(2)引入确认应答,确保对端收到了数据;
(3)引入超时重传,如果隔一段时间没有应答,就重发数据
三、TCP与UDP的区别
TCP是面向连接的、可靠性的、基于字节流的传输控制协议
UDP是无连接的、不可靠的、数据报传输的传输协议
1、TCP协议多用于可靠性传输,要求精度高的场景,例如:文件传输、重要状态更新等场景
2、UDP协议相对于来说就很简单,简单到只负责发送数据包,不保证数据包能够准确的发送到对方接收端的手中;
但UDP的**实时性相对更好,传输效率也更高**。应用场景:用于对高速传输和实时性要求较高的通信领域,例如,早期的QQ,视频传输等。另外UDP可以用于广播;
版权归原作者 是烟花哈 所有, 如有侵权,请联系我们删除。