TCP协议

Tcp协议
- 可靠性
- - 冯诺依曼体系结构
- TCP的协议格式
- 序号与确认序号
- 窗口大小
- 六个标志位
确认应答机制（ACK）
超时重传机制
连接管理机制

Tcp协议

TCP全称为 “传输控制协议”（Transmission Control Protocol）

TCP协议被广泛应用其根本原因就是提供了详尽的可靠性保证基于TCP的上层应用非常多比如HTTP、HTTPS、FTP、SSH、MySQL等。

可靠性

为什么网络中会存在不可靠

冯诺依曼体系结构

在这里插入图片描述
这里的输入设备内存输出设备 cpu这些硬件都是相互独立的

如果它们之间要进行数据交互就必须要想办法进行通信这几个设备是用“线”连接起来的

其中连接内存和外设之间的“线”叫做 IO总线 而连接内存和CPU之间的“线”叫做 系统总线

由于这几个硬件设备都是在一台机器上的因此这里传输数据的“线”是很短的传输数据时出现错误的概率也非常低

但如果要进行通信的各个设备相隔千里那么连接各个设备的“线”就会变得非常长传输数据时出现错误的概率也会大大增高此时要保证传输到对端的数据无误就必须引入可靠性

总之网络不可靠的根本原因就是长距离传输数据使用的‘线’太长了所以说数据在长距离传输的时候可能会遇到一些错误而TCP就是在这种背景下诞生的 TCP就是一种可靠的协议

单独的一台计算机可以看作成一个小型的网络计算机上的各种硬件设备之间实际也是在进行数据通信并且它们在通信时也必须遵守各自的通信协议只不过它们之间的通信协议更多是描述一些数据的含义

为什么会存在UDP协议？

TCP协议是一种可靠的协议而UDP是一种不可靠的协议

TCP是一种可靠的协议这也就意味着TCP需要做更多的工作来保证数据传输的可靠并且引起不可靠的因素越多我们要保证可靠的成本就越高其中常见的不可靠情况有丢包乱序等而我们的TCP由于要保证可靠所以说要想办法解决这些问题

UDP协议是不可靠的协议这也就意味着UDP不需要考虑数据传输时需要处理的问题因此UDP无论是使用还是维护都足够简单

但是虽然说TCP的使用比UDP更加复杂但是TCP的效率缺不比UDP低

如果我们严格要求了数据在传输过程中可靠性那么我们就必须采用TCP协议如果说允许数据有一点点丢包的话我们就可以使用UDP协议

TCP的协议格式

TCP协议格式如下：
在这里插入图片描述

TCP报头当中各个字段的含义如下：

源/目的端口号：表示数据是从哪个进程来到发送到对端主机上的哪个进程
32位序号/32位确认序号：分别代表TCP报文当中每个字节数据的编号以及对对方的确认是TCP保证可靠性的重要字段
4位TCP报头长度：表示该TCP报头的长度以4字节为单位
6位保留字段：TCP报头中暂时未使用的6个比特位
16位窗口大小：保证TCP可靠性机制和效率提升机制的重要字段
16位检验和：由发送端填充采用CRC校验接收端校验不通过则认为接收到的数据有问题（检验和包含TCP首部+TCP数据部分）
16位紧急指针：标识紧急数据在报文中的偏移量需要配合标志字段当中的URG字段统一使用
选项字段：TCP报头当中允许携带额外的选项字段最多40字节

TCP报头当中的6位标志位：

URG：紧急指针是否有效
ACK：确认序号是否有效
PSH：提示接收端应用程序立刻将TCP接收缓冲区当中的数据读走
RST：表示要求对方重新建立连接
SYN：表示请求与对方建立连接
FIN：通知对方本端连接要关闭了

TCP报头在内核当中本质就是一个位段类型给数据封装TCP报头时实际上就是用该位段类型定义一个变量然后填充TCP报头当中的各个属性字段最后将这个TCP报头拷贝到数据的首部至此便完成了TCP报头的封装

TCP如何将报头与有效载荷进行分离？

当TCP从底层获取到一个报文后虽然TCP不知道报头的具体长度但报文的前20个字节是TCP的基本报头并且这20字节当中涵盖了4位的首部长度

当TCP获取到一个报文后首先读取报文的前20个字节并从中提取出4位的首部长度此时便获得了TCP报头的大小size
如果size的字节大于20字节则再次从报文中读取size - 20的数据这些数据是选项大小
读取完报头和选项之后剩下的就是有效载荷了

如果TCP报头当中不携带选项字段那么TCP报头的长度就是20字节此时报头当中的4位首部长度的值就为 5 （20 / 4 = 5）

TCP如何决定将有效载荷交付给上层的哪一个协议？

应用层的每一个网络进程都必须绑定一个端口号

对于服务器来说，服务端进程必须显示绑定一个端口号
对于客户端来说，客户端进程由系统动态绑定一个端口号

而我们的TCP报头中含有这么一个字段十六位目的端口号

因为我们可以从该报头中提取十六位目的端口号找到对应的应用级进程进而将有效载荷交给对应的应用层进程进行处理

在内核中端口号与进程ID之间的映射关系是用哈希的结构传输层可以通过端口号快速找到其对应的进程ID

序号与确认序号

怎么才能确定对方收到我的消息

在进行网络通信时一方发出数据之后它不能够保证该数据被对端收到因为在路上可能会遇到各种各样的问题所以说我们必须想一种办法来确认自己的消息被对端收到了而在我们现在的网络通信中我们采用的办法就是序号和确认序号通俗点来说当自己向对端主机发送信息的时候对端会给你应答这个应答就能说明你的消息被对方接收到了

在下面中实线表示的是消息确认能够被对方收到虚线表示的是消息不确认能够被对方收到

在这里插入图片描述
但是TCP协议需要保证的是通信双方的可靠性虽然此时主机A能够保证自己上一次发送的数据被主机B可靠的收到了但主机B也需要保证自己发送给主机A的响应数据被主机A可靠的收到了

因此主机A在收到了主机B的响应消息后还需要对该响应数据进行响应但此时又需要保证主机A发送的响应数据的可靠性

因为我们只有在收到对方的响应消息之后我们才能保证自己上一次发送的数据被对端可靠的收到但是就像上面的图例一样总会有一条最新的消息不能确认被收到

所以严格意义上来说互联网中通信的时候不存在百分百的可靠性因为双方通信的时候总有一条最新的消息得不到应答

但实际没有必要保证所有消息的可靠性

我们只要保证双方通信时发送的每一个核心数据都有对应的响应就可以了而对于一些无关紧要的数据（比如响应数据）我们没有必要保证它的可靠性

这种策略在我们的TCP中叫做确认应答机制

需要注意的是确认应答机制并不是保证双方通信的可靠性而是只要一方收到了另一方的应答消息就说明它上一次发送的数据被另一方可靠的收到了

32位序号

如果双方在进行数据通信时只有收到了上一次发送数据的响应才能发下一个数据那么此时双方的通信过程就是串行的效率肯定会很差

因此双方在进行网络通信时允许一方向另一方连续发送多个报文数据只要保证发送的每个报文都有对应的响应消息就行了此时也就能保证这些报文被对方收到了

但是在连续发送多个报文的时候又会产生新的问题报文到达的先后顺序

由于在发送报文的时候路径选择的不同所以报文到达的时间不一定相同也就是说先发的报文不一定会先到

TCP将发送出去的每个字节数据都进行了编号这个编号叫做序列号

比如现在发送端要发送3000字节的数据如果发送端每次发送1000字节那么就需要用三个TCP报文来发送这3000字节的数据
此时这三个TCP报文当中的32位序号填的就是发送数据中首个字节的序列号因此分别填的是1、1001和2001

此时接收端收到了这三个TCP报文后就可以根据TCP报头当中的32位序列号对这三个报文进行顺序重排（该动作在传输层进行）重排后将其放到TCP的接收缓冲区当中此时接收端这里报文的顺序就和发送端发送报文的顺序是一样的了

接收端在进行报文重排时可以根据当前报文的32位序号与其有效载荷的字节数进而确定下一个报文对应的序号

32位确认序号

TCP中的三十二位确认序号是告诉对方我当前已经收到了哪些数据你的数据下一次应该从哪里开始发

为什么要用两套序号机制？

主机A和主机B之间通信

A主机只发送数据 B主机只接收数据

那么此时A主机发送序号请求报文的时候 B主机只需要在相同字段填写相同的响应报文就可以了

但是我们的TCP是一种全双工通信协议所以说在AB主机通信的过程中 B主机也有可能向A主机发送数据

那么此时我们就需要使用两套序号机制来区分序号和响应序号了

窗口大小

TCP的接收缓冲区和发送缓冲区

TCP协议本身是具有接收缓冲区和发送缓冲区的

在这里插入图片描述

我们调用write和read函数的时候并不是直接从磁盘而是从内存缓冲区中读取数据根本原因是因为磁盘的IO效率太低了

在应用层调用write函数的时候实际上就是向TCP的发送缓冲区中写入数据 TCP协议会等待合适的时机发送

与此同时当TCP接收从网络中发送过来数据的时候并不是直接发送到应用层而是拷贝到接收缓冲区中等待应用层使用read函数来读取

当我们平时调用write函数的时候它会将数据写入到TCP的数据缓冲区当写入成功（或失败）之后它就会返回了之后数据什么时候发送怎么可靠的发送就是传输层的事情了应用层并不关心

TCP的发送缓冲区和接收缓冲区存在的意义

发送缓冲区和接收缓冲区的作用：

TCP是一个要保证可靠性的协议如果发送端没有收到确认的应答发送的数据就会保存一段时间之后继续发送直到收到应答这部分数据才被覆盖
和UDP协议一样TCP协议也有接收缓冲区这是因为应用层梳处理数据的速度是有限的为了保证没来得及处理的数据不被直接丢弃所以说我们要设立接收缓冲区数据在网络中传输是十分耗费时间和空间的如果仅仅是因为没有即使处理就丢弃资源会造成对于网络资源极大的浪费

经典的生产者消费者模型：