TCP/IP四层模型：
UDP协议
UDP（User Datagram Protocol ）是传输层协议。
特点
1.无连接：知道对端的ip地址和端口号就可直接传输数据。
2.不可靠：没有确认机制、重传机制，当因为网络故障导致报文数据无法发送给对端，UDP协议也不会给应用层发送任何错误信息。
3.面向数报：不能灵活的控制读写数据的次数和内容。
如果发送端调用一次 sendto, 发送 100 个字节 , 那么接收端也必须调用对应的一次 recvfrom, 接收 100 个字节 ; 而不能循环调用 10 次 recvfrom, 每次接收 10 个字节。
UDP协议的缓冲区
UDP没有真正意义上的发送缓冲区，调用sendto函数会把数据直接交给内核，由内核将数据传递给网络层，再有网络层协议进行数据传输。
UDP有自己的接收缓冲区，但是这个接收缓冲区保证不了接收UDP数据报顺序与对端发送UDP数据报的顺序的一致。如果接收缓冲区满了再发来的数据就会被丢弃。
UDP 的 socket 既能读 也能写，是全双工的。
UDP协议段格式
UDP如何分离报头和有效载荷？报头数据中的16位UDP长度=报头（8byte）+有效载荷，OS内核依据这个定长计算分离报头和有效载荷。
TCP协议
TCP是传输层协议(Transform Control Protocol,传输控制协议)。
特点
1.有连接 2.可靠传输 3.面向字节流
如何理解TCP是传输控制协议？
TCP协议段格式
四位首部长度
报头和有效载荷如何分离，如何交付给应用层？
根据 **固定长度(标准报头)+子描述字段(报文里的报头中四位首部长度)**的方式分离出报头，然后报文里剩下的数据就是有效载荷了。
报头中的四位(4个比特位)首部长度，范围是二进制：[0000,1111]；十进制：[0,15]，经过转换就可以得到报头的总大小，报文首部大小=标准报头大小(20byte) + 选项大小。
四位首部长度计算的时候的基本单位是4byte，如：2进制数1001的10进制是9，可以得到报头总长度是4*9=36，因此选项的大小是：36-20=16
根据报文数据中的报头中的16位目的端口号确认交付给应用层的那个进程。
16位窗口大小
接收端处理数据的速度是有限的 . 如果发送端发的太快 , 导致接收端的缓冲区被打满 , 这个时候如果发送端继续发送 ，就会造成丢包， 继而引起丢包重传。
因此 TCP 支持根据接收端的处理能力， 来决定发送端的发送速度， 这个机制就叫做 流量控制 (Flow Control) ;
接收端将剩余的接收缓冲区大小放入 TCP 首部中的 " 窗口大小 " 字段 , 通过 ACK 端通知发送端 ;
窗口大小字段越大 , 说明网络的吞吐量越高 ;
接收端一旦发现自己的缓冲区快满了 , 就会将窗口大小设置成一个更小的值通知给发送端 ;
发送端接受到这个窗口之后 , 就会减慢自己的发送速度 ;
如果接收端缓冲区满了 , 就会将窗口置为 0; 这时发送方不再发送数据 , 但是需要定期发送一个窗口探测数 据段 , 使接收端把窗口大小告诉发送端
32位序号
作用：保证报文数据按顺序到达接收方。
当发送端一次性向接收端发送多个报文数据时（确认应答方式不是发一个报文必须得让对方确认应答），先被从用户级缓冲区拷贝到发送缓冲区里的数据，可能经过后网络网络层(由于网络宽带影响)不是第一个到达接收端接收缓冲区，这样就导致了接收方接收的数据乱序了！怎么保证这些报文被接收端接收的顺序和发送端发送时的顺序一致？
利用32位序号保证，可以把缓冲看作一个字符串，32位序号就是报文数据块最后一个字符的下标。
32位确认序号
确认序号=序号+1，当接收端确认应答时报头中的32位确认序号表示确认序号之前的数据接收端已经全部收到，期望发送端下一次发送数据从确认序号指定的数字发送。