【网络】TCP协议

TCP协议

TCP协议段格式

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

连接管理

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

详情戳：TCP三次握手四次挥手

“流”通信

UDP协议是IP协议在传输层的“傀儡”，用来实现数据包形式的通信。而TCP协议则实现了“流”形式的通信。

TCP协议是传输层协议，实现的是端口到端口(port)的通信。我们知道，计算机数据的本质是有序的 0/1 序列(如果以byte为单位，就叫做文本流)，计算机的功能就是储存和处理文本流。CPU + memory + 存储设备实现了文本流在同一台计算机内部的加工处理。通过一些IO，比如屏幕和键盘，文本流实现了人机交互。而进一步，如果网络通信可在不同计算机之间进行文本流的交互，那么我们就和整个计算机系统的数据处理方式实现了对接。

按序到达

IP协议和UDP协议采用的是数据包的方式传送，后发出的数据包可能早到，我们并不能保证数据到达的次序。TCP协议确保了数据到达的顺序与文本流顺序相符。当计算机从TCP协议的接口读取数据时，这些数据已经是排列好顺序的“流”了。

比如我们有一个大文件要从本地主机发送到远程主机，如果是按照TCP“流”接收到的话，我们可以一边接收，一边将文本流存入文件系统。这样，等到“流”接收完了，硬盘写入操作也已经完成。如果采取UDP的传输方式，我们需要等到所有的数据到达后，进行排序，才能组装成大的文件。这种情况下，我们不得不使用大量的计算机资源来存储已经到达的数据，直到所有数据都达到了，才能开始处理。

“流”的要点是次序(order)，然而实现这一点并不简单。TCP协议是基于IP协议的，所以最终数据传送还是以IP数据包为单位进行的。如果一个文本流很长的话，我们不可能将整个文本流放入到一个IP数据包中，那样有可能会超过MTU。

所以，TCP协议封装到IP包的不是整个文本流，而是TCP协议所规定的片段(segment)。与之前的一个IP或者UDP数据包类似，一个TCP片段同样分为头部(header)和数据(payload)两部分 (“片段”这个名字更多是起提醒作用：嘿，这里并不是完整的文本流)。整个文本流按照次序被分成小段，而每一段被放入TCP片段的数据部分。一个TCP片段封装成的IP包不超过整个IP接力路径上的最小MTU，从而避免令人痛苦的碎片化(fragmentation)。

(给文本流分段是在发送主机完成的，而碎片化是在网络中的路由器完成的。路由器要处理许多路的通信，所以相当繁忙。文本流提前在发送主机分好段，可以避免在路由器上执行碎片化，可大大减小网络负担)

TCP片段的头部(header)会存有该片段的序号(sequence number)。这样，接收的计算机就可以知道接收到的片段在原文本流中的顺序了，也可以知道自己下一步需要接收哪个片段以形成流。比如已经接收到了片段1，片段2，片段3，那么接收主机就开始期待片段4。如果接收到不符合顺序的数据包(比如片段8)，接收方的TCP模块可以拒绝接收，从而保证呈现给接收主机的信息是符合次序的“流”。

确认应答（ACK）机制

片段编号这个初步的想法并不能解决我们所有的问题。IP协议是不可靠的，所以IP数据包可能在传输过程中发生错误或者丢失。而IP传输是"Best Effort" 式的，如果发生异常情况，我们的IP数据包就会被轻易的丢弃掉。另一方面，如果乱序(out-of-order)片段到达，根据我们上面说的，接收主机不会接收。这样，错误片段、丢失片段和被拒片段的联手破坏之下，接收主机只可能收到一个充满“漏洞”的文本流。

TCP的补救方法是，在每收到一个正确的、符合次序的片段之后，就向发送方(也就是连接的另一段)发送一个特殊的TCP片段，用来知会(ACK，acknowledge)发送方：我已经收到那个片段了。这个特殊的TCP片段叫做ACK回复。如果一个片段序号为L，对应ACK回复有回复号L+1，也就是接收方期待接收的下一个发送片段的序号。

如果发送方在一定时间等待之后，还是没有收到ACK回复，那么它推断之前发送的片段一定发生了异常。发送方会重复发送(retransmit)那个出现异常的片段，等待ACK回复，如果还没有收到，那么再重复发送原片段… 直到收到该片段对应的ACK回复(回复号为L+1的ACK)。

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

超时重传机制

分为两种情况

• 主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B；
  如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发；
  
• 但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了
  
  因此主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉。这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果。

超时的时间如何确定?

最理想的情况下,找到一个最小的时间,保证 “确认应答一定能在这个时间内返回”。
但是这个时间的长短，随着网络环境的不同，是有差异的。
如果超时时间设的太长，会影响整体的重传效率；
如果超时时间设的太短，有可能会频繁发送重复的包；

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

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

通过ACK回复和超时重传机制，TCP协议将片段传输变得可靠。尽管底盘是不可靠的IP协议，但TCP协议以一种“不放弃的精神”，不断尝试，最终成功。(技术也可以很励志)

TCP协议和UDP协议走了两个极端。TCP协议复杂但可靠，UDP协议轻便但不可靠。在处理异常的时候，TCP极端负责，而UDP一副无所谓的样子。

滑动窗口

上面的工作方式中，发送方保持 发送->等待ACK->发送->等待ACK… 的单线工作方式，这样的工作方式叫做 stop-and-wait。stop-and-wait虽然实现了TCP通信的可靠性，但同时牺牲了网络通信的效率。

在等待ACK的时间段内，我们的网络都处于闲置(idle)状态。我们希望有一种方式，可以同时发送出多个片段。然而如果同时发出多个片段，那么由于IP包传送是无次序的，有可能会生成乱序片段(out-of-order)，也就是后发出的片段先到达。

在stop-and-wait的工作方式下，乱序片段完全被拒绝，这也很不效率。毕竟，乱序片段只是提前到达的片段。我们可以在缓存中先存放它，等到它之前的片段补充完毕，再将它缀在后面。然而，如果一个乱序片段实在是太过提前(太“乱”了)，该片段将长时间占用缓存。我们需要一种折中的方法来解决该问题：利用缓存保留一些“不那么乱”的片段，期望能在段时间内补充上之前的片段(暂不处理，但发送相应的ACK)；对于“乱”的比较厉害的片段，则将它们拒绝(不处理，也不发送对应的ACK)。

• 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，上图的窗口大小就是4000个字节(四个段)。三次握手后知道对方的窗口大小。
• 发送前四个段的时候，不需要等待任何ACK，直接发送；
• 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
• 操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；
• 窗口越大，则网络的吞吐率就越高；
  
  滑动窗口(sliding window)被同时应用于接收方和发送方，以解决以上问题。发送方和接收方各有一个滑窗。当片段位于滑窗中时，表示TCP正在处理该片段。滑窗中可以有多个片段，也就是可以同时处理多个片段。滑窗越大，越大的滑窗同时处理的片段数目越多(当然，计算机也必须分配出更多的缓存供滑窗使用)。

假设一个可以容纳三个片段的滑窗，并假设片段从左向右排列。对于发送方来说，滑窗的左侧为已发送并已ACK过的片段序列，滑窗右侧是尚未发送的片段序列。滑窗中的片段(比如片段5，6，7)被发送出去，并等待相应的ACK。如果收到片段5的ACK，滑窗将向右移动。这样，新的片段从右侧进入滑窗内，被发送出去，并进入等待状态。在接收到片段5的ACK之前，滑窗不会移动，即使已经收到了片段6和7的ACK。这样，就保证了滑窗左侧的序列是已经发送的、接收到ACK的、符合顺序的片段序列。

对于接收方来说，滑窗的左侧是已经正确收到并ACK回复过的片段(比如片段1，2，3，4)，也就是正确接收到的文本流。滑窗中是期望接收的片段(比如片段5, 6, 7)。同样，如果片段6，7先到达，那么滑窗不会移动。如果片段5先到达，那么滑窗会向右移动，以等待接收新的片段。如果出现滑窗之外的片段，比如片段9，那么滑窗将拒绝接收。

那么如果出现了丢包, 如何进行重传？这里分两种情况讨论：

• 情况一：数据包已经抵达，ACK被丢了
  
  这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认；

• 情况二：数据包丢了
  - 当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 "我想要的是 1001"一样；

• 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答，就会将对应的数据 1001 - 2000 重新发送；

• 这个时候接收端收到了 1001 之后，再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中；

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

流量控制

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control)；

• 接收端将自己接收的缓冲区的剩余大小放入 TCP 首部中的 “窗口大小” 字段，通过ACK端通知发送端；
• 窗口大小字段越大，说明网络的吞吐量越高；
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
• 发送端接受到这个窗口之后，就会减慢自己的发送速度；
• 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
  
  接收端如何把窗口大小告诉发送端呢？回忆我们的TCP首部中，有一个16位窗口字段， 就是存放了窗口大小信息；
  那么问题来了，16位数字最大表示65535，那么TCP窗口最大就是65535字节么？
  实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是 窗口字段的值左移 M 位;

拥塞控制

在TCP协议中，我们使用连接记录TCP两端的状态，使用编号和分段实现了TCP传输的有序，使用滑动窗口来实现了发送方和接收方处理能力的匹配，并使用重复发送来实现TCP传输的可靠性。

有了上面的机制，我们只需要将TCP片段包装成IP包，扔到网络中就可以了。TCP协议的相关模块会帮我们处理各种可能出现的问题(比如排序，比如TCP片段丢失等等)。最初的TCP协议就是由上述的几大块构成的。

然而进入上世纪八十年代，网络变的繁忙。许多网络中出现了大量的堵塞。堵塞类似于现实中的堵车。网络被称为“信息高速公路”。许多汽车(IP包)在网络中行驶，并经过一个一个路口 (路由器)，直到到达目的地。

一个路由器如果过度繁忙，会丢弃一些IP包。UDP协议不保证传输的可靠性，所以丢失就丢失了。而TCP协议需要保证传输的可靠性，当包含有TCP片段的IP包丢失时，TCP协议会重复发送TCP片段。于是，更多的“汽车”进入到公路中，原本繁忙的路由器变得更加繁忙，更多的IP包丢失。这样就构成了一个恶性循环。

这样的情况被称为堵塞崩溃(congestion collapse)。每个发送方为了保证自己的发送质量，而不顾及公共领域现状，是造成堵塞崩溃的主要原因。当时的网络中高达90%的传输资源可能被堵塞崩溃所浪费。

TCP协议的堵塞控制是通过约束自己实现的。当TCP的发送方探测到网络交通拥堵时，会控制自己发送片段的速率，以缓解网络的交通状况，避免堵塞崩溃。

我们先来说明堵塞是如何探测的。在前面，我们已经总结了两种推测TCP片段丢失的方法：ACK超时和重复ACK。一旦发送方认为TCP片段丢失，则认为网络中出现堵塞。

另一方面，TCP发送方是如何控制发送速率呢？TCP协议通过控制滑窗(sliding window)大小来控制发送速率。在前面，我们已经见到了一个窗口限制，就是接收缓冲区的剩余大小，以实现TCP流量控制。TCP还会维护一个拥塞窗口（congestion window size），以根据网络状况来调整滑窗大小。真实窗口大小取接收缓冲区剩余空间和拥塞窗口的最小值，从而同时满足两个限制 (流量控制和堵塞控制)。

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

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

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

少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞；
当TCP通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降；
拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

延迟应答

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

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

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

• 数量限制：每隔N个包就应答一次；
• 时间限制：超过最大延迟时间就应答一次；
  具体的数量和超时时间，依操作系统不同也有差异；一般N取2，超时时间取200ms；
  

捎带应答

在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说了 “How are you”，服务器也会给客户端回一个 “Fine, thank you”；
那么这个时候ACK就可以搭顺风车，和服务器回应的 “Fine, thank you” 一起回给客户端

总结

保证可靠性：

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

提高效率：

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