TCP与UDP区别详解

TCP与UDP区别详解计算机与其他网络设备相互通信,通信的双方在发送和接收数据包时必须基于相同的规则(例如:如何找到通信目标、如何发起通信、如何结束通信等规则都需要事先确定),我们将这种规则称为协议(Protocol)。 TCP/IP协议簇是 Internet 的基础,其是一系列网络协议的总称,例如…

TCP与UDP区别详解

计算机与其他网络设备相互通信,通信的双方在发送和接收数据包时必须基于相同的规则(例如:如何找到通信目标、如何发起通信、如何结束通信等规则都需要事先确定),我们将这种规则称为协议(Protocol)。

TCP/IP协议簇是 Internet 的基础,其是一系列网络协议的总称,例如:TCP、UDP、IP、FTP、HTTP、ICMP、SMTP等都属于TCP/IP协议族内的协议。 这些协议在计算机网络中自下而上被划分为四层:链路层、网络层、传输层和应用层。

  • 链路层: 负责发送和接收ARP/RARP报文;
  • 网络层: 该层包含IP协议、RIP协议(Routing Information Protocol),主要负责数据包在主机之间的传输
  • 传输层: 主要负责定位处理数据的具体进程并转发数据(TCP协议提供可靠的数据流运输服务,UDP协议提供不可靠的数据服务);
  • 应用层 负责向用户提供应用程序,比如HTTP、FTP、Telnet、DNS、SMTP等;
开放式系统互联通信参考模型

在网络体系结构中网络通信的建立必须是在通信双方的对等层进行,不能交错。 在整个数据传输过程中,数据在发送端经过各层时都要附加上相应层的协议头和协议尾(仅链路层需要封装协议尾)。

UDP 与 TCP 两种传输协议是 TCP/IP 协议簇的核心成员。

一、UDP

UDP(User Datagram Protocol)全称是用户数据电报协议,是一种无连接的协议,提供不可靠的用户数据报服务,1980 年发布的 RFC 768 定义了 UDP 协议。

UDP数据结构

UDP数据结构如下图所示:

UDP数据

UDP 协议头中只包含 4 个字段:源端口、目的端口、UDP长度、UDP校验码,其中每一个字段都占 16 位,即 2 字节,共8个字节。

  • 源端口 发送方进程的端口号,接收方可以使用该字段(不一定准确)向发送方发送信息(范围0-65535);
  • 目的端口 数据接收方的端口号(范围0-65535);
  • UDP长度 协议头和数据报中数据长度的总和,表示整个数据报的大小;
  • UDP校验码 使用 IP 首部、UDP 首部和数据报中的数据进行计算,接收方可以通过校验码验证数据的准确性,发现传输过程中出现的问题;

UDP首部数据举例

常见的 DNS 协议就可以使用 UDP 协议获取域名解析的结果:

0000   ff 7c 00 35 00 23 c2 6e

上述 UDP 首部中四个字段对应的值如下:

  • 源端口 0xff7c = 65404
  • 目的端口 0x0035 = 53 由于 DNS 协议使用的端口是 53,所以目的端口就是 53
  • UDP长度 0x0023 = 35
  • UDP校验码 0xc26e

UDP在数据传输中的位置

这里我们可以将应用到应用之间的传输过程分成两个部分: 主机到主机的数据传输主机到应用的数据转发

  • UDP 协议首部的目的端口号用于定位处理数据的具体进程并转发数据;
  • UDP 协议底层的网络层IP协议(Internet Protocol)会负责数据包在主机之间的传输;

我们说 UDP 协议是传输层协议,但是真正在主机间完成数据传输工作的是 IP 协议UDP 协议只起到了定位具体进程的作用。

UDP数据传输的特点

  • 面向无连接 UDP 不需要与 TCP一样在发送数据前进行三次握手建立连接,UDP想发数据就直接发送了;并且UDP只是数据报文的搬运工,不会对数据报文进行任何拆分和拼接操作。
  • 不可靠 首先不可靠性体现在无连接上,通信都不需要建立连接,想发就发,这样的情况肯定不可靠的;并且收到什么数据就传递什么数据,也不会备份数据,发送数据也不会关心对方是否已经正确接收到数据; 再者网络环境时好时坏,但是 UDP 因为没有拥塞控制,一直会以恒定的速度发送数据;即使网络条件不好,也不会对发送速率进行调整,这样实现的弊端就是在网络条件不好的情况下可能会导致丢包,但是优点也很明显,在某些实时性要求高的场景(比如直播、电话会议等)就需要使用 UDP 而不是 TCP;
  • 单播、多播、广播功能 由于 UDP 不会建立连接,因此它可以给任何人传递数据,不止支持一对一的传输方式,同样支持一对多、多对多、多对一的方式;
  • UDP是面向报文的 发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层(UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界);
  • 头部开销小,传输数据高效 UDP 的头部开销小,只有八字节,在传输数据报文时是比较高效的(在某些实时性要求高的场景,例如直播、电话会议、媒体传输等场景经常使用 UDP协议);
UDP数据传输

二、TCP

TCP(Transmission Control Protocol)协议全称是传输控制协议,是一种面向连接的、可靠的、基于字节流的传输层通信协议,由RFC 793定义。

当用户查看网页或电子邮件时,希望看到的内容完整且顺序正确,不丢失任何内容;当下载文件时,希望获得的是完整的文件,而不仅仅是文件的一部分;以上应用场景的传输层协议均可采用TCP协议。

TCP数据结构

TCP数据结构

  • 源端口、目标端口 发送方进程的端口号,数据接收方的端口号(范围0-65535);
  • 序号 主要是为了解决乱序问题(编好号才知道哪个先来,哪个后到);
  • 确认序号 发出去的包应该有确认,这样能知道对方是否收到,如果没收到就应该重新发送,这个解决的是不丢包的问题;
  • 状态位 SYN 是发起一个链接,ACK 是回复,RST 是重新连接,FIN 是结束连接(TCP 是面向连接的,因此需要双方维护连接的状态,这些状态位的包会引起双方的状态变更);
  • 窗口大小 TCP 要做流量控制,需要通信双方各声明一个窗口,标识自己当前的处理能力;

TCP三次握手

TCP协议发送数据之前必须在通信的两端建立连接,建立连接的方法是TCP三次握手

TCP三次握手

  • 第一次握手 客户端向服务端发送连接请求报文;请求发送后,客户端便进入 SYN-SENT 状态;
  • 第二次握手 服务端收到连接请求报文后,如果同意连接,则会发送一个应答,发送完成后便进入 SYN-RECEIVED 状态;
  • 第三次握手 当客户端收到连接同意的应答后,还要向服务端发送一个确认报文;客户端发完这个报文后便进入 ESTABLISHED 状态,服务端收到这个应答后也进入 ESTABLISHED 状态,此时连接建立成功。

为什么 TCP 建立连接需要三次握手,而不是两次? TCP既要保证数据可靠传输,又要提高传输的效率,而用三次(客户端与服务端发送的报文都得到了响应,通信双方全都有来有回)恰恰满足了以上两方面的需求!

TCP三次握手

TCP四次挥手

TCP断开连接,也被称为四次挥手:

enter description here

  • 第一次挥手 A:B,我不玩了 客户端A服务端B发送连接释放请求;
  • 第二次挥手 B:OK,A不玩了,知道了 服务端B 收到连接释放请求后,发送 ACK 包,并进入 CLOSE_WAIT 状态; 此时服务端B不再接收客户端A发送的数据,但服务端B 若此时还有没发完的数据会继续发送;
  • 第三次挥手 B:A,我也不玩了,拜拜 服务端 B 向 A 发送连接释放请求,然后 B 便进入 LAST-ACK 状态;
  • 第四次挥手 A:OK,B不玩了,拜拜 客户端A 收到释放请求后,向 服务端B 发送确认应答,此时 客户端A 进入 TIME-WAIT 状态; 客户端A的 TIME-WAIT状态会持续 2MSL(最大段生存期,指报文段在网络中生存的时间,超时会被抛弃) 时间,若该时间段内没有 B 的重发请求,就进入 CLOSED 状态。当 B 收到确认应答后,也便进入 CLOSED 状态。

TCP协议的特点

相比与UDP协议,TCP协议拥有面向连接、保证顺序、可靠传输、提供拥塞控制等特点。

为了保证顺序性,每个TCP数据包都有一个序号ID,在建立连接的时候会商定起始 ID 是什么,然后按照 ID 一个个发送; 为了保证不丢包,需要对发送的包都要进行应答,这里应答不是一个一个来的,而是会应答某个之前的 ID,表示都收到了,这种模式成为累计应答; 为了记录所有发送的包和接收的包,需要发送端接收端分别缓存这些记录。

TCP发送端的缓存里是按照数据包的 序号ID 一个个排列,根据处理的情况分成四个部分:

  • 发送并且确认的;
  • 发送尚未确认的;
  • 没有发送等待发送的;
  • 没有发送并且暂时不会发送的;
TCP发送端缓存结构

在 TCP 协议中接收端会给发送端报一个窗口大小Advertised Window,这个窗口大小等于上面的第二、第三部分加和,超过这个窗口接收端处理不过来,暂时不能继续发送;

上图TCP发送端缓存队列中:

  • 1、2、3 已发送并确认;
  • 4、5、6、7、8、9 都是发送了还没确认;
  • 10、11、12 是还没发出的;
  • 13、14、15 是接收方没有空间,不准备发的。

TCP接收端缓存内容类型如下:

  • 接收并且确认过的;
  • 还没接收,马上就能接收的;
  • 还没接收,也无法接收的;
TCP接收端缓存结构

上图TCP接收端缓存队列中:

  • 1、2、3、4、5 是已经完成 ACK ;
  • 6、7 是等待接收的,8、9 是已经接收还没有 ACK 的;
  • 10、11、12 、13、14、15 是暂时无法接收的;

TCP发送端、接收端当前的状态如下(依据以上两个图):

  • 1、2、3 没有问题,双方达成了一致;
  • 4、5 接收方响应 ACK 了,但是发送方尚未收到;
  • 6、7、8、9 肯定都发了,而且8、9 已经到了,但6、7 尚未收到,出现了乱序,缓存着暂无法 ACK;

根据这个例子可以知道顺序问题和丢包问题都有可能存在:

假设4的ACK响应发送端收到了,5的ACK丢了;6、7的数据包丢了,该怎么办?

  • 一种方法是超时重试,即对每一个发送了但是没有 ACK 的包设定一个定时器,超过了一定的事件就重新尝试;这个重试时间必须大于往返时间,但也不宜过长,否则超时时间变长,访问就变慢了; 例如:过一段时间,5、6、7 的ACK都超时了,发送端就会重新发送;接收方发现 5 原来接收过 于是丢弃 5,6、7收到了发送 ACK;
  • 另一个快速重传的机制,即当接收方接收到一个序号大于期望的报文段时,就检测数据流之间的间隔,于是发送三个冗余的 ACK,客户端接收到之后,知道数据报丢失,于是重传丢失的报文段; 例如:接收方发现 6、8、9 都接收了,但是 7 没来(7丢了),于是发送三个 6 的 ACK,要求下一个是 7;客户端接收到 3 个ACK,就会发现 7 丢了,马上重发。

参考

UDP—RFC768: tools.ietf.org/html/rfc768

TCP—RFC973: tools.ietf.org/html/rfc793

Stackoverflow: UDP checksum calculation, Sep 2017 stackoverflow.com/questions/1…

百度百科—UDP: baike.baidu.com/item/UDP/57…

百度百科—TCP: baike.baidu.com/item/TCP/33…

TCP 和 UDP 的区别: blog.csdn.net/zhang622328…

一文搞懂TCP与UDP的区别 www.cnblogs.com/fundebug/p/…

========== THE END ==========

wx_gzh.jpg

今天的文章TCP与UDP区别详解分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/21945.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注