# 网络协议

# HTTP

HTTP 协议(HyperText Transfer Protocol,超文本传输协议)是因特网上应用最为广泛的一种网络传输协议,所有的 WWW 文件都必须遵守这个标准。

# 简介

HTTP 是一种能够获取如 HTML 这样的网络资源,一般都浏览器这样的接受方发起的,一个完整的 web 文档通常由不同的子文档拼接组成,像是文本、布局、图片、视频、脚本等等。

HTTP 是一个 基于 TCP/IP 通信协议 来传递数据(HTML 文件, 图片文件, 查询结果等)。

工作原理

  • HTTP 是一个 client-server 协议,客户端发起请求,服务端接受请求并做出相应。
  • 浏览器作为 HTTP 客户端通过 URL 向 HTTP(Web) 服务端即 WEB 服务器发送所有请求
  • 由像浏览器这样的客户端发出的消息叫做 requests,被服务端响应的消息叫做 responses

HTTP 协议通信流程

特点

  • 无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
  • 无状态:HTTP 协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。
  • 媒体独立的:这意味着,只要客户端和服务器知道如何处理的数据内容,任何类型的数据都可以通过 HTTP 发送。客户端以及服务器指定使用适合的 MIME-type 内容类型。

# HTTP 报文结构

HTTP 是基于客户端/服务端(C/S)的架构模型,通过一个可靠的链接来交换信息,是一个无状态的请求/响应协议。

一个 HTTP"客户端"是一个应用程序(Web 浏览器或其他任何客户端),通过连接到服务器达到向服务器发送一个或多个 HTTP 的请求的目的。

一个 HTTP"服务器"同样也是一个应用程序(通常是一个 Web 服务,如 Apache Web 服务器或 IIS 服务器等),通过接收客户端的请求并向客户端发送 HTTP 响应数据。

HTTP 使用统一资源标识符(Uniform Resource Identifiers, URI)来传输数据和建立连接。

一旦建立连接后,数据消息就通过类似 Internet 邮件所使用的格式[RFC5322]和多用途 Internet 邮件扩展(MIME)[RFC2045]来传送。

# 客户端请求报文

客户端发送一个 HTTP 请求到服务器的请求消息包括以下格式:请求行(request line)、请求头部(header)、空行和请求数据四个部分组成。

# 服务器相应报文

HTTP 响应也由四个部分组成,分别是:状态行、消息报头、空行和响应正文。

# 请求方法

HTTP1.0 定义了三种请求方法: GET, POST 和 HEAD 方法。

HTTP1.1 新增了六种请求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

方法 描述
GET 获取资源
POST 传输实体主体
PUT 传输文件
DELETE 删除文件
HEAD 获取报文首部
OPTIONS 询问支持的方法
TRACE 追踪路径
CONNECT 要求用隧道协议连接代理
LINK 建立和资源之间的联系
UNLINKE 断开连接关系

# 状态码

# 1xx

信息响应,表示接受的请求正在处理

  • 100 临时响应
  • 101 指示服务器正在切换的协议

# 2xx

成功响应,请求被正常处理

  • 200 OK 请求已正常处理
  • 201 Create 请求成功,并创建了一个新的资源
  • 204 No Content 请求处理成功,但是没有任何资源可以返回给客户端
  • 206 Partial Content 是对某一部分的请求,使用场景为 HTTP 分块下载和断点续传当然,也要带上响应的响应头字段Content-Range

# 3xx

重定向,表明浏览器需要执行某些特殊的处理以正确的处理请求

  • 301 Moved Permanently 永久重定向 资源的 URL 以更新
  • 302 Found 临时性重定向,资源的 URL 临时换到其他位置
  • 304 Not Modified 协商缓存,资源未改变

# 4xx

客户端响应,客户端发生错误

  • 400 Bad Request 服务器无法理解客户端发送的请求
  • 401 Unattended 未通过验证信息
  • 403 Forbidden 禁止访问该资源
  • 404 Not Found 资源未找到
  • 405 Method Not Allowed 请求方法不允许
  • 406 Not Acceptable 资源无法满足客户端的条件
  • 408 Request Timeout 请求超时

# 5xx

服务端响应,服务器发生错误

  • 500 Internal Server Error 服务器内部发生未知错误
  • 501 Not Implemented 服务器不支持该请求方法且无法处理
  • 502 Bad Gateway 服务器正常,但是访问时出现错误
  • 503 Server Unavailable 服务器繁忙(停机或者维护)

# 缓存机制

HTTP 缓存分为两种:强缓存和协商缓存,

http-cache2.jpg

# 强缓存

不会像服务器发送请求,直接从浏览器缓存中读取资源。

强制缓存在缓存数据未失效的情况下(即 Cache-Control 的 max-age 没有过期或者 Expires 的缓存时间没有过期),那么就会直接使用浏览器的缓存数据,不会再向服务器发送任何请求。强制缓存生效时,http 状态码为 200。

  • Pragma:值为 no-cache 是,不使用缓存,更具新鲜度来使用缓存
  • Expires: Response Header 中过期时间,浏览器再次加载时,如果在这个过期时间内,则命中强缓存
  • Cache-Contorl:当值设为 max-age=300 时,则代表在这个请求正确返回时间(浏览器也会记录下来)的 5 分钟内再次加载资源,就会命中强缓存。

优先级依次递减 Pragma 优先级最高

# 协商缓存

强缓存失效或不存在的时候,向服务器发送请求,由服务器决定是否使用缓存。

  • Last-Modified/If-Modified-Since:即最后的修改时间,在浏览器第一次给服务器发送请求之后,服务区会在响应头中加上这个字段。

浏览器接受后,如果再次请求,会在将Last-Modified 字段,作为请求头中携带If-Modified-Since 字段的值发送给服务器。

服务器接受后会进行对比:

- 如果请求头中的这个值小于最后修改时间,说明是时候更新了。返回新的资源,跟常规的HTTP请求响应的流程一样。
- 否则返回304,告诉浏览器直接用缓存。
  • ETag/If-None-Match:由服务端给当前文件生成的唯一标识,服务器通过 Respones Header 把值传改浏览器。浏览器则会在下次请求时,将 ETag 的值作为If-None-Match 字段的内容,发送给浏览器进行对比。
    • 如果两者不一样,说明要更新了。返回新的资源,跟常规的 HTTP 请求响应的流程一样。
    • 否则返回 304,告诉浏览器直接用缓存。

总结流程

http_cache.png

先看强缓存,在看协商缓存,如果命中强缓存,则不执行协商缓存。

  • 强缓存
    • pragma
    • Exprires
    • Cache-contorl
  • 协商缓存
    • Last-Modified/If-Modified-Since
    • ETag-If-None-Match

未命中缓存,则重新从服务器请求更新资源,然后服务端返回资源和 200 状态码 若命中缓存,则直接从缓存中获取资源,返回 304,告诉浏览器直接从缓存获取资源

缓存参考文档

# 跨域

corss_domain.png

跨域的产生原因是浏览器的同源策略,也就是请求的地址必须与当前地址的协议、域名、端口一致。

常用的处理跨域的方法有三种:

  • jsonp
  • CORS
  • Server-Proxy

我经常用的是 CORS(跨域资源共享)后端设置一下就完事了。

简单介绍一下 CORS 吧,CORS 的请求分为两种,分别是:

  • 简单请求
  • 复杂请求

当请求方法是:HEAD、GET、POST 时,都属于简单请求,如果非以上三种请求方法,则属于复杂请求,比如 PUT、DELETE 请求,复杂请求发送时,需要先发送预检请求,询问服务器是否支持当前请求的域名和方法,如果服务器支持,则和简单请求一样发送即可,如果不支持,则触发报错。

还有关于请求头的一些设置和限制,更详细的可以看参考阮一峰-跨域资源共享 CORS 详解 (opens new window)

参考

# 参考

# WebSocket

说 webSockt 之前先从服务端推动开始说起。

在 webStockt 之前,如果前端想要实现一个试试刷新的功能,最多的方法是采用轮询的方式,也就是前端定时的去请求后端更新数据,比如使用 setInterval。

但是轮询也有一些缺点:客户端发起请求后,即便是在数据没有更新的时候也会请求,就造成了资源浪费。

与轮询相关的还有一种长轮询,于一般的轮询不同的是,他会在发出请求后,一直等待服务端有了数据变动时候在响应。

长轮询和普通轮询的不同是因为长轮询采取的是阻塞模型(一直打电话,没收到就不挂电话),也就是说,客户端发起连接后,如果没消息,就一直不返回 Response 给客户端。直到有消息才返回,返回完之后,客户端再次建立连接,周而复始。

这两种方式都是客户端发起的请求,假如服务端的数据并没有发生变化,客户端其实是没必要发生请求的,那可不可以由服务端发起请求,这样是不是就方便多了,当服务端的数据发生改变后,向客户端推送岂不美哉。

其实 webStockt 就是这样的,可以有服务端向客户端发送请求。

参考:

# UDP

上次更新: 2/5/2021, 4:04:11 PM