TCP 协议原理

一、TCP 原理

  TCP 对数据传输提供的管控机制，主要体现在两个方面：安全和效率。这些机和线程的设计原则是：保证数据安全的前提下，尽可能提高传输效率。

1.确认应答机制（可靠机制）

  发送方发送给接收方数据之后，接收方就会回应一个应答报文。如果发送方收到这个应答报文，那么就认为接收方已经收到了数据。

  由于网络上的传输，充满不确定性，因此不能通过收到数据的顺序来确定逻辑。因此就需要给应答进行编号。TCP 的序号和确认序号，是以字节为单位进行编号的。

  针对每个字节进行编号，依次进行累加。（TCP 序号的起始不一定是从1开始的）

1. 工作过程：
   

  解释：第一个请求,A 给 B 发送了1000个字节的数据，序号就是1~1000（假设从1开始编号），这就相当于是发送了一个数据报，这个数据报的序号是1，长度为1000；确认应答数据报，里面的确认序号是1001，意思就是1001之前的数据，B 已经收到了。也可以理解成，B 在向 A 索要1001开始的数据。序号1001~2000的数据传输和应答原理与上面的一致。

  TCP 的核心是可靠性，可靠性的核心是确认应答。

2. 其它应用：生产消费者模型

  消息队列负责保存数据，但是消息对列的存储空间不是无限的。所以存的数据就需要定期淘汰。淘汰的原则就是：如果一个数据没有被消费过，那么就不能被轻易的淘汰！

  如何判定这个数据是否被消费过？主要就是通过确认应答机制。

2.超时重传机制（可靠机制）

  确认应答机制是数据传输比较顺利的情况。但是实际中，数据传输过程中可能会出现丢包的情况。一旦发生数据丢包，就要进入超时传送的机制。

1. 出现数据丢包的原因：

   1. 主机 A 发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B；
   2. 主机 A 未收到B 发来的确认应答

   

2. 解决方法：如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。因此主机 B 会收到很多重复的数据，TCP协议通过数据的序列号就可以达到去重的效果。

3. 超时的时间确定：动态计算这个最大超时时间。

     Linux 中 以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。当累积到一定的重传次数，仍然得不到应答，TCP 就会认为网络对端主机出现异常，强制关闭连接。

3.连接管理机制（可靠机制）

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

1. “三次握手”的过程
   

    1. 客户端TCP 向 服务器端TCP 发送 SYN同步报文段（请求），请求建立连接。

    2. 服务器端TCP 接收到同步报文段之后，就向客户端TCP 发送 SYN应答报文（这个报文的 SYN 和 ACK 都为1）,表示客户端的 SYN 报文已被服务端成功接收了。

    3. 当客户端收到确认报文之后，继续会向服务器端TCP 返送确认报文段（ACK），确认连接。

    本应该是“四次握手”，但是中间的 SYN + ACK 可以合在一起（两个操作是同时发生的）。当客户端的 SYN 到达服务器端时，服务器端就会第一时间进行应答 ACK，同时也会第一时间发起 SYN，这两件事情同时触发，故此合成一次传输。

2. 三次握手的目的:

   1. 防止重复连接

       在网络情况比较差或者比较复杂的情况下,发送方可能会连续多次发送建立连接的请求,如果 TCP 只有两次,那么接收方只能选择接收请求或者拒绝请求,但是并不能分辨是正常的请求还是过期请求,如果是过期的请求就会造成错误的连接。

       如果 TCP 是三次握手的话，那么客户端在收到服务器端发送的（SYN + ACK）确认报文之后，就会判断当前连接是否为历史连接，如果是历史连接，就会发送终止报文给服务器终止连接；如果是正常连接，就会发送确认报文，进而建立连接。

   1. 同步初始化序列化

       TCP 为了保证在不稳定的网络环境中构建一个稳定的数据连接，需要一个“序列号”字段来保证自己的稳定性，而这个序列号的作用就是防止数据包重复发送，以及有效的解决数据包接收时顺序颠倒的问题。

       在 TCP 三次握手中的客户端发送给服务器的确认报文之后，就会得到一个可靠的初始化序列号，如果是二次握手，无法进行序列号的确认，进而也就无法得到可靠的序列号了，故此 TCP 连接至少需要三次握手。

3. “四次挥手的过程”

    中断连接端可以是客户端，也可以是服务器端

    1. 第一次挥手：客户端发送一个FIN=M，用来关闭客户端到服务器端的数据传送，客户端进入FIN_WAIT_1状态。意思是说"我客户端没有数据要发给你了"，但是如果你服务器端还有数据没有发送完成，则不必急着关闭连接，可以继续发送数据

    2. 第二次挥手：服务器端收到FIN后，先发送ack=M+1，告诉客户端，你的请求我收到了，但是我还没准备好，请继续你等我的消息。这个时候客户端就进入FIN_WAIT_2 状态，继续等待服务器端的FIN报文。

    3. 第三次挥手：当服务器端确定数据已发送完成，则向客户端发送FIN=N报文，告诉客户端，好了，我这边数据发完了，准备好关闭连接了。服务器端进入LAST_ACK状态。

    4. 第四次挥手：客户端收到FIN=N报文后，就知道可以关闭连接了，但是他还是不相信网络，怕服务器端不知道要关闭，所以发送ack=N+1后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。服务器端收到ACK后，就知道可以断开连接了。客户端等待了2MSL后依然没有收到回复，则证明服务器端已正常关闭，那好，我客户端也可以关闭连接了。最终完成了四次握手。

2. “四次挥手补充”

   1. ACK 和 FIN 为什么不能合并发送？

        服务器收到客户端的 FIN 就会立即触发 ACK，这个操作是由内核完成的。
        服务器发送的 FIN 是由代码控制的，代码中出现了 socket.colse()这样的操作之后，才会触发 FIN。

   2. CLOSE_WAIT:服务器收到 FIN 之后进入的状态，等待用户代码调用 close，来发送 FIN。

   3. TIME_WAIT：表示客户端收到了 FIN 进入了 TIME_WAIT，这个状态存在的意义主要就是为了处理最后一个 ACK 丢包。即使进程已经退出了，TIME_WAIT 状态仍然会存在（TCP连接不会立即销毁），此状态会等待一定的时间，如果一定的时间没有重传的 FIN 过来，才会真正的销毁。

4.滑动窗口（效率机制）

1. 滑动窗口的工作机理

  TCP 不仅仅是为了保证可靠性，还要尽可能提高传输效率。

  这种一发一收的过程中，发送方要花费很多时间来等待，性能较差，尤其是在数据往返时间较长的时候。

• 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。窗口越大，效率就越高。图中的窗口大小为4000个字节（四个段）。

• 发送前四个段的时候，不需要等待任何的ACK，直接发送。

• 收到第一个ACK之后，滑动窗口向后移动，继续发送第五个段的数据；以此类推；

• 操作系统为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有那些数据没有应答；只有应答过的数据，才能从缓冲区删掉。

  

    当前窗口的范围是1001_{5000，也就意味着发送方现在同时发送了1001}2000、2001_3000、30014000、4001~5000这四段数据，同时也在等待这四段数据的 ACK；
    假设2001这个 ACK 先到，发送方就知道1001_{2000这段数据已经被对方收到，也就不用再等待这段数据，接下来就会立即再发一个5001}6000的数据，仍然保证窗口大小是四段数据，保证当前同时等待的是四段数据的 ACK。（并不是把四份 ACK 都等到，才发送新数据，而是随着ACK 的收到，就继续往后发送）
    后发先至的情况？确认序号表示, 从该序号之前，前面的数据都已以收到，例如：如果收到了3001这个 ACK，就表示1001_2000和20013000都被对方收到，此时2001这个 ACK 收或者不收，已经不是关键。

2. 滑动窗口丢包

   1. 情况一： 数据报已经抵达，ACK 丢包

      这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认；

    2. 情况二： 数据包直接丢失

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

  这种机制被称为 “高速重发控制”（也叫 “快重传”）。

5.流量控制（可靠机制）

  流量控制是对滑动窗口的进一步补充。窗口的大小决定了传输的速率，窗口越大，效率越高；反之，效率就越低。

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

  但是如何决定窗口的大小呢？此处的流量控制就是基于接收方的处理能力来限制窗口的大小。（接收缓冲区空余空间的大小）

流量控制过程:

• 接收者将自己可以接收的缓冲区大小放入 TCP 首部中的"窗口大小"字段,通过 ACK 通知发送端。比如，当前的接收缓冲区大小是4000，就通过 ACK告诉发送端窗口大小为4000.
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；例如：如果接收端接收到1~1000的数据，缓冲区就用了1000，缓冲区大小剩余3000，然后接收端就返回 ACK 告诉发送端缓冲区大小剩余3000。
• 发送方接收到缓冲区大小为3000这个信息，就会减缓发送数据的速率，再次发送数据会以3000作为窗口大小进行发送。
• 如果接收端缓冲区已满，就会将窗口设置为0；这时发送端不再发送数据，但是会定期发送一个窗口探测数据段，这个数据端触发接收端的 ACK，通过ACK 发送端就可以知道当前窗口的大小了。

  接收端如何把窗口大小告诉发送端呢？在TCP首部中，有一个16位窗口字段，就是存放了窗口大小信息；

  16位数字最大表示65535，那么TCP窗口最大就是65535字节么？实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位；

6.拥塞机制（可靠机制）

  虽然 TCP 的滑动窗口能够高效可靠的发送大量的数据。但是在开始不清楚网络状况的情况下，就贸然发送大量的数据，可能会引发严重的问题。

  鉴于以上问题，TCP 引入了慢启动机制，先发送少量的数据，摸清当前的网络情况，如果数据没有发生丢包，就说明网络通畅，可以加大发送速率；如果数据出现丢包，就说明网络拥堵，就降低发送速率。（通过这样的方式决定发送窗口的大小）

拥堵控制过程：

• 此处引入一个概念：拥塞窗口。
• 发送开始的时候，定义拥塞窗口为1。
• 每次收到一个 ACK应答，拥塞窗口加1。
• 每次发送数据包的时候，将拥塞窗口和接收端主机犯反馈的窗口作比较，取较小的值作为实际发送的窗口。（实际窗口=min(流量控制的窗口，拥塞控制的窗口)）

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

• 为了不增长的那么快，因此不能使拥塞窗口单纯的加倍。
• 此处引入一个叫做慢启动的阈值
• 当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长
• 当TCP开始启动的时候，慢启动阈值等于窗口最大值
• 在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置回1

  少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞；

  当TCP通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降；

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

7.延迟应答（效率机制）

  在保证可靠性的基础上，使得窗口尽可能再大一些。

  如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。

• 假设接收端缓冲区为1M，一次收到了500K的数据；如果立刻应答，返回的窗口就是500K；
• 实际上可能处理端的处理速度很快，10ms之内数据就从缓冲区消费掉了。此时接收端处理还远没有达到自己的极限，即使窗口再大一点，也可以处理掉；
• 如果接收端稍微等一会再应答，比如等待200ms再应答，那么此时返回的窗口大小就是1M了。

  所有的包都可以做延时应答吗？肯定不是。

    1. 数量限制：每隔N个包就应答一次；

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

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

8.捎带应答（效率机制）

  在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说了 “How are you”，服务器也会给客户端回一个 “Fine, thank you”；

  那么这个时候ACK就可以搭顺风车，和服务器回应的 “Fine，thank you” 一起回给客户端