本篇主要总结的是TCP协议的一些字段
认识TCP
TCP协议全称是传输控制协议，也就是说是要对于数据的传输进行一个控制
以上所示的是对于TCP协议进行数据传输的一个理解过程
全双工
至此就可以对于TCP协议是全双工的来进行理解了，所谓全双工其实就是有自己对应的接收缓冲区和发送缓冲区，所以这就意味着TCP协议的发送和接受是完全可以分开独立进行的，这就和UDP协议有很大的不同，因此我们说TCP协议是全双工的
发送接收的本质
对于发送和接受的本质来说，其实都是一种拷贝，以系统调用read和write来说，站在操作系统上是把数据从磁盘加载到内存当中，而这样的加载过程的本质其实就是一个拷贝的过程，经过这样的拷贝从而把数据从磁盘中拷贝到内存中
而以recv和send为例，这两个系统调用展现出的本质实际上也是一种拷贝的过程，只不过这里的拷贝是把数据从内存拷贝到网络，或是把数据从网络拷贝到内存，这其实也是一种拷贝
TCP协议段格式
下面就要进行的是对于TCP协议段的阐述，也是本篇的重点内容
在进行UDP的学习当中，可以看到UDP的协议段定制是比较简单的，它是面向数据报的，所以只需要根据数据长度来进行判断发送成功或者是失败，并且它并不关心数据是否递达，而对于TCP来说就不是这样，它关心的点更多，它需要确保数据是否送达，这就必定意味着它需要传递更多的消息
报头和有效载荷的分离
在整个网络协议栈中，首先要关心的内容必然是对于报头和有效载荷分离的这个过程，因为对于任何一种协议来说都必须有这样的功能，结合报头和与报头进行分离，有这样的操作能力才能使得信息可以在网络协议栈中进行传输
那对于报头和有效载荷分离的这个过程来说，必然涉及到的一个点是如何把数据传输到上层当中，于是就要引入第一个报头参数，4位首部长度
4位首部长度
对于TCP的标准报头来说，它占据的是20个字节，而有效载荷则是最下面的数据区，那中间的选项其实严格意义来说也属于报头中的一种，因此就有了这个首部长度的概念
4位首部长度的最大取值是15，那如何表示20个字节呢？其实是因为在计算的时候四位首部长度是有基本的计算单位的，计算单位是4字节，这就意味着这个范围实际上是0-60字节，所以将报头和有效载荷的分离就直接借助这个4位首部长度就可以，本质上是通过固定长度和自描述字段
源端口号和目的端口号
这个字段其实和UDP是一样的，都是用来确认发送双方的一些信息，这样可以准确的通过端口号找到所需要传递的进程
16位窗口大小
TCP协议是面向字节流的，所以它和文件其实是有些相似的，那么现在的问题是对于这个协议来说，通信的双方该如何进行判断，对方的缓冲区中的数据到底满了还是没满？换句话说，发送数据的速度该如何进行判断呢？这就用到了这个窗口大小的概念了
对于窗口大小来说，值得是自己的接收缓冲区中剩余空间的大小，那么基于这个数据段，就能告诉对方我当前的缓冲区还有多少内容，如果此时剩余空间已经没有了，那么就代表我的接收缓冲区已经满了，不要再给我发送数据了，反之就是可以快点继续发，我当前缓冲区可以接受数据
32位序号
提到32位序号，就必须要提及确认应答机制了
TCP协议是传输可靠的协议，那么这个可靠该如何理解？它必然是因为有它特定的机制来保证它的传输是可靠的，因此下面就要介绍可靠的来源：确认应答机制
通俗来讲，这个机制的意思就是当前有主机A和主机B，当主机A向主机B发送数据的时候，主机B在接收到消息之后会传递给主机A一个消息，表示自己收到了这个消息。根据这个原理，我们说这就叫做是一次可靠的传输，落实到具体的来说，当我传输出去的数据收到了应答，那么就说明这次的传输是可靠的，意味着对方已经收到了我的消息，那反过来说，对于没有应答的数据，就不能保证它的可靠性，因此最新的一条消息是没有应答的，这也就意味着是不知道这个消息到达的结果如何，也就说明并不存在100%可靠的网络协议，不过TCP可以很大程度上帮助使得协议本身变得可靠
序号问题
下面要谈的一个问题是，数据的乱序问题
假设现在TCP的服务端向客户端发送了10条消息，那抵达到客户端后，这10条消息是依次抵达的吗？理想状态下是这样，但是实际上在进行基站的传输过程中，肯定不是这样的，所以带来的一个问题是，TCP数据传输造成的乱序，本身就是TCP协议不可靠的一种体现，我们以下图为例
上图所示的就是TCP最基本，最原始的通信过程，也是一种理想的通信过程，但是实际上传输遇到乱序是很正常的现象，那么TCP是如何处理这样的现象的呢？
TCP协议引入了序号的概念，TCP将每个字节的数据都进行了编号，每一个编号就叫做是序列号
该如何理解这个概念呢？我们可以认为TCP的发送缓冲区就是一个数组，而在这当中填入了很多的数据，天然的每一个字节就会有一个字节编号，这个编号本质上就数组的下标，而在发送的报头中会有对应32位序号，当发送一个TCP数据的时候，就会在报头中填写对应的数据块的最后一个字符的下标，这就意味着是当前发送的报文序号，这样就把数据发送过去了
32位确认序号
反之我们对应的是32位确认序号，这个确认序号代表的是确认序号之前的数据已经全部收到了，那这个确认序号填多少呢？它填充的是收到报文序号+1，比如第一次发报文序号是1000，第二个报文的序号是2000，那么在进行应答的时，对应的确认序号就是1001和2001，以下图为例
为什么要这样进行规定呢？这里我目前给出的解释是，表示的是1001之前的报文已经全部收到了，它表示的是当前确认序号之前的数据已经都收到了，那现在假设，发送了很多的报文，其中有一个报文丢失了，虽然我此时没有收到1001之前的内容和2001之前的内容，但是3001之前的内容已经收到了，那么就意味着服务器已经安全的把3001的报文接受了，那么就算要进行重传，也只需要把1001和2001进行传递就可以了
6个标记位
下面要谈的内容是6个标记位的问题，对于服务端来说，它会收到各种各样的来自很多客户端的TCP请求，那么在这些请求中其实是有很多类型的，比如说有请求连接，请求断开，请求申请数据，请求发送数据，那么这些请求该如何进行区分呢？就依靠这6个标记位，就可以实现不同类型的TCP请求进行识别