TCP与UDP

TCP与UDP

一、互联网的基石

1、网络协议及模型

计算机与网络设备要相互通信,双方就必须基于相同的方法。比如,如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信,所有的这一切都需要一种规则。而我们就把这种规则称为协议(protocol)。
网络协议有很多,按照功能不同,分工不同,人们人为的将其进行了分层,更便于理解。
例如OSI七层模型TCP/IP四层模型
实际上这个七层四层是不存在的,只是人为的划分的概念,区分出来的目的只是让你明白哪一层是干什么用的。

OSI:开放式系统互联通信参考模型(英语:Open System Interconnection Reference Model,缩写为 OSI),简称为 OSI 模型(OSI model),一种概念模型,由国际标准化组织提出,一个试图使各种计算机在世界范围内互连为网络的标准框架。定义于ISO/IEC 7498-1。

TCP/IP:(Transmission Control Protocol/Internet Protocol,传输控制协议/网际协议)是指能够在多个不同网络间实现信息传输的协议簇。 TCP、UDP、IP、FTP、HTTP、ICMP、SMTP 等都属于 TCP/IP 族内的协议, 只是因为在 TCP/IP 协议中 TCP 协议和 IP 协议最具代表性,所以被称为 TCP/IP 协议。这些协议可以划分为四层,分别为链路层、网络层、传输层和应用层

2、TCP和UDP

下图展示了分层模型:

分层模型1
分层模型2

如图所示,TCP和UDP都是传输层协议,在《OSI七层网络协议详解》一文中详细的讲解了各个分层在网络传输中的作用及原理。

传输层提供逻辑连接的建立、传输层寻址、数据传输、传输连接释放、流量控制、拥塞控制、多路复用和解复用、崩溃恢复等服务。

二、TCP

1、TCP的概念

当一台计算机想要与另一台计算机通讯时,两台计算机之间的通信需要畅通且可靠,这样才能保证正确收发数据。例如,当你想查看网页或查看电子邮件时,希望完整且按顺序查看网页,而不丢失任何内容。当你下载文件时,希望获得的是完整的文件,而不仅仅是文件的一部分,因为如果数据丢失或乱序,都不是你希望得到的结果,于是就用到了 TCP。

TCP协议全称是(Transmission Control Protocol)传输控制协议
一种面向连接的、可靠的、全双工通信的、基于字节流的传输层通信协议

2、TCP的特征

  • TCP在传输数据之前必须先建立连接,数据传输结束后要释放连接。
  • 每一条TCP连接只能有2个端点,故TCP不提供广播或多播服务。
  • TCP提供可靠交互,通过TCP连接传输的数据,无差错、不丢失、不重复、并且按序到达。
  • TCP是面向字节流的。虽然应用进程和TCP的交互是一次一个数据块(大小不等),但TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。TCP并不知道所传输的字节流的含义。

2、TCP的报文结构

  • 报文整体

TCP报文结构

  • TCP首部

TCP首部

  • tcp flags 状态控制码,占 6 比特位,含义如下:
    • URG:紧急比特(urgent),当 URG=1 时,表明紧急指针字段有效,代表该封包为紧急封包。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据), 且上图中的 Urgent Pointer 字段也会被启用。
    • ACK:确认比特(Acknowledge)。只有当 ACK=1 时确认号字段才有效,代表这个封包为确认封包。当 ACK=0 时,确认号无效。
    • PSH:(Push function)若为 1 时,代表要求对方(接收端)立即传送缓冲区内的其他对应封包,而无需等缓冲满了才送。
    • RST:复位比特(Reset),当 RST=1 时,表明 TCP 连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。
    • SYN:同步比特(Synchronous),SYN 置为 1,就表示这是一个连接请求或连接接受报文,通常带有 SYN 标志的封包表示『主动』要连接到对方的意思。
    • FIN:终止比特(Final),用来释放一个连接。当 FIN=1 时,表明此报文段的发送端的数据已发送完毕,并要求释放传输连接。
  • 序列号(小写单词是序列号,大写单词是状态控制码非0及1)
    • 序号seq:占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;给字节编上序号后,就给每一个报文段指派一个序号;序列号seq就是这个报文段中的第一个字节的数据编号。
    • 确认号ack:占4个字节,期待收到对方下一个报文段的第一个数据字节的序号;序列号表示报文段携带数据的第一个字节的编号;而确认号指的是期望接收到下一个字节的编号;因此当前报文段最后一个字节的编号+1即为确认号。

3、TCP的连接过程

TCP 是面向连接的,无论哪一方向另一方发送数据之前,都必须先在双方之间建立一条连接。在 TCP/IP 协议中,TCP 协议提供可靠的连接服务,连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP 窗口大小信息。这就是面试中经常会被问到的 TCP 三次握手。只是了解 TCP 三次握手的概念,对你获得一份工作是没有任何帮助的,你需要去了解 TCP 三次握手中的一些细节。先来看图说话。

3.1 TCP 三次握手

TCP三次握手

  • 三次握手过程
    • 1、客户端发生 SYN 给服务器,表示客户端向服务器请求建立连接;
    • 2、服务端收到客户端的 SYN,并回复 SYN+ACK 给客户端(同意建立连接);
    • 3、客户端收到来自服务器的 SYN+ACK 后,回复 ACK 给服务端(表示客户端收到了服务端发的同意报文);
    • 4、服务端收到客户端的 ACK,连接已建立,可以进行数据传输。
  • 过程详解
    • B 的 TCP 服务器进程首先创建传输控制块 TCB,准备接受客户进程的连接请求。然后服务器进程就处于 LISTEN (收听)状态,等待客户的连接请求。如有,就做出响应。
    • A 的 TCP 客户进程也是首先创建传输控制模块 TCB,然后向B发出连接请求报文段,这时首部中的同步位 SYN=1,同时选择一个初始序号 seq=x。TCP 规定,SYN 报文段(即SYN=1的报文段)不能携带数据,但是要消耗一个序号。这时,TCP客户进程进入 SYN-SENT(同步已发送) 状态。
    • B收到连接请求报文段后,如同意建立连接,则向A发送确认。在确认报文段中应把 SYN 和ACK 位都置1,确认号是 ack=x+1,同时也为自己选择一个初始序号 seq=y。注意:这个报文段也不能携带数据,但同样要消耗一个序号。这时TCP服务器进程进入 SYN-RECV(同步收到) 状态。
    • TCP 客户进程收到B的确认后,还要向B给出确认。确认报文段的ACK置1,确认号ack=y+1,而自己的序号seq=x+1。TCP 标准规定,ACK 报文段可以携带数据。但如果不携带数据则不消耗序号。在这种情况下,下一个数据报文段的序号仍然是 seq=x+1。这时,TCP 的连接已经建立,A 进入 ESTABLISHED(已建立连接) 状态。当 B 接收到 A 的确认后,B 也进入 ESTABLISHED(已建立连接) 状态。
  • TCP 为什么要进行三次握手?
    • 因为信道不可靠,而 TCP 想在不可靠信道上建立可靠地传输,那么三次通信是理论上的最小值。(而 UDP 则不需建立可靠传输,因此 UDP 不需要三次握手)
    • 因为双方都需要确认对方收到了自己发送的序列号,确认过程最少要进行三次通信;
    • 为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。

      已失效的连接请求报文段的产生在这样一种情况下:
      client 发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达 server。
      本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后,就误认为是 client 再次发出的一个新的连接请求。
      于是就向 client 发出确认报文段,同意建立连接。假设不采用三次握手,那么只要 server 发出确认,新的连接就建立了。
      由于现在 client 并没有发出建立连接的请求,因此不会理睬 server 的确认,也不会向 server 发送数据。但 server 却以为新的运输连接已经建立,并一直等待 client 发来数据。
      这样,server 的很多资源就白白浪费掉了。采用三次握手的办法可以防止上述现象发生。例如刚才那种情况,client 不会向 server 的确认发出确认。server 由于收不到确认,就知道 client 并没有要求建立连接。

3.2 TCP 四次挥手

TCP四次挥手

  • 四次挥手
    • 1、客户端发送 FIN 给服务器,说明客户端不必发送数据给服务器了(请求释放从客户端到服务器的连接);
    • 2、服务器接收到客户端发的 FIN,并回复 ACK 给客户端(同意释放从客户端到服务器的连接);
    • 3、客户端收到服务端回复的 ACK,此时从客户端到服务器的连接已释放(但服务端到客户端的连接还未释放,并且客户端还可以接收数据);
    • 4、服务端继续发送之前没发完的数据给客户端;
    • 5、服务端发送 FIN+ACK 给客户端,说明服务端发送完了数据(请求释放从服务端到客户端的连接,就算没收到客户端的回复,过段时间也会自动释放);
    • 6、服务端发送 FIN+ACK 给客户端,说明服务端发送完了数据(请求释放从服务端到客户端的连接,就算没收到客户端的回复,过段时间也会自动释放);
    • 7、服务端收到客户端的 ACK 后,断开从服务端到客户端的连接。
  • 过程详解
    • A 和 B 都处于 ESTABLISHED 状态,A 的应用进程首先向其 TCP 发出连接释放报文段,并停止再发送数据,主动关闭 TCP 连接。A 把连接释放报文段首部的 FIN 置 1,其序列号 seq=u,它等于前面已经传送过的数据的最后一个字节的序号加 1。这时,A 进入 FIN-WAIT-1(终止等待1) 状态,等待B的确认。注意:TCP 规定:FIN 报文段即使不携带数据,它也会消耗一个序号。
    • B 收到连接释放报文段后即发出确认,确认号是 ack=u+1,而这个报文段自己的序号是 v,等待 B 前面已经传送过的数据的最后一个字节的序号加 1。然后 B 就进入 CLOSE-WAIT(关闭等待) 状态。TCP 服务器进程这时应通知高层应用进程,因而从 A 到 B 这个方向的连接就释放了,这时的 TCP 连接处于半关闭状态,即 A 已经没有数据要发送了,但 B 若发送数据,A 仍要接收。也就是说,从 B 到 A 这个方向的连接并没有关闭,这个连接可能会持续一段时间。
    • A 收到来自 B 的确认后,就进入 FIN-WAIT-2(终止等待2) 状态,等待 B 发出的连接释放报文段。如果 B 已经没有要向 A 发送的数据,其应用进程就会通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN=1。现假定 B 的序号为 w(在半关闭状态B可能又发送了一些数据)。B 还必须重复上次已经发送过的确认号 ack=u+1。这时,B 就进入 LAST-ACK(最后确认状态),等待 A 的确认。
    • A 在收到 B 的释放连接报文段后,必须对此发出一个确认。在确认报文段中把 ACK 置 1,确认号 ack=w+1,而自己的序号是 seq=u+1(根据 TCP 标准,前面发送过的 FIN 报文段要消耗一个序号)。然后经过时间等待计时器 (TIME-WAIT) 设置的时间 2MSL 后,A 才进入到 CLOSED 状态。时间 MSL 叫做最长报文段寿命
  • TCP 为什么要进行四次挥手?
    • 因为 TCP 是全双工模式,客户端请求关闭连接后,客户端向服务端的连接关闭(一二次挥手),服务端继续传输之前没传完的数据给客户端(数据传输),服务端向客户端的连接关闭(三四次挥手)。所以 TCP 释放连接时服务器的 ACK 和 FIN 是分开发送的(中间隔着数据传输),而 TCP 建立连接时服务器的 ACK 和 SYN 是一起发送的(第二次握手),所以 TCP 建立连接需要三次,而释放连接则需要四次。
    • 如果要正确的理解四次分手的原理,就需要了解四次分手过程中的状态变化。

      FIN_WAIT_1:这个状态要好好解释一下,其实 FIN_WAIT_1 和 FIN_WAIT_2 状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是:FIN_WAIT_1 状态实际上是当 SOCKET 在 ESTABLISHED 状态时,它想主动关闭连接,向对方发送了 FIN 报文,此时该 SOCKET 即进入到 FIN_WAIT_1 状态。而当对方回应 ACK 报文后,则进入到 FIN_WAIT_2 状态,当然在实际的正常情况下,无论对方何种情况下,都应该马上回应 ACK 报文,所以 FIN_WAIT_1 状态一般是比较难见到的,而 FIN_WAIT_2 状态还有时常常可以用 netstat 看到。(主动方)
      FIN_WAIT_2:上面已经详细解释了这种状态,实际上 FIN_WAIT_2 状态下的 SOCKET,表示半连接,也即有一方要求 close 连接,但另外还告诉对方,我暂时还有点数据需要传送给你(ACK信息),稍后再关闭连接。(主动方)
      CLOSE_WAIT:这种状态的含义其实是表示在等待关闭。怎么理解呢?当对方 close 一个 SOCKET 后发送 FIN 报文给自己,你系统毫无疑问地会回应一个 ACK 报文给对方,此时则进入到 CLOSE_WAIT 状态。接下来呢,实际上你真正需要考虑的事情是察看你是否还有数据发送给对方,如果没有的话,那么你也就可以 close 这个 SOCKET,发送 FIN 报文给对方,也即关闭连接。所以你在 CLOSE_WAIT 状态下,需要完成的事情是等待你去关闭连接。(被动方)
      LAST_ACK:这个状态还是比较容易好理解的,它是被动关闭一方在发送 FIN 报文后,最后等待对方的 ACK 报文。当收到 ACK 报文后,也即可以进入到 CLOSED 可用状态了。(被动方)
      TIME_WAIT:表示收到了对方的 FIN 报文,并发送出了 ACK 报文,就等 2MSL 后即可回到 CLOSED 可用状态了。如果 FINWAIT1 状态下,收到了对方同时带 FIN 标志和 ACK 标志的报文时,可以直接进入到 TIME_WAIT 状态,而无须经过 FIN_WAIT_2 状态。(主动方)
      CLOSED:表示连接中断。

  • 为什么 TCP 建立连接时可以 ACK 和 SYN 一起发送,而断开连接时则 ACK 和 FIN 分开发送呢?(ACK 和 FIN 分开是指第二次和第三次挥手)
    • 因为客户端请求释放时,服务器可能还有数据需要传输给客户端,因此服务端要先响应客户端 FIN 请求(服务端发送 ACK),然后数据传输,传输完成后,服务端再提出 FIN 请求(服务端发送 FIN);而连接时则没有中间的数据传输,因此连接时可以 ACK 和 SYN 一起发送。
  • 为什么客户端断开连接时,最后需要 TIME-WAIT 等待 2MSL 呢?
    • 为了保证客户端发送的最后一个 ACK 报文能够到达服务端。若未成功到达,则服务端超时重传 FIN+ACK 报文段,客户端再重传 ACK,并重新计时。、
    • 防止已失效的连接请求报文段出现在本连接中。TIME-WAIT 持续 2MSL 可使本连接持续的时间内所产生的所有报文段都从网络中消失,这样可使下次连接中不会出现旧的连接报文段。
3.3 TCP 有限状态机

TCP 有限状态机

三、UDP

1、UDP的概念

UDP(User Datagram Protocol)全称是用户数据报协议,在网络中它与TCP协议一样用于处理数据包,是一种无连接的协议。在OSI模型中,在第四层——传输层,处于IP协议的上一层。
UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点,也就是说,当报文发送之后,是无法得知其是否安全完整到达的。

2、UDP的报文结构

  • 报文整体

UDP 报文

  • UDP首部

UDP 报文

  • UDP头部包含了以下几个数据:
    • 两个十六位的端口号,分别为源端口(可选字段)和目标端口
    • 整个数据报文的长度
    • 整个数据报文的检验和(IPv4 可选 字段),该字段用于发现头部信息和数据中的错误

因此 UDP 的头部开销小,只有八字节,相比 TCP 的至少二十字节要少得多,在传输数据报文时是很高效的

3、UDP的特征

  • UDP 在发送数据之前不需要建立连接。
  • UDP 不保证可靠交互,主机不需要位置复杂的连接状态。
  • UDP 是面向报文的。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的的边界,即应用层交给 UDP 多长的报文,UDP 就照样发送,即一次发送一个报文。在接收端,UDP 一次交付一个完整的报文。
  • UDP 没有拥塞控制,网络出现的拥塞不会使源主机的发送速率降低。
  • UDP 支持一对一、一对多、多对一和多对多的交互通信。
  • UDP 的首部开销小,只有8个字节,比 TCP 的 20 个字节的首部要短。

四、TCP与UDP简单对比

  • 特征对比
    • TCP协议面向连接,UDP协议面向非连接。
    • TCP协议传输速度慢,UDP协议传输速度快。
    • TCP协议保证数据顺序,UDP协议不保证。
    • TCP协议保证数据正确性,UDP协议可能丢包。
    • TCP协议对系统资源要求多,UDP协议要求少。
  • 使用场景对比
    • TCP协议适用于对效率要求相对低,但对准确性要求相对高的场景下,或者是有一种连接概念的场景下。
    • 而UDP协议适用于对效率要求相对高,对准确性要求相对低的场景。

参考链接:
https://www.cnblogs.com/fundebug/p/differences-of-tcp-and-udp.html
https://blog.csdn.net/cdlwhm1217096231/article/details/90760282
更详细的内容请参见百度百科:
https://baike.baidu.com/item/TCP/33012
https://baike.baidu.com/item/UDP

作者

hellosyl

发布于

2020-10-27

更新于

2020-10-27

许可协议

评论

:D 一言句子获取中...

加载中,最新评论有1分钟缓存...