传输层TCP协议

传输层TCP协议

• 1. TCP协议简介
• 2. TCP 特点
• 3. TCP 协议段格式
• 4. 确认应答(ACK)机制和序列号
• 5. 捎带应答
• 6. 标志位
• 7. 连接管理机制
• • 7.1 三次握手
  • 7.2 四次挥手
  • 7.3 服务端状态转化
• 8. 超时重传机制
• 9. 流量控制
• 10. 滑动窗口
• 11. 拥塞控制
• 12. 延迟应答
• 13. 面向字节流
• 14. 粘包问题
• 15. TCP异常情况
• 16. 扩展问题
• • 如何用udp实现可靠性传输
  • TCP 和 UDP的对比
  • 为什么上面传输数据都是1000

1. TCP协议简介

UDP是一种没有复杂控制，提供面向无连接通信服务的一种协议，它将部分控制转移给应用程序处理，自己只提供作为传输层协议的最基本的功能，与UDP不同，TCP充分实现了数据传输时各种控制的功能，可以在丢包是进行重发，可以对次序乱掉的分包进行顺序控制，这些功能在UDP中都没有，此外，TCP是一种面向有连接的协议，只有在通信对端存在时才会发送数据，从而可以控制通信流量的浪费。TCP 全称为 "传输控制协议(Transmission Control Protoco). 人如其名, 要对数据的传输进行一个详细的控制;

2. TCP 特点

• TCP协议特点
• 面像字节流
• 全双工
• 可靠传输：接收端是否收到数据，发送端有感知
• 有连接

其中可靠传输是TCP诞生的初衷，为了实现可靠传输，TCP引入了一系列的机制，例如检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等

3. TCP 协议段格式

• 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
• 32 位序号/32 位确认号: 后面详细讲;
• 4 位 TCP 报头长度: 表示该 TCP 头部有多少个 32 位 bit(有多少个 4 字节); 所以TCP 头部最大长度是 15 * 4 = 60，也就是说TCP Header + 选项的最大大小就是60，而TCP Header是固定20字节的，也就说选项的最大大小时40字节。
• 6 位标志位:
  • URG: 紧急指针是否有效
  • ACK: 确认号是否有效
  • PSH: 提示接收端应用程序立刻从 TCP 缓冲区把数据读走
  • RST: 对方要求重新建立连接; 我们把携带 RST 标识的称为复位报文段
  • SYN: 请求建立连接; 我们把携带 SYN 标识的称为同步报文段
  • FIN: 通知对方, 本端要关闭了, 我们称携带 FIN 标识的为结束报文段
• 16 位窗口大小: 后面再说
• 16 位校验和: 发送端填充, CRC 校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含 TCP 首部, 也包含 TCP 数据部分.
• 16 位紧急指针: 标识哪部分数据是紧急数据;
• 40 字节头部选项: 暂时忽略;

4. 确认应答(ACK)机制和序列号

TCP协议是怎么保证可靠性的呢？这有一部分原因在于确认应答机制。就好比，两个人对话，这两个人是怎比保证对方明白了自己的意思一样，一个人问，另一个人进行回答。这样就可以保证消息是确确实实的给到了对方。所以对于客户端和服务端也是一样的道理，客户端对服务器发起请求，服务端进行确认应答，同样的道理，我们不能只保证客户端到服务端是可靠的，TCP是全双工的，所以也要保证服务端到客户端也是可靠的，所以服务端对客户端同样也要经上面的过程。而这个操作时双方的OS自己做到的。

但是像这样客户端发起请求，服务端发起确认应答后，服务器才能向客户端发起可靠性请求，然后客户端进行确认应答的这种串行的方式显然消耗的时间时多余的。一般的网络确认应答机制都是先发送很多个可靠性请求后，最后在一起做确认应答。

但是这也有了一个问题，那就是我们怎么确认确认应答的响应是哪一个发起的，虽然我们图上已经标清楚了，但是总会有意外的，不能说先发送的就是先到达的。所以为了让发送的和接受的匹配到一起，所以就要了32 位序号。所以在每个发送的报文都会携带一个序号，这样服务器就可拿到序号，并将序号排好序依次的进行确认响应。这个就是TCP的按序到达。但是也有一种情况时接受的确认应答的时候可能只接受到了2个ACK应答？这个怎么解决呢？所以这个时候TCP协议字段中的32位确认序号就起到作用了。在确认应答的报文中序号字段会返回收到的序号+1。

而这个确认序号的定义就是：该序列之前的数据，我已经收到了，下次发送请从确认序号开始。

5. 捎带应答

到这里就有会有一个疑问了，明明有了一个32位的序列号了，为什么还要有个以32位的确认序号呢？难道我的确认应答中不能使用32位的序列号当作是确认序列号吗？那是因为有一个场景。就是服务器可能既想确认应答，同时也想发数据。这个时候，因为我们的ACK确认只需要确认32位的确认序号即可，同时我们发数据的时候，就可以把32位序列号也填上了，这样本来要发送两次的报文，现在只需要发送一份报文就可以做到即ACK确认应答，也可以发送数据，两不误，大大节约时间成本和带宽成本，这个就叫做捎带应答。也就是说我既要有作为ACK应答的序号，也要有作为发送数据时的序号，所以就需要有两个序列号即发送序列号和确认序列号。

总结：

1. 学号存在的意义：按序到达，应答和确认对应。
2. 确认序号&&序号：同时向对方发数据的同时也在做应答。

6. 标志位

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

我们的服务器只有一个，但是我们的客户端去有很多个，所以服务器肯定会收到来自不同客户端发送的不同的数据报文，而收到的TCP报文是不同的类型的，这个时候就要有区分不同TCP报文类型，所以标志位的作用就是区分不同报文类型。

7. 连接管理机制

7.1 三次握手

建立连接(三次握手)
在数据通信之前，通过TCP首部发送一个SYN包作为建立连接的请求等待确认应答

注：

1. 这里我们要注意的是，所谓的发送SYN，ACK+SYN， ACK其实都是表示一个完整的报文，即TCP协议端格式。这里只是为了方便所以只是写上了添加的标志位的字段。
2. 而既然是建立连接总要有一方先发起请求把，所以这就与我们之前写TCP协议代码时，client的一段connect函数，就是由客户端发起请求，而既然client发起请求所以服务器就必须处于listen监听状态来捕获请求，当接受到请求时server就要accept来获取client的连接，这样服务器就可以进行处理数据了，请求连接，而三次握手是OS自动帮我们完成的。
   
3. 这里的ACK + SYN是进行了捎带应答的，每次数据报文的传输都要经历一系列的封装和分用，合并成一个数据报发送节省代价。

那么问题来了为什么要进行三次握手呢？

1. 如果只是一次握手的话，也就是说只要客户端主动提出连接就行了，但是建立连接和维护链接是有成本的，如果客户端一直申请连接去不作答，那是不是在一直浪费资源呢，同样服务器也很容易收到攻击？
2. 而如果是两次是两次握手的话也是同样的道理，只不过是多了一步通知客户端连接成功了，还是客户端占据主导地位。把这种称之为SYN洪水
3. 三次握手其实就是保证可靠性传输的机制，在正式通信之前我们要保证信道（网络）是健康的，从三次握手我们可以发现客户端和服务端都进行了一次ACK确认应答，这就变相的确定的双方通行的信道是健康的，也就是确认是全双工的。
4. 三次握手可以确保双方的操作系统（TCP）是否是健康并且是否愿意通信。

7.2 四次挥手

断开连接(四次挥手)
在通信结束时会进行断开连接的处理(FIN包）
TCP的首部用于控制的字段来管理TCP的连接。一个连接的建立和断开，正常过程至少需要来回发送7个数据包才能完成
与三次握手不同的是，三次握手的过程只能是客户端主动发起，对于四次挥手来说，通信双方都能主动发起
【断开连接的过程】

与三次握手不同的是，四次挥手的中间两次的交互过程不一定能进行合并

1. 主要是因为主机B返回ACK和FIN的时机是不同的，主机B返回ACK是操作系统内核来完成的，内核在收到来自A的FIN后，会立即返回一个ACK，而B要返回的FIN是由代码控制的，当用户在代码中调用了socket.close方法之后，才会触发FIN，这就导致B发送的FIN和ACK之间有不可忽视的时间间隔。
2. 这里之所以说不一定能合并是因为TCP中还有延时应答和捎带应答的机制。
3. 而在三次握手的时候，B返回的SYN和ACK都是内核收到A的SYN之后，立即返回的
4. TCP建立连接是没有历史包袱的，立即就能完成，而断开连接，很可能再A->B发送FIN的时候，B还有数据每读完，B一般不会立即断开，要把未处理的数据都处理完了再说，B何时发送FIN就是代码层次的了。那么问题又来了，不是说客户端已经调用了close(fd)了吗，怎么服务器发的数据客户端上层还能拿到数据呢？但是其实只是我们这么认为的，也有一种情况是其实我们的客户端只是单单的想收数据，不想发数据，也是有这种情况的，也就是说关闭了客户端的发的功能，但是还保留着收数据的功能。我们的系统也给我们提供了系统接口
   

7.3 服务端状态转化

【服务端状态转化】

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

但是这里我们要注意一点了，那就是三次握手那里的ESTABLISHED->ESTABLISHED的客户端向服务器发送ACK确认请求的时候是得不到服务器的确认应答的，也就是说一旦客户端发送了ACK确认请求了，那么客户端就认为已经完成了三次握手并建立好了连接。但是对于服务器来讲只有当它收到了ACK确认请求后才认为是完成了三次握手并建立好了连接。所以万一在最后的三次握手阶段的最后一个ACK请求报文丢失了怎么办呢？这个时候我们的客户端时已经认为是建立好了连接，接下来就是发数据了，但是服务器还是处于SYN_RCVD 阶段。所以一旦客户端发送数据给服务器了，这个时候服务器就会给客户端响应一个RST标志位的报文，告诉客户端我们还没建立好连接嘞，告诉客户端要求将三次握手进行重置（reset），重新来过。

【客户端状态转化】

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

CLOSE_WAIT

当我们发现服务器上有大量的close_wait状态的时候，就意味着，大概率我们的服务器写的有bug，主要是看服务器端有没有关闭close(fd)，

TIME_WAIT的意义：

1. 主动退出的一方，最后要处于time_wait状态，也就是等待一定的时长。
2. TCP 协议规定,主动关闭连接的一方要处于 TIME_ WAIT 状态,等待两个MSL(maximum segment lifetime)的时间后才能回到 CLOSED 状态.
3. 我们使用 Ctrl-C 终止了 server, 所以 server 是主动关闭连接的一方, 在TIME_WAIT 期间仍然不能再次监听同样的 server 端口;
4. MSL 在 RFC1122 中规定为两分钟,但是各操作系统的实现不同, 在 Centos7 上默认配置的值是 60s;
5. 可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看 msl 的值;
6. 规定 TIME_WAIT 的时间请读者参考 UNP 2.7 节;

可以通过这个命令查看MSL的时间

cat /proc/sys/net/ipv4/tcp_fin_timeout

为什么是 TIME_WAIT 的时间是 2MSL

1. MSL 是 TCP 报文的最大生存时间, 因此 TIME_WAIT 持续存在 2MSL 的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的);
2. 同时也是在理论上保证最后一个报文可靠到达(假设最后一个 ACK 丢失, 那么服务器会再重发一个 FIN. 这时虽然客户端的进程不在了, 但是 TCP 连接还在, 仍然可以重发 LA
   ST_ACK);

TIME_WAIT 状态引起的 bind 失败

服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求). 这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量 TIME_WAIT 连接. 由于我们的请求量很大, 就可能导致 TIME_WAIT 的连接数很多, 每个连接都会占用一个通信五元组(源 ip, 源端口, 目的 ip, 目的端口, 协议). 其中服务器的 ip 和端口和协议是固定的. 如果新来的客户端连接的 ip 和端口号和 TIME_WAIT 占用的链接重复了, 就会出现问题. 使用 setsockopt()设置 socket 描述符的 选项 SO_REUSEADDR 为 1, 表示允许创建端口号相同但 IP 地址不同的多个 socket 描述符

8. 超时重传机制

在这个密集的网络时代中，难免会有数据会到不了目标主机，在中途中被丢包了，那么TCP又是怎么确保数据不掉包呢？那就是超时重传机制。首先客户端是通过服务器返回的ACK来确定数据到达的服务器端，也就是说只要客户端收到了ACK确认应答，就认为数据就到达了服务器，反之就是数据丢包了。那么TCP是怎么判断数据丢包了，肯定是等太久了，所以判断数据丢包了。
【数据包丢失的情况】

数据包丢失情况也不一定是客户端发送的数据啊，也有可能是服务器发送的ACK确认请求包丢失了。就会出现客户端不断的进行这超时重传。

因此主机 B 会收到很多重复数据. 那么 TCP 协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉. 这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果.

那么, 如果超时的时间如何确定?

最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.

• 但是这个时间的长短, 随着网络环境的不同, 是有差异的.
• 如果超时时间设的太长, 会影响整体的重传效率;
• 如果超时时间设的太短, 有可能会频繁发送重复的包;

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

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

9. 流量控制

1. 这是一张数据传输的整体过程
   

• 接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应，从而影响了传输的效率。
• 因此 TCP 支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control)，也就是说（假设是主机A发送给主机B）主机B可以时事通告主机A它的接受能力。这就要用到我们TCP协议字段中的16位窗口大小，这个字段就是用来告诉主机A我们的接受能力是多少。
• 所谓主机B的接受能力，其实就是主机B的接收缓冲区的剩余空间的大小。
• 而主机B是通过ACK确认应答机制通告给主机A它的接收能力，可以进行捎带应答的就捎带应答，不能就行捎带应答的就直接发送新的完整报文。

流量控制的大致过程

1. 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过 ACK 端通知发送端;
2. 窗口大小字段越大, 说明网络的吞吐量越高;
3. 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通
   知给发送端;
4. 发送端接受到这个窗口之后, 就会减慢自己的发送速度;
5. 如果接收端缓冲区满了, 就会将窗口置为 0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端.
   
6. 如果接收端的窗口大小一直是0怎么办呢？主机A难道就一直发送窗口探测吗？所以这里又要介绍一个标志位PSH（它的全程叫push推送的意思），一旦主机A发送了过多的窗口探测，这个时候主机A会发送一个标志位PSH设置位1的报文给主机B，主机B接收到了这个报文后就会将接收缓冲区的数据尽快的交付给上层。

2. URL紧急指针

TCP的序号要求了数据要按序到达接收缓冲区，也就是说就像队列一样，来到接收缓冲区的数据都是从尾部进，从头部交付给上层这样按序列管理好的。但是如果突然我们的接收端突然接收到了放弃本次上传的信息了，可是我们说过了数据是按序排好的，可能这个放弃上传的信息前面还有很多的数据在排队等着上传给上层呢，但是其实前面的数据是没必要处理的，因为上层已经放弃上传的打算了。所以我们就因该让这个紧急报文优先处理。所以就有了URL紧急字段。一旦URL被设置为1了16位的紧急指针将会被设置，它代表的是紧急数据在接收缓冲区的偏移量，这样就可以优先处理紧急数据了。而紧急数据的大小只有1个字节。

在send函数参数中有个flag可以发送这个紧急数据。


用recv接收这个数据

10. 滑动窗口

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

既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。也就是说我们发送端要支持发送一个数据后没有接收的应答后可以接着发送数据的能力，再就是连续发送数据也是有上限的，不能超过接受缓冲区的大小，也就是窗口大小有一定的限制。

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

在滑动窗口机制下丢包了怎么办呢
【情况一】数据包已经抵达, ACK 被丢了

• 因为确认应答机制代表的是之前的所以数据都发送成功了
• 比如1-1000的ACK报文发送失败了但是10001-2000的ACK确认报文发送成功了，即发送了下一个是2001的报文，那就说明2001之前的报文一定是发送成功的，也就是说1-1000和1001-2000的都收到了。

【情况二】数据包就直接丢了.

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

这种机制被称为 “高速重发控制”(也叫 “快重传”).

11. 拥塞控制

• 首先为什么要有拥塞控制呢？不是已经有了流量控制吗？所以首先我们要区分流量控制和拥塞控制的区别。流量控制是站在发送方和接收方角度来看的，接收方告诉传输方它的缓冲区大小来控制传输的速率，以防止出现大量重传机制。但是我们从整体的传输效率来看，数据在网络传输的过程还是会经过很多的中间设备进行传输的，因此控制发送方的发送速率，不能只考虑率接收端的接受能力，也要考虑中间设备的转发能力。
• 虽然 TCP 有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据，即重传机制和流量控制都是依附于滑动窗的，但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题.
• 对于接收端的处理能力，可以用缓冲区的大小来衡量，那么对于中间设备的转发能力，又该如何衡量呢？TCP 引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;如果判定了网络拥塞，那么就不能立即进行重传了，因为重传也没什么用，很大几率还是会丢包的，而是要进入拥塞控制。

• 那么问题来了，我们上面讲过了滑动窗口的能力其实=接收方窗口（即接受能力，接收方的缓冲区大小），但是这个公式是没有考虑网络中的中间设备的，所以这里正确的滑动窗口能力其实=min(接收方窗口（即接受能力，接收方的缓冲区大小）， 拥塞窗口）

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

1. 发送开始的时候, 定义拥塞窗口大小为 1;
2. 每次收到一个 ACK 应答, 拥塞窗口加 1;
3. 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;

像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快. 那么这样做的好处是什么呢，我们都知道指数级前期增幅很弱，但是后期就是指数爆炸了。
因为慢启动是发送的是探测报文，一旦探测报文可以进行发和收到ACK确认应答，那么就说明网络是良好的，既然是良好的那么我们就非常希望快速的恢复通信，二指数级别的特点恰好可以做到前期探测，后期快速恢复通信。

1. 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.
2. 此处引入一个叫做慢启动的阈值
3. 当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长

1. 当 TCP 开始启动的时候, 慢启动阈值等于窗口最大值;
2. 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回 1;
3. 少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;当 TCP 通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;拥塞控制, 归根结底是 TCP 协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

12. 延迟应答

延迟应答可以一定程度的提高传输效率，如果接收数据的主机立刻返回 ACK 应答, 这时候返回的窗口可能比较小.

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

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;
那么所有的包都可以延迟应答么? 肯定也不是;

1. 数量限制: 每隔 N 个包就应答一次;
2. 时间限制: 超过最大延迟时间就应答一次;

具体的数量和超时时间, 依操作系统不同也有差异; 一般 N 取 2, 超时时间取 200ms;

13. 面向字节流

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

1. 调用 write 时, 数据会先写入发送缓冲区中;
2. 如果发送的字节数太长, 会被拆分成多个 TCP 的数据包发出;
3. 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
4. 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
5. 然后应用程序可以调用 read 从接收缓冲区拿数据;
6. 另一方面, TCP 的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

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

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

14. 粘包问题

• 首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.
• 在 TCP 的协议头中, 没有如同 UDP 一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.
• 站在传输层的角度, TCP 是一个一个报文过来的. 按照序号排好序放在缓冲区中.
• 站在应用层的角度, 看到的只是一串连续的字节数据.
• 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.

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

• 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的 Request 结构, 是固定大小的, 那么就从缓冲区从头sizeof(Request)依次读取即可;
• 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
• 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可);

思考: 对于 UDP 协议来说, 是否也存在 “粘包问题” 呢?

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

15. TCP异常情况

1. 主机重启或关机

按照程序关机，会先杀死所有的用户进程(同时也就包括TCP程序)，进程终止会释放文件描述符(相当于调用了close)，调用了close就会触发FIN，开启四次挥手的过程。和正常关闭没有什么区别。如果还没完成四次挥手，就已经关机了，对端重传了FIN若干次后，没有响应，也就放弃了

2. 程序崩溃

和主机重启一样

4. 主机掉电/网线断开

突然拔电源，主机突然掉电是来不及进行四次挥手的
【接受方掉电】
对方尝试发送数据，发现没有ACK，会尝试重传，重传几次如果还没有ACK，发送方会尝试重新建立连接，如果无法重新建立连接，就认为网络上出现了问题，就放弃了
【发送方掉电】
接受方在等待发送方发送的数据，由于发送方此时已经掉线了，等待的数据肯定是发不过来的，但是接收方无法判断当前数据包是发送方处在正常工作的情况下，但还没发，还是发送方已经出现了问题。为了解决这个问题，接收方会给发送方定期的发送一个"心跳包 “。
心跳包：接收方给发送方发送一个特殊的报文"ping”，对方返回一个特殊的报文"pong"，如果发送的ping后收到对应的pong，则认为对方是正常工作的，如果发送的ping没有收到pong则认为对方挂了

5. 保活定时器：

TCP自己也内置了一个保活定时器，会定期询问对方是否还在。如果 对方不在，也会把连接释放。
另外，应用层的某些协议，也有一些这样的检测机制。例如HTTP长连接中，也会定期检测对方的状态。例如QQ，在QQ断线之后，也会定期尝试重新连接

16. 扩展问题

TCP小结：
可靠性:

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

提高性能:

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

其他:

• 定时器(超时重传定时器, 保活定时器, TIME_WAIT 定时器等)

如何用udp实现可靠性传输

参考 TCP 的可靠性机制, 在应用层实现类似的逻辑;

• 引入序列号, 保证数据顺序;
• 引入确认应答, 确保对端收到了数据;
• 引入超时重传, 如果隔一段时间没有应答, 就重发数据;
• 引入连接管理机制，确保可靠数据传输
• 引入流量控制
• 引入拥塞控制
• …

TCP 和 UDP的对比

1. 如果需要关注可靠性传输，优先考虑TCP
2. 如果传输的单个数据报比较大(UDP报文上限64kb)，优先考虑TCP
3. 对于可靠性要求不高，但是对于性能要求很高，优先使用UDP，例如同一机房内部的主机之间通信，网络环境简单，带宽充裕，并且希望主机通信能尽可能快
4. 如果需要进行"广播",优先考虑UDP，TCP要想实现广播，需要在应用层打开多个连接的方式来实现
5. UDP用于对高速传输和实时性要求较高的通信领域，例如，早期的QQ，视频传输等

归根结底, TCP 和 UDP 都是程序员的工具, 什么时机用, 具体怎么用, 还是要根据具体的需求场景去判定.

为什么上面传输数据都是1000

到这里我们不免会有疑问，特别是在滑动窗的时候。假设滑动窗口大小是4000，为什么在传递数据的时候是一千一千的传递数据呢？而不是一股脑的直接将4000大小的数据传过去呢？
这就需要更下层的协议来解释了，在链路层规定单个数据的传输大小（MTU）不能超过1500个字节。我们可以在linux下看到这个数字，使用ifconfig命令。

具体细节我们将会在链路层里讲解。