大厂面经--史上最全面的http协议考点

一. http协议

1. http协议的发展历程以及每个版本存在的问题

1.1 http1.1优缺点

1.1.1 优点

• 针对tcp连接十分耗时，使用Connection: keep-alive增加了持久连接
• 增加管道机制，在1.0请求必须排队发出的基础上增加了管道机制，请求可以同时发出，但是响应必须按照请求发出的顺序依次返回，性能在一定程度上得到了改善。
• 在1.0版本，服务器端必须等到一操作全部完成后，才会向客户端发送数据的基础上增加了分块传输，没必要等待数据完全处理完毕再返回，服务器产生部分数据，那么就发送部分数据。

1.1.2 缺点

• 高延迟 --带来页面加载速度的降低，这个缺陷主要由于队头堵塞导致的，请求必须排队处理
• 无状态特性 – 带来巨大的 HTTP 头部
• 明文传输 – 带来不安全性
• 不支持服务器推送消息

1.2 http2 优缺点

1.2.1 http2优点

• 二进制传输，更利于计算机的解析
• 头部压缩，使用专门的 "HPACK”算法，在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，还采用哈夫曼编码来压缩整数和字符串，可以达到 50%~90% 的高压缩率。
• 多路复用，客户端和服务端实现真正的全双工通信
• 服务端推送，服务端不在被动等待客户端请求，而是能够主动向客户端发送请求

1.2.2 http2缺点

• TCP 和 TCP+TLS 建立连接的延时
• TCP 的队头阻塞并没有彻底解决

2. http2出现之前针对http连接无法复用缺陷的解决方案（移动端）

2.1 基于tcp的长链接

移动端app都会建立一条自己的长链接通道，通道的实现是基于tcp协议，基于tcp的socket编程技术难度相对复杂很多，而且需要自己制定协议，但带来的回报也很大，目前淘宝应该有自己的协议。

2.2 长轮询

客户端在初始状态就会发送一个polling请求到服务器，服务器并不会马上返回业务数据，而是等待有新的业务数据产生的时候再返回。所以连接会一直被保持，一旦结束马上又会发起一个新的polling请求，如此反复，所以一直会有一个连接被保持。服务器有新的内容产生的时候，并不需要等待客户端建立一个新的连接。它的缺点也很多，长连接增加server端压力，断网，重发机制，过期机制的设置

2.3 websocket

WebSocket和传统的tcp socket连接相似，也是基于tcp协议，提供双向的数据通道。WebSocket优势在于提供了message的概念，比基于字节流的tcp socket使用更简单，同时又提供了传统的http所缺少的长连接功能.

二. https协议

https是在http上建立的ssl加密层，对传输的数据进行加密，是http协议的安全版，https协议的主要功能都依赖于TLS/SSL协议，TLS/SSL的功能实现主要依赖于散列算法/ 对称加密算法/非对称加密算法，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性

2.1 http的存在的问题

• 使用明文通信，内容可能被窃取（数据泄露/数据篡改/流量劫持等）
• 无法证明报文的完整性，所以可能遭到篡改，也就说说没有办法确认发出和请求到的报文前后是i相同的
• 不验证通信双方的身份，因此有可能遭遇到伪装，http无法验证通信方的身份，任何人都可以伪造虚假服务器欺骗用户。

2.2 https协议的构建

针对明文通信，内容可能被窃取：采用对称加密+非对称，对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的。https将对称加密与非对称加密结合起来,充分利用两者各自的优势，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

针对无法证明报文的完整性/身份验证：：采用校验数字签名，将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文文一起传送给接收者。接下来就是接收者校验数字签名的流程了。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
这里的私钥和公钥采用的证书颁发机构的方式。

2.3 https协议的工作流程

1.Client发起一个HTTPS，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。

2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。

3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。

4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。

5.Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。

6.Server使用对称密钥加密“明文内容A”，发送给Client。

7.Client使用对称密钥解密响应的密文，得到“明文内容A”。

8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。

2.4 https协议和http的区别

• HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO,谷歌、百度优先索引HTTPS网页;
• HTTPS需要用到SSL证书，而HTTP不用;
• HTTPS标准端口443，HTTP标准端口80;
• HTTPS基于传输层，HTTP基于应用层;
• HTTPS在浏览器显示绿色安全锁，HTTP没有显示;

三. tcp协议

3.1 三次握手

• 客户端发送syn包（syn=x）到服务器，并入SYN_SEND状态，等待服务器确认
• 服务器收入syn包，必须确认客户的SYN（ACK/ack=j+1），同时自己也发送一个SYN包（syn=k），既SYN+ACK包，此时服务器进入SYN_RECV状态。
• 客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手

3.2 四次挥手

• 客服端调用close等函数主动关闭, 并向服务端发送一个含FIN(seq=x)的报文, 然后就进入FIN-WAIT1阶段,
• 服务端接收到对端的FIN后, 立马向对端回一个ACK(ack=x+1,seq=y)确认, 然后进入CLOSE-WAIT阶段, 该阶段服务端还能够将没有发送完的数据发送给对端. 当服务端将数据发送完后再发送一个FIN段, 之后进入LAST-ACK阶段
• 客户端接收到对端的ACK时, 进入FIN-WAIT2阶段, 该阶段客服端还能够继续接收数据, 但是不能在发送数据了;
• 服务端的数据传输完了之后，向客户端发送FIN和ACK(FIN=1, ack = x+1,seq =k), 之后客户端进入TIME_WAIT阶段. 等待2MSL后客户端彻底关闭.
• 客户端收到服务端的关闭报文之后，发送ACK=1, ack= k+1, 服务端收到后完全关闭该连接。

3.3 三次握手和四次挥手的问题

【问题1】为什么三次握手？
为了让客户端和服务端都能确认自己能正常接收/发送报文，防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
（client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据）

【问题2】为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

【问题3】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接

3.4 tcp的可靠传输是怎么保证的？

• 确认和重传：接收方收到报文就会确认，发送方发送一段时间后没有收到确认就重传。
• .数据校验
• 数据合理分片和排序，TCP会按MTU合理分片，接收方会缓存未按序到达的数据，重新排序后再交给应用层
• 流量控制，运用TCP报文段中的窗口大小字段来控制，发送方的发送窗口不可以大于接受方发回的窗口大小。
• 拥塞控制：当网络拥塞时，减少数据的发送。

总结一下步骤：

1. 在传递数据之前，会有三次握手来建立连接。

2. 应用数据被分割成TCP认为最适合发送的数据块（按字节编号，合理分片）。这和UDP完全不同，应用程序产生的数据报长度将保持不变。（将数据截断为合理的长度）

3. 当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。（超时重发）

4. 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒。（对于收到的请求，给出确认响应）（之所以推迟，可能是对包做完整校验）

5. TCP将保持它首部和数据的校验和。这是一个端到端的校验和，目的是检测数据在传输过程中的任何变化。如果收到段的校验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。（校验出包有错，丢弃报文段，不给出响应，TCP发送数据端，超时时会重发数据）

6. 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。（对失序数据进行重新排序，然后才交给应用层）

7. 既然IP数据报会发生重复，TCP连接的接收端必须丢弃重复的数据。（对于重复数据，能够丢弃重复数据）

8. TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能容纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。（TCP可以进行流量控制，防止较快主机致使较慢主机的缓冲区溢出），TCP使用的流量控制协议是可变大小的滑动窗口协议。

9. TCP还能提供拥塞控制。当网络阻塞时，减少数据的发送。

3.5 tcp和udp的区别以及适用场景