Chendi Wu

Appearance

概念 ​

  • http（HyperText Transfer Protocol），超文本传输协议，是互联网上应用最广泛的一种网络协议，以ASCII码传输，建立在TCP/IP协议之上的应用层规范。传输文字、图片、音频、视频等超文本数据的约定和规范（或规则）来进行通信。
  • http也可以说成是一种客户端和服务器端请求和应答的标准(TCP)，通过使用客户端或工具发起一个到应答服务器上指定端口(如Tomcat的8080或imx的1099等)的http请求，或者反过来，服务器给客户端发送一个回应，在客户端和应答服务器端在多个中间H如代理网关或者隧道。

特点 ​

  • 灵活可扩展：一个是语法上只规定了基本格式，空格分隔单词，换行分隔字段等。另外一个就是传输形式上不仅可以传输文本，还可以传输图片，视频等任意数据
  • 请求-应答模式：通常而言，就是一方发送消息，另外一方要接受消息（或响应等），如后端通信
  • 可靠传输：HTTP是建立在TCP/IP协议之上的应用层规范
  • 无状态

缺点 ​

  • 无状态：有时需要保存信息，如购物，需要保留下顾客信息等等；另外一方面，无状态也会减少网络开销，比如类似直播行业这样子等，这个还是分场景来说。
  • 明文传输：即协议里的报文(主要指的是头部)不使用二进制数据，而是文本形式。这让HTTP的报文信息暴露给了外界，给攻击者带来了便利。
  • 队头阻塞：当http开启长连接时，共用一个TCP连接，当某个请求时间过长时，其他的请求只能处于阻塞状态，这就是队头阻塞问题。

http请求过程 ​

image2.jpg

URI、URL、URN ​

HTTP三次握手 ​

. 首先需要理解一个概念：    user  http request          ---------------- TCP connection ---------------------->  服务器    在客户端与服务端进行一个http请求的发送和返回的过程当中，需要创建一个叫TCP connection。    因为http不存在“连接”这个概念的。http只有“请求”和“响应”这个概念。    请求和响应都是数据包，它们之间需要经过一个传输的通道，就是TCP connection。这个TCP连接，可以一直保持在那边，    HTTP请求是在TCP连接基础上发送的。    在一个TCP连接上面，是可以发送多个HTTP请求的。    在不同的版本里面，这个模式是不一样的:        在HTTP/1.0里面，一个http请求发送到服务器，服务器接收请求并处理，然后返回响应，之后，这个TCP连接就会关闭。        在HTTP/1.1里面，一个TCP连接可以声明为长连接。使这个TCP连接保持在那边的。意思是第一个请求发送并返回完成之后，        第二个请求还可以在这个tcp连接上进行发送。        这样的好处是：TCP连接在创建的过程中是有三次握手这个消耗的，三次握手就代表有三次网络传输。只有创建了TCP连接，        才能去发送http请求。如果把tcp连接保持在那边，这时候，新的http请求就没有了三次握手的开销。        在HTTP2里面，还有一个好处，tcp连接上的http请求是可以并发的。        同一个用户对同一个服务器发起网络请求的时候，它只需要一个tcp连接。        具体含义会在tcp长连接那节课中讲解。    在这里，只需要明白 tcp连接与http请求的关系。     . 三次握手时序图    client                           server      ----------SYN=1，Seq=X ----------->        服务端接收到创建连接的请求之后，会开启一个端口，返回给客户端，      <------ SYN=1，ACK=X+1，Seq=Y -----        返回的ACK等于客户端的Seq+1，并且会返回一个服务端自己的Seq=Y      ----------ACK=1，Seq=Z ----------->        客户端收到服务端的返回，知道已经允许创建tcp连接了，再去发送ACK等于服务端的Seq+1,                                                 并且发送客户端自己的Seq等于一个新的数字。      SYN是一个标志位，代表它是一个创建请求的数据包。      Seq一般来说初始默认等于1      以上就是tcp连接创建的一个过程。为什么要经过三次握手呢？      .为了防止服务端开启一些无用的服务。规避网络传输延迟而导致的服务器开销问题。        因为我们知道，网络传输是有延时的。...

HTTP报文格式 ​

(a) 请求报文                                                (b) 响应报文 注意：HTTP的首行并不属于HTTP的headers。 它的首行和headers是有所区分的。   首行换行之后，都是HTTP的headers； HTTP的headers与主体之间，有一个完整的空行，来区分。 (a) 在请求报文中， .首行包括：    . HTTP的method，就是请求的方法，---用来定义对于资源的操作        HTTP的method的很多种，有GET,POST,PUT,DELETE，它们        有各自的语义，GET是获取，POST是创建，PUT是修改/更新，DELETE是删除        希望按照语义规范实现web服务。    . 路由    . HTTP协议版本   . headers包括：后面具体讲,这节主要讲HTTP的首行 (b)在响应报文中， . 首行包括：    . HTTP协议版本      . status code ---定义服务器对请求的处理结果        . 各区间的code有各自的语义        . 好的HTTP服务可以通过code判断结果    . status description

HTTP缓存的应用，不仅仅是max-age ​

HTTP协议中主要涉及缓存的Header就是Cache-Control和Expires（已渐渐被淘汰） Cache-Control并不是只有指定max-age过期时间这么一种使用方式， 事实上这只是Cache-Control最基础的用法，我们来看看Cache-Control有哪些可以设置的值：        1. private、public和no-cache用来指定客户端和代理缓存的可缓存性        2. max-age和s-maxage用来指定客户端和代理缓存的缓存时间        3. must-revalidate和proxy-revalidate用来指定缓存过期后是否必须验证才能使用        4. no-store用来表明任何地方都不应该缓存内容        5. 其他一些不常用的设置

首先大家必须要弄清楚的一点是，缓存不仅仅只有浏览器可以缓存，互联网中存在着各式各样的代理缓存。    HTTP仅仅是一个应用层的协议，在数据传输的过程中逃不开各种中继的设备，而本身HTTP是明文传输的，    所以每个中继设备都可以解析HTTP数据包中的内容，所以如果某个中继设备想，他就可以成为一个代理缓存。    当然HTTP的代理缓存更多还是服务假设者自己做的，但是本质上是一个意思。    代理缓存最明显的优势就是：客户端缓存是一对一的，但是代理缓存是一对多的。    对于同一个源服务器可以存在不同的代理（有些CDN就近获取资源就有用到缓存的知识）。    如果这些代理都开启来缓存功能，那么用户一在第一次访问数据的时候，代理通过源服务器获取资源返回给用户，并同时缓存来这个请求，    这时候用户二再次来请求的时候，就不需要经过源服务器，直接从代理缓存读取就可以来。    所以对于耗时操作而且数据修改不频繁的数据，开启代理缓存对于性能的提升是非常明显的，哪怕你每次缓存的时间只有5秒，对于并发量很高请求带来的性能提升也是不可估量的。    当然这个操作源服务器通过自己设置缓存也可以实现，但是代理缓存的好处是，如果你的代理离用户足够近，那么减少的延时也是非常明显的。    比如如果你的服务器在美国纽约，如果你不在国内设置一个代理缓存，那么所有数据都要跨国半个地球再绕回来，而有代理缓存的情况就不一样来。    那么说回来，怎么控制代理缓存的使用？还是靠HTTP协议，在HTTP协议的发展历史中，已经有非常多的实践让协议进行修改和发展，    所以目前的缓存方案可以说已经比较完善了。一般来说，代理缓存服务器都会对最新的HTTP协议的标准进行实现，并且适当兼容老得标准，    一般不会出现一些魔改实现。所以只要你对HTTP协议的缓存方案充分了解，那么你就可以很好得使用代理服务器的缓存了。    最主要的你需要知道：    如何控制代理服务是否缓存或者缓存多少时间    代理缓存时候可以提供过期缓存的内容    如何进行缓存验证    知道这些之后，配合一个好用的代理缓存，相信能对你的服务带来很大的性能提升。    以上的内容并不是特别好理解，如果大家有兴趣可以去看一下我的新课HTTP协议，里面对HTTP协议的原理，不同HEADER的作用和实践、Nginx部署代理和缓存、HTTPS、HTTP2都有使用例展示进行深入的讲解。    最后，HTTP协议是所有相关开发都必须要牢牢掌握的基础，仅仅知道POST、GET、Content-Type并不算理解HTTP协议，