HTTP面试相关问题整理

前言

补充-前端安全（XSS，CSRF）

浏览器前端优化

浏览器前端优化,推荐，从页面渲染来看优化。（这里有页面渲染过程）
看看 前端总结–性能优化

• 减少 HTTP 请求
• 减少 DOM 操作
• 避免不必要的重绘与重排
• 优化 CSS 选择器（从右向左匹配）
• CSS/JS minify，减少文件体积
• 开启 Gzip 压缩
• 将 CSS 放到顶部，JavaScript 放到尾部
• 压缩图片以及使用 CSS Sprite
• 使用 CDN 加速，适当进行文件缓存
• 合理控制 cookie 大小（每次请求都会包含 cookie）

http状态码有那些？

1XX：通知
表示临时响应并需要请求者继续执行操作的状态代码。

100 （继续） 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
101 （切换协议） 请求者已要求服务器切换协议，服务器已确认并准备切换。
2XX: 成功
表示请求成功

200 成功处理了请求，一般情况下都是返回此状态码；
201 请求成功并且服务器创建了新的资源。
202 服务器已接受请求，但尚未处理

客户端的请求无法或将不被实时处理。请求稍后会被处理。请求看上去是合法的，但在实际处理它时有出现问题的可能。
若一个请求触发了一个异步操作，或者一个需要现实世界参与的动作，或者一个需要很长时间才能完成且没必要让Web客户端一直等待的动作时，这个相应代码是一个合适的选择。

203 返回另一资源的请求；
204 服务器成功处理了请求，但没有返回任何内容；
205 服务器成功处理了请求，但没有返回任何内容；
206 处理部分请求；
3XX 重定向

3XX系列响应代码表明：客户端需要做些额外工作才能得到所需要的资源。它们通常用于GET请求。他们通常告诉客户端需要向另一个URI发送GET请求，才能得到所需的表示。那个URI就包含在Location响应报头里。

300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 （永久移动-永久重定向） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。

301比较常用的场景是使用域名跳转。
比如，我们访问http://www.baidu.com会跳转到 https://www.baidu.com，发送请求之后，就会返回301状态码，然后返回一个location，提示新的地址，浏览器就会拿着这个新的地址去访问。
注意： 301请求是可以缓存的， 即通过看status code，可以发现后面写着from cache。
或者你把你的网页的名称从php修改为了html，这个过程中，也会发生永久重定向

302 （临时移动-临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

用来做临时跳转
比如未登陆的用户访问用户中心重定向到登录页面。
访问404页面会重新定向到首页。

301重定向和302重定向的区别
　　 302重定向只是暂时的重定向，搜索引擎会抓取新的内容而保留旧的地址，因为服务器返回302，所以，搜索搜索引擎认为新的网址是暂时的。
而301重定向是永久的重定向，搜索引擎在抓取新的内容的同时也将旧的网址替换为了重定向之后的网址。

303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

4XX：客户端错误
400 服务器不理解请求的语法。
401 请求未授权(请求要求身份验证)。 （没有登录或者登录失效）对于需要登录的网页，服务器可能返回此响应。
403 （登陆了，但没权限）禁止访问,服务器拒绝请求。
404 服务器找不到请求的网页。
405 禁用请求中指定的方法。
406 无法使用请求的内容特性响应请求的网页。
407 此状态代码与 401类似，但指定请求者应当授权使用代理。
408 服务器等候请求时发生超时。
409 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410 如果请求的资源已永久删除，服务器就会返回此响应。
411 服务器不接受不含有效内容长度标头字段的请求。
412 服务器未满足请求者在请求中设置的其中一个前提条件。
413 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 请求的 URI（通常为网址）过长，服务器无法处理。
415 请求的格式不受请求页面的支持。
416 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 服务器未满足”期望”请求标头字段的要求。

401 Unauthorized（没有登录或者登录失效）： 该HTTP状态码表示认证错误，它是为了认证设计的，而不是为了授权设计的。收到401响应，表示请求没有被认证—压根没有认证或者认证不正确—但是请重新认证和重试。（一般在响应头部包含一个WWW-Authenticate来描述如何认证）。通常由web服务器返回，而不是web应用。从性质上来说是临时的东西。（服务器要求客户端重试）
…
403 Forbidden（登陆了，但没权限）：该HTTP状态码是关于授权方面的。从性质上来说是永久的东西，和应用的业务逻辑相关联。它比401更具体，更实际。收到403响应表示服务器完成认证过程，但是客户端请求没有权限去访问要求的资源。
…
总的来说，401 Unauthorized响应应该用来表示缺失或错误的认证；403 Forbidden响应应该在这之后用，当用户被认证后，但用户没有被授权在特定资源上执行操作。
链接：https://www.jianshu.com/p/6dceeebbde5b

5XX 服务端错误
500 （服务器内部错误） 服务器遇到错误，无法完成请求。
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

参考:

原文 https://blog.csdn.net/xianjie0318/article/details/76541407
补充 https://www.cnblogs.com/xflonga/p/9368993.html
补充 https://www.cnblogs.com/zhuzhenwei918/p/7582620.html
19/12/31补充 401和403
https://www.jianshu.com/p/6dceeebbde5b
补充 403 Forbidden vs 401未经授权的HTTP响应？

RESTful

REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

• GET
  get方法在Rest中主要用于获取资源，能够发送参数，不过有限制，且参数都会以?开头的形 式附加在URL尾部。 规范的get方法处理器应该是幂等的，也就是说对一个资源不论发送多少次get请求都不会更改数据或造成破坏。
• POST
  post方法在Rest请求中主要用于添加资源，参数信息存放在请求报文的消息体中相对安全，且可发送较大信息
• PUT
  put方法在Rest中主要用于更新资源，因为大多数浏览器不支持put和delete，会自动将put和delete请求转化为get和post. 因此为了使用put和delete方法, 需要以post发送请求，在表单中使用隐藏域发送真正的请求。 put方法的参数是同post一样是存放在消息中的，同样具有安全性，可发送较大信息。 put方法是幂等的，对同一URL资源做出的同一数据的任意次put请求其对数据的改变都是一致的。
• DELETE
  Delete在Rest请求中主要用于删除资源，因为大多数浏览器不支持put和delete，会自动将put和delete请求转化为get和post。 因此为了使用put和delete方法,需要以post发送请求，在表单中使用隐藏域发送真正的请求。 Delete方法的参数同post一样存放在消息体中,具有安全性，可发送较大信息 Delete方法是幂等的，不论对同一个资源进行多少次delete请求都不会破坏数据

HTTP是什么？

概况

HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口。它使用 TCP 作为传 输层协议，保证了数据传输的可靠性。

HTTP 是一个无状态的协议，HTTP 服务器不会保存关于客户的任何信息。

HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。

HTTP 有两种连接模式，一种是持续连接，一种非持续连接。非持续连接指的是服务器必须为每一个请求的对象建立和维护 一个全新的连接。持续连接下，TCP 连接默认不关闭，可以被多个请求复用。采用持续连接的好处是可以避免每次建立 TCP 连接三次握手时所花费的时间。在 HTTP1.0 以前使用的非持续的连接，但是可以在请求时，加上 Connection: keep-a live 来要求服务器不要关闭 TCP 连接。HTTP1.1 以后默认采用的是持续的连接。目前对于同一个域，大多数浏览器支持 同时建立 6 个持久连接。

HTTP 请求报文
HTTP 请求报文的格式如下：

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

HTTP 请求报文的第一行叫做请求行，后面的行叫做首部行，首部行后还可以跟一个实体主体。请求首部之后有一个空行，这 个空行不能省略，它用来划分首部与实体。（请求行、请求头、请求体）

请求行包含三个字段：方法字段、URL 字段和 HTTP 版本字段。

HTTP和HTTPS

• HTTP协议通常承载于TCP协议之上，在HTTP和TCP之间添加一个安全协议层（SSL或TSL），这个时候，就成了我们常说的HTTPS

• 默认HTTP的端口号为80，HTTPS的端口号为443

为什么HTTPS安全

因为网络请求需要中间有很多的服务器路由器的转发。中间的节点都可能篡改信息，而如果使用HTTPS，密钥在你和终点站才有。https之所以比http安全，是因为他利用ssl/tls安全协议传输。它包含证书，卸载，流量转发，负载均衡，页面适配，浏览器适配，refer传递等。保障了传输过程的安全性。

关于HTTP/2 你知道多少？

• HTTP/2引入了“服务端推（server push）”的概念，允许服务器主动推送应答到客户端的缓存中，从而提高性能。（它允许服务端在客户端需要数据之前就主动地将数据发送到客户端缓存中）。
• HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行。
• HTTP/2使用报头压缩，降低了开销。
• 二进制协议代替文本协议，更加简洁高效

浅析HTTP/2的多路复用
HTTP/2 多路复用技术分享

HTTP1.1还是存在效率问题
如上面所说，在HTTP1.1中是默认开启了Keep-Alive，他解决了多次连接的问题，但是依然有两个效率上的问题：

• 第一个：串行的文件传输。当请求a文件时，b文件只能等待，等待a连接到服务器、服务器处理文件、服务器返回文件，这三个步骤。我们假设这三步用时都是1秒，那么a文件用时为3秒，b文件传输完成用时为6秒，依此类推。（注：此项计算有一个前提条件，就是浏览器和服务器是单通道传输）
• 第二个：连接数过多。我们假设Apache设置了最大并发数为300，因为浏览器限制，浏览器发起的最大请求数为6，也就是服务器能承载的最高并发为50，当第51个人访问时，就需要等待前面某个请求处理完成。

HTTP/2的多路复用就是为了解决上述的两个性能问题

以前我们做的性能优化不适用于HTTP/2了

• CSS精灵图，加载速度优势在http2开启后荡然无存，HTTP2多路复用，多张图片也可以重复利用一个连接通道搞定。
• JS文件的合并。我们现在优化的一个主要方向就是尽量的减少HTTP的请求数， 对我们工程中的代码，研发时分模块开发，上线时我们会把所有的代码进行压缩合并，合并成一个文件，这样不管多少模块，都请求一个文件，减少了HTTP的请求数。但是这样做有一个非常严重的问题：文件的缓存。当我们有100个模块时，有一个模块改了东西，按照之前的方式，整个文件浏览器都需要重新下载，不能被缓存。现在我们有了HTTP/2了，模块就可以单独的压缩上线，而不影响其他没有修改的模块。
• 多域名提高浏览器的下载速度。之前我们有一个优化就是把css文件和js文件放到2个域名下面，这样浏览器就可以对这两个类型的文件进行同时下载，避免了浏览器6个通道的限制，这样做的缺点也是明显的，1.DNS的解析时间会变长。2.增加了服务器的压力。有了HTTP/2之后，根据上面讲的原理，我们就不用这么搞了，成本会更低。

GET和POST两种基本请求方法的区别?

HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。

1. GET产生一个TCP数据包；POST产生两个TCP数据包(验证数据包完整性)。
2. GET参数通过URL传递，POST放在Request body中。
3. GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
4. GET请求在URL中传送的参数是有长度限制的，而POST么有。
5. GET请求会被浏览器主动缓存，而POST不会，除非手动设置。
6. GET请求只能进行url编码，而POST支持多种编码方式。
7. 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
8. GET在浏览器回退时是无害的，而POST会再次提交请求。
9. GET产生的URL地址可以被Bookmark，而POST不可以。
10. GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
    （本标准答案参考自w3schools）

下面这段来源于：GET和POST两种基本请求方法的区别

在我大万维网世界中，TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。

但是，我们只看到HTTP对GET和POST参数的传送渠道（url还是requrest body）提出了要求。“标准答案”里关于参数大小的限制又是从哪来的呢？

在我大万维网世界中，还有另一个重要的角色：运输公司。不同的浏览器（发起http请求）和服务器（接受http请求）就是不同的运输公司。 虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦。

好了，现在你知道，GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

GET和POST还有一个重大区别，

简单的说：
GET产生一个TCP数据包；POST产生两个TCP数据包。
长的说：
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。
因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？

总结：

1. GET与POST都有自己的语义，不能随便混用。

2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

即时通讯的实现，短轮询、长轮询、SSE长连接 和 WebSocket 间的区别？

短轮询和长轮询的目的都是用于实现客户端和服务器端的一个即时通讯。

短轮询的基本思路就是浏览器每隔一段时间向浏览器发送 http 请求，服务器端在收到请求后，不论是否有数据更新，都直接进行响应。这种方式实现的即时通信，本质上还是浏览器发送请求，服务器接受请求的一个过程，通过让客户端不断的进行请求，使得客户端能够模拟实时地收到服务器端的数据的变化。这种方式的优点是比较简单，易于理解。缺点是这种方式由于需要不断的建立 http 连接，严重浪费了服务器端和客户端的资源。当用户增加时，服务器端的压力就会变大，这是很不合理的。

长轮询的基本思路是，首先由客户端向服务器发起请求，当服务器收到客户端发来的请求后，服务器端不会直接进行响应，而是先将这个请求挂起，然后判断服务器端数据是否有更新。如果有更新，则进行响应，如果一直没有数据，则到达一定的时间限制才返回。客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。长轮询和短轮询比起来，它的优点是明显减少了很多不必要的 http 请求次数，相比之下节约了资源。长轮询的缺点在于，连接挂起也会导致资源的浪费。

SSE（长连接） 的基本思想是，服务器使用流信息向服务器推送信息。严格地说，http 协议无法做到服务器主动推送信息。但是，有一种变通方法，就是服务器向客户端声明，接下来要发送的是流信息。也就是说，发送的不是一次性的数据包，而是一个数据流，会连续不断地发送过来。这时，客户端不会关闭连接，会一直等着服务器发过来的新的数据流，视频播放就是这样的例子。SSE 就是利用这种机制，使用流信息向浏览器推送信息。它基于 http 协议，目前除了 IE/Edge，其他浏览器都支持。它相对于前面两种方式来说，不需要建立过多的 http 请求，相比之下节约了资源。
(SSE 是单向通道，只能服务器向客户端发送消息，如果客户端需要向服务器发送消息，则需要一个新的 HTTP 请求。 这对比 WebSocket 的双工通道来说，会有更大的开销。)

上面三种方式本质上都是基于 http 协议的，
我们还可以使用 WebSocket 协议来实现。WebSocket 是 Html5 定义的一个新协议，与传统的 http 协议不同，该协议允许由服务器主动的向客户端推送信息。使用 WebSocket 协议的缺点是在服务器端的配置比较复杂。WebSocket 是一个全双工的协议，也就是通信双方是平等的，可以相互发送消息，而 SSE 的方式是单向通信的，只能由服务器端向客户端推送信息，如果客户端需要发送信息就是属于下一个 http 请求了。

Web端即时通讯技术简析:轮询、长轮询、长连接、websocket

一个页面从输入URL到页面加载显示完成，这个过程都发生什么？

从浏览器输入一个 url 到页面渲染，涉及的知识点及优化点

（1）浏览器url 解析，是否符合url格式，中文会encode等。
（2）在发送http请求前，需要域名解析(DNS解析)，解析获取相应的IP地址。
（3）浏览器向服务器发起tcp连接，与浏览器建立tcp三次握手。
（4）握手成功后，浏览器向服务器发送http请求，请求数据包。
（5）服务器处理收到的请求，将数据返回至浏览器
（6）浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程。
（7）（生成Dom树、解析css样式、js交互）浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，如果遇到 script 标签，则判端是否含有 defer 或者 async 属性，要不然 script 的加载和执行会造成页面的渲染的阻塞。当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页面进行绘制。这个时候整个页面就显示出来了。
（8）最后一步是 TCP 断开连接的四次挥手过程。

其中，步骤2的具体过程是：

• 浏览器缓存：浏览器会记录DNS一段时间，因此，只是第一个地方解析DNS请求；
• 操作系统缓存：如果在浏览器缓存中不包含这个记录，则会使系统调用操作系统，获取操作系统的记录(保存最近的DNS查询缓存)；
• 路由器缓存：如果上述两个步骤均不能成功获取DNS记录，继续搜索路由器缓存；
• ISP（运营商）缓存：若上述均失败，继续向ISP搜索。
• 域名服务器：到此处的过程为：根域服务器（.） -> 顶级域名服务器（eg: .com，.org）->主域名服务器（eg: google.com）

1、HTML的加载

　　HTML是一个网页的基础，下载完成后解析

2、其他静态资源加载

　　解析HTML时，发现其中有其他外部资源链接比如CSS、JS、图片等，会立即启用别的线程下载。

　　但当外部资源是JS时，HTML的解析会停下来，等JS下载完执行结束后才继续解析HTML，防止JS修改已经完成的解析结果

3、DOM树构建

　　在HTML解析的同时，解析器会把解析完成的结果转换成DOM对象，再进一步构建DOM树

4、CSSOM树构建

　　CSS下载完之后对CSS进行解析，解析成CSS对象，然后把CSS对象组装起来，构建CSSOM树

5、渲染树构建

　　当DOM树和CSSOM树都构建完之后，浏览器根据这两个树构建一棵渲染树

6、布局计算

　　渲染树构建完成以后，浏览器计算所有元素大小和绝对位置

7、渲染

　　布局计算完成后，浏览器在页面渲染元素。经过渲染引擎处理后，整个页面就显示出来

https://blog.csdn.net/jean_0920/article/details/100084233

https://www.cnblogs.com/WaTa/p/5477374.html

当你在浏览器中输入 Google.com 并且按下回车之后发生了什么？

（1）首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径。如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查 URL 中是否出现了非法字符，如果存在非法字符，则对非法字符进行转义后再进行下一过程。

（2）浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里并且没有失效，那么就直接使用，否则向服务器发起新的请求。

（3）下一步我们首先需要获取的是输入的 URL 中的域名的 IP 地址，首先会判断本地是否有该域名的 IP 地址的缓存，如果有则使用，如果没有则向本地 DNS 服务器发起请求。本地 DNS 服务器也会先检查是否存在缓存，如果没有就会先向根域名服务器发起请求，获得负责的顶级域名服务器的地址后，再向顶级域名服务器请求，然后获得负责的权威域名服务器的地址后，再向权威域名服务器发起请求，最终获得域名的 IP 地址后，本地 DNS 服务器再将这个 IP 地址返回给请求的用户。用户向本地 DNS 服务器发起请求属于递归请求，本地 DNS 服务器向各级域名服务器发起请求属于迭代请求。

（4）当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，我们本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理，通过将 IP 地址与我们本机的子网掩码相与，我们可以判断我们是否与请求主机在同一个子网里，如果在同一个子网里，我们可以使用 APR 协议获取到目的主机的 MAC 地址，如果我们不在一个子网里，那么我们的请求应该转发给我们的网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关的地址。

（5）下面是 TCP 建立连接的三次握手的过程，首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号，服务端接收到请求后向服务器端发送一个 SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个 ACK 确认报文段，服务器端接收到确认后，也进入连接建立
状态，此时双方的连接就建立起来了。

（6）如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程。首先由客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后
发送给服务器端，并且还会提供一个前面所有内容的 hash 值供服务器端检验。服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash 值供客户端检验。这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成一把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输。

（7）当页面请求发送到服务器端后，服务器端会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程。
（8）浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，如果遇到 script 标签，则判端是否含有 defer 或者 async 属性，要不然 script 的加载和执行会造成页面的渲染的阻塞。当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页面进行绘制。这个时候整个页面就显示出来了。页面渲染机制（一、DOM和CSSOM树的构建）

（9）最后一步是 TCP 断开连接的四次挥手过程。

详细资料可以参考： 《当你在浏览器中输入 Google.com 并且按下回车之后发生了什么？》已失效

说说TCP传输的三次握手四次挥手策略

TCP三次握手和四次挥手
浏览器根据 IP 地址向服务器发起 TCP 连接，与浏览器建立 TCP 三次握手：

为了准确无误地把数据送达目标处，TCP协议采用了三次握手策略。用TCP协议把数据包送出去后，TCP不会对传送 后的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了TCP的标志：SYN（Synchronize Sequence Numbers）同步序列编号和ACK (Acknowledge character）确认字符

过程

• 发送端首先发送一个带SYN标志的数据包给对方（客户端：我要连接你了，可以吗）
• 接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息（服务器：嗯，我准备好了，连接我吧）
• 最后，发送端再回传一个带ACK标志的数据包，代表“握手”结束（客户端：好，那我连接你咯。）
• 若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包

详细过程

• 第一次握手：主机A发送位码为syn＝1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；

• 第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包

• 第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。

1.客户端向服务器发送一个建立连接的请求（客户端：我要连接你了，可以吗）；
2.服务器接到请求后发送同意连接的信号（服务器：嗯，我准备好了，连接我吧）；
3.客户端接到同意连接的信号后，再次向服务器发送了确认信号（客户端：那我连接你咯。），自此，客户端与服务器两者建立了连接。

断开一个TCP连接则需要“四次握手”：

为什么服务器在接到断开请求时不立即同意断开?

当服务器收到断开连接的请求时，可能仍然有数据未发送完毕，所以服务器先发送确认信号，等所有数据发送完毕后再同意断开。

过程：
1.客户端向服务器发送一个断开连接的请求（不早了，我该走了）；
2.服务器接到请求后发送确认收到请求的信号（知道了）；
3.服务器向客户端发送断开通知（我也该走了）；
4.客户端接到断开通知后断开连接并反馈一个确认信号（嗯，好的），服务器收到确认信号后断开连接；

过程

• 第一次挥手：主动关闭方(客户端)发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。（不早了，我该走了）

• 第二次挥手：被动关闭方(服务器)收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）（知道了）

• 第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了（我也该走了）

• 第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手（嗯，好的）

为什么可能仍然有数据未发送完毕

这种情况主要是由于 TCP 全双工传输的特性决定的。什么是全双工？先说一下半双工吧，举个栗子，有一条很窄的道路，只有单通道，但是却两个方向的车都可以走。当有一个方向的车进入，另一个方向的车就只能等待它通过才能进入。而全双工就是互不影响，你走你的，我走我的。所以 TCP 的数据传输也是这样，两端同时可以向对方发送数据，所以当 A 要断开连接的时候，B 接收到 FIN 表示没有数据会发来了，但是我还可以继续发送数据，可能还有数据要发，为了数据不丢失，即采用先确定后断开的方式。

说说网络分层里七层模型是哪七层

• 应用层：应用层、表示层、会话层（从上往下）（HTTP、FTP、SMTP、DNS）

• 传输层（TCP和UDP）

• 网络层（IP）

• 物理和数据链路层（以太网）

每一层的作用如下：

• 物理层：通过媒介传输比特,确定机械及电气规范（比特Bit）
• 数据链路层：将比特组装成帧和点到点的传递（帧Frame）
• 网络层：负责数据包从源到宿的传递和网际互连（包PackeT）
• 传输层：提供端到端的可靠报文传递和错误恢复（段Segment）
• 会话层：建立、管理和终止会话（会话协议数据单元SPDU）
• 表示层：对数据进行翻译、加密和压缩（表示协议数据单元PPDU）
• 应用层：允许访问OSI环境的手段（应用协议数据单元APDU）

TCP和UDP的区别

• TCP（Transmission Control Protocol，传输控制协议）是基于连接的协议，提供可靠的连接服务。也就是说，在正式收发数据前，必须和对方建立可靠的连接。一个TCP连接必须要经过三次“对话”才能建立起来。

• UDP（User Data Protocol，用户数据报协议）是与TCP相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去！ UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。

XSS(Cross Site Scripting)-跨站脚本攻击

XSS是什么
人们经常将跨站脚本攻击（Cross Site Scripting）缩写为CSS，但这会与层叠样式表（Cascading Style Sheets，CSS）的缩写混淆。因此，有人将跨站脚本攻击缩写为XSS。

跨站脚本攻击（XSS），是最普遍的Web应用安全漏洞。这类漏洞能够使得攻击者嵌入恶意脚本代码到正常用户会访问到的页面中，当正常用户访问该页面时，则可导致嵌入的恶意脚本代码的执行，从而达到恶意攻击用户的目的，如盗用cookie等。

特点
能注入恶意的HTML/JavaScript代码到用户浏览的网页上，从而达到Cookie资料窃取、会话劫持、钓鱼欺骗等攻击。 <攻击代码不一定（非要）在<script></script>中>

原因

• Web浏览器本身的设计不安全。浏览器能解析和执行JS等代码，但是不会判断该数据和程序代码是否恶意。
• 输入和输出是Web应用程序最基本的交互，而且网站的交互功能越来越丰富。如果在这过程中没有做好安全防护，很容易会出现XSS漏洞。
• 程序员水平参差不齐，而且大都没有过正规的安全培训，没有相关的安全意识。
• XSS攻击手段灵活多变。

危害

• 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
• 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
• 盗窃企业重要的具有商业价值的资料
• 强制发送电子邮件
• 网站挂马
• 控制受害者机器向其它网站发起攻击

如何防范

• 将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了.
• 表单数据规定值的类型，例如：年龄应为只能为int、name只能为字母数字组合。。。。
• 对数据进行Html Encode 处理
• 过滤或移除特殊的Html标签， 例如: <script>, <iframe> , < for <, > for >, &quot for
• 过滤JavaScript 事件的标签。例如 “οnclick=”, “onfocus” 等等。

参考资料：
https://www.cnblogs.com/phpstudy2015-6/p/6767032.html

https://www.cnblogs.com/443855539-wind/p/6055816.html

https://baike.baidu.com/item/XSS%E6%94%BB%E5%87%BB/954065?fr=aladdin

CSRF（Cross-site request forgery）跨站请求伪造

CSRF是什么
CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

特点

• 依靠用户标识危害网站
• 利用网站对用户标识的信任
• 欺骗用户的浏览器发送HTTP请求给目标站点
• 另外可以通过IMG标签会触发一个GET请求，可以利用它来实现CSRF攻击。

防御

• 通过referer、token或者验证码来检测用户提交。
• 尽量不要在页面的链接中暴露用户隐私信息。
• 对于用户修改删除等操作最好都使用post操作 。
• 避免全站通用的cookie，严格设置cookie的域。

参考

GET和POST两种基本请求方法的区别
Front-end-basic-knowledge
Front-End-Interview-Notebook
FE-Interview-Questions