[网络协议]【计算机网络】TCP相关总结

两种传输层协议对比

UDP

在传送数据之前不需要建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信）。

比如： QQ 语音、 QQ 视频 、直播等等

TCP

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务。

TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销， 如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。

 TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

可靠传输

如何可靠传输

TCP 是通过序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输的。

1. 应用数据被分割成 TCP 认为最适合发送的数据块。
2. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
3. 校验和： TCP 将维护一个首部和数据的检验和，检测数据在传输过程中的任何变化。如果收到段的检验和有差错， TCP 将丢弃这个报文段和不确认收到此报文段。
4. TCP 的接收端会丢弃重复的数据。
5. 流量控制： TCP 连接的双方都有固定大小的缓冲空间，接收端只允许发送端发送接收端缓冲区能接纳的数据（就是我不让你发太大的数据一方我自己吃不下）。当接收方来不及接手数据，提示发送方降低发送速率，防止包丢失。 TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
6. 拥塞控制： 当网络拥塞时，减少数据的发送。
7. ARQ 协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
8. 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

滑动窗口、流量控制

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段用来控制发送方窗口大小，从而影响发送方的发送速率。（简单来说，是我来控制你给我发多少）将窗口字段设置为 0，则发送方不能发送数据。

拥塞控制、流量控制的区别

拥塞控制：

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

流量控制：

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

拥塞控制

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

• 拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。

• 那么怎么知道当前网络是否出现了拥塞呢？其实只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了用拥塞。

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

拥塞控制采用了四种算法：

1. 慢开始
2. 拥塞避免
3. 快重传
4. 快恢复。

在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

具体这个窗口是按照什么规则变大变小的呢？

（1）慢开始：

因为现在还不知道网络的符合情况，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，由小到大逐渐增大拥塞窗口数值。

cwnd 初始值为 1，每经过一个传播轮次， cwnd 加倍。

（2）拥塞避免：

拥塞避免算法的思路是随着时间，拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送放的 cwnd 加 1。（而不是上一个的按照传播轮次增加窗口大小）

上述两种方法都是将拥塞窗口不断变大，但当网络拥塞的时候，会出现丢包情况，这时候就要引入快重传和快恢复了。

（3）快重传与快恢复：

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

相比于直接超时重传，他比较温和，如果直接拥塞后触发超时重传，接着，就重新开始慢启动，慢启动是会突然减少数据流的。这真是一旦「超时重传」，拥塞窗口立马回到最初的1，马上回到解放前。但这种方式太激进了，反应也很强烈，会造成网络卡顿。

当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，则 ssthresh 和 cwnd 变化如下：

• cwnd = cwnd/2 ，也就是设置为原来的一半;
• ssthresh = cwnd;

之后，进入快速恢复算法。

• 没有FRR，如果数据包丢失了， TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。
• 有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。
• 有了 FRR，就不会因为重传时要求的暂停被耽误。 当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。
• 缺点是，当有多个数据信息包在某一段很短的时间内丢失时，则不能有效地工作。

ARQ 协议

自动重传请求（Automatic Repeat-reQuest， ARQ）是 OSI 模型中数据链路层和传输层的错误纠正协议之一。

• 它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。
• 如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。
• ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。

（1）停止等待 ARQ 协议

• 停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。
• 如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组；
• 在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

优点： 简单
缺点： 信道利用率低，等待时间长

无差错情况:
发送方发送分组，接收方在规定时间内收到，并且回复确认，发送方再次发送。

出现差错情况（超时重传） :
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。

另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。

确认丢失和确认迟到：

确认丢失 ：

消息在传输过程丢失。当 A 发送 M1 消息， B 收到后， B 向 A 发送了一个 M1 确认消息，但却在传输过程中丢失。而 A 并不知道，在超时计时过后， A 重传 M1 消息， B 再次收到该消息后采取以下两点措施：

1. 丢弃这个重复的 M1 消息，不向上层交付。
2. 向 A 发送确认消息。（不会认为已经发送过了，就不再发送。 A 能重传，就证明 B 的确认消息丢失）。

确认迟到 ：

确认消息在传输过程中迟到。 A 发送 M1 消息， B 收到并发送确认。在超时时间内没有收到确认消息， A 重传 M1 消息， B 仍然收到并继续发送确认消息（B 收到了 2 份 M1）。此时 A 收到了 B 第二次发送的确认消息。接着发送其他数据。过了一会， A 收到了 B 第一次发送的对 M1 的确认消息（A 也收到了份确认消息）。处理如下：

• A 收到重复的确认后，直接丢弃。
• B 收到重复的 M1 后，也直接丢弃重复的 M1。

（2）连续 ARQ 协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。

缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。

比如：发送方发送了 5 条 消息，中间第三条丢失（3 号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退N），表示需要退回来重传已经发送过的 N 个消息。

握手和挥手

TCP连接为什么三次握手

客户端和服务端通信前要进行连接，“3次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。

第一次握手：客户端发送网络包，服务端收到了。

• 这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。

• 这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。但此时，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。

第三次握手：客户端发包，服务端收到了。

• 这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。

而在第三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送能力是正常的。而客户端的接收能力也是正常的。

经历了上面的三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的。之后就可以正常通信了。而从上面的过程可以看到，最少是需要三次握手过程的。两次达不到让双方都得出自己、对方的接收、发送能力都正常的结论。

传了 SYN,为啥还要传 ACK

双方通信无误必须是两者互相发送信息都无误。传了 SYN，证明发送方到接收方的通道没有问题（即我发过去没问题），但是接收方到发送方的通道还需要 ACK 信号来进行验证（即你发回来没问题）。

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

• 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
• 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加 1 ，和SYN 一样，一个 FIN 将占用一个序号
• 服务器-关闭与客户端的连接，发送一个 FIN 给客户端
• 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加 1

进程通讯方式