网络基础--传输层

传输层：负责应用程序之间的数据传输 TCP/UDP协议

UDP协议特性：无连接，不可靠，面向数据报
无连接：通信的时候，不需要建立连接，只需要知道对方的地址信息，就可以直接发送数据
不可靠：通信过程中，并不保证数据安全可靠以及有序的到达对端
数据报传输：无连接的，不可靠的，有最大传输长度限制的一种传输方式
有最大传输长度限制：udp报文头部中有一个数据报长度字段，最大数字为65535，限制一个完整的报文长度不得超过64k
UDP报文

16位源端口/16为目的端口：描述数据从哪个进程发送到哪个进程–负责实现应用程序间的数据传输
16位数据报长度：包含udp报文头部在内的整体报文长度—存储的最大数字是65535
16位校验和：二进制反码求和算法，用于校验接受到的数据和发送的数据是否一致
udp协议对上层程序员编写程序的影响
若sendto传输的数据(应用层的原始数据)大小大于64k-8（udp报文头部长度是8个字节），则传输报错
因此若数据过长，需要程序员在应用层自己手动将大数据分割为一个个小的数据段进行sendto发送
但是udp并不保证数据有序到达，这时候在上层，程序员进行数据分包之后，就要考虑在应用层实现各个数据段的包序管理
udp报文都是整条收发的，因此udp在使用recvfrom获取数据的时候，给的buffer就要足够大，防止数据过长给的buffer不够大而报错，接收失败的情况
因为udp报文头部中定义了报文长度，因此sendto发送数据的时候，数据一到发送缓冲区就会直接封装udp报文头部，然后发送数据，接收方接受数据，放到接收缓冲区，用户recvfrom接收的时候，不能出现接收半条或多条数据的情况，只能是一条完整的数据。

TCP：面向连接，可靠传输，面向字节流
面向连接:tcp协议中的连接管理(连接建立成功后才能进行通信)
三次握手 四次挥手
握手为什么是三次
tcp是双向通信，必须确保双方都具有数据收发的能力；假设客户端发送连接请求后，直接退出了，因此都要给对方发送SYN数据
挥手为什么是四次
发送FIN,只是表示不再给对方发送数据，不代表不再接收数据，因此被动关闭方对FIN确认回复后，依然还要可能发送数据，主动关闭方还有可能继续接收数据，也正是因为如此，因此被动关闭方不能将ACK和FIN合成一个进行发送

可靠传输：保证数据安全有效达到对端
确认应答机制：对于发送的每一条数据，都需要接收方确认回复
超时重传机制：在指定时间内没有收到确认回复，则认为数据丢失，对之前的数据进行重传
协议字段中的序号/确认序号：进行包序管理，并且实现确认应答机制
确认序号，功能就是告诉发送方，这个确认序号以前的数据都已经收到
如果第一条数据丢失，就算收到第二条数据，也不会进行回复，因为每一条回 复表示都是前面的数据都已经完全收到了
协议字段中的校验和：校验数据是否一致，不一致则要求对方进行重传
哪条数据不一致，则回复这条数据的起始序号
滑动窗口机制：通过协议字段中的窗口大小实现-通过窗口大小告诉对方最多发送多少数据，避免因为发送数据过多接收缓冲区满溢而造成丢包
快速重传机制：发送方连输发送多条数据时，若接收方首先接受的是第二条数据，则有理由认为第一条数据丢失，因此开始向发送方连续三次发送第一条数据重传请求，发送方连续三次接收到重传请求，则会对这条数据进行重传
重传这里存在三种协议：停等协议/选择重传协议/回退n步协议
停等协议：收到一条回复才会发送第二条数据
选择重传协议：哪条丢了，就重传哪条数据
回退n步协议：从丢失的数据开始，往后的数据都需要重传一遍
拥塞机制：滑动窗口实现一次连续发送多条数据，但是若网络不好，一开始在网络状况不明的情况下，有可能会导致发的越多丢得越多，因此在发送数据时，进行网络探测，查看网络是否支持数据都连续快速传输
实现原理：慢启动，快增长
可靠传输的实现：面向连接/确认应答机制/超时传输机制
避免丢包：滑动窗口机制/拥塞机制
提高性能：快速重传机制/延迟应答机制/捎带应答机制

协议实现:

16位源端口/16为目的端口：描述数据从哪个进程发送到哪个进程–负责实现应用程序间的数据传输
32位序号/32为确认序号：实现确认应答机制，以及进行包序管理
4位头部长度：表示tcp头部有多长，tcp头部是不定长数据，主要取决于选项数据的大小，以4字节为单位
6位保留位：现在没想好要做什么，先预留着用于以后扩展
6位标志位：URG/ACK/PSH/RST/SYN/FIN
16位窗口大小：用于实现滑动窗口机制，进行流量控制
16位校验和：二进制反码求和算法，用于校验接受到的数据和发送的数据是否一致

面向字节流：提供的是可靠地，有序的，基于连接的字节流传输
字节流传输L数据可以在缓冲区进行堆积，取出比较灵活，以字节为单位进行存放/取出
但是这种数据在缓冲区堆积会有一个缺陷：tcp粘包—将多条数据当做一条数据进行处理
粘包的本质原因：tcp在传输层对数据边界不敏感（不管上层数据是什么样的，每次都根据mss取出合适大小进行发送/不管接收缓冲区中是什么数据，只管从缓冲区中取出用户需要大小的数据进行交付），因此造成粘包问题
粘包问题的解决方案：程序员在应用层进行数据的边界管理
1.特殊字符间隔–每条数据结尾有一个特殊字符，数据中的特殊字符就需要进行转义
2.数据定长—每次只发送/接收指定长度的数据，数据短了会造成资源浪费
3.在应用头中定义数据长度字段—先按照指定长度将头部获取，根据头部的长度，取出指定长度数据
udp不会产生粘包–udp数据是整条收发的
tcp连接管理中的保活机制：
tcp是面向连接通信，若通信双方长时间没有数据往来，就需要确定对方是否在线，连接是否正常
若通信双方长时间没有数据往来，在服务端会向数据端每隔一段时间发送一个保活探测数据报包，要求对方进行响应，若多次没有响应，则认为连接断开