一、基础概念

URI

URI包含URL和URN（不是很明白这是什么，后面在看看）

  • URI（Uniform Resource Identifier，统一资源标识符）
  • URL（Uniform Resource Locator，统一资源定位符）
  • URN（Uniform Resource Name，统一资源名称）

请求和响应

  • 请求
  • 响应

二、HTTP方法

从上面的请求报文中能看到在第一行开头就是方法字段

  • GET：获取资源，目前使用最多的方法
  • HEAD：获取报文首部，和GET类似，只是不返回报文实体主体部分，多用于确认url的有效性以及资源更新的日期等（大概意思是只返回了请求资源的描述信息而不要内容）
  • POST：传输实体，主要用来传输数据，get主要用来获取资源，很多时候请求中包含了用户数据，当然也可以把数据都拼接到get的url中，但是这样会暴露用户信息，关于get和post后面还会详细说明
  • PUT：上传文件，该方法自身不带验证机制，任何人都可以上传文件，存在安全问题，一般不会去使用
  • PATCH:对资源进行部分修改，没见过
  • DELETE:和put的作用相反，删除文件，同样不带验证机制
  • OPTIONS：查询支持的方法，查询服务器接口支持的方法，以前写PHP的时候post类型的请求会先发起一个options然后才进行post的真正请求
  • CONNECT:要求在与代理服务器进行通信时建立隧道
  • TRACE:追踪路径

三、HTTP状态码

  • 1XX：信息性状态码，接受请求正在处理
    • 100 Continue：一切正常，客户端可以继续发送请求或者忽略这个响应
  • 2XX：成功，请求正常处理完毕
    • 200 OK
    • 204 No Content :请求已经处理成功，但返回的响应报文不包含实体的主体部分（字面意思，没有返回内容），有的请求只是需要像服务器发送一个信息而不需要服务器返回数据。
    • 206 Partial Content:客户端进行了范围请求，而服务器返回了对应内容。
  • 3XX : 重定向
    • 301 Moved Permanently：永久性重定向
    • 302 Found：临时性重定向
    • 303 See Other : 相比302，303明确指出客户端应该使用get方法（据说大多数的浏览器在301和302下都会把post改成get，而http协议规定他俩是不能改请求方法的）
    • 304 Not Modified : 如果请求报文首部包含一些条件（If-Match,If-Modified-Since等），如果不满足条件，则服务器返回304（==这个好像是有关缓存策略的，后面应该会有详细的说明==）
    • 307 Temporary Redirect : 临时重定向，与302类似，要求浏览器不要把post改为get
  • 4XX：客户端错误
    • 400 Bad Request：请求报文中存在语法错误（经常是请求方法不对post和get没和接口对应好）
    • 401 Unauthorized：缺乏身份认证信息或者认证失败
    • 403 Forbidden：身份认证成功了，但是对资源没有访问的权限
    • 404 Not Found
  • 5XX：服务器错误
    • 500 Internal Server Error：这个可能就是服务器上对应的程序出错了
    • 503 Service Unavailable：服务器宕机，一般是暂时性的，不知道程序怎么判断是不是暂时性的

四、具体应用

  • 连接管理
    • 长连接和短连接
      • 长连接就是一次连接里面可以进行多次的http通信，在http1.1版本开始默认都是长连接，如果要断开则有客户端或者服务器中的一方发出Connectioin : close;
      • 短连接就没什么好说的，基本是历史的尘埃了，在1.1以前如果需要使用长连接要标明Connection：Keep-Alive
    • 流水线：默认情况下请求是要按顺序来的，上一个请求得到响应后新的请求才能被发出去，但考虑到现实情况下的网络延迟和带宽限制，这样效率可能会很低，流水线是指在同一个长链接中发出连续的请求而不用等待响应返回
  • Cookie：
    为了让http协议尽可能的简单，他本身是没有状态的，1.1引入Cookie来保存状态信息。Cookie是服务器发送到客户端的部分保存在浏览器中的数据，后续的每次请求中都会带上Cookie数据，这样服务器和客户端之间实现了一对一，不然只有客户端知道服务器，而服务器不知道请求来自哪个客户端，Cookie解决这个问题的同时也导致请求消耗资源增多
    • 用途：会话管理（登录状态、购物车）、个性化设置、浏览器行为跟踪
    • 创建过程：服务器发送的响应报文中包含Set-Cookie字段，客户端得到响应报文后将Cookie内容保存到浏览器中，之后客户端再对这个服务器发起请求的时候就会把Cookie数据带上
    • 生命周期：会话期cookie在浏览器关闭后就被删除，而设置了expires之后（有时候登录一个网站时会问你要不要记住登录信息）cookie会被写入硬盘
    • JavaScript：通document.cookie属性可以在js中创建cookie和访问非HttpOnly标记的cookie
    • HttpOnly：标记之后可以避免被通过js脚本的方式来窃取cookie信息，能一定程度上提高安全性
    • Secure：标记Secure之后cookie信息只能通过HTTPS加密传输（反向来看就是走http协议的网站不能用这个属性），且即使加密之后也是不能保证信息安全的，总的来说敏感信息就不应该被放到cookie里面
    • session：除了将用户信息通过cookie存在客户端以外，还可以利用session存到服务器端，比如用户登录完后就把信息存到redis里面，然后把key放到cookie中返回给客户端，之后的通信都只要传递这个key就行了，服务器拿到key就能从Redis里面找到对应的内容；这里要注意session ID的安全性，可以通过经常更新或者重新验证的方式来提高安全性
    • 浏览器禁用cookie：这个时候就不能用cookie了，只能通过上面说的session的方式，session的ID也不能通过cookie来传递了，使用URL重写技术，将ID作为URL参数进行传递
    • cookie和session的选择：
      • cookie只能存储ASCII码字符串，而session是可以存储任何类型的数据的（可以存储到任何的数据库或者内存中）
      • cookie存在客户端容易被查看，解决方式是进行加密，然后到服务器端进行解密
      • 其实总的来说session在各个方面都是要优于cookie的，但是必须要考虑一个现实的问题，cookie占用的是用户的存储空间，而session占用服务器存储，对大型网站来说这个开销将非常大，所以要根据内容的敏感性来决定存储方式
  • 缓存：
    • 优点是能缓解服务器压力，而且一般缓存可能放到客户端或者分布式的缓存服务器，物理位置更近读取更快
    • 实现方式：
      • 代理服务器进行缓存
      • 客户端进行缓存
    • Cache-Control:控制缓存
      • Cache-Control:no-store 完全禁止缓存
      • no-cache:强制确认缓存，让缓存服务器必须先向服务器确认资源的有效性
      • private和public：私有和公有，私有内容只能被单独的用户使用，一般存储在用户浏览器；而公有就是大家都能使用，一般存储到缓存服务器
      • 缓存过期机制：请求中加入一个max-age指令，告诉缓存服务器验证缓存存在的时间是否小于这个时间，如果成了那就能接受该缓存内容；如果是响应报文中的max-age则表示缓存在缓存服务器中保存的时间，客户端收到这个参数可以自己去判断是否接受这个缓存数据
    • 缓存的验证机制：资源用一个唯一标识ETag来标记，缓存服务器向服务器验证缓存内容是否最新的时候就对比两个资源的ETag就行，这里如果两个资源的ETag是匹配的，服务器返回304 Not Modified就是前面讲状态码中说到的报文条件验证满足
  • 内容编码：将返回数据的实体进行压缩再传输，浏览器发送的Accept-Encoding首部其中包含了他所支持的压缩算法以及各自的优先级，常见的内容编码：gzip、compress、deflate、identity
  • 范围请求：如果出现网络中断，而服务器值发送了另一部分的数据，范围请求可以使得客户端只请求没有得到的那部分数据（估计这个是断点续传的底层实现原理）
    • range：在请求报文中添加Range指定请求的范围，请求成功服务器会返回206 Partial Content，不支持范围请求时服务器返回200
  • 虚拟主机：HTTP/1.1使用虚拟主机可以使得一台服务器拥有多个域名，在逻辑上可以看成多个服务器
  • 通信数据转发
    • 代理：主要目的–缓存、负载均衡、访问控制、日志记录
    • 网关：网关服务器是将HTTP转化为其他协议进行通信，从而请求其它非HTTP服务器的服务
    • 隧道：使用SSL等加密手段在客户端和服务器之间建立一条安全的通信线路

HTTP/2.0

  • 1.X的缺陷
    • 对并发没有好的处理方案（通过使用多个连接来实现）
    • 不会压缩请求和响应的首部，浪费流量降低效率
    • 不支持有效的资源优先级，致使地城TCP链接的利用率低下
  • 二进制分帧层：2.0将报文分成headers帧和DATA帧，他们都是二进制格式
  • 服务端推送：请求一个资源是，会把相关的资源一起发送给客户端（js、css之类的资源）
  • 首部压缩：1.1的时候首部含有大量信息，且每次都要重新发送；2.0要求客户端和服务器同时维护一个包含之前见过的首部字段表，避免重复传输，同时还使用Huffman编码对首部字段进行压缩