一、特点

• 简单快速：客户端与服务端通信，只需要传送请求方式和请求路径即可；HTTP协议简单，因此HTTP服务器的程序规模小，所以通信速度快。

• 灵活：HTTP传输的任意类型，任意语言可使用。传输类型由Content-Type标记。

• 无连接：指客户机（Web浏览器）和服务器之间不需要建立持久的连接。

  • 优点：可以节省传输时间。

• 无状态：无状态指协议对于事务处理没有任何记忆能力

  • 缺点：如需有记忆，需要传数据，导致每次连接传输数据可能较大

  • 有点：不需要传输数据时候，应答速度很快

• 默认端口：80

二、HTTP之URI和URL

• URI是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。

  俗话解释，URI就相当于人身份证号，通过这个身份证号就能确定这个人是谁了

• URL是uniform resource locator，统一资源定位器，它是一种具体的URI

  俗话解释，URL就相当于--> 地球://中国/xx省/xx市/xx区/xx小区/10086号房间/张三，URL不光精确到某个人还精确到某个人在上面地方

三、HTTP之请求消息Request

HTTP之请求消息

• 请求行（request line）、请求头部（header）、空行和请求数据四个部分组成

• GET的request

  
  
  GET的request

• POST的request

  
  
  POST的request

四、HTTP之请求消息Response

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

HTTP之请求消息Response

五、HTTP之状态码

• 状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:

    1xx：指示信息--表示请求已接收，继续处理
    2xx：成功--表示请求已被成功接收、理解、接受
    3xx：重定向--要完成请求必须进行更进一步的操作
    4xx：客户端错误--请求有语法错误或请求无法实现
    5xx：服务器端错误--服务器未能实现合法的请求

• 常见状态码：

    200 OK                        //客户端请求成功
    400 Bad Request               //客户端请求有语法错误，不能被服务器所理解
    401 Unauthorized              //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 
    403 Forbidden                 //服务器收到请求，但是拒绝提供服务
    404 Not Found                 //请求资源不存在，eg：输入了错误的URL
    500 Internal Server Error     //服务器发生不可预期的错误
    503 Server Unavailable        //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

六、HTTP请求方法

GET     请求指定的页面信息，并返回实体主体。
HEAD     类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
POST     向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT     从客户端向服务器传送的数据取代指定的文档的内容。
DELETE      请求服务器删除指定的页面。
CONNECT     HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS     允许客户端查看服务器的性能。
TRACE     回显服务器收到的请求，主要用于测试或诊断。

七、不同版本的HTTP优缺点

• HTTP/1.0：

  • 每个TCP连接只能发送一次请求，因为每次TCP连接三次握手很好时间。

  • 解决方案：在请求头上添加 Connection:keep-alive ，服务器同样回应这个字段。一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接

    这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

• HTTP/1.1：

  • 默认不关闭TCP，解决了1.0的问题。客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。目前同一个域名，最多只能建立6个持久连接

  • 添加管道机制，就是同一个TCP连接，允许同事发送多个请求。管道机制则是允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。

    • 缺点：前一个发生阻塞，后面的请求只能排队，这称为：“队头阻塞”

  • Content-Length：一个TCP连接现在可以传送多个回应，势必就要有一种机制，区分数据包是属于哪一个回应的。这就是Content-length字段的作用，声明本次回应的数据长度。

  • 分块传输：Content-length有前提条件，服务器得知道数据长度，如果数据很多，服务器得获取数据长度后再操作，很耗时，效率低，所以采用流模式(stream)取代缓存模式(buffer)

    • 因此，1.1版规定可以不使用Content-Length字段，而使用"分块传输编码"（chunked transfer encoding）。只要请求或回应的头信息有Transfer-Encoding字段，就表明回应将由数量未定的数据块组成。

  Transfer-Encoding: chunked

• 每个非空的数据块之前，会有一个16进制的数值，表示这个块的长度。最后是一个大小为0的块，就表示本次回应的数据发送完了。下面是一个例子。

HTTP/1.1 200 OK
            Content-Type: text/plain
            Transfer-Encoding: chunked
            ​
            25
            This is the data in the first chunk
            ​
            1C
            and this is the second one
            ​
            3
            con
            ​
            8
            sequence
            ​
            0

• HTTP/2：

  • 二进制协议：HTTP/1.1 版的头信息肯定是文本（ASCII编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧

  • 多工：HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了"队头堵塞"。

  • 数据流：HTTP/2 将请求或响应的所有数据包，称之为数据流。每个数据流都有唯一的ID，用于区分属于哪个数据流。request的id为基数，response 为偶数

    • HTTP/1.1 取消请求，需要关闭TCP，而HTTP/2，直接取消数据流，TCP，没有关闭

  • 头信息压缩：多次请求，携带的字段有很多重读的，携带很浪费贷款。HTTP/2引入了头信息，信息压缩机制

    1. 头信息压缩发送

    2. 客户端和服务端同时维护一张头信息表，将所有的字段存储下来，生成索引，后期之后发送索引就行了，这样就能提速

  • 服务端推送：未经服务器允许直接向客户端推送数据。比如：静态资源，以前客户端需要一个从服务端请求一个，HTTP/2 ，预期到客户端需要哪些资源，主动推送

八、HTTP工作原理

• HTTP工作过程

  1. DNS域名解析

  2. 封装HTTP请求数据包

  3. 封装成TCP包，建立TCP连接（TCP的三次握手）

  4. 客户机发送请求命令

  5. 服务器响应

  6. 关闭TCP连接（如果Connection:keep-alive，入后续还有请求，TCP不关闭，否则直接）

• 建立TCP/IP连接（三次握手）

  
  
  建立TCP/IP连接（三次握手）

• 建立连接协议（三次握手）：

  1. 第一次握手：客户端发送syn包（syn=x）的数据包到服务器，并进入SYN_SEND状态，等待服务器确认；

  2. 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

  3. 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

     握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP连接都将被一直保持下去。

• 连接终止协议（四次握手）

image.png

• 由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

  1. 第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。

  2. 第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号， SYN 和 FIN 都有seq序号）。

  3. 第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。

  4. 第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

参考：
TCP三次握手、四次挥手及状态转换详解
HTTP详解(1)-工作原理