android-notes

10 KiB

Raw Blame History

TCP 口水话

概述

TCP 是一个可靠的、面向连接的、基于字节流、全双工的协议。

面向连接的协议要求正式发送数据之前需要通过握手建立一个逻辑连接，结束通信时也是通过有序的四次挥手来断开连接。

TCP 协议是可靠的，而 IP 是一种无连接、不可靠的协议。IP 协议尽最大可能将数据报从发送者传输给接受者，但并不保证包到达的顺序会与它们被传输的顺序一致，也不保证包是否重复，甚至都不保证包是否会到达接受者。TCP 要想在 IP 的基础上构建可靠的传输层协议，必须有一个复杂的机制来保障可靠性，主要有：对每个包提供校验和、包的序列号解决了接收数据的乱序、重复问题、超时重传机制以及流量控制、拥塞控制。

TCP 是面向字节流的协议，流的含义是没有固定的报文边界，这就需要应用程序定义自己的消息分隔符，比如 HTTP 中的 \r\n。

TCP 是全双工的协议，通信的双方在任意时刻既可以是接收数据也可以是发送数据，每个方向的数据流都独立管理序列号、滑动窗口大小、MSS 等信息。

TCP 头部

TCP 头部是支撑 TCP 复杂功能的基石，它包括源端口、目标端口、序列号、确认号、头部长度、校验和以及一些 SYN、ACK 标识位等等。

下面主要说一下标识位的意思：

SYN：用于发起连接同步双方的初始序列号

ACK：确认数据包

RST：强制断开连接

FIN：通知对端已经发送完数据了，准备断开连接，后续也不会再发数据了

PSH：告知对方这些数据包收到以后应该马上交给上层应用，不能缓存起来

三次握手

三次握手的最重要的就是交换彼此的 ISN（初始序列号）。客户端会随机选择一个数字作为初始序列号。SYN 报文不携带数据，但是它占用一个序号，下次发送数据序列号要加一。之所以要消耗一个序列号是因为它需要对端确认，不占用序列号的段是不需要确认的，比如 ACK。总结来说，凡是消耗序列号的 TCP 报文段，一定需要对端确认，如果这个段没有收到确认，会一直重传直至到达指定的次数为止。

除了交换彼此的初始序列号，三次握手的另一个重要作用是交换一些辅助信息，比如最大段大小 MSS、窗口大小 Win、窗口缩放因子 WS 等。

当客户端发送 SYN 到对端，服务端收到后会回复 SYN+ACK，此时会将连接信息放入半连接队列，服务端同时会开启一个定时器，如果超时还未收到 ACK 就会进行 SYN+ACK 重传。一旦收到客户端的 ACK，服务端就开始尝试把它加入另一个全连接队列。

SYN 洪水攻击就是客户端伪造 IP 发送 SYN 包，服务端回复的 ACK+SYN 去到了一个未知的 IP 地址，势必会造成服务端大量连接处于 SYN_RCVD 状态。而服务器的半连接队列大小也是有限的，如果半连接队列满了，也会出现无法处理正常请求的情况。解决 SYN Flood 攻击的办法是 SYN Cookie 机制，它的原理其实很简单，就是在三次握手的最后阶段才分配连接资源。服务端在收到 SYN 包后不马上分配内存资源，而是根据这个 SYN 包计算出一个 Cookie 值，作为握手第二步的序列号回复 SYN+ACK，等对方回应 ACK 包是校验回复的 ACK 是否合法，如果合法握手成功，分配资源。

四次挥手

FIN 同 SYN 报文一样，不管是否携带数据，FIN 段都需要消耗一个序列号，如果 FIN 段不消耗序列号，那么在客户端收到 ACK 报文时是不知道是 Data 的确认包还是 FIN 的确认包。

在实际情况下，四次挥手进程会变成三次，即第二步和第三步合并了。在客户端发送 FIN 包之后，会进入半关闭状态，表示自己不会再给对方发送数据了，但是服务端还是可以给自己发送数据的，在这种情况下，如果不及时发送 ACK，死等服务端这边发送数据，可能会造成客户端不必要的重发 FIN 包。如果服务端确定没有什么数据需要发送给客户端，当然就可以把 FIN 和 ACK 合并成一个包发送，四次挥手的过程也就变成了三次。

同理，三次握手也可以变成四次握手，只是把第二步的 SYN+ACK 拆分开来。与 FIN 不同的是，一般情况下，SYN 包都不携带数据，收到客户端的 SYN 包以后不用等待，可以立马回复 SYN+ACK，四次握手理论上可行，但是现实中并不常见。

最后再说一下 TIME_WAIT 状态。

需要明确的是，只有主动断开的那一方才会进入 TIME_WAIT 状态，且会在那个状态持续 2 个 MSL（报文最大生存时间）。TIME_WAIT 存在的原因是什么呢？

第一个原因是：数据报文可能在发送途中延迟但最终会到达。如果客户端在发送完 FIN 包后不等待直接进入 CLOSE 状态，过一段时间相同的 IP 和端口号又建立一个新的连接，这样收到的数据包就无法知道到底是旧连接的包还是新连接的包了，造成新连接数据的混乱。如果等待时间是 2 个 MSL，已经足够让一个方向上的包最多存活 MSL 秒就被丢弃，保证了在新创建的 TCP 连接以后，老连接姗姗来迟的包已经在网络中被丢弃消逝，不会干扰新连接。

第二个原因是确保可靠实现 TCP 全双工终止连接。关闭连接的四次挥手中，最终的 ACK 是由主动关闭方发出，如果这个 ACK 丢失，对端将重发 FIN，如果主动关闭方不维持 TIME_WAIT 直接进入 CLOSED 状态，则无法重传 ACK，被动关闭方因此不能及时可靠释放。1 个 MSL 确保四次挥手中主动关闭方最后的 ACK 报文最终能够到达对端，1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文可以到达。

当然 TIME_WAIT 也带来了一些问题，比如连接表无法复用，因为处于 TIME_WAIT 的连接会存活 2MSL（60s），意味着相同的 TCP 连接四元组在一分钟之内没有办法复用。解决办法是添加 TCP 头部时间戳选项。

重传机制

滑动窗口

TCP 会把要发送的数据放入发送缓冲区，接收到的数据放入接收缓冲区，应用程序会不停的读取缓冲区的内容进行处理。流量控制做的事情就是，如果接收缓冲区已满，发送端应该停止发送数据，那发送端怎么知道接收端缓冲区是否已满呢？为了控制发送端的速率，接收端会告知客户端的自己的接收窗口（rwnd），TCP 在收到数据包回复的 ACK 包里会带上自己接收窗口的大小，客户端需要根据这个值调整自己的发送策略。

由此引入两个状态，TCP window full 与 TCP zero window。TCP Window Full 是站在发送端角度说的，表示在途字节数等于对方接收窗口的情况，此时发送端不能再发数据给对方直到发送的数据包得到 ACK。TCP zero window 是站着接收端角度来说的，是接收端接收窗口满，告知对方不能在发送数据给自己。

拥塞控制

前面介绍了 TCP 利用滑动窗口来做流量控制，流量控制这种机制确实可以防止发送端向接收端过多的发送数据，但是它只关注了发送端和接收端自身的状况，而没有考虑整个网络的通信状况。

拥塞处理主要涉及三个算法，慢启动、拥塞避免、快速重传。

为了实现上面的算法，TCP 的每个连接都有两个核心状态值，拥塞窗口（cwnd）和慢启动阈值。

拥塞窗口指的是在收到对端 ACK 之前自己还能传输的最大 MSS 段数。接收窗口（rwnd）是接收端的限制，是接收端还能接受的数据量大小；拥塞窗口（cwnd）是发送端的限制，是发送端在还未收到对端 ACK 之前还能发送的数据量大小。

拥塞控制算法本质是控制拥塞窗口的变化。

在连接建立之初，应该发多少数据才是合适的呢？其实很难，因为不知道对端的处理能力以及途径的网络状况，所以在最初时，发送的数据量很小，但随着时间的推移，拥塞窗口会慢慢的递增，这种机制被称为慢启动。cwnd 每经过一个 RTT，就会变为之前的两倍。

但是也不可能无止境的指数级增长下去，否则就失控了，当 cwnd 超过慢启动阈值时，就启动拥塞避免算法，拥塞窗口按线性增长。即没经过一个 RTT，cwnd 增加 1.

快速重传的含义是：当接收端收到一个不按序到达的数据段时，TCP 立刻发送一个 1 个重复 ACK，当发送端收到 3 个或以上重复 ACK 时，就意识到之前发的包可能丢了，于是马上进行重传，不用傻等到重传定时器超时在重传。

常见笔试面试题汇总

1.收到 IP 数据包解析以后，它怎么知道这个分组应该投递到上层的哪一个协议呢？

解析：IP 头里有一个 protocol 字段，指出在上层使用的协议，比如值为 6 表示数据交给 TCP，值为 17 表示数据交给 UDP。

2.TCP 提供了一种字节流服务，而收发双方都不保持记录的边界，应用程序应该如何提供他们自己的记录标识呢？

解析：应用程序使用自己约定的规则来表示消息的边界，比如有一些使用回车+换行（""\r\n"）。

3.TCP/IP 协议中，MSS 和 MTU 分别工作在哪一层？

解析：MSS -> 传输层，MTU -> 链路层。

4.在 MTU = 1500 字节的以太网中，TCP 报文的最大载荷为多少字节？

解析：1500（MTU）- 20（IP 头）- 20（TCP 头）= 1460

5.假设 MSL 是 60s，请问系统能够初始化一个新连接然后主动关闭的最大速率是多少？（忽略 1~1024 区间的端口）

解析：（65535-1024）/ 120

10 KiB Raw Blame History

目录

概述