目录：
1.HTTP 方法
2.HTTP 状态码
3.HTTP 报文
4.HTTP 和 HTTPS 的区别
5.HTTPS 相关
HTTP方法
-
GET 获取资源
当前网络请求中，绝大部分使用的是 GET 方法。
-
HEAD 获取报文首部
和GET方法类似，但是不返回报文实体主体部分。
主要用于确认URL的有效性以及资源更新的日期时间等。
-
POST 传输实体主体
POST 主要用来传输数据，而 GET 主要用来获取资源。
更多 POST 与 GET 的比较请见第九章。
-
PUT 上传文件
由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。
PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16
New File
-
PATCH 对资源进行部分修改
PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100
[description of changes]
-
DELETE 删除文件
与 PUT 功能相反，并且同样不带验证机制。
DELETE /file.html HTTP/1.1
-
OPTIONS 查询支持的方法
查询指定的 URL 能够支持的方法。
会返回Allow: GET, POST, HEAD, OPTIONS这样的内容。
-
CONNECT 要求在与代理服务器通信时建立隧道
使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
CONNECT www.example.com:443 HTTP/1.1
-
TRACE追踪路径
服务器会将通信路径返回给客户端。
发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。
通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。
不安全的http方法及其危害
1.PUT方法：自身不带验证机制，利用PUT方法即可快捷简单地入侵服务器，上传Webshell或其他恶意文件，从而获取敏感数据或服务器权限。
2.DELETE方法：自身不带验证机制，利用DELETE方法可以删除服务器上特定的资源文件，造成恶意攻击。
3.OPTIONS方法：将会造成服务器信息暴露，如中间件版本、支持的HTTP方法等。
4.TRACE方法：容易引发XST攻击（见网站安全相关）
5.PATCH方法：修改资源的部分内容
HTTP 状态码
HTTP状态码根据首位数字的不同，其代表的含义也不同：
1XX：信息状态码
- 100（Continue）：一切正常，可以继续发送请求
2XX：成功状态码
- 200（OK）：请求成功
- 204（No Content）：请求成功，但响应报文无实体主体。一般用于客户端往服务端发送信息而不需要返回数据时。
- 206（Partial Content）：客户端进行了范围请求，响应报文中有 Content-Range 指定范围的实体内容。
3XX：重定向状态码
- 301（Moved Permanently）：永久重定向
- 302（Found）：临时重定向
- 303（See Other）：临时重定向，要求浏览器不会把重定向请求的 POST 方法改成 GET 方法
注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。 - 304（Not Modified）：无变化/未修改/只读，服务器对比数据发现未修改，客户端直接从本地缓存读取即可，返回该状态吗
- 307（Temporary Redirect）：临时重定向，要求post方法
4XX：客户端状态码
- 400（Bad Request）：报文语法错误
- 402（Unauthorized）：需要认证，一般是要求登录
- 403（Forbidden）：请求被拒绝，一般是权限不足
- 404（Not Found）：找不到网页
409（Conflict）：请求的资源与该资源的当前状态发生冲突
410（Gone）：资源在服务器上已被永久性删除
5XX：服务端状态码
- 500（Internal Server Error）：服务器执行请求时法发生错误
- 503（Service Unavailable）：服务器超负载/停机维护，现在无法处理请求。校园网选课经常返回该值。
最全的HTTP1.1状态码
HTTP 报文
HTTP首部字段包含四种：
- 通用首部字段（General Header Fields）：请求和响应报文两方都会使用的首部字段。
| 首部字段名 | 说明 |
|---|---|
| Cache-Control： | 控制缓存的行为 |
| Connection | 控制不再转发给代理的首部字段、管理持久连接 |
| Date | 创建报文的日期时间 |
| Pragma | 报文指令 |
| Trailer | 报文末端的首部一览 |
| Transfer-Encoding | 指定报文主体的传输编码方式 |
| Upgrade | 升级为其他协议 |
| Via | 代理服务器的相关信息 |
| Warning | 错误通知 |
- 请求首部字段（Reauest Header Fields）：客户端向服务器发送请求的报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关的优先等级信息。
| 首部字段名 | 说明 |
|---|---|
| Accept | 用户代理可处理的媒体类型 |
| Accept-Charset | 优先的字符集 |
| Accept-Encoding | 优先的内容编码 |
| Accept-Language | 优先的语言（自然语言） |
| Authorization Web | 认证信息 |
| Expect | 期待服务器的特定行为 |
| From | 用户的电子邮箱地址 |
| Host | 请求资源所在服务器 |
| If-Match | 比较实体标记（ETag） |
| If-Modified-Since | 比较资源的更新时间 |
| If-None-Match(1.1) | 比较实体标记（与 If-Match 相反） |
| If-Range(1.1) | 资源未更新时发送实体 Byte 的范围请求 |
| If-Unmodified-Since(1.1) | 比较资源的更新时间（与 If-Modified-Since 相反） |
| Max-Forwards | 最大传输逐跳数 |
| Proxy-Authorization | 代理服务器要求客户端的认证信息 |
| Range(1.1) | 实体的字节范围请求（断点续传） |
| Referer | 对请求中 URI 的原始获取方 |
| TE | 传输编码的优先级 |
| User-Agent | HTTP 客户端程序的信息 |
- 响应首部字段（Response Header Fields）：从服务器向客户端响应时使用的字段，补充响应的附加内容，也会要求客户端附加额外信息
| 首部字段名 | 说明 |
|---|---|
| Accept-Ranges | 是否接受字节范围请求 |
| Age | 推算资源创建经过时间 |
| ETag(1.1) | 资源的匹配信息 |
| Location | 令客户端重定向至指定 URI |
| Proxy-Authenticate | 代理服务器对客户端的认证信息 |
| Retry-After | 对再次发起请求的时机要求 |
| Server | HTTP 服务器的安装信息 |
| Set-Cookie | 在浏览器种cookie，一旦被种下，当浏览器访问符合条件的url地址时，会自动带上这个cookie |
| Vary | 代理服务器缓存的管理信息 |
| WWW-Authenticate | 服务器对客户端的认证信息 |
- 实体首部字段（Entiy Header Fields）|针对请求报文和响应报文的实体部分使用首部。补充了资源内容更新时间等实体有关的信息。
| 首部字段名 | 说明 |
|---|---|
| Allow | 资源可支持的 HTTP 方法 |
| Content-Encoding | 实体主体适用的编码方式 |
| Content-Language | 实体主体的自然语言 |
| Content-Length | 实体主体的大小 |
| Content-Location | 替代对应资源的 URI |
| Content-MD5 | 实体主体的报文摘要 |
| Content-Range | 实体主体的位置范围 |
| Content-Type | 实体主体的媒体类型 |
| Expires | 实体主体过期的日期时间 |
| Last-Modified | 资源的最后修改日期时间 |
小知识点：
降低服务器压力的方法[参考3]
细节可看我的文章HTTP缓存请求首部字段Referer和安全相关
细节可看我的文章XSS，CSRF，XST等网站安全请求首部字段Max-Forwards和TRACE、OPTIONS方法有关系
细节可看我的文章
HTTP 和 HTTPS 的区别
主要区别如下：
- https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
- http是超文本传输协议，基于TCP连接，信息是明文传输；https运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输内容都经过加密。
- http和https使用的端口不一样，前者是80，后者是443。
- http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
HTTPS 相关
HTTPS 的工作原理
我们都知道HTTPS能够加密信息，以免敏感信息被第三方获取，所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。
1. 客户端发起HTTPS请求
这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。
2. 服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。
这套证书其实就是一对公钥和私钥，如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
3. 传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
4. 客户端解析证书
这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。
如果证书没有问题，那么就生成一个随机值，然后用证书对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
5. 传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6. 服务段解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
7. 传输加密后的信息
这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。
8. 客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。
HTTPS 的优点
正是由于HTTPS非常的安全，攻击者无法从中找到下手的地方，从站长的角度来说，HTTPS的优点有以下2点：
1. SEO方面
谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。
2. 安全性
尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：
（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
HTTPS 的缺点
虽然说 HTTPS 有很大的优势，但其相对来说，还是有些不足之处的，具体来说，有以下2点：
SEO方面
据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电，此外，HTTPS协议还会影响缓存，增加数据开销和功耗，甚至已有安全措施也会受到影响也会因此而受到影响。
而且HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。
最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。经济方面
（1）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
（2）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。
（3）HTTPS连接缓存不如HTTP高效，大流量网站如非必要也不会采用，流量成本太高。
（4）HTTPS连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本，如果全部采用HTTPS，基于大部分计算资源闲置的假设的VPS的平均成本会上去。
（5）HTTPS协议握手阶段比较费时，对网站的相应速度有负面影响，如非必要，没有理由牺牲用户体验。
参考：
[1].CS-Notes
[2].不安全的http方法