网络通信 --- 传输层协议 (UDP 和 TCP)

目录

一、UDP协议

1.UDP协议段首部格式

2.UDP特点：

3.缓冲区：

4.经典面试题

二、TCP协议

1. TCP协议段格式

2. TCP特点

3. TCP原理

① 确认应答（安全机制）

② 超时重传机制（安全机制）

③ 三次握手（连接管理机制(安全机制)）

④四次挥手（连接管理机制(安全机制)）

⑤滑动窗口（效率机制）

⑥ 流量控制（安全机制）

⑦ 拥塞控制（安全机制）

⑧ 延迟应答（效率机制）

⑨捎带应答（效率机制）

⑩ TCP 缓冲区

粘包问题

异常情况

TCP中的长短连接 

TCP小结

---

                                                        哥几个来学传输协议啦~~

                                                                

一、UDP协议

1.UDP协议段首部格式

(1) 16位源端口号 / 16位目的端口号：见名知义。

(2) 16位 UDP长度：表示整个数据报（UDP首部 + UDP数据）的最大长度。

大家都知道，16位二进制数可表示的最大值就是65535，那么这就代表了 UDP协议传输报文的最大长度是 64kb。

(3) 16位 UDP校验和：如果校验和出错，就会直接丢弃。

UDP使用的校验和算法是 CRC算法，大家如果有学过计算机网络这门课的话，应该不会陌生。

为什么要有校验和？

原因是数据在通信设备上传输可能会受到干扰，导致传输到对端的时候，数据发生了变化。那么这时候就要用到校验和。如果传输完成后，数据的校验和没有发生改变，并不能完全保证数据没有发生改变；但是如果校验和不同，那么数据就一定发生了变化。

2.UDP特点：

(1) 无连接：知道对端的 IP地址 和 端口号 就能直接进行传输，不需要建立连接。

(2) 不可靠：没有任何安全机制，发送端发送数据报以后，如果因为故障导致该段无法发送到对方，UDP协议层也不会返回给应用层任何错误信息。

(3) 面向数据报：应用层交给 UDP 多长的报文，UDP 原样返回，既不会拆分，也不会合并。

用 UDP 传输 100个字节的数据：

如果发送端一次发送 100个字节，那么接收端也必须一次接收 100个字节；而不能循环接收10次，每次接收 10个字节。

对于UDP协议来说，是否也存在 "粘包问题" 呢？

不会。

• 对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在。同时，UDP是一个一个把数据交付给应用层。就有很明确的数据边界。
• 站在应用层的站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收。 不会出现"半个"的情况。

(4) 全双工：可以同时（瞬时）进行信号的双向传输（A→B且B→A）。指A→B的同时B→A，是瞬时同步的。

3.缓冲区：

UPD 只有接收缓存区，没有发送缓存区。

UDP没有真正意义上的 发送缓冲区。发送的数据会直接交给内核，由内核将该数据传输给网络层协议进行后续的传输动作；

UDP具有接收缓存区，但是这个缓存区不能保证收到的 UDP报的顺序和发送UDP报的顺序一致。如果缓冲区满了，再达到的UDP数据就会被丢弃。

4.经典面试题

1. UDP本身是无连接，不可靠，面向数据报的协议，如果要基于传输层UDP协议，来实现一个可靠传 输，应该如何设计？

2. UDP大小是受限的，如果要基于传输层UDP协议，传输超过64K的数据，应该如何设计？

以上两个问题答案类似，都可以参考TCP的可靠性机制在应用层实现类似的逻辑：

例如：

• 引入序列号，保证数据顺序；
• 引入确认应答，确保对端收到了数据；
• 引入超时重传，如果隔一段时间没有应答，就重发数据；
• ……

二、TCP协议

1. TCP协议段格式

(1) 源 / 目的端口号：表示数据是从哪个进程来，到哪个进程去。

(2) 32位序号 / 32位确认号：这个后面细说~~

(3) 4位TCP报头长度：表示该TCP头部有多少个 32位bit（有多少个4字节）；所以TCP头部最大长度是 15 * 4 = 60 个字节。

(4) 6 位标志位：

• URG：紧急指针是否有效
• ACK：确认号是否有效
• PSH：提示对端应用程序立刻从TCP缓存区把数据读走
• RST：对方要求重新建立连接。我们把携带 RST 标识的称为 复为报文段
• SYN：请求建立连接。我们把携带 SYN 标识的称为 同步报文段
• FIN：通知对方，本段要关闭了，我们称携带 FIN 标识的为 结束报文段

(5) 16位窗口大小：后面我们细说~~

(6) 16位校验和：发送端填充，CRC检验。接收端检验不通过，则认为数据有问题。此处的检验不光包含 TCP首部，也包含 TCP数据部分。

(7) 16位紧急指针：标识哪部分数据是紧急数据。

(8) 40字节头部选项：暂时忽略~~

2. TCP特点

(1) 有连接

(2) 可靠传输

(3) 面向字节流

(4) 全双工

这几个特点不是随随便便几句话能讲完，下面我们来重点认识一下这些特点。

                                        请往下走(跳转到 TCP原理 )~~~

                                                

3. TCP原理

① 确认应答（安全机制）

确认应答是 TCP 实现可靠性最核心的机制。

 这个过程类似于 特种兵打仗的时候用无线电通信：

但是，由于网络上经常出现后发先至（就是比较晚发的消息先到达），那这样就会导致数据的接收方对数据的理解出现了偏差：

正常情况：此时曾国藩会很生气（屡败屡战，屡战屡败——无能）

 异常情况：此时曾国藩会很感动（屡战屡败，屡败屡战——百折不饶）

因此，TCP将每个字节都进行了编号，成为序列号。

 每一个ACK报文段都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开始发。

② 超时重传机制（安全机制）

        由于在网络通信的过程中，数据在传输的过程中会经过许多的设备，每个设备都是在承担很多的转发任务的，每个设备的转发能力都有上限。某一时刻，某一设备的可以承载的流量达到峰值，就可能引起部分数据被丢包~~

        如果 TCP 要想实现 可靠传输，那么就要重新传输丢失的数据：

情况1：主机A发送的数据丢失

1. 主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B。
2. 如果主机A在一个特定时间间隔内 (超时重传时间) 没有收到B发来的确认应答，就会进行重发。

情况2：主机A成功发送数据，主机B的ACK丢失

 如上图所示，主机B会重复收到 两个 “数据(1 ~ 1000)”。

那要如何去重呢？

TCP协议会通过前面提到的 序列号 来判断哪些数据是重复发送的，并把重复的包丢弃。 

超时重传的时间该如何确定呢？

如果超时重传的时间太长，会影响网络传输效率；

如果超时重传时间太短，又会可能频繁传输重复的包

（超时重传时间太短的情况如下）

 这真是一个令人头疼的问题

 好在TCP协议为我们解决了这个问题：

TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。

• Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定 超时重发的超时时间都是500ms的整数倍。
• 如果重发一次之后，仍然得不到应答，等待 2*500ms 后再进行重传。
• 如果仍然得不到应答，等待 4*500ms 进行重传。依次类推，以指数形式递增。
• 累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

如果面试官问你：TCP是如何实现可靠性的？

答：确认应答 + 超时重传。（而不是 三次握手 + 四次挥手~~）

③ 三次握手（连接管理机制(安全机制)）

        握手(handshake)指的是通信双方进行一次网络交互，相当于 客户端 和 服务器 之间，通过三次交互，建立了连接关系。

 

•  SYN：同步报文段，意思是一方向另一方申请连接
•  ACK：确认报文段，意思是确认收到对方发送的数据
•  seq：初始序号
•  ack：确认号

简化版：

 

为什么要进行三次握手，握一次行不行？

要回答这个问题，那么我们就需要清楚 三次握手 的目的是什么了，三次握手的目的是为了检测 交互双方 的 接收能力 和 发送能力 是否能够正常使用：

我们拿 连麦打游戏 来举例子，把 接收能力 比作 耳机，把 发送能力 比作 麦克风；我们开始打游戏前要保证双方的耳机和麦克风都没有问题：

三次握手一定是客户端先发起的！！！

④四次挥手（连接管理机制(安全机制)）

 简化版：

 FIN：通知对方，本段要关闭了，我们称携带 FIN 标识的为 结束报文段

注意：四次挥手里的 ACK 和 FIN 不能一起发送！！！

这个过程就像男女之间提分手一样：

注意：客户端和服务器都可以先发送 断开连接的请求。

思考：

为什么 三次握手 里的 SYN 和 ACK 可以一起发送，而 四次挥手 里的 ACK 和 FIN 不能一起发送？

三次握手的时候， ACK 和 SYN 是同一个时期触发的（都是由内核来完成的）

四次挥手的时候，ACK 和 FIN 则是不同时机触发的：

ACK是内核完成的，会在收到 对方的FIN 的第一时间返回；

FIN 则是应用程序代码控制的，在调用 socket 的 close 方法的时候才会触发 FIN。

上一篇文章里基于TCP的服务器代码里的close：

 这个 close 的执行时机，可能是立即执行，也可能是隔很久执行，这取决于你的代码怎么写。如果立即 close，趁着刚才 ACK 还没发，那么这里就可以合并；如果是隔了很久再 close，此时 FIN 只能单独发送了~~

整个 TCP 传输过程：

 状态转化（了解即可）：

 服务端状态转化：

• [CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态，等待客户端连接；
• [LISTEN -> SYN_RCVD] 一旦监听到连接请求（同步报文段），就将该连接放入内核等待队列 中，并向客户端发送SYN确认报文。
• [SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文，就进入ESTABLISHED状 态，可以进行读写数据了。
• [ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接（调用close），服务器会收到结束 报文段，服务器返回确认报文段并进入CLOSE_WAIT；
• [CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接（需要处理完之前 的数据）；当服务器真正调用close关闭连接时，会向客户端发送FIN，此时服务器进入 LAST_ACK状态，等待最后一个ACK到来（这个ACK是客户端确认收到了FIN）
• [LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK，彻底关闭连接。

客户端状态转化：

• [CLOSED -> SYN_SENT] 客户端调用connect，发送同步报文段；
• [SYN_SENT -> ESTABLISHED] connect调用成功，则进入ESTABLISHED状态，开始读写数据；
• [ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时，向服务器发送结束报文段，同时进入FIN_WAIT_1；
• [FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认，则进入FIN_WAIT_2，开始等待服务器的结束报文段；
• [FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段，进入TIME_WAIT，并发出LAST_ACK；
• [TIME_WAIT -> CLOSED] 客户端要等待一个2MSL（Max Segment Life，报文最大生存时 间）的时间，才会进入CLOSED状态。

其中，特别要注意 三次握手 和 四次挥手 的状态：

三次握手：

四次挥手：

这里插一个非常重要的内容，就是主动关闭方的 TIME_WAIT 状态

为什么会有这个状态呢？

因为 主动关闭方 最后一次发送 ACK 有可能丢失，

 

那么丢失了之后，由于 被动关闭方 始终收不到这个 主动关闭方的 ACK，那么 被动关闭方 就会再次发送一个 FIN包 来通知 主动关闭方 要断开连接了。

 那如果此时 主动关闭方 TIME_WAIT 了之后就直接 CLOSE 掉程序了，那么如果此时恰巧新启动了一个客户端，那么这时这个新启动的客户端就会收到发过来的 FIN。

因此，为了避免由于 主动发送方 最后的 ACK 丢失，导致 被动发送方 重传 FIN包，使 新启动的 客户端 还没连接就收到 FIN包 的情况，通常 TIME_WAIT 之后会等待 2msl 的时间 才会 CLOSE 掉主动发送方。

 

⑤滑动窗口（效率机制）

在前面的前面，我们讨论了确认应答策略，就是对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送 下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。

既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多 个段的等待时间重叠在一起了）。

•  窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000 个字节（四个段）。
• 发送前四个段的时候，不需要等待任何ACK，直接发送.
• 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据，依次类推。
• 操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉。
• 窗口越大，则网络的吞吐率就越高。

那么如果在传输过程中出现了丢包情况，阁下又该如何应对？

情况一：

这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认； 

情况二：

• 当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 "我想 要的是 1001" 一样；
• 如果发送端主机连续三次收到了同样一个 "1001" 这样的应答，就会将对应的数据 1001 - 2000 重新发送；
• 这个时候接收端收到了 1001 之后，再次返回的ACK就是7001了（因为2001 - 7000）接收端 其实之前就已经收到了，被放到了接收端操作系统内核的 接收缓冲区 中；

我们来讲一讲这个 接收缓冲区 具体有什么作用：

在主机A接收到第三个重复的 答应报文段之前，在主机B的 接收缓冲区里已经根据字节序放好了除1001 ~ 2000 之外的所有 1 ~ 7000字节序的数据。

 当主机A第三次收到了同样一个 "1001" 这样的应答，就会将对应的数据 1001 - 2000 重新发送，此时字节序位 1001 ~ 2000 的空挡就会被填上。

这种机制被称为 "高速重发控制"（也叫 "快重传"）。

⑥ 流量控制（安全机制）

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。

因此TCP会根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制（Flow Control）。

1.接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段，通过ACK端通知发送端：

当 ACK 为 1 的时候，此时窗口大小字段就会生效，这里的值就是建议发送的窗口大小。

 注意：接收方(也就是发送 ACK 的一方)才会计算窗口大小。如何计算？

其实很简单，直接拿接收缓冲区的剩余空间作为窗口大小。

那么问题来了，窗口大小只有 16位，而16位数字最大表示65535，那么TCP窗口最大就是65535字节么？

实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移 M 位。

2.窗口大小字段越大，说明网络的吞吐量越高；

3.接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；

4.发送端接受到这个窗口之后，就会减慢自己的发送速度；

5.如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一 个窗口探测数据段，使接收端把窗口大小告诉发送端。

具体流程如下：

⑦ 拥塞控制（安全机制）

虽然TCP有滑动窗口能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大 量的数据，仍然可能引发问题。 因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发 送大量的数据，是很有可能引起雪上加霜的。

因此，TCP引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。

此处引入一个概念程为拥塞窗口：

• 发送开始的时候，定义拥塞窗口大小为1。
• 每次收到一个ACK应答，拥塞窗口加1。
• 每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为 实际发送的窗口，即 实际发送窗口 = min(拥塞窗口, 流控窗口)。
• 拥塞窗口是由网络线路的阻塞情况来决定的，而流控窗口是由接收端的缓冲区的剩余空间决定的。

它的过程大致是这样滴：

1.刚开始传输的时候，会给一个非常小的窗口（一个比较小的值），然后以指数级别的速度增长。"慢启动" 只是指初使时慢，但是增长速度非常快。

2.为了不增长的那么快，因此不能使拥塞窗口单纯的加倍。

此处引入一个叫做慢启动的阈值(ssthresh)，当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长。

3.少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞。而当网络拥塞的时候，吞吐量会立刻下降，即把窗口回归到一个比较小的初始值。

同时 慢启动的阈值(ssthresh) 也会降到发生网络阻塞时的一半(以上图为例，ssthresh 降到了 12，即 24 的一半)

4.重复上述环节。

⑧ 延迟应答（效率机制）

前面我们学到，TCP 中决定效率最重要的元素就是 窗口大小。窗口越大，网络吞吐量就越大，传输效率就越高。

那么，如果接收数据的主机一收到一份数据，就立马返回带有窗口大小的ACK应答，那么这时候返回的窗口大小就会比较小。

• 假设接收端缓冲区为1M。一次收到了500K的数据，如果立刻应答，返回的窗口就是500K。
• 但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了； 在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来。
• 如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是 1M。

那么所有的包都可以延迟应答么？

肯定也不是。 

• 数量限制：每隔N个包就应答一次。
• 时间限制：超过最大延迟时间就应答一次。

⑨捎带应答（效率机制）

前面我们提到 四次挥手里 ACK 和 FIN 不能同时发送，原因是它们 发送的时机不同：

但是，如果 ACK 等上那么一会儿再发送，就可能和 response 合并成一个数据报。

合并成一个，比分成两次发效率要高。

就像搭顺风车一样，如果两个目的地一样，但是上车的时间可能不同的两个人要坐同一辆车，那么时间早的人可以等一等时间比较晚的人一起坐车，这样司机的效率提高了，车费也平摊了~~

这种 “搭顺风车” 的行为就叫 捎带应答。

⑩ TCP 缓冲区

创建一个TCP的socket，同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区：

• 调用write时，数据会先写入发送缓冲区中。
• 如果发送的字节数太长，会被拆分成多个TCP的数据包发出。
• 如果发送的字节数太短，就会先在缓冲区里等待，等到缓冲区长度差不多了，或者其他合适 的时机发送出去。
• 接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区。
• 然后应用程序可以调用read从接收缓冲区拿数据。

另一方面，TCP的一个连接，既有发送缓冲区，也有接收缓冲区，那么对于这一个连接，既 可以读数据，也可以写数据。这个概念叫做 全双工（UDP 也是 全双工）。

由于缓冲区的存在，TCP程序的读和写不需要一一匹配，例如：

• 写100个字节数据时，可以调用一次write写100个字节，也可以调用100次write，每次写一 个字节；
• 读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次read 100个字 节，也可以一次read一个字节，重复100次；

粘包问题

由于 TCP 是面向字节流的，那就会产生粘包问题，粘包问题简单来说就是分不清一串字节数据从哪里开始到哪里结束是一段完整的数据报。

那么如何避免粘包问题呢？归根结底就是一句话，明确两个包之间的边界。

1. 对于长度一定的包，保证每次都按固定大小读取即可。
2. 对于长度会改变的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置。
3. 对于长度会改变的包，还可以在包和包之间使用明确的分隔符（应用层协议，是程序猿自己来定 的，只要保证分隔符不和正文冲突即可）；

异常情况

即 断开连接时 发生的异常：

1. 进程终止：正常进行 四次挥手。

2. 电脑正常关机：电脑关机的时候会先终止所有的用户进程，也会触发四次挥手。如果四次挥手 没有完全结束，比如，对方发过来了 FIN，电脑还没有来得及发送 ACK 就关机了，此时对端就会重传 FIN ，对端重传了几次 FIN 之后，都没有接收到 ACK，那就会尝试重置连接；如果还不行，就直接释放连接。

3.机器掉电 / 网线断开：

• 对端是发送方，本方机器掉电 / 网线断开了，那对端就不会收到 ACK，那么就会进行 超时重传 -> 重置连接 ->释放连接
• 对端是接收端，本方机器掉电 / 网线断开了，对端无法立刻知道你这边是还没来得及发送新的数据还是直接没了。那么就可以用上 TCP 内置的 心跳包保活机制：如果每一个 ping 都有及时的 pong，那么证明当前对端的状态良好；如果 ping 过去之后，没有 pong 了，说明心跳没了，也就是出异常了~~

TCP中的长短连接 

TCP发送数据时，需要先建立连接，什么时候关闭连接就决定是短连接还是长连接：

短连接：每次接收到数据并返回响应后，都关闭连接，即是短连接。也就是说，短连接只能一次收发数据。

长连接：不关闭连接，一直保持连接状态，双方不停的收发数据，即是长连接。也就是说，长连接可以多次收发数据。

对比以上长短连接，两者区别如下：

建立连接、关闭连接的耗时：短连接每次请求、响应都需要建立连接，关闭连接；而长连接只需要 第一次建立连接，之后的请求、响应都可以直接传输。相对来说建立连接，关闭连接也是要耗时 的，长连接效率更高。

主动发送请求不同：短连接一般是客户端主动向服务端发送请求；而长连接可以是客户端主动发送 请求，也可以是服务端主动发。

两者的使用场景有不同：短连接适用于客户端请求频率不高的场景，如浏览网页等。长连接适用于 客户端与服务端通信频繁的场景，如聊天室，实时游戏等。

TCP小结

为什么TCP这么复杂？

因为要保证可靠性，同时又尽可能的提高性能。

可靠性：

• 校验和
• 序列号（按序到达）
• 确认应答
• 超时重发
• 连接管理
• 流量控制
• 拥塞控制

提高性能：

• 滑动窗口
• 快速重传
• 延迟应答
• 捎带应答

                                        这篇文章有点长，大家要好好消化一下哦~~