传输层 主要解决 进程与进程之间的(可跨设备) 通信
UDP
User Datagram Protocol : 用户数据报协议
协议详解
UPD 首部构造
特点
- 无连接协议
- 不保证可靠的交付数据
- 面向报文传输
- 没有 拥塞控制
首部开销小
HTTP 3.0这类应用层协议，用UDP作为底层技术，然后在UDP基础上解决可靠性TCP
Transmission Control Protocol : 传输控制协议
协议详解
TCP 首部构造
特点
- 面向连接协议
- 点到点通通信
- 提供可靠的传输服务
- 提供全双工的通信
- 面向字节流的协议 （可能对用户数据进行分拆合并等操作）
可靠传输的基本原理
发送的消息丢失，确认的消息丢失， 确认的消息很久才到
- 停止等待协议 ：最简单，对信道的利用率不高
- 连续 ARQ 协议 ： 滑动窗口，累计确认
窗口 指明 允许对方发送的数据量
TCP 协议的可靠传输
- 基于 连续 ARQ 协议
- 滑动窗口以字节为单位
- 选择重传
发送、接收窗口的大小可以用来控制 TCP 协议的流速。窗口越大，同时可以发送、接收的数据就越多，支持的吞吐量也就越大。当然，窗口越大，如果数据发生错误，损失也就越大，因为需要重传越多的数据。
TCP 拆包的作用是将任务拆分处理，降低整体任务出错的概率，以及减小底层网络处理的压力。拆包过程需要保证数据经过网络的传输，又能恢复到原始的顺序。这中间，需要数学提供保证顺序的理论依据。TCP 利用（发送字节数、接收字节数）的唯一性来确定封包之间的顺序关系。粘包是为了防止数据量过小，导致大量的传输，而将多个 TCP 段合并成一个发送
超时定时器
TCP 协议的流量控制
TCP 通过让接收方指明希望从发送方接收的数据字节数（即窗口大小）来进行流量控制
点对点的通信量的控制
主要是抑制发送端发送数据的速率，以便使接收端来得及接收。
使用坚持定时器，防止形成死锁：接收方和发送方都会等待 。
坚持定时器: 收到0窗口通告后，就启动坚持定时器。坚持定时器每隔一段时间发送一个窗口探测报文
TCP 协议的拥塞控制
考虑整个网络
一条数据链路经过非常多的设备，其中各个部分都有可能成为网络传输的瓶颈
拥塞控制 ： 防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载
报文超时可以认为是拥塞
判断拥塞的方法
- 慢启动算法
- 拥赛避免算法
TCP 的三次握手和四次挥手
如果一个 Host 主动向另一个 Host 发起连接，称为 SYN（Synchronization），请求同步；
如果一个 Host 主动断开请求，称为 FIN（Finish），请求完成；
如果一个 Host 给另一个 Host 发送数据，称为 PSH（Push），数据推送。
以上 3 种情况，接收方收到数据后，都需要给发送方一个 ACK（Acknowledgement）响应。请求/响应的模型是可靠性的要求，如果一个请求没有响应，发送方可能会认为自己需要重发这个请求
为什么不能两次握手建立连接：
如果两次握手，可能一个连接很慢，导致发送方发了两次请求，导致建立两次连接，发送了重复数据据
三次握手 防止已经失效的连接请求报文传送到对方引起错误
因为当 Server 端收到 Client 端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。但是关闭连接时，当 Server 端收到 FIN 报文时，很可能并不会立即关闭 SOCKET，所以只能先回复一个 ACK 报文，告诉 Client 端，”你发的 FIN 报文我收到了”。只有等到我 Server 端所有的报文都发送完了，我才能发送 FIN 报文，因此不能一起发送。故需要四步握手。
连接 在等待中是不会释放的（端口依然被占用）
等待计时器
- 最后一个报文未确认，确保最后一个 发送方的
ack能到达接收方。2msl内没收到，发送方会重发 - 确保当前连接的 所有报文都已过期
补
保活计时器(Keeplive Timer)：
目的：主要是为了防止两个TCP连接出现长时间的空闲。当客户端与服务器端建立TCP连接后，很长时间内客户端都没有向服务器端发送数据，此时很有可能是客户端出现故障，而服务器端会一直处于等待状态。保活计时器就是解决这种问题而生的。
工作原理：每当服务器端收到客户端的数据时，都将保活计时器重新设置（通常设置为2小时）。过了2小时后，服务器端如果没有收到客户端的数据，会发送探测报文段给客户端，并且每隔75秒发送一个，当连续发送10次以后，仍没有收到对端的来信，则服务器端认为客户端出现故障，并会终止连接。