TCP三次握手（重点）
- TCP 提供面向有连接的通信传输。面向有连接是指在数据通信开始之前先做好两端之间的准备工作。
- 所谓三次握手是指建立一个 TCP 连接时需要客户端和服务器端总共发送三个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发。
下面来看看三次握手的流程图：
- ***次握手：客户端将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给服务器端，客户端进入SYN_SENT状态，等待服务器端确认。
- 第二次握手：服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务器端将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态。
- 第三次握手：客户端收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务器端，服务器端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。
TCP四次挥手（重点）
- 四次挥手即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。
- 由于TCP连接是全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。
下面来看看四次挥手的流程图：
四次挥手
- 中断连接端可以是客户端，也可以是服务器端。
- ***次挥手：客户端发送一个FIN=M，用来关闭客户端到服务器端的数据传送，客户端进入FIN_WAIT_1状态。意思是说"我客户端没有数据要发给你了"，但是如果你服务器端还有数据没有发送完成，则不必急着关闭连接，可以继续发送数据。
- 第二次挥手：服务器端收到FIN后，先发送ack=M+1，告诉客户端，你的请求我收到了，但是我还没准备好，请继续你等我的消息。这个时候客户端就进入FIN_WAIT_2 状态，继续等待服务器端的FIN报文。
- 第三次挥手：当服务器端确定数据已发送完成，则向客户端发送FIN=N报文，告诉客户端，好了，我这边数据发完了，准备好关闭连接了。服务器端进入LAST_ACK状态。
- 第四次挥手：客户端收到FIN=N报文后，就知道可以关闭连接了，但是他还是不相信网络，怕服务器端不知道要关闭，所以发送ack=N+1后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。服务器端收到ACK后，就知道可以断开连接了。客户端等待了2MSL后依然没有收到回复，则证明服务器端已正常关闭，那好，我客户端也可以关闭连接了。最终完成了四次握手。
上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况。
具体流程如下图：
一、滑动窗口的引出
TCP的确认应答策略，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。
既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多个段的等待时间重叠在一起了）。
- 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节（四个段）。
- 发送前四个段的时候，不需要等待任何ACK，直接发送；
- 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
- 操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；
- 窗口越大，则网络的吞吐率就越高；
这个一次性发送多条数据的量也是有上限的，TCP的发送端会根据对方接收能力和网络承载能力，动态地调节自己的发送流量。（提高到达率）
二、流量控制
滑动窗口实现了TCP流控制。首先明确滑动窗口的范畴：TCP是双工的协议，会话的双方都可以同时接收和发送数据。TCP会话的双方都各自维护一个发送窗口和一个接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的发送窗口则要求取决于对端通告的接收窗口，要求相同。
滑动窗口解决的是流量控制的的问题，就是如果接收端和发送端对数据包的处理速度不同，如何让双方达成一致。接收端的缓存传输数据给应用层，但这个过程不一定是即时的，如果发送速度太快，会出现接收端数据overflow，流量控制解决的是这个问题。
接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制（FlowControl）；
2.1 16位窗口大小
流量控制是根据对方的接收能力来调节发送窗口大小（允许发送的数据量大小）
首先接收端需要知道对方的接收能力，最好是实时感知到，应该怎么做到？
就需要对方告诉接收端，在Segment Header 中把接收能力携带给发送方。
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段，通过ACK端通知发送端；
窗口大小字段越大，说明网络的吞吐量越高；
接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
发送端接受到这个窗口之后，就会减慢自己的发送速度；
如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
注意：
16位数字最大表示65535，那么TCP窗口最大就是65535字节么？
实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是 窗口字段的值左移 M位；
接收窗口 = 接收缓冲区的大小 - 已用大小（接受的数据，暂时没被应用层读走）
最大发送量 = 对方的接收窗口
2.2 发送缓冲区
TCP会通过滑动窗口来控制发送量！！！！保证数据不会发送过量！
滑动窗口是发送缓冲区上一块可以“滑动” 的窗口。
下面逐步梳理一下发送缓冲区的逻辑部分有哪些：
1.三次握手阶段，能收到对方送过来的segment，里面会带有对方的接收窗口大小。
2.随着应用层写入了数据。
写入的数据有可能超过对方接收窗口，也可能少于
3.此时TCP可以把缓冲区的一些数据发送出去
有可能全部发发送了，也有可能只发送了一部分
4.然后收到了服务器传回来的应答
这部分发送已应答的数据就没必要存在缓冲区了，可以视为可用空间了。
2.3 逐步解析滑动窗口运作
有了上面的铺垫，下面用图片逐步演示滑动窗口是怎么运作的：
- 首先是三次握手后，得知了对方接收窗口（假设此时服务器的接收窗口 = 1000），发送端的发送缓冲区是2000。
- 此时发送缓冲区收到了应用层的1500个数据（黄色部分是对方接收窗口大小1000，蓝色部分+黄色部分是 接受的1500个数据）
- 然后TCP发送了500个数据出去（紫色部分），然后有300个数据被对方的接收缓冲区接受了，服务器返回应答，假设应答中返回的接收窗口大小是900。（因为有可能对方应用层只消耗了200个数据，还有100个没消耗掉，所以接收窗口大小为900）
- 那么这应答了的300个数据就等于说是完成了使命，不用留在发送缓冲区了，可以变成可用空间了。（左边300个数据就变成了白色，滑动窗口左边界缩小1000-300 = 700），但注意，因为收到应答中，窗口大小已经变成了900，所以黄色右边界就要扩大了，900-700 = 200 , 可以看图中，右边界从1000 扩到了1200.
- 假设此时应用层又写入了300个数据到发送缓冲区里（蓝色右边界往右扩了300）
- 此时收到了服务器传来的ack，确认之前发的那500个数据已经接收完毕了，窗口大小为1000。（紫色部分变成了白色部分，黄色右边界右移300），此时黄色窗口大小是1000，蓝色+黄色是1300，左边白色是500，右边白色是200，此时缓冲区是还有1300个数据没有发送的，因为之前是1500个数据发了500个出去，然后又新增了300个数据进来，就是1300了。
- 然后TCP发了500数据出去，又发了300出去。。。（以此类推）
从上面一系列状态，相信已经很明白了，滑动窗口的大小就是紫色+黄色的那部分数据，每次紫色变成白色之后，黄色右边界就要根据传回来的window大小往右滑~~
三、快重传机制
默认情况，只有超时时间到了才会重传，而且超时时间是ms为单位的，相对认为是非常久的。
TCP做了个加速机制，如果连续收到ASN = 重复编号 的应答，就不超时等待了，而是立即重传。
- 当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 “我想要的是 1001” 一样；
- 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答，就会将对应的数据 1001 -2000 重新发送；
- 这个时候接收端收到了1001 之后，再次返回的ACK就是7001了（因为2001 -7000）接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中；
模拟动画
模拟特点
找到了一个模拟TCP窗口发送的动画的地址，稍微有缺陷：1. 丢包率如果设得太高，有时无论重发多少次都不能恢复正常 2. 窗口最大可为10，其实应该为9
明确发送端和接收端，发送A~S数据包，我们不会从头到尾分析，因为过程比较长。
1. 简化了窗口大小，双方窗口大小都一直是4
2. 设置一定的丢包率，否则没什么值得分析的，包括sender发送的数据包和receiver回复的ACK包。
3. 简化重传机制，出现丢包则直接重传，不等3个冗余ACK和超时。
4. 既不是选择重传也不是退回N步，重传的包是随机的发
分析滑动窗口机制
- 首先发送端发送A,B,C,D四个包，但是A,B丢失，只有C,D到达接收端。
- 接收端没有收到A，所以不回复ACK包。发送端重传A,B,C,D四个包，这次全都到达了。
- 接收端先获得A，发ACK包A，但是中途丢失；获得B后，根据累计确认的原则，发D的ACK包，然后窗口滑动。再次获得C,D后，连续回复2个D的ACK包，其中C对应的ACK包丢失。
- 发送端连收2个D的ACK包，说明4个包对方都已收到，窗口滑动，发E,F,G,H包，其中G包丢失。现在整个序列的状态：ABCD是已发送已确认，EFGH是已发送未确认，I~S是不能发送。
- 接收端先收到E，发ACK包；收到F后发F的ACK包；未收到G，还是发F的ACK包；收到H，还是发F的ACK包。不幸的是，三个ACK包全都丢失。
- 发送端收到E的ACK包，窗口向右滑动一位；然后再发送F,G,H,I，其中F丢失。
- 接收端获得I，因为没有G，只好回复F的ACK包。相继收到G,H包。
- 接收端根据累计确认，连发两个I包，其中H对应的丢失。窗口向右滑动。
- 发送端接收I的ACK包后，向右滑动四位。发送J,K,L,M四个包，后面不再分析。
从上面的过程中，我们可以得到以下结论：
1. TCP连接是通过数据包和ACK实现的，我们作为第三者可以看到双方发包的过程，但接受者在收到之前不知道发送方发的是什么，同样的，发送方在收到ACK前也不知道对方是否成功接收。
-
发送方没有收到接收方发回的ACK，就不能向右滑动。假设发送方向接收方发了ABCD就滑动，只要对方没收到A，就不能滑动，那么就会出现二者不同步的局面。
-
滑动窗口提高了信道利用率，TCP是发送报文段为单位的，假如每发一个报文就要等ACK，那么对于大数据包，等待时间就太长了。只要发送的报文在滑动窗口里面，不用等每个ACK回来就可以向右滑动。本例中，开始接收端空着AB，只有CD，此时不能滑动；之后接收到EF和H，直接向右滑动2位，不必等G到位。
-
窗口大小不能大于序号空间大小的一半。目的是为了不让两个窗口出现交迭，比如总大小为7，窗口大小都为4，接收窗口应当滑动4，但只剩3个序号，导致两个窗口交迭。
-
有一种情况没出现：发送方发ABCD，接收方都收到然后向右滑动，但回复的ACK包全丢了。发送方未收到任何ACK， timeout后会重发ABCD，此时的接收方按累计确认的原则，收到ABCD后只会重发D的ACK，发送方收到后向右滑动。
对比滑动窗口和拥塞窗口
滑动窗口是控制接收以及同步数据范围的，通知发送端目前接收的数据范围，用于流量控制，接收端使用。拥塞窗口是控制发送速率的，避免发的过多，发送端使用。因为tcp是全双工，所以两边都有滑动窗口。
两个窗口的维护是独立的，滑动窗口主要由接收方反馈缓存情况来维护，拥塞窗口主要由发送方的拥塞控制算法检测出的网络拥塞程度来决定的。
拥塞窗口控制sender向connection传输数据的速率，使这个速率为网络拥堵状况的函数。
拥塞控制
网络中由于有大量的包传输，在固定带宽下处理不过来数据包的传输，可能会导致数据包阻塞，网络传输的速度下降，甚至会下降到 0 的情况。这就有点类似排队买东西，如果正常排队，速度虽然不快但处理速度比较稳定。但是如果一下涌来很多人口，就会处理不过来，导致「堵死情况」。
而 TCP 被设置成一个无私的协议，当遇到网络拥塞时，TCP 会减少自己发送数据包，这样网络拥塞会得到很大的缓解。
为了实现拥塞控制，首先在发送端定义一个拥塞窗口 CWND (congestion window),「限制发送端发送数据最多没有收到 ACK 确认包的大小，超过拥塞窗口范围后，就不会继续发送数据了」。
拥塞窗口会随着网络情况的变化动态的调用自身的大小，大体的变化规则是：如果没有出现拥塞，就扩大窗口大小，否则就缩小窗口的大小。
拥塞控制算法主要包含四个部分：
- 慢启动
- 拥塞避免
- 拥塞发生
- 快速恢复
慢启动
当一个新的TCP连接开始时，无法确定是否用拥塞发生，一开始不会发送大量的包，而是从最小的发送窗口开始，后续会采用倍增的方式增加窗口的大小，窗口大小从 1 开始，后续慢慢增大到 2、4、8 等。
指数增加速度会越来越快，窗口扩大的一定的程度，就会减慢增加的速度，改成线性增加，这时候就进入拥塞避免阶段。
拥塞避免
慢启动和拥塞避免的临界点叫做「慢启动门限」 ssthresh （slow start threshold。
cwnd < ssthresh 时，使用慢启动算法。
cwnd >= ssthresh 时，就会使用「拥塞避免算法」。
ssthresh 大小一般是 65535 字节。拥塞避免的规则是：「每当收到一个 ACK 时，cwnd 增加 1/cwnd」。就变成线性增长了。
拥塞发生
拥塞避免将原来的指数增长改成了线性增长，虽然增长速度减慢，但 CWND 窗口还是在增长阶段。随着窗口进一步缓慢增加，网络还是会遇到阻塞的状态，会出现丢包的情况。就需要对丢包进行重传。
重传机制有两种：
超时重传
快速重传
当发生超时重传时，sshresh 和 cwnd 的值会发生如下变化：
sshresh 变成 cwnd 的一半
cwnd 重置为 1
cwnd 重置为1，表示直接进入慢启动状态。
上面的超时重传速度变化太快，而快速重传是一个相对温和的方案。如果我们连续 3 次收到同样序号的 ACK，包还能回传，说明这个时候可能只是碰到了部分丢包，网络阻塞还没有很严重，无需重置 cwnd。
此时 ssthresh 和 cwnd 变化如下：
cwnd = cwnd/2 ，也就是设置为原来的一半;
ssthresh = cwnd
并进入到快速恢复阶段。
快速恢复
快速恢复主要是将 cwnd 恢复到正常大小，上面说的 cwnd 设置成原来的一半，ssthresh 设置成 cwnd 的大小。
快速恢复算法如下：
重传丢失的数据包。
如果接收到重复 ACK 确认，cwnd 增加 1。
如果接收到新数据的 ACK 确认，就将 ssthresh 恢复到慢启动时期的值，因为返回新数据的 ACK 确认，表示网络阻塞已经结束，可以恢复到之前的状态，cwnd 也可以指数或者线性增加。
总结
TCP 提供基于字节流、可靠的数据传输，为了确保数据的可靠性，做了很多工作：
报文段序号和确认号
每个报文都有序号和确认号，序号表示报文段第一个字节号，确认号表示下一个接收字节的序号。
发送确认和重传机制
每个报文段发送后，都会确认应答 ACK，表示已经报文段已经成功发送。
当网络异常数据包无法达到时，就会触发重传机制。重传主要有两种方式：超时重传和快速重传。
超时重传：设置一个定时器，超过时间未收到确认应答，就会重新传数数据包。这个重传方式周期比较长。
快速重传：快速重传不会等待超时时间到了再重传，是以数据为基点，发送多次报文段，当接受到重复的确认应答号 ACK 时，直接重传所有的报文段。可以使用 SACK 记录哪些报文段已经成功接收了，只重传没有被成功接收的报文段。
滑动窗口
报文段拆分，TCP 将要发送的数据拆分适当大小的数据包。
引入窗口的概念，这个窗口大小是由接收方来决定，表示接收方可以接收的缓存大小。在窗口范围之内， TCP 可以连续发送多个数据包给接收方，当数据包发送并且有确认应答，整个窗口会往后移动，继续发送新的数据。
随着数据传输的速度和网络情况，接受方可能会动态修改窗口的大小，以此来控制数据传输的速度。
滑动窗口能流量进行控制，控制数据发送的速度和频率，避免出现拥塞情况。
拥塞控制，在网络传输中可能会出现大量的数据请求，而固定的网络宽带可能处理不过来这么多数据传输，容易形成阻塞的情况。TCP 遇到网络拥塞时，会自动减少自己发送包的数量，这样网络拥塞情况就会缓解。TCP 发送端定义拥塞窗口 CWND,表示没有接收到 ACK 确认数据的最大发送量。拥塞控制算法主要包含四个部分：
慢启动：开始一个新的连接时，从较小的发送窗口开始，然后「指数增长」增加 CWND 窗口大小，知道达到慢启动门限。
拥塞避免：窗口达到慢启动门限临界点时候，慢启动阶段结束，这个阶段，窗口大小「线性增加」，增长速度比较慢，避免发生网络拥塞。
拥塞发生：窗口进一步缓慢增加，网络还是会遇到阻塞的状态，会出现丢包的情况。就需要对丢包进行重传。此时有两种重传机制：超时重传和快速重传。超时重传，是窗口大小重置为 1，数据传输又恢复成慢启动时的速度。这种传输速度急剧下降，不利于系统稳定，由于窗口大小限制，网络传输次数更多，拥塞的情况也会更大。而快速重传是相对温和的方案，此时认为网络只是暂时有阻塞情况，将窗口大小 CWND 改成原来的一半，并进入快速恢复阶段。
快速恢复：重传丢失的数据包，如果接收到重复 ACK 确认，cwnd 增加 1。如果接收到新数据的 ACK 确认，就将 ssthresh 恢复到慢启动时期的值，因为返回新数据的 ACK 确认，表示网络阻塞已经结束，cwnd 也可以指数或者线性增加。
696
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
