前言

TCP（Transmission Control Protocol，传输控制协议）是计算机网络的的重要组成部分，也是网络编程的重要内容，还有咱们平时接触最多的 HTTP 也是基于 TCP 实现的。TCP 能够说是最重要的传输层协定，既然如此，作为开发人员，就有必要把 TCP 的外围概念和原理搞清楚。除此之外，诸如三次握手、四次挥手、滑动窗口和拥塞管制这些概念更是高频面试题，这就更有理由深刻学习一下 TCP 了，本文就为大家具体梳理一下 TCP 的外围概念和原理。注：因为本文图片较多，标注有 by HYN 的图片为作者自制，其它来自于网络或参考资料，侵删

一、TCP 简介

第一局部先为大家介绍一下 TCP 的次要概念，并解说一下 TCP 的三个重要个性——1. 面向连贯；2. 基于字节流；3. 可靠性。

对于网络分层的概念切实是陈词滥调了，下图就是两种经典的分层模型，能够看到 TCP 在网络分层中的地位。

网络分层模型

本文重点对 TCP 进行介绍，从图中能够看到 TCP 位于传输层，而且构建于网络层的 IP 协定之上，对于 TCP 最常见的介绍就是“TCP 是一种面向连贯的、牢靠的、基于字节流的传输层通信协议”，那这三个形容词到底是什么意思呢？

1.1 面向连贯

面向连贯意味着两个应用 TCP 的利用 (通常是一个客户端和一个服务器) 在彼此替换数据之前必须先建设一个 TCP 连贯。这一过程与打电话很类似，先拨号响铃，等对方应答后后再阐明是谁。具体的三次握手、四次挥手过程将在第二局部——连贯治理局部进行介绍。

1.2 基于字节流

TCP 连贯单方的数据交换格局是以字节 (byte，1byte = 8 bit）形成的有序但无构造的字节流。TCP 不在字节流中插入记录标识符，这被称为字节流服务(byte stream service)。如果一方的应用程序先传 10 字节，又传 20 字节，再传 50 字节，连贯的另一方将无奈理解发方每次发送了多少字节。收方能够分 4 次接管这 80 个字节，每次接管 20 字节。一端将字节放逐到 TCP 连贯上，同样的字节流将呈现在 TCP 连贯的另一端。另外，TCP 对字节流的内容不作任何解释，TCP 无奈晓得传输的数据字节流是二进制数据，还是 ASCI I 字符。

如果感觉下面这段话比拟形象的话，能够拿 TCP 的字节流和 UDP 的报文 (message) 进行比拟（UDP：User Datagram Protocol，用户数据报协定，和 TCP 同为传输层的协定，前面会提供两者的全面比照）。TCP 的字节流相似于自来水，连贯单方都有缓冲区，能够类比成蓄水池，发送方的发送频率和每次的发送量没有固定要求，接管方也能够自在决定本人的接管频率和每次的接管量，只有把所有的数据接管结束即可。而 UDP 的数据报则相似于瓶装水 (比方农夫山泉)，发送方发送一瓶，接管方就要相应地接管一瓶。

下图形容了 TCP 连贯中数据的传输过程以及 TCP 在整个过程中所表演的角色。

TCP 在网络数据传输中的地位和角色

依照图中的流程，比方咱们在浏览 B 站，在 TCP 连贯建设之后，客户端的应用层协定能够向 TCP 发送无非凡格局的字节流，TCP 会将这些字节打包成报文段（segment），报文段大小视状况而定，这些报文段会被网络层的 IP 封装成 IP 数据报（IP Datagram），而后通过网络传输给服务器，而接下来服务器的操作相当于客户端的逆操作，先从 IP 数据报中拆分出 TCP 报文段，再把 TCP 报文段还原成字节流并发送给下层的应用层协定。服务器向客户端发送数据的流程也是一样的，发送方和接管方的角色调换即可。

报文段简介

下面屡次提到了报文段的概念，其构造十分重要，前面的连贯过程和拥塞管制等内容也要用到相干概念，先在这里介绍一下。

TCP 报文段构造

图的上半局部显示 TCP 报文段被封装在 IP 数据报中，图的下半局部则显示了 TCP 报文段和 TCP 首部的构造，TCP 首部的固定数据有 20 字节，加上选项局部最大可达 60 字节，而无效数据局部则是被打包的应用层数据。上面介绍一下 TCP 首部的构造：

• 端口号 (Source Port and Destination Port)：每个 TCP 报文段都蕴含源端和目标端的端口号，用于寻找发送端和接收端利用过程。这两个值加上 IP 首部中的源端 IP 地址和目标端 IP 地址就能够确定一个惟一的 TCP 连贯。
• 序号 (Sequence Number)：这个字段的次要作用是用于将失序的数据重新排列。TCP 会隐式地对字节流中的每个字节进行编号，而 TCP 报文段的序号被设置为其数据局部的第一个字节的编号。序号是 32 bit 的无符号数，取值范畴是 0 到 2 32 – 1。
• 确认序号 (Acknowledgment Number)：接管方在承受到数据后，会回复确认报文，其中蕴含确认序号，作用就是通知发送方本人接管到了哪些数据，下一次数据从哪里开始发，因而，确认序号该当是上次已胜利收到数据字节序号加 1。只有 ACK 标记为 1 时确认序号字段才无效。
• 首部长度 (Header Length)：首部中的选项局部的长度是可变的，因而首部的长度也是可变的，所以须要这个字段来明确示意首部的长度，这个字段占 4 bit，4 位的二进制数最大能够示意 15，而首部长度是以 4 个字节为一个单位的，因而首部最大长度是 15 * 4 = 60 字节。
• 保留字段 (Reserved)：占 6 位，将来可能有具体用处，目前默认值为 0.
• 管制位 (Control Bits)：在三次握手和四次挥手中会常常看到 SYN、ACK 和 FIN 的身影，一共有 6 个标记位，它们示意的意义如下：URG (Urgent Bit)：值为 1 时，紧急指针失效 ACK (Acknowledgment Bit)：值为 1 时，确认序号失效 PSH (Push Bit)：接管方应尽快将这个报文段交给应用层 RST (Reset Bit)：发送端遇到问题，想要重建连贯 SYN (Synchronize Bit)：同步序号，用于发动一个连贯 FIN (Finish Bit)：发送端要求敞开连贯
• 窗口大小 (Window)：TCP 的流量管制由连贯的每一端通过申明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接管端正冀望接管的字节。窗口大小是一个 16 bit 字段，单位是字节，因此窗口大小最大为 65535 字节。
• 测验和 (Checksum)：性能相似于数字签名，用于验证数据完整性，也就是确保数据未被批改。测验和笼罩了整个 TCP 报文段，包含 TCP 首部和 TCP 数据，发送端依据特定算法对整个报文段计算出一个测验和，接收端会进行计算并验证。
• 紧急指针 (Urgent Pointer)：当 URG 管制位值为 1 时，此字段失效，紧急指针是一个正的偏移量，和序号字段中的值相加示意紧急数据最初一个字节的序号。TCP 的紧急形式是发送端向另一端发送紧急数据的一种形式。
• 选项 (Options)：这一部分是可选字段，也就是非必须字段，最常见的可选字段是“最长报文大小 (MSS，Maximum Segment Size)”。
• 无效数据局部 (Data)：这部分也不是必须的，比方在建设和敞开 TCP 连贯的阶段，单方替换的报文段就只蕴含 TCP 首部。

1.3 可靠性

咱们都晓得 TCP 是具备可靠性的通信协议，它次要通过以下形式确保可靠性，这里先理解一下可靠性的原理，其中细节局部后文会讲：

• 正当的数据大小：TCP 发送的数据并不是固定的大小，而是会依据理论状况调整报文段的大小。
• 测验和：发送端依照特定算法计算出 TCP 报文段的测验和并存储在 TCP 首部中的对应字段上，接收端在接管时会以同样的形式计算校验和，如果不统一，阐明报文段呈现谬误，会将其抛弃。
• 序号与确认序号：对乱序的数据进行排序后发给应用层，并抛弃反复的数据。
• 超时重传机制：当 TCP 收回一个报文段后，它会启动一个定时器，期待目标端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段，前面会细讲这个机制。
• 连贯治理：也就是三次握手和四次挥手，连贯的可靠性是整体可靠性的前提，本文第二局部将会具体介绍连贯治理的内容。
• 流量管制：TCP 单方都有固定大小的缓冲区，流量管制的原理是利用滑动窗口控制数据发送速度，防止缓冲区溢出导致数据失落。
• 拥塞管制：TCP 利用慢启动和拥塞防止等算法实现了拥塞管制。

下面为大家介绍了 TCP 最重要的三个特点，在本文第一局部的最初，再来看看 TCP 和 UDP 的比照吧。

1.4 TCP 和 UDP 的区别

二、TCP 的连贯管制

2.1 建设连贯

2.1.1 三次握手

这个问题几乎太经典了，如果你在面试中只被问到了一个对于 TCP 的问题，那大概率就是对于三次握手的问题。TCP 的重要个性之一就是面向连贯，连贯单方在发送数据之前必须经验握手的阶段，那具体的过程是怎么的呢？先来看图，大家最好能够入手简略画画这个图，当然还有后文四次挥手的图，帮忙加深记忆。

三次握手过程

如图所示，单方之间的三个蓝色箭头就示意了三次握手过程中所产生的数据交换：

1. 第一次握手：客户端向服务器发送报文段 1，其中的 SYN 标记位 (前文曾经介绍过各种标记位的作用)的值为 1，示意这是一个用于申请发动连贯的报文段，其中的序号字段 (Sequence Number，图中简写为 seq)被设置为初始序号 x (Initial Sequence Number，ISN)，TCP 连贯单方均可随机抉择初始序号。发送完报文段 1 之后，客户端进入 SYN-SENT 状态，期待服务器的确认。
2. 第二次握手：服务器在收到客户端的连贯申请后，向客户端发送报文段 2 作为应答，其中 ACK 标记位设置为 1，示意对客户端做出应答，其确认序号字段 (Acknowledgment Number，图中简写为小写 ack) 失效，该字段值为 x + 1，也就是从客户端收到的报文段的序号加一，代表服务器冀望下次收到客户端的数据的序号。此外，报文段 2 的 SYN 标记位也设置为 1，代表这同时也是一个用于发动连贯的报文段，序号 seq 设置为服务器初始序号 y。发送完报文段 2 后，服务器进入 SYN-RECEIVED 状态。
3. 第三次握手：客户端在收到报文段 2 后，向服务器发送报文段 3，其 ACK 标记位为 1，代表对服务器做出应答，确认序号字段 ack 为 y + 1，序号字段 seq 为 x + 1。此报文段发送结束后，单方都进入 ESTABLISHED 状态，示意连贯已建设。

常见面试题 1：TCP 建设连贯为什么要三次握手而不是两次？

答：网上大多数材料对这个问题的答复只有简略的一句：避免已过期的连贯申请报文忽然又传送到服务器，因此产生谬误，这既不够全面也不够具体。上面给出比拟具体而全面的答复：

1. 避免已过期的连贯申请报文忽然又传送到服务器，因此产生谬误在单方两次握手即可建设连贯的状况下，假如客户端发送 A 报文段申请建设连贯，因为网络起因造成 A 临时无奈达到服务器，服务器接管不到申请报文段就不会返回确认报文段，客户端在长时间得不到应答的状况下从新发送申请报文段 B，这次 B 顺利达到服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，客户端在收到 确认报文后已进入 ESTABLISHED 状态，单方建设连贯并传输数据，之后失常断开连接。此时捷足先登的 A 报文段才达到服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，然而曾经进入 CLOSED 状态的客户端无奈再承受确认报文段，更无奈进入 ESTABLISHED 状态，这将导致服务器长时间单方面期待，造成资源节约。
2. 三次握手能力让单方均确认本人和对方的发送和接管能力都失常第一次握手：客户端只是发送处申请报文段，什么都无奈确认，而服务器能够确认本人的接管能力和对方的发送能力失常；第二次握手：客户端能够确认本人发送能力和接管能力失常，对方发送能力和接管能力失常；第三次握手：服务器能够确认本人发送能力和接管能力失常，对方发送能力和接管能力失常；可见三次握手能力让单方都确认本人和对方的发送和接管能力全副失常，这样就能够欢快地进行通信了。
3. 告知对方本人的初始序号值，并确认收到对方的初始序号值 TCP 实现了牢靠的数据传输，起因之一就是 TCP 报文段中保护了序号字段和确认序号字段，也就是图中的 seq 和 ack，通过这两个字段单方都能够晓得在本人收回的数据中，哪些是曾经被对方确认接管的。这两个字段的值会在初始序号值得根底递增，如果是两次握手，只有发起方的初始序号能够失去确认，而另一方的初始序号则得不到确认。

常见面试题 2：TCP 建设连贯为什么要三次握手而不是四次？

答：相比上个问题而言，这个问题就简略多了。因为三次握手曾经能够确认单方的发送接管能力失常，单方都晓得彼此曾经筹备好，而且也能够实现对单方初始序号值得确认，也就无需再第四次握手了。

常见面试题 3：有一种网络攻击是利用了 TCP 建设连贯机制的破绽，你理解吗？这个问题怎么解决？

答：在三次握手过程中，服务器在收到了客户端的 SYN 报文段后，会调配并初始化连贯变量和缓存，并向客户端发送 SYN + ACK 报文段，这相当于是关上了一个“半开连贯 (half-open connection)”，会耗费服务器资源。如果客户端失常返回了 ACK 报文段，那么单方能够失常建设连贯，否则，服务器在期待一分钟后会终止这个“半开连贯”并回收资源。这样的机制为 SYN 洪泛攻打 (SYN flood attack)提供了机会，这是一种经典的 DoS 攻打 (Denial of Service，拒绝服务攻打)，所谓的拒绝服务攻打就是通过进行攻打，使受益主机或网络不能提供良好的服务，从而间接达到攻打的目标。在 SYN 洪泛攻打中，攻击者发送大量的 SYN 报文段到服务器申请建设连贯，然而却不进行第三次握手，这会导致服务器关上大量的半开连贯，耗费大量的资源，最终无奈进行失常的服务。

解决办法：SYN Cookies，当初大多数支流操作系统都有这种进攻零碎。SYN Cookies 是对 TCP 服务器端的三次握手做一些批改，专门用来防备 SYN 洪泛攻打的一种伎俩。它的原理是，在服务器接管到 SYN 报文段并返回 SYN + ACK 报文段时，不再关上一个半开连贯，也不分配资源，而是依据这个 SYN 报文段的重要信息 (包含源和目标 IP 地址，端口号可一个机密数)，利用特定散列函数计算出一个 cookie 值。这个 cookie 作为将要返回的 SYN + ACK 报文段的初始序列号 (ISN)。当客户端返回一个 ACK 报文段时，服务器依据首部字段信息计算 cookie，与返回的确认序号(初始序列号 + 1) 进行比照，如果雷同，则是一个失常连贯，而后分配资源并建设连贯，否则回绝建设连贯。

2.2.2 同时关上

这是 TCP 建设连贯的非凡状况，有时会呈现两台机器同时执行被动关上的状况，不过概率十分小，这种状况大家仅作理解即可。在这种状况下就无所谓发送方和接管方了，双放都能够称为客户端和服务器，同时关上的过程如下：

同时关上的过程

如图所示，单方在同一时刻发送 SYN 报文段，并进入 SYN-SENT 状态，在收到 SYN 后，状态变为 SYN-RECEIVED，同时它们都在发送一个 SYN + ACK 的报文段，状态都变为 ESTABLISHED，连贯胜利建设。在此过程中单方一共替换了 4 个报文段，比三次握手多一个。

2.2 敞开连贯

2.2.1 四次挥手

建设一个连贯须要三次握手，而终止一个连贯要通过 4 次握手。这由 TCP 的半敞开(half-close) 造成的。既然一个 TCP 连贯是全双工 (即数据在两个方向上能同时传递)，因而每个方向必须独自地进行敞开。这准则就是当一方实现它的数据发送工作后就能发送一个 FIN 来终止这个方向连贯。当一端收到一个 FIN，它必须告诉应用层另一端曾经终止了数据传送。实践上客户端和服务器都能够发动被动敞开，然而更多的状况下是客户端被动发动。

四次挥手过程

四次挥手具体过程如下：

1. 客户端发送敞开连贯的报文段，FIN 标记位 1，申请敞开连贯，并进行发送数据。序号字段 seq = x (等于之前发送的所有数据的最初一个字节的序号加一)，而后客户端会进入 FIN-WAIT-1 状态，期待来自服务器的确认报文。
2. 服务器收到 FIN 报文后，发回确认报文，ACK = 1，ack = x + 1，并带上本人的序号 seq = y，而后服务器就进入 CLOSE-WAIT 状态。服务器还会告诉下层的应用程序对方曾经开释连贯，此时 TCP 处于半敞开状态，也就是说客户端曾经没有数据要发送了，然而服务器还能够发送数据，客户端也还可能接管。
3. 客户端收到服务器的 ACK 报文段后随即进入 FIN-WAIT-2 状态，此时还能收到来自服务器的数据，直到收到 FIN 报文段。
4. 服务器发送完所有数据后，会向客户端发送 FIN 报文段，各字段值如图所示，随后服务器进入 LAST-ACK 状态，期待来自客户端的确认报文段。
5. 客户端收到来自服务器的 FIN 报文段后，向服务器发送 ACK 报文，随后进入 TIME-WAIT 状态，期待 2MSL(2 * Maximum Segment Lifetime，两倍的报文段最大存活工夫)，这是任何报文段在被抛弃前能在网络中存在的最长工夫，罕用值有 30 秒、1 分钟和 2 分钟。如无非凡状况，客户端会进入 CLOSED 状态。
6. 服务器在接管到客户端的 ACK 报文后会随即进入 CLOSED 状态，因为没有等待时间，一般而言，服务器比客户端更早进入 CLOSED 状态。

常见面试题 1：为什么 TCP 敞开连贯为什么要四次而不是三次？

答：服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上敞开连贯，然而会做出应答，返回 ACK 报文段，接下来可能会持续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，示意数据曾经发送结束，申请敞开连贯，而后客户端再做出应答，因而一共须要四次挥手。

常见面试题 2：客户端为什么须要在 TIME-WAIT 状态期待 2MSL 工夫能力进入 CLOSED 状态？

答：依照常理，在网络失常的状况下，四个报文段发送完后，单方就能够敞开连贯进入 CLOSED 状态了，然而网络并不总是牢靠的，如果客户端发送的 ACK 报文段失落，服务器在接管不到 ACK 的状况下会始终反复 FIN 报文段，这显然不是咱们想要的。因而客户端为了确保服务器收到了 ACK，会设置一个定时器，并在 TIME-WAIT 状态期待 2MSL 的工夫，如果在此期间又收到了来自服务器的 FIN 报文段，那么客户端会从新设置计时器并再次期待 2MSL 的工夫，如果在这段时间内没有收到来自服务器的 FIN 报文，那就阐明服务器曾经胜利收到了 ACK 报文，此时客户端就能够进入 CLOSED 状态了。

2.2.2 同时敞开

之前在介绍 TCP 建设连贯的时候会有一种非凡状况，那就是同时关上，与之对应地，TCP 敞开时也会有一种非凡状况，那就是同时敞开，这种状况仅作理解即可，流程图如下：

同时敞开过程

这种状况下，单方应用层同时收回敞开命令，这将导致单方各发送一个 FIN，两端均从 ESTABLISHED 变为 FIN_WAIT_1，两个 FIN 通过网络传送后别离达到另一端。收到 FIN 后，状态由 FIN_WAIT_1 变迁到 CLOSING，并发送最初的 ACK，当收到最初的 ACK 时，为确保对方也收到 ACK，状态变动为 TIME_WAIT，并期待 2MSL 工夫，如果一切正常，随后会进入 CLOSED 状态。

三、TCP 的流量管制与滑动窗口

3.1 什么是流量管制？

TCP 连贯单方的主机都为该连贯设置了发送缓存和接管缓存，这些缓存起到了蓄水池的作用，咱们必定不能把下层应用程序发来的数据一股脑儿发送到网络中，而是利用发送缓存将其缓存起来，而后再按肯定的速率通过网络发送给对方，而接管缓存的作用是把对方传来的数据先缓存起来，等到己方应用程序有空的时候再来取走数据。示意图如下：

TCP 缓存示意图

在此过程中，如果接管方应用程序读取数据的速度小于发送方的数据发送速度，将导致接管方的接管缓存溢出，造成数据失落，这显然不是咱们想看到的。因而 TCP 为应用程序提供了流量管制服务 (flow-control service)，以打消发送方使接管方的接管缓存溢出的可能性。简略来说流量管制的目标就是协调发送方的数据发送速度，使其与接管方的数据处理速度相匹配，防止数据失落，那么如何实现流量管制呢？

3.2 晚期的流量管制模式——进行 - 期待模式 (stop-wait)

顾名思义就是发送方在发送一个数据包后就进行发送，期待对方响应 ACK，而后能力持续发送数据。这种模式的具体实现为 Positive Acknowledgment With Retransmission (PAR)，意为带重传的必定确认协定，其实现形式如下图所示：

PAR 示意图

这种实现很简略，发送方在发送数据包 (图中的 msg)时会设置一个计时器，而后期待接管方的 ACK，接管方在收到数据后会返回 ACK 作为应答，发送方在收到 ACK 后会发送下一个数据包。如果因为网络起因造成数据包或者 ACK 失落时，计时器会超时，而后发送方会从新发送未被确认的数据包。能够看到，这种模式尽管能够确保数据传输的可靠性，然而有个致命的毛病，那就是效率太低？如果是你，你会怎么对这个计划进行优化呢？

既然每次发送只一个数据包效率太低，那就多发送几个，而后给这些数据包编上号，接收端必须对每一个包进行确认，这样设施 A 一次多发送几个片段，而不用等待 ACK，同时接收端也要告知它可能收多少，这样发送端发起来也有个限度，当然还须要保障程序性，不要乱序，对于乱序的情况，咱们能够容许期待肯定状况下的乱序，比如说先缓存提前到的数据，而后去期待须要的数据，如果肯定工夫没来就丢掉乱序的数据，来保障程序性，这样的话，数据传输效率就能够大大提高。不过 TCP 也没有采纳这种计划，而是在此基础上实现更加简单的滑动窗口。

3.3 滑动窗口

咱们能够把发送方的发送缓存中的字节分为以下四类，每个编号对应一个字节：

发送缓存中的字节分类

1. 第一类：已发送且已确认，这些数据曾经发送胜利并曾经被确认的数据，比方图中的前 31 个 bytes，这些数据其实的地位是在窗口之外了，下一步将被移出发送缓存。窗口内程序最低的字节被确认之后，窗口左边界会向右挪动，称为窗口合拢。
2. 第二类：已发送但未收到确认，这部分数据曾经被发送进来，然而还没有收到接收端的 ACK，认为并没有实现发送，这部分数据属于窗口内的数据。
3. 第三类：未发送然而接管方曾经筹备好接管，这部分是尽快发送的数据，这部分数据曾经被加载到缓存中，也在发送窗口中，正在期待发送，其实这个窗口是齐全有接管方告知的，接管方告知以后能够承受这些数据，所以发送方须要尽快的发送。
4. 第四类：未发送且接管方未筹备好接管，这些数据属于未发送，同时接收端也不容许发送的，因为这些数据曾经超出了发送端所接管的范畴。

3.3.1 发送窗口和接管窗口

发送窗口

发送窗口：图中的彩色框就是发送方的发送窗口，其大小由两个因素决定：1、接管方的提供的窗口大小 (TCP 报文段首部中的 window 字段)，发送方在三次握手阶段首次失去这个值，之后的通信过程中接管方会依据本人的可用缓存对这个值进行动静调整；2、发送方会依据网络状况保护一个拥塞窗口变量 (后文介绍)。发送窗口的大小取这两个值的最小值。对于发送方来说，发送窗口分为两局部，别离是曾经发送的局部（曾经发送了，然而没有收到 ACK）和可用窗口，接收端容许发送然而没有发送的那局部称为可用窗口。

接管窗口：对于接收端也是有一个接管窗口的，相似发送端，接收端的数据有 3 个分类，因为接收端并不需要期待 ACK 所以它没有相似的接管并确认了的分类，状况如下

1. Received and ACK Not Send to Process：这部分数据属于接管了数据然而还没有被下层的应用程序接管；
2. Received Not ACK: 曾经接管，然而还没有回复 ACK；
3. Not Received：有空位，还没有被接管的数据。

3.3.2 滑动窗口是如何滑动的？

滑动窗口的滑动过程

累积确认概念：TCP 并不是每一个报文段都会回复一个 ACK，可能会对两个报文段发送一个 ACK，也可能会对多个报文段发送 1 个 ACK，这称为累积确认。比如说发送方有 1/2/3 3 个报文段，先发送了 2,3 两个报文段，然而接管方冀望收到 1 报文段，这个时候 2/3 报文段就只能放在缓存中期待报文 1 的空洞被填上，如果报文段 1 始终不来，报文 2/3 也将被抛弃，如果报文 1 来了，那么会发送一个 ACK 对第 3 个报文段进行确认，就代表对这三个报文段全副进行了确认。

上面举例说明一下窗口滑动的过程：

1. 在握手过程中，接管方通告的窗口大小为 20 字节，所以发送方将发送窗口大小设置为 20 字节。
2. 从图中的 ” 上一个发送窗口的地位 ”(灰色虚线框)说起，32-51 号字节恰好处于发送窗口中，恰好 20 个字节，假如 TCP 将其分为 4 个报文段进行发送，每个报文段 5 个字节数据，别离记为 seg1 32-36, seg2 37-41, seg3 42-46, seg4 47-51。
3. TCP 将有序发送 seg1、seg2、seg3 和 seg4 四个报文段，如果这四个报文段都顺利达到接管方 (图中并不是这样)，接管方将发回一个累积确认的 ACK 报文段，其中 ack = 52，代表心愿收到下一个报文段的起始字节编号，报文段中也会持续通告窗口大小，如果还是 20 字节，那么发送方的窗口将整体向右挪动 20 字节，如果通告的窗口值变小，比方变成 15，那么发送窗口左边界挪动 20 字节，右边界挪动 15 字节。
4. 如果在发送过程中 seg2 报文段失落，而其余三个报文段失常达到接管方，那么接管方会现承受这三个报文段，而后返回 ACK 报文段，ack = 37，示意心愿收到的下一个报文段的起始字节号为 37，也就是 seg2 报文段。如果通告窗口值未发生变化，发送方在收到 ACK 后会将窗口整体右移 5 个字节，也就变成了图中的地位。
5. 因为 seg2 还未收到 ACK，当重传计时器超时后，发送方会从新发送 seg2，此时 52-56 号字节又落到了发送窗口中，TCP 将其封装成 报文段进行发送，如果接管方全副顺利收到，会返回一个累积确认的 ACK，ack = 57，示意心愿收到的青睐个报文段的起始字节号为 57。

接下来就是反复上述过程，直到 TCP 字节流的所有数据发送结束。在这个过程中，接管方会依据本人接管缓存的残余空间动静调整窗口值，对发送方进行流量管制。文字描述可能不够直观，大家能够参考上文举荐的视频。另外举荐一个动图演示的网站 动画地址，能够观看滑动窗口的动态效果，如下图 (此演示未思考丢包的状况)：

滑动窗口动画成果

四、TCP 的拥塞管制

4.1 什么是拥塞管制？

当数据从一个大的管道 (比方一个疾速局域网)向一个较小的管道 (比方较慢的广域网)发送的时候就会产生拥塞，还有一种状况就是当多个输出流达到一个路由器，而路由器的输入流小于这些输出流的总和时，也会产生拥塞。举个例子就好了解了，第一种状况就如同源源不断的车流从八车道进入四车道，如果不进行管制，必然造成路线拥挤；第二种状况相似于很多车辆汇入十字路口，如果进的速度大于出的速度，再不加以控制，必然也会造成拥挤。于是 TCP 提供了相应的机制来应答这种状况，也就是 TCP 的拥塞管制。

4.2 如何实现拥塞管制？

TCP 一共应用了四种算法来实现拥塞管制：1、慢开始 (slow-start)；2、拥塞防止 (congestion avoidance)；3、疾速重传 (fast retransmit)；4、疾速复原 (fast recovery)。

这里先介绍一下拥塞窗口 (congestion window，简写为 cwnd)的概念：拥塞窗口是由发送方依据网络情况保护的一个变量，用于管制本人的数据发送速率。前文提到了发送方的发送窗口受两个变量束缚，一是接管方通告的窗口大小值，二就是发送方本身的拥塞窗口，理论的发送窗口大小取二者最小值。

慢开始和拥塞防止

4.2.1 慢开始（慢启动）

如图所示，在刚开始，TCP 采纳慢开始算法。慢开始不是指拥塞窗口的增长速度慢(增长速度是指数增长，十分快)，而是指 TCP 开始发送设置 cwnd=1。思路就是不要一开始就发送大量的数据，先探测一下网络的拥塞水平，也就是说由小到大 逐步减少拥塞窗口的大小。这里用报文段的个数的拥塞窗口大小举例说明慢启动算法，实时拥塞窗口大小是以字节为单位的。为了避免 cwnd 增长过大引起网络拥塞，设置一个慢开始门限(slow start threshold，简写为 ssthresh)，

当 cnwd < ssthresh，应用慢开始算法

当 cnwd = ssthresh，既可应用慢开始算法，也能够应用拥塞防止算法

当 cnwd > ssthresh，应用拥塞防止算法

4.2.2 拥塞防止

当拥塞窗口大小达到初始 ssthresh 值时，转而采纳拥塞防止算法。拥塞防止并非齐全可能防止拥塞，是说在拥塞防止阶段将拥塞窗口管制为按线性法则增长，使网络比拟不容易呈现拥塞，思路：让拥塞窗口 cwnd 迟缓地增大，即每通过一个往返工夫 RTT 就把发送方的拥塞窗口加一。无论是在慢开始阶段还是在拥塞防止阶段，只有发送方判断网络呈现拥塞(其依据就是没有收到确认，尽管没有收到确认可能是其余起因的分组失落，然而因为无奈断定，所以都当做拥塞来解决)，就把慢开始门限设置为呈现拥塞时的发送窗口大小的一半。而后把拥塞窗口设置为 1，执行慢开始算法。

4.2.3 疾速重传

TCP Reno 利用了四种算法

有时候的发送方未收到某个报文段的确认也并肯定就阐明肯定是呈现了网络拥塞，也可能是其余起因，所以间接执行慢开始算法会影响整体效率，起初的 TCP Reno 版本解决了这一问题，那就是采纳疾速重传和疾速复原算法。

疾速重传要求接管方在收到一个失序的报文段后就立刻收回反复确认(为的是使发送方及早晓得有报文段没有达到对方)，而不要等到本人发送数据时捎带确认。快重传算法规定，发送方只有一连收到三个反复确认就该当立刻重传对方尚未收到的报文段，而不用持续期待设置的重传计时器工夫到期。因为不须要期待设置的重传计时器到期，能尽早重传未被确认的报文段，能进步整个网络的吞吐量。

4.2.4 疾速复原

当发送方间断收到三个反复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半。然而接下去并不执行慢开始算法。思考到如果网络呈现拥塞的话就不会收到好几个反复的确认，所以发送方当初认为网络可能没有呈现拥塞。所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，而后执行拥塞防止算法。

五、TCP 粘包与拆包

5.1 TCP 粘包和拆包的起因

咱们晓得 TCP 是以字节流的形式传输数据，传输的最小单位为一个报文段（segment）。TCP 首部 中有个选项 (Options)的字段，常见的选项为 MSS (Maximum Segment Size 最大音讯长度)，它是收发单方协商通信时每一个报文段所能承载的最大无效数据的长度。数据链路层每次传输的数据有个最大限度 MTU (Maximum Transmission Unit)，个别是 1500 比特，超过这个量要分成多个报文段，MSS 则是这个最大限度减去 TCP 的首部，光是要传输的数据的大小，个别为 1460 比特。换算成字节，也就是 180 多字节。

MSS = MTU – Header

TCP 为进步性能，发送端会将须要发送的数据发送到发送缓存，期待缓存满了之后，再将缓存中的数据发送到接管方。同理，接管方也有接管缓存这样的机制，来接收数据。

下面这些是产生 TCP 粘包和拆包的前提，上面是具体的起因：

1. 要发送的数据大于 TCP 发送缓冲区残余空间大小，将会产生拆包。
2. 待发送数据大于 MSS（最大报文长度），TCP 在传输前将进行拆包。
3. 应用程序写入数据小于残余缓存大小，网卡将利用屡次写入的数据先缓存起来，而后一起发送到网络上，这将会产生粘包。
4. 接收数据端的应用层没有及时读取接管缓存中的数据，将产生粘包。

5.2 TCP 粘包和拆包的解决方案

1. 设置定长音讯，服务端每次读取既定长度的内容作为一条残缺音讯。
2. 设置音讯边界，数据结尾尾减少特殊字符宰割。
3. 应用带音讯头的协定，音讯头存储音讯开始标识及音讯长度信息，接管方获取音讯头的时候解析出音讯长度，而后向后读取该长度的内容。

如果您感觉文章对您有用的话 请转发点赞反对一波