HTTP基础知识

网络基础

网络基础TCP/IP

TCP/IP 协议族

把互联网相关联的协议集合起来总称为 TCP/IP。

为了使设计更加自由，修改更加简单，我们按照功能分类，使其相互独立，TCP/IP 协议族按层次分为以下四种：

名称	作用
应用层	决定了向用户提供应用服务时通信的活动
传输层	对上层应用层提供网络连接中两台计算机之间的数据传输
网络层	处理网络上流动的数据包，在众多选项中选择一条传输路线
链路层	用来处理连接网络的硬件部分

TCP/IP 通信传输流

TCP/IP 通信传输流的过程：

数据从客户端的应用层向下传播，每经过一层都会被打上首部信息，直到链路层，将数据传输给服务器，再从服务器的链路层一层层上传，每经过一层都会把对应的首部信息消去，直到应用层接收到完整的数据。

以上把数据包装起来的做法叫封装。

IP、TCP、DNS

IP（Internet Protocol）

IP 协议位于网络层，负责传输数据。
（ IP 和 IP 地址不同，前者是一种协议的名称）

IP 地址和 MAC 地址

为了确保数据运输到对方，需要满足各类条件，而 IP 地址和 MAC 地址是两个重要的条件。

名称	区别
IP 地址	节点被分配到的地址，可变换
MAC 地址	网卡所属的固定地址，不可变换

IP 地址可以和 MAC 地址配对，在通讯过程中，常常需要中转，在中转中会利用下一站中转设备的 MAC 地址来搜索下一个中转目标， ARP 协议（Address Resolution Protocol）可以根据通信方的 IP 地址来反查出对应的 MAC 地址。

路由选择

在互联网的数据运输中，每一个中转站都只知道自己下一站应该向谁传输数据，所以无论是哪一台计算机、路由器都无法完全掌握数据运输的路线。

TCP协议

TCP协议位于传输层，为了更容易传送大数据把数据分割，并且能够确认最终数据是否送达到对方。

三次握手

握手中使用了TCP的标志—— SYN （synchronize 同步）和 ACK （acknowledgement 确认）

1. 发送端将标有 SYN 的数据包发给接收端。
2. 接收端收到之后，回传一个标有 SYN/ACK 标志的数据包，传达确认信息。
3. 发送端再回传一个带有 ACK 标志的数据包，代表“握手”结束了。

四次握手（中断连接）

所谓四次握手，是由TCP的半关闭造成的

1. 第一次握手：发送端调用close（这里我们称发送close请求的一方为发送端），这时，发送端发送一个FIN分节表明数据传输完毕，可以进行中断连接操作了
2. 第二次握手：当接收端收到FIN分节后，执行被动关闭，接收端调用close，向发送端发送带有ACK的FIN分节
3. 第三次握手：发送端接收到ACK与FIN后进入等待连接终止状态，向接收端发送ACK
4. 第四次握手：接收端接收到ACK，连接成功终止

当一方接收到FIN分节，就意味着本次连接，接收端不会再接收到其他新信息
半关闭指的是在第二次握手与第三次握手之间可能从执行被动关闭一端到执行主动关闭一端流动数据

DNS 服务

提供通过域名查找IP地址，或逆向从IP地址反查域名的服务。
域名简单来说就是这样的东西：https://cn.bing.com
虽然我们人类比较喜欢用域名来记忆，但是电脑更擅长处理数字（IP 地址），所以催生了DNS服务。

各个协议和HTTP的关系

URI和URL

URI 代表的是某一互联网资源，而 URL 是资源的地址。可见 URL 是 URI 的子集。

这个也是一个URL:https://hhhfccz.github.io/hhhfccz.github.io/2020/01/18/python的几个常用模块/
这个不是URL，并不知道所需资源的路径:https://hhhfccz.github.io
简单来说，URI代表名字，URL代表位置

虚拟主机

即使物理增面只有一台服务器，但只要使用虚拟主机的功能，则可以假想已经拥有多台服务器。

也就是说在一台硬件设备上运行多个相互独立服务器，称之为虚拟主机。值得注意的是，部署在同一台服务器上的两个域名具有相同的IP地址，这也就是为什么需要在Host首部中完整指明主机名或域名的URI。

代理、网关、隧道

代理是一种有转发功能的应用程序，扮演位于服务器和客户端“中间人”的角色。分为缓存代理和透明代理。

网关是转发其他服务器通信数据的服务器，接收客户端发送来的请求时，他就像自己拥有资源的源服务器一样对请求进行处理。能够使通信路线上的服务器提供非HTTP协议服务。

隧道是在相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的程序应用。

缓存

缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减少对源服务器的访问，因此也就节省了通信流量和通信时间。

HTTP内容

关于HTTP协议的几个规定

1. HTTP协议用于客户端和服务器端之间的通信。请求访问文本或图像资源的一端称为客户端，而提供资源响应的一段称为服务器端。HTTP可以分辨哪端是客户端，哪段是服务器端。

2. HTTP协议规定，请求从客户端发出，最后服务器端响应该请求并返回。

3. HTTP是不保存状态的协议。HTTP协议本身不具备保存之前发送过的请求和响应的功能。

虽然HTTP协议是不保存状态，但是我们经常遇到需要保存状态的情况，所以引入了Cookie技术，下文中会提到该技术。

4. HTTP协议使用 URI 定位资源。

HTTP方法

名称	作用	适用HTTP版本
GET	用来请求访问已被 URI 识别的资源	1.0、1.1
POST	用来传输实体的主体	1.0、1.1
PUT	用来传输文件	1.0、1.1
HEAD	和GET方法一样，只是不返回报文的主体部分，用于确认 URI 的有效性和资源更新的日期时间等	1.0、1.1
DELETE	用来删除文件	1.0、1.1
OPTIONS	用来查询针对 URI 指定的资源支持方法	1.1
TRACE	追踪路径，让Web服务器端将之前请求通信返回给客户端	1.1
CONNECT	要求用隧道协议连接代理	1.1

Cookie的状态管理

在日常使用中，一些需要登陆的网页显然是需要进行状态保存的，然而HTTP是不保存状态的协议，所以使用Cookie来进行状态管理。

• 首先在没有Cookie信息状态下的请求

客户端对服务器端发出请求，服务器生成Cookie，记住向谁发送，在响应中添加Cookie后返回响应。

1. 请求报文：

GET /reader/ HTTP/1.1
Host : hackr.jp
*首部字段中没有Cookie的信息

2. 响应报文（服务器端生成Cookie）：

Http/1.1 200 OK
Date : Thu, 12 jul 2012 07:12:20 GMT
Server : Apache
<Set-Cookie : sid=13420777140226724; path=/; expires=Wed,10-Oct-12 0.:12:20 GMT>
…………

• 第二次以后（存有Cookie信息状态）的请求

客户端在发送请求的时候会自动添加Cookie，而服务器则根据这个Cookie来认出客户端。

3. 请求报文（自动发送保存着的Cookie）：

GET /image/ HTTP/1.1
Host:hackr.jp
Cookie : 13420777140226724

HTTP报文

报文的结构

用于HTTP协议交互的信息称之为HTTP报文。
TTP报文大致可分为报文首部和报文主体两块，两者由最初出现的空行（CR+LF）来划分。通常，并不一定要有报文主体。

报文的结构
报文首部
空行（CR+LF）
报文主题

其中报文首部一般分为：

1. 请求行（请求报文）
2. 状态行（响应报文）
3. 首部字段
4. 其他

HTTP首部

状态行

状态行的职责是当用户端发送请求时，描述返回的请求结果。

	类别	原因短语
1XX	Informational（信息性状态码）	接受的请求正在处理
2XX	Success（成功状态码）	接受的请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操以完成请求
4XX	Client Error（客户端错误状态码	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

2XX 成功

名称	作用
200 OK	表示从客户端发来的请求在服务器端被正常处理了
204 NO Content	表示请求已经成功处理，但在返回的响应中不含实体的主体部分
206 Partial Content	表示服务器端成功处理了范围请求

3XX 重定向

名称	作用
301 Moved Permanently	永久性重定向
302 Found	临时重定向
303 See Other	表示由于请求对应的资源存在另一个URI，应使用GET方法定向获得请求的资源
304 Not Modified	服务器允许访问资源，但是发生请求条件未满足的情况
307 Temporary Redirect	临时重定向（不会从POST变成GET）

4XX 客户端错误

名称	作用
400 Bad Request	请求报文中有语法错误
401 Unauthorized	表示发送的请求需要通过HTTP认证
403 Forbidden	对资源的访问被服务器拒绝了
404 Not Found	表明服务器上无法找到请求的资源

5XX 服务器错误

名称	作用
500 Internal Server Error	服务器执行请求时出错
503 Service Unavailable	表明服务器无法处理请求（超负荷运载或者停机维护之类的）

首部字段

见我的另外一篇博客：HTTP首部字段——《HTTP图解》笔记

为什么是HTTPS？

与SSL（Secure Socket Layer，安全套接层）组合使用的HTTP就被称为HTTPS（HTTP Secure，超文本传输安全协议）或HTTP over Secure。

简单的来说，HTTP+加密+认证+完整性保护=HTTPS

HTTP的缺点

HTTP有相当优秀和方便的一面，但是它也有不可忽视的缺点，就是它的安全问题：

1. 通信使用明文，内容可能会被窃听。
   TCP/IP是可能被窃听的网络。可以使用抓包或嗅探器工具对网上流动的数据包进行解析。

加密处理防止窃听：

1. 通信的加密：

通过SSL和TLS（Transport Layer Security，安全传输层协议）的组合使用，加密HTTP的通信内容。

2. 内容的加密：

由于HTTP协议本身没有加密机制，那么就对HTTP协议传输的内容本身加密。即把HTTP报文里所含的内容进行加密处理。

但是由于这种方式不同于SSL和TLS的对通信本身加密， 报文本身的内容仍然有可能被篡改。

2. 不验证通信方的身份，因此有可能遭遇伪装。

查明证书来确定身份：

证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。

3. 无法证明报文的完整性，所以有可能已遭篡改。

常用的是MD5和SHA-1等散列值校验的方法，以及用来确认文件的数字签名方法。（PGP和MD5本身如果被改写的话，用户是没办法意识到的，所以依靠上述方法也没办法百分之百确认结果正确）

加密

HTTP采用的是共享密钥加密和公开密钥加密并用的混合加密机制。
使用公开密钥加密方式安全的交换在稍后的共享密钥加密中需要使用的密钥，确保交换的密钥是安全的前提下，使用共享密钥加密方式进行通信。

共享密钥加密

加密和解密同用一个密钥的方式称之为共享密钥加密（Common key crypto system），也叫做对称密钥加密。

因为使用同一个密钥加密，那么就必须要把密钥发送给对方，怎么安全的发送成了棘手的问题。如果被监听到密钥，那么也就失去了加密的意义，但是不发送密钥对方又无法解密；话说回来，密钥如果能够安全发送的话，那数据应该也可以安全到达，那密钥的存在又无意义了。

使用两把密钥的公开密钥加密

公开密钥加密使用一对非对称的密钥，一把叫做私有密钥，一把叫做公开密钥。
发送密文的一方使用对方的公开密钥进行加密处理，对方接收到被加密的信息后，再使用自己的私有密钥进行解密。

公开密钥加密与共享密钥加密相比，其处理速度更慢。

并且，公开密钥加密还是存在一些问题的，那就是无法证明公开密钥本身就是货真价实的公开密钥。为了解决这个问题，可以使用数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

除此之外，还有用以证明组织真实性的EV SSL证书、用以确认客户端的客户端证书、由自认证机构颁发的自签名证书。

认证

计算机本身无法判断坐在显示器前使用者的身份，所以为了确认使用者是否有访问系统的权限，就需要核对“只有本人才会知道的信息”、“只有本人才会有的信息”。

1. BASIC认证
2. DIGEST认证
3. SSL客户端认证
4. 基于表单认证

认证部分过于复杂，再次不再展开讲述。