网络编程_网络基础2（传输层、应用层）

主要是总结应用层与传输层的作用及协议

应用层：
自定义协议：
序列化：数据进行持久化存储/传输时数据的排布
反序列化：按照制定协议对数据进行解析
知名协议：http（超文本传输） 协议
网址：URL-统一资源定位符
协议方案名：//用户名：密码@服务器地址端口：端口/资源路径?查询字符串#片段标识符
URL：编码/解码：针对的是提交的用户数据
http协议：
http协议三大部分：首行，头部，空行，正文

首行：请求首行，响应首行
请求首行：请求方法（GET/POST/HEAD/PUT/DELETE） URL 协议版本（0.9/1.0/1.1/1.2）\r\n
GET与POST的区别：get无正文 post有正文
响应首行：协议版本 状态码（）状态码描述信息\r\n

头部：一个个以：间隔的键值对，键值对之间以\r\n间隔，每条头部信息都包含特殊含义
Key :val\r\nkey:val\r\n
Content-length/content-Type/Cookie/Referer/Transfer-Encoding/Location//User-Agent
空行：\r\n
正文：
接收一个HTTP头部是否完整…
数据在各层的名称：数据段，数据包，数据帧

传输层：负责端与端之间的数据传输：TCP/UDP

Udp：无连接，不可靠，面向数据报
面向数据包不会产生粘包问题：因为udp数据包中定义数据报长度
UDP协议报头：源端口，目的端口，数据包长度，校验和

UDP数据包最大长度：64k；
若用户sendo发送的数据长度大于64k-8则会报错；因为UDP在传输层不会自动进行数据分段

意味着如果传输的数据若大于64k 则需要用户在应用层就开始数据的分段；但是因为传输层udp并不保证数据的有序到达，需要用户在应用层进行包序的管理

Udp协议内部实现了广播功能—udp广播

TCP：面向连接，可靠传输，面向字节流
Tcp的连接管理

三次握手（为什么是三次）四次挥手（为什么四次）
三次：确保 双方都能收发数据，SYN客户端确认能发 SYN+ACK确保服务端收到数据，并且能发数据
ACK确保客户端能收到数据
四次：确认双方数据处理完毕，调用close才会发送FIN包

握手的时候第三次握手失败，服务器会如何处理
为了避免占用大量资源，最后ack等待超时则回复RST报文重置连接

若服务器出现大量TIME_WAIT的原因？ 出现大量断开连接
调整MSL等待时间大小： setsockopt(sockfd SOL_SCOKET,SO_REUSEADDR,int opt = 1,sizeof(opt))

SYN泛洪攻击：大量syn请求，但是不进行ack确认回复
TIEM_WAIT状态
Time_WAIT状态（等待2MSL：俩个最大生命周期）

三次握手，四次挥手过程：

假如没有time_wait状态，主动关闭方直接进入CLOSED，如果立即重启客户端使用相同的端口 在最后一次ACK丢失时，
服务端重发FIN请求，就会被新启动的客户端接收到；
或者新启动的客户端向服务端发起请求的时候；因为i服务端正在等待最后一次ACK，因此新连接请求发送的SYN就会被认为请求码错误，回复RST重置连接
因此需要主动关闭放发送最后一次ACK之后进入一个TIME_WAIT状态等待一段时间：2MSL
等待这段时间就是为了若接收到了重发的FIN请求能够进行最后一次ACK回复
让在网络中延迟的FIN/ACK数据都消失在网络中，

TCP可靠传输：
确认应答机制/超时重传机制---- 保证安全到达
协议中的序号/确认序号—进行包序管理
校验和–验证数据的一致性

Tcp为了实现可靠传输，因此牺牲了部分性能；因此又引入了各种机制来针对不同场景提高传输性能

滑动窗口机制：（窗口是接收方为了告诉发送方最多 我最多能接受多少，所以发送方就要限制发送的数据量，而非要发送端要发送多少数据）
流量控制：通过双方协商的窗口大小进行流量控制，窗口大小不大于接受缓冲区中剩余空间大小；避免因为数据处理不及时导致的大量丢包

通信双方通过协议中的窗口字段，来协商能够一次发送的最多数段，然后连续发送多条数据，若在socket中使用俩个指针维护窗口后延和前沿

发送端：发送的起始位置-后沿，前沿就是发送的结束位置–若窗口中后沿数据没有接收到ack确认，后沿不能向前移动，数据不能从缓冲区移除，接受到ack确认，后沿不能向前移动，数据不能从缓冲区移除，接收到ack确认后窗口前后沿向后移动向后
接收端：接收数据的起始位置–后沿 接受的结束位置–前沿 当接收数据时候若没有接收到第一条数据。则后沿不能移动 只有接收到数据之后，后沿才会向前移动

滑动窗口中的快速重传机制：
Ack确认丢失的情况：
每条数据都要进行回复，并且应该按序逐条回复，如果没有收到第一条，但是都收到了第二、第三条 就不能先回复，应该先回复第一条；带来的好处就是，因为第一条ack丢失后，如果发送端收到第二条的回复，也会认为第一条正常接受；第一条就不需要重传了；
数据丢失的情况：
当数据连续发送n条，但是第一条数据丢失，接收端先接受第二条，这时候接收端认为第一条数据就有可能丢失，因此 直接开始向发送端发送第一条数据的重传请求；连续发送三次（防止网络延迟，有接收到数据包）；当发生端连接接收到三条重传请求，则会对这条数据进行重传 （三次请求时间 < 超时等待时间）

滑动窗口机制，通过窗口大小来确定连续发送多条数据；但是一开始通信的时候，因为不了解网络状态，有可能造成发的越多，丢的越多，超时重传就越多，降低效率

滑动窗口机制中的拥塞窗口（阻塞机制）：定义一个拥塞窗口限制通信起始时，数据发送速度，以及一个阈值控制增长上限；在通信中以慢启动，快增长的形式尽力避免因为网络状况不好导致的丢包发生

延迟应答机制：尽可能的保持窗口大小，保持网络传输吞吐率
捎带应答机制：尽量减少不必要的确认应答报文（在发送数据的时候顺便对上一次的请求进行一个ack确认
因为每条数据的确认回复，说白了也就是只有一个确认序号来实现，若为每个确认回复都新建一个tcp来发送，将要确认的序号放到即将要发送的数据包头中进行发送，尽可能减少纯报头的传输

面向字节流：
传输数据时，并不关注什么是数据，只管传输二进制的数据流

Tcp粘包问题：缓冲区中的数据对于tbp来说没有边界；造成数据粘连的问题
本质问题：数据没有边界
需要用户在应用进行边界管理：
特殊字符问题（http协议）
定长数据
变长数据（udp协议中包含数据长度）

Tcp的连接断开：
进程退出，会进行正规的四次回收断开连接流程
关机：灰烬正规的四次回收断开连接流程
网线断开/断点：tcp内部实现保活机制keep-alive，长时间无通信则进行网络探测：连续多次探测连接有 响应认为连接断开，外在表现：recv返回0/send触发SIGPIPE异常