总结的HTTP比较详细的知识

HTTP

含义

HTTP的直译意是：超文本传输协议。它是一个明文传输协议。何为明文？就是在整个传输过程中，不管是客户端的请求还是服务器的响应，都是明文的，这样就表示其他人可以窃取或篡改。

在层面上，HTTP是面向事务的应用层协议。什么是事务？所谓事务就是，一系列的信息交换，一系列信息交换是一个不可分割的整体，就是说要么全部交换完成，要么一次交换信息都不进行。

每个万维网的网点都有一个服务器进程，它不断的监听TCP的80端口，以便发现是否有浏览器向服务器发出连接建立请求。一旦监听到连接建立并建立TCP连接之后，客户端就会向服务器发出浏览某个页面的请求，服务器就会返回对于页面资源给客户端作为响应。最后，TCP连接释放断开了。这个过程中客户端的请求和服务器的响应之间的交互，必须按照规定的格式和遵循一定的规则，这些格式和规则就是超文本传输协议HTTP。

HTTP协议特点

1. 简单快速：客户端请求资源时，只需要请求路径和请求方法。
2. 灵活：HTTP协议支持任意类型的数据对象，正在传输的类型使用Content-Type标记。
3. 无连接的：无连接是，每次连接只能处理一个请求，服务器响应客户端，当服务器确认客户端拿到响应结果后，服务器就断开连接了，这样节省了传输效率。
4. 无状态的：HTTP协议是无状态协议。无状态是指协议对事务处理没有记忆能力。缺少状态意味着，后续处理需要前面的信息时，它必须重传，这样就导致了请求中的数据量不断增大。再举一个具体的例子，就是客户端去访问一个服务器上的资源，当客户端再次第二次去访问同一个服务器上的同一个资源时，服务器给的响应与第一次相同。因为服务器不知道哪些客户端访问自己，也同时不知道同一个客户端访问过自己多少次。这样的设计简化了服务器的设计。
5. 支持B/S、C/S端
   • B/S：Browser浏览器，负责显示内容；Server服务器，负责提供显示的内容。
   • C/S：Client客户端（通常是APP等），负责显示页面内容；Server服务器，负责提供显示的内容。
   • Browser和Client很像的，两者都是负责内容展示的。只是Client通常表示手机、平板、电脑等上的APP，Browser是指浏览器页面。

服务器的概念

严格来说，服务器是一台计算机，只提供服务，不是用户用的。

通常我们所说的服务器，是服务容器。
服务容器：是一个程序（服务进程），它能监听端口，处理请求并返回请求内容。

我们通常说的搭建一个服务器，监听哪个端口，进而对请求做出响应，其实说的就是服务容器，只不过我们习惯叫它服务器。

HTTP报文格式

使用HTTP协议时，必定是一方是客户端，一方是服务端。客户端发送请求，服务端接收请求并响应客户端。其中请求有请求报文的格式，响应有响应报文的格式。

请求报文

由三部分组成：请求行、请求头、请求体

1. 请求行：请求方法 请求地址 协议版本（注意 都是以一个空格隔开的）
2. 请求头：请求行换行后的内容，有很多HTTP首部字段，比如，Connection、Content-Type等，采取键值对的方式，用冒号‘: ’隔开。（英文的冒号+空格）
3. 请求体：请求头换两行后的内容。一般请求体用的不多，根据请求方式而变。

GET www.baidu.com HTTP/1.1
Connection: keep-alive
Host: localhost
\n
\n
body

请求方式

GET和POST的区别

主要分为两点：

1. 不是基于RFC规范，只是符合语法和HTTP协议语法的话，GET和POST几乎没什么区别，只是名字不同而已。
2. 如果是基于RFC规范的话，同样分为两部分
   • 理论上：GET和POST语法相同，只是语义不同而已。GET是获取资源，而POST是发送数据的，其他方面没有什么区别。
   • 实现上：也就是我们常探讨的那些区别，出现这些区别的是因为浏览器是这些规范的实现者
     常见的那些不同
     • GET的数据在URL上可见，POST数据不显示在URL上。
       • 可见、不显示、不可见的区别
       • 在URL上可见，但是不一定在URL上显示全，可能整个路径在url上可见但是显示不全
       • 不显示在URL上，不代表不可见，POST不显示URL上，但在请求体上可见
     • GET比POST相对来说安全性较差，因为GET的数据在URL上。POST的数据存储在请求体中
     • GET的长度有限制，POST长度无限
     • GET请求的资源可以收藏为书签，POST的不行
     • GET请求在点击后退、刷新按钮时无影响，POST不行
     • GET请求历史参数会保留在浏览器，POST不行
     • GET请求的编码格式：application/x-www-form-url，POST的编码格式有很多，encodedapplication/x-www-urlencoded、multipart/form-data
     • GET请求只允许ASCII（中文在url中存在%之类的东西），POST没有编码限制，甚至允许读二进制

响应报文

三部分组成：响应行、响应头、响应体

1. 响应行 ：协议版本 状态码 描述状态码的原因短语
2. 响应头：同样是HTTP首部字段
3. 响应体：客户端请求的资源内容

HTTP/1.1 200 ok
Content-Length: 362
Content-Type: text/htm
\n
\n
资源内容

TCP

三次握手

在客户端和服务器通讯的过程中，客户端发出请求前必须建立TCP连接，也就是要通过三次握手来达到连接的目的。客户端：A，服务器：B。

用自己的话简明叙述三次握手的过程：

第一次：A向B发出建立连接的信息，表示A能发内容
第二次：B接收到A信息，并响应给A结果，表示B能接收信息，B也能发送内容
第三次：A接收到B给的响应结果，表示A能接收信息

图解：

四次挥手

客户端在完成所有请求后想要断开TCP连接，经历四步确保双方都发完数据后再断开连接。
客户端：A，服务器：B。
双方需要明确的是：客户端和服务器明确对方都发送完数据

第一次：A说我发完了，想断开连接。
表示A发送完数据想断开连接
第二次：B收到A断开连接的请求，并响应A说，我知道你发完了，但是我还没处理完数据，表示B知道A发完数据了但自己还有未处理完的请求，也就是B的数据未发完。
表示B明确A发完数据，B自己还未发完
第三次：B处理完数据了，响应给A说，我的数据也发完了，我要断开了。
表示A此时明确B发完了数据并断开连接
第四次：A接收到B响应的数据，A知道B发完了数据，并断开了连接，A自己也断开连接了
A断开连接

图解：

HTTP1.0和HTTP1.1的区别

1. http1.0 无连接模式，每次连接只能处理一个请求。http1.1的持久化连接解决了1.0的缺点
2. http1.1的持久化连接是只要双方没有提出断开连接，则保持着TCP连接。持久化连接有两种方式：
   • 非流水线方式：请求一次响应一次，再请求一次再响应。每一次请求发出后，必须等待响应结果返回，才能发送下一个请求。这就导致了通信时间会变成，如果一个页面中需要很多资源都需要发请求，必须一个一个的发送接收响应，这样就增加了页面的响应时间，整个过程等待的时间会变成，页面会处于卡顿状态，用户体验也不好。
   • 流水线方式，也叫管线化。http1.1使用的是管线化。可以连续发送请求，不用等待响应结果返回就可以发送下一个请求，最后响应结果会依次返回。这样大大节省了通信的时间。

Cookie的状态管理和Session

因为HTTP是无状态协议，服务器没有对事务处理的记忆能力。当用户登录账号后，再去访问其他资源时，由于服务器不记得该用户登录过，所以用户需要再次输入账号密码登录才能继续访问，这样整个过程就很繁琐。

Cookie

所以，采用了Cookie进行状态管理。Cookie是保存在服务器端的。

说一下登录的过程：
1）初次登录：服务器此时没有Cookie
2）用户登录：服务器验证用户账号密码，并生成一个该用户的Cookie
3）登录成功：服务器会把请求结果以及生成的Cookie一并响应给用户
4）用户再次请求：请求头中会自动带上服务器返回的Cookie值
5）服务器响应：服务器接收到用户请求时，会拿到用户的Cookie，跟自己的Cookie表进行核实，发现存在这个用户的Cookie说明用户登录过
6）给出响应结果，不需要登录

当用户第一次登录时，服务器会验证并生成一个Cookie，会把请求结果以及生成的Cookie一并响应给用户；在用户下次访问时，请求头中会自动带上服务器返回的Cookie值，这样当服务器接收到用户请求时，会拿到用户的Cookie，跟自己的Cookie表进行核实，发现存在这个用户的Cookie说明用户登录过，这次访问不需要登录了。

上图上图：

Cookie缺点：

• XXS注入攻击：Cookie可以保存在浏览器上还可以长期保存在浏览器上，某个坏人复制了我浏览器上的Cookie就可以使用我的账号登录了
• Cookie存在跨域问题：Cookie是保存在不同的域名下面的，也就是不同的域Cookie不同，Cookie不可跨域访问。想象一下，淘宝域名下可以存在百度的Cookie吗？百度域名下可以存在淘宝的Cookie嘛？当然是不能l。
• 对于服务器：当用户量非常大的时候，就代表服务器端保存的用户的Cookie量也很大，这就导致服务器会崩溃。

Session

因为Cookie状态管理存在缺点：因为Cookie是存储在服务器端的，当用户量非常大时，服务器端就不行了。
所以，选择另外一个方式 —— Session。
Session是存储在浏览器的，这样服务器端就减轻了负担，不用每次都传输用户的Cookie值了。

HTTP协议的缺点

1. HTTP明文传输，无法保证信息的保密性，内容可能被窃听
2. HTTP是不会验证通信者的身份，因此可能遭遇身份伪装
3. HTTP无法证明报文的完整性，所以有可能已遭篡改

加密 + 认证 + 完整性保护 才能真正确保安全的通信。 ------- HTTPS协议

HTTPS协议

HTTPSs协议是在TCP/IP协议上加了一层SSL协议。
因为http协议是明文传输协议，所以在请求和响应的过程中，会存在安全问题，为了保证传输过程中的安全性采取https协议。

SSL协议中安全的地方，采取加密。常用的有对称加密和非对称加密。
对称加密：共享密钥加密。只有一个公钥。用这个公钥加密，同时也用它进行解密。

使用共享密钥加密时，首先是得传递共享得密钥。所以进而就是要解决如何把共享密钥传递给服务器？那就引出了另一个加密方法。
非对称加密：公开密钥加密。一个公钥一个私钥。可以用公钥加密私钥解密，也可以用私钥加密公钥解密。通常都是公钥公开，私钥自己保留。

混合加密：使用非对称加密方式加密通信通道，使用对称加密方式加密传输内容。

混合加密的过程，就是服务器自己产生有一个密钥对，其中公钥（k2）是公开的，客户端自己生成一个公钥（k1），当客户端请求服务器时，客户端用服务器的公钥（k2）加密客户端自己的公钥（k1）发给服务器，服务器接收到了使用k2加密后的密文，服务器使用k2对应的私钥解密客户端发来的密文，得到客户端的公钥（k1）。以后，客户端和服务器的传输就使用客户端的公钥（k1）进行加密。

但是这样也会存在一个问题，如果一个黑客拦截了服务器响应内容，黑客也生成一个密钥对，黑客使用它自己的公钥（k3）对拦截内容加密，把k3加密后的内容给客户端，客户端得到黑客的公钥（k3），然后客户端把自己的公钥（k1）用公钥（k3）加密发给服务器，黑客再次拦截，使用公钥（k3）对应的私钥解密，然后再用服务器公钥（k2）加密发给服务器。此时服务器获取的就是黑客发给服务器的内容，而不是客户端发的内容了。

攻击者获取客户端公钥，进而篡改内容。

服务器去申请一个CA证书，确保通信安全。