TCP
TCP协议段格式
TCP报文 等于报头 加 有效载荷 TCP的标准报头长度 整体为20字节
报头的宽度是0-31，表示报头所对应的字节数 (4字节)报文对应的宽度 为0-31 有效的标准报头长度一共 5行，所以 整体为20字节
选项 如：客户端和服务器建立好了链接，但这个链接长时间不关，并且也不发数据，所以 操作系统 就会使用一定的策略 保证链接在一定时间内自动断开
报头和有效载荷如何分离？
考虑两种情况 第一种 没有选项时 标准报头的长度为20字节，剩下的都是有效载荷
第二种 有选项时 将标准报头长度20字节 与选项大小去掉，剩下的就是 有效载荷
所以就需要借助4位首部长度，来确定是否存在选项 若不存在选项，则使用第一种方法 若存在选项，则使用第二种方法
4位首部长度
TCP中存在4位首部长度，占的是4个比特位 (采用的是位段，所以有比特位) 首部长度 基本单位为：4字节 4位首部长度 表示 TCP报头一共有多少4字节对应的行 即整个报头长度的大小
二进制的取值范围为[0000,1111]，转化为 十进制的取值范围为[0,15] 取值范围乘以4后，变为 [0,60]
由于标准报头长度20字节，所以最终 选项的取值范围是[20,60] 即 选项可从20字节开始，最多到60字节
若为标准报头，4为首部长度应该填充多少？ 假设填充x x*4=20 x=5 转化为 二进制是 0101
提取报文的前20个字节(前20个字节一定是标准报头) 在提取首部长度字段 根据首部长度字段* 4 减去20字节 若为0，说明没有选项，报文就是标准报头，直接读取有效载荷即可 若不为0，剩下几个字节，就说明有几个字节的选项，整个报文长度 减去 标准报头以及 选项长度 即可获得 有效载荷
TCP可靠性
确认应答机制的提出
TCP通信时，那些是不可靠的？ 丢包、乱序、重复、校验失败、发送太快/太慢 单纯的就是因为 通信双方 距离太远
在这些不可靠的问题中，最核心的就是丢包问题
如何知道丢包了？ 就需要正确理解 确认应答机制
确认应答机制的本质：确认是否丢包 如：给你发个报文，需要对该报文进行确认，只要收到了确认，就认为 发的报文被收到了
客户端给服务器发了一条消息，可服务器是否收到报文，客户端是不清楚的 客户端为了保证 消息被服务器收到了，就要求 服务器对客户端做应答
虽然无法保证此时的ACK 是否丢失的问题，但是可以保证 只要客户端收到了应答，客户端向服务器发送的数据，对方一定能收到 若客户端收不到应答， 客户端就认为报文丢失
结论：可靠性是通过收到应答保证的
在TCP中 客户端和服务器端，双方的地位是对等的 如：客户端想给服务器端发消息，服务器端必须应答 ，才能保证客户端给服务器发的消息的可靠性
序号和确认序号
如果发一个接收一个，效率太低了，所以就采用一次向对方塞满大量数据
这样的话，服务器的每一个报文都要应答
这样来看效率是提高了，但是会出现两个问题 1. 发送的顺序，不一定是接收的顺序
- 当服务器收到多个确认的时候， 并不知道哪一个应答，对应哪一个请求报文
为了解决这两个问题， 就需要给报文 带上编号
结论： TCP报头中必定要包含 序号
客户端要对众多要发送的报文数据 进行编号
假设 客户端 给服务器发送一个序号为10的报文 ，服务器给客户端的确认应答中 要有 确认序号 此时的确认序号 为 11
确认序号的含义 确认序号X：X-1之前的报文，已经全部收到了，下次发送请从X编号开始发送
若在确认应答时，序号10对应的确认序号11丢失了 而确认序号12是应答成功的
确认序号12 表示 11号之前的报文已经全部收到了，下次从12序号 开始发送 就可以告诉 客户端 10序号的数据发送成功了，只是应答丢了
为什么序号和确认序号在不同的字段？
TCP是全双工的，既能读，又能写 看似服务器只做了一个确认应答，实际上 服务器做了两个工作 1.给客户端做出应答，2.给客户端发送数据 被压缩成了一个请求/应答，被称为 捎带应答(提高通信效率) 如：有人问你吃了吗？ 你说吃了，并反问你呢？ 两个人各自只张了一次口，通信效率就提高了
确认应答并不纯粹，在相当大的情况下 确认应答即是对客户端的确认，又携带了服务器给客户端发送的数据 该报文必须要有32位序号，表示 服务器给客户端发送数据时 数据序号的问题 必须要有32位确认序号，服务器对客户端的历史数据的确认
为了32位序号和32位确认序号同时存在，所以必须要在不同的字段
16位窗口大小
传输层的TCP中包括 发送缓冲区 和 接收缓冲区
在传输层与应用层之间有一个 系统接口 如：send/ write read/recv
调用系统接口之前，应用层有自己的应用层缓冲区
如果TCP发送数据时，发送太快， 接收缓冲区很快就满了，报文就会被丢弃掉
虽然说TCP有重传机制，技术上没有问题，但是这样做不合理 因为 这些报文 经过 各种网络资源的转发，已经消耗很多的网络资源了，才到达了目标主机
为了不出现当前情况，让发送方 控制 一下自己的发送速度，这种策略 称之为 流量策略
接受方 在收到报文时，对每一个 收到的报文 都会进行应答
为了不使 接收方 来不及接收，所以需要将自己的接收能力 告诉对方 如：你回家 你妈给你做了一桌子菜，当你吃饭时，你妈一直给你加菜，直到你吃不动时，就跟你妈说，吃饱了，但如果你妈依旧给你加菜，你肯定受不了
发送方发送的策略，是要受接收方接收的能力 影响的
而接收方的接收能力 取决于 接收缓冲区的剩余空间的大小
每个报文都有应答 以及 自己是知道自己的接收能力的 ，两者合在一起 ，就对应 TCP的16位窗口大小
客户端给服务器发送消息时，服务器要给客户端做出响应，响应中携带对应的TCP报文，TCP报文中包含TCP报头 报头中包含 16位窗口大小， 会把服务器中 接收缓冲区的剩余空间大小 填入窗口大小中 就根据 16位窗口大小 来决定发送方 还能发送多少数据
6个标志位
每一个标志位在报头中 只占一个比特位
标志位本质
可能存在很多的客户端给服务器 发消息 所有的客户端在任何时刻 都可能发送大量消息
TCP是面向链接的，服务器在收到数据时，这些收到的数据 有相当一部分是链接请求 当通信完成时，可能会断开链接，此时客户端要给服务器发送一些断开链接的请求
在建立链接之后，断开链接之前，客户端要给服务器 正常的数据通信
绿色建立链接 蓝色发送消息 红色断开链接 服务器在同一时刻 会收到各种各样的报文请求，报文之间是不同的
如：你是一家餐厅的老板，在餐厅中有各种各样的人，有的人是来吃饭的，有的人是来找人的，有的人是来拿外卖的 你每天都会面对各种各样不同的人，这些各种各样不同的人是你观察到的现象 来吃饭的，会进行推荐店里最好吃的东西 来找人的，就会询问是什么样子的
不同的人 来到店里 提供不同的处理动作 你把人划分成不同的类型，所以 报文也是有类型的
标志位的本质就是 标识不同类型的报文，所以服务器就会有不同的处理动作
具体标志位
ACK：该报文 是一个确认应答报文，可能会携带数据 (捎带应答)
SYN：是一个连接请求的报文 (三次握手)
FIN： 是一个连接断开的请求报文 (四次挥手)
这三个后面会详细说
PSH
催促对方，让对方尽快将接收缓冲区的数据 向上交付
如：当你正在写作业，你的爸爸过来催促你，让你赶紧做 所以每一个人在完成一件事情时，在一定的情况下，别人会催促你，让你尽快把一件事情做成
同理，客户端给服务器发送消息时， 服务器要给客户端做出应答， 通告客户端 ，服务器中的接收缓冲区的剩余空间的大小，使客户端进行 流量控制
若服务器的TCP报文 在的 窗口大小为0， 则客户端就不能发送数据了 所以客户端就需要 定期给服务器 发送一些询问报文(不携带数据) 客户端就会确认应答，同时也会告知对应的 窗口大小依旧为0
客户端再次发起询问报文，就可以将自己对应的PSH置为1 表示让服务器中的应用层赶紧把接收缓冲区的内容取走，把接收缓冲区的空间腾出来，以方便客户端发送数据
RST
TCP三次握手时，需要进行三次报文交互，不一定能握手成功 但握手成功了，一定是经历了三次握手
当客户端 与服务器 进行链接时，双方都认为有链接，服务器端因为一些原因 而释放了对应的链接 而客户端还不知道，客户端还会一直维护这个链接
过了一会，服务器又把对应的网线插上了，客户端又向服务器发起请求 服务器并没有接收到 获取到三次握手的任何细节，所以服务器意识到客户端的链接是异常的
所以服务器就会给客户端发送 一个 RST置为1的TCP报头 当客户端接收到 当前报头时，将自己老的链接释放掉，再重新发起三次握手
RST 全称 为 reset，作用为 对链接进行重置
URG
紧急指针标志位
TCP本身包含了序号，就可以将TCP报文按序号排序，就可以按序号由小到大入队列，这样就保证上层拿到的数据是有序的
若报文中携带了特殊数据，让接收方将特殊数据插队处理，就需要使用URG标志位
作用为：告诉接收方， 当前报文中的有效载荷里面 有紧急数据存在的，并且16位紧急指针是有效的 (大部分情况下 16位紧急指针是无效的)
若URG被置1，则表示报文中包含了紧急数据
16位紧急指针 本质为 一个偏移量，紧急数据(只有1个字节) 在有效载荷中的偏移量
超时重传机制
若主机A向主机B发送消息，是有可能造成丢包的，但如何知道丢包呢？ 在特定的时间范围有没有收到应答，若收到应答，则说明收到了 若没收到应答，则说明报文在网络中丢失了
主机A收不到应答的情况 分为两种
第一种： 虽然主机A给主机B发送数据，但主机B没有接收到数据，所以主机B就不会应答 所以主机A在等待一段时间后，就会把对应的数据重发一次 这个重发的过程就叫做 超时重传
TCP发送数据时，必须把暂时没有得到反馈的数据 维护一段时间，支持超时重传
最理想的情况下，找到一个最小的时间， 保证 确认应答一定再这个时间内返回 若超时时间设置太长，会影响整体的重传效率 若超时时间设置太短，有可能会频繁发送重复的包
第二种：
主机A给主机B发送数据时，主机B接收到了数据，但是应答丢失了 主机A在特定时间内若没有收到对应的应答，主机A会重新再发送对应的数据 主机B有可能收到 重复报文 就需要主机B进行对应报文的去重
