【网络】TCP协议——TCP连接相关、TCP连接状态相关、TCP数据传输与控制相关、TCP数据处理和异常、基于TCP应用层协议

Linux网络

1. TCP协议

  TCP（Transmission Control Protocol，传输控制协议） 是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。

  

  

1.1 TCP连接相关

1.1.1 TCP协议段格式

  
  源/目的端口号：表示数据是从哪个进程来，到哪个进程去。

  
  序列号：32 位，标识本报文段所发送数据的第一个字节的序号。

  
  确认号：32 位，期望接收对方下一个报文段的第一个数据字节的序号。

  
  数据偏移：4 位，指出 TCP 报文段的数据起始处距离 TCP 报文段起始处有多远。

  
  保留：6 位，保留为今后使用。

  
  6位标志位：

  URG: 紧急指针是否有效

  ACK: 确认号是否有效

  PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走

  RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段

  SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段

  FIN: 通知对方, 本端要关闭了 , 我们称携带FIN标识的为结束报文段

  
  窗口大小：16位，用于流量控制，表示接收方愿意接收的字节数。

  
  校验和：16位，发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分。用于检验 TCP 报文段的完整性。

  
  紧急指针：16位，标识哪部分数据是紧急数据。

  

1.1.2 确定应答(ACK)机制

  在 TCP 通信中，接收方通过发送 ACK 确认报文来告知发送方已成功接收的数据。例如，当发送方发送了一段数据，接收方成功接收后，会返回一个 ACK 报文，其中的确认号是发送方下一个应该发送的数据的序号。这样发送方就知道哪些数据已经被接收方确认，哪些还需要重传。

  

  TCP将每个字节的数据都进行了编号，即为序列号。

  每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据，下一次你从哪里开始发。

  例如，发送方发送了序列号为 1 的 1000 字节数据，接收方成功接收后，会返回一个 ACK 报文，确认号为 1001，表示它已经成功接收了序列号为 1 到 1000 的 1000 字节数据，期望接收序列号为 1001 的下一个数据段。

  

  

1.1.3 超时重传机制

  在 TCP 通信中，当发送方发送一个数据段后，会启动一个计时器。如果在计时器超时之前，发送方没有收到接收方针对该数据段的确认（ACK），就会认为这个数据段丢失了，然后重新发送该数据段。

  主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B，如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。

  

  

  但是，主机A未收到B发来的确认应答, 也可能是因为ACK丢失了。

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

  

  

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

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

  但是这个时间的长短，随着网络环境的不同，是有差异的。

  如果超时时间设的太长，会影响整体的重传效率。

  如果超时时间设的太短，有可能会频繁发送重复的包。

  

  TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。Linux中(BSD Unix和Windows也是如此)，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。

  如果重发一次之后，仍然得不到应答，等待 2500ms 后再进行重传。如果仍然得不到应答， 等待 4500ms 进行重传。依次类推，以指数形式递增，累计到一定的重传次数, TCP认为网络或者对端主机出现异常，强制关闭连接。

  

1.2 TCP连接状态相关

  在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接。

  

  服务端状态转化：

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

  

  客户端状态转化：

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

  

  

  以下是TCP状态转换：

  较粗的虚线表示服务端的状态变化情况。

  较粗的实线表示客户端的状态变化情况。

  CLOSED是一个假想的起始点, 不是真实状态。

  

  

1.2.1 TIME_WAIT状态

  TIME_WAIT 状态是 TCP 协议中的一种连接状态。

  

  特点：

  持续时间通常为 2 倍的最大段生存期（MSL，Maximum Segment Lifetime），在大多数实现中，MSL 的值约为 30 秒到 2 分钟，因此 TIME_WAIT 状态的持续时间一般在 1 到 4 分钟。

  

  作用：

  可靠地实现 TCP 全双工连接的终止：在主动关闭连接的一方发送最后一个 ACK 后，进入 TIME_WAIT 状态。如果这个 ACK 丢失，被动关闭方会重传 FIN 报文。由于主动关闭方仍处于 TIME_WAIT 状态，能够重新发送 ACK 来完成连接的关闭。

  允许老的重复分节在网络中消逝：即使连接已经关闭，之前传输的数据可能还在网络中传输。处于 TIME_WAIT 状态可以确保这些延迟的数据在其可能对新连接造成干扰之前被丢弃。

  

  举例说明：

  假设客户端和服务器端进行通信，客户端主动关闭连接。客户端发送完最后的 ACK 后进入 TIME_WAIT 状态。如果这个 ACK 在网络中丢失，服务器端由于没有收到 ACK 会重传 FIN 报文。由于客户端还在 TIME_WAIT 状态，能够接收到重传的 FIN 报文并重新发送 ACK，从而确保连接正常关闭。

  另外，如果客户端在关闭连接后立即建立新的连接，并且新连接使用了与之前相同的源端口和目的端口，且网络中仍存在之前连接的延迟数据包。如果没有 TIME_WAIT 状态来缓冲，这些延迟数据包可能会被错误地认为是新连接的数据，从而导致数据混乱。

  

  

1.2.2 CLOSE_WAIT 状态

  CLOSE_WAIT 状态是 TCP 连接中的一种中间状态。

  当对方主动关闭连接（即对方发送了 FIN 报文），而本地还没有调用 close 函数关闭连接时，就会处于 CLOSE_WAIT 状态。

  处于 CLOSE_WAIT 状态可能会带来一些问题。例如，如果程序没有正确处理这种状态，长时间不调用 close 关闭连接，可能会导致资源泄漏，比如文件描述符没有被释放，内存占用无法回收等。

  

  以下是一个可能导致进入 CLOSE_WAIT 状态的示例场景：

  假设服务器端和客户端建立了 TCP 连接进行通信，客户端完成任务后主动关闭连接，向服务器端发送了 FIN 报文。服务器端收到 FIN 报文后，正常情况下应该处理完剩余数据，并调用 close 函数关闭连接。但如果服务器端的程序存在逻辑漏洞，没有及时调用 close 函数，那么服务器端就会一直处于 CLOSE_WAIT 状态。

  为了避免出现 CLOSE_WAIT 状态，程序在接收到对方的 FIN 报文后，应尽快完成必要的清理工作，并调用 close 函数关闭连接，以释放相关资源并使连接正常关闭。

  

1.3 TCP数据传输与控制相关

1.3.1 滑动窗口

  滑动窗口是TCP协议中的一个重要机制，用于控制、管理发送方和接收方之间的数据传输。是TCP实现流量控制和拥塞控制的基础。

  

  特点：

  动态调整：窗口大小不是固定不变的，而是根据网络状况、接收方的处理能力和缓冲区空间等因素动态调整。

  基于字节：窗口是以字节为单位进行计量和操作的，而非数据包的数量。

  

  作用：

  提高传输效率：允许发送方在等待确认的同时发送多个数据包，而不必逐个数据包进行确认，从而充分利用网络带宽，减少等待时间。

  流量控制：接收方通过通告其可用的接收窗口大小，来控制发送方的发送速率，防止接收方缓冲区溢出。

  

  工作原理示例：

  假设发送方的窗口大小为 1000 字节，初始时已发送但未确认的字节范围是 1 - 500。当接收方成功确认了 1 - 300 字节，发送方的窗口就会向右滑动 300 字节，此时可以发送 301 - 800 字节的数据。

  如果接收方的缓冲区已满，它可能通知发送方窗口大小为 0。发送方会停止发送数据，直到接收方重新通知有可用的窗口空间。

  

  优点：适应网络变化：能够根据网络的拥塞程度和接收方的处理能力自动调整数据发送量。减少开销：减少了频繁的确认和等待，降低了通信开销。

  缺点：实现复杂：需要双方精确地维护窗口状态和相关的控制信息。对内存要求较高：需要为未确认的数据保留缓冲空间。

  

1.3.2 流量控制

  接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。

  因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制(Flow Control)。

  

  流量控制特点：

  接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段，通过ACK端通知发送端。

  窗口大小字段越大，说明网络的吞吐量越高。

  接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端。

  发送端接受到这个窗口之后，就会减慢自己的发送速度。

  如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

  接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中，有一个16位窗口字段，就是存放了窗口大小信息。

  

  那么问题来了，16位数字最大表示65535，那么TCP窗口最大就是65535字节么?

  实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是 窗口字段的值左移 M 位;

  

  

1.3.3 拥塞控制

  虽然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据，但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。

  因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵，在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。

  TCP引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据此处引入一个概念程为拥塞窗口。

  

  发送开始的时候，定义拥塞窗口大小为1。

  每次收到一个ACK应答，拥塞窗口加1。

  每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为实际发送的窗口。

  

  

  像上面这样的拥塞窗口增长速度，是指数级别的。“慢启动” 只是指初使时慢，但是增长速度非常快。

  为了不增长的那么快，因此不能使拥塞窗口单纯的加倍。

  此处引入一个叫做慢启动的阈值。

  当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长。

  

  

  当TCP开始启动的时候，慢启动阈值等于窗口最大值。

  在每次超时重发的时候，慢启动阈值会变成原来的一半, 同时拥塞窗口置回1。

  少量的丢包，我们仅仅是触发超时重传，大量的丢包，我们就认为网络拥塞；当TCP通信开始后，网络吞吐量会逐渐上升。随着网络发生拥堵，吞吐量会立刻下降。

  拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

  

1.3.4 延迟应答

  其核心思想是：接收方在收到数据后，不立即发送确认应答（ACK），而是等待一段时间再回复。

  延迟应答带来的好处主要有以下几点：

  增加窗口大小：在等待的这段时间内，接收方可能有更多的数据被处理，从而使得接收缓冲区腾出更多空间。这样在回复 ACK 时，可以告知发送方一个更大的接收窗口，允许发送方发送更多的数据，提高了传输效率。

  减少应答次数：如果每次收到数据都立即应答，可能会导致频繁的小数据包交互。通过适当延迟应答，可以将多个数据的确认合并在一个应答中，减少网络中的数据包数量。

  

  一定要记得，窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

  那么所有的包都可以延迟应答么? 肯定也不是：

  数量限制：每隔N个包就应答一次。

  时间限制：超过最大延迟时间就应答一次。

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

  

  

1.3.5 捎带应答

  捎带应答是 TCP 协议中一种提高通信效率的机制。

  当一个主机在向另一个主机发送数据的同时，正好有对对方数据的确认信息要返回，就可以把确认信息搭载在正在发送的数据上，一起发送给对方，而不必单独发送一个确认数据包。

  例如，A 向 B 发送数据，此时 B 正好要向 A 发送数据，并且 B 已经成功接收了 A 之前发送的数据，那么 B 就可以在要发送给 A 的数据包中捎带上对 A 之前数据的确认信息。

  

  这样做的好处是减少了网络中数据包的数量，节省了网络资源，提高了数据传输的效率。

  假设在一个客户端与服务器进行频繁交互的场景中，客户端向服务器发送请求，服务器处理请求后返回响应，同时确认收到了客户端之前的某些数据。如果每次确认都单独发送一个数据包，会增加网络开销。而通过捎带应答，服务器可以在返回响应时一并完成确认，减少了不必要的数据包传输。

  

  

1.3.6 面向字节流

  TCP 并不关心应用层交给它的数据的具体含义和结构，它只是把这些数据看作一连串无结构的字节序列进行传输。

  具体来说，TCP 把应用层交下来的数据仅仅看成是一连串的字节流，它不保留应用层交下来数据的边界。 例如，应用层程序一次性向 TCP 写入了 100 个字节，然后又写入了 200 个字节。TCP 可能并不会把这两次写入的数据分别发送，它可能会根据当时的网络状况和自身的策略，将这 300 个字节拆分成几个部分进行发送，也可能会把它们和后续写入的数据一起组合发送。

  

  在接收端，TCP 接收到的数据也只是一系列的字节，接收方的应用程序需要根据自己的需求和数据的特点来确定数据的边界和含义。

  举例来说，假设一个即时通讯应用通过 TCP 发送了两条消息“Hello”和“World”。在传输过程中，TCP 可能将它们作为一个连续的字节流发送，比如“HelloWorld”。接收方的应用程序需要根据事先约定的规则（比如特定的分隔符或者消息长度）来将这个字节流解析为两条独立的消息。

  

1.4 TCP数据处理和异常

1.4.1 粘包问题

  粘包问题是在基于 TCP 协议进行数据传输时可能出现的一种现象。

  由于 TCP 是面向字节流的协议，且其具有优化机制（如 Nagle 算法），数据在传输过程中可能不会按照发送方发送的边界进行接收，导致多个数据包粘连在一起。

  例如，发送方先后发送了两个小数据包，一个包含“Hello”，另一个包含“World”。在接收方，可能会一次性接收到“HelloWorld”，而不是分别接收到两个独立的数据包。

  

  粘包问题产生的原因主要有以下几点：

  应用程序写入数据的字节大小较小，TCP 为了提高传输效率，会将多次写入的数据合并发送。

  接收方的缓冲区大小和接收时机，可能导致多个数据包一次性被读取。

  

  那么如何避免粘包问题呢? 就是明确两个包之间的边界。常见的方法有：

  定长消息：规定每个数据包的固定长度，接收方按照固定长度读取。

  特殊分隔符：在数据包之间添加特定的分隔符，接收方根据分隔符来拆分数据包。

  消息头+消息体：在数据包开头添加描述消息长度等信息的消息头，接收方根据消息头来解析消息体。

  假设一个聊天应用中，客户端发送了多条短消息，如果不处理粘包问题，服务端可能会将多条消息混淆。通过添加消息头指示消息长度，服务端就能准确地拆分和处理每条消息。

  

1.4.1 TCP异常情况

  TCP异常情况：

  进程终止：进程终止会释放文件描述符，仍然可以发送FIN。和正常关闭没有什么区别。

  机器重启：和进程终止的情况相同。

  机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。即使没有写入操作，TCP会定期询问对方是否还在自己也内置了一个保活定时器，如果对方不在，也会把连接释放。

  另外，应用层的某些协议，也有一些这样的检测机制。例如HTTP长连接中，也会定期检测对方的状态。例如QQ，在QQ断线之后，也会定期尝试重新连接。

  

  以上TCP机制是按照功能分类的，也可以按照实现的性质分类：

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

  提高性能: 滑动窗口、快速重传、延迟应答、捎带应答。

  

1.5 基于TCP应用层协议

  HTTP、HTTPS、SSH、Telnet、FTP、SMTP、我们自己写TCP程序时自定义的应用层协议。