TCP协议入门级基础知识梳理。
image.png
一. 流程图简述
TCP协议是可靠的传输协议。为了实现可靠传输，所以采用连接管理和应答确认。
连接管理主要是建连时的三次握手和释放连接的四次挥手。
为了实现应答确认，采用了序列号。传输过程中，如果丢包了，就要超时重传。由于每次发送数据时都要等待上一条数据的ACK到达，传输速度较慢，于是引入了滑动窗口机制。滑动窗口采用ACK累计确认，这时候如果发生丢包，就会进行快速重传。
采用滑动窗口机制，虽然发送速度快了，但是可靠传输不太能保证了。发送数据太快，就可能造成接收方来不及接收和网络拥堵。于是就有了流量控制(由接收方控制)和拥塞控制(由网络健康状况控制)。
这时候如果想让数据传输再快一点，就可以采用延时应答和捎带应答。
二. 连接管理
1. 三次握手协议
① client --> server：syn包，请求建立连接
② server --> client：server收到①的syn包后，申请缓存资源。同时发送[ack+syn]包
③ client --> server：client收到②的包，申请缓存资源，建立连接。
1.如果将server --> client的ack+syn分开发送，三次握手就变成四次握手。
2.建立连接后，client突然故障了，怎么办？
TCP设有一个保活计时器。server每收到一次client的请求后都会复位这个计时器。通常设置2h。若2h内没有收到client端的任何数据，server就会每个75s发送一个探测报文。若连续发送10个探测报文都没有反应，则server认为client出现故障，然后就关闭连接。
更深一步：为什么tcp协议三次握手
2. 四次挥手协议
image.png
① client --> server：client结束报文发送，向server发送fin包，进入fin_wait_1状态。
② server --> client：server收到①的fin包，发送ack报文，进入close_wait状态。此时处于[半关闭]状态，即client没有再发送数据，但若server发送数据，client依然要接收。
③ client接到ack后，进入fin_wait_2状态，此时依然需要接收server发送的数据。
④ server --> client：server将最后的数据发送完毕，就向client发送连接释放报文fin包，进入last_ack状态，等待client的最后确认。由于此时仍是[半关闭]状态，因此可能又发送了一些数据。
⑤ client--> server：client接收到fin包后，发出ack确认，进入time_wait状态。
⑥ server收到最后的ack后，立即进入close状态，释放连接。
⑦ client等待 2*MSL(最长报文寿命)，进入close状态，释放连接。
2*MSL的作用：
1> 重传最后一个ack报文(如果server没有收到ack报文，会重传fin包)。
2> 2*MSL可以使网际路由上的残留报文彻底消失，以免端口被重复利用时，这些残留报文可能会干扰新的连接。(残留报文：因为各种原因导致数据报文走的时间太长，重传报文都收到了，原始报文还在路上)
三. 确认应答
序列号：① 应答；② 将接收到的数据根据序列号进行排序，并去掉重复序列号的数据。
序列号是tcp可靠传输的保证之一。
tcp数据包中的序列号不是以报文段来进行编号的，而是将连接生存周期内传输的所有数据作为一个字节流，序列号就是整个字节流中每个字节的编号。
1.应答机制
1. ACK确认
tcp传输数据的过程中，每次接收方收到数据后，都会发送ACK报文进行确认。ACK报文中带有对应的确认序列号，告诉发送方接收到了哪些数据，下一次的数据从哪里发。
2.ACK累计确认
在滑动窗口机制中，接收端并不需要每收到一个分组就返回一个应答，可以连续收到分组之后统一返回一个应答。这样可以节省流量。
tcp头部的ack字段就是用来累计确认，表示已确认的字节序列号+1，也表示期望发送端发生的下一个分组的起始字节号。
3.延时应答
接收方在收到数据后，并不会立即回复ack,而是延迟一定时间。目的如下：
1.ack是可以合并的。如果连续收到两个tcp包，只需回复最终的ack，可以降低网络流量。
2.如果接收方有数据要发送，那么就可以在发送数据的tcp数据包里，带上ack信息。避免大量的ack以一个单独的tcp包发送，可以降低网络流量。
4.捎带应答
接收端在给发送端发送数据时，捎带着向发送端去确认应答。应答的内容是接收端已经收到发送端之前发送的数据。
2. 超时重传
发送端在发送一个数据时会同时开启一个定时器，若是在这个时间段内没有收到刚才发送数据的ack报文，则对该报文进行重传。
超时重传的问题：
1.增加端到端的时延：当一个报文段丢失，会等待一定的超时周期才进行重传
2.引起不必要的重传：当一个报文丢失，在等待超时的过程中，其后的报文已经被接收端成功接收，但得不到确认，发送端会认为丢失了，引起不必要的重传，浪费资源和时间。
3. 快速重传
冗余ACK(dup ack)：tcp采用累计确认机制，当接收端收到比期望序号大的报文段时，便会重复发送最近一次确认的报文段的确认信号。
快速重传：发送端收到三次dup ack，不用等到超时，直接重传。
4. 滑动窗口
概念：类似窗口，用来告诉发送端可以发送数据的大小，或者说窗口标记了接收端缓存区的大小
知识点：
1.接收端将自己可以接收的缓冲区大小放到tcp首部中的“窗口大小”字段，通过ack来通知发送端
2.窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，即就是说不需要接收端的应答，可以一次连续的发送数据
3.操作系统内核为了维护滑动窗口，需要开辟发送缓冲区，来记录当前还有那些数据没有应答，只有确认应答过的数据，才能从缓冲区删掉。如果发送缓存区太大，就会有空间开销。
4.接收端发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知发送端。发送端收到通知后，就会减慢发送速度。
5.如果接收端缓存区满了，就会将窗口大小设置为0。发送端不再发送数据，但会定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
6.滑动窗口中的数据类型：① 已发送但未收到确认；② 可以发送但未发送
5. 流量控制
概念：防止发送端发的太快，耗尽接收端的资源，从而使接收端来不及处理。
接收端抑制发送端的依据：接收端缓冲区的大小。
流量控制的目标是接收端，怕接收端来不及处理。
流量控制的机制是丢包。
6. 拥塞控制
概念：防止发送方发的太快，使得网络来不及处理，从而导致网络拥塞。
拥塞控制的目标是网络，怕网络拥堵。
拥塞控制的机制：定时器超时和收到三个dup ack。
拥塞控制的表现：丢包和时延变长。
为什么会有拥塞控制？
流量控制虽然可以高效可靠的传送大量数据，但如果在刚开始阶段就发送大量数据，可能会导致网络拥堵，因为网络上的计算机太多。
7. 流量控制和拥塞控制的对比
1. 相同点
- 1.现象都是丢包
- 2.实现机制都是让发送方发得慢一点，发的少一点
2. 不同点
- 丢包位置不同
- 流量控制的丢包位置在接收端上
- 拥塞控制的丢包位置在路由器上
- 作用对象不同
- 流量控制的对象是接收端，怕发送端发的太快，使得接收端来不及处理
- 拥塞控制的对象是网络，怕发送端发的太快，造成网络拥塞，使得网络来不及处理
3. 联系
- 流量控制
发生在发送端和接收端之间，只是点到点之间的控制。 - 拥塞控制
全局性的过程，涉及到网络中所有的主机、路由器和降低网络传输性能的所有因素。
