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

   阮一峰和其他博客和计算机网络

原文链接：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. 简单请求

               1. 请求方式：head、get、post

               2.  http头部不超出这些字段：accept，accept-language，content-language，content-type（只限于三个值application/x-www-form-                     urlencoded、multipart/form-data、text/plain），last-event-id

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

   --------JSONP只支持`GET`请求，CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。

5. cors设置

   1. 简单请求：浏览器在头部加上origin字段-------用来说明本次请求来自哪里，服务器根据这个值决定是否同意这次请求

      1. 不同意返回正常的http回应

        1. 浏览器发现，这个回应的头信息没有包含`Access-Control-Allow-Origin`字段，就知道出错了，从而抛出一个错误，被`XMLHttpRequest`的`onerror`回调函数捕获

      2.  同意的返回

        1.   Access-Control-Allow-Origin: http://api.bob.com

           //该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。

        2.  Access-Control-Allow-Credentials: true//可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中

        3.  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`就不能设为星号，必须指定明确的、与请求网页一致的域名。**

   2. 非简单请求：非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。

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

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

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

          （1）Access-Control-Request-Method**

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

          （2）Access-Control-Request-Headers

            该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，

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

          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. 

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. 

2. 如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。