HTTP相关知识

HTTP请求报文

HTTP请求报文由请求行，请求头部，空行和请求数据四个部分组成。这四个部分，每个部分的结束都带有\r\n两个字符，除了最后的请求数据，对于GET方法，没有请求数据，对于POST方法，在处理请求报文中的请求数据时，要特殊处理；

• GET方法
  

• POST方法
  

1. 请求行：用来说明请求类型，要访问的资源以及所使用的HTTP版本。
   1. GET说明请求类型为GET，/562f25980001b1b106000338.jpg(URL)为要访问的资源，该行最后一部分说明使用的是HTTP1.1版本；
2. 请求头部：紧接着请求行之后的部分，用来说明服务器使用的附加信息。
3. 空行：请求头部后面的空行是必须的，即使第四部分的请求数据为空，也必须有空行。
4. 请求数据也叫主体，可以添加任意的其他数据。

POST和GET方法

GET方法没有请求实体，而POST方法有请求实体；

1. 请求参数长度限制：GET请求长度最多1024KB，POST对请求数据没有限制。

2. GET产生一个TCP数据包，POST产生两个TCP数据包。对于GET方式的请求，浏览器会把HTTP header和data一起发送出去，服务器响应200 OK返回数据。对于POST方法，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 OK（返回数据）。注意，尽管POST请求会分为两次，但是body是紧跟着header后面发送的，不存在等待服务器响应的说法。

3. POST比GET安全性要高，通过GET提交的数据都将显示在URL上，页面会被浏览器缓存，其他人查看历史记录会看到提交的数据，而POST不会。

4. GET请求参数通过URL传递，多个参数以&连接，POST请求放在request body中。

5. GET请求会被缓存，而POST请求不会，除非手动设置。

6. GET请求支持收藏为书签，POST请求不支持收藏为书签。

7. GET请求参数会被完整保留在浏览器历史记录中，而POST中的参数不会被保留。

8. GET只接受ASCII字符，而POST没有限制。

9. 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将参数写在URL中？的后面，并用&分隔不同的参数；而post是将信息存放在Message Body中传送，参数不会显示在URL中；
• GET请求提交的数据有长度限制（HTTP协议本身没有限制URL及正文长度），POST请求没有内容长度限制；
• GET请求返回的内容会被浏览器缓存起来，而每次提交POST请求，浏览器在你按下F5时会跳出确认框，不会缓存POST请求返回的内容；
• GET对数据进行查询，POST主要对数据进行增删改！简单来说，GET是读，POST是写；

GET请求方式从浏览器的URL地址就可以看到参数；但无论是GET还是POST其实都是不安全的，因为HTTP协议是明文传输的；想要安全传输资料，必须使用SSL/TLS来加密数据，也就是使用HTTPS；

HTTP响应报文

HTTP响应也由四个部分组成，分别是状态行，消息报头，空行和响应正文。

• 状态行：由HTTP协议版本号，状态码，状态消息三部分组成

HTTP报文头部

HTTP协议的请求和响应报文中必定包含HTTP头部。首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。

HTTP请求报文

在请求中，HTTP报文由方法，URI，HTTP版本，HTTP首部字段等部分构成。

HTTP响应报文

在响应中，HTTP报文由HTTP版本，状态码（数字和原因短语），HTTP首部字段3部分构成。

首部字段同时存在与请求和响应报文中，并涵盖HTTP报文相关的内容信息。

HTTP首部字段

HTTP首部字段事构成HTTP报文的要素之一。在客户端与服务器之间以HTTP协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。

使用首部字段是为了给浏览器和服务器提供报文主体大小，所使用的语言，认证信息等内容。

HTTP首部字段由首部字段名和字段值构成，中间用冒号“:”分割。

首部字段名:字段值

例如，在HTTP首部中以Content-Type这个字段来表示报文主体的对象类型。

Content-Type: text/html

就以上实例来看，首部字段名为Content-Type，字符串text/html是字段值。

另外，字段值对应单个HTTP首部字段可以有多个值。如下所示：

Keep-Alive: timeout=15, max=100

HTTP头部本质上是一个传递额外重要信息的键值对。主要分为：通用头部，请求头部，响应头部和实体头部。

• 通用首部字段：请求报文和响应报文两方都会使用的首部。
• 请求首部字段：从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容，客户端信息，响应内容优先级等信息。
• 响应首部字段：从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
• 实体首部字段：针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

通用头部

首部字段名	说明	举例
Cache-Control	用来指定当前的请求/回复中是否使用缓存机制	Cache-Control: no-store
Connection	客户端（浏览器）想要优先使用的连接类型	Connection: keep-alive
Date	报文创建的时间	Date: Dec, 26 Dec 2015 17: 30: 00 GMT
Trailer	会说明在报文主体后记录哪些首部字段，该首部字段可以使用在HTTP/1.1版本分块传输编码时	Trailer: Expiress
Transfer-Encoding	用来改变报文格式	Transfer-Encoding: chunked
Upgrade	要求服务器升级到一个高版本协议	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Via	告诉服务器，这个请求是由哪些代理发出的	Via: 1.0 fred, 1.1 itbilu.com.com (Apache/1.1)
Warning	一个一般性的警告，表示在实体内容中可能存在错误	Warning: 199 Miscellaneous warning

请求头部

协议头	说明	举例
Accept	告诉服务器自己允许哪些媒体类型	Accept: text/plain
Accept-Charset	浏览器申明可接受的字符集	Accept-Charset: utf-8
Accept-Encoding	浏览器申明自己接收编码方法	Accept-Encoding: gzip, deflate
Accept-Language	浏览器可接受的相应内容语言列表	Accept-Language: en-US
Authorization	用于表示HTTP协议中需要认证资源的认证信息	Authorization: Basic OSdjJGRpbjpvcGVul ANIc2SdDE==
Expect	表示客户端要求服务器做出特定的行为	Expect: 100-continue
From	发起此请求的用户的邮件地址	From: user@itbilu.com
Host	表示服务器的域名以及服务器所监听的端口号	Host: www.itbilu.com:80
If-XXX	条件请求	If-Modified-Since: Dec, 26 Dec 2015 17:30:00 GMT
Max-Forwards	限制该消息可被代理及网关转发的次数	Max-Forwards: 10
Range	表示请求某个实体的一部分，字节偏移以 0 开始	Range: bytes=500-999
Referer	表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面	Referer: http://itbilu.com/nodejs
User-Agent	浏览器的身份标识字符串	User-Agent: Mozilla/……

响应头部

协议头	说明	举例
Accept-Ranges	字段的值表示可用于定义范围的单位	Accept-Ranges: bytes
Age	创建响应的时间	Age：5744337
ETag	唯一标识分配的资源	Etag：W/“585cd998-7c0f”
Location	表示重定向后的 URL	Location: http://www.zcmhi.com/archives/94.html
Retry-After	告知客户端多久后再发送请求	Retry-After: 120
Server	告知客户端服务器信息	Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Vary	缓存控制	Vary: Origin

实体头部

协议头	说明	举例
Allow	对某网络资源的有效的请求行为，不允许则返回405	Allow: GET, HEAD
Content-encoding	返回内容的编码方式	Content-Encoding: gzip
Content-Length	返回内容的字节长度	Content-Length: 348
Content-Language	响应体的语言	Content-Language: en,zh
Content-Location	请求资源可替代的备用的另一地址	Content-Location: /index.htm
Content-MD5	返回资源的MD5校验值	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	在整个返回体中本部分的字节位置	Content-Range: bytes 21010-47021/47022
Content-Type	返回内容的MIME类型	Content-Type: text/html; charset=utf-8
Expires	响应过期的日期和时间	Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified	请求资源的最后修改时间	Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT

HTTP状态码

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。

HTTP状态码由三个十进制数字组成，第一个数字定义了状态码的类型，后两个并没有起到分类的作用。

HTTP状态码共有5种类型：

分类	分类描述
1XX	指示信息——表示请求正在处理
2XX	成功——表示请求已被成功处理完毕
3XX	重定向——要完成的请求需要进行附加操作
4XX	客户端错误——请求有语法错误或者请求无法实现，服务器无法处理请求
5XX	服务器端错误——服务器处理请求出现错误

相应的HTTP状态码列表：

状态码	英文名称	中文描述
100	Continue	继续。客户端继续处理请求
101	Switching Protocol	切换协议。服务器根据客户端的请求切换到更高级的协议
200	OK	请求成功。请求所希望的响应头或数据体将随此相应返回
201	Created	请求已实现。并且有一个新的资源已经依据需求而建立
202	Accepted	请求已接受。已经接受请求，但还未处理完成
203	Non-Authoritative Information	非授权信息。请求成功，但返回的meta信息不在原始的服务器中，而是一个副本
204	No Content	无内容。服务器成功处理了请求，但不需要返回任何实体内容
205	Reset Content	重置内容。与204类似，不同点是返回此状态码的响应，要求请求者重置文档视图
206	Partial Content	部分内容。服务器成功处理了部分GET请求
300	Multiple Choice	多种选择。被请求的资源有一些可供选择的回馈信息，用户或浏览器能够自行选择一个首选地址进行重定向
301	Moved Permanently	永久移动。请求的资源已被永久地移动到新URI，返回信息会包含新的URI，浏览器会自动定向到新URI
302	Found	临时移动。与301类似，但资源只是临时被移动，客户端应继续使用原有URI
303	See Other	查看其他地址。与301类似，使用GET和POST请求查看
304	Not Modified	未修改。如果客户端发送了一个带条件的GET请求且该请求已被允许，而文旦的内容（自上次访问依赖或者根据请求的条件）并没有改变，则服务器应当返回这个状态码
305	Use Proxy	使用代理。被请求的资源必须通过指定的代理才能被访问。
306	Unused	在最新版的规范中，306状态码已经不再被使用
307	Temporary Redirect	临时重定向。请求的资源现在临时从不同的URI响应请求，与302类似
400	Bad Request	客户端请求的语法错误，服务器无法理解；请求的参数有误
401	Unauthorized	当前请求需要用户验证
402	Payment Required	该状态码是为了将来可能的需求而预留的
403	Forbidden	服务器已经理解请求，但是拒绝执行它
404	Not Found	请求失败，请求所希望得到的资源未被在服务器上发现
405	Method Not Allowed	客户端请求中的方法被禁止
406	Not Acceptable	请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体
407	Proxy Authentication Required	与401响应类似，只不过客户端必须在代理服务器上进行身份验证
408	Request Time-out	请求超时。服务器等待客户端发送的请求时间过长，超时
409	Conflict	由于和被请求的资源的当前状态之间存在冲突，请求无法完成
410	Gone	被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址
411	Length Required	服务器拒绝在没有定义Content-Length头的情况下接受请求
412	Procondition Failed	客户端请求信息的先决条件错误
413	Request Entity Too Large	服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围
414	Request-URI Too Large	请求的URI长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务
415	Unsupported Media Type	服务器无法满足expect的请求头信息
416	Requested range not satisfiable	客户端请求的范围无效
417	Expectation Failed	服务器无法满足Expect的请求头信息
500	Internal Server	服务器遇到了一个未曾预料的状况，导致了他无法完成对请求的处理
501	Not Implemented	服务器不支持当前请求所需要的某个功能
502	Bad Gateway	作为网关或代理工作的服务器尝试执行请求时，从远程服务器接受到无效的响应
503	Service Unavailable	由于临时的服务器维护或者过载，服务器当前无法处理请求，一段时间后可能恢复正常
504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求
505	HTTP version not supported	服务器不支持，或者拒绝支持在请求中使用的HTTP版本

HTTP的请求方法

• GET：获取资源，用来请求访问已被URI识别的资源。
• POST：用来传输实体的主体，GET方法也可以实现，但是一般不用。
• PUT：传输文件，PUT方法自身不带验证机制，任何人都可以上传文件，存在安全性问题，一般网站都不采用该方法。
• HEAD：获得报文首部。和GET请求一样，只是不返回报文主体部分。
• DELETE：删除文件。不带验证机制，存在安全性问题。
• OPTIONS：询问值定的请求URI支持哪些方法。

Keep-Alive和非Keep-Alive区别，对服务器性能有影响么？

在早期的HTTP/1.0中，浏览器每次发起HTTP请求都要与服务器创建一个新的TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。然而创建和关闭连接的过程需要消耗资源和时间，为了减少资源消耗，缩短响应时间，就需要重用连接。在HTTP/1.1版本中默认使用持久连接，在此之前的HTTP版本的默认连接都是使用非持久连接，如果想要在旧版本的HTTP协议上维持持久连接，则需要指定connection的首部字段的值为Keep-Alive来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流。用一个示意图来更加生动的表示两者的区别：

对于非Keep-Alive来说，必须为每一个请求的对象建立和维护一个全新的连接。对于每一个这样的连接，客户端和服务器都要分配TCP的缓冲区和变量，这给服务器带来的严重的负担，因为一台Web服务器可能同时服务于数以百计的客户机请求。在Keep-Alive的方式下，服务器在响应后保持该TCP连接打开，在同一个客户机与服务器之间的后续请求和响应报文可通过相同的连接进行传送。甚至位于同一台服务器的多个Web页面从该服务器发送给同一个客户机时，可以在单个持久TCP连接上进行。

然而，Keep-Alive并不是没有缺点的，当长时间的保持TCP连接时容易导致系统资源被无效占用，若对Keep-Alive模式配置不当，将有可能比非Keep-Alive模式带来的损失更大。因此，我们需要正确地设置Keep-Alive的timeout参数，当TCP连接在传送完最后一个HTTP响应，该连接会保持keepalive_timeout秒，之后就开始关闭这个链接。

HTTP/1.1和HTTP/1.0的区别

• 缓存处理：在HTTP/1.0中主要使用header里的if-modified-Since，Expires来做缓存判断的标准。而HTTP/1.1请求头中添加了更多与缓存相关的字段，从而支持更为灵活的缓存策略。例如Entity-tag，if-unmodified-Since，If-None-Match等可供选择的缓存头来控制缓存策略。
• 节约带宽：当客户端请求某个资源时，HTTP/1.0默认将该资源相关的整个对象传送给请求方，但很多时候可能客户端并不需要对象的所有信息。而在HTTP/1.1的请求头中引入了range头域，它允许只请求部分资源，其使得开发者可以多线程请求某一资源，从而充分的利用带宽资源，实现高效并发。
• 错误通知的管理：HTTP/1.1在1.0的基础上新增了24个错误状态响应码，例如414标识客户端请求中所包含的URL的地址太长，以至于服务器无法处理；410表示所请求的资源已经被永久删除。
• Host请求头：早期HTTP/1.0中认为每台服务器都绑定一个唯一的IP地址并提供单一的服务，请求消息中的URL并没有传递主机名。而随着虚拟主机的出现，一套物理服务器上可以存在多个虚拟主机，并且他们共享同一个IP地址。为了支持虚拟主机，HTTP/1.1中添加了host请求头，请求消息和响应消息中应声明这个字段，若请求消息中缺少该字段时，服务端会响应一个404错误状态码。
• 长连接：HTTP/1.0默认浏览器和服务器之间保持短暂连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成后立即断开TCP连接。HTTP/1.1默认使用的是持久连接，其支持在同一个TCP请求中传送多个HTTP请求和响应。此之前的HTTP版本的默认连接都是使用非持久连接，如果想要在旧版本的HTTP协议上维持持久连接，则需要指定connection的首部字段的值为keep-alive。

HTTP/1.X和HTTP/2.0的区别

• 相比于HTTP/1.X的文本（字符串）传送，HTTP/2.0采用二进制传送。客户端和服务器传输数据时把数据分成帧，帧组成了数据流，流具有ID标识和优先级，通过优先级以及流依赖能够一定程度上解决关键请求被阻塞的问题。
• HTTP/2.0支持多路复用。因为流ID的存在，通过同一个HTTP请求可以实现多个HTTP请求传输，客户端和服务器可以通过流ID来标识究竟是哪个流从而定位到哪个HTTP请求。
• HTTP/2.0头部压缩。HTTP/2.0通过gzip和compress压缩头部然后再发送，同时通信双方会维护一张头信息表，在每次HTTP传输时只需要传头字段在表中的索引即可，大大减小了重传次数和数据量。
• HTTP/2.0支持服务器推送。服务器在客户端未经请求许可的情况下，可预先向客户端推送需要的内容，客户端在退出服务时可通过发送复位相关的请求来取消服务端的推送。

HTTP3

HTTP/2存在的问题

我们知道，传统Web平台的数据传输都是基于TCP协议，而TCP协议在创建连接之前不可避免的需要三次握手，如果需要提高数据交互的安全性，即增加传输层安全协议（TLS），还会增加更多的握手次数。HTTP从1.0到2.0，其传输层都是基于TCP协议的。即使是带来巨大性能提升的HTTP/2，也无法完全解决TCP协议存在的故有问题。此外，HTTP/2多路复用只是减少了连接数，其队头的拥塞问题并没有完全解决，倘若TCP丢包率过大，则HTTP/2的表现将不如HTTP/1.1。

QUIC协议

QUIC（Quick UDP Internet Connections），直译为快速UDP网络连接，是谷歌制定的一种基于UDP的低延迟传输协议。其主要目的是解决采用传输层TCP协议存在的问题，同时满足传输层和应用层对多连接，低延迟等需求。该协议融合了TCP，TLS，HTTP/2等协议的特性，并基于UDP传输。该协议带来的主要提升有：

• 低延迟连接。当客户端第一次连接服务器时，QUIC只需要1RTT延迟就可以建立安全可靠的连接，相比于TCP+TLS的3次RTT要更加便捷。之后，客户端可以在本地缓存加密的认证信息，当再次与服务器建立连接时可以实现0 RTT的连接建立延迟。
• QUIC复用了HTTP/2协议的多路复用功能，由于QUIC基于UDP，所以也避免了HTTP/2存在的队头阻塞问题。
• 基于UDP协议的QUIC运行在用户域而不是系统内核，这使得QUIC协议可以快速的更新和部署。
• QUIC的报文是经过加密和认证的，除了少量的报文，其他所有的QUIC报文头部都经过了认证，报文主体经过了加密。只要有攻击者篡改了QUIC报文，接收端都能及时发现。
• 具有向前纠错机制，每个数据包携带了除本身内容外的部分其他数据包的内容，使得在出现少量丢包的情况下，尽量地减少其他包的重传次数，其通过牺牲单个包所携带的有效数据大小换来更少的重传次数，这在丢包数量较少的场景下能够带来一定程度的性能提升。

HTTP/3

HTTP/3是在QUIC基础上发展起来的，其底层使用UDP进行数据传输，上层仍然使用HTTP/2。在UDP与HTTP/2之间存在一个QUIC层，其中TLS加密过程在该层进行处理。HTTP/3主要有以下几个特点：

• 使用UDP作为传输层进行通信；
• 在UDP之上的QUIC协议保证了HTTP/3的安全性。QUIC在建立连接的过程中就完成了TLS的加密握手。
• 建立连接快，正常只需要1 RTT即可建立连接。如果有缓存之前的会话信息，则直接验证和建立连接，此过程0 RTT。建立连接时，也可以带有少量业务数据。
• 不和具体底层连接绑定，QUIC为每个连接的两端分别分配了一个唯一ID，上层连接只认这对逻辑ID。网络切换或者断连时，只需要继续发送数据包即可完成连接的建立。
• 使用QPACK进行头部压缩，因为在HTTP/2中的HPACK要求传输过程有序，这会导致队头阻塞，而QPACK不存在这个问题。

DNS的作用和原理

域名系统DNS（Domain Name System）是互联网使用的命名系统，用来把便于人们使用的机器名字转换成IP地址。

用户与互联网上某台主机通信时，必须要知道对方的IP地址。然而用户很难记住长达32位的二进制主机地址。但在应用层为了便于用户记忆网络应用，连接在互联网上的主机不仅有IP地址，而且还有便于用户记忆的主机名字。

域名系统DNS能够把互联网上的主机名字转换为IP地址。

为什么机器在处理IP数据报时要使用IP地址而不使用域名呢？这是因为IP地址的长度是固定的32位，而域名的长度并不是固定的，机器处理起来比较困难。

从理论上讲，整个互联网可以只使用一个域名服务器，使它装入互联网上的所有主机名，并回答所有对IP地址的查询。然而这种做法并不可取。因为互联网规模很大，这样的域名服务器肯定会因过负荷而无法正常工作，而且一旦域名服务器出现故障，整个互联网就会瘫痪。因此，采用分布式的域名系统DNS。

互联网的域名系统DNS被设计成为一个联机分布式数据库系统，并采用客户服务器方式。DNS使大多数名字都在本地进行解析，仅少量解析需要在互联网上通信，因此DNS系统的效率很高。由于DNS是分布式系统，即使单个计算机出了故障，也不会妨碍整个DNS系统正常的运行。

域名到IP地址的解析是由分布在互联网上的许多域名服务器程序共同完成的。

域名到IP地址的解析过程的要点如下：当某一个应用进程需要把主机名解析为IP地址时，该应用进程就调用解析程序，并成为DNS的一个客户，把待解析的域名放在DNS请求报文中，以UDP用户数据报方式发给本地域名服务器（使用UDP是为了减小开销）。本地域名服务器在查找域名后，把对应的IP地址放在回答报文中返回。应用进程获得目的主机的IP地址后即可进行通信。

若本地域名服务器不能回答该请求，则此域名服务器就暂时成为DNS中的另一个客户，并向其他域名服务器发出查询请求。这种过程直至找到能够回答该请求的域名服务器为止。

域名服务器

根域名服务器

根域名服务器是最高层次的域名服务器，也是最重要的域名服务器。所有的根域名服务器都知道所有的顶级域名服务器的域名和IP地址。根域名服务器是最重要的域名服务器，因为不管是哪一个本地域名服务器，若要对互联网上任何一个域名进行解析（即转换为IP地址），只要自己无法解析，就首先要求助于根域名服务器。假定所有的根域名服务器都瘫痪了，那么整个互联网中的DNS系统就无法工作。

根域名服务器采用了任播技术，因此当DNS客户向某个根域名服务器的IP地址发出查询报文时，互联网上的路由器就能找到里这个DNS客户最近的一个根域名服务器。

需要注意的是，在很多情况下，根域名服务器并不直接把带查询的域名直接转换成IP地址（根域名服务器也没有存放这种信息），而是告诉本地域名服务器下一步应当找哪一个顶级域名服务器进行查询。

顶级域名服务器

顶级域名服务器负责管理在该顶级域名服务器注册的所有二级域名。当收到DNS查询请求时，就给出相应的回答（可能是最后的结果，也可能是下一步应当找的域名服务器的IP地址）。

权限域名服务器

一个服务器所负责管辖的范围叫做区。各单位根据具体情况来划分自己管辖范围的区，在一个区中的所有结点必须是能够联通的。每一个区设置相应的权限域名服务器，用来保存该区中的所有主机的域名到IP地址的映射。总之，DNS服务器的管辖范围不是以“域”为单位，而是以“区”为单位。区是DNS服务器实际管辖的范围。区可能等于或小于域，但一定不能大于域。

当一个权限域名服务器还不能给出最后的查询回答时，就会告诉发出查询请求的DNS客户，下一步应当找哪一个权限域名服务器。

本地域名服务器

当一台主机发出DNS查询请求时，这个查询请求报文就发送给本地域名服务器。每一个互联网服务提供者ISP，或一个大学，甚至一个大学里的系，都可以拥有一个本地域名服务器，这种域名服务器有时也称为默认域名服务器。

本地域名服务器离用户较近，一般不超过几个路由器的距离。当所要查询的主机也属于同一个本地ISP时，该本地域名服务器立即就能将所查询的主机名转换为它的IP地址，而不需要再去询问其他的域名服务器。

为了提高域名服务器的可靠性，DNS域名服务器都把数据复制到几个域名服务器来保存，其中一个是主域名服务器，其他的是辅助域名服务器。当主域名服务器出现故障时，辅助域名服务器可以保证DNS的查询工作不会中断。主域名服务器定期把数据复制到辅助域名服务器中，而更改数据只能在主域名服务器中进行。

域名的解析过程

第一，主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文（即替该主机继续查询），而不是让该主机自己进行下一步的查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者报错，表示无法查询到所需的IP地址。

第二，本地域名服务器向根域名服务器的查询通常是采用迭代查询，迭代查询的特点是这样的：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地域名服务器：“你下一步应该向哪一个域名服务器进行查询”。然后让本地域名服务器进行后续查询（而不是替本地域名服务器进行后续的查询）。根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地域名服务器下一步应该向哪一个权限域名服务器进行查询，本地域名服务器就这样进行迭代查询。最后，知道了索要解析的域名的IP地址，然后把这个结果返回给发起查询的主机。

DNS查询的例子

假定域名为m.xyz.com的主机想知道另一台主机（域名为y.abc.com）的IP地址。例如，主机m.xyz.com打算发送邮件给主机y.abc.com。这时就必须知道主机y.abc.com的IP地址。下面是图6-5(a)的几个查询步骤。

1. 主机m.xyz.com先向其本地域名服务器dns.xyz.com进行递归查询。
2. 本地域名服务器采用迭代查询。它先向一个根域名服务器查询。
3. 根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器dns.com的IP地址。
4. 本地域名服务器向顶级域名服务器dns.com进行查询。
5. 顶级域名服务器dns.com告诉本地域名服务器，下一次应查询的权限域名服务器dns.abc.com的IP地址。
6. 本地域名服务器向权限域名服务器dns.abc.com进行查询。
7. 权限域名服务器dns.abc.com告诉本地域名服务器，所查询的主机的IP地址。
8. 本地域名服务器最后把查询结果告诉主机m.xyz.com。

这8个步骤总共要使用8个UDP用户数据报的报文。

图6-5(b)是本地域名服务器采用递归查询的情况。在这种情况下，本地域名服务器只需向根域名服务器查询一次，后面的几次查询都是在其他几个域名服务器之间进行的。

为了提高DNS查询效率，并减轻根域名服务器的负荷和减少互联网上的DNS查询报文数量，在域名服务器中广泛地使用了高速缓存。高速缓存用来存放最近查询过的域名以及从何处获得域名映射信息的记录。

DNS为什么用UDP

DNS既使用TCP又使用UDP。

当进行区域传送（主域名服务器向辅助域名服务器传送变化的那部分数据）时会使用TCP，因为数据同步传送的数据量比一个请求和应答的数据量要多，而TCP允许的报文长度更长，因此为了保证数据的正确性，会使用基于可靠连接的TCP。

当客户端向DNS服务器查询域名（域名解析）的时候，一般返回的内容不会超过UDP报文的最大长度，即512字节。用UDP传输时，不需要经过TCP三次握手的过程，从而大大提高了响应速度，但这要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。

怎么实现DNS劫持

DNS劫持即域名劫持，是通过将原域名对应的IP地址进行替换从而使得用户访问到错误的网站或者使得用户无法正常访问网站的一种攻击方式。域名劫持往往只能在特定的网络范围内进行，范围外的DNS服务器能够返回正常的IP地址。攻击者可以冒充原域名所属机构，通过电子邮件的方式修改组织结构的域名注册信息，或者将域名转让给其他阻止，并将新的域名信息保存在所指定的DNS服务器中，从而使得用户无法通过对原域名进行解析来访问目的网址。

具体实施步骤如下

1. 获取要劫持的域名信息：攻击者首先会访问域名查询站点查询要劫持的域名信息。
2. 控制域名相应的 E-MAIL 账号：在获取到域名信息后，攻击者通过暴力破解或者专门的方法破解公司注册域名时使用的 E-mail 账号所对应的密码。更高级的攻击者甚至能够直接对 E-mail 进行信息窃取。
3. 修改注册信息：当攻击者破解了 E-MAIL 后，会利用相关的更改功能修改该域名的注册信息，包括域名拥有者信息，DNS 服务器信息等。
4. 使用 E-MAIL 收发确认函：在修改完注册信息后，攻击者在 E-mail 真正拥有者之前收到修改域名注册信息的相关确认信息，并回复确认修改文件，待网络公司恢复已成功修改信件后，攻击者便成功完成 DNS 劫持。

用户端的一些预防手段

• 直接通过IP地址访问网站，避开DNS劫持。
• 由于域名劫持往往只能在特定的网络范围内进行，因此一些高级用户可以通过网络设置让DNS指向正常的域名服务器以实现对目的网址的正常访问，例如将计算机首选DNS服务器的地址固定到8.8.8.8；

HTTPS和HTTP的区别

• HTTP协议以明文方式发送内容，数据都是未加密的，安全性较差；HTTPS数据传输过程是加密的，安全性较好。
• HTTP和HTTPS使用的是完全不同的连接方式，用的端口不同，前者是80端口，后者是443端口。
• HTTPS协议需要向数字认证机构（Certificate Authority，CA）申请证书，一般需要一定的费用。
• HTTP页面响应比HTTPS快，主要因为HTTP使用3次握手建立连接，客户端和服务器需要握手3次，而HTTPS除了TCP的3次握手，还需要经历一个SSL协商过程。

HTTP是不保存状态的协议，如何保存用户状态？

我们知道，假如某个特定的客户机在短时间内两次请求同一个对象，服务器并不会因为刚刚为该用户提供了该对象后就不再作出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前所做过的一样。因为一个HTTP服务器并不保存关于客户机的任何信息，所以我们说HTTP是一个无状态协议。

通常有两种解决方案：

• 基于Session实现的会话保持
  • 在客户端第一次向服务器发送HTTP请求后，服务器会创建一个Session对象并将客户端的身份信息以键值对的形式存储下来，然后分配一个会话标识给客户端，这个会话标识一般保存在客户端Cookie中，之后每次该浏览器发送HTTP请求都会带上Cookie中的SessionID到服务器，服务器根据会话标识就可以将之前的状态信息与会话联系起来，从而实现会话保持。
    • 优点：安全性高，因为状态信息保存在服务器端。
    • 缺点：由于大型网站往往采用的是分布式服务器，浏览器发送的HTTP请求一般要先通过负载均衡器才能到达具体的后台服务器，倘若同一个浏览器两次HTTP请求分别落在不同的服务器上时，基于Session的方法就不能实现会话保持了。
• 基于Cookie实现的会话保持
  • 当服务器发送响应消息时，在HTTP响应头中设置Set-Cookie字段，用来存储客户端的状态信息。客户端解析出HTTP响应头中的字段信息，并根据其生命周期创建不同的Cookie，这样一来每次浏览器发送HTTP请求的时候都会带上Cookie字段，从而实现状态保持。基于Cookie的会话保持与基于Session实现的会话保持，最主要的区别是前者完全将会话状态信息存储在浏览器Cookie中。
    • 优点：服务器不用保存状态信息，减轻服务器存储压力，同时便于服务端做水平拓展。
    • 缺点：该方式不够安全，因为状态信息存储在客户端，这意味着不能在会话中保存机密数据。除此之外，浏览器每次发起HTTP请求时都需要发送额外的Cookie到服务器端，会占用更多带宽。

Cookie被禁用了怎么办？

若遇到Cookie被禁用的情况，则可以通过重写URL的方式将会话标识放在URL的参数里，也可以实现会话保持。

如果你访问一个网站很慢，怎么排查和解决

网页打开速度慢的原因有很多，这里列举出一些较常出现的问题。

1. 首先最直接的方法是查看本地网络是否正常，可以通过网络测速软件例如电脑管家等对电脑进行测速，若网速正常，我们查看网络带宽是否被占用，例如当你正在下载电影时并没有限速，是会影响你打开网页的速度的，这种情况往往是处理器内存小导致的；
2. 当网速测试正常时，我们对网站服务器速度进行排查，通过ping命令查看链接到服务器的时间和丢包等情况，一个速度好的机房，首先丢包率不能超过1%，其次ping值要小，最后是ping值要稳定，如最大和最小差值过大说明路由不稳定。或者我们也可以查看同台服务器上其他网站的打开速度，看是否其他网站打开也慢。
3. 如果网页打开的速度时快时慢，甚至有时候打不开，有可能是空间不稳定的原因。当确定是该问题时，就要找你的空间商解决或换空间商了，如果购买空间的话，可选择购买双线空间或多线空间；如果是在有的地方打开速度快，有的地方打开速度慢，那应该是网络线路的问题。电信线路用户访问放在联通服务器的网站，联通线路用户访问放在电信服务器上的网站，相对来说打开速度肯定是比较慢。
4. 从网站本身找原因。网站的问题主要包括网站程序设计，网页设计结构和网页内容三个部分。
   1. 网站程序设计：当访问网页中有拖慢网站打开速度的代码，会影响网页的打开速度，例如网页中的统计代码，我们最好将其放在网站的末尾。因此我们需要查看网页程序的设计结构是否合理；
   2. 网页设计结构：如果是 table 布局的网站，查看是否嵌套次数太多，或是一个大表格分成多个表格这样的网页布局，此时我们可以采用 div 布局并配合 css 进行优化。
   3. 网页内容：查看网页中是否有许多尺寸大的图片或者尺寸大的 flash 存在，我们可以通过降低图片质量，减小图片尺寸，少用大型 flash 加以解决。此外，有的网页可能过多地引用了其他网站的内容，若某些被引用的网站访问速度慢，或者一些页面已经不存在了，打开的速度也会变慢。一种直接的解决方法是去除不必要的加载项。

URI（统一资源标识符）和URL（统一资源定位符）之间的区别

URL，即统一资源定位符，URL其实就是我们平时上网输入的网址，它标识一个互联网资源，并指定对其进行操作或获取该资源的方法。例如 https://leetcode-cn.com/problemset/all/这个URL，标识一个特定资源并标识该资源的某种形式是可以通过HTTP协议从相应位置获得。

从定义即可看出。URL是URI的一个子集，两者都定义了资源是什么，而URL还定义了如何能访问到该资源，URI是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，是绝对的。简单的来说，只要能唯一标识资源的就是URI，在URI的基础上给出其资源的访问方式就是URL。

socket()套接字有哪些？

套接字（Socket）是对网络中不同主机上的应用进程之间进行双向通信的端点的抽象，网络进程通信的一端就是一个套接字，不同主机上的进程便是通过套接字发送报文来进行通信。例如TCP用主机的IP地址+端口号作为TCP连接的端点，这个端点就叫做套接字。

套接字主要有以下几种类型：

• 流套接字（SOCK_STREAM）：流套接字基于TCP传输协议，主要用于提供面向连接，可靠的数据传输服务，由于TCP协议的特点，使用流套接字进行通信时能够保证数据无差错，无重复传送，并按顺序接收，通信双方不需要在程序中进行相应的处理。
• 数据报套接字（SOCK_DGRAM）：和流套接字不同，数据报套接字基于UDP传输协议，对应于无连接的UDP服务应用。该服务并不能保证数据传输的可靠性，也无法保证对端能够顺序接收到数据。此外，通信两端不需要建立长时间的连接关系，当UDP客户端发送一个数据给服务器后，其可以通过同一个套接字给另一个服务器发送数据。当用UDP套接字时，丢包等问题需要在程序中进行处理。
• 原始套接字（SOCK_RAW）：由于流套接字和数据报套接字只能读取TCP和UDP协议的数据，当需要传送非传输层数据包（例如Ping命令时用的ICMP协议数据包）或者遇到操作系统无法处理的数据包时，此时就需要建立原始套接字来发送。

网页解析全过程

1. DNS解析：当用户输入一个网址并按下回车键的时候，浏览器获得一个域名，而在实际通信过程中，我们需要的是一个IP地址，因此我们需要先把域名转换成相应的IP地址。
2. TCP连接
3. 发送HTTP请求
4. 处理请求并返回
5. 浏览器渲染
6. 断开连接