5、TCP粘包现象原因和解决方法
原因：
TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。
出现粘包现象的原因是多方面的，它既可能由发送方造成，也可能由接收方造成。
粘包出现原因
简单得说，在流传输中出现，UDP不会出现粘包，因为它有消息边界(参考Windows网络编程)
1发送端需要等缓冲区满才发送出去，造成粘包
2接收方不及时接收缓冲区的包，造成多个包接收
具体点：
（1）发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。
（2）接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。
粘包情况有两种，一种是粘在一起的包都是完整的数据包，另一种情况是粘在一起的包有不完整的包。
不是所有的粘包现象都需要处理，若传输的数据为不带结构的连续流数据（如文件传输），则不必把粘连的包分开（简称分包）。但在实际工程应用中，传输的数据一般为带结构的数据，这时就需要做分包处理。
在处理定长结构数据的粘包问题时，分包算法比较简单；在处理不定长结构数据的粘包问题时，分包算法就比较复杂。特别是粘在一起的包有不完整的包的粘包情况，由于一包数据内容被分在了两个连续的接收包中，处理起来难度较大。实际工程应用中应尽量避免出现粘包现象。
为了避免粘包现象，可采取以下几种措施：
（1）对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满；
（2）对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象；
（3）由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。
以上提到的三种措施，都有其不足之处。
（1）第一种编程设置方法虽然可以避免发送方引起的粘包，但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能，一般不建议使用。
（2）第二种方法只能减少出现粘包的可能性，但并不能完全避免粘包，当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。
（3）第三种方法虽然避免了粘包，但应用程序的效率较低，对实时应用的场合不适合。
一种比较周全的对策是：接收方创建一预处理线程，对接收到的数据包进行预处理，将粘连的包分开。对这种方法我们进行了实验，证明是高效可行的。
6、为什么是三次握手 为什么两次不行？
三次握手都做什么？
三次握手 建立起 TCP连接 的 reliable，分配初始序列号和资源，在相互确认之后开始数据的传输。有 主动打开(一般是client) 和 被动打开(一般是server)。
TCP使用3次握手建立一条连接，该握手初始化了传输可靠性以及数据顺序性必要的信息，这些信息包括两个方向的初始序列号，确认号由初始序列号生成，使用3次握手是因为3次握手已经准备好了传输可靠性以及数据顺序性所必要的信息，该握手的第3次实际上并不是需要单独传输的，完全可以和数据一起传输。详细过程如下所示：
第一步，Client会进入SYN_SENT状态，并发送Syn 消息给Server端，SYN标志位在此场景下被设置为1，同时会带上Client这端分配好的Seq号，这个序列号是一个U32的整型数，该数值的分配是根据时间产生的一个随机值，通常情况下每间隔4ms会加1。除此之外还会带一个MSS，也就是最大报文段长度，表示Tcp传往另一端的最大数据块的长度。
第二步，Server端在收到，Syn消息之后，会进入SYN_RCVD状态，同时返回Ack消息给Client，用来通知Client，Server端已经收到SYN消息并通过了确认。这一步Server端包含两部分内容，一部分是回复Client的Syn消息，其中ACK=1，Seq号设置为Client的Syn消息的Seq数值+1；另一部分是主动发送Sever端的Syn消息给Client，Seq号码是Server端上面对应的序列号，当然Syn标志位也会设置成1，MSS表示的是Server这一端的最大数据块长度。
第三步，Client在收到第二步消息之后，首先会将Client端的状态从SYN_SENT变换成ESTABLISHED,此时Client发消息给Server端，这个方向的通道已经建立成功，Client可以发送消息给Server端了，Server端也可以成功收到这些消息。其次，Client端需要回复ACK消息给Server端，消息包含ACK状态被设置为1，Seq号码被设置成Server端的序列号+1。（备注：这一步往往会与Client主动发起的数据消息，合并到一起发送给Server端。）
第四步，Server端在收到这个Ack消息之后，会进入ESTABLISHED状态，到此时刻Server发向Client的通道连接建立成功，Server可以发送数据给Client，TCP的全双工连接建立完成。
为什么需要三次握手？
TCP的连接因为是全双工的，也就是Client和Server两端，发送消息两个方向的连接都要建立成功。如果要保证双向连接都成功的话，三次通信是最少的次数了。大于三次的话，后面的次数通信就没有必要了，是在浪费资源。
二次的话，会怎么样，可不可以呢？答案是不可以，我们来看下，下面的场景。
在谈论这个之前，我们先要知道TCP是基于IP协议的，而IP协议是有路由的，IP协议不能够保证先发送的数据先到达，这当中依赖于IP协议底层的网络质量，以及Client与Server之间的路由跳数。
Client在发送完Syn消息1，这里称作Syn1之后，假设因为网络原因，Syn1并没有到达Server端，这个时候Client端已经超时，Client之后重新发起SYN消息，这里称作Syn2。结果由于网络原因Syn2先到答Server，Server于是与Client基于Syn2建立了连接，结果没过多久Syn1又到达了Server,Server于是关掉了Syn2建立的那条连接，又重新建立了一条连接。对于Client来说新建立的这条连接是早就过时的，所以Client不会在这条连接上发送任何数据，这就导致了Server端长时间收不到数据，Client新的连接被断掉了。
三次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
三次握手的状态转换？
TCP的状态变化图如下所示，Client和Server的初始状态都是CLOSED状态，其中：
Client:
CLOSED-----发送Syn 消息--->SYN_SENT-----收到Server端发回的SYN+ACK--->ESTABLISHED---发送和接收数据-->......
Server:
CLOSED----收到Client端发送过来的SYN消息-->SYN_RCVD-----发送SYN+ACK消息--->SYN_RCVD----收到Client发回来的ACK消息--->ESTABLISHED-----发送和接收数据-->......
其中TCP的三次握手与Scoket的函数对应关系如下所示：
备注：connect时，触发了连接请求，向服务器发送了SYN J包，这时connect进入阻塞状态；服务器监听到连接请求，即收到SYN J包，调用accept函数接收请求向客户端发送SYN K ，ACK J+1，这时accept进入阻塞状态；客户端收到服务器的SYN K ，ACK J+1之后，这时connect返回，并对SYN K进行确认；服务器收到ACK K+1时，accept返回，至此三次握手完毕，连接建立。
7、TCP四次挥手过程以及状态改变，为什么四次？CLOSE-WAIT和TIME-WAIT存在的意义？如何查看TIME-WAIT状态的链接数量？为什么会TIME-WAIT过多？解决方法是怎样的？
四次挥手过程理解
1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
大量TIME_WAIT造成的影响：
在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。主动正常关闭TCP连接，都会出现TIMEWAIT。
这题太专业了，后面的我看不懂了，以后填坑
8、浏览器输入URL并回车的过程以及相关协议，DNS查询过程。
在浏览器输入URL，按下回车会经历那些流程？
1、DNS域名解析，得到IP地址
DNS解析流程:
（1）.在主机查询DNS缓存，如果没有就会给本地的DNS发送查询请求
（2）.本地的DNS服务器向根域名服务器发送查询请求，根域名服务器返回该域名的一级域名服务器
（3）.该本地服务器给该一级域名服务器发送查询请求，然后依次类推直到查询到该域名的IP地址
2、解析出IP地址后，根据IP地址和默认端口80和服务器建立连接
3、浏览器发出读取文件（URL中域名后边部分对应的文件）的HTTP请求，该请求报文作为TCP三次握手的第三个报文的数据发送给服务器
4、服务器对浏览器的请求作出响应，并把对应的html文本发送给浏览器
5、释放TCP连接（四次挥手断开连接）
6、浏览器解析该HTML文本并显示内容
过程中用到的协议以及作用
1、域名解析用到DNS协议
2、DNS服务器是基于UDP的，因此会用到UDP协议
3、得到IP地址后，浏览器会与服务器建立HTTP连接，用到HTTP协议
4、http协议生成GET请求报文，将该报文传给TCP层处理，用到了TCP协议
5、如果用到了HTTPS协议还会对HTTP协议内容进行加密
6、TCP层若有需要会对HTTP数据报分片，分片依据路径MTU和MSS
7、TCP的数据报会发送给IP层，用到IP协议
8、IP层通过路由选择，将数据发送给目的端口
9、以太网协议需要知道目的IP的物理地址，需要用到ARP协议
用到了网络中的哪些层，每一层的作用
1.DNS协议，HTTP协议，HTTPS协议属于应用层
应用层是体系结构中的最高层。应用层确定进程之间通信的性质满足用户的需要。这里所说的进程就是指正在运行的程序。应用层不仅需要提供应用进程需要的信息交换，而且还要作为相互作用的应用进程的用户代理，来完成一些为进行语义上有意义的交换所必须的功能。
2.TCP/UDP属于传输层
传输层的任务就是负责主机中两个进程间的通信。因特网的传输层可使用两种不同的协议；即面向连接的传输控制协议TCP和无连接的用户数据报协议UDP。面向连接的服务能够提供可靠的交付，两种方式都各有其优点
3.IP协议和ARP协议属于网络层
网络层负责为分组交换网上的不同主机提供通信。在发送数据时，网络层将传输层产生的报文段或用户数据报封装成分组或者包进行传送。在TCP/IP体系中，分组也叫作IP数据报。网络层的另一个任务就是选择合适的路由，使源主机传输层传下来的分组能够交付到目的主机。
4.数据链路层
当发送数据时，数据链路层的任务是将在网络层交下来的IP数据报组装成帧，在两个相邻节点间的链路上传送以帧为单位的数据。每一帧包括数据和必要的控制信息（如同步信息、地址信息、差错控制以及流量控制等信息）。控制信息使接收端能够知道一个帧从那个比特开始到那个比特结束。控制信息还使接收端能够检测到所收到的帧中有没有差错。
5.物理层
物理层的任务就是透明的传送比特流。在物理层上所传输的数据的单位是比特。传递信息所利用的一些物理媒介，如双绞线、同轴电缆、光缆等，并不是在物理层之内而是在物理层的下面。因此也有人把物理媒体当做第0层。
9、HTTP1.0、1.1、2.0之间的区别
http 1.0
1、链接无法复用，即不支持持久链接：
http 1.0 规定浏览器与服务器保持较短时间的链接，浏览器每次请求都和服务器经过三次握手和慢启动（基本思想是当TCP开始传输数据或发现数据丢失并开始重发时，首先慢慢的对网路实际容量进行试探，避免由于发送了过量的数据而导致阻塞）建立一个TCP链接，服务器完成请求处理后立即断开TCP链接，而且不跟踪每个浏览器的历史请求。
注意：由于http 1.0每次建立TCP链接对性能的影响实在是太大，http1.1实现持久化链接之后，又反向移植到http 1.0上，只是默认是没有开启持久链接的，通过http的header部分的 Connection: KeepAlive 来启用）
2、线头阻塞（Head of Line (HOL) Blocking）
请求队列的第一个请求因为服务器正忙（或请求格式问题等其他原因），导致后面的请求被阻塞。
http 1.1
1、支持持久链接（在request和response中的header中的connection是close或者Keep-Alive进行控制）
一个TCP链接可以传送多个http请求和相应，减少了TCP建立链接和关闭链接的消耗。另外http1.1允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能 够区分出每次请求的响应内容。
2、支持http管道
不使用管道的http请求，在使用持久链接时，必须严格满足先进先出的队列顺序（FIFO），即发送请求，等待响应完成，再发送客户端队列中的下一个请求。管道可以让我们把 FIFO 队列从客户端（请求队列）迁移到服务器（响应队列），即客户端可以并行，服务端串行。客户端可以不用等待前一个请求返回，发送请求，但服务器端必须顺序的返回客户端的请求响应结果。
缺点：
a. 一个请求响应阻塞，就会阻塞后续所有请求
b. 并行处理请求时，服务器必须缓冲管道中的响应，从而占用服务器资源，如果有个响应非常大，则很容易形成服务器的受攻击面；
c. 响应失败可能终止 TCP 连接，从页强迫客户端重新发送对所有后续资源的请求，导致重复处理；
d. 由于可能存在中间代理，因此检测管道兼容性，确保可靠性很重要；
e. 如果中间代理不支持管道，那它可能会中断连接，也可能会把所有请求串联起来。
3、使用多个TCP链接
http1.1 在客户端排队所有请求，然后通过一个TCP持久链接，一个接一个的发送请求（如果有http管道还必须顺序等待服务端的顺序返回结果）。但实际中，浏览器的开发时不会这么笨，浏览器允许我们打开N个TCP链接（大多说浏览器是6个TCP链接，这个数字越大，客户端和服务器的资源占用越多，这个数据也只是感觉安全的数字而已）。
带来的好处：
- 客户端可以并行发送最多 N个请求；
- 服务器可以并行处理最多 N个请求；
- 第一次往返可以发送的累计分组数量（TCP cwnd）增长为原来的 N 倍。
代价：
1.更多的套接字会占用客户端、服务器以及代理的资源，包括内存缓冲区和 CPU时钟周期；
2.并行 TCP 流之间竞争共享的带宽；
3.由于处理多个套接字，实现复杂性更高；
4.即使并行 TCP 流，应用的并行能力也受限制。
因此使用多个TCP链接只是权宜之计，后续的http 2.0支持多路复用，很好的解决了上述问题。
4、 http 1.1 增加了请求头和响应头来扩充功能
举例：
a. 支持Host请求：
b. Connection: 请求头的值为Connection时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close 时，客户端通知服务器返回本次请求结果后关闭连接
c. 支持断点续传:
d.身份认证：
e.状态管理:
f. 缓存处理：
5、域名分区
域名分区是思想是将原来集中到一个服务器上的资源分布到多个服务器上，这样就可以突破浏览器的链接限制（一般是6个），提高并行能力。
代价：
- 每多一台主机都要多一次的 DNS 查询，每多一个套接字都会多消耗两端的一些资源；
2.必须手工分离一台主机上的资源到多台；.
实际实践中，效果并不是很明显，反而导致被滥用。
6、http的header的优化
目前所有的header请求都是以没有经过压缩的纯文本的形式发送（通常会有600`1000字节），而通常使用的http请求body却很少（10~200字节），和header相比，显得很少，特别是在使用了cookie之后，这样的矛盾就更加突出，因此要减少header的数据。
7、减少连接次数
即将需要多次才能获取的文件或资源组合并成一个，通过一次网络请求获取。这样减少了协议的开销，间接地将服务器端的管道思维移植到了客户端。缺点：增加复杂性，更缓存带来负担，页面的分步显示，改成一次显示，在网络慢的时候影响用户体验。
8、嵌入小的文件
即将资源嵌入文档（通过URI嵌入图片，音频或PDF），可以减少请求次数。嵌入资源作为页面的返回一部分一次返回，即如果在多个页面中都嵌入同样的资源，那么这个资源将会随着每个页面的加载而被加载，从而增大每个页面的总体大小，如果嵌入资源被更新，客户端只能重新获取有效的资源。
实践：一般只考虑嵌入1~2KB一下的资源
参照建议： - 如果文件很小，而且只有个别页面使用，可以考虑嵌入；
2.如果文件很小，但需要在多个页面中重用，应该考虑集中打包； - 如果小文件经常需要更新，就不要嵌入了；
- 通过减少 HTTP cookie 的大小将协议开销最小化。
http 2.0
HTTP 2.0把解决性能问题的方案内置在了传输层，通过多路复用来减少延迟，通过压缩 HTTP首部降低开销，同时增加请求优先级和服务器端推送的功能。
1、支持多路复用
多路复用允许同时通过单一的 HTTP 2.0 连接发起多重的请求-响应消息，即所有HTTP 2.0 连接都是持久化的，而且客户端与服务器之间也只需要一个连接即可，所有数据流共用同一个连接 ，减少了因http链接多而引起的网络拥塞（在 HTTP1.1 协议中，同一时间，浏览器会针对同一域名下的请求有一定数量限制），解决了慢启动针对突发性和短时性的http链接低效的问题。
2、将通信的基本单位缩小为帧
即应用层(HTTP)和传输层(TCP or UDP)之间增加一个二进制分帧层，因此在多向请求和响应时，客户端和服务器可以把HTTP消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来，解决了http 1.*的对手阻塞问题。
3、首部压缩
http 2.0支持DEFLATE和HPACK 算法的压缩。
4、服务端推送
指客户端请求之前发送数据的机制，在 HTTP 2.0 中，服务器可以对客户端的一个请求发送多个响应。
5、请求优先级
HTTP 2.0 使用一个31比特的优先值,0表示最高优先级, 2(31)-1表示最低优先级，服务器端就可以根据优先级，控制资源分配，优先处理和返回最高优先级的请求帧给客户端。
10、HTTP与HTTPS之间的区别，HTTPS链接建立的过程，了解对称加密算法和非对称加密算法不？
一、Http和Https的区别
Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：
端口不同：Http与Http使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；
开销：Https通信需要证书，而证书一般需要向认证机构购买；
Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。
二、对称加密与非对称加密
对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；
解释这里的密匙：(A,B,C,D)转换成(摸左耳朵，摸右耳朵，放左手，放右手)”
为什么叫对称加密？
一方通过密钥将信息加密后，把密文传给另一方，另一方通过这个相同的密钥将密文解密，转换成可以理解的明文。他们之间的关系如下：
明文 <-> 密钥 <-> 密文
而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。
但是此时交换的两个公钥不一定正确
11、HTTP请求有哪些，多说点。Post和get区别。
HTTP请求的常用方法有：GET方法、POST方法、HEAD方法、PUT方法、DELETE方法、CONNECT方法、OPTIONS方法、TRACE方法。
Post和get区别
- GET提交的数据放在URL中，POST则不会。这是最显而易见的差别。这点意味着GET更不安全（POST也不安全，因为HTTP是明文传输抓包就能获取数据内容，要想安全还得加密）
- GET回退浏览器无害，POST会再次提交请求（GET方法回退后浏览器再缓存中拿结果，POST每次都会创建新资源）
- GET提交的数据大小有限制（是因为浏览器对URL的长度有限制，GET本身没有限制），POST没有
- GET可以被保存为书签，POST不可以。这一点也能感受到。
- GET能被缓存，POST不能
- GET只允许ASCII字符，POST没有限制
- GET会保存再浏览器历史记录中，POST不会。这点也能感受到。
总之，两者之间没有本质区别，区别就在于数据存储的位置。各自有适用环境，根据需求选择合适的方法即可。
12、HTTP常见响应状态码
1.100-199信息响应
100 Continue: 服务器通知浏览器之前一切正常，请客户端继续请求，如果请求结束，可忽略；
101 Switching Protocal: 针对请求头的Upgrade返回的信息。表明服务器正在切换到指定的协议。
103 Early Hints: 此状态代码主要用于与Link链接头一起使用，以允许用户代理在服务器仍在准备响应时开始预加载资源
2.200-299成功响应
200 OK： 请求成功
201 Created: 常用于POST，PUT 请求，表明请求已经成功，并新建了一个资源。并在响应体中返回路径。
202 Accepted: 请求已经接收到，但没有响应，稍后也不会返回一个异步请求结果。 该状态码适用于等待其他进程处理或者批处理的场景。
203 No-Authoritative Information: 表明响应返回的元信息（meta-infomation）和最初的服务器不同，而是从本地或者第三方获取的。
主要用于其他资源的镜像和备份。除了前面的情况，首选还是200。
204 No Content: 请求没有数据返回，但是头信息有用。用户代理(浏览器)会更新缓存的头信息。
205 Reset Content: 告诉用户代理（浏览器）重置发送该请求的文档。
206 Partical Content: 当客户端使用Range请求头时，返回该状态码。
用户代理：代替用户运行的软件，如web浏览器，或者邮件阅读器。
3.300-399重定向消息
300 Multiple Choice： 返回多个响应，需要浏览器或者用户选择；
301 Moved Permanently: 请求资源的URL被永久的改变，新的URL会在响应的Location中给出。
浏览器到新的URL重新请求资源，因为有些客户端会把请求方式method改成GET。所以该状态码建议GET和HEAD方法中使用。
搜索引擎会更新地址到资源的链接（SEO中‘link-judge’被发送到新的URL）。
302 Found: 请求资源的URL被暂时修改到Location提供的URL。未来可能还会有新的修改。
浏览器会根据新的URL重新请求资源。有些客户端会把方法method改为GET，建议在GET和HEAD方法中使用。
搜索引擎不会更改URL到资源的。
303 See Other: 服务通过返回的响应数据指导客户端通过GET方法去另一个URL获取资源。
通常用于POST或者PUT的请求返回结果，重定向到信息提示页面或者进度展示页面。
重定向页面的方法是GET方法。
304 Not Modified: 资源未变更。服务器根据请求头判断，需要资源未修改，只返回响应头；否则将资源一起返回。
发生场景：1）请求方法安全（如GET，HEAD请求）
2）条件请求并且使用了If-None-Match或者If-Modified-Since 的请求头
如果想使用200状态码达到相同304效果，需要强制缓存，需要额外的请求头：Cache-Control, Expires, Vary
307 Temporary Redirect: 临时重定向。基本和302相同。
唯一的区别是这个状态码严格禁止浏览器到新URL请求资源时修改原来的请求方式和请求体。
就是说原来使用POST，这次还是要使用POST。
如果想要用PUT方法去修改一个服务器上没有的资源，可以用303状态码
如果想要把一个POST方法改为GET，请使用303。
308 Permanent Redirect: 永久重定向。基本和301相同。但是严格禁止修改请求方式和请求体。
400-499 客户端错误响应
400 Bad Request: 请求语法有问题，服务器无法识别。
没有host请求头字段，或者设置了超过一个的host请求头字段。
401 UnAuthorized: 客户端未授权该请求。缺乏有效的身份认证凭证，一般可能是未登陆。登陆后一般都解决问题。
403 Forbidden: 服务器拒绝响应。权限不足。
404 Not Found: URL无效或者URL有效但是没有资源。
405 Method Not Allowed: 请求方式Method不允许。但是GET和HEAD属于强制方式，不能返回这个状态码。
406 Not Acceptable: 资源类型不符合服务器要求。
407 Proxy Authorization Required: 需要代理授权。
408 Request Timeout：服务器将不再使用的连接关闭。响应头会有Connection: close。
426 Upgrade Required: 告诉客户端需要升级通信协议。500-599 服务器错误响应
500 Internal Server Error: 服务器内部错误，未捕获。
502 Bad Gateway: 服务器作为网关使用时，收到上游服务器返回的无效响应。
503 Service Unavailable: 无法服务。一般发生在因维护而停机或者服务过载。
一般还会伴随着返回一个响应头Retry-After: 说明恢复服务的估计时间。
504 Gateway Timeout: 网关超时。服务器作为网关或者代理，不能及时从上游服务器获取响应返回给客户端。
505 Http Version Not Supported: 发出的请求http版本服务器不支持。如果请求通过http2发送，服务器不支持http2.0，就会返回该状态码。
13、重定向和转发区别
1、重定向是两次请求，转发是一次请求，因此转发的速度要快于重定向
2、重定向之后地址栏上的地址会发生变化，变化成第二次请求的地址，转发之后地址栏上的地址不会变化，还是第一次请求的地址
3、转发是服务器行为，重定向是客户端行为。重定向时浏览器上的网址改变 ,转发是浏览器上的网址不变
4、重定向是两次request，转发只有一次请求
5、重定向时的网址可以是任何网址，转发的网址必须是本站点的网址
14、cookie和session区别。
1、数据存放位置不同：
cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、安全程度不同：
cookie不是很安全，别人可以分析存放在本地的COOKIE并进COOKIE欺骗,考虑到安全应当使用session。
3、性能使用程度不同：
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用cookie。
4、数据存储大小不同：
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，而session则存储与服务端，浏览器对其没有限制。
5、会话机制不同
session会话机制：session会话机制是一种服务器端机制，它使用类似于哈希表（可能还有哈希表）的结构来保存信息。
cookies会话机制：cookie是服务器存储在本地计算机上的小块文本，并随每个请求发送到同一服务器。 Web服务器使用HTTP标头将cookie发送到客户端。在客户端终端，浏览器解析cookie并将其保存为本地文件，该文件自动将来自同一服务器的任何请求绑定到这些cookie。