计算机网路系列（三）：TCP篇

1、TCP是什么

• 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息。

• 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端;

• 字节流：消息是「没有边界」的，所以无论我们消息有多大都可以进行传输。并且消息是「有序的」，当 「前一个」消息没有收到的时候，即使它先收到了后面的字节，那么也不能扔给应用层去处理，同时对「重复」的报文会自动丢弃。

2、TCP格式

• 源端口号 ：16 位，数据发起者的端口号。

• 目标端口号：16位，数据接收者的端口号。

• 序列号：32 位，在建立连接时由计算机生成的随机数作为其初始值，然后为数据流中的每一个字节都编上一个序号，序列号字段的值则指的是本报文段所发送的数据的第一个字节的序号。每发送一次数据，就 「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。

• 确认应答号：32 位，「期望」收到对方的下一个报文段的数据的第一个字节的序号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决不丢包的问题。

• 数据偏移/首部长度：4 位，指 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远，单位是 32 位字(以 4 字节为计算单位)。

• 保留位：6 位，保留为今后使用，目前应置为 0。

• 控制位：6 位，分别对应六个字段。
• URG：该位为 1 时，告诉系统此报文段中有紧急数据，应尽快传送。
• ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置为 1 。只有当 ACK=1 时确认应答号字段才有效；当 ACK=0 时，确认应答号无效。
• PSH：该值为 1 时，应尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。
• RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
• SYN：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
• FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

• 窗口大小：16 位，服务器向客户端返回的滑动窗口大小，表示服务器当前可以接受的数据量大小，用于流量控制。

• 检验和：16 位，用于检测发送过程中是否出现错误。

• 紧急指针：16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。

• 选项：长度可变，TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节.” [MSS(Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度，数据字段加上 TCP 首部才等于整个的 TCP 报文段]。

• 填充：这是为了使整个首部长度是 4 字节的整数倍。

TCP 四元组可以唯一的确定一个连接，四元组包括如下：

• 源地址

• 源端口

• 目的地址

• 目的端口

其中源地址和目的地址的字段（32位）是在 IP 头部中，作用是通过 IP 协议发送报文给对方主机；源端口和目的端口的字段（16位）是在 TCP 头部中，作用是告诉 TCP 协议应该把报文发给哪个进程。所以 TCP 协议只包含端口号，不包含 IP 地址。

2.1 MTU和MSS

• MTU：一个网络包的最大⻓度，以太网中一般为 1500 字节;

• MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大⻓度;

2.2 TCP和UDP的区别

• 目标和源端口：主要是告诉 UDP 协议应该把报文发给哪个进程。

• 包⻓度：该字段保存了 UDP 首部的⻓度跟数据的⻓度之和。

• 校验和：校验和是为了提供可靠的 UDP 首部和数据而设计。

TCP 和 UDP 对比：

1. 连接
• TCP 是面向连接的传输层协议，传输数据前先要建立连接。
• UDP 是不需要连接，即刻传输数据。

2. 服务对象
• TCP 是一对一的两点服务，即一条连接只有两个端点。
• UDP 支持一对一、一对多、多对多的交互通信

3. 可靠性
• TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。
• UDP 是尽最大努力交付，不保证可靠交付数据。

4. 拥塞控制、流量控制
• TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。
• UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。

5. 首部开销
• TCP 首部⻓度较⻓，会有一定的开销，首部在没有使用「选项」字段时是20个字节，如果使用了「选项」字段则会变⻓的。
• UDP 首部只有 8 个字节，并且是固定不变的，开销较小。

6. 传输方式
• TCP 是流式传输，没有边界，但保证顺序和可靠。
• UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

7. 分片不同
• TCP 的数据大小如果大于 MSS 大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
• UDP 的数据大小如果大于 MTU 大小，则会在 IP 层进行分片，目标主机收到后，在 IP 层组装完数据，接着再传给传输层，但是如果中途丢了一个分片，在实现可靠传输的 UDP 时则就需要重传所有的数据包，这样 传输效率非常差，所以通常 UDP 的报文应该小于 MTU。

2.3 TCP为什么是可靠的协议

• 三次握手和四次挥手保证连接是可靠的。

• 基于序列号的确认应答机制，保证数据包的有序性。

• 对于没有收到数据包，提供重传机制。

• 为了协调发送方的发送包和接收方的接收包的速度，提供流量控制机制。

• 为了维护网络环境的稳定，提供拥塞控制机制。

3、三次握手

• 一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。

• 客户端会随机初始化序号( client_isn )，将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志 位置为 1 ，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不 包含应用层数据，之后客户端处于 SYN-SENT 状态。

• 服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号( server_isn )，将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1 , 接着把 SYN 和 ACK 标志位置为 1 。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。

• 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位 置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客 户到服务器的数据，之后客户端处于 ESTABLISHED 状态。

• 服务器收到客户端的应答报文后，也进入 ESTABLISHED 状态。

3.1 为什么握手是三次，不是两次，四次？

• 如果是历史连接(序列号过期或超时)，则第三次握手发送的报文是 RST 报文，以此中止历史连接。

• 如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接。

为什么不是两次？

为什么不是四次？

3.2 半连接队列和全连接队列

• 半连接队列，也称 SYN 队列

• 全连接队列，也称 accepet 队列

3.3 SYN攻击

• 当 「 SYN 队列」满之后，后续服务器收到 SYN 包，不进入「 SYN 队列」

• 计算出一个 cookie 值，再以 SYN + ACK 中的「序列号」返回客户端，

• 服务端接收到客户端的应答报文时，服务器会检查这个 ACK 包的合法性。如果合法，直接放入到「 Accept 队列」。

• 最后应用通过调用 accpet() socket 接口，从「 Accept 队列」取出的连接。

3.4 TCP的保活机制

• tcp_keepalive_time=7200：表示保活时间是 7200 秒(2小时)，也就 2 小时内如果没有任何连接相关的活动，则会启动保活机制

• tcp_keepalive_intvl=75：表示每次检测间隔 75 秒;

• tcp_keepalive_probes=9：表示检测 9 次无响应，认为对方是不可达的，从而中断本次的连接。

4、四次挥手

• 客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。

• 服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。

• 客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。

• 等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。

• 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态。

• 服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭。

• 客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。

为什么挥手是四次？

• 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。

• 服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

为什么需要TIME_WAIT？

• 防止旧的数据包被接收。如果 TIME-WAIT 过短或者没有，假如网络拥堵，关闭本次连接再重新打开连接之后，旧连接的数据包才到达，就会造成数据混乱。而足够长的 TIME-WAIT 足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。

• 防止数据包丢失导致被动关闭方不能正常关闭。四次挥手的最后一个 ACK 报文如果在网络中被丢失了，此时如果客户端 TIME-WAIT 过短或没有，则就直接进入了 CLOSED 状态了，那么服务端则会一直处在 LASE_ACK 状态。后面客户端和服务端就不能正常建立连接。而足够长的 TIME-WAIT 可以保证服务端没有收到四次挥手的最后一个 ACK 报文时，则会重发 FIN 关闭连接报文并等待新的 ACK 报文，从而帮助双方都正确关闭。

为什么TIME_WAIT的时间是2MSL？

TIME_WAIT过多的危害和优化

• 复用处于 TIME_WAIT 的 socket 为新的连接所用。客户端在调用 connect() 函数时，内核会随机找一个 time_wait 状态超过 1 秒的连接给新的连接复用。使用 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_timestamps 参数。

重传机制

• 超时重传

• 快速重传

• 选择重传

超时重传

• RTT (Round-Trip Time)：往返时间，也就是从数据发出去到接收响应所需的时间。

• RTO (Retransmission Timeout)：超时重传时间。

• 当超时时间 RTO 较大时，􏰁发就慢，丢了老半天才重发，没有效率，性能差;

• 当超时时间 RTO 较小时，会导致可能并没有丢就重发，于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。

快速重传

选择重传

SACK机制

D-SACK机制

• 让发送方知道，是发送的包丢了，还是返回的ACK包丢了；

• 网络上是否出现了包失序；

• 数据包是否被网络上的路由器复制并转发了

• 是不是自己的timeout太小了，导致重传

1. 第一个段将包含重复收到的报文段的序号

2. 跟在D-SACK之后的SACK将按照SACK的方式工作

3. 如果有多个被重复接收的报文段，则D-SACK只包含其中第一个

1. 如果SACK的第一个段的范围被ACK所覆盖，那么就是D-SACK

2. 如果SACK的第一个段的范围被SACK的第二个段覆盖，那么就是D-SACK

流量控制

滑动窗口

滑动窗口的实现

发送方的滑动窗口

• SND.WND：表示发送窗口的大小(大小是由接收方指定的);

• SND.UNA：是一个绝对指针，它指向的是已发送但未收到确认的第一个字节的序列号，也就是 #2 的第一个字节。

• SND.NXT：也是一个绝对指针，它指向未发送但可发送范围的第一个字节的序列号，也就是 #3 的第一个 字节。

• 指向 #4 的第一个字节是个相对指针，它需要 SND.UNA 指针加上 SND.WND 大小的偏移􏰀，就可以指向 #4 的第一个字节了。

接收方的滑动窗口

• RCV.WND：表示接收窗口的大小，它会通告给发送方。

• RCV.NXT：是一个指针，它指向期望从发送方发送来的下一个数据字节的序列号，也就是 #3 的第一个字 节。

• 指向 #4 的第一个字节是个相对指针，它需要 RCV.NXT 指针加上 RCV.WND 大小的偏移􏰀，就可以指向 #4 的第一个字节了。

流量控制的实现

• 客户端是接收方，服务端是发送方

• 假设接收窗口和发送窗口相同，都为 200，整个传输过程中都保持相同的窗口大小，不受外界影响

1. 客户端向服务端发送请求数据报文。这里要说明下，本次例子是把服务端作为发送方，所以没有画出服务端 的接收窗口。

2. 服务端收到请求报文后，发送确认报文和 80 字节的数据，于是可用窗口 Usable 减少为 120 字节，同时 SND.NXT 指针也向右偏移 80 字节后，指向 321，这意味着下次发送数据的时候，序列号是 321。

3. 客户端收到 80 字节数据后，于是接收窗口往右移动 80 字节， RCV.NXT 也就指向 321，这意味着客户端期 望的下一个报文的序列号是 321，接着发送确认报文给服务端。

4. 服务端再次发送了 120 字节数据，于是可用窗口耗尽为 0，服务端无再继续发送数据。

5. 客户端收到 120 字节的数据后，于是接收窗口往右移动 120 字节， RCV.NXT 也就指向 441，接着发送确认报文给服务端。

6. 服务端收到对 80 字节数据的确认报文后， SND.UNA 指针往右偏移后指向 321，于是可用窗口 Usable 增大到 80。

7. 服务端收到对 120 字节数据的确认报文后， SND.UNA 指针往右偏移后指向 441，于是可用窗口 Usable 增大到 200。

8. 服务端可以继续发送了，于是发送了 160 字节的数据后， SND.NXT 指向 601，于是可用窗口 Usable 减少到 40。

9. 客户端收到 160 字节后，接收窗口往右移动了 160 字节， RCV.NXT 也就是指向了 601，接着发送确认报文给服务端。

10. 服务端收到对 160 字节数据的确认报文后，发送窗口往右移动了 160 字节，于是 SND.UNA 指针偏移了 160 后指向 601，可用窗口 Usable 也就增大至了 200。

零窗口和窗口探测

• 发送方一直等待非 0 窗口通知。

• 接收方一直等待发送方发送数据。

• 如果接收窗口仍然为 0，那么收到这个报文的一方就会重新启动持续计时器。

• 如果接收窗口不是 0，那么死锁的局面就可以被打破了。

延迟确认和Nagle算法

• 对于发送方来说可以使用 Nagle算法

• 对于接收方来说可以使用 延迟确认。

Nagle算法

• 没有已发送未确认报文时，立刻发送数据。

• 存在未确认报文时，直到「收到所有未确认报文的ACK报文」或「数据⻓度达到 MSS 大小」时，再发送数据。

• 一开始由于没有已发送未确认的报文，所以就立刻发了 H 字符。

• 接着，在还没收到对 H 字符的确认报文时，发送方就一直在囤积数据，直到收到了确认报文后，此时没有已发送未确认的报文，于是就把囤积后的 ELL 字符一起发给了接收方。

• 待收到对 ELL 字符的确认报文后，于是把最后一个 O 字符发送了出去。

延迟确认

• 当有响应数据要发送时，ACK 会随着响应数据一起立刻发送给对方。

• 当没有响应数据要发送时，ACK 将会延迟一段时间，以等待是否有响应数据可以一起发送

• 如果在延迟等待发送 ACK 期间，对方的第二个数据报文又到达了，这时就会立刻发送 ACK

• 发送方先发出一个小报文，接收方收到后，由于延迟确认机制，自己又没有要发送的数据，只能干等着发送方的下一个报文到达;

• 而发送方由于 Nagle 算法机制，在未收到第一个报文的确认前，是不会发送后续的数据。所以接收方只能等待最大时间 200 ms 后，才回 ACK 报文，发送方收到第一个报文的确认报文后，也才可以发送后续的数据。

拥塞控制

• 只要网络中没有出现拥塞， cwnd 就会增大。

• 但网络中出现了拥塞， cwnd 就减少。

• 慢启动（Slow Start）

• 拥塞避免（Congestion Avoidance）

• 快速重传（Fast Retransmit）

慢启动

• 当 cwnd < ssthresh 时，使用「慢启动算法」。

• 当 cwnd >= ssthresh 时，就会使用「拥塞避免算法」。

• 当收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个

• 当收到 2 个的 ACK 确认应答后， cwnd 增加 2，于是就可以比之前多发2 个，所以这一次能够发送 4 个

• 当这 4 个的 ACK 确认到来的时候，每个确认 cwnd 增加 1， 4 个确认 cwnd 增加 4，于是就可以比之前多发 4 个，所以这一次能够发送 8 个。

拥塞避免

• 因为 ssthresh 为 8，当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9个 MSS 大小的数据，变成了线性增⻓。

快速重传

• 超时重传

• 快速重传

超时重传对应的拥塞控制算法

• ssthresh = cwnd/2。

• cwnd 重置为 1。

• 进入慢启动算法。

快速重传对应的拥塞发生算法

• ssthresh = cwnd/2。

• cwnd = ssthresh + 3(3 的意思是确认有 3 个数据包被收到了)。

• 进入快速恢复算法。

快速恢复

• 重传丢失的数据包。

• 如果再收到重复的 ACK，那么 cwnd 增加 1。

• 如果收到新数据的 ACK 后，把 cwnd 设置为 ssthresh 的值，然后再次进入拥塞避免状态。原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的拥塞避免状态了。

拥塞避免算法过程

1. 当新建连接时，cwnd初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加1个MSS大小。这样cwnd的值就随着网络往返时间(Round Trip Time,RTT)呈指数级增长。

2. 当cwnd超过慢启动门限(ssthresh)后，慢启动过程结束，进入拥塞避免算法。当窗口中所有的报文段都被确认时，cwnd的大小加1。cwnd的值就随着RTT开始线性增加。

3. 当检测到拥塞状态（判断拥塞的依据是TCP对每一个报文段都有一个定时器，称为重传定时器(RTO)，当RTO超时且还没有得到ack报文，或者连续三次收到相同的ack报文，就判断出现了拥塞情况。），进入快读重传阶段，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段，进入快速恢复阶段。

4. 再收到重复的ACK时，拥塞窗口增加1。当收到新的数据包的ACK时，把cwnd设置为第3步中的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。

常见问题

解决time_wait过多的问题

解决CLOSE_WAIT过多的问题

泛洪攻击