TCP 和 UDP 详解

TCP和UDP都是传输层的协议,用来定义数据传输的协议。

1. TCP

TCP的特点是面向连接,可靠。

面向连接体现在,在数据传输之前,需在客户端和服务器之间通过三次握手建立连接。数据传输完之后,需通过四次挥手断开连接。

三次握手和四次挥手的过程就不展开讲了,注意理解 为什么是三次握手? 以及为什么时四次挥手?

面向连接是TCP可靠性的体现之一,因为数据都是在 TCP 连接上进行传输的,有效的连接能够保证传输的可靠性。

可靠性的体现

1. 校验和

在发送方将整个报文分为16位的段,然后将所有段进行反码相加,将结果存放在校验和字段中。

接收方使用相同的方法进行计算,再加校验和,如果所有位都为1则正确,否则错误。

2. 序列号机制

TCP对每个字节的数据都进行了编号,即序列号。

a、保证可靠性(当接收到的数据总少了某个序号的数据时,能马上知道)
b、保证数据的按序到达
c、提高效率,可实现多次发送,一次确认
d、去除重复数据

3. 确认应答机制 ACK

在TCP的首部中有一个标志位——ACK,此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认,当标志位ACK=1时确认首部的确认字段有效。进行确认时,确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文,则继续传输下一部分数据;而如果等待了一定时间还没有收到确认报文就会启动重传机制。

4. 超时重传机制

如果发送方在发送报文一段时间后没有收到确认ACK,会启动重传机制。

未收到ACK,不一定是数据包丢了,也可能是确认ACK丢了。

如果是确认ACK丢了,启动重传机制后,接收方会收到两次相同的数据,可通过序列号对其去重。

     

5. 流量控制

接收方处理数据的速度是有限的,如果发送方发送数据速度过快,就会堆满接收方窗口,发送方继续发送,会导致丢包,重传等一系列动作。

流量控制就是根据接收方的处理能力(接收缓冲区的“剩余空间大小”)来反向制衡发送方的发送速率(窗口大小)。

当接收端接收到发送方的数据后,在应答报文ACK中携带缓冲区的剩余大小。

如果接收方反馈的剩余大小为0,则发送方会发送试探报文,试探出接收方剩余的窗口大小。

滑动窗口机制

为了提高 tcp 的通信效率,使用滑动窗口来同时发送和接收多个数据包。

 上图中,每 1000 个字节表示一个数据包。发送端同时发送了 3 个数据包(2001-5000),接收端响应的确认应答包为“下一个发送4001”,表示接收端成功响应了前两个数据包,没有响应最后一个数据包。此时,最后一个数据包要保留在窗口中。

可能会出现的种情况:

第一种:ACK丢失。

如果前面的数据(比如3001-4000)没有收到 ACK 确认包,而后面的数据(比如4001-5000)收到了ACK确认包,则发送端不需要重新发送前面的数据包。

如果是最后一个数据包丢了,最后有个 FIN 包作为接收响应。

第二种:数据包丢了

如果数据包丢了就会进行重传,此处重传只是重传丢了的数据,其他数据不需要额外重传。

如果中间两次丢包:

第三种:数据包先发后到

TCP适合场景:

Web项目中常见的服务器和浏览器之间的数据传输,文件传输,远程登陆等等。

2. UDP

UDP不需要建立连接,直接发送数据,无连接使得UDP不存在建立连接的时延。

不保证可靠性,没有TCP的确认机制、重传机制,如果因为网络原因没有传送到接收端,UDP也不会给应用层返回错误信息。

UDP面向报文,应用层交给传输层多长的报文,UDP都会一次发送,报文是UDP发送数据的最小单位

UDP也有校验和机制,只用来检错,机制与TCP校验和相同。如果UDP校验和校验出UDP数据报是错误的,可以丢弃,也可以交付上层,但是要附上错误报告,告诉上层这是错误的数据报。

适合场景:适合于对速率和时延要求高,但对准确性要求不高的场景。如:网络聊天,网络电话等等

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值