TCP总结笔记

TCP作为面向连接的协议在实际应用中占据很重要的地位，其是可靠传输协议，保证了数据流的稳定传输。现在对TCP做一个简单的笔记；

一.TCP在通讯中的概览

如上图所示，TCP是传输层协议，其底层是通过IP层来进行数据收发的；

下面是IP协议的结构：

下面是TCP数据在IP报文中的位置：

下面是TCP协议的结构：

下面是TCP数据传输过程：

---

二.TCP通讯的握手和释放

首先，TCP在传输数据前，需要进行三次握手，流程如下：

但是也存在特殊情况，就是如果在同一主机中，当Peer两端同时发起SYN来建立连接时，就出现了四次握手来建立连接，如下图：

其次，TCP在结束数据传输时，需要进行四次挥手来释放连接：

再来看看，TCP的总的时序图：

然后就是TCP的有限状态机图：

---

三.TCP可靠传输流程

1.TCP可靠传输的流程的基础：
（1）滑动窗口协议和连续ARQ协议；
（2）流量控制和阻塞控制；
2.达到的效果：
（1）传输信道不产生差错；
（2）不管发送方以多快的速度发送数据包，接收方总是来得及有序的处理接收到的数据（这有赖于累计确认、超时重传和拥塞控制等策略）

3.“停止等待协议和自动重传请求ARQ”对比“滑动窗口协议和连续ARQ协议”
为了达到“传输信道不产生差错”的目的，需要有发送回复机制以及数据重传机制，
最简单的实现方式就是“停止等待协议和自动重传请求ARQ”策略，如下图：

当A给B发送数据包M1后，需要等待B回复确认包后，A才能发送M2，这就是“停止等待协议”；
当A给B发送数据包M1后，等待确认数据包超时后，就会重新向B发送M1，直到收到确认包，或者超过重传次数然后向应用层报错；

在这基础上，为了加快传输速度以及减少流量，于是，出现了“滑动窗口协议和连续ARQ协议”，如下图：

发送方和接收方商议得出一个窗口长度，发送方在发送数据时，并不只发送一个数据包，而是发送连续的多个数据包，然后接收方接收数据时，也不是每个数据包都回复，而是回复连续数据包的最后一个数据包（若收到的数据包不连续，就取与以前已收数据包连续的最后一包，若没有数据包与以前的数据包连续，则不回复），然后接收方将窗后向前滑动。发送方在收到确认包后，也把窗口向后移动。

4.流量控制
流量控制主要解决了发送方发送能力和接收方接收能力不匹配的问题，同时也限制了流量，如图：

在建立连接时，发送方根据接收方提供的窗口大小，构造自己的窗口，图中显示了前沿和后延两个数据指针；
当然，在建立连接后，还需要有机制保持发送方和接收方的窗口同步，如图：

注意，为了解决“零窗口”报文导致的死锁状态，TCP提供了“持续计时器”的机制，当发送方收到“零窗口”报文后，会启动计时器，若在时间到达之后就会发送“零窗口探测报文”，以此来通过轮询方式来解决死锁的状态；

5.拥塞控制
流量控制是用于点到点传输的控制策略，而拥塞控制是针对整个网络环境的策略。
当网络环境恶化时，拥塞控制将会有效的控制各点的数据流量，以尝试达到恢复网络环境的目的，具体措施如下：
（1）通过慢开始来确定拥塞窗口cwind，同时避免瞬间的大流量造成网络的瘫痪：

（2）通过快重传和快恢复来调整cwind：

（3）根据接收窗口rwind和拥塞窗口cwind，来重新确定发送窗口：
发送窗口的上限值 = Min[rwnd， cwnd]

（4）路由器中，为了维持其稳定性，就出现了流量超载时随机丢弃数据包的机制，此机制如图：

为了迎合这种的策略，减少数据包丢失造成的对TCP通讯的危害，TCP出现了随机早期检测机制（random early detection）RED，具体做法就是：监控路由器发送队列的平均队列长度Lav，若发现逼近拥堵，则随机的选择本地中的几个连接来提前告知拥塞情况，以提前降低网络流量。

---

四. 笔记后的问题和记录

1.重传时，发送方和接收方如何处理重复收到的数据包？
答：接收方会丢弃这个数据包同时回复一个确认包，发送方会直接丢弃这个重复的确认包；

2.若因为物理故障或其他原因，接收方一直没收到发送方的任何数据包，导致接收方处于停止状态而无法通知应用程序AP来关闭连接，怎么办？
答：
（1）TCP协议栈里提供了keepalive机制，开启了这个属性后，tcp将会定期的发送keepalive数据包进行连接检测，若发现异常，则报告给AP；
（2）同时，也可以应用层实现心跳包机制，一般是client发送给server，server和client通过心跳来判定连接是否有效；