cors配置 http状态码 tcp协议 一些内容
2021-01-21 16:15
标签:format xmlhttp available 答复 拷贝 desktop 默认 计时 理解 阮一峰和其他博客和计算机网络 原文链接:https://blog.csdn.net/qq_38950316/article/details/81087809 原文链接:https://blog.csdn.net/Freak_ysy/article/details/81543873 3. CORS 1. CORS需要浏览器和服务器同时支持。 2. 浏览器发现ajax跨域就会自动添加附加信息,所以实现cors的关键是服务器实现cors接口 3.请求 1. 非简单请求:会在通信之前增加http查询,县询问服务器,当前域名是在在许可名单,只有得到肯定答复才会发送请求否则报错 --------JSONP只支持`GET`请求,CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器,以及可以向不支持CORS的网站请求数据。 5. cors设置 1. 简单请求:浏览器在头部加上origin字段-------用来说明本次请求来自哪里,服务器根据这个值决定是否同意这次请求 - 不同意返回正常的http回应 1. 浏览器发现,这个回应的头信息没有包含`Access-Control-Allow-Origin`字段,就知道出错了,从而抛出一个错误,被`XMLHttpRequest`的`onerror`回调函数捕获 - 同意的返回 1. Access-Control-Allow-Origin: http://api.bob.com //该字段是必须的。它的值要么是请求时Origin字段的值,要么是一个*,表示接受任意域名的请求。 Access-Control-Allow-Credentials: true//可选。它的值是一个布尔值,表示是否允许发送Cookie。默认情况下,Cookie不包括在CORS请求之中 Access-Control-Expose-Headers: FooBar Content-Type: text/html; charset=utf-8 //可选。CORS请求时,XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段:Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段,就必须在Access-Control-Expose-Headers里面指定 //CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器,一方面要服务器同意,指定Access-Control-Allow-Credentials字段。 //开发者必须在AJAX请求中打开withCredentials属性。 **如果要发送Cookie,`Access-Control-Allow-Origin`就不能设为星号,必须指定明确的、与请求网页一致的域名。** ###### 非简单请求:会在通信之前增加http查询,县询问服务器,当前域名是在在许可名单,只有得到肯定答复才会发送请求否则报错 - "预检"请求用的请求方法是`OPTIONS`,表示这个请求是用来询问的。头信息里面,关键字段是`Origin`,表示请求来自哪个源。 除了`Origin`字段,"预检"请求的头信息包括两个特殊字段。 **(1)Access-Control-Request-Method** 该字段是必须的,用来列出浏览器的CORS请求会用到哪些HTTP方法,上例是`PUT`。 **(2)Access-Control-Request-Headers** 该字段是一个逗号分隔的字符串,指定浏览器CORS请求会额外发送的头信息字段,上例是`X-Custom-Header`。 - 服务器收到检查上述字段之后 1. 如果返回正确的http状态吗没有其余的回应则浏览器知道不支持访问 2. 返回字段包含下面 **1)Access-Control-Allow-Methods** 该字段必需,它的值是逗号分隔的一个字符串,表明服务器支持的所有跨域请求的方法。注意,返回的是所有支持的方法,而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。 **(2)Access-Control-Allow-Headers** 如果浏览器请求包括`Access-Control-Request-Headers`字段,则`Access-Control-Allow-Headers`字段是必需的。它也是一个逗号分隔的字符串,表明服务器支持的所有头信息字段,不限于浏览器在"预检"中请求的字段。 **(3)Access-Control-Allow-Credentials** 该字段与简单请求时的含义相同。 **(4)Access-Control-Max-Age** 该字段可选,用来指定本次预检请求的有效期,单位为秒。在此期间,不用发出另一条预检请求。 - 一旦服务器通过了"预检"请求,以后每次浏览器正常的CORS请求,就都跟简单请求一样,会有一个`Origin`头信息字段。服务器的回应,也都会有一个`Access-Control-Allow-Origin`头信息字段。 1. get和post的区别 1. 对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据); 而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据) 2. \1. GET与POST都有自己的语义,不能随便混用。 \2. 如果网络环境好的话,发一次包的时间和发两次包的时间差别基本可以无视。如果网络环境差的话,两次包的TCP在验证数据包完整性上,有非常大的优点。 \3. 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。 3. GET在浏览器回退时是无害的,而POST会再次提交请求。-------GET请求会被浏览器主动cache,而POST不会,除非手动设置。------GET请求只能进行url编码,而POST支持多种编码方式。------GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。------GET请求在URL中传送的参数是有长度限制的,而POST么有。-----对参数的数据类型,GET只接受ASCII字符,而POST没有限制。------GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。------GET参数通过URL传递,POST放在Request body中 ###### http请求码 - 1xx 1. 100 - Continue 初始的请求已经接受,客户应当继续发送请求的其余部分 2. 101 - Switching Protocols 服务器将遵从客户的请求转换到另外一种协议 - 2xx:表明服务器成功地接受了客户端请求。 1. 200 - OK 一切正常,对GET和POST请求的应答文档跟在后面。 2. 201 - Created 服务器已经创建了文档 3. 202 - Accepted 已经接受请求,但处理尚未完成。 4. 203 - Non-Authoritative Information 文档已经正常地返回,但一些应答头可能不正确,因为使用的是文档的拷贝, 5. · 204 - No Content 没有新文档,浏览器应该继续显示原来的文档。 6. 205 - Reset Content 没有新的内容,但浏览器应该重置它所显示的内容。用来强制浏览器清除表单 7. 206 - Partial Content 客户发送了一个带有Range头的GET请求,服务器完成了它 - 3xx-- 重定向 1. 300 - Multiple Choices 客户请求的文档可以在多个位置找到,这些位置已经在返回的文档内列出。如果服务器要提出优先选择,则应该在Location应答头指明。 2. 301 - Moved Permanently 客户请求的文档在其他地方,浏览器应该自动地访问新的URL。 3. 302 - Found 类似于301,但新的URL应该被视为临时性的替代,而不是永久性的。 4. 303 - See Other 类似于301/302,不同之处在于,如果原来的请求是POST,重定向目标文档应该通过GET提取 5. 304 - Not Modified 客户端有缓冲的文档并发出了一个条件性的请求 6. 305 - Use Proxy 客户请求的文档应该通过Location头所指明的代理服务器提取 7. 307 - Temporary Redirect 和302(Found)相同。许多浏览器会错误地响应302应答进行重定向,即使原来的请求是POST,即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因,HTTP 1.1新增了307,以便更加清除地区分几个状态代码:当出现303应答时,浏览器可以跟随重定向的GET和POST请求;如果是307应答,则浏览器只能跟随对GET请求的重定向。 - 4xx---客户端错误 1. 400 - Bad Request 请求出现语法错误。 2. 401 - Unauthorized 访问被拒绝,客户试图未经授权访问受密码保护的页面 3. 403 - Forbidden 资源不可用。服务器理解客户的请求,但拒绝处理它 4. 404 - Not Found 无法找到指定位置的资源 5. 405 - Method Not Allowed 请求方法(GET、POST、HEAD、Delete、PUT、TRACE等)对指定的资源不适用, 6. 406 - Not Acceptable 指定的资源已经找到,但它的MIME类型和客户在Accpet头中所指定的不兼容,客户端浏览器不接受所请求页面的 MIME 类型 7. 407 - Proxy Authentication Required 要求进行代理身份验证,类似于401,表示客户必须先经过代理服务器的授权 8. 408 - Request Timeout 在服务器许可的等待时间内,客户一直没有发出任何请求。客户可以在以后重复同一请求 - 5xx - 服务器错误 1. 500 - Internal Server Error 服务器遇到了意料不到的情况,不能完成客户的请求。 2. 501 - Not Implemented 服务器不支持实现请求所需要的功能,页眉值指定了未实现的配置。例如,客户发出了一个服务器不支持的PUT请求 3. 502 - Bad Gateway 服务器作为网关或者代理时,为了完成请求访问下一个服务器,但该服务器返回了非法的应答。 亦说Web 服务器用作网关或代理服务器时收到了无效响应。 4. 503 - Service Unavailable 服务不可用,服务器由于维护或者负载过重未能应答 5. 504 - Gateway Timeout 网关超时, ###### restful 1. 每一个URI代表一种资源; **所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。**每种资源对应一个特定的URI。要获取这个资源,访问它的URI就可以,因此URI就成了每一个资源的地址或独一无二的识别符,所谓"上网",就是与互联网上一系列的"资源"互动,调用它的URI。 2. 客户端和服务器之间,传递这种资源的某种表现层; **我们把"资源"具体呈现出来的形式,叫做它的"表现层"(Representation)。**它的具体表现形式,应该在HTTP请求的头信息中用Accept和Content-Type字段指定, 3. 客户端通过四个HTTP动词,对服务器端资源进行操作,实现"表现层状态转化"。 HTTP协议,是一个无状态协议。这意味着,所有的状态都保存在服务器端。因此,**如果客户端想要操作服务器,必须通过某种手段,让服务器端发生"状态转化"(State Transfer)**客户端用到的手段,只能是HTTP协议。具体来说:GET、POST、PUT、DELETE。它们分别对应四种基本操作:**GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源。** ###### udp 1. UDP是无连接的,即发送数据之前不需要建立连接(当然,发送数据结束时也没有连接可释放) 2. UDP是面向报文的。发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界,即一次发送一个报文 3. UDP使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的连接状态 4. UDP没有拥塞控制,因此网络出现的拥塞不会使源主机的发送速率降低 ###### tcp/ip 1. TCP是面向连接的运输层协议。这就是说,应用程序在使用TCP协议之前,必须先建立TCP连接。在传送数据完毕后,必须释放已经建立的TCP连接。 2. TCP提供可靠交付的服务。通过TCP连接传送的数据,无差错、不丢失、不重复,并且按序到达 过程 1. ![20180809205502714](/Users/mac/Desktop/20180809205502714.png) 2. 1)主机A向主机B发送TCP连接请求数据包,其中包含主机A的初始序列号seq(A)=x。(其中报文中同步标志位SYN=1,ACK=0,表示这是一个TCP连接请求数据报文;序号seq=x,表明传输数据时的第一个数据字节的序号是x) (2)主机B收到请求后,会发回连接确认数据包。(其中确认报文段中,标识位SYN=1,ACK=1,表示这是一个TCP连接响应数据报文,并含主机B的初始序列号seq(B)=y,以及主机B对主机A初始序列号的确认号ack(B)=seq(A)+1=x+1) (3)第三次,主机A收到主机B的确认报文后,还需作出确认,即发送一个序列号seq(A)=x+1;确认号为ack(A)=y+1的报文; 3. 三次握手不是二次的原因:如果A发送了两次请求给B,第一次由于其他原因没有及时到达b,而第二次是正常的得到了b的确认并且建立了连接, 之后第一个请求又到达了b,然后b又回应,如果只有两次握手这个连接就建立起来了,但是a收到回应自己又没有发送请求所以不会理会这个回应,b以为已经建立了连接就一直等待a发送数据但是a不会发送就浪费了b的资源 如果是三次握手,b发送回应a不确认的话这个连接就没有建立起来 所以第三次握手,a发送一次确认是为了防止:如果客户端迟迟没有收到服务器返回的确认报文,这时他会放弃连接,重新启动一条连接请求; 但问题是:服务器不知客户端没收到,所以他会收到两个连接请求,白白浪费了一条连接开销。而四次或更多次的握手,则是浪费资源,因为三次握手已经可以达到的效果没有必要再去多次连接 或者形成死锁:建立了连接但是a没有给b要发送的数据的一些信息,b不管收到啥都不会理会,就一直等待,而a发送了数据一直得不到回应就一直发送数据 1. ![20180809212921723](/Users/mac/Desktop/20180809212921723.jpeg) 2. 如果已经建立了连接,但是客户端突然出现故障了怎么办? TCP还设有一个保活计时器,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。 cors配置 http状态码 tcp协议 一些内容 标签:format xmlhttp available 答复 拷贝 desktop 默认 计时 理解 原文地址:https://www.cnblogs.com/zjj-study/p/13292620.html
上一篇:[SWPU2019]Web1
文章标题:cors配置 http状态码 tcp协议 一些内容
文章链接:http://soscw.com/index.php/essay/45048.html