1. UDP协议
1.1 UDP协议格式
系统内的UDP协议结构体：
注1：UDP协议的报头大小是确定的，为8字节
注2：可以通过报头中，UDP长度将UDP协议的报头和有效载荷分离，有效载荷将存储到接收缓冲区中等待上层解析。
注3：UDP没有真正意义上的发送缓冲区，调用sendto会直接交给内核，由内核将数据传给网络层协议后进行后续传输动作
注4：UDP具有接收缓冲区，该缓冲区不能保证收到UDP报文的顺序和发送UDP报文的顺序一致，如果缓冲区满了，再到达的UDP数据会被丢弃。
认知：操作系统会接收各种协议的大量的报文，因此os需要对报文做管理，而每个报文都是一个结构体(类)，该类保存了报头和有效载荷等其他相关属性信息，该结构体可以通过某些数据结构统一管理起来。注1：一个struct sk_buff对应一块内存空间记录报文数据，这和先前学习 struct file_struct 也会指向对应file是类似的
注2：网络通信，每一层都是报头+有效载荷的结构。
head和end标志整个缓冲区的开始和结束，假设数据从应用层一直递交到网络层，开始时data指向应用层数据开始地址处，tail指向尾部，每一层加入新的报头时，data往上添加
2. TCP协议
2.1 TCP协议格式
2.2 序号和确认序号
认知 ：TCP协议是面向字节流的协议，序号和确认序号是报文中有效载荷在整个数据流中的编号， 如果将字节流抽象成一个一维数组，那么编号就是数组下标，即序号确定了报文有效载荷的开始与结束
**注：**SYN和FIN标志位会占用序号，其他标志位不会占用序号
2.3 四位首部长度
认知：用于记录TCP报头长度，基本单位是4字节，TCP协议规定了报头的长度范围为20~60字节，因此四位报头长度的数值应为[5,15]。
2.4 窗口大小
现象：TCP协议，通信的双方存在各自的接收缓冲区，实际通信过程中，如果多个客户端向服务端发起通信请求，那么可能会导致服务端的接收缓冲区占满。占满之后，多余的客户端请求会被丢弃，导致资源浪费和低效。
认知 ：为了解决上述问题，窗口大小的目的是为了流量控制，是为了告诉对方，我的接收缓冲区剩余空间大小，避免资源浪费和低效。当客户端知道了服务端的窗口大小，会控制自己的发送速度。
2.5 6/8位标志位
问：为什么TCP报头中要有标志位？
答：接收方会收到不同类型的TCP报文，针对不同的报文类型，接收方要有不同的做法，因此需要有标志报文不同类型的字段，所以就需要这个标志位。
注：实际是位段，属于哪个类型就哪个位置一，否则置零
2.5.1 SYN标志位
作用：同步、建立连接，在握手过程中使用的标志位
2.5.2 ACK标志位
作用：表明是一个应答报文
注：大多数情况下，ACK标志位常置为1，只有第一次握手时为0，后续讨论。
2.5.3 FIN标志位
作用：表明是一个关闭连接的报文
2.5.4 PSH标志位
作用：催促接收方尽快将接收缓冲区内的数据交给上层
2.5.5 RST标志位
作用：连接重置报文，双方连接出现任何问题时，都可以进行重置
3. TCP协议中的三次握手☆☆☆
3.1 第一次握手
解释：
• SYN = 1：
SYS标志位置1，SYN标志位是用来建立连接的，因此，当客户端第一次向服务端发起握手请求时，报文中的SYN标志位会被置1
• Seq：
是客户端OS随机生成的一个序列号，用于建立连接
• ACK = 0：
第一次发送请求时，不会包含应答，所以ACK置0
细节1：双方在握手过程中，实际发送的是报文！
细节2 ：第一次握手时，报文中只包含报头数据，不包含有效载荷
3.2 第二次握手
服务端在接收到客户端发来的报文时，服务端也会将SYN置1，同时发送一个随机序号y，同时将确认序号置为：Ack = x + 1，告知客户端，下一次从x + 1序号位置发送数据。
细节：第二次握手时，报文中依然只有报头，没有有效载荷
3.3 第三次握手
客户端接收到服务端发送来的应答，表明x+1之前的序号已经连接成功，第一次握手成功，此时客户端向服务端发送应答 Ack = y + 1，告知服务端，下次从y+1开始的序号发送数据。
当服务端再次收到客户端的应答时，双方都建立了可靠的通信。
☆☆☆细节 ：ACK不占用序号，所以在双方三次握手完毕，建立起连接后，客户端的确认需要就为seq = x + 1 ；客户端在后续发送带有有效载荷的数据时，就从该序号开始，这样双方在第一次通信时，就能够保证发送方的起始序号 和接收方的确认序号能够一致
3.4 细节问题
问：前面我们说了，序号是用来形容有效载荷的，而且第一次握手和第二次握手中，不包含有效载荷，那么第一次握手和第二次握手中的序号Seq是什么？
答：SYN和FIN标志位会被计入到序号中，只占1位
问：序号和确认序号究竟是什么？有什么作用？答：
• 序号 ：每个字节在数据流中的开始位置，告知对方这次发送的数据是从该序号开始的，每个字节都有唯一序号，在数据发送过程中不断递增。
• 确认序号 ：告诉接收方期望收到的下一个字节的序号，并告知对方我已经成功收到了你从开始序号 到该序号为止的数据
举两个例子：
1.三次握手(假设握手成功)：
• 客户端向服务端发送序号Seq = 100，有效载荷的大小和SYN标志位决定了序号的范围，即1
**•**服务端接收客户端发来的序号 Seq = 100，服务端OS解析TCP报文长度，得知序号范围为100~101，所以Ack = Seq + 1 = 101，同时随机设置一个序号Seq = 200，发送给客户端。
**•**客户端接收到服务端的应答，表明从100~101的序号服务端已经全部接收完毕，客户端OS会解析服务端发送来的报文，得知序号范围为200~201，所以应答 Ack = Seq + 1 = 201，发送给服务端。
2.握手成功后正常通信（ 假设标志位全为0，双方有效载荷的大小为50字节**）：**
**•**客户端向服务端发送序号Seq = 100
**•**服务端接收客户端发来的报文，告知客户端下次从150序号开始发送数据，同时回复Ack = 150，并随机发送自己的序列号 1000
**•**客户端接收服务端的应答，客户端的数据从150序号开始发送，同时告知服务端下次数据从1050序号开始发送。
问：为什么三次握手前两次需要有SYN标志位？答：SYN是用于建立连接的标志位，TCP通信是全双工通信，需要确认双方可以互通
问：为什么要三次握手？答：1.验证服务端和客户端能进行全双工通信的最短的方式，本质是验证网络畅通；2.以最小成本100%确认双方通信意愿
问：假设第三次握手时，服务端没有收到来自客户端的回应？答：那么握手就失败了，客户端觉得，只要把ACK发出，他就认为三次握手完成，但实际情况是：服务端没有接收到客户端的回应，就会导致出现一个建立是否成功认知不一致的问题，即客户端认为连接建立成功，而服务器认为连接建立失败。
此时若客户端向服务端发送报文时，服务器就会识别到当前没有成功建立连接，就会向客户端发送一个带RST标志位的报文，要求重新建立连接。
细节1：connect发起握手请求，三次握手的过程由 client OS 和 client OS 完成，accpet不参与三次握手的过程
细节2：丢包问题，当发送方收不到应答 && 接收Ack超时时问：这个时间有多长？
答：根据网络情况定长短，以500ms为基准，第二次传以500*2为基准 ，第三次传以500*4为基准，如果500*4成功了，下次就以500*4为基准
细节3：TCP在握手时，向对方传递的不仅仅是SYN、ACK标志位，而是一整个报文，保温内部有对方的窗口大小信息，因此在握手过程中，双方就确认了对方的窗口大小信息，以便控制自己滑动窗口的大小进行流量控制
4. TCP协议中的四次挥手☆☆☆
4.1 四次挥手的过程(假设客户端主动断开连接)
第一次挥手：
客户端调用close(fd); 关闭套接字，发送带有FIN标志位的报文，表示要关闭客户端，客户端进入FIN_WAIT_1状态；
第二次挥手：
服务端接收客户端发来的FIN报文，返回带有ACK的报文，表示服务端知道客户端要关闭了，此时服务端进入CLOSED_WAIT状态
第三次挥手：
服务器处理完剩余数据后，主动发送带有FIN标志位的报文，表示要关闭服务端，服务端进入LAST_ACK状态
第四次挥手：
客户端收到服务端的FIN后，发送ACK表示客户端知道服务端关闭了，此时客户端进入TIME_WAIT状态，大约两个MSL时间后，客户端完全关闭进入CLOSED状态
细节：上述是客户端主动断开连接的情况，如果是服务端主动断开连接，对应状态变化只需要互换即可。
4.2 细节问题
问：如果客户端关闭/退出，服务端不关会出现什么情况？
答：服务端会一直处于close_wait状态，依旧占用fd，连接没有释放 → 服务端文件描述符泄漏问题
注 ：客户端关闭时，服务端也需要调用close() ,关闭对应套接字，即发起第三次挥手过程。
问：MSL是什么？答：MSL：TCP协议通信双方互发的历史报文中，存活时间最大的报文。
问：为什么要等待两倍的MSL？在回答这个问题之前，需要对另一个现象做一下描述。
现象 ：当发送方发送一个数据时，发送方判断超时，认为该数据已经丢失，但实际情况可能是该数据还在路由器的等待队列当中，即还存在于网络当中。此时如果断开的服务器立马重启，那么在建立连接的过程中，网络中的数据可能会被重新接收，从而影响建立连接的过程
答 ：为此发起断开的那一方在最后一次发送ACK时，需要处于TIME_WAIT状态同时等待两倍的MSL时间，为的就是网络中两个方向上残存的报文消散 ，避免引起下一次建立通信连接时出错。
注1：这也就是为什么主动断开的那一方为什么无法立刻重启服务器，因为他处于TIME_WAIT的状态，对应的端口号无法被使用，得换一个端口号才能重启。历史上被丢弃的报文就不会和新的连接配得上(源ip port 目的 ip port)，双方os就能够甄别出来这是陈旧报文
注2 ：如果需要让服务端又要处于TIME_WAIT状态，又要立即重启，需要重新设置套接字：
5. 滑动窗口
滑动窗口的作用：用于流量控制，是流量控制的具体实现方案
滑动窗口的大小：无需等待确认应答而可以继续发送数据的最大值
**滑动窗口是发送缓冲区的一部分：**窗口左边是已经发送完毕的数据，会被清空；窗口内部是待发送的数据；窗口右边是尚未发送的数据。
问：滑动窗口的大小有谁决定？
答：滑动窗口的大小由对方接收能力决定，简单点的话，滑动窗口的start = 报文确认序号
问：滑动窗口可以向左滑动吗？
答：不可以
问：滑动窗口可以变小、变大、不变以及为零吗？
答：可以
问：如果对端的窗口大小满了呢？
答：滑动窗口的大小设置为0，
1. 发送端周期性的进行窗口探测(发送只带报头的报文)来获取对端窗口大小属性。
2. 对端窗口更新时也会向发送端发送窗口更新的报文(报头)
问：如果滑动窗口内的数据丢失了怎么办？丢失分为三种：左侧、中间以及右侧丢失，后两种丢失都可以变为左侧丢失，因此只对左侧丢失做分析
答：假设发送方发送的序号为1001~2000、2001~3000、3001~4000、4001~5000。
①. 如果现在发送方在发送时，1001~2000的数据丢失了，而2000后的数据接收方正常接收。
这里需要注意一点 ：那就是发送方 发过来的起始序号 必须和接收方 的确认序号 是完全相同的。接收方 的确认序号为1001，那么发送方 发过来数据的起始序号必须为1001，如果1001~2000的数据丢失了，后续所有接收方 收到的报文的确认序号都为1001，发送方 在接收接收方 的应答时，就还是从1001序号开始发送报文，如果发送方收到了多个相同确认序号，就会触发快重传，否则就是慢重传。
再来复习一下确认序号的定义：假设确认序号为x，告知对方，前x个序号已经被成功接收，下一次从x+1开始的序号发送数据。
上述情况，如果1001~2000的数据接收成功，那么接收方 的确认序号会被重置为seq = 2000+1 = 2001，作为应答传给发送方 ，告知前2001个序号接收成功，下一个数据从2001序号开始，但是如果接收方 接收失败，后续收到的报文的起始序号 和当前接收方 的确认序号 不一致，那么接收方会以1001作为确认序号来应答。此时滑动窗口的大小不会更新！
② . 如果1001~2000数据的应答丢失，发送方收到了3001的确认序号，说明3001序号之前的数据已经接收完毕，此时可以更新滑动窗口的大小了，更新到3001序号处。
6. 拥塞控制
6.1 相关概念
拥塞窗口(cwnd):决定了发送端发送缓冲区滑动窗口的大小
滑动窗口大小 = min(拥塞窗口，对端接收缓冲区剩余空间)
注：网络情况是实时变化的，这决定了拥塞窗口也是实时更正的，拥塞窗口大，客户端的滑动窗口可能越大，能够发送的数据越多。
ssthresh：慢启动阈值
网络拥塞： 在TCP网络通信过程中，出现大面积的丢包问题。
6.2 拥塞控制策略
具体方式：
**1.**慢启动阶段
拥塞窗口指数增长，开始增长慢，探测网络情况，后续增长快，尽快占用带宽
**2.**拥塞避免阶段
当拥塞窗口超过慢增长阈值时，开始线性增长，避免过快增长导致出现网络拥塞
3. 小面积丢包触发快/慢重传
当发生丢包时，接收方会发送重复的ACK，发送方可以快速重传丢失的数据包，
数据恢复后，拥塞窗口较小至原来的一半，并通过线性增长逐步恢复
4 . 大面积丢包重新进入慢启动阶段
如果发生网络拥塞，慢开始阈值变为拥塞窗口的一半，拥塞窗口从1开始重新进入慢开始阶段
注：当发生网络拥塞时，此时客户端不能立即重传数据，因为成千上亿的用户如果同时重传，会导致网络负担进一步加大
7. 延时应答
概念：接收端在接收到对方报文，可以先等一下再答复，等待期间上层可能已经报这条报文处理完了，或者先前的报文处理完了，这样窗口的大小可能不变或者变大，再应答给发送端，这样发送端的窗口有概率会增大，发送更多数据
注：这个等待时间不会超过发送方的等待时间