记录一下 TCP 的部分知识点

一、TCP 的部分知识点

为什么要写这个，其实只是做笔记了。方便自己以后阅读，也当作知识的分享。只是一些简单知识的概括，详细请参考谢希仁的《计算机网络》。

---

1. 一些基本知识

• 运输层最重要的两种协议 TCP 和 UDP
• 套接字 socket = (IP 地址:端口号)
• 每一条 TCP 连接唯一地被通信两端的两个端点（即两个套接字）所确定。

---

2. 可靠传输的工作原理

2.1 停止等待协议

全双工通信的双方既是发送方也是接收方。“停止等待” 就是每发送完一个分组就停止发送，等待对方确认，在收到确认后再发送下一个分组。

2.1.1 无差错情况

A 发送分组 M1，发送完就暂停发送，等待 B 的确认。B 收到了 M1 就向 A 发送确认。A 在收到了 B 对 M1 的确认后，就再发送下一个分组 M2。

2.1.2 出现差错

B 收到 M1 时检测出了差错，就丢弃 M1，然后什么都不做（不通知 A 收到有差错的分组）。或者是 M1 在传输过程中丢失了，B 什么都不知道。这两种情况，B 都不会发送任何的消息。可靠传输协议的设计是 A 只要超过了一段时间仍未收到 B 的确认，就认为刚才发送的分组丢失了，然后重传前面发送过的分组。这就是 超时重传。

2.1.3 确认丢失和确认迟到

假设 A 在设定的超时时间内并没有收到 B 的确认，在 A 的角度，并不知道这个分组是丢失了还是出错了，或者是 B 发送的确认丢失了。反正 A 在超时计时器到期后就重传分组。假设 B 又收到了重传的分组。这时就采取两个方式处理：

1. 丢弃这个重复的分组。
2. 向 A 发送确认。为什么要发送这个确认，因为 A 之所以重传，就表示 A 并没有收到对这个分组的确认。

像这种可靠的传输协议常称为 自动重传请求 ARQ (Automatic Repeat reQuest)。

2.1.4 信道利用率

通知等待协议的优点是简单，但缺点是信道利用率太低。

2.2 连续 ARQ 协议

发送方维持一个发送窗口，位于发送窗口的分组都可以连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。

连续 ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

接收方一般都是采用 积累确认 的方式。换言之，接收方不需要对收到的分组挨个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示，到这个分组为止的所有分组都已正确收到。

积累确认优点是容易实现，即使确认丢失也不必重传，缺点是不能向发送方反映出接收方已经正确收到的所有分组信息。

---

3. 三次握手

首先来一张很常见的图：

再来一些常见的描述：

1. A 向 B 发出连接请求报文段，此时首部中同部位 SYN = 1，同时选择一个初始序号 seq = x。A 进程进入 SYN-SENT（同步已发送）状态。
2. B 收到连接请求报文段后，如果同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。B 进程进入 SYN-RCVD（同步收到）状态。
3. A 收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y + 1，自己的序号 seq = x + 1。TCP 连接建立，A 进入 ESTABLISHED 状态。
4. 当 B 收到 A 的确认后，也进入 ESTABLISHED 状态。

为什么最后 A 还需要发送一次确认？这样做主要是为了防止已失效的连接请求报文段突然又传到了 B，导致出现错误。

已失效的连接请求报文段是如何产生的？设想一种情况，A 发出的连接请求，但因为连接请求报文丢失而没有收到 B 的确认，于是 A 再重传一次连接请求，此时收到了 B 的确认，双方正常的建立了连接。待到数据传输完成之后，释放连接。

如果 A 连接请求报文并没有丢失，而是在某些网络节点滞留了，于是 A 再重传，收到 B 的确认，双方建立连接，传输数据，释放连接。到此就结束了。然而，那个因为滞留的请求回来了，B 收到了请求后，就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认，同意建立连接。假设不采用三次握手，那么只要 B 发出确认后，新的连接就建立了。

由于此时的 A 并没有发出建立连接的请求，所以对于 B 的确认不理会，也不向 B 发送数据。但 B 却认为新的连接已经建立，并一直等待 A 的数据，就这样 B 的许多资源就白白浪费了。

---

参考：

• 谢希仁的《计算机网络》第五版