计算机网络——HTTP

输入URL返回页面的过程：首先，DNS解析域名得到IP，然后利用IP发起TCP三次握手（浏览器会随机生成一个端口去连接服务器的web80端口），然后客户端发起HTTP请求，然后服务器响应请求，返回响应数据。浏览器解析数据，渲染呈现。

HTTP常见字段。客户端发送请求的时候，用Host字段来指定服务器的域名。服务器返回数据的时候，通过Content-Length字段表明本次回应的数据长度。Connection字段最常用于客户端要求服务器使用TCP持久连接，以便其他请求复用。

HTTP协议特点。允许传输任何类型的数据，由content-type决定。是无状态的，每次客户端发的数据都会被服务器认为是新的请求，上一次和这一次无关。支持cs模式。

HTTP请求报文格式，行头体。请求行，请求头，请求体。请求行包括请求方法，请求URL，使用的HTTP版本。请求头是属性名和属性值。
HTTP响应报文格式，状态行，响应头，响应体。状态行包含协议版本，状态码和状态描述。
HTTP状态码：1表示成功接收到客户端请求，需要客户端继续发送请求。2表示成功处理了客户端请求。3表示重定向，就是成功接收了请求，但是还需要进一步操作才能完成请求。4表示无法处理请求。5表示处理请求失败。

（1）HTTP1.1是长连接，减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。

（2）HTTP1.1是管道网络传输，允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序接收，先回应A请求，再回应B请求。要是前面的回应特别慢，后面就会有许多请求排队等着，这称为队头阻塞，会导致客户端一直请求不到数据。0

HTTP1.1相比于1.0。长连接，断电续传，新增一些以4开头的错误状态响应码，Host头处理（因为多个虚拟主机可以共享一个IP地址了）。

HTTP2.0相比于1.1。二进制的文件传输格式，多路复用（并发响应），头部压缩技术（HPACK算法，头信息表，只发送索引号。把头和数据分离，封装成头帧和数据帧。记录已发送的键值对防止重复发送，防止数据冗余，降低开销），服务端推送功能（不需要客户端发起请求），还有数据流。关于数据流，HTTP2的数据报不是按照顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪一个回应。每个请求或回应的所有数据包都是一个数据流。每个数据流都标记着一个独一无二的编号，规定客户端发出的数据流编号为奇数，服务器发出的是偶数。客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。

 HTTP2的问题在于，多个HTTP请求在复用一个TCP连接，下层的TCP协议是不知道有多少个HTTP请求的。所以一旦发生丢包现象就会触发重传机制，TCP连接中的所有HTTP请求都必须等待这个丢了的包被重传回来。这是基于TCP传输层的问题，所以HTTP3把TCP协议改成了UDP协议。

UDP是不可靠传输的，但是基于UDP的QUIC协议可以实现类似TCP的可靠性传输。当某个流发生丢包的时候，只会阻塞这个流，其他流不会受到影响。HTTPS要建立一个连接，要花费6次交互，先是建立三次握手，然后是TLS的三次握手。QUIC协议直接把以前的TCP和TLS的6次交互，合并成了3次，减少了交互次数。

HTTP风险：窃听（密码被盗）、篡改（垃圾广告弹出）、冒充（冒充淘宝骗钱）、

HTTPS和HTTP的区别。HTTP是基于TCP协议的超文本传输协议，HTTPS是具有安全性的SSL加密传输协议。端口不一样，一个是80，一个是443。HTTPS需要到CA机构申请证书，花销大。要注意ssl协议也是基于TCP协议的。

HTTPS的基本原理。首先是TCP三次握手。然后客户端发送一个client hello包，告诉服务器自己可以支持的加密算法（协商加密算法）、SSL协议支持的版本、随机产生的数num1。服务器回应sever hello包，告诉客户端加密算法、确认协议版本、随机产生的数num2。然后服务器向数字证书颁发机构CA获取数字证书（自己设了公钥）传给客户端。客户端收到证书后，首先确认证书真实性，然后拿出服务器公钥，使用它加密报文，并向服务端发送随机数num3、加密通信算法改变通知（以后都用新的会话密钥）加密通信、握手结束通知和给服务端校验的摘要。接着就用三个随机数和之前协商的加密算法，算出本次通信的会话密钥（对称加密）。

（1）混合加密：非对称加密和对称加密的结合。通信之前使用非对称加密交换会话密钥，后续通信过程中全部使用对称加密的会话密钥的方式加密明文数据。
（2）摘要算法：浏览器发数据之前会先通过摘要算法算出明文对应的md5码之类的特定指纹，然后指纹和明文一起发送过去服务器。服务器用相同的摘要算法算出明文，通过对比指纹判断数据的完整性。
（3）数字证书：服务器把公钥给CA机构，CA用自己的私钥和服务器的公钥做成数字签名颁发数字证书。数字证书从服务器传到客户端。客户端通过CA公钥（事先就在浏览器或操作系统）确认证书真实性，从数字证书获取服务器公钥，使用该公钥对报文加密发送。服务器使用加密算法计算的私钥对报文解密。

考虑到性能的问题，双方在加密应用信息的时候使用的是对称加密密钥。但是这个密钥不能被泄漏，所以使用非对称加密的方式保护对称加密密钥的协商（三个随机数和加密算法）。
对称加密算法有AES和ADS。
非对称加密算法有RSA和DSA和ECDHE。（公钥，密钥，比如HTTPS）

get和post请求的不同。
功能，参数传递的方式，传输大小，安全性性。此外，从浏览器端来看，get产生一个TCP数据包，post产生两个（发送过去收到100，然后接收到之后，再次发送）。（1）get是从服务器获取数据，参数在url请求行发送，因此不太安全，url的传输大小比较小。（2）post是向服务器传送数据。参数在响应体里面传送，因此比较安全，传输大小比较大。

HTPS的优化如下。
cookie和session的区别。cookie在浏览器，很容易被窃取。session在服务端，安全员比较高。cookie长时间保持，session短时间失效。cookie存储容量小（小于4k），session存储容量大（但是不能太大，要有删除机制）

web开发中，webserver会自动的为那个用户创建一个session，提供数据存储功能（存储登录信息自动登录，和数据库就不一样，才会有session删除机制）
在HTTP通讯中，客户端发送请求，服务器接受请求并创建session会话，使用响应头返回sessionid给客户端。浏览器收到sessionid以后会保存在本地cookie。当客户端要发起第二次请求的时候，就会访问本地cookie获取sessionid放到请求头，服务器解析请求头和session配对。
分布式系统会带来session共享的问题。同一个用户的多次请求被分发到集群的不同服务器上，就会出现取不到session用户需要重新登录验证的情况。
解决方案：
第一种，session复制和同步，tomat自带该功能。需要数据传输，有延迟，且受内存限制。
第二种，客户端cookie存储法，不安全，存储大小受限。
第三种，反向代理hash一致性。反向代理层让同一个用户的请求落在同一个服务器上。失去了nginx负载均衡的意义。
第四种，后端统一集中存储，比如数据库或缓存，需要增加一次网络调用。可以使用spring session框架，将session缓存到redis里面。使用redis和EhCache实现一级和危机缓存。
第五种，使用token的方式代替session功能，移动端没有session概念，使用token实现。token最终会存到redis，Redis-cluster分片集群中默认支持分布式共享。（最靠谱的分布式session数据一致性解决方案）