文章目录
- 认识TCP
- TCP协议段格式
本篇主要总结的是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请求进行识别