APP网络优化相关问题

　　目录HTTP协议 HTTPS与网络安全 TCP/UDP DNS解析 Session/Cookie
　　HTTP 超文本传输协议请求响应报文 链接建立流程 HTTP特点
　　请求报文
　　HTTP协议使用TCP协议进行传输，在应用层协议发起交互之前，首先是TCP的三次握手。完成了TCP三次握手后，客户端会向服务器发出一个请求报文。请求报文的格式如下图抓包所示：
　　在HTTP连接中报文分为请求（request）和响应（response）两种。每种报文在HTTP首部都有不同的字段来标识不同的用途。
　　HTTP协议使用TCP协议进行传输，在应用层协议发起交互之前，首先是TCP的三次握手。完成了TCP三次握手后，客户端会向服务器发出一个请求报文。请求报文的格式如下图抓包所示：
　　前三行为请求行，其余部分称为request-header。请求行中的method表示这次请求使用的是get方法。请求方法的种类比较多，如option，get，post，head，put，delete，trace等，常用的主要是get，pos。Get表示请求页面信息，返回页面实体；post是请求服务器将指定文档作为请求的url中的从属实体，简单说，我们常用的在网页中填写表单然后申请等动作就是使用了post方法，填写用户名密码登录站点就使用了post方法。
　　请求行之后是请求首部。首部常见的部分有如下几个：
　　Accept：
　　请求的对象类型。如果是＂/＂表示任意类型，如果是指定的类型，则会变成＂type/＂。
　　Accept-Language：
　　使用的语言种类。
　　Accept-Encording：
　　页面编码种类。
　　Accept-Charset：
　　页面字符集。
　　说到这里，需要解释以下字符集和编码的区别。字符集通常对应着一种语言，将语言中的所有字符集合起来就可以视为一种字符集，这样我们可以看出，中文并非是一种字符集，因为中文无法使用一些字符来进行表示；而编码则是将字符转换为计算机所能识别的2进制数的一种方式，例如常说的unicode，UTF-8，ANSI等等，我们在访问一些国外网站会出现乱码的原因就是因为我们浏览器所使用的编码与页面所使用的编码不能互相识别。我们常说的BIG5和GB2312都是编码。
　　User-Agent：
　　提供了客户端浏览器的类型和版本。
　　Host：
　　连接的目标主机，如果连接的服务器是非标准端口，在这里会出现使用的非标准端口。
　　Connection：
　　对于HTTP连接的处理，keep-alive表示保持连接，如果是在响应报文中发送页面完毕就会关闭连接，状态变为close。
　　响应报文
　　当收到get或post等方法发来的请求后，服务器就要对报文进行响应。同样，响应报文也分为两部分。
　　前两行称为状态行，状态行给出了服务器的http版本，以及一个响应代码。响应代码是服务器根据请求进行查找后得到的结果的一种反馈，共有5大类。分别以1、2、3、4、5开头。
　　1**
　　表示接收到请求，继续进程，在发送post后可以收到该应答。
　　2**
　　表示请求的操作成功，在发送get后返回。
　　3**
　　表示重发，为了完成操作必须进一步动作。
　　4**
　　表示客户端出现错误。
　　5**
　　表示服务器出现错误。
　　其余部分称为应答实体。
　　其中的server表示服务器软件版本，date标注了当前服务器的时间，connection标明连接关闭，抓包可以发现在响应返回后服务器向客户端发出fin包单向关闭了连接。Expires表示在某个时间以前可以不用重新缓存该页面，而cache-control表示对页面是否进行缓存。Pragma的参数no-cache表示对页面不进行缓存。而content-type表示了应答请求后返回的内容类型。Content还有内容长度和内容语言以及内容编码三个项，其中内容长度只有在请求报文中的connection值为keep-alive时才会用到。
　　问题：GET和POST方式的区别 ？
　　初级答案： GET请求参数以？的方式分割拼接到URL后面，POST请求参数在body里面
　　GET参数长度限制2048个字符，POST一般没有该限制
　　GET请求不安全，POST请求安全
　　进阶答案：（从语意角度来回答） GET获取资源：
　　安全 （不引起sever端的任何状态变化，GET， HEAD， OPTIONS）
　　幂等 （同一个请求方法执行多次和执行一次的效果完全相同，PUT，DELETE）
　　可缓存 （代理服务器缓存，官方定义的一种规范，GET，HEAD）
　　POST处理资源：
　　非安全，非幂等，不可缓存
　　常见响应报文状态码含义 1**表示接收到请求，继续进程，在发送post后可以收到该应答。
　　2**表示请求的操作成功，在发送get后返回。
　　3**表示重发，重定向，为了完成操作必须进一步动作。
　　4**表示客户端出现错误。
　　5**表示服务器出现错误
　　HTTP连接建立和断开流程
　　三次握手和四次挥手
　　三次握手和四次挥手
　　问题：HTTP建立连接的时候为什么是三次握手而不是两次？ 超时情况：
　　客户端发送SYN报文，由于网络原因服务端没有收到，此次客户端会启动超时重传策略，再次发送一个SYN报文，服务端收到第二次发送的SYN报文，回复SYN+ACK确认报文，此时经过两次握手连接建立，但是超时的SYN报文随后也传到了服务端，服务端收到第一次发送的SYN报文后会再次建立一个http连接，这并不是我们想要的结果，增加第三次ACK确认后可以避免这种情况的发生。
　　为什么不是四次握手？ 三次已经能够保证正确的连接建立了，没有必要再进行第四次。
　　问题：HTTP断开连接为什么是四次握手？
　　客户端和服务端之间是一个全双工的连接通信，增加的一次握手时为了保证服务端收到客户端断开请求后完成本次传输后再断开。
　　HTTP的特点： 无连接（HTTP的持久连接）
　　无状态（cookie/session）
　　持久连接 Connection : keep-alive 设置位keep-alive表示开启持久连接
　　time:20 超时时间，在20秒之内连接不会断开
　　max: 10 最多可以发生多少个http连接响应对
　　问题：怎样判断一个持久连接已经结束？ 方法一：响应报文中的Content-length：1024 大小是否和我们接受到的数据大小一致，一致为已
　　方法二：最后一个响应报文的chunked字段为空，则表示此次的全部请求结束
　　charlers抓包原理？
　　中间人攻击
　　中间人代理接受客户端的请求，然后假冒客户端向服务器请求数据，再把篡改后的数据返回给客户端
　　HTTPS与HTTP有什么区别？
　　HTTPS=HTTP+SSL/TLS
　　HTTPS是一种安全的HTTP
　　HTTPS建立的连接流程？
　　​会话密钥=randomS+randomC+预主密钥
　　HTTPS都使用到了那些加密手段？为什么？ 对称加密
　　连接建立过程使用了非对程加密，非对程加密安全但是很耗时
　　后续通讯过程使用了对程加密
　　为什么不直接用对称加密？
　　不安全
　　为什么不直接用非对程加密？   1、耗时
　　2、万一私钥泄漏也不能保证绝对安全，而且我们不可能每次http连接前就能在客户端和服务端之间约定好公钥和私钥
　　TCP/UDP都是传输层协议
　　TCP 传输控制协议
　　UDP 用户数据报协议
　　UDP特点 ： 无连接
　　尽最大努力交付（不保证可靠传输）
　　面向报文（即不拆分，也不合并，把应用层的数据报文原封不动的+UDP首部 生成 UDP报文 ，然后传输 给IP层 IP层再+IP首部生成IP报文向外传输）
　　UDP功能 ： 复用 （多端口 复用）分用 （多端口拆分）
　　​ 差错检测
　　接收段以相同的办法去计算检验数据的正确性是否一致，达到差错检测的功能
　　TCP特点： 面向连接 （三次握手连接 四次挥手断开） 可靠传输 （无差错 不丢失 不重复 按序到达） 面向字节流 （不管发送方一次发送多少个字节，TCP都会根据自身的情况或者拆分或者合并，然后把拆分或者合并后的字节流发送给接收方，与UDP的不拆分不合并原则正好相反） 流量控制 （滑动窗口协议，动态调整发送窗口的大小 从而达到流量控制）
　　​ 拥塞控制 （慢开始，拥塞避免策略 和 快恢复，快重传策略）
　　发送一个报文，没有拥塞，第二次发送2个报文，指数增长，直到达到门限制值16，然后改为线型增长，当达到拥塞窗口时（网络开始拥塞），立即回落到初始值，然后重复指数和线型增长的过程，新的门限制调低为上次拥塞窗口值的一半
　　问题：如何界定网络拥塞？
　　连续三个报文的ACK确认信息没有收到，则界定为网络拥塞
　　问题：TCP是怎样保证可靠传输的？
　　何为可靠传输，就是 无差错 不丢失 不重复 按序到达
　　通过停止等待协议处理：无差错情况 ，超时重传，确认丢失，确认迟到，四种情况 无差错情况：
　　正常传输超时重传：
　　报文因网络环境超时，发送端发出报文在一定时间没有收到接收端的确认信息，将视为这条报文超时，发送端将开启重传机制重新发送一条相同的报文给接收端确认丢失：
　　发送端发送一条报文给接收端，接收端收到报文，然后发送一个确认报文给发送端，这条确认报文因为网络原因丢失，发送端没有收到确认报文，误以为接收端没有收到数据报文，开启重传机制，重新发送一条数据报文给接收端，此时接收端收到了两条相同的报文，会删除第二次传的数据报文，并且给发送方重新发送确认报文，发送方收到确认报文后继续传输确认迟到：
　　发送端发送一条报文给接收端，接收端收到报文，然后发送一个确认报文给发送端，这条确认报文因为网络原因迟到，发送端没有收到确认报文，误以为接收端没有收到数据报文，开启重传机制，重新发送一条数据报文给接收端，此时接收端收到了两条相同的报文，会删除第二次传的数据报文，并且给发送方重新发送确认报文，在后续的某个时间，迟到的那条确认报文又传到了发送端，发送端接收到迟的确认报文，什么也不做，继续传递当前的数据报文
　　DNS
　　域名到IP地址的映射，NDS请求采用UDP数据报，且明文
　　DNS解析的查询方式： 递归查询 迭代查询
　　​
　　​
　　NDS解析存在哪些问题？ DNS劫持问题：
　　​DNS解析转发问题：
　　​移动DNS服务器转发给了电信的DNS服务器，造成跨网访问问题，影响访问效率
　　问题：DNS劫持与HTTP的关系是怎样的？
　　没有关系，DNS劫持是发生在哎HTTP请求之前的，所以没有关系
　　问题：怎样解决DNS劫持问题？
　　方案一：httpDNS 正常情况下，使用DNS协议向DNS服务的53端口进行请求 改为，使用http协议向DNS的80端口进行请求 通过IP直连的方式以http的GET请求向NDS服务器发起请求，DNS服务器返回IP，HTTP的安全访问这样就规避了DNS劫持
　　​
　　方案二：长连接 通过内网专线与长连server建立一个长连接通道，避开访问外网DNS服务器
　　​
　　session/cookie
　　是对http协议无状态特点的补偿
　　cookie记录用户状态，区分用户，保存在用户端
　　​客户端发送的cookie在请求报文的cookie首部字段中
　　服务端返回的cooki在响应报文的set-cookie首部字段中
　　问题：怎样修改cookie？ 新的cookie覆盖旧的cookie
　　覆盖规则：name，path，domain，等需要与原kookie一致
　　问题：怎样删除cookie？ 新的cookie覆盖旧的cookie
　　覆盖规则：name，path，domain，等需要与原kookie一致
　　设置cookie的exprice=过去的某个时间，或者maxAge=0，cookie失效，等同于删除
　　问题：怎样保证cookie的安全？ 对cookie进行加密
　　只在https上携带cookie
　　设置cookie为httpOnly，防止跨站脚本攻击
　　session 也是用来记录用户状态，存放在服务器端
　　session要依赖于cookie存在