1、一个十分重要的对象XHR
使用XMLHttpRequest (XHR)对象可以与服务器交互。您可以从URL获取数据,而无需让整个的页面刷新。这使得Web页面可以只更新页面的局部,而不影响用户的操作。XMLHttpRequest在 Ajax 编程中被大量使用。
尽管名称如此,XMLHttpRequest可以用于获取任何类型的数据,而不仅仅是XML,它还支持 HTTP以外的协议(包括文件和ftp)。
如果您的通信需要从服务器接收事件或消息数据,请考虑通过EventSource
接口使用 server-sent events。对于 full-duplex 通信, WebSockets 可能是更好的选择。
属性节
此接口继承了 XMLHttpRequestEventTarget
和 EventTarget
的属性。
XMLHttpRequest.onreadystatechange
当readyState属性发生变化时调用的EventHandler
。
返回 一个unsigned short 即无符号短整型,请求的状态码。
返回ArrayBuffer
、Blob
、Document
、DOMString
},具体是哪种类型取决于XMLHttpRequest.responseType
的值。其中包含响应体body。
XMLHttpRequest.responseText
只读
返回一个DOMString
},该DOMString
}包含对请求的响应,如果请求未成功或尚未发送,则返回null。
定义响应类型的枚举值。
返回响应的序列化URL,如果URL为空,则返回空字符串。
XMLHttpRequest.responseXML
只读 Not available to workers
返回一个Document
,其中包含该请求的响应,如果请求未成功、尚未发送或不能解析为XML或HTML,则返回null。
返回 unsigned short 即无符号短整型请求响应状态。
返回一个DOMString
},其中包含HTTP服务器返回的响应状态。与 XMLHTTPRequest.status
不同的是,它包括响应状态的整个文本(例如,“200 OK”)。
unsigned long 即无符号长整型,表示该请求的最大请求时间(毫秒),超过该时间请求会自动结束。
XMLHttpRequestEventTarget.ontimeout
当请求超时调用的EventHandler
。{ { gecko_minversion_inline(" 12.0 ")} }
XMLHttpRequestUpload
,表示上传过程。
XMLHttpRequest.withCredentials
Boolean
,用来指定跨域的请求是否应该使用证书(如cookie或授权header头)。
nsIChannel
,对象在执行请求时使用的通道。
一个布尔值,如果为真,请求将在没有cookie和身份验证header头的情况下发送。
一个布尔值,如果为真,则在请求时不会强制执行同源策略。
XMLHttpRequest.mozBackgroundRequest
一个布尔值,它指示对象是否是后台服务器端的请求
XMLHttpRequest.mozResponseArrayBuffer
已废弃 Gecko 6 只读
一个ArrayBuffer类型,把请求的响应作为一个TypedArrays。
XMLHttpRequest.multipart
已废弃 Gecko 22
这个Gecko的独有属性,是一个布尔值,在Firefox/Gecko 22中被删除了。请使用Server-Sent Events, Web Sockets, 或来自进度事件的responseText代替。
方法节
如果请求已经被发送,则立刻中止请求.
XMLHttpRequest.getAllResponseHeaders()
以字符串的形式返回所有用CRLF分隔的响应头,如果没有收到响应,则返回null。
XMLHttpRequest.getResponseHeader()
返回包含指定响应头的字符串,如果响应尚未收到或响应中不存在该报头,则返回null。
初始化一个请求。该方法只能JavaScript代码中使用,若要在native code中初始化请求,请使用openRequest()。
XMLHttpRequest.overrideMimeType()
重写由服务器返回的MIME type。
发送请求。如果请求是异步的(默认),那么该方法将在请求发送后立即返回。
XMLHttpRequest.setRequestHeader()
设置HTTP请求头的值。您必须在open()之后、send()之前调用setRequestHeader()这个方法。
非标准方法节
init()
在 C++代码中初始化一个XHR对象.
警告: 该方法不能在 JavaScript 代码中使用.
openRequest()
初始化一个请求. 这个方法用于本地代码; 如果用JavaScript 代码来初始化请求, 使用 open()
代替. 看文档open()
.
XMLHttpRequest.sendAsBinary()
send()方法的变体,用来发送二进制数据。
2、服务器返回的状态码
当我们从客户端向服务器发送请求时
服务器向我们返回状态码
状态码就是告诉我们服务器响应的状态
通过它,我们就可以知道当前请求是成功了还是出现了什么问题
状态码是由3位数字和原因短语组成的(比如最常见的:200 OK)
其中第一位数字表示响应类别,响应类别从1到5分为五种
add:其实我查阅资料发现还有一个6打头的一个 600 Unparseable Response Headers
表示服务器没有返回响应头部,只返回实体内容,也算做服务器错误状态码吧,不过绝对不常见
状态码 响应类别 原因短语
1XX 信息性状态码(Informational) 服务器正在处理请求
2XX 成功状态码(Success) 请求已正常处理完毕
3XX 重定向状态码(Redirection) 需要进行额外操作以完成请求
4XX 客户端错误状态码(Client Error) 客户端原因导致服务器无法处理请求
5XX 服务器错误状态码(Server Error) 服务器原因导致处理请求出错
---------------------
原文:https://blog.csdn.net/q1056843325/article/details/53147180
https://blog.csdn.net/hhthwx/article/details/78659323
HTTP协议了解一下:消息格式举例
2018.11.1 学习 http://www.cnblogs.com/tylerdonet/p/3520862.html
浏览器与服务器通信的过程
首先当用户在浏览器的地址栏中敲入了网站的网址 ( 比如: alibaba.com ) ,这时浏览器会首先通过访问的域名来定位到IP (DNS) 从而找到去哪里获取资源, 这时, 浏览器会依次进行如下查找:
1. 浏览器缓存 :
浏览器首先会在自己的缓存中查找有没有对应的域名 – IP匹配, 如果好运的话, 这里就可以直接尝试去访问资源了, 如果运气平平则往下走吧.
2. 系统缓存 :
浏览器缓存中没有命中, 浏览器会告诉操作系统:”嘿, 我在我自己口袋里没找到, 可能丢了, 我得去你那看看”, 然后, 一个系统进程(?)调取系统中的DNS缓存进行查询, 重复上一条的运气判断…
3. 路由器缓存 :
走到这, 运气还真不太好啊, 操作系统也没辙了, 那怎么办呢, 向路由去要要看吧… 重复运气判断…
4. ISP DNS缓存 :
好吧, 真不知道说运气好还是运气不好了, 不废话, 去ISP (网络提供商) 的DNS缓存服务器中寻找了, 一般情况下, 在ISP端的缓存中都能找到相应的缓存记录了, 不该这么背了, 或者… 您的ISP有够菜…
5. 递归搜索…
最无奈的情况发生了, 在前面都没有办法命中的DNS缓存的情况下, ISP的DNS服务器开始从root域名服务器开始进行递归, 顺序是从.com顶级域名服务器到alibaba的域名服务器, 再没找到…好吧, 您认为您要去的网站真的公开存在么…?
两个KEY POINT:
首先我们想想,我们要和接线员通话是不是要约定一个大家都能听得懂的语言,否则我说中文他说英语,这样就谁也听不懂谁的话,也不会完成通话,那么这个约定的语言是什么呢?那就是HTTP协议。
超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。
我们可以把它理解成一种浏览器和服务器都遵循的一种语法规范,所有的信息都是通过这种语法规范传输的,这样浏览器和服务器都可以正确的理解。
浏 览器和服务器一般并不是直接连接上的,而是需要通过中间的网络设备,就像我们的声音并不是直接传到接线员的耳朵里,而是要通过电话线通过电波传送一样,浏 览器和服务器所发送的遵循HTTP协议的信息也要通过网络设备的传递才能被对方所接收。而这就需要一种在网络设备(网线)上传输数据的一种通用的语法规范 (协议)。这样的协议使用最多的有2种:TCP协议和UDP协议
下面让我们来看看我们浏览网页的时候发生了什么吧。
1.首先我们在地址栏上输入我们想要打开的网址,然后我们通常会按下回车。这样一个请求就由浏览器以一种满足http协议的请求报文的形式发往服务器,请求报文中包含了要请求的页面地址,请求的文件类型等一系列信息。
2.在请求报文传递至客户端得网络设备的时候,网络设备把请求报文包装在一个满足TCP协议的数据中,通过网线传向服务器的网络设备。
3.服务器的网络设备接收到数据后,使用特殊的算法将数据解译,重新恢复成浏览器发出满足http协议的请求报文的形式,然后传向服务器软件。
4.服务软件得到请求报文后,根据请求报文所请求的页面地址在服务器的数据库中找到相应的页面,然后生成满足http协议的响应报文发向浏览器。响应报文中包括了响应报文头和被请求页面的代码(响应报文体)。
5.同样的,响应报文通过服务器的网络设备,被包装在一个满足TCP协议的数据,通过网线传向客户端的网络设备。
6.客户端的网络设备将响应报文解析,然后传给浏览器软件,浏览器在将响应报文解析,这样我们就在浏览器上看到了想要看到的网页。
B/S(Browser/Server)结构就是浏览器/服务器结构,它是随着Internet技术的兴起,对C/S结构的一种变化或者改进的结构。在这种结构下,用户工作界面是通过WWW浏览器来实现,极少部分事务逻辑在前端(Browser)实现,但是主要事务逻辑在服务器端(Server)实现,形成所谓三层3-tier结构。本文将主要讲解浏览器和服务器通信的过程。
浏览器和服务器之间的通讯并不是看上去那么简单,里面还是有着许多的门道的。想要简单理解浏览器和服务器之间的通讯,我们可以打一个简单的比方:
设想我们自己就是浏览器,服务器就是10086语音服务台,我们现在想要和10086服务台取得联系(比如说想骚扰接线员MM),我们该怎么办呢?
当然,大多数人都应该想到,那就是要有部电话。是这样的,这就引出了我们的第一个概念:套接字(Socket)。
套接字在百度百科上的解释是:
多个TCP连接或多个应用程序进程可能需要通过同一个 TCP协议端口传输数据。为了区别不同的应用程序进程和连接,许多计算机操作系统为应用程序与TCP/IP协议交互提供了称为套接字(Socket)的接口。
这个解释太学术了,我们可以简单把套接字理解成一个电话,我们可以从中发送信息和获取信息。
好了,电话有了,我们该给10086服务台打电话了。等等,我们是不是忘了一点,给10086打电话是不是要保证10086服务台也要有一部电话来等待我们的来电呢?对的,那么就是说服务器端也要有一个套接字,专门接受浏览器的请求。一般当一个服务器启动服务后就会开启一个监听连接的套接字,专门等待浏览器连接,接受浏览器请求。
接下来我们要开始打电话了。大多数人都应该有给10086服务台打电话的经验吧,接通后并不是马上由接线员MM来接听你的电话的,而是根据语音提示选择你想要的服务。当你选择了语音服务以后,系统才会自动给你安排一个接线员MM来 接听你的电话。那么这个过程是不是又生成了一个套接字呢?是的,没错,我们可以把呼叫系统(也就是给你语音提示,让你选择服务的系统)当成专门接受浏览器 的请求的那个套接字,当浏览器发送了一个请求后系统自动生成一个专门和你的浏览器通信的套接字,这样我们就可以和接线员MM通话了,浏览器也就可以和服务器通信了。
当然这远远不是B/S结构的全部,我们还需要进一步深化:
首先我们想想,我们要和接线员通话是不是要约定一个大家都能听得懂的语言,否则我说中文他说英语,这样就谁也听不懂谁的话,也不会完成通话,那么这个约定的语言是什么呢?那就是HTTP协议。
还是先来看百度百科上的解释:
超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。
我们就可以把它理解成一种浏览器和服务器都遵循的一种语法规范,所有的信息都是通过这种语法规范传输的,这样浏览器和服务器都可以正确的理解。
浏览器和服务器一般并不是直接连接上的,而是需要通过中间的网络设备,就像我们的声音并不是直接传到接线员的耳朵里,而是要通过电话线通过电波传送一样,浏览器和服务器所发送的遵循HTTP协议的信息也要通过网络设备的传递才能被对方所接收。而这就需要一种在网络设备(网线)上传输数据的一种通用的语法规范(协议)。这样的协议使用最多的有2种:TCP协议和UDP协议
TCP---传输控制协议,提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前,必须先在双方之间建立一个TCP连接,之后才能传输数据。TCP提供超时重发,丢弃重复数据,检验数据,流量控制等功能,保证数据能从一端传到另一端。
UDP---用户数据报协议,是一个简单的面向数据报的运输层协议。UDP不提供可靠性,它只是把应用程序传给IP层的数据报发送出去,但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接,且没有超时重发等机制,故而传输速度很快。
不管使用哪种方法,总之这样网络设备间也有了一套传输的协议,这样一来,浏览器和服务器才能真正的实现通信。
下面让我们来看看我们浏览网页的时候发生了什么吧。
1.首先我们在地址栏上输入我们想要打开的网址,然后我们通常会按下回车。这样一个请求就由浏览器以一种满足http协议的请求报文的形式发往服务器,请求报文中包含了要请求的页面地址,请求的文件类型等一系列信息。
2.在请求报文传递至客户端得网络设备的时候,网络设备把请求报文包装在一个满足TCP协议的数据中,通过网线传向服务器的网络设备。
3.服务器的网络设备接收到数据后,使用特殊的算法将数据解译,重新恢复成浏览器发出满足http协议的请求报文的形式,然后传向服务器软件。
4.服务软件得到请求报文后,根据请求报文所请求的页面地址在服务器的数据库中找到相应的页面,然后生成满足http协议的响应报文发向浏览器。响应报文中包括了响应报文头和被请求页面的代码(响应报文体)。
5.同样的,响应报文通过服务器的网络设备,被包装在一个满足TCP协议的数据,通过网线传向客户端的网络设备。
6.客户端的网络设备将响应报文解析,然后传给浏览器软件,浏览器在将响应报文解析,这样我们就在浏览器上看到了想要看到的网页。
以上只是浏览器与服务器之间通信的最简单的形式,实际使用中,一个网页往往包含着html代码,js代码,css样式表,图片等等多种数据,而这些数据并不是一次性由服务器传给浏览器的,而是存在着一定的顺序。首先服务器收到浏览器的请求后会将html代码发给浏览器,浏览器收到响应后会解析响应报文,发现html代码中包含着js代码和css样式表,而浏览器端并没有这些数据,所以浏览器会再次发送请求,向服务器请求js代码或css样式表数据(注意一次只能请求一种类型的数据),服务器收到请求后,会根据浏览器的请求再次找到数据库中的js文件或css样式表,将其发送到浏览器端。当网页中包含图片的时候也是同理。就这样循环往复,经过多次浏览器的请求和服务器的响应,当浏览器发现自己已经有了所有需要的数据后,会停止发送请求,这样一个完整的网页就呈现在我们眼前了。