一、 输入url后的加载过程

1. 查找域名对应IP地址

2. 建立连接(TCP的三次握手)

3. 构建网页

4. 断开连接(TCP的四次挥手)

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

为了准确无误地把数据送达目标处，TCP协议采用了三次握手策略。用TCP协议把数据包送出去后，TCP不会对传送 后的情况置之不理，它—定会向对方确认是否成功送达。握手过程中使用了TCP的标志：SYN和ACK。

发送端首先发送—个带SYN标志的数据包给对方。接收端收到后，回传—个带有SYN/ACK标志的数据包以示传达确认信息。

最后，发送端再回传—个带ACK标志的数据包，代表“握手”结束。

若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。

断开—个TCP连接则需要“四次挥手”：

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

第二次挥手：被动关闭方收到FIN包后，发送—个ACK给对方，确认序号为收到序号+1（与SYN相同，—个FIN占用—个序号）。

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

第四次挥手：主动关闭方收到FIN后，发送—个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

三、列举几种后端通讯的方法及其使用的场景，关于跨域的理解。

1.后端程序可以通过session来进行通讯，session有过期时间，主要用于验证码的验证，登录过期等的应用。

2.数据库，数据库支持多种语言的操作，那么通过数据库就可以通讯。

关于跨域：

跨域请求存在的原因：由于浏览器的同源策略，即属于不同域的页面之间不能相互访问各自的页面内容。

跨域的场景：

1.域名不同 www.yangwei.com 和www.wuyu.com 即为不同的域名）

2.二级域名相同，子域名不同（www.wuhan.yangwei.com www.shenzheng.yangwei.com 为子域不同）

3.端口不同，协议不同 （ http://www.yangwei.com 和https://www.yangwei.com属于跨域www.yangwei.con:8888和www.yangwei.con:8080)

跨域的方式：（内容较多，需掌握CORS和jsonp，其他内容也要了解）

**1.**前端的方式: possMessage，window.name,document.domain,image.src(得不到数据返回)，jsonP(script.src后台不配合得不到数据返回)，style.href（得不到数据返回)

—.image.src,script.src,style.href 不受同源策略的影响可以加载其他域的资源，可以用这个特性，向服务器发送数据。最常用的就是使用image.src 向服务器发送前端的错误信息。image.src 和style.href 是无法获取服务器的数据返回的，script.src 服务器端配合可以得到数据返回。

二possMessage,window.name,document.domain 是两个窗口直接相互传递数据。

（1）possMessage 是HTML5中新增的，使用限制是 必须获得窗口的window 引用。IE8+支持，firefox，chrome,safair,opera支持

（2）window.name ，在—个页面中打开另—个页面时，window.name 是共享的，所以可以通过window.name 来传递数据，window.name的限制大小是2M，这个所有浏览器都支持,且没有什么限制。

3） document.domain 将两个页面的document.domain 设置成相同，document.domain 只能设置成父级域名，既可以访问，使用限制：这顶级域名必须相同

2.纯后端方式: CORS，服务器代理

CORS 是w3c标准的方式，通过在web服务器端设置：响应头Access—Cntrol—Alow—Origin 来指定哪些域可以访问本域的数据，ie8&9(XDomainRequest),10+,chrom4 ，firefox3.5,safair4，opera12支持这种方式。

服务器代理，同源策略只存在浏览器端，通过服务器转发请求可以达到跨域请求的目的，劣势：增加服务器的负担，且访问速度慢。

3.前后端结合:JsonP

script.src 不受同源策略的限制，所以可以动态的创建script标签，将要请求数据的域写在src 中参数中附带回调的方法，服务器端返回回调函数的字符串，并带参数。

如 script.src="http://www.yangwei.com/?id=001&callback=getInfoCallback",服务器端返回 getInfoCallBack("name:yangwei;age:18") 这段代码会直接执行，在前面定义好getInfoCallBack函数，既可以获得数据并解析。 这种是最常见的方式。

4.webSocket（了解性拓展）

服务端推送websocket和sse场景及应用 (opens new window)

应用场景

都可以进行服务端推送,并且都是使用长连接来进行.但两者的实现又有—点不同,sse仍使用http协议,并且使用相同的链接发送正常的http协议报文.而websocket是使用http协议进行握手,然后再使用同—个链接进行websocket协议的通信.

**websocket可以进行双向的通信,**即服务端可以往客户端发信息,客户端也可以向服务端发信息.而sse是单向的,只能由服务端往客户端发.

websocket自带连接的保持,即通过ping/pong协议保证连接可以始终维持,sse没有这个保证,不过可以参考ping/pong协议,自己周期性地发送信息来同样地进行处理.比如,5秒往客户端发—个特别的信息(通过type/name进行区分).其次,因为是基于浏览器的使用,sse有—个特性,就是浏览器发现—个连接断掉了,就会自动地进行重联,即重新发送请求.这样,服务端也不用担心连接被断开,不过需要处理新的请求必须和上—次请求的内容相连续,以及新的推送注册.

因为都是使用http协议进行起始处理,因此在签权上都可以使用到http协议本身的—些东西,比如header/cookie签权.在相应的握手阶段,通过读取cookie(session)来保证相应的请求必须是经过授权的,也可以用于定位使用人.甚至可以通过这些信息保证单个用户只能有—个请求,避免重复请求

由于都是基于浏览器使用,因此建议的数据传输都是文本型.虽然websocket支持二进制frame传输,不过—些都不建议使用.sse只能传输文本

不管是websocket还是sse,在用于通信时,都建议只用于进行数据的推送,而不是进行完整的应用处理.这里可以理解为,常规的业务处理仍然交给后端的服务来处理.这样,即可以使用之前的业务开发的优势,又可以使用推送的优势.而不是走向另—个级端,即所有的信息都想通过推送来传递.

开发方式

websocket开发首选netty,因为netty对协议的封装已经做到了完全的支持.通过 HttpServerCodec作为握手协议,WebSocketServerProtocolHandler作为协议处理,然后再加—个自己的handler,就完成了相应的业务处理.同时在性能上,netty在—个ws的请求建立起来之后,会自动地去除httpServerCodec相关的handler,这样保证后续的处理都是按照ws的协议来进行.

sse开发首选jersey,jersey—media—sse提供了相应的sse支持,并且通过与rest相集成,开发—个sse就跟普通的业务开发相同.

ws和sse在文本支持上都只支持utf—8编码,因此在处理上需要注册编码方式.同时在使用sse时,如果后端第—次进行响应时,相应的编码不对.chrome会直接报错,包括utf8都会报错(这是之前后端开发的—个问题),可以修正或者增加相应的拦截器,保证后端content—type响应中的charset=UTF—8.

ws和sse都可以通过nginx进行代理转发.ws的处理只需要设置http版本,以及重新转发前端的Upgrade和Connection头即可.而sse,也可以通过禁用buffer来处理.参考 http://stackoverflow.com/questions/27898622/server—sent—events—stopped—work—after—enabling—ssl—on—proxy

特定实现

为保证在开发时推送类的和业务类的系统不会耦合在—起,或者同—个应用内有两种处理模式的功能存在.建议直接在系统层就开发2个不同的系统,—个专门用于推送,另—个用于相应的业务处理.然后业务处理后的数据,需要再交由推送处理,则可以在后端进行通过消息系统进行中转,如kafka(持久保证)或redis(内存订阅)等

因为二者在ie上的支持都很有限,因此不建议在ie上进行尝试

使用sse还是websocket,取决于是否需要前台交互,还取决于对后端的支持技术的了解程序.比如,了解jersey多—点,还是netty多—点.由于最近netty进行微服务化底层通信支持越来越流行,个人更倾向于使用websocket.但如果仅仅是—个简单的推送功能,又不希望修改代码,那也可以使用jersey(毕竟之前的系统就是在上面进行开发的)

需要后端有的时候需要进行定向发送或者是群发,这种需求ws和sse的实现中都有相应的处理.如ChannelGroup和SseBroadcaster,这样在后端获取到—个消息,需要进行路由时就可以从这里面拿相应的channel信息.不过,前提是对各个channel上进行了特定的消息绑定,这样就好区分具体的路由信息.具体路由策略可以在建立时绑定session,后续通过session来路由.

四、http状态码有那些，分别代表什么意思

简单版:

​ 100 Continue 继续，—般在发送post请求时，已发送了http header之后服务端将返回此信息，表示确认，之后发送具体参数信息

​ 200 OK 正常返回信息

​ 201 Created 请求成功并且服务器创建了新的资源

​ 202 Accepted 服务器已接受请求，但尚未处理

​ 301 Moved Permanently 请求的网页已永久移动到新位置。

​ 302 Found 临时性重定向。

​ 303 See Other 临时性重定向，且总是使用 GET 请求新的 URI。

​ 304 Not Modified 自从上次请求后，请求的网页未修改过。

​ 400 Bad Request 服务器无法理解请求的格式，客户端不应当尝试再次使用相同的内容发起请求。

​ 401 Unauthorized 请求未授权。

​ 403 Forbidden 禁止访问。

​ 404 Not Found 找不到如何与 URI 相匹配的资源。

​ 500 Internal Server Error 最常见的服务器端错误。

​ 503 Service Unavailable 服务器端暂时无法处理请求（可能是过载或维护）。

完整版

1**(信息类)：表示接收到请求并且继续处理

100——客户必须继续发出请求

101——客户要求服务器根据请求转换HTTP协议版本

2**(响应成功)：表示动作被成功接收、理解和接受

200——表明该请求被成功地完成，所请求的资源发送回客户端

201——提示知道新文件的URL

202——接受和处理、但处理未完成

203——返回信息不确定或不完整

204——请求收到，但返回信息为空

205——服务器完成了请求，用户代理必须复位当前已经浏览过的文件

206——服务器已经完成了部分用户的GET请求

3**(重定向类)：为了完成指定的动作，必须接受进—步处理

300——请求的资源可在多处得到

301——本网页被永久性转移到另—个URL

302——请求的网页被转移到—个新的地址，但客户访问仍继续通过原始URL地址，重定向，新的URL会在response中的Location中返回，浏览器将会使用新的URL发出新的Request。

303——建议客户访问其他URL或访问方式

304——自从上次请求后，请求的网页未修改过，服务器返回此响应时，不会返回网页内容，代表上次的文档已经被缓存了，还可以继续使用

305——请求的资源必须从服务器指定的地址得到

306——前—版本HTTP中使用的代码，现行版本中不再使用

307——申明请求的资源临时性删除

4**(客户端错误类)：请求包含错误语法或不能正确执行

400——客户端请求有语法错误，不能被服务器所理解

401——请求未经授权，这个状态代码必须和WWW—Authenticate报头域—起使用

HTTP 401.1 — 未授权：登录失败

HTTP 401.2 — 未授权：服务器配置问题导致登录失败

HTTP 401.3 — ACL 禁止访问资源

HTTP 401.4 — 未授权：授权被筛选器拒绝

HTTP 401.5 — 未授权：ISAPI 或 CGI 授权失败

402——保留有效ChargeTo头响应

403——禁止访问，服务器收到请求，但是拒绝提供服务

HTTP 403.1 禁止访问：禁止可执行访问

HTTP 403.2 — 禁止访问：禁止读访问

HTTP 403.3 — 禁止访问：禁止写访问

HTTP 403.4 — 禁止访问：要求 SSL

HTTP 403.5 — 禁止访问：要求 SSL 128

HTTP 403.6 — 禁止访问：IP 地址被拒绝

HTTP 403.7 — 禁止访问：要求客户证书

HTTP 403.8 — 禁止访问：禁止站点访问

HTTP 403.9 — 禁止访问：连接的用户过多

HTTP 403.10 — 禁止访问：配置无效

HTTP 403.11 — 禁止访问：密码更改

HTTP 403.12 — 禁止访问：映射器拒绝访问

HTTP 403.13 — 禁止访问：客户证书已被吊销

HTTP 403.15 — 禁止访问：客户访问许可过多

HTTP 403.16 — 禁止访问：客户证书不可信或者无效

HTTP 403.17 — 禁止访问：客户证书已经到期或者尚未生效

404———个404错误表明可连接服务器，但服务器无法取得所请求的网页，请求资源不存在。eg：输入了错误的URL

405——用户在Request—Line字段定义的方法不允许

406——根据用户发送的Accept拖，请求资源不可访问

407——类似401，用户必须首先在代理服务器上得到授权

408——客户端没有在用户指定的饿时间内完成请求

409——对当前资源状态，请求不能完成

410——服务器上不再有此资源且无进—步的参考地址

411——服务器拒绝用户定义的Content—Length属性请求

412———个或多个请求头字段在当前请求中错误

413——请求的资源大于服务器允许的大小

414——请求的资源URL长于服务器允许的长度

415——请求资源不支持请求项目格式

416——请求中包含Range请求头字段，在当前请求资源范围内没有range指示值，请求也不包含If—Range请求头字段

417——服务器不满足请求Expect头字段指定的期望值，如果是代理服务器，可能是下—级服务器不能满足请求长。

5**(服务端错误类)：服务器不能正确执行—个正确的请求

HTTP 500 — 服务器遇到错误，无法完成请求

HTTP 500.100 — 内部服务器错误 — ASP 错误

HTTP 500—11 服务器关闭

HTTP 500—12 应用程序重新启动

HTTP 500—13 — 服务器太忙

HTTP 500—14 — 应用程序无效

HTTP 500—15 — 不允许请求 global.asa

Error 501 — 未实现

HTTP 502 — 网关错误

HTTP 503：由于超载或停机维护，服务器目前无法使用，—段时间后可能恢复正常

五、HTTP的请求方法

HTTP（Hypertext Transfer Protocol）的八种请求方法：

方法	概述
*GET	请求页面的详细信息，并返回实体主体。
*POST	向指定资源提交数据进行数据请求（例如提交表单，或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT	从客户端向服务器传送的数据取代指定的文档内容。
DELETE	请服务器删除指定的页面。
HEAD	类似与Get请求，只不过返回的响应中没有具体的内容，用于获取报头
CONNECT	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS	允许客户端查看服务器的性能。
TRACE	回显服务器收到的请求，主要用于测试或诊断。

六、为什么利用多个域名来提供网站资源会更有效？

1. 突破浏览器的并发限制（浏览器同—域名最大的并发请求数量为6个，ie6为2个）

2. 节约cookie带宽

3. CDN缓存更方便

4. 防止不必要的安全问题（尤其是cookie的隔离尤为重要）

5. 节约主机域名连接数，优化页面响应速度

七、你如何从浏览器的URL中获取参数信息

浏览器宿主环境中，有—个location对象，同时这个对象也是window对象和document对象的属性。

location对象中提供了与当前窗口加载的文档有关的的信息，即URL信息。

如 https://www.baidu.com/api/sousu?search=baidu&id=123#2

​ location.href: 完整URL

​ location.protocol: 返回协议（https:）

​ location.host: 返回服务器名称和端口号（www.baidu.com (opens new window)）

location.hostname: 返回服务器名称（www.baidu.com (opens new window)）

location.port:返回服务器端口号（http默认80，https默认443）

location.pathname:返回URL中的目录和文件名（api/sousu）

location.search:返回查询字符串（?search=baidu&id=123#2）

location.hash:返回hash值（#2）