目录
UDP
Udp协议的格式
UDP的传输特性
UDP的缓冲区
基于UDP的应用层协议
TCP协议
TCP的报文格式
1.ACK确认应答机制
2.超时重传
3.TCP的链接管理机制
为什么要三次握手呢？
理解TIME_WAIT状态
流量控制（可靠性+效率）
滑动窗口
拥塞控制
TCP的特点
UDP
我们系看看udp协议：
Udp协议的格式
UDP报文一共16字节，由UDP首部和UDP数据组成，在进行校验时，如果校验出错，就会选择丢弃。
首部格式：8字节
源端口：2字节
目的端口：2字节
长度：2字节，含UDP首部和载荷
校验：2字节
UDP的传输特性
UDP的传输过程类似于寄信。
UDP在传输信息时，如果检验出错，就会丢弃报文，并不会通知对方，因此传输特性为：
无连接性：传输数据时，是不会向对方请求建立连接的，直到ip地址和端口号就进行传输。
不可靠：因为无连接，那么数据在传输过程中，是无法保证能准确到达目的地，没有确认机制，也没有重传机制，如果校验有错，报文直接就没了，也不知到原因，也收不到。
面向数据报：不能够灵活的控制读写数据的次数和数量。每次发送数据都可以认为是再发邮件，且要一次就把邮件的内容全读取到。
在我们之前学习Tcp套接字的时候，我们知道Tcp在数据传输过程中，是要去定制协议的，每一次都需要对发送或者读取的数据进行定长，定格式，一次就发一串报文接受也一样，需要对数据序列化与反序列化。而对于UDP这都是不需要做的，发多少，就收多少。
UDP的缓冲区
在编写UDP套接字的时候，我们基本就了解到在发送消息和接收消息的时候，我们貌似只用了一个缓冲区，既可以读，也可以写，我们称为全双工。
实际上UDP并没有真正意义上的发送缓冲区，在调用sendto时会直接交给给内核，由内核将数据传给网络协议进行后续的传输。
但UDP具有接收缓冲区，但是并不保证接受报和发送报的数据顺序是否一致，且缓冲区满了数据就会被丢弃。
注意事项：
UDP 协议首部中有一个 16 位的最大长度 . 也就是说一个 UDP 能传输的数据最大长度是 64K( 包含 UDP 首 部). 然而64K 在当今的互联网环境下 , 是一个非常小的数字 . 如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装 ;
基于UDP的应用层协议
NFS: 网络文件系统TFTP: 简单文件传输协议DHCP: 动态主机配置协议BOOTP: 启动协议 ( 用于无盘设备启动 )DNS: 域名解析协议
TCP协议
相对于UDP协议，TCP协议就更加的重要了，TCP---传输控制协议面积对数据传输会做详细的控制,对于数据什么时候发，发多少，发错了怎么办全由TCP自主决定。
宏观上就是将数据拷贝到的缓冲区，之后交给协议传输，发送方再从缓冲区处拷贝数据，即本质就是数据拷贝。
TCP的报文格式
不同层时，对数据的的描述方式也不一样，对于传输层骂我们一般叫做数据段。
TCP传输面向字节流
报文首部：固定20字节，最长60字节
源端口：2字节
目的端口：2字节
SN：序号，4字节，报文段所发送的第一个字节的序号
ACK：确认号，4字节，期望收到对方下一个报文段的第一个字节的序号
Data Offset：数据偏移，4位，即首部长度，无选项时为0x5
控制位：12位，后五位依次为：ACK，PSH，RST，SYN，FIN
第一次握手：0x02（SYN）
第二次握手：0x12（SYN+ACK）
第三次握手：0x10（ACK）
第一次挥手：0x19（ACK+PSH+FIN）
第二次挥手：0x10（ACK）
第三次挥手：0x19（ACK+PSH+FIN）
第四次挥手：0x10（ACK）
窗口：2字节，发送方的接收窗口大小
校验：2字节
紧急指针：2字节
选项：MSS选项（4字节）
前两次握手时一般需要协商MSS，因此数据偏移和控制位分别为0x6002和0x6012-第三次握手和所有四次挥手一般无选项
三次握手
第一次：ACK1=0（无ACK标志）
第二次：ACK2=SN1+1
第三次：SN3=ACK2=SN1+1，ACK3=SN2+1
四次挥手
第二次：SN2=ACK1，ACK2=SN1+1
第三次：SN3=SN2，ACK3=ACK2
第四次：SN4=ACK3=SN1+1，ACK4=SN3+1
TCP的前20字节为它的标准报头，之后的为数据的有效载荷。
那么如何对数据的报头和有效载荷进行分离呢：固定长度+自描述字段
第一层是16源端口号与16位目的端口号（32位序号）（32位的确认序号）
序列号与确认字段号都是为了保证数据可靠传输：
此外还有确认序号，表示确认字段号前的数据我已经接收到了。
至于为什么要有两个序号这是因为：极有可能是确认应答的报文，也有可能时数据加确认报文。
第二层首先是单位大小位4字节的首部长度，之后16位的窗口大小
先以前两层来看，如果发送发一直向接收方发送数据，因为发送方并不知道接收方的承受能力，所以当缓冲区的数据溢满了，此时就有可能来不及接收数据，（发送方还在发），就会出现数据大面积丢失的情况。为了确保数据发送是安全可靠的，因此需要根据接收方的缓冲区，控制发送数据的速率，这种方式就叫做流量控制。
其次每次发送还需要有确认应答机制保证数据传输。除此之外，如果还存在数据发送后丢包，还会有超时重发机制。综上我们再来看看报文的接收与发送。
所以发送方发送后每一要回收应答，从而确定自己的传输速率（根据接收方接收缓冲区的大小），而这里16位字段存储的就是接收方剩余空间的大小。
6 位标志位 :URG: 紧急指针是否有效ACK: 确认号是否有效PSH: 提示接收端应用程序立刻从 TCP 缓冲区把数据读走RST: 对方要求重新建立连接 ; 我们把携带 RST 标识的称为 复位报文段（存在二次握手最后发数据，及连接建立不一致（网络问题））SYN: 请求建立连接 ; 我们把携带 SYN 标识的称为 同步报文段FIN: 通知对方 , 本端要关闭了
连接建立是否成功就看能不能收到第三次发送的确报文；链接一旦连接建立好，由于有多个客户端，所以我们还需要对链接进行管理。
综上基本上TCP的包头的字段的主要功能就是这些了。
现在我们再来细看关于TCP的一些确保数据安全传输的机制：
1.ACK确认应答机制
ACK应答机制我们在6个标志位字段已经了解过了，如发送方通过三次握手建立连接中，就是通过设置报文中的ACK字段，表明已确认收到报文，以及在数据的发送过程中。
2.超时重传
实际上数据在传输的过程，我们并不会知道关心数据是不是丢包了，还是在阻塞者，我们只有当接收方收到才知道传输没问题，但我们怎么去确信数据是丢包了还是阻塞？因此通过设定固定的时间间隔，如果超时（可能阻塞----路由选择的路径太差，可能网络断开丢包了），都会重新传输该报文。
3.TCP的链接管理机制
刚开始，发送方想要和接收方发送数据前，需要先建立连接，通过三次握手：
发送方先向接收方发送建立连接的请求SYN，接收方接受后发送确认建立连接ACK+SYN，之后发送发收到，发送确认收到建立连接的报文ACK。
之后就进行数据传输。
所以在我们编写套接字的时候，接口connect就是去形成一个建立连接请求的报文，而accept只关心三次握手成功时，返回的文件缓冲区connfd。
最后关闭连接的时候，通过四次挥手关闭连接：想要关闭的一方向接收方发送FIN报文，请求断开连接，接收方接收到后发送确认收到ACK，之后在向对方发送取消l连接的报文FIN，之后发送方再次发送ACK确认收到保文，并将自己的状态为立马ime_wait。套接字就是通过closed发送FIN报文。
链接有全连接对列，也有半连接对列--被建立连接的一方（维护的时间不长）。listen接口的第二个参数代表全链接队列的长度+1。
为什么全连接队列不能长呢--当上层很忙的时候，下层还不断有新的连接，那么没时间去处理对列，那么就会白白占用资源。
为什么要三次握手呢？
实际上真的是三次握手吗？发送方先发送SYN建立连接，接收方接受到后向对方发送ACK，之后再次向发送方发送建立链接的请求，只不过在发送时，我们将这两条报文合二为一了，即ACK+SYN
（应答时附带建立SYN报文），之后收到再次发送ACK，确认建立。
看到这里我们发现，其实四次挥手也可以压缩为三次挥手。
至于为什么不压缩，对于连接时，SYN与ACK不存在时间差，你给我发，我就跟你建立连接。但是在挥手时，你给我说再见，我不会直接就跟你说再见，我指挥先收到你的再见，根据情况，在看是否真的就和你说再见。
1.建立三次握手有一点就是 验证全双工通道是否流畅。
2.如果只有一次握手，存在SYN泛洪攻击，一直发建立连接，服务端需要资源来接受，就存在连接资源被打满的情况，如果是两次握手，发送方先发送给服务端，服务端先建立连接后发送报文给客户端，此时客户端才建立连接，这还是会存在客户端出现异常导致服务端在建立连接消耗资源。
只要出现影响，后果全让服务端来承受，因为客户端的基数大。
但当三次握手时，我们能知道给你发送的确认，你是否收到，报文是否丢失。
理解TIME_WAIT状态
那么为什么断开的时候，断开的一方需要等待呢？
1.让通信双方的历史数据消散。
2.让我们断开连接，四次挥手有较好的容错性。
流量控制（可靠性+效率）
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应.
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段, 通过ACK端通知发送端;
窗口大小字段越大, 说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
发送端接受到这个窗口之后, 就会减慢自己的发送速度;
如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端
在超时重传的时候，首先会想接收方发送一个窗口检测，判断双方是否能通信，如果你发不了，我收不到，那大概率就是网络的问题了，此时就断开链接了。
滑动窗口
我们已经了解到了确认应答机制是为了保证数据的可靠性，发送一次数据包，收到后就要向我发送ACK，没发一次，对应就要发ACK，如果距离太远，那么数据传输的效率就比较低了。
因此在实际发送数据时，发送方会将发送的数据进行分批次发出去，接收方接受这些请求再一个个发送确认报文，由于某些问题，接收方接受了，但没发送确认，根据超时传输再次发送，此时还没发送确认的数据就还是会保存到缓冲区当中，所以需要对缓冲区进行分区，这里我们简单的分区：
对于发送缓冲区：
发送滑动窗口的大小一般为接收方的窗口的大小。一般使用双指针对区域进行划分，如果区域需要扩大或者缩小，指针就可以向前或者向后滑动--因此被称为滑动窗口。
在该窗口内的报文，可以立即发送，可以不需要收到应答。
但是如果存在滑动窗口中间丢包怎么办？如果不是头一个ACK丢失，即使丢包了，滑动窗口也能确认丢包之后的ACK，因为存在确认序号。即使丢了，也能向后继续更新。
所以每次都是尽快的将数据从内核拿出来， 腾出更大的缓冲区，这样窗口也就大了。
拥塞控制
TCP的特点
与UDP相比，TCP具有发送缓冲区，在将数据拷贝至发送缓冲区时，会有tcp下层协议决定，之后接收方从接收缓冲古拷贝数据。总结就是TCP是一个由接受和发送缓冲区的，全双工的，数据发送控制的一个协议。
