之前负责一个项目的时候出现这样一个问题,当我选用兼容模式的时候,某个Iframe嵌套的模块可以显示,但是,当我选择的是360极速模式的时候,就显示不出来,找了很久的原因,才发现是因为网站是Https的,而嵌套的是Http,导致在极速模式无法显示。
虽然问题不大,但是还是折腾了好久,讲出来,还是有不少可以说的地方,加上准备在一篇里面将之前的网络协议的相关的笔记整理出来。所以东西还是有很多的。
1.一些常见的协议
协议如同人与人的语言
将汉语和英语当作协议
将聊天当作通信
将说话内容当作数据
为了能够沟通,他们之间规定使用汉语这个协议
Tables | Are |
---|---|
SMTP: | Simple Mail Transfer Protocol:简单邮件传输协议 |
FTP: | File Transfer Protocol:文件传输协议 |
Telnet: | 用于远程登录的协议 |
DNS: | Domain Name System:域名解析服务 |
DHCP: | Dynamic Host Configuration Proctocol:动态主机分配协议 |
SNMP: | Simple Network Management Protocol:简单网络管理协议 |
SIP: | Session Initiation Protocol:用于多方多媒体通信:基于IP的一个应用层控制协议 |
HTTP: | Hyper Text Transfer Protocol:超文本传输协议 |
https: | 用安全套接字层传送的超文本传输协议 |
mailto: | 电子邮件地址 |
ldap: | 轻型目录访问协议搜索 |
file: | 当地电脑或网上分享的文件 |
news: | Usenet新闻组 |
gopher: | Gopher协议 |
telnet: | Telnet协议 |
网络协议的具体层级我借用了科来的图,很详细,非常感谢。
科来网络协议pdf下载
但是,这张图太详细,太大了,所以只将其中TCP/IP部分贴了出来,大家可以去下载原版,先来了大概的图。
这里只有部分:
基本上我们已经将相关的协议过了一遍,本身不是搞网络的,这一节就不详细梳理了。
再次感谢科来!!!!
2.网络硬件层
具体去分析协议之前,先将硬件层的一些常见的东西梳理一下。
在工作中,我碰到了类似于堡垒机,网闸,防火墙,核心交换机,网络行为管理,网关等一系列网络层的东西,一开始让我一度很蒙圈,很多普遍能实现的功能出现了各种问题,追其源头多数是被以上的控制了,这种情况下就有必要去了解这些东西大概有什么作用了。
领域 | 种类 | 作用 |
---|---|---|
堡垒机 | 跳板机 | 跳板机就是一台服务器,维护人员在维护过程中,首先要统一登录到这台服务器上,然后从这台服务器再登录到目标设备进行维护 |
堡垒机 | 云堡垒机 | 所谓云堡垒机,就是基于云计算的堡垒机系统,云堡垒机没有硬件,以软件和其他形式提供服务,获取起来极为方便,理论上可以达到秒级部署。 |
网闸 | 安全隔离网闸 | 安全隔离网闸是一种由带有多种控制功能专用硬件在电路上切断网络之间的链路层连接,并能够在网络间进行安全适度的应用数据交换的网络安全设备。 |
防火墙 | 防火墙(Firewall),也称防护墙 | 防火墙一般在进行IP包转发的同时,通过对IP包的处理,实现对TCP会话的控制,但是对应用数据的内容不进行检查。 |
上网行为管理 | 上网行为管理 | 上网行为管理是指帮助互联网用户控制和管理对互联网的使用。其包括对网页访问过滤、网络应用控制、带宽流量管理、信息收发审计、用户行为分析。 |
核心交换机 | 核心交换机 | 核心交换机并不是交换机的一种类型,而是放在核心层(网络主干部分)的交换机叫核心交换机。区别普通交换机 |
以上都是可以说看得见的管理部件,当然,还有一些我们看不到的网络部件。
- 网关(Gateway)又称网间连接器、协议转换器。网关在传输层上以实现网络互连,是最复杂的网络互连设备,仅用于两个高层协议不同的网络互连。网关既可以用于广域网互连,也可以用于局域网互连。
所以说,当我们想要与更高协议或者更高与我们通信的时候,必然会经过网关。
3.网络
3.1网络连接
1.TCP/IP的三次握手
首先,三次握手的目的
a. 第一次,发送请求
b. 第二次,返回是否同意,并且反馈第一次请求发送成功
c. 第三次,确认都知道。同时,告知第二次请求接收到此时,就完全了解到都可以接收和发送请求
包裹的发送
a. 先向目的地发送将要发送包裹的信息
b. 之前已经确定序号及端口号
c. 如果过大,将包裹拆分并且编号
d. 每次最多发送三个包裹
e. 每次收到一个就再发一个
f. 如果中间漏包,则需要从漏的地方重新发布
g. 反馈收到会按顺序,如果中间有遗漏,不会反馈后面已收到,直到遗漏被填补
3.2.Https
回到我们一开始谈到的事情,Https是什么?
在说HTTPS之前先说说什么是HTTP,HTTP就是我们平时浏览网页时候使用的一种协议。
HTTP协议传输的数据都是未加密的,也就是明文的,因此使 用HTTP协议传输隐私信息非常不安全。
为了保证这些隐私数据能加密传输,于是网景公司设计了SSL(Secure Sockets Layer)协议用于对HTTP协议传输的数据进行加密,从而就诞生了HTTPS。
以一个图来说明,图来源于码农翻身
HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手,在握 手过程中将确立双方加密传输数据的密码信息,通常情况下会配合数字证书实现。
TLS/SSL协议不仅仅是一套加密传输的协议,更是一件经过艺术家精心设计的艺术品,TLS/SSL中使用 非对称加密,对称加密以及HASH算法。
以及一个宏观的形象比喻:
浏览器将自己支持的一套加密规则发送给网站,如RSA加密算法,DES对称加密算法,SHA1摘要算法
网站从中选出一组加密算法与HASH算法,并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息(证书中的私钥只能用于服务器端进行解密,在握手的整个过程中,都用到了证书中的公钥和浏览器发送给服务器的随机密码以及对称加密算法)
获得网站证书之后浏览器要做以下工作:
a) 验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等),如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。
b) 如果证书受信任,或者是用户接受了不受信的证书,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。
c) 使用约定好的HASH算法计算握手消息(如SHA1),并使用生成的随机数对消息进行加密,最后将之前生成的被公钥加密的随机数密码,HASH摘要值一起发送给服务器- 网站接收浏览器发来的数据之后要做以下的操作:
a) 使用自己的私钥将信息解密并取出浏览器发送给服务器的随机密码,使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。
b) 使用随机密码加密一段握手消息,发送给浏览器。 - 浏览器解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
从上面的4个大的步骤可以看到,握手的整个过程使用到了数字证书、对称加密、HASH摘要算法,接下来我们用实际代码来实现整个过程
加密和解密算法是公开的,那个密钥是保密的,这种加密被称为:对称加密算法, 因为加密和解密用的是同一个密钥。
3.3.Http请求头
下面是一个案例:
①是请求方法,GET和POST是最常见的HTTP方法,除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。不过,当前的大多数浏览器只支持GET和POST,Spring 3.0提供了一个HiddenHttpMethodFilter,允许你通过“_method”的表单参数指定这些特殊的HTTP方法(实际上还是通过POST提交表单)。服务端配置了HiddenHttpMethodFilter后,Spring会根据_method参数指定的值模拟出相应的HTTP方法,这样,就可以使用这些HTTP方法对处理方法进行映射了。
②为请求对应的URL地址,它和报文头的Host属性组成完整的请求URL,③是协议名称及版本号。
④是HTTP的报文头,报文头包含若干个属性,格式为“属性名:属性值”,服务端据此获取客户端的信息。
⑤是报文体,它将一个页面表单中的组件值通过param1=value1¶m2=value2的键值对形式编码成一个格式化串,它承载多个请求参数的数据。不但报文体可以传递请求参数,请求URL也可以通过类似于“/chapter15/user.html? param1=value1¶m2=value2”的方式传递请求参数。
HTTP请求方法
根据HTTP标准,HTTP请求可以使用多种请求方法。
HTTP1.0定义了三种请求方法: GET, POST 和 HEAD方法。
HTTP1.1新增了五种请求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
序号 描述
序号 | 方法 | 描述 |
---|---|---|
1 | GET | 请求指定的页面信息,并返回实体主体。 |
2 | HEAD | 类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头 |
3 | POST | 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 |
4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
5 | DELETE | 请求服务器删除指定的页面。 |
6 | CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。 |
7 | OPTIONS | 允许客户端查看服务器的性能。 |
8 | TRACE | 回显服务器收到的请求,主要用于测试或诊断。 |
**HTTP的头域包括通用头、请求头、响应头和实体头四个部分。
每个头域由一个域名,冒号(:)和域值三部分组成,即键值对形式。**
通用头:是客户端和服务器都可以使用的头部,可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能,如Date头部。
请求头:是请求报文特有的,它们为服务器提供了一些额外信息,比如客户端希望接收什么类型的数据,如Accept头部。
响应头:便于客户端提供信息,比如,客服端在与哪种类型的服务器进行交互,如Server头部。
实体头:指的是用于应对实体主体部分的头部,比如,可以用实体头部来说明实体主体部分的数据类型,如Content-Type头部。
HTTP通用头:
通用头域包含请求和响应消息都支持的头域,通用头域包含缓存头部Cache-Control、Pragma及信息性头部Connection、Date、Transfer-Encoding、Update、Via。
信息 | 描述 |
---|---|
Cache-Control | 请求:no-cache(不要缓存的实体,要求现在从WEB服务器去取) |
max-age:(只接受 Age 值小于 max-age 值,并且没有过期的对象) max-stale:(可以接受过去的对象,但是过期时间必须小于 max-stale 值) min-fresh:(接受其新鲜生命期大于其当前 Age 跟 min-fresh 值之和的缓存对象) 响应:public(可以用 Cached 内容回应任何用户) private(只能用缓存内容回应先前请求该内容的那个用户) no-cache(可以缓存,但是只有在跟WEB服务器验证了其有效后,才能返回给客户端) max-age:(本响应包含的对象的过期时间) ALL: no-store(不允许缓存) | |
Pramga | 主要使用 Pramga: no-cache,相当于 Cache-Control: no-cache。 |
Connection | 表明客户端是否可以处理HTTP持久连接。持久连接允许客户端或浏览器在一个请求中获取多个文件。 |
close(告诉WEB服务器或者代理服务器,在完成本次请求的响应后,断开连接,不要等待本次连接的后续请求了)。 keepalive(告诉WEB服务器或者代理服务器,在完成本次请求的响应后,保持连接,等待本次连接的后续请求)。 响应:close(连接已经关闭)。 keepalive(连接保持着,在等待本次连接的后续请求)。 Keep-Alive:如果浏览器请求保持连接,则该头部表明希望 WEB 服务器保持连接多长时间(秒)。 | |
例如:Keep-Alive:300 | |
Date | 当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。 |
Transfer-Encoding | WEB 服务器表明自己对本响应消息体(不是消息体里面的对象)作了怎样的编码,比如是否分块(chunked) |
例如:Transfer-Encoding: chunked | |
Upgrade | 它可以指定另一种可能完全不同的协议,如HTTP/1.1客户端可以向服务器发送一条HTTP/1.0请求,其中包含值为“HTTP/1.1”的Update头部,这样客户端就可以测试一下服务器是否也使用HTTP/1.1了。 |
Via | 列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器,他们用什么协议(和版本)发送的请求。 |
当客户端请求到达第一个代理服务器时,该服务器会在自己发出的请求里面 添加 Via 头部,并填上自己的相关信息,当下一个代理服务器 收到第一个代理服务器的请求时,会在自己发出的请求里面复制前一个代理服务器的请求的Via头部,并把自己的相关信息加到后面, 以此类推,当 OCS 收到最后一个代理服 务器的请求时,检查 Via 头部,就知道该请求所经过的路由。 | |
例如:Via:1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13) |
请求头:
请求头用于说明是谁或什么在发送请求、请求源于何处,或者客户端的喜好及能力。服务器可以根据请求头部给出的客户端信息,试着为客户端提供更好的响应。请求头域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通讯双方都支持,如果存在不支持的请求头域,一般将会作为实体头域处理。
HTTP 请求消息头部实例:
Host:rss.sina.com.cn
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language:zh-cn,zh;q=0.5
Accept-Encoding:gzip,deflate
Accept-Charset:gb2312,utf-8;q=0.7,*;q=0.7
Keep-Alive:300
Connection:keep-alive
Cookie:userId=C5bYpXrimdmsiQmsBPnE1Vn8ZQmdWSm3WRlEB3vRwTnRtW <-- Cookie
If-Modified-Since:Sun, 01 Jun 2008 12:05:30 GMT
Cache-Control:max-age=0
HTTP 响应消息头部实例:
Status:OK - 200 <-- 响应状态码,表示 web 服务器处理的结果。
Date:Sun, 01 Jun 2008 12:35:47 GMT
Server:Apache/2.0.61 (Unix)
Last-Modified:Sun, 01 Jun 2008 12:35:30 GMT
Accept-Ranges:bytes
Content-Length:18616
Cache-Control:max-age=120
Expires:Sun, 01 Jun 2008 12:37:47 GMT
Content-Type:application/xml
Age:2
X-Cache:HIT from 236-41.D07071951.sina.com.cn <-- 反向代理服务器使用的 HTTP 头部
Via:1.0 236-41.D07071951.sina.com.cn:80 (squid/2.6.STABLE13)
Connection:close
=====================================
信息 | 描述 |
---|---|
Accept | 指定浏览器或其他客户端可以处理的MIME类型。它的值通常为 image/png 或 image/jpeg |
Accept-Charset | 指定浏览器要使用的字符集。比如 ISO-8859-1 |
Accept-Encoding | 指定编码类型。它的值通常为 gzip 或compress |
Accept-Language | 指定客户端首选语言,servlet会优先返回以当前语言构成的结果集,如果servlet支持这种语言的话。比如 en,en-us,ru等等 |
Authorization | 在访问受密码保护的网页时识别不同的用户 |
If-Modified-Since | 表明只有当网页在指定的日期被修改后客户端才需要这个网页。 服务器发送304码给客户端,表示没有更新的资源 |
If-Unmodified-Since | 与If-Modified-Since相反, 只有文档在指定日期后仍未被修改过,操作才会成功 |
If-Match | 如果对象的 ETag 没有改变,其实也就意味著对象没有改变,才执行请求的动作。 |
If-None-Match | 如果对象的 ETag 改变了,其实也就意味著对象也改变了,才执行请求的动作。 |
If-Modified-Since | 如果请求的对象在该头部指定的时间之后修改了,才执行请求 的动作(比如返回对象),否则返回代码304,告诉浏览器该对象没有修改。 |
例如:If-Modified-Since:Thu, 10 Apr 2008 09:14:42 GMT | |
If-Unmodified-Since | 如果请求的对象在该头部指定的时间之后没修改过,才执行 请求的动作(比如返回对象)。 |
If-Range | 浏览器告诉 WEB 服务器,如果我请求的对象没有改变,就把我缺少的部分给我,如果对象改变了,就把整个对象给我。 浏览器通过发送请求对象的 ETag 或者 自己所知道的最后修改时间给 WEB 服务器,让其判断对象是否 改变了。 总是跟 Range 头部一起使用。 |
Range | 浏览器(比如 Flashget 多线程下载时)告诉 WEB 服务器自己想取对象的哪部分。 |
例如:Range: bytes=1173546- | |
Proxy-Authenticate | 代理服务器响应浏览器,要求其提供代理身份验证信息。 |
Proxy-Authorization | 浏览器响应代理服务器的身份验证请求,提供自己的身份信息。 |
Host | 指出原始URL中的主机名和端口号 |
Referer | 标志着所引用页面的URL。比如,如果你在页面1,然后点了个链接至页面2,那么页面1的URL就会包含在浏览器请求页面2的信息头中 |
User-Agent | 用来区分不同浏览器或客户端发送的请求,并对不同类型的浏览器返回不同的内容 |
ETag | 就是一个对象(比如URL)的标志值,就一个对象而言,比如一个 html 文件, 如果被修改了,其 Etag 也会别修改, 所以,ETag 的作用跟 Last-Modified 的作用差不多,主要供 WEB 服务器 判断一个对象是否改变了。 比如前一次请求某个 html 文件时,获得了其 ETag,当这次又请求这个文件时,浏览器就会把先前获得的 ETag 值发送给 WEB 服务器,然后 WEB 服务器会把这个 ETag 跟该文件的当前 ETag 进行对比,然后就知道这个文件有没有改变了。 |
Http响应头
响应头向客户端提供一些额外信息,比如谁在发送响应、响应者的功能,甚至与响应相关的一些特殊指令。这些头部有助于客户端处理响应,并在将来发起更好的请求。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通讯双方都支持,如果存在不支持的响应头域,一般将会作为实体头域处理。
头信息 | 说明 |
---|---|
Age | 当代理服务器用自己缓存的实体去响应请求时,用该头部表明该实体从产生到现在经过多长时间了。 |
Server | 服务器名字。Servlet一般不设置这个值,而是由Web服务器自己设置。 |
Accept-Ranges | WEB服务器表明自己是否接受获取其某个实体的一部分(比如文件的一部分)的请求。bytes:表示接受,none:表示不接受。 |
Vary | WEB服务器用该头部的内容告诉 Cache 服务器,在什么条件下才能用本响应 所返回的对象响应后续的请求。 |
假如源WEB服务器在接到第一个请求消息时,其响应消息的头部为: Content-Encoding: gzip; Vary: Content-Encoding 那么 Cache 服务器会分析后续请求消息的头部,检查其 Accept-Encoding,是否跟先前响应的 Vary 头部值一致,即是否使用相同的内容编码方法,这样就可以防止 Cache 服务器用自己Cache 里面压缩后的实体响应给不具备解压能力的浏览器。 | |
例如:Vary:Accept-Encoding | |
Refresh | 表示浏览器应该在多少时间之后刷新文档,以秒计。除了刷新当前文档之外,你还可以通过setHeader(“Refresh”, “5; URL=http://host/path“)让浏览器读取指定的页面。 |
注意这种功能通常是通过设置HTML页面HEAD区的<META HTTP-EQUIV=”Refresh” CONTENT=”5;URL=http://host/path“>实现,这是因为,自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是,对于Servlet来说,直接设置Refresh头更加方便。 | |
注意Refresh的意义是”N秒之后刷新本页面或访问指定页面”,而不是”每隔N秒刷新本页面或访问指定页面”。因此,连续刷新要求每次都发送一个Refresh头,而发送204状态代码则可以阻止浏览器继续刷新,不管是使用Refresh头还是<META HTTP-EQUIV=”Refresh” …>。 注意Refresh头不属于HTTP 1.1正式规范的一部分,而是一个扩展,但Netscape和IE都支持它。 | |
WWW-Authenticate | 客户应该在Authorization头中提供什么类型的授权信息?在包含401(Unauthorized)状态行的应答中这个头是必需的。例如,response.setHeader(“WWW-Authenticate”, “BASIC realm=\”executives\”“)。 注意Servlet一般不进行这方面的处理,而是让Web服务器的专门机制来控制受密码保护页面的访问(例如.htaccess)。 |
Http实体头
实体头部提供了有关实体及其内容的大量信息,从有关对象类型的信息,到能够对资源使用的各种有效的请求方法。总之,实体头部可以告知接收者它在对什么进行处理。请求消息和响应消息都可以包含实体信息,实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息,实体头包括信息性头部Allow、Location,内容头部Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type,缓存头部Etag、Expires、Last-Modified、extension-header。
头信息 | 说明 |
---|---|
Allow | 服务器支持哪些请求方法(如GET、POST等)。 |
Location | 表示客户应当到哪里去提取文档。Location通常不是直接设置的,而是通过HttpServletResponse的sendRedirect方法,该方法同时设置状态代码为302。 |
Content-Encoding | 文档的编码(Encode)方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩,但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此,Servlet应该通过查看Accept-Encoding头(即request.getHeader(“Accept-Encoding”))检查浏览器是否支持gzip,为支持gzip的浏览器返回经gzip压缩的HTML页面,为其他浏览器返回普通页面。 |
Content-Length | 表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势,可以把输出文档写入 ByteArrayOutputStream,完成后查看其大小,然后把该值放入Content-Length头,最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。 |
Content-Location | 资源实际所处的位置。 |
Content-MD5 | 主体的MD5校验和。 |
Content-Type | 表示后面的文档属于什么MIME类型。Servlet默认为text/plain,但通常需要显式地指定为text/html。由于经常要设置Content-Type,因此HttpServletResponse提供了一个专用的方法setContentType。 |
Content-Range | 实体头用于指定整个实体中的一部分的插入位置,他也指示了整个实体的长度。在服务器向客户返回一个部分响应,它必须描述响应覆盖的范围和整个实体长度。 |
一般格式: Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth。例如,传送头500个字节次字段的形式:Content-Range:bytes0- 499/1234如果一个http消息包含此节(例如,对范围请求的响应或对一系列范围的重叠请求),Content-Range表示传送的范围,Content-Length表示实际传送的字节数。 | |
Expires | 应该在什么时候认为文档已经过期,从而不再缓存它? |
Last-Modified | 文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期,该请求将被视为一个条件GET,只有改动时间迟于指定时间的文档才会返回,否则返回一个304(Not Modified)状态。Last-Modified也可用setDateHeader方法来设置。 |
Set-Cookie | 设置和页面关联的Cookie。Servlet不应使用response.setHeader(“Set-Cookie”, …),而是应使用 |
3.4 Http状态码
HTTP响应状态码
100-199:表示成功接收请求,要求客户端继续提交下一次请求才能完成整个处理过程
200-299:表示成功接收请求并已完成整个处理过程,常用200
300-399:未完成请求,客户需进一步细化请求,常用302,307,304
400-499:客户端的请求有错误,常用404
500-599:服务器端出现错误,常用500
以下是详情:
状态码 | 消息 | 描述 |
---|---|---|
100 | Continue | 只有一部分请求被服务器接收,但只要没被服务器拒绝,客户端就会延续这个请求 |
101 | Switching Protocols | 服务器交换机协议 |
200 | OK | 请求被确认 |
201 | Created | 请求时完整的,新的资源被创建 |
202 | Accepted | 请求被接受,但未处理完 |
203 | Non-authoritative Information | |
204 | No Content | |
205 | Reset Content | |
206 | Partial Content | |
300 | Multiple Choices | 一个超链接表,用户可以选择一个超链接并访问,最大支持5个超链接 |
301 | Moved Permanently | 被请求的页面已经移动到了新的URL下 |
302 | Found | 被请求的页面暂时性地移动到了新的URL下 |
303 | See Other | 被请求的页面可以在一个不同的URL下找到 |
304 | Not Modified | |
305 | Use Proxy | |
306 | Unused | 已经不再使用此状态码,但状态码被保留 |
307 | Temporary Redirect | 被请求的页面暂时性地移动到了新的URL下 |
400 | Bad Request | 服务器无法识别请求 |
401 | Unauthorized | 被请求的页面需要用户名和密码 |
402 | Payment Required | 目前还不能使用此状态码 |
403 | Forbidden | 禁止访问所请求的页面 |
404 | Not Found | 服务器无法找到所请求的页面 |
405 | Method Not Allowed | 请求中所指定的方法不被允许 |
406 | Not Acceptable | 服务器只能创建一个客户端无法接受的响应 |
407 | Proxy Authentication Required | 在请求被服务前必须认证一个代理服务器 |
408 | Request Timeout | 请求时间超过了服务器所能等待的时间,连接被断开 |
409 | Conflict | 请求有矛盾的地方 |
410 | Gone | 被请求的页面不再可用 |
411 | Length Required | “Content-Length”没有被定义,服务器拒绝接受请求 |
4 12 | Precondition Failed | 请求的前提条件被服务器评估为false |
413 | Request Entity Too Large | 因为请求的实体太大,服务器拒绝接受请求 |
414 | Request-url Too Long | 服务器拒绝接受请求,因为URL太长。多出现在把”POST”请求转换为”GET”请求时所附带的大量查询信息 |
415 | Unsupported Media Type | 服务器拒绝接受请求,因为媒体类型不被支持 |
417 | Expectation Failed | |
500 | Internal Server Error | 请求不完整,服务器遇见了出乎意料的状况 |
501 | Not Implemented | 请求不完整,服务器不提供所需要的功能 |
502 | Bad Gateway | 请求不完整,服务器从上游服务器接受了一个无效的响应 |
503 | Service Unavailable | 请求不完整,服务器暂时重启或关闭 |
504 | Gateway Timeout | 网关超时 |
505 | HTTP Version Not Supported | 服务器不支持所指定的HTTP版本 |
4.Cookie与Session
Cookie与Session一两句话是说不清楚的,这里只是解释大概。
1.Cookie
1、cookie的作用:
我们在浏览器中,经常涉及到数据的交换,比如你登录邮箱,登录一个页面。我们经常会在此时设置30天内记住我,或者自动登录选项。那么它们是怎么记录信息的呢,答案就是今天的主角cookie了,Cookie是由HTTP服务器设置的,保存在浏览器中,但HTTP协议是一种无状态协议,在数据交换完毕后,服务器端和客户端的链接就会关闭,每次交换数据都需要建立新的链接。就像我们去超市买东西,没有积分卡的情况下,我们买完东西之后,超市没有我们的任何消费信息,但我们办了积分卡之后,超市就有了我们的消费信息。cookie就像是积分卡,可以保存积分,商品就是我们的信息,超市的系统就像服务器后台,http协议就是交易的过程。
2、机制的区别:
session机制采用的是在服务器端保持状态的方案,而cookie机制则是在客户端保持状态的方案,cookie又叫会话跟踪机制。打开一次浏览器到关闭浏览器算是一次会话。说到这里,讲下HTTP协议,前面提到,HTTP协议是一种无状态协议,在数据交换完毕后,服务器端和客户端的链接就会关闭,每次交换数据都需要建立新的链接。此时,服务器无法从链接上跟踪会话。cookie可以跟踪会话,弥补HTTP无状态协议的不足。
3、cookie的分类:
cookie分为会话cookie和持久cookie,会话cookie是指在不设定它的生命周期expires时的状态,前面说了,浏览器的开启到关闭就是一次会话,当关闭浏览器时,会话cookie就会跟随浏览器而销毁。当关闭一个页面时,不影响会话cookie的销毁。会话cookie就像我们没有办理积分卡时,单一的买卖过程,离开之后,信息则销毁。
持久cookie则是设定了它的生命周期expires,此时,cookie像商品一样,有个保质期,关闭浏览器之后,它不会销毁,直到设定的过期时间。对于持久cookie,可以在同一个浏览器中传递数据,比如,你在打开一个淘宝页面登陆后,你在点开一个商品页面,依然是登录状态,即便你关闭了浏览器,再次开启浏览器,依然会是登录状态。这就是因为cookie自动将数据传送到服务器端,在反馈回来的结果。持久cookie就像是我们办理了一张积分卡,即便离开,信息一直保留,直到时间到期,信息销毁。
4、简单的使用cookie的代码
cookie的几种常见属性:document.cookie=”key=value;expires=失效时间;path=路径;domain=域名;secure;(secure表安全级别),
cookie以字符串的形式保存在浏览器中。下面贴段代码出来,是一个类似购物网站的将商品添加到购物车,再从购物车还原商品信息的过程,是自己用原生JS封装的函数。
封装的cookie的存入,读取以及删除的函数:(这里是将信息以对象的形式存放到cookie中的,会用到JSON的知识)
2.Session
http是无状态的协议,客户每次读取web页面时,服务器都打开新的会话,而且服务器也不会自动维护客户的上下文信息,那么要怎么才能实现网上商店中的购物车呢?
session就是一种保存上下文信息的机制,它是针对每一个用户的,变量的值保存在服务器端,通过SessionID来区分不同的客户,session是以cookie或URL重写为基础的,默认使用cookie来实现,系统会创造一个名为JSESSIONID的输出cookie,我们叫做session cookie,以区别persistent cookies,也就是我们通常所说的cookie,注意session cookie是存储于浏览器内存中的,并不是写到硬盘上的,这也就是我们刚才看到的JSESSIONID,我们通常情是看不到JSESSIONID的,但是当我们把浏览器的cookie禁止后,web服务器会采用URL重写的方式传递Sessionid,我们就可以在地址栏看到 sessionid=KWJHUG6JJM65HS2K6之类的字符串。
1、session保存在服务器,客户端不知道其中的信息;cookie保存在客户端,服务器能够知道其中的信息。
2、session中保存的是对象,cookie中保存的是字符串。
3、session不能区分路径,同一个用户在访问一个网站期间,所有的session在任何一个地方都可以访问到。而cookie中如果设置了路径参数,那么同一个网站中不同路径下的cookie互相是访问不到的。
4、session需要借助cookie才能正常使用。
5.总结
先说这么多,这个后面还有很多,等笔记整理出来再贴出来
参考:
http://kingj.iteye.com/blog/2103662
http://blog.youkuaiyun.com/u010256388/article/details/68491509