关于HTTP的小结

发表于   |   分类于   |     |  

[TOC]
HTTP是应用层协议，TCP是传输层协议
Http协议是建立在TCP协议基础之上的，当浏览器需要从服务器获取网页数据的时候，会发出一次Http请求。Http会通过TCP建立起一个到服务器的连接通道，当本次请求需要的数据完毕后，Http会立即将TCP连接断开，这个过程是很短的。所以Http连接是一种短连接，是一种无状态的连接。

HTTP报文组成


响应的格式大体也差不多

  • 请求的起始行：请求类型 + URL + HTTP协议版本
  • 响应的起始行：HTTP协议版本 + 状态码 + 原因短语

HTTP请求：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
GET /Protocols/rfc2616/rfc2616-sec5.html HTTP/1.1   //起始行
Host: www.w3.org     //首部开始
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Referer: https://www.google.com.hk/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: authorstyle=yes
If-None-Match: "2cc8-3e3073913b100"
If-Modified-Since: Wed, 01 Sep 2004 13:24:52 GMT //首部结束
name=qiu&age=25   //主体

HTTP响应：

1
2
3
4
5
6
7
8
9
10
11
12
13
HTTP/1.1 200 OK
Date: Tue, 08 Jul 2014 05:28:43 GMT
Server: Apache/2
Last-Modified: Wed, 01 Sep 2004 13:24:52 GMT
ETag: "40d7-3e3073913b100"
Accept-Ranges: bytes
Content-Length: 16599
Cache-Control: max-age=21600
Expires: Tue, 08 Jul 2014 11:28:43 GMT
P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
Content-Type: text/html; charset=iso-8859-1
{"name": "qiu", "age": 25}

请求类型

GET和HEAD方法被认为是安全的，安全的方法并不是什么动作都不执行，所谓的安全方法就是在使用可能引发不安全行为时允许HTTP应用程序开发者通知用户。

GET

HTTP1.1要求服务器实现此方法。

只返回首部，不返回主体
可以用于查看某个对象是否存在，或者测试资源是否被修改

PUT

向服务器写入文档，很多都要求在执行PUT之前用密码登陆

TRACE 环回诊断

行程最后一站服务器会弹回一条TRACE响应，并在响应主体中携带它原始报文请求

OPTIONS

询问服务器支持哪些方法

DELETE

请服务器删除请求URL所指定的资源

状态码

1XX

  1. 100 continue ：收到请求的初始部分，请客户端继续。一般在发送post请求时，已发送了http header之后服务端将返回此信息，表示确认，之后发送具体参数信息

2XX

  1. 200 OK ：正常返回信息，主体部分包含所请求的资源
  2. 201 Created：请求成功，并且服务器创建了新的资源（一般用于PUT写入请求）
  3. 202 Accept；服务器已接受请求，但尚未处理
  4. 204 No Content：响应中没有实体

3XX

  1. 301 Moved Permanetly：永久重定向，请求的网页已永久移动到新位置
  2. 302 Found：临时重定向
  3. 303 See Other：临时重定向，告知客户端应该用另一个URL来请求资源，新的URL位于响应报文的location首部
  4. 304 Not Modified：自从上次请求后，请求的资源未修改过

4XX

  1. 400 Bad Request：告知客户端它发送了一个服务器无法理解的请求
  2. 401 Unauthorized：请求未授权，要先获取资源的访问权，一般需要密码等
  3. 403 Foebidden：禁止访问，由于IP、读写权限等
  4. 404 Not Found：找不到所请求的URL资源

5XX

  1. 500 Internal Server Error：服务器端错误，可能是程序错误、服务器关闭、服务器太忙等
  2. 503 Service Unavailable： 服务器端暂时无法处理请求（可能是过载或维护）。

HTTP缺点

1.通信使用明文，内容可能会被窃听，即使加密，密文也可以被看到并解密 尺寸 n
2.不验证通信双方身份，可能遭遇伪装
3.无法证明报文的完整性，可能遭遇篡改

http2.0

http2 是完全兼容 http/1.x 的，在此基础上添加了 4 个主要新特性：

  • 二进制分帧：http/1.x 是一个文本协议，而 http2 是一个彻彻底底的二进制协议
  • 多路复用：在 http/1.x 情况下，每个 http 请求都会建立一个 TCP 连接，这就意味着每个请求都需要进行三次握手。并且浏览器会限制同一个域名下并发请求的个数。所以，在 http/1.x 的情况下，一个常见的优化手段是把静态资源分布到不同域名下，以此来突破浏览器并发数的限制。在 http2 的情况下，所有的请求都会共用一个 TCP 连接，客户端请求会分解成多个帧，这些帧会在服务器端重新组合得到完整的请求
  • 头部压缩： 减少 http header 在每次请求中消耗的流量
  • 服务端推送：服务端推送指的是服务端主动向客户端推送数据。比如请求一个网页的时候服务器会把css、js资源也同时发送过来

HTTPS

参考：https://www.jianshu.com/p/ca7df01a9041
https://www.cnblogs.com/zxj015/p/6530766.html

  • 共享密钥加密：加密和解密同用一个密钥,加密公开，密钥传给客户端是个问题

共享加密

  • 公开密钥加密：发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

公开密钥加密

  • HTTPS 采用混合加密机制：使用公开密钥加密传递密钥，然后使用共享加密密钥方式传输报文。

  • HTTPS混合加密

  • 数字证书：公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

  • 数字证书

  • HTTPS通信过程：
    https通信过程
    第一次握手：
    (1)客户端发送Client Hello协商加密组件，报文中携带客户端支持的SSL版本和加密组件
    (2)服务器回应Server Hello，在报文中携带服务器对客户端SSL版本及加密组件支持情况
    (3)服务器发送公开密钥证书
    (4)服务器发送Server Hello Done通知客户端初始SSL协商部分结束
    进行一次验证
    (5)SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
    (6)接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
    (7)客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
    (8)服务器同样发送 Change Cipher Spec 报文。
    (9)服务器同样发送 Finished 报文。
    建立完成，发送HTTP请求
    最后由客户端断开连接。断开连接时，发送 close_notify 报文

  • HTTPS比HTTP慢2到10倍
    SSL 的慢分两种。一种是指通信慢。另一种是指由于大量消耗 CPU 及内存等资源，导致处理速度变慢。
    1、和使用 HTTP 相比，网络负载可能会变慢 2 到 100 倍。除去和 TCP 连接、发送 HTTP 请求 • 响应以外，还必须进行 SSL 通信，因此整体上处理通信量不可避免会增加。
    2、另一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。
    针对速度变慢这一问题，并没有根本性的解决方案，我们会使用 SSL 加速器这种（专用服务器）硬件来改善该问题。该硬件为 SSL 通信专用硬件，相对软件来讲，能够提高数倍 SSL 的计算速度。仅在 SSL 处理时发挥 SSL加速器的功效，以分担负载。

    SSL

    SSL是对http通信方式进行加密。改动了协议本身，在TCP层和HTTP层之间硬加了一层SSL层，与内容加密的方式不同

TCP三次握手与四次挥手

热评文章