1.HTTP协议
HTTP(超文本传输协议)是属于应用层的协议。它是一个基于请求和相应模式的无状态的应用层的协议,常基于TCP的连接方式。HTTP1.1版本中给出一种持续连接的机制。绝大多数的web开发都是构建在HTTP协议上的web应用。
HTTP协议的主要特点:
- 支持客户/服务器模式。HTTP协议工作于客户端/服务器架构之上。浏览器作为http客户端通过url向http服务端即web服务器发送server请求。web服务器根据接收到的请求,向客户端发送相应信息。
- 简单快速。客户端向服务器请求服务的时候,只需传送请求方法和路径。请求方法常用的有get/head/post。每种方法规定了客户与服务器连系的类型不同。由于HTTP协议简单,使得http服务的程序规模小,因而通信速度很快。
- 灵活。http允许传输任意类型的数据对象。
- 无连接。限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答之后,就断开连接。采用这种方式可以节省时间。从http1.1默认使用长连接,即服务器需要等待一定时间后才断开连接,以保证连接特性。长连接无法得知,下层实现对上层透明。
- 无状态。协议对事物处理没有记忆能力
http1.1相比较于1.0是引入了keep-alive长连接技术。2.0虽然更合理,更先进,但是推广不开的原因是1.1目前完全可以满足应用,并且升级上,2.0成本太大。
2.HTTP相应的步骤:
- 客户端连接到web服务器。一个http客户端通常是浏览器与web服务器的http端口。默认端口号是80建立一个tcp套接字连接。
- 发送htttp请求。通过tcp套接字,客户端向web服务器发送一个文本的请求报文。请求报文包含请求的方法,url,协议版本,请求头部和请求数据。
- 服务器接收请求并返回http响应。web服务器解析该请求,定位请求资源,服务器将资源副本写到tcp套接字由客户端读取。
- 释放tcp连接。若连接模式为close,则服务器主动关闭tcp连接,客户端被动关闭连接,释放tcp连接。若连接模式为keep-alive,则该连接会保持一段时间, 在该时间内可以继续接收请求。
- 客户端浏览器解析HTML内容。客户端浏览器首先去解析状态行,查看表明请求是否成功的状态代码。然后解析每一个响应头。响应头告知以下为若干字节的html文档客户端读取响应html,根据html的语法对其进行格式化,并在浏览器窗口中显示。
3. 在浏览器地址栏键入URL,按下回车键之后经历的流程:
1.首先浏览器会依据URL逐层查询DNS服务器缓存,解析URL中的域名所对应的IP地址。DNS缓存从进到远一次是:浏览器缓存->系统缓存->路由器缓存->IPS服务器缓存->根域名服务器缓存->顶级域名服务器缓存。从那个缓存找到对应的ip,则直接返回,不在查询后面的缓存。
2. TCP连接。找到ip地址之后,会根据该ip地址的对应端口默认是80端口和服务器建立TCP连接 然后三次握手。
3. 发送http请求。之后浏览器会发出读取文件的http请求,该请求将发送给服务器。
4. 服务器处理请求并返回HTTP报文。服务器请求对浏览器请求做出响应,并把对应的带有对应html文本的http响应报文发送给浏览器。
5. 浏览器解析渲染页面。浏览器收到了html
6. ,并在显示窗口内去渲染它。
7. 浏览器释放tcp连接, 即四次挥手。
5和6可以认为是同时发生的,那一步在前没有要求。
4. HTTP状态码
需要状态码大致判定出现问题的原因。
5种可能的取值:
1xx | 指示信息–表示请求已接收,继续处理 |
---|---|
2xx | 成功–表示请求已被成功接收、理解、接受 |
3xx | 重定向–要完成请求必须进行进一步操作,往往这一类和跳转相关 |
4xx | 客户端错误–请求有语法错误或请求无法实现 |
5xx | 服务器端错误–服务器未能实现合法的请求、 |
常见状态码:
状态码 | 信息含义 |
---|---|
200 OK | 正常返回信息 |
400 Bad Request | 客户端请求有语法错误,不能被服务器所理解 |
401 Unauthorized: | 请求未经授权,这个状态码必须和WWW-Authenticate 报头域一起作用 |
403 Forbidden: | 服务器收到请求,但是拒绝提供服务 |
404 Not Found: | 请求资源不存在,eg,输入了错误的URL |
500 Internal Server Error: | 服务器发生不可预期的错误 |
503 Server Unavaliable: | 服务器当前不能处理客户端的请求,一段时间后可能回复正常 |
5. GET请求和POST请求的区别
从三个层面来解答:
比较方面 | GET | POST |
---|---|---|
http报文层面 | GET将请求信息放在URL,请求信息与URL之间以“?”隔开,请求信息的格式为键值对 ,且请求信息会有长度限制 | POST放在报文体中,想获得请求信息必须 解析报文,因此安全性比GET方式高一些,但是解析报文获取信息方式也很容易,所以安全性方面两者并没有太大区别,想要解决信息安全问题,还要靠https,请求信息长度没有限制 |
数据库层面 | GET符合幂等性(对数据库的一次操作和多次操作获得的结果是一致的)和安全性(对数据库的操作没有改变数据库中的数据),get请求是做查询工作的 | POST不符合,POST请求会往数据库中提交数据,因此会改变数据库中的数据,POST请求是作用在上一级的URL上的,每一次请求都会添加新资源,每次获得的结果可能不一样 |
其他层面 | GET可以被缓存,会保存在浏览器的浏览记录中、被存储 | 不行 |
Cookie和Session的区别
Cookie简介:
- 由服务器发送给客户端的特殊信息,以文本的形式存放在客户端。
- 客户端再次请求的时候,会把Cookie回发。
- 服务器接收到后,会解析Cookie生成与客户端相对应的内容。
因为HTTP是无状态的,也就意味着我们每次访问某个有登录需求的页面时,每次都要输入账号和密码。现实生活中并没有出现这样的情况,这是因为引入了某些机制让HTTP具备了状态,其中的两个便是Cookie和Session。
Cookie技术是客户端的解决方案,是由服务器发送给客户端的特殊信息,以文本的形式存放在客户端。客户端每次向服务器发送请求时,都会带上这些特殊的信息。
当用户使用浏览器访问一个支持Cookie的网站的时候,用户会提供包括用户名在内的个人信息,并且提交至服务器。紧接着,服务器向客户端回传响应的超文本的同时,也会发回这些个人信息。这些信息并不是存放在HTTP响应体response body中的,而是存放在HTTP响应头response header,当用户端浏览器接收到了来自服务器的响应之后,浏览器会将这些信息存放在一个统一的位置。之后,客户端再向服务器发送请求的时候,都会把响应的cookie再次发回至服务器中,而这一次Cookie信息则存放在http请求头里面了。
服务器在接收到来自客户端浏览器的请求之后,就能够通过分析存放于请求头的Cookie得到客户端特有的信息,从而动态生成与该客户端相对应的内容。
Cookie的设置以及发送过程
Session简介:
- 服务器端机制,在服务器上保存的信息
- 解析客户端请求并操作session id ,按需保存状态信息
Session机制是一种服务器端机制,服务器使用了一种类似于散列表的结构来保存信息。当程序需要为某个客户端的请求创建一个session的时候,服务器首先检查这个客户端的请求里是否已包含了一个session标识,称为session id,如果已包含session id,则说明以前已经为此客户端创建过session,服务器就按照session id,把这个session检索出来使用。如果检索不到,就会新建一个。如果客户端请求不包含session id ,则为此客户端创建一个session ,并且生成一个与此相关的session id。session id的值应该是一个既不会重复又不容易被找到的规律以防被捏造的字符串。这个session id将会在本次响应中
回发给客户端进行保存。
Session的实现方式:
- 使用Cookie来实现
- 使用URL回写来实现
Cookie和Session的区别:
- Cookie数据存放在客户的浏览器中,Session数据存放在服务器上
- Session相对于Cookie更安全
- 若考虑减轻服务器负担,应当使用Cookie