DNS

DNS的作用就是根据域名找到对应的IP地址

域名的层级

网址的网址倒过来就是域名的层级关系

首先是本地DNS服务器，每一台主机必须连接一个本地DNS，这个DNS的IP可能是自己指定的，有可能是自动分配的

然后是根域名服务器.root，这个.是根DNS服务器，默认情况下所有的网址的最后一位都是.，为了方便用户，通常都会省略，浏览器在请求DNS的时候会自动加上

根域名的下一级，叫做顶级域名，或者一级域名

再下一级叫做次级域名，这个域名用户可以自己注册

再再下一级叫做三级域名，这是用户在自己的域里面为服务器分配的名称，是用户可以任意分配的

查找过程

迭代查找，按如下顺序：本地DNS服务器，根DNS服务器，顶级DNS服务器，主域名DNS服务器

由于根服务器的IP地址一般是不改变的，所以本地DNS服务器默认知道根服务器的地址

在发送查询请求时，本地先向根DNS发送消息，根服务器会给本地返回对应域名的顶级服务器的IP，本地再将请求发送给顶级，然后是次级，三级

例如：. -> .com -> google.com. -> www.google.com.

优化

1，DNS缓存：当DNS服务器找到网址后，网址的IP地址与域名的映射关系会存入每一个DNS服务器的DNS缓存中，便于下一次查找

2，负载均衡：同一个域名可能有多个服务器，DNS会根据负载均衡策略返回承载量最少（最近的）服务器IP给客户端

常见的DNS攻击

1，域名劫持：通过采用黑客手段控制了域名管理密码和域名管理邮箱，然后将该域名的NS纪录指向到黑客可以控制的DNS服务器，然后通过在该DNS服务器上添加相应域名纪录，从而使网民访问该域名时，进入了黑客所指向的内容

2，缓存投毒：利用控制DNS缓存服务器，把原本准备访问某网站的用户在不知不觉中带到黑客指向的其他网站上

3，DDOS攻击：一种攻击针对DNS服务器软件本身，通常利用BIND软件程序中的漏洞，导致DNS服务器崩溃或拒绝服务;另一种攻击的目标不是DNS服务器，而是利用DNS服务器作为中间的“攻击放大器”，去攻击其它互联网上的主机，导致被攻击主机拒绝服务。

4，DNS欺骗：DNS欺骗就是攻击者冒充域名服务器的一种欺骗行为。如果可以冒充域名服务器，然后把查询的IP地址设为攻击者的IP地址，这样的话，用户上网就只能看到攻击者的主页，而不是用户想要取得的网站的主页了

使用的协议

虽然 DNS 服务器支持 TCP 和 UDP 双协议，但是通常我们在做 DNS 查询的时候，也只用到了 UDP 协议

使用基于UDP的DNS协议只要一个请求、一个应答就好了，而使用基于TCP的DNS协议要三次握手、发送数据以及应答、四次挥手，明显基于TCP协议的DNS更浪费网络资源

DNS通常在以下两种情况下使用TCP协议：

1，DNS 查询响应报文大于 512 字节时
2，DNS为保证高可用，需要搭载DNS集群（只用作主备模式），进行主从复制的时候，使用TCP连接保证成功率

HTTP协议

超文本传输协议（Hypertext Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应

HTTP请求报文

1，请求行：包括对服务端的请求方式（get、post）、请求路径以及参数、协议版本号

2，请求头：附加信息，是一个个的键值对，如Connection：Keep-alive

3，请求体：传递给客户端数据储存在请求正文中，如上传文件、post提交表单等操作

GET和POST有什么区别

相同点：
本质上没什么区别，都是基于TCP连接，都是HTTP请求报文

不同点：
对服务器请求是查询时使用get，url可能会很长并且明文（把信息在url后面），在URL中传送的参数有长度限制，可以成为书签，没有请求体

对数据库进行修改时使用post，安全（信息在请求体中）

还有一点略微的不同，用ruby构建http服务时，发送post报文时会先发送请求头，等待一段时间后再发送请求体

幂等性和非幂等性

幂等性是指在服务器资源没有被其他方式改变的情况下一个请求不管请求多少次返回的资源都不会出现变化，非幂等性则是每次请求都会返回不同的结果

幂等性是分布式系统设计中十分重要的概念，具有这一性质的接口在设计时总是秉持这样的一种理念：调用接口发生异常并且重复尝试时，总是会造成系统所无法承受的损失，所以必须阻止这种现象的发生

HTTP GET方法用于获取资源，不应有副作用，所以是幂等的

HTTP DELETE方法用于删除资源，有副作用，但它应该满足幂等性，因为它只会删除一次资源

HTTP POST方法不具备幂等性，因为每次调用都会在服务器创建新的东西

HTTP PUT请求方法请求服务器接受并存储提供的URI中包含的实体。 如果该URI引用已经存在的资源，则该资源被修改; 如果URI不指向现有资源，则服务器可以使用该URI创建资源，因此它是非幂等性的

HTTP响应报文

1，响应行：状态码，状态码解释，协议版本号

2，响应头：附带信息，对应请求报头

3，响应体：返回的主体信息，http，css等数据都是放在响应体中的

状态码

1xx：请求正在被处理
2xx：成功响应
3xx：重定向
4xx：客户端错误（客户端找到的地址错误，或者服务器转发地址错误）
5xx：服务器错误，未响应合理请求（代码写错了）

常见状态码：
100：要求继续发送数据
200：成功
204：返回空内容
301：永久重定向（服务器返回一个新域名，此时用户使用新域名去访问服务器得到网站，并且浏览器网站变更为新网址，当多个域名指向网站主域通常使用301）
302：暂时重定向（用户的浏览器在收到响应后，输入栏仍是显示旧网址，但是显示的是新网址的内容，在csdn里访问外网时会弹出一个拦截，使用的就是暂时重定向）
403：拒绝访问（没有权限）
404：服务器接到请求，但是找不到地址
500：服务器内部错误（一般是代码错误）

长连接短连接

http的长连接与短链接实质上是TCP的连接，http1.1的长连接使用了线程池实现了连接复用

长连接：在HTTP/1.1中默认使用，资源获取后TCP连接不断开，减少建立连接线路时的资源消耗

短链接：在HTTP/1.0中默认使用，每传输一次web资源，tcp都会断开

线程池的连接复用

在HTTP1.1中，HttpClient通过连接池来管理持久连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟（在物理层这个叫时分复用）

连接池对keepalive的主要需要处理两个地方：一个是maxKeepAliveRequests连接达到最大的设置次数，超过这个次数其他的连接都会被设定为短链接，另一个为keepAliveTimeout超过该时间没有流量，则会关闭掉连接

这种方法的缺点是，连接复用基于TCP，多个HTTP连接到一个TCP端口，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，因此有某个请求处理时间过长，后面的请求只能等待

HTTP如何保存用户状态（session、cookie、token混合使用）

http无状态，即连接后不知道客户端状态，翻译成通俗的语言就是系统不知道哪个用户进行操作

session：存放在服务器，用于获取用户状态，session一般存放在缓存或者数据库中，一般在cookie中存放sessionID，这个sessionID可以唯一标识一个用户以此让系统知道该连接对应哪个用户，如果cookie被禁用，则存放在URL中

cookie：存放在用户端，用于记录用户信息或者服务器返回的数据，这些数据可以让系统了解该用户状态

token：有些系统会返回一个token存放在cookie中，token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，用户只要带上这个令牌就无需再次带上用户名和密码

那么问题来了，token不和sessionID作用一样吗，它们有什么区别啊？

token是无状态的，在使用sessionID的情况下如果大量的用户访问会占用大量的空间，而且在分布式系统中，存放sessionID需要考虑数据一致性问题，而如果是token的话，系统接受后会进行一系列认证过程来确定用户，以CPU计算时间换取存储空间

HTTP2.0的IO多路复用

HTTP2.0的IO多路复用有两个很重要的概念分别叫流和帧

流代表某个客户端和服务器的连接，每个流都有一个独一无二的ID，多个流可以在一个http连接中

帧就是流动在流中的最小单元，以二进制格式来传输数据，用唯一的ID来标记它属于哪一个流，在HTTP/2的标准中定义了10种不同的帧类型，包括帧头、数据帧、终止流等等

多路复用代替了HTTP1.x的序列和阻塞机制，所有的相同域名请求都通过同一个TCP连接并发完成。同一TCP中可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免HTTP旧版本中的队头阻塞问题，极大的提高传输性能

URI和URL

URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。比如www.baidu就是www.baidu.com的URI。uri是不固定的，是相对来说的，具体是什么就看你的参照角度是什么

URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI（URI时URL的父类），即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源，大家把浏览器地址栏里访问网站的地址认为是URL就好了

HTTPS

基础概念

密钥：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数

对称加密：加密解密使用相同密钥，双方在建立连接时商定一个密钥，之后双方使用这个密钥进行加密解密，双方之间传输的是加密后的报文。这个方法的缺点在于，双方在建立连接时商定密钥的报文被截取了，任何人都可以冒充目标，所以这个方法不是很安全

非对称加密：这种加密可以生成公钥和私钥，公钥可以解开被私钥的数据，但不能解开被自己加密的数据，私钥也一样，建立连接时向对方发送公钥，这样就是被截取了，也不能解密数据。这个方法的缺点在于性能，双方都得向对方发送公钥

TLS加密过程

TLS协议是基于TCP协议之上的，中文名字叫安全传输层协议

图中第一个蓝色往返是TCP的握手过程，之后两次橙色的往返，我们可以叫做TLS的握手，所以TLS一共握手三个来回。握手过程如下：

Client1：TLS版本号+所支持加密套件列表+希望使用的TLS选项

Server1：选择一个客户端的加密套件+自己的公钥+自己的证书+希望使用的TLS选项+（要求客户端证书）；

Client2：(自己的证书)+使用服务器公钥和协商的加密套件加密一个对称秘钥（自己生成的一个随机值）；

Server2：使用私钥解密出对称秘钥（随机值）后，发送加密的Finish消息，表明完成握手

HTTPS加密过程

首先，客户端发起握手请求，以明文传输请求信息，包含版本信息，加密-套件候选列表，压缩算法候选列表，随机数，扩展字段等信息(这个没什么好说的，就是用户在浏览器里输入一个HTTPS网址，然后连接到服务端的443端口)

服务端的配置，采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。

服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 以及证书。(这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等)

客户端验证证书的合法性，包括可信性，是否吊销，过期时间和域名。(这部分工作是由客户端的SSL/TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个随机值。然后用证书（也就是公钥）对这个随机值进行加密)

客户端使用公匙对对称密匙加密，发送给服务端。(这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了)

服务器用私钥解密，拿到对称加密的密匙。传输加密后的信息，这部分信息就是服务端用私钥加密后的信息，可以在客户端用随机值解密还原

SSL

SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持

HTTPS是HTTP报文直接将报文信息传输给SSL套接字进行加密，SSL加密后将加密后的报文发送给TCP套接字，然后TCP套接字再将加密后的报文发送给目的主机，目的主机将通过TCP套接字获取加密后的报文给SSL套接字，SSL解密后交给对应进程

SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等

HTTP和HTTPS的区别

http为明文传输，不加密，使用端口80， HTTP协议运行在TCP之上

https在建立连接时使用对称加密与非对称加密混合使用，https使用端口为443，HTTPS是运行在SSL/TLS之上的应用层协议