文章目录
- TCP报头格式
- 端口号
- 序号和确认序号
- 确认应答（ACK）机制
- 超时重传机制
- 首部长度
- 窗口大小
- 报文类型
- URG
- ACK
- SYN
- PSH
- FIN
- RST
- 滑动窗口
- 滑动窗口的大小怎么设定怎么变化
- 滑动窗口变化问题
TCP报头格式
端口号
两个端口号比较好理解，通过端口号来找到指定的进程
序号和确认序号
先要认清这两个序号首先得了解TCP的确认应答（ACK）机制
确认应答（ACK）机制
根据生活例子来说，当我们再和别人聊天时需要得到对方的回复才能够确定对方能够听到我们的话。对于TCP通信也是如此，当一端向另一端发送数据后，对端收到数据后需要告诉发送端已经收到了，这样发送端才能够知道，因此作为接收端就会应答确保已经接收到数据了
这种机制就是确认应答机制
在真实的使用场景中，TCP发送端如果是一条数据发送后等收到接收端的应答再发送另一条数据，这样效率就非常的低。所以真实的场景中，发送端会一下子发送多条数据。那么为了确保每一条数据都被接收端接收到了，那么接收端就需要对应每一条数据都进行应答，那么如何保证接收端应答的是对应的数据。或者说如果发生了丢包，接收端不会应答该条数据那么作为发送端如何知道是哪一条数据没有收到接收端的应答呢
这就引进了序号和确认序号的概念：
序号可以用来标识数据之间的不同，接收端收到数据后应答该条数据就会返回确认序号，而这个确认序号就是数据序号+1 。这样的目的是告诉发送端下次发送数据的序号从这个确认序号开始。
有了序号和确认序号的配合后，应答机制就能保证应答的是指定的数据
需要注意：接收方应答了一个确认序号后，就代表着这个确认序号之前的所有序号的数据都已经接收到。
也就是说假如接收端接收到了序号1000和3000的数据，但是没有收到2000的数据，那么接收端应答的确认序号只会是1001。那么这里又得引出一个概念：
超时重传机制
根据上述的例子，如果接收端没有收到2000的数据，那它就只会发送1001的应答。那么作为发送端迟迟都等不来2000的数据的应答，那发送端就会意识到数据丢包了。这时候作为发送端就会再次向接收端发送数据。
关于数据丢包就会出现另一种情况，上述的情况是发送端发送的数据丢包了。那么如果接收端接收到了数据，但是它发送的应答丢包了呢。这种情况同样会导致发送端迟迟收不到应答而重新发送数据，那假如应答老是丢包那么发送端就会发送很多份相同的数据，这时候作为接收端就会收到很多重复的数据。所以接收端需要对数据去重，而去重就可以利用序号实现，因为每个相同的数据都会有相同的序号
首部长度
- TCP协议的报头是有标准长度的也就是最少长度，长度为20字节。因此读取时首先会读取20字节
- 首部长度为4个比特位，也就是说范围在[0000 - 1111]也就是[0 - 15]
- TCP报头的总长度 = 首部长度 * 4字节
- 因为TCP协议的标准长度为20字节，因此首部长度初始为5(0101)
窗口大小
首先的了解TCP协议发送数据和读取数据是在哪里得到的。
事实上，接收端调用read函数将数据读取并不是从TCP的报文中读取的，而是从一个缓冲区中也就是接收缓冲区中读取的。而发送端调用write函数写数据发送也不是直接写到TCP的报文中，而是写到发送缓冲区中
那么对于缓冲区而言就必定有大小，窗口大小就是指接收缓冲区的大小。TCP的报头中要含有自己缓冲区剩余的大小，为了告诉发送端自己的缓冲区大小还剩多少，让发送端做出发送策略调整，防止出现发送的太快导致来不及读使得缓冲区满了，也不能发的太慢
报文类型
事实上，TCP的报文也是有类型的，接收端要根据不同类型的报文做出不同的动作
这几个就对应着TCP不同的报文类型，而这几个都是一位来着，置1或置0
URG
数据对于接收方而言，乱序就是不可靠的现象。所以要对收到的数据进行排序，因为报文是有序号的所以可以保证数据的按序到达。那么如果需要排队那就难免会有需要插队的情况。
URG：代表着有需要尽快读取的数据
而这个要配合这紧急指针使用，通过紧急指针知道一个偏移量在报文的有效数据中通过偏移量找到该数据
ACK
ACK用于建立连接时应答确认
SYN
用于请求连接
PSH
催促接收端尽快读取数据，避免缓冲区满
FIN
用于断开连接请求
RST
由于连接并不一定会成功，RST就用于重置连接
滑动窗口
因为发送端发出数据后接收端不一定会接收到数据，也就是出现丢包。因此发送端在发送出去数据后并不能直接将数据抹除，需要等待接收端应答后才可以抹除。那么这份数据保存在哪里呢？
这种数据就保存在滑动窗口中
图中为缓冲区的分布，其中中间部分就是滑动窗口
滑动窗口的大小怎么设定怎么变化
对于缓冲区本质上就是一个数组，所以滑动窗口就有这个数组中的两个下标控制大小
而决定缓冲区的大小和接收端的接受能力有关，也就是不管未来滑动窗口怎么变化都一定要保证在接收端的接受范围内。
因为数据都是有数据序号的，因此滑动窗口的变化：win_start = 应答收到的数据确认序号，win_end = win_start + 对端的窗口大小
滑动窗口变化问题
窗口会往左移动吗？
答案肯定是不会的
窗口一定会向右移动吗？
肯定窗口的变化可以得出，只有收到应答时窗口才会滑动，所以也有可能是不动的，但是如果动了一定是向右动
滑动窗口移动的本质就是数组下标的更新，所以窗口有可能会不动的
同样窗口也有可能变成0，例如对方的缓冲区满了
如果一直移动，空间不够了怎么办
针对这个问题，操作系统内核将发送缓冲区组织为环形结构了
![Java并发编程（三）线程同步 上[synchronized/volatile]](https://img-blog.csdnimg.cn/a07261944dfa424c8df9453179a0257d.png)
