码迷,mamicode.com
首页 > Web开发 > 详细

cors配置 http状态码 tcp协议 一些内容

时间:2020-07-13 13:57:23      阅读:74      评论:0      收藏:0      [点我收藏+]

标签: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-ControlContent-LanguageContent-TypeExpiresLast-ModifiedPragma。如果想拿到其他字段,就必须在Access-Control-Expose-Headers里面指定

        //CORS请求默认不发送CookieHTTP认证信息。如果要把Cookie发到服务器,一方面要服务器同意,指定Access-Control-Allow-Credentials字段。

        //开发者必须在AJAX请求中打开withCredentials属性。

          **如果要发送Cookie`Access-Control-Allow-Origin`就不能设为星号,必须指定明确的、与请求网页一致的域名。**

###### 非简单请求:会在通信之前增加http查询,县询问服务器,当前域名是在在许可名单,只有得到肯定答复才会发送请求否则报错

- "预检"请求用的请求方法是`OPTIONS`,表示这个请求是用来询问的。头信息里面,关键字段是`Origin`,表示请求来自哪个源。

  除了`Origin`字段,"预检"请求的头信息包括两个特殊字段。

  **1Access-Control-Request-Method**

  该字段是必须的,用来列出浏览器的CORS请求会用到哪些HTTP方法,上例是`PUT`

  **2Access-Control-Request-Headers**

  该字段是一个逗号分隔的字符串,指定浏览器CORS请求会额外发送的头信息字段,上例是`X-Custom-Header`

- 服务器收到检查上述字段之后

  1. 如果返回正确的http状态吗没有其余的回应则浏览器知道不支持访问

  2. 返回字段包含下面

     **1Access-Control-Allow-Methods**

     该字段必需,它的值是逗号分隔的一个字符串,表明服务器支持的所有跨域请求的方法。注意,返回的是所有支持的方法,而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。

     **2Access-Control-Allow-Headers**

     如果浏览器请求包括`Access-Control-Request-Headers`字段,则`Access-Control-Allow-Headers`字段是必需的。它也是一个逗号分隔的字符串,表明服务器支持的所有头信息字段,不限于浏览器在"预检"中请求的字段。

     **3Access-Control-Allow-Credentials**

     该字段与简单请求时的含义相同。

     **4Access-Control-Max-Age**

     该字段可选,用来指定本次预检请求的有效期,单位为秒。在此期间,不用发出另一条预检请求。

- 一旦服务器通过了"预检"请求,以后每次浏览器正常的CORS请求,就都跟简单请求一样,会有一个`Origin`头信息字段。服务器的回应,也都会有一个`Access-Control-Allow-Origin`头信息字段。

 

1. getpost的区别

   1. 对于GET方式的请求,浏览器会把http headerdata一并发送出去,服务器响应200(返回数据);

      而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)

2. \1. GETPOST都有自己的语义,不能随便混用。

   \2. 如果网络环境好的话,发一次包的时间和发两次包的时间差别基本可以无视。如果网络环境差的话,两次包的TCP在验证数据包完整性上,有非常大的优点。

   \3. 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。

3. GET在浏览器回退时是无害的,而POST会再次提交请求。-------GET请求会被浏览器主动cache,而POST不会,除非手动设置。------GET请求只能进行url编码,而POST支持多种编码方式。------GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。------GET请求在URL中传送的参数是有长度限制的,而POST么有。-----对参数的数据类型,GET只接受ASCII字符,而POST没有限制。------GETPOST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。------GET参数通过URL传递,POST放在Request body

###### http请求码

- 1xx

  1. 100 - Continue 初始的请求已经接受,客户应当继续发送请求的其余部分

  2.  101 - Switching Protocols 服务器将遵从客户的请求转换到另外一种协议

- 2xx:表明服务器成功地接受了客户端请求。

  1. 200 - OK 一切正常,对GETPOST请求的应答文档跟在后面。

  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 302Found)相同。许多浏览器会错误地响应302应答进行重定向,即使原来的请求是POST,即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因,HTTP 1.1新增了307,以便更加清除地区分几个状态代码:当出现303应答时,浏览器可以跟随重定向的GETPOST请求;如果是307应答,则浏览器只能跟随对GET请求的重定向。

- 4xx---客户端错误

  1. 400 - Bad Request 请求出现语法错误。

  2. 401 - Unauthorized 访问被拒绝,客户试图未经授权访问受密码保护的页面

  3. 403 - Forbidden 资源不可用。服务器理解客户的请求,但拒绝处理它

  4. 404 - Not Found 无法找到指定位置的资源

  5. 405 - Method Not Allowed 请求方法(GETPOSTHEADDeletePUTTRACE等)对指定的资源不适用,

  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请求的头信息中用AcceptContent-Type字段指定,

3. 客户端通过四个HTTP动词,对服务器端资源进行操作,实现"表现层状态转化"

   HTTP协议,是一个无状态协议。这意味着,所有的状态都保存在服务器端。因此,**如果客户端想要操作服务器,必须通过某种手段,让服务器端发生"状态转化"State Transfer**客户端用到的手段,只能是HTTP协议。具体来说:GETPOSTPUTDELETE。它们分别对应四种基本操作:**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=1ACK=0,表示这是一个TCP连接请求数据报文;序号seq=x,表明传输数据时的第一个数据字节的序号是x

   2)主机B收到请求后,会发回连接确认数据包。(其中确认报文段中,标识位SYN=1ACK=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

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!