说起来 TCP 的连接与释放真是个浪漫的故事呢！( 三 ) _TCP

SYN：同步，1意味着要发起会话。

FIN：finish，1意味着释放连接。

窗口：同步接收端和发送端窗口大小的，接收端先发，发送端根据接收端的窗口尺寸确定发送端窗口尺寸。

检验和：略，上已讲。

紧急指针：只有URG为1才有用。

文章插图
滑动窗口
1、TCP 可靠通信的具体实现：

TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口；
TCP 的可靠传输机制用字节的序号进行控制；
TCP 两端的四个窗口经常处于动态变化之中；
TCP连接的往返时间 RTT 也不是固定不变的，需要使用特定的算法估算较为合理的重传时间；

2、窗口动态变化-以字节为单位的滑动窗口：

文章插图

A的发送窗口是由B的接受窗口长度决定的；
在没有收到B确认收到之前，A不能删掉滑动窗口内的内容；
A可以持续给B发送，直到A的滑动窗口内数据都发送成功；
B收到后给A发确认收到的反馈ack（下一个应该发送的字节的序号），A收到后，就可以滑动窗口到对应的位置。例如B反馈ack是7，那么A的滑窗可以移动到7位置，1-6删除，21-26可以继续发送。

相关名词：

文章插图

P3 – P1 = A 的发送窗口（又称为通知窗口）；
P2 – P1 = 已发送但尚未收到确认的字节数；
P3 – P2 = 允许发送但尚未发送的字节数（又称为可用窗口）。

文章插图
TCP流量控制
流量控制(flowcontrol)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。
利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制，收方返回的 rwnd中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送，发送方在rwnd窗口之后的数据不允许发送。
流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。

文章插图
死锁解决：
接收方返回窗口大小为0，可能是缓冲区已满，需要处理缓存中的字节，发送端收到滑动窗口为0，不再发送，但是数据还没发送完，这就造成了死锁；
如果在某个时候，接收方缓冲区有空间了，于是发送了一个非 0 窗口的通告给接收方，不幸的是这个通告丢失了，而发送方却还在死等接收方的非 0 窗口通告，接下来就成了死锁；
TCP 为每一个连接设有一个持续计时器：

若持续计时器设置的时间到期，就周期性的向接收方发送 1 字节的 0 窗口探测报文；
若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器，等待重传；
若窗口不是零，则死锁的僵局就可以打破了。

文章插图
三次握手齐白首
传输连接有三个阶段，即：连接建立（三次握手）、数据传送和连接释放（四次挥手）。

文章插图
头两次握手除了确定双方都能联通外，还通知了双方的一些端口信息：
A：我们谈恋爱吧；
B：好的（如果“好的“丢了，A就不知道B的态度，感情就无法建立起来）；
C：走你~
第三次握手原因：假如把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机A和B之间的通信，假定A给B发送一个连接请求分组，B收到了这个分组，并发送了确认应答分组。
按照两次握手的协定，B认为连接已经成功地建立了，可以开始发送数据分组。可是，B的应答分组在传输中被丢失的情况下，A将不知道B是否已准备好，A认为连接还未建立成功，将忽略B发来的任何数据分组，这样就形成了死锁。