打开抖音互联网会发生什么|青训营笔记

98 阅读4分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的的第5篇笔记

HTTP协议的交互过程及请求详解

HTTP的交互流程简单来讲就是客户端与服务器端的通信,包括客户端对服务器端的请求以及服务器端对客户端的响应。

首先客户端与服务器端建立一个连接,三次握手经历完成之后才能建立一个稳定可靠的连接。  

这里用到JavaSE在网络阶段的基本知识:“三次握手”。第一次握手:客户端给服务器端发送一个syn的标志位;服务器端接收到syn后会返回一个ack(相当于一个回调的机制),同时还有一个服务器端的syn;客户端接收服务器端发送的syn后会再次给服务器端发送一个ack,这样才算完成三次握手。

然后客户端就可以向服务器端发送请求并且服务器端也会给客户端响应了。在HTTP1.1后,他们之间的连接就是可持续的连接,也叫作常连接。客户端可以向服务器端发送多个请求并且得到多个响应。

当客户端不再发送请求给服务器端并且服务器端没有响应发送给客户端时,就可以断开连接了。

这里面有一个四次分手的原则。客户端向服务器端发送断开连接的请求;服务器端接收到请求后,返回可以断开连接的请求,客户端断开连接并且释放资源;服务器端向客户端发送断开连接的信息;客户端向服务器端发送同意断开连接的信息,服务器端断开连接释放资源。

image.png 首先,HTTP协议是一个规范。一定会限制请求的格式。
链接

请求行包括三个属性。描述对应的请求的时候,最精确的形式就是K-V键值对的格式。
请求头中也是一堆的K-V数据。包含头信息中的一些附加信息(比如客户端允许接收的信息格式)。
空行的作用就是分割请求头和请求体。
请求体:当发送某一个请求的时候,请求后面可以加一些用户定义的参数(比如表单)。以K=V的形式发送给后台。

HTTP1.1优化
  • 长连接
  • 部分传输
  • HOST
  • 缓存
HTTPS-SSL/TLS

非对称: 不告诉别人我的加密算法, 只有协商的时候另一方才知道

网络提速

  • 多图一起请求, 一起响应
  • TCP发生丢包时: 对头阻塞(一直等待那一个包)
  • QUIC协议: 具有弱网优势, 0 RTT(使用了Diffie-Hellman算法(迪菲-赫尔曼算法)来保证数据交互的安全性并合并了它加密和握手过程来减小连接建立过程中的往返次数,以此来达到0RTT的目的), 改进UDP为可靠传输(解决对头阻塞)
  • 数据中心: 简单地理解为服务器集合的地方, POP接入(增加与互联网接入的入口)
  • 网络路径优化: CDN优化,
  • 同运营商访问: 跨运营商的服务器访问会比较差
  • 路径优化: DSA(计算每个机房的最优路径)
容灾

故障发生, 故障感知, 自动切换, 服务回复
方案:

  • 设置机房之间的专线(避免走因特网(外网))
  • GTN保证自动化容灾, 探测哪个机房挂了, 然后(这一步是防止雪崩)感知另一个机房的容量是否能够承受这个机房(已经挂了)的流量, 如果可以的话, 进行切换
  • 云到端: 自动降级/容灾 (需要切域名, 但是浏览器访问就不能做到)
  • Bug导致全crash -> 前置兜底逻辑/cache文件
故障排查
  • 故障明确(故障出现在哪里)
  • 先止损再排查(止损方法: 是否有容灾手段(组件or系统), 没有则降级)
  • 分段排查 (客户端排查, 服务端排查, 中间链路排查)
  • 预防故障是最重要的(监控报警 -> 故障演练/预案 -> 故障降级/止损)

总结

课程通过举例抖音视频获取讲解了网络通信的过程,还讲解了网络容灾,我认为这部分最难掌握因为这部分涉及一些场景,学会如何排查网络容灾很重要。