网络通信（应用层/传输层）

应用层

应用层：直面程序员的一层，应用层的协议由程序员自己实现
自定制协议：
功能：客户端将俩个数字发给服务端，服务端取得数据后运算，返回结果；
int i= 1; int j = 2; char op = ‘+’;
1.–将所有数据转化为字符串，使用特殊字符间隔，就将数据按指定协议组织起来了；
2.采用结构体构造二进制数据串，
struct cal_t{
int i= 1;
int j = 2;
char op = ‘+’;
};
序列化：将数据对象按照指定协议组织成为持久化存储/数据传输的二进制字符串；
反序列化：将二进制字符串按照指定协议解析得到各个数据对象；

知名协议—HTTP协议
http协议：超文本传输协议，早期用来传输HTML，随着发展，不限制数据格式；
URL（统一资源定位器）：在网络中标识唯一的资源（网址）
如何–URL中包含的元素：
协议方案名称：//认证用户名：认证密码@服务器IP地址：服务器处理进程端口/请求的资源路径？查询字符串#片段标识符
http://usename:password@www.baidu.com:80/index.html？name=wanghao#ch
服务器地址：我们所见的IP地址不一定是IP地址，也有可能是域名（服务器的别名）–通过域名解析服务器就可以得到服务器IP地址；
服务器端口：web服务器默认HTTP服务器端口是80端口，默认不显示；
查询字符串：客户端提交给服务器的数据，由key = val形式的键值对组成；
查询字符串不能出现的字符：由于url中特殊字符有特殊含义，一旦提交的数据中有特殊字符，有可能造成歧义，若有特殊字符，需要转译；
urllencode:url编码，将特殊字符的每一个字节，转化为16进制的数字字符，并且使用%前缀作为转义标识，+转化为%2b;
urldecode:url解码,在url中遇到%时，则认为后面的俩个字符需要转义，将第一个字符数字乘以16左移4位，加上第二个字符转化为数字
片段标识符：HTML中的一个标签id，直接跳转到页面的某个位置；

HTTP协议实现

HTTP协议格式：
首行：：GEThttp://192.168.0.1/admin HTTP/1.1，以空格的形式间隔三个要素，最终以\r\n作为结尾；
请求方法
GET–请求实体资源，也可以通过url中查询字符串向服务器提交数据–数据不安全/url有长度的限制（服务器运营商的限制）
POST–主要向服务器提交数据，提交的数据存在正文中，GET请求没有正文，POST有正文；
HEAD—类似于GET，head需要响应头部，不需要响应正文；
URL：http//192.168.0.1/admin
协议版本：
0.9版本：http仅仅用于传输html数据，并且只有get请求，协议格式不完整；
1.0版本：规定了http协议格式，增加了多种请求方法，并且支持了不同文件格式的数据流传输；
1.1版本：在1.0的版本基础上加上了请求方法和头部描述信息，并且支持了长连接，管线化传输；
2.0版本：采用了二进制流式传输，并且支持多路复用，并且允许服务器主动推送数据；
短连接：http基于传输层的tcp传输，发送一个请求得到回复后，则关闭连接；
长连接：一次可以发送多条请求；

请求头部：描述本次请求的关键字信息，由key=：val键值对组成，并且每个键值对之间通过\r\n结束；
Connection：控制长短连接/Cache-Control:缓存控制/User-Agent客户端属性/Accept-描述自己所能接收的数据属性/Content-Length-描述正文长度/Content-Type描述正文数据类型/
Cookie：早期http是短连接通信，是无状态协议，不会保存状态，每次访问都需要重新登录，引入Cookie；
Cookie带有一些信息，持续在通信中描述客户端的通信状态，但是不够安全；
空行：间隔头部与正文，接收http数据时，出现\r\n\r\n时，认为头部到此结束；
正文：提交给服务器的数据；

响应：

首行：
HTTP/1.1 303 See Other,包含三个要素，以空格间隔，以\r\n结尾
协议版本：0.9/1.0/1.1/2.0
响应状态码：
1xx：描述信息；
2xx:表示此次请求正确处理完毕 eg：200；
3xx：重定向-所请求的资源在其他位置，要求客户端重新请求新的位置 eg：301永久/302临时
4xx：表示客户端错误，eg：400请求格式错误 /404 -请求资源不存在
5xx：表示服务端错误，500服务器内部错误/502代理请求失败，无效响应/504请求超时；
状态码描述：官方文档的定义，也可以自定义；

**头部：**关于本次响应一些关键字段的描述，以键值对的形式存在，以\r\n为结束标识；
Transfer-Encoding：正文实体传输方式/Expires-缓存过期时间/Location-3xx重定向的位置/
Set-Cookie–服务器通过set-cookie向客户端发送传递信息，会被保存在客户端浏览器的cookie文件中；
Session–会话，服务端会为每个登录客户端的创建会话，在服务端描述会话信息，（客户的身份信息，状态信息），保存在服务端，可以通过cookie返回给客户端Session ID，客户端每次通信都会通过cookie带上自己的Session ID；
cookie和Session的区别
cookie是保存在客户端的的数据，用于持续与服务端进行信息传递的手段；
session是一种会话控制，服务器保存的会话信息包括客户端的身份状态信息；

传输层

传输层：负责应用程序之间的数据传输（通过端口的描述-描述哪俩个进程进行通信）–UDP/ TCP；

UDP – 无连接，不可靠，面向数据报

UDP协议格式：UDP协议报头只有8字节；

特性解析：
无连接：不需要建立连接，只要得到对方的地址信息就可以发送数据；
不可靠：UDP在传输层不保证数据安全有序到达对端–需要自己进行包序管理；
面向数据报：有最大的长度限制–取决于数据报长度字段，因为长度字段只有16位，因此数据报总长度不能大于64位，也就是说sendto接口给数据长度不能大于64k-8；
因此若要传输的数据比较大，需要程序员进行分包管理包序管理；

TCP:面向连接，可靠传输，面向字节流

面向连接：连接建立成功后才能进行数据通信–tcp有自己的连接管理–三次握手，四次挥手；

TCP的连接管理中的保活机制
tcp通信中，若长时间没有通信往来，每隔一段时间，服务端会向客户端发送一个保活探测数据包，客户端多次若无响应，则认为连接断开
长时间没有数据传输 ：默认720s（可配置）
间隔时间：75s（可配置）
连续无响应次数：9次（可配置）

可靠传输
1.面向连接；
2.确认应答机制：发送数据要求对方进行回复，才可以知道对方是否收到数据，可以通过序号以及确认序号实现；
3.超时重发机制：发送数据响应超时时，认为数据丢失，重新发送数据
4.通过序号/确认序号实现数据的有序传输；
5.通过校验和检验字段的一致性，不一致则重新发送

数据连续发送时，如果序号小的丢失，接收方即使接收到了后面的数据，也不会进行对数据的回复（原因：确认序号回复即可证明前面的数据接收成功，这样的机制可以防止数据的丢失导致数据重传）
就算后发的数据先到了，接收方也会严格按照序号接收，后发的数据会先存放在数据传冲区中，按照序号先进行存放；

额外的丢包问题处理
1.发送方发送数据过快，接收方来不及处理，接收缓冲区溢出，数据会丢失
2.发送方发送大量数据由于网络状态不好导致重传；
滑动窗口机制
定义：依靠协议中的窗口的大小字段实现流量控制；
接收方通过协议中的窗口大小，告诉发送方最多可以发送多少数据
MSS：最大数据段大小，表示tcp数据通信时一条数据的最大大小，通信时双方进行协商，取双方mss中较小的一方作为最大数据段的大小；
滑动窗口通过前沿序号和后沿序号组成，窗口的大小不能大于缓冲区剩余空间的大小；
1.发送窗口：
后沿：所要发送数据的起始序号，后沿的移动取决于是否得到了数据回复
前沿：根据接收方的窗口大小计算的结束序号，取决于窗口的大小（前沿减去后沿的大小等于接收窗口的大小）
2.接收窗口
后沿：接收数据的起始序号，后沿的移动取决于是否接收到了新数据
前沿：根据缓冲区的剩余空间大小计算得到接收数据的结束序号，前沿的移动取决于剩余缓冲区的大小；

问题
1.为什么握手是三次，挥手是四次？
握手：俩次不安全，四次没必要；
TCP通信需要确保双方都具有数据的收发能力，因此双方必须都要发送SYN确保对方具有通信的能力；
发送FIN包，只能表示对方不再发送数据了，不表示对方不再接收数据，因此被动关闭方进行ACK回复后有可能会发送数据，等到不再发送数据，才会发送下一个FIN包，因此FIN和ACK是分开的

2.TIME_WAIT的作用，即为什么主动关闭方没有直接进入close阶段？
假设主动关闭方最后一次的ACK丢失，被动关闭方超时后会重新发送一个FIN，假设客户端没有TIME_WAIT直接释放资源，有可能新的客户端会使用之前的地址信息；
1.刚启动的客户端绑定地址信息成功，收到传来的FIN包，对新连接造成影响；
2.新启动的客户端连接握手时，服务端处于上次连接的状态，会发送RST,因

综上：不进行TINME_WAIT有可能会对新的；连接造成影响；

等待的时间：2个MSL时间，MSL–报文最大的生命周期；
1.足够ACK和新的FIN包时间，直到所有报文生命周期结束；

3.tcp握手失败，服务端如何处理
1.没有收到SYN，服务端不做处理
2.回复了ACK和SYN，长时间没有响应后，发送RST重连；

4.释放资源时，一台主机出现大量TIME_WAIT如何处理？

TIME_WAIT是主动关闭方提出来的，出现大量的该操作说明，主机客户端大量的关闭了连接，常见于一些爬虫服务器；

5.一台主机出现了大量的CLOSE_WAIT是什么原因
该状态是客户端发送FIN后的服务器的操作，如果没有出现，可能是服务端忘记了最后一步，直接关闭了连接；