【图解HTTP】学习笔记

版权声明：本文为博主原创文章，转载请注明出处-- https://blog.csdn.net/qq_38790716/article/details/90241605

1. 与HTTP关系密切的协议：IP、TCP、DNS

(1) $IP$

• 位于网络层，作用是把各种数据包传送给对方
• $IP$地址指明了节点被分配的地址， $MAC$地址是指网卡所属的固定地址， $IP$地址可以和 $MAC$地址进行配对
• 使用 $ARP$协议凭借 $MAC$地址进行通信： $ARP$协议用以解析地址，根据通信方的 $IP$地址就可以反查出对应的 $MAC$地址

(2) $TCP$

• 位于传输层，提供可靠的字节流服务
• 使用三次握手确保数据能到达目标

(3) $DNS$

• 位于应用层，提供域名到 $IP$地址之间的解析服务，或逆向从 $IP$地址反查域名的服务

2. 浏览一个页面的步骤

• (1)客户端想要浏览 $http://hackr.jp/xss/Web$页面，向 $DNS$请求解析，得到 $hackr.jp$对应的 $IP$地址是 $20X.189.105.112$
• (2)得到IP地址即得到服务器地址，那么接下来向服务器请求资源；此时用到 $HTTP$协议：生成针对目标 $Web$服务器的 $HTTP$请求报文
• (3)得到 $HTTP$请求报文后，到达传输层，使用 $TCP$协议：方便通信，将 $HTTP$请求报文按序号分割成多个报文段，将每个报文段可靠的传输给对方
• (4)接下来用到 $IP$协议：搜索对方的地址，一边中转一边传送(用到路由器)。到达服务器
• (5)收到请求，用到 $TCP$协议：从对方那里接收到报文段，按序号以原来的顺序重组请求报文
• (6)得到请求报文，使用 $HTTP$协议：对请求的内容进行处理
• (7)请求的处理结果也同样利用 $TCP/IP$通信协议向用户进行回传，称为响应

3. URL和URI

$URL$：同一资源定位符，例如 $http://hackr.jp/$就是 $URL$
$URI$：统一资源标识符，用字符串标识某一互联网资源，而 $URL$表示资源的地点

绝对 $URI$格式： $http://user:[email protected]:80/dir/index.htm?uid=1$# $ch1$

• $http:$ —协议方案名
• $user:pass$ —登陆信息(认证)
• $www.example.jp$ —服务器地址
• $80$ —服务器端口号
• $dir/index.htm$ —带层次的文件路径
• $uid=1$ — 查询字符串
• $ch1$ —片段标识符

4. HTTP协议

$HTTP$协议特点

• HTTP是一种不保存状态，即无效协议。HTTP协议自身不对请求和响应之间的通信状态继续保存。也就是说HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理
• 使用 $HTTP$协议，每当有新的请求发送时，就会有对应的新响应产生；不保存状态的原因：更快的处理大量事务，确保协议的可伸缩性，而特意把 $HTTP$协议设计成如此简单的
• $HTTP/1.1$虽然是无状态协议，但为了实现期望的保持状态功能，于是引入 $Cookie$技术

$HTTP$协议方法

• $GET$：获取资源，请求已被 $URI$识别的资源
• $POST$：传输实体中的主体
• $PUT$：用来传输文件
• $HEAD$：获得报文首部
• $DELETE$：删除文件
• $OPTIONS$：查询针对请求 $URI$指定的资源支持的方法
• $TRACE$：让 $Web$服务器端将之前的请求通信返回给客户端的方法
• $CONNECT$：要求在与代理服务器通信时建立隧道，实现用隧道协议进行 $TCP$通信

5. HTTP持久连接

5.1 持久连接

• $HTTP$协议的初始版本中，每进行一次 $HTTP$通信就要断开一次 $TCP$连接。
• 为了解决上述 $TCP$连接的问题， $HTTP/1.1$想出了持久连接( $HTTP$ $keep-alive$)的方法。
• 持久连接的特点：只要任意一端没有明确提出断开连接，则保持 $TCP$连接状态
• 持久连接好处：减少了 $TCP$连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载

5.2 管线化

• 管线化技术使得不用等待响应就可直接发送下一个请求，做到同时并行发送多个请求

5.3 使用Cookie的状态管理

• $HTTP$是无状态协议，不对之前发生过的请求和响应的状态进行管理
• 无状态协议的优点：(1)由于不必保存状态，自然可减少服务器的 $CPU$及内存资源的消耗 (2)因为 $HTTP$协议本身非常简单，所以才会被用于各种场景
• 于是在保留无状态协议这个特征的同时又要解决类似的矛盾问题，引入了 $Cookie$技术
• $Cookie$技术通过在请求和响应报文中写入 $Cookie$信息来控制客户端的状态
• $Cookie$会根据服务器端发送的响应报文内的一个叫做 $Set-Cookie$的首部字段信息，通知客户端保存 $Cookie$。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 $Cookie$值后发送出去；服务器端发现客户端发送过来的 $Cookie$后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息

示例：
(1)请求报文

GET /reader/ HTTP/1.1
Host: hacker.jp

(2)响应报文(服务器端生成 $Cookie$信息)

HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
< Set-Cookie: sid=1342077140226724; path=/; expires=Wed,10-Oct-12 07:12:20 GMT>
Content-Type:  text/plain; charset=UTF-8

(3)请求报文(自动发送保存着的 $Cookie$信息)

GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724

6. HTTP报文结构

7. HTTP状态码

状态码：当客户端向服务器端发送请求时，描述返回的请求结果；借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。

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

7.1 2XX 成功

• $200$ $OK$：表示从客户端发来的请求在服务端被正常处理了
• $204$ $No Content$:表示服务器接受的请求已成功处理，但在返回的响应报文中不含实体的主体部分
• $206$ $Partial Content$：表示客户端进行了范围请求，而服务器成功执行了这部分的 $GET$请求

7.2 3XX 重定向

• $301$ $Moved Permanently$：永久性重定向。该状态码表示请求的资源已被分配了新的 $URI$
• $302$ $Found$：临时性重定向。该状态码表示请求的资源已被分配了新的 $URI$
• $303$ $See Other$：表示请求对应的资源存在着另一个 $URI$，应使用 $GET$方法定向获取请求的资源
• $304$ $Not Modified$：该状态码表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回 $304$ $Not Modified$
• $307$ $Temporary Redirect$：临时重定向

7.3 4XX 客户端错误

• $400$ $BadRequest$：表示请求报文中存在语法错误
• $401$ $Unauthorized$：表示发送的请求需要有通过 $HTTP$认证的认证信息
• $403$ $Forbidden$：表示请求资源的访问被服务器拒绝了
• $404$ $NotFound$：表示服务器上无法找到请求的资源

7.4 5XX 服务器错误

• $500$ $Internal Server Error$：表示服务器在执行请求时发生了错误
• $503$ $ServiceUnavailable$：表示服务器暂时处于超负载或正在停机维护，现在无法处理请求

8. 通信数据转发程序：代理、网关和隧道

$HTTP$通信时，除客户端和服务器之外，还有一些用于通信数据转发的应用程序，例如代理、网关和隧道。它们可以配合服务器工作

8.1 代理

• 代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器。代理不改变请求 $URI$，会直接发送给前方持有资源的目标服务器
• 持有资源实体的服务器被称为源服务器。从源服务器返回的响应经过代理服务器后再传给客户端
• 转发时，需要附加 $Via$首部字段以标记出经过的主机信息
• 使用代理服务器的理由：利用缓存技术减少网路带宽的流量，组织内部针对特定网站的访问控制
• 缓存代理：代理转发响应时，缓存代理会预先将资源的副本保存在代理服务器上；当代理再次接收到对相同资源的请求时，就可以不从原服务器哪里获取资源，而是将之前缓存的资源作为响应返回
• 透明代理：转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理。反之，对报文内容进行加工的代理被称为非透明代理

8.2 网关

• 网关的工作机制与代理类似。而网关能使通信线路上的服务器提供非 $HTTP$协议服务
• 利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全

8.3 隧道

• 可按要求建立起一条与其他服务器的通信线路，届时使用 $SSL$等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信
• 隧道本身不会去解析 $HTTP$请求。即请求保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束

8.4 缓存

• 缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减少对原服务器的访问，因此也就节省了通信流量和通信时间
• 缓存服务器是代理服务器的一种，并归类在缓存代理类型中。当代理转发从服务器返回的响应时，代理服务器将会保存一份资源的副本
• 缓存服务器的优势在于利用缓存可避免多次从原服务器转发资源。因此客户端可就近从缓存服务器上获取资源，而源服务器也不必多次处理相同的请求

缓存的有效期限

• 即使缓存服务器内有缓存，也不能保证每次都会返回对同资源的请求，如果客户端要求的资源有效期在缓存有效期之外，那么缓存失效，缓存服务器会再次从源服务器上获取新资源

客户端的缓存

• 缓存不仅可以存在于缓存服务器中，还可以存在客户端浏览器中。

9. HTTP/1.1 首部字段

表 $6-1$：通用首部字段

表 $6-2$：请求首部字段

表 $6-3$：响应首部字段

表 $6-4$：实体首部字段

10. HTTP不足

$HTTP$不足之处：

• 通信使用明文(不加密)，内容可能会被窃听
• 不验证通信方的身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能已遭篡改

10.1 通信使用明文可能会被窃听

10.1.1 TCP/IP是可能被窃听的网络

• $TCP/IP$是可能被窃听的网络：按 $TCP/IP$协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视
• 即使已经过加密处理的通信，也会被窥视到通信内容；只是说如果通信经过加密，就有可能让人无法破解报文信息的含义，但加密处理后的报文信息本身还是会被看到的
• 窃听相同段上的通信并非难事。只需要收集在互联网上流动的数据包就行了。对于收集来的数据包的解析工作，可交给哪些抓包( $Wireshark$)或嗅探器工具

10.1.2 加密防止被窃听

• 通信加密： $HTTP$协议中没有加密机制，但可以通过和 $SSL$或 $TLS$的组合使用，加密 $HTTP$的通信内容；用 $SSL$建立安全通信线路之后，就可以在这条线路上进行 $HTTP$通信了。与 $SSL$组合使用的 $HTTP$被称为 $HTTPS$
• 内容加密：对 $HTTP$协议传输的内容本身加密。即把 $HTTP$报文里所含的内容进行加密处理

10.2 不验证通信方的身份就可能遭遇伪装

$HTTP$协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求中 $URI$真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端

10.2.1 任何人都可发起请求

$HTTP$协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下隐患

• 无法确定请求发送至目标的 $Wec$服务器是否是按真实意图返回响应的那台服务器。有可能是组装的服务器
• 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是伪装的客户端
• 无法确定正在通信的双方是否具备访问权限。因为某些 $Web$服务器上保存着重要的信息，只想发送给特定用户通信的权限

10.2.2 查明对手的证书

• 使用 $SSL$可以确定通信方， $SSL$不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方
• 证书由值得信任的第三方机构颁发，用以证明客户端和服务器是实际存在的
• 通过使用证书，以证明通信方就是意料中的服务器。客户端持有证书即可完成个人身份的确认，也可用于对 $Web$网站的认证环节

10.3 无法证明报文完整性，可能已被篡改

所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确

• 由于 $HTTP$协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉，换句话说，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的
• 防止篡改：常用的是 $MD5$和 $SHA-1$等散列值校验的方法，以及用来确认文件的数字签名方法

11. HTTP+加密+认证+完整性保护=HTTPS

• 我们把添加了加密及认证机制的 $HTTP$称为 $HTTPS$
• 通常， $HTTP$直接和 $TCP$通信。当使用 $SSL$时，则演变成先和 $SSL$通信，再由 $SSL$和 $TCP$通信了。简言之，所谓 $HTTPS$，其实就是身披 $SSL$这层外壳的 $HTTP$

11.1 公开密钥加密技术

$SSL$采用一种叫做公开密钥加密的加密处理方式

11.1.1 共享密钥加密

• 加密和解密同用一个密钥的方式称为共享密钥加密，也被叫做对称加密密钥
• 这种加密方式有一个困境：发送密钥就有被窃听的风险，但不发送，对方就不能解密

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

• 公开密钥加密使用了一种非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥可以随意发布，任何人都可以获得
• 使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走

11.1.3 HTTPS采用混合加密机制

• $HTTPS$采用共享密钥加密和公开密钥加密两者并用的混合加密机制
• 在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享加密方式

11.2证明公开密钥正确性的证书

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

11.3 SSL速度慢吗

$HTTPS$也存在一些问题，那就是当使用 $SSL$时，它的处理速度会变慢

$SSL$的慢分两种。一种是指通信慢。另一种是指由于大量消耗 $CPU$及内存等资源，导致处理速度变慢

• 和使用 $HTTP$相比，网络负载可能会变慢2到100倍。除去和 $TCP$连接、发送 $HTTP$请求/响应相比，还必须进行 $SSL$通信，因此整体上处理通信量不可避免会增加
• 另一点是 $SSL$必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 $HTTP$会更多地消耗服务器和客户端地硬件资源，导致负载增强

11.4 为什么不一直使用HTTPS

• 其中一个原因是，因为与纯文本通信相比，加密通信会消耗更多地 $CPU$及内存资源。如果每次通信都加密，会消耗更多地资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少
• 特别是每当那些访问量较多的 $Web$网站在进行加密处理时，它们所承担的负载不容小觑。在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源
• 除此之外，想要节约购买证书的开销也是原因之一

12. Web的攻击技术

因输出值转义不完全引发的安全漏洞

• 跨站脚本攻击
• $SQL$注入攻击
• $OS$命令注入攻击
• $HTTP$首部注入攻击
• 邮件首部注入攻击
• 目录遍历攻击
• 远程文件包含漏洞

因设置或设计上的缺陷引发的安全漏洞

• 强制浏览
• 不正确的错误消息处理
• 开放重定向

因会话管理疏忽引发的安全漏洞

• 会话劫持
• 会话固定攻击
• 跨站点请求伪造

其它安全漏洞

• 密码破解
• 点击劫持
• $Dos$攻击
• 后门程序