阮一峰和其他博客和计算机网络
原文链接：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个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。