1. 简介
定义：超文本传输协议，属于应用层
作用：规定了应用进程间通信的准则
特点： 传输效率高，可靠性高，兼容性好，灵活性高
2. 工作方式
-
http协议采用请求/响应的工作方式 -
具体工作流程如下：
3. Http报文详解
-
HTTP在应用层交互数据的方式 = 报文 -
HTTP的报文分为请求报文 & 响应报文
分别用于 发送请求 & 响应请求
3.1 请求报文
3.1.1报文结构
-
HTTP请求报文由请求行、请求头、请求体组成
报文结构
具体介绍
- 请求行（request line）：声明请求方法、主机域名、资源路径、协议版本
- 请求头（header）：声明 客户端、服务器、报文的部分信息
- 请求体（request body）：存放 需发送的数据信息
3.1.2 结构详细介绍
组成1：请求行
- 作用 声明请求方法、主机域名、资源路径、协议版本
- 结构 请求行的组成 = 请求方法 + 请求路径 + 协议版本
注：空格不能省
-
组成介绍
此处特意说明GET、POST方法的区别
- 示例
设：请求报文采用GET方法、URL地址 = www.walle.com/walle/index.html ;HTTP1.1版本
则请求行是：GET/walle/index.html HTTP/1.1
组成2：请求头
- 作用：声明 客户端、服务器/报文的部分信息
- 使用方式：采用 “header（字段名）：value（值）”的方式
1.请求和响应报文的通用Header
2.常见请求的Header
- 示例：
(URL地址：www.walle.com/walle/index.html）
Host：www.walle.com(表示主机域名)
User-Agent ：Mozilla/5.0(表示用户代理是使用firefox浏览器)
组成3：请求体
- 作用：存放 需发送给服务器的数据信息
可选部分：如
GET请求就没有请求数据
-
使用方式：共3种
至此，关于请求报文的请求行，请求头，请求体讲解完毕
3.2 HTTP响应报文
3.2.1报文结构
-HTTP的响应报文包括：状态行、响应头 & 响应体
报文结构
具体介绍
- 状态行：声明协议版本、状态码、状态码描述
- 响应头：声明 客户端、服务器、报文的部分信息
- 响应体：存放 需发送的数据信息
其中，响应头、响应体与请求报文的请求头、请求体类似。这2种报文的最大的不同在于 状态行&请求行
3.2.2结构详细介绍
组成1：状态行
- 作用：声明协议版本，状态码，状态描述
- 组成：状态行有协议版本、状态码&状态信息组成
注：其中空格不能省！！！
-
具体介绍
- 状态行 示例：
HTTP/1.1 202 Accepted（可接受）、HTTP/1.1 404 Not Found（找不到）
组成2： 响应头
- 作用：声明客户端、服务器/报文的部分信息
- 使用方式：采用“header（字段名）：value（值）”的方式
- 常用请求头
1.请求和响应报文的通用Header
2.常见响应Header
组成3：响应体
- 作用：存放需返回给客户端的数据信息
-
使用方式：和请求体是一致的，同样分为：任意类型的数据交换格式、键值对形式和分部分形式
3.2.3 响应报文总结
3.3 总结
下面，简单总结两种报文结构
请求报文
响应报文
4. 额外知识
下面讲解一些关于HTTP的额外知识：
-
HTTP1.1与HTTP1.0的区别 -
HTTP与HTTPS的区别 -
HTTP处理长连接的方式
4.1 HTTP1.1与HTTP1.0的区别
HTTP1.1比HTTP1.0多了一下优点：
- 引入持久连接，即 在同一个
TCP的连接中可传送多个HTTP请求头&响应 - 多个请求 & 响应可同时进行、可重叠
- 引入更多的请求头 & 响应头
如 与身份认证、状态管理 &
Cache缓存等机制相关的，HTTP1.0无host字段
4.2 HTTP与HTTPS的区别
4.3 HTTP处理长连接的方式
5 TCP的三次握手和四次挥手
1.比较重要的字段有：
（1）序号（sequence number）Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记
（2）确认号（acknowledgement number）：Ack序号，占32位，只有ACK标志位位1时，确认序号字段才有效，Ack=Seq+1.
（3）标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN具体含义如下：
URG:紧急指针有效
ACK:确认序号有效
PSH:接收方应该尽快将这个报文交给应用层
RST:重置连接
SYN:发起一个新连接
FIN:释放一个连接
2.三次握手
所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的，以下为客户端主动发起连接的图解
]
握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：
（1）首先客户端向服务器端发送一段TCP报文，其中：
标记位为SYN，表示“请求建立新连接”;
序号为Seq=X（X一般为1）；
随后客户端进入SYN-SENT阶段。
（2）服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；
序号为Seq=y；
确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；随后服务器端进入SYN-RCVD阶段。
（3）客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；
序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；
确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；
随后客户端进入ESTABLISHED阶段。
服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。
3.“四次挥手”的详解
所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。以下为客户端主动发起释放连接的图解：
（1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：
- 标记位为FIN，表示“请求释放连接“；
- 序号为Seq=U；
- 随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。
注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。
4.为什么“握手”是三次，“挥手”却要四次？
TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。
即SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。
TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。为何建立连接时一起传输，释放连接时却要分开传输？
- 建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。
- 释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。
所以是“三次握手”，“四次挥手”。
5.为什么客户端在TIME-WAIT阶段要等2MSL?
为的是确认服务器端是否收到客户端发出的ACK确认报文
当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；
如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；
否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。
所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因
