Http1.0和1.1 和2.0的区别

HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；

HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行
机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；在HTTP1.1中新增了24
个错误状态响应码， HTTP 1.1支持长连接

HTTP/2 ，多路复用，即连接共享，即每一个request都是是用作连接共享机制的多个请求可同时在一个连接上并行执
行。某个请求任务耗时严重，不会影响到其它连接的正常执行；服务端推送（server push）

在PC浏览器的地址栏输入一串URL，然后按Enter键这个页面渲染出来，这个过程中都发生了什么事?这个是很多面试官喜欢问的一个问题
如果测试只是停留在表面上点点点，不知道背后的逻辑，是无法发现隐藏的bug，只能找一些页面上看得到的bug。

浏览器输入url按回车背后经历了哪些？

1.在PC浏览器的地址栏输入一串URL，然后按Enter键这个页面渲染出来，这个过程中都发生了什么事?
    1、首先，在浏览器地址栏中输入url，先解析url，检测url地址是否合法
    2、浏览器先查看浏览器缓存-系统缓存-路由器缓存，如果缓存中有，会直接在屏幕中显示页面内容。若没有，则跳到第三步操作。
    浏览器缓存：浏览器会记录DNS一段时间，因此，只是第一个地方解析DNS请求；
    操作系统缓存：如果在浏览器缓存中不包含这个记录，则会使系统调用操作系统，获取操作系统的记录(保存最近的DNS查询缓存)；
    路由器缓存：如果上述两个步骤均不能成功获取DNS记录，继续搜索路由器缓存；
    ISP缓存：若上述均失败，继续向ISP搜索。
    3、在发送http请求前，需要域名解析(DNS解析)，解析获取相应的IP地址。
    4、浏览器向服务器发起tcp连接，与浏览器建立tcp三次握手。
    5、握手成功后，浏览器向服务器发送http请求，请求数据包。
    6、服务器处理收到的请求，将数据返回至浏览器
    7、浏览器收到HTTP响应
    8、浏览器解码响应，如果响应可以缓存，则存入缓存。
    9、 浏览器发送请求获取嵌入在HTML中的资源（html，css，javascript，图片，音乐······），对于未知类型，会弹出对话框。
    10、 浏览器发送异步请求。
    11、页面全部渲染结束。

GET 和 POST 的区别

2.get和post请求区别，这个是被问烂的题了
首先这个题看似简单，实际上是个送命题！如果你百度搜到的标准答案可能是这样的（本标准答案参考自w3schools）：
GET在浏览器回退时是无害的，而POST会再次提交请求。
GET产生的URL地址可以被Bookmark，而POST不可以。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求在URL中传送的参数是有长度限制的，而POST么有。
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET参数通过URL传递，POST放在Request body中。
如果我告诉你，你死记硬背的这些所谓“标准答案”不是面试官想要的，你肯定不服，首先从安全性讲，get和post都一样，没啥所谓的哪个更安全
get请求参数在url地址上，直接暴露，post请求的参数放body部分，按F12也直接暴露了，所以没啥安全性可言
“GET参数通过URL传递，POST放在Request body中”这个其实也不准，post请求也可以没body，也可以在url传递呢？
如果我告诉你 get 请求和 post 请求本质上没区别，你肯定不信！
GET和POST有一个重大区别，简单的说：
GET产生一个 TCP 数据包；POST 产生两个 TCP 数据包。
长的说：
对于GET方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

cookies机制和session机制的区别

3.cookies机制和session机制的区别，这个也是经常会问的
cookies数据保存在客户端，session数据保存在服务器端；
cookies可以减轻服务器压力，但是不安全，容易进行cookies欺骗；
session较安全，但占用服务器资源

HTTP状态码

200 请求已成功，请求所希望的响应头或数据体将随此响应返回。
201 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回
202 服务器已接受请求，但尚未处理
301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
401 当前请求需要用户验证。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书
403 服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交
404 请求失败，请求所希望得到的资源未被在服务器上发现
500 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。
501 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。
502 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
503 由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复

http和https区别

HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，
于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS和HTTP的区别主要如下：

总的来说： HTTPS=SSL+HTTP

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
（这个只是默认端口不一样，实际上端口是可以改的）
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

报文

7.HTTP请求报文与响应报文格式
请求报文包含三部分：
a、请求行：包含请求方法、URI、HTTP版本信息
b、请求头部（headers）字段
c、请求内容实体(body)
响应报文包含三部分：
a、状态行：包含HTTP版本、状态码、状态码的原因短语
b、响应头部（headers）字段
c、响应内容(body)实体

post请求body

8.常见的 POST 提交数据方式
application/x-www-form-urlencoded
multipart/form-data
application/json
text/xml

DNS

域名解析服务。将主机名转换为IP地址。如将http://www.cnblogs.com/主机名转换为IP地址：211.137.51.78

10.什么是Http协议无状态协议?怎么解决Http协议无状态协议?

(1)、无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息
(2)、无状态协议解决办法： 通过1、Cookie 2、通过Session会话保存。

三次握手 四次挥手

服务器结束TCP连接的时间要比客户端早一些

为什么TCP客户端最后还要发送一次确认呢

主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，
由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，
传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，
两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。
由于服务器收不到确认，就知道客户端并没有请求连接。

为什么客户端最后还要等待2MSL？

1、保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，
客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，
而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器

2、防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，
在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，
时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，
服务器就认为客户端出了故障，接着就关闭连接。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

1、建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
2、关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，
所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，
因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

一、为什么要用Cookie和Session？

很多时候客户端和服务器进行交互使用了HTTP协议，但是HTTP协议是无状态的；HTTP协议的请求过程，是基于 TCP/IP 的，
当客户端请求服务器，服务器处理后，进行响应，该过程是无状态的。
但是在有些时候是需要保存一些客户端的请求信息，识别客户端的某些状态，智能的、有针对性的去分析某些客户端的习惯。这些时候，
就需要去记录客户端的连接状态，识别请求的状态等。所以为了解决类似的事情，就需要使用到了 Cookie 和 Session。
比如，
使用Cookie的场景：有些网站有记住用户名的功能，当你勾这个的时候，下次进入该网站时，就会保存上一次登录的用户名；
使用Seesion的场景：利用Seesion来验证用户是否已登录，利用Session来保存验证码。

初始序列号是什么？

TCP连接的一方A，随机选择一个32位的序列号（Sequence Number）作为发送数据的初始序列号，比如为1000，以该序列号为原点，
对要传送的数据进行编号：1001、1002...三次握手时，把这个初始序列号传送给另一方B，
以便在传输数据时，B可以确认什么样的数据编号是合法的

TCP为啥可靠

特点：无差错、无重复、无丢失、按照顺序传送
机制保证：超时重传、流量控制、拥塞控制

TCP如何保证传输的可靠性

1数据包校验
2对失序数据包重新排序（TCP报文具有序列号）
3丢弃重复数据
4应答机制：接收方收到数据之后，会发送一个确认（通常延迟几分之一秒）；
5超时重发：发送方发出数据之后，启动一个定时器，超时未收到接收方的确认，则重新发送这个数据；
6流量控制：确保接收端能够接收发送方的数据而不会缓冲区溢出

TCP如何实现流量控制

使用滑动窗口协议实现流量控制。防止发送方发送速率太快，接收方缓存区不够导致溢出。接收方会维护一个
接收窗口 receiver window（窗口大小单位是字节），接受窗口的大小是根据自己的资源情况动态调整的，
在返回ACK时将接受窗口大小放在TCP报文中的窗口字段告知发送方。发送窗口的大小不能超过接受窗口的大小，
只有当发送方发送并收到确认之后，才能将发送窗口右移
发送窗口的上限为接受窗口和拥塞窗口中的较小值。
接受窗口表明了接收方的接收能力，拥塞窗口表明了网络的传送能力

TCP的拥塞控制是怎么实现的？

拥塞控制主要由四个算法组成：慢开始（Slow Start）、拥塞避免（Congestion voidance）、
快重传 （Fast Retransmit）、快恢复（Fast Recovery）
慢开始：刚开始发送数据时，先把拥塞窗口（congestion window）设置为一个最大报文段MSS的数值，
        每收到一个新的确认报文之后，就把拥塞窗口加1个MSS。这样每经过一个传输轮次
        （或者说是每经过一个往返时间RTT）， 拥塞窗口的大小就会加倍.

拥塞避免：当拥塞窗口的大小达到慢开始门限(slow start threshold)时，开始执行拥塞避免算法，
      拥塞窗口大小不再指数增加，        而是线性增加，即每经过一个传输轮次只增加1MSS.

快重传：快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有
        报文段没有到达对方） 而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要
        一连收到三个重复确认就应当立即重传对方尚未收到的报文段

快恢复：当发送方连续收到三个重复确认时，就把慢开始门限减半，然后执行拥塞避免算法

什么叫无连接

UDP发送数据之前不需要建立连接

什么叫不可靠

UDP接收方收到报文后，不需要给出任何确认

TCP是面向字节流的，UDP是面向报文的

面向字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，
而UDP一个报文只能一次发完

Https的连接过程？

1、客户端向服务器发送请求，同时发送客户端支持的一套加密规则（包括对称加密、非对称加密、摘要算法）

2、服务器从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，
加密公钥（用于非对称加密），以及证书的颁发机构等信息（证书中的私钥只能用于服务器端进行解密）；

3、客户端验证服务器的合法性，包括：证书是否过期，CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的
“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配；

4、如果证书受信任，浏览器会生成一个随机密钥（用于对称算法），并用服务器提供的公钥加密（采用非对称算法对密钥加密）；
使用Hash算法对握手消息进行摘要计算，并对摘要使用之前产生的密钥加密（对称算法）；
将加密后的随机密钥和摘要一起发送给服务器；

5、服务器使用自己的私钥解密，得到对称加密的密钥，用这个密钥解密出Hash摘要值，并验证握手消息是否一致；
如果一致，服务器使用对称加密的密钥加密握手消息发给浏览器；

6、浏览器解密并验证摘要，若一致，则握手结束。之后的数据传送都使用对称加密的密钥进行加密