TCP基础（2）

前边（1）基本上说明了可靠传入的目标以及实现方式，那么把那些东西都实现一下并且解决更多的问题，这就是TCP。
TCP协议，也叫传输控制协议，是一种可靠传输的协议。因为可靠，被广泛的应用。是SOCKET里面的重点。现在N多应用层协议都是封装了它来实现数据的传输。TCP的基本流程就是：建立连接->传数据->断开连接。所有many people都说这是打电话。so 就按照流程来

建立连接

接收端和发送端首先是需要建立连接才能通信的。建立连接的过程，被形象的成为握手，建立连接的机制，也叫做握手机制
（1）三次握手：这就是大名鼎鼎的三次握手了。
在这里插入图片描述
没图怎么行？三次握手很简单，首先client给server发送同步请求SYN报文，并且发送序列号x。这个x是很有用的，server接收到之后，发送SYN，把X+1给client，并且给他一个自己的序列号。client接收到之后再给server一个Y+1.
两个小问题：
1.为啥要发序列号？
这其实是为了标识这个包，因为之前就说了，包是可能丢失的，丢失之后就要重传，那么怎么标识这个包？给它一个ID就行了
2.为啥要+1？
这个也其实为了告诉client，你发的我接受了，并且准确的告诉他接收到的是哪一个包。因为可能存在网络延迟，导致client在固定的时间内没有受到应答，就发了好几个包，这些包都有序列号，所以这样操作在重复包来临时可以唯一标识他们。

两次存在的问题

三次握手时，第三次似乎看起来没必要？？逻辑分析一下，client问server在不在，server告诉client自己在，那么就可以开始通信了啊，为啥client还要告诉server自己在？？？似乎是多余的。
其实不然，因为server要和client通信，就需要分配CPU，内存这些资源，这是十分珍贵的，尤其是高并发状态下，本来服务器就忙不过来了，如果你是一个坏人，故意调戏他，每次发送第一次SYN之后就不管了，那么服务器每次都要给你准备点通信的资源，那完了，我开个几百万的线程瞬间就把服务器的资源抢占了，服务器gg。所以第三次握手实际上对client看上去没必要，对于服务器来说十分的重要。
当然了，在包重复时，也会产生对应的问题，所以第三次握手时必要的。

开始通信

这个和之前说的一样，可靠传输，滑动窗口机制。

断开连接

数据传输完就要断开连接了，这时也需要双方的配合。
四次挥手：断开连接不是三次握手了，是四次挥手。其实本质上是一样的。
在这里插入图片描述继续看图，当滑动窗口滑到最后时，数据都发完了，client发送FIN报文，开始告诉服务器我的数据发完了，我要关机。服务器ACK一下，此时，接收到ACK的client进入CLOSE_WAIT状态，等待关机。然后服务器继续发送FIN报文，告诉client你可以关了，client发送ACK断开连接。
这里也会有一点问题，就是为啥client会进入CLOSE_WAIT状态。其实很好解释，因为你发完了，别人不一定收完，还有包在链路上没有到达，等所有的达到了，再让client关机。所以四次挥手其实每一步都是必要的，没有多余。

完成传输

到这里，TCP已经圆满完成任务了。建立了一个可靠的传输，但是这其中还是右许多的问题的。

RTT设置的问题

前边说了，如果一个包在RTT内没有被ACK，那么就开始重传。那么RTT怎么设置呢？静态RTT？？但是网络环境时刻在变化，一会好一会坏，RTT太小导致大量数据被重传，浪费资源，太大传输效率变低。对于这个东西，可以采用自适应RTT，至于方法，不再深入讨论。

流量控制

这也是TCP的一个十分重要的设计。
起因：一个很现实的问题，接收端，收到包以后，其实是存在起来的（这个地方我忘了叫啥，好像叫做XX缓存？实现是通过啥IO多路复用？？留个坑，等我想起来了填）。然后应用层会把数据抽取上去，解析（或者说解压）。显然，这个速度比发送要慢多了。所以当这个缓存被填满时，包就会被自动丢失。
总结一下就是发送端太快，需要控制合适的速度。
解决：注意，接收端的接受也是通过滑动窗口实现的。在这里插入图片描述比如这个，接收端的窗口空隙还有3个位置，这个时候，发送端发送的包不能超过3个，多的就会被丢弃。所以把这个信息告诉发送端。
发送端：
使用当前窗口大小和发送来的窗口大小的最小值作为窗口大小，发送。
那么这样窗口不是越来越小？？
不是，如果没有丢包，那么就开始增加窗口大小。（具体方式在上一篇结尾有说过AIDM）。
具体实现：
在这里插入图片描述图片十分的清晰，不再多解释了。