HTTP协议

HTTP is the foundation of any data exchange on the Web.

The first version of HTTP,referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by RFC 1945 , improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts.


HTTP的首个版本是HTTP/0.9，这是一个用于在网络中发送原始数据的简易协议。HTTP/1.0进一步提升了该协议，通过允许信息以MIME-like信息的格式发送，在请求/响应中包含数据传送/修改者的元信息。但是HTTP/1.0在处理分层代理，缓存，持久性链接和虚拟主机时，仍有不足

报文

开始行

开始行用于区分是何种报文

请求报文

请求行的第一行只有三个内容：方法，URL,HTTP版本。

HTTP的1.0版本中只有三种请求方法

1. GET
   请求指定的页面信息，并返回实体主体。GET请求请提交的数据放置在HTTP请求协议头中，GET方法通过URL请求来传递用户的输入。
   该方法具有安全问题，因为无论你发送什么东西，在URL中都是对任何人可见的，也就是说：用户输入在网络中明文传递！
2. POST
   向指定资源提交数据进行处理请求（例如提交表单或者上传文件），可能会导致新的资源的建立和/或已有资源的修改。
3. HEAD
   请求指定的页面信息，但不返回实体，用于获取报头

POST 与 GET 区别

1. get的参数放在url传递，而post放在请求体里
2. get只能请求资源；post可以改动资源
3. get可以cache而post不能
4. get请求受URL长度限制，最长2048，且发送接收ASCII码；post请求信息不做限制，且类型不局限于ASCII码

到了1.1版本时，新增加了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

http请求行如下

GET https://tools.ietf.org/images/rfc.png HTTP/1.1

响应报文

同样也是响应报文的第一行：状态行。包含三项内容http版本，状态码，简单短语。
状态码可分为五大类
1xx ： 信息状态码，如请求收到 或 正在处理
2xx ： 成功状态码 200 成功
3xx ： 重定向状态码 302 重定向
4xx ： 客户端错误状态码 404资源不存在
5xx ： 服务端错误 502 bad Gateway

关于状态码更加详细的介绍
简单短语用于解释状态码

http状态行如下：

HTTP/1.1 200 OK

首部行

传送附加信息。整个首部行结束时，空一行与之后的实体主体分开

实体主体

请求报文一般不用这个，同样响应报文可可以没有这个(HEAD请求)

链接

一次网络请求经历的过程

1. 浏览器从URL中解析服务器主机名
2. DNS查询将主机名转换为IP
   DNS解析过程
3. 解析URL中的端口号
4. 三次握手建立与web服务器的tcp连接
   TCP三次握手
5. 浏览器向服务器发送http请求
6. 服务器返回响应
7. 四次握手关闭tcp连接
   TCP四次握手

虽然HTTP使用了TCP，但是HTTP是无连接的，在发送HTTP报文之前不需要建立HTTP连接。
此外，HTTP连接还是无状态的。怎么说呢，就是忘得快。客户端第一次找服务端，TCP连接一关，再去找服务端就记不住人了，也就是服务端响应与第一次被访问时响应相同，这样的设计便于服务器支持大量并发HTTP请求。
但是这样的设计存在缺点，对于客户端来说每次请求都要先建立TCP连接，传送两个连接报文，影响响应速度。在HTTP/1.1中，为了优化连接管理，提出长连接

长连接

为了使用同一个TCP链接发送/接收多个请求/响应，连接超时设定会长一些。长连接是HTTP/1.1的重要特点，开启传输时默认使用长连接，其引入极大的提高HTTP传输效率

Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection.
Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server.
The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client or the server.

advantages

• 更少的TCP链接使得CPU能节省时间用于路由器和hosts，用于TCP链接管理的内存也能用于hosts存储
• HTTP请求/响应能以流水线方式链接。
  流水线：允许多个请求发送，而不必等待其响应后再发送下一个
• TCP启动时包少了，网络拥塞也少了

长连接提供了客户端和服务端可通知关闭连接的机制：使用Connection header中的connection-token字段并设为 close。一旦结束信号发出，C端不能发送任何请求。

短链接

与长连接相反，服务端响应与第一次被访问时响应相同，每次都要建立TCP连接才能开始通信

从 HTTP/1.1 开始默认是长连接的，如果要断开连接，需要由客户端或者服务器端提出断开，使用 Connection : close；
在 HTTP/1.1 之前默认是短连接的，如果需要使用长连接，则使用 Connection : Keep-Alive。

缓存

1. Last-Modified 和 If-Modified-Since

   当次请求本地存在的缓存页面时,客户端会通过 If-Modified-Since 头把浏览器端缓存页面的最后一次被服务器修改的时间一起发到服务器去
   服务器会把这个时间与服务器上实际文件的最后修改时间进行比较,通过这个时间戳判断客户端的页面是否是最新的
   如果不是最新的,就返回 HTTP 状态码 200 和新的文件内容,客户端接到之后,会丢弃旧文件,把新文件缓存起来,并显示到浏览器中
   如果是最新的,则返回 304 告诉客户端其本地缓存的页面是最新的,就直接把本地缓存文件显示到浏览器中

2. ETag 和 If-None-Match
   ETag 和 If-None-Match 可以是任何资源的任何属性。
   服务器会为每个资源分配对应的 ETag 值,根据资源的内容得到其值。当资源内容发生改变时,其值也会改变。在 HTTP Response 中添加 ETags 信息。当客户端再次请求该资源时,将在 HTTP Request 中加入 If-None-Match 信息(也就是 ETags 的值)。如果服务器验证资源的 ETags 没有改变(该资源的内容没有改变),将返回一个 304 状态;否则,服务器将返回 200状态,并返回该资源和新的 ETags。

Last-Modified 与 ETag 一起使用时,服务器会 优先验证 ETag 的值 。

3. Expires / Cache-Control
   用来控制缓存的失效日期,控制浏览器是直接从浏览器缓存取数据还是重新发请求到 服务器取数据。
   Expires 的一个缺点就是,返回的到期时间是服务器端的时间,如果客户端的时间与服务器的时间相差很大,那么误差就很大。
   以在 HTTP 1.1 版开始,使 用 Cache-Control: max-age=(秒)替代。

客户端认证

由于HTTP协议是无状态的，为了能让服务端识别用户，跟踪记录用户的信息，在HTTP/1.1以后，引入了cookie作为用户认证

cookie

cookie是服务端给客户端发送的一组数据，客户端将其存储在本地，每次访问该服务器都会带上cookie，标记身份。

结构

[name]  [value]   [path]    [domain]      [expires]    [secure]          [httponly]
键         值      路径       所属域        过期时间    secure flag      httponly flag

作用域
Domain 标识指定了哪些主机可以接受 Cookie。如果不指定，默认为当前文档的主机，如果指定了 Domain，则一般包含子域名。
Path 标识指定了主机下的哪些路径可以接受 Cookie。以字符 ‘/’ 作为路径分隔符，子路径也会被匹配。

过期时间
表示cookie何时应该被删除的时间戳。如果不设置这个时间戳，浏览器会在页面关闭时即将删除所有cookie。

HttpOnly
标记为 HttpOnly 的 Cookie 不能被 JavaScript 脚本调用，防止XSS攻击

Secure
只有在使用SSL链接时候才能发送到服务器，如果是http链接则不会传递该信息。不要把重要信息放cookie就对了服务器端设置。

创建过程

服务器发送的响应报文包干Set-Cookie首字段

HTTP/1.1 200 OK
Content-Length: 43
Content-Type: image/gif
Set-Cookie: yummy_cookie=choco; Path=/; Domain=hm.baidu.com; Expires=Sun, 18 Jan 2038 00:00:00 GMT
Strict-Transport-Security: max-age=172800

之后客户端对同一服务器请求时都会带上这个cookie

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco;

作用

Cookies are mainly used for three purposes:

• Session management
  Logins, shopping carts, game scores, or anything else the server should remember
• Personalization
  User preferences, themes, and other settings
• Tracking
  Recording and analyzing user behavior

安全问题

对于服务器来说，相同的cookie对应相同的客户，因此这也导致了安全问题。攻击者可以截获HTTP报文中的cookie来冒充用户，如果cookie中还含有其他敏感信息，后果更加严重。
此外，广告公司的第三方cookie会监视我们的浏览记录，并有针对性的推送

session

与cookie不同，session选择将信息存储在服务器。相较于cookie只能存储ASCII码且长度有限，Session 则可以存储任何类型的数据。

创建过程

用户在第一次访问时，服务器会为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。此后客户端携带session id与服务器进行通信。

Cookie 与 Session 的区别。

1. cookie 数据存放在客户端,用来记录用户信息的；session 数据放在服务器上。
2. 由于 Cookie 存储在客户端中,对客户端是可见的,因此是不安全的；而 Session 存储在服务器上,不存在敏感信息泄露的危险。
3. Session 是保存在服务器端，并发访问的用户 非常多,过多Session,消耗大量的服务器内存；而 Cookie 保存在客户端,不占用服务器资源。

HTTP/1.1 与 HTTP/1.0区别：

1. HTTP/1.1 新增了PUT、PATCH、HEAD、OPTIONS、DELETE五种方法；以及状态码 100 Continue
2. HTTP/1.1默认使用长连接；而HTTP/1.0需要声明Connection: keep-alive
3. HTTP/1.1默认采用 流水线的方式发送请求,即客户端每遇到一个对象引用就立即发出一个请求,而不必等到收到前一个响应之后才能发出下一个请求，但服务器端必须保证按序响应
4. HTTP/1.1 引入了被称为分块(chunked)的传输方法。该方法使发送方能将消息实体 分割为任意大小的组块(chunk),并单独地发送；HTTP/1.0 可用来指定实体长度的唯一机制是通过 Content-Length 字段。
5. HTTP/1.1请求头新增Host字段,用来指定服务器的域名，用于将请求发往同一台服务器上的不同网站

在浏览器中输入 URL 后,执行的全部过程。会用到哪些协议?(一次完整的 http 请求过程)。

• 域名解析
  见DNS域名解析
• IP 协议、ARP 协议和 OSPF 协议 从 PC 上传到服务器上。
• 发起 TCP 的 3 次握手
• 建立 TCP 连接后发起 http 请求
• 服务器响应 http 请求
• 浏览器解析 html 代码,并请求 html 代码中的资源(如 js、css、图片等)
• 断开 TCP 连接
• 浏览器对页面进行渲染呈现给用户

https

HTTP的安全版本，增加了一次SSL握手，可以采用对称/非对称的加密方式。能对内容加密，验证通信双方身份，检校数据完整性。

数字认证

非对称加密

对称加密
既然有非对称的，那就也有对称的，例如MD5，AES啥的。加密算法是公开的，靠的是密钥来加密数据，因此想要建立对称加密安全的信道，就需要双方提前沟通密钥，显然在网络环境中，密钥可能在沟通时被暴露，导致安全问题

通信双方所持密钥不同，分为公钥和私钥，其中公钥对外公开，私钥私有。虽然密钥不同，但是加解密内容一致。

非对称加密有多种实现方式，如RSA,DSA，这里只说明RSA的原理，其构造过程如下：

1. 根据伪随机数+MR测试生成两个大质数P,Q
2. 令$n=P\cdot Q$，求n的欧拉函数$\varphi (n)=(P-1)(Q-1)=m$
3. 在$[1,m]$区间内随机选择数字e 且 e与n互质
4. 计算e在$\varphi (n)$下的逆元d

在上面的数字中挑选出构造非对称加密的元素：

公钥：(n, e)	 私钥：(n, d)

加解密利用逆元的性质，现有明文m，对明文加密后密文c
$$m^d=c(mod\varphi (n))$$
对密文c解密
$$c^e=m(mod\varphi (n))$$

为什么RSA是安全的呢？
RSA算法中，公钥(n,e)是公开，只有d未知，理论上可以通过公钥求出私钥(n,d)。
d 和 e 是在$\varphi (n)$下的一对逆元，既然n已知，似乎d没什么保密性。但是关键就在于$\varphi (n)$的求解上，因此这涉及到了大数质数分解。截止至2019年，被分解的最大RSA数有795位，分解使用了900个CPU年的算力，而NIST建议目前的RSA秘钥安全强度是2048位，除非量子计算有所突破，否则RSA将是绝对安全的。

数字签名

防止在传输过程中，内容被恶意修改。

虽然加密方式是安全的，但是上述流程中仍存在安全隐患：对于接受端来说，我拿着谁的公钥？
在接受端并没有身份验证机制，只能通过解密后核对来证实密文是否被改动过。假设接受端B，开始时持有A的公钥，后来被偷换成了C的公钥，那么现在C给B发送信息，B验证后仍会认为是A发送的。

数字证书

为了避免上述情况的发生，引入数字证书来核对通信双方的身份

中间人攻击

出处见水印(从别人转载文章里引用的，原文不可考)

SSL握手

1. 客户端发送可供选择的密码，并向服务器请求证书
2. 服务器发送选中的密码和证书
3. CA公钥验证证书，认证后客户端发送加密后对称密钥，用于加密随后的传输信息
4. 服务器解密密钥，开始通信

为什么在文本传输中不继续使用非对称加密，而改为对称加密呢？
非堆成加密虽然绝对安全，但是加密过程较为复杂，消耗时间，因此在确定信道安全后，转为对称加密，提高传输速度

HTTP与HTTPS对比：
HTTPS与HTTP最主要的区别在于安全性。由于HTTP的安全性不能满足网络传输的要求，因此设计了HTTPS用于安全传输。
HTTPS可以对传输信息加密，可以采用数字证书验证通信双方身份。
可扩展：RSA加密原理/数字证书验证过程/中间人攻击

---

参考链接：

1. HTTP的长连接和短连接
2. HTTP1.0、HTTP1.1、HTTP2和HTTPS的对比
3. http请求方法
4. SA安全与秘钥基础设施
5. CS-Notes
6. 第五章 网络 之 计算机网络基础（一）
7. JavaGuideBooster/Java应届生面试突击/计算机网络/
8. 计算机网络(第七版) - 谢希仁