什么是TCP/UDP协议？（超简单，一看就会）

妖狐艹你老母 2022-10-25 14:04 184阅读 0赞

# TCP/UDP协议做了什么？ #

TCP/UDP协议处于计算机网络的第四层“传输层”，负责传输数据包。

## 数据包怎么传？（UDP协议） ##

TCP/UDP协议处于计算机网络的第四层“传输层”，下面三层从小到大 分别是“物理层”、“数据链路层”、“网络层”。有了下三层的铺垫，我们已经可以把一个数据包从A主机发送到在互联网任意一个角落的B主机上啦！ 站在高层就是好啊！什么都不要做！那开始传输数据包吧。

好像有问题了，数据包传输过程中只给到了ip地址，从A主机发到B主机后，交给哪个进程（软件）处理呢？

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hjcncwMQ_size_16_color_FFFFFF_t_70][]

所以，你需要把通信的进程区分开来，于是就给每个进程分配一个数字编号，你给它起了一个响亮的名字：**端口号**。

![20210201005451111.png][]

OK，这样你将原本主机到主机的通信，升级为了**进程和进程之间的通信**。

你没有意识到，你不知不觉实现了 **UDP 协议**！

# 数据包丢了怎么办？ #

上述UDP协议已经可以愉快的传数据包了，可是忽略了一个问题，如**果数据包丢了**怎么办？

是啊，A把数据包传给了B，会不会在过程中丢失呢？ 如果收不到怎么办？ 真是个令人头疼的问题。

有问题，就一定有解决方案，首先把问题拆解

对于丢包问题，只要解决两个事就好了。

> **第一个，A 怎么知道包丢了？**
> 
> 答案：让 B 告诉 A
> 
> **第二个，丢了的包怎么办？**
> 
> 答案：重传

于是你设计了如下方案，A 每发一个包，都必须收到来自 B 的**确认**（ACK），再发下一个，否则在一定时间内没有收到确认，就**重传**这个包。

![20210201010002221.gif][]

你管它叫**停止等待协议**。只要按照这个协议来，虽然 A 无法保证 B 一定能收到包，但 A 能够确认 B 是否收到了包，收不到就重试，尽最大努力让这个通信过程变得可靠，于是你们现在的通信过程又有了一个新的特征，**可靠交付**。

## 数据包ACK确认太慢怎么办？ ##

停止等待虽然能解决问题，但是效率太低了，A 原本可以在发完第一个数据包之后立刻开始发第二个数据包，但由于停止等待协议，A 必须等数据包到达了 B ，且 B 的 ACK 包又回到了 A，才可以继续发第二个数据包，这效率慢得可不是一点两点。

于是你对这个过程进行了改进，采用**流水线**的方式，不再傻傻地等。

![20210201010142351.gif][]

## 数据包顺序乱了怎么办？ ##

网路是复杂的、不可靠的。

有的时候 A 发出去的数据包，分别走了不同的路由到达 B，可能无法保证和发送数据包时一样的顺序。

![20210201010235432.gif][]

在流水线中有多个数据包和ACK包在**乱序流动**，他们之间对应关系就乱掉了。

难道还回到停止等待协议？A 每收到一个包的确认（ACK）再发下一个包，那就根本不存在顺序问题。应该有更好的办法！

A 在发送的数据包中增加一个**序号**（seq），同时 B 要在 ACK 包上增加一个**确认号**（ack），这样不但解决了停止等待协议的效率问题，也通过这样标序号的方式解决了顺序问题。

![20210201010428984.gif][]

而 B 这个确认号意味深长：比如 B 发了一个确认号为 ack = 3，它不仅仅表示 A 发送的序号为 2 的包收到了，还表示 2 之前的数据包都收到了。这种方式叫**累计确认**或**累计应答**。

## 数据包太多，接收方接收不了这么多怎么办？ ##

有的时候，A 发送数据包的速度太快，而 B 的接收能力不够，但 B 却没有告知 A 这个情况。

![20210201010548736.gif][]

怎么解决呢？

很简单，B 告诉 A 自己的接收能力，A 根据 B 的接收能力，相应控制自己的**发送速率**，就好了。

B 怎么告诉 A 呢？B 跟 A 说"我很强"这三个字么？那肯定不行，得有一个严谨的规范。

于是 B 决定，每次发送数据包给 A 时，顺带传过来一个值，叫**窗口大小**（win)，这个值就表示 B 的**接收能力**。同理，每次 A 给 B 发包时也带上自己的窗口大小，表示 A 的接收能力。

![20210201010611304.gif][]

B 告诉了 A 自己的窗口大小值，A 怎么利用它去做 A 这边发包的流量控制呢？

很简单，假如 B 给 A 传过来的窗口大小 win = 5，那 A 根据这个值，把自己要发送的数据分成这么几类。

![图片][2b8960532c94cc29425b0ffcadf0e9ae.png]

图片过于清晰，就不再文字解释了。

当 A 不断发送数据包时，**已发送的最后一个序号**就往右移动，直到碰到了窗口的上边界，此时 A 就无法继续发包，达到了流量控制。

![20210201010650421.gif][]

但是当 A 不断发包的同时，A 也会收到来自 B 的确认包，此时**整个窗口**会往右移动，因此上边界也往右移动，A 就能发更多的数据包了。

![2021020101070960.gif][]

以上都是在窗口大小不变的情况下，而 B 在发给 A 的 ACK 包中，每一个都可以**重新设置**一个新的窗口大小，如果 A 收到了一个新的窗口大小值，A 会随之调整。

如果 A 收到了比原窗口值更大的窗口大小，比如 win = 6，则 A 会直接将窗口上边界向右移动 1 个单位。

![20210201010741439.gif][]

如果 A 收到了比原窗口值小的窗口大小，比如 win = 4，则 A 暂时不会改变窗口大小，更不会将窗口上边界向左移动，而是等着 ACK 的到来，不断将左边界向右移动，直到窗口大小值收缩到新大小为止。

![2021020101075115.gif][]

OK，终于将流量控制问题解决得差不多了，你看着上面一个个小动图，给这个窗口起了一个更生动的名字，**滑动窗口**。

拥塞问题

但有的时候，不是 B 的接受能力不够，而是网络不太好，造成了**网络拥塞**。

![图片][89f19e6d469faeb934f57cc58b364680.gif]

拥塞控制与流量控制有些像，但流量控制是受 B 的接收能力影响，而拥塞控制是受**网络环境**的影响。

拥塞控制的解决办法依然是通过设置一定的窗口大小，只不过，流量控制的窗口大小是 B 直接告诉 A 的，而拥塞控制的窗口大小按理说就应该是网络环境主动告诉 A。

但网络环境怎么可能主动告诉 A 呢？只能 A 单方面通过**试探**，不断感知网络环境的好坏，进而确定自己的拥塞窗口的大小。

![图片][7bf892ad6c3d54fd96d454d11823f1e1.gif]

拥塞窗口大小的计算有很多复杂的算法，就不在本文中展开了，假如**拥塞窗口的大小为  cwnd**，上一部分流量控制的**滑动窗口的大小为 rwnd**，那么窗口的右边界受这两个值共同的影响，需要取它俩的最小值。

**窗口大小 = min(cwnd, rwnd)**

含义很容易理解，当 B 的接受能力比较差时，即使网络非常通畅，A 也需要根据 B 的接收能力限制自己的发送窗口。当网络环境比较差时，即使 B 有很强的接收能力，A 也要根据网络的拥塞情况来限制自己的发送窗口。正所谓受其**短板**的影响嘛~

连接问题

有的时候，B 主机的相应进程还没有准备好或是挂掉了，A 就开始发送数据包，导致了浪费。

![图片][a9329f189c0e6b88644874f44d441f94.gif]

这个问题在于，A 在跟 B 通信之前，没有事先确认 B 是否已经准备好，就开始发了一连串的信息。就好比你和另一个人打电话，你还没有"喂"一下确认对方有没有在听，你就巴拉巴拉说了一堆。

这个问题该怎么解决呢？

地球人都知道，**三次握手**嘛！

A：我准备好了(SYN)

B：我知道了(ACK)，我也准备好了(SYN)

A：我知道了(ACK)

![图片][667f4d2154d52a00367e0eff9a42597d.gif]

A 与 B 各自在内存中维护着自己的状态变量，三次握手之后，双方的状态都变成了**连接已建立**（ESTABLISHED）。

虽然就只是发了三次数据包，并且在各自的内存中维护了状态变量，但这么说总觉得太 low，你看这个过程相当于双方建立连接的过程，于是你灵机一动，就叫它**面向连接**吧。

注意：这个连接是虚拟的，是由 A 和 B 这两个终端共同维护的，在网络中的设备根本就不知道连接这回事儿！

但凡事有始就有终，有了建立连接的过程，就要考虑释放连接的过程，又是地球人都知道，**四次挥手**嘛！

A：再见，我要关闭了(FIN)

B：我知道了(ACK)

给 B 一段时间把自己的事情处理完...

B：再见，我要关闭了(FIN)

A：我知道了(ACK)

![图片][1a50f50020c0f3bcf55b3d263bd86a94.gif]

总结

以上讲述的，就是 TCP 协议的核心思想，上面过程中需要传输的信息，就体现在 TCP 协议的头部，这里放上最常见的 TCP 协议头解读的图。

![图片][f09d03d9d1c9e82305f6cd6cf3d418d9.png]

不知道你现在再看下面这句话，是否能理解：

**TCP 是**

**面向连接的、可靠的、基于字节流的**

**传输层通信协议**

面向连接、可靠，这两个词通过上面的讲述很容易理解，那什么叫做基于字节流呢？

很简单，TCP 在建立连接时，需要告诉对方 MSS（最大报文段大小）。

也就是说，如果要发送的数据很大，在 TCP 层是需要按照 MSS 来切割成一个个的 **TCP 报文段 **的。

切割的时候我才不管你原来的数据表示什么意思，需要在哪里断句啥的，我就把它当成一串毫无意义的字节，在我想要切割的地方咔嚓就来一刀，标上序号，只要接收方再根据这个序号拼成最终想要的完整数据就行了。

在我 TCP 传输这里，我就把它当做一个个的**字节**，也就是基于字节流的含义了。

![图片][b94c1c119a51fd2b9c91f07ddb6e1d85.png]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hjcncwMQ_size_16_color_FFFFFF_t_70]: /images/20221024/0aad474d941c4e068e408b9f3f0f3cd6.png
[20210201005451111.png]: /images/20221024/d867ef7844c54ca5b1ffcd329ac7c5cc.png
[20210201010002221.gif]: /images/20221024/b6c659e48cf34aaaa66e4f6b54edfd58.png
[20210201010142351.gif]: /images/20221024/d86e0dd91c924d438b1b7afa70081b5a.png
[20210201010235432.gif]: /images/20221024/8fb3a268bb4148d582d94393ce75107c.png
[20210201010428984.gif]: /images/20221024/baed7aaaacb248c8a2668508ead7ae9c.png
[20210201010548736.gif]: /images/20221024/28ced1b646274960bdcb3cd580e33a15.png
[20210201010611304.gif]: /images/20221024/6081a9d8cac843aaaf288d9cfa0890ee.png
[2b8960532c94cc29425b0ffcadf0e9ae.png]: /images/20221024/491e3ee897ec42d4a8a5aba88e4fb407.png
[20210201010650421.gif]: /images/20221024/2d5296fce3ae4c1e84218c7776d845f9.png
[2021020101070960.gif]: /images/20221024/41221ab26c494591ac2bd3edd9de5d76.png
[20210201010741439.gif]: /images/20221024/75b567188a85498caa833807de7eefc4.png
[2021020101075115.gif]: /images/20221024/b2b6430581bd46f986ad8cf787c7b48c.png
[89f19e6d469faeb934f57cc58b364680.gif]: /images/20221024/e25e5902f20e4754a3e5cc3f177a123d.png
[7bf892ad6c3d54fd96d454d11823f1e1.gif]: /images/20221024/2a664cc136084ae09035dc1456ac4461.png
[a9329f189c0e6b88644874f44d441f94.gif]: /images/20221024/7ea32b3481314106bee4abe1a416dd75.png
[667f4d2154d52a00367e0eff9a42597d.gif]: /images/20221024/fe36eda8f0f6400c94c35634b91a6571.png
[1a50f50020c0f3bcf55b3d263bd86a94.gif]: /images/20221024/c6255db9376f40c084b67ae0cd782a25.png
[f09d03d9d1c9e82305f6cd6cf3d418d9.png]: /images/20221024/795f55ac34c548a7b8e715baaad6ec2c.png
[b94c1c119a51fd2b9c91f07ddb6e1d85.png]: /images/20221024/003ecec7190b445795ff1eaa5d208c8a.png