TCP/IP协议之传输层：TCP/UDP协议详解（一）

简介：

在TCP/IP网络体系结构中，TCP（传输控制协议，Transport Controll Protocol、UDP（用户数据报协议，User Data Protocol）是传输层最重要的两种协议，为上层用户提供级别的通信可靠性。

传输层的功能

传输层的主要功能是实现分布式进程之间的通信。利用网络层提供的服务，在源主机的应用进程与目的主机的应用进程建立“端—端”连接。
传输层之间传输的报文称为“传输协议数据单元（TPDU）”，TPDU有效载荷称为应用层的数据

UDP协议

用户数据报协议（UDP）：UDP（用户数据报协议）是一个简单的面向数据报的传输层协议。提供的是非面向连接的、不可靠的数据流传输。UDP不提供可靠性，也不提供报文到达确认、排序以及流量控制等功能。它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。因此报文可能会丢失、重复以及乱序等。但由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。

它有以下几个特点：

1.面向无连接
首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。

具体来说就是：

在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了
在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作
2.有单播，多播，广播的功能
UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。

3.UDP是面向报文的
发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文

4.不可靠性
首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠。

并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。

再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。

5.头部开销小，传输数据报文时是很高效的。

UDP 头部包含了以下几个数据：

• 两个十六位的端口号，分别为源端口（可选字段）和目标端口
• 整个数据报文的长度
• 整个数据报文的检验和（IPv4 可选 字段），该字段用于发现头部信息和数据中的错误

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

TCP协议

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

TCP协议全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的RFC 793定义。TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构，你可以把它想象成排水管中的水流。

1.TCP连接过程
如下图所示，可以看到建立一个TCP连接的过程为（三次握手的过程）:

第一次握手

客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。

第二次握手

服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态。

第三次握手

当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。

这里可能大家会有个疑惑：为什么 TCP 建立连接需要三次握手，而不是两次？这是因为这是为了防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误。

2.TCP断开链接

TCP 是全双工的，在断开连接时两端都需要发送 FIN 和 ACK。

第一次握手

若客户端 A 认为数据发送完成，则它需要向服务端 B 发送连接释放请求。

第二次握手

B 收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明 A 到 B 的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。

第三次握手

B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B 便进入 LAST-ACK 状态。

第四次握手

A 收到释放请求后，向 B 发送确认应答，此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态。当 B 收到确认应答后，也便进入 CLOSED 状态。

3.TCP协议的特点
面向连接
面向连接，是指发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”，这样能建立可靠的连接。建立连接，是为数据的可靠传输打下了基础。

仅支持单播传输
每条TCP传输连接只能有两个端点，只能进行点对点的数据传输，不支持多播和广播传输方式。

面向字节流
TCP不像UDP一样那样一个个报文独立地传输，而是在不保留报文边界的情况下以字节流方式进行传输。

可靠传输
对于可靠传输，判断丢包，误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。

提供拥塞控制
当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞

TCP提供全双工通信
TCP允许通信双方的应用程序在任何时候都能发送数据，因为TCP连接的两端都设有缓存，用来临时存放双向通信的数据。当然，TCP可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于MSS）

4.累计确认

• TCP 如何实现可靠传输?

首先为了保证顺序性，每个包都有一个 ID。在建立连接的时候会商定起始 ID 是什么，然后按照 ID 一个个发送，为了保证不丢包，需要对发送的包都要进行应答，当然，这个应答不是一个一个来的，而是会应答某个之前的 ID，表示都收到了，这种模式成为累计应答或累计确认。

为了记录所有发送的包和接收的包，TCP 需要发送端和接收端分别来缓存这些记录，发送端的缓存里是按照包的 ID 一个个排列，根据处理的情况分成四个部分

发送并且确认的
发送尚未确认的
没有发送等待发送的
没有发送并且暂时不会发送的
这里的第三部分和第四部分就属于流量控制的内容

在 TCP 里，接收端会给发送端报一个窗口大小，叫 Advertised window。这个窗口应该等于上面的第二部分加上第三部分，超过这个窗口，接收端做不过来，就不能发送了

于是，发送端要保持下面的数据结构

对于接收端来讲，它的缓存里面的内容要简单一些

接收并且确认过的
还没接收，但是马上就能接收的
还没接收，但也无法接收的
对应的数据结构如下

5.顺序问题和丢包问题
结合上面的图看，在发送端，1、2、3 已发送并确认；4、5、6、7、8、9 都是发送了还没确认；10、11、12 是还没发出的；13、14、15 是接收方没有空间，不准备发的。

在接收端来看，1、2、3、4、5 是已经完成 ACK 但是还没读取的；6、7 是等待接收的；8、9 是已经接收还没有 ACK 的。

发送端和接收端当前的状态如下：

• 1、2、3 没有问题，双方达成了一致
• 4、5 接收方说 ACK 了，但是发送方还没收到
• 6、7、8、9 肯定都发了，但是 8、9 已经到了，6、7 没到，出现了乱序，缓存着但是没办法 ACK。

根据这个例子可以知道顺序问题和丢包问题都有可能存在，所以我们先来看确认与重传机制。

假设 4 的确认收到了，5 的 ACK 丢了，6、7 的数据包丢了，该怎么办？

一种方法是超时重试，即对每一个发送了但是没有 ACK 的包设定一个定时器，超过了一定的事件就重新尝试。这个时间必须大于往返时间，但也不宜过长，否则超时时间变长，访问就变慢了。

如果过一段时间，5、6、7 都超时了就会重新发送。接收方发现 5 原来接收过，于是丢弃 5；6 收到了，发送 ACK，要求下一个是 7，7 不幸又丢了。当 7 再次超时的时候，TCP 的策略是超时间隔加倍。每当遇到一次超时重传的时候，都会讲下一次超时时间间隔设为先前值的两倍。

超时重传的机制是超时周期可能相对较长，是否有更快的方式呢？

有一个快速重传的机制，即当接收方接收到一个序号大于期望的报文段时，就检测到了数据流之间的间隔，于是发送三个冗余的 ACK，客户端接收到之后，知道数据报丢失，于是重传丢失的报文段。

例如，接收方发现 6、8、9 都接收了，但是 7 没来，所以肯定丢了，于是发送三个 6 的 ACK，要求下一个是 7。客户端接收到 3 个，就会发现 7 的确又丢了，不等超时，马上重发。

6.流量控制的问题
在流量控制的机制里面，在对于包的确认中，会携带一个窗口的大小

简单的说一下就是接收端在发送 ACK 的时候会带上缓冲区的窗口大小，但是一般在窗口达到一定大小才会更新窗口，因为每次都更新的话，刚空下来就又被填满了

7.拥塞控制的问题
也是通过窗口的大小来控制的，但是检测网络满不满是个挺难的事情，所以 TCP 发送包经常被比喻成往谁管理灌水，所以拥塞控制就是在不堵塞，不丢包的情况下尽可能的发挥带宽。

水管有粗细，网络有带宽，即每秒钟能发送多少数据；水管有长度，端到端有时延。理想状态下，水管里面的水 = 水管粗细 * 水管长度。对于网络上，通道的容量 = 带宽 * 往返时延。

如果我们设置发送窗口，使得发送但未确认的包为通道的容量，就能撑满整个管道。

如图所示，假设往返时间为 8 秒，去 4 秒，回 4 秒，每秒发送一个包，已经过去了 8 秒，则 8 个包都发出去了，其中前四个已经到达接收端，但是 ACK 还没返回，不能算发送成功，5-8 后四个包还在路上，还没被接收，这个时候，管道正好撑满，在发送端，已发送未确认的 8 个包，正好等于带宽，也即每秒发送一个包，也即每秒发送一个包，乘以来回时间 8 秒。

如果在这个基础上调大窗口，使得单位时间可以发送更多的包，那么会出现接收端处理不过来，多出来的包会被丢弃，这个时候，我们可以增加一个缓存，但是缓存里面的包 4 秒内肯定达不到接收端课，它的缺点会增加时延，如果时延达到一定程度就会超时重传

TCP 拥塞控制主要来避免两种现象，包丢失和超时重传，一旦出现了这些现象说明发送的太快了，要慢一点。

具体的方法就是发送端慢启动，比如倒水，刚开始倒的很慢，渐渐变快。然后设置一个阈值，当超过这个值的时候就要慢下来

慢下来还是在增长，这时候就可能水满则溢，出现拥塞，需要降低倒水的速度，等水慢慢渗下去。

拥塞的一种表现是丢包，需要超时重传，这个时候，采用快速重传算法，将当前速度变为一半。所以速度还是在比较高的值，也没有一夜回到解放前。

总结：

TCP协议如何来保证传输的可靠性？

TCP提供面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和服务器）在彼此交换数据之前必须建立一个TCP连接。

在一个TCP连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过TCP连接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。

对于可靠性，TCP通过以下方式进行保证：

数据包校验：目的是检测数据在传输过程中的任何变化，若检验出包出错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据

对失序数据包重新排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层（即A端发送到B端后，TCP报文段可能会失序，这是为了能让B端正常确认，需要对TCP报文段重新排序）

丢弃重复数据：对于重复数据，能够丢弃重复数据

应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常会推迟几分之一秒

超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段

流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议

TCP/UDP区别：

TCP面向连接, UDP面向非连接(发送数居前无需创建链接)

• 面向连接是通信前, 确认双方链路是否可达(请求前的三次握手, 断链接的 四次挥手)
• 面向非连接, 通信之前不去确认链路是否可达

TCP提供安全可靠的数据传输服务, UDP不保证传输的数据的可靠性
TCP面向字节流, UDP面向报文
TCP传输速度慢, UDP传输数据快(实际上现在TCP并不比UDP慢多少)
TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

为什么TCP连接需要三次握手，断开四次挥手

三次握手的目的是为了防止已失效的链接请求报文突然又传送到了服务端，因而产生错误。

• 正常情况：A发出连接请求，但因连接请求报文丢失而未受到确认，于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”。

• 异常情况：A发出了第一个连接请求报文段并没有丢失，而是在某个网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这时一个早已失效的报文段。但B受到此失效的连接请求报文段后，就误认为是A再次发出了一个新的连接请求，于是就向A发出确认报文段，同意建立连接。

假设不采用三次握手，那么只要B发出确认，新的连接就建立了。由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已建立，并一直等待A发来数据。这样，B的很多资源就白白浪费。采用三次握手的办法可以防止上述现象发生。

四次挥手：

TCP协议是一种面向连接的、可靠的、基于字节流的传输层通信协议，TCP是全双工模式，这就意味这，当A向B发出FIN报文段时，只是表示A已经没有数据要发送了，而此时A还是能够接收到来自B发出的数据；B向A发出ACK报文段也只是告诉A，它自己知道A没有数据要发送了，但B还是能够向A发送数据。

关注公众号，获取更多开发必备知识