一、TCP协议格式
我们看到报头固定有20字节，最后选项大小不固定。
4位首部长度（二进制0000 ~ 1111，十进制范围[0, 15]）单位是4字节（存放字节大小范围[0, 60]）包括了20字节固定长度 +选项长度。若选项大小为0，四位首部长度是5，即0101，用于解包。
二、TCP各种机制
1、确认应答机制
保证双方请求发送可靠性。
发送方和接收方不一定就是 client 和 server ，身份可以互换，上图举例。
只要 client 收到应答，就能保证上次 client 发送的请求 server 一定接收到了，这是保证了从 client 到 server 的数据发送可靠性。但是我们不能对应答再次应答来保证从 server 到 client 数据发送的可靠性，因为这样会死循环，所以一般不对应答进行处理。
可靠性：不是TCP协议保证每一个请求都能让发送方收到应答，而是能确认接收方是否得到了请求，如果得到发送方收到应答，没有就是发送方没收到应答。
TCP通信模式
首先由于应用层会有发送缓冲区和接收缓冲区来进行通信，Linux中把缓冲区以字节为单位逻辑上看成是数组，数字就是数组的下标，序号与确认序号就是这样的缓冲区中的数组下标。
2、超时重传机制
由确认应答机制可以知道，我收到了 ACK 就说明对方一定收到了数据，经过一段时间我没有收到 ACK，TCP协议规定我认为对方没有收到数据，我要补发数据。
没有收到 ACK 两种情况：
那么经过多长时间进行数据补发呢？与网络相关，Linux 中第一次超时0.5s，第二次超时1s，第三次超时2s，第一次超时4s...重复一定次数还没有收到就关闭不传了。
3、连接管理机制
正常情况下，三次握手建立连接，四次挥手断开连接。
（1）三次握手建立连接
标记位 SYN 表示申请建立连接
标记为 RST 表示要再次建立连接
我们看到最后一次服务器没有对 ACK 进行应答，实际上就算连接在最后一步出现问题，导致没有连接成功，客户端在发起 ACK 之后就认为连接已经建立，此时对服务器发送请求时，服务器发现没有连接成功就会返回 RST，客户端看到后就知道没有建立连接，重新三次握手建立连接。
（2）四次挥手断开连接
第一次挥手表示客户端向服务器发送的数据已经发完，之后客户端不会主动发消息给服务器，但由于没有第二次挥手，服务器还可以继续给客户端发消息，客户端也必须 ACK 应答，但应用层已经关闭，只能发 ACK 应答报头。
所以允许客户端还要收到服务器的消息就只能关闭套接字的写端。
用函数 int shutdown(int sockfd, int how) how中的选项 SHUT_WR 关闭写端。
（3）建立连接为什么要三次握手？
网络中有许多连接，为了管理连接就要先描述再组织，连接就是一个结构体，既要有空间存储，也要有时间来进行属性更新。所以三次握手也是在维护双方的连接结构体。
而且三次握手要有三次才能建立连接，对抗 SYN 洪水效果好。
原因：
a、验证全双工：即保证双方网络连通性，用最小的次数验证。
b、建立双方通信共识：客户端发送 SYN 说明客户端想连接服务器，服务器也发 SYN 说明服务器想连接客户端。
c、协商双方接受能力，在 ACK 应答报头中会带有16位窗口大小，这就是说当前接受缓冲区剩余量，用于为下一次数据发送进行发送量的确定。
（4）四次挥手中状态含义
服务器 CLOSE_WAIT 状态：客户端已经退出，服务器知晓，但是还不能立即关闭自己的 connfd
客户端 TIME_WAIT 状态：TCP规定，处于 TIME_WAIT 状态下在 2 * MSL（maximum segment lifetime 报文最大生存时间） 时间内不能再次监听同一个端口。
主动断开连接的一方最终会进入 TIME_WAIT 状态。
那如何不用等就可以重新监听端口呢？
int setsockopt(int sockfd, int level, int optname, void* optval, socklen_t* optlen)
level：所在层，SOL_SOCKET
optname：选项名字，SO_REUSEADDR，重新使用地址
optval：选项值，int opt = 1
optlen：选项大小，sizeof opt
函数作用是允许创建端口号相同，但IP地址不同的 socket 描述符，不用等就可以连接相同端口。
为什么要等 2MSL 时间，要有 TIME_WAIT ?
a、保证两个朝向尚未接受或迟到的报文在 2MSL 时间内被接受后丢弃（因为已经是超时报文）如果没有 TIME_WAIT，立即建立相同的连接，就会接收到之前的旧数据，导致数据错误。
b、同时也保证四次挥手最后的 ACK 服务器能就收到，要是没有 TIME_WAIT，客户端立即退出，ACK 传递出错，服务器再次向客户端发送 FIN 时客户端退出就会导致错误。
（5）连接管理总流程
4、流量控制
发送方会根据接收方的接收缓冲区剩余空间来动态调整发送速度。
所以接收方可以在 ACK 应答中的16窗口大小填写缓冲区剩余量来告知发送方。
窗口探测：主机A给主机B发空报头，B必须 ACK 应答带上窗口大小，主机A就能了解情况。
窗口更新通知：主机B终于能有空间接收请求时，会给主机A发消息，提醒他可以发数据了。
标记位 URG：紧急指针标记位（0无效，1有效）数据中有紧急数据，16位紧急指针就会标识紧急数据在数据中的偏移量。因为TCP协议中紧急数据大小1字节，所以只有偏移量没有大小。举例：0代表正常，1代表暂停，2代表取消...读取紧急数据知晓方法对应上层对于数据的处理方法。
recv 和 send 函数里面的 flag 标记设成 MSG_OOB 就可以对紧急数据设置。
5、滑动窗口
问题
流量控制：具体怎么控制发送数据大小？
超时重传：超时时间内，已发送的数据不能丢弃，保存在哪里？
发送方规定了一个滑动窗口，在窗口内的数据可以直接发送，暂时不用收到应答。
根据感性的理解，滑动窗口是可以变大变小变成0，只能向右移。
构建模型：
缓冲区在Linux里面逻辑上看成是字节为单位的数组，则滑动窗口就是用双指针(win_start , win_end)维护的内存空间。
接收到 ACK 应答之后，win_start = 确认序号，win_end = win_start + 16位窗口大小。
考虑一个问题：如果数据丢包，滑动窗口如何移动？
建立模型
1、最左侧报文丢失
即2000的报文丢失，此时传来的 ACK 确认序号只能是1001，由于我们一次发送多条数据，应答回来的都是1001，超过3次重复应答，发送方就会意识到1001~2000的报文已经丢失，再次补发，下一次 ACK 确认序号就直接是5001，这就是快重传机制。
上述情况是报文丢了，但如果应答丢了呢？没关系，只要相信最新一次应答的确认序号就能确定下一次报文从哪里开始发送（由确认序号定义得知）
所以最左侧报文丢失移动策略：
a、由于确认序号规定的约束，滑动窗口左边界不动。
b、快重传和超时重传对左侧报文补发。
快重传 vs 超时重传
快重传要连续3次相同确认序号才能触发（保证效率），但是在极端情况下超时重传一定能识别到报文丢失（保证安全）
2、中间报文丢失
a、win_start = 确认序号，此时新滑动窗口就是最左侧报文丢失
b、由于确认序号规定的约束，滑动窗口左边界不动。
c、快重传和超时重传对左侧报文补发。
3、最右侧报文丢失
a、win_start = 确认序号，此时新滑动窗口就是最左侧报文丢失
b、由于确认序号规定的约束，滑动窗口左边界不动。
c、快重传和超时重传对左侧报文补发。
所以最后我们来回答最开始的两个问题。
流量控制：具体怎么控制发送数据大小？滑动窗口机制
超时重传：超时时间内，已发送的数据不能丢弃，保存在哪里？滑动窗口里面，出问题转化成最左侧报文丢失问题即可解决。
6、拥塞控制
（1）介绍网络拥塞
由于网络拥堵导致发送报文大面积的丢包，TCP会采用慢启动机制，先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据。
TCP解决网络拥塞的问题，最大的价值在于：在多个使用同一网络进行通信的主机有拥塞避免的共识。即TCP协议是全体主机都要遵守的，在网络拥塞的情况下，不能只从一台主机考虑，全体主机都必须减少报文发送才能缓解网络拥塞。
具体的拥塞控制：发送方的滑动窗口 = min(接收方的应答窗口，拥塞窗口)
（2）拥塞窗口
网络状况是浮动的，就说明拥塞窗口的大小肯定也是动态变化的。所以要经过多轮尝试才能得出准确的拥塞窗口大小。
慢启动机制
但是如果只是单纯向上面一样指数级增长就会导致测出来的拥塞窗口不准确，所以慢启动之后我们要让拥塞窗口线性增长来保证准确。
加法增大：达到阈值之后只能线性增长来探测到准确的网络拥塞值。
乘法减少：上一次的网络拥塞值的一半就是下一次慢启动的阈值。
但是不会无限线性增大下去，一定会有拥塞窗口极限值限制线性增长。
7、延迟应答
收到一批报文之后不会立即应答，等上层处理完一些请求之后能空出更多的接收窗口了，再 ACK 应答告知对方有更大的接收窗口，可以在网络不拥堵时保证传输效率。
但是延迟应答也有限制。
8、捎带应答
发送数据时带上上一次的应答数据
三、理解TCP面向字节流
四、TCP粘包问题
1、介绍粘包问题
2、解决粘包问题
3、UDP不用考虑粘包问题
五、TCP异常
六、TCP小结
可靠性: 校验和，序列号(按序到达) ，确认应答机制，超时重传机制，连接管理机制，流量控制机制，拥塞控制机制
七、TCP / UDP对比
八、用UDP实现可靠性传输
1、引入超时重传机制，防止丢包
2、引入确认应答机制，保证对方收到数据
3、引入序号，保证数据接收顺序