计算机网络之传输层

5 传输层

5.1 复用与分用

IP地址 来区分主机，端口号 来区分进程。

将 IP地址 + 端口号 就构成 套接字 ，用来唯一地标识网络中的一台主机及其上的一个应用进程；

FTP：21 TELNET：23 SMTP：25 DNS：53 TFTP：69 HTTP：80 SMTP：161

5.2 UDP ⭐️

5.3 TCP 🌟

TCP 与 UDP 的区别（重要）

1. 是否面向连接 ：UDP 在传送数据之前不需要先建立连接。而 TCP 提供面向连接的服务，在传送数据之前必须先建立连接，数据传送结束后要释放连接。
2. 是否是可靠传输：远地主机在收到 UDP 报文后，不需要给出任何确认，并且不保证数据不丢失，不保证是否顺序到达。TCP 提供可靠的传输服务，TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制。通过 TCP 连接传输的数据，无差错、不丢失、不重复、并且按序到达。
3. 是否有状态 ：这个和上面的“是否可靠传输”相对应。TCP 传输是有状态的，这个有状态说的是 TCP 会去记录自己发送消息的状态比如消息是否发送了、是否被接收了等等。为此 ，TCP 需要维持复杂的连接状态表。而 UDP 是无状态服务，简单来说就是不管发出去之后的事情了。
4. 传输效率 ：由于使用 TCP 进行传输的时候多了连接、确认、重传等机制，所以 TCP 的传输效率要比 UDP 低很多。
5. 传输形式 ： TCP 是面向字节流的，UDP 是面向报文的。
6. 首部开销 ：TCP 首部开销（20 ～ 60 字节）比 UDP 首部开销（8 字节）要大。
7. 是否提供广播或多播服务 ：TCP 只支持点对点通信，UDP 支持一对一、一对多、多对一、多对多

什么时候选择 TCP,什么时候选 UDP?

• UDP 一般用于即时通信，比如： 语音、 视频 、直播等等。这些场景对传输数据的准确性要求不是特别高，比如你看视频即使少个一两帧，实际给人的感觉区别也不大。
• TCP 用于对传输准确性要求特别高的场景，比如文件传输、发送和接收邮件、远程登录等等。

HTTP 基于 TCP 还是 UDP？

基于TCP：FTP【控制21，数据20】、SMTP【25】、POP3【110】/IMAP【143】、Telnet【23】、SSH

基于UDP：DNS【53】、DHCP【67、68】

HTTP 3.0 之前是基于 TCP 协议的，而 HTTP3.0 将弃用 TCP，改用 基于 UDP 的 QUIC 协议 。

此变化主要为了解决 HTTP/2 中存在的队头阻塞问题：由于 HTTP/2 在单个 TCP 连接上使用了多路复用，受到 TCP 拥塞控制的影响，少量的丢包就可能导致整个 TCP 连接上的所有流被阻塞。当单个（慢）对象阻止其他/后续的对象前进时

TCP 三次握手

建立一个 TCP 连接需要“三次握手”，缺一不可 ：

• 一次握手:客户端发送带有 SYN（SEQ=x） 标志的数据包 -> 服务端，然后客户端进入 SYN_SEND 状态，等待服务器的确认；
• 二次握手:服务端发送带有 SYN+ACK(SEQ=y,ACK=x+1) 标志的数据包 –> 客户端,然后服务端进入 SYN_RECV 状态
• 三次握手:客户端发送带有 ACK(ACK=y+1) 标志的数据包 –> 服务端，然后客户端和服务器端都进入ESTABLISHED 状态，完成TCP三次握手。

当建立了 3 次握手之后，客户端和服务端就可以传输数据啦！

为什么要三次握手?

三次握手的目的是建立可靠的通信信道，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

1. 第一次握手 ：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
2. 第二次握手 ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
3. 第三次握手 ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

三次握手就能确认双方收发功能都正常，缺一不可。

如果两次握手，服务器无法知道客户端是否已经接收到自己的同步信号，如果这个同步信号丢失了，初始序列号将无法达成一致。

第2次握手传回了ACK，为什么还要传回SYN？

服务端传回发送端所发送的ACK 是为了告诉客户端：“我接收到的信息确实就是你所发送的信号了”，这表明从客户端到服务端的通信是正常的。

回传 SYN 则是为了建立并确认从服务端到客户端的通信。

SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。

在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement）消息响应。

这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递

TCP 四次挥手

断开一个 TCP 连接则需要“四次挥手”，缺一不可 ：

1. 第一次挥手 ：客户端发送一个 FIN（SEQ=X） 标志的数据包->服务端，用来关闭客户端到服务器的数据传送。然后，客户端进入 FIN-WAIT-1 状态。
2. 第二次挥手 ：服务器收到这个 FIN（SEQ=X） 标志的数据包，它发送一个 ACK （SEQ=X+1）标志的数据包->客户端 。然后，此时服务端进入CLOSE-WAIT状态，客户端进入FIN-WAIT-2状态。
3. 第三次挥手 ：服务端关闭与客户端的连接并发送一个 FIN (SEQ=y)标志的数据包->客户端请求关闭连接，然后，服务端进入LAST-ACK状态。
4. 第四次挥手 ：客户端发送 ACK (SEQ=y+1)标志的数据包->服务端并且进入TIME-WAIT状态，服务端在收到 ACK (SEQ=y+1)标志的数据包后进入 CLOSE 状态。此时，如果客户端等待 2MSL 后依然没有收到回复，就证明服务端已正常关闭，随后，客户端也可以关闭连接了。

只要四次挥手没有结束，客户端和服务端就可以继续传输数据！

为什么要四次挥手？

TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。

举个例子：A 和 B 打电话，通话即将结束后。

1. 第一次挥手 ： A 说“我没啥要说的了”
2. 第二次挥手 ：B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话
3. 第三次挥手 ：于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”
4. 第四次挥手 ：A 回答“知道了”，这样通话才算结束。

为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？

因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复 ACK，表示接收到了断开连接的请求。等到数据发完之后再发 FIN，断开服务器到客户端的数据传送。

如果第二次挥手时服务器的 ACK 没有送达客户端，会怎样？

客户端没有收到 ACK 确认，会重新发送 FIN 请求。

为什么第四次挥手客户端需要等待 2*MSL（报文段最长寿命）时间后才进入 CLOSED 状态？

第四次挥手时，客户端发送给服务器的 ACK 有可能丢失，如果服务端因为某些原因而没有收到 ACK 的话，服务端就会重发 FIN，如果客户端在 2*MSL 的时间内收到了 FIN，就会重新发送 ACK 并再次等待 2MSL，防止 Server 没有收到 ACK 而不断重发 FIN。

MSL(Maximum Segment Lifetime) : 一个片段在网络中最大的存活时间，2MSL 就是一个发送和一个回复所需的最大时间。如果直到 2MSL，Client 都没有再次收到 FIN，那么 Client 推断 ACK 已经被成功接收，则结束 TCP 连接。

TCP传输可靠性

（1）校验和 （2）序号 （3）确认机制 （4）超时重传

**（1）校验和：**TCP 首部具有一个校验和字段，用来校验首部和数据的和。

端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。

（2）序号：对失序数据包重新排序以及去重：TCP 为了保证不发生丢包，就给每个包一个序列号，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据就可以实现数据包去重

（3）确认机制

TCP发送的报文段也许会丢失，所以发送方的TCP缓存还会留有已发送的报文段数据，直到收到接收方的确认报文段；

接收方采用 累积确认/捎带确认 的方式发出确认信息；

发送方收到确认信息，会将已经确认的报文段删除；

（4）重传机制

确认机制 和 重传机制 是密切相关的，规定时间未确认 就需要 重传；

TCP流量控制

为什么需要流量控制? 这是因为双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来。如果接收方处理不过来的话，就只能把处理不过来的数据存在 接收缓冲区(Receiving Buffers) 里（失序的数据包也会被存放在缓存区里）。如果缓存区满了发送方还在狂发数据的话，接收方只能把收到的数据包丢掉。出现丢包问题的同时又疯狂浪费着珍贵的网络资源。因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。

TCP 流量控制：流量控制是为了控制发送方发送速率，保证接收方来得及接收
在OSI参考模型中，数据链路层、网络层、传输层都具有流量控制功能，

数据链路层是相邻结点之间的流量控制，
网络层是整个网络中的流量控制，
传输层是端到端的流量控制。

流量控制：采用 滑动窗口 来控制 发送方 的传输速度；

两个重要窗口：接收窗口rwnd 和 拥塞窗口cwnd ；

发送窗口 = Min {接收窗口 rwnd，拥塞窗口 cwnd}；

TCP 发送窗口可以划分成四个部分 ：

1. 已经发送并且确认的TCP段（已经发送并确认）；
2. 已经发送但是没有确认的TCP段（已经发送未确认）；
3. 未发送但是接收方准备接收的TCP段（可以发送）；
4. 未发送并且接收方也并未准备接受的TCP段（不可发送）。

TCP 接收窗口可以划分成三个部分 ：

1. 已经接收并且已经确认的 TCP 段（已经接收并确认）；
2. 等待接收且允许发送方发送 TCP 段（可以接收未确认）；
3. 不可接收且不允许发送方发送TCP段（不可接收）。

发送窗口的大小取决于接收窗口和拥塞窗口的最小值。发送窗口 = Min {接收窗口 rwnd，拥塞窗口 cwnd}；

接收窗口的大小是根据接收端处理数据的速度动态调整的。 如果接收端读取数据快，接收窗口可能会扩大。 否则，它可能会缩小。

TCP拥塞控制

网络中某一资源的需求超过了该资源所能提供的可用部分**【需求超过可用部分】**，网络的性能就要变坏。这种情况就叫拥塞。

拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。

流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。

接收窗口接收方根据接受缓存设置的值，并告知给发送方，反映接收方容量。

拥塞窗口发送方根据自己估算的网络拥塞程度而设置的窗口值，反映网络当前容量。

发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP 的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

• 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。

• 拥塞避免： 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1.

• 快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。

  没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。

  有了 FRR，就不会因为重传时要求的暂停被耽误。

  如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。

  如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。